Getting started with Zoom Phone Local Survivability service

The Zoom Phone Local Survivability (ZPLS) service module leverages the platform and OS provided by Zoom Node and is distributed as a Linux-based appliance that is spun up on an on-premises VMware ESXi host. Deploying the ZPLS module allows organizations to have an on-premise failover for their Zoom Phone system.

What is the Zoom Phone Survivability service module

Zoom Phone Local Survivability (ZPLS) enables Zoom Phone clients and devices to maintain core phone services during connectivity disruptions to the Zoom Phone data centers. The system automatically handles both failover and recovery - when cloud connectivity is restored, clients and devices seamlessly re-register without requiring any action from administrators or end users.

Use cases for the Local Survivability service

Zoom Phone Local Survivability (ZPLS) serves as a backup solution for strategic locations with large employee populations in a single site or campus. Under normal conditions, Zoom Phone clients connect directly to Zoom Phone data centers, bypassing the ZPLS service module entirely. However, when an outage prevents clients from reaching the data centers, supported clients and devices automatically register with the onsite ZPLS service module. This ensures that internal dialing and core services remain operational during the disruption. Organizations can also maintain PSTN connectivity through an optional Session Border Controller (SBC). Once connectivity to the cloud is restored, clients seamlessly re-register with the data centers, and the ZPLS service module returns to standby mode.

How does the Local Survivability service module work

The placement and deployment of ZPLS service modules depends on understanding sites, which can be managed through the Company Info section of your Zoom Phone settings in the admin portal. Sites are configuration settings that group end users with shared characteristics. Users, devices, and other phone system components may belong to the same site based on factors such as a common access code, geographical location, or default emergency address.

Before deploying ZPLS modules, administrators must plan the network connectivity between users/devices and the ZPLS modules. During an outage, Zoom clients and devices need direct access to the ZPLS modules to maintain service continuity.

Deployment considerations

Single-site setup

The example above illustrates a three-building campus configuration. All locations share a centralized internet breakout point located in Building A. A single ZPLS module has been deployed and should be positioned in the building with the highest concentration of users and devices requiring business continuity.

When the Zoom cloud becomes inaccessible, the ZPLS module can maintain service across all three buildings, provided the campus network's IP connectivity remains operational. To enable this functionality, users at all three locations must be provisioned within a single Phone System Site (in this example, Site "ABC"), which is linked to the ZPLS service module.

The system supports internal dialing within the Site through both short extension calling and contact dialing. Additionally, inbound and outbound PSTN calling capabilities are available when SBC and Route Groups are properly configured.

Multi-site setup

In the previous example, the campus network was considered sufficiently reliable and resilient, eliminating the need for a separate on-site ZPLS module at each location. In contrast, consider a scenario where the connectivity between locations is less robust.

In this scenario, each campus building or location is configured as a separate Zoom Phone site, with its own local users, devices, and ZPLS module. This deployment model offers a key advantage over the centralized approach: telephony service remains operational even if the campus network experiences an outage. PSTN connectivity can also be preserved by provisioning an SBC and PSTN trunks at each location. Customers can also implement a centralized SBC and PSTN architecture, provided the SBC maintains connectivity to each ZPLS during survivability mode.

However, this model has an important limitation. Each ZPLS service module operates independently, unaware of other ZPLS modules deployed across the network. This means that while internal dialing works within each location, cross-location or inter-building dialing will be limited unless a Call Bridge is added into the architecture(explained below).

Another critical design consideration involves the static nature of site assignments in Zoom Phone. When users or devices are added to the system, they are permanently assigned to a "home" site. If a user roams from their home site to a different location, Zoom does not dynamically update their site association. For example, if a user normally based at Building A (home site) temporarily relocates to Building B (roaming site) during an outage, their client will still attempt to connect to the ZPLS module at Building A rather than the local module at Building B. In this situation, service continuity would still depend on the campus network being operational, negating the survivability benefit of the distributed deployment.

Multi-site setup with Call Bridge (Shared database node)

In a multi-site setup, users connected to different ZPLS modules cannot reach each other by default. To address this limitation, organizations can deploy a Call Bridge module. The CallBridge enables communication between users registered to different ZPLS modules during an outage by synchronizing data across all modules. This synchronization ensures that each ZPLS module maintains current user and extension information from other modules, allowing registered users to call each other directly - functionality that would otherwise require routing through an SBC. This, however, requires that the campus network's IP connectivity remains operational.

Multi-site setup with redundancy

ZPLS modules support redundant architecture deployment, enabling sites to implement redundant ZPLS modules. In this configuration, secondary ZPLS modules serve as backups that activate if the primary ZPLS module fails. This redundancy provides critical locations with additional protection against cloud connectivity failures. Organizations can optionally integrate a Call Bridge into this design, which enables users and devices registered to highly available modules to communicate with other sites and users—regardless of whether those remote sites use highly available or single ZPLS module configurations.

Supported Zoom Phone functionality during ZPLS failover

To ensure that BYOC-P numbers remain operational during survivability mode, it is essential that these numbers are correctly routed to ZPLS. Under normal conditions, the SBC directs all calls to the Zoom cloud for call routing. However, in a survivability situation, the SBC must be configured to route calls locally to the ZPLS node instead. This configuration requires defining appropriate routing rules and priorities within the SBC to ensure seamless call delivery both under normal operation and during local survivability.

End-user functionality during periods of cloud service disruption will always be limited when compared to the feature set offered under normal operations due to the majority of features are dependent on the Zoom Cloud. The following features are supported during failover:

ZPLS module also supports forwarding calls for an Auto Receptionist (AR), Call queue (CQ) or Shared Line Groups (SLG) to a Survivable Distribution Group (SDG).

Supported Zoom Phone endpoints

For information on what devices are supported with the Local Survivability service module, please see the following:

End-user experience during failover

Zoom does not support check pointing of active calls when access to the cloud is lost. Users involved in an active call will hear a fast busy tone at the time when the client can no longer reach the Zoom Phone cloud and will need to wait for the failover process to the ZPLS service module to complete before manually re-establishing the call.

The process of failover and fallback is transparent to the End User. They are not required to close and relaunch the client or reboot hardware devices and there is no trigger required to initiate the failover.

Users will see the following banner indicating that they are operating in failover mode: