Cisco Emergency Responder 8.6 Troubleshooting Guide
Troubleshooting Email Alerts
Downloads: This chapterpdf (PDF - 366.0KB) The complete bookPDF (PDF - 1.24MB) | Feedback

Troubleshooting Email Alerts

Table Of Contents

Troubleshooting Email Alerts

Emergency Call Alert

Transition Alert

Tracking Failure

Failed To Get Provider

Failed To Establish Communication With Cisco Emergency Responder Phone Tracking Engine

Lost Communication With Cisco Emergency Responder Phone Tracking Engine

Failed To Send Unlocated Phone Details To Remote Cisco Emergency Responder Server Group

Emergency Call Could Not Be Routed

Calling Party Modification Failed


Troubleshooting Email Alerts


This chapter covers topics that help you troubleshoot problems related to the email alerts that Cisco Emergency Responder (Emergency Responder) generates:

Emergency Call Alert

Transition Alert

Tracking Failure

Failed To Get Provider

Failed To Establish Communication With Cisco Emergency Responder Phone Tracking Engine

Lost Communication With Cisco Emergency Responder Phone Tracking Engine

Failed To Send Unlocated Phone Details To Remote Cisco Emergency Responder Server Group

Emergency Call Could Not Be Routed

Calling Party Modification Failed

Emergency Call Alert

Whenever a user makes a 911(Emergency) call, Emergency Responder generates an email alert. Emergency Responder sends the email alert to all of the onsite alert (security) personnel whose email ids are configured for the ERL from which the call was made. (See the Configuring a Cisco Emergency Responder Server Group section in the Cisco Emergency Responder 8.6 Administrative Guide)

Security personnel are expected to respond to that user. For detailed call information, see the following URL:

http://<<CERServer HostName>>/ceruserreports

When a 911 call is made and the backup Emergency Responder server handles the call, an alert similar to the following is sent:

Subject: Emergency Call Alert -- Extn # 332101 (Generated by Backup Cisco ER)
Message: EMERGENCY CALL DETAILS (Generated by Emergency Responder)
Caller Extension:332101
Zone/ERL         :Z1
Location         :ddd    
Call Time        :June 2, 2003 3:47:30 PM IST

Transition Alert

When the standby Emergency Responder server takes control and becomes the active server, a Transition Alert is sent to the Emergency Responder administrator. This situation occurs under the following circumstances:

If the primary Emergency Responder server is stopped.

If the Emergency Responder service is stopped on that server.

If the connectivity between primary and standby Emergency Responder servers is broken.

The administrator should diagnose the cause and fix the problem as soon as possible.

When the Emergency Responder backup server takes control, an alert similar to the following is sent:

Subject: Transition Alert: Cisco ER Backup is active
Message:
Backup Cisco ER <<CER HostName>> has taken control as Active Cisco ER.
Transition Time  :June 2, 2003 3:57:12 PM IST

When the master Emergency Responder server takes control, an alert similar to the following is sent:

Subject: Transition Alert: Cisco ER Master is active
Message:
Master Cisco ER <<Emergency Responder Server HostName>> has taken control as Active Cisco 
ER.
Transition Time  :June 2, 2003 3:57:12 PM IST

Tracking Failure

At the end of a switch-port and phone tracking process, if there are any devices that could not be tracked, Emergency Responder sends a Tracking Failure email to the Emergency Responder administrator.

The administrator should look at the event log on the Emergency Responder server to find the list of devices that were not tracked. Then the administrator should check the following and make the required corrections:

1. Make sure that the correct SNMP Community String is configured in Emergency Responder.

2. Check that the device is connected.

3. Check that the host name for the Emergency Responder server is resolvable, that is, it can be found.

4. Check that the SNMP service is enabled on that particular device (Switch / Cisco Unified CM).

Here is an example of a tracking failure alert.

Subject: CER Phone Tracking failed to track some devices
Message:
CER Phone Tracking could not get information [using SNMP] from 2 Cisco Cisco Unified CM(s) 
and 1 Switch(es)
Check Event Viewer on CER Server for details.

Failed To Get Provider

Emergency Responder sends a Failed to Get Provider Alert to the Emergency Responder administrator if Emergency Responder is not able register to one of the configured Cisco Unified Communications Manager (Cisco Unified CM) clusters. Emergency Responder continues trying the registration until it succeeds. Emergency Responder sends the Failed to Get Provider email after a few retries.

The message provides information about how to clear the problem, as shown in the following example.

Subject: Failed to get JTAPI Provider for Cisco Unified CM <<CCM IP/Host Name>> (Generated 
by Backup Cisco ER)
Message:
Please check the following:
1) Check if the Cisco Unified CM is connected to the CER server.
2) Check if the configured Call Manager is running a version supported by the CER server.
3) Check if the given login credentials are correct:
	CTI Manager Host Name:<<CCM IP/HostName>>

Failed To Establish Communication With Cisco Emergency Responder Phone Tracking Engine

Emergency Responder sends this email alert to the Emergency Responder administrator if the Emergency Responder server fails to establish communication with the Phone Tracking Engine for some time. This can occur if the Emergency Responder Phone Tracking Engine service is down. The administrator should perform the following steps:

1. If the Emergency Responder Phone Tracking Engine service is down, start the service.

2. Make sure that the Host Name of the Emergency Responder server does not contain an underscore (_) character.

Here is an example of a tracking failure alert.

Subject: CER Server failed to establish communication with CER Phone Tracking Engine.
Message:
CER Server could not communicate with CER Phone Tracking Engine.

Lost Communication With Cisco Emergency Responder Phone Tracking Engine

Emergency Responder sends this email alert to the Emergency Responder administrator if the Emergency Responder server loses communication with the Emergency Responder Phone Tracking Engine. This is most liked to occur if the Emergency Responder Phone Tracking Engine service goes down when the Emergency Responder server is running.

The administrator should restart the Emergency Responder Phone Tracking Engine service.

The following shows an example of a tracking failure alert.

Subject: CER Server lost communication with CER Phone Tracking Engine
Message:
CER Server could not communicate with CER Phone Tracking Engine.

Failed To Send Unlocated Phone Details To Remote Cisco Emergency Responder Server Group

If Emergency Responder fails to send unlocated entries to a server group because it is already in the process of sending entries to that server group, this alert is sent.

This alert occurs very rarely. It can occur when a Emergency Responder server is found in more than one Emergency Responder server group. To resolve this problem, check to see which server group is an old configuration and remove that server group.

Subject: CER Server failed to send Unlocated Phones details to Remote CER Server Group.
Message:
CER Server failed to send Unlocated Phones to Remote CER Server Group. Please ensure that 
the CER servers are not found under more than one CER Server Group.
CER Servers in Remote Server Group:<< CERServer HostNames >>

Emergency Call Could Not Be Routed

If the emergency call routing to some route patterns configured in the ERL fails, Emergency Responder sends an email to the system administrator.

Subject: Emergency call could not be routed using some route patterns (CERServer:<server hostname>)

Message Body: Emergency call from: <Caller Extn> could not be routed using some Route Patterns. Check Event Log.

The Event Log displays the following message:

Emergency call from <extn> could not be routed using the following route patterns

<RoutePattern1>
<RoutePattern2>
*****************
Call Routed to <RoutePattern-X>

Please check the availability of the above routes. Also, check for the following error 
conditions:

1. If FAC and/or CMC are configured on the route patterns used for Cisco ER, please 
disable them.
2. If the "Calling Party Number Modification" flag on the CER user page in the Cisco 
Unified CM is not enabled, please enable it.

Solution   

1. If you are running Cisco Unified CM 4.2 or 4.3, check to make sure that the Calling Party Number checkbox on the Emergency Responder User page is checked.

2. If you are running Cisco Unified CM 5.x or Cisco Unified CM 6.x, check to make sure that the routes are available.

3. Add the Emergency Responder Application User to the "Standard CTI Allow Calling Number Modification" user group.

Calling Party Modification Failed

If the calling party modification was not successful, Emergency Responder sends the following email to the system administrator:

Subject: Emergency Calling Party Modification Failed (Emergency Responder Server: <server>)

Message Body: Emergency call from :<Caller Extn> cannot be routed with calling party modification. Check Event Log.

The Event Log displays the following message:

Emergency Call from <Caller Extn> has been routed to default ERL because the calling party 
modification failed.
Please make sure that the checkbox "Enable Calling Party Number Modification: is checked 
on the Cisco Unified CM user page for the CER user. PSAP callbacks MAY NOT work correctly. 
The CER service will need to be restarted once the flag is checked on the Cisco Unified CM 
User page.

Check the box for the "Enable Calling Party Number Modification" in the Emergency Responder user page in Cisco Unified CM Administration. After you enable this flag, restart the Emergency Responder service for the changes to take effect.