Learn › Microsoft Teams › 7 · Network & firewalls

Network and media: transport selection and every fallback

Teams never has one path to the media relay — it has a ladder of them, and it silently climbs down until something works. Quality is decided by which rung your network leaves available.

The flow — what actually happens

Plain-language first; the packet-level view underneath each step is what you'd see in a Wireshark trace, and what healthy looks like.

  1. You press Call

    Nothing media-related happens yet. The client tells the Teams service over its existing HTTPS connection: 'I want to call Priya.' The service works out where Priya's clients are signed in and pushes a ring notification to all of them.

    On the wire Existing TLS session to 52.112.0.0/14:443 (SNI teams.microsoft.com) carries a burst of small packets. Nothing on UDP yet. If you see a fresh DNS query + TLS handshake here, the client was cold-starting its signalling.
  2. Both sides map their exits (ICE gathering)

    While Priya's phone is still ringing, both clients quietly ask a Microsoft relay: 'what do I look like from the internet, and can you reserve me a slot on you just in case?' Each side builds its list of possible addresses — local, public, and relay.

    On the wire First UDP appears: STUN Binding Requests to relay IPs on 3478, answered with XOR-MAPPED-ADDRESS (your public address), then TURN Allocate Request/Success (the reserved relay slot). All parsed by Wireshark's STUN dissector. No allocations appearing = your 3478 is blocked.
  3. Priya answers — the race

    The candidate lists cross over via signalling, and both clients simultaneously probe every combination: me-direct-to-you, me-via-relay, you-via-relay. First usable pair with the highest priority wins. This is why answer-to-audio takes about a second.

    On the wire A flurry of STUN Binding Requests BETWEEN candidate pairs, carrying PRIORITY and eventually USE-CANDIDATE attributes — the nomination. Failed pairs just stop; the winner keeps exchanging.
  4. Media flows

    Voice packets start streaming both ways on the winning path — encrypted (SRTP), 50 tiny packets a second in each direction, every 20 ms, for as long as you talk.

    On the wire Steady bidirectional UDP: ~50 pps per direction, ~100-200 bytes each, to relay 3478-3481 (or peer-to-peer for 1:1). Decode As > RTP shows sequence numbers and timestamps even though payloads stay encrypted. HEALTHY: metronome-regular 20 ms spacing, sequence numbers without gaps. SICK: gaps (loss), irregular spacing (jitter), or media inside a TLS stream on 443 — the TCP fallback rung.
  5. Mid-call housekeeping

    Every few seconds the endpoints exchange quality report cards (loss, jitter, delay) and keep the path alive through firewalls. If the network changes — Wi-Fi to 4G — the call re-runs the race on the new network without hanging up.

    On the wire RTCP Sender/Receiver Reports every ~5 s (these numbers feed CQD), STUN keepalives roughly every 15-25 s, and on network change: a fresh burst of gathering + checks (ICE restart) while audio briefly gaps.

Two planes, two problems

Signalling (join, roster, mute, chat during the call) is HTTPS 443 to the Teams service. It survives almost any network and is rarely your problem.

Media (RTP audio/video/screenshare) negotiates its own path per call using ICE (Interactive Connectivity Establishment). Understanding that negotiation — and the exact order it degrades in — is the whole game.

The candidate ladder

At call setup each endpoint gathers candidates — addresses it might be reachable on:

  1. Host — its own local IP/port (client range, see below)
  2. Server-reflexive — its public IP as seen by the relay, discovered via STUN on UDP 3478
  3. Relay — a port allocated on the Microsoft transport relay (13.107.64.0/18, 52.112.0.0/14), allocated via TURN on UDP 3478

Both sides exchange candidates, run connectivity checks on every pair, and pick the best working pair, in strict preference order:

Rank Path Transport What it means
1 Direct peer-to-peer (1:1 calls) UDP, client range Best case — media never leaves your WAN for internal calls
2 Via relay UDP 3478–3481 Normal case for conferences and most external calls
3 Via relay TCP 443 (TURN/TCP) UDP blocked — works, degrades
4 Via proxy HTTPS tunnel (CONNECT) Last resort — expect complaints

The call connects on all four rungs. Users don't report "we're on rung 4" — they report choppy audio on Thursdays. Your job is knowing which rung a site actually uses.

Port-by-port: what breaking each one does

The four relay ports are not equals:

  • UDP 3478 — STUN/TURN control. The one that matters. Candidate discovery and relay allocation happen here. Block it and UDP media is off the table entirely — every call at that site drops to TCP 443 (rung 3).
  • UDP 3479 (audio), 3480 (video), 3481 (screenshare) — per-modality relay ports. Their real purpose is classification: they let firewalls and QoS treat audio better than screenshare. With only 3478 open, media multiplexes onto 3478 and calls still work on UDP — you lose per-modality visibility and QoS separation, not the call. Microsoft lists all four as required for the Optimize category; treat 3478-only as a degraded state you fix, not a config you design for.

Failure signatures, mapped back:

Symptom Likely rung/break
Call connects, then ~10s silence, then drops UDP checks timing out before TCP fallback completes — asymmetric block
One-way audio UDP open one way only (site A can reach relay, site B's return path filtered)
Everything works but quality dips at one site That site is on TCP 443 fallback — check 3478 outbound
Screenshare stutters while audio is fine 3481 blocked / QoS starving sharing; audio survived on 3479
Works on mobile hotspot, fails on corp Wi-Fi Proxy or SSL-inspection in the media path

The client side of the port pair

The source ports matter too. Defaults (visible in your tenant — we scan TeamsMeetingConfiguration):

  • Audio: UDP 50000–50019 · Video: 50020–50039 · Sharing: 50040–50059

These exist for the same reason as 3479–3481: so your LAN can classify and DSCP-mark each modality (audio EF/46, video AF41/34, sharing AF21/18 by convention). If ClientMediaPortRangeEnabled is false, the client uses ephemeral ports and your QoS policy has nothing to match on.

Three rules that prevent most tickets

  1. Local breakout for Optimize endpoints. Media exits the internet at the user's site — never hairpinned through a central proxy or full-tunnel VPN. Every hop is jitter you cannot remove; SSL inspection of media is pure harm (it's SRTP — encrypted already, uninspectable, and inspection boxes mangle long-lived UDP flows).
  2. Never proxy the relay ranges. Proxies exist for HTTP; TURN/TCP through a proxy is rung 4. The Optimize list is three rows — 13.107.64.0/18, 52.112.0.0/14, 52.122.0.0/15 — automate it from endpoints.office.com rather than hand-copying.
  3. Split-tunnel VPN for the same three ranges. Full-tunnel VPN + voice is the single most common self-inflicted quality incident.

Verifying instead of believing

  • Tenant side: our scan holds TeamsMeetingConfiguration (client port ranges, QoS) and TeamsNetworkRoamingPolicy — check what policy says before touching cables.
  • Network side: the Microsoft 365 network connectivity test from an affected site tests the actual relay path, UDP reachability and protocol used.
  • After the fact: a rising share of TCP-transport calls in CQD for one subnet is the smoking gun for a broken UDP path at that site.

The wire

  • UDP 3478 -> relay ranges: STUN/TURN control — the load-bearing port
  • UDP 3479/3480/3481 -> audio/video/sharing relay (multiplexes onto 3478 if blocked)
  • TCP 443 -> TURN/TCP fallback (works, degrades)
  • Client source: UDP 50000-50019 audio / 50020-50039 video / 50040-50059 sharing
  • Optimize ranges: 13.107.64.0/18, 52.112.0.0/14, 52.122.0.0/15
  • endpoints.office.com — machine-readable endpoint feed

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.