# Network-based location for E911 across platforms Canonical: https://warmtransfer.net/knowledge/e911-network-location-discovery Last verified: 2026-10-14 # Network-based location for E911 across platforms Microsoft Teams, Webex Calling, Zoom Phone and Cisco Emergency Responder locate emergency callers by matching network identifiers such as switch port, wireless access point BSSID and IP subnet against configured locations[^29][^41][^50][^4]. Base HELD identifies a device only by the source IP address of its location request, while RFC 6155 adds other device identifiers and RFC 7105 lets a device report LLDP and 802.11 measurements[^11][^17][^18][^20]. ## How it works In HELD (RFC 5985), the Location Information Service (LIS) identifies the requesting device by the source IP address of the location request, and other identifiers are outside the base protocol[^11]. A HELD locationResponse returns location by value as a PIDF-LO document or by reference as 1 or more location URIs[^13]. The request may ask for the any, geodetic, civic or locationURI types[^13]. RFC 5985 warns that a NAT or VPN between the device and the LIS can make the returned location inaccurate[^12]. It advises devices to perform LIS discovery and an initial query before connecting to a VPN, SOCKS or proxy server[^12]. RFC 6155 extends HELD so a requester can identify a device by IP address, MAC address, transport port numbers, NAI, URI, FQDN, cellular identifiers or DHCP Unique Identifier[^17]. RFC 6155 does not define LLDP or 802.11 measurements[^17]. RFC 7105 lets a device report LLDP chassis and port identifiers learned from the adjacent node, and it requires the device to report them exactly as provided[^18]. RFC 7105 also defines an 802.11 WLAN measurement in which the access point BSSID is the only mandatory element, with optional signal measurements reported as RCPI[^20]. RFC 7105 treats device-provided measurements as potentially falsified[^19]. It describes lying-by-proxy and environment-spoofing threats and requires HELD over TLS for measurement data[^19]. WarmTransfer's reading of the sources is that the commercial softphone pattern of reporting LLDP chassis/port and BSSID to a cloud location service mirrors the device-provided measurement model of RFC 7105, not the IP-only identification of base HELD[^21]. ## Regulatory context in the US 47 CFR 9.3 defines dispatchable location as a location delivered to the PSAP with a 911 call[^7]. That location consists of the validated street address of the calling party plus additional information, such as suite or apartment, needed to adequately identify the caller's location[^7]. Under 47 CFR 9.16(b)(3)(i), an on-premises fixed MLTS telephone must provide automated dispatchable location no later than January 6, 2021[^8]. Under 47 CFR 9.16(b)(3)(ii), from January 6, 2022 an on-premises non-fixed MLTS device must provide automated dispatchable location when technically feasible[^9]. Where that is not feasible, the device must provide dispatchable location from an end-user manual update or alternative location information[^9]. Under 47 CFR 9.16(b)(3)(iii), from January 6, 2022 an off-premises MLTS device must provide automatic dispatchable location if technically feasible[^10]. Otherwise it must provide a manual end-user update or enhanced location information, which may be coordinate-based[^10]. We infer that network-identifier mapping is the mechanism these platforms use to try to meet the "automated dispatchable location when technically feasible" standard for non-fixed devices, with manual user entry as the regulatory fallback[^14]. ## Platform differences ### Microsoft Teams When a Teams client queries the LIS, the LIS matches network elements in this order, and the first match is used[^29]: - Wireless access point first[^29] - Then Ethernet switch and port[^29] - Then Ethernet switch[^29] - Then subnet[^29] Teams attempts an IP-based dynamic policy or location lookup only when the user's external IP address matches an entry in the tenant's trusted IP addresses[^34]. Teams makes LIS requests based on Ethernet switch (PortID or ChassisID) and wireless access point (BSSID) whether or not the external IP address matches a trusted IP address[^28]. Cloud proxy deployments that modify the source IP address of Teams clients do not support Teams network configuration setting lookups[^23]. Teams LIS subnet matching calculates a network ID from the client IP address and the client-reported prefix length[^30]. That network ID must equal a subnet configured in the LIS; for example, 10.10.10.150/25 yields 10.10.10.128[^30]. Subnets defined in Teams network sites do not render dynamic locations by themselves and must be redefined in the LIS[^33]. A Windows client with a stateful DHCPv6 address can report a /128 prefix[^26]. In that case the Teams LIS computes the full address as the network ID and does not match a /64 LIS subnet[^26]. The same client can still match a /64 network site and receive its emergency policies[^26]. Where IPv6 subnet matching fails, Microsoft directs admins to use one of these alternatives[^27]: - An IPv4 LIS subnet for dual-stack endpoints[^27] - A switch or switch/port entry for IPv6-only wired endpoints[^27] - A BSSID entry for IPv6-only wireless endpoints[^27] Microsoft also says not to create per-device /128 LIS entries[^27]. Client support varies by location type:[^36][^31] - Subnet-based locations are supported on all Teams clients[^36]. - Wi-Fi (BSSID) based locations are supported on all Teams clients except Teams phones[^36]. - Ethernet/switch (LLDP) location is supported on Windows 10.0 or later and on Teams Rooms on Windows and Android[^31]. - On macOS, Ethernet/switch (LLDP) location is supported only with Microsoft's LLDP enablement software[^31]. - On Teams phones, Ethernet/switch (LLDP) location requires app 1449/1.0.94.2021110101 or later[^31]. - Dynamic emergency calling, including security desk notification, is not supported on the Teams web client[^35]. For web-client users, Microsoft recommends a calling policy with Web PSTN calling turned off[^35]. Emergency addresses assigned to network identifiers for dynamic location must include geo codes[^25]. Addresses without geo codes cannot be assigned to those identifiers[^25]. Some network setting changes, such as a new address or network identifier, can take up to 4 hours to propagate to Teams clients[^32]. For Direct Routing dynamic emergency calling, the SBC gateway must have PidfloSupported set to true[^24]. The tenant must also connect to an Emergency Routing Service provider (US and Canada) or configure the SBC for an ELIN application[^24]. ### Webex Calling with RedSky In Webex Calling enhanced emergency calling, Cisco MPP devices use HTTP Enabled Location Delivery (HELD) to report their network environment to RedSky[^39]. MPP phones report the upstream LLDP-enabled switch, the wireless access point BSSID, the IP address, or their MAC addresses for RedSky to match against configured locations[^41]. Webex Calling devices that do not support HELD, such as Poly VVX/Trio and Yealink phones, are located by the caller ID sent with the emergency call rather than by network discovery[^42]. For Webex App network discovery, Cisco Discovery Protocol (CDP) is not supported[^37]. The desktop app reports BSSID, IP address, upstream gateway MAC and LLDP information[^37]. When a computer running Webex App connects through an IP phone's pass-through port, the app cannot read LLDP information because the switch's LLDP packets stop at the phone[^43]. Webex desktop app on Windows and macOS ignores all VPN and virtual network interfaces for emergency network discovery[^45]. On Windows, it identifies these interfaces by the Virtual parameter of the network adapter[^45]. If a HELD-capable MPP device's network location cannot be determined, Webex Calling enhanced emergency calling falls back to the phone-number-based address[^38]. RedSky offers a "Use DID for Fall-Back Routing of HELD" option[^38]. If Webex Calling E911 service cannot find a dispatchable location for a device placing an emergency call, the call goes to a relay center[^44]. Relay charges may be passed to the customer when the user entered no address or RedSky was misconfigured[^44]. ### Webex for BroadWorks Webex for BroadWorks E911 integration configures a Primary and Secondary HELD Server URL in the third-party emergency calling settings[^2]. These URLs are exposed to the client as dynamic tags[^2]. The tag EMERGENCY_REDSKY_USER_LOCATION_PROMPTING_WXT controls when the Webex App prompts for an unknown location[^3]. Its default is once_per_login, and the "aggressive" value prompts on every network change to an unknown location[^3]. ### Zoom Phone Zoom Phone nomadic emergency services checks network data in this order[^50]: - LLDP switch MAC plus port first[^50] - Then BSSID[^50] - Then public plus private IP/subnet[^50] - Then public IP[^50] - Then GPS[^50] - Then site default, account default or Unknown[^50] Sources disagree on this order: a 2020 Zoom blog described location as resolved by BSSID first, then IP subnet, then GPS, then a static portal address, with no switch or LLDP step[^47]. LLDP switch matches and public-plus-private IP/subnet matches apply only to company locations[^49]. BSSID and public IP matches can also resolve to a user's personal locations[^49]. Zoom Phone evaluates location scope in this order: the user's assigned site, all other account sites, the user's personal locations, then default or Unknown[^57]. Zoom Phone allows up to 2 consecutive wildcard characters in the last octet of a BSSID, and up to 20 BSSID entries may contain wildcards[^48]. When a client detects multiple configured BSSIDs, the BSSID with the highest RSSI wins, even over the access point the client is connected to[^56]. Zoom Workplace applications do not transmit LLDP to the switch, so the switch must send LLDP[^46]. Some switch vendors require LLDP-MED on the port, and Zoom recommends 30-second LLDP timers[^46]. For a Zoom app on a PC behind an IP phone, the phone must pass the switch's LLDP packets through to the PC[^54]. The phone must not generate its own LLDP toward the PC[^54]. Nomadic location detection, including LLDP, is not supported on Linux, and on macOS it requires the privileged Zoom Helper App[^52]. Zoom notes that IP-based matching can be unreliable where network address translation or shared subnets make IPs insufficiently unique[^53]. In that case, Zoom directs admins to switch data[^53]. Zoom Phone uses GPS-derived approximate addresses only in the US and Canada, only on GPS-capable devices, and only when no network data matches[^51]. In the US and Canada, a caller with no network match, no GPS and no default address is reported as Unknown[^58]. That call is routed through a nationwide clearinghouse that verbally confirms location[^58]. US and Canada Zoom Native calls carry the address in PIDF-LO without ELINs[^55]. Outside the US and Canada, Zoom Phone generally requires ELINs and reports the originating caller ID to public safety[^55]. ### Cisco Emergency Responder Cisco Emergency Responder tracks phones by switch port using SNMP and CDP[^4]. For a non-Cisco switch or one with CDP disabled, the admin enables CAM-based phone tracking on the LAN switch entry[^4]. ERLs are assigned to switch ports after phone tracking completes[^6]. An ERL can be as granular as building, floor, quadrant, room or workstation[^6]. When a call is placed through Cisco Emergency Responder and no ERL is associated with the phone, the Default ERL is used, so Cisco advises configuring it[^5]. ### RingCentral The RingCentral Emergency Response Locations API allows up to 10,000 company-wide ERLs per account and up to 20 private ERLs per user[^16]. RingCentral is phasing out setting an emergency address by updating a device[^15]. Error EME-384 indicates that the ERL workflow must be used instead[^15]. ### 8x8 8x8 Nomadic 911 must be enabled for the account, through an 8x8 Support case or Sales, before any configuration can be performed[^1]. ## Diagnosing and testing If a Teams IP-based lookup fails, first check the client's external IP against the tenant's trusted IP addresses, because Teams attempts IP-based lookups only on a match[^34]. Next, compare the network ID computed from the client's reported prefix with the configured LIS subnet[^30]. A /128 prefix reported by a stateful DHCPv6 Windows client will not match a /64 LIS subnet[^26]. After a change, allow up to 4 hours before concluding that a new address or network identifier has failed to reach Teams clients[^32]. If a desktop softphone behind an IP phone is missing LLDP data, check pass-through behaviour[^43][^54]. On Webex App, the switch's LLDP packets stop at the phone[^43]. Zoom requires the phone to pass the switch's LLDP through without generating its own[^54]. If a Zoom client resolves to an unexpected wireless location, check whether a different configured BSSID has a stronger RSSI than the connected access point[^56]. Teams Calling Plan, Operator Connect and Teams Phone Mobile users in the US or Canada can dial 933 to hear back their calling number and emergency address[^22]. Teams Direct Routing customers must coordinate testing with their ERSP[^22]. Webex Calling enables RedSky per location in 2 stages[^40]. First, the admin allows RedSky to receive network connectivity information and test calls (state Location Integration On) and places 933 test calls[^40]. Then the admin turns on Route Emergency Calls to RedSky (state Routing On)[^40]. ## See also - [Dispatchable location and nomadic user handling](https://warmtransfer.net/knowledge/dispatchable-location) - [Setting up dynamic emergency calling in Microsoft Teams](https://warmtransfer.net/knowledge/teams-dynamic-e911-setup) - [Setting up Webex Calling emergency calling with RedSky](https://warmtransfer.net/knowledge/webex-calling-redsky-e911-setup) - [Setting up Zoom Phone emergency calling](https://warmtransfer.net/knowledge/zoom-phone-emergency-calling-setup) - [Cisco Emergency Responder setup](https://warmtransfer.net/knowledge/cisco-emergency-responder-setup) - [US emergency calling regulatory requirements](https://warmtransfer.net/knowledge/e911-us-regulatory) - [E911 test calls and validation](https://warmtransfer.net/knowledge/e911-testing-procedures) - [Troubleshooting 911 calls that route with the wrong location](https://warmtransfer.net/knowledge/e911-routing-failures) ## Applicability Applies to: Microsoft Teams, Cisco Webex Calling, Cisco Webex App, Cisco Webex for BroadWorks, Zoom Phone, Cisco Emergency Responder, RingCentral Platform API, and 8x8 Work. Deployments: on-premises and multi-tenant. Sources checked 2026-10-14. Zoom Phone's GPS-derived addresses apply only in the US and Canada[^51]. Zoom Phone's ELIN-free PIDF-LO delivery applies to US and Canada Zoom Native calls, and ELINs are generally required elsewhere[^55]. The Teams Direct Routing Emergency Routing Service provider option applies to the US and Canada[^24]. The FCC dispatchable location requirements cited here are those of 47 CFR 9.3 and 9.16(b)(3)[^7][^8][^9][^10]. The protocol behaviour described here is that of RFC 5985, RFC 6155 and RFC 7105[^11][^17][^18]. ## What remains uncertain Sources disagree on Zoom Phone's detection order, because a 2020 Zoom blog omitted the LLDP switch step that current Zoom guidance places first[^47][^50]. When Zoom Phone added LLDP switch data ahead of BSSID is not covered by the sources below. RedSky receives switch, BSSID, IP and MAC data from Webex Calling MPP phones[^41]. The order in which RedSky's matching evaluates MAC, LLDP port, LLDP chassis, BSSID and IP ranges is not covered by the sources below. Whether other Cisco device types on MPP firmware are HELD-capable in Webex Calling is not covered by the sources below. Webex desktop app ignores VPN and virtual network interfaces for emergency network discovery[^45]. RFC 5985 warns that a VPN between device and LIS can make the returned location inaccurate[^12]. How each platform resolves location for softphones on full-tunnel versus split-tunnel VPN is not covered by the sources below. 8x8 Nomadic 911 must be enabled before configuration[^1]. How 8x8 Nomadic 911 maps IP subnets, LLDP chassis/port and BSSID to locations is not covered by the sources below. NG911 standards requirements for enterprise LIS and HELD use are not covered by the sources below. Network-based emergency location features of calling platforms not named in this article are not covered by the sources below. ## Sources [^1]: 8x8 Nomadic 911 must be enabled for the account, via an 8x8 Support case or Sales, before any configuration can be performed. Source: [Nomadic 911 Administration and Planning Guides](https://help.8x8.com/docs/nomadic-911-administration-and-planning-guides.md), Page body, enablement paragraph. Checked 2026-10-14. [^2]: Webex for BroadWorks E911 integration configures a Primary and Secondary HELD Server URL in the third-party emergency calling settings, exposed to the client as dynamic tags. Source: [E911 Emergency Calling in Webex for BroadWorks](https://help.webex.com/en-us/article/fwm1hy/E911-Emergency-Calling-with-RedSky), Configure Third-Party Calling URLs table; Dynamic Tags table. Checked 2026-10-14. [^3]: In Webex for BroadWorks, the tag EMERGENCY_REDSKY_USER_LOCATION_PROMPTING_WXT controls when the Webex App prompts for an unknown location, defaulting to once_per_login, with 'aggressive' prompting on every network change to an unknown location. Source: [E911 Emergency Calling in Webex for BroadWorks](https://help.webex.com/en-us/article/fwm1hy/E911-Emergency-Calling-with-RedSky), Webex Client Configuration Tags for Emergency Calling > Custom Tags. Checked 2026-10-14. [^4]: Cisco Emergency Responder tracks phones by switch port using SNMP and CDP, and for a non-Cisco switch or one with CDP disabled the admin enables CAM-based phone tracking on the LAN switch entry. Source: [Integrate Emergency Responder with CUCM](https://www.cisco.com/c/en/us/support/docs/unified-communications/emergency-responder/211453-Cisco-Emergency-Responder-Integration-wi.html), Identify LAN Switches. Checked 2026-10-14. [^5]: When a call is placed through Cisco Emergency Responder and no ERL is associated with the phone, the Default ERL is used, so Cisco advises configuring it. Source: [Integrate Emergency Responder with CUCM](https://www.cisco.com/c/en/us/support/docs/unified-communications/emergency-responder/211453-Cisco-Emergency-Responder-Integration-wi.html), Default ERL configuration. Checked 2026-10-14. [^6]: In Cisco Emergency Responder, ERLs are assigned to switch ports after phone tracking completes, and an ERL can be as granular as building, floor, quadrant, room or workstation. Source: [Integrate Emergency Responder with CUCM](https://www.cisco.com/c/en/us/support/docs/unified-communications/emergency-responder/211453-Cisco-Emergency-Responder-Integration-wi.html), Phone Tracking via Switch Ports; ERL definition. Checked 2026-10-14. [^7]: 47 CFR 9.3 defines dispatchable location as a location delivered to the PSAP with a 911 call consisting of the validated street address of the calling party plus additional information such as suite, apartment or similar information needed to adequately identify the caller's location. Source: [47 CFR part 9 — 911 Requirements](https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-9), § 9.3, definition 'Dispatchable location'. Checked 2026-10-14. [^8]: Under 47 CFR 9.16(b)(3)(i), an on-premises fixed MLTS telephone must provide automated dispatchable location no later than January 6, 2021. Source: [47 CFR part 9 — 911 Requirements](https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-9), § 9.16(b)(3)(i). Checked 2026-10-14. [^9]: Under 47 CFR 9.16(b)(3)(ii), from January 6, 2022 an on-premises non-fixed MLTS device must provide automated dispatchable location when technically feasible, otherwise dispatchable location from an end-user manual update or alternative location information. Source: [47 CFR part 9 — 911 Requirements](https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-9), § 9.16(b)(3)(ii). Checked 2026-10-14. [^10]: Under 47 CFR 9.16(b)(3)(iii), from January 6, 2022 an off-premises MLTS device must provide automatic dispatchable location if technically feasible, otherwise a manual end-user update or enhanced location information, which may be coordinate-based. Source: [47 CFR part 9 — 911 Requirements](https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-9), § 9.16(b)(3)(iii). Checked 2026-10-14. [^11]: In HELD (RFC 5985), the LIS identifies the requesting device by the source IP address of the location request; other identifiers are out of scope of the base protocol. Source: [HTTP-Enabled Location Delivery (HELD)](https://www.rfc-editor.org/rfc/rfc5985.html), Sections 4 and 5.1. Checked 2026-10-14. [^12]: RFC 5985 warns that a NAT or VPN between device and LIS can make the returned location inaccurate, and advises devices to perform LIS discovery and an initial query before connecting to a VPN, SOCKS or proxy server. Source: [HTTP-Enabled Location Delivery (HELD)](https://www.rfc-editor.org/rfc/rfc5985.html), Sections 4.1, 4.1.1, 4.1.2. Checked 2026-10-14. [^13]: A HELD locationResponse returns location by value as a PIDF-LO document or by reference as one or more location URIs, and the request may ask for any, geodetic, civic or locationURI types. Source: [HTTP-Enabled Location Delivery (HELD)](https://www.rfc-editor.org/rfc/rfc5985.html), Sections 4.2, 4.3, 6.2. Checked 2026-10-14. [^14]: Network-identifier mapping is the mechanism these platforms use to try to meet the 'automated dispatchable location when technically feasible' standard for non-fixed devices, with manual user entry as the regulatory fallback (inferred). Source: [47 CFR part 9 — 911 Requirements](https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-9), § 9.16(b)(3)(ii)-(iii), read with vendor claims in this packet. Checked 2026-10-14. [^15]: RingCentral is phasing out setting an emergency address by updating a device; error EME-384 indicates the ERL workflow must be used instead. Source: [Emergency Locations](https://developers.ringcentral.com/guide/provisioning/location/emergency-locations), Method 1: update by device, warning. Checked 2026-10-14. [^16]: The RingCentral Emergency Response Locations API allows up to 10,000 company-wide ERLs per account and up to 20 private ERLs per user. Source: [Emergency Locations](https://developers.ringcentral.com/guide/provisioning/location/emergency-locations), Emergency Response Locations (Method 2), feature-check limits. Checked 2026-10-14. [^17]: RFC 6155 extends HELD so a requester can identify a device by IP address, MAC address, transport port numbers, NAI, URI, FQDN, cellular identifiers or DHCP Unique Identifier; it does not define LLDP or 802.11 measurements. Source: [Use of Device Identity in HTTP-Enabled Location Delivery (HELD)](https://www.rfc-editor.org/rfc/rfc6155.html), Sections 3.1 to 3.8. Checked 2026-10-14. [^18]: RFC 7105 lets a device report LLDP chassis and port identifiers learned from the adjacent node in a location request, and requires the device to report them exactly as provided. Source: [Using Device-Provided Location-Related Measurements in Location Configuration Protocols](https://www.rfc-editor.org/rfc/rfc7105.html), Section 5.1. Checked 2026-10-14. [^19]: RFC 7105 treats device-provided measurements as potentially falsified, describing lying-by-proxy and environment-spoofing threats and requiring HELD over TLS for measurement data. Source: [Using Device-Provided Location-Related Measurements in Location Configuration Protocols](https://www.rfc-editor.org/rfc/rfc7105.html), Sections 6, 7.1.4, 7.1.6. Checked 2026-10-14. [^20]: RFC 7105 defines an 802.11 WLAN measurement in which the access point BSSID is the only mandatory element, with optional signal measurements reported as RCPI. Source: [Using Device-Provided Location-Related Measurements in Location Configuration Protocols](https://www.rfc-editor.org/rfc/rfc7105.html), Section 5.3. Checked 2026-10-14. [^21]: The commercial softphone pattern of reporting LLDP chassis/port and BSSID to a cloud location service mirrors the device-provided measurement model of RFC 7105 rather than the IP-only identification of base HELD (inferred). Source: [Using Device-Provided Location-Related Measurements in Location Configuration Protocols](https://www.rfc-editor.org/rfc/rfc7105.html), Sections 5.1 and 5.3, compared with vendor claims in this packet. Checked 2026-10-14. [^22]: Teams Calling Plan, Operator Connect and Teams Phone Mobile users in the US or Canada can dial 933 to hear back their calling number and emergency address, while Direct Routing customers must coordinate testing with their ERSP. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Test emergency calling. Checked 2026-10-14. [^23]: Cloud proxy deployments that modify the source IP address of Teams clients do not support Teams network configuration setting lookups. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Configure network settings, Important box. Checked 2026-10-14. [^24]: For Teams Direct Routing dynamic emergency calling, the SBC gateway must have PidfloSupported set to true and the tenant must connect to an Emergency Routing Service provider (US and Canada) or configure the SBC for an ELIN application. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Emergency calling prerequisites for Direct Routing; Set up an Emergency Routing Service provider. Checked 2026-10-14. [^25]: Teams emergency addresses assigned to network identifiers for dynamic location must include geo codes; addresses without geo codes cannot be assigned to those identifiers. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Assign emergency addresses, paragraph after the bullet list. Checked 2026-10-14. [^26]: A Windows client with a stateful DHCPv6 address can report a /128 prefix, so Teams LIS computes the full address as the network ID and does not match a /64 LIS subnet, even though the same client can still match a /64 network site and receive its emergency policies. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Configure Location Information Service > IPv6 subnet matching. Checked 2026-10-14. [^27]: Where IPv6 subnet matching fails, Microsoft directs admins to an IPv4 LIS subnet for dual-stack endpoints, a switch or switch/port entry for IPv6-only wired endpoints, or a BSSID entry for IPv6-only wireless endpoints, and says not to create per-device /128 LIS entries. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Configure Location Information Service > IPv6 subnet matching, scenario table and following paragraph. Checked 2026-10-14. [^28]: Teams makes LIS requests based on Ethernet switch (PortID or ChassisID) and wireless access point (BSSID) regardless of whether the external IP address matches a trusted IP address. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Configure network settings, Note following the trusted IP paragraph. Checked 2026-10-14. [^29]: When a Teams client queries the Location Information Service, the LIS matches network elements in the order wireless access point, Ethernet switch and port, Ethernet switch, then subnet, and the first match is used. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Plan for emergency calling, numbered step 2, second bullet. Checked 2026-10-14. [^30]: Teams LIS subnet matching calculates a network ID from the client IP address and the client-reported prefix length, and that network ID must equal a subnet configured in LIS (for example 10.10.10.150/25 yields 10.10.10.128). Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Configure network settings, Note on defining subnets in LIS. Checked 2026-10-14. [^31]: Teams Ethernet/switch (LLDP) location is supported on Windows 10.0 or later, on macOS only with Microsoft's LLDP enablement software, on Teams phones with app 1449/1.0.94.2021110101 or later, and on Teams Rooms on Windows and Android. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Supported clients, 'Ethernet/Switch (LLDP) is supported on' list. Checked 2026-10-14. [^32]: Some Teams network setting changes, such as a new address or network identifier, can take up to four hours to propagate to Teams clients. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Configure network settings, paragraph before the LIS subnet Note. Checked 2026-10-14. [^33]: Subnets defined in Teams network sites do not render dynamic locations by themselves; they must be redefined in the Location Information Service. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Configure Location Information Service > Using PowerShell, Important box. Checked 2026-10-14. [^34]: Teams attempts an IP-based dynamic policy or location lookup only when the user's external IP address matches an entry in the tenant's trusted IP addresses. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Configure network settings, paragraph on trusted IP addresses. Checked 2026-10-14. [^35]: Teams dynamic emergency calling, including security desk notification, is not supported on the Teams web client, and Microsoft recommends a calling policy with Web PSTN calling turned off for web-client users. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Supported clients, second Note. Checked 2026-10-14. [^36]: Subnet-based locations are supported on all Teams clients, but Wi-Fi (BSSID) based locations are supported on all Teams clients except Teams phones. Source: [Configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling), Supported clients, first Note. Checked 2026-10-14. [^37]: For Webex App network discovery in Webex Calling, Cisco Discovery Protocol (CDP) is not supported; the desktop app reports BSSID, IP address, upstream gateway MAC and LLDP information. Source: [Enhanced Emergency Calling for Webex Calling](https://help.webex.com/en-us/article/av6oo3/Enhanced-Emergency-Calling-for-Webex-Calling), Webex App (HELD+) network discovery description. Checked 2026-10-14. [^38]: If a HELD-capable MPP device's network location cannot be determined, Webex Calling enhanced emergency calling falls back to the phone-number-based address, and RedSky offers a 'Use DID for Fall-Back Routing of HELD' option. Source: [Enhanced Emergency Calling for Webex Calling](https://help.webex.com/en-us/article/av6oo3/Enhanced-Emergency-Calling-for-Webex-Calling), Caller ID fallback text; RedSky HELD/HELD+ Routing settings. Checked 2026-10-14. [^39]: In Webex Calling enhanced emergency calling, Cisco MPP devices use HTTP Enabled Location Delivery (HELD) to report their network environment to RedSky. Source: [Enhanced Emergency Calling for Webex Calling](https://help.webex.com/en-us/article/av6oo3/Enhanced-Emergency-Calling-for-Webex-Calling), Enhanced emergency calling for Webex Calling, device support and network discovery section. Checked 2026-10-14. [^40]: Webex Calling enables RedSky per location in two stages: first allow RedSky to receive network connectivity information and test calls (state Location Integration On), place 933 test calls, then turn on Route Emergency Calls to RedSky (state Routing On). Source: [Enhanced Emergency Calling for Webex Calling](https://help.webex.com/en-us/article/av6oo3/Enhanced-Emergency-Calling-for-Webex-Calling), Control Hub location-level configuration steps. Checked 2026-10-14. [^41]: Webex Calling MPP phones report the upstream LLDP-enabled switch, the wireless access point BSSID, the IP address, or their MAC addresses for RedSky to match against configured locations. Source: [Enhanced Emergency Calling for Webex Calling](https://help.webex.com/en-us/article/av6oo3/Enhanced-Emergency-Calling-for-Webex-Calling), Network discovery description for HELD MPP devices. Checked 2026-10-14. [^42]: Webex Calling devices that do not support HELD, such as Poly VVX/Trio and Yealink phones, are located by the caller ID sent with the emergency call rather than by network discovery. Source: [Enhanced Emergency Calling for Webex Calling](https://help.webex.com/en-us/article/av6oo3/Enhanced-Emergency-Calling-for-Webex-Calling), Device support: non-HELD devices. Checked 2026-10-14. [^43]: When a computer running Webex App connects through an IP phone's pass-through port, the app cannot read LLDP information because the switch's LLDP packets stop at the phone. Source: [Enhanced Emergency Calling for Webex Calling](https://help.webex.com/en-us/article/av6oo3/Enhanced-Emergency-Calling-for-Webex-Calling), Webex App desktop network discovery description. Checked 2026-10-14. [^44]: If Webex Calling E911 service cannot find a dispatchable location for a device placing an emergency call, the call goes to a relay center, and relay charges may be passed to the customer when the user entered no address or RedSky was misconfigured. Source: [Enhanced Emergency Calling for Webex Calling](https://help.webex.com/en-us/article/av6oo3/Enhanced-Emergency-Calling-for-Webex-Calling), No dispatchable location / relay center paragraph. Checked 2026-10-14. [^45]: Webex desktop app on Windows and macOS ignores all VPN and virtual network interfaces for emergency network discovery, filtering on Windows by the Virtual parameter of the network adapter. Source: [Enhanced Emergency Calling for Webex Calling](https://help.webex.com/en-us/article/av6oo3/Enhanced-Emergency-Calling-for-Webex-Calling), VPN and virtual network interfaces note. Checked 2026-10-14. [^46]: Zoom Workplace applications do not transmit LLDP to the switch, so the switch must send LLDP (some vendors require LLDP-MED on the port) and Zoom recommends 30-second LLDP timers. Source: [Deploying a nomadic emergency services solution](https://library.zoom.com/zoom-workplace/zoom-phone/expert-insights/emergency-services-best-practices/deploying-a-nomadic-emergency-services-solution), LLDP requirements. Checked 2026-10-14. [^47]: A 2020 Zoom blog described Zoom Phone nomadic E911 location as resolved by BSSID first, then IP subnet, then GPS, then a static portal address, with no switch or LLDP step (disputed). Source: [Zoom Phone Nomadic E911 Service — and Why It's So Critical Now](https://www.zoom.com/en/blog/zoom-phone-nomadic-e911-service-why-its-critical), Body paragraph on how location is determined. Checked 2026-10-14. [^48]: Zoom Phone allows up to two consecutive wildcard characters in the last octet of a BSSID, and up to 20 BSSID entries may contain wildcards. Source: [Deploying a nomadic emergency services solution](https://library.zoom.com/zoom-workplace/zoom-phone/expert-insights/emergency-services-best-practices/deploying-a-nomadic-emergency-services-solution), BSSID configuration guidance on wildcards. Checked 2026-10-14. [^49]: In Zoom Phone, LLDP switch matches and public-plus-private IP/subnet matches apply only to company locations, while BSSID and public IP matches can also resolve to a user's personal locations. Source: [Emergency Services Best Practices: Nomadic location detection and configuration](https://library.zoom.com/zoom-workplace/zoom-phone/expert-insights/emergency-services-best-practices/nomadic-location-detection-and-configuration.md), Detection hierarchy table, scope column. Checked 2026-10-14. [^50]: Zoom Phone nomadic emergency services checks network data in the order LLDP switch MAC plus port, BSSID, public plus private IP/subnet, public IP, then GPS, then site default, account default or Unknown. Source: [Emergency Services Best Practices: Nomadic location detection and configuration](https://library.zoom.com/zoom-workplace/zoom-phone/expert-insights/emergency-services-best-practices/nomadic-location-detection-and-configuration.md), Detection hierarchy table. Checked 2026-10-14. [^51]: Zoom Phone uses GPS-derived approximate addresses only in the US and Canada, only on GPS-capable devices, and only when no network data matches. Source: [Deploying a nomadic emergency services solution](https://library.zoom.com/zoom-workplace/zoom-phone/expert-insights/emergency-services-best-practices/deploying-a-nomadic-emergency-services-solution), Network data hierarchy item 7. Checked 2026-10-14. [^52]: Zoom Phone nomadic location detection, including LLDP, is not supported on Linux, and on macOS it requires the privileged Zoom Helper App. Source: [Emergency Services Best Practices: Nomadic location detection and configuration](https://library.zoom.com/zoom-workplace/zoom-phone/expert-insights/emergency-services-best-practices/nomadic-location-detection-and-configuration.md), OS support section. Checked 2026-10-14. [^53]: Zoom notes that IP-based matching can be unreliable where network address translation or shared subnets make IPs insufficiently unique, and directs admins to switch data in that case. Source: [Deploying a nomadic emergency services solution](https://library.zoom.com/zoom-workplace/zoom-phone/expert-insights/emergency-services-best-practices/deploying-a-nomadic-emergency-services-solution), Network data hierarchy discussion of IP data. Checked 2026-10-14. [^54]: For a Zoom app on a PC behind an IP phone, the phone must pass the switch's LLDP packets through to the PC and must not generate its own LLDP toward it. Source: [Emergency Services Best Practices: Nomadic location detection and configuration](https://library.zoom.com/zoom-workplace/zoom-phone/expert-insights/emergency-services-best-practices/nomadic-location-detection-and-configuration.md), Desk phone LLDP pass-through. Checked 2026-10-14. [^55]: Outside the US and Canada, Zoom Phone generally requires ELINs and reports the originating caller ID to public safety, whereas US and Canada Zoom Native calls carry the address in PIDF-LO without ELINs. Source: [Deploying a nomadic emergency services solution](https://library.zoom.com/zoom-workplace/zoom-phone/expert-insights/emergency-services-best-practices/deploying-a-nomadic-emergency-services-solution), US/Canada vs rest of world. Checked 2026-10-14. [^56]: When a Zoom Phone client detects multiple configured BSSIDs, the BSSID with the highest RSSI wins, even over the access point the client is connected to. Source: [Emergency Services Best Practices: Nomadic location detection and configuration](https://library.zoom.com/zoom-workplace/zoom-phone/expert-insights/emergency-services-best-practices/nomadic-location-detection-and-configuration.md), BSSID matching notes; section 7.2. Checked 2026-10-14. [^57]: Zoom Phone evaluates location scope in the order the user's assigned site, all other account sites, the user's personal locations, then default or Unknown. Source: [Emergency Services Best Practices: Nomadic location detection and configuration](https://library.zoom.com/zoom-workplace/zoom-phone/expert-insights/emergency-services-best-practices/nomadic-location-detection-and-configuration.md), Location scope order. Checked 2026-10-14. [^58]: In the US and Canada, a Zoom Phone caller with no network match, no GPS and no default address is reported as Unknown and routed through a nationwide clearinghouse that verbally confirms location. Source: [Deploying a nomadic emergency services solution](https://library.zoom.com/zoom-workplace/zoom-phone/expert-insights/emergency-services-best-practices/deploying-a-nomadic-emergency-services-solution), No-match behaviour. Checked 2026-10-14.