Microsoft Teams Direct Routing: Should you use Media Bypass?

Matt Ellis
Mar 20 · 5 min read

In the past week or so documentation about Media Bypass for Direct Routing started to appear on docs.microsoft.com. Then, yesterday at Enterprise Connect, it was officially announced as “available now”.

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.

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.
  • As pointed out by Chris (@WeakestLync), 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:

365 UC

Stories from the world of UC by a bunch of UC professionals…

Matt Ellis

Written by

Unified Communications Architect, Pompey fan, burger eater, coffee drinker...

365 UC

365 UC

Stories from the world of UC by a bunch of UC professionals…