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.

Once the Zoom Phone cloud is available following a survivability event, an SBC may temporarily attempt to route BYOC numbers to the Zoom cloud while the affected number’s client device is registered to the ZPLS module. Should this occur, call routing will follow the settings for When a Call is Not Answered during this interim period.

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.

Common examples of impacted numbers may include numbers assigned to: Users, Common Areas, Auto Receptions (AR), Shared Line Groups (SLG) and Call Queues (CQ).

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:

1. An internal extension with site code prepended

2. A Zoom-provided PSTN number

3. 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.

To minimize downtime and ensure business continuity, Zoom recommends businesses establish reliable procedures for enabling call forwarding logic from the web portal during a survivability event.

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.

1. An external caller initiates a call to a Zoom Phone-registered number, and is routed across the PSTN.

2. The call is routed to the Zoom Phone cloud, and the dialed phone number is identified as impacted by call forwarding.

If call forwarding is not enabled, Zoom Phone will follow the When a call is not answered logic for that particular user or extension.

1. 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.

2. The call is routed from the PSTN to the survivability SBC.

3. The survivability SBC forwards the call to the ZPLS module.

4. 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.

A registered extension is a short extension without the site code, a long extension with the site code, an assigned Zoom-registered number, or an assigned BYOC number. Administrators should keep in mind the ZPLS module updates this data once every 10 hours.

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.

This section is dedicated to hardware deployment and network design considerations. Refer to the section on deploying ZPLS for step-by-step deployment instructions.

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.