Teams – Direct Routing – The impact of Media Bypass on remote working (home working) users

Direct Routing with Media Bypass has been available for almost two years now and its benefits in different scenarios are clear.

For example, in a corporate environment with SBCs deployed inside the internal network, there are positive results when the users are connecting from the company’s offices.

However, with the existing situation pushing companies to remote work (and this will probably be still the case for a few months at least), it is more relevant than ever to optimise the remote users’ connectivity (especially the Media traffic) to Teams

Whilst Signaling traffic always flows via the Microsoft Cloud (and it does not contribute much to the overall network usage), Media traffic is managed really in a different way if we use Direct Routing with or without Media Bypass (and the Media traffic is the one that uses more bandwidth, so important to optimise)

There are two components in the Microsoft Cloud that can be in the path of media traffic: Media Processors (MPs) and Transport Relays (TRs). Depending on our configuration, they could be involved in the path for media traffic.

I am not going to deep dive them here, but there are some important information to understand, as stated in this Microsoft document https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan-media-bypass

Media Processors:

1. will always be used in a non-bypass scenario
2. are not always available in a region (5 regions are available so far)
3. will be always used for voice applications like Auto Attendant and Call Queues

Transport Relays:

1. will be used only if the public IP of the SBC is not reachable
2. will always be used for scenarios with Media Bypass
3. are more extensively available in regions near to the users

As an additional information, as for conferencing, MPs will be always selected based on the location of the SBC, not on the location of the user (Mark Vale did some testing around that some time ago https://commsverse.blog/2019/09/20/microsoft-teams-media-with-privacy-boundaries/ )

So, let’s outline a few scenarios, assuming that
• We are focusing on home-based users
• The users are able to connect to Office 365 and Teams directly using their local Internet connection (no VPN or split-tunnel VPN deployed)
• When possible, the client will use the nearest geographical public IP address for the Office 365 and Azure services
• The SBC is deployed in Azure (there is not a big difference if it is in your datacentre for this conversation, though)

First Scenario: Direct Routing, Media Bypass, SBC with no filters on incoming IPs or ports

• Media flow will go directly from the Teams client to the public IP of the SBC
• The traffic will not use the Microsoft Azure network, so there could be a lot of unmanaged hops between the client and the SBC (opposite to using the nearest access to the Azure network)
• There are risks about security with this solution that does not control the Internet access to the SBC services

Second Scenario: Direct Routing, No Media Bypass, SBC allowing only Microsoft IPs

• The client will connect to the Media Processor
• The Media Processor used will be the one nearest to the SBC
• The client media flow  will not use the Microsoft Azure network, so there could be a lot of unmanaged hops between the client and the MP (opposite to using the nearest access to the Azure network)

Third Scenario: Direct Routing, Media Bypass, SBC allowing only Microsoft IPs

• The client will connect to the Transport Relay
• The Transport Relay used will be the one nearest to the client
• The client media flow will use the Microsoft Azure network as soon as possible, granting a good quality connection

Wrap Up

As you can see, the safest solution, from a quality of connection point of view, talking about users connecting from their homes, should be Direct Routing with Media Bypass (with the SBC configured to accept connectivity only from Microsoft, as for the recommended standards https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan )