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.
This article covers:
The ZPLS service module does not affect the phone service during normal operations. Phone clients and devices in survivable Phone Sites register to the corresponding ZPLS service module and are able to maintain a subset of Phone features when connectivity to Zoom Phone is lost. When connectivity to the Zoom Phone cloud returns, clients and devices re-register back to the cloud. During the outage neither the administrator nor end user is required to take any action to enable survivability- the failover and fallback process is seamless and automatic.
The survivability appliance is designed to typically serve as a backup plan in strategic locations that house a large number of employees in a single location or campus. During normal operations, Zoom Phone clients communicate with Zoom Phone data centers directly bypassing the ZPLS service module. During an outage when the Zoom Client is unable to connect to the Zoom Phone data centers, supported clients and devices are able to register to an onsite ZPLS service module in order to maintain internal dialing functionality and basic supplementary services. Optionally, PSTN connectivity can be maintained should an SBC and appropriate Route Groups be provisioned. When normal operations have been restored, clients register back to the cloud and the ZPLS service module returns to an idle state.
Critical to the design of when and where to deploy the ZPLS service module(s) is the concept of Sites that can be viewed and added from the Admin portal under the Company Info section of your Zoom Phone settings. Sites within the Zoom Phone System is a configuration setting that enables customers to organize end users with shared characteristics into a single dialing domain. For example, a common access code, geographical location, or default emergency address are possible reasons why users, devices, and other constructs within the Phone System would belong to the same site.
An important consideration before administrators deploys the survivability appliance is that each ZPLS service module can only serve a single site as defined within the Zoom Phones Administration portal and each administratively defined site can only leverage a single ZPLS service module. In other words, there is a 1:1 mapping between Zoom Phone Sites and ZPLS service modules.
Consider a campus environment at an educational or healthcare facility that contains multiple buildings or locations.
In the example above there are three buildings that comprise the campus. Internet breakout for all locations is centralized (Building A). A single ZPLS service module has been deployed and should be located in the Building housing most of the users and devices where business continuity is critical. In the event that the Zoom Cloud is inaccessible, the ZPLS service module is able to provide service for all three buildings on the condition that the IP Connectivity within the Campus Network is still functional. Users at the three locations would need to have been provisioned into a single Phone System Site (in this example Site “ABC”) which is attached to the ZPLS service module. Internal dialing within the Site through short extension calling or contact dialing is supported. Optionally inbound and outbound PSTN calling is functional if SBC and Route Groups are enabled.
In the previous example, the Campus Network was deemed to have sufficient reliability and resiliency to the point that each location did not warrant a separate (on-site) ZPLS service module. Contrast this with a situation whereby the connectivity between locations is less robust.
In the above scenario, each campus building or location maps to its own Phone System Site that contains local users and devices along with a local ZPLS service module. The advantage of this deployment model versus the one discussed earlier is that telephony service can be maintained in the event that the Campus Network suffers an outage. PSTN connectivity could also be maintained if an SBC and PSTN trunks were provisioned at each of the locations. The limitation of this deployment model is related to the reduced scope of the internal dialing domain since each ZPLS service module has no awareness of other ZPLS service modules that have been deployed in the network. While internal dialing within each location is supported, internal dialing between locations/buildings is not supported in this example.
Another consideration that affects the optimal design is the static nature of the association of Zoom Phone constructs to a site. When users or devices are added to the Phone System, a “home” site is statically configured. If a specific user were to roam outside of their home site to a temporary “roaming site”, Zoom does not dynamically adjust the site bound to the user. In the above example, if a user based at Building A (home site) temporarily moves to Building B (roaming site) at the time of an outage, the client would attempt to connect to the ZPLS service module provisioned at the home site or Building A as opposed to the local module at Building B. In this scenario, survivability would still be dependent on the operational status of the Campus Network.
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:
For information on what devices are supported with the Local Survivability service module, please see the following:
Zoom does not support checkpointing 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:
Users will see the following banner once reconnected: