QoS for Teams!

SOLVED
nikmagashi
Getting noticed

QoS for Teams!

Hi,

 

I am trying to configure QoS on meraki MX84 and I have only configured it here. We have non-meraki switches and APs so I have started first with MX first. 

 

I have created rules under SD WAN & traffic shaping and created 5 rules (the default one is disabled). 

 

Rule #1:

 

Definition: All VoIP & video conferencing 

Bandwidth limit: Obey network per-client limit

Priority: High

DSCP Tagging: AF11

 

All the other rules are the same when it comes to definition, bandwidth limit and priority but they have other DSCP tagging. I have configured AF21 for rule #2, AF31 for rule #3, for rule #4 is AF41 and for rule #5 I took CS0/DF - Best effort/Default forwarding.

 

Are these settings supposed to work for optimizing Video Conference on Teams?

 

Thank you in advance!

1 ACCEPTED SOLUTION
Bruce
Kind of a big deal

Unlikely as the video traffic in MS Teams doesn’t go to the SBC, the SBC is usually just for PSTN (voice) calls, or interconnection to a PBX. You’ll need to identify the ports that MS Teams is using for video and identify traffic based on those. I believe MS Teams uses destination ports of UDP 3478-3481 for media when communicating to the Office365 cloud along with TCP 80 and 443 for signalling - they are a good start... Within the network (I.e. peer to peer) it will be other port ranges, as per the QoS link from UCcert.

View solution in original post

5 REPLIES 5
UCcert
Kind of a big deal

Hi @nikmagashi , take a read through the below document:

 

https://docs.microsoft.com/en-us/microsoftteams/qos-in-teams

 

Looking at that document and your rules Teams Video Conferencing will hit rule 4

Darren O'Connor | uccert.co.uk
https://www.linkedin.com/in/darrenoconnor/

I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.
Bruce
Kind of a big deal

@nikmagashi I’m assuming by Teams you are referring to Microsoft Teams. In this case I’m not sure you’re going to be prioritising traffic as you expect. Microsoft Teams uses HTTPS-based REST calls for most of its signalling and I don’t believe the “All VoIP and Video Conferencing” captures these, and it definitely can’t apply any smarts to determine the real-time streams since the signalling is encrypted. The notable exception to this is signalling to a SBC for which Microsoft Teams uses SIP, and the rules “All VoIP and Video Conferencing” should catch this.

 

If you use the article that @UCcert referenced you can determine the ports used for the various traffic types in Microsoft Team and create rules to identify the Microsoft Teams traffic based on these and then mark (I.e. assign a DSCP tag), shape and prioritise appropriately. You should only need a few rules at most, one to identify/mark audio traffic, one for video, and one for application/screen sharing.

 

You don’t mention anything about where this traffic is going. Is it going straight to the internet, or over a AutoVPN to another site? If it’s straight to the internet then there is little point in marking the traffic as the marking will be lost/ignored the minute the traffic hits the internet. If you’re using AutoVPN then by all means mark the traffic and the markings will be carried to the other site. But you are right to use the the priority to ensure the real-time traffic leaves the MX in-front of other traffic.

 

After all that is said, if you’re currently not seeing any performance issues with your Teams calls at the moment, you probably won’t get any benefit from QoS. However, if you’re having issues then it’s worth working through it.

Hi Bruce,

 

When you are saying "The notable exception to this is signalling to a SBC for which Microsoft Teams uses SIP, and the rules “All VoIP and Video Conferencingshould catch this" does this mean that the All VoIP and Video Conferencing will catch or will not, the video traffic?

Bruce
Kind of a big deal

Unlikely as the video traffic in MS Teams doesn’t go to the SBC, the SBC is usually just for PSTN (voice) calls, or interconnection to a PBX. You’ll need to identify the ports that MS Teams is using for video and identify traffic based on those. I believe MS Teams uses destination ports of UDP 3478-3481 for media when communicating to the Office365 cloud along with TCP 80 and 443 for signalling - they are a good start... Within the network (I.e. peer to peer) it will be other port ranges, as per the QoS link from UCcert.

View solution in original post

GIdenJoe
Kind of a big deal

The feature I find lacking in the MX traffic shaping rules is matching on existing DSCP tags.

It's better IMO to give corp laptops QoS trust and let the client itself apply the tagging.

Since Teams uses the same source ports for voice like skype4b and the same source ports for video you can easily build a GPO with a netQoS policy that adds support for these.

However the voice part which is using UDP 50000-50019 should already be tagged DSCP EF which should be matched by the MX when you use default QoS rules in the realtime queue.

Btw normal strategy for video conferencing uses AF4x PHB, not the high throughput AF1x.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels