Troubleshooting Email Alerts

From DocWiki

Jump to: navigation, search

Contents

Troubleshooting Email Alerts

This chapter covers topics that help you troubleshoot problems related to the email alerts that Cisco ER generates.

Emergency Call Alert

Whenever a user makes a 911(Emergency) call, Cisco ER generates an email alert. Cisco ER 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).

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

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

When a 911 call is made and the backup Cisco ER 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 Cisco ER)

Caller Extension: 332101

Zone/ERL: Z1

Location: ddd

Call Time: June 2, 2003 3:47:30 PM IST

Transition Alert

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

  • If the primary Cisco ER server is stopped.
  • If the Cisco ER service is stopped on that server.
  • If the connectivity between primary and standby Cisco ER servers is broken.

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


When the Cisco ER backup server takes control, an alert similar to the following is sent:

Subject: Transition Alert: Cisco ER Backup is active

Message: Backup Cisco ER <<CERServer HostName>> has taken control as Active Cisco ER.

Transition Time: June 2, 2003 3:57:12 PM IST


When the master Cisco ER server takes control, an alert similar to the following is sent:

Subject: Transition Alert: Cisco ER Master is active

Message: Master Cisco ER <<CERServer 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, Cisco ER sends a Tracking Failure email to the Cisco ER administrator.

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

1. Make sure that the correct SNMP Community String is configured in Cisco ER.

2. Check that the device is connected.

3. Check that the host name for the Cisco ER 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 CallManager(s) and 1 Switch(es)

Check Event Viewer on CER Server for details.

Failed To Get Provider

Cisco ER sends a Failed to Get Provider Alert to the Cisco ER administrator if Cisco ER is not able register to one of the configured Cisco Unified CM clusters. Cisco ER will continue trying registration until it succeeds. Cisco ER sends the Failed to Get Provider email after a few retries.

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

Subject: Failed to get JTAPI Provider for Cisco CallManager <<CCM IP/Host Name>> (Generated by Backup CiscoER)

Message: Please check the following:

1. Check if the Cisco CallManager 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

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

1. If the Cisco ER Phone Tracking Engine service is down, start the service.

2. Make sure that the Host Name of the Cisco ER server does not contain any underscore (_) characters.

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

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

The administrator should restart the Cisco ER 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 Cisco ER 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 will occur very rarely. It can occur when a Cisco ER server is found in more than one Cisco ER 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: CERServer 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, Cisco ER 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 CallManager 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 Cisco ER 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 Cisco ER Application User to the “Standard CTI Allow Calling Number Modification” user group.

Calling Party Modification Failed

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

Subject: Emergency Calling Party Modification Failed (CERServer: <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 CallManager 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 CallManager User page.

Check the box for the “Enable Calling Party Number Modification” in the Cisco ER user page in Cisco Unified CM 4.2 or 4.3 Administration. After you enable this flag, restart the Cisco ER service for the changes to take effect.

Rating: 0.0/5 (0 votes cast)

Personal tools