Troubleshooting Cisco Emergency Responder

These topics address problems you might encounter with Cisco Emergency Responder (Cisco ER), and provide ways to resolve them; also included are other tasks associated with problem identification and resolution.

Troubleshooting Phone-Related Problems

These topics help you troubleshoot problems related to assigning phones to ERLs and managing the phones:

Undiscovered Phones

If Cisco Emergency Responder (Cisco ER) is not discovering the phones homing to Cisco CallManager, check that the Cisco CallManager is SNMP-reachable and that the SNMP settings are correct. Cisco ER will log an event if Cisco CallManager is SNMP-unreachable.

Step 2 If you can ping the Cisco CallManager, make sure the SNMP settings are correct on Cisco CallManager:

Start > Settings > Control Panel > Administrative Tools >
Services Properties > SNMP > Properties > Security Tab

Too Many Unlocated Phones

Cisco Emergency Responder (Cisco ER) obtains a list of registered phones from Cisco CallManager and tries to locate all phones. If Cisco ER cannot locate a phone, it places the phone in the Default ERL and puts it in a 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 Cisco ER can resolve some of the problems automatically. See the "Manually Running the Switch-Port and Phone Update Process" section for more information.

The phone is attached to a switch that is not defined in Cisco ER. See the "Identifying the LAN Switches" section for information on 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 the "Network Hardware and Software Requirements" section for a list of supported switches. See the "Manually Defining a Phone" section for information on 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. Cisco ER 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 Cisco ER. Correct the Cisco ER configuration. See the "Configuring the SNMP Connection" section.
The phone requires CAM table access, but CAM tracking is not enabled for the switch in Cisco ER. See the "Identifying the LAN Switches" section.
There is a network outage preventing communication between the Cisco ER server and the switch. Locate and resolve the network outage problem.

Unreachable switches are not retried until Cisco ER runs the next full switch-port and phone update process, unless you run it against the individual switch (see below).

The phone has moved to a switch served by a different Cisco ER group. If this is the case, the Cisco ER group name is shown for the phone in the unlocated phones list. If the phone is not locatable in the next incremental phone tracking process after it is moved, the phone remains unlocated in any Cisco ER 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 the "Identifying the LAN Switches" section for information on enabling CAM-based tracking, and "Network Hardware and Software Requirements" section for a list of phones that require CAM-based tracking.

After fixing the problems that are preventing Cisco ER 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.

Related Topics

Moved Phone Located On Wrong Switch

When you move a phone from one port to another port, it takes some time for the switch to age out the entry for the phone. If Cisco Emergency Responder's (Cisco ER's) incremental phone tracking process inspects the switch before the entry times out, Cisco ER thinks that the phone is still connected to the switch.

This situation should occur only rarely, because the switch ages out the entry within 180 seconds or so.

This miss-assignment is resolved the next time Cisco ER runs the switch-port and phone update process. If you need to resolve it sooner, manually run the process on the switch. Select Phone Tracking>LAN Switch Details and select the switch in the left-hand column; then click Locate Switch Ports.

Related Topics

Cisco IP SoftPhone Movements Not Tracked

If the computer that hosts a Cisco IP SoftPhone moves, Cisco Emergency Responder (Cisco ER) tracks the movement only during the full switch-port and phone update process. The movements are not tracked by the incremental phone tracking process. Any emergency calls from the Cisco IP SoftPhone are routed based on the last ERL assigned during the switch-port and phone update process.

If your organization uses Cisco IP SoftPhones extensively, and users move them frequently, you might consider running the full switch-port and phone update process more than once per day.

You must configure the Cisco IP SoftPhone software to work with Cisco ER. See the "Setting up Cisco IP SoftPhone for Cisco Emergency Responder" section.
You must enable CAM tracking on the switches to which Cisco IP SoftPhones are attached. See the "Identifying the LAN Switches" section for more information.
Cisco IP SoftPhones are not tracked if they are attached through a hub, even if the hub is attached to a supported switch port.
Cisco IP SoftPhones are only tracked by the incremental phone update process if the Cisco IP SoftPhone is detached from the network for more than 10 minutes. That is, at least 10 minutes must pass between unplugging the computer from the network and plugging it into a different port. If the move takes less than 10 minutes, the move is only discovered during the next full switch-port and phone update process.
Cisco IP SoftPhones, like other phones, must be attached to the network using Ethernet. Cisco ER does not support Cisco IP SoftPhones attached to other types of network such as Token-Ring or ATM.
A single Cisco ER group can support up to 500 Cisco IP SoftPhones.
With Cisco Emergency Responder 1.1(3) and later, if you change the IP address on a computer running Cisco IP SoftPhone, the IP address change will be reflected in the Cisco ER web interface.

The IP address change is reflected in the Cisco ER web interface only if you used Cisco IP SoftPhone's Automatic Selection and you used the correct URL in Network Audio Settings.

A changed IP address on a computer running Cisco IP SoftPhone will not be reflected in the Cisco ER web interface if you have selected Select IP or Specify IP in the Network Audio Settings. If you have selected Select IP or Specify IP in the Network Audio Settings, you must restart Cisco IP SoftPhone after you have changed the IP address for Cisco ER to discover the new IP address.

Related Topics

Defining the Phone Tracking and Switch Update Schedules

Phone Sometimes Disappears in Cisco Emergency Responder

If Cisco Emergency Responder (Cisco ER) is in the middle of a phone tracking process, and a phone is in the middle of homing to a different Cisco CallManager cluster, no Cisco CallManager cluster has a record of the phone. Thus, Cisco ER does not know the phone exists, and you will not be able to look up the phone in the Cisco ER interface. However, assuming the phone successfully connects to a Cisco CallManager cluster, Cisco ER tracks the phone during the next incremental phone tracking process, and the phone should then appear in the Cisco ER interface.

This problem can also occur if phones are reconnecting to a primary Cisco CallManager server from a backup server during the Cisco ER phone tracking process.

Wrong ERL is Used for a Shared Line

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

Because the moved phones are still registered to their original Cisco CallManager cluster, emergency calls from these phones are routed to the original Cisco ER group. In this case, the Cisco ER group detects that the calling phone is connected to a switch that is monitored by a different Cisco ER group, and the call is forwarded to the appropriate Cisco ER 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 Cisco ER 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 Cisco ER group, this is not a problem. However, when multiple phones with a shared line appearance connect to switches monitored by the receiving Cisco ER group, then Cisco ER 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.

Related Topics

Troubleshooting Emergency Call Problems

These topics help you troubleshoot problems related to the routing of emergency calls and the information supplied with the calls:

Emergency Calls are Not Being Intercepted by Cisco Emergency Responder

If Cisco Emergency Responder (Cisco ER) is not intercepting emergency calls, there is probably a mistake in your Cisco CallManager configuration or its representation in the Cisco ER configuration. Check these items (based on the names used in the examples in "Configuring Cisco CallManager for Cisco Emergency Responder.")

The emergency call number (911) is in the Phones partition and uses the E911CSS calling search space. Ensure this number was identified during Cisco ER installation (see the "Installing Cisco Emergency Responder on a New System" section.) This ensures that users can dial the emergency number. See the "Creating the Emergency Call Route Points" section for information on setting up the Cisco CallManager configuration for this number.
The standby Cisco ER server's route point (912) is in the E911 partition and uses the E911CSS calling search space. See the "Creating the Emergency Call Route Points" section for information on setting up the Cisco CallManager configuration for this number. Ensure this number is defined as the standby server's route point in the Cisco ER configuration (see the "Configuring Group Telephony Settings For the Cisco Emergency Responder Server" section.)
The PSAP callback route point pattern (913XXXXXXXXXX) is in the E911 partition and uses the E911CSS calling search space. See the "Creating the Emergency Call Route Points" section for information on setting up the Cisco CallManager configuration for this number. Ensure this number is defined as the PSAP callback route point pattern in the Cisco ER configuration, and that the strip prefix (913) is also identified (see the "Configuring Group Telephony Settings For the Cisco Emergency Responder Server" section.)
All ELIN route patterns are in the E911 partition. See the "Creating the Route Patterns for ELINs" section for information on setting up the Cisco CallManager 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 Cisco ER partitions and calling search spaces in the same manner as these partitions in the examples described in the "Setting Up Cisco Emergency Responder to Handle Emergency Calls" section.
All gateways to the service provider's network use the E911CSS calling search space. See the "Configuring the Calling Search Space for the Gateways Used to Connect to the PSAP" section for more information.

ELIN not Transmitted to the PSAP

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 (which will be the ELIN) rather than a static number, such as the main site number. See the "Obtain CAMA or PRI Trunks to the PSTN" section.

ELIN For Default ERL Used For Calls From Other ERLs

If an emergency call is assigned an ELIN defined for the Default ERL rather than an ELIN assigned to the ERL whence the call was made:

Check the Cisco CallManager configuration for the route pattern for the ELIN you expected to be used. See the Creating the Route Patterns for ELINs.
Check the ERL definition in Cisco ER to ensure that the ELIN is correctly configured for the ERL. See the "Setting Up an Individual ERL and Its Automatic Location Information (ALI)" section.

If the route pattern for an ERL fails, Cisco ER uses the route pattern defined for the Default ERL.

Emergency Calls Not Routed to the Correct PSAP

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 Cisco ER 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 will not be routed correctly. See the "Creating ERLs" section.
If the ELIN is correct, is the ELIN's 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.

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 the "Exporting ERL and ALI Information for Submission to Your Service Provider" section.
Does the emergency caller's phone register with a Cisco CallManager cluster supported by a different Cisco ER group than the Cisco ER group that supports the originating switch port? Then you might have a miss-configured Cisco ER cluster. See these topics:

Emergency Callers Sometimes Get Busy Signal and Emergency Calls Are Sometimes Not Routed

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 Cisco Emergency Responder (Cisco ER) server:

If you have only configured a primary Cisco ER server, install and configure a standby Cisco ER server. If CPU utilization on the primary server reaches 100%, Cisco ER 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 the "Creating the Emergency Call Route Points" section for information on the Cisco CallManager configuration, and the "Configuring Group Telephony Settings For the Cisco Emergency Responder Server" section for the Cisco ER configuration.

PSAP Call Back Errors

You might encounter these problems if a PSAP operator tries to call back an emergency caller using the ELIN provided by caller ID:

Recommended Action Cisco ER caches a mapping between the caller's true extension and the ELIN you define for an ERL. If more calls get made than the number of ELINs you define for an ERL, Cisco ER must reuse these numbers and thus overwrites the original caller's extension. You can view the call history to determine the extension of the original caller. See the "What Happens When an Emergency Call Is Made" section.

Recommended Action Cisco ER routes PSAP callbacks to the onsite alert personnel for the default ERL if ELIN-to-extension mapping for the emergency call has expired from the cache. By default, this is three hours, although you can configure expiration to be a longer or shorter time. See the "CER Group Settings" section.

Onsite Alert Personnel Are Not Getting Web Alerts

If the onsite alert personnel are not seeing web alerts in the Cisco Emergency Responder (Cisco ER) user interface, the CERAdminServer service is probably not yet initialized. This system is initialized when someone logs into the Cisco ER administration interface.

After you start the Cisco ER server, make sure you log into the administration interface at least once. You can then log out of the interface. All that is required is that someone log in once, not that someone is always logged in. You only have to log in again if you restart the server or if the service gets restarted somehow on its own (for example, a power outage takes down all computers, then the computers are restarted when power comes up; or someone unplugs the server then plugs it in again, thus restarting the server).

Onsite Alert Personnel Are Not Getting Telephone Alerts

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 partitions and calling search spaces in the same manner as these partitions in the examples described in the "Setting Up Cisco Emergency Responder to Handle Emergency Calls" section.

Also, ensure that the Cisco ER configuration for the Cisco CallManager clusters is correct. The Cisco ER configuration should show the correct begin address for the telephony ports you defined as CTI ports in Cisco CallManager, and the number of telephony ports should be the correct number and it must be greater than 0 for any calls to occur. Cisco ER uses this CTI ports to place the telephone calls to onsite alert personnel.

If the Windows Event Viewer shows the error message "No port to place call," this means that there were not enough CTI ports defined to initiate all the calls to onsite alert personnel. Define more ports.

Onsite Alert Personnel Not Getting Email (or Paging) Notifications

If the onsite alert personnel are not getting email, or email-based pages, even though you configure email addresses for them (see the "Onsite Alert Settings" section), check the Cisco ER configurations SMTP settings. Ensure that the SMTP server address and source mail ID are correct (see the "CER Group Settings" section), and that there is an account for the mail ID in the SMTP server.

Incorrect Location Information Sent To Onsite Alert Personnel

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 the "Creating ERLs" section.
Is the phone location data for the switch port correct? See the "Configuring Switch Ports" section.
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 formerly correct configuration is no longer correct. Wires cannot be moved from port to port without potentially invalidating the ERL assignment. See the "Data Integrity and Reliability Considerations" section.
The wiring closet is secure, the ERL assignment is simply incorrect. See the "Configuring Switch Ports" section.

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 the "Manually Defining a Phone" section.
The phone is not supported and it is not defined as a manual phone. See the "Manually Defining a Phone" section.
The phone is supported but Cisco ER could not locate it. You might have to manually assign the phone to an ERL if you cannot resolve the problem. See the "Too Many Unlocated Phones" section.

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 the "Manually Defining a Phone" section.

Emergency Call History Problems

Symptom Emergency call information does not show up in call history right away.

Recommended Action Cisco ER writes call history information to the LDAP directory every 45 seconds. You should be able to view history information after 45 seconds.

Symptom The call history does not show the ELIN and route pattern used for a call.

Recommended Action If the call could not be routed to the PSAP, you will not see an ELIN or route pattern. Check to determine why the call could not be routed. See the "Emergency Calls Not Routed to the Correct PSAP" section.

Recommended Action When a phone is moved to a remote Cisco ER group, Cisco ER only writes the inter-Cisco ER-group route pattern in the call history, and does not include the ELIN.

Troubleshooting Cisco Emergency Responder System and Administration Problems

These topics help you troubleshoot problems related to the Cisco Emergency Responder system and its administration, such as server and web server problems:

Troubleshooting Login Problems

These are some issues you might encounter while logging into Cisco Emergency Responder (Cisco ER):

Symptom You occasionally cannot log in as LAN switch administrator or ERL administrator.

Recommended Action Check the error message for the reason for the failed login. If the system administrator is logged in, you cannot log in as a LAN switch or ERL administrator. This is because the system administrator can configure the same data as the LAN switch and ERL administrators; you are prevented from logging in simultaneously to ensure data integrity. If the system administrator is not logged in, separate LAN switch and ERL administrators can log in simultaneously.

Symptom You cannot open multiple Cisco ER sessions using Netscape Navigator.

Recommended Action Netscape Navigator uses the same session ID across multiple windows. This creates problems if you try to log into Cisco ER using different IDs. Normally, you can open multiple windows when logged in as system administrator. With Internet Explorer, if you open separate IE session by starting a new IE instance (rather than by opening a new window from an existing session), IE uses different session IDs, and you should be able to log in using separate IDs (for example, as a user and an administrator, or as LAN switch and ERL administrators).

Recommended Action When you first connect to Cisco ER, Cisco ER goes through an initialization process before the login screen can be loaded. Once the initialization process is completed, subsequent logins (while your system is running) should not take as long.

Recommended Action Cisco ER maintains its configuration in the Cisco CallManager LDAP database. If Cisco ER cannot access the database, you cannot use the configuration screens. Check to ensure there is connectivity to the computer running the LDAP directory. If there are no connectivity problems, check the computer running the directory to ensure that the directory service has been started and is running properly.

Related Topics

Troubleshooting Cisco Emergency Responder System Problems

Troubleshooting Cisco Emergency Responder Switch and Port Configuration Problems

These are some issues you might encounter while configuring switches or switch ports in Cisco Emergency Responder (Cisco ER):

Symptom Cisco ER is configured with Cisco CallManager information, but no phones get discovered.

Symptom Cisco ER does not show the ports on a switch configured in Cisco ER.

Recommended Action If you add a supported switch to Cisco ER and run phone tracking on the switch after adding it, you should be able to view the list of 10/100 Ethernet ports on the switch. If Cisco ER does not list the ports, check the SNMP settings in Cisco ER for the switch (see the "Configuring the SNMP Connection" section.) Also, verify that the switch is reachable over the network. Retry the selective phone tracking process on the switch (click Locate Switch Ports when viewing the switch details; see the "LAN Switch Details" section.)

Recommended Action Any phones that cannot be located on a switch configured in Cisco ER will appear on the unlocated phones list (see the "Unlocated Phones" section.) See the "Too Many Unlocated Phones" section for a list of reasons that a phone could not be located.

Recommended Action You cannot delete a switch when a phone tracking process is in progress. Retry the deletion after the process has ended. If this is not the problem, the Cisco ER server might not be running. Check the control center and restart the server (see the "Starting and Stopping a Cisco Emergency Responder Server" section.)

If the problem persists, there might have been an LDAP failure the last time you tried to update the switch configuration information in Cisco ER. Try updating the switch information again (for example, by changing the notes). If the update is successful, you should then be able to delete the switch from the Cisco ER configuration.

Recommended Action If a switch port import or export attempt fails, it might be due to these reasons: the first switch-port and phone update process has not yet ended (wait for it to finish); the Cisco ER server is not running (use the control center to restart it, see the "Starting and Stopping a Cisco Emergency Responder Server" section); the Cisco ER server is not completely initialized (wait for it to initialize).

Recommended Action To import switch port configurations, Cisco ER must already be configured with the switch and Cisco ER must first discover the ports on the switch using the switch-port and phone update process. If you try to import a configuration for ports not yet discovered in Cisco ER, the importation of those settings fails. See the "Manually Running the Switch-Port and Phone Update Process" section for information on the process. Run it on the switches whose port configurations you could not import, then retry the import.

Symptom Port location information is lost after restarting the Cisco ER server.

Recommended Action Cisco ER waits five minutes before saving port location information. If the Cisco ER server goes down, or you restart it, within five minutes of changing location information, you loose the changes you made.

Symptom Phones moved from other Cisco ER groups to this Cisco ER group, and then moved back, are still showing up in the switch port details for the Cisco ER group.

Recommended Action This types of phones are not removed from the switch port details until the next full switch-port and phone update process is run. If this is an issue for you, you can run the process on the switch (or on all switches) manually. See the "Manually Running the Switch-Port and Phone Update Process" section.

Troubleshooting Cisco Emergency Responder System Problems

These are some issues you might encounter with general operation of the Cisco Emergency Responder (Cisco ER) system and the configuration screens that involve the Cisco ER server, group, and cluster:

Possible Cause You have configured Cisco ER to use a TCP port that is already in use.

Recommended Action Check the Windows Event Viewer for the message "Cisco ER could not open socket at port peer-tcp-port, Exiting." If you see this message, change the Cisco ER group configuration to use a different TCP port. See the "Configuring a Cisco Emergency Responder Server Group" section for instructions.

Symptom The Cisco ER Groups in Cluster screen does not load, and exhibits the error "Cannot connect to primary LDAP."

Recommended Action Check the connectivity to the computer running the primary LDAP directory for the cluster to which the Cisco ER group belongs. If there is connectivity, check the computer to ensure that the directory service is started and running correctly. If this does not resolve the problem, Cisco ER might not have been able to resolve the host name of the primary LDAP directory during Cisco ER installation. See the "Installing Cisco Emergency Responder on a New System" section for information on Cisco CallManager LDAP database requirements.

Symptom I can see the entry for a Cisco ER group in a drop-down list, but when I select the group, no data appears.

Related Topics

Troubleshooting Cisco CallManager Configuration Problems

These are some issues that you might encounter with Cisco Emergency Responder's (Cisco ER's) communications with Cisco CallManager. Additional problems with symptoms that involve emergency call failures are discussed in the "Troubleshooting Emergency Call Problems" section.

Symptom Cisco ER does not register with the route points and CTI ports configured for its use.

Recommended Action Ensure that the route points and CTI ports are associated with the Cisco CallManager Cisco ER user (see the "Creating a Cisco Emergency Responder Cisco CallManager User" section.) Ensure that the CTI Manager and DC Directory on the Cisco CallManager server are running properly.

Symptom When trying to delete a Cisco CallManager from the Cisco ER configuration, Cisco ER prevents me and displays the message "Phone tracking in progress."

Recommended Action You cannot delete a Cisco CallManager server from the Cisco ER configuration while a phone tracking process is in progress. Retry the deletion after the process has ended.

Updating Cisco Emergency Responder After You Add Devices

You must create a Cisco CallManager user for Cisco ER's use and CTI ports and route points that need to be assigned to the user before Cisco ER tries to create a provider with the Cisco ER cluster. Cisco ER only registers the CTI ports and route points that are associated with the user when the provider is created. Thus, any devices you add to the user after starting Cisco ER will not be registered by Cisco ER.

If you add devices to the Cisco ER user in Cisco CallManager, you can force Cisco ER to recreate the provider using any of these techniques:

Restart the Cisco ER server.
Delete the Cisco CallManager server from the Cisco ER configuration and re-enter it.
Change the backup CTI Manager setting for the Cisco CallManager server in the Cisco ER configuration and click Update. This forces Cisco ER to log off the provider and recreate it.
Change the name of the user in Cisco CallManager, or create a new user, and associate all devices with it. Then update the Cisco ER configuration to use the new user.

Identifying the Cisco Emergency Responder Groups and Servers in a Cisco Emergency Responder Cluster

If you are connected to the administrator's interface on a Cisco Emergency Responder (Cisco ER) server, you can view the details of the server and the Cisco ER group's standby server by selecting CER Group>Server Settings.

You can also identify the Cisco ER groups and their Cisco ER servers that are in the same Cisco ER cluster. To view the other Cisco ER groups in the cluster, select Reports>CER Groups in Cluster. From the Cisco ER Groups in Cluster page, select the group you want to view from the left column, and Cisco ER displays the Cisco ER servers that are in the group. To view the details for these servers, you must connect to the Cisco ER administrator's interface running on one of the servers.

If you need to uninstall a Cisco ER group, first delete the group from the Cisco ER cluster using this page. You must log in as a system administrator to delete the group. Deleting the group from the cluster simply removes the entries for the group from the Cisco ER cluster's LDAP directory; it does not remove Cisco ER from the group's servers.

Related Topics

CER Server Groups in Cluster

Starting and Stopping a Cisco Emergency Responder Server

When you install Cisco Emergency Responder (Cisco ER), the Cisco ER server is set up to automatically start whenever the computer is powered up or rebooted. However, you can stop and then restart a Cisco ER server through the Cisco ER administrator's interface without powering down or rebooting the computer. You might find this helpful if you are trying to debug a problem, or if you are trying to move a Cisco ER server to another computer.

To start or stop a Cisco ER server, select CER Group>Control Center. From the control center, you can click Start to restart the server, or Stop to stop the server. The buttons only appear if the action is possible; for example, Start only appears if the server is stopped. Table 6-1 explains the meaning of the icons you might see on this page.

Table 6-1 Cisco Emergency Responder Control Center Icons

Icon	Meaning
	The Cisco ER server is started and functioning normally.
	The Cisco ER server was stopped by the administrator.
	The Cisco ER server is experiencing connectivity or permission errors. Verify that the Cisco ER server is connected to the network and running properly. If the problem is due to permission errors, ensure that both Cisco ER servers in the group are in the same Windows domain, or if they are in different domains, that they are logged in with the same user name and password.

Icon

Meaning

The Cisco ER server is started and functioning normally.

The Cisco ER server was stopped by the administrator.

The Cisco ER server is experiencing connectivity or permission errors.

Verify that the Cisco ER server is connected to the network and running properly.

If the problem is due to permission errors, ensure that both Cisco ER servers in the group are in the same Windows domain, or if they are in different domains, that they are logged in with the same user name and password.

Related Topics

Troubleshooting ALI Data Uploads

Periodically, you must export your ALI data and submit it to your service provider. The ALI data is used to route emergency calls from your network to the correct PSAP, and provide the PSAP with information about the location of the emergency call.

Cisco Emergency Responder (Cisco ER) lets you export the ALI data in a variety of NENA formats. Ask your service provider which format you should use.

During the upload process, you might find that some ALI data records did not upload correctly. Your service provider should be able to provide you with a list of errors, or you might see these when using your service provider's data upload software. You must fix any mistaken records and resubmit the ALI data export file. To fix the records, you might need to manually edit the records in error.

These sections describe the general procedure for fixing ALI data records, and explain how to edit the various types of NENA formatted files:

Fixing ALI Data Records

If you receive data errors when uploading ALI records to your service provider, use this procedure to correct the errors.

Before You Begin

Obtain NENA Doc 02-010, Recommended Formats and Protocols for Data Exchange, from NENA or your service provider. This document explains the various NENA formats in detail.

Procedure

Step 3 If any of the records in error were new, you must change the database function for the records. Because Cisco ER has already exported these records, Cisco ER will label them as updates rather than new insertions. However, because these records failed on upload, the service provider's database will view them as new.

Open the ALI export file in a text editor and change the function code for the records that you are fixing. Use an editor that will not add formatting or other extra characters. See these sections for details about editing the files:

Editing NENA 2.0 and 2.1 File Formats

Fixed-length records
Fields are in a specific order
Unused fields are filled with blanks
End of record is indicated by an asterisk (*)

Use NENA Doc 02-010, Recommended Formats and Protocols for Data Exchange, to determine the byte location and length of each field. When you edit the file, ensure that you are not lengthening the records. Delete any extra spaces that get added. If the length of an item is less than the length of a field, pad the field with blanks. Depending on the field, padding might be on the right or the left.

The file contains one header and one trailer record. The ALI data records are contained between these records.

Table 6-2 describes the fields you are most likely to edit. You should use the Cisco ER web interface to change the other fields.

Table 6-2 NENA 2.0 and 2.1 Common Fields

Field	Description
Function Code	Location: Byte 1. Length: 1 character. Description: The database function for the record. One of: I—Insert new ALI record C—Change existing record. You must have successfully uploaded the record once before you can use C. If you are correcting a record that has never been successfully uploaded, change the C to an I. D—Delete the record. Cisco ER only generates a deletion record once, in the export file created after you deleted the ALI from the Cisco ER configuration. If you need to regenerate the record, cut and paste it from the previous export file (and adjust the record count), or recreate the ALI in Cisco ER, save it, export the data, then delete the ALI and export the data again.
Cycle Counter (sequence number)	Location: Byte 62 to 67. Length: 6 characters. Description: The sequence number of the file you are submitting to the service provider (for example, 1, 2, etc.) The number is right-aligned with leading spaces. Your service provider might ignore this field.
Record count	Location: Byte 62 to 70 in the trailer record. Length: 9 characters. Description: The total number of records in the file you are submitting to the service provider (for example, 1, 2, etc.) The number is right-aligned with leading spaces.

Field

Description

Function Code

Location: Byte 1.

Length: 1 character.

Description: The database function for the record. One of:

I—Insert new ALI record
C—Change existing record. You must have successfully uploaded the record once before you can use C. If you are correcting a record that has never been successfully uploaded, change the C to an I.
D—Delete the record. Cisco ER only generates a deletion record once, in the export file created after you deleted the ALI from the Cisco ER configuration. If you need to regenerate the record, cut and paste it from the previous export file (and adjust the record count), or recreate the ALI in Cisco ER, save it, export the data, then delete the ALI and export the data again.

Cycle Counter (sequence number)

Location: Byte 62 to 67.

Length: 6 characters.

Description: The sequence number of the file you are submitting to the service provider (for example, 1, 2, etc.) The number is right-aligned with leading spaces. Your service provider might ignore this field.

Record count

Location: Byte 62 to 70 in the trailer record.

Length: 9 characters.

Description: The total number of records in the file you are submitting to the service provider (for example, 1, 2, etc.) The number is right-aligned with leading spaces.

Editing NENA 3.0 File Formats

Variable-length records.
Fields are a tag and data combination, and can be in any order.
Unused fields are not included. The presence or absence of a tag has this effect:

If the tag is not included, the previous value of the element, if any, is left unchanged.
If the tag is included with a blank value, any previous value for the element is removed.
If the tag is include with a non-blank value, the value of the element is changed to the new value.

Tags are separated by a vertical bar (|).
End of record is indicated by a pre-defined character.

Use NENA Doc 02-010, Recommended Formats and Protocols for Data Exchange, to determine tag name and values for each field. Ensure that your values do not exceed the maximum length for the field. You do not need to pad fields with extra blanks.

The file contains one header and one trailer record. The ALI data records are contained between these records.

Table 6-2 describes the fields you are most likely to edit. You should use the Cisco ER web interface to change the other fields.

Table 6-3 NENA 3.0 Common Fields

Field	Description
Function Code	Tag: FOC. Description: The database function for the record. One of: I—Insert new ALI record (FOCI) C—Change existing record (FOCC). You must have successfully uploaded the record once before you can use C. If you are correcting a record that has never been successfully uploaded, change the C to an I. D—Delete the record (FOCD). Cisco ER only generates a deletion record once, in the export file created after you deleted the ALI from the Cisco ER configuration. If you need to regenerate the record, cut and paste it from the previous export file (and adjust the record count), or recreate the ALI in Cisco ER, save it, export the data, then delete the ALI and export the data again.
Cycle Counter (sequence number)	Tag: CYC. Description: The sequence number of the file you are submitting to the service provider (for example, CYC1, CYC2, etc.) Your service provider might ignore this field.
Record count	Tag: REC in the header and trailer records. Description: The total number of records in the file you are submitting to the service provider (for example, REC1, REC2, etc.)

Field

Description

Function Code

Tag: FOC.

Description: The database function for the record. One of:

I—Insert new ALI record (FOCI)
C—Change existing record (FOCC). You must have successfully uploaded the record once before you can use C. If you are correcting a record that has never been successfully uploaded, change the C to an I.
D—Delete the record (FOCD). Cisco ER only generates a deletion record once, in the export file created after you deleted the ALI from the Cisco ER configuration. If you need to regenerate the record, cut and paste it from the previous export file (and adjust the record count), or recreate the ALI in Cisco ER, save it, export the data, then delete the ALI and export the data again.

Cycle Counter (sequence number)

Tag: CYC.

Description: The sequence number of the file you are submitting to the service provider (for example, CYC1, CYC2, etc.) Your service provider might ignore this field.

Record count

Tag: REC in the header and trailer records.

Description: The total number of records in the file you are submitting to the service provider (for example, REC1, REC2, etc.)

Collecting Call History Logs

Cisco Emergency Responder (Cisco ER) maintains extensive call history logs, which include entries for each emergency call handled.

You can view call history information from the administration and user interfaces. The interface shows you detailed records for the past three months, or summary information for three to twelve months ago. However, if you need detailed information for periods prior to three months ago, or if you need to maintain detailed records for liability purposes, you can view Cisco ER's raw log information. You can copy and back up these files for your records.

Cisco ER maintains log files in the /callHistory directory (relative to the Cisco ER installation directory). Each server maintains logs of the calls it handles. For example, if the standby Cisco ER server in a Cisco ER group takes over for the primary server, emergency calls made are reflected only in the standby server's logs. When the primary becomes available again, the primary server takes over logging, and the calls handled by the standby server are not reflected in the primary server's logs.

Cisco ER can create up to 99,999 logs, called callRecordsxxxxx.csv, where xxxxx is a digit from 00001 to 99999. Cisco ER starts a new log whenever the Cisco ER server is started, for example, by rebooting the server, or starting and stopping the server using the control center (see the "Starting and Stopping a Cisco Emergency Responder Server" section). Cisco ER also starts a new log if a log reaches 10,000 records.

Cisco ER uses these logs in numerical sequence, that is, 00001, 00002, 00003, and so forth. After finishing 99999, Cisco ER reuses 00001.

The files are in comma-separated (CSV) format, and the first record of each log explains the fields. You can view the file with any spreadsheet program that supports CSV formats, or you can use a text editor.

Collecting Trace and Debug Information

When you contact Cisco Technical Support for help with a problem you are having with Cisco Emergency Responder (Cisco ER), Cisco might request that you collect trace and debug information.

Because collecting trace and debug information will affect Cisco ER's performance, you should only turn on tracing and debugging at Cisco's request. The generated information is for Cisco's use in resolving product problems.

Procedure

Step 2 From the left column, select the server from which you need to collect debug or trace information.

Step 3 Scroll down to the debug package and trace package sections. Select the packages that Cisco Technical Support has requested. The lists in each section are identical; make sure that you select the package in the list Cisco requested. Packages selected in the Debug list generate trace information plus extra debug data. If Cisco request you select all packages, click Select All for the appropriate list.

CER_DIRECTORY—The directory update subsystem, used for updating the LDAP directories.
CER_TELEPHONY—The telephony subsystem, used for interactions with Cisco CallManager.
CER_GROUP—The Cisco ER server group subsystem, used for communicating between servers within a group.
CER_SYSADMIN—The system administration web interface subsystem.
CER_TRACKING—The phone tracking subsystem, which runs the phone tracking and switch-port and phone update processes.
CER_CALLENGINE—The call engine subsystem, which routes and processes calls.
CER_REMOTEUPDATE—The remote update subsystem, which manages updates between servers.
CER_ONSITEALERT—The onsite alert subsystem for notifying onsite alert personnel.
CER_CLUSTER—The server cluster subsystem, used for communicating between CER groups in a cluster.

The information is placed in a log file in the /logs subdirectory of the Cisco ER installation directory. Or, if you configured Cisco ER to use the CiscoWorks 2000 Syslog facility, the data is sent to syslog. Send this information to the Cisco Technical Support group with which you are working. See the "Collecting System Logs with Syslog" section for information on using syslog.

Step 5 When you have finished generating debug and trace information, turn off debug and trace by clicking Clear All for each section in which you have made a selection. Then, click Update to complete the change.

Related Topics

Server Settings (for CER Group)

Viewing Windows Event Messages

You can view Cisco Emergency Responder (Cisco ER) messages in the Windows Event Viewer to help diagnose problems with the software. In Event Viewer, look for messages from the source "CiscoER."

See the Microsoft documentation for information on using Event Viewer. Event Viewer is an administration tool.

Managing Performance

Cisco Emergency Responder (Cisco ER) stores most configuration information in the Cisco CallManager database (directory). The size of the configuration can affect the performance of the product. Specifically, these things can hurt system performance:

A large number of manually-defined phones—Replace the phones with models that Cisco ER supports for automatic tracking (either CDP- or CAM-based). See the "Network Hardware and Software Requirements" section for the supported phone models.
A large number of unlocated phones—See the "Too Many Unlocated Phones" section for tips on resolving these issues.
A large number of ERLs—The "Determining the Required Number of Cisco Emergency Responder Groups" section describes the maximum number of ERLs a Cisco ER group can support without affecting performance. Try to keep the number of ERLs within this range.

In addition to these directory-performance issues, Cisco ER performance can be affected if Cisco ER is managing switches across a WAN link. Cisco ER must send SNMP requests to the managed switches, and WAN delays can lead to SNMP timeouts and increase the time needed to track phone and switch changes. You might need to tune the SNMP parameters. See the "Configuring the SNMP Connection" section for more information.

Integrating with Network Management Systems

You can manage the status of the Cisco Emergency Responder (Cisco ER) server remotely using CiscoWorks2000 or another SNMP-based network management system. CiscoWorks2000 is the standard Cisco network management system, but it is not bundled with Cisco ER. For more information about CiscoWorks2000, Campus Manager, and Topology Services, refer to the documentation, available at the following URL:

These topics provide information to assist you in integrating Cisco ER with network management systems:

Understanding CDP Support

Cisco Emergency Responder (Cisco ER) uses the Cisco Discovery Protocol (CDP) to periodically send out CDP messages, on the active interface, to a designated multicast address. These messages contain information such as device identification, interface name, system capabilities, SNMP agent address, and time-to-live. Any Cisco device with CDP support can locate a Cisco ER server by listening to these periodic messages.

Using information provided through CDP, the CiscoWorks2000 Server can detect the Cisco ER server, and the Campus Manager application, Topology Services, can build topology maps displaying the Cisco ER server.

In addition to sending out CDP messages, the Cisco ER server uses CDP to locate phones that support CDP. You must ensure CDP is enabled on your switches so that Cisco ER can obtain this information through SNMP queries to the switches.

Monitoring Cisco Emergency Responder Subsystem Status

Cisco Emergency Responder (Cisco ER) supports the SYSAPPL-MIB that allows you to use CiscoWorks2000 or a third-party SNMP browser to remotely access information about the following Cisco ER components:

Cisco ER Server

CERServer.exe

Cisco ER Web Administration

CERAdminServer.exe

The SYSAPPL-MIB uses the Simple Network Management Protocol (SNMP). Cisco ER supports the following SYSAPPL-MIB tables:

SysApplInstallPkgTable—provides installed application information such as Manufacturer, Product Name, Version installed, Date installed, and Location, which is a partial URL for accessing the associated Application Administration web page (when applicable).
SysApplRunTable—describes the application starting time and run-time status.
SysApplInstallElmtTable—describes the individual application elements, or associated executables, which comprise the applications defined in the SysApplInstallPkgTable.
SysApplElmtRunTable—describes the processes, or executables, that are currently running on the host system.

Collecting System Logs with Syslog

You can configure Cisco Emergency Responder (Cisco ER) to use the Cisco Syslog Collector. Cisco Syslog Collector and Cisco Syslog Analyzer are offered with CiscoWorks2000 as part of the Resource Management Essentials package. You can also adapt Syslog output from Cisco ER for use with other network management systems.

The Cisco Syslog Collector keeps common system logs of messages reported to Cisco ER.

The Cisco Syslog Analyzer controls and displays all events efficiently so they can easily be read, interpreted, and used for system maintenance and problem solving.

Procedure

Step 3 Enter the fully-qualified DNS name of the CiscoWorks2000 server in Syslog Server, for example, server.domain.com.

Related Topics

Backing Up and Recovering Data

Most Cisco Emergency Responder (Cisco ER) configuration data is stored in the Cisco CallManager database (LDAP directory). If you already have backup procedures for this database, the Cisco ER configuration is protected.

However, some configuration or log information is stored on the Cisco ER servers. Ensure that you add these files and locations to your network backup procedures. If you must restore your Cisco ER configuration, first restore the LDAP information (if necessary), then restore these files:

/callHistory directory—This contains the raw call history logs. The logs are not consolidated between a primary and standby server: backup and recover these logs independently.
Export and import files—If you created export or import files, include the directories used in your backup. You might be able to restore a lost configuration using your import files.
/location/location.txt—The phone location information associated to switch ports. If you made changes to port location information immediately before the primary server went down, the copy of this file on the backup server might not have your latest changes.
/nena_msag_record directory—Contains the MSAG files.

Related Topics

Collecting Call History Logs

Table of Contents