- Purpose of this Document
- Why use CER in my VoIP environment?
- CER's Elements
- CTI Route Points
- ERLs
- Common CER/CUCM Outbound Call Flow
- What if my End User dials 9911?
- How does CER recognize where the phones are located?
- SNMP and CER
- Using IP Subnets
- Manually Adding IP Phones
- Testing your CER Solution
- Preliminary Testing
- Final Testing
- Conclusion
Purpose of this Document
This document is to help understand the architecture of CER and CUCM as explained the CER documentation up to 9.x. This document does not instruct the reader on how to configure CER but, instead, compliment the release notes & documentation released with each CER build.
Why use CER in my VoIP environment?
CER is is a product built and distributed to the US & Canada to do 4 main things: Route an emergency call out to a local public-safety answering point (PSAP), alert personnel via email or phone of an emergency call to respond to locally, keep a log of all emergency calls, & provide the PSAP with accurate geo-location of the caller in need.
CUCM has the capability to route emergency calls out to specific gateways with a carefully constructed CSS/Partition architecture; but this can get complex, hard to manage, and the other features - such as alerting, logging, geo-location, and dynamic tracking/updating of 911 details - are not as easily available or not at all.
CER's Elements
This section will explain the common CER acronyms and what they mean to the configuration. As well as understanding how CER & CUCM route an emergency call.
CTI Route Points
In an Emergency Responder deployment, CUCM uses CTI Route Points to pass 911 calls to CER in order to make calling party modifications based on the phones location. Depending on your CER environment (1 server or 2 servers in a CER Cluster) you will use either 1 or 2 CTI Route Points within CUCM for 911 calls. The CTI Route Point registered with the CER Publisher will have the 911 directory number; CTI Route Point registered to the CER Subscriber will have the 912 directory number.
There is a 3rd CTI Route Point for callbacks from the PSAP which is ‘913XXXXXXXXXX’. This is later explained in the “Call Back Number (ELIN)” section of this document.
NOTE: The 912 directory number should only be 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. The way CER does this is 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 for forwarding the call in 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 explain in the ‘ERLs’ section of this documentation’)
Two Node CER Cluster
If this is a 2 server CER environment, then the 911 directory number would have 912 set in ‘Call Forward and Call Pickup’ fields – this is to forward the 911 call to the CER subscriber- and the 912 directory number would have the ‘Default ERL’s Route Pattern in these fields.
** In this example, the '10911' is the Route Pattern that is configured on the CER's 'Default ERL'.
IMPORTANT NOTE: This is very important in case one or both CTI Route Points unregisters, or the CER server(s) are unavailable to answer the call. This way the emergency call can still be routed to a PSAP, instead of getting a fast busy.
ERLs
Emergency Response Location (ERL) are used in CER to: forward the emergency call to a Route Pattern/PSAP, provide a callback/ELIN, assign a physical location (ALI), and alert local/in-house dispatch teams of an emergency call. As you can see this is one of the most important aspects of the CER configuration as it ties the phones switch port to a physical location, allowing the PSAP to dispatch emergency response personnel to the correct location. Please take into consideration, an ERL is really the area from which an emergency call is placed. This isn’t necessarily where the emergency is, but where the call is placed from. Example, if there is a fire on the third floor but the person dials 911 from the 2nd floor.
ERLs are assigned to devices by IP Subnets & LAN Switch Port details. (This is covered in ‘How does CER recognize where the phones are located?’)
There is a ‘Default ERL’ that is required in CER. This ERL is there in case there is an end point [phone] that CER cannot match to an ERL per the administrator’s configuration. Therefore, CER will use the ‘Default ERL’ to route the call to a PSAP instead of just failing to route.
ALIs
Automatic Location Information (ALI) is the physical location of the end users of the ERL. The goal here is to pin point, as best as possible, where the responding unit (Police, Ambulance, Fire Fighters, etc.) will need to go to help the person(s) in need. This is a great feature to have in case the caller is unable to speak or gets disconnected and doesn't answer the callback.
Once the administrator completes entering this information on each ERL the administrator will need to export the ALI to a file and provide this to the PSAP. This is the link on how to do this in CER 8.6.
Generating a Formatted ALI File in CER 8.6
Call Back Number (ELIN)
Emergency Location Identification Number (ELIN) is the phone number [Caller ID] (associated with an ERL in CER) that is presented to the PSAP so they can A) Match the caller ID number to the ALI Information [Caller’s Address], and B) Provide a call back number to the PSAP in case of a call disconnect.
This can be any number your administrator would like. However, this number would need to be a Direct Inward Dial (DID) that routes to your CUCM environment. Here is how an ELIN works in a call back scenario.
- PSAP loses connection with end user caller.
- PSAP calls the ELIN/Callback number provided.
- Service Provider routes the call to your VoIP environment which will route to your CUCM environment.
- CUCM will have a translation pattern that will change the ELIN/Callback DID to prefix ‘913’ to the DID.
- The ‘913’ DID will route to the ‘913XXXXXXXXXX’ CTI Route Point which will send the number to CER.
- CER will strip the ‘913’ from the front of this DID.
- CER will match the ELIN/Callback DID in CER’s call history and transfer the call back to CUCM with the directory number of the end point [phone] that made the 911 call.
- CUCM will route the call to the end point [phone] that made the call & hopefully that person picks up.
Common CER/CUCM Outbound Call Flow
CER’s main goal is to route an emergency call to a local PSAP. Imagine Alex is in Boston and he dials 911; The CUCM cluster is in New York City and the local administrator did the most logical thing – set 911 to route to the local PSAP. Needing a PSAP Alex is glad to get someone on the phone that can help him but since he is talking to a New York PSAP they will need to re-route the call to the Boston PSAP - who can dispatch the emergency department(s) needed.
On a positive note, Alex did finally get the help that he desperately needed. However, there was precious time that was lost while waiting to be routed to the PSAP that is local to him. This can be dangerous in many ways. It could be possible the very company that Alex works for could be responsible for that loss of time since they did not route his 911 call to a local PSAP.
CER is designed to avoid this situation. If Alex is in Boston and dials 911 he will instantly be routed to a Boston PSAP that will have his exact location provided to the emergency dispatch.
This is how a typical CER call flow works.
- 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.
- CER reviews the calling end point [phone] and does the following:
- CER checks its database to get the phones ERL (based on calling number).
- CER will then modify the calling number, based on the database lookup, and log the call in its database. [ERL]
- This will provide the ELIN/Callback number & Route Pattern.
- After modifying the calling number CER will redirect the call back to CUCM. The call will then match a route pattern in CUCM.
- The Route Pattern will route the call to the correct gateway.
- The gateway routes the call to the local PSAP.
NOTE: If using CER's audio alerts - CER will use CTI ports in CUCM to call pre-defined numbers and play an announcement of a recent 911 call.
What if my End User dials 9911?
Since it is common for end users to dial 9 before dialing an outside number, such as a cell phone, this can be a hard habit to break; especially when they are in a hurry dialing an emergency number. CER/CUCM’s solution is to create a translation pattern in CUCM that would intercept the 9911 number and remove the first 9 via pre-dot – making the number 911; once this is done CUCM will route the call to the 911 CTI Route point as if the end user dialed 911 originally.
How does CER recognize where the phones are located?
CER keeps track of all the phones in your CUCM cluster and it does this entirely by talking to CUCM & supported LAN switches via SNMP. After CER queries CUCM & supported LAN Switches it will combine what was discovered into CER's database.
SNMP and CER
SNMP is a protocol that allows administrators to remotely manage devices. CER does not control any devices but, instead, uses read-only rights to take inventory of the devices on CUCM & supported LAN switches (supported LAN switches & IOS is listed in each CER's Release Notes).
This allows CER to track the IP Phone’s physical location based on its switch port. An administrator can then assign an appropriate ERL based on this information.
Cisco Emergency Responder - Release Notes
http://www.cisco.com/en/US/products/sw/voicesw/ps842/prod_release_notes_list.html
NOTE: It is important to know that CER will not show an IP phone that is on a LAN switch unless there is a phone with the same MAC address configured in CUCM.
Using IP Subnets
IP Subnets is an additional way to assign ERLs to a group of phones. If you assign specific IP Subnets to specific site, building, floors, etc. then IP Subnets is a good feature to use to track wireless phones.
Manually Adding IP Phones
CER allows an administrator to manually add phones to its configuration. An administrator may want to do this for a few reasons, one would be licensing restrictions, another would be unsupported switches in your network.
Testing your CER Solution
There are 2 ways that a CER deployment can be tested. One can allow the administrator to test throughout the configuration; the 2nd is a final test to confirm everything is reliable.
Preliminary Testing
As stated previously in this document, the call flow (CER) forwards the 911 call to a Route Pattern in CUCM which will route the call to the correct PSAP/service provider. Within this Route Pattern, the administrator can set the ‘Called Party Transformations’ > ‘Called Party Transformation Mask’ to another number you want the call to forward to; remember to set the ‘Discard Digits’ to ‘<None>’.
This will avoid calling the PSAP too many times. Once you have completed your testing be sure to remove the ‘Called Party Transform Mask’ number and set the ‘Discard Digits’ back to ‘PreDot’.
Final Testing
Once you have completed your CER/CUCM configuration you are going to want to test all sites to assure that each site is getting the correct PSAP and the PSAP is seeing the correct information. The test is simple – dial 911 and say something like the following:
“I’m testing a new emergency responding solution. Could you please let me know what call back number & address you see and what area/town your response unit is for?”
The PSAP will answer your questions and you can adjust your configuration as needed.
Be sure to let the PSAP know if you will be calling back more than once and/or if you are done testing. This will keep the PSAP informed and let them decide if they should dispatch any emergency responses for other 911 calls.
Please keep in mind that you want to do this once you are confident that your CER/CUCM configuration is completed. PSAPs are extremely busy and though they are happy to help they do have actual emergency calls to respond to.
Conclusion
I hope this documentation has made Cisco Emergency Responder (CER)’s configuration & architecture easier to comprehend. CER’s documentation can help with the configuration and explain each feature with more detail. If you feel there is anything in this documentation that needs clarification or should be added feel free to let me know. Thank you.
