LearnMicrosoft Teams › 5 · Calling & Enterprise Voice

Direct Routing: the SBC contract

Direct Routing is a standing contract between Microsoft's SIP proxy and your SBC, renewed every minute by OPTIONS pings and enforced by TLS certificates. Read the contract's clauses and every DR outage becomes diagnosable in minutes.

The contract's clauses

  1. Identity: your SBC presents a certificate whose SAN matches its FQDN (sbc1.contoso.com), chained to a CA Microsoft trusts. The FQDN's domain must be a verified domain in your tenant — that mapping is how Microsoft knows which tenant a trunk belongs to. Wildcards allowed; the tenant's default .onmicrosoft.com domain is NOT usable for pairing.
  2. Reachability: SIP over TLS to sip.pstnhub.microsoft.com (with numbered fallbacks sip2/sip3), your chosen signalling port. Media to/from Microsoft's relay ranges — or directly to clients with bypass.
  3. The heartbeat: Microsoft and the SBC exchange SIP OPTIONS continuously. Miss enough replies and the trunk is quietly removed from routing rotation — calls fail over to other routes/SBCs in the voice routing policy. This is both the failover mechanism AND your earliest outage signal: OPTIONS died before users noticed.
  4. Routing admission: the SBC only carries calls for users whose OnlineVoiceRoutingPolicy chain (usage → route → this SBC) says so. A perfect trunk with a broken policy chain = "call failed" with a healthy SBC.

Media bypass vs local media optimization

  • No bypass: client SRTP → Microsoft relay → SBC. Simple, always works, adds a hairpin.
  • Media bypass: client SRTP → SBC's public IP directly. Shortest path; requires clients to reach the SBC externally.
  • Local Media Optimization: the refinement for enterprises — clients on the corporate network send media to the SBC's INTERNAL interface, branch scenarios keep media in-country; configured with network sites + trusted IPs. Powerful, and the config-error capital of Direct Routing (wrong site mapping = one-way audio precisely for on-net users).

Failure signatures

Symptom Clause violated
Trunk shows unhealthy in TAC, calls reroute Heartbeat: OPTIONS unanswered (SBC down, TLS expired, path blocked)
Everything dies on a certificate renewal date Identity: new cert missing SAN/chain — the classic self-inflicted DR outage
Calls fail instantly for SOME users Admission: their routing policy has no usable route
Ring then dead air ~30s ACK/media path broken — NAT/SIP-ALG at the edge, or bypass reachability
On-net users one-way audio, remote users fine LMO site/trusted-IP misconfiguration

What to watch (proofs)

  • The heartbeat, from Microsoft's side: TAC > Voice > Direct Routing per-SBC health — OPTIONS state, TLS state, recent failure codes; this page is the contract's scoreboard.
  • The heartbeat, from your side: SBC SIP traces — OPTIONS in/out with 200s; the moment replies stop is your outage's true start time.
  • Certificate runway: the SBC cert's notAfter date — put it in your monitoring with 30-day alerting; serv365's app-credential pattern applies to SBCs in spirit.
  • Per-call truth: SBC CDRs + Teams PSTN usage report joined on correlation IDs — where a call died (Teams side vs SBC vs carrier) stops being a debate.
  • Config drift: Get-CsOnlinePSTNGateway | fl — SignalingPort, FailoverTimeSeconds, MediaBypass, and friends; snapshot and diff (serv365 scans what app-only auth can see; SBC-side config deserves the same discipline in your SBC's own backup).

The wire

  • Pairing: SBC FQDN (verified domain) + TLS cert with matching SAN -> sip.pstnhub.microsoft.com
  • Heartbeat: continuous SIP OPTIONS both ways; missed replies = silent removal from rotation
  • Bypass: client SRTP direct to SBC public IP; LMO: internal interface for on-net clients

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.