Emergency Responder obtains a list of registered phones from Unified CM and tries to locate all phones. If Emergency Responder cannot locate a phone behind a switch port or in any configured IP subnets, and the phone is not a configured synthetic phone, the phone is placed in the list of unlocated phones.

If there are a lot of unlocated phones, first try running the switch port and phone update process to see if Emergency Responder can resolve some of the problems automatically. See Manually Run the Switch-Port and Phone Update Process for more information.

These are some of the situations that can prevent Emergency Responder from locating a phone:

• If more than one switch port reports the phone as a Cisco Discovery Protocol (CDP) neighbor, then the phone is placed in unlocated phones. This condition is corrected in the next phone tracking when only one switch port reports this phone as its CDP neighbor.

• The phone is attached to a switch that is not defined in Emergency Responder. See LAN Switch Identification for information about defining switches.

• The phone is connected to an unsupported device, such as a router port, a hub connected to a router, or an unsupported switch. See Network Hardware and Software Requirements for a list of supported switches. See Manually Define Phones for information about configuring these types of phones if you cannot connect them to a supported device.

• The phone is connected to a hub, which is connected to a supported switch port, but it does not support CDP. Emergency Responder can consistently discover CDP-enabled phones attached to hubs (which are attached to supported switch ports), but cannot always track non-CDP phones attached in this manner. For non-CDP phones, ensure the phones are attached directly to supported switch ports.

• The switch to which the phone is connected is currently unreachable, for example, it does not respond to SNMP queries. This could be for several reasons:

  • The SNMP read community string on the switch does not match the string configured in Emergency Responder. Correct the Emergency Responder configuration. See Set Up SNMPv2.

  • The phone requires CAM table access, but CAM tracking is not enabled for the switch in Emergency Responder. See LAN Switch Identification.

  • There is a network outage preventing communication between the Emergency Responder server and the switch. Locate and resolve the network outage problem.

    Unreachable switches are not retried until Emergency Responder runs the next full switch port and phone update process, unless you run it against the individual switch.

• The phone has moved to a switch served by a different Emergency Responder group. If this is the case, the Emergency Responder group name is shown for the phone in the unlocated phones list. If the phone is not in the next incremental phone tracking process after it is moved, the phone remains unlocated in any Emergency Responder group until a full switch port and phone update process is run.

• The phone requires CAM-based tracking, but CAM-based tracking is not enabled on the switch to which the phone is connected. Cisco IP SoftPhone and some other phone models require CAM-based tracking. See LAN Switch Identification for information about enabling CAM-based tracking, and Network Hardware and Software Requirements for a list of phones that require CAM-based tracking.

After fixing the problems that are preventing Emergency Responder from locating phones, run the switch port and phone update process on the affected switches, or on all switches:

• To run the process on a specific switch—Select Phone Tracking > LAN Switch Details and select the switch in the left-hand column; then click Locate Switch Ports.

• To run the process on all switches—Select Phone Tracking > Run Switch-Port & Phone Update.

If Emergency Responder is in the middle of a phone tracking process, and a phone is in the middle of homing to a different Unified CM cluster, no Unified CM cluster has a record of the phone. Thus, Emergency Responder does not know the phone exists, and you cannot look up the phone in the Emergency Responder interface. However, assuming the phone successfully connects to a Unified CM cluster, Emergency Responder tracks the phone during the next incremental phone tracking process, and the phone should then appear in the Emergency Responder interface.

This problem can also occur if phones are reconnecting to a primary Unified CM server from a backup server during the Emergency Responder phone tracking process.

When two or more phones with a shared line appearance move from switches that are monitored by one Emergency Responder group to switches that are monitored by a different Emergency Responder group, then Emergency Responder may assign an incorrect ERL to these phones during an emergency call. This situation can occur when the phones move to a different campus that has a different Unified CM cluster (although the moved phones are still registered with the original Unified CM cluster), and it can also occur when the phones move within a single large campus that is served by multiple Unified CM clusters.

Because the moved phones are still registered to their original Unified CM cluster, emergency calls from these phones are routed to the original Emergency Responder group. In this case, the Emergency Responder group detects that the calling phone is connected to a switch that is monitored by a different Emergency Responder group, and the call is forwarded to the appropriate Emergency Responder group through an H.323 inter-cluster trunk. Because the inter-cluster trunk does not pass the MAC address of the calling phone, the receiving Emergency Responder group does not know the MAC address of the calling phone and must associate the phone to an ERL based on the calling party number.

In cases with a single phone connected to the switches monitored by the receiving Emergency Responder group, this is not a problem. However, when multiple phones with a shared line appearance connect to switches monitored by the receiving Emergency Responder group, then Emergency Responder must guess which phone has placed the emergency call. If all of the phones with a shared line appearance are in the same ERL, the guess is correct. If the phones span multiple ERLs, then the guess might be incorrect.

Wireless endpoints (such as CiscoWirelessIP7920Phones and CiscoIPSoftPhones) may be using switch port-based ERL instead of the configured subnet-based ERL.

CiscoEmergency Responder (Emergency Responder) give a higher priority to switch port association for call routing. If Emergency Responder finds a switch port mapping for any endpoint (including wireless endpoints), it uses the switch port mapping to route emergency calls. If the switch port mapping is not found or if the ERL is not configured for the corresponding switch port, Emergency Responder routes emergency calls using subnet-ERL configuration.

See the switch port screen or the ERL debug tool (see Check Emergency Responder Configuration Using ERL Debug Tool) to check if the wireless endpoint is associated with a switch port.

It is recommended that you track wireless endpoints using subnet-based ERLs.

If Emergency Responder is not intercepting emergency calls, there is probably a mistake in your Unified CM configuration or its representation in the Emergency Responder configuration.

• The emergency call number (911) is in the Phones partition and uses the E911CSS calling search space. Ensure that this number was identified during Emergency Responder installation (see Installation on a New System) to ensure that users can dial the emergency number. See Create Emergency Call Route Points for information about setting up the Unified CM configuration for this number.

• The standby Emergency Responder server route point (912) is in the E911 partition and uses the E911CSS calling search space. See Create Emergency Call Route Points for information about setting up the Unified CM configuration for this number. Ensure this number is defined as the standby server route point in the Emergency Responder configuration (see Set Up Group Telephony Settings for Server).

• The PSAP callback route point pattern (913XXXXXXXXXX) is in the E911 partition and uses the E911CSS calling search space. See Create Emergency Call Route Points for information about setting up the Unified CM configuration for this number. Ensure this number is defined as the PSAP callback route point pattern in the Emergency Responder configuration, and that the strip prefix (913) is also identified (see Set Up Group Telephony Settings for Server).

• All ELIN route patterns are in the E911 partition. See Create Route Patterns for ERLs for information about setting up the Unified CM configuration for these numbers.

• All phones and CTI ports (both device and line) are in the Phones partition and use the PhoneCSS calling search space. You can use additional partitions, but they must be set up with relationship to the Emergency Responder partitions and calling search spaces in the same manner as these partitions in the examples described in the Create Route Patterns for ERLs.

• All gateways to the service provider's network use the E911CSS calling search space. See Set Up Calling Search Space for Gateway and PSAP Connection for more information.

• The Unified CM Version (JTAPI jar) being configured is proper. To check the Unified CM version, follow these steps:

  1. Log in to the Emergency Responder Admin Utility website.

  2. Select Update > CCM Version

  3. In the Status section, check the Current Version of CCM.

If the ELIN is not transmitted to the PSAP, and you are using a PRI connection to route emergency calls to the PSAP, check the configuration of the gateway. The PRI must be configured to send the real calling party number (the ELIN) rather than a static number, such as the main site number. See CAMA and PRI Trunks.

If an emergency call is assigned an ELIN defined for the default ERL instead of an ELIN assigned to the ERL from where the call was made:

• Check the Unified CM configuration for the route pattern for the ELIN you expected to be used. See Create Route Patterns for ERLs.

• Check the ERL definition in Emergency Responder to ensure that the ELIN is correctly configured for the ERL. See Set Up Individual ERL and Automatic Location Information (ALI).

If the route pattern for an ERL fails, Emergency Responder uses the route pattern defined for the default ERL.

If an emergency call is not routed to any PSAP, check whether the route patterns used for the ERL from which the call was made and for the default ERL are configured and use the correct partitions and calling search spaces (see Create Route Patterns for ERLs). Ensure that the partitions and calling search spaces for the gateways are correct (see Set Up Calling Search Space for Gateway and PSAP Connection).

Note	When a 911 call is made, the call does not route to an alternate PSAP when the primary PSAP call fails. The caller may hear a busy tone, but the Emergency Responder administrator will not receive an email alert that the emergency call could not be routed.

If an emergency call successfully leaves your network but does not get routed to the correct PSAP, look at these possible points of failure:

• Is Emergency Responder configured to assign the correct ELIN to the ERL assigned to the phone? Emergency calls are routed based on the ELIN, so if you assign the wrong ELIN, the call is not routed correctly. See ERL Creation.

• No Calling Party Transformation masks are set at the Gateway or Trunk, which may transform the ELIN set by Emergency Responder.

• If the ELIN is correct, is the ELIN route pattern configured to use the correct gateway? If you select the wrong gateway, the call might be routed to a part of the service provider's network that cannot connect to the desired PSAP. Consult with your service provider to determine gateway requirements.

  See these topics:

  • ELIN Numbers Emergency Calls and PSAP Callbacks

  • Deployment in Main Site with Two or More PSAPs

• Does the service provider's ALI database contain the correct information for the ELIN? Emergency call routing outside your network is based on the information in the service provider's database, not on the information in your local network. See Export ERL Information.

• Does the emergency caller's phone register with a Unified CM cluster supported by a different Emergency Responder group than the Emergency Responder group that supports the originating switch port? Then you might have a mis-configured Emergency Responder cluster. See these topics:

  • Installation on a new system

  • Create route patterns for Inter-Cisco Emergency Responder Group communications

  • Set up group telephony settings for server

    Note	If the call reaches the PSAP, but the PSAP cannot talk to the caller, ensure that the Unified CM for the remote Emergency Responder group has the Unified CM for the local Emergency Responder group defined as a gateway.

If callers hear a busy signal when calling the emergency call number, or if emergency calls sometimes do not get routed, there is probably a problem with the configuration of your standby Emergency Responder server:

• If you have only configured a primary Emergency Responder server, install and configure a standby Emergency Responder server. If CPU utilization on the primary server reaches 100 percent, Emergency Responder cannot handle emergency calls. In this case, the standby server handles the calls.

• Check the route point configuration for the standby server. Ensure the emergency call route point's call forward settings are configured to forward calls to this number. See Create Emergency Call Route Points for information about the Unified CM configuration, and the Set Up Group Telephony Settings for Server for the Emergency Responder configuration.

You might encounter a PSAP call back error if a PSAP operator tries to call back an emergency caller using the ELIN provided by caller ID. The following sections describe two such errors: if a PSAP cannot reach the original emergency call extension and if onsite security personnel get a call back from a PSAP.

If the onsite alert personnel are not getting telephone alerts when an emergency call is made in an ERL they are covering, ensure that all phones and CTI ports (both device and line) are in the Phones partition and use the PhoneCSS calling search space. You can use additional partitions, but they must be set up with relationship to the Emergency Responder partitions and calling search spaces.

Also, ensure that the Emergency Responder configuration for the Unified CM clusters is correct. The Emergency Responder configuration should show the correct beginning address for the telephony ports that you defined as CTI ports in Unified CM. The number of telephony ports should be the correct number, and the number must be greater than 0 for any calls to occur. Emergency Responder uses this CTI port to place the telephone calls to onsite alert personnel.

If the Event Viewer in the Emergency Responder Serviceability web interface displays the error message "No port to place call," then there were not enough CTI ports defined to initiate all the calls to onsite alert personnel. Therefore, you must define additional ports. To access the Event Viewer, log in to the Emergency Responder Serviceability web interface and select Tools > Event Viewer.

If the onsite alert personnel are not getting email or email-based pages, even though you configure email addresses for them, check the Emergency Responder configurations SMTP settings. Ensure that the SMTP server address and source mail ID are correct, and that there is an account for the mail ID in the SMTP server.

If your onsite alert (security) personnel are receiving incorrect location information for an emergency call, consider these potential problems:

• Is the ALI data for the ERL correct? See ERL Creation.

• Is the phone location data for the switch port correct? See Switch Port Configuration.

• Is the correct ERL assigned to the switch port to which the phone is connected? If not, there could be two problems:

  • Someone switched wires on the switch, so your previously correct configuration is no longer correct. Wires cannot be moved from port to port without potentially invalidating the ERL assignment. See Data Integrity and Reliability.

  • The wiring closet is secure, but the ERL assignment is incorrect. See Switch Port Configuration.

• Did the call come from the Default ERL (assuming you do not use the Default ERL for any permanent ERL)? This could indicate these problems:

  • The phone is connected to an unsupported port and is not defined as a manual phone. See Manually Define Phones.

  • The phone is not supported and it is not defined as a manual phone. See Manually Define Phones.

  • The phone is supported but Emergency Responder could not locate it. You might have to manually assign the phone to an ERL if you cannot resolve the problem. See Unlocated Phones.

• Did the call come from a manually-defined phone extension? If so, it is likely the incorrect ERL is assigned, perhaps because the phone moved. See Manually Define Phones.

There are two issues you might encounter when viewing the emergency call history information:

• Emergency call information does not appear in call history.

• Call history does not show call ELIN and route pattern.

For additional information, see View Emergency Call History.

Whenever a user makes a 911(Emergency) call, Emergency Responder generates an email alert. Emergency Responder sends the email alert to all the onsite alert (security) personnel whose email IDs are configured for the ERL from which the call was made.

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 CiscoER)
Message: EMERGENCY CALL DETAILS (Generated by Emergency Responder)
Caller Extension : 332101
Display Name     : Caller's Name
Zone/ERL         : Z1
Location         : ddd  
System Call Time : March 13, 2018 11:07:54 AM IST
Local Call Time  : March 12, 2018 22:37:54 PM PDT (Note: In this example, Local Call Time is for the America/Los_Angeles time zone.)

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 any of 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 activeMessage:
Backup Cisco ER <<CER HostName>> has taken control as Active Cisco ER.
Transition Time  :June 2, 2003 3:57:12 PM IST

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

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

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. The administrator should check the following and make any 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 / Unified CM).

Here is an example of a tracking failure alert:

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

Emergency Responder sends a Failed to Get Provider alert to the Emergency Responder administrator if Emergency Responder is not able to register to one of the configured 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>>

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 a period of time. This failure to communicate 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 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.

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 situation is likely 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 EngineMessage:
CER Server could not communicate with CER Phone Tracking Engine.

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

If the installation cannot validate the Publisher (Step 5 of the Install Emergency Responder Subscriber), check the following:

1. Verify that the Publisher hostname is correct and that the Publisher is reachable by hostname.

2. Verify that the Publisher and Subscriber servers are running the same version of Emergency Responder.

3. Verify that the database password that you entered is correct. This password was specified on the Database Access Security Configuration page during installation.

4. Make sure that the Subscriber has been configured correctly on the Publisher.

The following section shows some issues you might encounter while logging into Emergency Responder.

Use Cisco Unified Operations Manager to continuously monitor the health of the Emergency Responder system.

For information about setting up Emergency Responder to use Cisco Unified Operations Manager, see Set Up Test ERLs.

For information about installing and using Cisco Unified Operations Manager, go to this location:

https://www.cisco.com/c/en/us/obsolete/cloud-systems-management/cisco-prime-unified-operations-manager.html

The following sections describe several common issues that you might encounter while configuring switches or switch ports in Emergency Responder.

The following sections describe how to replace a faulty Publisher server and how to replace a faulty Subscriber server.

You can use the Emergency Responder Admin Utility tool to perform the following tasks:

• To update Emergency Responder cluster database host details

• To upgrade the CCM version

For additional information, see Track Phone Movement Across a Cluster.

To collect trace and debug information, you must enable syslog for Emergency Responder.

To enable syslog for Emergency Responder, see Collect Information From Syslog.