Arkadin is now operating as the Cloud Communications division of NTT Ltd. Together we do great things

How to design resilience into your Microsoft Teams voice deployment

Well, this is a big question!

Of course, Microsoft does have high availability built into their Office 365 data centers, but does this cover every eventuality for Teams telephony customers? 

Not quite!

The downtime on Monday 3rd February meant users worldwide experienced issues signing in. This duly affected all the amazing functionality people rely on – as well as PSTN telephony.

Problems reported with Microsoft Teams (via

Eventually, it turned out this downtime was due to an expired SSL certificate. It reminded me of all the OCS / Lync, Skype for Business, and hybrid deployments I’ve done over the years, where I’ve seen this exact same issue. It can – and does – happen, even to the mighty Microsoft.

Now, we all know that there are multiple options for Teams telephony. These include using Microsoft as the telco; using a calling-plan provider such as us; or direct routing, where session border controllers – SBCs – are deployed in region to facilitate local PSTN breakouts.  

This is all well and good – but if your users are unable to sign in to Teams in the first place to make a call, then what?

We’re all remote users – we all need to sign in

Following this recent Teams service downtime a number of our clients have asked what they can do to maintain at least some level of Teams telephony if / when Teams becomes unavailable in the future.

Luckily, we have a couple of options available. One is available now, and the other is on the Microsoft roadmap, so whilst it’s not currently an option, it is surely coming soon. I’ve highlighted these scenarios below – but first, a quick overview on the Teams sign-in process…

Since Teams servers reside in Office 365 data centers, there is no such thing as an on-premise Teams deployment. As such, we are all effectively remote users: we all need to sign-in before we can do anything. 

The Microsoft Teams client sign-in process

The diagram above is a little technical but it does show that – for the Teams desktop client, web client, and mobile app – we need to talk directly to the Office 365 Teams infrastructure, along with Azure and other services. IP phones are, of course, another valid endpoint: we can either sign-in to Teams using the Android full Teams client or in third-party IP / Skype for Business (3PIP / S4B) mode.

Now, let’s consider the options we have – both now and to come – should such a downtime happen again.

Option 1: Look to an SBC vendor for help

If you have deployed SBCs such as Audiocodes with their own brand IP phones, then we can use a solution such as One Voice Resilience (OVR). With this option, although the IP phones normally register to Teams via the SBCs, in the event of a Teams outage where sign-in is not possible, the phones will know to register to the SBC directly and become ‘limited functionality devices’. 

This will allow users to call each other using these IP phones – and also to make and receive calls to / from the PSTN. It should be noted it is only the IP phones that will work in this scenario, and the other Teams clients – desktop, web, and mobile – will still fail to sign-in.

IP phone sign-in, when Teams service is unavailable

In this situation, your critical users who are using IP phones will be able to continue to work. These could be key individuals – perhaps senior execs, or a whole customer services team.

Normal sign-in resumed, using IP phones

Once the Teams service comes back online then full functionality will be restored on the IP phone and normal operation and sign-in will resume.

I should note a couple of caveats: your IP phones must be only running in the 3PIP / S4B mode – and you will need to ensure you have licensed and configured the SBCs. Just be aware that, depending on the SBC used, there is a licensable limit, hence this is not a solution designed to protect your whole IP phone estate when downtimes like this happen.

The above example refers to Audiocodes, but similar solutions are available via other vendors; e.g. Ribbon has a similar solution using Yealink phones.

Option 2: Use HTTP Proxy

This is a solution that is due to be released – H1 2020 – by Microsoft. We don’t currently have too many details on how this local proxy will work, but it is expected to be a service that will be installed on – or close to – the SBCs. It’s reminiscent of using ‘good-old’ SBAs (survivable branch appliances) in Lync / Skype for Business on-premise solutions.

The good news here is that this solution will support all Teams clients and not just IP Phones. It’s expected that the HTTP proxy will synchronize with Office 365 in terms of voice, user, and SBC settings and, in the event of a Teams service outage, will take over – using local PSTN connectivity. Once the Teams service comes back online then normal operation and sign-in will resume.

How connection via HTTP Proxy might work

Again, some caveats to note. One is that your IP phones will have to be in Teams mode, rather than 3PIP / S4B. Another is that you’ll need to install the HTTP Proxy components on your SBCs. This could be either via a local drive (as was the case with SBAs) or perhaps we’ll see vendors providing virtual SBCs that include these required components. Finally, it should of course be remembered that this is – at this stage – only a Microsoft roadmap item and details of the exact way this will work is not yet confirmed.

A quick recap…

Scenario 1

Customer X uses Microsoft Teams with direct routing and a calling plan from a third party provider. In the event of the Teams service being unavailable they want to ensure local Teams telephony resilience for a subset of users using IP phones. The solution here will be to deploy local SBCs in-region and on-customer-premises – perhaps with OVR – to allow their IP phones to continue to make and receive PSTN calls.

Scenario 2

Customer Y uses Microsoft Teams with direct routing using in-region and on-customer-premises SBCs. In the event of the Teams service being unavailable across desktop, web, mobile, and IP phone clients, they want to ensure all Teams clients are still able to make and receive calls. The solution here will be to deploy the Teams’ HTTP proxy, once released by Microsoft and SBC vendors.

…and a final word

As these solutions demonstrate, if direct routing is used with local customer PSTN connectivity (i.e. BYOT – Bring Your Own Trunk) we have some options to maintain PSTN connectivity if the Teams service is unavailable. If however, you’re using a Microsoft calling plan only, there will be no PSTN connectivity whatsoever should the Teams service be down.

Every organization has unique business requirements and there will, naturally, be deployment and design prerequisites with both these scenarios.

Our Teams workshops offer the ideal way to explore your future-proofed options – do get in touch if you’d like arrange one for your organization.


3 Scenarios for Your Journey to Microsoft Teams Direct Routing

About the author

Darren Ellis is a Microsoft UC Solutions Architect at the Cloud Communications division of NTT, with a focus on global Skype for Business, Office 365, and Microsoft Teams voice solutions. He has worked for several Microsoft gold partners over the past 20 years and has a keen eye and passion for technology. Based in the Midlands, Darren is a life-long supporter and season ticket holder at Wolverhampton Wanderers F.C.

One Response to “How to design resilience into your Microsoft Teams voice deployment”

Leave a Reply

Together we do great things