# Troubleshooting Teams Direct Routing

Canonical: https://warmtransfer.net/knowledge/teams-direct-routing-troubleshooting

Last verified: 2026-09-25

Microsoft groups Direct Routing Session Border Controller (SBC) connectivity symptoms into four categories: SIP OPTIONS not received, TLS connection problems, the SBC not responding, and the SBC marked inactive in the Teams admin center[^24]. It attributes these issues primarily to TLS certificate faults, SBC misconfiguration for Direct Routing, or both[^24].

## Connectivity and the SIP OPTIONS Process

In the Direct Routing SIP OPTIONS exchange, the SBC initiates a TLS connection to the SIP proxy FQDN, such as sip.pstnhub.microsoft.com[^50]. If the SIP proxy considers the connection request invalid, it terminates the TLS connection and does not receive OPTIONS from the SBC[^50]. When the proxy recognizes the SBC FQDN, it responds to the SBC's OPTIONS with 200 OK across the established TLS connection[^49]. The proxy then transmits its own OPTIONS request to the FQDN found in the Contact header of the SBC's OPTIONS[^49]. Only after the SBC replies to that request with 200 OK is the SBC flagged as Active in the Teams admin center[^49]. In the hosted carrier model, only the hosted SBC should transmit SIP OPTIONS, while SBCs on a derived trunk inherit their status from the primary SBC[^39].

When an SBC receives no 200 OK to its OPTIONS despite valid TLS and certificates, Microsoft identifies several causes: the Record-Route or Contact FQDN does not match the FQDN configured in Teams, the Contact header specifies an IP address rather than an FQDN, the domain lacks full validation, or the SBC domain is not activated by adding a licensed user[^47]. If the SBC receives a 200 OK from the SIP proxy but does not receive the proxy's return OPTIONS, Microsoft recommends confirming that the Record-Route or Contact FQDN is accurate and resolves to the correct IP address, and verifying that firewall rules permit inbound traffic from all SIP proxy signaling IP addresses[^1].

Sending OPTIONS to static IP addresses rather than SIP proxy FQDNs can cause intermittent inactivity because those IPs can shift datacenters during maintenance or outages[^41]. Microsoft instructs administrators to direct OPTIONS exclusively to FQDNs and configure sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com, and sip3.pstnhub.microsoft.com[^41]. Intermittent inactivity also occurs when a root or intermediate certificate installed on the SBC does not belong to the SBC certificate's issuer chain; the Teams platform cannot validate the chain, drops the connection, and requires the installation of the proper intermediate and root certificates on the SBC[^40].

Activating an SBC domain for a tenant requires assigning at least 1 licensed user to the SBC's subdomain, and activation may require up to 24 hours after meeting all prerequisites[^36].

## TLS and Certificate Validation

If a TLS connection drops immediately and the SIP proxy receives no OPTIONS or 200 OK from the SBC, the SBC TLS version should be verified as TLS 1.2 or higher[^59]. Self-signed SBC certificates are not supported; certificates must originate from a trusted CA and contain at least 1 FQDN registered to a Microsoft 365 tenant[^55]. Wildcard certificates cover only a single subdomain level, meaning *.contoso.com validates sbc1.contoso.com but fails for customer10.sbc1.contoso.com[^60]. If the SBC FQDN fails to match the certificate Common Name (CN) or Subject Alternative Name (SAN), a replacement certificate is required[^60].

SBCs must trust all 7 root authorities used by Teams Direct Routing and Operator Connect client and server certificates: DigiCert Global Root CA, DigiCert Global Root G2, DigiCert Global Root G3, DigiCert TLS ECC P384 Root G5, DigiCert TLS RSA 4096 Root G5, Microsoft ECC Root CA 2017, and Microsoft RSA Root CA 2017[^57]. Baltimore CyberTrust Root was removed from Azure service endpoint CAs on October 8 2024[^17]. Production Direct Routing SIP endpoints adopted certificates from a new CA at the end of July 2026, and the validation test endpoint sip.g1.pstnhub.microsoft.com (port 5061, OPTIONS only) has been discontinued[^46]. Microsoft executed a phased validation test starting June 30 2026 at 09:00 UTC lasting 2 to 4 days, where SBCs failing outbound TLS or rejecting inbound connections demonstrated trust failures against the new CA[^19].

Regarding certificate extensions, Microsoft SIP endpoints currently accept SBC certificates missing the Client Authentication Extended Key Usage (EKU) and expect to maintain this tolerance for the foreseeable future[^21]. WarmTransfer's reading of the sources is that whether Microsoft will eventually require the Client Authentication EKU on SBC certificates is unsettled[^37].

After renewing an SBC certificate, existing TLS sessions established with the earlier certificate must be cleared, or the Teams admin center will continue showing certificate expiration alerts[^20]. Microsoft recommends rebooting the SBC during low-traffic periods or consulting the SBC vendor to terminate stale TLS sessions[^20]. If connections fail despite valid configurations, packet captures can confirm whether the SBC certificate or intermediate chain is missing from the SBC TLS Hello message[^38]. Intermediate network devices such as customer-managed firewalls or routers can also terminate the TLS connection[^45].

## Health Monitoring and Call Routing

The Direct Routing health dashboard is located under Voice > Direct Routing in the Teams admin center, where it tracks total SBCs, voice routes, and SBCs reporting issues such as inactivity, absent SIP OPTIONS, certificate expiration, low network effectiveness, or capacity limits[^27]. An SBC created via the PowerShell cmdlet `New-CsOnlinePSTNGateway` that has never connected displays as unhealthy with issues[^32]. The dashboard monitors certificate validity and issues a warning when an SBC certificate expires within 30 days[^26].

SIP OPTIONS statuses on the dashboard comprise three values: Active (OPTIONS arrive regularly), Warning, no SIP options (the SBC exists but has sent no OPTIONS to the service), and Warning, SIP Messages aren't configured (OPTIONS monitoring is disabled)[^34]. By default the SBC sends OPTIONS every minute, though this can vary by SBC vendor[^33]. Direct Routing treats an SBC as healthy for routing if it sent OPTIONS within the last three minutes, which is three one-minute intervals, before the call[^52]. If this threshold is missed, the SBC is demoted in routing priority; Direct Routing routes through alternate SBCs first, retrying the demoted SBC before generating an overall failure[^53]. Equal-priority healthy SBCs distribute calls via a Fisher-Yates shuffle[^53].

The dashboard calculates network effectiveness ratio as 100 x (Answered calls + User Busy + Ring no Answer + Terminal Reject Seizures) / Total Calls, where user rejections and calls sent to voicemail count as successful deliveries[^29]. Microsoft notes that NER metrics based on fewer than 100 calls may show low values while remaining normal[^30]. Average call duration serves as an indicator of call quality; Microsoft advises establishing an organizational baseline, noting that sudden drops to around 15 seconds often indicate user abandonment due to audio quality or reliability defects[^25].

In detailed per-SBC reporting, status Active indicates healthy traffic flow, whereas Inactive indicates no recent health checks or calls, though Microsoft provides no numeric threshold defining "recent"[^35]. The per-SBC view also reports network parameters—jitter, packet loss, and round-trip latency—measured between the Direct Routing interface and the SBC, which are comparable against Microsoft's Customer Edge to Microsoft Edge guidance[^31]. Concurrency graphs measure calls passing between Direct Routing and the SBC against the `-MaxConcurrentSessions` parameter set in `New-CsOnlinePSTNGateway` or `Set-CsOnlinePSTNGateway`, which will not reflect true SBC load if the SBC routes traffic for external PBXs[^28].

## Diagnostic Tools and Error Codes

Call Analytics only captures data once calls reach internal Direct Routing components; failures occurring during SBC pairing or due to invalid trunk FQDNs must be analyzed directly in SBC logs[^18]. Teams Administrator and Teams Telephony Administrator accounts can view the Direct Routing SIP ladder under Analytics & reports > Usage reports > PSTN usage report > Direct Routing[^42]. The SIP call flow interface displays records up to 30 days old, and new call data requires up to 30 minutes to appear[^43]. Automated test suites can also be configured under Voice > Direct Routing > SBC test cases to run Outbound-Inbound, Simultaneous ring, Media escalation, and Consultative transfer tests against an SBC using test credentials[^54].

Direct Routing failure records pair a 3-digit SIP response code (CallEndReason) describing the event with a Microsoft response code (CallEndSubReason, typically 6 digits) detailing the root cause[^23]. Microsoft response codes prefixed with 560 indicate that the SBC issued the final SIP rejection, ending in the corresponding 3-digit SIP code (for example, 560403 denotes a 403 response from the SBC)[^22]. All other Microsoft response codes indicate generation by Microsoft internal services[^22].

| Sub-Code | Meaning and Diagnostic Focus |
|---|---|
| 510532 | Direct Routing found no trunk configuration for the call with SIP 403 ('No trunk config was found' or 'RuntimeApi trunk config not found for customer'); verify SBC FQDN, gateway configuration, and tenant Contact registration[^2]. |
| 510560 | User lacks Enterprise Voice enablement; verify Phone System licensing and Direct Routing enablement[^7]. |
| 510562 | User restricted from outbound PSTN calling; verify Phone System licensing and Direct Routing enablement[^7]. |
| 510563 | User profile restricted to domestic calls only[^7]. |
| 510559 | Dialed number did not match voice route patterns with SIP 403 ('Get Outbound routing - No viable path'), or routing blocked by policy[^3]. |
| 510534 | Calling number blocked by inbound call blocking policy[^5]. |
| 510546 | No trunk found due to Location-Based Routing criteria (such as PreventTollBypass)[^5]. |
| 10500 | Call blocked due to Location-Based Routing site-state rules[^5]. |
| 10553 | Failed INVITE to an assigned compliance recording application[^5]. |
| 10199 | Private calling feature disabled for the receiving user[^5]. |
| 500001 | SBC failover timer expired with SIP 408 ('Gateway (SBC) failover timer expired') (default 10 seconds; can be adjusted to 20 seconds for long setup paths)[^8]. |
| 1106 | Callee answered but SBC failed to acknowledge Microsoft 200 OK in allotted time with SIP 408; inspect SBC SIP stack and transport[^9]. |
| 531000 | Incompatible media codecs (CannotSupportAnyMedia) or missing SRTP support (SrtpEncryptionRequired) with SIP 488[^12]. |
| 531027 | Media bypass failure due to missing ICE candidates in SBC SDP with SIP 488 ('There are no ICE candidates in the SDP'); configure ICE Lite on the SBC[^11]. |
| 531052 | SBC offered unsupported blackhole media using IP address 0.0.0.0 in SDP with SIP 488 ('Cannot negotiate a new modality with blackhole media')[^10]. |
| 540998 | Expected maintenance state (SIP 503 ('Service state: Inactive/DrainingTransactions')); ensure SBC refreshes DNS at least every 15 minutes[^13]. |
| 560503 | SBC generated 503 due to maintenance or overload; review SBC session licensing and logs[^14]. |

If an INVITE or OPTIONS sent to the Microsoft SIP proxy carries an IP address instead of an FQDN as the Contact header hostname, the proxy refuses it with 403 Forbidden[^4]. When outbound calls reach the SBC but result in SIP 403 or 404 responses, Microsoft indicates the PSTN provider is the most probable cause[^6]. In busy datacenter scenarios, Microsoft Direct Routing can return a 503 response containing a Retry-After header of 1 second, instructing the SBC to close the active session and attempt the next Microsoft datacenter[^15].

If all tenant users fail to place outbound calls, administrators should verify that `Get-CsOnlinePSTNGateway` shows `Enabled` as True (correcting with `Set-CsOnlinePSTNGateway -Enabled $true`) and inspect firewalls for blocked SIP OPTIONS traffic[^48]. Where only specific users fail, policies created by copying and pasting from WYSIWYG text editors may contain hidden characters affecting route matching; resolving this requires recreating the Online Voice Routing Policy in plain text[^51].

## Network and Vendor Boundaries

Direct Routing signaling operates over TLS port 5061 targeting Microsoft 365, Office 365, and GCC proxies[^56]. Signaling FQDNs resolve across subnets 52.112.0.0/14 and 52.120.0.0/14 (IPv6 2603:1063:400::/40), and firewalls must permit traffic across these entire ranges rather than specific DNS responses[^56]. Media traffic traverses UDP/SRTP across ports 3478 through 3481 and ports 49152 through 53247 bidirectionally, with Microsoft recommending allocating at least 2 SBC media ports per concurrent call[^44].

Microsoft provides support for Direct Routing exclusively when paired with certified SBC platforms[^58]. Microsoft mandates that support investigations originate with the SBC vendor, who then escalates to Microsoft engineering with an investigation report attached[^58].

## See also

See also [SIP TLS handshake failures on trunks](https://warmtransfer.net/knowledge/sip-tls-handshake-failures).  
See also [Troubleshooting Teams call queues and auto attendants](https://warmtransfer.net/knowledge/teams-call-queue-troubleshooting).  
See also [SIP 503 and trunk out-of-service failures](https://warmtransfer.net/knowledge/sip-503-trunk-failures).  
See also [Session border controller selection and certification](https://warmtransfer.net/knowledge/sbc-selection).

## Applicability

The certificate authority changes and root trust requirements apply across Microsoft 365, Office 365, and GCC environments, with specific CA testing initiated on June 30 2026 and entering production at the end of July 2026[^57][^46][^19][^56].

## What remains uncertain

WarmTransfer's reading of the sources is that whether Microsoft will eventually require the Client Authentication EKU on SBC certificates is unsettled[^37]. The exact numeric threshold that Microsoft uses to classify an SBC status as Inactive based on a lack of recent calls or health checks is not covered by the sources below.

## Sources

[^1]: If the SBC gets 200 OK from the SIP proxy but never receives the proxy's own OPTIONS, Microsoft says to check that the Record-Route or Contact FQDN is correct and resolves to the right IP. It also says to check that firewall rules allow inbound connections from all SIP proxy signaling IP addresses. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), SIP options issues > SBC receives "200 OK" response but not SIP options. Checked 2026-09-25.
[^2]: Microsoft response code 510532 with SIP 403 ('No trunk config was found' or 'RuntimeApi trunk config not found for customer') means Direct Routing found no trunk configuration for the call. Microsoft says to check that calls come from the correct SBC FQDN for the tenant, that the Contact header FQDN is registered to the tenant, and that the gateway configuration is correct. Source: [SIP 403 and Microsoft response codes - Microsoft Teams](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/microsoft-sip-response-codes-403), 510532 403 Get Inbound Direct Routing - RuntimeApi trunk config not found for customer; 510532 403 No trunk config was found. Checked 2026-09-25.
[^3]: Microsoft response code 510559 with SIP 403 ('Get Outbound routing - No viable path') means the dialed number matched no number pattern in the user's voice routes. Causes include a misdialed number or internal policy that blocks certain countries or patterns. Source: [SIP 403 and Microsoft response codes - Microsoft Teams](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/microsoft-sip-response-codes-403), 510559 403 Get Outbound routing - No viable path (Forbidden). Checked 2026-09-25.
[^4]: If an INVITE or OPTIONS sent to the Microsoft SIP proxy has an IP address instead of an FQDN as the Contact header hostname, the proxy refuses it with 403 Forbidden. An IP address in Record-Route or Contact also fails the certificate check. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Detailed requirements for Contact header and Request-URI > Contact header, final paragraph; Use of FQDN name in Contact or Record-Route. Checked 2026-09-25.
[^5]: Other Microsoft-generated 403s: 510534 is a calling number blocked by inbound call blocking; 510546 is no trunk found by Location-Based Routing criteria, often toll-bypass restriction or PreventTollBypass; 10500 is a Location-Based Routing site-state block; 10553 is a failed invite to a required compliance recorder; 10199 is private calling disabled for the callee. Source: [SIP 403 and Microsoft response codes - Microsoft Teams](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/microsoft-sip-response-codes-403), Sections 510534 403, 510546 403, 10500 403, 10553 403, 10199 403. Checked 2026-09-25.
[^6]: Microsoft's outbound-call article says that when Teams calls reach the SBC but fail with SIP 403 or 404, the PSTN provider is the most likely source, and you should contact the provider. Source: [Issues with outbound calls - Microsoft Teams](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/issues-with-outbound-calls), Connection to the SBC not established > Cause 2 / Resolution 2. Checked 2026-09-25.
[^7]: For user-provisioning 403s: 510560 means the user isn't Enterprise Voice enabled; 510562 means the user can't make outbound PSTN calls; 510563 means the user is limited to domestic calls. For 510560 and 510562, Microsoft says to check the Phone System licence and Direct Routing enablement. Source: [SIP 403 and Microsoft response codes - Microsoft Teams](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/microsoft-sip-response-codes-403), Sections 510560 403 (two variants), 510562 403, 510563 403. Checked 2026-09-25.
[^8]: Microsoft response code 500001 with SIP 408 ('Gateway (SBC) failover timer expired') means the SBC didn't answer the INVITE within FailoverTimeSeconds, which defaults to 10 seconds. In regions with long PSTN setup times, Microsoft suggests raising it to 20 seconds. Source: [SIP 408 and Microsoft response codes - Microsoft Teams](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/microsoft-sip-response-codes-408), 500001 408 Gateway (SBC) failover timer expired. Checked 2026-09-25.
[^9]: Microsoft response code 1106 with SIP 408 means the callee answered but the SBC never acknowledged Microsoft's 200 OK. Microsoft says to work with the SBC vendor to check the SIP stack and the TCP/TLS connections to the Microsoft connection points. Source: [SIP 408 and Microsoft response codes - Microsoft Teams](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/microsoft-sip-response-codes-408), 1106 408 An acknowledgement was not received for the call acceptance in the allotted time. Checked 2026-09-25.
[^10]: Microsoft response code 531052 with SIP 488 ('Cannot negotiate a new modality with blackhole media') means the SBC sent SDP with connection address 0.0.0.0, which the Microsoft SIP stack doesn't support. Source: [SIP 488 and Microsoft response codes - Microsoft Teams](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/microsoft-sip-response-codes-488), 531052 488 Cannot negotiate a new modality with blackhole media. Checked 2026-09-25.
[^11]: Microsoft response code 531027 with SIP 488 ('There are no ICE candidates in the SDP') means media bypass failed because the SBC's SDP had no ICE candidates. Microsoft's fix is to enable ICE Lite on the SBC. Source: [SIP 488 and Microsoft response codes - Microsoft Teams](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/microsoft-sip-response-codes-488), 531027 488 There are no ICE candidates in the SDP. Non-ice endpoints cannot use bypass. Checked 2026-09-25.
[^12]: Microsoft response code 531000 with SIP 488 has two forms. CannotSupportAnyMedia means the SBC offered no acceptable media format, so check its codec configuration. SrtpEncryptionRequired means the SBC didn't offer SRTP, so enable SRTP on the SBC. Source: [SIP 488 and Microsoft response codes - Microsoft Teams](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/microsoft-sip-response-codes-488), 531000 488 InternalDiagCode: CannotSupportAnyMedia; 531000 488 InternalDiagCode: SrtpEncryptionRequired. Checked 2026-09-25.
[^13]: Microsoft response code 540998 with SIP 503 ('Service state: Inactive/DrainingTransactions') is expected while Microsoft SIP endpoints are down for maintenance, and normally needs no action. If it happens often, check that the SBC re-resolves DNS frequently, ideally every 15 minutes or more often. Source: [SIP 503 and Microsoft response codes - Microsoft Teams](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/microsoft-sip-response-codes-503), 540998 503 Service Unavailable - Service state: Inactive/DrainingTransactions. Checked 2026-09-25.
[^14]: Microsoft response code 560503 with SIP 503 means the SBC itself returned 503 (maintenance or overload). Microsoft says to check the SBC logs, check that the SBC is licensed for the concurrent session count, and see whether the failures cluster on a particular destination country or calling corridor. Source: [SIP 503 and Microsoft response codes - Microsoft Teams](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/microsoft-sip-response-codes-503), 560503 503 Service unavailable. SBC undergoing maintenance or temporarily overloaded. Checked 2026-09-25.
[^15]: If a Direct Routing datacenter is busy, it can send the SBC a 503 with Retry-After (one-second interval) in response to an INVITE. The SBC must then terminate that connection and try the next available Microsoft datacenter. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Retry-After. Checked 2026-09-25.
[^16]: Microsoft's SBC connectivity troubleshooting article still says that if the SBC doesn't trust the SIP proxy certificate, you should download and install the Baltimore CyberTrust root on the SBC (disputed). Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), TLS connection issues > SBC doesn't trust SIP proxy certificate. Checked 2026-09-25.
[^17]: Microsoft's Azure Certificate Authority details change log records that Baltimore CyberTrust Root was removed from the list of CAs used by Azure service endpoints on October 8 2024. Source: [Azure Certificate Authority details](https://learn.microsoft.com/en-us/purview/encryption-office-365-certificate-chains), Article change log > October 8, 2024. Checked 2026-09-25.
[^18]: Call Analytics helps only when calls reach Direct Routing's internal components and then fail. For SBC pairing problems, or a SIP INVITE rejected because of a misconfigured trunk FQDN, Microsoft says to use the SBC logs, where Direct Routing sends detailed issue descriptions. Source: [Monitor Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-monitor-and-troubleshoot), Monitor Call Quality Analytics dashboard and SBC logs, final paragraph. Checked 2026-09-25.
[^19]: Microsoft planned a staged validation test starting June 30 2026 at 09:00 UTC, running over 2-4 days, to move Direct Routing SIP endpoints to certificates from a new CA. It said that SBCs failing outbound TLS or rejecting inbound connections during the test indicated trust issues with the new certificate. Source: [What's New Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-whats-new), Validation test that switches Microsoft Teams Direct Routing SIP endpoints to certificates issued by a new CA (June 30, 2026). Checked 2026-09-25.
[^20]: After renewing the SBC certificate, the TLS connections already set up with the old certificate must be torn down and re-established, or the Teams admin center keeps raising expiration warnings. Microsoft suggests restarting the SBC in a low-traffic window, or asking the SBC vendor how to force old TLS connections closed. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), TLS connection issues > SBC certificate is invalid, second paragraph. Checked 2026-09-25.
[^21]: Microsoft says its SIP endpoints currently trust SBC certificates that lack the Client Authentication EKU, expects this to continue for the foreseeable future, and will announce any change in advance. Source: [What's New Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-whats-new), Clarification on Client Authentication Extended Key Usage (EKU). Checked 2026-09-25.
[^22]: A Microsoft response code starting with 560 means the final SIP response was generated by the SBC, and its last three digits are that SIP code (for example 560403 is a 403 from the SBC). Microsoft says to start with the SBC logs and the SBC vendor. Any other Microsoft response code means a Microsoft service generated the final response. Source: [Microsoft and SIP response codes](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/microsoft-sip-response-codes), Direct Routing error codes. Checked 2026-09-25.
[^23]: Direct Routing failures carry two codes. The SIP response code (CallEndReason) is three digits and says what happened. The Microsoft response code (CallEndSubReason) is usually six digits, though it can be empty or longer, and says why. Both appear in the Teams admin center and in the Power BI Quality of Experience Report for PSTN. Source: [Microsoft and SIP response codes](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/microsoft-sip-response-codes), Introduction, two bullets and following paragraph. Checked 2026-09-25.
[^24]: Microsoft groups four Direct Routing SBC connectivity symptoms: SIP OPTIONS not received, TLS connection problems, the SBC not responding, and the SBC marked inactive in the Teams admin center. It attributes them mostly to TLS certificate problems, SBC misconfiguration for Direct Routing, or both. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), Introduction (before 'Overview of the SIP options process'). Checked 2026-09-25.
[^25]: Microsoft treats average call duration on the dashboard as a quality indicator. It recommends setting a company baseline, because a large drop, for example to about 15 seconds, can mean users are hanging up over quality or reliability problems. Source: [Health dashboard for Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-health-dashboard), The SBCs tab > Average call duration. Checked 2026-09-25.
[^26]: The dashboard's TLS connectivity status checks the SBC certificate's expiration date and warns when it expires within 30 days. Source: [Health dashboard for Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-health-dashboard), The SBCs tab > TLS connectivity status. Checked 2026-09-25.
[^27]: The Direct Routing health dashboard is under Voice > Direct Routing in the Teams admin center. It shows total SBCs, voice routes, and SBCs with issues. Issues include low network effectiveness, certificate expiration, inactivity, no SIP OPTIONS, and capacity constraints. Source: [Health dashboard for Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-health-dashboard), View the health dashboard for Direct Routing; Overall health > Direct Routing summary. Checked 2026-09-25.
[^28]: The dashboard's concurrent calls capacity compares the calls Direct Routing sent or received through an SBC with the limit set by -MaxConcurrentSessions on New-CsOnlinePSTNGateway or Set-CsOnlinePSTNGateway. If the SBC also serves other PBXs, the figure isn't the SBC's true concurrency. Source: [Health dashboard for Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-health-dashboard), The SBCs tab > Concurrent calls capacity. Checked 2026-09-25.
[^29]: The dashboard calculates network effectiveness ratio as 100 x (Answered calls + User Busy + Ring no Answer + Terminal Reject Seizures) / Total Calls. User rejections and calls sent to voicemail count as successful deliveries. Source: [Health dashboard for Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-health-dashboard), The SBCs tab > Network effectiveness. Checked 2026-09-25.
[^30]: The dashboard shows how many calls each metric is based on. Microsoft cautions that when fewer than 100 calls are analysed, a low network effectiveness ratio may still be normal. Source: [Health dashboard for Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-health-dashboard), The SBCs tab > Network effectiveness, final paragraph. Checked 2026-09-25.
[^31]: The per-SBC view shows jitter, packet loss and latency (round-trip time), measured from the Direct Routing interface to the SBC, filterable by days and call direction. For recommended values Microsoft points to the Customer Edge to Microsoft Edge targets in its Teams network preparation guidance. Source: [Health dashboard for Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-health-dashboard), Detailed information for each SBC > Network parameters. Checked 2026-09-25.
[^32]: An SBC added with PowerShell (New-CsOnlinePSTNGateway) that never connected appears on the health dashboard as unhealthy with issues. Source: [Health dashboard for Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-health-dashboard), Overall health > Direct Routing summary > SBCs with issues. Checked 2026-09-25.
[^33]: By default the SBC sends OPTIONS every minute, though this can vary by SBC vendor. Source: [Health dashboard for Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-health-dashboard), The SBCs tab > SIP options status, first sentence. Checked 2026-09-25.
[^34]: The dashboard shows three SIP OPTIONS status values. 'Active' means OPTIONS arrive regularly. 'Warning, no SIP options' means the SBC exists but the service has never seen OPTIONS from it. 'Warning, SIP Messages aren't configured' means OPTIONS trunk monitoring isn't turned on. Source: [Health dashboard for Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-health-dashboard), The SBCs tab > SIP options status, list of possible values. Checked 2026-09-25.
[^35]: In the per-SBC view, SBC status 'Inactive' means the SBC has no recent calls or health checks. 'Active' means it is healthy and taking traffic. The page gives no numeric threshold for 'recent'. Source: [Health dashboard for Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-health-dashboard), Detailed information for each SBC > SBC status. Checked 2026-09-25.
[^36]: To activate an SBC domain for a tenant, at least one licensed user must be assigned to the subdomain the SBC uses. Once all requirements are met, activation can take up to 24 hours. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), SIP options issues > Domain activation is not registered in the Microsoft 365 environment. Checked 2026-09-25.
[^37]: Whether Microsoft will eventually require the Client Authentication EKU on SBC certificates is unsettled. The December 2025 entry said it would, and the later clarification says the current tolerance should continue for the foreseeable future. Advice that SBC certificates must carry the Client Authentication EKU today is not supported (inferred). Source: [What's New Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-whats-new), Update on upcoming certificate changes (December 12, 2025) > Summary, second bullet; and Clarification on Client Authentication Extended Key Usage (EKU). Checked 2026-09-25.
[^38]: Sometimes the SBC certificate or required intermediates are missing from the SBC's TLS Hello even though the configuration looks correct. Microsoft notes that a packet capture can show the certificate isn't actually being presented to Teams. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), TLS connection issues > SBC certificate or intermediary certificates are missing in the SBC TLS "Hello" message. Checked 2026-09-25.
[^39]: In the hosted (carrier) model, only the hosted SBC should send SIP OPTIONS. SBCs in a derived trunk take their status from the main SBC. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), Overview of the SIP options process, Note. Checked 2026-09-25.
[^40]: Another cause of an intermittently inactive SBC is a root or intermediate certificate on the SBC that isn't part of the SBC certificate's issuer chain. The Teams service can't validate the chain and resets the connection. The fix is to install the correct intermediate and root on the SBC. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), SIP options issues > SBC status is intermittently inactive, second bullet. Checked 2026-09-25.
[^41]: One cause of an intermittently inactive SBC is sending OPTIONS to fixed IP addresses instead of the SIP proxy FQDNs. During maintenance or outages those IPs can move to another datacenter. Microsoft's fix is to send OPTIONS only to FQDNs and to configure all three: sip, sip2 and sip3.pstnhub.microsoft.com. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), SIP options issues > SBC status is intermittently inactive, first bullet. Checked 2026-09-25.
[^42]: The Direct Routing SIP call flow (ladder) view requires the Teams Administrator or Teams Telephony Administrator role. To open it: Analytics & reports > Usage reports > PSTN usage report > Direct Routing tab > select a call > SIP call flow, or select the call's Final SIP code. Source: [SIP call flow for Direct Routing in Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-monitor-sip-ladder), Prerequisites; Access SIP call flow, steps 1-8. Checked 2026-09-25.
[^43]: SIP call flow data can take up to 30 minutes to appear in the Teams admin center. Calls older than 30 days aren't available in the SIP call flow. Source: [SIP call flow for Direct Routing in Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-monitor-sip-ladder), Access SIP call flow, Note. Checked 2026-09-25.
[^44]: Direct Routing media between the SBC and Microsoft media processors is UDP/SRTP on ports 3478-3481 and 49152-53247 in both directions. Microsoft recommends allocating at least two SBC media ports per concurrent call. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), Media ports (table and Tip). Checked 2026-09-25.
[^45]: A TLS connection that drops or never forms, even though certificates and SBC settings are fine, may be closed by a device in the path such as a firewall or router. Microsoft points to the customer-managed network as the place to fix it. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), TLS connection issues > SBC connection is interrupted. Checked 2026-09-25.
[^46]: Microsoft says certificates issued by a new CA went into production on the Teams Direct Routing SIP endpoints at the end of July 2026. It has discontinued the test endpoint sip.g1.pstnhub.microsoft.com (port 5061, OPTIONS only), which had been provided for validating SBC trust. Source: [What's New Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-whats-new), Testing endpoint for upcoming certificate changes (February 16, 2026), Warning box. Checked 2026-09-25.
[^47]: Microsoft lists these causes when the SBC gets no 200 OK to its OPTIONS even though TLS and the certificate are valid: the Record-Route or Contact FQDN differs from the FQDN configured in Teams; the Contact header carries an IP address instead of an FQDN; the domain isn't fully validated; or the SBC domain hasn't been activated by adding a licensed user. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), SIP options issues > SBC doesn't receive a "200 OK" response from SIP proxy. Checked 2026-09-25.
[^48]: If no user in a tenant can make outbound calls, Microsoft suggests two checks. First, whether the gateway is disabled: Get-CsOnlinePSTNGateway should show Enabled True, and it can be fixed with Set-CsOnlinePSTNGateway -Enabled $true. Second, whether a firewall is blocking SIP OPTIONS from the Microsoft signaling IPs and FQDNs. Source: [Issues with outbound calls - Microsoft Teams](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/issues-with-outbound-calls), No users are able to make calls > Cause 1 and Cause 2. Checked 2026-09-25.
[^49]: When the SIP proxy recognizes the SBC FQDN, it answers the SBC's OPTIONS with 200 OK on the same TLS connection. It then sends its own OPTIONS to the FQDN in the Contact header of the SBC's OPTIONS. Only after the SBC answers those with 200 OK is the SBC marked Active in the Teams admin center. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), Overview of the SIP options process, bullets 3-7. Checked 2026-09-25.
[^50]: In the Direct Routing SIP OPTIONS process, the SBC first opens a TLS connection to the SIP proxy FQDN (for example sip.pstnhub.microsoft.com). If the SIP proxy judges the connection request invalid, it closes the TLS connection and never receives OPTIONS from the SBC. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), Overview of the SIP options process, bullets 1-2. Checked 2026-09-25.
[^51]: Pasting into an Online Voice Routing Policy from Word or another WYSIWYG editor can insert invisible characters that still affect route selection. Microsoft's fix is to remove the policy and recreate it by typing it or pasting from a plain-text editor. Source: [Issues with outbound calls - Microsoft Teams](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/issues-with-outbound-calls), Some users are unable to make calls > Cause 3 / Resolution 3. Checked 2026-09-25.
[^52]: Direct Routing treats an SBC as healthy for routing if it sent OPTIONS within the last three minutes, which is three one-minute intervals, before the call. Otherwise the SBC is demoted in the route. No tenant action is needed to enable this OPTIONS monitoring. Source: [Monitor Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-monitor-and-troubleshoot), Monitoring availability of Session Border Controllers using Session Initiation Protocol (SIP) options messages. Checked 2026-09-25.
[^53]: A demoted SBC isn't tried first. Direct Routing tries the other SBCs in the route, then retries the demoted SBC before generating a failure. When two or more SBCs in a route are equally healthy and equal in priority, calls are spread across them with a Fisher-Yates shuffle. Source: [Monitor Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-monitor-and-troubleshoot), Monitoring availability of Session Border Controllers using Session Initiation Protocol (SIP) options messages, paragraphs on demotion and Fisher-Yates. Checked 2026-09-25.
[^54]: Under Voice > Direct Routing > SBC test cases in the Teams admin center, admins can build a test suite against one SBC using test-user credentials. The available tests are Outbound-Inbound, Simultaneous ring, Media escalation and Consultative transfer. Results include suggested fixes for tenant, user or policy configuration. Source: [Diagnose issues that affect Direct Routing](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/diagnose-direct-routing-issues), Create a test suite, steps 1-8. Checked 2026-09-25.
[^55]: A self-signed SBC certificate isn't valid for Direct Routing. The certificate must come from a trusted CA and contain at least one FQDN that belongs to a Microsoft 365 tenant. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), TLS connection issues > SBC certificate is self-signed or not from a trusted CA. Checked 2026-09-25.
[^56]: For Microsoft 365, Office 365 and GCC, the SBC connects to the Microsoft SIP proxy on TLS port 5061. The signaling FQDNs resolve into 52.112.0.0/14 and 52.120.0.0/14 (IPv6 2603:1063:400::/40). Microsoft says to allow all these ranges in the firewall, not only the addresses DNS returns. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), SIP signaling: FQDNs (Important box); SIP signaling ports. Checked 2026-09-25.
[^57]: Microsoft says Teams SIP interface client and server certificates, for both Direct Routing and Operator Connect, chain to one of seven roots: DigiCert Global Root CA, DigiCert Global Root G2, DigiCert Global Root G3, DigiCert TLS ECC P384 Root G5, DigiCert TLS RSA 4096 Root G5, Microsoft ECC Root CA 2017, and Microsoft RSA Root CA 2017. SBCs must trust all of them. Source: [What's New Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-whats-new), Update on upcoming certificate changes (December 12, 2025) > Changes and call to action; Summary. Checked 2026-09-25.
[^58]: Microsoft supports Direct Routing only with certified SBCs. It wants issues taken to the SBC vendor first, with the vendor escalating to Microsoft, and asks customers to include the vendor's investigation report when opening a Microsoft support request. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), Support boundaries. Checked 2026-09-25.
[^59]: If the TLS connection closes immediately and no OPTIONS arrive from the SBC, or no 200 OK comes back from the SBC, Microsoft suggests checking the TLS version. The SBC should be configured for TLS 1.2 or higher. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), TLS connection issues, opening paragraph. Checked 2026-09-25.
[^60]: A wildcard certificate matches only one subdomain level. For example, *.contoso.com matches sbc1.contoso.com but not customer10.sbc1.contoso.com. If the SBC FQDN doesn't match the certificate CN or SAN, Microsoft says to get a new certificate that does. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), SIP options issues > FQDN doesn't match the contents of CN or SAN in the provided certificate. Checked 2026-09-25.