MSTurnPing Bug

The MsTurnPing.exe application included in the Lync Server 2013 Resource Kit Tools package contains a bug that may have inadvertently triggered some incorrect practices related to the configuration of Edge server certificates.

Remember that the officially supported, best practice covered in this previous article is that an Edge Pool must utilize a single, identical certificate on all servers for the internal Edge interface which only includes the Edge Pool FQDN as the Common Name.  The individual Edge Server’s unique FQDNs are not, and should not be included as these certificate should not include any SAN entries.

Issue

When running MsTurnPing.exe against a single Edge server it should not report any issues as the certificate’s Common Name is the single Edge Server’s FQDN (e.g. edge.schertz.name).

But when run against a multiple server Edge Pool in a DNS Load Balanced arrangement it will not function accurately.  The tool will incorrectly report a problem with the certificate because it is hardcoded to utilize the Edge Server’s internal FQDN (e.g. edge1.schertz.name) during the test.  But that FQDN should not be included in the certificate, thus causing the tool to report a problem establishing a secure connection to the server.  The actual Lync Servers do not utilize the same method as they properly use the Edge Pool name.

  • The tool will resolve the Edge Pool FQDN (e.g. edgepool.schertz.name) which is reported as the Cluster Name in the output.  But as it connects to each server in the pool the Machine FQDN is reported

================================================================================
Cluster Name: edgepool.schertz.name

Machine FQDN edge1.schertz.name
Exception Message: Operation failed because the network connection was not available.
Cause:             Lync Server Audio/Video Authentication service is not started

================================================================================
Cluster Name: edgepool.schertz.name

Machine FQDN edge2.schertz.name
Exception Message: Unable to establish a connection.
Cause:             Lync Server Audio/Video Authentication service is not started

In this environment there are actually no problems with the Lync Server A/V Authentication service and all ICE/STUN/TURN capabilities are functional. 

  • Checking the System log on the local server where the tool was executed should report an Schannel error explaining why the previous test connection failed.

Log Name:      System
Source:        Schannel
Event ID:      36884

The certificate received from the remote server does not contain the expected name. It is therefore not possible to determine whether we are connecting to the correct server. The server name we were expecting is edge1.schertz.name. The SSL connection request has failed.

Guidance

As the tool reports a false-positive in this scenario this unfortunately has caused some administrators to go down the incorrect route of replacing the internal Edge certificates with SAN certificates containing both the Computer and Pool FQDNs.  The problem here is that every computer FQDN would need to be in the SAN as the same exact certificate must be applied to all servers so that the same public and private keys are used by all server nodes, yet there should not be a SAN field contains on the certificates.

The proper guidance is to leave the certificates as Lync intended, with only the Pool FQDN assigned to the single shared certificate and no other FQDNs are included.

October 2014 Lync Users Group

The next round of quarterly Lync Users Group meetings has been scheduled and announced for this month.

image

Event Details

This meeting will be conducted in our familiar two-session format:

The first session presented by Aruba Networks will cover Software Defined Networking (SDN) and Wi-Fi scenarios with Lync.

The second session presented by a local subject matter expert will discuss Lync Online within Office 365.

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 and its official sponsors.

Our ever-growing LUG family has adopted two new regions this quarter in Baltimore and Kansas City.

Western U.S.

Central U.S.

Southern U.S.

Eastern U.S.

 

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.


Chicago Event

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

Date Location Address
Wednesday, October 22th
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

Configuring QoS for Lync IP Phones

This article covers various aspects of configuring a complete Quality of Service (QoS) design in a Lync environment which utilizes various models of IP handsets for Lync.  Prioritization of both signaling and media communications will be covered by addressing the following topics:

  1. Designing and configuring a network QoS plan
  2. Enabling QoS on network devices
  3. Enabling QoS for Lync desktop clients
  4. Enabling QoS on Lync Qualified IP Phones
  5. Updating QoS for Lync Phone Edition devices

The term Quality of Service (QoS) can refer to a variety of technical approaches for prioritizing specific traffic over an IP network.  For the purposes of Lync the applicable solutions covered in this article are (a) leveraging Differentiated Services Code Point (DSCP) identification of specific traffic types and (b) defining separate custom port ranges for the various media payloads in Lync.  Using this combination of traffic classification, commonly referred to as DiffServ, and organization will provide network routers and switches the ability easily identify real-time communication traffic and then prioritize each category as desired.

While there exists various modes of thought on these approaches the example guidance in this article will closely mimic real-world best practices which many production deployments of Lync share in common.  Not all of the options shown here are necessarily critical; for example some administrators prefer to only prioritize the media payloads of Lync while others will also include the signaling traffic.  Or in some cases only the audio traffic is tagged while other times audio, video, desktop sharing, or other traffic types like peer-to-peer file sharing are all individually categorized with unique values to create a layered approach to handling critical and non-critical data streams.


Design a QoS Plan

Providing end-to-end QoS in a Lync environment starts with defining port ranges for specific traffic to always be sent to and then includes the ability for the client sending that traffic to tag it with proper DSCP values so that the network devices place the traffic into the appropriate QoS queues.

This article is not intended to serve as a complete guide to all aspects of enabling QoS for Lync Server.  A proper QoS approach is to address both client-to-server and server-to-server topologies by configuring Windows operating system policy settings and Lync Server settings applicable to both Windows desktop clients and servers.  Various existing articles like the official TechNet guidance and this excellent article by Lync MVP Elan Shudnow are great resources to also read through.  Keep in mind that although the official TechNet guidance covers how to configure some of the same settings as shown in this article their examples do not always represent the common practices used in the field.

Addressed here are only bi-directional peer-to-peer media sessions between any internal Lync endpoint including desktop clients and both types of Lync Optimized and Qualified phones.  A complete QoS plan should also take into account the media port ranges and DSCP values for client-to-server and server-to-server media for conferencing and media relay call flows.  The articles linked to in the previous paragraph include those details and can be used to complete the configuration started in this article.

DSCP Tagging

The ‘tagging’ or ‘marking’ mentioned earlier is in reference to the DSCP value set on the outgoing packets from a client.  By default this value is null and would be seen in a packet capture like this:

Differentiated Services Field: 0×00 (DSCP 0×00: Default)

This previous article explains the different levels of classifications and the supported marking values for each.  The actual values which should be used must coincide with what the networking devices are configured to support, so it is critical to first understand how DSCP may already be defined on the network.  For the purposes of this article it is assumed that QoS is not yet defined on the network and the next section will outline the actual configuration on an example switch.

Port Ranges

It should be understood that it is not required to define media port ranges in order to utilize DSCP traffic prioritization on the network.  But without doing so it is not possible to assign different types of traffic to different DSCP queues on the network as all traffic from the Lync desktop clients would be tagged, and thus prioritized the same.  the easy way would be to simply tag all traffic from the Lync client application but then signaling, media, DNS requests, web service connections, and any other type of traffic would be prioritized no differently as the network device would not be able to tell one packet from the next.

The proper approach is to separate the different media types into their own unique port ranges so that the network devices can properly identify them and place each into the proper queue providing a layered approach.  For example audio traffic is traditionally treated as the most critical payload and these packets are the last to be dropped on a saturated network, while less important (or higher bandwidth) traffic like video or non real-time communications like the signaling traffic or file transfers can still be prioritized over generic unclassified packets, but in a lower class or queue than the audio.

While defining media port ranges is used in conjunction with DSCP tagging for QoS there is another common reason outside of QoS for defining custom client media port ranges.  By default all peer-to-peer media between Lync clients will utilize destination ports on both endpoints on a random high port between 1024 and 65535.  In the event that internal clients are separated from each other by any firewalls then direct media sessions will usually not be possible and the clients will need to leverage ICE/STUN/TURN provided by the Edge Server to communicate with each other even though they are both internal clients.  To avoid this undesirable load on the Edge Server it is recommended to define a much smaller port range for peer-to-peer media than the default of 64,511 ports (which no firewall administrator in their right mind would open up) to something much smaller (like 100 ports or less) which can be allowed through these firewalls between any internal network where Lync clients and devices may reside.

  • To validate this default behavior in Lync simply capture a packet trace with a tool like Wireshark to view the source and destination ports used on a peer-to-peer media sessions between two Lync endpoints.

image

The example above shows a Polycom VVX 600 (192.168.1.100) and a Lync 2013 desktop client (192.168.1.101) in a peer audio call utilizing a UDP media session.  Note that the source and destination ports are randomly selected within the 1024-65535 range (and that the DSCP flag is null).

The recommended custom port ranges for each media modality had traditionally been advertised by Microsoft as a minimum of 40 but that is older, outdated guidance.  The latest guidance shown in TechNet correctly reflects the required minimum of at little as 20 ports per modality.  Note that the exact math behind this number is related more to the audio and video modalities and a behind-the-scenes look at this was presented in the July 2014 Lync Users Group meetings.  Utilizing the default range of 20 port per modality means that at most a single range of 100 ports would need to be opened on the internal firewalls.  Also these ports are not actively listening and are only opened dynamically during media establishment between two clients.

The example port ranges in this article are arbitrary and realistically any unused range of ports can be defined.  The approach used here roughly follows the same guidance seen in various other articles with one important exception related to supporting the Polycom Qualified IP phones (e.g. VVX).  While the Lync clients and Lync Phone Edition devices can be defined with an exact range of any number of ports the VVX phones do not have the same configuration flexibility.  These devices are hardcoded to use a range of up to 48 ports (24 for audio and 24 for video) and only the starting port can be defined, thus is the Lync policy is defined to use on 20 ports then it would be possible for the VVX phones to request media from the Lync clients to be sent in an out-of-scope port which would fail to be properly tagged.

To provide a complete QoS solution in which all Lync clients, optimized devices, and qualified devices will always communicate within the correct ranges then it is recommended to increase the defined port ranges for audio and video to at least 24 ports.  Rounding these up to 25 ports can make the configuration easier to manage when derailing with a larger contiguous block.  Adding one additional port to round it out will not cause any problems if a Lync client or LPE device uses that single destination port above 24 when receiving media from a VVX phone as the VVX phone will still tag all outbound media correctly.  The VVX in turn will only utilize one of the defined 24 ports for its own destination (listening) port when accepting peer connections from a Lync client or LPE device, which is also still in the defined range.  So in short increasing the range from 20 to 25 ports can provide for a simple to manage policy that will work for all clients.  In fact it is perfectly fine to assign an even larger port range like 100 contiguous ports to make the plan very simple to read.  As long as the Lync-defined port range is larger than the static port range on the VVX phones the traffic will be properly tagged in both directions.  The only difference is how many ports must be  opened between internal firewalls, as network administrators may be accepting of 100 ports in total but maybe not 500 ports.

Example Configuration

As explained the DSCP values are a reflection of what are commonly used in the field but are in no way the only values which can be used.  Any existing DSCP configuration on a network should be leveraged as the network administrator may already have defined classifications for certain types of traffic.  The actual port numbers used are arbitrary and the 60xx range in this article is only only an example.  Various TechNet documentation uses 20000 or 50000 but high ports can be used as long as they do not overlap with other traffic, like 5061.

Also understand that while the focus of this article is on IP phones in which only audio (and for some models video) are applicable each peer-to-peer media modality should be included in the design even if there are no plans to prioritize that traffic.  Once custom client port ranges are enabled then all modalities will be enabled and the default values need to be changed for each (explained further in a later section).

Traffic Type DSCP Value Protocol Port Range
Audio 46 – Expedited Forwarding (EF) UDP & TCP 6000 – 6024
Video 34 – Assured Forwarding (AF41) UDP & TCP 6025 – 6049
Signaling 24 – Class Selector (CS3) TCP 5061
Application Sharing 0 – Unclassified TCP 6050 – 6074
File Transfer 0 – Unclassified TCP 6075 – 6099

When selecting the port ranges do not forget that the starting port counts as the first port so when beginning with ‘0’ ports like 6000 that is why the ending port is only 6024 as that range includes 25 actual ports.  If this seems confusing then just start on the ‘1’ digit for ranges like 6001-6025.  Or if the network administrator doesn’t mind dealing with non-contiguous port ranges for all traffic then something like 6001-6025, 6101-6125, and so on can be even easier to manage.  Aligning the different media ranges end-to-end is better practice though as then a single contagious range (e.g. 6000-6099) can be opened in firewalls if required to support internal peer-to-peer client sessions.


Setup the Network

This section is included to provide a complete story but will differ greatly depending on the type of network equipment in the environment as well as how it may already be configured.  The environment used for this article is the same Lync 2013 lab used for all past articles which includes a NetGear Pro-Safe GS110TP switch that will be used for managing QoS on the network.

The default configuration on this switch indicates that there are 4 different hardware queues available for prioritizing traffic differentially.

  • Review the default DSCP Queue configuration to see which of the desired DSCP values are mapped to which hardware queues. 

image

Note that in this example the queue values are displayed in binary so converting them to decimal will make it much easier to understand.  Interestingly this specific switch has both EF and AF41 assigned to the same hardware queue which would not actually prioritize audio and video traffic differently based on the previously selected DSCP values.

DSCP Value Decimal
Value
Hexadecimal
Value
Binary
Value
Hardware
Queue
Class Selector (CS 3) 24 18 011000 1
Assured Forwarding (AF 41) 34 22 100010 2
Expedited Forwarding (EF) 46 2E 101110 2

In a typical production environment any existing network DSCP configuration would dictate the values used in Lync, but for this example the switch configuration will be modified to retain the desired DSCP values.

  • Modify the configuration as necessary to provide the required design.  For this example the Expedited Forwarding value was reassigned to the highest hardware queue (e.g. 3) to ensure this traffic is forwarded ahead of any other classified data in the switch’s buffer.

image

With this configuration in place then in the event of network congestion any unclassified traffic will first be delayed or dropped, then the signaling traffic, then video traffic, and finally audio traffic as a last resort.


Configure Lync Clients

What follows are the necessary steps for turning on QoS for Lync clients which are disabled by default, configuring policies to enable Windows desktop Lync clients to tag packets with a designated value, and finally defining a custom port range for media traffic for all QoS-capable registered Lync clients to utilize.  Note that mobility clients will not utilize this QoS capability as it is only applicable to Windows and Mac desktop clients and desktop IP phone devices which are registered directly to an internal Lync pool on managed networks; QoS is not applicable for traffic routed over the Internet.

Media Port Ranges

By default Lync Server has port ranges already defined for peer-to-peer media sessions but they are not enabled, thus the default client behavior of using random high ports.  The first step is to enable the static port ranges so that Lync clients and devices will receive this information in-band during registration.  Yet the default values for the different media ports are actually not configured correctly and all overlap, which is not ideal and should be changed prior to actually enabling QoS.

  • Using the Lync Server Management Shell execute the Get-CsConferencingConfiguration cmdlet to display the default Lync Server configuration.

PS C:\> Get-CsConferencingConfiguration | fl client*

image

Note that the starting port for each type of media is the same port (5350) which means that if the default configuration was simply enabled then all clients would attempt to use the same 40 ports for all modalities.  That would prevent any QoS compatible network devices from being able to identify between different payload types and putting them in different queues.

The ClientMediaPort and ClientMediaPortRange parameters are not used by Lync clients but are meant for older Office Communicator 2007 clients which were only able to define a single media port range for all media payloads (audio, video, and application sharing).  The parameters highlighted in yellow are used by Lync 2010 and 2013 clients for separate port ranges for each peer-to-peer media modality. 

The two ClientSipDynamicPort parameters do not actually do anything and can be ignored (these may be left over from LCS).  SIP traffic in Lync 2013 is always client-to-server (not peer-to-peer) and is always TCP 5061 on internal networks to the Lync Front End servers.

  • Enter the following Set-CsConferencingConfiguration cmdlet to configure the desired custom port ranges, which were defined in the table earlier in this article, and then enable Lync desktop clients to use these settings.

PS C:\> Set-CsConferencingConfiguration -ClientMediaPortRangeEnabled $true
-ClientAudioPort 6000 -ClientAudioPortRange 25 -ClientVideoPort 6025
-ClientVideoPortRange 25 -ClientAppSharingPort 6050 -ClientAppSharingPortRange 25
-ClientFileTransferPort 6075 -ClientFileTransferPortRange 25

  • Re-run the Get-CsConferencingConfiguration cmdlet to verify the proper configuration was applied to the global policy.

PS C:\> Get-CsConferencingConfiguration | fl client*

image

If any older Office Communicator clients are still in use in this topology than the ClientMediaPort parameters should also be configured with another unique port range of at least 40 ports to cover the multiple modalities included in that range.  This articles assumes that only Lync clients are utilized internally in the environment and thus these parameters will be ignored.

DSCP Tagging

To enable DSCP tagging for Windows desktop Lync clients the host operating system is what needs to be configured to perform this action; this is not configured anywhere on the Lync Server.  The steps for configuring this on Windows 7 and Windows 8 workstations can be found in the official TechNet documentation on this specific page.  As mentioned earlier the guidance in this article will differ slightly in a few spots which will be explained in detail.

For the purposes of this lab, and as a general recommendation to test any major changes before applying them to every domain-joined workstation in the network, the following configuration uses a new Organizational Unit (OU) created in the Active Directory domain to store the computer account of the test workstation running the Lync desktop client.

These same steps can be completed locally on a workstation in the event domain-joined computers are not available for testing in a given environment.  Simply use the Lync workstation’s Local Group Policy Editor (gpedit.msc) to define the following Policy-based QoS settings instead of the Group Policy Management tool (gpmc.msc) used for domain controllers.

  • On the Lync Front End Server or Domain Controller launch the Group Policy Management tool (gpmc.msc) and then create a new GPO called Lync Client QoS Policy in the desired location.  In this example the test workstation’s computer object in Active Directory has been moved into a new OU called ‘Workstations’.

image

  • Select the newly created Group Policy Object and select Edit to launch the Group Policy Management Editor and then browse to Computer Configuration > Policies > Windows Settings > Policy-based QoS.

  • Create a new policy in this container entitled Lync Audio and set the Specify DSCP Value option to 46.

image

  • Advance to the next window and select Only applications with this executable name and then enter lync.exe as the application name.

image

As mentioned earlier the TechNet guidance will differ in a few place, this being one of them. In TechNet the QoS Policy is shown as being applied to any application on the workstation instead of ideally limiting the tagging behavior to only the lync.exe application.  The latter practice will prevent other applications (rogue or intended) on the same workstation from accidentally having their traffic prioritized in the event that a randomly selected port happened to fall into a range defined for Lync traffic.

  • Advance to the next window and leave the default options selected for Any source IP address and Any destination IP address.

  • In the next window select TCP and UDP for the protocol and then select From this source port number or range.  Enter the defined port range for audio traffic as the starting port and ending port separated by a colon. (e.g. 6000:6024).

image

Here is another area where the guidance can differ depending on the source.  TechNet outlines the exact guidance shown above, in that only the source port is used to identify traffic and apply the assigned DSCP value to the outbound audio packets.  Other directions will often state to set both source and destination ports but this is unnecessary if the QoS configuration is correct in all areas. Also in the event other Lync endpoints which do not not support custom media port ranges are used then the approach above will allow the Lync desktop client to still tag its outbound media even if it’s destined for a port outside of the defined range.

Now that the audio policy is complete repeat these same steps to create new policies for video, and signaling traffic as detailed in the QoS design for this example environment.  If additionally prioritizing application sharing and/or file transfer media sessions is desired then create policies for those as well and assign the desired DSCP value.

  • Using the defined QoS Policy create new policies for Lync Video and Lync Signaling.  Take note that the signaling policy needs to be configured slightly different in that the Protocol is only TCP and the Destination Port (and not the Source Port) needs to be set to 5061 as the Lync client will use a random source port for signaling traffic sent to the Lync Front End Server.

image

If these changes were applied to the AD domain’s Group Policy (and not the local workstations Group Policy directly) then forcing a refresh of the domain policy on the workstation may be required prior to testing the configuration changes.

  • Issue the following command on the test workstation to force an immediate update of the domain global policy changes to be applied to the workstation.

gpupdate.exe /force

Test Configuration

To validate the new configuration on a Lync desktop client exit the Lync application on a workstation and restart it to trigger a registration connection which will refresh any policy settings.  (Make sure that the Lync user is assigned to the proper client policy in the event that the previous configuration changes where not applied to the Global conferencing configuration container.)

  • Browse to the current user’s Tracing folder to locate the Lync-UccApi logs file to search for the latest provisioning data passed in-band to the client during the registration process.

%userprofile%\appdata\local\Microsoft\Office\15.0\Lync\Tracing\

  • Open the Lync-UccApi-0.UccApilog file in a text editor like Notepad and go to the end of the file.  Search for a previous instance of the string ucPortRangeEnabled to look for the most recent settings provided in the <provisionGroup name="ServerConfiguration" > section.

<ucPortRangeEnabled>true</ucPortRangeEnabled>
<ucMinMediaPort>5350</ucMinMediaPort>
<ucMaxMediaPort>5389</ucMaxMediaPort>
<ucMinSipDynamicPort>7100</ucMinSipDynamicPort>
<ucMaxSipDynamicPort>7102</ucMaxSipDynamicPort>

<ucMinAudioPort>6000</ucMinAudioPort>
<ucMaxAudioPort>6024</ucMaxAudioPort>
<ucMinVideoPort>6025</ucMinVideoPort>
<ucMaxVideoPort>6049</ucMaxVideoPort>
<ucMinAppSharingPort>6050</ucMinAppSharingPort>
<ucMaxAppSharingPort>6074</ucMaxAppSharingPort>
<ucMinFileTransferPort>6075</ucMinFileTransferPort>
<ucMaxFileTransferPort>6099</ucMaxFileTransferPort>

The output above shows the various custom port ranges which were defined earlier. If the default settings still appear here then wait a few minutes and then repeat the process until the correct configuration appears on the client.

Next the Windows registry can be viewed to verify that the defined Policy-based QoS parameters have also successfully been imported into the workstation with the Lync desktop client.

  • Open the Registry Editor (regedit.exe) on the Lync desktop client’s workstation and browse to the following location to verify the existence of the custom QoS policies.

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\QoS\

image

A new test call between this Lync client and a Polycom VVX phone will show that the Lync client is now using the defined range. 

  • Capture a new trace on traffic between the Lync client and a VVX phone during a Lync audio call for a few seconds to capture some UDP media traffic in both directions.

image

Notice that the destination port on UDP media traffic (the audio payload) to the Lync client (192.168.1.101) now falls within the expected port range (6018).  The Polycom VVX phone on the other hand still needs to be configured as an out-of-range dynamic port (2230) was still used for the media sent by the Lync client to the phone.

Also seen is the successful DiffServ tagging of outgoing media packets from the Lync client as confirmed by DSCP 0x2e Expedited Forwarding reported in the packet, which equals 46 in decimal.  Even though the Polycom VVX device is not yet configured for QoS the Lync client still tagged traffic that it sent to the phone on a destination port of 2230.  Because the Lync QoS policy was configured to use source ports for media then because that traffic left UDP port 6018 on the Lync client the traffic was properly tagged.

The next test is to verify that the signaling traffic from the Lync client to the Lync Front End Server is also classified correctly.

  • Capture a trace on the traffic between the Lync client and the Lync Front End server that it is currently registered to.  Perform any basic action like placing a call to another Lync user which will generate some SIP traffic to the server.  In the following example Microsoft Network Monitor was run directly on the Lync Front End Server to capture the traffic.

image

The results above show that signaling traffic from the Lync client  (192.168.1.101) to the Lync Server (192.168.1.33) is properly tagged with a DSCP value of 24 which would put this type of traffic into a lower priority hardware queue than the media in the previous test based on the configuration enabled on the network switch in this scenario.


Configure VVX Devices

This section is applicable to all 3PIP Qualified Polycom handsets which run on the Unified Communications Software (UCS) firmware.  Although the modern Polycom VVX devices are the focus of this section the SoundPoint IP, SoundStation IP, and SoundStructure models can also utilize the identical configuration shown here.

It is unknown if the other currently qualified handsets from Audiocodes and Snom support custom port ranges and if so what their behavior is.  An article from Lync MVP Matt Landis briefly shows how to set DSCP values on these other models.

The following configuration settings for the Polycom UCS-based qualified devices can either be manually imported into the phones individually for testing by using the embedded web management interface or in bulk to all devices using a custom provisioning server as detailed in this past article.

Media Port Ranges

As was mentioned earlier these qualified devices do not currently adhere to the in-band media port ranges in Lync so a separate configuration step is require to make sure they utilize listening ports for media in the proper custom port ranges.

  • Define the following parameters on the Polycom VVX phones to set the proper starting port for each range of supported media traffic.

tcpIpApp.port.rtp.mediaPortRangeStart="6000"

tcpIpApp.port.rtp.videoPortRange.enable="1"

tcpIpApp.port.rtp.videoPortRangeStart="6025"

In most cases only the first parameter for audio needs to be defined but in the event that some of the VVX models are equipped with the supported USB video camera then it is possible to perform phone-to-phone video calls via Lync.  (Phone-to-Lync peer video calling is not yet supported due to the lack of any common video codec between Lync clients and the phones.)

DSCP Tagging

DiffServ values can be individually configured for signaling, audio, and video using another set of parameters.

  • Define the following parameters on the Polycom VVX phones to set the desired DSCP value for each mode of supported traffic.

qos.ip.rtp.dscp="46"

qos.ip.rtp.video.dscp="34"

qos.ip.callControl.dscp="24"

The qos.ip.rtp.dscp parameter applies to all media if it is the only one defined but if the video parameter is also defined then only audio will be tagged using the general qos.ip.rtp.dscp setting.  The callControl parameter applies to signaling traffic sent to the Lync Front End server.

Phone Configuration

A single XML provisioning file can be created with both the custom port ranges and DSCP tagging parameters defined, which would look like the following:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!–Schertz Home Lab Shared configuration file –>
<LYNC>
  <qos qos.ip.rtp.dscp="46" qos.ip.rtp.video.dscp="34" qos.ip.callControl.dscp="24" tcpIpApp.port.rtp.mediaPortRangeStart="6000" tcpIpApp.port.rtp.videoPortRange.enable="1" tcpIpApp.port.rtp.videoPortRangeStart="6025"></qos>
</LYNC>

image

  • Copy the text above into a new text file and save it with a .cfg file extension (e.g. qos.cfg).

  • Connect to the embedded web management interface on a Polycom VVX phone from a web browser.

If the device is running UCS firmware version 5.1.1 or newer and the Lync Base Profile is enabled then the web interface may not function as it is disabled by default when used in Lync environments.  To temporarily re-enable this feature perform the following steps directly from the phone (as usual this can also be performed programmatically for all phones using a centralized provisioning server).

  • Press the Home key and then navigate to Settings > Advanced (enter the administrator password which is ‘456’ by default) > Administration Settings > Web Server Configuration (located at the bottom of the menu).

  • Select Web Server and then choose Enabled.

  • Select Web Config Mode and then choose either HTTP Only, HTTPS Only, or HTTP/HTTPS.

After the phone reboots the web management interface will again be available.  For security purposes it may be desirable to disable this feature again after the configuration file has been imported.

  • Connect to the phone’s IP address using a web browser and then go to the Utilities > Import & Export Configuration menu.

  • Under Import Configuration select Choose File and then locate the previously created configuration file ( e.g. qos.cfg).

  • Click the Import button to confirm the action and then trigger a reboot of the phone.

image

Test Configuration

Now that both the port range and DSCP parameters have been imported into the phone it should behave identically to the configured Lync clients and both QoS features should be functioning in either direction for all media.

  • Capture a new trace on traffic between the the Lync client and the VVX phone during a Lync audio call for a few seconds to capture some UDP media traffic in both directions.

image

The results above indicate that media sent from the phone (192.168.1.100)  to the Lync client (192.168.1.101) is now assigned to the correct port range for its source port  (6000) and destination port (6016). This outbound UDP audio traffic from the VVX phone is also properly classified using the configured DSCP value of 46 (0x2E) which is Expedited Forwarding (EF).

The return traffic sent from the Lync client is still allocated within the proper port range as was configured earlier in this article, so now media is successfully defined in the proper ranges and with the ideal DiffServ markings bi-directionally.

The last test is to verify that the signaling traffic from the VVX phone to the Lync Front End Server is also classified correctly.

  • Capture a trace on the traffic between the VVX phone and the Lync Front End server that the phone is currently registered to.  Perform any basic action like placing a call to the Lync client which will generate some SIP traffic to the server.

image

The results above show that signaling traffic from the VVX phone (192.168.1.100) to the Lync Server (192.168.1.33) is properly tagged with the DSCP value 24 which will drop this type of traffic into a lower hardware queue than the media in the previous test based on the previous configuration enabled on the network switch.  Note that the DSCP value will not be defined on the traffic from the server to the Lync client yet as this article does not cover the QoS configuration on the servers as was explained earlier.


Configure LPE Devices

This section is applicable to all Optimized Lync Phone Edition devices from any of the four current manufacturers.

The previously completed configuration for defining media port ranges for Lync clients applies to LPE devices as well, so no additional steps are required for addressing the media ports. 

By default Lync Server already has QoS enabled for any Lync Phone Edition device registered to it.  This default behavior is covered in detail along with a primer on DSCP in the previous article Lync Quality of Service Behavior.  As was pointed out in that article Microsoft has set the default DSCP value as 40 which is not commonly used for audio traffic in most networks.  Since the Expedited Forwarding classification of 46 is used for audio throughout this article then this value needs to be updated to configure LPE devices accordingly.

Be aware that the signaling traffic for LPE devices cannot be prioritized as the following behavior is hardcoded to only apply to the audio traffic leaving the phone.

  • Using the Lync Server Control Panel browse to the Clients > Device Configuration section.

  • Either edit the existing Global or custom device configuration if one exists, or create a new Site level configuration object if so desired.
  • Set the Voice Quality of Service (QoS) value to 46 and the Commit the change.

image

This modification as well as the previous changes applied to the media port ranges will not automatically be applied to any currently registered LPE devices until a maximum of 8 hours as each device’s own schedule of refreshing Lync policy changes occurs.

  • To push the change immediately to one or more devices simply reboot the phone(s) to force a new registration to the Lync server.

To validate the configuration change perform the same steps as in the previous sections to review the audio source port and DSCP marking values in a network trace.


Summary

At this point the environment should be correctly configured to support QoS on all signaling and media traffic involved with peer-to-peer media sessions between any internal Lync desktop client, Lync Phone Edition device, or Polycom VVX phone.  This includes all peer-to-peer media traffic as well as all signaling traffic between these clients and their registered Lync Front End Server(s).

As mentioned at the beginning of the article to complete the entire QoS story for all internally routed media make sure to additionally configure QoS policies on the Lync Servers so that multiparty conferences will also have their media protected when these same Lync endpoints are instead sending their media sessions directly to the server instead of in a peer-to-peer model.  For more details on these different call-flow scenarios have a look at the previous article Understanding Lync Modalities.

Updating CX5100 and CX5500 Firmware

An earlier article entitled Polycom CX5100 for Lync 2013 introduced the newest RoundTable device for Lync, briefly discussing the firmware update process.  As this product was brand new at the time there had been no newer firmware updates yet released to warrant covering that process in detail.

image

Now that the CX5100 and the nearly identical CX5500 have been out for some time a few firmware updates have been made available for them.  As usual it is always a best practice to utilize the latest device firmware version available to provide for the best experience possible.  And like the other Updates articles on this blog site the following table will be updated over time to capture any future releases for these two new products.  For details on the older CX5000 models head over to this older article.

Firmware Versions

The same software release package is applicable to both the CX5100 and CX5500 models so there are no separate download files to worry about.  The CX5500 does include additional Polycom UC software similar to what is found in the VVX phones which is already included in the package, but this additional code is simply unused by the CX5100 model.

For details on specific issues addressed in each update check the ‘Resolved Issues’ table listed near the end of the Release Notes for that specific version.  Some of the new features provided in future releases are also covered at the end of this article.

Version Date Details Links
1.0.0 December 2013 Initial Release of CX5100 model
1.1.0-10114 May 2014 Hotfixes and support added for the CX5500 model Release Notes
Firmware
1.1.1-10117 September 2014 Hotfixes and security related patches Release Notes
Firmware
1.1.2-32157 October 2014 Hotfixes and new functionality:
- CX5500 touch interface call control options when USB tethered to Lync
- CX5500 embedded UCS firmware upgraded to 5.2.0.8580
Release Notes
Firmware

 

Update Processes

These new models include a few different available methods for updating the firmware on the device.  Older models were basically limited to a single process which was not all that user-friendly.  It required installing an application on a Windows PC, physically connecting a Windows computer via USB, reading the documentation  to find a little known default device password, and then finally copying the package files to the device using a complicated command line utility.

The newest models have completely redesigned the upgrade process to provide for different requirements.  For one-off, hands-on updates the software can simply be dropped on a standard USB flash drive and inserted into the system to trigger an instant upgrade.  Yet for bulk updates the software can be retrieved from a central location and scheduled for periodic updates to automatically be applied. 

The multicolored LEDs surrounding the three Mute buttons on the camera base of either model are used to indicate the current readiness status of the device when powered on.

  • No Light - Device is ready to be used and mute is not enabled.  (Or it is powered off.)
  • Solid Red – Device is ready to be used and the microphones are muted.
  • Flashing Green – Device is powering on or rebooting.
  • Flashing Red/Green – Device is performing a firmware update process.

USB Flash Drive

By far the simplest method, and a welcome change over the previous generation device, a single file can be copied to a USB flash drive and inserted in the camera base to trigger an automatic update.  This process can be used to perform either an upgrade or a downgrade as the device will apply whatever version firmware is provided.  Do not store more than one firmware package on the drive, only copy over the desired version.

  • Download the desired firmware package form the table above and then save the .tar file to the root of a USB flash drive.  (Do not decompress the package or extract the files.)

  • The USB drive should be formatted as FAT32 .  (FAT partitions are also compatible but NTFS-formatted volumes are not.)

image

  • Insert the USB drive into the USB Type-A slot located at the base of the tabletop camera unit.

image

The secondary USB port on the Power/Data Box can also be used but this port is typically the blocked with a small rubber plug.  It is simply easier to just use the more accessible port on the camera base.

After inserting the USB flash disk the device (when idle and not actively in a Lync call) will look at the root directory of the volume and search for a valid firmware update package.

  • On a CX5100 if a valid firmware file is located then the upgrade process begins automatically within a few seconds.  The three mute buttons will begin to alternately flash red and green to indicate that the process has begun.

  • On a CX5500 the display will report a successful discovery of the firmware package on the USB disk, prompting to either cancel or proceed with the upgrade.  This screen will automatically advance to the upgrade process within a few seconds so there is no requirement to confirm by actually selecting OK.  Tapping Cancel within those first few seconds though will interrupt the automatic process and return to the main menu.

image

On either model the process is the same from this point forward as the blinking red and green lights indicate the firmware is being updated and the process should not be interrupted..  The CX5500 will additionally report the current upgrade status on the integrated display

image

From this point on do not attempt to use the device, disconnect, or connect anything. Removing the USB flash drive could corrupt the firmware and damage the system.

The device will first download the files from the USB disk and then perform a reboot within one to two minutes.  After the first reboot completes it will begin installing individual files in the firmware packages which typically takes about 10 minutes for the first batch of components.  A second reboot may be triggered mid-way through this process potentially a third reboot to complete then entire process.  The entire process should only take about 15-20 minutes.

After the final reboot the blinking lights will stop and the main screen will be displayed on a CX5500.

  • Remove the USB drive.

Although not necessary, if desired the firmware version can be checked to validate the expected version was successfully applied.  This is very easy on the CX5500 as it can be looked up on the device itself or via the integrated UCS web management interface (covered later in this article).  But on the CX5100 only way to check without connecting from a separate PC would be to review the device log files. (Additionally the control panel application can also be used on either model as an alternative method, covered in the next section.)

The following process is valid for either model (CX5100 or CX5500).

  • Connect the same USB flash drive which was just used for the update to a computer and look for a folder on the root directory named with the device’s Serial Number (e.g. 88142541B785DB).

  • Open this folder and look for the most recent log file package (e.g. log_1411222116678.tgz) which should have been written to the USB drive after the last boot up process.

  • Open the desired .tgz file with a compatible application (like WinRar) and then open the data\log\system_properties.txt file.

  • Search for the string “polycom.ver” to locate the reported version (ro.build.polycom.ver) and build number (ro.build.polycom.num) strings in the file.  In the example below the device’s current firmware is the 1.1.0-10117 release.

[ro.build.polycom.num]: [10117]
[ro.build.polycom.ver]: [1.1.0]

image

As mentioned a much easier way to do this on the CX5500 is to use the touch interface to browse to the Phone status menu.

  • On the device’s home screen select Settings > Status > Platform > Phone and review the Device Software Version value.

image

Control Panel

Also briefly mentioned in a previous article was the new Polycom CX5100/CX5500 Control Panel application which provides the ability to manage, update, customize, and troubleshoot the devices in ways not possible with the older generation RoundTable models.

Fellow Lync MVP and Polycom employee Brennon Kwok has already posted an excellent article covering the various options in the Control Panel application so all aspects of the utility do not need to be rehashed here.  As the focus of this article is on updating the firmware then only the Software Update sections will be covered.

Note that the update processes triggered by the control panel require that the CX5100 or the CX5500 is connected to an Ethernet network, the device has a valid IP address, and has access to the Internet (or to the network location of a custom update server if one is defined).

Also this process cannot be used to downgrade a device as it will only apply newer updates that are stored on the configured update server.  The only supported method to downgrade a device is via the USB process shown in the previous section.

Version Date Details Links
1.1.0-42 December 2013 Initial Release of the Control Panel application Download
1.1.2-74 October 2014 Added USB 3.0 optimization option for reduced cabling arrangements Download

 

The control panel can be used to update the firmware in one of two ways: either immediately or scheduled for a future, reoccurring time.

  • Download and install the latest version of the CX5100/CX5500 Control Panel Application from the Polycom Support site on an Windows workstation.

  • Connect the CX device using the blue USB 3.0 Type A-to-B cable from the tabletop camera base to the workstation.

  • Launch the CX5100/CX5500 Control Panel Application and the tool should connect to the device and default to the System Information screen under the System section. 

image

Note that the current Device Software Version is displayed in the screen above.  Clearly this is a much easier way to verify the current firmware on a CX5100 than the log-based approach shown in the previous section.

Update Now

The following steps walk through the process of trigging an immediate update over the Internet and without having to download the firmware to a USB drive first.

  • Switch to the Software Update menu under the System section and select the Update Now button to initiate an upgrade process.

image

The device will then connect to the currently configured update Server source and look for a package different than what is currently installed.  By default the central Polycom update server which is available over the Internet is defined which always contains the latest publically available firmware package.  The exact location is not listed on this menu but is simply shown as ‘polycom’.  The next section of this article will show how to point the device to a custom distribution point instead of using the default Polycom server.

  • Once the update process begins the control panel will change to show on the update status.  Disconnecting the USB cable from the PC at this point will not cause any problems as the device is using it’s own Ethernet connection to retrieve the package directly from the server.  The only thing the control panel is doing at this point is reporting the upgrade status.

image

The remainder of the upgrade process is exactly as described in the USB Flash Drive section earlier in this article.  Once complete the control panel will reconnect to the device.

  • If the focus changes to the Profile Editor section the device password may be prompted for.  Simply hit Cancel and then switch back to the System > System Information screen where the new version can easily be confirmed.

Update Later

These steps show how to schedule an automatic update using software currently posted to the Polycom update server.

In order to modify the configuration of the device the device password will be required. The default password is the serial number of the unit, but be aware that the tabletop camera unit and the main box typically placed on the floor have different, unique serial numbers. The serial number located on the main floor box is what should be entered here, not the serial number found on the camera base.  An easier method to retrieve the serial number is to simply use the control panel as shown in the following steps.

  • Launch the CX5100/CX5500 Control Panel Application and the tool should connect to the device and show the System Information screen under the System section. 

  • Record the Product Serial Number (e.g. 88142541B785DB) as this is also the default device password which will be prompted for in the next step.

image

  • Switch to the Profile Editor section and the control panel application should request the device password.  If it does not then either exit the control panel application and restart it, or go to the Load Profile menu in the bottom left corner and select Load from Device.

  • Enter the current device password.

  • Select the Software Update menu and then select a day under the Update Frequency menu and as well as a time under the Update Time menu. 

image

The example above shows that at 4:00AM device local time every Tuesday the public Polycom update server will be contacted to check for any updates. If at that time a newer version is found on the update server then the same update process and behavior documented earlier in this article will begin.

  • To optionally change the firmware distribution point simply replace the text ‘polycom’ with a valid URL of a web server hosting the desired firmware package (e.g. http://server.domain.com/directory/)

image

Point to the directory where the desired firmware package has been expanded.  To prepare the source directory extract the .tar file into the desired location so that the ‘millennium’ folder created by the extraction process is located in the directory that pointed to.  Do not point directly to the millennium directory in the update Server path as that is what the device looks for.

For example a subdirectory named ‘update’ was created at the root of the web server in this example and then the latest firmware package was extracted into that directory which automatically created a millennium subdirectory.  For future updates make sure to delete all previous files before extracting the new package.

image

Note that if the Update Server path is changed this also changes the location that the device will go to get updates when the previously discussed  Update Now process is manually triggered.

To return the configuration to the default Polycom server simply enter ‘polycom’ as the Update Server value and the device will recognize that name and utilize the hardcoded distribution URL.

  • Click the Apply to Device button to write the configuration changes to the device.  The update process will begin at the scheduled date and time.

Web Management Interface

This approach is only valid for the CX5500 model as the embedded UC Software stack includes the same web service that the Polycom VVX phones models utilize.  Just as with those phones the CX5500 can be updated remotely by accessing the embedded web interface, signing as as an administrator, and then updating the device.

Note that the password used to remotely connect as an Admin or User to the Polycom Web Configuration Utility is not the same as the device password used in the previous step for the control panel application.  The embedded UCS stack utilizes its own separate password which is identical to the VVX phones.  The default Admin password is ‘456’ and the default User password is ‘123’.

  • Connect to the device’s IP address in a web browser.

  • Leave the Login As selection on Admin, enter the password (e.g. 456), and click Submit.

  • Select the Utilities > Software Update menu.

image

Note that the options shown above are the same as what the control panel application provides.  Whereas the control panel has the immediate update and scheduled update options in different locations the web management utility has them both on the same page.

  • To trigger an immediate update process identical to what was covered in the previous section simply click Update Now.

  • Alternatively to schedule the update process to be triggered at a later date and/or time configure the Update Frequency and Update Time as desired and click Save.

Additionally the Update Server URL can be changed here, as instructed in the control panel, when needing to utilize a central destitution server other than the public Polycom update server.

New Features

This section will include details on some of the more important capabilities added throughout the various updates.

Version 1.1.2-32157

  • When a CX5500 model is USB tethered to a Windows workstation running the Lync 2013 desktop client the touch panel on the device can now be used to Answer or Reject an incoming Lync call.  The established call can also be placed on Hold or Ended directly from the device.

image  image

  • When simultaneous audio calls are active on both the tethered Lync client and via the embedded SIP telephony client then the calls can be individually managed using  new Calls and PC Lync buttons at the top of the screen.

image image

  • The CX5500 model also contains newer embedded Unified Communications Software (UCS) to bring it in line with the current VVX firmware release of 5.2.0.  Be aware that selecting the Lync Base Profile in this new release will disable the embedded web management interface as described in this previous article.

image

Understanding Lync Modalities

There are multiple ways to initiate communications sessions in Lync across different modalities and features.  These various options can utilize a few different network paths to reach the intended destination(s).  The path that each takes depends primarily on the type of communication involved and is also influenced by the number of parties involved.

In Lync, and going all the way back to Office Communications Server, there are a few constants that can be defined.

  1. All communication data can be categorized as either Signaling data where the session setup and handling is performed, or as Payload which would be be the actual content itself (e.g. media, instant messages, shared files).

  2. For signaling data Lync clients will always be connected to a Lync Server and this traffic will always go from client to server to client.  Lync clients do not and cannot send signaling messages directly to each other. 

  3. For payload data all modalities can utilize either a two-party Peer-to-Peer (P2P) model or a Multiparty Conferencing Unit (MCU) model.  Again the primary signaling path is always handled by the Lync Server as previously defined, but the payload can take different routes depending the scenario.  While most modalities can leverage either model depending on the type of call in session, some of them only support a single model and will always communicate in that fashion.

Using these constants the various ways that sessions can be initiated and how the different modalities are utilized can all be defined to understand exactly what is sending network data to where, and what actions trigger changes in these paths.

Models

The following table can be used to quickly reference which types of modalities support which of the two communications models. For the purposes of simplicity media traversal through and Edge Server is not included here but regardless of the model the Edge server may be involved in transparently proxying one or both of the two data streams.

  Peer-to-Peer (P2P) Model Multiparty Conferencing Unit (MCU) Model
  image image
Instant Messaging   X
Audio Calls X X
Video Calls X X
Desktop Sharing X X
Application Sharing X X
File Transfer / Images X  
PowerPoint   X
Whiteboarding   X
Meeting Poll / Q&A   X
Attachment Upload   X

 

As noted some only support a single model while other can work in either model depending on the type of session currently in use when the specific modality is added.  Modalities which only support the MCU model will trigger an immediate escalation from an existing P2P session up to an MCU session when selected.

Escalation

For example say that a basic audio call has been established between two Lync clients which utilizes the P2P model by default.  Then one of Lync users decides to add whiteboarding to the session, which requires the MCU as it is not a modality that is supported directly between the Lync clients.  The act of enabling the Whiteboard modality will automatically escalate the audio call to a conference call and at this time the P2P media payload session will be stopped and both Lync clients will then negotiate media paths directly to the MCU on the Lync Front End server.  This escalation can happen only once per session and is permanent.  From this point on the addition of any more participants or MCU-only modalities are seamless as the session has already been moved to the MCU.  Regardless of how many other participants or modalities are added to the call removing all of these will never trigger any sort of de-escalation back to a P2P session.  So even if there are only two participants remaining in the conference call and audio is the only modality left in use the call remains hosted on the MCU.

Instant Messaging

image

The most basic communications type simply invites the user to an instant message conversation.  The act of locating the other user, showing their presence, and sending the initial IM message as basically an invitation is all handled by the signaling path through the Lync server.  The payload, or the instant messages themselves, are embedded in the SIP signaling traffic for instant messaging and thus are one in the same.

This is the only modality in which the payload is included in the signaling path as SIP messages.  Additional features like sending files or pasting images into the IM window will trigger a different type of session establishment.  Only text and emotions (which are represented by their text values) are included in this single stream.

  • Internal clients connect directly to the primary Lync Front End server in the user’s home pool.  This traffic is always sent as TCP traffic to port 5061 on the Front End server, encrypted using TLS.

  • Externally connected clients connect to an Edge Server via TCP to port 443 (by default) on the Access Edge external IP, also encrypted as TLS.

  • Federated, Lync Online, and other supported public IM platforms will connect to the same Access Edge external IP but on port 5061 (by default) which is used for federation communications.

  • If a third Lync client is added to an active IM conversation window then the session is automatically escalated to the Lync Front End server and is handled by the IM Conferencing service.  Because the IM session and payload was already handled by the server end-to-end then there is no change in the communications path between the original two clients.

Audio Calling

image

Selecting an entry on the phone menu will place an outgoing audio call to the contact, depending on which option or number is selected.  Just hitting the button will place a call to either the only option (e.g. Lync Call) or to the last used option when the contact contains more than one choice.  As is true with all the actions in Lync the server is handling the signaling traffic so this includes the call invitation, reply, media establishment instructions, and anything else involved in the call setup.  Once a secondary media connection is established then the payload may be delivered to a few different locations.

Signaling traffic is sent to the same servers as defined in the previous section for either internal or external clients.  This is consistent throughout the rest of the scenarios covered in this article and from this point forward only the payload traffic patterns will be discussed specifically.

Among the multiple calling options which may be available on a Lync contact they will all fall into one of three categories: a native Lync Call, a Telephone Call, or Voice Mail.

Lync Calls

Lync Calls to other Lync clients in the same environment, federated companies, Lync Online, and soon even Skype clients will utilize native media establishment rules which dictate that a direct connection between both parties is negotiated whenever possible, otherwise the Internet Connectivity Establishment (ICE) protocol will be utilized to provide fallback assistance by leveraging the Edge Server.

  • In the event that a direct connection is available between both clients then the media payload will be delivered to randomly selected UDP or TCP ports on both clients somewhere between 1024 and 65535 by default.  It is possible to reduce this port range via Lync Server client policy configuration as documented here by selecting a custom range of contiguous ports.  This approach provides the ability to open a much smaller range (no less than 40 ports) on any firewalls which may sit between internal client subnetworks.  For audio streams UDP is the default protocol but if that cannot be established then Lync can fallback to using TCP, which is less desirable for delivery of real-time media over IP networks.

  • If direct connectivity between the two clients fails for any reason then ICE will be used to leverage the Edge Server for assistance.  Each leg of the bidirectional audio stream could potentially used different paths, whichever is the most efficient for each side.  Clients will either negotiate media connections directly to the client through one or more firewalls (STUN) or be forced to send media directly to the Edge Server (TURN).  For STUN connections the media payload would again be sent to any range of high-ports (1024-65535) on the remote client’s firewall.  For TURN connections the client would establish a media session with the Edge Server directly.  Internal clients would prefer to send media to UDP 3478 on the Edge Server’s internal interface, or to TCP 443 for media fallback if UDP connectivity to the Edge Server is not available.  External clients would negotiate media in the same UDP-before-TCP preference to the Edge Server’s external A/V interface over a dynamically-assigned port in the range of 50000-59999.  Fallback attempts in the event that ports in this range are not reachable can also utilize 3478 and 443.  Realistically ICE is a complex topic that is difficult to summarize in a single paragraph, so the important concept here is that the payload delivery will always attempt to be delivered directly and if that is not possible then there are many different options available to insure that the call is completed somehow.

Telephone Calls

Calls placed to telephone numbers can be routed a few different ways.

  • First, if the called Work number belongs to another Lync user who is actively signed into Lync then the server will leverage reverse number lookup to simply perform a Lync call as there is no need to send this call to any outbound PSTN destination.  This call routing will be identical to the scenario just covered n the Lync Call section above.

  • If the resolved Lync user is offline then the call will be forwarded to another destination based on the rule defined for that user (Call Forwarding, Simultaneous Ring) or sent to an Exchange UM server for voice mail.

  • If the called number is an external number like a cell phone or other PSTN destination then the signaling path is still client to server but the Lync Server will handle the reset of the call out through an mediation services to the PSTN.  The media payload for this call may be sent to a Mediation Server over either UDP or TCP to a dynamically assigned port in the range of 49152-57500.  Alternatively if Media Bypass is enabled and available for this call then the payload would not go to the Mediation Server but instead directly to a media gateway.

  • For external Lync clients the media payload session would need to travel to the Mediation Server by way of the Edge Server to first get into the internal network and then reach the mediation services, before be routed back out to the PSTN.

Voice Mail

Calls to voice mail are essentially a P2P session even though a server is technically involved.  The Exchange Unified Messaging service is not an MCU though and is really just another client in this communications path.  So calls to the Subscriber Attendant are categorized as a peer call between a client and server as these are the only two parties involved.

  • Calls placed to Voice Mail will be routed to the appropriate Exchange Unified Messaging server and will utilize the same UDP and TCP rules for RTP media as any other Lync audio call.

  • The Exchange UM service be default will dynamically assign a port in the 1024-65535 range just as Lync clients do, but this can also be configured although it is not technically supported by Microsoft.

Video Calling

image

Video calls will follow the exact same behavior as audio calls in Lync except that the additional video modality will is also included in separate media sessions.  From the signaling to the media payload delivery both audio and video utilize the same paths, protocols, and selection logic explained in the previous section.

 

Additional Modalities

Once a session has been established there are a number of additional modalities when can be added or certain features which leveraged will trigger additional sessions in the background.  Some of these additional options will retain the existing P2P communications pattern while others are capabilities provided only in multi-party conference calls be one of the Lync Server services, which will automatically escalate the existing P2P session to a conference up on the Lync Front End server even if there are still only two parties connected.

image

The layout of the content menu in the Lync 2013 client incidentally makes it very easy to understand which options fall into which category.

  • The Desktop and Application sharing options on the top row will respect the current call model, either establishing additional P2P sessions for the payload, or when already in a multiparty conference call simply connecting to the MCU directly.

  • The options along the bottom row will all trigger the creation of a conference call and move the current peer session up to the server.

Although these concepts are not new to  Lync (or OCS, or even LCS for that matter) when moving over from a different type of collaboration platform it is important to understand the models that Lync adheres to when planning for or troubleshooting an existing environment.

Updating Lync 2013

Upon looking at visitor statistics for this blog one of the reoccurring trends is the amount of traffic to articles like Updating Lync Phone Edition Devices after Microsoft releases a new round of Lync updates.  It can sometimes be difficult to successfully navigate through the various updates which follow different release schedules which are sometimes bundled together with other Office releases, so hopefully this article can bring some additional clarity to the subject.

This article will continually be updated to serve as both a source of new update information as well as a history of all past updates for both client and server platforms.  Releases for IP phones will continue to be tracked in their original articles so this article will only cover the server and soft client releases. The ‘Updates’ tag can be used as a quick route to all of these articles.  Keeping this data up-to-date and accurate is an ongoing process feel free to leave comments regarding any errors or dead links.

One thing to understand is that for some products Microsoft will continue to leave multiple previous versions online on their download sites, while others (namely Lync Phone Edition) are removed an only the latest cumulative releases are provided.

Lync 2013 Server Updates

Download

As Microsoft only provides the latest releases for the server components then the following two links are always updated with the most recent information and can be used as a definitive source of the latest server updates.

Typically one does not need worry about the individual components as the LyncServerUpdateInstaller.exe is the ideal package to download and run on any servers.  This tool will locate and upgrade only the applicable components on each Lync server it is executed on locally.

image

Installation

At this point in the product cycle there is no real value in documenting the steps which have been already covered on various other websites for basic installations (like here and here) to more complex articles covering Enterprise Edition pools with mirrored databases.

The important points to understand are the following:

  • Use the LyncServerUpdateInstaller referenced above to make life easy.
  • Start inside-out and work from Front End servers toward Edge servers.
  • Do not forget to update and verify the backend SQL database for each Enterprise Edition pool that is patched

Component History

For occasions when working with the individual packages is desired then the following table covers each cumulative update release with links to the original Knowledge Base articles for each new component.

This matrix provides a visual aid to when and how often some of the various Lync components are updated as cumulative releases will typically not refresh every single server component.

Component CU1
5.0.8308.291
2/27/2013
CU2
5.0.8308.420
7/9/2013
CU3
5.0.8308.556
10/7/2013
CU4
5.0.8308.577
1/8/2014
CU5
5.0.8308.738
8/5/2014
CU6
5.0.8308.815
9/6/2014
Core Components
OcsCore.msp
2781550 2835432 2881682 2905040 2937305 2987511
2992965
Front End Server and Edge Server
Server.msp
2781547 2819565 2881684 2905048 2937310 2987510
2986072
UC Managed API 4.0 Runtime
UcmaRuntime.msp
2781555 2835437 2881685 2905047 2937311 2995717
Web Components Server
WebComponents.msp
2781564 2835435 2881688 2905042 2937297 2995718
2982390
Web Conferencing Server
DataMCU.msp
2787570 2835507 2937314
Conferencing Server
OCSMCU.msp
2781551 2835434
Mediation Server
MediationServer.msp
2796554 2796554 2881699
Call Park Service
CPS.msp
2781549 2835440 2881703
Persistent Chat
MgcServer.msp
2835433
UC Managed API 3.0 Workflow
UcmaWorkflowRuntime.msp
2835438
Administrative Tools
admintools.msp
2837510 2967485
Conferencing Announcement
CAS.msp
2881701
Conferencing Attendant
CAA.msp
2881700 2995716
Central Management Server
MgmtServer.msp
2883679 2910244
Backup Service
BackupService.msp
2910243
Windows Fabric
WindowsFabricPatch.msp
2967486  
Response Group Service
Rgs.msp
          2982389

 

Lync 2013 Client Updates

Windows Desktop Client

The following table lists major client update packages with links directly to the download pages for both the client and any prerequisite components, which are only represented again when they themselves are updated.

Release Date Version Number KB Article Client MSO MSORES IDCRL Lynchelp
October 2012 RTM 15.0.4420.1017
February 2013 CU1 15.0.4454.1509 KB2812461  x86 | x64  x86 | x64
March 2013 15.0.4481.1000 KB2760556  x86 | x64
July 2013 CU2 15.0.4517.1004 KB2817465  x86 | x64  x86 | x64  x86 | x64  x86 | x64
August 2013 15.0.4517.1504 KB2817621  x86 | x64
September 2013 15.0.4535.1002 KB2825630  x86 | x64
November 2013 CU3 15.0.4551.1005 KB2825630  x86 | x64  x86 | x64  x86 | x64  x86 | x64  x86 | x64
December 2013 CU4 15.0.4551.1007 KB2850057
February 2014 SP1 15.0.4569.1503 KB2817430  x86 | x64
March 2014 15.0.4569.1508 KB2863908  x86 | x64
April 2014 15.0.4605.1003 KB2880474  x86 | x64  x86 | x64
May 2014 15.0.4615.1001 KB2880980  x86 | x64
June 2014 15.0.4623.1000 KB2850074  x86 | x64
August 2014 CU5 15.0.4641.1000 KB2881070  x86 | x64  x86 | x64  x86 | x64
September 2014 CU5 15.0.4649.1000 KB2889860 x86 | x64 x86 | x64      
September 2014   15.0.4659.1001 KB2889929 x86 | x64 x86 | x64      

 

  • Releases denoted with ‘CU’ refer to the unofficial but commonly used Cumulative Update nomenclature for Lync.
  • Releases denoted with ‘SP’  refer to a Service Pack release for Microsoft Office.
  • 32-bit downloads are recorded as ‘x86’ while links to 64-bit download are labeled as ‘x64’
  • Items in strikethrough text have been pulled and replaced by the following update but have been left in this table for posterity.

Polycom UCS 5.1 for VVX Phones

This article was posted to serve two purposes which are to introduce the latest 5.1.1 firmware and its new features as well as detail the out of the box experience for the fifteen lucky Lync User Group attendees who managed to win a free Polycom VVX410 and Color Expansion Module at their local event this month.

The primary news here is that this new 5.1.1 UCS software is now Qualified for Lync 2013 as part of the Third Party Interoperability Program (3PIP).  This new version brings a couple of new features (covered later in this article) in addition to a host of hotfixes and stability improvements.

These new features in addition to what was previously added in the UCS 5.0 release are now all fully supported with Lync by both Polycom and Microsoft.

Out of Box Experience

A new product SKU (Stock Keeping Unit) has been added for each of the VVX desktop phone models which are preconfigured for Lync in addition to including the nominal Polycom license fee for Lync usage wrapped up in price.  The product description will include ‘LYNC’ indicating this (pictured below).  There is absolutely no physical difference between these phones and the standard VVX phones as the only change is that the default configuration is set to the Lync Base Profile on the device at the factory.

image

All new VVX phones are still being shipped with some variant of 4.1.x firmware and have not yet moved to shipping with any 5.x releases on them from the factory. As it is always recommended to upgrade the firmware to the latest available release then this should be performed first.  (New units will move to 5.1.x firmware from the factory later on.)

  • To check the current version of software press the Home key on the phone and then navigate to the following menu: Settings > Status > Platform > Application > Main

  • Take note of the reported Version number.  (The latest version is 5.1.1.2986 as of the date of this article so if this version was previously loaded by someone else then there is no need to update anything.)

Upgrade Firmware

As covered in past articles there are various ways to upgrade the firmware on VVX phones but the easiest is to simply use the web server interface on phone to download and install the latest version from a Polycom hosted server over the Internet.

To connect to the phone’s configuration web server the device’s IP address can be looked up directly on the phone.

  • Press the Home key on the phone and then navigate to the following menu: Settings > Status > Network > TCP/IP Parameters
  • Note the IP address and then connect to that address in a web browser. 
  • Leave the Login As value at the default setting of Admin and then enter the default administrator password of ‘456’. (If Internet Explorer 11 is used then it may be required to add the IP address to the Compatibility View list if getting stuck at this menu.)
  • Browse to the Utilities > Software Upgrade menu and verify that the Server Type is set to
  • Select the Check for Updates button to check the hosted server for the available versions.
  • Select the latest version (5.1.1.2986) and then confirm the process.

image

The phone will reboot a couple of times as the upgrade process completes and then will return to the default home screen.

After upgrading to the 5.1.1 firmware a few important changes will have been applied to the Lync Base Profile as part of the latest Lync qualified firmware.  Most importantly the phone’s management web interface will be disabled as a security measure. Connections to the phone’s IP address from a browser over either HTTP or HTTPS will no longer function.  Additionally the phone and web interface will display a warning whenever the administrator password is still set to the default value of ‘456’.

Enable Lync Base Profile

New phones provided in the Lync SKU will not need to have this step performed as it is already set at the factory.  Previous articles have covered various ways to set this but the easiest is to use the Multi Key Combo of 1,4,9 to jump right to the Base Profile menu.

  • Press the 1, 4, and 9 keys together and hold them all for 3 seconds and then enter the administrator password (again the default is ‘456’).

  • At the Base Profile menu Select Lync and confirm the choice to immediately reboot the phone.

Register to Lync

After the phone completes the reboot and anytime it is powered on in Lync Base Profile without an existing Lync user registration it will default to the PIN Authentication menu.

  • If utilizing PIN Authentication on an internal network enter the desired Lync user’s phone number or extension and the associated authentication PIN, then select Sign In.

image

  • If not utilizing PIN Authentication then press the Exit key, followed by the More key, and then the Sign In key.

  • Select User Credentials and then enter the Lync user’s appropriate account information.  Either the NetBIOS Domain Name and sAMAccount Name format or Universal Principal Name (UPN) format are accepted.

image     image

New Features

The following new features have been introduced in 5.1.1.

  • Contact Card support allowing calls directly not just to the Lync SIP URI but all destinations including Exchange Voice Mail and various PSTN numbers.

image

  • Improved Boss/Admin call scenarios including the ability to transfer a call directly to voice mail.. 

image

  • PIN Authentication support directly from the web interface to allow for remote provisioning.

image

  • Full support for up to three daisy-chained of the latest Color Expansion Modules (a.k.a. sidecars) with Lync.  Note that only a single expansion module is supported when the phone is powered by PoE so if adding a second and/or third module the phone must be connected to an OEM 48v power supply.

Color Expansion Module

If an expansion module is available then it can be connected to the phone either powered off or when it is already on.  Simply connect the provided patch cable to the AUX port on the phone and the AUX 1 port on the sidecar.  Also use the mounting bracket and thumbscrews to attach both units to each other.

image

After the initial Polycom logo splash screen appears the module will most likely show a blank screen unless the registered Lync.has manually pinned enough contacts as Favorites to bleed over from the phone’s main screen to the expansion module.

A single expansion module will provide for 3 pages of contacts to switch between using the 3 buttons on the bottom center of the module.  If the registered Lync user does not have any pinned Favorites then no additional contacts will appear on the home screen.

  • Sign into a desktop Lync client using the same account as what is registered to the phone and then select a number of contacts and use the ‘Add to Favorites’ menu item to permanently pin these contacts to the special Favorites group in Lync.

imageimageimageimage

If the changes are not immediately reflected on the phone after pinning favorites then reboot the phone to trigger a refresh as this can happen in some environments; for example when the Exchange Unified Contact Store is enabled on the Lync users account.

Additional Tips

Now that the phone is registered to Lync there are no additional steps required as the necessary configuration information is passed down to the phone from the Lync server in-band.  That being said there are still a host of other settings available in the firmware to tweak and improve the experience.  This section will cover some helpful parameters, some old and some new.

Clear Warnings

Obviously the suggested guidance is to change the default administrator password to a non-default value, but for the purposes of lab testing this may not be important so simply dismissing the warning may be desired.

  • Note the red warning icon in the upper right-hand corner of the phones display.

image

  • To clear the icon press the Home key and then browse to the following menu: Settings > Status > Diagnostics > Warnings and then select the Clear Icon button.  The warning will remain listed in this menu but the icon will be removed from the main screen.

image

Enable Web Server

The built-in web service can be re-enabled directly on the phone using the process outlined in the following steps.  It can also be turned back on via standard provisioning methods by utilizing the associated parameters covered on page 14 of the UCS 5.1.1 Release Notes.

  • Press the Home key and then browse to the following menu: Settings > Advanced > Administration Settings > Web Server Configuration

  • Select Web Server and choose the Enabled option.
  • Select Web Config Mode and choose the desired option (HTTP Only, HTTPS Only, or HTTP/HTTPS).
  • Select Back and then Save Config to save the changes and immediately restart the phone.

Additional Parameters

To further customize the phones where is a list of some new (and old) parameters which can be used to control some of the more beneficial settings on the VVX phones.

Because the following parameters are specific to controlling behavior in UCS then there is no way to utilize the Lync Server to provide these settings in-band.  A separate provisioning server would still be needed to manage a quantity of devices in this manner.

Parameter (Description) Minimum Default Maximum
httpd.cfg.enabled

This parameter controls whether the web service is enabled or not.

0

(Disabled)

0

(Disabled)
1

(Enabled)

httpd.cfg.secureTunnelRequired

This parameter controls whether or not HTTPS is required on the web service.

0

(Disabled)

0

(Disabled)
1

(Enabled)

up.oneTouchVoiceMail

This parameter can be used to enable one-touch calls to Voice Mail from the message button

0

(Disabled)

0

(Disabled)

1

(Enabled)

powerSaving.enable

This parameter is used to enable or disable power saving (screen sleep) outside of defined office hours.  The default office hours configuration is covered in the full 5.1.0 administrators guide.  Only touchscreen models (VVX 500/600) are enabled by default.

0

(Disabled)

0 / 1

(VVX 300/400 Disabled)
(VVX 500/600 Enabled)

1

(Enabled)

July 2014 Lync Users Group

The next round of quarterly Lync Users Group meetings has begun to be scheduled and announced for next month. 

image

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.

Event Details

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.

Chicago Event

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

Date Location Address
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

Resetting Polycom Phones

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.

The phones covered in this article fall into two separate categories: Lync Phone Edition (LPE) optimized CX devices and Third Party Interoperability Program (3PIP) qualified devices. 

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. 

Wipe Configuration

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.”

image     image

  • Select Yes to confirm the action and the device will reboot, wiping the current configuration.

Polycom CX700

  • To wipe the configuration data locate the physical, recessed reset button located on the bottom of the device between the USB and headset ports.

image

  • 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.”

image     image

  • Select Yes to confirm the action and the device will reboot, wiping the current configuration, and reverting the firmware to the previously installed version.

Polycom CX700

  • 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.)

image

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.

image

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.

image

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.

Basic Reset

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.

image

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 [5] 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
VVX 1500
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.

Advanced Resets

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.

image

In the following screenshot the two configuration files are highlighted for a device with the MAC address of 0004f2831d71.

image

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.

image

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.

image

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 [5] 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 [1] 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 [2] 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 [5] 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 [1] and [2] 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 :)

Video Temporal Scaling Behavior in Lync 2013

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.

Temporal Layers

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. 

image_thumb[24]

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).

image

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.

image

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.

image

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.

  

Next Page »