Troubleshooting Network Topology in Microsoft Teams Direct Routing

Matt Ellis
Feb 10 · 3 min read

If you are playing around with location based routing or local media optimization in Microsoft Teams Direct Routing, you will have no doubt had to configure Trusted IPs and network sites in Microsoft Teams. In order for LBR or LMO to work correctly, a client needs to be determined to be “internal”. This is done using Trusted IPs and network subnets in the Network Topology section of the Teams Admin Center. It is often wise to check if what you have configured is correct. I’ve also found that trusted IPs can take a while to filter through the Teams service, so instead of waiting for stuff to miraculously work you can use the process below to check what your client thinks is going on.

Alternatively, maybe the networking team has snuck in a new subnet without telling you, or the security team have changed the firewall IP and the clients no longer think they’re internal?

I have also found that the MediaLine_Description_ReflexiveLocalIPAddress_IPAddr or Connectivity_LocalSite IP shown in the calling logs in the TAC also don’t accurately reflect the actual Trusted IP you need to enter. We use Zscaler, so things like don’t actually show the IP Microsoft sees when your client makes the REST API call during call setup.

The Teams client doesn’t easily surface this amount of data, so you need to generate some debug log files in order to see it.

While in Microsoft Teams, hold down Ctrl + Alt + Shift + 1 (or Option + Command + Shift + 1 for Mac) and the Teams client will automatically download a series of logs in your Downloads folder (%userprofile%\Downloads in Windows, and ~/Downloads on Mac).

The folder will be called “MSTeams Diagnostics Log” with a timestamp after it:

There are 3 subfolders:

The one we’re interested in is the web folder. In the web folder you will see a series of log files:

There are loads of interesting log files here but the one we want for this has a suffix of: _calling

At the top of the file you will see a list of previously placed calls showing you termination reasons and subcodes etc.

Further down you will see a Current known location section. In the example below you will see that my client has matched for a Trusted IP which matches a Zscaler IP range. However, there is no site match since my client is at home.

Current known location showing matched trusted IP, but no matching site info.

It’s worth noting that if the external/trusted IP is not matched, Teams will not try and match the subnet as it’s already considered an external client.

This following example shows a client that has matched both a trusted IP and a site subnet:

Current known location showing matched trusted IP as well as matching site info.

So, that’s pretty much it. I have found that you might need to logout and back in to the Teams client if you have only very recently made changes to the network topology in the TAC. I’m not sure how often the client pulls down the new topology.

Anyway, happy troubleshooting!

365 UC

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

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store