Microsoft Teams Direct Routing: what an SBC has to get right
Short version: Direct Routing connects your own SBC to Microsoft's phone-system proxies so Teams users can make and take PSTN calls through it. Microsoft is strict about a short list of things on every SBC: a working TLS session with the right certificate, an answered OPTIONS keep-alive, the SBC's FQDN in Contact, SRTP towards Teams, and numbers in E.164. Nearly every Direct Routing fault is one of them, and each leaves a distinct mark in a capture.
The shape of the connection
The SBC sits between two worlds: a carrier or PBX on one side, and the Microsoft
signalling proxies (sip.pstnhub.microsoft.com, plus the
sip2 and sip3 names) on the other. Signalling to Microsoft is
SIP over TLS, port 5061, with certificates checked in both directions. Media is
SRTP. The SBC terminates all of that and talks plain RTP (or whatever the carrier
wants) on its other leg, which is why a Direct Routing capture is always a
back-to-back story: two legs that
must each be read on their own terms.
The checks, and how each one fails
| What Microsoft checks | How it fails | What a capture shows |
|---|---|---|
| TLS session to the SBC FQDN on 5061, with a certificate from a CA Microsoft trusts and the FQDN in the certificate | SBC is marked inactive; no calls either way | A handshake that stops after ClientHello, or ends in an alert such as bad_certificate or unknown_ca. An encrypted capture still shows the SNI and certificate names. |
| OPTIONS keep-alives answered with 200 | SBC is taken out of service | OPTIONS from the Microsoft proxy with no response, or a 4xx/5xx answer |
| The SBC FQDN (not an IP address) in Contact | Calls ring then drop; in-dialog requests refused | Contact: <sip:[email protected]:5061> on requests to Microsoft |
| SRTP using SDES, AES_CM_128_HMAC_SHA1_80 | 488 or a 400 straight from the Microsoft proxy; or no audio | Offer is RTP/AVP with no a=crypto, or crypto with a different suite |
| Numbers in E.164 | 404 from Microsoft; wrong user rung; unknown caller ID | Request-URI, To or From user part without a leading + |
| The SBC and voice routes defined in the tenant | 403 or 404 from Microsoft | The rejection itself, with nothing wrong on the wire before it |
Reading a Direct Routing capture
- Did TLS come up? If the capture is raw, look at the handshake first: SNI, the certificate's names and dates, and any alert. A certificate that does not cover the name asked for is rejected by Microsoft whatever else is right.
- Is the SBC answering OPTIONS? The Microsoft proxy polls it constantly; the pattern of answers tells you whether the SBC is in service.
- Compare the two legs. The Teams side must carry E.164 numbers, the SBC FQDN in Contact and an SRTP offer; the carrier side usually will not. Differences that the SBC is meant to fix are your configuration to-do list.
- Read the Microsoft response. A 403 is usually tenant definition or certificate name, a 404 is usually a number or voice route, a 488 is media security or codecs.
What hiccup does with it
hiccup recognises Direct Routing from the Microsoft proxy names, the PSTNHub User-Agent and the X-MS headers (or from the SNI and certificate names when the SIP is encrypted), says plainly that this is what it thinks you are trying to do, and then reports the checks above with fixes for the Teams side (the PowerShell cmdlets) and for AudioCodes and Oracle/Acme SBCs. The configuration blocks are drafts to check against your vendor's guide. Microsoft changes details such as signalling address ranges and trusted CAs over time, so confirm those against its current Direct Routing documentation.
hiccup reads Direct Routing traces, a decrypted SBC log or a raw 5061 capture, and explains what Microsoft is objecting to. Self-hosted, free for individual users.
upload a trace