Troubleshooting Network Topology in Microsoft Teams Direct Routing
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 whatismyip.com 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 165.225.0.0 Zscaler IP range. However, there is no site match since my client is at home.
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:
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!
