Abstract:
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.
Introduction:
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.
Audience:
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.
Call flow:
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.
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.
Configuration steps:
- Create a new Partition and Calling Search Space for the hunt pilot. This document will use p_911HP and css_911HP for the partition and CSS respectively.
- Create a CTI port device. The CTI port will never register, but will be used in the line group/hunt group. The Directory Number is irrelevant, but the partition should be p_911HP.
- Create a line group and add the Directory Number from the CTI port that was just created.
- Create a Hunt List and add the line group created in the previous step.
- Record the message you would like to play to callers when they dial 911. To avoid delaying the call and longer than necessary, the message should be short. For example, the message might be “911 Emergency Services has been dialed” or “Routing call to 911 Emergency Service”. The message should be in PCM 16-bit audio format (.wav file). For additional details on the recording format, refer to the System Configuration Guide.
- Create a new Announcement that will be played to all 911 callers.
Go to ‘Media Resources->Announcements’ and Select ‘Add New’. Provide a name and description for this announcement. Leave the default announcement as <none> and save the announcement. Once saved, select the option to ‘Upload File’.
Browse to the recorded message file and select ‘Upload File’. Once the file is uploaded, the upload file status should say ‘Upload successful’ - Create a new Music On Hold Audio Source
Select an available MOH stream number. Provide an MOH Audio Source Name. This can be descriptive, like ‘CallTo911’. Select an MOH Audio Source File. This will not be used, so the selection is unimportant. In the ‘Announcement Settings for Held and Hunt Pilot Call’, set the Initial announcement and periodic announcement to the announcement created in step 6.
Set the ‘Initial Announcement for queuing-enabled Hunt Pilot calls’ to ‘Play announcement before routing to Hunt Member’. Save the MOH Audio Source - Create a new Hunt Pilot to play the audio announcement to callers.
Go to ‘Call Routing->Route/Hunt->Hunt Pilot’ and select ‘Add New’. Set the number to be used for this hunt pilot. This number will be set in the called party number on the 911/9911 translation patterns. Set the ‘Route Partition’ to the partition created in step 1 (p_911HP in this document). Select the Hunt list created in step 4. In the ‘Queueing’ section, check ‘Queue Calls’ box. In the same section, set the ‘Network Hold MOH’ setting to the MOH Source you created in step 7.
In the same section, set the “When no hunt members answer, are logged in or registered’ to a target number in the ‘Route the call to this destination’ and the appropriate calling search space to the next hop for processing the 911 call. This will typically be a CER Route Point or a 911 Route Pattern that will resolve the local gateway via Standard Local Route Group.
Save the Hunt Pilot. - Test the new call flow prior to using the hunt pilot. Create a translation pattern with arbitrary number to route through the hunt pilot.
Create a translation pattern with any number (*911 in this scenario) in a partition that the phones can reach. Set the called party number to the number of the Hunt Pilot (999999) and the calling search space to the one created in step 1
Dial the translation pattern to verify the desired message is heard. You may also consider verifying that calls route correctly through this call flow, but be sure to stay on the line and tell the PSAP dispatcher that this was a test and there is no emergency. It would be recommended that you verify the dispatch address at the same time. (NOTE: it is not advisable to call the local PSAP more than once to verify your address.) - After verifying that the test calls route through the hunt pilot to CER or a route pattern using SLRG (See section below on Routing to CER or Route Pattern for details), update the system 911/9911 translation pattern with the calling search space and hunt pilot Directory Number defined earlier in this document.
- Verify that system user calls will trigger the audio announcements before routing the call.
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.
Other Considerations:
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.
Conclusion:
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.
