emergency calling · published

Network-based location for E911 across platforms

Verified 2026-10-14 · 58 sources · tier 1–3 · 1 disputed

Also known as dynamic-e911.

Disputed: 1 source below carries conflicting evidence.

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

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.

See also

Depends on

Related to

Sources

  1. 1
    8x8 Nomadic 911 must be enabled for the account, via an 8x8 Support case or Sales, before any configuration can be performed.
    Nomadic 911 Administration and Planning Guides · Page body, enablement paragraph · Checked 2026-10-14
  2. 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.
    E911 Emergency Calling in Webex for BroadWorks · Configure Third-Party Calling URLs table; Dynamic Tags table · Checked 2026-10-14
  3. 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.
    E911 Emergency Calling in Webex for BroadWorks · Webex Client Configuration Tags for Emergency Calling > Custom Tags · Checked 2026-10-14
  4. 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.
    Integrate Emergency Responder with CUCM · Identify LAN Switches · Checked 2026-10-14
  5. 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.
    Integrate Emergency Responder with CUCM · Default ERL configuration · Checked 2026-10-14
  6. 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.
    Integrate Emergency Responder with CUCM · Phone Tracking via Switch Ports; ERL definition · Checked 2026-10-14
  7. 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.
    47 CFR part 9 — 911 Requirements · § 9.3, definition 'Dispatchable location' · Checked 2026-10-14
  8. 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.
    47 CFR part 9 — 911 Requirements · § 9.16(b)(3)(i) · Checked 2026-10-14
  9. 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.
    47 CFR part 9 — 911 Requirements · § 9.16(b)(3)(ii) · Checked 2026-10-14
  10. 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.
    47 CFR part 9 — 911 Requirements · § 9.16(b)(3)(iii) · Checked 2026-10-14
  11. 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.
    HTTP-Enabled Location Delivery (HELD) · Sections 4 and 5.1 · Checked 2026-10-14
  12. 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.
    HTTP-Enabled Location Delivery (HELD) · Sections 4.1, 4.1.1, 4.1.2 · Checked 2026-10-14
  13. 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.
    HTTP-Enabled Location Delivery (HELD) · Sections 4.2, 4.3, 6.2 · Checked 2026-10-14
  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
    47 CFR part 9 — 911 Requirements · § 9.16(b)(3)(ii)-(iii), read with vendor claims in this packet · Checked 2026-10-14
  15. 15
    RingCentral is phasing out setting an emergency address by updating a device; error EME-384 indicates the ERL workflow must be used instead.
    Emergency Locations · Method 1: update by device, warning · Checked 2026-10-14
  16. 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.
    Emergency Locations · Emergency Response Locations (Method 2), feature-check limits · Checked 2026-10-14
  17. 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.
    Use of Device Identity in HTTP-Enabled Location Delivery (HELD) · Sections 3.1 to 3.8 · Checked 2026-10-14
  18. 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.
  19. 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.
  20. 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.
  21. 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
    Using Device-Provided Location-Related Measurements in Location Configuration Protocols · Sections 5.1 and 5.3, compared with vendor claims in this packet · Checked 2026-10-14
  22. 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.
    Configure dynamic emergency calling · Test emergency calling · Checked 2026-10-14
  23. 23
    Cloud proxy deployments that modify the source IP address of Teams clients do not support Teams network configuration setting lookups.
    Configure dynamic emergency calling · Configure network settings, Important box · Checked 2026-10-14
  24. 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.
    Configure dynamic emergency calling · Emergency calling prerequisites for Direct Routing; Set up an Emergency Routing Service provider · Checked 2026-10-14
  25. 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.
    Configure dynamic emergency calling · Assign emergency addresses, paragraph after the bullet list · Checked 2026-10-14
  26. 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.
    Configure dynamic emergency calling · Configure Location Information Service > IPv6 subnet matching · Checked 2026-10-14
  27. 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.
    Configure dynamic emergency calling · Configure Location Information Service > IPv6 subnet matching, scenario table and following paragraph · Checked 2026-10-14
  28. 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.
    Configure dynamic emergency calling · Configure network settings, Note following the trusted IP paragraph · Checked 2026-10-14
  29. 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.
    Configure dynamic emergency calling · Plan for emergency calling, numbered step 2, second bullet · Checked 2026-10-14
  30. 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).
    Configure dynamic emergency calling · Configure network settings, Note on defining subnets in LIS · Checked 2026-10-14
  31. 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.
    Configure dynamic emergency calling · Supported clients, 'Ethernet/Switch (LLDP) is supported on' list · Checked 2026-10-14
  32. 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.
    Configure dynamic emergency calling · Configure network settings, paragraph before the LIS subnet Note · Checked 2026-10-14
  33. 33
    Subnets defined in Teams network sites do not render dynamic locations by themselves; they must be redefined in the Location Information Service.
    Configure dynamic emergency calling · Configure Location Information Service > Using PowerShell, Important box · Checked 2026-10-14
  34. 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.
    Configure dynamic emergency calling · Configure network settings, paragraph on trusted IP addresses · Checked 2026-10-14
  35. 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.
    Configure dynamic emergency calling · Supported clients, second Note · Checked 2026-10-14
  36. 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.
    Configure dynamic emergency calling · Supported clients, first Note · Checked 2026-10-14
  37. 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.
    Enhanced Emergency Calling for Webex Calling · Webex App (HELD+) network discovery description · Checked 2026-10-14
  38. 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.
    Enhanced Emergency Calling for Webex Calling · Caller ID fallback text; RedSky HELD/HELD+ Routing settings · Checked 2026-10-14
  39. 39
    In Webex Calling enhanced emergency calling, Cisco MPP devices use HTTP Enabled Location Delivery (HELD) to report their network environment to RedSky.
    Enhanced Emergency Calling for Webex Calling · Enhanced emergency calling for Webex Calling, device support and network discovery section · Checked 2026-10-14
  40. 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).
    Enhanced Emergency Calling for Webex Calling · Control Hub location-level configuration steps · Checked 2026-10-14
  41. 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.
    Enhanced Emergency Calling for Webex Calling · Network discovery description for HELD MPP devices · Checked 2026-10-14
  42. 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.
    Enhanced Emergency Calling for Webex Calling · Device support: non-HELD devices · Checked 2026-10-14
  43. 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.
    Enhanced Emergency Calling for Webex Calling · Webex App desktop network discovery description · Checked 2026-10-14
  44. 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.
    Enhanced Emergency Calling for Webex Calling · No dispatchable location / relay center paragraph · Checked 2026-10-14
  45. 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.
    Enhanced Emergency Calling for Webex Calling · VPN and virtual network interfaces note · Checked 2026-10-14
  46. 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.
    Deploying a nomadic emergency services solution · LLDP requirements · Checked 2026-10-14
  47. 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
    Zoom Phone Nomadic E911 Service — and Why It's So Critical Now · Body paragraph on how location is determined · Checked 2026-10-14
  48. 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.
    Deploying a nomadic emergency services solution · BSSID configuration guidance on wildcards · Checked 2026-10-14
  49. 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.
    Emergency Services Best Practices: Nomadic location detection and configuration · Detection hierarchy table, scope column · Checked 2026-10-14
  50. 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.
  51. 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.
    Deploying a nomadic emergency services solution · Network data hierarchy item 7 · Checked 2026-10-14
  52. 52
    Zoom Phone nomadic location detection, including LLDP, is not supported on Linux, and on macOS it requires the privileged Zoom Helper App.
  53. 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.
    Deploying a nomadic emergency services solution · Network data hierarchy discussion of IP data · Checked 2026-10-14
  54. 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.
    Emergency Services Best Practices: Nomadic location detection and configuration · Desk phone LLDP pass-through · Checked 2026-10-14
  55. 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.
    Deploying a nomadic emergency services solution · US/Canada vs rest of world · Checked 2026-10-14
  56. 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.
    Emergency Services Best Practices: Nomadic location detection and configuration · BSSID matching notes; section 7.2 · Checked 2026-10-14
  57. 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.
  58. 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.
    Deploying a nomadic emergency services solution · No-match behaviour · Checked 2026-10-14

Documents

tier 1 standards and regulators

47 CFR part 9 — 911 Requirements

Office of the Federal Register / eCFR · 2026-09-14 · accessed 2026-09-16

tier 1 standards and regulators

HTTP-Enabled Location Delivery (HELD)

IETF · 2010-09-01 · accessed 2026-10-14

tier 1 standards and regulators

Use of Device Identity in HTTP-Enabled Location Delivery (HELD)

IETF · 2011-03-01 · accessed 2026-10-14

tier 1 standards and regulators

Using Device-Provided Location-Related Measurements in Location Configuration Protocols

IETF · 2014-01-01 · accessed 2026-10-14

tier 2 current vendor documentation

Configure dynamic emergency calling

Microsoft · 2026-06-15 · accessed 2026-09-21

tier 2 current vendor documentation

Deploying a nomadic emergency services solution

Zoom · accessed 2026-10-14

tier 2 current vendor documentation

E911 Emergency Calling in Webex for BroadWorks

Cisco Webex Help Center · 2025-12-19 · accessed 2026-10-14

tier 2 current vendor documentation

Emergency Locations

RingCentral · 2025-07-02 · accessed 2026-10-14

tier 2 current vendor documentation

Emergency Services Best Practices: Nomadic location detection and configuration

Zoom · accessed 2026-09-30

tier 2 current vendor documentation

Enhanced Emergency Calling for Webex Calling

Cisco Systems, Inc. (Webex Help Center) · 2026-08-21 · accessed 2026-09-16

tier 2 current vendor documentation

Integrate Emergency Responder with CUCM

Cisco Systems (TAC) · 2026-08-03 · accessed 2026-09-24

tier 2 current vendor documentation

Nomadic 911 Administration and Planning Guides

8x8 · 2026-05-22 · accessed 2026-10-14

tier 3 vendor-maintained repositories

Zoom Phone Nomadic E911 Service — and Why It's So Critical Now

Zoom · 2020-07-24 · accessed 2026-10-14

Cite this page

APA

WarmTransfer. (2026, October 14). Network-based location for E911 across platforms. WarmTransfer. https://warmtransfer.net/knowledge/e911-network-location-discovery

BibTeX

@misc{warmtransfer-e911-network-location-discovery,
  title  = {Network-based location for E911 across platforms},
  author = {{WarmTransfer}},
  year   = {2026},
  url    = {https://warmtransfer.net/knowledge/e911-network-location-discovery},
  note   = {Verified 2026-10-14}
}