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.