Microsoft Teams Direct Routing: Should you use Media Bypass?

-

I recently started looking at implementing Direct Routing in my organisation so I have been doing a fair bit of reading about it.

Media bypass, on the face of it, seems like an absolute “must have” when it comes to Direct Routing. However, nothing is ever simple and due to the nature of Microsoft Teams being a cloud-based service as well as being relatively young, media bypass isn’t quite as simple as it could be.

In it’s current guise Media Bypass has the following limitations:

  1. Media bypass is currently only supported with ICE Lite on the SBC side. This means that clients currently have to connect to the SBC on it’s public interface. This might be difficult for some enterprises to configure which might lead to firewall hair-pinning and actually diminish the advantages of media bypass anyway.
  2. Media bypass is not supported by the Teams web/browser clients. They recommend not enabling media bypass if the browser clients are going to be used.
  3. Media bypass is not supported for 3PIP devices. Microsoft currently recommends setting up a separate trunk and voice routing policy for 3PIP devices. A bit of a ballache.

Having said that, Microsoft don’t recommend allowing all your clients to reach the SBC directly anyway, especially when they’re external to your corporate network.

“For media optimization purposes, Microsoft recommends opening the public IP address of the SBC only to Teams Transport Relays. For clients outside of the corporate network, Microsoft recommends using Transport Relays instead of reaching the public IP address of the SBC directly.”

https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan-media-bypass#use-of-media-processors-and-transport-relays

The only scenario they recommend for media bypass is when the client is in the same building or network as the SBC.

In the case of my organisation we have moved almost exclusively to a direct-Internet connected, Zscaler protected, SD-WAN environment. So, is there much point back-hauling the traffic to my SBC via the SD-WAN or should I just take advantage of Microsoft’s massive Internet presence and their huge number of media processors and media relays?

So, what does a call with media bypass look like versus a call without media bypass? Let’s take a look…

In my scenario, I have only opened connectivity to my SBC for the Microsoft media processors and transport relays as detailed here. External clients (as per Microsoft’s best practice) cannot get to my SBC directly. So, in this example my media bypass call will use the Transport Relays.

Normal call (non-bypass)

Here’s the call. Shows as good audio quality.
Media Processors

In the advanced tab you can see that both the Teams user and the PSTN endpoint are showing as MP00000B which I’m assuming is a media processor. A media processor is involved in the media flow of all non-bypass calls. You can also see that it’s on a 10.0.4.x IP address which is internal to Microsoft.

SDP offer in SIP Invite from Microsoft

The SIP invite shows the SDP offer with the Media Processor and the 10.0.4.x reflexive IP. It also shows lots of codecs (including SILK) offered for the call.

SILKWide > PCMU transcoding

Under the Advanced > Inbound network section you can see that the client is sending SILKWide codec. The recipient PSTN endpoint is getting PCMU/G711 which means there is some transcoding happening at the media processor here.

DIRECT ICE Connectivity

Under the Advanced > Other section we can see that ICE Connectivity description is DIRECT indicating a non-media bypass call.

Media Bypass Call (with Transport Relay)

Some data not available?

The call shows as good quality but doesn’t have some of the data. Not sue if this is because Media Bypass is new and Call Analytics hasn’t been tweaked for it yet?

Shows my client this time…

This time in the Advanced tab I get actual details about my client. The PSTN side has nothing.

SDP offer in SIP invite from Microsoft

The SIP invite shows the relay address this time with only G711 offered as the codec.

Under the Advanced > Inbound network section it shows my client sending PCMU/G711 audio. No SILK this time, presumably because the Transport Relays do not do transcoding.

From here: https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan-media-bypass#use-of-media-processors-and-transport-relays
ICE Connectivity RELAY

Under Advanced > Other, we can also see that the ICE connectivity description is RELAY along with the relay IP address to indicate the transport relay being used.

In Conclusion

So, in this scenario there are various pros and cons to using Media Bypass:

  • Media bypass (by design) should provide a shorter, more direct media path
  • This shorter media path could increase call quality.
  • If you route this traffic over your WAN you can at least manage the traffic/quality with QoS markings.
  • Media bypass pretty much forces* the use of PCMU/G711 for the call, especially if you’re using Microsoft’s transport relays. PCMU/G711 traditionally doesn’t fare so well over unmanaged networks, especially the Internet.

* Unless you have enough transcoding resources on your SBC and you allow direct connectivity

  • SILK on the other hand is excellent over the Internet so could provide a better call quality for the client > Microsoft leg of the call in a non-bypassed call.
  • Can’t use media bypass for web/browser Teams clients (yet)
  • Can’t use media bypass for 3PIP devices (yet?)


Key reading sources:

Comments

Post a Comment

Popular posts from this blog

Troubleshooting Network Topology in Microsoft Teams Direct Routing

-
Image
  If you are playing around with location based routing or local media optimization in Microsoft Teams Direct Routing, you will have no doubt had to configure Trusted IPs and network sites in Microsoft Teams. In order for LBR or LMO to work correctly, a client needs to be determined to be “internal”. This is done using Trusted IPs and network subnets in the Network Topology section of the Teams Admin Center. It is often wise to check if what you have configured is correct. I’ve also found that trusted IPs can take a while to filter through the Teams service, so instead of waiting for stuff to miraculously work you can use the process below to check what your client thinks is going on. Alternatively, maybe the networking team has snuck in a new subnet without telling you, or the security team have changed the firewall IP and the clients no longer think they’re internal? I have also found that the  MediaLine_Description_ReflexiveLocalIPAddress_IPAddr  or  Connectivity_...
Read more

What is Office 365 and How It Works?

-
Office 365, now known as Microsoft 365, is a cloud-powered productivity platform that combines the familiar Microsoft Office applications with intelligent cloud services, providing an all-in-one solution for working professionals, students, and organizations. The subscription model ensures that users always have access to the most up-to-date tools, including Microsoft Teams, Word, Excel, PowerPoint, Outlook, OneDrive, SharePoint Online, and Microsoft Forms, among others. The primary advantage of Microsoft 365 is the seamless integration of its applications with the cloud. This allows users to easily access, store, and collaborate on documents from any device with an internet connection. Furthermore, the subscription service offers a range of plans catering to different user needs, such as for home and personal use, small and mid-sized businesses, large enterprises, schools, and non-profit organizations. Microsoft 365 also provides world-class security features to protect users and th...
Read more