Teams Direct Routing SBC Troubleshooting: SIP OPTIONS Failures, TLS Errors, Audio Problems, and Domain Deactivation

Microsoft Teams Direct Routing has a frustrating failure mode: Teams will rarely tell you why anything broke. The SBC’s Direct Routing trunk goes from “Active” to “Inactive” in the admin center, calls stop connecting, and the only operational signal you get is the absence of one. Microsoft’s side of the connection is a black box; everything diagnosable lives on yours.

That is what this guide is for. It works through the failure categories that come up in real production deployments (SIP OPTIONS heartbeat failures, TLS handshake errors, one-way audio and no-audio media problems, Direct Routing domain deactivation, NAT and firewall quirks specific to Teams DR), and gives you a triage order that resolves most incidents in under an hour. It assumes the SBC is already deployed and working at some point in the past, and that you have access to the SBC’s call trace, packet capture, and TLS profile configuration. If you are still in green-field setup, the Teams Direct Routing guide covers requirements and initial configuration; this article picks up where that one leaves off.

The Three-Layer Mental Model for Triage

Almost every Teams Direct Routing problem reduces to a failure in one of three layers, and the symptom you observe tells you which one to look at first. Building this mental model is the difference between thirty minutes of triage and three hours of guessing.

Signaling layer. The TLS handshake and SIP exchange between Microsoft’s SIP proxy and your SBC. Failures here produce trunks marked “Inactive,” sustained SIP OPTIONS errors, and calls that never reach the ringing state.

Media layer. The SRTP/RTP exchange between Teams (or the Teams Media Processor) and your SBC, then between the SBC and the carrier. Failures here produce calls that connect and answer normally but have no audio, one-way audio, or audio that cuts randomly after holding or resuming a call.

Application layer. Teams routing policies, voice routes, dial plans, user license assignment, and SBC routing rules. Failures here produce specific users or specific dial patterns that fail while everything else works.

The mistake most teams make is jumping into a packet capture before classifying which layer is at fault. The Quick Triage table below is built to do that classification fast, in two columns of decision-making before you open Wireshark.

Quick Triage: Symptom to Likely Cause

Map what you are observing to the most likely cause and the layer to investigate first. Most production incidents land in one of these rows.

Once the layer is identified, the corresponding section below has the diagnostic detail.

SIP OPTIONS Failures: The Most Common Outage

SIP OPTIONS failure is the single most common cause of a Teams DR outage that affects the whole system rather than a specific user call. Understanding what OPTIONS does, and exactly how Teams reacts when it stops working, gets you to the root cause faster than a packet capture.

It is a coordinated exchange on both sides: Microsoft sends OPTIONS to your SBC’s FQDN on TLS port 5061, expects a 200 OK within a few seconds, and repeats roughly every minute. Your SBC does the same in the reverse direction, sending OPTIONS to Microsoft’s regional SIP proxy and expecting a 200 OK back. Both directions must succeed continuously for Teams to consider the trunk healthy. If either direction fails consistently for several minutes, Teams flips the FQDN to “Inactive” and stops routing calls to or from that SBC.

OPTIONS fails because of TLS or DNS resolution failure, not SIP. The most frequent root cause of OPTIONS failure is not the OPTIONS request itself but the TLS handshake that has to succeed before any SIP request can be sent. If TLS fails, no OPTIONS request is ever exchanged, the SBC sees nothing, and Microsoft sees a complete absence of response. The TLS Handshake section below covers those root causes in detail.

OPTIONS fails because the SBC stopped sending or DNS resolution failed. The reverse direction (SBC to Microsoft) breaks if the outbound NAP toward Microsoft is misconfigured, if its TLS profile points at the wrong certificate, or if a routing rule blocks SIP-method OPTIONS on the outbound path. The signal in the SBC log is “no response” or “timeout” against Microsoft’s SIP proxy address, with no corresponding inbound 200 OK.

The 200 OK that looks fine but is not. An SBC can answer Microsoft’s OPTIONS with a 200 OK that contains Contact or Via headers Teams does not accept. Teams treats the response as malformed and may still mark the FQDN “Inactive” despite the apparent success. If the SBC log shows the OPTIONS being received and a 200 OK being sent, but the trunk is still “Inactive,” capture the full 200 OK in a packet trace and inspect every header. The Contact header should refer to the SBC’s FQDN, not its IP, and the Via header chain must be valid.

How Teams decides to deactivate. Microsoft does not publish exact thresholds, but in practice sustained OPTIONS failure (several consecutive minutes of failure in either direction) is sufficient to flip the trunk to “Inactive.” Recovery is not always immediate when the cause is fixed: Teams typically waits for sustained success before flipping back to “Active,” which can take five to fifteen minutes after the actual fix is in place. Do not assume your fix did not work just because the admin center is slow to refresh.

TLS Handshake Failures

TLS failures are the single most common root cause of a Direct Routing outage, and they have a small set of well-understood triggers. The table below summarizes them, with the log signal you can use to confirm each one and the fix.

Two of these triggers deserve a closer look. The Microsoft CA root update that took effect through 2026 caused a wave of “Unknown CA” failures across Direct Routing deployments because the SBC trust store did not contain the new DigiCert and Microsoft 2017 roots that Microsoft began presenting in their server certificates. If your SBC is on the older trust configuration and your trunk has been intermittent or dead since early 2026, that is the most likely cause and the resolution is to import the seven required root CAs into the trust store.

The other trigger to watch for is FQDN mismatch after a certificate renewal. Renewals sometimes drop a Subject Alternative Name (SAN) entry, especially in multi-tenant deployments where the SBC presents a wildcard certificate covering several subdomains. After every certificate renewal, run a TLS test against the SBC’s FQDN on port 5061 and confirm that the served certificate includes every FQDN registered for that SBC in Teams. The SBC TLS and SRTP configuration guide covers the full configuration patterns; this article focuses on what breaks them.

One-Way Audio and No-Audio Problems

When signaling works (calls connect, the called party’s phone rings, both sides answer) but audio is missing in one or both directions, the problem is in the media path. The hard part of media triage is that there are several distinct causes that all produce the same headline symptom, and only a packet capture or per-call MOS report tells them apart.

SRTP crypto context mismatch. Both ends agree on SRTP in the SDP, but the crypto key, cipher suite, or authentication tag length does not match. The Teams side requires AES-CM with HMAC-SHA1; if the carrier-side SDP offers a different cipher or omits the crypto attribute, the SBC negotiates inconsistent contexts on each leg and must perform the SRTP re-encryption itself, at a performance and latency cost. The fix is to enforce the AES-CM cipher list on both NAP profiles and confirm the SBC is performing the crypto rewrite between legs rather than passing the SDP through unmodified. The SRTP overview covers the cipher options in detail.

Changing SRTP crypto key along SDP exchanges. Microsoft Teams requires the SRTP crypto key to stay the same for the whole call length. No SRTP key renegotiation must happen; otherwise the audio can be cut or misdecrypted, and the call could even be dropped by Teams.

SBC media path never opens to one side. If the SBC has multiple network interfaces (a Teams-facing public interface and a carrier-facing private one), media routing must be explicitly bound to the right interface per NAP. Misconfiguration produces a half-open RTP path: the SBC sends media to one side and the return packets go to a stale interface. The signal is “no RTP received” on one leg in the call trace, with the other leg showing normal packet counts.

NAT translation breaks the inbound RTP port. When the SBC sits behind a NAT, the public address advertised in SDP must match the address the firewall actually maps. A common failure mode is that the SBC’s media is bound to its private address, the SDP advertises that address, and the far end then tries to send RTP to an unroutable destination. The fix is to set the SBC’s external media address explicitly on the Teams-facing NAP and confirm the firewall has a stable port mapping for the media range.

Codec offer/answer mismatch. Teams DR requires SILK, OPUS, or G.711 on the Teams side. If the carrier side offers AMR, GSM, or iLBC and the SBC has no hardware transcoder, the SBC negotiates G.711 on the Teams side and fails to deliver any media on the carrier side. The signal is “no compatible codec” or a 488 Not Acceptable Here on one leg. Either align the codec list on the carrier trunk or add a transcoder.

Media bypass enabled without firewall preparation. Media bypass changes the media path: instead of media flowing through Microsoft’s regional Media Processor, it flows directly between the Teams client and the SBC. The SBC firewall must now accept media from the full Microsoft media IP range (not just the SIP proxy range), and on the public internet rather than within Microsoft’s controlled network. Bypass that worked in lab often breaks in production because that firewall change was never made.

Audio cuts at a clean interval. Audio that cuts at the same interval is almost always a SIP session timer (RFC 4028) problem rather than a media problem. One side is not refreshing the session via re-INVITE or UPDATE, the timer expires, and the call is torn down. The session timer is the messenger rather than the root cause, which is almost always an interoperability problem in SRTP during the SDP negotiation that affects the rollover sequence of the RTP packets. The troubleshooting step is still to configure the SBC to refresh the session on the side that is not doing it.

Direct Routing Domain Marked “Inactive”

The “Inactive” state in Teams Admin Center is the single visible operational signal Microsoft gives you, and it is downstream of whatever failure caused it. Treat “Inactive” as a symptom, not a diagnosis.

The state is shown under Voice → Direct Routing → SBCs in Teams Admin Center, per SBC FQDN. The page shows the SBC’s current health and the time of the last successful SIP OPTIONS exchange in each direction. When the FQDN is “Inactive,” Teams stops routing new outbound calls to that SBC and rejects inbound INVITEs from it. Existing in-progress calls usually continue until natural termination.

The recovery sequence is consistent across most causes:

1. Confirm the SBC FQDN resolves publicly and the SBC is reachable on TCP/TLS 5061 from the public internet.
2. Confirm DNS resolution of the SBC.
3. Confirm the SBC certificate is not expired and includes the registered FQDN in its SAN.
4. Confirm the SBC trust store includes the current Microsoft root CAs (DigiCert Global Root G2 chain plus Microsoft 2017 roots, as required by the 2026 CA root update).
5. Inspect the SBC’s call trace for incoming OPTIONS and outgoing OPTIONS. Confirm both directions are present and returning 200 OK.
6. If both directions look healthy at the SBC and the trunk is still “Inactive,” capture a packet trace of the 200 OK response and inspect every header. Malformed Contact or Via headers are the silent killer of an otherwise valid response.

If the FQDN never went “Active” in the first place (a new SBC being added), the most likely root cause is FQDN mismatch between the certificate SAN and the value registered in Teams, or DNS not yet propagated for the FQDN. Both produce “Inactive” indefinitely with no recovery; there is no failure to recover from because the trust path never established.

NAT and Firewall: Teams DR-Specific Quirks

Generic SIP firewalling rules are not enough for Teams Direct Routing. Microsoft uses a specific set of signaling addresses, the media address range is much larger than most teams expect, and the firewall feature most likely to interfere (SIP ALG) is enabled by default on many enterprise firewalls. Three things break Teams DR more than any others.

SIP ALG must be disabled. SIP Application Layer Gateways rewrite SIP headers and SDP addresses in transit, which is almost never compatible with mTLS (the firewall cannot see inside the encrypted stream to rewrite it) and never compatible with the predictable SDP behaviour Teams expects. If the firewall on the SBC’s public interface has SIP ALG enabled, Teams DR will work intermittently or not at all, and the failure mode looks like a media problem or a SIP header issue. Disable SIP ALG on the firewall, full stop. The SBC security overview covers why SIP-aware enforcement belongs in the SBC, not the firewall.

Microsoft’s signaling address range must be reachable. Teams DR signaling comes from a documented Microsoft IP range (the SIP proxy FQDNs sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com, and sip3.pstnhub.microsoft.com resolve into that range). The firewall must allow inbound TLS on 5061 from those addresses to your SBC’s FQDN. Microsoft updates this range periodically; if your firewall is on a static allowlist, you will see intermittent outages when Microsoft expands the range. Either use FQDN-based allow rules or subscribe to Microsoft’s URLs and IP address ranges feed.

Media address range is larger than people expect. The Teams Media Processor uses one address range; media bypass uses another (the Teams client’s address, which is anywhere on the public internet). If your SBC firewall opens the Media Processor range only, media bypass will fail. If you want bypass, the SBC’s media port range must be accessible from any source IP, with the SBC’s SIP-aware filtering doing the per-call validation rather than the firewall.

One more quirk that comes up repeatedly: asymmetric NAT on a multi-homed SBC. If the SBC has separate public and private interfaces and the media bind is wrong, RTP egresses one interface and the return packets arrive on the other. The SBC drops them because the source does not match the established session. Lock the media bind explicitly to the right interface on the Teams-facing NAP.

Reading SIP Traces for Teams DR

Once the layer is identified and the obvious causes are eliminated, the diagnostic tool is the SIP trace. The two ProSBC features used most for Teams DR triage are the per-NAP call trace (which records SIP signaling at the trunk-group level) and live Wireshark capture (which gives full packet-level visibility into the SIP messaging, DNS resolution, and media). Both run on the SBC without external probes.

There is a short list of things to inspect first in any Teams DR trace.

The OPTIONS exchange. Confirm OPTIONS is being received from Microsoft and returned with a 200 OK. Confirm OPTIONS is being sent from the SBC to Microsoft and a 200 OK is coming back. If either direction is missing, the trust relationship is broken and the trunk will be “Inactive” regardless of what call traffic looks like.

The TLS handshake. If you have packet-level capture, the TLS handshake tells you immediately whether the issue is certificate validation, cipher negotiation, or version mismatch. A handshake that completes but is immediately followed by a TLS alert from Microsoft means the certificate passed but something inside the SIP exchange was unacceptable.

The 200 OK headers. Inspect the Contact and Via headers on the OPTIONS 200 OK. Contact should be your SBC’s FQDN over the configured transport. Via should reflect the SBC, not a downstream system.

The SDP on call setup. For audio-failure cases, the SDP in both the INVITE and the 200 OK answer tells you the codec list each side offered, the SRTP crypto attribute, and the media address. Compare the address advertised against the address from which media is actually arriving. VoIP monitoring best practices covers what to track continuously so this kind of triage starts from a richer baseline.

Header-rewrite confirmation. Teams has a specific SIP dialect, and a working Teams DR deployment almost always relies on SIP header manipulation at the SBC to normalize between Teams and the carrier. If headers are not being rewritten, the trace will show Teams’ headers passing through unchanged to the carrier (or vice versa), and one side will reject the call. Confirm the rewrite rules on the relevant NAPs are loaded.

The Triage Playbook

When a Teams DR incident lands and you have nothing but “calls aren’t working,” the steps below resolve most cases in under an hour. They are ordered by likelihood, not by severity.

1. Open Teams Admin Center and check the SBC’s FQDN state. If “Inactive,” the problem is signaling and you go to step 2. If “Active,” the problem is media or application and you skip to step 5.
2. Confirm the SBC certificate is not expired and the registered FQDN matches a Subject Alternative Name on the served certificate. Most “Inactive” incidents in the wild are certificate problems.
3. Confirm the SBC trust store contains the current Microsoft root CAs (the 2026 CA root update is the most recent change to push). Missing roots produce “Unknown CA” handshake failures and immediate “Inactive.”
4. Inspect the SBC’s call trace for incoming and outgoing OPTIONS. If outgoing OPTIONS is missing, the outbound NAP toward Microsoft is misconfigured. If incoming OPTIONS arrives but the 200 OK has a malformed Contact or Via, the response is the problem.
5. If the trunk is “Active” but inbound calls do not reach the user, the cause is the Teams application layer (voice routing policy, voice route, dial plan, license assignment, user enabled-for-Teams-Phone flag). The SBC is healthy; the Teams configuration is not.
6. If audio is missing on calls that connect, capture an RTP-level trace and confirm media is arriving at the SBC from both directions. Missing media on one side is a media path or NAT problem; present media but no audio is an SRTP crypto context problem.
7. If audio cuts at clean time intervals, the cause is typically RFC 4028 session timers, not the media path. Configure the SBC to refresh the session.
8. If problems are new and appeared without a catalyst, check for certificate expiry inside the next 30 days, NAT timeout shorter than the OPTIONS interval, and recent changes to the firewall or carrier configuration.

If you reach the end of the playbook and the issue is not resolved, the next step is a packet capture filtered to Microsoft’s SIP proxy address and the relevant media addresses. At that point the data needed for support escalation, whether to TelcoBridges, your carrier, or Microsoft, is in hand.

Frequently Asked Questions