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: 0x00 (DSCP 0x00: 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.

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.

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.

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*

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*

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

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

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

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

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.

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\

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.

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.

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>

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

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.

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.

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.

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.