What it does

Pairing registers your Session Border Controller with the Direct Routing SIP proxy as an online PSTN gateway, identified by its FQDN. Once paired and answering SIP OPTIONS, the SBC can carry Teams calls to and from your own carrier trunks.

Key facts

• Pairing is New-CsOnlinePSTNGateway -Fqdn <SBC FQDN> -SipSignalingPort <port> -MaxConcurrentSessions <n> -Enabled $true. Get-, Set- and Remove-CsOnlinePSTNGateway handle the rest. In GCC High and DoD the admin center option isn't there — PowerShell only.
• The FQDN's domain must be a verified, Managed-authentication domain in the tenant, with at least one user on that domain holding an E3 or E5 licence. *.onmicrosoft.com isn't supported. Subdomains work if the subdomain itself is registered. Maximum FQDN length is 63 characters.
• One FQDN maps to one IP. Multiple IPs behind the same FQDN isn't supported.
• The SBC certificate must come from a CA in the Microsoft Trusted Root Program, carry the SBC FQDN in the CN or SAN, and include the Server Authentication EKU. Wildcards are supported (RFC 2818). If mutual TLS is on, install the Microsoft trusted root certificates on the SBC.
• TLS 1.2 minimum, with the ECDHE-RSA AES-GCM/CBC cipher suites listed on Learn.
• SBC points at sip.pstnhub.microsoft.com, then sip2 and sip3 as secondary and tertiary. Signalling from the SBC goes to TCP 5061; the proxy connects back to whatever SipSignalingPort you configured.
• Signalling and media come from 52.112.0.0/14 and 52.120.0.0/14. Media uses UDP 3478–3481 and 49152–53247 in both directions — allow at least two SBC media ports per concurrent call.
• SendSipOptions defaults to True. Expect OPTIONS from the SBC to get 200 OK, and the SBC must answer the proxy's OPTIONS with 200 OK. Microsoft monitors at one transaction every 60–180 seconds per trunk.
• Contact header (OPTIONS included) must carry the SBC FQDN, never an IP — an IP gets a 403. Request-URI should be E.164 with the +.
• Defaults worth knowing: ForwardPAI False, ForwardCallHistory False, FailoverTimeSeconds 10, FailoverResponseCodes 408, 503, 504, IPAddressVersion IPv4. MaxConcurrentSessions (1–100,000) only drives alerting at 90%, it doesn't throttle.
• Only SBCs on the certified list are supported, and support goes through the SBC vendor first.

When to use / skip

You do this for every Direct Routing deployment — there's no Direct Routing without a paired SBC, whether it's your own appliance, a cloud-hosted SBC in Azure, or a carrier's managed SBC that's paired into your tenant under your domain. If the client wants a carrier to own the SBC entirely and doesn't need Direct Routing's flexibility, that's Operator Connect territory and the pairing problem goes away.

Where you do have a choice is how many trunks you pair and on what FQDNs. Pairing two FQDNs on the same box (different TLS ports, one SAN cert) is the standard way to pilot media bypass or new translation rules on a subset of users without touching the production trunk.

Configuration decisions

• FQDN naming and which domain it lives on — a dedicated subdomain (sbc.voice.contoso.com) is cleaner but has to be registered and have a licensed user on it.
• Certificate: per-SBC SAN vs wildcard, which public CA, and who owns renewal.
• SipSignalingPort — 5061 is conventional; non-standard ports are fine and useful when you need several trunks on one SBC.
• Whether to enable ForwardPAI and ForwardCallHistory — usually driven by carrier requirements for anonymous calls and forwarded-call CLI.
• FailoverResponseCodes and FailoverTimeSeconds — the defaults suit most, but some carriers respond with codes you'll want to add.
• Single region vs geo-redundant SBC pairs, and whether the carrier trunk is shared or per SBC.

Gotchas

• The domain-plus-licensed-user check catches people every time. Create the SBC subdomain, verify it, put a licensed user on it (a service account works), then pair. Otherwise you get "Can not use the domain as it was not configured for this tenant".
• Pairing success means nothing until OPTIONS flow both ways. Enabled: True on Get-CsOnlinePSTNGateway is config, not health — check the SBC health view in the admin center.
• An IP in the Contact or Record-Route header is the classic half-working trunk: OPTIONS fail or calls 403.
• Certificate renewal from a different CA, or an intermediate the SBC doesn't present, quietly kills TLS. Watch the root CA changes Microsoft announces — they've moved roots before and SBCs without the new trusted roots fail on mutual TLS.
• Moving an SBC off ACS Direct Routing (retiring 30 September 2028)? The same FQDN can't be paired with ACS and Teams at once. Either cut over and accept the propagation gap, or pair a second FQDN with a certificate covering both. ACS and Teams media ranges differ too, so redo the firewall rules. See ACS retirement: what lands on Teams voice.
• Media bypass isn't supported on IPv6, and mixed IPv4/IPv6 on one gateway isn't supported.
• AMR-WB is available only on non-bypass calls.

Consultant notes

• Before cut-over, run the Direct Routing diagnostic at aka.ms/TeamsDirectRoutingDiag (not available in GCC, 21Vianet or Germany clouds) and capture a clean OPTIONS trace for the handover pack.
• Firewall rules should be scoped to the Microsoft ranges, not "any" on 5061. Keep the ranges in a named object so the next Microsoft change is one edit.
• Put cert expiry in the client's monitoring, not just a calendar reminder. An expired SBC cert is a total outage.
• If the carrier operates the SBC, get the cert ownership and renewal process in the contract.

---

Recheck the trusted root CA list and the cipher suite requirements before every SBC certificate renewal