June 24, 2014 by Jeff Schertz · Leave a Comment
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 · 5 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 · 2 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 · 19 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 a gel material.
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.
|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)
31 1/8” x 58 5/8”
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|
|EXPEDIT||Shelving insert with door
13” x 13”
|EXPEDIT||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.
April 4, 2014 by Jeff Schertz · Leave a Comment
The next round of quarterly Lync Users Group meetings has been scheduled and announced for this month. The Lync User Group family has now grown to 15 different locations across the country with the addition of two new regional groups this quarter in Charlotte (N.C.) and in Los Angeles.
For a full schedule of regional events the Lync Users Group Locations page lists all current event locations with links to the associated Meetup.com page for each regional group.
Some additional changes have occurred since last quarter in the form of new roles being filled on the Board of Directors for the non-profit UC User Group which manages all of the Lync UG events. I’ve assumed the role of Director of Content for the group and will be chiefly responsible for selection and creation of the presentation material for each event. Joining me on the board are Britt Baubie of Unify Square who has filled the role of Director of Communications and Chad McGreanor of ExtraTeam who has taken up Director of Onboarding duties. As we continue to add one or two new groups every quarter to the LUG family this newly expanded set of roles has helped us deal with the scale and demand we are seeing in the community.
Presentations will be provided on the following two topics:
Lync Conference 2014 “Top Ten”
- The first session will recap the recent Lync Conference in Las Vegas and cover some of the most important and interesting announcements and details from the event.
Advanced Troubleshooting Tools for Lync
- The second session will cover a host of different troubleshooting tools available for Lync Server from Microsoft, third-parties, and the Lync user community.
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. (Please be aware that this event has been temporarily moved to a Wednesday due to limited availability of the MTC on our normal Thursday night spot.)
|Wednesday, April 23rd
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
March 31, 2014 by Jeff Schertz · 4 Comments
The original intent of this article was to review the current list of supported audio and video codecs in Lync 2013 and attempt to explain what each one is used for given that the list has grown quite a bit over time. But due to the latest announcements around Lync and Skype integration it seems appropriate to first take a closer look at one of these codecs in particular before diving into the rest. This article has been in the works for a while and in the meantime fellow MVP Johan Delimon has also posted a brief article covering just the audio codecs in Lync 2013.
At the latest Lync Conference Microsoft released more details regarding further integration plans between Lync 2013 and Skype. While most of this new information was focused around direct video compatibility with Lync 2013 clients, there will be some advancements in audio calling as well. Last year Microsoft added support for peer-to-peer audio calls between Lync 2013 clients and newer Skype clients. This “Version 1” capability was actually provided by use of media transcoding gateways in the Skype cloud which would allow both clients to utilize their own , unique pre-existing audio codecs. The signaling gateways in the Skype cloud would then facilitate the connections between the different clients allowing each to negotiate a media connection with the media gateways. So even though the calls are basic peer-to-peer scenarios the media must still traverse the Skype back-end infrastructure regardless. So in the event that a Skype user is calling a Lync user on the same network the media would take the long way around and effectively be hairpinned back into the same network.
For native Lync connectivity the topic of media traversal is well documented and the value of negotiating a direct media connection can be quite obvious. The Lync to Skype scenario is quite different though as this use-case is more about bridging enterprise and consumer solutions in which it can be argued that the two clients would rarely be on the same network. Either way, as depicted in the following simplified diagram, the signaling and media paths are basically the same in that they both must traverse the entire backend infrastructure.
There is tremendous value in terms of performance and scale to providing a direct media path between these different client, and Microsoft is moving in that direction. What will be coming sometime this year is the addition of a separate deployment of services in the Skype cloud referred to as ‘Version 2′ which will be deploy side-by-side with the current v1 capabilities. The biggest difference in the v2 design is that there will no longer be a need for media transcoding gateways, only the signaling gateways which translate the Session Initiation Protocol (SIP) and Session Description Protocol (SDP) messages between the different clients. This will allow for the SDP of both clients to be used to setup a direct media path by using the same ICE, STUN, and TURN protocol implementation that Lync does to facilitate a peer media connection.
Since media transcoding is no longer utilized then the clients obviously must have at least one audio and one video codec in common. For video Microsoft has opted to integrate into Skype the same H.264 SVC codec which was first introduced in Lync 2013. This codec has been added to the latest release of Skype clients and functions at the same levels of compatibility as the Lync 2013 clients. Both ends will support the same list of resolutions, frame rates, and temporal scaling layers.
For the audio portion of the call Microsoft has gone the opposite route and actually selected the SILK codec already in use in Skype. Unbeknownst to most users Microsoft already added native support for this audio codec to the Lync 2013 desktop client with a Cumulative Update in November 2013 (CU4). When performing some troubleshooting shortly after that release the new codec declaration was seen hiding in the SDP of the captured SIP messages. At that time there was no information on exactly why SILK was included but it was an safe guess as to the possible intent. Although this support has been added in the Lync clients the codec is not actually being used yet as the back-end signaling has not been updated, so currently audio calls between Lync and Skype are still using the v1 media transcoding gateways.
When Microsoft launces the ‘v2’ infrastructure when not only will H.264 SVC video calling be available between Lync and Skype clients but the media paths will be optimized and SILK will be the audio codec of choice.
Viewing Session Description Protocol
To see the actual list of supported codecs in the Lync client the SIP INVITE messages of a call attempt can be captured and reviewed in one of a few ways. A SIP trace could be captured at the server or client level, but the easiest approach is to simply review the tracing log file created by the Lync client when logging is enabled. This requires no access to any Lync servers and the file can be pulled directly from the client workstation.
- Open the Options menu on the Lync 2013 client and on the General tab set the Logging In Lync parameter to either Light or Full.
- Sign-out and completely exit the Lync client. Open the user’s Tracing folder in explorer using the path shown below. If a Lync-UccApi-0.UccApilog file already exists then delete it.
Deleting this file will provide a clean file to view in the next steps to make it much easier to find the desired SIP message. IF tracing was just enabled and was not previously used then this file may not yet even exist.
- Restart the Lync client and note that a new Lync-UccApi-0.UccApilog file will be created.
- Place a video call to another Lync client and hang up a few seconds after it is confirmed that the call was succesfully established. This will populate the new trace file with some SIP messages that include both audio and video codec declarations.
- Open the Lync-UccApi-0.UccApilog file in Notepad and search for the string “application/sdp” to locate the first SIP message containing Session Description Protocol information.
The first result should also show the text “ms-proxy-2007fallback” under the Content-Disposition line just below. This message is for backward compatibility with any clients or endpoints still utilizing the older implementation of ICE (v6). This section will be skipped over as the next section includes the same declarations and the formatting of some parameters is easier to read.
- Select search again to find the second instance in the same SIP INVITE message which will not include the fallback string in the Content-Disposition line. This message contains support for the more recent implementation of ICE (v19).
The c=IN line lists the IP address of the sender of this message. The SIP messages captured during call setup can include the list of supported receiving capabilities from both parties, depending on the process used to capture the trace. Checking this line helps identify which of the two clients in the call this SDP information was sent by.
The m=audio line defines the media profile, or RTP Audio Video Profile (RTV/AVP), which lists each supported codec by their unique Payload Type identifiers. The order of the identifiers defines the order of preference from left (e.g. 117=most preferred) to right (e.g. 101=least preferred) . Scenarios where more than one codec may be applicable, like with poor network conditions or lower bit rate policy limitations, can result in the use of a less-preferred codec.
- Skip past the a=candidate lines which are used to declare all the potential host IP addresses to attempt to negotiate media paths. Look for the first occurrence of the a=rtpmap lines as this is where the individual audio codecs are further defined.
Each unique codec is initially defined by an individual a=ftpmap line while some may also include a secondary a=fmtp line to set additional parameters specific to that codec. The order that the codecs are declared in the text (top to bottom) also matches the order they are defined in the media profile (left to right).
The ‘rtpmap’ attribute defines the type of Real Time Protocol (RTP) media payload for a specific codec. The following text uses the wideband RTAudio.codec as an example.
a=rtpmap:<payload type> <encoding name>/<clock rate>
- The Payload Type which is unique to each different codec variant is defined as a numeric value placed immediately after the colon.
- The Encoding Name is the common name of the codec.
- The Clock Rate is the numeric value after the slash which defines the sampling frequency used for each codec. Values of ‘8000’ typically indicate a narrowband codec while ‘16000’ defines a wideband codec.
The list of audio codecs in Lync 2013 is quite extensive and has grown over the many different releases of the Communications Server product. When looking directly at SIP messages between two Lync 2013 clients the initial SIP INVITE from the calling party will include the following lines below the m=audio section of the SDP messages.
The following sections do not outline the audio codecs in any specific order of preference. They are simply organized in similar groups, starting with the more commonly used codecs.
Microsoft’s own proprietary audio codec which can be licensed for use in other third-party clients and devices.
RTAudio, as with a few other supported audio codecs, is provided in both narrowband (8 kHz) and wideband (16 kHz) options. The wideband codec is most commonly used in peer-to-peer Lync calls while the narrowband option can be used for either peer Lync calls or in some outbound calling scenarios. In the event that available network bandwidth is limited then instead of sending G.711 directly to a Mediation server for outbound media sessions destined for the Public Switched Telephony Network (PSTN) the Lync client can utilize RTA instead. Although this will provide better quality at a lower bit rate over a poor network it will require that the Mediation Server perform decoding and re-encoding tasks on the media session into G.711 for the PSTN side. In scenarios with plenty of local bandwidth the Lync client will typically send G.711 to the Mediation Server (freeing the server from transcoding duties) or if Media Bypass is applicable then G.711 is sent directly to a media gateway.
These entries advertise compatibility with the industry standard G.711 audio codec used throughout the PSTN. Support for two different common Pulse Code Modulation (PCM) algorithms are denoted as PCMU for G.711 µ-Law (used exclusively in North America and Japan) and PCMA for G.711 A-Law (commonly used throughout the rest of the world).
These codecs can be used in numerous calling scenarios but are most commonly seen in calls with PSTN callers. The most common scenario is when placing a Lync audio call to the PSTN where there is plenty of available bandwidth on the network between the client and the mediation server. As of an earlier Office Communicator R2 release the as-designed behavior here is for the client to simply encode the audio in G.711 so that the Mediation Server is not taxed with having to perform any transcoding; it will simply send the media on to its next hop. In the event that local bandwidth is limited and the Lync client is aware of this it may instead opt to encode the audio in Real-Time Audio (RTA) so that the transmission over the network is more efficient (e.g. lower bit rate) and then the Mediation Server will need to decode the RTV session and re-encode it into G.711 for delivery on to the PSTN. Another common scenario for G.711 usage is when Media Bypass is enabled and the Lync client must encode the audio in a format that a media gateway or whatever is on the other side of a SIP Trunk can understand, which would generally not be a Lync-only codec like RTA.
The Siren family of patented codecs was originally developed by Polycom. The specific variant supported by Lync is also known as ‘Siren 7’ and has been used only for conferencing scenarios for some time in the Communications Server product family. An immediate benefit of Siren is that it provides wideband audio at a low bit rate (16 kbps) making it ideal for large multiparty calls where many audio streams are sent to the same Front End server.
Developed specifically for Skype to replace the older SVOPC audio codec and was introduced in the 4.x release of Skype clients. It has also been extended into the Internet standard Opus audio codec.
a=fmtp:103 useinbandfec=1; usedtx=0
a=fmtp:104 useinbandfec=1; usedtx=0
This pair of narrowband and wideband codecs will be used for Lync 2013 and Skype audio calling in the near future when media transcoding is removed from the topology. As mentioned earlier SILK supports in-band FEC, denoted by the ‘useinbandfec=1’ parameter, meaning that any additional error correction media packets are sent inside the same media payload stream.
A freely available and widely popular wideband audio codec which Lync will use in a few scenarios.
Unlike other wideband codec the clock rate here is incorrectly identified as only 8,000Hz even though the actual sampling rate is 16,000KHz. Johan’s aforementioned article explains this is due to an error in RFC 1890 and Lync must declare the rate this way to support compatibly with other systems.
This codec is primarily used in Lync conference calls when no other Lync clients are participating in the same call. In the event that a single Lync client joins an audio conference call populated with only PSTN attendees then the mixed audio sent by the Lync AVMCU to the sole Lync client will be in G.722.
In scenarios where other Lync clients have joined the same conference call then the Lync ACMVU will fallback to using Siren for the mixed audio streams sent to each Lync client. Constrained bandwidth or high-latency scenarios can also trigger a fallback to Siren regardless of the client types in attendance. A previous article from Lync MVP Curtis Johnstone covers this specific behavior in more depth.
While RTA is primarily used for wideband audio between Lync clients when negotiating peer to peer Lync calls, when other clients, like Lync Qualified phones, negotiate calls with Lync clients then G.722 may need to be used if RTA is not available on the phone. (RTA compatibility is not a Lync Qualification requirement for IP phones, but it is included in Optimized phones running Lync Phone Edition.)
This codec declaration is a newer capability added with the RTM version of Lync 2013 and is designed to support Lync Room System devices which are equipped with two microphones for stereo dual-channel audio pickup.
Just as with G.722 the clock rate here is also defined as ‘8000’ yet again the actual rate is 16,000Hz. The ‘/2’ after the clock rate indicates that this codec has 2 separate channels,for stereo applications. Lync Room Systems utilize this codec to provide for improved audio pickup in conference rooms.
Another supported option from the same family of royalty-free wideband audio codecs. It is not based on G.722 though, it is actually a variant of the Siren 7 codec.
G.726 is an Adaptive Differential Pulse Code Modulation (ADPCM) codec designed to more effectively compress speech than older PCM-based codecs. The specific variant supported by Lync 2013 is a single narrowband (32 kbps) option which results in a lower bit rate stream of comparable quality to G.711 audio. Some of the Lync-compatible IP desk phones natively support this codec and in theory could negotiate G.726 instead of G.711 in constrained bandwidth scenarios.
Comfort Noise (CN)
Utilizing Comfort Noise provides Lync the ability to leverage either a narrowband or wideband options for adding white noise during periods of silence to prevent users from mistakenly thinking that the call connection might have been lost.
Redundant Audio Payload (RED)
RED is utilized for any out-of-band Forward Error Correction (FEC) audio payload. While Lync clients will leverage this codec for error correction needs in native calls the Skype clients do not support this and will use in-band FEC.
Dual-Tone Multi-Frequency (DTMF)
DTMF signaling is used to support the common telephone events of pushing buttons on the dial pad while in a call.
The unique tone created by each key is represented by a value between 0 and 16 as defined by the additional fmtp attribute. The name describes exactly how these tones work in that each button on a traditional telephone produces two simultaneous tones of different frequencies. Each row and column on a standard phone number pad uses a different frequency tone so that 8 unique tones can be used to support 16 different dual-tone patterns.
The supported 16 standard tones come from 0-9, *, #, and four additional tones used by the AUTOVON military application defined as A, B, C, D. RFC 4733 defines only 16 unique values (0-15) so it is unclear why Lync defines a 17th value (0-16).
|1209 Hz||1336 Hz||1477 Hz||1633 Hz|
For example depressing ‘4’ will produce two tones of 1209 Hz and 770 Hz. This is why many of the tones seem to sound the same as all keys in a row or column will use the same tone for one of the two played. This harmony is difficult for the average person to easily differentiate between but a computer can accurately identify each of the two frequencies in play.
The list of video codecs in Lync 2013 is much shorter than the list of supported audio codes by comparison.
- Return to the same spot in the tracing file as shown at the beginning of the last section and then search for the m=video line found immediately below the audio section.
Just as with audio codecs the m=video line uses the same format to list the order of preference by defaulting to H.264 SVC (122) ahead of RTVideo.(121).
This is the Real-Time Video codec which has been supported from the introduction of video calling in the Communications Server platform.
The ‘/90000’ value is used as the clock rate for all video codecs advertised by Lync. As denoted by the preference order above this codec is listed second and will be used in the event that both sides do not support H.264 SVC.
As covered in various other articles the H.264 SVC implementation in Lync is used by default for all native 2013 calling scenarios as well in certain third-party interoperability scenarios (e.g. Polycom Group Series with at least 4.1.3 firmware).
When communicating with legacy clients (e.g. Lync 2010, Office Communicator) and some third-party video conferencing systems (e.g. Polycom HDX) then RTVideo would still be used.
As explained in previous articles and various presentations the implementation of H.264 SVC in Lync is not the basic H.264 codec but is specialized in Lync This unique implementation is advertised to other clients as X-H264UC and thus must be understood by the other client in the call equally. In the additional fmtp declaration statement the ‘packetization-mode=1’ parameter indicates that UCConfig Mode 1 is the maximum scaling mode supported which is the ability to encode two separate temporal layers: a base layer and an enhancement layer. As previously stated the upcoming implementation of Skype will support the same mode.
Uneven Level Protection FEC
This codec is actually used to allow Lync 2013 clients to setup a second RTP session used specifically for out-of-band forward error correction data, separate from the main video stream.
As the ‘uneven’ part of the name suggests this codec will send portions of redundant data when needed as it is not an complete duplicate of the main media stream.
Just as mentioned earlier in the audio codecs section Skype clients do not support this and will instead simply used in-band FEC with the single SVC media session. This entry did not exist in previous versions of Lync so in legacy video call scenarios the Lync 2010 clients utilizing RTV will also embed FEC data in-band.
March 14, 2014 by Jeff Schertz · 8 Comments
After getting a few weeks to decompress from Lync Conference 2014 in Las Vegas here is some feedback on numerous topics which followers of this blog may find interesting. Some of the information is related to recent product announcements while other items dive deeper into information uncovered from discussions with members of the Microsoft Lync product team and other conference attendees. While video conferencing is a great adjunct to personal communications there is still no complete replacement for in-person discussion with resources which typically are not freely available. The value of an industry-wide conference specific to just the Lync product can be measured in a variety of ways and it is highly recommended to attend future occurrences of this conference if at all possible.
Video Interoperability Server (VIS)
Last year Microsoft first made mention of a native, embedded video interoperability service but details were far and few between on what this might actually be. This year details were still on the light side, but the intent and functionality are a bit more transparent.
During the latest keynote Microsoft showed a live demonstration of a multiparty conference call with Lync 2013 clients and a single Cisco/Tandberg EX video conferencing system.
Little detail was shared on what was actually shown during the demo, other than the capability was reported as to be “released in our next version of Lync Server”. As no information was shared regarding the delivery of the next release of the Lync product then one can only guess when VIS will be available to the general public. And by going off what was shown in the demo it appears that VIS will support not just peer-to-peer calls but also dragging SIP-registered video endpoints into a multiparty conference call on the Lync 2013 AVMCU. The video codec in use in this demo is unknown but even though the Tandberg EX cannot support Scalable Video Coding (SVC) there is a compatibility option in H.264 SVC as implemented in Lync Server 2013 in terms of using basic Advanced Video Coding (AVC) media payloads. The VIS signaling gateway service embedded in the next Lync version is most likely handling this complexity. These concepts were first discussed in this previous blog article.
Fellow Lync MVP Adam Jacobs has covered the topic of VIS in a new blog article which discusses the service in more detail as well as relating it to existing third-party solutions already compatible with Lync 2013.
During the keynote Microsoft also demonstrated a capability which was first announced last year in San Diego at Lync Conference 2103: the ability to support peer-to-peer video calling between Lync 2013 and Skype clients. In the demonstration a video call was placed to a Skype contact in the Lync contact list and similar video behavior one would expect from another Lync client was seen. The call started off in the small embedded window in low resolution and when maximized to full screen a higher resolution of a widescreen aspect ratio was renegotiated, as shown below.
Currently Microsoft has been supporting peer-to-peer audio calls for time with Lync 2013 clients, but these media sessions are not peer-to-peer. The audio is actually being transcoded on the backend by a gateway as currently two different audio codecs are in use between the different clients. This current ‘v1’ infrastructure will be maintained for some time for backward compatibility, but the upcoming ‘v2’ topology will facilitate direct media connections between Lync and Skype clients for both audio and video session, leverage ICE, STUN, and TURN protocols for media establishment assistance.
The video codec at in the demo image above here was definitely H.264 SVC as the most recent releases of Skype clients have already introduced native support for that video codec just as it was implemented in Lync 2013. This means that when the v2 back-end Skype infrastructure is made available to the public then media will be negotiated directly between them. There will be no need for any intermediary servers or gateways to transcode media.
The Lync 2013 clients have already received native support for both narrowband and wideband SILK audio codecs in a previous cumulative update, which will be used for direct audio streams as well.
In short Microsoft has put the latest video codec from Lync (H.264 SVC) into Skype and the latest audio codec from Skype (SILK) into Lync.to facilitate the media codec compatibility required to support peer-to-peer media sessions..
Lync Room Systems
Microsoft originally announced the Lync Room System (LRS) solution at last year’s conference and a few partners demonstrated early pre-release systems at the event in San Diego. Fast-forward a year later and there are now three established product offerings which come in a variety of display sizes, quantities, and camera configurations.
Polycom has joined the arena with Crestron and SMART (LifeSize no longer offers an LRS product) with a handful of additional bundling options in terms of multiple monitor and camera choices.
The Polycom CX8000 can be purchased unbundled from the displays which are then individually selected from an a la carte menu of qualified touch-panels from Samsung and Perceptive Pixel. Any size monitors can be selected alone or in pairs. For the best in-room user experience it is always recommended to utilize dual displays when wall space allows as this provides more screen real estate to use when dealing with multiple modalities. Dedicating separate screens to content and video or using both screen to display the entire video Gallery view (as shown in the photo above) are what the system was designed to do.
- Single or Dual 55” Perceptive Pixel display
- Single or Dual 65” Samsung Displays
- Single or Dual 82” Perceptive Pixel Displays
Also new is the availability of a center-or-room camera experience in the LRS by bundling the CX5100 ‘RoundTable’ camera which replaces the standard front-of-room USB camera typically mounted above the displays. This solution provides an improved video experience for far-end participants in both round-table discussions and when an in-room attendee is presenting and/or annotation on one of the main touch-screens and addressing the room attendees.
- Standard “Front of Room” Camera
- Enhanced “Center of Room” CX5100 Panorama Camera
Hidden Real-Time Video Resolutions
In a previous article about HD Video in Lync 2013 the discovery that Lync 2013 had added additional resolutions to RTV was first discussed. The list of video resolutions supported by the 2013 client for RTV can be seen when reviewing the Session Description Protocol (SDP) portion of SIP INVITE messages during call setup. The m=video portion of the SDP data exposes the different formats the clients are capable of receiving, declaring the capabilities of RTV on the a=x-caps:121 line. The format of each resolution is covered in the previous article in detail, but what is applicable here are the second and third parameters of each entry which lists the width and height in pixels of each resolution. When comparing the lists of supported resolutions between what Lync 2013 clients and 2010 clients declares there are multiple new resolutions in RTV on the Lync 2013 client.
- Lync 2010 Client RTV Receive Capabilities
- Lync 2013 Client RTV Receive Capabilities
What is interesting is how these new resolutions are not actually used in the current implementation of Lync.
These three new entries include one each for low, standard, and high resolutions all in a widescreen (16:9) aspect ratio. As only the Lync 2013 clients support these new resolutions then when performing a Lync 2013 to 2010 peer-to-peer video call they are not available because the 2010 client can neither send nor receive these new resolutions. The Lync 2010 client would simply report that it can only accept the original few resolutions and thus the Lync 2013 client will never send video to it using any of the new resolutions. An encoding client cannot send media in a format that the decoding client does not declare as an option.
When Lync 2013 clients participate in peer video calls H.264 SVC will always be used.. So although they both would support receiving those additional RTV resolutions the RTV codec itself would never be utilized. The same holds true for multiparty conference calls. Although the Lync 2013 AVMCU may support these same RTV resolutions any Lync 2010 or older RTV clients still do not support them. And, just as before, any Lync 2013 clients negotiating video with the Lync 2013 AVMCU will always utilize H.264 SVC.
So what in the heck are these new RTV resolutions included in Lync 2013 for, and why even add them when there appears to be no possible scenario in which they could be used? The answer actually lies within a recently removed configuration parameter in Lync Server 2013 which provided the capability to completely disable H.264 SVC on the Lync 2013 AVMCU for conferences. In the initial RTM version of Lync Server 2013 there was a parameter in the Set-CsMediaConfiguration cmdlet called DisableH264SVC which could be used to disable SVC on the Lync 2013 AVMCU. A restart of the service would be required to trigger the change, but afterward all Lync 2013 clients joining conference calls would utilize only RTV for video.
The obvious indicator to this change would be the loss of Smart Framing as cropping of the video stream was simply centered in the image and would not follow the user’s face. The media quality reports in the Monitoring server would also list the codec as ‘x-rtvc1‘. In these scenarios then the Lync 2013 clients would in theory be able to utilize the additional resolutions when negotiating media with the AVMCU. As this capability was removed in a recent cumulative update then it is no longer possible to create a scenario in which any of these additional resolutions can be utilized by forcing the use of RTV.
February 13, 2014 by Jeff Schertz · 14 Comments
The official Microsoft Lync Room System Deployment Guide covers in detail the creation of a resource mailbox which will be dedicated to each Lync Room system, yet it also includes a number of optional steps as well as the use of separate cmdlets for each individual parameter.
Lync MVP Adam Jacobs has boiled the account creation process down into a simplified list of command in fewer steps, but even those instructions can be further compressed into less steps by stacking parameters into the same cmdlets and using the Exchange cmdlets to also configure the Active Directory users account in the same process. Another Lync MVP Pat Richard has gone so far as to even create a PowerShell script to automate this process.
The following section in this brief article takes the mandatory configuration and combines it into three simple cmdlets. Some additional optional steps are covered separately in the next session.
The first two steps need to be performed on the Exchange Server Command Shell, which includes the creation of the Active Directory user account, enabling it for authentication, and setting a password on the account. Also added was the ability to define the target Organization Unit so that the account does not go into the default Users container, possibly needing to be moved later.
- Create the new resource mailbox replacing the individual parameter values with the desired information specific to the new account.
New-Mailbox –Name "Chicago Meeting Room" –Alias "chicagolrs" –UserPrincipalName "email@example.com" –sAMAccountName "chicagolrs" –Room -RoomMailboxPassword (ConvertTo-SecureString -String “p@5sw0rD” -AsPlainText -Force) -OrganizationalUnit "ou=Resources,dc=schertz,dc=local" -EnableRoomMailboxAccount $true
- Enable the Auto Accept Agent for the mailbox and control how meetings will be displayed on the LRS screen for the sake of privacy. (Technically the AutomateProcessing parameter is optional, but in most cases the mailbox calendar would not be managed manually by an employee.)
Set-CalendarProcessing -Identity "chicagolrs" -AutomateProcessing AutoAccept -AddOrganizerToSubject $false -RemovePrivateProperty $false
The final step must be performed on the Lync Server Management Shell. These cmdlets will enable the new user account in Lync as well as add the Enterprise Voice capability, if so applicable. The optional Domain Controller parameter was added to insure that the same DC is used for each cmdlet to eliminate the potential of errors in the event that the individual commands were to be executed against different DCs which might not yet have replicated the previous changes.
- Enable the account in Lync as a Meeting Room.
Enable-CsMeetingRoom -Identity "chicagolrs" -SipAddress "sip:firstname.lastname@example.org" -domaincontroller "dc1.schertz.local" -RegistrarPool "lync.schertz.local"
The following steps are not required but may be needed based on the desired configuration.
- Using the Exchange Server Management Shell define a Mail Tip to be displayed in Outlook to assist users in remembering that Lync Meetings should be used with this mailbox for the ideal room experience.
Set-Mailbox -Identity "chicagolrs" -MailTip "This room is equipped with Lync Meeting Room (LRS), please make it a Lync Meeting to take advantage of the enhanced meeting experience from LRS”
- Using the Exchange Server Management Shell define the meeting acceptance response text.
Set-CalendarProcessing -Identity "chicagolrs" –AddAdditionalResponse $TRUE –AdditionalResponse “Enter your desired text here”
- Using the Lync Server Management Shell enable Enterprise Voice and define a Telephone URI for the account..
Set-CsMeetingRoom -Identity "chicagolrs" -domaincontroller "dc1.schertz.local" -EnterpriseVoiceEnabled $true -LineURI "tel:+15551234567;ext=4567"