Maintain Connectivity Even If Your Network Goes Down

As customers make their journey toward a Unified Communications as a Service (UCaaS) platform, Zoom has rapidly been innovating. It recently surpassed the 4 million seat mark for Phone. At the same time, Zoom is incorporating important architecture for customers whose critical calling needs require more than UCaaS alone. Zoom Phone Local Survivability (ZPLS) now allows peace of mind through coverage during a cloud or internet outage.

ZPLS allows you to maintain a subset of Zoom Phone features when connectivity is lost. This feature is layered on the Zoom Node architecture, operating seamlessly and automatically, and it doesn’t require administrative intervention during the failover process. Once connectivity is restored to the Zoom Phone cloud, the clients and devices reregister on the cloud.

Planning is crucial when deploying this technology. ZPLS has robust support from a public switched telephone network (PSTN) model perspective. You can forward native Zoom PSTN numbers to a trunk on a local session border controller (SBC) within the admin portal. You also can easily bring your own carrier or use Zoom’s cloud peering carrier program, Provider Exchange. This type of support allows you to make the proper choice for your organization without sacrificing the ability to use ZPLS. This is a differentiator in the market, and I like how Zoom gives its customers options.

ZPLS relies specifically on the site configuration in Zoom Phone. If you look at a large university or healthcare campus, site configuration can vary greatly depending on underlying networking architecture or how locations dial one another.

An important design consideration is that each ZPLS module can only serve a single site as defined within the Zoom Phones Administration portal, and each site can only leverage a single ZPLS module. There is a 1:1 mapping between Zoom Phone Sites and ZPLS modules. That shouldn’t be an issue for most customers though, with each node supporting up to 5,000 registrations. I will demonstrate what this mapping looks like in a couple different scenarios.

In the first topology pictured below, you have three buildings that constitute a campus. Internet is centralized (Building A) and dialing intra-site encompasses all the buildings. In this example, a single ZPLS node is sufficient to allow these locations to function. This assumes the locations maintain network connectivity to one another in an internet outage scenario. Other considerations include backup PSTN connectivity capabilities and the number of devices/users that require calling during an outage.

In the next topology, each campus building maps to its own Phone System Site, which contains users and devices, along with a local ZPLS module. The advantage of this design is that telephony service can be maintained if the campus network suffers an outage. PSTN connectivity can be maintained if an SBC and PSTN trunks are provisioned at each location with a ZPLS node. However, there is a limitation when the internal dialing domain is split between each building.

Each ZPLS module can only service its respective location, and there is no awareness of the other nodes. Internal dialing within each location is supported in this case, but internal dialing between locations/buildings in the campus is not supported in this example. Since the client can cache 25,000 contact entries, users in a failover scenario can simply choose to dial the PSTN number. This model scales better from a capacity perspective, allowing 5,000 registrations per site.

I believe Zoom has done a great job incorporating critical features at launch. The experience for both callers and end users is significantly more feature rich than other UCaaS providers in this space. Zoom supports a wide range of devices and registrations per node, and ZPLS is significantly less complex to implement when compared to other solutions.

Supported features include:

• Internal extension dialing
• Dial by name
• Contact search/calling
• Dial from call history (in failover, call history is uploaded to Zoom when service resumes)
• Inbound/outbound PSTN (assumes SBC and survivable PSTN connectivity)
• Hold/resume
• Mute/unmute
• Dual tone multi frequency (RFC 2833)
• Consult transfer
• Blind transfer
• Call park
• Ad hoc three-way conference
• Emergency calling with PSAP callback

Supported hardware/software includes:

•  Zoom Client for Windows and Mac
• Poly VVX and CCX devices
• Yealink models that are not end of life
• AudioCodes MP1288 ATA

Zoom has done a superb job with ZPLS, however, there are a few minor items to consider.

• Each node can only support the first 2,000 or 5,000 soft clients/devices that register depending on virtual machine specs.
• There is no way to control what devices in each site register to the node.
• There is a cost to each individual node ($400 list).
• The mobile app is not supported.

ZPLS is a simple and straightforward approach to protect your organization from a cloud or internet outage. It is another example of how Zoom innovates with its current and future customer base in mind.

I can see this feature used in healthcare especially, where calling is mission critical. We get how mission critical calling is, and CDW has you covered with both managed and professional services for your journey into UCaaS. I encourage you to reach out to your CDW representative and see how we can make collaboration easier in your organization.

Story by Corey Buskirk, a technical architect at CDW with more than 11 years of experience in collaboration solutions.