Implementing the Citrix HDX RealTime Optimization Pack: don’t forget about QoS/DSCP!

Skype for Business (SFB) has become quite popular and, more and more, companies all over the world have implemented or are in the process of implementing Microsoft’s unified communications platform. The Citrix HDX RealTime Optimization Pack, the only field-proven VDI solution endorsed by Microsoft, enables you to deliver the SFB client in a virtual desktop without making compromises to call quality and optimized call routing.

The biggest challenge that is tackled by the Citrix HDX RealTime Optimization Pack (RTOP) when implementing SFB in a VDI environment is avoiding realtime voice traffic traversing the WAN multiple times. In order to achieve good call quality, it is of great importance that all voice traffic is sent without delay and using the shortest route from one endpoint to the other.

A good example is a remote office where users connect to their XenDesktop VDI or XenApp published desktop located in the main datacenter. Without RTOP, the SFB endpoint is running on the VDA. As a result, when two users located in the same remote office make a call, the audio and/or video will need to traverse the WAN twice through the ICA channel:

RTOP avoids this by running a legacy SFB client on the user’s endpoint device (redirecting all voice and video) while keeping the SFB client’s GUI available in the desktop. This enables a seamless user experience and optimized voice traffic. In our example, this means that a peer to peer call will be possible between User 1 and 2, avoiding traversing the WAN.

What this means in practice is that the user’s endpoint device (that may be running on a Windows, Linux or MacOS platform) is transformed into a SFB/VOIP endpoint and will behave as such. This has some implications on networking level we should look out for.

We also need to take other situations into consideration where the voice traffic will still need to traverse the WAN (outside the ICA channel):

  • User from main office calling to user in remote office and vice versa
  • User in remote office calling a user in another remote office
  • User from remote office where there is no local VOIP gateway making an external call
  • Conferences
  • User connecting with Citrix Receiver client not supporting the HDX Realtime Multimedia Engine

This brings us to a very important configuration on networking level that is often overlooked: DSCP and QoS.

DSCP

In short, setting the correct DSCP value (46 for audio, 34 for video) in the header of IPv4 or IPv6 packets will trigger network devices to apply QoS correctly and give the packet appropriate priority. This is especially important when traversing a WAN (e.g. using a VPN tunnel), as packets will traverse routers and switches managed by the telecom provider. Generally speaking, these devices will also take the DSCP value into account avoiding delays when the packet travels through public switches and routers.

Why is this often overlooked?

Most VOIP telephones set the correct DSCP value on outgoing voice/video packets by default and no extra configuration needs to be done. Additionally, in a lot of environments VOIP telephones are connected to a separate (voice) VLAN configured with QoS policies in place to prioritize the traffic. Remember that when using RTOP, the user client device (laptop, thin client, thin laptop,…) becomes a SFB/VOIP endpoint and will generally be connected to a client VLAN that may not have the appropriate QoS policies configured. Prioritizing voice traffic is highly recommended in this situation as other client traffic (movie streaming, printing,…) may cause noticeable delays in the audio stream.

Even in a situation where there is sufficient bandwidth available, small latency can be observed at switch/router/… level. This is often not noticeable with general network traffic (like downloading, printing,…). However, when it comes to voice, small delays can result in ‘robotic’ voices, out-of-sync conversations and other call quality issues. This occurs more often when traversing WAN/VPN, as it only takes one busy (public) switch or router to cause problems. Setting the correct DSCP value will put the packet into a high priority queue on every QoS enabled network device between endpoints.

How to avoid unprioritized voice traffic ?

By making sure that every endpoint running the SFB client (either native or using RTOP) is sending voice and video packets like a VOIP phone would: with DSCP value 46 in the header for voice and with value 34 for video.

On Linux and MacOS endpoints, this can be achieved by setting a registry key on the VDA. This article describes all steps to correctly implement this.

On Microsoft Windows endpoints, setting the correct DSCP value can be done using Policy Based QoS:

Using the Group Policy Management Console, create a new GPO and assign it to the appropriate OU of Windows devices. Edit the GPO and navigate to Computer Configuration -> Policies -> Windows Settings -> Policy-based Qos
Right click to create a new QoS policy. Start by creating a policy for audio, assigning it DSCP value 46.

In the next screen, optionally you can restrict the policy to an application, e.g MediaEngineService.exe.

In the following screen you can limit the policy to specific source and destination IP addresses. Choose Any source and destination IP address.

Select TCP and UDP (UDP will be used by default, however TCP fallback is possible) and specify the port ranges used for audio. You can get these ranges by running following Powershell command on a SFB Frontend or Management server: Get-CsConferencingConfiguration | fl Client* 

Repeat this procedure for video (DSCP 34) and configure the corresponding ports used for video in your SFB environment.

Verifying DSCP values are set correctly

You can use a tcpdump utility (e.g. Wireshark) to verify all voice and video traffic has the correct DSCP value assigned:

Optimizing traffic in fallback scenarios

When a user connects to his or her desktop using a Citrix Receiver client not supporting the Realtime Media Engine, all voice and video traffic will be handled from within the VDA. To make sure this traffic is also assigned the correct DSCP value, you can apply the same Policy Based QoS GPO’s to the VDA’s. This is of even greater importance when using a XenApp published desktop (SBC) as the (virtual) NIC will be shared with traffic from other users. Setting the correct policies will make sure appropriate priorities on voice traffic will be set by the (server) OS.

Conclusion

The Citrix HDX RealTime Optimization Pack enables you to deploy Skype for Business in your XenApp/XenDesktop environment providing the same optimized call routing and call quality as with native Skype for Business clients. By taking into account that RTOP will transform the client’s endpoint into a VOIP/SFB endpoint and applying the appropriate QoS and DSCP optimizations, you can further enhance call quality and user experience.