A glitch in the matrix that’s been bugging me for a while but just haven’t sat down to think it through… What to do with Video Based Screen Sharing and QoS. VBSS came to us midstream for Skype for Business in June 2016, as a nice improvement to update speed and smoothness for Application/Desktop sharing, utilizing video and UDP instead of RDP and TCP. Of course if you have a older client or if you start Recording the session, it reverts back to RDP/TCP.
What many have not realized though is that when a client is using VBSS in a Skype Meeting (not talking peer to peer here), that the Skype client selects an Application Port for the Source, but the Skype Server actually selects a Video port. For the purpose of this post I’m using my typical QoS settings:
Audio Server: 49152-57500 Audio Client: 50040-50079
Video Server: 57501-65535 Video Client: 58000-58039
App Server: 40803-49151 App Client: 42000-42039
DSCP: Audio=46, Video=34, Application Sharing=24
The screenshot below is a Wireshark capture on the FE server. As you can see, the Client source port is 42004, and the Destination port on the Server is 62345. And in this particular network where this sample is taken, there are source/destination port restrictions set for the DSCP tags. In this case 42000-40039 <–> 40803-49151. Result is that not only is the traffic using both App and Video ports, it’s not even left tagged at all.
QoS Problem #1 – assuming the network does not have Src/Dst restrictions, you would end up with a DSCP mismatch; traffic from the server tagged with 34, traffic from the client tagged with 24. Server Video traffic is then getting mixed with Server VBSS traffic.
QoS Problem #2 – with network Src/Dst port restrictions in place, traffic is deprecated into the lowest bucket 0, or worse.
In my opinion, the VBSS ports, both server and client, should have remained in the Application port ranges, but obviously this is not the case. Surprisingly the solution is not to difficult. We need to modify the QoS Policy on the Frontend servers by adding one new QoS policy.
New-NetQosPolicy -Name “Skype Server VBSS” -IPProtocol Both -IPSrcPortStart 57501 -IPSrcPortEnd 65535 -IPDstPortStart 42000 -IPDstPortEnd 42039 -DSCPValue 24
This new policy filters for network traffic matching both the Source port and the Destination port to tag it with a 24. From my observations, because the “Skype Server VBSS” has this additional criteria, this makes it more restrictive than the “Skype Server Video” policy and it gets applied and the tagging works as desired.
Look at those happy little tags. .101 is the Server in this screen shot and the .119 is a Trio.
If it is a particular concern, or just really want to locked down the policy, you can use this “Skype Server Video” policy. My concern about adding this policy restriction is the traffic with the Edge for external users would not be prioritized on the network. Edge traffic to the front end is going to be 443 or 3478 and would meet either Video QoS policy criteria:
New-NetQosPolicy -Name “Skype Server Video” -IPProtocol Both -IPSrcPortStart 57501 -IPSrcPortEnd 65535 -IPDstPortStart 58000 -IPDstPortEnd 58039 -DSCPValue 34
To address QoS Problem #2, the network will need to be reconfigured to allow:
42000-40039 <–> 40803-49151 with DSCP=24
42000-40039 <–> 57501-65535 with DSCP=24
Of course another solution is to modify your App and Video ports for client and server to all live in the 57501-65535 space with both using DSCP=34, but then you have no delineation between VBSS and Camera Video streaming. A less then ideal solution.
Or disable VBSS… yuck.
For posterity sake, the other Net QoS Policy settings I use are:
New-NetQosPolicy -Name “Skype Server Audio” -IPProtocol Both -IPSrcPortStart 49152 -IPSrcPortEnd 57500 -DSCPValue 46
New-NetQosPolicy -Name “Skype Server Video” -IPProtocol Both -IPSrcPortStart 57501 -IPSrcPortEnd 65535 -DSCPValue 34
New-NetQosPolicy -Name “Skype Server App” -IPProtocol Both -IPSrcPortStart 40803 -IPSrcPortEnd 49151 -DSCPValue 24