Home » Microsoft Teams » Considerations for Microsoft Teams Direct Routing

Considerations for Microsoft Teams Direct Routing

Microsoft released Direct Routing to Public Preview last week (15th May 18) for Microsoft Teams. We as a Microsoft UC team seems to be incapable of choosing a decent name that clearly identifies our products without having to Bing first… It also has a very confusing acronym, DR. C’mon DR means Disaster Recovery to so many that it’s going to be hard to keep the context if we in UC start talking about DR as in Direct Routing.

Direct Routing, for those Binging what this is, basically is a SIP trunking service provided by Microsoft that allows you to connect your existing PSTN connections to Microsoft for use within Microsoft Teams as a PSTN voice route.

This is a preview service at the moment and probably not the finished product, but if history is anything to go by public preview is basically 98% of the version 1 product released to GA.

If you are considering Direct Routing for your business then there are a few things that you need to consider when evaluating whether Direct Routing is right for you.

Firstly, this service is a welcome addition to the Office 365 product family, a simplified service for the customer that is easily accessible and relatively cost efficient, without the complexity of its predecessor Cloud Connector Edition.

Cloud Connector Edition was really considered a failure by the majority of professionals out there, it was a hacked version of Skype for Business that provided an easy way for Microsoft to connect to on-premises PSTN without too much investment on their side of things, by leveraging what was already available through federation to make the connection. The idea was sound, the way in which it was offered was its downfall. It was marketed as an appliance, but the customer had to provide the hardware and the base operating system licence. The appliance required 4 virtual machines which mandated Windows Server 2012 R2 Enterprise Edition, which compared to Standard Licence was really expensive, so even though Microsoft insisted Cloud Connector Edition was free and inclusive in your Office 365 licencing SKU, the total cost of ownership was far from free.

Microsoft’s decision to focus on Teams has probably saved the hybrid voice project from a Microsoft and customer standpoint by simplifying the connectivity to the cloud. Direct Routing is a SIP trunking service, so Microsoft provide SIP endpoints in their cloud for customers to connect their on-premises SBC to with little more than the cost of a SSL certificate. It’s a massive win for Office 365 hybrid voice and this is how Skype for Business Online should have done it.

However, as with any product, there are caveats, and at the moment there are a couple of potentially large ones, especially if you’re a customer with existing investments in technology that is not on the supported list for Direct Routing. By this I mean, if you think you can connect your existing Cisco or Avaya to Direct Routing without any additional investment, you will probably find that you are going to have trouble at best, or it won’t work at all. Currently Direct Routing is supported on Ribbon (Sonus) and Audiocodes Mediant SBCs. These SBCs require the most recent firmware version, for Sonus this is Edge 7.0.2. So you will need to invest in some hardware, or use the virtual SBCs available from either vendor. I’ve no doubt that other vendors will offer the same connectivity, but as for now, these are the two certified vendors.

To connect to Direct Routing, you will need an SSL Certificate on your SBC with the common name set as the SBC public FQDN, or at least a SAN entry. You’ll also need to install the Microsoft Balitimore root certificate. The details of how to set up and the requirements are well documented on Microsoft and Vendor support sites, so I will not be reinventing the wheel in this post. Connectivity is made over the internet and at the moment I don’t believe Direct Routing is supported on Office 365 or Azure Express Route, even though the Microsoft POPs are located in Azure. Don’t quote me on this as I’ve yet to get a definitive answer from Microsoft on this, but the safe assumption is that at the moment, probably not.

This leads to the first consideration. Usually when connecting to a SIP provider you’ll want to use dedicated lines for voice to your provider. Microsoft want you to use the internet. PSTN calls are going to be using G.711 and this is not an adaptive codec like SILK, so the connection needs to be stable. You’re not going to get this over the internet. If Express Route is not supported, there is no way to guarantee this connection to Office 365, not QoS policy can be applied. Express Route would be the likely requirement to provide the dedicated, controlled and consistent connection, but even if it is supported, implementing it purely for Direct Routing would be expensive, to the point where you may as well use Microsoft Calling Plans, it’ll be cheaper. However, this may not be a big issue, Microsoft have said that Media Bypass will be supported with Direct Routing. However, for Sonus users version 7.0.2 does not support Direct Routing Media Bypass. Version 8.0 will be required for that and that’s a few weeks off yet. The jury is still out if Media Bypass is the silver bullet to the internet media issue that has been plaguing hybrid voice ever since it was first whispered, it largely depends on how multi-party and user hybrid scenarios work. For instance, a Direct Routing user with delegates with Calling Plans, can the calling plan users use Media Bypass? We will have to see.

The second consideration is what you want Direct Routing for, on-premises at least. If you’re looking to procure a cheaper alternative to Microsoft Calling Plans, then you’re probably best to go and speak directly with SIP providers such as PureIP. Thinktel in Canada are the reference and they offer Direct Routing as a Service purely for this type of reason, cost efficiency. The only reason why you’d want Direct Routing on-premises is if you want to connect existing on-premises PBXs to Microsoft Office 365 for internal extension dialing. Again, consult with the SIP providers as they may be able to “as a service” this connectivity too. The idea is to get the best connectivity at the most efficient price for the business. Should you have Direct Routing SBCs at each site? Probably not, if your on-premises PBX can utilize your WAN for cross site connectivity, then you’re probably best to evaluate if a centralized deployment is feasible. Obviously considerations on bandwidth and other networking impairments will need to be investigated before this model is chosen.

Direct Routing does provide a lot of flexibility to Microsoft Teams voice. However, there are some restrictions right now that make the decision on whether a user is a Direct Routing user, or Microsoft Calling Plan User.

Currently, Direct Routing does not support service number usage. So this means you cannot use Direct Routing for Call Queues or Organization Auto Attendant. This is not so much of an issue right now, because neither does Teams. However, at the moment the if you want users to answer calls from a Call Queue, they need to be Skype for Business Online users for voice and therefore, cannot be a Direct Routing user as well.

This leads to the next point. Even though you use Skype for Business Online PowerShell commandlets to enable Direct Routing, you cannot use Skype for Business Online client as the voice endpoint for the user. This MUST be Teams client. I think this is purely a strategy decision by Microsoft as the technology and method seems to suggest this is nothing more than a policy restriction.

When users are enabled for Direct Routing, they don’t need a Calling Plan. However, if they want to use Audio Conferencing they will need the Audio Conferencing licence. This will permit them to use the Microsoft Audio Conferencing Service like a normal cloud user today. However, if they need dial out in conferencing, they will also need to be assigned the Calling Credits licence as dial out does not use Direct Routing, but Microsoft ACP service instead.

Direct Routing only users are able to use extension dialing to on-premises PBX subject to the correct routing capability on the SBC. Users who have Calling Plans and numbers acquired in the cloud can also use Direct Routing voice routes for the same or for PSTN calls that need to egress out of a local gateway for whatever reason, e.g. least cost routing, toll bypass (kind of) type scenarios.

Direct Routing users must have a number that terminates on-premises, they cannot be assigned a number from the cloud, ported or otherwise.

Common Area Phones, and any other 3PIP phone cannot be used with Direct Routing at the moment. This is largely due to the fact that Teams does not yet support these devices. Teams native phones, should be able to use Direct Routing. This is an assumption based on the routing policies enforced by Microsoft.

I’d expect Direct Routing users to also be capable of adding Calling Plan users as Delegates and Team members for call forwarding, but I haven’t been able to test this scenario yet.

High Availability can also be supported using Microsoft POP connectivity, Voice Routes and SBC to SBC interconnection. Microsoft have POP locations in Europe, America and Asia. You can prioritise the POP used for connectivity based on your location, so you can be sure to use the most optimal POP for your location until it goes down. POP availability is monitored by SIP OPTIONS on the SBC. If this is down, then the SBC will use the next POP location.

In the user’s voice routing policy you can specify which SBCs you want the call to be routed to. These are selected using round robin, so both SBCs need to be able to route the call if requested and online. If this is not possible and you can only run in active/passive mode for your SBC connectivity, then in PowerShell you can mark the gateway as offline so that the voice routing policies are configured ready to support HA/DR (Disaster Recovery), but in BAU, they are going to use only the primary SBC. In the event of a situation, the disabled SBC can be enabled in PowerShell and the broken one disabled and all users are restored without touching their individual configuration.

SBC to SBC interconnection is a method used to control PSTN connectivity HA/DR (Disaster Recovery) – see my issue here with acronyms… If the primary SBC loses connectivity to the PSTN, Microsoft Teams isn’t going to be aware of that. To that, the SBC is still very much alive and capable of accepting calls. However, the external calls will not be routed because the PSTN connection is down. Internal calls will still work as intended. In this scenario, the SBC would terminate the call and the user would have to place the call again and hope they got an alternative SBC. To improve user experience, you’d create a failover route on the SBC so that if the PSTN connection was down on one SBC, the SBC would attempt to re-route the call to another SBC where PSTN connectivity is available. The end result to the user is that calls are uninterrupted.

I hope this is useful for anyone considering Direct Routing at the moment.



Leave a Reply

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

%d bloggers like this: