A little less than a month ago, Microsoft released Direct Routing for Public Preview. Right around that time, I also wrote a blog post covering Direct Routing at a high level. Today, I’ll be doing a deep dive (5 part series) for all of you Skype for Business/Teams administrators and architects that want to know what is really happening behind the scenes. Before I start this deep dive, please note that this is preview content and is subject to change at general availability.
Terminology & Positioning
Microsoft Teams is known as the hub for teamwork in Office 365. One of the components that allows you to send and receive calls is known as Phone System (also referred to as PBX in the telco world). Phone System essentially allows users to do the following:
- Make calls
- Receive calls
- Transfer calls
- Mute/Unmute calls
You can do all of these basic tasks from pretty much anywhere, provided you have internet access. However, in order to complete these calls, the Phone System must be connected to something called the PSTN (public switch telephone network). In order to interconnect the Phone System to the PSTN you will have two options to choose within the Microsoft ecosystem.
- Microsoft Calling Plans – Microsoft is your provider. They provide your phone numbers and interconnects into the PSTN.
- Direct Routing in Teams (telco calling services) – This allows customers to interconnect their own services into the O365 cloud through the Direct Routing architecture.
Choosing one of these options will allow this interconnect and achieve what we call PSTN dial tone. When you pair Phone System with either Microsoft Calling Plans or Direct Routing in Teams, you will have full enterprise calling for your O365 users in Teams on a global scale. Now that you have a fundamental understanding of how Direct Routing works, let’s go over some scenarios for when you would choose Direct Routing.
Scenarios for choosing Direct Routing
One scenario, would be when you want to connect your own PSTN trunk into O365. Companies usually find themselves in this situation when Microsoft Calling plans are not available for their country. It also comes into play when customers want to keep their existing telco contract. In these situations, you would use your existing PSTN interconnects and connect that to a Microsoft certified SBC (session border controller) to allow access to O365 Phone System.
Another scenario would be interoperability with third-party systems. This would allow you to mix two systems. For example, if you have some users on a legacy PBX (Avaya, Cisco, etc.) while you migrate other users to Phone System in O365 and still allow you to communicate with one another. In addition, this would also allow you to connect something like an ATA (analog telephony adapter).
Now that we know the possible situations where Direct Routing comes into play, let’s discuss the types of paths that are taken from a user that is using Calling Plan vs a user that is using Direct Routing.
Call Paths (tenant)
In the diagram above you can see 2 users that are using Phone System. One that is Phone System with Calling Plan and one that is Phone System with Direct Routing. If the user with Calling Plan dials a number on the PSTN, this call will traverse the Microsoft data centers in order to reach PSTN. If the user with Direct Routing configured dials a number on the PSTN, the call will first traverse the on-premises certified SBC and then on to the PSTN. As you can see, both have the same result in that they reach the PSTN.
Call Paths (user)
It is also possible to configure a single user with both Calling Plans and Direct Routing. This will allow us to control the path that is taken based on the destination number being dialed. For example, in the diagram below let’s say this user (let’s just call him Bob…) is configured to use both Calling Plan and Direct Routing.
When Bob makes a call to country code +49 (Germany) based on the routing configuration in place, Bob will traverse the Microsoft data centers and out to the PSTN. Now, say Bob were to call +41 (Switzerland) or a phone number assigned to an analog device hanging off of the 3rd party PBX on-premises. Based on the routing configuration in place, it would make the decision to route the call through the Direct Routing path. This means that Bob’s calls to +41 or an analog device on the 3rd party PBX, would use the Direct Routing path by traversing the SBC. As the call reaches the SBC, the SBC will make the determination on whether to route the call to the ATA, to the 3rd party PBX, or if it is a +41 number, to the PSTN. The advantage here, is that the SBC could potentially be located in Switzerland, so this could be seen as a local call as opposed to an international call. Now that you have an understanding of the paths for both tenant and user levels, we can move on to the architecture, call flows, and technical topology.
Teams 1:1 call flow (voice can flow directly)
For a 1:1/Peer-to-peer call flow in Microsoft Teams, our two users (we’ll call them Alice and Bob) must first establish a signaling channel. If Alice were to call Bob, her Teams client would connect to a component in O365 called the Call Controller (CC). This is the signaling plane and this is where the signaling messaging goes over HTTP REST to the O365 component. The CC will see that this call is for Bob, and in turn will look to see all of Bob’s active endpoints and establish a RINGING to Bob’s active endpoints. In the diagram below, Bob will receive a “toast” notification of an incoming call from Alice.
If Bob and Alice are in a situation where they have direct connectivity to one another (i.e. located in the same office within the same building), media will actually be allowed to flow directly to one another. Media in this case is sRTP (secure real-time transport protocol) media, which is very much the same in the Skype for Business world.
Teams 1:1 call flow (no direct connectivity, example: NAT)
Now, say Alice and Bob do not have direct connectivity. For example, Alice could be at a coffee shop or on her home network where connections are restricted by NAT devices. In this scenario, if Alice and Bob tried to have their media connect to one another it would ultimately fail (as seen in the picture below).
Well if they can’t get connected that way, then how do they get connected? The short answer is via a relay, which is located within O365. By using this Relay device in Azure, Alice and Bob are now able to have their media traffic connect.
Teams 1:1 to multi-party call flow
Now let’s say Alice and Bob were chatting with one another in a 1:1/P2P session and wanted to drag in Charlie to the call. As before, we are operating our signaling via HTTP REST to the Call Controller (CC). CC needs to work with the MC (Media Controller) & MP (Media Prossessor) to establish a multi-party MCU (Multi-point Control Unit) for them to have the multi-party call. Then, from a signaling perspective CC will notify Bob and Charlie that the session is being escalated to a multi-party call. The MP then handles mixing all the audio and distributing it to all of the participants on the call.
In part 2 of this series, we will discuss Direct Routing with and without media bypass in place. Stay tuned!
