No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Zoom Phone Local Survivability: Zoom Phone’s Hybrid Moment


Zoom's headquarter in California
Image: Sundry Photography -
There’s a lot of talk about hybrid work these days, but most of these conversations focus on where employees work. Deployment models are another aspect of hybrid work, and those have to do where the servers reside. Hybrid deployments that involve cloud and local components can create a more reliable UCaaS experience.
Today, Zoom launched its first hybrid workload called Zoom Phone Local Survivability (ZPLS). Zoom Phone is Zoom’s first application to benefit from its new Zoom Node within its cloud architecture. More applications in the Zoom suite are expected to also leverage the Zoom Node framework. The design intent of Zoom Node is to give customers more control over the availability and usage of Zoom services. Zoom Node is designed as a hub that supports several Zoom workloads (or modules).  The Zoom Phone module, or ZPLS, is designed to provide seamless failover of services, regional compliance, and/or bandwidth optimization.
With ZPLS, Zoom is taking a new approach to a legacy solution known as a survivable branch gateway. Pre-cloud, some enterprises configured their main PBX to also support branch offices. The main office was effectively a cloud provider for the branch locations. A survivable branch office had enough equipment and services that it could “zoom” into action should its connection to the main office fail.
Modern UCaaS services simplify multi-location deployments, but outages are debilitating. A UCaaS outage is usually worse than an outage of networked PBX systems because UCaaS services go completely offline where a local PBX can still at least maintain internal calling services.
Survivable gateways usually involve hardware, but of course, Zoom took a pure-software approach. The ZPLS module loads on a local virtual machine. Each ZPLS module supports up to 5000 Zoom phone users, and multiple modules can be deployed. During normal Zoom Phone operations, Zoom Phone clients and devices connect to Zoom Phone in the cloud and locally to the ZPLS module.
Should the connection to the Zoom Phone cloud fail, the local module takes over. The ZPLS module essentially becomes Zoom Phone ‘in-a-box.’ The ZPLS module will maintain intra-site Zoom Phone calling (station-to-station).  This can be in a building or across buildings on a campus network. The ZPLS module can also be configured to work with an SBC for local calling trunks. ZPLS works with SBCs from Audiocodes, Cisco, Oracle, and Ribbon.
Although ZPLS runs on-premises, it’s just software. The ZPLS module can run on two different VM configurations. The smaller configuration is designed for up to 2000 Zoom Phone users and requires 8 virtual CPUs. The larger module requires 16 vCPUs and supports up to 5000 users. Organizations can mix and match the size of the VMs. Regardless of size, the price to run a module is $400 per module per month. 
The ZPLS modules are managed by the Zoom cloud. Zoom is responsible for upgrades, security, and management. ZPLS is effectively a native Zoom cloud service, or more specifically of the Zoom node in the Zoom cloud. The solution is relatively simple to deploy and highly scalable. Customers can customize their implementation with (or without) leading SBCs. At least one module should be implemented per site if failover survivability is required.
Zoom Phone devices and clients will automatically seek the ZPLS node should an outage occur and automatically return to the Zoom Phone cloud when connectivity is restored.
As the world embraces cloud-delivered services, it’s becoming increasingly clear that service outages are a fact of life. We can’t eliminate outages, but we can mitigate their impacts. “Cloud outages” can and do occur everywhere including the local router, last mile, in the broader network, or at Zoom’s data centers. Seasoned communication pros know to build redundancy wherever possible whenever feasible.
How much redundancy is a personal matter? Some sectors such as healthcare, education, and retail are heavily reliant on telephony services, and will likely adopt ZPLS faster than others. Beyond verticals, any organization that requires or values redundant design should take a look at ZPLS.
The hybrid office conversation needs to extend to resilient architecture. Motivations may vary, but phone users still expect their service to always work -- if for no other reason than to call IT in order to report the phones are down.
Dave Michels is a contributing editor and analyst at TalkingPointz.