Are you using Citrix or any other 3rd party application that handles media (e.g. Call Recording / Contact Centre) with Skype for Business? You may find you’re not marking this traffic with the correct DSCP markings.
You should configure QoS in the usual method using a Windows GPO. Mark Vale documents this process really well: https://blog.valeconsulting.co.uk/2015/09/07/skype-for-business-configuring-quality-of-service-qos/
Pat Richard has a really useful QoS Calculator here: https://www.ucunleashed.com/2821
“Why does it matter if I’m using Citrix or a call recording application like Verba?” Answer – They have their own executables and don’t use the standard SfB exe’s to send/receive media!
I’ll start with Citrix. When using SfB in a VDI environment, the user will be using a Thin Client and their SfB client would usually be installed on a XenApp / XenDesktop server in a datacentre somewhere. All SfB calls, whether P2P, PSTN, Conference will traverse the Citrix ICA session which may not be the most optimum path or protocol for Real Time Media. It’s also not possible to put QoS on SfB Voice as it would be encapsulated within the ICA session.
The solution from Citrix is the HDX Optimization Pack. At a high level, when you make a SfB call, the HDX Pack changes the Media Candidate from the VDI servers IP, to the users Thin Client IP. SfB calls are now outside the ICA session and direct to the Thin Client (yey!). The problem is the HDX Pack doesn’t have or use Lync.exe on the Thin Client for media traffic, it actually uses MediaEngineService.exe.
Citrix document it on a blog here: https://www.citrix.com/blogs/2017/12/19/rtop-dont-forget-about-qosdscp/
You can check the DSCP markings on your SfB traffic using WireShark, if QoS is working you will see the Expedited Forwarding for Audio Traffic. If you use the Citrix HDX pack and haven’t configured QoS, this will not be tagged correctly.
For Windows Terminals, the solution is simple, you need to add MediaEngineService.exe to your SfB Client QoS GPO using the same Source Ports and DSCP values as Lync.exe. For non-windows Terminals you need to follow the guidelines in the Citrix Blog above.
If you’re using a Third Party Contact Centre or Call Recording software you will also have the same issue. Your Third Party app may also not have been configured to use the same Source Ports as your SfB Servers too! I will use Verba as an example.
Verba has multiple methods to record different SfB modalities, in this example I will cover Audio recording via a Verba Proxy. When a Verba Proxy is utilised to record Audio, Verba modifies the SfB Media Candidates so the SfB client sends its Audio Stream to the Proxy. The proxy sits in the middle of a P2P, PSTN, Conference Call etc depending on the calls types that need to be recorded.
Problem 1 – Just like Citrix, Verba uses a different executable name so Audio traffic is not tagged as EF 46.
Problem 2 – Verba by default is not using the same SfB Audio and Video ports you have set for SfB QoS (i.e. Splitting Audio and Video)
Problem 1 is easily resolved by creating the relevant GPO for “recorderproxy.exe” (note use Local GPO for RecorderProxy.exe on Edges!):
Problem 2 is resolved within Verba itself, within the RTP Proxy settings you can specify the port ranges SfB is using for Audio and Video.
I hope you find this post useful, just keep in mind, if a SfB Audio/Video Stream is going to a non Microsoft application you may not have it covered by QoS. Please feel free to comment your QoS findings!
Technical Architect at Symity