# SIP trunk authentication: registration and static IP and mutual TLS

Canonical: https://warmtransfer.net/knowledge/sip-trunk-authentication-models

Last verified: 2026-10-02

RFC 6140 requires a service provider registrar to authenticate a SIP-PBX that registers a block of numbers, and it gives SIP digest or mutual TLS as example mechanisms[^26]. Vendor documentation describes trunks that authenticate by SIP digest over registration, by IP allow lists alone or layered with credentials, and by certificate[^56][^44][^45][^48].

## Digest authentication and registration

RFC 8760 updates RFC 3261 so that SIP digest authentication can use SHA-256, SHA-512/256, or any algorithm in the IANA HTTP Digest hash algorithm registry, instead of only MD5[^29]. RFC 8760 keeps MD5 only for backward compatibility and states that its use is NOT RECOMMENDED[^27]. Under RFC 8760, a SIP server must always send the qop parameter in digest challenges, and both the UAC and the UAS must handle it[^28]. A server may send several digest challenges with different algorithms, and the client uses the topmost challenge whose algorithm it supports[^30].

RFC 6140 lets a SIP-PBX register once for a whole block of addresses of record instead of keeping a separate registration per number[^24]. RFC 6140 is designed for SIP-PBXs that cannot be assumed to have a static IP address or a DNS entry that reliably resolves to them[^25]. RFC 5626 lets a proxy reuse the flow that a user agent opened when registering to deliver later inbound requests, so the UA can receive calls through NATs and firewalls that block inbound connections[^19]. RFC 5626 keeps connection-oriented flows alive with a double-CRLF ping answered by a single-CRLF pong[^18]. It keeps UDP flows alive with periodic STUN Binding Requests sent over the flow[^20].

A registration-based Webex Calling Local Gateway trunk authenticates with SIP digest, using a shared username and password for both registration and calls[^56]. When this trunk type is created in Control Hub, Webex Calling issues the following values[^54]:

- the registrar domain[^54]
- the line/port[^54]
- the authentication username and password[^54]
- the outbound proxy SRV address[^54]
- the trunk OTG/DTG value[^54]

Registration-based Local Gateway trunks support only Cisco Unified Border Element (CUBE) as the gateway[^55]. Cisco positions them for up to 250 concurrent calls per trunk, and positions certificate-based trunks for more than 250[^52]. A registration-based Local Gateway works behind any NAT or on a public IP, with dynamic NAT preferred, because the gateway's outbound registration opens the firewall pinholes[^53]. Cisco's example configuration registers over TLS with the sips scheme, a 240-second expiry and refresh ratio 50, so the gateway re-registers about every 120 seconds[^57].

Genesys Cloud external trunks use digest authentication for outbound requests, configured as a realm, username and password that answer challenges from the far end[^12]. Genesys Cloud phone trunks use digest in the inbound direction[^12]. Genesys Cloud offers outbound SIP registration, with an expiration interval and address of record, only on Premises External SIP trunks, and the setting is disabled by default[^14].

Bandwidth offers a separate SIP Registrar capability that sales must enable[^3]. That capability uses customer-supplied MD5 hash values (username:realm:password) for digest credentials on a per-realm auth.bandwidth.com domain[^3].

## Static IP and IP allow lists

Bandwidth UC Trunking does not support SIP REGISTER, and the customer must provide a public static IP address for Bandwidth to send calls to[^5]. Bandwidth signals from a mated pair of SIP proxies[^4]. Customers must allow both proxy IPs for origination and configure both for termination traffic[^4].

Twilio tells customers to configure their infrastructure not to register to an Elastic SIP trunk, and the trunk does not use SIP REGISTER[^46]. A Twilio Elastic SIP Trunking termination (outbound) setup must have at least an IP Access Control List or a credential list configured[^44]. When both an IP ACL and credentials are configured, Twilio enforces both on termination requests[^45]. Twilio strongly recommends configuring credentials, because IP ACLs alone do not protect against certain types of attacks[^43].

Amazon Chime SDK Voice Connector termination settings take an optional allowed hosts list of CIDR entries, and those IP addresses must be publicly routable[^6]. The same termination settings also take username and password credentials alongside the allowed hosts list[^7].

In Genesys Cloud, IP addresses entered as an external trunk's outbound SIP servers or proxies are added automatically to that trunk's SIP Access Control allow list[^10]. Genesys warns that setting SIP Access Control to Allow All on an external trunk is a security risk[^11]. Genesys recommends against Allow All for PSTN access trunks because of toll-fraud exposure[^11].

We infer that several cloud trunk services let IP allow-listing and digest credentials be layered rather than chosen between, so "registration versus IP" is not strictly a binary choice[^15]. WarmTransfer's reading of the sources is that registration plus digest is the model that tolerates dynamic NAT and no public IP, while IP-allow-list and certificate (mTLS) trunks assume a stable public address or static NAT[^17].

## Certificates and mutual TLS

RFC 5922 places a SIP server's domain identity in the certificate subjectAltName[^23]. It allows the subject CN to be examined only when no subjectAltName is present[^23]. Under RFC 5922, a SIP server that wants to authenticate the connecting peer requests a client certificate during the TLS handshake, which is the mutual-TLS step between SIP servers[^21].

### Webex Calling certificate-based Local Gateway

A certificate-based Webex Calling Local Gateway trunk authenticates by certificate with LGW FQDN verification[^48]. Every SIP transaction the gateway starts toward Webex Calling must carry the gateway FQDN in the Contact header[^48]. The gateway needs all of the following[^51]:

- a public internet-facing address (public IP or static NAT)[^51]
- public DNS A or SRV records[^51]
- a claimed domain[^51]

A public CA from Cisco's supported list must sign the device certificate[^50]. The certificate's CN or a SAN must equal the FQDN configured in Control Hub[^50]. Certificate-based trunks are not limited to CUBE: they support Cisco CUBE, Oracle, Ribbon, AudioCodes, anynode and Italtel[^49]. Webex for Government supports only certificate-based Local Gateway trunks, not registration-based ones[^47].

### Teams Direct Routing

Teams Direct Routing signalling is SIP over TLS only[^39]. The SBC connects to Microsoft SIP proxies on port 5061, and Microsoft connects to the SBC on a port configured on the SBC[^39]. The SBC certificate should meet these requirements[^37]:

- It carries the SBC FQDN in CN or SAN.[^37]
- It is signed by a CA in the Microsoft Trusted Root Program.[^37]
- It includes the Server Authentication EKU.[^37]

RFC 2818-compliant wildcards are supported[^37]. The SBC FQDN must belong to a verified Microsoft 365 domain and cannot use the default onmicrosoft.com domain[^41]. The TLS version configured on the SBC should be 1.2 or higher[^40].

Microsoft describes TLS between its Direct Routing SIP endpoints and customer SBCs as mutual TLS[^34]. In that exchange, the Teams SIP interface presents a client certificate that carries the Client Authentication EKU[^34]. If mutual TLS is enabled on the SBC for the Teams connection, all required Microsoft trusted root certificates must be installed on the SBC[^35]. Microsoft tells Direct Routing and Operator Connect SBCs to trust every root CA on its supported list for both client and server certificates[^38]. That list contains the following roots[^38]:

- DigiCert Global Root CA[^38]
- DigiCert Global Root G2[^38]
- DigiCert Global Root G3[^38]
- DigiCert TLS ECC P384 Root G5[^38]
- DigiCert TLS RSA 4096 Root G5[^38]
- the 2 Microsoft 2017 roots[^38]

Microsoft SIP endpoints currently accept SBC certificates that lack the Client Authentication EKU[^31]. Microsoft expects this to continue for the foreseeable future and says it will give advance notice before any change[^31].

### Azure Communication Services direct routing

Azure Communication Services direct routing supports only TLS 1.2 for SBC signalling, with a fixed list of 4 ECDHE-RSA cipher suites[^2]. An SBC FQDN paired with Azure Communication Services direct routing must differ from the SBC FQDN used for Teams Direct Routing[^1]. An SBC FQDN cannot pair with more than 1 Communication Services resource[^1].

### Zoom BYOC-P

For Zoom BYOC-P, the SBC certificate must meet these requirements[^58]:

- It carries the SBC FQDN in CN or SAN, and wildcards are accepted.[^58]
- It includes the Server Authentication key usage.[^58]
- It is presented with its full intermediate chain.[^58]

Zoom BYOC-P requires TLS 1.2 signalling and SRTP media between the customer SBC and Zoom when peering over the internet[^60]. Zoom's mTLS for BYOC-P does not validate peer names[^59]. Certificates are exchanged in the handshake, but Zoom does not check the SBC certificate CN or SAN against an expected hostname or FQDN[^59].

### Genesys Cloud and Amazon Chime SDK Voice Connector

Genesys Cloud external trunk TLS settings include a mutual authentication toggle that is disabled by default[^13]. The default protocol version for those settings is TLS 1.2[^13].

Amazon Chime SDK Voice Connector does not support mutual TLS, and customer SIP infrastructure should not request a client certificate from it[^9]. With encryption enabled, a Voice Connector behaves as follows[^8]:

- It uses TLS on port 5061 for signalling and SRTP for media.[^8]
- All inbound calls use TLS.[^8]
- Unencrypted outbound calls are blocked.[^8]
- TLS 1.2 and 1.3 are supported.[^8]

This is inferred: "mutual TLS" does not mean the same identity check everywhere[^16]. We infer that Teams Direct Routing and Webex certificate-based trunks bind the SBC to its FQDN, Zoom BYOC-P exchanges certificates without peer-name validation, and Amazon Chime SDK Voice Connector does not do mTLS at all[^16].

## Diagnosing certificate and identity failures

Teams Direct Routing maps the SBC to a tenant by the FQDN in its Contact or Record-Route header[^32]. If the Contact header carries an IP address, or carries an FQDN that differs from the Teams configuration, SIP OPTIONS fail[^32]. A self-signed SBC certificate is invalid for Teams Direct Routing[^36]. The certificate must come from a trusted CA and contain at least 1 FQDN that belongs to a Microsoft 365 tenant[^36]. TLS versions older than 1.2 on the SBC can make the connection close at once[^40]. A wildcard such as *.contoso.com matches sbc1.contoso.com but not customer10.sbc1.contoso.com, because multiple subdomain levels under a single wildcard are not allowed[^42].

For a certificate-based Webex Calling Local Gateway, check these values against the FQDN configured in Control Hub[^48][^50]:

- the gateway FQDN in the Contact header of transactions toward Webex Calling[^48]
- the certificate CN or SAN[^50]

For Amazon Chime SDK Voice Connector, a client certificate request from the customer side conflicts with Amazon's guidance[^9].

## See also

- [Local Gateway design and configuration](https://warmtransfer.net/knowledge/webex-calling-local-gateway)
- [Troubleshooting Teams Direct Routing](https://warmtransfer.net/knowledge/teams-direct-routing-troubleshooting)
- [Zoom Phone BYOC and Provider Exchange](https://warmtransfer.net/knowledge/zoom-phone-byoc)
- [Setting up an Asterisk PBX with Twilio Elastic SIP Trunking](https://warmtransfer.net/knowledge/asterisk-twilio-pbx-setup)
- [SIP trunk capacity and concurrent call planning](https://warmtransfer.net/knowledge/sip-trunk-capacity-planning)
- [Session border controller selection and certification](https://warmtransfer.net/knowledge/sbc-selection)

## Applicability

Applies to: Cisco Webex Calling, Microsoft Teams Direct Routing, Microsoft Azure Communication Services, Twilio Elastic SIP Trunking, Amazon Web Services Amazon Chime SDK Voice Connector, Genesys Cloud, Zoom Phone, Bandwidth UC Trunking, and Bandwidth SIP Registrar. Deployments: hybrid, multi-tenant, and any. Sources checked 2026-10-02. Webex for Government supports only certificate-based Local Gateway trunks[^47]. Genesys Cloud outbound SIP registration applies only to Premises External SIP trunks[^14]. The Microsoft certificate guidance on mutual TLS and root CAs comes from a Direct Routing update dated December 12, 2025[^33][^38]. The Zoom certificate and mTLS behaviour described here applies to BYOC-P[^58][^59].

## What remains uncertain

Microsoft's December 12, 2025 Direct Routing update said that all SBC certificates would have to include the Client Authentication EKU in the future, but it gave no date[^33]. Microsoft says SIP endpoints currently accept certificates without that EKU and that it will give advance notice before any change[^31].

Zoom does not check the BYOC-P SBC certificate CN or SAN against an expected hostname or FQDN[^59]. How Zoom otherwise identifies or allow-lists the customer SBC is not covered by the sources below.

The minimum CUBE IOS XE releases for registration-based and certificate-based Local Gateway are not covered by the sources below.

Genesys BYOC Cloud inbound carrier authentication and the Carrier Interoperability Specification are not covered by the sources below.

Bandwidth's SIP Registrar uses customer-supplied MD5 hash values for digest credentials[^3]. Which carriers and SBCs support SHA-256 digest per RFC 8760 is not covered by the sources below.

Webex Calling Dedicated Instance PSTN trunk authentication is not covered by the sources below.

Amazon Chime SDK Voice Connector termination settings take both an allowed hosts list and username and password credentials[^6][^7]. How the Voice Connector combines the 2 when both are set is not covered by the sources below.

Microsoft tells Operator Connect SBCs to trust all root CAs on its supported list[^38]. The Teams Operator Connect operator trunk authentication model beyond that is not covered by the sources below.

## Sources

[^1]: An SBC FQDN paired with Azure Communication Services direct routing must differ from the SBC FQDN used for Teams Direct Routing, and one SBC FQDN cannot pair with more than one Communication Services resource. Source: [Azure direct routing infrastructure requirements - Azure Communication Services](https://learn.microsoft.com/en-us/azure/communication-services/concepts/telephony/direct-routing-infrastructure), Section 'SBC certificates and domain names' (Note and pairing paragraph). Checked 2026-10-02.
[^2]: Azure Communication Services direct routing supports only TLS 1.2 for SBC signalling, with a fixed list of four ECDHE-RSA cipher suites. Source: [Azure direct routing infrastructure requirements - Azure Communication Services](https://learn.microsoft.com/en-us/azure/communication-services/concepts/telephony/direct-routing-infrastructure), Section 'SBC certificates and domain names' (Important callout). Checked 2026-10-02.
[^3]: Bandwidth offers a separate SIP Registrar capability that sales must enable; it uses customer-supplied MD5 hash values (username:realm:password) for digest credentials on a per-realm auth.bandwidth.com domain. Source: [How to setup SIP Registration](https://dev.bandwidth.com/docs/account/sipRegistrar/), Sections on realm creation and credentials (Hash1 and Hash1b). Checked 2026-10-02.
[^4]: Bandwidth signals from a mated pair of SIP proxies, so customers must allow both proxy IPs for origination and configure both for termination traffic. Source: [UC trunking integration guide](https://www.bandwidth.com/support/en/articles/12822954-uc-trunking-integration-guide), Section 'IP information'. Checked 2026-10-02.
[^5]: Bandwidth UC Trunking does not support SIP REGISTER; the customer must provide a public static IP address for Bandwidth to send calls to. Source: [UC trunking integration guide](https://www.bandwidth.com/support/en/articles/12822954-uc-trunking-integration-guide), Section 'No Registration'. Checked 2026-10-02.
[^6]: Amazon Chime SDK Voice Connector termination settings take an optional allowed hosts list of CIDR entries, and those IP addresses must be publicly routable. Source: [Editing Amazon Chime SDK Voice Connector settings](https://docs.aws.amazon.com/chime-sdk/latest/ag/edit-voicecon.html), Section 'Editing termination settings' step 2. Checked 2026-10-02.
[^7]: Amazon Chime SDK Voice Connector termination settings also take username and password credentials alongside the allowed hosts list. Source: [Editing Amazon Chime SDK Voice Connector settings](https://docs.aws.amazon.com/chime-sdk/latest/ag/edit-voicecon.html), Section 'Editing termination settings' step 5. Checked 2026-10-02.
[^8]: With encryption enabled, an Amazon Chime SDK Voice Connector uses TLS on port 5061 for signalling and SRTP for media, all inbound calls use TLS, and unencrypted outbound calls are blocked; TLS 1.2 and 1.3 are supported. Source: [Editing Amazon Chime SDK Voice Connector settings](https://docs.aws.amazon.com/chime-sdk/latest/ag/edit-voicecon.html), Section 'Using encryption with Voice Connectors'. Checked 2026-10-02.
[^9]: Amazon Chime SDK Voice Connector does not support mutual TLS; customer SIP infrastructure should not request a client certificate from it. Source: [Editing Amazon Chime SDK Voice Connector settings](https://docs.aws.amazon.com/chime-sdk/latest/ag/edit-voicecon.html), Section 'Using encryption with Voice Connectors' (Note). Checked 2026-10-02.
[^10]: In Genesys Cloud, IP addresses entered as an external trunk's outbound SIP servers or proxies are added automatically to that trunk's SIP Access Control allow list. Source: [External trunk settings](https://help.genesys.cloud/articles/external-trunk-settings/), Section 'SIP Access Control'. Checked 2026-10-02.
[^11]: Genesys warns that setting SIP Access Control to Allow All on an external trunk is a security risk and recommends against it for PSTN access trunks because of toll-fraud exposure. Source: [External trunk settings](https://help.genesys.cloud/articles/external-trunk-settings/), Section 'SIP Access Control'. Checked 2026-10-02.
[^12]: Genesys Cloud external trunks use digest authentication for outbound requests, configured as a realm, username and password that answer challenges from the far end; phone trunks use digest in the inbound direction. Source: [Enable digest authentication](https://help.genesys.cloud/articles/enable-digest-authentication/), Article body: external trunks versus phone trunks. Checked 2026-10-02.
[^13]: Genesys Cloud external trunk TLS settings include a mutual authentication toggle that is disabled by default, with TLS 1.2 as the default protocol version. Source: [External trunk settings](https://help.genesys.cloud/articles/external-trunk-settings/), Section 'TLS' / secure transport settings. Checked 2026-10-02.
[^14]: Genesys Cloud offers outbound SIP registration (with expiration interval and address of record) only on Premises External SIP trunks, and it is disabled by default. Source: [External trunk settings](https://help.genesys.cloud/articles/external-trunk-settings/), Section 'Registration'. Checked 2026-10-02.
[^15]: Several cloud trunk services let IP allow-listing and digest credentials be layered rather than chosen between (Twilio enforces both when both are set; Chime Voice Connector and Genesys external trunks expose both), so 'registration versus IP' is not strictly a binary choice (inferred). Source: [Elastic SIP Trunking](https://www.twilio.com/docs/sip-trunking), Section 'Authentication' compared with aws-chime-sdk-edit-voice-connector termination settings and genesys-help-external-trunk-settings. Checked 2026-10-02.
[^16]: 'Mutual TLS' does not mean the same identity check everywhere: Teams Direct Routing and Webex certificate-based trunks bind the SBC to its FQDN, Zoom BYOC-P exchanges certificates without peer-name validation, and Amazon Chime SDK Voice Connector does not do mTLS at all (inferred). Source: [BYOC-P or BYOP-P infrastructure requirements](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0079203), Section 'Public Trusted Certificates' compared with ms-learn-dr-sbc-connectivity-issues, cisco-help-t9xctu and aws-chime-sdk-edit-voice-connector. Checked 2026-10-02.
[^17]: Across the sources, registration plus digest is the model that tolerates dynamic NAT and no public IP, while IP-allow-list and certificate (mTLS) trunks assume a stable public address or static NAT (inferred). Source: [Get started with Local Gateway](https://help.webex.com/en-us/article/t9xctu/Get-started-with-Local-Gateway), Trunk types comparison: network requirements rows. Checked 2026-10-02.
[^18]: RFC 5626 keeps connection-oriented SIP flows alive with a double-CRLF ping answered by a single-CRLF pong. Source: [RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc5626.html), Section 4.4.1. Checked 2026-10-02.
[^19]: RFC 5626 lets a proxy reuse the flow a user agent opened when registering to deliver later inbound requests, so the UA can receive calls through NATs and firewalls that block inbound connections. Source: [RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc5626.html), Section 3.1. Checked 2026-10-02.
[^20]: RFC 5626 keeps UDP SIP flows alive with periodic STUN Binding Requests sent over the flow. Source: [RFC 5626: Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc5626.html), Section 4.4.2. Checked 2026-10-02.
[^21]: Under RFC 5922 a SIP server that wants to authenticate the connecting peer requests a client certificate during the TLS handshake, which is the mutual-TLS step between SIP servers. Source: [RFC 5922: Domain Certificates in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc5922.html), Section 7.4. Checked 2026-10-02.
[^22]: RFC 5922 requires SIP domain names in certificates to be matched in their entirety and does not permit wildcard or suffix matching. Source: [RFC 5922: Domain Certificates in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc5922.html), Section 7.2. Checked 2026-10-02.
[^23]: RFC 5922 places a SIP server's domain identity in the certificate subjectAltName and allows the subject CN to be examined only when no subjectAltName is present. Source: [RFC 5922: Domain Certificates in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc5922.html), Section 6; Section 7.1. Checked 2026-10-02.
[^24]: RFC 6140 lets a SIP-PBX register once for a whole block of addresses of record instead of keeping a separate registration per number. Source: [RFC 6140: Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc6140.html), Section 1. Checked 2026-10-02.
[^25]: RFC 6140 is designed for SIP-PBXs that cannot be assumed to have a static IP address or a DNS entry that reliably resolves to them. Source: [RFC 6140: Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc6140.html), Section 2 (constraints list). Checked 2026-10-02.
[^26]: RFC 6140 requires the service provider registrar to authenticate the SIP-PBX when it registers a block of numbers, giving SIP digest or mutual TLS as example mechanisms. Source: [RFC 6140: Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)](https://www.rfc-editor.org/rfc/rfc6140.html), Section 5.2. Checked 2026-10-02.
[^27]: RFC 8760 keeps MD5 in SIP digest only for backward compatibility and states its use is NOT RECOMMENDED. Source: [RFC 8760: The Session Initiation Protocol (SIP) Digest Access Authentication Scheme](https://www.rfc-editor.org/rfc/rfc8760.html), Section 3; Section 1. Checked 2026-10-02.
[^28]: Under RFC 8760 a SIP server must always send the qop parameter in digest challenges and both UAC and UAS must handle it. Source: [RFC 8760: The Session Initiation Protocol (SIP) Digest Access Authentication Scheme](https://www.rfc-editor.org/rfc/rfc8760.html), Section 2.6. Checked 2026-10-02.
[^29]: RFC 8760 updates RFC 3261 so that SIP digest authentication can use SHA-256 and SHA-512/256 (and any algorithm in the IANA HTTP Digest hash algorithm registry) instead of only MD5. Source: [RFC 8760: The Session Initiation Protocol (SIP) Digest Access Authentication Scheme](https://www.rfc-editor.org/rfc/rfc8760.html), Header (Updates: 3261); Section 2.1. Checked 2026-10-02.
[^30]: RFC 8760 allows a server to send several digest challenges with different algorithms, and the client uses the topmost challenge whose algorithm it supports. Source: [RFC 8760: The Session Initiation Protocol (SIP) Digest Access Authentication Scheme](https://www.rfc-editor.org/rfc/rfc8760.html), Sections 2.3 and 2.4. Checked 2026-10-02.
[^31]: Microsoft SIP endpoints currently accept SBC certificates that lack the Client Authentication EKU, and Microsoft expects this to continue for the foreseeable future, with advance notice before any change. Source: [What's New Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-whats-new), Entry 'Clarification on Client Authentication Extended Key Usage (EKU)'. Checked 2026-10-02.
[^32]: Teams Direct Routing maps the SBC to a tenant by the FQDN in its Contact or Record-Route header, so an IP address in Contact or an FQDN that differs from the Teams configuration causes SIP OPTIONS to fail. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), Issues related to SIP OPTIONS: 'The SBC doesn't receive a SIP 200 OK response from the SIP proxy'. Checked 2026-10-02.
[^33]: Microsoft's December 12, 2025 Direct Routing update said that in the future all SBC certificates would have to include the Client Authentication EKU, without giving a date. Source: [What's New Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-whats-new), Entry 'Update on upcoming certificate changes (December 12, 2025)': Summary, second bullet. Checked 2026-10-02.
[^34]: Microsoft describes TLS between its Direct Routing SIP endpoints and customer SBCs as mutual TLS, with the Teams SIP interface presenting a client certificate that carries the Client Authentication EKU. Source: [What's New Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-whats-new), Entry 'Update on upcoming certificate changes (December 12, 2025)': Background and Summary. Checked 2026-10-02.
[^35]: If mutual TLS is enabled on the SBC for the Teams connection, all required Microsoft trusted root certificates must be installed on the SBC. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), Section 'Public trusted certificate for the SBC' (final sentence). Checked 2026-10-02.
[^36]: A self-signed SBC certificate is invalid for Teams 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), Issues related to the TLS connection: 'The SBC certificate is self-signed or not from a trusted CA'. Checked 2026-10-02.
[^37]: A Teams Direct Routing SBC certificate should carry the SBC FQDN in CN or SAN, be signed by a CA in the Microsoft Trusted Root Program, and include the Server Authentication EKU; RFC 2818-compliant wildcards are supported. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), Section 'Public trusted certificate for the SBC'. Checked 2026-10-02.
[^38]: Microsoft tells Direct Routing and Operator Connect SBCs to trust all root CAs on its supported list (DigiCert Global Root CA, G2, G3, TLS ECC P384 Root G5, TLS RSA 4096 Root G5 and the two Microsoft 2017 roots) for both client and server certificates. Source: [What's New Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-whats-new), Entry 'Update on upcoming certificate changes (December 12, 2025)': Changes and call to action. Checked 2026-10-02.
[^39]: Teams Direct Routing signalling is SIP over TLS only: the SBC connects to Microsoft SIP proxies on port 5061, and Microsoft connects to the SBC on a port configured on the SBC. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), Section 'SIP signaling ports'. Checked 2026-10-02.
[^40]: The TLS version configured on a Teams Direct Routing SBC should be 1.2 or higher; older TLS versions can make the connection close at once. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), Section 'Issues related to the TLS connection' (intro paragraph). Checked 2026-10-02.
[^41]: The Teams Direct Routing SBC FQDN must belong to a verified Microsoft 365 domain and cannot use the default onmicrosoft.com domain. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), Section 'SBC domain names'. Checked 2026-10-02.
[^42]: For Teams Direct Routing a wildcard such as *.contoso.com matches sbc1.contoso.com but not customer10.sbc1.contoso.com; multiple subdomain levels under one wildcard are not allowed. Source: [SBC connectivity issues](https://learn.microsoft.com/en-us/troubleshoot/microsoftteams/phone-system/direct-routing/sip-options-tls-certificate-issues), Issues related to SIP OPTIONS: 'The FQDN doesn't match the contents of CN or SAN in the provided certificate'. Checked 2026-10-02.
[^43]: Twilio strongly recommends configuring credentials on Elastic SIP trunks because IP ACLs alone do not protect against certain types of attacks. Source: [Elastic SIP Trunking](https://www.twilio.com/docs/sip-trunking), Section 'Authentication'. Checked 2026-10-02.
[^44]: A Twilio Elastic SIP Trunking termination (outbound) setup must have at least an IP Access Control List or a credential list configured. Source: [Elastic SIP Trunking](https://www.twilio.com/docs/sip-trunking), Section 'Authentication'. Checked 2026-10-02.
[^45]: When a Twilio Elastic SIP trunk has both an IP ACL and credentials configured, Twilio enforces both on termination requests. Source: [Elastic SIP Trunking](https://www.twilio.com/docs/sip-trunking), Section 'Authentication'. Checked 2026-10-02.
[^46]: Twilio tells customers to configure their infrastructure not to register to an Elastic SIP trunk; the trunk does not use SIP REGISTER. Source: [Elastic SIP Trunking](https://www.twilio.com/docs/sip-trunking), Section 'Your Network'. Checked 2026-10-02.
[^47]: Webex for Government supports only certificate-based Local Gateway trunks, not registration-based ones. Source: [Get started with Local Gateway](https://help.webex.com/en-us/article/t9xctu/Get-started-with-Local-Gateway), Trunk types comparison: certificate-based trunk notes. Checked 2026-10-02.
[^48]: A certificate-based Webex Calling Local Gateway trunk authenticates by certificate with LGW FQDN verification, and every SIP transaction the gateway starts toward Webex Calling must carry the gateway FQDN in the Contact header. Source: [Get started with Local Gateway](https://help.webex.com/en-us/article/t9xctu/Get-started-with-Local-Gateway), Trunk types comparison: certificate-based trunk. Checked 2026-10-02.
[^49]: Certificate-based Webex Calling Local Gateway trunks support several SBC vendors (Cisco CUBE, Oracle, Ribbon, AudioCodes, anynode and Italtel), not only CUBE. Source: [Get started with Local Gateway](https://help.webex.com/en-us/article/t9xctu/Get-started-with-Local-Gateway), Trunk types comparison: supported devices row. Checked 2026-10-02.
[^50]: For a certificate-based Local Gateway, a public CA from Cisco's supported list must sign the device certificate, and its CN or one SAN must equal the FQDN configured in Control Hub. Source: [Configure Local Gateway on Cisco IOS XE for Webex Calling](https://help.webex.com/en-us/article/jr1i3r/Configure-Local-Gateway-on-Cisco-IOS-XE-for-Webex-Calling), Certificate-based Local Gateway: certificate requirements. Checked 2026-10-02.
[^51]: A certificate-based Webex Calling Local Gateway needs a public internet-facing address (public IP or static NAT), public DNS A or SRV records, and a claimed domain. Source: [Get started with Local Gateway](https://help.webex.com/en-us/article/t9xctu/Get-started-with-Local-Gateway), Trunk types comparison: network and domain requirements rows. Checked 2026-10-02.
[^52]: Cisco positions registration-based Webex Calling Local Gateway trunks for up to 250 concurrent calls per trunk and certificate-based trunks for more than 250. Source: [Get started with Local Gateway](https://help.webex.com/en-us/article/t9xctu/Get-started-with-Local-Gateway), Trunk types comparison: concurrent calls row. Checked 2026-10-02.
[^53]: A registration-based Webex Calling Local Gateway works behind any NAT or a public IP, with dynamic NAT preferred, because the firewall pinholes are opened by the gateway's outbound registration. Source: [Get started with Local Gateway](https://help.webex.com/en-us/article/t9xctu/Get-started-with-Local-Gateway), Trunk types comparison: network requirements row. Checked 2026-10-02.
[^54]: When a registration-based Local Gateway trunk is created in Control Hub, Webex Calling issues the registrar domain, line/port, authentication username and password, outbound proxy SRV address and trunk OTG/DTG value. Source: [Configure Local Gateway on Cisco IOS XE for Webex Calling](https://help.webex.com/en-us/article/jr1i3r/Configure-Local-Gateway-on-Cisco-IOS-XE-for-Webex-Calling), Registration-based Local Gateway: create trunk in Control Hub (trunk information). Checked 2026-10-02.
[^55]: Webex Calling registration-based Local Gateway trunks support only Cisco Unified Border Element (CUBE) as the gateway. Source: [Get started with Local Gateway](https://help.webex.com/en-us/article/t9xctu/Get-started-with-Local-Gateway), Trunk types comparison: supported devices row. Checked 2026-10-02.
[^56]: A registration-based Webex Calling Local Gateway trunk authenticates with SIP digest using a shared username and password for both registration and calls. Source: [Get started with Local Gateway](https://help.webex.com/en-us/article/t9xctu/Get-started-with-Local-Gateway), Trunk types comparison: registration-based trunk. Checked 2026-10-02.
[^57]: Cisco's example registration-based Local Gateway configuration registers over TLS with the sips scheme, a 240-second expiry and refresh ratio 50, so the gateway re-registers about every 120 seconds. Source: [Configure Local Gateway on Cisco IOS XE for Webex Calling](https://help.webex.com/en-us/article/jr1i3r/Configure-Local-Gateway-on-Cisco-IOS-XE-for-Webex-Calling), Registration-based Local Gateway: voice class tenant 100 registrar command. Checked 2026-10-02.
[^58]: For Zoom BYOC-P the SBC certificate must carry the SBC FQDN in CN or SAN (wildcards accepted), include the Server Authentication key usage, and be presented with its full intermediate chain. Source: [BYOC-P or BYOP-P infrastructure requirements](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0079203), Section 'Public Trusted Certificates'. Checked 2026-10-02.
[^59]: Zoom's mTLS for BYOC-P does not validate peer names: certificates are exchanged in the handshake, but Zoom does not check the SBC certificate CN or SAN against an expected hostname or FQDN. Source: [BYOC-P or BYOP-P infrastructure requirements](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0079203), Section 'Public Trusted Certificates' (mTLS note). Checked 2026-10-02.
[^60]: Zoom BYOC-P requires TLS 1.2 signalling and SRTP media between the customer SBC and Zoom when peering over the internet. Source: [BYOC-P or BYOP-P infrastructure requirements](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0079203), Section 'SBC Requirements'. Checked 2026-10-02.