In the previous two posts I’ve talked about Media Bypass and Local Media Optimization. In general, I don’t feel that the effort to configure those is dignified by quality gains that you may see… and you may not see, or you may make your call quality worse.

However, there is a more complex LMO scenario that involves two levels of SBCs in a hierarchy. The “spoke” or “remote” sites proxy to Teams through the main SBC. Microsoft provides this diagram on the docs page for this

As an aside, I very much dislike that 172.16.240.x is used as an example public IP or Trusted IP. RFC 5737 provides 3 example IP ranges. It’s technically impossible to have an RFC 1918 private/non-routable/internal only IP as your Trusted IP. This diagram is terribly confusing, especially when you start working with network and security teams, so ensure that you explain that they’re meant as example public IP addresses in this diagram.

Now then, on to LMO. We have two “remote” or “spoke” sites here, Indonesia and Vietnam. Vietnam has a PSTN connection and Indonesia does not. Neither Vietnam nor Indonesia SBCs are configured for Direct Routing directly to Teams. This could be because of poor Internet in those locations (either in terms of bandwidth or the ability to get enough static IPs that can be used as trusted IPs), or it could be a desire to limit the number of FQDNs and certificates required – though you could use a wildcard for all of the SBCs in the organization to achieve this too.

The SBCs in Vietnam and Indonesia proxy through the Singapore SBC. The Teams client, the Teams Direct Routing service, and the SBC sort out what path the media should take based on:

• What site the user device/client is in
• What site the SBC with the PSTN connection is in
• What Proxy SBC is set for that SBC (or if it is the Proxy SBC)
• What bypass mode the SBC is configured for (Always, or Only for local users)

The “remote”/”spoke” SBCs have an extra field that needs to be configured

which is the Proxy SBC.

The Verdict

Now, I’m not going to dive deeper into the technical bits of how this works and how you would configure it, because we’d honestly be here for months. If you are considering an LMO deployment that uses proxy SBC(s) and have not successfully done that before, then I implore you to reach out to a partner that has, and to involve your SBC vendor in that process as well. One does not simply turn on proxy scenario LMO and go home on time.

A Gotcha

I do need to include a gotcha here that will affect proxy scenario LMO design. For Teams to identify your client as being in a site, that client MUST egress to the Internet with a trusted IP address (recall that this is dedicated to your organization and static). If your reason for looking at proxy scenario LMO is because you can’t obtain a dedicated and static IP address in your remote/spoke site for Direct Routing, then you won’t be able to do LMO (or any other Site based Policy feature of Teams) at that site UNLESS you route traffic to Teams out via a site that does have a dedicated/static IP address.

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