SOLVED

Emergency Locations, Port Data, and physical phones

Steel Contributor

TLDR; Has anybody had any luck with Teams devices, such as a Poly CCX 400, Yealink MP56, or AudioCodes HD450 in getting location data when you have port level data defined?

 

I've seen this come up a couple of times, and have opened a case with Microsoft. First thing they did was point the fingers at the hardware vendors, but they all say they're just running the Teams client, so it has to be a Microsoft issue.  Setup goes something like this:

 

  • Setup a Civic Address

 

 

$civAddress = New-CsOnlineLisCivicAddress .....

 

 

  • Assign a subnet to that civic address

 

 

Set-CsOnlineLisSubnet -Subnet 1.2.3.0 -LocationId $civAddress.DefaultLocationId

 

 

  • Add a location for a room at that civic address

 

 

$loc = New-CsOnlineLisLocation -CivicAddressId $civAddress.CivicAddressId -Location 'Boardroom'

 

 

  • Assign a port to that location using LLDP information from the switch

 

 

Set-CsOnlineLisPort -LocationId $loc.LocationId -PortId 'Gi-0/0/14' -ChassisId 'AA-BB-CC-DD-EE-FF-'

 

 

  • Plug in physical phone device (such as any of the ones listed above)
  • Dial 911 (or 933 if you have testing setup)
  • Observe phone pulls the location up for the Civic Address, and PIDF-LO data sent to the 911/933 operator (such as Intrado) is the Civic Address only.
  • Unplug physical device, and plug in laptop
  • Dial 911 (or 933 if you have testing setup)
  • Observe Teams client address shows the room information you defined earlier, and PIDF-LO data also includes that room data

So this seems like the Teams client on a Windows workstation works fine, but physical phone device does not appear to be pulling the location properly.  Anybody successfully been able to get port level location data working with physical devices?

 

Thanks

53 Replies
Looks like it is going to take ages for a Fix :(
Moreover, for the Teams client to fetch location based on Chassis do we need to add any MS IP to Switch ACL, or just adding the Chassis ID with the location at Tenant should be fine.?

@radz 

 

Last update says they had code regression issues and pulled the code for expected release in June. What the heck?!

 

As for the switch ACLs, no.  The Teams Client uses LLDP to retrieve the switch chassis information.  This would mean your switch infrastructure must support LLDP.

Hi, I'm trying to get this working with Yealink MP54 Teams phones (running latest firmware) but I am struggling.
I have got it working using subnet so I know the trusted IPs and locations etc are all set up, but I cannot get it working with switch/port.
I have done a Wireshark capture and can see the LLDP information from the phone which I have put into TAC (using the xx-xx- format for switch MAC) but it does not give me the location.
I am also trying to do this with a Windows 10 client but I cannot get this working either.
I have a Cisco and UniFi switch and they both have LLDP enabled.

Does anyone have any tips please?
Thanks!
best response confirmed by ThereseSolimeno (Microsoft)
Solution

@JakeReed 

 

From my the last update from Microsoft, the next update will be in June should have fixes for the phones.

 

As for the MS Teams client itself, that should work assuming you have the correct information in Teams. I'd double check the values being sent in the LLDP packets to make sure you're using the right values for chassis ID and port ID.  Some switches will send extra information (TLVs) so it's important to grab the right fields.

 

If you connect a computer with Win10 and the Teams client on, give it some time to verify the networks. Go to Settings > Calling and see what location is showing up.  If you see a location, close the settings window, and hit ctrl+alt+shift+1. It'll dump a bunch of log files into your Downloads\ folder.  If you look at the file named "MSTeams Diagnostics <datetime>.txt" and search for chassisId, you should see what the Teams client is sending to Microsoft.  You could confirm this is what you have configured.

Thank you @jangliss this is really helpful.

I didn't see your update but I have seen it now. I assume this bug is regarding the native Teams phones getting location information at a port level? Did you ever get it working at just a switch level or didn't you try this?

I have done a Wireshark trace from my laptop Windows 10 client and my Yealink phone. 
Both traces give me the PortID as "Port 2" / "Port 8" and the chassisID as my switch MAC address in the format xx:xx:xx etc. The Microsoft documentation says to enter the MAC in their format xx-xx-xx which is what I did and it looks like you did the same format.
I still don't have any location information in my Teams client unfortunately. I added the locations into TAC a couple of weeks ago. 

I do have this logged with MS at the moment and after a couple of initial looks they said everything looks fine but so far there hasn't been a lot of traction with the case.

Cheers.

@JakeReed 

 

No LLDP location information (switch or port) is working on the Teams Phone devices, this should be fixed/released in June per support/PG.  Fingers crossed there.

 

For your issue, there's a couple of things you can probably check.

 

  • Ensure you setup the trusted IPs for your network.  This is the public IP address(es) that Teams will see clients appear from.  In the Teams Admin Center (TAC), you'll find this under Locations > Network Topology, or Get/Set-CsTentantTrustedIPAddress.
  • I'm assuming this is already done as Teams doesn't let you add a switch/port/bssid to a location unless it is already set, but the location must have lat/long defined.  You cannot edit a location address once it has been verified, so when creating civic addresses/locations, remember to set the lat/long
  • Verify if you get location data based on IP subnet.  Annoyingly you cannot use a supernet if you have locations broken down, so you have to define the subnet for each location. For example if you have an IP subnet of 10.10.0.0/16 for building A, and 10.10.1.0/24 for building A floor 1, you must define the subnet for the emergency location as 10.10.1.0.
  • Teams client updates the location information on two conditions, that I'm aware of.
    1. On network change (ie connecting to a new switch)
    2. Every 4 hours (I think that's the timing)

If you're still seeing issues resolving the location, you might take a look at the logs on the Teams client. With the Teams client in focus, use ctrl+alt+shift+1. It should dump a bunch of log files into your Downloads folder.  Depending on your client version, it might put it in a sub folder, it might not.  You'll want to look at the file named "MSTeams Diagnostics Log <datetime>.txt".  Search for getLocation, LocationCache, and LocationService.  Those will often give you a hint as to what is in the information being sent to Teams for the location.  My LocationCache entry in one of my logs looked something like this:

 

LocationCache: [e911][setLocationResponseInCache][key={"bssid":"ac-4a-56-XX-XX-XX","ipv4":"xx.xx.xx.xx","mac":"84:1b:77:xx:xx:xx","ssid":"XXXXXX","subnetLengthIpv4":"16","isCallingPlanUser":false}][value={"locationResponse":{"emergencyCallingPolicy":{"notificationGroup":"XXXXXXX","notificationMode":"NotificationOnly","policyDocument":"TeamsEmergencyCallingPolicy=Tenant:XXXXXX"},"emergencyCallRoutingPolicy":{...

 

In this case you can see it's showing BSSID, so I was on the wireless when this one was captured.

 

One last thing that might be worth an attempt, sometimes Teams caches data, and doesn't refresh when you think it might.  Ensure Teams is really closed (no running tasks), go into your %AppData%\Microsoft\ directory and rename Teams to Teams.Old, reopen Teams and test again.

 

Hope that helps.

@jangliss
Looks like MSFT has released the new Teams app version 1449/1.0.94.2021051303 which fix the LLDP issues for Phones. Hopefully, this fixes the fix..

https://support.microsoft.com/en-us/office/what-s-new-in-microsoft-teams-devices-eabf4d81-acdd-4b23-...
I did see that this week, seems they actually released a second one fairly quickly after this one. It's on my bench of testing Monday.
That's right, the latest version is 1449/1.0.94.2021052803 . I have tested it and no luck, it still didnt pick up the location.

@radz @JakeReed I think we are having a very similar issue with our setup of the admin portal and attempting to use Switch or Switch Port to define Emergency location "Place".  We are fine with matching on the first 2 criteria "Trusted IP" and then "Subnet" but we need to then use Switch and BSSID to match "Place".  BSSID actually works just fine for WIFI clients it is only the Switch that we cannot setup correctly. to identify LAN-connected devices.

 

We confirmed with Wireshark the our switches are broadcasting the Chassis ID (Base MAC address of our Cisco Switches) just fine but it appears that Teams client is still not able to pick this up.  Our MS rep just sent us something recently that said support of Switch / Switch port method is still "Pending Support" from MS so not sure if anyone actually has this working correctly or not on any LAN devices.

 

We are trying to test both PC running Teams client or MP54 Phone running Teams client, both connected by LAN and neither currently work with Switch designation.

 

If you are able to get this to work at all, please let us know!  We will do the same!

 

Thanks!

@doumis 

 

I've done switch and port level for multiple customers, and not had an issue with it except with physical phones (Yealink, Poly, Audiocodes). This appears to still be in question.

 

Have you looked over my previous responses at grabbing the log files to look at what's being sent to Teams from the desktop client, and ensured it matches?

@jangliss We have checked the _calling.txt log file  on LAN-connected devices and it shows no network information regarding switch or switch port so its as if Teams client is not seeing the switch info at all.

 

It only shows the bolded information below (IP/Mac has been removed for security), it does report the correct client IP and client MAC address however nothing about the switch or port.  

 

Networks and Locations known:
Network 1:
{
"ipv4": "xxx.xxx.xxx.xxx",
"mac": "yy:yy:yy:yy:yy:yy",
"subnetLengthIpv4": "25",
"isCallingPlanUser": false
}
 
Is this the only log file location we should be looking at for this information?  Note when I have defined BSSID for WIFI-connected PC, the BSSID is reported in this same log file location and section....Can you provide an example log file of working configuration using "switch"?
 
Thanks.

@doumiswhen you create your log files (ctrl+alt+shift+1) you'll want to look at the log file without the suffix, just the date.  For example "MSTeams Diagnostics Log 6_23_2021__2_03_19_PM.txt".  In that log file, search for "Location", "getLocation" or "e911". There's usually a few entries, an example of mine connected to wireless looks like:

 

2021-05-25T19:47:50.972Z Inf LocationCache: [e911][getLocationResponseFromCache][cacheHit=false][key={"bssid":"aa-bb-cc-dd-ee-ff","ipv4":"10.10.10.10","mac":"ff:ee:dd:cc:bb:aa","ssid":"MySecretSSID","subnetLengthIpv4":"24","isCallingPlanUser":false}][context=e911InfoChanged::emergencyService][cachedItem=undefined]

 

I don't have the logs currently for a switch connected device, but I believe it has "chassisid" in it.

 

Hope that helps.

@doumis The chassis ID should look like this in MSTeams Diagnostics Log 6_23_2021__2_03_19_PM.txt for the Client connected to switch
Inf LocationService: [e911][getLocationInternal][requestBody={"networkInformation":{"e911":[{"chassisId":"aa-bb-cc-dd-ee-00","portId":"Gi1/0/13"}]

hi @radz and @jangliss 

 

Checking several machines I see no entries for Chassis ID nor Port ID for LAN connected devices in this log file. - only IP and MAC info of the device itself.  We checked a wireshark capture running on the same machines and LLDP information (Switch and Port) for our Cisco switches is being presented to the Windows OS.  Teams just doesnt seem to be able to see it.  

 

Unsure where to turn next, please advise if you have any ideas.  Is there perhaps a policy on Teams admin center that would block this data from being seen by the client?

@doumis 

 

Could you try clearing all the Teams cache data on a test machine, and see if that forces a rediscovery?  That is, with Teams closed (actually exit, don't just minimize) go to %AppData%\Microsoft\ and rename Teams to Teams.old, relaunch Teams and sign back in.  Give it a bit of time, then hit ctrl+alt+shift+1 and take a look at the logs, also check in Settings > Calling to see if the location is set in there.

 

I've had issues previously with the Teams client not picking up some changes until the cache was cleared out completely, and the client itself didn't seem content with doing it itself.

@jangliss any further update from MS mate?

@radz 

 

Not yet unfortunately, though I just reached out again. I got a new case created and assigned to the original agent I had before, and they reported a number of people complaining it still wasn't working.  Last time I did observe they were not logging the full Port ID, but that could just be a logging issue.  Who knows!

@doumis 

You're not going crazy, friend.  A configuration that has been working for a while, appears to have stopped for me.  Same switch, same port, same tenant. I'm doing additional configuration testing.  Also observed some odd behavior with Set-CsOnlinePort earlier where it refused to update the location id.

@radz 

 

Status update so far from Microsoft is a Britney Spears hit song; "Ooops, we did it again".  As of Friday 9th:

 


The fix was not successful in the deployment regardless of the notes that were displayed. The last comment on it was Friday that they are still trying to determine what is wrong, so it is actively being worked on at this time. I have brought this up to my Team lead to discuss in an upcoming meeting with some higher-ups.

And the status update I got this morning was "Still monitoring the case, no ETA"