The subnet ID is manually configured to handle phones within a certain Subnet. Once configured, it will take care of any phone's, whose IP address falls in that range. CER does not automatically find these ranges. Nothing needs to be done on the non-supported switches for this to work - other than replace them with Cisco's magnificent switching technology. #AnotherShamelessPlug
Only only CUCM needs the SNMP configured to allow CER to reach out.
... View more
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. ;-)
... View more
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.
... View more
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.
... View more
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. :-)
... View more
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.
... View more
Yes and no. This same process can work on CUCM 10.5, however CUCM 10.5 comes with CTL being built in and controled via the CLI commands. You can read more about this in this document:
CUCM Mixed Mode with Tokenless CTL - Cisco (http://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/118893-technote-cucm-00.html)
... View more
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.
... View more
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.
... View more
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
... View more
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.
... View more
Purpose of this Document The purpose of this documentation is to provide a step-by-step instructional on providing CUCM (9.x +), Unity (9.x +), and CER (10.x +) licensing. These instructions will display how to fulfill license requests and further instructions on uploading the license files within ELM and PLM. Providing Licensing Requests to License TAC If the online license/PAK fulfillment solution does not work on the ELM or PLM, these instructions will help with any requests that Licensing TAC will request. ELM (9.x) Within ELM’s home page > License Management > Licenses > Other Fulfillment Options > Generate License Request > Copy the Hex-Dec hash (or click “Save it to a file to your PC”) Within ELM’s home page > Monitoring > License Usage > (Take screenshot) Send this information to Licensing agent PLM (10.x) Within PLM’s home page > Licenses > Fulfillment > Other Fulfillment Options > Generate License Request > Copy the Hex-Dec hash (or click “Save it to a file to your PC”) Within PLM’s home page > Licenses > Usage > (Take screenshot) Send this information to Licensing agent Upload License File (*.bin) to ELM/PLM When Licensing TAC sends the license file via Email, this is what you will need to do to get the licenses uploaded to ELM/PLM. ELM (9.x) Upload the license file: Within ELM’s home page > License Management > Licenses > Other Fulfillment Options > Fulfill Licenses from File > Browse > (Select File) > Open > Install License Verify the Licenses Usage and compliance: Within ELM’s home page > Monitoring > License Usage Alternatively, you can click on the latest file in the “Licenses” page, after upload, to see what licenses have been added. Sync with Products: Within ELM’s home page > Monitoring > License Usage > Synchronize Now PLM (10.x) Upload the license file: Within PLM’s home page > Licenses > Fulfillment > Other Fulfillment Options > Fulfill Licenses from File > Browse > (Select File) > Open > Install Verify the Licenses Usage and compliance: Within PLM’s home page > Licenses > Usage Alternatively, you can click on the latest file in the “Licenses” page, after upload, to see what licenses have been added. Sync with Products: Within PLM’s home page > Licenses > Usage > Synchronize Now
... View more
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 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. 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.
... View more