Recently Cisco announced the general availability of a new component in their cloud calling architecture: Site Survivability for Webex Calling Multitenant.

I’ve recorded a video demo to show what it looks like.
If you want to learn more about the feature, keep reading after the video.

Demo

The Survivable Telephony Problem

If you have been in the IP Telephony business long enough, you are certainly familiar with the concept of SRST (Survivable Remote Site Telephony), which is an incredibly useful piece of the Cisco Unified Communications architecture.

To understand and set the context, we ask ourselves: what happens to IP Phones at a remote location when they lose connection to the PBX, which is the brain of the system?
And can users continue calling each other (or reach out to the PSTN) without accessing the PBX?
Survivable Remote Site Telephony provided a solid answer to those questions, within the CallManager based “on-premise” architecture.

In a nutshell:

  • IP Phones at remote branches are connected over WAN to a centralized UCM cluster,
  • something bad happens to the WAN connectivity, the remote site becomes isolated,
  • IP Phones turn to the on-premises branch router, which starts acting as a PBX, guaranteeing continuity of service.

Amazing piece of technology.

Adding Cloud to the Mix – The New Solution

Fast forward to 2023 and many IP Telephony conversations will involve cloud PBXs at some point. In Cisco’s terms, there are two variations of Cloud PBXs: the UCM–based Dedicated Instance, or the cloud–native Webex Calling Multitenant. This new product announcement clearly concerns the second, since Dedicated Instance can of course rely on traditional SRST.

When we talk about SaaS and cloud services, the security concept of trust is very relevant. The “chain of trust” must be respected at all times. To make sure this new survivable branch telephony model respects the chain of trust, Cisco introduced a new security overlay that:

  1. guarantees the router (who’s acting under the function of Survivability Gateway) is authorized to register the phones during a network failure;
  2. allows the router to download from Control Hub a copy of the phones’ identities and numbers;
  3. enables the phones to recognize and trust the router in a similar fashion to what they do with the Cisco’s cloud SBCs.

All the above leverages a IOS XE feature called “Guestshell” in combination with a Webex Gateway connector, that runs on top of it.

Note: I called out the phones, and this demo focuses exclusively on them, but the solution that is now generally available to Cisco Customers also works with desktop soft–clients (a.k.a. the Webex App).

The Resulting User Experience

When all these pieces are combined, we obtain something similar to what SRST used to deliver, but adapted to the modern–day cloud architectures.

Phones receive from the cloud the reference of the local Survivability Gateway they must reach out to, in case of a network failure.
If that time comes, they will first of all verify the identity of the gateway, and, upon successful identity validation, proceed to registering to it.

It will be responsibility of the gateway at this point to route phone calls and provide emergency PSTN access (if PSTN access is part of the design).
As soon as the network uplink towards the cloud is restored, the Cisco IP Phones running the MPP firmware will fall back to standard cloud mode of operation.

If you made it this far, and want to see what this all looks like, check out the video.

Conclusions

I hope you found this introduction useful. If you have experiences to share or comments about this architecture, don’t hesitate to get in touch.

See you next time!

Edit: if you want to know how I displayed the two real phones on screen, check out this article.