An older, now partially outdated article covered in depth how to configure Quality of Service (QoS) on Polycom VVX phones for use with Lync Server. Much of the guidance in that article is still applicable and even extends to newer Trio conference phones as well as the newer Skype for Business Server and Online platforms.
What has changed since that article was published was how the Polycom UCS-based devices leverage defined media port ranges. Previously this had to be handled out-of-band by either manually configuring the phones or using a provisioning server to perform the configuration in bulk. That configuration required discovering the static media ports ranges defined in the Lync/SfB server platform and then duplicating as close as possible the same configuration on the phones. That manual configuration is typically no longer necessary as more recent firmware releases for the VVX and Trio have added support for picking up and configuring the media port ranges automatically. During registration to Lync or Skype for Business any defined ranges which have always been passed in-band in the client provisioning information are now properly parsed and applied to the phone configuration.
But there was still an important limitation to that behavior as while the phones could automatically use that information they could not use all of it. At the time the firmware did not yet support defining separate source port ranges for audio, video, and content sharing streams. As the vast majority of these devices in the field are VVX IP phones which only support audio communications with Lync/SfB then this gap was not a major issue though. The media port range for audio ports defined in an environment was correctly utilized by the phones without additional configuration and thus any QoS management of that traffic worked identically between SfB clients and VVX phones.
Yet with the growth of Trio phone deployments with the Visual+ component which added video and content sharing streams meant this gap needed to be addressed. In later firmware releases this was in fact dealt with by introducing a new set of parameters which allowed the phones to define source listening ports in up to three different ranges to separate the audio, video, and content sharing media channels. Additionally other compatible video conferencing platforms like the Polycom Group Series also need to be factored in to these environments. This article will review the behavior and any configuration (if applicable) for each of these family of devices.
With the server platforms if no static media port ranges have been defined then the phones will operate with in their factory default port ranges. All devices registering directly to Skype for Business Online will be configured with the same globally-defined client port ranges that Microsoft controls for online clients. Understand that although Microsoft has recently simplified the required port ranges for Skype for Business online clients this does not change the client’s listening port configuration. Those changes are focused on outbound media connections from internal clients to Microsoft’s data centers. Yet for environments which may include firewalls separating even some internal networks then peer-to-peer media communications between these clients still needs to be allowed for no differently than has always been the case in Office Communicator, Lync, and Skype for Business.
As mentioned above server platforms can range from no configuration to any variety of custom port ranges, while the Office 365 offering uses a very specific set of defined port ranges. The examples shown throughout this article will leverage Skype for Business Online which currently assigns the following dedicated port ranges for each media type to registered clients and devices.
The configuration above is provided in the <provisionGroup name=”ServerConfiguration” > section of provisioning data sent to a registering client. This following details can be captured by a SIP trace run during the SfB client registration process or by looking through Lync-UccApi-*.UccApilog files found in the workstation’s Tracing folder.
As of the recent September release of 5.5.2 the Trio will both utilize the in-band port configuration received during SfB registration and also takes advantage of new parameters specifically for content sharing traffic so that it is no longer sharing the same port range with video streams as was the case in earlier releases.
There are a few ways to validate the current configuration of a Trio that has already been registered to a Lync or Skype for Business platform. As stated earlier the devices used in this article are registered to Skype for Business Online so the media port configuration seen will match the table shown above. The simplest way to see the configuration is to utilize the phone’s embedded web management UI to export the current configuration to a text file and then search for the specific parameters which store this information.
Enable Web Management UI
To perform the steps below it may be required to first enable the web UI on the device as it would have been disabled by default when set to the Skype for Business base profile.
- Using the Trio touch interface navigate to the Settings > Advanced > Administration Settings > Web Server Configuration menu. (When prompted for a password the default is ‘456‘.)
- Turn on the Web Server setting and then select the desired Web Config Mode (e.g. HTTP/HTTPS).
- Tap the Back arrow and select Save Config. And changes applied above will trigger an immediate reboot of the phone.
Once the phone has rebooted the web UI can be used to export the current configuration to a text file.
- Using the Trio touch interface tap the hamburger menu in the upper left corner to easily find the device’s current IP address.
- Using a web browser connect to the device IP address using either http or https (whichever options were enabled in the previous steps) and enter the same Admin password as before (default is ‘456‘).
- Browse to the Utilities > Import & Export Configuration menu and then expand the Export Configuration section.
- Leave the default selection of All Configuration (except Device Settings) and then click the Export button.
- Save and open the downloaded Export_all.cfg file in any text editor, or an XML editor of choice if available. Scan through the results or search for the string “port.rtp.lync” to locate the desired parameters.
As seen above the Trio utilizes the following six parameters to store the configuration provisioned by the registrar.
Another way to locate this information is by connecting to the phone via Telnet and looking up the parameters by name to see not only the provisioned values but also the device’s factory default values. This is a more advanced process and may be of interest to some readers for future reference and requires prior knowledge of the specific parameter names.
The phone’s embedded Telnet server is disabled by default so it must be enabled first by importing a configuration parameter into the phone. Obviously this process also requires that the web management UI is enabled as shown above. Also be aware that enabling the Telnet server on the phone is a static setting and will stay enabled though reboots, requiring either a factory reset or being manually turned back off.
- Create a new text file named “enable_telnet.cfg” in any text editor and paste the following text into a single line in the file.
- Using the web UI browse to the Utilities > Import & Export Configuration menu and then click the Choose File button under the Import Configuration section.
- Browse for the newly created enable_telnet.cfg file and then select Import. The results should be reported as “Configuration file imported successfully”.
- Connect to the device IP address using any Telnet client over port 1023.
telnet 192.168.1.165 1023
When prompted for credentials enter the default admin username of ‘Polycom‘ and password of ‘456‘.
At the Admin> prompt enter the command cfgParamName followed by the name of valid configuration parameter. For example “cfgParamName reg.1.address” would return the SIP address of the currently registered user.
In the results shown above there are several values returned for a specific parameter. Most importantly valDefault shows the factory default setting for any parameter, which would be null for this type of parameter. The valWeb value is what was used to store the registered user’s SIP address and this was because the phone was originally registered using the Skype for Business SignIn option in the web UI.
- Using the cfgParamName command the various media port parameters can be queried to find both the default and current settings.
Notice that while the factory default values shown above as still stored in valDefault the custom values for these parameters are instead stored in valPpsSip which indicates the custom settings originally came from a SIP provisioning process; in this case during registration to SfB Online.
As mentioned earlier it may be desired to disable the Telnet server on the phone once completed. Follow these steps to reverse that configuration.
- Create a new text file named “disable_telnet.cfg” in any text editor and paste the following text into a single line in the file.
- Import this file into the phone using the same process shown earlier in this section.
To validate that the configuration discovered above in the various processes is actually functional the following Wireshark traces were captured during a peer to peer call between a Skype for Business 2016 Windows client and the Trio 8800 with video enabled and the SfB client actively sharing its desktop to the Trio. Both endpoints were located on the same internal network so any media streams traveled directly between each host’s local IP. Traffic flows shown below are all from the SfB client (192.168.1.193) to the Trio (192.168.1.165) as the port configuration this article is focused on is applicable to how the Trio opens up listening ports intended for inbound connections from the other endpoint.
The audio stream seen below was sent from the SfB client over UDP to port 50004 on the Trio which is in-between 50000 ad 50019.
Meanwhile the video stream from the SfB client was directly to UDP 50038 on Trio, correctly falling within the 50020-50039 range.
Lastly the the shared desktop of the SfB client was sent to the Trio over TCP to port 50049 which is also within the new content sharing range of 50040-50059. Note that the application sharing session was utilizing Remote Desktop Protocol (RDP) which only supports TCP transmission.
As both the VVX and Trio device families are based on the same core Unified Communications Software (UCS) platform then the behavior here is the same. Any configuration, as explained above, is no longer required as it is all automatic now when registering to Lync Server, Skype for Business Server, or even Skype for Business Online. That being said the actual configuration utilizes slightly different parameters based on the fact that the VVX line does not support content sharing as it is only a phone. While video calling is not yet supported with Skype for Business clients it is functional directly between SfB-registered VVX phones in peer calls only, thus correct utilization of the video port range is still important.
Using the same instructions shown above in the Trio section the configuration can be exported or queried on the VVX phone. Note that the standard Telnet port of 23 is used on the VVX phone, where the Trio uses port 1023 as shown in the examples above.
Using the configuration export process the following parameters were found on the VVX phone registered to the same SfB Online tenant.
Note that the parameter names here are different than on the Trio. Firstly the Trio parameters include the additional *.lync.* text in the names and secondly the audio port parameters on the VVX are entitled ‘media‘ instead of ‘audio‘.
Using the Telnet process the two parameter sets query results are as follows:
This time the valDefault values differ from what was seen on the Trio, indicating different factory default port ranges between the phone families, yet the active port ranges have been provisioned correctly as seen in valPpsSip.
Outside of these configuration differences the registered VVX phone will now function identically a Trio registered to the same environment for audio (and video) streams.
The following table can be used as a quick reference for the defined UCS parameters between VVX and Trio phones.
The Polycom Group Series platform does not currently behave like the phones. While the Group Series does support native registration to Lync Server 2013, Skype for Business Server 2015, and Skype for Business Online platforms it does not utilize the in-band provisioning settings for media port ranges. Additionally the Group does not currently separate audio, video, and content streams into different port ranges, although it does allow for some limited customization to approximate the desired configuration.
An allowed custom configuration supports defining a starting port for two separate media port ranges for TCP and UDP traffic, which can overlap if desired. The port range for TCP traffic is hardcoded to 11 contiguous ports with 61 contiguous ports allowed for UDP traffic. As the Group currently supports an array of audio and video protocols with Lync/SfB then the audio and video communications will typically be over UDP, unless negotiation fails and the fallback to TCP process is used for these streams. Also as the Group currently supports only the RDP protocol for content sharing then all supported inbound content sharing streams will arrive over TCP.
This leaves a dilemma for the administrator to address. While the smaller TCP port range can easily be assigned within the larger 20 port ranges typically used in Skype for Business the much larger UDP range will extend beyond that range and potentially up into other ranges. For example if the Group is configured with a starting port of 50000 it will automatically set 50061 as the ending port. This means that inbound media streams from SfB clients could potentially travel over any of the defined 50000-50059 range used in Skype for Business Online, resulting in possibilities like video traffic landing in the audio queue, or vice versa.
Now for SfB Online this may not actually be a problem as all meeting traffic will be destined for the Internet and thus attempting to place that traffic in QoS queues internally will more or less be moot once that traffic hits the Internet. But for Server deployments where the majority of media streams are staying on-premises then it is suggested to look at the overall QoS and media port configuration and potentially adjust the ranges to work better with the current Group Series behavior. Or it may be desired to treat these dedicated conference rooms differently and thus place traffic destined for those devices in different ranges and queues altogether.
The example configuration used here would put the TCP ports up in the Application Sharing range based on the assumption that all inbound TCP media will be RDP traffic and UDP will successfully be leveraged for all audio and video traffic. But because the UDP ports could contain audio or video then it may be ideal to select a different media port range that is not in use by SfB and then configure the additional range for QoS as desired.
- Connect to the IP address of the Group Series endpoint using a web browser.
- Navigate to the Admin Settings > Network > IP Network menu and then expand the Firewall section.
- Enable the Fixed Ports setting.
- Set the desired starting port in TCP Ports (e.g. 50000) and the desired starting port in UDP Ports (e.g. 49938). (Starting ports must be even integers.)
- Click Save to apply the configuration changes.
Fixed Ports = On
TCP Ports = 50040-50051
UDP Ports = 49938-49999
This example configuration will put all UDP media outside the current SfB ranges, creating a new range of 49938-49999 which can be assigned to whatever QoS queue is desired.
Note that this only impact inbound media sessions to the Group Series. outbound media sessions will travel over the proper media port ranges as the far-end (clients and servers) will be advertising their listening ports correctly within the SfB configuration.
When capturing the traffic between an SfB client (192.168.1.193) and a Group Series (192.168.1.9) with both cameras turned of it is easy to isolate the audio traffic. In the capture below the audio traffic sent from the SfB client to the Group Series arrives on port 49944 via UDP. This port falls within the defined UDP range above of 49938-49999.
By muting the microphone and turning on the outbound video from the SfB client the majority of the capture will now show the video traffic. the following series of packets show UDP traffic from the SfB client destined to the Group Series over port 49948. This port also falls within the same defined UDP range above of 49938-49999. On the surface there is no definitive way to determine this video traffic is any different than the previous audio traffic, other than possibly using the packet size as an indicator (224 vs. 1193).
Lastly a desktop sharing session was started from the SfB client after stopping the video and muting the microphone. The most active results at this point were TCP packets sent from the client to the Group Series destined for port 50043. This port is in the preferred range for application sharing traffic of 50040-50051 as previously defined for TCP traffic.
Note that throughout these captures the SfB client is still correctly sending from and receiving to the port ranges defined in Skype for Business.