At EC19, Yealink announced a partnership with Ribbon to deliver PSTN survival with Microsoft Teams for their Teams Phones. I don’t have a Yealink, but I do have a few VVX’s lying around my home office, so I thought I would give it a shot and see if I can get this working on other handsets. Turns out I can and that means I do not have to invest in new hardware for this disaster event solution. Better still it works for Skype for Business On-Prem and Online as well as Microsoft Teams!

So, how does it work conceptually? Basically the VVX phone registers to both Skype for Business Online (Teams via SIP Gateway) and to the SBC at the same time. When registration fails to Skype for Business / Teams, the phone will failover the active registration to the SBC and become essentially a basic SIP phone for making and receiving calls.

In order to facilitate this functionality, there are a couple of per-requisites.

  • The SBC must have local SIP registrar licenses to cover the number of phones you want to have this capability
  • The VVX phones must be running UCS 5.8 onwards

To set this up I will say right now is not that easy, or scale-able. This solution is really meant for mission critical phones that must survive a failure and not every phone in your business. Why, will become apparent as you read on. But basically, you would provide this capability maybe for your senior execs, inbound sales / support teams and main office reception type scenarios.

First we need to configure a Cloud IP Phone Policy in the tenant. This is so we can disable the management of firmware by Office 365. The reason for this is we need UCS 5.8 or higher, and Microsoft will force a rollback to UCS 5.6 if managed by Office 365. As there is only the global policy, this would mean that all phones would be affected.

Set-CsIPPhonePolicy -Identity Global -EnableDeviceUpdate $False

Now update your VVX to UCS 5.8 either by Phone Web UI or on-prem provisioning server.

Before we touch the phone any further, we now need to set up the SBC to support this. Assuming you now have the required Local Registrar license installed.

First on the SBC go to SIP > Local Registrars and create one. I’ve called mine “Teams Fallback SIP”

Now from SIP > Local / Pass thru Auth tables create an auth table. I’ve called mine “Teams Local Fallback”.

In this auth table, create an account for the phone that you want to survive. Note it is important that the address URI is the same as the DDI assigned to the user in Teams. The username and password can be anything. But for simplicity sake, the username is the DDI and I’ve set the password to 12345

Now we have the account set up, we need to catch registrations, so we need to create a signalling group. Under signalling groups create a SIP SG, I’ve called mine “Teams Fallback Phone”

The settings of the SG should be:

  • Call Routing Table (select any for now – we will come back to this)
  • SIP Profile: Default
  • SIP Mode: Local Registrar
  • Registrar: Teams Fallback SIP
  • Media List: Default
  • Listen Ports: 5060 TCP/UDP
  • Federated IP: <your network range>

Now create a call route table to handle outbound calls from phones when they are in a fallback mode.

Go back to the Signalling Group and set the call routing table to this and apply the settings.

Now we have the bones of the configuration we need. Now to configure the outbound call route. From the routing table we created, add a route to your ITSP. You can use the same transformation tables created for your Teams -> ITSP if it is compatible

This is now outbound calling configured. Now let’s configure inbound.

For inbound we need to ensure that the fallback route is only tried if the primary (via Microsoft Teams Direct Routing) is unresponsive. There are a few ways in which to achieve this, but I am going with the simple way. Rather than using cause code re-routes, I am simply going to add my fallback signalling group to the existing ITSP -> Teams route entry as a second possible destination for calls.

The way that this works is destination SGs are attempted on a first to last basis. As the Teams SG will almost always be up, the calls will always route via that. In an outage, which is what we want, it will not be available so the 2nd SG is tried and this is to our local SIP registrar table.

The SBC configuration is now complete. Now we need to configure the VVX phone.

You will need to add the following configuration to your phone’s cfg file

feature.sfbPstnFailover.enabled="1"
reg.1.srtp.simplifiedBestEffort="1"
reg.1.server.2.address="192.168.1.252"
reg.1.server.2.pstnServerAuth.userId="+441782977074"
reg.1.server.2.pstnServerAuth.password="12345"
call.enableOnNotRegistered="1"

Where 192.168.1.252 is the IP address of your SBC, the userId is the sip user we created in the local auth table and it’s password.

Now the solution is ready the last note of interest is the experience.

By default, phones register to Office 365 for a period of 10 minutes. usually the phone re-registers when the time gets to 50% or 5 minutes. The phone is a single line, therefore, can only have one active registration for calls at any one time.

During a failure event, there may be a period of 10 minutes where no calling is possible until the registration with Office 365 times out, the phone will then automatically mark the backup registration active. Calls during this time inbound will receive a busy tone, and the message back from the phone will be a SIP 486 “Busy Here” message.

Once the phone realises that it can no longer register to Office 365 calls will proceed as normal, but the phone will be in a basic mode, which is nothing more than a landline type service.

As you can see, the solution would be quite hard to scale beyond the few critical phones you need and it is quite limited, but its giving your critical users something rather than nothing in a time where you need to be focused on restoring a service, not providing an ad-hoc workaround on a case by case basis.

Advertisements

3 thoughts on “PSTN Survival With Microsoft Teams, Polycom VVX and Ribbon SBC”

  1. It’s really good idea where DR is being thought about for PSTN survivability rather then when it’s all working but it’s such a shame it’s not scalable. It’s frustrating when a great concept comes around but cannot really see this being used in enterprise companies in mass without it being scaleable so perhaps something for the future development (I really hope it is).

  2. Mark, you could also use a pre-configured X-Lite client on the user’s desktop for the peepz who doesn’t have a desk phone that can do dual registration (which I doubt a native Teams phone will ever do). If the SBC lose the cloud or a way to it, fire up the X-Lite client on the user’s desktop and let it register to the local SBC using the backup registration account with the same DID. Voila – survivability with a softphone.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.