10-26-2017 08:15 AM - edited 03-12-2019 10:27 AM
This application note presents the configuration and call routing changes needed to provide a warning notification to a calling party that they have placed a call to 911. This announcement is intended to address the deployment and configuration details to assist in preventing accidental calls by users to the Emergency Services Public Safety Answering Point.
Accidental calls to 911 emergency services happen every day. If the caller hangs up before talking to a 911 dispatcher, then emergency services will be sent to the site to verify the emergency. Since most of these accidental calls are caused by users misdialing the number or by accidentally entering the long distance access code twice, administrators need a method by which to capture these inadvertent calls and allow the calling party to end the call prior to reaching the local PSAP. By intercepting calls to 911 and playing a short announcement before routing the call gives the calling party a chance to terminate the call prior to extending the call to the PSTN and thus prevent an accidental call to 911.
This Application Note will detail how to play an announcement to the caller when 911 is dialed prior to extending the call to the local emergency Public Service Answering Point.
This document is targeted at Cisco Unified Communications Manager administrators who are familiar with call routing in the UCM environment. To implement this feature, the administrator must have good knowledge of the existing dialplan, call routing and call flows to be able to implement the on-site emergency call announcement using the native call queuing capability. The administrator must understand Partitions, Calling Search Spaces and Translation Patterns. Since this configuration will be part of emergency call routing, it is very important that the call flows and device configurations be fully tested to ensure proper call routing.
In Cisco Unified Communications Manager 9.0, the native call queuing feature was introduced. The native call queuing feature allows administrators to set up very simple call distribution queues that could queue callers as well as play messages to caller in the queue.
Since the native call queuing feature allows for the playout of a message upon entry into the queue, this capability will be used to play a very short message to the caller indicating that “you have called 911“ and the call is routed immediately after the message is played. The audio notification should be as short as possible to prevent delaying an emergency call any longer than necessary. Most deployments can deliver a notification message as short as 2 seconds allowing 95%+ of the accidental calls to be ended prior to the call reaching the external 911 dispatch center.
The call flow will capture emergency calls and route them to a hunt pilot and into a native call queue. The hunt pilot will play out a message to the calling party upon entering the queue. After the message is played, the call will be immediately forwarded to either a Cisco Emergency Responder server or to a Route pattern that uses Standard Local Route Groups for correct gateway selection. The logic for this call flow is shown in Figure 1.
This call flow can be used with CER or Standard Local Route Groups for call routing. The flow through a native call queue will not affect CER’s ability to identify the calling party device and correctly associate the device to the ERL and ELIN appropriate for the call. If emergency calling is deployed without CER, the call must be routed using Standard Local Route Group (SLRG) to select the correct gateway to reach the PSTN. Additional details on using CER or SLRG can be found in the Routing to CER or Route Pattern section later in this document.
Routing to CER or Route Pattern:
After the message is played to the calling party, the call should be routed to either CER or a route pattern to reach the PSTN.
If the call is routed to CER, the original calling party number and device name are passed to CER during the call setup, which will allow CER to correctly identify the location of the caller. Alternatively, if the UCM is already using Standard Local Route groups for 911 calling, then this call flow will be able to leverage SLRG to route the 911 calls after the annunciator. In either of these cases, there is no further consideration for routing the call other than routing to the CER Route Point or through a SLRG.
If the UCM is configured with multiple sites and/or multiple 911 PSTN connections, and the correct gateway is selected from a device based dial plan, then UCM call routing will need to change to support this call flow. In this case, UCM must be changed to use Standard Local Route Group (SLRG) to route calls to 911. When using device based call routing, the device’s calling search space will find a site specific 911 route pattern and route to the correct local gateway. But in this call flow, due to the fact that there is only one calling search space and route pattern that will be selected after the announcement is played to the caller, the calling party device’s calling search space will not be able to select the correct 911 route pattern and gateway for the calling party. So in order to select the correct gateway to reach the PSTN based on the location of the caller, the 911 route pattern must resolve to a SLRG to select the gateway associated with the device pool of the caller.
Since this call flow leverages the annunciator to play out the announcement for calls to 911, the calling device will require access to an annunciator resource. If the UCM annunciators have been assigned to a Media Resource Group, every phone that should have the audio message played to them should have a Media Resource Group List with an annunciator available. If there are no annunciators available to the calling device, then the expected message will not be played to the calling device when calling 911. Although all Cisco IP Phones support G711a/u, G729, G722 and WB, always verify that a codec selection other than G711 also works. If the calling device does not support G711, make sure you have transcoders available to perform the appropriate codec conversion.
Tracking emergency calls:
Since this call flow leverages native call queueing in Cisco Unified Communications Manager, Cisco can provide basic statistics for the native queues to track the effectiveness of the announcement. Using the RTMT client, an administrator can determine how many potential calls to 911 were avoided. In RTMT, selecting the ‘Performance’ object in the System drawer. Expand Cisco Hunt Pilots and select QueueCallsAbandonded. Select the number of the hunt pilot. The number on the vertical axis is how many call to 911 hung up while the announcement was playing. The number of abandoned calls is the number of calls to 911 that were averted using this call flow.
Accidents happen all the time. When a real accident or emergency sitaution occurs, immedaite response is required. However, when a misdial occurs allowing the caller to end their call prior to reaching the emergency services is also expected. Since many dialplans are based on an access code of 9 followed by a long distance number of 1 or 011 for international calls, accidental calls to 911 happen on a frequent basis. The ability to capture those accidental misdials and allowing the caller a hort window to end the call prior to reaching emergency services can mean avoiding fines for excessvie non-emergency calls to 911.
The call flow described in this application note will allow an administrator to achieve both quick call delivery as well as misdial prevention at the same time. Intercepting an emergency call and delaying it by just 2 seconds can reduce accidental calls to 911 by over 95%. Additionally, an administrator can quantify the number of misdialed calls that would have previously have reached an emergency disaptcher. By reducing the number of misdialed calls to 911, a company allows emergency services to focus on their primary goal of saving lives.
I have finally gotten around to publishing a call flow that allows an administrator to play a short announcement before routing an emergency call. This call flow will not alter the location determination, but will just allow a user to hang up prior to the call being routed external to UCM. I am very interested in comments and any challenges that may occur during deployment. I look forward to hearing back from the field on how well this call flow solves accidental calls to 911.
Technical Marketing Engineer
Good afternoon Dan,
We are not allowed to reveal DIDs to the outside world, so the location of a person who dials 911 is unknown to emergency response and the local guard staff. In addition to your guide, what could we do to easily get this information?
In the states there is E911 service. Depending how you want to deploy this service you can use Cisco Emergency Responder or use the services your E911 provider offers.
We've reached out to a few vendors and West services (https://www.west.com/) is what we are looking into and mostly their own service. If I recall correctly they do not need the Cisco Emergency Responder, but they will sell you their own equipment.
Redsky also does it also - http://www.redskye911.com/
Dan, Great article.
One thought, Announcements need to be uploaded to each server just like MoH files right ?
If so, might want to edit the note to remind users to do this.
Plus as I recall the method for uploading the announcement on another CUCM server after it's created it not straightforward. You end up editing the announcement on the other CUCM nodes and repeating the upload process. It's different than the MoH file process and may confuse some folks.
If CUCM can't find the Announcement or if there is a codec mis-match or any other issue that would prevent the announcement from playing, will the call routing still work as expected and the caller will just hear silence for a few seconds and then the call will continue to route ?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: