Enterprise network-based solution for location of 911 caller using an IP phone
Document Number: TR-41.4/01-02-006
STANDARDS PROJECT:
TITLE:
Enterprise network-based solution for locating 911 caller using an IP phone
SOURCE:
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
CONTACTS:
Marc Linsner
Phone:
(941) 272-2105
Fax:
(317) 816-5214
E-mail:
[email protected]
DATE:
February, 2001
DISTRIBUTION TO:
TIA TR-41.4
NOTICE
This contribution has been prepared to assist TIA Standards Committee TR-41. It is offered to the committee as a
basis for discussion and is not binding on Cisco Systems or any other company. The recommendations are subject to
change in form and/or numerical value after further study. Cisco Systems specifically reserves the right to add to, or
amend, the quantitative statements contained herein. Nothing contained herein shall be construed as conferring by
implication, or otherwise any license or right under any patent, whether or not the use of information herein
necessarily employs an invention of any existing or later issued patent.
The contributor grants a free, irrevocable license to the Telecommunications Industry Association (TIA) to incorporate text
contained in this contribution and any modifications thereof in the creation of a TIA standards publication; to copyright in TIA's
name any standards publication even though it may include portions of this contribution; and at TIA's sole discretion to permit
others to reproduce in whole or in part the resulting TIA standards publication.
Page 1 of 4
Enterprise network-based solution for location of 911 caller using an IP phone
Introduction
To continue the dialog from the Savannah meeting, this document will further examine the use of standards-based
SNMP protocols and functions to locate IP Telephony devices for purposes of E911 caller location. This discussion
will describe the functions that would be required in network components including, call agent, E911 manager,
PSTN gateways, and network switches and routers.
Problem Summary
The challenge is to determine the physical location of an IP telephone user when they dial 911. IP Telephony
provides users with a feature that exacerbates a long-time problem for PBX Administrators. Where is the phone
physically located? This issue is amplified with IP Telephony due to the ability of the user to relocate the phone
and/or the identity of the phone as often as the user desires. This could include relocation happening several times a
day and includes the ability to carry the identity across a country. With the current legislation and more in the near
future, PBX administrators will be forced to locate a user instantaneously when a user dials 911. Since the current
North American 911 networks are regionalized, and even in some cases LEC specific, this user location information
is required to determine proper call routing, in addition to the obvious, dispatching the emergency responders to the
proper location.
Proposed Wireline IP Phone Solution
Use Simple Network Management Protocol (SNMP) and “wire maps” to locate IP phones.
Advantages:







SNMP is the de facto standard for internetwork management, not just a paper specification, but is implemented
by almost all vendors of hardware. SNMP separates the management of devices from the hardware architecture
of devices, providing an extensible platform for adding functions like device location.
Low cost solution – no special hardware needed in IP phones or in Ethernet switches
No special software provisions need to be made in either IP phones or Ethernet switches so nearly all current
shipping products should be compatible
Not vendor specific – can be used with IP phone networks implemented with multiple vendors’ hardware
The basic “wire map” location method is already used by administrators of traditional TDM PBX enterprise
locations
Virtually all brands of Ethernet switches support the SNMP “Management Information Base” (MIB) as
described in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 1213, “Management
Information Base for Network Management of TCP/IP-based Internets: MIB-II”.
This would provide the ability to locate campus wireless users to the Access Point level.
Disadvantages:

Won’t work with Ethernet hubs (but it probably isn’t an optimal solution to use Ethernet hubs for IP voice
anyway, since Ethernet switches can provide QoS features that hubs cannot)
Details
The first step is for the administrator of an enterprise PBX installation to create a “wire map” which is essentially a
table of data that gives the physical location of the ends of each Ethernet drop (jack location), referenced to the port
number of a given Ethernet switch. Creation of this table would feed into the master database created in the E911
Manager, which includes not only the physical location of the user, but the Emergency Response Location (ERL 1)
1
ERL as defined by the National Emergency Number Association (www.nena.org). -- A location to which a 9-1-1
emergency response team may be dispatched. The location should be, specific enough to provide a reasonable
opportunity for the emergency response team to quickly locate a caller anywhere within it.
Page 2of 4
Enterprise network-based solution for location of 911 caller using an IP phone
and corresponding Emergency Line Identification Number (ELIN2). An example of the database is shown in Figure
1. An example of a related database table that will also reside on the E911 Manager and will be used by the E911
community is shown in Figure 2.
Figure 1 – E911 Manager Master Database
END USER
ETHERNET
IP PHONE
JACK
SWITCH/PORT
MAC
NUMBER
ADDRESS
2A57
SW16/73
abc067854dea
4F98
SW07/19
e10f4598d3ba
IP
ADDRESS
E.164
ADDRESS
ELIN
10.1.1.26
10.6.3.2
408-555-6789
408-555-5378
408-555-1212
408-555-1234
Figure 2 – ELIN to ERL Database
ELIN
ERL
408-555-1212
170 W. Tasman Dr., 3rd floor, NW corner
408-555-1234
170 W. Tasman Dr., 2nd floor, SE corner
ESZ
EMERG.
SRV. ZONE
124
348
GEODETIC LOCATION INFORMATION
The E911 Manager Application would consist of the SNMP ‘manager’ that would poll the network devices, receive
SNMP traps and communicate with the Call Agent. Individual vendor implementations could place the functions of
the E911 Manager within the Call Agent for small implementations. The E911 Manager would be aware of the IP
phones in service by communicating with the Call Agent via standards based APIs, TAPI 3 or JTAPI4. Once this
database is built, any changes in the wire closet will need to be reflected in the corresponding database record.
The ELIN to ERL Database, shown in Figure 2, would be built based on the geography of the campus with
regulatory guideline. This database, once built, would remain static until physical changes to the campus take place.
This would ease the administrative burden for both the customer and the E911 community, as updates to the ALI 5
database would be infrequent.
The Ethernet switches would then be programmed to notify, via the SNMP trap mechanism, the E911 Manager of
link state changes on the various ports. This trap would need to provide the MAC address of the device that just
initiated the link state change, or the E911 Manager would in turn request the MAC address associated with the port
provided in the just received trap message. This would allow the E911 Manager to ‘watch’ the IP phones move
around the campus. An automatic poll of the bridge table from each Ethernet switch should be done on a periodic
basis and compared with the MAC address/Switch port table. The time frame for this polling would be dictated by
2
ELIN as defined by the National Emergency Number Association (www.nena.org). -- A valid North American
Numbering Plan format telephone number, assigned to the MLTS Operator by the appropriate authority, that is used
to route the call to a PSAP and is used to retrieve the ALI for the PSAP. The ELIN may be the same number as the
ANI. The North American Numbering Plan number may in some cases not be a dialable number.
3
TAPI stands for Telephony API, or Telephony Application Programming Interface. TAPI was developed jointly by
Microsoft and Intel, with input from a number of telephony companies, and originally released in 1994. TAPI
enables Windows applications to share telephony devices with each other and provides a common means of
handling different media (voice, data, fax, video, etc.) on a wide range of hardware platforms.
4
The Java Telephony API (JTAPI) was designed by a consortium of industry-leading computer and
telecommunications companies interested in designing a portable, object-oriented API for computer-telephony
integrated call control.
5
ALI – Automatic Location Identification. Automatic display at the PSAP of the calling party’s telephone number
and address, and possibly additional location information and supplementary services information such as the
presence of hazardous material codes, etc.
Page 3of 4
Enterprise network-based solution for location of 911 caller using an IP phone
the size of the network. In large networks consisting of several Ethernet switches, polling could take a considerable
amount of time; therefore this effort would be executed once a day, preferably at nighttime when network traffic is
typically low.
The E911 Manager would then communicate with the Call Agent to gather the IP address and E.164 address for all
devices known by the Call Agent. If the Call Agent does not track the device’s MAC address, then the E911
Manager would then need to cross reference the IP address to MAC address by polling the arp cache from the
associated IP routers on the various subnets. The Call Agent would then notify the E911 Manager, via the api, as
new devices are defined/registered with it.
Figure 4 – Conceptual IP Telephony Network
IP Telephony
Call Agent
ISDN
PRI or
CAMA
PSTN
E911 Manager
Gateway
API Set
(TAPI)
Zone 1
of building
Zone 2
of building
Ethernet switch
"A"
Port A1
Port A2
to
Port B1
Ethernet switch
"B"
IP telephone
MAC=2
x2001
Port B2
IP telephone
MAC=1
x2000
When an IP phone is used to call 911, the Call Agent routing software would query the E911 Manager software
application to get the most current table of data relating Ethernet switch ports with MAC. The E911 Manager would
then return the ELIN and Gateway information so the Call Agent could make the proper routing decision. The Call
Agent would substitute the E.164 address of the IP phone with the ELIN. The ELIN in turn would be preloaded in
the ALI database with the proper location. In order to meet current 911 regulations, the Call Agent would then ‘call
forward’ the ELIN to the IP phone that placed the 911 call for a period of time. As the 911 network matures, the
ability to transmit both the ELIN and the callback number will be possible. At that time it will be the responsibility
of the Call Agent to adhere to the new protocol.
The E911 Manager would also be used to transmit the ELIN/ERL changes to the 911 Service Provider for eventual
updating of the ALI database. Today, this mechanism is done via various apps and in most cases paper faxes.
Page 4of 4