# One SBC serving several calling platforms

Canonical: https://warmtransfer.net/knowledge/multi-platform-sbc-design

Last verified: 2026-10-14

Microsoft's Direct Routing certified SBC list and Zoom's certified hardware list for Zoom Phone both include Cisco Unified Border Element and AudioCodes Mediant SBC models[^4][^1][^9][^2]. On Cisco CUBE, a voice class tenant acts as a configuration template for dial-peers, so one platform can hold different SIP settings for each trunk[^8].

## Certification on each platform

Microsoft supports Teams Phone with Direct Routing only when a Microsoft-certified SBC is used, and it may decline support requests that involve non-certified SBCs[^17]. Microsoft's certified list includes Cisco Unified Border Element on Catalyst 8000 Edge Platforms, supported from IOS XE 17.3.2 with 17.6.1a recommended[^4]. The same list includes AudioCodes Mediant SBC models, including Virtual Edition and Cloud Edition, supported at 7.40A.600 with 7.40A.500 recommended for most models[^1]. As of the page update on 2026-09-28, Microsoft states that it is not accepting new nominations for Direct Routing SBC certification until further notice[^26].

Sources disagree on how far Microsoft certification extends beyond the documented firmware[^15][^16]. Sources disagree here: one part of the Microsoft certified SBC page says higher firmware versions are supported as long as the major.minor version is the same[^15]. This is disputed: the closing note on the same page says certification is granted to a major version, so firmware with any number after the major version is supported[^16].

Zoom's certified hardware list for Zoom Phone includes Cisco Unified Border Element at version 17.3.3 under Session Border Controllers[^9]. Zoom's list also includes AudioCodes Mediant SBC models, including Mediant Software SBC VE and CE, at firmware 7.40A.605.092[^2].

For Webex Calling, a registration-based Local Gateway trunk works only with Cisco CUBE, and a certificate-based trunk supports several SBC device types[^38][^33].

See also [Session border controller selection and certification](https://warmtransfer.net/knowledge/sbc-selection).

## Separating trunks on CUBE

On CUBE, a voice class tenant is a configuration template for dial-peers[^8]. When it is bound to VRF interfaces, it can hold different SIP settings for each customer as well as for each trunk[^8]. When a dial-peer references a tenant, CUBE applies configuration in this order: dial-peer, then tenant, then global[^7]. Without a tenant, the order is dial-peer, then global[^7].

A tenant-level listen port requires IOS XE 17.8.1a or later and an interface bind configured for that tenant[^5]. Each listen port and bind combination must be unique across global and tenant configuration, and across secure and nonsecure ports[^3]. Nonsecure tenant listen ports are limited to 5000-5500[^3].

You can configure a tenant listen port only when the associated dial-peers have no active calls[^6]. Changing the bind or tenant configuration closes the associated active connections[^6].

See also [Cisco Unified Border Element configuration and licensing](https://warmtransfer.net/knowledge/cube-configuration).

## Microsoft Teams Direct Routing requirements

For Teams Direct Routing, the SBC FQDN must belong to a verified domain in the Microsoft 365 tenant, and the default *.onmicrosoft.com domain cannot be used[^30].

On an inbound INVITE, the Direct Routing proxy finds the destination tenant from the FQDN in the Contact header[^19]. It tries the full FQDN first and then the FQDN without its host part, and that FQDN must match the certificate CN or SAN[^19]. If an INVITE or OPTIONS sent to the Teams SIP proxy carries an IP address instead of an FQDN as the Contact hostname, the proxy refuses the connection with 403 Forbidden[^23].

For inbound calls, the phone number in the Request-URI and in the From header must include a leading plus sign[^27]. Direct Routing does not support a Delayed Offer INVITE, which is an INVITE without SDP[^25].

Direct Routing picks its transfer method from the capabilities the SBC advertises[^28]. If the SBC lists REFER in its Allow header, the proxy sends REFER to the SBC to complete the transfer[^28]. Otherwise, the proxy completes the transfer itself[^28].

Microsoft tells administrators to make sure the SBC does not use Replaces headers in SIP requests, because Direct Routing rejects SIP requests that define Replaces headers[^29]. The same SIP protocol page also states that the SBC must support Invite with Replaces[^31].

### One SBC serving several Teams tenants

Direct Routing lets one SBC serve multiple Microsoft 365 tenants, and Microsoft describes this scenario as designed for Microsoft partners and PSTN carriers[^24]. In this hosting scenario, the carrier requests a certificate with a CN and/or SAN of *.base_domain, for example *.sbc1.adatum.biz, to authenticate connections to multiple tenants from one SBC[^22]. Each customer subdomain must match both the FQDN of the trunk configured for that customer and the FQDN the SBC puts in the Contact header when it sends the INVITE[^32].

A derived trunk in a customer tenant takes all of its configuration from the carrier trunk[^21]. SIP OPTIONS are sent only to the carrier trunk FQDN, and the carrier trunk's health status applies to every derived trunk[^21]. Number translation rules applied on a carrier trunk do not apply to derived trunks[^20]. Microsoft lists this as a known issue, so translation rules must be created in each customer tenant[^20].

See also [Troubleshooting Teams Direct Routing](https://warmtransfer.net/knowledge/teams-direct-routing-troubleshooting).

## Webex Calling Local Gateway requirements

In Cisco's Local Gateway configuration for Webex Calling, voice class tenants hold trunk-specific configuration[^40]. Tenant 100 carries the Webex Calling registrar, credentials, sip-server and outbound proxy, and the Webex dial-peer inherits these settings[^40]. For a registration-based Local Gateway, only SRV-based addresses are supported on the tenant side that connects to Webex Calling[^39].

Registration-based and certificate-based trunks have different requirements and limits[^35][^38][^33]:

- A registration-based Local Gateway on Cisco IOS XE requires 17.6.1a or later[^35]. It supports up to 250 concurrent calls per trunk, works only with Cisco CUBE, and uses digest authentication[^38].
- A certificate-based Local Gateway requires 17.9.1a or later and a device certificate signed by a public CA[^35]. It supports more than 250 concurrent calls per trunk and several SBC device types, using certificate authentication with Local Gateway FQDN verification[^33].

Wildcard certificates are not supported for the Local Gateway, which needs a certificate signed by one of the listed certificate authorities[^36]. Webex Calling currently does not support running both CME and Local Gateway on a single instance of vCUBE[^37].

In Cisco's Local Gateway design with an existing Unified CM, all calls are routed through Unified CM[^41]. Calls from Unified CM on port 5060 go to the PSTN, calls on port 5065 go to Webex Calling, and each path uses its own dial-peer group[^41].

See also [Local Gateway design and configuration](https://warmtransfer.net/knowledge/webex-calling-local-gateway). See also [Unified CM and Webex Calling coexistence during a migration](https://warmtransfer.net/knowledge/cucm-webex-calling-coexistence).

## Zoom BYOC-P requirements

In the Zoom admin portal, you add a BYOC-P SBC by display name, public IP address and port, and TLS is the only supported transport[^54]. For peering over the internet, the SBC must support TLS 1.2, SRTP, SIP (RFC 3261), RFC 2833 DTMF and RFC 5853 topology hiding[^55]. Zoom does not accept SDP offers or media streams that specify an SRTP Media Key Identifier (MKI)[^51].

Zoom Phone endpoints always initiate connectivity into Zoom data centers, but BYOC-P SBCs require bidirectional connectivity[^53].

Zoom BYOC-P accepts wildcard SBC certificates when the appropriate domain names are configured[^56]. The certificate must come from a listed CA and include the SBC FQDN in its CN or SAN, and the SBC must present the full chain[^56]. During mutual TLS, Zoom does not validate the CN or SAN of the SBC certificate against an expected hostname or FQDN[^48].

The SBC must send INVITEs with an SDP offer (early offer), and an INVITE without SDP receives 488 Not Acceptable Here[^46]. Calls should carry the destination in E.164 format, and Zoom accepts SIP URIs but not tel: or sips: URIs[^45]. Zoom BYOC-P does not use REFER or SUBSCRIBE/NOTIFY toward the SBC, and it does not use the Replaces header for redirection, even though REFER appears in its Allow header[^49].

When OPTIONS keepalive is enabled, Zoom sends SIP OPTIONS to the SBC every 30 seconds[^50]. Zoom marks the trunk down after 4 consecutive failures, which means detection takes about 90-120 seconds, and recovery needs 3 consecutive successes[^50]. Zoom fails over from an SBC when OPTIONS marks it down or when it answers an INVITE with 403, 408, 480, 488, 500, 502, 503, 504 or 606[^47]. Zoom then tries the other active SBCs in the route group, then the backup route group, then the backup region[^47].

A route group selects the region whose Zoom data centers terminate the SBC trunks, and creating one may take up to 48 hours to complete[^52]. Phone numbers must be assigned to a Common SIP Group to enable both inbound and outbound calling[^44].

Any SBC certified for Zoom Phone can also be used with the Zoom Phone Local Survivability module, so existing BYOC customers do not need a separate SBC for survivability[^57]. With Zoom Phone Local Survivability, the SBC must route inbound PSTN calls to Zoom data centers as its first and second choices, and to the ZPLS module only as its third[^58].

See also [Zoom Phone BYOC and Provider Exchange](https://warmtransfer.net/knowledge/zoom-phone-byoc). See also [Remote site survivability patterns](https://warmtransfer.net/knowledge/survivability-remote-site).

## Platform differences

Teams Direct Routing and Zoom BYOC-P state different codec support[^18][^43]:

| Platform | Codec statement |
|---|---|
| Teams Direct Routing | Supports SILK, G.711, G.722, G.729 and AMR-WB (AMR-WB non-bypass only) between Teams and the SBC, and Opus is not in the list[^18]. |
| Zoom BYOC-P | Prefers Opus, G.722, G.711 A-law/mu-law and G.729, in that order, and on inbound calls uses the first encryption standard and codec offered by the SBC that Zoom supports[^43]. |

Both Teams and Zoom require an SDP offer in the INVITE[^25][^46]. Teams does not support a Delayed Offer INVITE[^25]. Zoom answers an INVITE without SDP with 488 Not Acceptable Here[^46].

Wildcard certificate handling differs between Teams, Webex Calling and Zoom[^22][^36][^56]:

- The Teams carrier hosting scenario uses a *.base_domain certificate[^22].
- The Webex Calling Local Gateway does not support wildcard certificates[^36].
- Zoom BYOC-P accepts wildcard certificates under stated conditions[^56].

Identity checks also differ between Teams and Zoom[^19][^48]. Teams matches the Contact FQDN against the certificate CN or SAN[^19]. Zoom does not validate the CN or SAN against an expected hostname during mutual TLS[^48].

Transfer handling differs between Teams and Zoom as well[^28][^49]. Teams sends REFER to the SBC when the SBC lists REFER in its Allow header[^28]. Zoom does not use REFER toward the SBC[^49].

Number formats differ between Teams and Zoom in a similar way[^27][^45]. Teams requires a leading plus sign in the Request-URI and From header[^27]. Zoom expects E.164 destinations in SIP URIs[^45].

See also [SIP trunk redundancy and failover design](https://warmtransfer.net/knowledge/sip-trunk-redundancy-design). See also [SIP trunk capacity and concurrent call planning](https://warmtransfer.net/knowledge/sip-trunk-capacity-planning).

## Applicability

Applies to: Microsoft Teams Phone, Cisco Unified Border Element, AudioCodes Mediant SBC, Cisco Webex Calling, and Zoom Phone. Deployments: on-premises, hybrid, and multi-tenant. Sources checked 2026-10-14. Microsoft lists Cisco Unified Border Element on Catalyst 8000 Edge Platforms as supported from IOS XE 17.3.2, with 17.6.1a recommended[^4]. Microsoft lists AudioCodes Mediant SBC models at 7.40A.600, with 7.40A.500 recommended for most models[^1]. Zoom lists Cisco Unified Border Element at 17.3.3 and AudioCodes Mediant SBC models at 7.40A.605.092[^9][^2]. Webex Calling Local Gateway on IOS XE requires 17.6.1a or later for registration-based trunks and 17.9.1a or later for certificate-based trunks[^35]. CUBE tenant-level listen ports require IOS XE 17.8.1a or later[^5]. Webex for Government does not currently support any third-party SBC as a Local Gateway, and it does not support registration-based Local Gateway trunks[^42].

## What remains uncertain

Sources disagree on whether Microsoft certification covers later firmware within the same major.minor version or within the same major version[^15][^16]. Microsoft's Direct Routing documentation says that Direct Routing rejects SIP requests that define Replaces headers, and it also says that the SBC must support Invite with Replaces, so verify the current behavior with Microsoft[^29][^31]. Whether a single SBC instance can carry Teams Direct Routing, Webex Calling and Zoom BYOC-P trunks at the same time under each vendor's support terms is not covered by the sources below. The total concurrent call capacity of one SBC shared across several calling platforms is not covered by the sources below.

## Sources

[^1]: Microsoft's Direct Routing certified SBC list includes AudioCodes Mediant SBC models, including Virtual Edition and Cloud Edition, supported at 7.40A.600 with 7.40A.500 recommended for most models. Source: [Session Border Controllers certified for Direct Routing - Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-border-controllers), Certified SBC vendors table, AudioCodes rows. Checked 2026-10-14.
[^2]: Zoom's certified hardware list includes AudioCodes Mediant SBC models, including Mediant Software SBC VE and CE, at firmware 7.40A.605.092. Source: [Zoom Phone certified hardware](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0060242), Session Border Controllers > AudioCodes. Checked 2026-10-14.
[^3]: On CUBE, each listen port and bind combination must be unique across global and tenant configuration and across secure and nonsecure ports, and nonsecure tenant listen ports are limited to 5000-5500. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Configure Multiple Trunks Using Tenants](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-multi-tenants.html), Restrictions for listen port per tenant. Checked 2026-10-14.
[^4]: Microsoft's Direct Routing certified SBC list includes Cisco Unified Border Element on Catalyst 8000 Edge Platforms, supported from IOS XE 17.3.2 with 17.6.1a recommended. Source: [Session Border Controllers certified for Direct Routing - Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-border-controllers), Certified SBC vendors table, Cisco rows. Checked 2026-10-14.
[^5]: A tenant-level listen port on CUBE requires IOS XE 17.8.1a or later and an interface bind configured for that tenant. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Configure Multiple Trunks Using Tenants](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-multi-tenants.html), Configure listen port per tenant; Feature information. Checked 2026-10-14.
[^6]: On CUBE, a tenant listen port can be configured only when the associated dial-peers have no active calls, and changing the bind or tenant configuration closes the associated active connections. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Configure Multiple Trunks Using Tenants](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-multi-tenants.html), Restrictions for listen port per tenant. Checked 2026-10-14.
[^7]: On CUBE, when a dial-peer references a tenant, configuration is applied in the order dial-peer, then tenant, then global; without a tenant the order is dial-peer, then global. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Configure Multiple Trunks Using Tenants](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-multi-tenants.html), Precedence of configuration. Checked 2026-10-14.
[^8]: On Cisco CUBE, a voice class tenant acts as a configuration template for dial-peers, letting one platform hold different SIP settings for each trunk and, when bound to VRF interfaces, for each customer. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Configure Multiple Trunks Using Tenants](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-multi-tenants.html), Multi-tenancy overview. Checked 2026-10-14.
[^9]: Zoom's certified hardware list for Zoom Phone includes Cisco Unified Border Element at version 17.3.3 under Session Border Controllers. Source: [Zoom Phone certified hardware](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0060242), Session Border Controllers > Cisco. Checked 2026-10-14.
[^10]: A single SBC that serves Teams hosting, Zoom BYOC-P and a certificate-based Webex Calling Local Gateway cannot use only a wildcard certificate: Webex LGW rejects wildcards, so the Webex trunk needs its own non-wildcard identity even if Teams and Zoom share a wildcard (inferred). Source: [Get started with Local Gateway](https://help.webex.com/en-us/article/t9xctu/Get-started-with-Local-Gateway), Certificate and TLS requirements; combined with ms-learn-dr-sbc-multiple-tenants 'Register a base domain and subdomains - Overview' and zoom-kb0079203 'Certificate requirements'. Checked 2026-10-14.
[^11]: On CUBE, the natural way to host Teams, Zoom and Webex trunks side by side is one voice class tenant per platform trunk, with tenant-level bind, listen port and TLS profile (17.8.1a or later). Cisco's HTML documentation does not show this three-platform combination (inferred). Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Configure Multiple Trunks Using Tenants](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-multi-tenants.html), Multi-tenancy overview; Configure listen port per tenant. Checked 2026-10-14.
[^12]: Teams Direct Routing and Zoom BYOC-P both reject INVITEs without SDP, so an SBC carrying calls into either platform from a delayed-offer source must convert delayed offer to early offer on that leg (inferred). Source: [BYOC-P or BYOP-P call processing](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0079205), Incoming calls to Zoom (SDP requirements); combined with ms-learn-dr-protocols-sip 'Non-media bypass flow' note. Checked 2026-10-14.
[^13]: Because Teams sends REFER to an SBC that advertises it while Zoom BYOC-P never sends REFER, an SBC bridging Teams and Zoom must complete Teams-originated transfers itself or stop advertising REFER on the Teams leg. The SBC cannot simply relay REFER to Zoom (inferred). Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Call transfer; combined with zoom-kb0079205 'Transfer / REFER handling'. Checked 2026-10-14.
[^14]: Cisco CUBE and AudioCodes Mediant appear on the Teams certified list, the Zoom certified list and the Webex LGW material, but at different versions, so a shared SBC's firmware must fall within every platform's listed range at once (inferred). Source: [Session Border Controllers certified for Direct Routing - Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-border-controllers), Certified SBC vendors table; combined with zoom-kb0060242 'Session Border Controllers' and cisco-help-t9xctu third-party table. Checked 2026-10-14.
[^15]: The Microsoft certified SBC page says firmware versions higher than those documented are supported as long as the major.minor version is the same (disputed). Source: [Session Border Controllers certified for Direct Routing - Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-border-controllers), Introductory Note, last paragraph. Checked 2026-10-14.
[^16]: The Microsoft certified SBC page's closing note says certification is granted to a major version, so firmware with any number after the major version is supported (disputed). Source: [Session Border Controllers certified for Direct Routing - Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-border-controllers), Direct Routing and analog devices interoperability, closing note. Checked 2026-10-14.
[^17]: Microsoft supports Teams Phone with Direct Routing only when a Microsoft-certified SBC is used, and may decline support requests involving non-certified SBCs. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), Support boundaries; Supported Session Border Controllers (SBCs). Checked 2026-10-14.
[^18]: Direct Routing supports SILK, G.711, G.722, G.729 and AMR-WB (AMR-WB non-bypass only) between Teams and the SBC; Opus is not in the list. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), Supported codecs. Checked 2026-10-14.
[^19]: On an inbound INVITE, the Teams Direct Routing proxy finds the destination tenant from the FQDN in the Contact header (full FQDN first, then the FQDN without its host part), and that FQDN must match the certificate CN or SAN. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Processing the incoming request: finding the tenant and user, steps 1-3. Checked 2026-10-14.
[^20]: Number translation rules applied on a Teams carrier trunk do not apply to derived trunks. Microsoft lists this as a known issue, so translation rules must be created in each customer tenant. Source: [Configure a Session Border Controller for multiple tenants](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-sbc-multiple-tenants), Create a trunk and provision users > Note after the provisioning examples. Checked 2026-10-14.
[^21]: In the Teams carrier model, a derived trunk in a customer tenant takes all of its configuration from the carrier trunk. SIP OPTIONS are sent only to the carrier trunk FQDN, and its health status applies to every derived trunk. Source: [Configure a Session Border Controller for multiple tenants](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-sbc-multiple-tenants), Create a trunk and provision users > Provisioning logic and example. Checked 2026-10-14.
[^22]: For the Teams SBC hosting scenario, the carrier requests a certificate with CN and/or SAN of *.base_domain (for example *.sbc1.adatum.biz) to authenticate connections to multiple tenants from one SBC. Source: [Configure a Session Border Controller for multiple tenants](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-sbc-multiple-tenants), Register a base domain and subdomains - Overview. Checked 2026-10-14.
[^23]: If an INVITE or OPTIONS sent to the Teams SIP proxy carries an IP address rather than an FQDN as the Contact hostname, the connection is refused with 403 Forbidden. 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. Checked 2026-10-14.
[^24]: Direct Routing lets one SBC serve multiple Microsoft 365 tenants, and Microsoft describes this scenario as designed for Microsoft partners and PSTN carriers. Source: [Configure a Session Border Controller for multiple tenants](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-sbc-multiple-tenants), Introduction and first Note. Checked 2026-10-14.
[^25]: Teams Direct Routing does not support a Delayed Offer INVITE, meaning an INVITE without SDP. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Inbound call: SIP dialog description > Non-media bypass flow (note). Checked 2026-10-14.
[^26]: As of the page update on 2026-09-28, Microsoft states it is not accepting new nominations for Direct Routing SBC certification until further notice. Source: [Session Border Controllers certified for Direct Routing - Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-border-controllers), Paragraph before 'Certified SBC vendors'. Checked 2026-10-14.
[^27]: For inbound calls to Teams Direct Routing, the phone number in the Request-URI and in the From header must include a leading plus sign. 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 > Request-URI; From Header. Checked 2026-10-14.
[^28]: Teams Direct Routing picks its transfer method from the SBC's advertised capabilities: if the SBC lists REFER in Allow, the proxy sends REFER to the SBC to complete the transfer; otherwise the proxy completes the transfer itself. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Call transfer. Checked 2026-10-14.
[^29]: Microsoft tells administrators to make sure the SBC does not use Replaces headers in SIP requests, because Direct Routing rejects SIP requests that define Replaces headers. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Processing the incoming request: finding the tenant and user (note, third bullet). Checked 2026-10-14.
[^30]: For Teams Direct Routing the SBC FQDN must belong to a verified domain in the Microsoft 365 tenant; the default *.onmicrosoft.com domain cannot be used. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), SBC domain names. Checked 2026-10-14.
[^31]: The Teams Direct Routing SIP protocol page states that the SBC must support Invite with Replaces. Source: [Teams Phone System Direct Routing: SIP protocol](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip), Replaces option. Checked 2026-10-14.
[^32]: In the Teams hosting model, each customer subdomain must match both the FQDN of the trunk configured for that customer and the FQDN the SBC puts in the Contact header when it sends the INVITE. Source: [Configure a Session Border Controller for multiple tenants](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-sbc-multiple-tenants), Register a base domain and subdomains - Overview. Checked 2026-10-14.
[^33]: A certificate-based Webex Calling Local Gateway trunk supports more than 250 concurrent calls per trunk and several SBC device types, using certificate authentication with Local Gateway FQDN verification. Source: [Get started with Local Gateway](https://help.webex.com/en-us/article/t9xctu/Get-started-with-Local-Gateway), Registration-based versus certificate-based trunk comparison. Checked 2026-10-14.
[^34]: The Webex Calling Local Gateway third-party SBC table lists AudioCodes Mediant CE, VE and appliances as tested at 7.40A.250.440 for certificate-based trunks, with a noted ICE interoperability limitation. Source: [Get started with Local Gateway](https://help.webex.com/en-us/article/t9xctu/Get-started-with-Local-Gateway), Third-party SBC support table (certificate-based). Checked 2026-10-14.
[^35]: A registration-based Webex Calling Local Gateway on Cisco IOS XE requires 17.6.1a or later; a certificate-based one requires 17.9.1a or later and a device certificate signed by a public CA. 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), Configure your Local Gateway (registration-based and certificate-based prerequisites). Checked 2026-10-14.
[^36]: Wildcard certificates are not supported for the Webex Calling Local Gateway; the gateway needs a certificate signed by one of the listed certificate authorities. Source: [Get started with Local Gateway](https://help.webex.com/en-us/article/t9xctu/Get-started-with-Local-Gateway), Certificate and TLS requirements for certificate-based trunks. Checked 2026-10-14.
[^37]: Webex Calling currently does not support running both CME and Local Gateway on a single instance of vCUBE. Source: [Get started with Local Gateway](https://help.webex.com/en-us/article/t9xctu/Get-started-with-Local-Gateway), Local Gateway requirements / limitations. Checked 2026-10-14.
[^38]: A registration-based Webex Calling Local Gateway trunk supports up to 250 concurrent calls per trunk, works only with Cisco CUBE, and uses digest authentication. Source: [Get started with Local Gateway](https://help.webex.com/en-us/article/t9xctu/Get-started-with-Local-Gateway), Registration-based versus certificate-based trunk comparison. Checked 2026-10-14.
[^39]: For a registration-based Webex Calling Local Gateway, only SRV-based addresses are supported on the tenant side that connects to Webex Calling. 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), Configure Webex Calling trunk (registration-based), tenant configuration note. Checked 2026-10-14.
[^40]: In Cisco's Local Gateway configuration for Webex Calling, voice class tenants hold trunk-specific configuration: tenant 100 carries the Webex Calling registrar, credentials, sip-server and outbound proxy, and the Webex dial-peer inherits them. 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), Design overview; Configure Webex Calling trunk. Checked 2026-10-14.
[^41]: In Cisco's Local Gateway design with an existing Unified CM, all calls are routed through Unified CM: calls from Unified CM on port 5060 go to the PSTN and calls on port 5065 go to Webex Calling, using separate dial-peer groups for each path. 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), Configure Local Gateway with an existing Unified CM environment. Checked 2026-10-14.
[^42]: Webex for Government does not currently support any third-party SBC as a Local Gateway, and does not support registration-based Local Gateway trunks. 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), Configure your Local Gateway; third-party SBC note. Checked 2026-10-14.
[^43]: Zoom BYOC-P prefers Opus, G.722, G.711 A-law/mu-law and G.729, in that order, and on inbound calls uses the first encryption standard and codec offered by the SBC that Zoom supports. Source: [BYOC-P or BYOP-P call processing](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0079205), Audio codecs. Checked 2026-10-14.
[^44]: For Zoom BYOC-P, phone numbers must be assigned to a Common SIP Group to enable both inbound and outbound calling. Source: [BYOC-P or BYOP-P configuration guide](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0083637), Assign SIP Groups to phone numbers. Checked 2026-10-14.
[^45]: Zoom BYOC calls should carry the destination in E.164 format; Zoom accepts SIP URIs but not tel: or sips: URIs. Source: [BYOC-P or BYOP-P call processing](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0079205), Incoming calls to Zoom (number format). Checked 2026-10-14.
[^46]: Zoom BYOC-P requires the SBC to send INVITEs with an SDP offer (early offer); an INVITE without SDP receives 488 Not Acceptable Here. Source: [BYOC-P or BYOP-P call processing](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0079205), Incoming calls to Zoom (SDP requirements). Checked 2026-10-14.
[^47]: Zoom fails over from an SBC when OPTIONS marks it down or when it answers an INVITE with 403, 408, 480, 488, 500, 502, 503, 504 or 606. It then tries the other active SBCs in the route group, then the backup route group, then the backup region. Source: [BYOC-P or BYOP-P call processing](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0079205), Failover routing. Checked 2026-10-14.
[^48]: During mutual TLS, Zoom does not validate the CN or SAN of the SBC certificate 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), Certificate requirements (mutual TLS hostname validation). Checked 2026-10-14.
[^49]: Zoom BYOC-P does not use REFER or SUBSCRIBE/NOTIFY toward the SBC, and does not use the Replaces header for redirection, even though REFER appears in its Allow header. Source: [BYOC-P or BYOP-P call processing](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0079205), Transfer / REFER handling. Checked 2026-10-14.
[^50]: When enabled, Zoom sends SIP OPTIONS to the SBC every 30 seconds and marks the trunk down after four consecutive failures (detection about 90-120 seconds); recovery needs three consecutive successes. Source: [BYOC-P or BYOP-P call processing](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0079205), Options Keepalive. Checked 2026-10-14.
[^51]: Zoom does not accept SDP offers or media streams that specify an SRTP Media Key Identifier (MKI). Source: [BYOC-P or BYOP-P infrastructure requirements](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0079203), Cipher requirements. Checked 2026-10-14.
[^52]: Creating a Zoom BYOC-P route group, which selects the region whose Zoom data centers terminate the SBC trunks, may take up to 48 hours to complete. Source: [BYOC-P or BYOP-P configuration guide](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0083637), How to manage Route Groups. Checked 2026-10-14.
[^53]: Zoom Phone endpoints always initiate connectivity into Zoom data centers, but BYOC-P SBCs require bidirectional connectivity. Source: [Bring Your Own Carrier - Premises Peering (BYOC-P) | Zoom Technical Library](https://library.zoom.com/zoom-workplace/zoom-phone/zoom-phone-bluepaper/overview/bring-your-own-carrier-premises-peering-byoc-p), Zoom Phone Premises Peering Network Design, Note. Checked 2026-10-14.
[^54]: In the Zoom admin portal, a BYOC-P SBC is added by display name, public IP address and port, and only TLS is supported as the transport. Source: [BYOC-P or BYOP-P configuration guide](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0083637), Add a Session Border Controller (SBC). Checked 2026-10-14.
[^55]: For Zoom BYOC-P peering over the internet, the SBC must support TLS 1.2 and SRTP, plus SIP (RFC 3261), RFC 2833 DTMF and RFC 5853 topology hiding. Source: [BYOC-P or BYOP-P infrastructure requirements](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0079203), Session Border Controllers (SBCs) requirements list. Checked 2026-10-14.
[^56]: Zoom BYOC-P accepts wildcard SBC certificates when the appropriate domain names are configured, provided the certificate comes from a listed CA, includes the SBC FQDN in CN or SAN, and the SBC presents the full chain. Source: [BYOC-P or BYOP-P infrastructure requirements](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0079203), Certificate requirements. Checked 2026-10-14.
[^57]: Any SBC certified for Zoom Phone can also be used with the Zoom Phone Local Survivability module, so existing BYOC customers do not need a separate SBC for survivability. Source: [PSTN Integration Considerations | Zoom Technical Library](https://library.zoom.com/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/pstn-integration-considerations), Any Zoom Phone BYOC-certified SBC can be used. Checked 2026-10-14.
[^58]: With Zoom Phone Local Survivability, the SBC must route inbound PSTN calls to Zoom data centers as its first and second choices and to the ZPLS module only third. Source: [PSTN Integration Considerations | Zoom Technical Library](https://library.zoom.com/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/pstn-integration-considerations), SBCs must route inbound calls to Zoom Phone data centers as first and second routing choices, and the ZPLS module third. Checked 2026-10-14.