What it does
How Teams media actually gets from one endpoint to another — peer-to-peer where it can, through Microsoft's Transport Relays (TURN) where it can't — and what the firewall, proxy and VPN have to allow for that to happen over UDP. Most Teams quality problems in an enterprise come back to this path being longer, or more TCP, than it should be.
Key facts
- Media uses standard ICE: clients gather local, server-reflexive and relay candidates, then pick the most direct working path. Peer-to-peer is preferred; the Transport Relay is the fallback when NAT or firewall rules prevent a direct path.
- A meeting is hosted in the region where the first participant joined. Signalling always goes to the closest server to the user.
- Media runs as SRTP over UDP by preference; TCP is a last-resort fallback. TURN credentials and SRTP keys are exchanged over TLS-secured signalling.
- Endpoint set ID 11 (category Optimize, Required):
52.112.0.0/14,52.122.0.0/15,2603:1063::/38on UDP 3478, 3479, 3480, 3481. Port 3478 is STUN, 3479 audio, 3480 video, 3481 screen sharing. - ID 12 (Allow, Required):
*.lync.com,*.teams.cloud.microsoft,*.teams.microsoft.com,teams.cloud.microsoft,teams.microsoft.complus the Teams IP ranges on TCP 443/80 and UDP 443. - Microsoft's recommendation is no proxy for Teams. Windows-based Teams devices don't support authenticated proxies; Android-based devices don't support authenticated proxies or tenant restrictions and have limited or no support for unauthenticated ones.
- Third-party media relays, SIP proxies and B2BUAs inside the Teams media path aren't supported; an SBC belongs only at the PSTN boundary. Packet shapers and inspection devices in the media path aren't recommended.
- For VPN, Microsoft's model is to route the Optimize ranges direct (split tunnel). The endpoint web service at
endpoints.office.comreturns the current Optimize IPs, and Microsoft publishes PowerShell to add routes withNew-NetRoute. - Signalling (Allow category, HTTPS) is less latency-sensitive and can stay in the tunnel if the security team insists.
- Town halls and view-only meetings use separate CDN endpoints such as
*.ml.cdn.office.netand*.ml.teams.microsoft.comthat Microsoft lists for proxy bypass.
When to use / skip
This isn't optional knowledge on any Teams Phone or Teams Rooms project; it's the first network conversation to have. If UDP 3478–3481 to the Optimize ranges isn't open outbound from every client network, everything else — QoS, bandwidth planning, CQD tuning — is polishing a TCP-fallback experience.
VPN split tunnelling for Teams media is the right call for nearly every organisation with a full-tunnel remote access VPN. Hairpinning media through a VPN concentrator adds latency, burns concentrator capacity, wraps the traffic in TCP if the VPN is SSL-based, and loses DSCP markings. The usual objection is security; Microsoft's answer is that the media is already SRTP-encrypted and the Optimize ranges are Microsoft-owned and low-churn. If a client's security policy truly won't allow it, document the quality impact and move on — don't pretend QoS will fix it.
Configuration decisions
- Whether outbound UDP 3478–3481 to the Optimize ranges goes direct from every site, or through a central breakout. Direct local egress is Microsoft's recommendation.
- Whether to maintain firewall and VPN rules from the endpoint web service automatically or by hand. Automation is the only sane option at scale.
- Split tunnel scope: Teams Optimize only, all Microsoft 365 Optimize, or Optimize plus selected Allow endpoints.
- Proxy bypass for Teams signalling and the events CDN endpoints, and how Teams Rooms and phones are kept off any authenticated proxy.
- Whether to allow peer-to-peer media between internal subnets, or force it through the relay. Allowing it keeps calls inside the building local.
- How the VPN client handles IPv6: either include the IPv6 Optimize range in the split or make sure the IPv6 path isn't leaking around the policy.
- Where Direct Routing media bypass or Local Media Optimization fits — that's a PSTN design decision covered separately, but it changes which flows stay internal.
Gotchas
- TCP 443 working isn't proof that Teams is healthy. Calls still connect over TCP and sound worse; only the connectivity test or call analytics shows the fallback.
- The Optimize ranges change occasionally. Hard-coded lists in VPN profiles drift out of date, and nobody notices until a new relay range is used.
- Cloud proxies and SWG agents on the endpoint often grab UDP or reroute it via a distant POP. Check the egress location, not just whether the call connected.
- Full-tunnel SSL VPNs carry media inside TCP. You get the worst of both worlds: extra latency plus head-of-line blocking.
- Split tunnel by IP only works if the client resolves to the Optimize ranges. Some VPN products split by FQDN, which is harder to keep correct for media.
- Old split tunnel guides list Teams ranges that are no longer current. Always take the list from the endpoint service.
- Android-based Teams Rooms and phones don't support privately signed certificates, so TLS inspection on their signalling breaks them.
Consultant notes
- Verify the path from a remote laptop:
tracert worldaz.tr.teams.microsoft.comshould leave via the local ISP, and a Wireshark capture during a call should show UDP to an address in the Optimize range. - Ask the security team early whether split tunnelling is acceptable. It's a policy decision that can stall a project for weeks if it surfaces late.
- Put the Optimize IP and port table in the low-level design with a link to the endpoint service, and note who owns keeping it current.
- Run the connectivity test before and after any firewall, proxy or VPN change; it detects VPN and split tunnel status and shows the egress point.
- When reviewing an existing estate, check firewall logs for UDP 3478–3481 drops before you look at anything else.
Recheck the ID 11 and ID 12 endpoint rows whenever Microsoft publishes a Teams endpoint change in the Message center