September 21, 2014 by Jeff Schertz · 3 Comments
An earlier article entitled Polycom CX5100 for Lync 2013 introduced the newest RoundTable device for Lync, briefly discussing the firmware update process. As this product was brand new at the time there had been no newer firmware updates yet released to warrant covering that process in detail.
Now that the CX5100 and the nearly identical CX5500 have been out for some time a few firmware updates have been made available for them. As usual it is always a best practice to utilize the latest device firmware version available to provide for the best experience possible. And like the other Updates articles on this blog site the following table will be updated over time to capture any future releases for these two new products. For details on the older CX5000 models head over to this older article.
The same software release package is applicable to both the CX5100 and CX5500 models so there are no separate download files to worry about. The CX5500 does include additional Polycom UC software similar to what is found in the VVX phones which is already included in the package, but this additional code is simply unused by the CX5100 model.
For details on specific issues addressed in each update check the ‘Resolved Issues’ table listed near the end of the Release Notes for that specific version.
|1.0.0||December 2013||Initial Release of CX5100 model|
|1.1.0-10114||May 2014||Hotfixes and support added for the CX5500 model||Release Notes
|1.1.1-10117||August 2014||Hotfixes and security related patches||Release Notes
These new models include a few different available methods for updating the firmware on the device. Older models were basically limited to a single process which was not all that user-friendly. It required installing an application on a Windows PC, physically connecting a Windows computer via USB, reading the documentation to find a little known default device password, and then finally copying the package files to the device using a complicated command line utility.
The newest models have completely redesigned the upgrade process to provide for different requirements. For one-off, hands-on updates the software can simply be dropped on a standard USB flash drive and inserted into the system to trigger an instant upgrade. Yet for bulk updates the software can be retrieved from a central location and scheduled for periodic updates to automatically be applied.
The multicolored LEDs surrounding the three Mute buttons on the camera base of either model are used to indicate the current readiness status of the device when powered on.
- No Light - Device is ready to be used and mute is not enabled. (Or it is powered off.)
- Solid Red – Device is ready to be used and the microphones are muted.
- Flashing Green – Device is powering on or rebooting.
- Flashing Red/Green – Device is performing a firmware update process.
USB Flash Drive
By far the simplest method, and a welcome change over the previous generation device, a single file can be copied to a USB flash drive and inserted in the camera base to trigger an automatic update. This process can be used to perform either an upgrade or a downgrade as the device will apply whatever version firmware is provided. Do not store more than one firmware package on the drive, only copy over the desired version.
- Download the desired firmware package form the table above and then save the .tar file to the root of a USB flash drive. (Do not decompress the package or extract the files.)
- The USB drive should be formatted as FAT32 . (FAT partitions are also compatible but NTFS-formatted volumes are not.)
- Insert the USB drive into the USB Type-A slot located at the base of the tabletop camera unit.
The secondary USB port on the Power/Data Box can also be used but this port is typically the blocked with a small rubber plug. It is simply easier to just use the more accessible port on the camera base.
After inserting the USB flash disk the device (when idle and not actively in a Lync call) will look at the root directory of the volume and search for a valid firmware update package.
- On a CX5100 if a valid firmware file is located then the upgrade process begins automatically within a few seconds. The three mute buttons will begin to alternately flash red and green to indicate that the process has begun.
- On a CX5500 the display will report a successful discovery of the firmware package on the USB disk, prompting to either cancel or proceed with the upgrade. This screen will automatically advance to the upgrade process within a few seconds so there is no requirement to confirm by actually selecting OK. Tapping Cancel within those first few seconds though will interrupt the automatic process and return to the main menu.
On either model the process is the same from this point forward as the blinking red and green lights indicate the firmware is being updated and the process should not be interrupted.. The CX5500 will additionally report the current upgrade status on the integrated display
From this point on do not attempt to use the device, disconnect, or connect anything. Removing the USB flash drive could corrupt the firmware and damage the system.
The device will first download the files from the USB disk and then perform a reboot within one to two minutes. After the first reboot completes it will begin installing individual files in the firmware packages which typically takes about 10 minutes for the first batch of components. A second reboot may be triggered mid-way through this process potentially a third reboot to complete then entire process. The entire process should only take about 15-20 minutes.
After the final reboot the blinking lights will stop and the main screen will be displayed on a CX5500.
- Remove the USB drive.
Although not necessary, if desired the firmware version can be checked to validate the expected version was successfully applied. This is very easy on the CX5500 as it can be looked up on the device itself or via the integrated UCS web management interface (covered later in this article). But on the CX5100 only way to check without connecting from a separate PC would be to review the device log files. (Additionally the control panel application can also be used on either model as an alternative method, covered in the next section.)
The following process is valid for either model (CX5100 or CX5500).
- Connect the same USB flash drive which was just used for the update to a computer and look for a folder on the root directory named with the device’s Serial Number (e.g. 88142541B785DB).
- Open this folder and look for the most recent log file package (e.g. log_1411222116678.tgz) which should have been written to the USB drive after the last boot up process.
- Open the desired .tgz file with a compatible application (like WinRar) and then open the data\log\system_properties.txt file.
- Search for the string “polycom.ver” to locate the reported version (ro.build.polycom.ver) and build number (ro.build.polycom.num) strings in the file. In the example below the device’s current firmware is the 1.1.0-10117 release.
As mentioned a much easier way to do this on the CX5500 is to use the touch interface to browse to the Phone status menu.
- On the device’s home screen select Settings > Status > Platform > Phone and review the Device Software Version value.
Also briefly mentioned in a previous article was the new Polycom CX5100/CX5500 Control Panel application which provides the ability to manage, update, customize, and troubleshoot the devices in ways not possible with the older generation RoundTable models.
Fellow Lync MVP and Polycom employee Brennon Kwok has already posted an excellent article covering the various options in the Control Panel application so all aspects of the utility do not need to be rehashed here. As the focus of this article is on updating the firmware then only the Software Update sections will be covered.
Note that the update processes triggered by the control panel require that the CX5100 or the CX5500 is connected to an Ethernet network, the device has a valid IP address, and has access to the Internet (or to the network location of a custom update server if one is defined).
Also this process cannot be used to downgrade a device as it will only apply newer updates that are stored on the configured update server. The only supported method to downgrade a device is via the USB process shown in the previous section.
The control panel can be used to update the firmware in one of two ways: either immediately or scheduled for a future, reoccurring time.
- Download and install the latest version of the CX5100/CX5500 Control Panel Application from the Polycom Support site on an Windows workstation.
- Connect the CX device using the blue USB 3.0 Type A-to-B cable from the tabletop camera base to the workstation.
- Launch the CX5100/CX5500 Control Panel Application and the tool should connect to the device and default to the System Information screen under the System section.
Note that the current Device Software Version is displayed in the screen above. Clearly this is a much easier way to verify the current firmware on a CX5100 than the log-based approach shown in the previous section.
The following steps walk through the process of trigging an immediate update over the Internet and without having to download the firmware to a USB drive first.
- Switch to the Software Update menu under the System section and select the Update Now button to initiate an upgrade process.
The device will then connect to the currently configured update Server source and look for a package different than what is currently installed. By default the central Polycom update server which is available over the Internet is defined which always contains the latest publically available firmware package. The exact location is not listed on this menu but is simply shown as ‘polycom’. The next section of this article will show how to point the device to a custom distribution point instead of using the default Polycom server.
- Once the update process begins the control panel will change to show on the update status. Disconnecting the USB cable from the PC at this point will not cause any problems as the device is using it’s own Ethernet connection to retrieve the package directly from the server. The only thing the control panel is doing at this point is reporting the upgrade status.
The remainder of the upgrade process is exactly as described in the USB Flash Drive section earlier in this article. Once complete the control panel will reconnect to the device.
- If the focus changes to the Profile Editor section the device password may be prompted for. Simply hit Cancel and then switch back to the System > System Information screen where the new version can easily be confirmed.
These steps show how to schedule an automatic update using software currently posted to the Polycom update server.
In order to modify the configuration of the device the device password will be required. The default password is the serial number of the unit, but be aware that the tabletop camera unit and the main box typically placed on the floor have different, unique serial numbers. The serial number located on the main floor box is what should be entered here, not the serial number found on the camera base. An easier method to retrieve the serial number is to simply use the control panel as shown in the following steps.
- Launch the CX5100/CX5500 Control Panel Application and the tool should connect to the device and show the System Information screen under the System section.
- Record the Product Serial Number (e.g. 88142541B785DB) as this is also the default device password which will be prompted for in the next step.
- Switch to the Profile Editor section and the control panel application should request the device password. If it does not then either exit the control panel application and restart it, or go to the Load Profile menu in the bottom left corner and select Load from Device.
- Enter the current device password.
- Select the Software Update menu and then select a day under the Update Frequency menu and as well as a time under the Update Time menu.
The example above shows that at 4:00AM device local time every Tuesday the public Polycom update server will be contacted to check for any updates. If at that time a newer version is found on the update server then the same update process and behavior documented earlier in this article will begin.
- To optionally change the firmware distribution point simply replace the text ‘polycom’ with a valid URL of a web server hosting the desired firmware package (e.g. http://server.domain.com/directory/)
Point to the directory where the desired firmware package has been expanded. To prepare the source directory extract the .tar file into the desired location so that the ‘millennium’ folder created by the extraction process is located in the directory that pointed to. Do not point directly to the millennium directory in the update Server path as that is what the device looks for.
For example a subdirectory named ‘update’ was created at the root of the web server in this example and then the latest firmware package was extracted into that directory which automatically created a millennium subdirectory. For future updates make sure to delete all previous files before extracting the new package.
Note that if the Update Server path is changed this also changes the location that the device will go to get updates when the previously discussed Update Now process is manually triggered.
To return the configuration to the default Polycom server simply enter ‘polycom’ as the Update Server value and the device will recognize that name and utilize the hardcoded distribution URL.
- Click the Apply to Device button to write the configuration changes to the device. The update process will begin at the scheduled date and time.
Web Management Interface
This approach is only valid for the CX5500 model as the embedded UC Software stack includes the same web service that the Polycom VVX phones models utilize. Just as with those phones the CX5500 can be updated remotely by accessing the embedded web interface, signing as as an administrator, and then updating the device.
Note that the password used to remotely connect as an Admin or User to the Polycom Web Configuration Utility is not the same as the device password used in the previous step for the control panel application. The embedded UCS stack utilizes its own separate password which is identical to the VVX phones. The default Admin password is ‘456’ and the default User password is ‘123’.
- Connect to the device’s IP address in a web browser.
- Leave the Login As selection on Admin, enter the password (e.g. 456), and click Submit.
- Select the Utilities > Software Update menu.
Note that the options shown above are the same as what the control panel application provides. Whereas the control panel has the immediate update and scheduled update options in different locations the web management utility has them both on the same page.
- To trigger an immediate update process identical to what was covered in the previous section simply click Update Now.
- Alternatively to schedule the update process to be triggered at a later date and/or time configure the Update Frequency and Update Time as desired and click Save.
Additionally the Update Server URL can be changed here, as instructed in the control panel, when needing to utilize a central destitution server other than the public Polycom update server.
August 31, 2014 by Jeff Schertz · 5 Comments
There are multiple ways to initiate communications sessions in Lync across different modalities and features. These various options can utilize a few different network paths to reach the intended destination(s). The path that each takes depends primarily on the type of communication involved and is also influenced by the number of parties involved.
In Lync, and going all the way back to Office Communications Server, there are a few constants that can be defined.
- All communication data can be categorized as either Signaling data where the session setup and handling is performed, or as Payload which would be be the actual content itself (e.g. media, instant messages, shared files).
- For signaling data Lync clients will always be connected to a Lync Server and this traffic will always go from client to server to client. Lync clients do not and cannot send signaling messages directly to each other.
- For payload data all modalities can utilize either a two-party Peer-to-Peer (P2P) model or a Multiparty Conferencing Unit (MCU) model. Again the primary signaling path is always handled by the Lync Server as previously defined, but the payload can take different routes depending the scenario. While most modalities can leverage either model depending on the type of call in session, some of them only support a single model and will always communicate in that fashion.
Using these constants the various ways that sessions can be initiated and how the different modalities are utilized can all be defined to understand exactly what is sending network data to where, and what actions trigger changes in these paths.
The following table can be used to quickly reference which types of modalities support which of the two communications models. For the purposes of simplicity media traversal through and Edge Server is not included here but regardless of the model the Edge server may be involved in transparently proxying one or both of the two data streams.
As noted some only support a single model while other can work in either model depending on the type of session currently in use when the specific modality is added. Modalities which only support the MCU model will trigger an immediate escalation from an existing P2P session up to an MCU session when selected.
For example say that a basic audio call has been established between two Lync clients which utilizes the P2P model by default. Then one of Lync users decides to add whiteboarding to the session, which requires the MCU as it is not a modality that is supported directly between the Lync clients. The act of enabling the Whiteboard modality will automatically escalate the audio call to a conference call and at this time the P2P media payload session will be stopped and both Lync clients will then negotiate media paths directly to the MCU on the Lync Front End server. This escalation can happen only once per session and is permanent. From this point on the addition of any more participants or MCU-only modalities are seamless as the session has already been moved to the MCU. Regardless of how many other participants or modalities are added to the call removing all of these will never trigger any sort of de-escalation back to a P2P session. So even if there are only two participants remaining in the conference call and audio is the only modality left in use the call remains hosted on the MCU.
The most basic communications type simply invites the user to an instant message conversation. The act of locating the other user, showing their presence, and sending the initial IM message as basically an invitation is all handled by the signaling path through the Lync server. The payload, or the instant messages themselves, are embedded in the SIP signaling traffic for instant messaging and thus are one in the same.
This is the only modality in which the payload is included in the signaling path as SIP messages. Additional features like sending files or pasting images into the IM window will trigger a different type of session establishment. Only text and emotions (which are represented by their text values) are included in this single stream.
Internal clients connect directly to the primary Lync Front End server in the user’s home pool. This traffic is always sent as TCP traffic to port 5061 on the Front End server, encrypted using TLS.
Externally connected clients connect to an Edge Server via TCP to port 443 (by default) on the Access Edge external IP, also encrypted as TLS.
Federated, Lync Online, and other supported public IM platforms will connect to the same Access Edge external IP but on port 5061 (by default) which is used for federation communications.
If a third Lync client is added to an active IM conversation window then the session is automatically escalated to the Lync Front End server and is handled by the IM Conferencing service. Because the IM session and payload was already handled by the server end-to-end then there is no change in the communications path between the original two clients.
Selecting an entry on the phone menu will place an outgoing audio call to the contact, depending on which option or number is selected. Just hitting the button will place a call to either the only option (e.g. Lync Call) or to the last used option when the contact contains more than one choice. As is true with all the actions in Lync the server is handling the signaling traffic so this includes the call invitation, reply, media establishment instructions, and anything else involved in the call setup. Once a secondary media connection is established then the payload may be delivered to a few different locations.
Signaling traffic is sent to the same servers as defined in the previous section for either internal or external clients. This is consistent throughout the rest of the scenarios covered in this article and from this point forward only the payload traffic patterns will be discussed specifically.
Among the multiple calling options which may be available on a Lync contact they will all fall into one of three categories: a native Lync Call, a Telephone Call, or Voice Mail.
Lync Calls to other Lync clients in the same environment, federated companies, Lync Online, and soon even Skype clients will utilize native media establishment rules which dictate that a direct connection between both parties is negotiated whenever possible, otherwise the Internet Connectivity Establishment (ICE) protocol will be utilized to provide fallback assistance by leveraging the Edge Server.
- In the event that a direct connection is available between both clients then the media payload will be delivered to randomly selected UDP or TCP ports on both clients somewhere between 1024 and 65535 by default. It is possible to reduce this port range via Lync Server client policy configuration as documented here by selecting a custom range of contiguous ports. This approach provides the ability to open a much smaller range (no less than 40 ports) on any firewalls which may sit between internal client subnetworks. For audio streams UDP is the default protocol but if that cannot be established then Lync can fallback to using TCP, which is less desirable for delivery of real-time media over IP networks.
- If direct connectivity between the two clients fails for any reason then ICE will be used to leverage the Edge Server for assistance. Each leg of the bidirectional audio stream could potentially used different paths, whichever is the most efficient for each side. Clients will either negotiate media connections directly to the client through one or more firewalls (STUN) or be forced to send media directly to the Edge Server (TURN). For STUN connections the media payload would again be sent to any range of high-ports (1024-65535) on the remote client’s firewall. For TURN connections the client would establish a media session with the Edge Server directly. Internal clients would prefer to send media to UDP 3478 on the Edge Server’s internal interface, or to TCP 443 for media fallback if UDP connectivity to the Edge Server is not available. External clients would negotiate media in the same UDP-before-TCP preference to the Edge Server’s external A/V interface over a dynamically-assigned port in the range of 50000-59999. Fallback attempts in the event that ports in this range are not reachable can also utilize 3478 and 443. Realistically ICE is a complex topic that is difficult to summarize in a single paragraph, so the important concept here is that the payload delivery will always attempt to be delivered directly and if that is not possible then there are many different options available to insure that the call is completed somehow.
Calls placed to telephone numbers can be routed a few different ways.
- First, if the called Work number belongs to another Lync user who is actively signed into Lync then the server will leverage reverse number lookup to simply perform a Lync call as there is no need to send this call to any outbound PSTN destination. This call routing will be identical to the scenario just covered n the Lync Call section above.
- If the resolved Lync user is offline then the call will be forwarded to another destination based on the rule defined for that user (Call Forwarding, Simultaneous Ring) or sent to an Exchange UM server for voice mail.
- If the called number is an external number like a cell phone or other PSTN destination then the signaling path is still client to server but the Lync Server will handle the reset of the call out through an mediation services to the PSTN. The media payload for this call may be sent to a Mediation Server over either UDP or TCP to a dynamically assigned port in the range of 49152-57500. Alternatively if Media Bypass is enabled and available for this call then the payload would not go to the Mediation Server but instead directly to a media gateway.
- For external Lync clients the media payload session would need to travel to the Mediation Server by way of the Edge Server to first get into the internal network and then reach the mediation services, before be routed back out to the PSTN.
Calls to voice mail are essentially a P2P session even though a server is technically involved. The Exchange Unified Messaging service is not an MCU though and is really just another client in this communications path. So calls to the Subscriber Attendant are categorized as a peer call between a client and server as these are the only two parties involved.
- Calls placed to Voice Mail will be routed to the appropriate Exchange Unified Messaging server and will utilize the same UDP and TCP rules for RTP media as any other Lync audio call.
- The Exchange UM service be default will dynamically assign a port in the 1024-65535 range just as Lync clients do, but this can also be configured although it is not technically supported by Microsoft.
Video calls will follow the exact same behavior as audio calls in Lync except that the additional video modality will is also included in separate media sessions. From the signaling to the media payload delivery both audio and video utilize the same paths, protocols, and selection logic explained in the previous section.
Once a session has been established there are a number of additional modalities when can be added or certain features which leveraged will trigger additional sessions in the background. Some of these additional options will retain the existing P2P communications pattern while others are capabilities provided only in multi-party conference calls be one of the Lync Server services, which will automatically escalate the existing P2P session to a conference up on the Lync Front End server even if there are still only two parties connected.
The layout of the content menu in the Lync 2013 client incidentally makes it very easy to understand which options fall into which category.
- The Desktop and Application sharing options on the top row will respect the current call model, either establishing additional P2P sessions for the payload, or when already in a multiparty conference call simply connecting to the MCU directly.
- The options along the bottom row will all trigger the creation of a conference call and move the current peer session up to the server.
Although these concepts are not new to Lync (or OCS, or even LCS for that matter) when moving over from a different type of collaboration platform it is important to understand the models that Lync adheres to when planning for or troubleshooting an existing environment.
August 20, 2014 by Jeff Schertz · 1 Comment
Upon looking at visitor statistics for this blog one of the reoccurring trends is the amount of traffic to articles like Updating Lync Phone Edition Devices after Microsoft releases a new round of Lync updates. It can sometimes be difficult to successfully navigate through the various updates which follow different release schedules which are sometimes bundled together with other Office releases, so hopefully this article can bring some additional clarity to the subject.
This article will continually be updated to serve as both a source of new update information as well as a history of all past updates for both client and server platforms. Releases for IP phones will continue to be tracked in their original articles so this article will only cover the server and soft client releases. The ‘Updates’ tag can be used as a quick route to all of these articles. Keeping this data up-to-date and accurate is an ongoing process feel free to leave comments regarding any errors or dead links.
One thing to understand is that for some products Microsoft will continue to leave multiple previous versions online on their download sites, while others (namely Lync Phone Edition) are removed an only the latest cumulative releases are provided.
Lync 2013 Server Updates
As Microsoft only provides the latest releases for the server components then the following two links are always updated with the most recent information and can be used as a definitive source of the latest server updates.
Typically one does not need worry about the individual components as the LyncServerUpdateInstaller.exe is the ideal package to download and run on any servers. This tool will locate and upgrade only the applicable components on each Lync server it is executed on locally.
At this point in the product cycle there is no real value in documenting the steps which have been already covered on various other websites for basic installations (like here and here) to more complex articles covering Enterprise Edition pools with mirrored databases.
The important points to understand are the following:
- Use the LyncServerUpdateInstaller referenced above to make life easy.
- Start inside-out and work from Front End servers toward Edge servers.
- Do not forget to update and verify the backend SQL database for each Enterprise Edition pool that is patched
For occasions when working with the individual packages is desired then the following table covers each cumulative update release with links to the original Knowledge Base articles for each new component.
This matrix provides a visual aid to when and how often some of the various Lync components are updated as cumulative releases will typically not refresh every single server component.
|Front End Server and Edge Server
|UC Managed API 4.0 Runtime
|Web Components Server
|Web Conferencing Server
|Call Park Service
|UC Managed API 3.0 Workflow
|Central Management Server
Lync 2013 Client Updates
Windows Desktop Client
The following table lists major client update packages with links directly to the download pages for both the client and any prerequisite components, which are only represented again when they themselves are updated.
|Release Date||Version Number||KB Article||Client||MSO||MSORES||IDCRL||Lynchelp|
|February 2013||CU1||15.0.4454.1509||KB2812461||x86 | x64||x86 | x64|
|March 2013||15.0.4481.1000||KB2760556||x86 | x64|
|July 2013||CU2||15.0.4517.1004||KB2817465||x86 | x64||x86 | x64||x86 | x64||x86 | x64|
|August 2013||15.0.4517.1504||KB2817621||x86 | x64|
|November 2013||CU3||15.0.4551.1005||KB2825630||x86 | x64||x86 | x64||x86 | x64||x86 | x64||x86 | x64|
|February 2014||SP1||15.0.4569.1503||KB2817430||x86 | x64|
|March 2014||15.0.4569.1508||KB2863908||x86 | x64|
|April 2014||15.0.4605.1003||KB2880474||x86 | x64||x86 | x64|
|May 2014||15.0.4615.1001||KB2880980||x86 | x64|
|June 2014||15.0.4623.1000||KB2850074||x86 | x64|
|August 2014||CU5||15.0.4641.1000||KB2881070||x86 | x64||x86 | x64||x86 | x64|
- Releases denoted with ‘CU’ refer to the unofficial but commonly used Cumulative Update nomenclature for Lync.
- Releases denoted with ‘SP’ refer to a Service Pack release for Microsoft Office.
- 32-bit downloads are recorded as ‘x86’ while links to 64-bit download are labeled as ‘x64’
- Items in strikethrough text have been pulled and replaced by the following update but have been left in this table for posterity.
July 24, 2014 by Jeff Schertz · 42 Comments
This article was posted to serve two purposes which are to introduce the latest 5.1.1 firmware and its new features as well as detail the out of the box experience for the fifteen lucky Lync User Group attendees who managed to win a free Polycom VVX410 and Color Expansion Module at their local event this month.
The primary news here is that this new 5.1.1 UCS software is now Qualified for Lync 2013 as part of the Third Party Interoperability Program (3PIP). This new version brings a couple of new features (covered later in this article) in addition to a host of hotfixes and stability improvements.
These new features in addition to what was previously added in the UCS 5.0 release are now all fully supported with Lync by both Polycom and Microsoft.
Out of Box Experience
A new product SKU (Stock Keeping Unit) has been added for each of the VVX desktop phone models which are preconfigured for Lync in addition to including the nominal Polycom license fee for Lync usage wrapped up in price. The product description will include ‘LYNC’ indicating this (pictured below). There is absolutely no physical difference between these phones and the standard VVX phones as the only change is that the default configuration is set to the Lync Base Profile on the device at the factory.
All new VVX phones are still being shipped with some variant of 4.1.x firmware and have not yet moved to shipping with any 5.x releases on them from the factory. As it is always recommended to upgrade the firmware to the latest available release then this should be performed first. (New units will move to 5.1.x firmware from the factory later on.)
- To check the current version of software press the Home key on the phone and then navigate to the following menu: Settings > Status > Platform > Application > Main
- Take note of the reported Version number. (The latest version is 220.127.116.1186 as of the date of this article so if this version was previously loaded by someone else then there is no need to update anything.)
As covered in past articles there are various ways to upgrade the firmware on VVX phones but the easiest is to simply use the web server interface on phone to download and install the latest version from a Polycom hosted server over the Internet.
To connect to the phone’s configuration web server the device’s IP address can be looked up directly on the phone.
- Press the Home key on the phone and then navigate to the following menu: Settings > Status > Network > TCP/IP Parameters
- Note the IP address and then connect to that address in a web browser.
- Leave the Login As value at the default setting of Admin and then enter the default administrator password of ‘456’. (If Internet Explorer 11 is used then it may be required to add the IP address to the Compatibility View list if getting stuck at this menu.)
- Browse to the Utilities > Software Upgrade menu and verify that the Server Type is set to
- Select the Check for Updates button to check the hosted server for the available versions.
- Select the latest version (18.104.22.16886) and then confirm the process.
The phone will reboot a couple of times as the upgrade process completes and then will return to the default home screen.
After upgrading to the 5.1.1 firmware a few important changes will have been applied to the Lync Base Profile as part of the latest Lync qualified firmware. Most importantly the phone’s management web interface will be disabled as a security measure. Connections to the phone’s IP address from a browser over either HTTP or HTTPS will no longer function. Additionally the phone and web interface will display a warning whenever the administrator password is still set to the default value of ‘456’.
Enable Lync Base Profile
New phones provided in the Lync SKU will not need to have this step performed as it is already set at the factory. Previous articles have covered various ways to set this but the easiest is to use the Multi Key Combo of 1,4,9 to jump right to the Base Profile menu.
- Press the 1, 4, and 9 keys together and hold them all for 3 seconds and then enter the administrator password (again the default is ‘456’).
- At the Base Profile menu Select Lync and confirm the choice to immediately reboot the phone.
Register to Lync
After the phone completes the reboot and anytime it is powered on in Lync Base Profile without an existing Lync user registration it will default to the PIN Authentication menu.
- If utilizing PIN Authentication on an internal network enter the desired Lync user’s phone number or extension and the associated authentication PIN, then select Sign In.
- If not utilizing PIN Authentication then press the Exit key, followed by the More key, and then the Sign In key.
- Select User Credentials and then enter the Lync user’s appropriate account information. Either the NetBIOS Domain Name and sAMAccount Name format or Universal Principal Name (UPN) format are accepted.
The following new features have been introduced in 5.1.1.
- Contact Card support allowing calls directly not just to the Lync SIP URI but all destinations including Exchange Voice Mail and various PSTN numbers.
- Improved Boss/Admin call scenarios including the ability to transfer a call directly to voice mail..
- PIN Authentication support directly from the web interface to allow for remote provisioning.
- Full support for up to three daisy-chained of the latest Color Expansion Modules (a.k.a. sidecars) with Lync. Note that only a single expansion module is supported when the phone is powered by PoE so if adding a second and/or third module the phone must be connected to an OEM 48v power supply.
Color Expansion Module
If an expansion module is available then it can be connected to the phone either powered off or when it is already on. Simply connect the provided patch cable to the AUX port on the phone and the AUX 1 port on the sidecar. Also use the mounting bracket and thumbscrews to attach both units to each other.
After the initial Polycom logo splash screen appears the module will most likely show a blank screen unless the registered Lync.has manually pinned enough contacts as Favorites to bleed over from the phone’s main screen to the expansion module.
A single expansion module will provide for 3 pages of contacts to switch between using the 3 buttons on the bottom center of the module. If the registered Lync user does not have any pinned Favorites then no additional contacts will appear on the home screen.
- Sign into a desktop Lync client using the same account as what is registered to the phone and then select a number of contacts and use the ‘Add to Favorites’ menu item to permanently pin these contacts to the special Favorites group in Lync.
If the changes are not immediately reflected on the phone after pinning favorites then reboot the phone to trigger a refresh as this can happen in some environments; for example when the Exchange Unified Contact Store is enabled on the Lync users account.
Now that the phone is registered to Lync there are no additional steps required as the necessary configuration information is passed down to the phone from the Lync server in-band. That being said there are still a host of other settings available in the firmware to tweak and improve the experience. This section will cover some helpful parameters, some old and some new.
Obviously the suggested guidance is to change the default administrator password to a non-default value, but for the purposes of lab testing this may not be important so simply dismissing the warning may be desired.
- Note the red warning icon in the upper right-hand corner of the phones display.
- To clear the icon press the Home key and then browse to the following menu: Settings > Status > Diagnostics > Warnings and then select the Clear Icon button. The warning will remain listed in this menu but the icon will be removed from the main screen.
Enable Web Server
The built-in web service can be re-enabled directly on the phone using the process outlined in the following steps. It can also be turned back on via standard provisioning methods by utilizing the associated parameters covered on page 14 of the UCS 5.1.1 Release Notes.
- Press the Home key and then browse to the following menu: Settings > Advanced > Administration Settings > Web Server Configuration
- Select Web Server and choose the Enabled option.
- Select Web Config Mode and choose the desired option (HTTP Only, HTTPS Only, or HTTP/HTTPS).
- Select Back and then Save Config to save the changes and immediately restart the phone.
To further customize the phones where is a list of some new (and old) parameters which can be used to control some of the more beneficial settings on the VVX phones.
Because the following parameters are specific to controlling behavior in UCS then there is no way to utilize the Lync Server to provide these settings in-band. A separate provisioning server would still be needed to manage a quantity of devices in this manner.
This parameter controls whether the web service is enabled or not.
This parameter controls whether or not HTTPS is required on the web service.
This parameter can be used to enable one-touch calls to Voice Mail from the message button
This parameter is used to enable or disable power saving (screen sleep) outside of defined office hours. The default office hours configuration is covered in the full 5.1.0 administrators guide. Only touchscreen models (VVX 500/600) are enabled by default.
|0 / 1
(VVX 300/400 Disabled)
June 24, 2014 by Jeff Schertz · 5 Comments
The next round of quarterly Lync Users Group meetings has begun to be scheduled and announced for next month.
For a full schedule of regional events the Lync Users Group Locations page lists all planned event locations with links to the associated Meetup.com page for each regional group. For current members If your region’s event is not yet scheduled you just make sure that your notification options are configured so that you’ll get an alert when the new event is posted. For anyone who is not yet a member and would like to participate simply create a new Meetup account (or use an existing one) and join your local group.
This meeting’s theme is “An evening with Enterprise Voice” and will be conducted in our familiar two-session format:
The first session presented by Sonus will cover audio gateways and how they are integrated into Lync voice deployments.
The second session presented by Lync MVP Elan Shudnow will cover Quality of Service (QoS) and Quality of Experience (QoE) topics as applicable to Lync Server 2013.
Industry Experts will be on-site to deliver these presentations and help answer any questions related to Lync. Food, beverages and additional door prizes will be provided courtesy of the Lync Users Group.
As usual I will be hosting the Chicago event downtown. Food will be ready at 5:30 so come early if you can to spend time socializing with the group before the presentations begin at 6:00
|Thursday, July 24th
5:30PM – Food and Networking
6:00 PM – Presentation Kickoff
|Chicago UC Users Group||Microsoft Technology Center
200 East Randolph Drive, Suite 200
Chicago, IL 60601
June 6, 2014 by Jeff Schertz · 7 Comments
Resetting configuration data or rolling back the firmware on Lync IP phones is one of the most basic troubleshooting procedures, but at the core is also often misunderstood. This article will cover the reset procedures as well as explain what is actually happening on the devices.
Although most of the instructions in this article have been covered in various past articles it may be difficult to locate when incorporated into separate, larger topics. In an effort to provide a single resource for the simple task of resetting different Lync compatible Polycom IP phones, as well as explaining what the reset is actually doing, creating a separate dedicated article seemed logical.
These categories are quite different in their design. The Microsoft Lync product team designed and owns the LPE software and any devices running this are basically ‘dumb’ handsets which can do nothing until they are first successfully registered to a Lync server which will provide all possible configuration parameters in-band. Meanwhile the Polycom 3PIP devices utilize Unified Communication Software (UCS) firmware which was designed prior to Lync compatibility so these devices are capable of much more and may only receive a subset of their possible configuration parameters during Lync registration. Many other parameters can be set out-of-band using different methods which can then be stored in different configuration containers. Additional background on these two different device families can be found in this recent article.
Lync Phone Edition
The common range of Polycom CX model phones which run LPE are very simple devices and actually performing a reset is straightforward. But it is important to understand exactly what ‘resetting’ a device means and what happens when the events are triggered.
There are two types of reset procedures which accomplish different tasks in LPE. In the official Microsoft documentation these procedures are described as either a Hard Reset or a Factory Reset, yet these terms can be a bit misleading. Often people may refer to a partial reset as ‘soft’ but a full reset as ‘hard’ which already does not match up with the official terms. Secondly in LPE the ‘factory reset’ process as it is called does not actually perform a factory reset in the traditional sense of the term. These processes were originally documented in the article Externally Provisioning Lync Phone Edition.
Note that these reset processes are different between the Aries family of phones (CX500/600/3000) and the older Tanjay phone (CX700) models.
The Hard Reset process performs one task: it wipes all configuration data currently cached into the phone. It simply blows away the user credentials, downloaded root certificates, issued client certificates, in-band user configuration parameters, the cached device lock code, time zone setting, etc. Basically everything expect the firmware version itself. Whatever version was active before this process was triggered is left unchanged.
Polycom CX500 / CX600 / CX3000
- To wipe the configuration simply press and hold both the * and # keys on the phone and then connect the power source to turn the device on. Continue to hold the keys for approximately 10 seconds until the following message appears: “The operation you have requested will erase all user-created data.”
- Select Yes to confirm the action and the device will reboot, wiping the current configuration.
- To wipe the configuration data locate the physical, recessed reset button located on the bottom of the device between the USB and headset ports.
While the device is already powered-on use a straightened paperclip or another small tool to depress and briefly hold the device reset button, releasing it after the reboot is triggered.
Revert Firmware and Wipe Configuration
The Factory Reset process performs two tasks: wiping the configuration data and reverting the firmware to the previously installed version.
It is important to understand that this process is not reverting the phone to the version of firmware that was preinstalled on the factory, unless the device has never been updated since it was originally installed. This is the most commonly misunderstood concept of this topic. This is why the term ‘Factory Reset’ is not an ideal name for the process.
Exactly what version it will be reverted to cannot be known until the phone reboots and the version number can be verified in the System Information menu. The previously installed version could be older or newer depending on the update history of the phone. In most cases where devices are systematically upgraded throughout each Cumulative Update (CU) released by Microsoft then it would most likely be one version older.
Polycom CX500 / CX600 / CX3000
- To revert the firmware and wipe the configuration simply press and hold both the 4 and 6 keys on the phone and then connect the power source to turn the device on. Continue to hold the keys for approximately 10 seconds until the following message appears: “The operation you have requested will reset your phone to factory default settings.”
- Select Yes to confirm the action and the device will reboot, wiping the current configuration, and reverting the firmware to the previously installed version.
- While the device is running use a straightened paperclip or another small tool to depress and briefly hold the device reset button, releasing it after the reboot is triggered.
- After the device reboots perform the screen calibration to complete the initial setup and then depress the button again in the safe manner before.
- Repeat this reset and calibration cycle a total of five times to trigger the phone to revert to the previously installed firmware.
This tedious manual process triggers the device’s built-in protection mechanism where a corrupted firmware load that causes the device to crash on bootup. If this happens five times in a row then the device assumes the current firmware is longer longer functioning and will then revert to the last version. Manually triggering this is the only way to revert the firmware, and this process was clearly simplified in the Aries family to a single step.
Firmware Storage Design
Most administrators would typically think of the ‘factory reset’ phrasing as synonymous with reverting a device back to the exact configuration it was shipped from the factory with, which might include both the parameter configuration and the version of firmware. That type of reset is very common among networking devices for example, and is typically accomplished by the device having some read-only area of memory in which this original firmware is saved and can always be recalled.
Yet LPE was not designed this way at all. Going back to the original Tanjay device running the first release of Lync Phone Edition all LPE devices use the same design of a dual-partition design consisting of an Active Partition and and Inactive Partition. Each of the two areas are completely independent and can store a full, separate firmware image. This design allows for two different firmware versions to be installed allowing the phone to switch between them when needed. Note that LPE will never have the same version of firmware on both partitions, the other partition’s firmware must be unique whether it is a newer or older version.
For example a brand new device might leave the manufacturing line with only the original RTM firmware release installed and the inactive partition might still be blank. (This example is solely for educational purposes and does not reflect what may or may actually be performed by device manufactures on brand new phones.)
An update is applied to the phone to bring it up to a more recent firmware version (e.g. 4.0.7577.4397). This new version is applied into the other partition which now becomes the active partition. The previous 4.0.7577.0 version remains intact in the original partition which is now deactivated.
When another firmware update is applied to the phone for an even newer version (e.g. 4.0.7577.4420) then the downloaded version is again installed into the inactive partition, overwriting the previously stored version (4.0.7577.0). The phone reboots and swaps the active and inactive partitions. The previously active 4.0.75774397 version is now the inactive partition and would be available if manually reverted using the process shown above.
At this point it should be evident that it only takes 2 updates to being purging older versions permanently from memory as the phone switches back and forth, overwriting each partition in turn.
The benefit of this design is that upgrades or downgrades will be applied to the inactive partition while the phone is running which minimizes any impact to the device user. When the defined period of inactivity is reached then the device will reboot and switch to the other partition which only adds a few additional minutes to the normal reboot process.
One limitation of this design though is that there is no hardcoded original factory image saved in the phone, only the version that was last installed which exists on the now-inactive partition. So as multiple upgrades are performed over time the older versions are overwritten. In the unlikely event that a much older version is required on the phone for some reason then the device can not be rolled back to that version simply be performing a device reset. Instead the older version of firmware must be uploaded into the Lync Server and approved which will trigger a downgrade process as the device locates the different version on the server, downloads it, and then installs it into the inactive partition. All LPE devices (aside from the discontinued Tanjay CX700 model which is impacted by a certificate change) can be upgraded or downgraded from any version to any other version across the twelve packages released by Microsoft to-date since the original Lync 2010 RTM firmware.
Unified Communications Software
The larger range of Open SIP and Lync Compatible/Qualified Polycom IP phones in the SoundPoint IP, SoundStation IP, and VVX model lines all utilize the same Polycom-designed UCS firmware. These phones are much more powerful in terms of configurability and thus the reset process can be a bit more complicated to understand. This does depend on the environment configuration though so in many scenarios resetting a phone can be a one-step process, while in other deployments it may take a few reboots to completely wipe all configured parameters.
The biggest difference in the reset processes between these and LPE devices is that there is no way to change or rollback firmware directly from the phone itself. These devices do not store any secondary firmware images so access to some type of provisioning server or hosted software server is required. The web management UI included in UCS devices can be used to manually upgrade or downgrade the firmware from either the Polycom Hosted server on the Internet or a custom download server.
As there are multiple storage containers for different parameter types and configuration methods then there are also multiple options available for wiping portions or all of these. The guidance is different depending on whether or not a central provisioning server is deployed and in use. If there is no separate provisioning server in place and the phone receive all of their configuration data directly from the Lync Server during registration then resetting the phone is a basic one-step process. But in the event that the phones are configured to use a central provisioning server then multiple steps may be required to insure that all settings have been permanently erased for a phone, which is a more advanced process.
This process was originally documented in the article Polycom Qualified Lync Phones with PIN Authentication.
If you have no idea what a provisioning server is or you know that one is not defined on the network then all device parameters are stored on the phone only. These can be a combination of settings defined directly on the phone, passed in-band from the Lync server during registration, set manually on the device’s web management user interface, or imported into the phone from a static configuration XML file. Regardless of the method used a single action will be able to revert all of these settings to the factory default configuration.
- On the phone access the main menu from either the Home key or the Menu key, depending on the device family.
- Navigate to the Settings > Advanced menu and then enter the device administrator password, which is ’456’ by default, and select Enter.
- Then navigate to the Administration Settings > Reset to Defaults menu.
There are five available menu options which each perform different tasks, some of which can overlap. These options will be explained in more detail in the next section but for now only the Reset to Factory option is needed as this will reset the entire configuration.
- Select  Reset To Factory and confirm the action by selecting Yes. The phone will immediately reboot into the factory default configuration.
Alternatively there is also a shortcut to triggering the Reset to Factory option as shown in the steps above which can be used from basically any menu of the phone, even prior to the application software starting up when the phone is first powered on. The UCS firmware contains various different Multi Key Combination (MKC) codes which can be used to perform different functions or jump directly to some specific configuration menus.
As some models use different MKCs for the same actions the following table is provided as a quick reference for convenience..
Device Factory Reset MKC SoundPoint IP 321, 331, 335, 450
SoundStation IP 5000, Duo
1 3 5 7 SoundPoint IP 550, 560, 650
4 6 8 * VVX 300, 310, 400, 410, 500, 600 1 3 5
Press and hold (in any order) the MKC for at least 3 seconds to trigger the reset process for the specified phone model. (For example on a VVX 500 press and hold the 1, 3, and 5 keys.)
Enter the device administrator password, which is ‘456’ by default, and select Enter. The phone will trigger the reset and reboot immediately.
A lengthier process is applicable when a provisioning server is already in use and the phone has pulled some configuration settings down from this out-of-band server as well as uploaded some of the local settings back up to the server. This read/write approach provides the phone the ability to have a central provisioning method for any required parameters (e.g. corporate background pattern) and also save any of the individual user’s customization (e.g. ringer volume). Whenever settings are modified on the phone or via the Web UI then the phone will write these to files which are automatically created on the provisioning server.
Before addressing the full reset process it is important to understand the different menu options and how they apply to the device files saved on the provisioning server. This helps to select the correct option for the desired reset process.
As covered in a previous articles the provisioning server is simply a file server which stores different shared and unique files for the phones. Among these files are two types: manually created and automatically generated. During the initial provisioning server configuration an administrator may choose to define one or more static configuration files to store both common and device-specific parameters. These administrator-managed static files are not modified in anyway by the individual phones and are treated as read-only. In the event that the provisioning server path is provided via DHCP to the phones then even after a full factory reset of the device it will automatically relocate the file server and reapply any configuration parameters defined in these static files.
The other file types used by the phone are automatically created the first time it connects to the assigned provisioning server. Some of these files are used to store log data (*.log)while others are used to store backup configuration data (*.cfg). The phone will create files using its MAC address with suffixes of “-phone.cfg” and “-web.cfg” to store parameters assigned using different methods.
The phone stores all configuration data internally in one of three containers: Local, Web, and Device.
The first two containers are defined by the method used to define the parameters, meaning that any settings modified directly on the phone are stored in the Local Configuration container and any settings configured using the web management UI by connecting to the phone’s IP address using a browser are stored in the Web Configuration container.
The third container, Device Settings, is a special category of device.* parameters which are always stored here regardless of what method was used to actually define them. An example of a device parameter would be the Base Profile setting which is accessible from both the phone menu and the web UI, but it does not matter where it was modified as it is always stored in the Device container, not the Local or Web container.
In the following screenshot the two configuration files are highlighted for a device with the MAC address of 0004f2831d71.
Viewing the 0004f2831d71-phone.cfg file shows that a user-selected ring tone volume has been saved back to the server. This parameter was set on the phone itself and thus it was saved in the Local Configuration container.
Viewing the 0004f2831d71-web.cfg file shows that a user-selected ring tone pattern has been saved back to the server. This setting was selected using the web management UI and therefor it was saved in the Web Configuration container.
Any of the special device parameters are not backed up to the server and are only stored in the phone’s memory.
This complex design provides granularity for various levels of reset methods for phones which have multiple sources of configuration data..
For one, if a device is malfunctioning the settings can be wiped from the phone itself but much of the customized settings would be left intact on the server so that after a reboot these settings will be downloaded and reapplied to the phone.
- Navigate to the Reset to Defaults menu as shown in the previous section.
- Select  Reset to Factory to wipe all configuration containers on the device.
After the phone reboots any local or web configuration which was previously saved to the provisioning server will still be intact and the phone should connect to the file server and reapplied these parameters into the phone. Any of the device.* parameters would have been purged and if they were previously defined from either the phone or the web UI then they would be gone.
Alternatively if it is desired to permanently wipe all customized settings for a device then the phone can be told to erase the saved settings on the server as well as wipe them from local memory so that after the reboot there will no longer be any customized parameters on the server to apply. Note that only the –phone and –web files can be overwritten by this process. Any administrator-defined settings stored in the managed files will not be touched and will still be reimported into the phone after this process is completed.
- Navigate to the Reset to Defaults menu as shown in the previous section.
- Select  Reset Local Configuration to wipe any local settings both on the phone and on the provisioning server. The phone will automatically connect to the file server to remove all override parameters in the MACADDRESS-phone.cfg within a few seconds. If the phone automatically reboots wait for it to complete and then return to the Reset to Defaults menu.
- Select  Reset Web Configuration to wipe any web UI settings both on the phone and on the provisioning server. The phone will automatically connect to the file server to remove all override parameters in the MACADDRESS-web.cfg within a few seconds. If the phone automatically reboots wait for it to complete and then return to the Reset to Defaults menu.
Ignore the option to reset Device Settings as these settings will be cleared in the next step anyway.
Also make sure not to select the Format File System option as this will forcibly delete the application software on the phone, leaving only the BootROM. If that happens the phone will no longer function correctly and will need to be pointed to a provisioning server in order to download the firmware and reinstall the application software portion.
- Select  Reset to Factory to wipe any remaining configuration on the device. After the automatic reboot the phone will start with default settings plus any administrator-provisioned settings which may be statically defined on the file server.
To summarize the behavior of the various options the difference is that Reset to Factory will wipe all settings on the phone only, where as manually selecting options  and  first will forcibly delete any saved override settings on the server as well as wipe all settings saved in the phone itself.
Recovering a Locked Phone
Finally, a little known but important behavior to understand is how to recover a device in which the administrator password has been changed and forgotten. Comparatively this problem cannot occur on LPE phones as the reset procedure clears all user data, including the device lock PIN which may have been set.
Because UCS devices include an administrative menu on the phone as well as the ability to change the default administrator password then it is possible to be locked out of a device. In the event the password is unknown a factory reset can be triggered on the phone using the MAC address of the device as the password. Note that this process can not be used at access or modify any protected administrative settings on the phone, it can only be used to trigger a factory reset and only when triggered in a certain way: during initial bootup of the phone.
- Power cycle the phone and watch for the message “Starting application, press Cancel to interrupt” to be displayed, and then quickly select the Cancel button as this menu will only appear for a brief moment.
- At the Welcome screen a countdown timer will begin. Press and hold the About menu to locate and record the MAC address (or just flip the phone upside-down and look at the label on the bottom of the device).
- Release the About key to return to the Welcome menu and before the timer expires press and hold the reset MKC (listed in the table earlier in this article) and a new new should appear prompting for the password to reset the phone.
- Enter the device’s MAC address as the password and then select OK to reset the phone. This will wipe settings exactly as described earlier in this article and in doing so will return the administrator password to the default value of ‘456’ allowing access back into the device to be provisioned again.
Entering the password in this menu is quite cumbersome, so the following guidance should be read closely before attempting this for the first time, otherwise this exercise may result in a phone being smashed into hundreds of little pieces.
When entering the password the first softkey (1->Aa) indicates the default character entry mode of Numeric (1) in front of the arrow (–>) which is followed by the other entry modes of Capital Letters (A) and Lowercase Letters (a). Repeatedly tapping this softkey will infinitely scroll through the three different character input modes. So if the MAC address starts with a number then simply tap the appropriate key(s). If or when a letter is reached then use the softkey to toggle between numeric, capital letter, and lowercase letter modes. For this purpose only the numeric (1->Aa) and capital letter (A->a1) modes are applicable.
When in numeric mode a single key press will only enter the number on that key and immediately advance the cursor. But when in letter mode the key may need to be pressed multiple times to cycle to the desired letter assigned to that key. So for example selecting the letter ‘A’ is as easy as tapping the ‘2’ key once. But note that the cursor does not immediately advance in this mode as there is a 2 second delay while the phone waits for any additional keystrokes in the event the latter characters on that key are desired. So make sure to wait until the blinking cursor reappears before entering the next character in the password. In the instance that the letter ‘E’ is needed then the ‘3’ key would need to be depressed twice in rapid secession in order to scroll over the ‘D’ and stop on the ‘E’.
Because the entered string is hidden by stars there is no way to confirm the actual character being entered so it is critical to pay attention to the timing and order of keys pressed. Most likely it will take multiple attempts to be successful, but it does get easier with practice. Repeating this character entry in other phone menus which show the characters briefly before changing them to a star is helpful when trying to understand the input logic.
Here are the exact keystrokes to reset a phone with an example MAC Address of 00-04-F2-AA-81-4C:
Character Actions 0 Press the ‘0’ key once 0 Press the ‘0’ key once 0 Press the ‘0’ key once 4 Press the ‘4’ key once F Select the input modifier once to toggle into capital letter mode
Press the ‘3’ key three times quickly
2 Select the input modifier twice to toggle back into numeric mode
Press the ‘2’ key once
A Select the input modifier once to toggle into capital letter mode
Press the ‘2’ key once
Wait for two seconds for the blinking cursor to return
A Press the ‘2’ key once 8 Select the input modifier twice to toggle back into numeric mode
Press the ‘8’ key once
1 Press the ‘1’ key once 4 Press the ‘4’ key once C Select the input modifier once to toggle into capital letter mode
Press the ‘2’ key three times quickly
The moral of this last section is do not lose the administrator password and there should never be any need to do this
May 27, 2014 by Jeff Schertz · 2 Comments
This article is a continuation on a series of articles dedicated to the H.264 Scalable Video Coding (SVC) video codec implementation utilized by Lync 2013. Previous article introduced the standards-based codec and the possibilities it contains based on the defined specifications. Additional articles, like this one, take a closer look at how the actual implementation of the codec in Lync 2013 operates.
The concept of temporal scaling in H.264 SVC was introduced in this article at a marginally high level. Microsoft consultants Danny Cheung and Mariusz Ostrowski also cover this topic briefly in their video deep dive session at the recent Lync Conference, which can be seen at about 35 minutes into this recording.
The benefit which SVC provides here is that a single encoded video stream can incorporate multiple frame rate requests. While the H.264 SVC codec specifications defines for support of many additive layers the actual implementation of this codec in Lync 2013 supports a maximum of two temporal layers per video stream.
The Base Layer which is identified with a Temporal ID (TID) of ‘0’ must been sent to the decoder at a minimum, providing video in the frame rate encoded for that layer. The base layer provides all the data needed to reconstruct a video stream at only the single frame rate provided in the single stream. This layer includes the initial Intraframes (I) which are key frames that contain all the needed data for a given single frame of video. The subsequent Predicative frames (P) include only the data which has changed since the previous ‘I’ frame was sent, which are basically the deltas of video data. After a set number of P frames are sent a new I frame is encoded to refresh the complete frame image.
For an additional frame rate request a single Enhancement Layer can be added to the same stream which includes even more ‘P’ frames, effectively doubling the frame rate. The enhancement layer alone is useless as it is only comprised of the interim predicative frames; thus it must be sent alongside the base layer to be of any value to the decoder.
If a Lync 2013 client participating in a multiparty conference call receives requests for two different frame rates from multiple parties of the same resolution then the encoding client can provide for both requests in a single video stream. It does this by encoding a specific frame rate in the base layer and then using the same frame rate value in the enhancement layer. Then for clients requesting the lower value the AVMCU will only forward on the base layer to those clients, meanwhile any clients requesting a higher value will be given both the base and enhancement layers be the AVMCU.
In the basic scenario where an encoder is attempting to supply requests for both 15 fps and 30 fps it will encode video at 15 fps in the base layer and then additionally encode video at 15 fps again in the enhancement layer. For decoders requesting 15 fps the AVMCU will only forward the base layer on to those clients, while other clients asking for 30 fps would be sent both layers by the AVMCU. Those clients would receive two temporal layers of 15 fps each to produce a 30 fps stream (15 + 15).
These individual layers would not have the same data, but would contain unique individual frames. Think of it as every other frame encoded from the camera is placed into alternating layers. So frame A would go into layer 0, then frame B into layer 1, then frame C would be placed back into the base layer 0, and frame D in the enhancement layer 1, and so on. Decoding layer 0 would result in receiving frames A, C, E, while decoding both layers 0 and 1 together would provide all of the encoded frames of A, B, C, D, E, F, and so on.
H.264 SVC in Lync 2013 supports a third frame rate of 7.5 fps and one might think that that lower request could be extrapolated from the above stream, but this is not the case. Even though 7.5 is evenly divisible from the encoded 15 fps rate in the above example the data is not packaged in a way that individual frames can simply be dropped. In earlier articles this concept may have been over-simplified to give the impression that the AVMCU can simply drop half of the individual frames to cut 30 fps streams down into 15 fps, for example, and then again by half down to 7.5 fps. But this was not the intention, and this article should help clear up the fact that the flexibility of the codec lies completely within the individually packaged layers. The AVMCU can only work with the entire layers by choosing to either forward or strip the single enhancement layer.
So for the rare occasions when a client is asking for 7.5 fps then the encoding client would need to send an additional, complete video stream with a pair of temporal layers encoded at different frame rates. The effectively doubles the work that the encoding client must do as it’s no encoding the video twice, but the impact on bandwidth is not actually doubled as the second stream providing lower frame rates would be comprised of less data when compared to the higher frame rate stream.
As Lync Server matures in future versions and device processing power increases it is quite possible that this same benefit in providing multiple frame rates could be expanded into providing multiple resolutions as the SVC codec. This is called as Spatial Scaling and is defined in the codec’s design specifications, showing how SVC has plenty of room for growth and is only partially utilized in its current implementation.
May 9, 2014 by Jeff Schertz · 7 Comments
Microsoft has recently posted all recorded sessions from the 2014 Lync Conference to the Channel 9 events page on MSDN. Among these are a pair of sessions I presented this year on the topic of planning for and understanding the impact of video traffic on your network.
Video – What in the World are You Doing to My Network?
Networking Track / Level 300 – Technical
“So, you are thinking about adding video to your Lync deployment. Join us for an end-to-end discussion about how Lync utilizes video and what this means for your network. We will discuss bandwidth utilization, planning, and what customers really see on their network after video has been deployed.”
Both sessions cover identical content but due to room capacity some of the breakout sessions required an additional session to meet demand. Recordings of each session can be found at the following locations. The Q&A at the end of each session differs but for the most part the rest of the presentation is the same.
The basic goal for this presentation was two fold. Firstly to further educate people on the technical nuances of video in Lync from how it looks on the client to how it works on the back-end. And secondly to show that although video can be locked down and limited pretty extensively in Lync it is actually not a bad idea to simply leave the defaults and instead just monitor usage retroactively.
The story as it was told walks through technical aspects of the video codecs in play and then looks at how these provide the user experience that was brand new to Lync 2013. This leads into discussion of bit rates and how much bandwidth can be consumed across different video calls and conferencing layouts, and then wraps up with a look at real-world data and feedback.
The important points in this section focus on the use of H.264-SVC (and RTV when older version Lync and OCS clients are involved). A detailed look into the Temporal Scaling behavior of the new SVC codec also describes how a single video stream can provide multiple frame rates without additional costs over the network, up to a point. Additional focus is placed on the different limitations of the various Lync client versions and types available.
Dissecting the Video Experience
This section takes a hard look at how screen real estate, or sometimes the lack of it, has a direct impact on the amount of video bandwidth which can be consuming in a particular call. What you should learn here is that physical screen size places a limit on the bandwidth available for video as does the inclusion of other components like participant rosters, IM conversation windows, and even content sharing (which has its own associated network costs).
Doing the Math
The third section dives into the numbers by reviewing video and audio bit rates across various resolutions and frame rates as well as which of these options are available for different call types. What beings to become apparent at this point is that the more participants in a multiparty conference call with video enabled, approaching up to the maximum of 5 live video feeds, the better in some cases.
The final section reviews actual reporting data provided by Microsoft from their own internal usage of video for the entire 2103 calendar year. Some interesting results and trends appear which all tie back into concepts and behaviors explained earlier in the session. The story wraps up by revisiting why or how the video modality is important and the immeasurable factors out there to keep in mind when planning for video conferencing in Lync.
Additionally this previous article has been updated with links to the posted recordings for all of the other video-related breakout sessions presented by other Lync MVPs, Masters, SMEs, and Microsoft employees.
April 25, 2014 by Jeff Schertz · 7 Comments
A topic originally meant for the recent Lync Conference summary article, it seemed more appropriate to break this out into a separate post. This subject comes up now in almost every discussion related to Lync Enterprise Voice deployment needs for physical desk phones and conference phones.
Recently the most common question, especially evident at the Lync Conference, is this incorrect notion that Lync Phone Edition devices are ‘dead’ and will be considered end of life any minute now. Another common area of confusion is the difference between Lync Qualified and Optimized handsets, and what the roadmaps look like for these different types of device families.
There are already a number of older articles detailing some of the technical difference between optimized and qualified devices like this on VOIP Supply and over here on No Jitter, so there is no reason to rehash all the details. This article will be a summarization of the state of IP desk phones available for Lync today.
As with any article on this site it would be prudent to revisit the past for a few moments before looking ahead to the future. It is also helpful to define some of the terms used in these conversations as not only is there some overlap but the value of some of these classifications will change over time, and already have begun to some degree.
Optimized for Lync
The term ‘optimized’ has some very specific meaning behind it in relation to Lync peripherals, but each can differ a bit whether referring to headsets, desk phones, conference room devices, etc. For the purposes of Ethernet-connected desk and conference phones which are not simply USB-only audio devices driven by the Lync soft client the classifications are quite straightforward.
The only device types that fits into this classification are phones which run the Microsoft Lync Phone Edition (LPE) client. This includes currently available devices from Aastra (6721ip / 6725ip), HP/Snom (HP 4410 / HP 4120), and Polycom (CX500 / CX600 / CX3000). Microsoft developed the firmware for these devices and still manages any software development and support while the device partners simply build a hardware shell around the components required by the client.
All of the device models listed above are part of the Aries family which first launched with Lync Server 2010. The older Tanjay models (Polycom CX700 & LG-Nortel IP8540) run an older design of Lync Phone Edition but are still supported with Lync Server 2010 and 2013 today with current versions. Manufacturing of these devices has ceased but there may still be some new units still for sale yet sitting on a few warehouse shelves. Another anomaly here is the Polycom CX3000 which is a conference room phone as opposed to a typical desk handset that also runs the same Aries firmware as the rest of these models.
Historically the Aries devices are 99% identical between each vendor with only varied physical differences between models and brands. The user experience and functionality are basically identical across all devices. At the time of this article Microsoft has delivered at least eleven different cumulative update releases for these models since the original Lync Server 2010 RTM product release. Originally this client was referred to as Lync 2010 Phone Edition but with the release of Lync Server 2013 the ‘2010’ portion of the name was dropped to prevent confusion as the same client is supported on either version of Lync Server. (This change happened as part of the January 2013 cumulative update release.)
In the past 3 years Microsoft has addressed numerous issues across the periodic updates, but overall very few new features have been added to the clients. While desktop and mobile Lync clients often receive both hotfixes and feature enhancements the LPE firmware has changed very little in that arena. Outside of a handful of additions like Music On Hold support, the ability to change a users presence directly from the phone, or native support for Lync Online the majority of work has been focused on the behavior and stability of the product.
In summary the LPE Aries devices have been the workhorse of Lync IP desk phones with a proven track-record, massive deployments in numbers, and all with the backing and support of both the software and hardware providers. What they may lack in terms of some of the less common features is made up for in providing an intuitive, tried-and-true user experience that for the most part has been left unchanged.
Compatible with Lync
On the flipside the devices in this category could not be much more different from optimized phones. Firstly the terms qualified and compatible are used interchangeably throughout Microsoft’s documentation. The general approach is that a device is deemed compatible after it successfully passes through a Microsoft-controlled qualification program. This is sometimes referred to as the Third Party Interoperability Program (3PIP) as made evident by the directory name where non-LPE firmware updates are stored on the Lync pool fileshare (\1-WebServices-1\DeviceUpdateStore\3PIP).
The most important difference here is that these devices are entirely in the hands of the manufacturers themselves and typically run their own software. Primarily this means that devices provided by different partners will have their own look and feel, feature sets, support channels, etc. The commonalty though is that in order to reach Lync qualification a standard set of test criteria must be passed which insures that all of these devices provide at minimum a consistent level of Microsoft tested and approved capabilities. Many of the devices can then go above and beyond in terms of providing enhanced features not yet part of the qualification process or inapplicable features which fall outside of the Lync Server world but which still offer extended value as traditional telephony capabilities.
One typical example of the latter is something like device paging. Paging is not a capability provided by Lync Server but there is no reason that 3PIP devices which inherently support this feature cannot still utilize it out-of-band from Lync while still actively registered to a Lync server.
There is a much wider, and growing, variety of devices in this category provided by Microsoft partners. The Lync Solutions Catalog lists all compatible IP phones that have passed qualification, which is up to 19 different devices at this time from partners like Audiocodes, Polycom, Snom, and Spectralink ranging from primarily wired Ethernet device to even a handful of WiFi and DECT wireless phones.
These devices are just stating to hit their stride in terms of performance and capabilities in native Lync environments. Starting with initial development to simply reach a basic level of compatibility with Lync the current landscape shows a number of device options which have passed numerous qualification tests to provide the core set of features needed. Although none of these devices have yet to achieve a one-to-one feature parity relationship with LPE capabilities that is on the horizon.
The perceived demise of LPE devices has been unfairly rampant in the past year in the industry, due in part to the emergence of many new compatible IP handsets, and partly related to the lack of any feature-enhancements in these older devices. Microsoft has recently extended the mainstream support deadline for Lync Phone Edition out to April 2018, offering extended support into 2023.
Jamie Stark also has just published an article to the Lync Team Blog on this same topic, restating Microsoft’s commitment to both optimized and qualified device programs.
The emergence of the qualification program allows for vendors with a traditional SIP telephony background to embed more of features which are typically needed when trying to emulate use-cases from an older telephony platform as much as possible. Some or all of these extended features may not actually be needed and the ability of the Lync desktop client to basically drive the LPE devices means that common UI elements are not required in the handset itself as the user drives the experience form the desktop soft client and the phone simply handles the more processor-intensive media payload on the back-end.
What should now be evident is that sometime in the near future the many qualified handsets will reach a level of maturity that rivals Lync Phone Edition, while provide much more in the way of features and capabilities. At this time the terms ‘compatible’ and ‘qualified’ will indicate handsets which might actually considered better than the original ‘optimized’. But in the meantime the existing capabilities, any limitations, and defined feature roadmaps need to be clearly understood when making any deployment decisions so that the right devices are selected for both the present and the future. And there is nothing to say that a mixture of device types is not a viable option so it is not always an either/or choice.
April 11, 2014 by Jeff Schertz · 34 Comments
After spending a Sunday morning upgrading my PC and rewiring my home office I recently tweeted a photo of the end result and quickly had a number of questions about where I got my standing desk. As I originally got the idea by looking at a few other custom-built standing desks online I decided to document the process in case anyone else wishes to build something similar to what I did..
A few coworkers of mine who had previously converted to a standing desk, primarily Mike Stacy, had me convinced to do the same for my home office as my posture was typically poor and the ergonomics of my desk where really never quite what I wanted. There are numerous articles online touting the health benefits of standing versus sitting all day long. Most importantly I’ve found that it is not that standing is technically better than sitting for the same long periods of time but instead the standing workspace effectively untethers me from the chair and allows me to just move around more, either just pacing while on an audio conference call or leaving the office for a few minutes to take occasional breaks. Any spouts of back pain I’ve had over the last number of years are now completely gone after only a few months of using my new desk.
Moving into a new home last fall seemed like as good an excuse as any to give this a shot, but I needed to a place to start. Some online research pointed me towards a couple of popular options which ran the entire spectrum from nearly free to costing almost a thousand dollars.
The easier, but more expensive route was to opt for a purpose-build standing desk, some of which are motorized for alternating between sitting and standing. These can run from $500 (like the UpLift Desk) to over $1200 (like the Anthro Elevate) and are typically not a very large surface either. As much as I liked the idea of a purpose-built solution this was too high of a cost for a small desk that wouldn’t suit my needs without some compromise. The cheaper, but less ideal route used by many others was to simply take my current desk and raise it up on blocks of some sort. Aesthetically speaking I would not like this and I wanted something more permanent, but my old desk was a glass surfaced ‘L’ shaped workstation that didn’t lend itself well to this approach either.
A third option appeared after a little more research which was to build a custom desk, but at a manageable cost and without the need for a crate of woodworking tools and an apprenticeship in furniture building. A large number of people were putting together various IKEA products from their large catalog to design a custom desk that not only doesn’t cost a lot but is easy to assemble and looks pretty nice. An afternoon spent on the IKEA Hackers website gave me the foundation to get started on the design. I found a number of different D.I.Y. articles written by others detailing the build process on their own desks but I couldn’t find one that met my needs exactly, so I borrowed different ideas from various desks to create a hybrid solution that had everything I wanted.
The end result as shown in the photos cost only about $220 and everything was purchased from my local IKEA store. All of the parts selected were available for shipping if you don’t have a store nearby but I did take one preliminary trip to do some brainstorming and measuring before buying all of the components.
For the basic design I used this desk by Thibaut Colar as a template. The main difference is that instead of gluing two smaller square EXPEDIT bookcases together it was easier to simply purchase a single wider bookcase of basically the same overall dimensions. My desk also has a uniform width (59”) from top to bottom by matching a tabletop with the same dimension as the bookcase and the bookshelf. This allowed for the main table supports to be moved out to the corners for better stability. Other differences are that I omitted the feet for my personal height requirement and I also added a custom monitor stand.
For the monitor stand I found Eric McKiddie’s custom desk to be the best option. His design used separate bookcases turned 90 degrees which was an approach I considered but in the end I wanted the cubes facing forward for stashing some of the many IP phones I have in my office.
The overall design also provides plenty of room to hold equipment, keeping everything off the floor. The eight bookcase cubes are perfect for hiding power adapters, routers, switches, and the associated cabling. The 6” height in the space under the main desktop and above the bookcase is also great for either mounting some cable management products or, as in my case, placing a laptop. The space 8” of vertical space at the rear of the desktop and under the monitor stand is also enough room for my IP phones to fit as well as various other USB devices and even my Surface Pro.
The placement of the desktop was pretty arbitrary as it is not centered as seen from the side view of the diagram above. This was done for two reasons: to allow clearance under the desk so that I would not be kicking it with my feet and to provide fore-aft balance by placing the monitors closer to the center of the base.
The ergonomics are also very good on this design (again for me) in my normal standing position. The dual 22” monitors are located at the optimum eye-level which is roughly 2-3 inches below the top of the screen. The ideal distance is also about arms-length to the monitors so I have mine positioned closer to the front of the top shelf to achieve this. Again if you are taller you can push the monitors back a little bit to adjust the distance.
In terms of comfort a quality anti-fatigue standing mat is highly recommended, especially when first starting out after years of sitting. I opted for the Imprint Cumulus 9 gel mat from Imprint after reading a host of reviews online on various different products. Beware of some of the cheaper gel mats on the market as some do not actually contain any gel material and are just foam.
The following parts will result in a completed desk height of 39” which is just about perfect for my height (5’6”). If you are taller then you can add some adjustable feet like these to the bottom of the main bookshelf to raise the entire desk up the required amount. I’ve noticed that others have mounted large casters to the bottom of these as well which makes moving the entire desk around very easy, if mobility is a requirement. Be aware that not all of the following wood pieces are available in all of the same colors, so if you want to build one in white or one of the faux wood finishes you may have to go hunting around for alternative items. The Black-Brown finish is one of the most popular and almost every component I looked at included that finish as an option.
Update: IKEA has recently discontinued the EXPEDIT bookshelf series so the parts list has been updated to reflect the replacement KALLAX series and the related accessories. From feedback in the comments the dimensions are nearly identical and thus the desk design plan still works fine with these changes.
|EKBY AMUND||Monitor Shelf
59” x 11"
|EKBY TORE||Shelf Bracket
For back of monitor stand
For front of monitor stand
59” x 29 1/2”
|CAPITA||Bracket, angled (2-pack)
I ended up not using the cable organizer but it would fit well under the main table top if desired. I also have not purchased any of the door or drawer inserts yet but am still planning on getting a couple to hide the networking equipment and to hide some of the wiring out of sight.
|SIGNUM||Cable management, horizontal||Silver||302.002.53||$10|
|Shelving insert with door
13” x 13”
|Shelving insert with 2 drawers
13” x 13”
12 ½” x 13 ¾” x 12 ½”
As with most IKEA products the assembly was quite simple, I just had to improvise in a few places as the overall desk took shape.
Putting together the EXPEDIT bookshelf was exactly as the directions called for and there was no need to modify this piece. The supplied wall brackets were not used but could be if you wanted to secure the entire desk to the wall once completed. In the end I found my design to be plenty stable and would not tip over unless it was purposely pushed or pulled from one side.
Before drilling any holes I approximated the desk and shelf height to give it a test drive and was happy with the layout.
The next step was to drill holes for the six CAPITA angle brackets which support the main desk. I used the black spacers which came with the legs as guides for drilling holes, starting with a small pilot hole and then drilling out the proper hole. Note that the top of the bookshelf is not solid wood, it is a hollow box design.
This was the trickiest part of the build as the length of the welded bolts in the CAPITA leg is too short to clear the entire 2” width of the top of the bookshelf and also allow a nut to be threaded on the bottom to secure it. In fact the bolts are exactly 2” long so they will end up being flush with the bottom of the drilled hole. At first I was worried about this and looked at other articles and forum posts online where people had modified these brackets to accept longer bolts from a hardware store. To be completely secure you can modify the brackets like others have done to accept longer bolts, like in this build (reference photos 1 and 2).
I tested the stability without actually bolting the bottoms of the brackets down as the bolts are still snug in the hole. Once the LINNMON desktop surface was mounted onto the CAPITA legs I noticed that it was were very solid and there was no way I could pry out any of the legs by applying downward pressure on any one side or corner. I suppose if I lifted the entire table top evenly from all corners then it could separate but that is a unrealistic event. Putting pressure on any corner of half only serves to bind the legs on the opposite wide, so in the table is effectively ‘wedged’ into place once assembled.
I had planned to remove the brackets one at a time in the future to mount longer bolts but after nearly 6 months of use, including leaning on the table often, I do not see this as necessary. I just make sure not to ever lift or move it by grabbing the table top, only by handling the bookshelf base.
The next step was mounting the EKBY AMUND shelf for the monitors which started by clamping the EXBY TORE shelf brackets to the table top. There was no drilling or screws required for this first step.
For increased stability I mounted the feet of the EKBY TORE brackets over the metal flange of the CAPITA brackets instead of screwing the plastic feet directly into the table.
The spacing of the CAPITA legs worked out perfectly to do this on all three shelf brackets. This photo also shows how the space below the table to and above the bookshelf is perfect for placing my Quad Core Lenovo W520 laptop and dock. It’s hidden out of sight and is nearly silent, at least when not under heavy CPU loads.
The front supports of the monitor shelf are also unique in that although the straight CAPITA leg upper mounting brackets are screwed into the bottom of the EKBY AMUND monitor shelf these are just legs so no mounting holes are required in the surface of the LINNMON tabletop. This means that the finished result has zero holes in the table so if needed the configuration or layout can be changed without damaging the table surface.
The upper mounts were evenly spaced and screwed into the bottom of the monitor shelf.
The shelf was then mounted and screwed to the EKBY TORE brackets. The CAPITA legs were spun onto the mounting screw and then adjusted to the proper height to support the shelf at a level pitch.
And voila! Our cat seems less impressed than I with the end-result.
It didn’t take long to start filling up space, but I attempted to keep things at a minimum. A single laptop is docked to both monitors as well as a Polycom Group Series 500 video conferencing system and I can alternate between the separate HDMI inputs when needed. A single PoE switch drives the Polycom phones on the table which are registered to a few different Lync environments.
The fixed Polycom EagleEye Acoustic camera was quickly replaced with an EagleEye III 1080p 12x optical Pan/Tilt/Zoom (PTZ) camera but I didn’t have a good mounting option for it. Using the VESA bracket on the back of the monitor was not ideal as I did not want the camera to be mounted to the desk in any way. Any nudge on the desk from bumping it or typing on the keyboard could be seen on video as the camera would sway or vibrate.
Using a few more IKEA parts (EKBY HEMNES / EKBY VALTER) I mounted a simple bookshelf directly to the wall behind the monitors to hold the camera as well as place it at the optimum eye level for video conferencing. The other side of the shelf was a perfect place to put my Wireless Access Point as it is also out of sight but not obstructed in a way that might degrade the signal reach.
And here is how it looks today. Everything on the desk top is functional while the phones stored in the bookshelf below are not actively connected. I can easily swap them out with the devices on the desk when testing new features, firmware, etc.
Also worth noting is that every device on the desktop is actively used with Microsoft Lync in some fashion, from the natively registered Polycom Group 500 video system and CX & VVX IP phones, to the Plantronics, Jabra, and Logitech USB audio and video devices.