Architecture

Microsoft Teams Direct Routing

Direct Routing is Microsoft's BYOC mechanism for Teams Phone — it lets you bring your own SIP carrier instead of buying Microsoft's bundled Calling Plans. You connect Teams to your carrier through a certified Session Border Controller (SBC) that speaks SIP-TLS to Microsoft on one side and to your carrier on the other. In practice, the SBC is the single most-finicky piece of any Teams deployment.

Why Direct Routing exists

Microsoft sells two ways to put PSTN on Teams:

• Calling Plans: Microsoft is the carrier. Bundled per-user fee. Limited country coverage (~30 countries). Microsoft owns the numbers.
• Direct Routing: you bring your own carrier (DIDHub or any other), Microsoft just runs the call control. You own the numbers and pay wholesale telecom rates. Available in any country your carrier serves — 130+ for DIDHub.

For anyone outside Microsoft's Calling Plan footprint, anyone with existing carrier contracts, or anyone who wants real STIR/SHAKEN attestation control, Direct Routing is the only option.

The architecture

End-to-end, an inbound call to a Teams Phone user looks like:

Caller (PSTN) → Carrier (DIDHub) → SBC → Microsoft Teams (sip.pstnhub.microsoft.com)
                                       ↑
                                       SIP-TLS only, port 5061, mTLS
                                       Strict SIP header validation
                                       FQDN must match SBC certificate

SBC-as-a-Service vs on-prem SBC

	On-prem SBC (Ribbon, AudioCodes, Oracle)	SBC-as-a-Service (DIDHub managed)
CapEx	$5K-$50K hardware	$0
Setup time	2-6 weeks (procurement + cert + tuning)	~5 minutes
Public IP / FQDN	You buy IP, you manage DNS	We assign <your-name>.teams.didhub.io
TLS cert	You buy + renew yearly	We auto-renew (Let's Encrypt + carrier-grade)
Microsoft cert validation	Your problem	We test against MS hubs daily
SIP header tuning	You diagnose 488s	Pre-tuned, regression-tested
Capacity	Box-limited (~250-1000 concurrent)	Elastic, per-tenant
Multi-region	Buy a box per region	3 PoPs out of the box

SBC-as-a-Service is overwhelmingly the right choice unless you have specific compliance needs (data residency in your own DC, PCI scope reduction, etc.) that force on-prem.

Why your SBC needs a unique customer FQDN

Microsoft requires a unique fully-qualified domain name per tenant per SBC. The FQDN must:

• Be a public DNS hostname (resolvable from Microsoft's hubs).
• Match the Common Name (CN) or a Subject Alternative Name (SAN) on the SBC's TLS certificate.
• Be added to your tenant via New-CsOnlinePSTNGateway -Fqdn <fqdn>.
• Be unique per tenant — you cannot share the same FQDN across multiple Microsoft tenants on the same SBC.

This is why DIDHub assigns each customer their own subdomain like acme-corp.teams.didhub.io rather than a shared sbc.didhub.io. With a shared FQDN you couldn't onboard more than one tenant. Customers who own a domain can also bring their own (e.g. sbc.acme-corp.com) and we will issue the cert — but the default per-tenant subdomain is faster and works just as well.

# In Microsoft Teams admin PowerShell
New-CsOnlinePSTNGateway -Fqdn "acme-corp.teams.didhub.io" \
  -SipSignalingPort 5061 \
  -Enabled $true \
  -MediaBypass $false \
  -ForwardCallHistory $true \
  -ForwardPai $true

Microsoft Teams hubs (regional ingress)

Microsoft does not expose a single SIP destination. Direct Routing traffic is anycast to three regional hubs — whichever responds fastest. Your SBC must accept SIP-TLS from all three:

Hub	FQDN	Region served
Primary (NOAM)	sip.pstnhub.microsoft.com	Global anycast (resolves to nearest)
Secondary	sip2.pstnhub.microsoft.com	EMEA
Tertiary	sip3.pstnhub.microsoft.com	APAC

The three FQDNs share a small set of public IP ranges (52.x and 13.x). Microsoft publishes the IP/port reference; firewall rules must allow all three on TCP/5061. Do not pin your SBC to a single hub — calls will fail when Microsoft fails over.

SIP OPTIONS probing (the 'is-the-SBC-alive' check)

Microsoft sends SIP OPTIONS to your SBC every ~60 seconds from each of the three hubs. If your SBC fails to respond with 200 OK for ~3 minutes, Microsoft marks the gateway Inactive in Get-CsOnlinePSTNGateway output and stops routing calls to it.

• Probe source: Microsoft hubs → your SBC FQDN on TCP/5061 (TLS).
• Probe payload: bare OPTIONS with From: sip:keepalive@<hub> and a User-Agent: Microsoft.PSTNHub.SIPProxy.
• Required reply: 200 OK with Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, ... and a Contact header pointing back to your SBC FQDN.

If OPTIONS requests aren't answered (firewall drop, TLS handshake fail, SBC busy), Microsoft logs SBCNotResponding and customers see one-way call failures with no obvious cause. Always log inbound OPTIONS and confirm 200 OK.

TLS — Microsoft is strict

Microsoft validates the SBC's TLS certificate aggressively. Common rejection reasons:

• Self-signed cert: rejected. Must be from a public CA.
• SHA-1 cert: rejected. SHA-256 minimum.
• FQDN not in CN/SAN: rejected with TLS handshake failure.
• Wildcard cert: works only if the wildcard is at the same level as the SBC FQDN. *.didhub.io does NOT match acme.teams.didhub.io; you need *.teams.didhub.io.
• Missing intermediate CA: rejected. Bundle the full chain in the SBC.
• TLS 1.0 / 1.1: deprecated by Microsoft as of 2022. TLS 1.2 minimum, 1.3 preferred.
• Cert expiry: must be valid for at least 30 days into the future or Microsoft sometimes refuses to add the gateway.

DIDHub managed-SBC certs are issued from a public CA, auto-renew at 60 days, and are validated against the Microsoft cipher suite list daily.

SIP headers Microsoft is picky about

This is where most on-prem SBC deployments lose weeks. Microsoft enforces strict SIP semantics on every INVITE in and out:

Header / behavior	What Microsoft requires
Contact: on inbound INVITE	Must contain the SBC FQDN, not its IP. Contact: <sip:[email protected]:5061;transport=tls>
From: domain	Must be a verified domain in the tenant or the SBC FQDN. Mismatch → 403 Forbidden.
To:	Request-URI and To header must reference E.164 with leading +. tel: URIs accepted.
P-Asserted-Identity	Required for caller-ID. Must be E.164. Without it, the call shows "Unknown".
Diversion / History-Info	If the call is forwarded, must include the original number. Used by Teams for "redirected from" UI.
Privacy: id	For anonymous calls, must use this. Don't blank P-Asserted-Identity.
Max-Forwards	Must be at least 70 inbound. Microsoft has been known to reject 60.
Re-INVITE handling	Microsoft sends re-INVITEs for hold/transfer. SBC must process them and not 488.
SDP a=label	Microsoft includes labels on each m-line. Don't strip them — some Microsoft components key off them.
Codec list	SILK, G.722, G.711 (PCMU/PCMA). Opus is increasingly accepted but not universal.
SRTP keying	SDES with AES_CM_128_HMAC_SHA1_80. DTLS-SRTP not supported on Direct Routing media.

Media bypass — the optional optimization

By default, RTP flows through the SBC. With Media Bypass, the Teams client sends RTP directly to the SBC, skipping Microsoft's media path. Lower latency, less Microsoft bandwidth.

• Requires a public-IP SBC (no NAT).
• SBC must support ICE-Lite + Microsoft's RTP-over-TURN extensions.
• Most useful when the Teams client and SBC are in the same region.

DIDHub managed SBC supports media bypass on request. Default is no-bypass (simpler troubleshooting). For high-volume tenants this typically improves p99 audio latency by 40-80ms.

Common failure modes

• SBCNotResponding in Get-CsOnlineSBCsHealth: OPTIONS probes failing. Check firewall on TCP/5061 from MS IP ranges; check TLS cert chain.
• 403 Forbidden on outbound: tenant FQDN not registered or assigned voice routing policy is wrong. Run Get-CsOnlineUser | fl OnlineVoiceRoutingPolicy.
• Inbound rings on Teams but call drops at answer: Microsoft sent a re-INVITE the SBC didn't ack within 32s. Check SBC re-INVITE handling.
• One-way audio outbound: SBC's Contact on 200 OK has private IP. Set external_signaling_address / use SBC public-IP NAT mode.
• Calls work for some users, fail for others: those users have no assigned OnlineVoiceRoutingPolicy. Grant policy.

Validation commands

# Show all PSTN gateways
Get-CsOnlinePSTNGateway

# Show real-time SBC health from Microsoft's side
Get-CsOnlineSBCsHealth

# Show effective voice routing policy on a user
Get-CsOnlineUser -Identity "[email protected]" | fl OnlineVoiceRoutingPolicy

# Test routing for a number without placing a real call
Test-CsOnlineE911Service -PhoneNumber "+15551234567"

References

• Microsoft — Plan Direct Routing
• Microsoft — Multi-tenant SBC FQDN requirements
• Microsoft — SIP OPTIONS in Direct Routing
• DIDHub tutorial — UK toll-free to Teams in 5 minutes

Related terms