Deploying a Nomadic Emergency Services Solution

"Nomadic,” in the context of placing an emergency call, is defined as “the system detects where you are right now and automatically reports the correct location to public safety." As Zoom Phone users roam between predefined company and personal locations, Zoom detects their location based on network connection data and effectively reports the emergency address associated with their location to public safety responders. Deploying a nomadic emergency services solution includes these basic steps:

• Defining Company and Personal locations

• Enabling users and devices to report their network connection data

• Maintaining and monitoring the emergency services environment

Nomadic Solution Overview

When Zoom Phone (within a Zoom Workplace app) or IP phone makes an emergency call, it reports the associated network data to the Zoom Phone server. The server will then try to match that data to a pre-defined physical Company or Personal location. The Zoom Phone endpoints can report public and private IP addresses, and, when enabled, can report wireless access point MAC addresses (also called BSS_ID) and network LAN switch data. When there’s a match, we can report the established emergency address for the corresponding location to both public safety and internal safety response teams.

The address reporting capability is accomplished either by reporting the emergency address directly in call signaling—as is possible with Zoom Native services in the US/Canada, or by selecting and sending a caller ID (aka ELIN) that has been pre-established to align with the given location—as is required in countries outside of the US/Canada and/or when utilizing BYOC carriers for handling emergencies.

Network Data Hierarchy

Zoom uses the following network data hierarchy to detect the caller's corresponding emergency address:

1. Network switch MAC address & port data matches for company location

2. BSS_ID matches for company or personal location. The service will look for a match among locations in the caller's home site first.

3. Public & Private IP address/subnet matches for company location. The service will look for a match amongst locations in the caller's home site first.

4. Public IP address matches for company location. The service will look for a match among locations in the caller's home site first.

5. Public & Private IP address matches for personal location.

6. Public IP address matches for personal location.

7. If none of the above match, US/CA emergency calls placed by a device that has GPSwill use GPS coordinates, which are then translated to an (approximate) physical address by our carrier.

8. If none of the above match and the device has no GPS capabilities:

   1. For users in the US/Canada, Zoom will report the user’s default emergency address if the user has selected, created, or confirmed an address. If the user has never done this (and is therefore still provisioned with some inherited site-level default address), the server will report the location as “Unknown”. Reporting a location as unknown triggers a process with our carrier that will route the call to a nationwide emergency services clearinghouse service, which will verbally ascertain the caller’s location before routing the call to the correct PSAP (Public Safety Answering Point).

   2. For common area phones in the US/Canada, Zoom will report the configured address of the device if it exists, otherwise will report the default site emergency address.

   3. For users and phones outside the US/Canada, Zoom will report the originating caller ID to public safety/emergency services.

Emergency Call Routing: Zoom Native or BYOC

When Nomadic Emergency Services are enabled and you are utilizing BYOC phone numbers in the US and Canada, by default, Zoom Native will provide the call handling for emergency calls. This simplifies deployment as regular day-to-day calls will be routed via your BYOC carrier, but emergency calls will utilize Zoom Phone’s Native service.

There are no incremental charges or fees for BYOC customers that choose this option, and it is strongly recommended that they do so.

When Zoom Native is the carrier for emergency calls in the US & Canada, both the caller’s emergency address and the caller ID are communicated separately and independently in the emergency call signaling. The address portion is communicated via a protocol called PIDF-LO, and this works regardless of whether the caller ID represents a Zoom Native number or a BYOC number.

When a BYOC carrier is used for emergency calls for all Native and BYOC circumstances outside the US & Canada, we don’t have the ability to include PIDF-LO signaling, and only the caller ID can be included in the call signaling. This means that the receiving public safety answering point must do a database lookup in the public ANI/ALI database to determine the ‘address of record’ for the caller ID. The ability to directly communicate the caller’s address in emergency call signaling independently of the caller ID has multiple practical benefits:

• When deploying nomadic emergency services, it removes the requirement to assign dedicated phone numbers (aka ELINs) to locations in the US & Canada. If you are a BYOC-enabled customer and do not select the option to use Zoom to route emergency calls for US & Canada BYOC numbers, you will be required to define ELINs for all of your US & Canada locations.

• It simplifies address management for users in the US & Canada. You and your users can effectively define or update emergency addresses that are associated with a user, phone, or location in near real time via the capabilities built into the Zoom Workplace app and the Zoom administration portal—there is no need to update a public database.

• Zoom maintains public records for Zoom Native numbers, but Zoom doesn’t (and can’t) maintain public records for BYOC numbers—you must manage that part with your carrier when using BYOC for emergency calls.

Defining Company Locations

Admins must define and align Zoom Phone Sites into a location hierarchy. Sites are a key management construct in Zoom Phone: users, phones, and numbers are assigned to sites, which have dial plans, routing rules, and configurable policies, including emergency services settings. Sites should be primarily defined by geography: for user populations spread across multiple physical locations, separate sites are suggested at the city or campus level. For populations spanning multiple countries, separate sites per country are strongly recommended.

For remote workers, it is usually best to align them to the closest physical site if possible, and we’ll deal with them more specifically in the Personal Locations section.

Within a site, you must then define locations and sub locations for emergency calling. Often, first-level locations in a Site are buildings, second-level locations are floors, and third-level locations (if needed) can be wings or rooms or suites within a floor. Locations needs the following important details, depending on requirements:

• Dispatchable emergency address: A location must be sufficiently detailed to provide street address, building number, floor, and when appropriate, a room/suite/wing within the floor. Generally, this specificity can be captured via the Address Line 2, so each location or sub-location you create should have a unique emergency address.

Different states have different rules regarding how much physical space can be included in one dispatchable location; for large buildings, you can configure sublocations to meet these guidelines.

• An ELIN (Emergency Location Identifying Number) is an industry name for a phone number that is configured to have a public address of record that matches the dispatchable emergency address of a specific location. When a Zoom Phone endpoint makes an emergency call from a defined and detected location that contains an ELIN, the endpoint will utilize the ELIN as its caller ID. When the call is received by a public safety answering point (PSAP), a database lookup is performed by the PSAP to identify the address of record of the incoming caller ID and establish the caller’s Location. Should the PSAP need to call back, inbound calls to the ELIN number can be routed to the originating Zoom Phone extension for at least 2 hours following an emergency call.

ELIN is not required in the US and Canada, when Zoom Native services are used for handling emergency calls. ELIN is also not applicable to many countries such as Japan, China, and others. In countries where ELIN applies and/or a customer is using a BYOC carrier for emergencies, emergency services requires ELIN configuration.

• Network data that is sufficiently unique to the location: When the Zoom Workplace app or an IP phone makes an emergency call, it reports network data to the Zoom Phone server. The Zoom Phone endpoints can report public and private IP addresses, and, when enabled, can report:

  • Wireless access point MAC addresses (also called BSS_ID)

  • Network switch MAC address, port number, and port label (when endpoints are plugged into a network LAN port).

While wireless access point MAC addresses (also called BSS_ID) are unique values and thus are useful for identifying a specific location, IP addresses are not always helpful—many customers have IP network address translations or subnets that are not sufficiently unique to distinguish a given building or floor of a building from another building or floor.

In these cases we need to probe to the next level by examining the network infrastructure—if you know that phone clients or devices will be plugged into your LAN and you also know that wired IP subnets are not sufficiently unique to identify a location, you will need to look at the underlying network switches and correlate that network switch data to locations. This capability requires that LLDP protocol be allowed to run on your network.

The BSSID field supports wildcard characters that include asterisks (*) to represent a single character. Up to two consecutive wildcard characters are supported in a single BSSID in the last octet. You can add up to 20 BSSID with wildcard characters.

It is generally best to start implementing the Zoom Nomadic E911 solution at one site and define your Company Locations in detail for this site. Start with buildings and floors, and consider your network topology. How are IP subnets organized? What granularity of wireless access point coverage do you have—namely, what specific rooms or areas of the floor are covered? If needed, what network switches are relevant to this building and floor? We need to translate this network data into physical locations. We recommended that you build a spreadsheet like the one below:

A	B	C	D	E	F	G	H	I	J	K	L	M	N	O	P	Q
		Location Hierarchy			Network Topology			e911 Addresses
Site Name	parent #	parent_location name	Location #	Location display name	Wireless access point MAC addresses (BG_ID) list	Public IP address	Private IP address (Wired & Wireless Subnets)	LAN switch identifiers	Address Line 1	Address Line 2	City	State/ province/ territory	Country/Region	Postal Code	E2M Routing (locations outside US/CA)	VAIN/NIF/CIF Number (applicable to sites in Belgium, Netherlands, Portugal, Spain and Switzerland)
San Jose	1	Headquarters Building 1	1.1	HQ Building 101 First Floor	12:34:56:78:9A:BC	75.125.25.12/32	172.30.21.0/23, 172.31.25.0/23, 10.14.0.0/16	MAC Address: 12:34:56:78:9A:BC, Port Label: "ABC", "Port Range: Room": "A233", "Floor: Building": "Outlet"	501 Main Street	First Floor	San Jose	CA	United States	95015	n/a
San Jose	1	Headquarters Building 1	1.2	HQ Building 101 Second Floor					501 Main Street	Second Floor Suite 200	San Jose	CA	United States	95015	n/a
San Jose	2	Headquarters Building 2	2.2	HQ Building 200 First Floor					600 Main Street	Suite 3000	San Jose	CA	United States	95015	n/a
Atlanta	3	Atlanta	3.3	Atlanta Sales Office					123 Lenora Way	6th floor suite 9	Atlanta	GA	United States	30305	n/a

It is suggested that locations and sublocations are named in plain language, and you must provide detailed emergency addresses with line one and line two for each location. Then, define as much network data as you have for these locations: wireless access points, MAC addresses (also called BSS_ID), Public and Private IP subnets, and if you need it, network switch data.

The nomadic emergency services feature must be turned on for a given site before you can begin to manage the locations. We recommend that you enable the feature only for a small test team to start:

Locations can then be added in bulk via CSV file, or manually via the admin portal:

Bootstrap Mode

If you do not have complete network data for all of your company locations, there is a tool that can help: Bootstrap Mode. To use it, enable personal locations and Bootstrap Mode together for your test users:

Bootstrap Mode provides a way for users to report locations and underlying network data to the administrator(s). When Bootstrap Mode and Personal Locations are enabled for your test users, each time their Zoom Workplace desktop or iPad app roams into an unknown location (i.e., each time it encounters network connection data that is not already associated with a defined location) the client will prompt the user to confirm or update their location. They can choose from an existing list of company locations (that may have no or only partial network data attached) or define a new company location.

When users confirm a location, administrators will get an email alert indicating that new network data has been reported for a company location, and you can either approve or reject the data in the admin portal. There is also a setting to control who receives alerts when new data is reported in this process called “Email Recipients for Emergency Services Data Maintenance”, which you will find under the Emergency Services Management for each site. Thus, you can have your testers “walk the property” to confirm or effectively report network data for each company location.

When you are first setting up your locations, it’s recommended to enable Bootstrap Mode for your ‘feature testing’ team. Later, when company locations are well-defined, you can enable Bootstrap Mode as an ongoing test & data maintenance tool: if and when users report ‘new’ data for an existing company location via Bootstrap Mode, it likely means that something has changed in your network and you’ll need to make corresponding updates to your Zoom Phone locations.

Personal Locations

Personal Locations are a powerful tool designed to enable you to support a remote, mobile, or hybrid workforce where users may roam between company locations and external work areas such as home offices.

When Personal Locations are enabled, each time a user’s Zoom Workplace desktop or iPad app roams into an unknown location (i.e., each time it encounters network connection data that is not already associated with a defined location), the app will prompt the user to confirm or update their emergency address. They can choose from an existing Personal Location if they already have one, or they can define a new one. When defining a Personal Location, the user will input a complete physical emergency address for the location, and the Zoom Workplace app will record the network data associated with this location (public IP address and BSS_ID) so that it can be detected again later.

We strongly recommend that personal locations be enabled for your users, especially if they are mobile and/or work remotely in the United States or Canada. If you have a hybrid environment where users are sometimes at home and sometimes in the office, you may want to wait to enable personal locations until you have your company locations well-defined so that users don’t accidentally create duplicates of what will become a company location.

If Personal Locations are not enabled, the default emergency address for the site/user will be used, and the Zoom Workplace app will never prompt the user to update or confirm their emergency address when unknown network connection data is encountered.

As users create them, Personal Locations will appear as their own category of locations in your admin portal. You’ll also be able to quickly see which users have or have not created a personal location on the location tracking dashboard. Below are important considerations about Personal Locations:

US and Canada:

Users can create an effectively unlimited number of personal locations. This is also true for users that are extension-only. This works because the location information can be sent dynamically and independently of the caller ID in emergency call signaling.

Countries/Regions outside of the US and Canada:

The number of personal locations a user can create should be limited to the number of DIDs that are owned by that user, and there will be a delay before the location is fully functional. This is because the location information that can be sent to public safety is tied to the user’s caller ID—the public safety answering point has to look-up the address of record for the incoming caller ID. Thus, personal locations are not recommended at all for extension-only users. For users that do have one or more assigned DID(s), they can create a personal location for each DID—but behind the scenes, the address of record for the user’s phone number will need to be updated to match the location, which takes time.

For Zoom Native phone numbers, Zoom will conduct this address change/update process on your behalf. In some countries, this is a manual process in which our service team works with local carriers to complete the updates.

For Zoom BYOC phone numbers, it is your responsibility to work with your carrier(s) to complete the address change/update process.

Enabling Users and Devices to Report Network Data

In order for our nomadic solution to function, we need the Zoom Workplace app to be able to successfully detect and report location data.

Location Sharing with the Zoom Workplace Application

In order for the Zoom Workplace application to report network data (IP addresses and BSS ID) for these purposes, location sharing with the application must be enabled at the operating system level for macOS, iPadOS, and Windows-based app. When the nomadic emergency services feature is enabled, the Zoom Workplace app will ask the users to enable location sharing with Zoom via an in-app pop-up:

This location sharing status is also manageable and shown in the app settings for Zoom Phone:

You’ll be able to track which users have completed the process on the Zoom Phone dashboard. However, for Macs and iPads, Apple security requirements permit only a local user with administrative privileges for the device to enable location sharing with the Zoom Workplace application. We are not yet aware of any reliable means to remotely control this security setting for Apple users. So if your Mac users don’t have admin privileges to their machines, you’re going to have to enable location sharing with Zoom for them via a manual process.

Detecting and Reporting Network Switch Data

If your deployment needs to enable detecting and reporting network switch data, we potentially have work to do on your Zoom Workplace apps and also your network. Zoom Workplace applications leverage Link Layer Discovery Protocol (LLDP) to determine the network topology in a corporate network based on switch ports, so we have to enable the clients to detect LLDP and your network to report LLDP.

Let’s start with the Zoom Workplace desktop application: While supported IP phones and Windows-based Zoom Workplace desktop apps can detect and report network switch data as long as they have the minimum version of firmware or Zoom Workplace app installed, reporting network switch data is a heavier lift for macOS applications. For these applications, you’ll need to enable an option in the admin portal and downloading/install a helper application.

If your users have administrative privileges for their machines, you can choose the option that will prompt users to download and install the option for themselves. If users do not have such privileges, you’ll have to distribute the helper application to them.

Reporting network switch data is supported for Zoom Phone on Windows and Mac devices, and Poly and Yealink IP phones.

When making an emergency call, the Zoom Workplace app retrieves the MAC address of the switch from the “Chassis ID” type-length-value (TLV) and the switch port number or interface ID from the “PortID” type-length-value (TLV). This information is extracted from the LLDP data unit (LLDPDU) that is sent by the switch to the Zoom Workplace app that is plugged in to the switch. During an emergency call, these parameters are sent to Zoom servers to be mapped to the emergency location that is configured by the administrator or discovered as part of Bootstrap Mode.

Preamble	Dest. MAC	Source MAC	Ethertype	Chassis ID TLV	PortID TLV	Time to live TLV	Optional TLVs	End of LLDPDU TLV	Frame check sequence

To ensure a successful deployment of Nomadic emergency services with switch port-based tracking, administrators are required to enable LLDP on the switch ports where Zoom Workplace applications will be connected.

• The network switch must be configured to “send” LLDP information towards the Zoom Workplace applications. Zoom Workplace applications do not send LLDP packets towards the network switch.

• LLDP configuration should include transmitting the mandatory TLVs, which are required by Zoom Workplace applications to track the location of the device.

• Certain switch vendors may require LLDP-MED to be enabled on the switch ports to allow the mandatory TLVs required to be sent in the LLDPDU. We recommended that you refer to the vendor documentation for the configuration steps.

• LLDP timers should be set to a value that would allow Zoom Workplace applications to detect any network changes. A value of 30 seconds is recommended.