Understand Emergency Responder

Introduction

This document describes the architecture of Cisco Emergency Responder (CER) Release 9.x and earlier and CUCM as explained in the CER documentation.

Background Information

This document does not provide instruction on how to configure CER, but it complements the release notes and documentation released with each CER build.

Why Use CER in my VoIP Environment

CER is a product built and distributed to the United States and Canada to perform four main things:

1. Route an emergency call to a local public-safety answering point (PSAP).
2. Alert personnel by email or phone of an emergency call to respond to locally.
3. Keep a log of all emergency calls.
4. Provide the PSAP with accurate geolocation of the caller in need.

Cisco Unified Communications Manager (CUCM) has the capability to route emergency calls to specific gateways with a carefully constructed calling search space (CSS)/Partition architecture; but this can become complex and difficult to manage. Other features, such as alerts, logs, and geolocation, are not as easily available or not at all.

CER Elements

This section explains the common CER acronyms, and what they mean to the configuration, as well as provides increased knowledge on how CER and CUCM route an emergency call.

CTI Route Points

In an Emergency Responder deployment, CUCM uses Computer Telephony Integration (CTI) Route Points to pass 911 calls to CER in order to make calling party modifications based on the phone's location. Dependent on your CER environment (one server or two servers in a CER cluster) you must use either one or two CTI Route Points within CUCM for 911 calls. The CTI Route Point registered with the CER Publisher contains the 911 directory number; CTI Route Point registered to the CER Subscriber contains the 912 directory number.

There is a third CTI Route Point for callbacks from the PSAP which is 913XXXXXXXXXX. This is explained in the Call Back Number (ELIN) section of this document.

Note: The 912 directory number is only reachable via CSS/Partitions by the 911 CTI Route Point. This is to avoid any accidental dials by end users.

CTI Route Point Failover

CER does not provide any load balance; however, it does provide a failover solution. CER provides this through the CTI Route Point's directory number configuration in CUCM.

Single Node CER Deployment

In CUCM, the CTI Route Point that was configured with the 911 directory number (DN) includes a DN configuration to forward the call in the case of a no answer or CTI failure, such as unregistered CTI Route Point, Call Forward, and Call Pickup.

In a single server CER environment, set the Call Forward fields to the number you have configured for your Default ERL in CER. Default ERL is explained in the ERLs section of this document.

Two Node CER Cluster

In a two-server CER environment, the 911 directory number contains the 912 that is set in the Call Forward and Call Pickup fields. This forwards the 911 call to the CER subscriber, and the 912 directory number contains the Default ERL route pattern in these fields.

In this example, the 10911 is the route pattern that is configured on the CER Default ERL.

Note: This is very important in the case that one or both CTI Route Points become unregistered or if the CER servers are unavailable to answer the call. The emergency call can still be routed to a PSAP instead of receiving a fast busy signal.

ERLs

Emergency Response Locations (ERL) are used in CER to:

• Forward the emergency call to a route pattern/PSAP.
• Provide a callback/Emergency Location Identification Number (ELIN).
• Assign a physical location (ALI).
• Alert local or in-house dispatch teams of an emergency call.

This is one of the most important aspects of the CER configuration because it ties the phone's switch port to a physical location, which allows the PSAP to dispatch emergency response personnel to the correct location. Take into consideration that an ERL is really the area from which an emergency call is placed; this is not necessarily the location of the emergency. For example, there is a fire on the third floor, but the person dials 911 from the second floor.

ERLs are assigned to devices by IP subnets and LAN switch port details. This is covered in the section How CER Recognizes Where the Phones are Located.

There is a Default ERL that is required in CER. This ERL exists in case there is an end point (phone) that CER cannot match to an ERL per the configuration. Therefore, CER uses the Default ERL to route the call to a PSAP so that it does not fail to route.

ALIs

Automatic Location Information (ALI) is the physical location of the end users of the ERL. The goal here is to identify as best as possible the exact location the unit that responds (police, ambulance, fire fighters, and so on) must go to in order to help the person(s) in need. This is a great feature to have in case the caller is unable to speak or is disconnected and does not answer the call back. When this information is entered on each ERL, you must export the ALI to a file and provide this to the PSAP.

Call Back Number (ELIN)

Emergency Location Identification Number (ELIN) is the phone number (Caller ID), which is associated with an ERL in CER, that is presented to the PSAP so they can match the caller ID number to the ALI Information (Caller's Address) and provide a call back number to the PSAP in case of a call disconnect.

This can be any number value. However, this number must be a Direct Inward Dial (DID) that routes to your CUCM environment. Here is how an ELIN works in a call back scenario.

1. PSAP loses connection with the end user caller.
2. PSAP calls the ELIN/Callback number provided.
3. Service Provider routes the call to your VoIP environment, which routes to your CUCM environment.
4. CUCM contains a translation pattern that changes the ELIN/Callback DID to the prefix 913 to the DID.
5. The 913 DID routes to the 913XXXXXXXXXX CTI Route Point, which sends the number to CER.
6. CER strips the 913 from the front of this DID.
7. CER matches the ELIN/Callback DID in the CER call history and transfers the call back to CUCM with the directory number of the end point (phone) that made the 911 call.
8. CUCM routes the call to the end point (phone) that made the call and hopefully that person answers the call back

Common CER/CUCM Outbound Call Flow

The main goal of CER is to route an emergency call to a local PSAP. Imagine a person is in Boston and dials 911. The CUCM cluster is in New York City and the local administrator set 911 to route to the local PSAP. The person reaches someone on the phone that can help, but since the person reached is on a New York PSAP, they must re-route the call to the Boston PSAP, who can dispatch the emergency department(s) needed. On a positive note, this person did finally receive the help that they desperately needed. However, there was precious time that was lost while they waited to be re-routed to the PSAP that is local to them. This can be dangerous in many ways. It is possible that the company the person works for could be responsible for that loss of time since they did not route the 911 call to a local PSAP.

CER is designed to avoid this situation. If the person in Boston dials 911, that person is instantly routed to a Boston PSAP that has the exact location provided to the emergency dispatch.

This is how a typical CER call flow works:

1. End user makes a 911 call to CUCM.
   • CUCM accepts the call and routes it to the 911 CTI Route Point that leads to CER.
2. CER reviews the calling end point (phone) and then:
   1. CER checks the database to retrieve the phone's ERL based on calling number.
   2. CER then modifies the calling number, based on the database lookup, and logs the call in its database (ERL).
      • This provides the ELIN/Callback number and route pattern.
3. After the calling number is modified, CER redirects the call back to CUCM. The call then matches a route pattern in CUCM.
4. The route pattern then routes the call to the correct gateway.
5. The gateway routes the call to the local PSAP.

Note: If you use CER's audio alerts, CER uses CTI ports in CUCM in order to call pre-defined numbers and play an announcement of a recent 911 call.

What if the End User Dials 9911

Because it is common for end users to dial 9 before they dial an outside number, this can be a difficult habit to break. This is especially prevalent in an urgent situation, and the user dials an emergency number. CER/CUCM's solution to this issue is to create a translation pattern in CUCM that intercepts the 9911 number and removes the first 9 via pre-dot, which changes the number to 911. When this is done, CUCM routes the call to the 911 CTI Route Point as if the end user dialed 911 originally.

How CER Recognizes Where the Phones are Located

CER keeps track of all the phones in your CUCM cluster, and it does this entirely when it talks to CUCM and supported LAN switches via Simple Network Management Protocol (SNMP). After CER queries CUCM and supported LAN switches, it combines the information discovered into the CER database.

SNMP and CER

SNMP is a protocol that allows you to manage devices remotely. CER does not control any devices, but instead, it uses read-only rights to take inventory of the devices on CUCM and supported LAN switches. The supported LAN switches and Cisco IOS® software releases are listed in each CER's Release Notes. This allows CER to track the IP Phone physical location based on its switch port. Then an appropriate ERL can be assigned based on this information.

Note: It is important to know that CER does not show an IP Phone that is on a LAN switch, unless there is a phone with the same MAC address configured in CUCM.

Use of IP Subnets

The use of IP subnets is an additional way to assign ERLs to a group of phones. If you assign specific IP subnets to a specific site, building, floor, and so on, then IP Subnets is a good feature to use in order to track wireless phones.

Add IP Phones Manually

CER allows you to add phones manually to its configuration. You want to do this for licensing restrictions or if there are unsupported switches in your network.

How to Test a CER Solution

There are two ways that a CER deployment can be tested. One can allow you to test throughout the configuration; the second is a final test to confirm everything is reliable.

Preliminary Test

As stated previously in this document, the call flow (CER) forwards the 911 call to a Route Pattern in CUCM, which routes the call to the correct PSAP/service provider. Within this Route Pattern, you can set the Called Party Transformations > Called Party Transformation Mask to another number you want the call forwarded to; remember to set the Discard Digits to <None>. This avoids calls to the PSAP too many times. When the tests are completed, be sure to remove the Called Party Transform Mask number and set the Discard Digits back to PreDot.

Final Test

When your CER/CUCM configuration is complete, you must test all sites to ensure that each site receives the correct PSAP, and the PSAP sees the correct information. The test is simple; dial 911 and say something, such as:

“This is a test of a new emergency response solution. Could you please let me know what call back number and address you see, and for what area or town your response unit is listed?”

The PSAP answers your questions, and you can adjust your configuration, as needed. Be sure to let the PSAP know if you plan to call back more than once, and/or whether the tests are complete. This keeps the PSAP informed and allows them to decide if they need to dispatch any emergency responses for other 911 calls.

Keep in mind that you want to do this when you are confident that your CER/CUCM configuration is complete. PSAPs are extremely busy, and though they are agreeable to assist, their first priority is to respond to actual emergency calls.

Conclusion

This document makes the CER configuration and architecture easier to comprehend. The CER documentation can help with the configuration and explain each feature with more detail.

Related Information

• Cisco Emergency Responder Release Notes
• Technical Support & Documentation - Cisco Systems