Architecting Microsoft Teams Direct Routing with Local Media Optimization (LMO)

Overview

Key takeaways

• Understand how LMO decouples SIP signaling from RTP media streams in Microsoft Teams Direct Routing.
• Learn the architectural distinction between Proxy (Central) SBCs and Secondary (Downstream) SBCs.
• Master the configuration of Teams PowerShell cmdlets including New-CsOnlinePSTNGateway flags for media bypass.
• Analyze SIP signaling flows and proprietary headers such as X-Comp-Path and P-D-Uri.
• Implement network site definitions, trusted IP subnets, and location-based routing for secure local hairpins.

Prerequisites

• Certified Session Border Controller (Ribbon, AudioCodes, Oracle, or Cisco) with LMO firmware support.
• Microsoft Teams Phone System licenses and administrative access to Tenant PowerShell.
• Deep understanding of SIP protocol flows, SDP offer/answer model, and ICE/STUN/TURN concepts.
• Enterprise network infrastructure with defined internal IPv4/IPv6 subnets and site topologies.

Guide

1. section #1

   Core Architecture and LMO Fundamentals

   Signaling vs. Media Paths

   In standard Microsoft Teams Direct Routing, SIP signaling and RTP media travel from the user's Teams client over the public Internet to the Microsoft Teams SIP Proxy and Media Processors, which then forward the streams to an enterprise Session Border Controller (SBC). While effective for simple topologies, sending internal site-to-PSTN media out to the cloud and back creates unnecessary WAN utilization and latency.

   Decoupling Media with LMO

   Local Media Optimization (LMO) solves this efficiency issue by allowing the SIP signaling path to remain routed through the Microsoft Cloud Infrastructure while forcing the RTP/SRTP media stream to flow directly between the internal Teams client and the local SBC. This media decoupling ensures optimal voice quality and saves internet bandwidth.

   Key Architectural Benefits

   • Reduced Bandwidth: Media stays entirely within the corporate LAN/WAN for on-premises users.
   • Lower Latency: Eliminates round-trips to Microsoft Cloud Media Relays.
   • Regulatory Compliance: Keeps voice payload inside localized physical boundaries for strict data residency mandates.
2. section #2

   Network Topology and Component Roles

   Proxy SBC vs. Downstream SBC

   LMO introduces a tiered topology consisting of two distinct SBC roles:

   • Proxy SBC (Central SBC): Connected directly to the public Internet and paired with the Microsoft Teams SIP Proxy using TLS and mutual authentication. It handles all inbound and outbound SIP signaling.
   • Downstream SBC (Secondary/Local SBC): Resides inside the internal enterprise network without a public IP address. It connects directly to local TDM/SIP trunks and handles local RTP media termination.

   Network Regions, Sites, and Subnets

   Teams client location detection is critical for LMO. Microsoft Teams uses defined Network Sites, Subnets, and Trusted IPs in the Teams Admin Center to determine whether a client is currently located on-premises behind a specific SBC.

   Location Determination Rules

   • Internal User: The client's public IP matches a Trusted IP, and its internal IP matches an enterprise Network Subnet associated with an SBC site.
   • External User: The client public IP does not match enterprise trusted IPs. Signaling and media fall back to standard Direct Routing paths via Microsoft Transport Relays.
3. section #3

   Configuring Teams Online PSTN Gateways for LMO

   Enabling Media Bypass Flags

   To configure LMO in Microsoft Teams PowerShell, you must update or create Online PSTN Gateways representing both the Proxy SBC and Downstream SBCs. LMO relies on specific flags including -MediaBypass, -PstnSignalingDecoupled, and -BypassMode.

   PowerShell Configuration Example

   The following script demonstrates how to define a Central Proxy SBC and a Downstream Local SBC using the MicrosoftTeams PowerShell module.

   Key Parameters Defined

   • PstnSignalingDecoupled: Set to $true on downstream SBCs to notify Teams that signaling is relayed by a central proxy.
   • BypassMode: Set to Always or OnlyForOnetoOne depending on tenant media topology.
   • IssuerHexNodeId: An optional hex string matching SBC identity for call routing disambiguation.
   powershellcopy

   # Define Central Proxy SBC (Internet Facing)
   New-CsOnlinePSTNGateway -Fqdn sbc-central.contoso.com `
     -SipSignalingPort 5061 `
     -MaxConcurrentSessions 500 `
     -Enabled $true `
     -MediaBypass $true `
     -BypassMode "Always" `
     -ProxySbc sbc-central.contoso.com
   
   # Define Downstream Local SBC (Internal Site SBC)
   New-CsOnlinePSTNGateway -Fqdn sbc-site-london.internal.contoso.com `
     -SipSignalingPort 5060 `
     -MaxConcurrentSessions 50 `
     -Enabled $true `
     -MediaBypass $true `
     -BypassMode "Always" `
     -PstnSignalingDecoupled $true `
     -ProxySbc sbc-central.contoso.com

4. section #4

   Call Flow Orchestration and Proprietary SIP Headers

   Custom Headers for Routing

   During LMO call setup, the Teams SIP Proxy inserts custom SIP headers into the INVITE message to direct the Proxy SBC on how to handle the media path. The most critical header is X-Comp-Path (Computation Path), which contains the internal IP and port of the target Downstream SBC.

   Outbound Call Flow (Teams to PSTN)

   1. The internal Teams client initiates an outbound call.
   2. Teams Infrastructure evaluates user subnet and attached SBC site parameters.
   3. Teams SIP Proxy sends a SIP INVITE to the Proxy SBC over the Internet.
   4. The INVITE contains the X-Comp-Path header specifying the Downstream SBC endpoint.
   5. The Proxy SBC strip/translates headers and forwards the SIP INVITE internally to the Downstream SBC.
   6. Media (SRTP) flows directly between the internal Teams Client IP and the Downstream SBC IP.

   SDP Candidate Exchange

   The SDP payload exchanged during early media setup contains candidate internal IPs. If the client is detected as external, candidate rewriting forces the media stream through the Central SBC's public interface.

   httpcopy

   INVITE sip:+14155550199@sbc-central.contoso.com:5061;transport=tls SIP/2.0
   Via: SIP/2.0/TLS sip-proxy.pstnhub.microsoft.com:5061;branch=z9hG4bK...
   From: <sip:user@contoso.com>;tag=a1b2c3d4
   To: <sip:+14155550199@sbc-central.contoso.com>
   Call-ID: c0a80101-3b2a-4a8f-891d-9e1234567890
   CSeq: 1 INVITE
   X-Comp-Path: sbc-site-london.internal.contoso.com:5060
   Contact: <sip:sip-proxy.pstnhub.microsoft.com:5061;transport=tls>
   Content-Type: application/sdp
   
   v=0
   o=user 123456 789012 IN IP4 10.100.20.45
   s=Teams Call
   c=IN IP4 10.100.20.45
   t=0 0
   m=audio 50002 RTP/SAVPF 104 117 9
   a=rtpmap:104 SILK/8000
   a=rtpmap:117 opus/48000/2
   a=rtpmap:9 G722/8000

5. section #5

   Location-Based Routing (LBR) and Multi-Site Integration

   Preventing Toll Bypass

   In many jurisdictions (such as India or strict European telecom regions), legal compliance requires Location-Based Routing (LBR) to prevent toll bypass. LBR ensures that an enterprise user cannot bypass local PSTN toll charges by routing calls through an SBC located in a different geographical site.

   Combining LMO with LBR

   LMO works hand-in-hand with LBR by binding both media and PSTN breakout to the user's validated physical site. When an LBR-enabled user makes a call:

   • Teams verifies that the user's subnet matches the assigned PSTN Gateway site.
   • If the user is roaming at a different office, LMO routes the media locally to the visited site's SBC, while LBR restricts the call to local trunks.
   • If the user is off-premises, PSTN calls are blocked or forced to route via compliant central gateways based on policy.

   SBC Routing Matrix

   Deploying a robust routing matrix on the Proxy SBC ensures fallback paths are executed safely without violating LBR rule sets.

6. section #6

   Verification, Diagnostics, and Troubleshooting

   Validating Active Media Paths

   To verify that Local Media Optimization is functioning as designed, network engineers must validate both client-side diagnostics and SBC trace logs.

   Diagnostic Checks

   • SIP Message Traces: Inspect SBC logs for the presence of X-Comp-Path and P-D-Uri headers on proxy-to-downstream legs.
   • Call Quality Dashboard (CQD): Filter CQD reports by First Endpoint Media IP and Second Endpoint Media IP. LMO calls show direct private IPv4/IPv6 address communication between client and SBC.
   • Wireshark Capture: Verify that SRTP streams are flowing locally on the enterprise LAN without entering the WAN firewall interface destined for Microsoft 52.112.0.0/14 or 52.120.0.0/14 subnets.

   Common Failures

   • Subnet Mismatch: If the user's internal subnet is missing from the Teams Admin Center Network Topology, Teams defaults to external behavior and sends media to Microsoft Media Processors.
   • Firewall Isolation: Internal ACLs blocking UDP ports (default 50,000–59,999) between Teams clients and internal SBC interfaces cause silent call drop or one-way audio.

Further reading

• Microsoft Docs: Plan and configure Local Media Optimization for Direct Routing
• Microsoft Docs: Network settings for cloud voice features in Microsoft Teams
• Ribbon Communications: Direct Routing with Local Media Optimization Deployment Guide
• AudioCodes: Enterprise Configuration Note - Teams Direct Routing Local Media Optimization