Enhanced 911 (E911) extends the basic 911 emergency call standard to make it more reliable.

When using basic 911 in North America, if a caller dials 911, the call is routed to a Public Safety Answering Point (PSAP), also called the 911 operator. The PSAP talks to the caller and arranges the appropriate emergency response, such as sending police, fire, or ambulance teams.

E911 extends this standard with these requirements:

• The emergency call must be routed to the local PSAP based on the location of the caller. In basic 911, the call is routed to a PSAP, but not necessarily the local one.

• The caller location information must be displayed at the emergency operator terminal. This information is obtained by querying an automatic location information (ALI) database.

In E911, the location of the caller is determined by the Emergency Location Identification Number (ELIN), which is a phone number the PSAP can dial to reconnect to the emergency caller if the emergency call is cut off or if the PSAP needs to talk to the caller again. The emergency call is routed to the PSAP based on the location information associated with this number. For multiline phone systems, such as an office system, the ELIN can be associated with more than one telephone by grouping the phones in an Emergency Response Location (ERL). In this case, the location the PSAP receives that would be the address of an office building. For large buildings, the location would include additional information such as floor or region on a floor. Each ERL requires a unique ELIN.

In addition to these general E911 requirements, each locality can further extend or limit these requirements. For example, a city ordinance might include specific limitations on the size of an ERL (such as, no larger than 7000 square feet), or on the number of phones that can be included in an ERL (such as, no more than 48 phones). You must work with your service provider and local government to determine the exact E911 requirements in your area.

See the Release Notes for Cisco Emergency Responder for a list of the new and enhanced features.

The Emergency Responder Release Notes are located at: https://www.cisco.com/c/en/us/support/unified-communications/emergency-responder/products-release-notes-list.html.

Emergency Responder supports a variety of hardware and software components. For the complete list of supported hardware and software, see the Release Notes for Cisco Emergency Responder located at http://www.cisco.com/en/US/products/sw/voicesw/ps842/prod_release_notes_list.html.

The following figure shows how CiscoEmergencyResponder (Emergency Responder) fits into your network.

Emergency Responder depends on CiscoUnifiedCommunications Manager (Cisco Unified CM) for the corporate dial plan, which you must modify to send emergency calls to the Emergency Responder group.

To track phones, Emergency Responder queries Cisco Unified CM for a list of phones registered with the cluster. Emergency Responder then queries the switches on the network to determine the port used by the phones. Emergency Responder performs this operation at regular intervals throughout the day to identify phones that have changed location. See the Emergency Responder Switch Configuration for more information about setting up switches for Emergency Responder. See Phone Management for information about configuring switch ports so that Emergency Responder can send emergency calls to the correct PSAP based on port and phone location.

Note

If you locate your Cisco IP Phones using a Cisco Layer 2 protocol with connected switch port discovery, then you must map and control your wiring plan. If you do not document changes in your wiring, Emergency Responder may not be able to locate a phone in your network. Update your wiring plan and your Emergency Responder configuration every time you change your wiring.

You can also have an SMTP email server in your network or with a service provider. You can then configure Emergency Responder to send an email to your onsite security personnel when an emergency call occurs. If the server is set up as an email-based paging service, the personnel are paged.

You also need a gateway with a PRI or CAMA link to the service provider's network so that Emergency Responder can route emergency calls to the local public safety answering point (PSAP).

Figure 1 shows one Emergency Responder group supporting a single CiscoUnifiedCommunicationsManager cluster. You can support more than one CiscoUnifiedCommunications Manager cluster with a single Emergency Responder group as long as the Unified CMs are running the same software version. With a larger network, you can install multiple Emergency Responder groups and create a Emergency Responder cluster.

See Emergency Call Process for an explanation of the path an emergency call takes when managed by Emergency Responder.

The following figure shows how Cisco Emergency Responder (Emergency Responder) interacts with your local service provider.

Cisco Emergency Responder and a Local Service Provider shows how Cisco Emergency Responder in your network interacts with local service provider. You need to have PRI/CAMA Gateway to send the Calling Party Number to your local service provider.

For more details on PRI/CAMA, see CAMA and PRI Trunks.

Instead of a local service provider, you can connect to a SIP Trunk service provider as shown in Cisco Emergency Responder and a SIP Trunk Service Provider or a dedicated National Emergency Call Delivery Service such as Intrado as shown in Cisco Emergency Responder and Intrado .

For more information on Cisco Unified Border Element, see Cisco Unified Border Element product page on Cisco.com.

For more information on Intrado, see Configure Emergency Responder and Intrado V9-1-1 Enterprise Services.

This topic describes the process that CiscoEmergencyResponder (Emergency Responder) uses to handle emergency calls. Understanding this process can help you set up Emergency Responder correctly and troubleshoot problems that you might encounter.

The following figure illustrates how Emergency Responder routes an emergency call.

When someone uses extension 3003 to make an emergency call:

1. CiscoUnifiedCommunications Manager routes the call to Emergency Responder.

2. Emergency Responder gets the route pattern configured for the emergency response location (ERL) of the caller. See Call Routing Order for information about the order of call routing.

3. Emergency Responder converts the calling party number to the route pattern configured for the caller's ERL. This route pattern is configured to pass the appropriate emergency location identification number (ELIN) to the public safety answering point (PSAP). The ELIN is a telephone number that the PSAP can use to call back the emergency caller.

4. Emergency Responder saves a mapping between the caller's extension and the ELIN, by default, for up to three hours. The mapping might be overwritten by subsequent calls before the entry times out. You can also configure the time-out to be longer or shorter than three hours.

5. Emergency Responder routes the call using the route pattern configured for the caller's ERL. This route pattern in turn uses the configured route list to send the emergency call to the appropriate service provider's network. The service provider looks up the ELIN in the automatic location information (ALI) database, and routes the call to the appropriate local PSAP. The PSAP receives the phone call and looks up the ALI in the ALI database.

6. Concurrently, Emergency Responder sends web alerts to the Emergency Responder user. In addition, Emergency Responder calls the onsite alert (security) personnel assigned to the ERL. If you configure an email address for the personnel, Emergency Responder also sends an email. If the address is for an email-based paging service, the personnel get pages instead of emails.

7. If an emergency call is cut off unexpectedly, the PSAP can call back the emergency caller using the ELIN. The call to the ELIN is routed to Emergency Responder, and Emergency Responder converts the ELIN to the last cached extension associated with the ELIN. The call is then routed to the extension.

To ensure proper performance and eliminate major points of failure, verify the following:

• For the emergency call to be routed correctly, the caller's phone must be assigned to the correct ERL. To check the correctness of the ERL associated with the phones, use the ERL debug tool.

• Another potential problem in not routing the call correctly relates to the ELIN definition. If you assign the ELINs route pattern to the wrong gateway, the emergency call can be routed to the wrong network and the PSAP can receive the wrong emergency call.

  Work with your service provider to determine how many gateways you need and where to connect them. These requirements are based on the service provider's network topology more than on your network's topology. In the United States, connecting to the PSTN does not ensure the correct routing of emergency calls.

• The call might be routed incorrectly in the service provider's network if the information in the ALI database is incorrect. Ensure that you export your ALI data and submit it to the service provider, and resubmit it whenever you change ELIN or location information.

• The PSAP might not be able to successfully call back an emergency caller if a lot of emergency calls are made from an ERL. Emergency Responder caches the ELIN-to-extension mapping for up to three hours. If you have two ELINs defined for an ERL, and three emergency calls are made in a three-hour window, the first ELIN is used twice: once for the first caller, then reused for the third caller. If the PSAP calls the first ELIN, the PSAP reaches the third caller, not the first caller. The likelihood of this problem arising depends on how many ELINs that you define for an ERL and the typical rate of emergency calls in the ERL.

An Emergency Responder cluster is a set of Emergency Responder server groups that share data to provide correct emergency call-handling capabilities. Emergency Responder cluster information is stored in a central location in the cluster called the cluster database. An Emergency Responder server group is considered part of a cluster when the group points to the same cluster database as the other server groups in that cluster.

Emergency Responder uses two separate databases:

• A database that stores Emergency Responder configuration information.

• A database that stores Emergency Responder cluster information.

During installation, both databases are created on each Emergency Responder server. However, only one Emergency Responder server contains cluster data.

Note	You cannot deploy different versions of Emergency Responder in the same Emergency Responder group. If you are upgrading to the latest version of Emergency Responder, make sure to upgrade both Emergency Responder servers to the same version.

The following figure shows how Cisco Emergency Responder (Emergency Responder) groups can be joined in a single Emergency Responder cluster.

In this example:

• There are two Cisco Unified Communications Manager clusters, Unified CM cluster A and Unified CM cluster B.

• Emergency Responder Server Group 1 and Emergency Responder Server Group 2 form a single Emergency Responder cluster.

• Emergency Responder Server Group 1 supports Unified CM cluster A and Emergency Responder Server Group 2 supports Unified CM cluster B.

• Cisco ER1 Publisher cluster database stores the Emergency Responder cluster information for both Emergency Responder server groups. Dotted lines show the Emergency Responder servers communications with the cluster database host.

• Each Emergency Responder server has a database containing the Emergency Responder configuration information.

Note	For Emergency Responder intra-cluster phone tracking to work accurately, an Emergency Responder server in the cluster must be able to be found by its hostname and must be able to be reached on the network from all other Emergency Responder servers.

Note

If you enter the system administrator email account in the System Administrator Mail ID field when you configure the Emergency Responder Server Group Settings, the system administrator receives an email notification when the standby server handles a call or when the standby server takes over for the primary server.

To complete the creation of the Emergency Responder cluster, you must navigate to the Cisco Unified CM and create inter-cluster trunks and route patterns to allow the Emergency Responder groups to hand off emergency calls between the groups and configure these route patterns in Emergency Responder.

Caution

Before you create an Emergency Responder cluster, be aware that the dial plans in all Cisco Unified Communications Manager clusters supported by the Emergency Responder cluster must be unique. For example, extension 2002 can only be defined in one Cisco Unified Communications Manager cluster. With overlapping dial plans, you must have separate Emergency Responder clusters and you cannot support dynamic phone movement between those Cisco Unified Communications Manager clusters.

The correct routing of emergency calls to the local PSAP is based on your ERL configuration. Inside your network, correct identification of the ERL for a phone determines which gateway is used to connect to the service provider's network. In the service provider's network, the routing is based on the ELIN, which is also used to look up the ALI for the caller. Your ERL configuration must be reliable so that the correct ELIN is assigned to the emergency call.

The following information will help you to maintain the reliability of your ERL configuration:

• ERLs are assigned to switch ports based on the location of the device attached to the port, not the location of the port itself. If you change the wire plugged into a port (for example, by switching wires between two or more ports), there is the potential that the device now plugged into the port is actually in a different ERL. If you do not change the ERL assigned to the port, the incorrect ELIN is used for the port, and the wrong ALI is sent to the PSAP.

  This type of change does not normally result in an incorrectly routed call, because it is unlikely that a single LAN switch connects to ERLs serviced by separate PSAPs. However, the ALI sent will be incorrect, with the possibility that your security staff will search the third floor for an emergency when the caller is actually on the fourth floor.

  To prevent this problem, ensure that your wiring closets are secure, and train your networking staff to avoid swapping wires between switch ports.

• With phones that Emergency Responder cannot automatically track, you ensure that any moves, adds, or changes to these phones also result in an update to the Emergency Responder configuration. See Manually Define Phones for information about defining these types of phones.

  Note	If the switch port mapping changes, an email alert is sent.

• Before Emergency Responder1.2, if registered phones were not located behind a switch port, Emergency Responder would list the phone in the Unlocated Phones page.

  Emergency Responder1.2 and later locates these phones as follows:

  • If a registered phone is not located behind a switch port, it may be located in one of the configured IP subnets.

  • If a registered phone is not behind a switch port, or the IP subnet of the phone is not configured, or the phone is not configured as a synthetic phone, Emergency Responder lists the phone in the Unlocated Phones page.

    To determine the ERL that Emergency Responder will use for call routing, use the ERL Debug Tool to search for the phone. The search yields the current ERL used in routing the emergency call from this phone and why Emergency Responder chose that ERL. For more information, see Emergency Responder Admin Utility.

• When you install Emergency Responder, you install a Publisher server (primary) and a Subscriber server (backup) that points to the Publisher. The Publisher server and the Subscriber server make up a Cisco Emergency Responder Server Group. This redundancy helps to ensure that the failure of one server does not affect the ability to make emergency calls. Consider installing the standby server in a physically separate location from the primary server, and on a separate subnet. This separation can protect against some types of disruption, for example, a fire in the building housing the primary server, or the loss of connectivity to the subnet hosting the primary server.

• Ensure that the Emergency Responder configuration is regularly updated as switches are added, removed, or upgraded (for example, by adding or changing modules). When you change a switch, run the switch-port and phone update process on the switch by viewing the switch in Emergency Responder and clicking Locate Switch Ports. See LAN Switch Identification for more information.

  Phones connected to undefined switches are listed as unlocated phones in Emergency Responder. If you changed a defined switch, new or changed ports become ports without an ERL association. You should assign ERLs for the new or changed switch ports. See Emergency Responder Network Administrator Role and Emergency Responder ERL Administrator Role for information about the recurring tasks involved in network changes.

• As you change your ERL/ALI configuration, you must export the information and send it to your service provider for inclusion in the ALI database. This ensures that emergency calls are routed to the correct PSAP, and that the PSAP is presented with the correct ALI. See Export ERL Information and Export ALI Information for Submission to Your Service Provider for more information.

To handle emergency calls, you must obtain PRI or CAMA trunks to connect to your service provider. Your service provider might support only one type of trunk. You should consult with your service provider and decide on the type of connection that works best for you.

Consider these issues:

• PRI—If you use a PRI connection for emergency calls, you can share the connection with regular telephone traffic. If you use the trunk for regular traffic, monitor trunk usage to ensure that there is sufficient available bandwidth to handle emergency calls. If your capacity is inadequate, an emergency caller might get a busy signal when trying to make the call. Ensure that you do capacity planning based on emergency call requirements.

  When you configure the PRI trunk, you must configure it so that it sends the actual calling-party number rather than a generic number (such as the main number of the site). Otherwise, the PSAP does not receive the expected ELIN, and the emergency call might not be routed to the right PSAP.

• CAMA—CAMA trunks are dedicated to emergency calls, and are available in most areas. You do not need to do capacity planning for CAMA trunks, because they are never used by regular voice traffic.

Work with your service provider to determine how many trunks are required for your network. For example, some service providers use a guideline of two CAMA trunks for 10,000 phones.

Also, the number of trunks can differ depending on the distribution of your offices with respect to the local PSAPs. For example, with offices in New York and Chicago, you would need trunks in both cities, even if your total number of telephones would require fewer trunks if your office was only in New York. Your service provider, who knows the layout of the emergency call network, can direct you on trunk requirements that are based on PSAP accessibility.

You must obtain direct inward dial (DID) numbers from your service provider for use as emergency location identification numbers (ELIN) for your emergency response locations (ERL).

In general, you must have at least one unique number per ERL. Emergency calls are routed to the local PSAP based on the ELIN of the ERL, so if you do not have unique ELINs, the call cannot be routed properly. The ALI database provider also might not accept ALIs that include duplicate ELINs.

You might want more than one ELIN per ERL. If your ERLs include more than one phone, you might have more than one emergency call made from an ERL in a short time (less than three hours). If you assign only one ELIN to the ERL, that ELIN is reused for each emergency call. For example, if four people make emergency calls within an hour, and if the PSAP calls the ELIN, the PSAP connects to the last caller. This situation might be a problem if the PSAP was trying to contact one of the earlier callers.

If you define more than one ELIN per ERL, Emergency Responder uses those ELINs in sequence until all are used, then reuses the ELINs in order. Emergency Responder maintains the link between the ELIN and the extension of the actual emergency caller for up to three hours.

Because you must purchase these DIDs from your service provider, you must balance the needs of your budget with the needs of maintaining the capability of the PSAP to reach the correct caller.

Note

The number of DIDs you obtain is not related to the number of emergency calls Emergency Responder can handle. Because Emergency Responder reuses the ELINs that you define, every emergency call gets handled and routed to the correct PSAP. The number of ELINs only influences the success rate of the PSAP calling back the desired emergency caller.

Emergency calls are routed to the appropriate PSAP based on the emergency location identification number (ELIN) of the emergency caller. To route the call, the telephony network must have your automatic location information (ALI) that maps these ELINs to a location. Besides routing the call appropriately, the ALI database also supplies the location information that appears on the PSAPs screens to help them locate the caller.

Emergency Responder includes features to create ALIs and to export them in a variety of formats that should be acceptable to your service provider. After you create your ERL/ALI configuration, you must export the ALI data and send it to the ALI database provider.

How you send the data can vary from location to location or service provider to service provider. You must work with your service provider to determine the services you can select for submitting ALI data. At a minimum, you must know the data format they expect, and the transmission method they require.

Emergency Responder does not include automated capability for submitting ALIs.

Tip

Before deploying Emergency Responder throughout your network, test the ALI submission process with your service provider. With your service provider's help, test that the PSAP can successfully call back into your network using the ALI data. Each service provider and ALI database provider has slightly different rules concerning ALI information. Emergency Responder allows you to create ALI data according to the general NENA standards, but your service provider or database provider has stricter rules.

The most powerful capability of Emergency Responder is the ability to automatically track the addition or movement of telephones in your network. This dynamic capability helps ensure that emergency calls are routed to the local PSAP, even if a user moves a phone between cities. By automatically tracking phones, you can reduce the cost of maintaining your telephone network, and simplify moves, adds, or changes.

However, Emergency Responder only can automatically track telephone movement for certain types of phones, and for phones attached to certain types of switch ports. See Network Hardware and Software Requirements for a list of these phones and switches.

To achieve full automation, update your switches to supported models or software versions, and replace your telephones with supported models.

To support a simple telephony network consisting of a single CiscoUnifiedCommunicationsManager cluster, install two Emergency Responder servers and configure one server as the Publisher and the other server as a Subscriber pointing to the Publisher.

Because there is only one local PSAP, you only need one gateway to the service provider's network, although capacity planning for your telephony network might require more than one gateway. Configure all route patterns to use this gateway.

The following figure shows how Emergency Responder fits into a simple telephony network with a single CiscoUnifiedCommunicationsManager cluster.

See these examples to extend this example to more complex networks:

• Deployment in Main Site with Two or More PSAPs

• Deployment in Main Site with Satellite Offices

• Deployment in Main Site Serving Multiple Sites

• Two Main Site Deployments

The following figure illustrates the Emergency Responder configuration with one main site that is served by two or more PSAPs. This example assumes you have one CiscoUnifiedCommunicationsManager cluster. If you have more than one, the setup is logically the same as the one discussed in the Two Main Site Deployments.

To support this type of network, install two Emergency Responder servers and configure one server as the Publisher and the other server as a Subscriber pointing to the Publisher.

Because there are two PSAPs serving the location, you probably need more than one gateway connecting to different parts of the service provider's network. However, this depends on the layout of the service provider's network: you might only need one gateway if the PSAPs are served by a selective router that can intelligently route emergency calls to more than one PSAP. Consult with your service provider to determine the requirements for your buildings. In this example, we assume that you need two gateways; capacity planning for your telephony network might require more than one gateway for each link.

After setting up the gateways to correctly connect to the service provider's network, configure all route patterns used in Building A ERLs to use gateway A, and all route patterns used in Building B ERLs to use gateway B. As phones move between buildings, Emergency Responder dynamically updates their ERLs so that emergency calls get routed out of the desired gateway.

See these examples to extend this example to other networks:

• Deployment in Main Site and PSAP

• Deployment in Main Site with Satellite Offices

• Deployment in Main Site Serving Multiple Sites

• Two Main Site Deployments

The following figure illustrates the Emergency Responder configuration with one main site that serves one or more satellite offices, that is, where the phones in the satellite office are run from the CiscoUnifiedCommunicationsManager cluster on the main site. If the satellite office has its own CiscoUnifiedCommunicationsManager cluster, see Two Main Site Deployments.

Caution

In this configuration, if the WAN link between the offices goes down, the people in the satellite office cannot make emergency calls with Emergency Responder support. SRST in the satellite office can provide basic support for emergency calls in case of WAN failure.

To support this type of network, install two Emergency Responder servers and configure one server as the Publisher and the other server as a Subscriber pointing to the Publisher. Install both servers in the main office.

Most likely, there are separate PSAPs serving the main (Columbus) and satellite (Chillicothe) offices. You probably need more than one gateway connecting to different parts of the service provider's network (you might have different service providers). However, this depends on the layout of the service provider's network: you might only need one gateway if the PSAPs are served by a shared switch. Consult with your service provider to determine the requirements for your buildings. In this example, we assume that you need two gateways; capacity planning for your telephony network might require more than one gateway for each link.

After setting up the gateways to correctly connect to the service provider's network, configure all route patterns used in Columbus's ERLs to use gateway COL, and all route patterns used in Chillicothe's ERLs to use gateway CHIL. As phones move between sites, Emergency Responder dynamically updates their ERLs so that emergency calls get routed out of the desired gateway.

You might also need to tune SNMP performance to account for the WAN link. Emergency Responder must do SNMP queries of the remote site switches to track phone movements there, and you might run into SNMP time-out problems if you do not allow enough time or retries to make a successful SNMP query. See Set Up SNMPv2 for more information.

See these examples to extend this example to other networks:

• Deployment in Main Site and PSAP

• Deployment in Main Site with Two or More PSAPs

• Deployment in Main Site Serving Multiple Sites

• Two Main Site Deployments

Tip

If the satellite office is small (fewer than 50 phones) and you are using survivable remote site telephony (SRST), it is probably easier to support emergency calls directly by configuring the gateway in the remote office to send 911 calls to an FXO port that has a CAMA trunk to the local PSAP rather than to Emergency Responder in the main office.

The following figure illustrates the Emergency Responder configuration with two or more main sites that are served by two or more PSAPs with one Unified CM cluster per site.

To support this type of network, install two Emergency Responder servers and configure one server as the Publisher and the other server as a Subscriber pointing to the Publisher.

Because there are two PSAPs serving the location, you probably need more than one gateway connecting to different parts of the service provider's network. However, this configuration depends on the layout of the service provider's network: you might only need one gateway if the PSAPs are served by a selective router that can intelligently route emergency calls to more than one PSAP. Consult with your service provider to determine the requirements for your buildings. In this example, assume that you need one gateway per site; capacity planning for your telephony network might require more than one gateway for each link.

After setting up the gateways to correctly connect to the service provider's network, configure all route patterns used in Site A ERLs and all route patterns used in Site B ERLs to use local site gateway. As phones move between buildings, Emergency Responder dynamically updates their ERLs so that emergency calls get routed out of the desired gateway.

In this example, Emergency Responder serves two Unified CM Clusters and facilitate the movement of phone between sites, it is required that route patterns for Site A ERLs and Site B ERLs are configured in both Site A and Site B Unified CM Clusters.

The following figure illustrates the Emergency Responder configuration with two (or more) main sites, each served by a separate PSAP.

You can adapt this example to a more complex setup by combining this discussion with these examples:

• If some of your main sites have satellite offices, see Deployment in Main Site with Satellite Offices for information about deploying Emergency Responder in those offices.

If a main site is served by more than one PSAP, see Deployment in Main Site with Two or More PSAPs for information about deploying Emergency Responder in that site. To support this type of network:

• Install two Emergency Responder servers in Chicago and configure one server as the Publisher and the other server as a Subscriber pointing to the Publisher. After installation, select the Emergency Responder Publisher server in the Chicago Emergency Responder group for use as the cluster database. See Set Up Emergency Responder Cluster and Cluster DB Host.

• Install two Emergency Responder servers in New York and configure one server as the Publisher and the other server as a Subscriber pointing to the Publisher. After installation, select the Emergency Responder Publisher server in the Chicago Emergency Responder group for use as the cluster database. See Set Up Emergency Responder Cluster and Cluster DB Host.

Most likely, there are separate PSAPs serving your main offices. In this example, Chicago and New York use different PSAPs. You need at least one gateway in Chicago, and one in New York, to connect to different parts of the service provider's network (you might have different service providers). Consult with your service provider to determine the requirements for your buildings. Capacity planning for your telephony network might require more than one gateway in each site.

After setting up the gateways to correctly connect to the service provider's network, configure all route patterns used in Chicago's ERLs to use gateway CHI, and all route patterns used in New York's ERLs to use gateway NYC.

To enable phone movement between Chicago and New York, you must also configure an inter-cluster trunk to link the CiscoUnifiedCommunicationsManager clusters, and create an inter-Emergency Responder group route pattern so that Emergency Responder can transfer calls between CiscoUnifiedCommunicationsManager clusters served by separate Emergency Responder groups.

As phones move between sites, Emergency Responder dynamically updates their ERLs so that emergency calls get routed out of the desired gateway. However, if the WAN link becomes unavailable, Emergency Responder cannot track phone movement between the sites.

Emergency Responder can provide enhanced support for 911 calls when using Extension Mobility Cross Cluster (EMCC) between two Unified CM clusters.

Deploying Cisco Emergency Responder in Two Main Sites illustrates the Emergency Responder configuration with two (or more) main sites, each served by a separate PSAP.

In this scenario, the two clusters must be configured for EMCC. When a 911 call is made by an EMCC logged-in user, the call is offered to Emergency Responder group in the users home cluster.

Emergency Responder groups in the user's home cluster and visiting cluster form an Emergency Responder cluster. Emergency Responder group in home cluster redirects the call to visiting Emergency Responder group by using Inter-Cluster Trunk (ICT) between the two Unified CM clusters and the visiting Emergency Responder routes the call to appropriate PSAP.

Note	In this scenario, the Unified CM does not have adjunct CSS configured.

See these examples to extend this example to other networks:

• Deployment in Main Site and PSAP

• Deployment in Main Site with Two or More PSAPs

• Deployment in Main Site with Satellite Offices

• Deployment in Main Site Serving Multiple Sites