BYOC-P or BYOP-P call processing

Note: This applies to Zoom Phone and Zoom Contact Center.

To provision BYOC-P or BYOP-P, Zoom requires that admins provision SIP Groups, Route Groups, and SBCs within the Zoom web portal. The figure below depicts the overview of how these constructs relate to each other.

In the case of Zoom, if there is no interoperability with a legacy PBX required, then only BYOC-P needs to be enabled at the SBC and Route Group level. Conversely, if the customer is operating in a hybrid environment, the SBC should be enabled for BYOC-P and BYOP-P.

For PBX integration, Zoom's external contacts and Routing Rules should be directed to a SIP Group containing Route Groups with BYOP-P enabled, thereby extending a private dial plan to Zoom.

Route Groups enabled for BYOC-P should be used for third-party PSTN interoperability and will not support a private numbering plan. Administrators must ensure that E.164 numbers are sent to the Zoom cloud.

Table of Contents

Audio codecs

Premises Peering connections, both via the internet or private circuit options, will prefer the following codecs as listed below:

Outbound calls from Zoom

This section details which SIP headers and parameters are used by Zoom when originating calls destined for a SBC.

Note: All headers are examples using fictitious numbers (+14085551212).

Request-URIINVITE sip:+14085551212@1.2.3.4:5061 SIP/2.0

The Request-URI header contains the destination party information. The user portion of this header will be in E164 format for BYOC-P calls. BYOP-P calls can be in localized or E.164 format. URI dialing is not supported.

Via HeaderVia: SIP/2.0/TLS 162.12.233.59:5061;branch=z9hG4bK04B42dcf7dc63f2ea91

The Via header contains the signaling information of originating SBC within the Zoom cloud (along with the unique branch parameter).

From HeaderFrom: "amiller" <sip:+14085551212@7006029031.zoom.us>;tag=gK0420aed1

The user portion of the From header contains the Calling Party information in E.164 format (for BYOP-P calls this could be in either E.164 or localized format).

To HeaderTo: <sip:+14085551212@1.2.3.4>
Allow HeaderAllow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH

The Allowed methods supported by Zoom are shown in the Allow header shown above. Zoom supports the PRACK mechanism for reliable 1XX responses but does not use REFER or SUBSCRIBE/NOTIFY.

Contact HeaderContact: "amiller" <sip:+14085551212@162.12.233.59:5061;transport=tls>
P-Asserted-Identity HeaderP-Asserted-Identity: "amiller" <sip:+14085551212@162.12.233.59:5061>

The Calling Name and Number are populated in both the Contact and P-Asserted-Identity header, The Remote-Party-ID header is not used by Zoom.

Supported HeaderSupported: timer,100rel,precondition,replaces

Zoom supports the PRACK mechanism for Early Media but does not use SIP preconditions or the Replaces header for redirection.

Session ExpiresSession-Expires: 1800

Zoom uses a 30-minute expiration timer for BYOC/P calls. The UAS will be required to refresh the session at the expiration of this timer.

Min-SE:Min-SE: 90

Zoom will accept incoming calls that contain an expiration timer of 90 seconds or more.

Zoom will send an outgoing INVITE method containing the SDP offer (Early Offer). The crypto map and codec list are contained within the SDP offer as shown below.

v=0

o=Sonus_UAC 492860 484112 IN IP4 162.12.233.59

s=SIP Media Capabilities

c=IN IP4 162.12.233.83

t=0 0

m=audio 27862 RTP/SAVP 102 9 0 8 18 101

a=crypto:1 AEAD_AES_256_GCM inline:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

a=crypto:2 AES_256_CM_HMAC_SHA1_80 inline:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

a=crypto:4 AES_CM_128_HMAC_SHA1_32 inline:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

a=rtpmap:102 opus/48000/2

a=fmtp:102 maxplaybackrate=24000; minptime=10; useinbandfec=1; maxaveragebitrate=40000

a=rtpmap:9 G722/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=sendrecv

a=maxptime:20

Incoming calls to Zoom

Zoom requires the SBC to send an INVITE with the SDP offer included (early offer). An INVITE method without the SDP offer will receive the 488 Not Acceptable Here response from Zoom.

Options Keepalive

The SIP OPTIONS method is used by Zoom in order to provide a heartbeat mechanism between each Zoom data center within the specified SIP Zone and the SBC. Depending on the response received to the outgoing SIP OPTIONS, Zoom will mark the status of the SBC as Up or Down, which is depicted within the Route Group and in the Zoom dashboard.

Zoom sends an OPTIONS request to the target IP Address/Port configured in SBC settings every 30 seconds when SIP Options is enabled. Upon receiving a 200 OK response for each OPTIONS request, the SBC status is marked green and subsequently included in the corresponding routing tables.

When the keepalive handshake fails on 4 consecutive occasions, either due to no response or a failure response to OPTIONS, Zoom will determine that the SIP trunk between the relevant Zoom data centers and the SBC is down. This failure detection period consists of 90 seconds plus the interval between the last successful handshake and the first failed handshake. Consequently, the total time required to identify this failure ranges from 90 to 120 seconds. The diagram below demonstrates this sequence of events.

During the 90-120 second interim period before the primary SIP Trunk transitions to "down" status, Zoom continues to route calls from the primary data center to the SBC. Before attempting an alternative path, Zoom will make one additional attempt to resend any outgoing INVITE.

The backup path can be configured to an alternate SBC within the selected Route Group, the backup Route Group, or to the SBC from an alternate Data Center. If these alternate choices are in a "down" status, the call originator will hear a failure message.

When the 90-120 second window has elapsed and Zoom has determined the status from the Data Center to the SBC as "down", calls will cease routing through this SBC. Subsequently, outgoing calls will be directed through the SBC in the backup path, circumventing the primary route. The primary SIP Trunk will only resume handling calls once its status returns to "up".

note icon
The SBC status changes to "up" after three consecutive keep-alive exchanges, which typically takes 60-90 seconds. Subsequently, the status update in the web portal will be reflected within approximately 5 minutes.
Customers have the option to implement the SIP OPTIONS keepalive mechanism from their SBC to Zoom. While this feature is supported, the outcome of this dialog does not affect Zoom's perceived status of the customer SBC. Furthermore, when customers opt to disable the SIP OPTIONS while adding the customer SBC on the Zoom web portal, the status of the SBC will remain unknown. Thus, the SBC will continue to be used for routing calls. In such cases, Zoom will attempt to resend the invite once before proceeding to the next routing option.

Failover routing

Zoom will initiate calls to backup SBCs under the following conditions:

When any of these scenarios occur, Zoom will attempt to reroute the call through an alternate SBC that maintains an active status within the Route Group. If all routes within the Route Group are exhausted, Zoom will then route the call to selected SBCs from the backup region or data center.

The primary and backup data center selection is based on the SIP Zone of the call originator's site. For instance, when a user makes a BYOC call from the "Test Site" configured in SIP Zone "US West (N California)", the San Jose Data Center serves as the primary region, while the Colorado data center functions as the backup region.

When the primary Route Group fails to provide a successful response to the INVITE, the system will utilize the backup Route Group if one is configured. The figure below illustrates a setup with four SBCs, where SBC1 and SBC2 are configured in the Primary Route Group, while SBC3 and SBC4 are provisioned within a backup Route Group.

note icon
Planning the deployment of BYOC-P/BYOP-P is crucial for a successful implementation. Learn more from the following resources: