cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
72148
Views
105
Helpful
35
Comments
Kevin Lang
Community Member

 

 

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.

 

2012-10-03_1134.png

** 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

http://www.cisco.com/en/US/docs/voice_ip_comm/cer/8_6/english/administration/guide/e911aft.html#wp1056662

 

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.

 

  1. PSAP loses connection with end user caller.
  2. PSAP calls the ELIN/Callback number provided.
  3. Service Provider routes the call to your VoIP environment which will route to your CUCM environment.
  4. CUCM will have a translation pattern that will change the ELIN/Callback DID to prefix ‘913’ to the DID.
  5. The ‘913’ DID will route to the ‘913XXXXXXXXXX’ CTI Route Point which will send the number to CER.
  6. CER will strip the ‘913’ from the front of this DID.
  7. 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.
  8. 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.

2012-10-03_1004.png

 

This is how a typical CER call flow works.

  1. End user makes a 911 call to CUCM.
    1. 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 does the following:
    1. CER checks its database to get the phones ERL (based on calling number).
    2. CER will then modify the calling number, based on the database lookup, and log the call in its database. [ERL]
      1. This will provide the ELIN/Callback number & Route Pattern.
  3. After modifying the calling number CER will redirect the call back to CUCM. The call will then match a route pattern in CUCM.
  4. The Route Pattern will route the call to the correct gateway.
  5. 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.

Comments
rajavier3105
Level 1
Level 1

Thanks, Kevin. I can use this.

Chester Rieman
Level 1
Level 1

Where is the doc that explains how to set up jabber softphone clients with CER?

spandian6
Level 1
Level 1

How does CER recognize where the phones are located on the Non Cisco Switching Environment. It just use SNMP

Kevin Lang
Community Member

Currently, CER only supports Cisco Switches. To know which ones you can read the release notes of each version of CER. There is a list of all supported switches.

http://www.cisco.com/c/en/us/support/unified-communications/emergency-responder/products-release-notes-list.html

Yes, CER uses SNMP to discover devices on the switches and CUCM. The phone has to be registered to the CUCM that it is discovering from to be added to the CER DB.

Kevin Lang
Community Member

CER will discover all devices from CUCM. This includes Jabber phones. 

- Cisco Unified Wireless IP Phone 7920, 7921, 7925, 7925-EX, 7926, and Cisco Cius
- Cisco IP Communicator running on 802.11b
- Cisco UC Integration for Microsoft Office Communicator, Cisco UC Integration for Microsoft Lync, Cisco Jabber, Cisco Unified Personal Communicator and third-party SIP phones
- Any Cisco Unified IP Phone or third-party SIP phone that is connected to Cisco or third-party switches that are not discovered or supported by Emergency Responder

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cer/9_0/english/release/notes/CER0_BK_DA64E66_00_cisco-emergency-responder-90-release-notes/CER0_BK_DA64E66_00_cisco-emergency-responder-90-release-notes_chapter_00.html

 

The way CER can track Jabber phones is using IP Subnet. That way if the laptop moves from office to another, the IP address of the "Jabber" phone is what tells CER where it is located. 

https://supportforums.cisco.com/document/113406/cisco-emergency-responder-cer-explained#Using_IP_Subnets

 

 

spandian6
Level 1
Level 1

any option available on the non-cisco switching environment ? or any workaround

Kevin Lang
Community Member

No. The IODs for the SNMP are hardcoded into an XML. There is no way to add or modify the list. Sorry. 

spandian6
Level 1
Level 1

Then not at all possible to install CER on non -cisco switch environment.  If we want to install CER the What are the limitation ?

 

Kevin Lang
Community Member

Technically, you don't need switches to use CER. You just need to sync up with CUCM via SNMP to get the registered phones. Then you can "organize" them and define their location via Subnet ID.

Sandeep Kumar Ka
Community Member

Great Doc, Kevin. Explains CER very well.

I just had one query, as users travels to another country and connect VPN to native location and uses softphone, the phones will get the native location series ip. In that scenario, can CRE help to trace the actual location than just go by the ip address.

 

Appreciate your time..

 

Thanks Kevin, Great document to understand CER.

I also have a query.Can CER be used to track the phone location whose call is going out from a different location's SIP trunk?

The DID range is different for both sites but service provider has ported both DIDs on a single CUBE..

Many thanks in advance!!

Kevin Lang
Community Member

Hi there, 

CER can only track a phone's location per CER's ERL/ALI configuration using the device's IP address, LAN Switch Port, or manually set via DN of the phone.

The DID is only used for the PSAP to associate to the ALI information (address/location) and for call back, should the emergency call fail. 

 

Hi Kevin,

 

Im new to CER and have gone through CER admin guide to get the understanding. Im still not able understand the call flow once an emergency calls arrives at CER.

I  want to know , what is the first thing CER does and process of  election of ERL using  IP Phone address.

If multiple route patterns are selected in an ERL, then which pattern will be chosen for the call. Will the route pattern for same ERL will change as per the calling number or it will change in case there are concurrent call.

The ALI information is sent to service provider or only to onsite personnel ?

Hi Kevin,

 

Im new to CER and have gone through CER admin guide to get the understanding. Im still not able understand the call flow once an emergency calls arrives at CER.

I  want to know , what is the first thing CER does and process of  election of ERL using  IP Phone address.

If multiple route patterns are selected in an ERL, then which pattern will be chosen for the call. Will the route pattern for same ERL will change as per the calling number or it will change in case there are concurrent call.

The ALI information is sent to service provider or only to onsite personnel ?

Hi Kevin,

 

Im new to CER and have gone through CER admin guide to get the understanding. Im still not able understand the call flow once an emergency calls arrives at CER.

I  want to know , what is the first thing CER does and process of  election of ERL using  IP Phone address.

If multiple route patterns are selected in an ERL, then which pattern will be chosen for the call. Will the route pattern for same ERL will change as per the calling number or it will change in case there are concurrent call.

The ALI information is sent to service provider or only to onsite personnel ?

Getting Started

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: