LearnMicrosoft Teams › 7 · Network & firewalls

QoS and DSCP marking

QoS only works if the marks survive the journey — and they are stripped, remapped or ignored at more hops than anyone admits. Configure by port range, verify by capture, and know where marks go to die.

The design in one paragraph

Teams separates modalities by CLIENT SOURCE PORT (audio 50000-50019, video 50020-50039, sharing 50040-50059 — TeamsMeetingConfiguration, in your scan). Your network marks by those ranges — audio EF(46), video AF41(34), sharing AF21(18) by convention — and every queue-capable hop from the access switch to the WAN edge honours the marks. Microsoft marks nothing FOR you on your LAN; outside your network the internet ignores DSCP entirely — QoS is a your-network-only instrument protecting the segments you control (LAN, Wi-Fi WMM, WAN links, VPN tunnels where applicable).

Two marking mechanisms: network-side (switch/router ACLs by port range — works for every client type incl. mobile and rooms) or endpoint-side (Windows GPO QoS policies marking at source — needs domain/MDM reach and the app path right). Prefer network-side as primary: fewer moving parts, covers unmanaged devices.

Where marks go to die (verify at each)

Hop Failure
The client's own OS Endpoint marking policy not applied (wrong app path, non-domain machine)
Access switch ingress Trust boundary resets DSCP to 0 (default on many switches!)
Wi-Fi DSCP-to-WMM mapping absent — marks exist, air interface ignores them
Router/WAN edge Re-marking policy or MPLS provider's class map eats your values
VPN tunnel Inner marks not copied to outer header — tunnel queues blind

What to watch (proofs)

  • Marks at origin: capture on the client — DSCP values on outbound RTP by port range; zero here = endpoint/policy layer, go no further.
  • Marks in transit: capture at (or SPAN of) the WAN edge — the same streams' DSCP; the hop where 46 became 0 is between your two captures. Binary-search with two more captures.
  • Port config truth: Get-CsTeamsMeetingConfiguration | fl Client*Port* — ranges on vs off; serv365 versions this nightly (a helpful admin 'simplifying' ranges breaks every ACL downstream — that's a drift alert).
  • Effect, not just marks: CQD jitter/loss for on-net calls before/after QoS on a congested link — the business case is that delta.

The wire

  • Audio UDP 50000-50019 -> EF/46, Video 50020-50039 -> AF41/34, Sharing 50040-50059 -> AF21/18
  • DSCP is honoured only inside networks you control; the internet ignores it

PowerShell for this concept

Discussion

No messages yet — start the thread.

Sign in with your email to join the discussion — we send a one-time link, no password.