In my last post I gave an overview of Media Bypass in Lync/SfB and Teams, as well as the new Local Media Optimization functionality. In this post I’ll dive into Media Bypass, and we’ll save LMO for the next post.

First things first – this is MEDIA Bypass. It’s just the media that we’re messing with, not the signaling. Signaling will always involve Teams and the SBC.

Without Media Bypass, our traffic looks like this:

Media Bypass involves sending media from your Teams endpoint directly to the outside interface of the SBC. That media will come from two places, the Internet if you’re remote, or the LAN if you’re inside your organization’s network.

Remote

If you’re remote, your media path looks like this:

This looks nice and simple. The remote client can find the outside of the SBC since we have an FQDN, DNS, firewall rules, and certificate already in place for the Direct Routing connection. What we don’t have though are firewall rules to allow traffic from the remote users to the SBC. That is an “any” as the source, and most security teams are hesitant to permit that. If they don’t allow this, you could still permit your own public IP ranges so your LAN users can take advantage of Media Bypass. If the Teams client tries Media Bypass the connection directly to the SBC would fail and the default path (above) through Teams would be used – but do read on!

There’s another point to consider here, and that’s the difference in the network path between a remote user reaching your SBC directly, and a remote user reaching your SBC through the Teams cloud/Microsoft infrastructure. Chances are that your remote staff are at home, a coffee shop, or a hotel. Something with a general purpose, consumer grade Internet service. Their media would traverse that link and the general purpose Internet to reach the SBC. If their traffic took the default path, it would enjoy a smooth and luxurious ride on the Microsoft network, appropriate prioritized as Teams voice traffic. Having Media Bypass turned on may not actually benefit their call quality,

Why a nice ride on the Microsoft network/ Microsoft has an amazingly large, fast, high quality global network that peers with ISPs early and often. For quality, they want Azure/M365 bound traffic on their network as soon as possible. This also gives Microsoft the ability to place Teams resources in locations other than major Microsoft datacentres. Everything is microservices after all, so your media traffic may not be flowing from your client to a major datacenter then down to your SBC.

Internal

If you’re on your organization’s LAN, your Media Bypass connection looks like this:

We need to do some pretty funky firewall hairpinning here to make this work. It’s easy enough to permit your own IP ranges back in through your firewall, but a lot of firewalls don’t like accepting traffic inbound if that traffic has just egressed – it just doesn’t seem normal or right. Some firewalls can’t even do this, period. Make sure you shut off deep packet/application aware everything, because it won’t be useful to your security posture and will just clobber your traffic and generate helpdesk tickets.
In this scenario, you should also consider the bandwidth being consumed by the media traversing the firewall and Internet twice. This shouldn’t be spectacularly high and may not be an issue, but it is something to consider.
This is a better scenario that the outside user in terms of potential call quality improvements, since there’s no external traffic at all.

SBC isn’t in your site

There’s another factor of Direct Routing to consider here as well. If your SBC is not in your own building (ideally the same one as those light blue users), you are in a scenario that’s very close to the remote user scenario – your traffic needs to traverse the Internet or Microsoft’s network to reach the SBC, and Microsoft’s network is probably better. If your SBC is hosted in Azure, then the traffic doesn’t need to leave the Microsoft network.

If you as using a Direct Routing as a Service provider, Media Bypass is likely not available to you as an option – the setup and complications would consume too much time.

The Verdict

Given the above, what should you do? My recommendation is that you NOT enable Media Bypass. Leave media paths at their defaults, and monitor your call quality through the Call Quality Dashboard. If you are seeing results in CQD that indicate you may benefit from Media Bypass for external users, turn it on and see if there’s a change (and if things improve, drop a comment below as this is, in my experience, rare). If you see results in CQD that indicate you may benefit from Media Bypass for your internal users, don’t implement Media Bypass, but instead read my next post on LMO.