While delivering some Teams Rooms on Android training, I was asked a question about Quality of Service (QoS) on Microsoft Teams Android devices. I knew the answer conceptually, but not practically. In other words, I wanted to see it in action.
In this article, I will show how to set up QoS on Teams Android devices and then how to vlaidate that DSCP tags are being applied.
There are a few ways to implement QoS for Teams – via Group Policy, networking equipiment, and via Meeting settings in Teams.
This article isn’t going to go through the pros and cons of each method. I’m just going with the last option – enabling QoS via Meeting Settings in Teams.
To do this, open up Teams admin center and expand to the Meetings section. Next, click on Meeting settings.
Meeting settings in Teams admin center
From here, scroll to the Network section. Right at the top of this section is an option named Insert Quality of Service (QoS) markers for real-time media traffic. Flip this switch from Off to On.
Enabling QoS in Teams
Note: This will enable QoS on a lot of things beyond Teams Android devices – like all your Android mobile phones. There *shouldn’t* be a problem here but be sure you ae working on this with your networking staff because there is a lot more to QoS than flipping this switch. I’m also leaving all the media ports at default where your network team may need you to change these values.
Once you have enabled QoS, wait. At some point, like magic, Teams network traffic will start getting tagged with the appropriate DSCP markers.
So how do we know it’s working?
Well in my world, you look at a Teams network packet and see if it is tagged. It is at this point in the article where I can only provide some high level guidance as every network is different and where you go to “listen” to network traffic differs wildly. If you are in any moderately sized IT department, there will be someone who can do this for you or work with you to sniff the network traffic.
Yup, if this is all knew to you, the workd sniffing is part of the parlance.
In my simple home network, this is how I did it.
I happen to have a firewall from Ubiquit that has a packet sniffer bnuilt in. It’s called tcpdump which is a commonly used tool to sniff traffic. I won’t explain other ways to do this, but mirrioring a network port or using a dumb hub works too.
Now the most direct way to do this is to remote to the firewall using secure shell (ssh), run tcpdump, capture the traffic, copy it to my PC, and finally look at the file with WireShark.
And that way definitely would work. But it’s a lot of signing in and copying files and manually opening files that was just a bit much for me. Doing a little Bing-fu, I came across a post on the Ubiquiti support forums that allowed me to stream the tcpdump captures directly into WireShark on my Windows PC.
This command may or may not work for you if you want to do similar packet sniffing.
plink -batch -l <firewall username> -pw <firewall password> <firewall IP address> sudo /usr/sbin/tcpdump -i <firewall interface, e.g. eth1> -w - host <IP address of Android device> | "c:\program files\WireShark\Wireshark.exe" -k -i -
First up….what is a “plink”? It was new to me too. Plink stands for “PuTTY link” which is a command line interface for PuTTY. It basically signs into my firewall, starts tcpdump, and then redirects the output from tcpdump to a data stream that gets piped to WireShark, where the real magic happens.
The loose ‘-‘ in that command line are required.
Note: Run this command the first time to cache the secure key from the firewall:
plink -l <firewall username> -pw <firewall password> <firewall IP address>
It’s also a useful test to make sure you can get connected.
Within WireShark, I used a simple display filter to filter on rtcp packets.
Apply rtcp display filter
The first few rtcp packets from your Android bar may not show the QoS information, but if you scroll down a bit, you will start seeing tagged packets, Also be sure that you are clicking on entries where the source is your Android device.
What are you looking for? How do you know QoS was tagged? Good question!
Here is a packet that shows QoS was applied. I’ll break this down to help you understand what you are seeing.
Full display of a captured rtcp packet.
Hopefully you figured out the top half shows all of the packets, and you can apply a display filter. After clicking on a packet, the bottom half of the screen shows the details. I’ve expanded the two most relevant sections.
Before we get any further, let me paste in the default settings that Teams recommends.
Recommended Port Ranges and DSCP Values
Now let’s break down the packet capture and see what we have. Starting from the top of the Internet Protocol (IP) section, we can see there are DSCP values.
For DSCP, we see something called “AF41”. If we look at the table above, we see that AF41 is applied to video. Cool. Can we further verify that this is a video stream?
Yes, yes we can.
Look down into the User Datagram Protocol (UDP) section and look at the Source Port value.
This tells us that the rtcp packet was sent from the Android device on UDP port 50031. Look up at the chart above, and you can see that media sourced from port 50031 is indeed video traffic as the video source port range is 50020 – 50039.
We now know that QoS is applied to our packets and that they are being applied correctly.
