Direct Routing for Microsoft Teams Deep Dive: Part 2

In part 1 of the Direct Routing for Microsoft Teams Deep Dive, we discussed the foundational call flows from the Teams client. In this article we will continue the discussion by talking about Direct Routing call flow with and without media bypass. Lastly, we will take a look at a high level view of the global topology when using Direct Routing.

Teams Direct Routing call without media bypass

Some of the components in the diagram below will look familiar. The CC, MC, and MP which we had used with our 1:1/P2P and multi-party calls also come into play when discussing Media Bypass.

However, there are a couple additional components to be aware of. The first is called the PSTN Hub. The PSTN Hub is responsible for making decisions on where to route the particular calls. The other component is called the SIP proxy. This comes into play due to the fact that the SBC cannot understand the HTTP REST signaling thus the SIP proxy is there to convert the HTTP REST signaling traffic into SIP traffic. In addition to these two components, you will have a central database. The central database is responsible for storing data such as:

• Voice Routes
• Voice Policies
• SBC trunk configuration
• CDR (Call Detail Records)
• Monitoring information
• Troubleshooting data

Now, let’s say Alice attempts to make a call to the +41 (Switzerland) number mentioned in the last blog article. Similar to before, Alice will set up a signalling channel via HTTP REST to the CC. CC will then be able to read the various voice routes and voice policies and determine that this call is destined for Direct Routing infrastructure. Next, CC will establish connections to the PSTN Hub. The PSTN Hub will then look into the backend database to determine the health of the various SBC’s that we need to connect to. The PSTN Hub will need to make the correct decision on where to route the call, but we want to ensure we are routing this call to a SBC that is currently available/active. This is done by a SIP OPTIONS polling interval that the SBC’s will do back into the service. Once the PSTN Hub has determined where the call should be routed and that these endpoints are healthy, we will establish a connection with the MC’s & MP’s. We do this so that we can allocate a correct MP that is geographically closest to the SBC. We can determine this based on the public IP address that the SBC uses as it is registered into O365.  The PSTN Hub will then connect to the SIP proxy using HTTP REST signaling, which in turn will be converted into SIP and establish the connection to the on-premises SBC. From a media perspective, the Teams client will connect its media to the corresponding MP. Likewise, the SBC will connect its media to the corresponding MP. Thus, allowing this call to succeed. Upon completion of the call, all of the various components will send the CDR information back into the service. This then allows the tenant administrator to go into the Call Analytics tool, look at the various information that has been posted, and then use this information for troubleshooting purposes or call quality reporting.

Teams Direct Routing call with media bypass

In some situations the call flow that we just looked at may not be the most optimal path. For example, say you have a large number of users that are homed in the same office as the on-premises SBC. Without media bypass in place, the users would have to send their traffic out to the internet, up to the MP, and then back to the SBC. This is where media bypass can be very practical. As you will see in the diagram below the signaling flow still follows the same path as the last scenario.

However, when going to establish a media connection, rather than returning the IP address of the MP, we would return the public IP Address of the SBC. This would allow the Teams client to be able to connect directly to the public IP address of the SBC instead of connecting up into the O365 service. In order for this to work, the public IP address of the SBC must be reachable by the Teams client. If the Teams client is on the internal customer network, we still need to ensure the public IP address of the SBC is routable. Please take this into consideration as you are planning your routing topology to ensure media bypass will work in this scenario. Once media bypass has been configured in the service and you have your networking open such that the public IP and media port ranges are available, the Teams client will be able to directly connect to the SBC.

So what if the user is not located on the customer premises? Well, first things first, as long as media bypass is configured we would return the public IP address of the SBC rather than the Media Processor. At this stage, the Teams client will perform a connectivity check. If the connectivity check succeeds, the Teams client can connect to the SBC. What if the connectivity check fails? There can be a multitude of reasons why this could fail. For example, maybe the security team hasn’t configured an ACL (access control list) that allows access to this public IP of the SBC. Maybe they only allow well known IP addresses such as those in Azure. Whatever the case may be, you will have the capability of using the Relay inside of O365. As you will see in the diagram below, this will allow the Teams client to connect to the Relay as well as the SBC to connect to the Relay.

In order to support this scenario from a media bypass perspective, you will need to ensure your SBC supports ICE (Interactive Connectivity Establishment) Lite. All of Microsoft’s certified SBC’s support ICE Lite, so as long as you have a  Microsoft certified SBC you will meet this requirement.

Global view of cloud topology

So where is Direct Routing deployed? To put this simply, the Direct Routing components are deployed in 3 different geographies:

• North America
• Europe
• Asia

Each of the geographies mentioned above have 2 datacenters. The corresponding datacenter that is chosen will revolve around the public IP address provided by the SBC.

Thanks for tuning in for part 2 of the Direct Routing for Microsoft Teams deep dive. In part 3 of this series, I’ll be discussing the configuration aspects of Direct Routing.