cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

Cisco Emergency Responder (CER) Explained

44538
Views
94
Helpful
35
Comments

 

 

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
Beginner

Hi Kevin,

This is a very nice description of the CER CUCM process.

One question though on the process of the call from CER back to CUCM after the calling number has been modified. What is being used to make the call from CER back to the CUCM route pattern? Is it the CTI Route Point like in the case of UCCX making a call back to CUCM?

  1. After modifying the calling number CER will redirect the call back to CUCM. The call will then match a route pattern in CUCM.

1a   What is being used to make the call from CER back to CUCM ????

  1. The Route Pattern will route the call to the correct gateway.

thanks

Community Member

What is being used to make the call from CER back to the CUCM route pattern?
I'm not entirely sure what you are referring to. BUt, you need to look at CER calling PSAP and PSAP calling CER as two separate call flows.
CER calling PSAP == Phone -> CUCM1 -> CER (does a forwarding of the call, but keeps track/control of the call) -> CUCM1 -> Gateway -> PSAP
PSAP calling CER == PSAP (Calling DID provided via callback number/ELIN from CER) -> Provider -> Gateway -> CUCM1 -> CER (based on callback number/ELIN and last 911 call that ended with this ELIN. Call will be forwarded to phone) -> CUCM1 -> Phone

Is it the CTI Route Point like in the case of UCCX making a call back to CUCM?
UCCX is far more complex, in its involvement with the call. CER simply forwards the call to a Route Pattern & modified the calling party's number. However, CER does maintain "control" of the call for monitoring purposes.

After modifying the calling number CER will redirect the call back to CUCM. The call will then match a route pattern in CUCM.
1a What is being used to make the call from CER back to CUCM ????
CER doesn't initiate any calls. It merely forwards the call to the end point, per configuration.

The Route Pattern will route the call to the correct gateway.
Yes.

Beginner

Hi Kevin,

Thanks for the feedback.

So part of the process on the CER to PSAP call flow is CER forwarding the call back to CUCM. Does CER use a CTI Route Point to forward the call back to CUCM? CER has to use something similar to how it uses CTI ports to make alerting calls to CUCM phones. The reference to UCCX is that UCCX uses CTI Route Points to call forward/call back/place calls to CUCM from a queue or other function.

CER calling PSAP == Phone -> CUCM1 -> CER (does a forwarding of the call, but keeps track/control of the call) -> CUCM1 -> Gateway -> PSAP

thanks

Community Member

So part of the process on the CER to PSAP call flow is CER forwarding the call back to CUCM.
Does CER use a CTI Route Point to forward the call back to CUCM?
Yes. It uses the same 911/912 CTI Route Point to forward the call as it uses to accept the emergency call.

CER has to use something similar to how it uses CTI ports to make alerting calls to CUCM phones. The reference to UCCX is that UCCX uses CTI Route Points to call forward/call back/place calls to CUCM from a queue or other function.
Concerning call redirection, CER will use the CTI Route Points utilized to forward the call. UCCX does use CTI port to call agents, then connect the call once the agent answers, but CER does not do this method. This is because CER is not reaching out to multiple end users/agents to see who will be accepting the call. CER simply forwards the call to the last known number, that recently ended a call using the defined ELIN. 


CER uses CTI ports to call Onsite Alert numbers, to make specific people aware of an emergency call. Such as local security or Superman. :-)

Beginner

Awesome  thanks

That is what I was leaning to but just wanted to be sure

Beginner

Hey Kevin,

In case anyone makes the same mistake like me, it may be worth adding under the Call Back Number (ELIN) section that the 913XXX CTI RP will need access to a CSS that can reach the internal phones.

I was testing our PSAP Call Back functionality and was the call was getting dropped.  In our logs I saw this message "CER_TELEPHONY-3: PSAP Callback failed for  :  Address = +16165551234  ;  Terminal = SIP_PSTN_GATEWAY- because, routedEndEvent returned :CAUSE_INVALID_DESTINATION"

Once the CSS was changed it routed to the internal IP phone as expected.

Enthusiast

Kevin - would you be able to PM me about what options are available for setting up CER for internal/on net use only?

Thanks,
Dan

Beginner

Hi Kevin,

Thanks for the excellent explanation.

I have one Question though. Do we have to enter the switch port information? or entering only the subnet info will work too?

For example, I added the subnet of the phones, and I can see them under the tracked phones. I have already assigned the ERL to this subnet. But i did not entered any info regarding the switch. Will it work?

Thanks

Abdul

Beginner

My workplace does only subnet and it works but I recommend tracking on both if you have a dynamic environment. 

Community Member

CER will use one tracking method or the other. Using both doesn't have any true benefit. 

CER will use the Switch ports placement as a higher preference than IP Subnet. But the switch environment has to be using switches that are supported by CER's version, which can be found in the CER version's Release notes. 

Community Member

Kevin -

If using CER and CUCM via SNMP (non supported switches), will this support extension mobility?  Will CER be able to track the location of an extension that moves to another phone/subnet?

Thank you

Community Member

Extension mobility (EM) is a feature in CUCM that allows an end user to log into a phone using a profile - much like how you can log into someone else's Windows desktop and get to your own file shares and email, but not theirs. Therefore, EM is not really a location based thing. If someone were to call 911 from a phone, while logged into EM, CER determines the phone's location via Subnet ID, manual configuration, or Switch port location. EM is not considered at all, because EM does not assist in determining where the phone is physically stationed.

CER & CUCM's SNMP connection allows CER to be aware of phones registered to the CUCM cluster (each CUCM node reports individually). For example, if I have 2 CUCM nodes in my cluster (CMPub & CMSub), and my phone is registered to CMSub, then the CER needs to do a SNMP query against CMSub to know if that phone is registered. If a phone is found on a Switch or Subnet, but not registered to CUCM, it is ignored by CER, as 911 calls cannot be routed to CER.

Using Switch location is only 1 method of identifying the phone's physical location. It is Cisco preferred because ordinarily switch ports are not changed very often and lead to a physical location in the building - which then tells CER exactly where that phone is. Subnet ID uses networking logic to determine where a phone generally is. Such as, 10.1.1.0/24 is BuildingA; 10.1.2.0/24 is BuildingB. Therefore, if a phone with an IP of 10.1.1.10 calls 911, logic dictates the call came from BuildingA

NOTE: All location methods are something the CER admin needs to maintain. CER doesn't do it by itself.

I hope this helps. 

Community Member

Thank you. 

A follow up, if using non-supported switches with CER using subnet based location, does CER need to be able to access the switches via SNMP or does CER get all information required from CUCM?

Thanks again

Community Member

Negative, Ghost Rider. Subnet ID and Switch location is normally an "either, or" feature. You can use both at the same time, but typically a company will use just one to simplify things. 

In your situation (using non-Cisco switches), using Subnet ID or Manual are your only choices. With Subnet ID you still need to use CER <-> CUCM SNMP communication. 

However, why you wouldn't want to use Cisco's superior routing and switching technology over other makes is beyond me. ;-)

Community Member

Thank you.

With Subnet ID, assuming manual config of the CER to define the subnets is required?  Using Subnet ID, does SNMP need to be configured on the non-supported switches to allow CER to pull information or is CER <--> CUCM the only communication required when using Subnet ID.

Thanks again.

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards