Media Bypass vs Local Media Optimization: When Teams Skips the SBC
Short answer: Media bypass vs local media optimization is not a branding choice. Media bypass lets the Teams client send media directly to your SBC when the path is allowed, so media does not hairpin through Microsoft’s cloud. Local Media Optimization (LMO) is a Direct Routing feature for branch/proxy SBC designs: media stays local to a site when possible, and only signaling (and fallback media) uses the proxy path. Pick bypass when clients can reach the SBC cleanly. Pick LMO when you deliberately put a proxy SBC in front of local SBCs and need site-local media without giving every client a public path to every trunk.
What media bypass does
In a default Direct Routing call, signaling goes Teams ↔ Microsoft SIP proxy ↔ your SBC. Media often takes a longer path through Microsoft media relays even when the user and the SBC are on the same network. That costs bandwidth at the internet edge and adds latency.
Media bypass changes the media leg. When Teams decides bypass is allowed for that call, the client establishes media toward the SBC (or the SBC’s public candidate) using ICE. Signaling still goes through Microsoft. You still need a certified SBC, TLS/SIP options, and correct voice routing. Bypass only changes where RTP/SRTP flows.
Bypass is configured on the online PSTN gateway object (MediaBypass / admin center Direct Routing gateway settings) and depends on:
- SBC and Teams both advertising usable ICE candidates
- Firewall/NAT rules that allow client ↔ SBC media (or a working TURN/relay path when direct fails)
- No policy forcing media through a path that blocks those candidates
For call-flow detail, see Microsoft Teams Media Bypass Explained. For when the SBC never comes up at all, start with Direct Routing troubleshooting before you touch bypass.
What Local Media Optimization is
Local Media Optimization targets a different topology. You deploy:
- A proxy SBC that Microsoft sees as the Direct Routing gateway (public FQDN, options, certificates)
- One or more local/branch SBCs closer to users or to local SIP trunks
Teams learns site/network information (trusted IPs / client location) so it can keep media on the local SBC when the user is “local” to that site. When the user is remote, media may go via the proxy path instead. LMO is about which SBC terminates media for which client location, not about skipping the SBC entirely.
LMO matters when:
- You have many branches with local PSTN breakout
- You want one Microsoft-facing SBC but local media and local trunks
- Central internet links cannot carry every branch’s RTP
It does not replace dial plans, voice routing policies, or number assignment. Those still decide whether the call is PSTN and which usage/route fires. See Teams dial plan vs voice routing policy.
Media bypass vs local media optimization — when each applies
| Question | Media bypass | Local Media Optimization |
|---|---|---|
| Primary goal | Client ↔ SBC media without Microsoft media relay hairpin | Site-local media in a proxy + local SBC design |
| Typical SBC layout | One or more gateways Teams talks to directly | Proxy SBC to Microsoft + local SBCs at sites |
| Best when | Clients can reach SBC candidates (LAN, VPN designed for it, or public SBC) | Branches need local trunks/media; Microsoft only needs one front door |
| Wrong tool when | You need proxy/local SBC hierarchy and site affinity | You only have a single SBC and just want shorter media paths |
| Failure looks like | One-way audio, setup delay, fallback to non-bypass | Remote users on wrong SBC, local users still tromboning, site mapping wrong |
Rule of thumb: If you do not have a proxy/local SBC architecture, you are debating bypass (on/off and network readiness), not LMO. If you do have proxy + local SBCs, LMO is the feature set; bypass settings on the proxy still matter but they are not the same decision.
ICE, VPN, and the traps that waste a weekend
Both features lean on connectivity that desks rarely document.
- ICE candidate mismatch. Bypass needs reachable candidates between client and SBC. If the SBC advertises a public IP the client cannot route to, and no usable relay exists, media fails or falls back. Captures show SIP 200 and then silence.
- Split-tunnel VPN. Full-tunnel VPN often sends Teams media into the datacenter and out again, defeating bypass and creating asymmetric paths. Split tunnel that excludes Teams but still needs SBC reachability is easy to get half-right: Teams works, bypass does not.
- “Bypass enabled” on the gateway, firewall not updated. Admin center shows Media Bypass = On. Client subnets still cannot hit UDP/TCP media ports on the SBC. Symptom: intermittent one-way audio on internal calls that looked fine in a lab on the same VLAN as the SBC.
- LMO site map wrong. Trusted IP / network site definitions do not match how clients actually egress. Everyone looks “remote,” so media never prefers the local SBC.
- Transcoding and bypass. If the path requires transcoding on a box that is not in the media path you expected, quality drops or the call forces a path you did not plan. Bypass does not remove codec negotiation requirements.
- Testing only from the SBC VLAN. Success on the voice VLAN proves nothing for Wi-Fi users two hops away or for home VPN users.
How to test: bypass on vs off
Change one variable at a time. Keep dial plan and routing fixed.
- Baseline with bypass off on the gateway. Place the same internal and external test calls. Confirm two-way audio and note path (Call Quality Dashboard / client call details / SBC media counters).
- Enable bypass on that gateway only. Repeat the same numbers from the same test users.
- Compare media path. With bypass working, client media should target the SBC address you expect, not only Microsoft relay addresses. With bypass failing open, you may still have audio via relay — that is not proof bypass works.
- Failure injection. From a client subnet, block SBC media ports temporarily. Confirm behavior (fallback vs dead air) matches what you promised the business.
- VPN matrix. Repeat on-corp, split-tunnel VPN, full-tunnel VPN. Document which mode is supported. Unsupported modes should be written down, not discovered in an outage.
PowerShell sketch (names vary by tenant; confirm against current Teams PowerShell docs):
Get-CsOnlinePSTNGateway | Select-Object Identity, MediaBypass, BypassMode, Fqdn, Enabled Set-CsOnlinePSTNGateway -Identity sbc.contoso.com -MediaBypass $true # retest, then: # Set-CsOnlinePSTNGateway -Identity sbc.contoso.com -MediaBypass $false
If OPTIONS are down or the gateway is Inactive, stop. Fix signaling first using the troubleshooting guide. Bypass will not heal a dead SBC.
LMO test checklist (proxy + local)
- Confirm Microsoft lists the proxy SBC as the gateway.
- Place a call from a client that should be classified as local to site A. On the local SBC, confirm media counters / sessions. On the proxy, confirm you are not hairpinning media unnecessarily.
- Place the same call type from a remote client. Confirm the expected remote/proxy media behavior.
- Change only the client’s apparent network (different trusted IP / VPN egress) and watch whether site affinity flips. If it never flips, your location mapping is wrong.
Decision guide
- Single SBC or multiple gateways Teams peers with directly, users can reach them: use media bypass where network policy allows; leave LMO alone.
- Proxy SBC + branch SBCs + local trunks: design for LMO; treat bypass as part of that design, not a substitute.
- Heavy full-tunnel VPN with no SBC route: do not promise bypass; fix network or accept relay media.
- One-way audio only after enabling bypass: revert bypass, then fix ICE/firewall before turning it back on.
