Teams Calling QoS — Network Requirements for Production Voice Quality
Voice calls are unforgiving about network conditions in a way that most other applications aren’t. A webpage that loads slowly is annoying. A video that buffers is frustrating. A voice call where words drop out, audio cuts in and out, or both parties keep talking over each other is unusable — and it reflects on the phone system, not the network, in the eyes of the people experiencing it.
Quality of Service (QoS) is the mechanism that prevents this. It tells your network to treat Teams voice traffic differently from everything else — to put it at the front of the queue rather than making it wait behind a software update or a file download. This article covers what QoS does, how it works for Teams specifically, and what you actually need to configure to make production voice quality consistent.
This article bridges into the Networking pillar — for the full end-to-end QoS configuration reference covering routers, switches, and VLANs, see the QoS for VoIP — How to Actually Configure It End to End.
Why Voice Traffic Needs Priority Treatment
Standard networks process traffic on a first-in, first-out basis. Every packet waits in line regardless of what it contains. That model works fine for most applications — a database query that takes an extra 50 milliseconds, a file transfer that takes an extra second — none of that is noticeable.
Real-time voice is different. Without QoS, voice and video traffic can experience jitter (media packets arriving at different rates, causing missing words or syllables), packet loss (packets dropped, resulting in degraded or unintelligible audio), and delayed round-trip time (noticeable delays between both parties that cause people to talk over each other).
These aren’t minor inconveniences. A call with consistent jitter is functionally unusable. And unlike a slow download, there’s no retry mechanism — dropped voice packets are gone.
QoS uses Differentiated Services Code Point (DSCP) markings together with port-based Access Control Lists (ACLs) to identify, mark, and classify all packets in real-time streams, ensuring that voice, video, and screen share streams receive preferential treatment over other types of traffic.
The Three Problems QoS Solves
Understanding what QoS fixes makes it easier to understand how it works.
Jitter is variation in packet arrival timing. Voice codecs expect packets at consistent intervals. When packets arrive irregularly — because they competed with other traffic in the queue — the audio output stutters or drops syllables. QoS reduces jitter by keeping voice packets in a dedicated high-priority queue rather than the general pool.
Packet loss happens when a router or switch drops packets under load. A router that’s processing more traffic than its queue can handle has to drop something — and in a first-in, first-out model, voice packets are just as likely to get dropped as anything else. With QoS, voice packets are processed before the queue reaches the point where dropping starts.
Latency — specifically round-trip time — is the delay between one party speaking and the other hearing it. Humans tolerate up to about 150ms of one-way delay before conversation becomes stilted. Beyond 300ms it becomes noticeably awkward. Network congestion adds variable latency that QoS eliminates by keeping voice on a priority path through every hop.
How Teams Marks and Classifies Traffic
Teams uses DSCP values to tag packets by traffic type. Each type of Teams media traffic gets a specific DSCP value that network devices can recognize and prioritize accordingly.
Microsoft’s recommended port ranges and DSCP values for Teams are:
| Media Traffic Type | Client Source Port Range | Protocol | DSCP Value | DSCP Class |
|---|---|---|---|---|
| Audio | 50,000–50,019 | TCP/UDP | 46 | Expedited Forwarding (EF) |
| Video | 50,020–50,039 | TCP/UDP | 34 | Assured Forwarding (AF41) |
| Application/Screen Sharing | 50,040–50,059 | TCP/UDP | 18 | Assured Forwarding (AF21) |
| Signaling | 50,070–50,089 | UDP | 40 | Class Selector 5 (CS5) |
Audio gets DSCP 46 — Expedited Forwarding — which is the highest priority class in the DSCP model and the standard marking for voice traffic across virtually all QoS implementations. Video gets AF41, screen sharing gets AF21, and signaling gets CS5. The port ranges are what allow network devices to identify and mark traffic from endpoints that don’t insert their own DSCP markings.
One important note on the signaling port range: the ports used for calling and meetings signaling (50,070–50,089) are not currently configurable. Everything else can be adjusted if your environment requires it, but port ranges can’t overlap and should remain adjacent.
Two Ways to Implement QoS for Teams
There are two implementation approaches, and Microsoft recommends using both together where possible.
Endpoint DSCP Marking
The Teams client inserts DSCP markers directly into IP packet headers before the traffic leaves the device. On Windows endpoints this is configured via Group Policy or Intune. The executable for new Teams is ms-teams.exe.
For Mac and mobile clients (iOS and Android), DSCP values for audio (EF/46) and video/screen sharing (AF41) are hard-coded — they apply automatically once QoS is enabled globally in the Teams Admin Center and can’t be customized further.
Port-Based Tagging at the Router
Your network’s routers and switches examine incoming packets, identify Teams traffic by source port range, and apply the appropriate DSCP marking. This approach works regardless of the endpoint type or operating system — it catches traffic from Windows, Mac, iOS, Android, and browser-based clients alike.
Port-based tagging is the most reliable method because it works in mixed Windows, Mac, and Linux environments. The recommended approach is a combination of DSCP markings at client endpoints and port-based tagging ACLs on routers — managed devices get centralized policy controls for client-side DSCP markings, while port-based ACLs handle devices that can’t configure client-side markings.
The QoS Implementation Sequence
Getting QoS right requires consistency across every device in the path — from the endpoint to the router to the internet edge. A QoS configuration that only covers part of the path provides partial benefit at best.
1. Enable QoS globally in Teams Admin Center. Before endpoint or network configuration has any effect, QoS needs to be enabled at the Teams service level. In the Teams Admin Center, go to Meetings > Meeting settings and enable “Insert Quality of Service (QoS) markers for real-time media traffic.” Without this step, client-side DSCP markings won’t function.
2. Configure DSCP markings on Windows endpoints. Use Group Policy or Intune to push the QoS policy to domain-joined Windows devices. The policy targets ms-teams.exe, covers both TCP and UDP, and applies the appropriate DSCP value per port range. Audio (50,000–50,019) gets DSCP 46, video (50,020–50,039) gets DSCP 34, screen sharing (50,040–50,059) gets DSCP 18.
3. Configure port-based ACLs on routers and switches. Work with the network team to implement ACLs that match Teams port ranges and apply the correct DSCP markings. This covers endpoints that can’t insert their own markings — Mac clients, mobile devices, browser-based participants.
4. Configure QoS queues on network devices. DSCP markings only matter if the network devices act on them. Routers and switches need to be configured with queuing policies that prioritize EF-marked traffic (audio) over AF41 (video) over AF21 (screen sharing) over best-effort traffic. This is the network team’s side of the QoS equation.
5. Validate the implementation. Capture traffic at the network egress point and verify that DSCP values are present and correct — that they haven’t been stripped or rewritten somewhere in the path. Call Quality Dashboard (CQD) in the Teams Admin Center is the primary tool for ongoing monitoring once QoS is live.
VPN and Remote Workers
VPN is where QoS gets complicated for remote deployments, and it’s worth being direct about this: QoS works as expected only when implemented on all links between callers. A VPN inherently adds packet overhead and creates delays in real-time traffic — running real-time communications traffic over a VPN is not recommended.
The standard recommendation for remote Teams voice users is split tunneling — Teams media traffic bypasses the VPN and goes directly to Microsoft’s network, while other corporate traffic routes through the tunnel normally. Split tunneling removes the VPN as a latency and jitter source for voice calls, which typically has a more significant impact on call quality than QoS configuration alone.
If split tunneling isn’t an option in your environment, QoS can still be applied to the VPN tunnel itself — but the benefit is limited to the tunnel segment, and the VPN overhead remains.
Bandwidth Requirements
QoS manages how available bandwidth is used — it doesn’t create bandwidth. If a circuit is genuinely undersized for the call volume it needs to support, QoS helps but won’t fully solve the problem. Both need to be right.
Microsoft’s bandwidth guidance for Teams audio calls:
| Scenario | Recommended Bandwidth |
|---|---|
| Peer-to-peer audio call | 30 Kbps per direction |
| Group audio call | 30 Kbps per direction |
| Teams Phone (desk phone) | 100 Kbps per device |
| Teams Rooms | 3–4 Mbps typical (up to 10 Mbps allocated) |
For a calling-focused deployment, the audio figures are the critical ones. Size your internet and WAN circuits against concurrent call estimates, not total user count — most users aren’t on calls simultaneously.
What Goes Wrong
QoS enabled on endpoints but not on the network. DSCP markings in packet headers accomplish nothing if the routers and switches don’t have queuing policies that act on them. Both sides of the implementation have to be complete.
DSCP values stripped at the network edge. Some ISPs and edge devices rewrite or remove DSCP markings as traffic leaves the managed network. If this happens, verify where the stripping occurs and whether it can be preserved to the Microsoft network edge.
VPN swallowing voice traffic. A full-tunnel VPN that routes Teams media is one of the most common causes of poor call quality in hybrid environments. If users are consistently experiencing worse call quality from home than from the office, VPN routing is usually the first place to look.
QoS not enabled in Teams Admin Center. Client-side DSCP markings don’t function until QoS is enabled globally at the service level. This is a one-switch change that’s easy to miss.
Inconsistent port ranges between endpoint policy and network ACLs. If the port ranges in your Group Policy or Intune configuration don’t match the ranges in your router ACLs, the network devices won’t correctly identify and prioritize the traffic. Verify the ranges match exactly across every configuration point.
The Bottom Line
QoS for Teams is a joint project between the Teams admin and the network team. The Teams side is enabling QoS in the Admin Center and pushing DSCP policies to endpoints. The network side is configuring ACLs and queuing policies on routers and switches. Neither side alone is sufficient.
Get the DSCP values right, apply them consistently from endpoint to network edge, keep voice traffic off the VPN, and validate with CQD before you call a deployment production-ready. Voice quality problems are the ones users notice and remember — QoS is the configuration that prevents most of them.
For the full network-side implementation — router ACLs, switch configuration, VLAN design for voice, and firewall rules — see QoS for VoIP — How to Actually Configure It End to End.
Microsoft reference: Implement Quality of Service (QoS) in Microsoft Teams