There are lots of guides on the Internet of how to configure Direct Routing with Microsoft Teams. However, whilst these are extremely useful for those looking to implement this technology, you may be looking for a little bit more information on how to extend this into a highly available and resilient solution for your telephony services.
In this blog, I will be discussing the principles of high availability and resilience using Ribbon / Sonus technology as the context platform.
You will know that from the Microsoft Teams side of the configuration, Direct Routing is simple to set up, just pair your gateway, configure your PSTN usages, routes and routing policies. However, simply adding more PSTN Gateways to the PSTN Gateway table does not automatically give you High Availability or resilience.
I want to break this down into three focused elements:
- Microsoft Teams Configuration
- Direct Routing Configuration
- PSTN Carrier Configuration
Microsoft Teams Configuration
The first element you will perform in Microsoft Teams is to pair your SBCs with Office 365. Basically this is an access control list that tells PSTNHUB to expect and allow SIP connectivity from the SBC FQDNs and SIP Ports. The rest of the magic is performed by Microsoft back end services. When you add these to the table, it is important that you ensure that you allow SIP OPTIONS to be sent from PSTNHUB, you will need this to determine your availability status when configuring your SBCs. Why? SIP OPTIONS is like the SIP version of TCP Ping test. This basically determines whether or not the SBCs in PSTNHUB are actually available at a basic SIP connectivity level.
Once you have added your SBCs, you are going to create PSTNUsages and then voice routes that include your SBCs as target destinations. The order in which you enter the SBCs into these routes matters in the same way as they would in Skype for Business. Each one will be tried in round robin subject to them reporting SIP OPTIONS to PSTNHUB within five minutes previous to the call being placed.
Direct Routing Configuration
If you where to connect each of your SBCs to Microsoft Teams Direct Routing independently and then to your PSTN trunk then you may think you have yourself covered? Well, the short answer is probably more like, maybe but it could be better.
Although Microsoft PSTNHUB should detect if a SIP trunk is down between itself and a particular SBC then it should not route a call to it and temporarily mark the trunk as inactive. But what if the SBC trunk between PSTNHUB and the SBC is working, but its the trunk between the SBC and your PSTN carrier or internal VoIP system that is down? PSTNHUB isn’t going to be aware of that, should under these circumstances potentially would route calls to that SBC assuming it will be routed.
In this case, what would happen is that the SBC would return a Q.850 cause code back to PSTNHUB to say that it cannot route the call (probably no circuit available, or temporarily down). In theory, PSTNHUB should re-route. So what’s the problem?
The user experience may suffer as a result and the user may hear the pre-dial tone of Teams for longer until they actually get Early 183 and a real dial tone. The thought of, this isn’t going well will enter their minds and in all liklihood the call could actually fail to establish.
To make this cleaner, on your SBC you can use that Q.850 code and re-route at the SBC to another so that the experience for the user is far more fluid and normal.
The medium range of Sonus / Ribbon SBCs do not have any HA capabilities, but what they do have is re-routing capabilities. So when configuring them it is in my opinion best to create an interconnect SIP trunk between the SBCs you have and use cause code re-routing to redirect calls to the other SBC(s) in the event the target signalling group is inactive.
PSTN Carrier Configuration
It is important that when you speak with your carrier that you fully describe your intentions and desires to them. You’ll want to make sure that your service and trunks support active / active and not active / passive or all calls inbound will be delivered to one SBC and then you’ll reach capacity issues potentially.
By employing active / active you are load balancing your calls across all your trunks. But again, what if the trunk to PSTNHUB is down on the SBC that gets offered the call? Much like what you’d do for Teams, you would do this side of the call too and use re-routing to get the SBC to send the call via the other SBC(s) in the site.
When I get time, I will post how to guides and configuration snippets to make this happen. But for now, conceptually this should give you enough of an idea to implement using other blogs on Direct Routing as a reference point.