PSTN Integration Considerations
This section applies to customers who are considering integrating the ZPLS module with an SBC and PSTN connection for additional survivability. Customers who do not plan to integrate the ZPLS module with PSTN connectivity may bypass this section without consequence.
SBC Integration Considerations
SBC Requirements
To integrate an SBC with Zoom for survivability, an SBC must meet the following requirements:
TLS 1.2 and SRTP
Support for Mutual TLS
Session Initiation Protocol (SIP)
DTMF (RFC-2833)
Topology hiding (RFC-5853)
SIP Early Offer (mandatory)
Opus, G.711 μ-law, G.711 A-law and G.729 codecs
PSTN integrations require an SBC and a reliable third-party provider
For PSTN connectivity, customers must provide a session border controller (SBC) connected to either a legacy connection, or a SIP trunk with a cellular or alternate connection (e.g. DSL). Customers should keep in mind that any SIP trunks deployed at the SBC may be dependent on the same internet service that is undergoing an outage. Because of this possibility, customers should consider a reliable, tertiary connection for PSTN connectivity.
Any Zoom Phone BYOC-certified SBC can be used
Any session border controller (SBC) that is certified for Zoom Phone can also be used with the ZPLS module. Customers on an existing Zoom Phone BYOC plan do not require an additional or separate SBC for the purposes of survivability.
Zoom’s DigiCert certificates must be installed on the SBC
In order to establish TLS connectivity to both the ZPLS module and Zoom cloud, Zoom’s DigitCert root and intermediate certificates must be installed on the SBC.
SBCs must route inbound calls to Zoom Phone data centers as first and second routing choices, and the ZPLS module third
Customer SBCs must route inbound calls from the PSTN to primary and secondary SIP zone before attempting the ZPLS module. With this configuration, calls will only route to the ZPLS module during a survivability event, as the SBC and Zoom Phone data centers should otherwise maintain steady connectivity.
Failure to follow this logic may result in call delivery failures, as the ZPLS module cannot route calls to cloud-registered devices.
Outbound calls from the ZPLS module must route to the SBC and PSTN SIP trunk
When survivability mode is active, calls from ZPLS into the SBC must route to the PSTN SIP Trunk to establish external phone connections. All calls to numbers that are not registered to the ZPLS module are sent to the SBC configured for survivability in E.164 format.
Call Forwarding Local Survivability Considerations
During a survivability event, phone numbers provided by Zoom Phone will not be externally reachable unless they are re-routed through call forwarding
During a survivability event, phone numbers provided by Zoom will not be externally reachable from the perspective of the cloud. Consequently, users located within affected locations may be unreachable unless calls to their primary numbers are forwarded to an alternative number associated with an on-premises SBC.
Customers using a on-premises based BYOC do not require advanced configurations, and can bypass call forwarding by adding a tertiary route to their ZPLS module from their SBC
Customers using an on-premises based BYOC plan (i.e., customers that do not use Zoom Phone-registered numbers) do not require advanced configurations to enable call forwarding. Instead, BYOC customers can add a tertiary route to the ZPLS module from the premises-based SBC.
Call forwarding configurations are set by an admin or authorized user from the web portal
An account admin or authorized user can configure call forwarding logic from the web portal through manual entry or a bulk CSV upload.
Users configured for call forwarding will have three assigned numbers
After applying a BYOC number to a user for call forwarding survivability, the client device will be assigned at least three numbers:
An internal extension with site code prepended
A Zoom-provided PSTN number
A BYOC PSTN number
Phone numbers can be forwarded to a maximum of one BYOC number
Each Zoom Phone number can be forwarded to a maximum of one other BYOC number. However, you can forward multiple phone numbers to the same BYOC number.
For example, if John is assigned the phone number X55-555-5555, John’s phone number can be forwarded to his building’s operator number at X99-999-9999. Similarly, John’s coworkers can also have their numbers (X55-555-5554, X55-555-5553, etc.) forwarded to X99-999-9999. Alternatively, each user can have their phone number forwarded to a completely unique number, such as X55-555-5554 routing to X99-999-9998, and X55-555-5553 routing to X99-999-9997. However, no individual user can have their number forwarded to both X99-999-9999 and X99-999-9998.
Call forwarding must remain disabled until a survivability event occurs
Although an administrator can pre-provision call forwarding logic for a site ahead of time, call forwarding functionality must remain disabled until a survivability event occurs. If call forwarding is enabled during routine operations, all inbound calls to a Zoom Phone-registered number will be re-routed to the on-premises SBC and the associated BYOC phone number, bypassing Zoom Phone services. Therefore, to maintain regular Zoom Phone routing, call forwarding must be disabled during routine operations.
Call forwarding can only be enabled by an authorized user or admin with a working internet connection
During a survivability mode event, a site’s internet connection is assumed to be unavailable. However, because call forwarding must remain disabled for standard operation, it can only be enabled by an authorized user or admin with a working internet connection like a phone data plan, or an alternate internet connection within a different location.
Call forwarding rules can apply to entire site or for individual numbers
During a survivability event, an administrator or authorized user can enable call forwarding rules for the entire site or for specific numbers from the web portal.
Once call forwarding is enabled for a user’s phone number, Zoom will not ring a user’s cloud-registered client, even if it maintains an independent cloud connection
When call forwarding is enabled for a Zoom Phone-registered number, Zoom will not attempt to route any call to the user through the cloud. Consequently, even if an impacted user has a cloud-registered device like a mobile phone, if the phone number is marked for call forwarding, all calls will route through the PSTN to the company’s SBC.
For example, a site is experiencing a survivability mode event and a user’s mobile phone is connected to the Zoom Phone cloud through their cellular provider’s data connection. If a user’s phone number is marked for call forwarding, the Zoom Phone cloud will not ring their Zoom Phone number through the mobile app, despite the stable connection. Instead, all calls will continue to route through the PSTN to the customer’s SBC.
If call forwarding is not enabled for a user during a survivability event, incoming calls will follow each user’s call handling preferences
If call forwarding is not enabled during a survivability event, incoming calls will be treated according to the call handling logic for each individual user. If a user does not have a backup phone client registered to the cloud, like a mobile phone, callers will be subject to the rules defined by the When a call is not answered section of call handling preferences.
Call forwarding only applies to incoming PSTN calls
Call forwarding for survivability only applies to calls routed across the PSTN and/or Zoom Phone cloud. Calls originating from Zoom-registered extensions within the same site will attempt to connect through the ZPLS module first, and the PSTN second if an SBC is connected. Calls that cannot connect will otherwise be subject to the treatment defined by the When a call is not answered section of the Call Handling rules within a user’s phone settings.
Call Forwarding Flow
The following diagram details the logic for call forwarding (once enabled) during a survivability event. This logic will remain in effect until call forwarding is disabled or standard operations are restored. However, if call forwarding remains enabled after standard operations are restored, forwarded calls will hairpin from the Zoom Phone cloud, to the SBC, and back to the cloud, before being delivered to a user’s device. For this reason, call forwarding should be disabled promptly after a survivability event.
An external caller initiates a call to a Zoom Phone-registered number, and is routed across the PSTN.
The call is routed to the Zoom Phone cloud, and the dialed phone number is identified as impacted by call forwarding.
Because call forwarding is enabled, Zoom will not attempt to alert the user and will instead redirect the call toward the designated call forwarding number across the PSTN.
The call is routed from the PSTN to the survivability SBC.
The survivability SBC forwards the call to the ZPLS module.
The ZPLS module forwards the call to the user’s registered client(s), if connected.
Emergency Location Identification Number (ELIN) Considerations
An ELIN is a site-exclusive phone number that communicates location information to emergency services when dialed
An Emergency Location Identification Number (ELIN) is a dedicated phone number that is used by Public Safety Answering Points (PSAP) to identify the physical address of a caller when calling emergency services. For this feature, businesses must work with their PSTN service provider to map an address to a telephone number, to help ensure the address is listed within an automatic location identification (ALI) database when the call is received by a PSAP operator.
For example, consider a university campus that spans multiple buildings, with each building represented by a separate Zoom Phone site. If a user dials emergency services during a survivability event from a phone or device associated with the site, emergency services will automatically receive the full address on record for the site, providing the location is configured and up to date with the service provider.
Each site can support multiple ELINs
Customers can assign multiple ELINs to a site for a pool of emergency number resources. In the event of an emergency during a survivability event, this will allow multiple callers to each have a uniquely assigned ELIN, which can help emergency services reach the original caller if returning a call.
Additionally, an ELIN can be assigned to a user or a common area phone, providing a more granular ELIN assignment than the site-level, offering a more precise location for emergency services.
During a survivability event, all emergency calls are replaced by the ELIN
When a user makes an emergency call during a survivability event, the user’s calling number, if one is available, will be replaced with the ELIN that is designated at the site level. This allows users who do not have a direct number to call emergency services and be reachable for callback from the emergency operator.
An ELIN number must be a BYOC number associated with the site’s SBC PSTN trunk
A site’s ELIN must be a BYOC number that is terminated on a PSTN trunk that is located at the site’s failover SBC. No other type of number can be used.
The ZPLS module will automatically route emergency provider calls to the ELIN back to the user’s extension who originally dialed for up to 2 hours
If an emergency operator returns a call to the ELIN, the ZPLS module will route the call back to the original user who made the emergency call. The ZPLS module will continue to route PSAP callbacks to the original caller for up to 2 hours. At this time this functionality is limited to the first caller.
Once a phone number is designated as the ELIN, it cannot be assigned to a user or device
Once an administrator has assigned a BYOC number as the designated ELIN for a site, the BYOC number cannot be assigned to any user or other Zoom Phone entity unless it is unassigned.
Customers are responsible for maintaining and updating physical addresses associated with their ELIN for each site
Zoom does not take responsibility for updating BYOC carriers with physical addresses that correlate to each ELIN. Customers are responsible for ensuring emergency addresses are correctly mapped to the appropriate physical address.
PSTN Routing Considerations
When survivability mode is active, media packets are routed through the ZPLS module
When survivability mode is enabled, clients do not communicate directly with an SBC or other internal clients; instead, media packets are anchored or “hairpinned” through the ZPLS module, with no support for media offloading.
The following diagram depicts the signaling and media path for active internal and external calls.
Calls will attempt to route locally first
Whenever possible, the ZPLS module will attempt to route calls originating from registered Zoom clients to locally registered destinations. Calls are only forwarded to the SBC if the destination contained within the Request URI field of the incoming SIP Invite does not match a registered extension.
During a survivability event, external, outbound calls will display the user’s BYOC number
During a survivability event, external, outbound calls from ZPLS-registered devices will contain the BYOC Calling Number. The following diagram depicts survivability mode call flow for a user:
Returned calls may route to a user’s BYOC number
Because external, outbound calls placed during a survivability event will use a BYOC number, external callers may return a call using a BYOC number instead of a user’s Zoom-registered phone number. If the survivability event is over, calls will route back through the cloud if the correct routing priority is configured. However, if the event is ongoing, the SBC will route the call to the ZPLS module and the client-registered device.
Supported Survivability Codecs
Supported survivability codecs are Opus, G.711 μ-law, G.711 A-law and G.729. Transcoding or transrating of audio codecs is not supported. All parties involved in an active call are required to support the same codec and sampling rate.
Survivability Distribution Group Considerations
This section discusses considerations for Survivability Distribution Groups (SDGs). Customers who do not plan to utilize SDGs or integrate the ZPLS module with PSTN connectivity may bypass this section without consequence.
Survivability Distribution Groups provide nuanced call routing options during a survivability event
Survivability distribution groups (SDGs) provide businesses with nuanced call routing options — like call queues and interactive voice response (IVR) menus — during a survivability event. With SDGs, businesses can continue to support core telephony services and call routing configurations (similar to call queues, auto receptionists, and shared line groups) until standard operations are restored.
SDGs are not the same as standard-operation distribution groups, and must be separately built and maintained
Although SDGs offer similar call routing functionality as standard-operation distribution groups, SDGs are unique and specific to survivability events, and consequently must be separately built and maintained. In other words, SDGs will not inherit the settings or configurations of a standard-operation distribution group (i.e., call queue, auto receptionist, IVR, etc.)
SDGs are best paired with a BYOC-PSTN integration and call forwarding enabled
Although SDGs can provide internal-only support (i.e., non-PSTN calls), they are best paired with a BYOC-PSTN integration. With a PSTN-enabled SDG, once call forwarding is enabled during a survivability event, a main company number can route to the designated SDG phone number, and the call will follow the configured routing profile. This allows a business to provide a consistent call flow experience for external dialers until standard operations are restored.
The following diagram demonstrates the call routing logic for a PSTN-enabled SDG:
SDGs can be customized in the following ways
SDGs support the following options:
Dedicated extension number
Assigned direct inward dial number
Time zone
Business hours
Recorded greetings
Group members
Route to:
User
Interactive voice response (IVR) menu
Group members
Phone number
Call distribution:
Simultaneous
Sequential
Hardware and Networking Considerations
This section discusses hardware and networking considerations for the ZPLS Module, an SBC integration, Zoom clients, and phone devices. After reading this section, you can expect to have an understanding of necessary network communications and configurations for a ZPLS deployment.
ZPLS Module Deployment and Networking Considerations
The ZPLS module requires a static IPv4 address within your network
The ZPLS module should be deployed on an internal LAN with a static IPv4 address accessible to Zoom Phone devices and desktop clients. The ZPLS module does not support IPv6 addresses at this time.
The ZPLS module must maintain periodic HTTPS connections with the Zoom Phone cloud
The ZPLS module requires periodic HTTPS connections with the Zoom Phone cloud to synchronize account and user settings.
In most cases, a ZPLS module can be deployed on an internal LAN within a customer’s network. Alternatively, a DMZ network can be used in some circumstances; however, network administrators must ensure communication is possible through the enterprise firewall. In either case, administrators are required to adjust corporate firewall policy to enable communication between the ZPLS module and the Zoom Cloud.
The ZPLS module must maintain a regular OPTIONS ping with the Zoom Phone cloud
While in an idle state, the ZPLS module must maintain an OPTIONS keepalive ping with the Zoom Phone cloud to monitor connectivity. In the event that both client devices and the ZPLS module within a site lose connectivity with the Zoom Phone cloud, supported clients and devices will register to the ZPLS module using SIP Digest Authentication over TLS v1.2.
SBC Deployment and Networking Considerations
An SBC must be reachable from ZPLS and Zoom cloud whenever possible
Customers should ensure the SBC maintains connectivity with both the ZPLS module and Zoom Phone cloud, whenever possible. Customers can provision a dual-NIC SBC configured with a private and public IPv4 address, or ensure that static 1:1 NAT rules are in place on the edge firewall in addition to opening up of the required ports.
An SBC must maintain TLS and UDP connectivity between the Zoom Phone cloud and the ZPLS module
During routine operations, an SBC must maintain TLS and UDP connectivity to both the Zoom Phone cloud and the associated site’s ZPLS module. This connection is used to route any potential calls to a BYOC-listed phone number through the Zoom Phone cloud. The OPTIONS keepalive mechanism is automatically enabled between ZPLS and the SBC and is optional between the SBC and cloud.
Zoom Clients and Phone Devices Considerations
Clients and devices must be able to discover the site’s ZPLS module within the local area network
Clients and supported devices enabled for phone survivability discover the appropriate failover ZPLS module from the Zoom Phone cloud during the bootup process. However, the module must already be bound to the Phone System Site with an internally discoverable IPv4 address.
Devices should have a static IP or be assigned a private IP via a local DHCP server
To mitigate potential issues, phone devices should be assigned a static or an internal IP via a local DHCP server. If a device is not assigned a static IP, or a DHCP server is not available during a survivability event, phone devices may fail to register.
Clients and devices must maintain regular a OPTIONS ping with the Zoom Phone cloud
Similar to the ZPLS module, supported clients and devices must maintain an OPTIONS keepalive ping to the Zoom Phone cloud to determine data center connectivity status. In the event of an outage, the client continues to send keepalive messages in order to detect the return of the cloud service and initiate resumption of normal operations. This process is automatic and cannot be disabled.
Firewall and Network Data Flow
See the section on Network Ports and Data Flow.
Last updated
Was this helpful?