SBC connectivity issues

Publisher

Microsoft

URL

https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues

Published

2023-10-30

Updated

unknown

Accessed

2026-09-24

HTTP status

200

License

Microsoft Learn content; Microsoft Terms of Use; no-redistribution; short excerpts and locators only

Source notes citing this source

• If the SBC gets 200 OK from the SIP proxy but never receives the proxy's OPTIONS, Microsoft says to check that the Record-Route or Contact FQDN is correct and resolves to the right IP, and that firewall rules allow inbound traffic from all SIP proxy signalling addresses. in context
• Causes Microsoft lists for an SBC getting no 200 OK to its OPTIONS include: a Contact header carrying an IP address instead of the FQDN, an FQDN in Record-Route or Contact that differs from the one configured in Teams, and a domain that is not fully validated or not activated. in context
• In the hosted (multi-tenant carrier) model, only the hosted SBC should send SIP OPTIONS, and the status of SBCs in a derived trunk follows the main SBC. in context
• Microsoft describes the Direct Routing OPTIONS exchange in this order: the SBC opens TLS to the SIP proxy FQDN, the SBC sends OPTIONS, the proxy identifies the SBC FQDN and answers 200 OK on the same TLS connection, the proxy sends OPTIONS to the Contact FQDN, the SBC answers 200 OK, and the SBC is marked Active in the Teams admin center. in context
• An SBC that sends OPTIONS to fixed IP addresses rather than to the SIP proxy FQDNs can show as intermittently inactive, because those addresses can move to another datacenter during maintenance or outages. Microsoft says to send OPTIONS to FQDNs only and to configure all three proxy FQDNs. in context
• When the Microsoft SIP proxy receives OPTIONS from an SBC, it looks for a known tenant's SBC FQDN in the Record-Route header first and falls back to the Contact header. in context
• Devices that support DNS names can use sip-all.pstnhub.microsoft.com, which resolves to all possible SIP proxy IP addresses. in context
• Microsoft's Teams Direct Routing troubleshooting article says an SBC that does not trust the SIP proxy certificate should install the Baltimore CyberTrust root. disputed in context
• If the root or intermediate installed on the SBC is not the actual issuer chain of the SBC certificate, the Teams service cannot validate the chain and resets the connection; Microsoft lists this as a cause of an SBC that is intermittently inactive. in context
• Microsoft's Direct Routing troubleshooting guidance says that if the TLS connection closes right away and no SIP OPTIONS arrive from the SBC, the TLS version may be the cause, and the SBC should be configured for TLS 1.2 or higher. in context
• The Direct Routing Health Dashboard in the Teams admin center can show that an SBC certificate is expired or revoked; the fix is to renew it from a trusted CA and install it on the SBC. in context
• When certificates and SBC settings are correct but the TLS connection is still interrupted, Microsoft points to intermediary devices such as firewalls or routers between the SBC and Microsoft closing the connection. in context
• Microsoft lists a missing SBC certificate or missing intermediate certificates in the SBC's TLS handshake as a failure cause, and notes that only a packet capture may show that the certificate was never sent even when the configuration looks correct. in context
• If TLS is established but the SBC gets no 200 OK to its OPTIONS, Microsoft points to SIP-layer causes: the Record-Route or Contact FQDN differs from the Teams configuration, the Contact carries an IP address, or the domain is not fully validated. in context
• In Teams Direct Routing the SBC opens the TLS connection to the SIP proxy FQDN and presents its certificate; if the SIP proxy judges the request invalid it closes the TLS connection and never receives SIP OPTIONS from the SBC. in context
• After an SBC certificate is renewed, TLS connections set up with the old certificate must be torn down and re-established, for example by restarting the SBC in a maintenance window; otherwise the Teams admin center keeps raising certificate expiry warnings. in context
• Teams Direct Routing treats a self-signed SBC certificate as invalid; the certificate must come from a trusted CA and contain at least one FQDN that belongs to a Microsoft 365 tenant. in context
• A Direct Routing wildcard certificate covers only one label: *.contoso.com matches sbc1.contoso.com but not customer10.sbc1.contoso.com, and an FQDN that does not match the CN or SAN needs a new certificate. in context
• 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. in context
• 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 in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context

Cite this source record

APA

WarmTransfer. (2023, October 30). SBC connectivity issues. WarmTransfer. https://warmtransfer.net/knowledge/sources/ms-learn-troubleshoot-dr-sbc-connectivity

BibTeX

@misc{warmtransfer-ms-learn-troubleshoot-dr-sbc-connectivity,
  title  = {SBC connectivity issues},
  author = {{WarmTransfer}},
  year   = {2023},
  url    = {https://warmtransfer.net/knowledge/sources/ms-learn-troubleshoot-dr-sbc-connectivity},
  note   = {Microsoft, accessed 2026-09-24}
}