All Microsoft Teams clients are capable of using location information from the Network, OS, or User for emergency calls. When the network is the desired source of the location, there are 3 key places that need to be configured.
First, the Trusted IP Address. This address is used by the Teams client to understand if it is on your organization’s network, or outside/remote. Trusted IP Address is not used beyond that.
Second, the client’s IP address is checked about the subnets/supernets configured in the Network Topology to establish if there’s a match for a network topology site. If there is a match, the policies from that site are applied. For emergency calls, there is the Emergency Call Routing Policy, that establishes the route a call will take to reach emergency call takers if Direct Routing is being used, and there is the Emergency Calling Policy to configure notifications. There is one more policy not related to emergency calling, and that’s the Roaming Policy, which you can read about here.
Third, the client’s IP address and BSSID for wireless, and IP address, switch chassis, and switch port for wired, are compared against the LIS database. LIS stands for Location Information Services, and its job is to match your network information to the various places in your organization that first responders should respond to.
Ultimately, the goal is to have the correct location displayed in the user’s Teams client. This location is what will be passed through to the SBC in the Emergency Call Routing Policy, and off to an emergency call taker. It’s not uncommon for an address to not appear, or for the wrong address to appear, especially in new deployments. Fret not, there’s an easy way to see what’s happening.
Right click on the Teams icon in the systray – you may need to click on the ^ icon beside the clock to see it. Select “Collect Support Files”. You’ll see a flurry of activity as the client writes files to the downloads folder, and then zips them.
Grab that zip file and open it. We’re just reading a text file in the zip, so you don’t need to unzip and then find the file. Click on the folder called “web”, and then double click the file named “MSTeams Diagnostics Log 7_7_2022__9_31_02_PM_calling.txt” or similar, depending on the date/time you created the log file.
Search for the phrase “trustedIpMatchInfo”. That’s the actual case used in the file, but make life easy on yourself and make sure your search isn’t case sensitive. The first block you’ll see will look like this:
“_comment”: “Match Client Public IP to Tenant Trusted IP”
Here, the public IP shown is the public IP address that the Teams client used to connect to Teams. This IP needs to be in the “Trusted IP Address” list within Teams for the Teams client to be considered “internal”, and for the rest of the internal network policies to take effect.
The next section is used to apply policies if the Teams client is within a given site internal to the organization.
“_comment”: “Used to match endpoint subnet to Tenant site if trustedIpMatchInfo matches”
In this case, the LAN IP is 192.168.20.207. Even if there is a Network Site defined with this subnet, the policies for that Network Site will not apply since the Public IP/Trusted IP did not match.
Common policies applied based on the Network Site include Location Based Routing, Roaming Policies, Emergency Calling Policy, and Emergency Call Routing Policy. See this post for details.
The next section is used to establish the Teams Client’s location within the organization for emergency calling purposes.
“matchingIdentity”: “50.6583, -120.383”,
“_comment”: “Used to find emergency address, against Tenant Location Network Information (LIS), otherwise against Client Geo Location Information (CLS) if available”
Note here that my LAN IP did match against the LIS database, however Teams would not use this information for my emergency location as my Public IP didn’t match. There’s no way for Teams to know that I’m not in a coffee shop or at home with the same 192.168.20.0/24 subnet as the office.
For the Teams client to “find” your location for emergency calling, ideally all 3 of the above should result in “Matched”: The client’s public IP must be in the Trusted IP Address list, the NetworkLocationMatchInfo must find your IP subnet, wireless BSSID, Switch chassis ID, or switch Chassis ID and port name in the LIS database. You don’t necessarily need to have “matched” for the Network Location section, as you could have valid Global policies that would apply, or perhaps user-level policies assigned to the user. That may be the case in a very small organizationwith just one location, but would indicate a bad design in a larger organization with multiple locations.