No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Understanding Enterprise E911

Today's IP telephone systems and current carrier offerings allow enterprises the flexibility to architect systems to join sites, share trunking, and create a single virtual telephone environment like never before. But these capabilities challenge consultants, system designers, and customers to fully understand and plan through the implications these can have for emergency services notification. Before a system is deployed, it is important to determine answers to key questions, such as:

* When someone dials "9-1-1" from the enterprise, will their call ring into the correct dispatch center responsible for serving that site?

* When someone dials "9-1-1" from the enterprise, will dispatch receive the correct information (phone number and address) for that caller?

* If emergency personnel have to respond to the call using the address information for the caller, is it reasonable that they would be able to find the individual if no one was around to take them to the caller?

In years past, these questions were often not considered a critical part of telephone system design except when working with larger system installations. Today, this has clearly changed as more and more organizations are purchasing systems and enabling sophisticated networking features, enabling centralized trunking, tying multiple disparate sites together, supporting remote users, and supporting the fluid move/change environment enabled by IP phones. These capabilities have the potential to affect the integrity of 911 calling.

At this time, several states have some type of legislation regarding expectations for the processing of 911 calls from a business environment with the potential to impact design considerations. Whether or not state regulations exist, prudence recommends taking steps to ensure that the constituents using an organization’s telephone system can depend on that system to process a 911 call properly and allow emergency responders to show up at the correct location with enough information to quickly find the caller.

This article explains the applications and services that exist to allow a system to be designed to deliver customized and detailed location information to the emergency dispatch center (Public Safety Answering Point or "PSAP"). Specifically, we will look at how enhanced 911 services work on the CPE side and compare that to the specialized Private Switch – Automatic Location Information (PS-ALI) services that exist on the carrier side – and how the two interact. Lastly, we will offer some guidance when moving forward with the decision to implement enhanced 911 services.

911 CALL PROCESSING

Without the use of any special E911 capabilities, a user dialing 911 in an enterprise telephone system will pass the Automatic Number Identification (ANI) associated with the trunk they are using. The Automatic Location Information (ALI) will almost always correspond to the billing address for the trunk--which typically is the same as the address for the demarc. The general process is described below:

If analog central office lines are used, the ANI passed to the PSAP will be the number associated with the line being used to place the call. If digital ISDN-PRI service is being used with Direct Inward Dial (DID) numbers, the ANI will follow the configuration of how the PRI was set up; either the main pilot number associated with the PRI will be out-pulsed or the individual DID number being used to place the call will be out-pulsed. In many system implementations, allowing a user to pass the ANI/ALI of the trunk they are using is acceptable because in many cases the user's location and the trunk's billing information (demarc location) are the same. However, we potentially get into difficulty under at least three scenarios:

1. A single building environment that is either very large and/or has multiple floors.

2. A campus environment with multiple buildings but only one demarc.

3. A networked environment that serves multiple buildings (MAN/WAN) where some/all of the buildings have access only to hub trunks (no local trunks exist at the networked endpoints to process 911 calls).

In all of the above scenarios, a call to 911 may either provide insufficient information to emergency responders--or worse yet, may actually lead responders to the incorrect address. Generally-followed dispatch protocol recommends that upon answering a call to query the nature of the emergency, dispatchers will ask to confirm the caller’s location. However, if this cannot be done, the ALI address is what will be used when dispatching a responder. Additionally, if the call drops--or even if the caller immediately hangs up--dispatch will call back on the ANI received and if they cannot reach anyone at the number, they will dispatch an officer to the ALI address. Therefore, providing dispatch with the proper ANI (or minimally an ANI that will be answered by the organization) as well as an accurate ALI, is critical to enabling the emergency response process to work.

If we use the example of an organization using ISDN-PRI service and DID numbers in a multi-floor building, the telephone system can be set up to pass the actual ANI of the caller dialing 911, but the ALI will only indicate the main billing address. Therefore, emergency responders showing up at the scene would not know what floor to go to unless it was communicated on the original call or someone at the scene could guide them to the caller. Likewise, in a multi-site/campus environment using a single set of centralized trunks, a common ALI address (the building address where the demarc is located) would be given for anyone dialing 911.

In networked metropolitan environments (e.g., municipal government, school systems, local banks) this shortcoming can be alleviated by dedicating a small group of at least two analog lines into each building and routing each building’s users to the local trunks when dialing 911, but this latter method assumes:

* A demarc exists in each building
* Each site is equipped with a system/gateway that will support local trunking
* Each system/gateway can direct its building's 911 calls to a local separate trunk route
* Each system/gateway can make these "emergency" lines a ringing appearance on at least one phone in the building in case Dispatch was to call back on a 911 hang-up/disconnect

If these assumptions cannot be met, callers to 911 may suffer compromised outcomes.

There is at least one other scenario that will force us to deal with 911 call handling:

* State regulation that requires compliance

Currently, 16 states have legislation with the potential to impact business telephone system design:

Alaska; Arkansas; Colorado; Connecticut; Florida; Illinois; Kentucky; Louisiana; Maine; Massachusetts; Minnesota; Mississippi; Texas; Vermont; Virginia; Washington

See "State Status of MLTS (Multi-Line Telephone System)/PBX Legislation" for more information (Note: This site is only periodically updated). Each state’s regulations and requirements are unique, so implementing systems in these states requires consideration to determine whether the regulation affects your project and if so, what will be required to satisfy the regulations.

It should be noted that in some isolated cases, some organizations elect to handle their own emergency calls by directing users to call an internal extension to reach a Security/Public Safety department who in turn determines if a 911 call needs to be placed. Although beyond the scope of this article, organizations should be aware that the potential liability associated with this protocol should be assessed against the benefits of screening emergency calls; best practices would recommend against taking on the liability for matters normally in the domain of emergency service professionals. Alternative approaches to addressing notification to an internal security department will be discussed later within this article.

  • 1