In my previous two posts, I give an intro to Media Bypass and Local Media Optimization, with the end goal of determining if you need them or not.

Local Media Optimization (LMO) at its core is similar to Media Bypass, except your device connects directly to the inside interface of the SBC and not the outside interface. That’s good in some ways, but does add some complexities of its own.

First, we don’t need to worry about firewall hairpinning or having to battle the security guys to open up the outside interface. We only ever talk to the inside interface, and thus only internal clients can do LMO. However, it’s only the outside interface that has an FQDN, so we need some other way of establishing where the SBC is, and how we connect to it. And that’s a bit of work.

In Teams Admin Center (TAC), under tLocation > Network Topology

you specify two important components for this, The first is Trusted IP Addresses, which are the IP addresses your clients are NAT’d to when they access Teams (or your entire IPv6 range if you’re one of the cool kids doing that). This lets the client understand if it’s “internal” on your network or external. That leads to a couple of requirements – you need to have static IP address(es) assigned only to you. No cloud-based shared proxy services like zScaler offers, and no dynamic addresses (DHCP assigned addresses with a reservation are fine). If your client doesn’t egress to the Internet with an IP that meets these requirements, it will not be identified as internal to your network and will not be able to do LMO.

The second part in TAC that you need to be concerned with is under Locations, Network Topology, Network Sites. This is the section where you identify sites in your network and what subnets are present at each site. This is used for the client to identify where it is within your organization, and thus which location based policies (of which LMO is one) apply and where.

There’s a third part that you need to do as well, and that’s in the configuration for the SBC. In TAC under Voice > Direct Routing click on the SBC, the select Settings, the Edit

For LMO you need to configure a couple of things. First, Gateway Site ID is the site that you configured above, that the SBC belongs to. SBCs are made by many vendors, and don’t have enough Teams client bits baked into them to establish what site they’re in based on IP address, so you have to specify it here.

The next part you need to configure is Bypass Mode – even though this is LMO and not Media Bypass. There are two options here, Always, and Only for local users. Always will attempt to do LMO for all clients, and fall back to default media paths if that fails. Only for local users will only attempt to do LMO if the user’s device is in the same site (that you defined above) as the SBC.

And lastly, you need to turn on “Media Bypass” even though we’re doing LMO. If you’ve read my previous post on Media Bypass and don’t want to do it, that’s fine. You won’t magically be doing it by turning this on unless you also configure your firewall.

Your SBC vendor will also have a bunch of configuration steps to take on the SBC to enable LMO.

Your device and the SBC should now be doing LMO.

SBC isn’t in your site

To be clear, here “site” means “your organizations premises” and not the Network Site that can be configured in TAC (that is the Bypass Mode of “always” or “only for local users”.

Moreso than with Media Bypass, LMO makes little sense to configure in hosted scenarios. First, you’d need to establish a network connection from your LAN(s) to the inside interface of the SBC, so now you’re firing up VPNs and dealing with datacentre or Azure networking, and… that makes no sense to go through that effort to get the traffic to the SBC.

LMO is also not applicable to Direct Routing as a Service scenarios. No DRaaS vendor in their right mind would setup an inside interface and take on the burden of LMO configuration on their SBCs, even if you paid them lots of money.

The Verdict

But wait you say, I’ve only cover basic LMO configuration. Yes, just one SBC, and users on the inside. We’ll dive into the more advanced “proxy” or hierarchical LMO deployment in the next post.

My recommendations are two-fold here. First, if you have excellent WAN bandwidth for users from any site to be able to place calls via the SBC you’re configuring LMO for, go ahead if you want to try it out. It’s probably going to be rare that you have run into a scenario where you have so many users in France who are trying to call Australian PSTN numbers via the SBC in Australia that you will need to be concerned about bandwidth consumption in “Always Bypass” mode. If this is the case, then flip the mode for this SBC to “Only for local users”.

Second, my recommendation for Media Bypass also applies here. If you’re not seeing call quality issues, then it may not make sense to go through the hassle of configuring LMO within Teams (well, it’s not that big of a deal) and in the SBC (this is more of a big deal, it can be messy and confusing). If you think you may benefit from LMO, and you have enough data in CQD for a baseline to compare against, go ahead and turn on LMO.

TL;DR – you probably don’t need to do Media Bypass or this basic form of LMO unless you have some weird network capacity constraints and topologies.

Up next, we’ll touch on the Proxy configuration for LMO