Cisco Emergency Responder 8.6 Administration Guide
Chapter 1: Planning for Cisco Emergency Responder 8.6
Downloads: This chapterpdf (PDF - 667.0KB) The complete bookPDF (PDF - 12.85MB) | Feedback

Planning for Cisco Emergency Responder 8.6

Table Of Contents

Planning for Cisco Emergency Responder 8.6

Understanding Enhanced 911 (E911)

Overview of Enhanced 911 Requirements

Understanding E911 and Cisco Emergency Responder Terminology

Understanding Cisco Emergency Responder

Cisco Emergency Responder 8.6 Features

Network Hardware and Software Requirements

Licenses for Cisco Emergency Responder 8.6

Licenses for Initial Installation or Upgrades

Server Licenses

User Licenses

Determining Your License Requirements

Uploading License Files

How Cisco Emergency Responder Fits Into Your Network

What Happens When an Emergency Call Is Made

Cisco Emergency Responder Call Routing Order

Location Information for Calls Forwarded by CTI Applications

Understanding Cisco Emergency Responder Clusters and Groups

Moving Phone Between Clusters

Determining the Required Number of Cisco Emergency Responder Groups

Data Integrity and Reliability Considerations

Preparing Your Network For Cisco Emergency Responder

Obtain CAMA or PRI Trunks to the PSTN

Obtain DID Numbers from Your Service Provider

Negotiate ALI Submission Requirements With Your Service Provider

Upgrade Switches and Phones

Preparing Your Staff for Cisco Emergency Responder

Deploying Cisco Emergency Responder

Deploying Cisco Emergency Responder in One Main Site with One PSAP

Deploying Cisco Emergency Responder in One Main Site with Two or More PSAPs

Deploying Cisco Emergency Responder In One Main Site with Satellite Offices

Deploying Cisco Emergency Responder In One Main Site Serving Two or more Sites

Emergency Responder in One Site Serving Two or more sites with EMCC

Deploying Cisco Emergency Responder In Two Main Sites

Deploying Cisco Emergency Responder In Two Main Sites as Emergency Responder Cluster with EMCC

Deploying Cisco Emergency Responder In Two Main Sites as Emergency Responder Cluster with Adjunct CSS Configuration

Configuring a Local Route Group in a Wide Area Network Deployment


Planning for Cisco Emergency Responder 8.6


Cisco Emergency Responder 8.6 Administrator Guide (Emergency Responder 8.6) helps you manage emergency calls in your telephony network so that you can respond to these calls effectively and so that you can comply with local ordinances concerning the handling of emergency calls. In North America, these local ordinances are called "enhanced 911," or E911. Other countries and locales have similar ordinances.

Because emergency call ordinances can differ from location to location within a country, region, state, or even metropolitan area, Emergency Responder includes the flexibility you must fit your emergency call configuration to specific local requirements. However, because ordinances do differ from location to location, and because security requirements differ from company to company, you must do extensive planning and research before you can deploy Emergency Responder in a manner that fits your legal and security needs.

These topics help you understand emergency call ordinances, how Emergency Responder helps you meet the ordinances, and what you must do to deploy Emergency Responder successfully:

Understanding Enhanced 911 (E911)

Understanding Cisco Emergency Responder

Preparing Your Network For Cisco Emergency Responder

Preparing Your Staff for Cisco Emergency Responder

Deploying Cisco Emergency Responder

Configuring a Local Route Group in a Wide Area Network Deployment

Understanding Enhanced 911 (E911)

Enhanced 911, or E911, is an extension of the basic 911 emergency call standard in North America. These topics describe E911 requirements and terminology.

Overview of Enhanced 911 Requirements

Understanding E911 and Cisco Emergency Responder Terminology

Overview of Enhanced 911 Requirements

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 simply needs to be routed to some PSAP, 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 simply 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 multi-line 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 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 7,000 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.

Related Topics

Understanding E911 and Cisco Emergency Responder Terminology

Understanding Cisco Emergency Responder

Understanding E911 and Cisco Emergency Responder Terminology

Table 1-1 defines some of the key terminology used in this document.

Table 1-1 E911 and Cisco Emergency Responder Terminology 

Term
Definition

ALI

Automatic location information. Information that ties an ELIN to a location, is used to route emergency calls from that ELIN to the correct local PSAP, and is presented to the PSAP to help the PSAP locate the emergency caller. In Emergency Responder, you fill in ALI data for each ERL and submit the ALI data to your service provider for inclusion in the ALI database.

ANI

Automatic number identification. ANI is another name for ELIN. This document uses ELIN instead of ANI.

CAMA

Centralized automated message accounting. An analog phone trunk that connects directly to an E911 selective router, bypassing the Public Switched Telephone Network (PSTN).

DID

Direct inward dial. A telephone number obtained from your service provider that can be used to dial into your telephone network. DID numbers are used for ELIN.

ELIN

Emergency location identification number. A phone number that routes the emergency call to the local PSAP, and which the PSAP can use to call back the emergency caller. The PSAP might need to call the number if the emergency call is cut off, or if the PSAP needs additional information after normally ending the emergency call. See ALI.

emergency call

A call made to the local emergency number, such as 911. Emergency Responder routes the call to the service provider's network, where the call is routed to the local PSAP.

emergency caller

The person who places the emergency call. The caller might require help for a personal emergency, or might be reporting a more general emergency (fire, theft, accident, and so forth).

ERL

Emergency response location. The area from which an emergency call is placed. The ERL is not necessarily the location of the emergency. If an emergency caller is reporting a general emergency, the actual emergency might be in a different area. In Emergency Responder, you assign switch ports and phones to ERLs, and ERL definitions include ALI data.

ESN

Emergency service number.

ESZ

Emergency service zone. The area covered by a given PSAP. This area usually includes several police and fire departments. For example, a city and its suburbs might be serviced by one PSAP.

Each ESZ is assigned a unique ESN to identify it.

MSAG

Master street address guide. A database of ALIs that enables proper routing of emergency calls to the correct PSAP. In Emergency Responder, you export your ALI definitions and transmit them to your service provider, who ensures the MSAG is updated. You must negotiate this service with your service provider—it is not a service provided directly through Emergency Responder.

NENA

National Emergency Number Association. The organization that recommends data and file formats for ALI definitions and other emergency call requirements in the United States. Emergency Responder uses the NENA formats for ALI data export files. Your service provider has additional restrictions on data format, so ensure that your ALI entries abide by your service provider's rules.

PSAP

Public safety answering point. The PSAP is the organization that receives emergency calls (for example, the 911 operator) and is staffed by people trained in handling emergency calls. The PSAP talks to the emergency caller and notifies the appropriate public service organizations (such as police, fire, or ambulance) of the emergency and its location.


Related Topics

Overview of Enhanced 911 Requirements

Understanding Cisco Emergency Responder

Understanding Cisco Emergency Responder

These topics provide an overview of Emergency Responder and how you can use it in your network:

Cisco Emergency Responder 8.6 Features

Network Hardware and Software Requirements

Licenses for Cisco Emergency Responder 8.6

How Cisco Emergency Responder Fits Into Your Network

What Happens When an Emergency Call Is Made

Understanding Cisco Emergency Responder Clusters and Groups

Determining the Required Number of Cisco Emergency Responder Groups

Data Integrity and Reliability Considerations

Cisco Emergency Responder 8.6 Features

This is the major new and enhanced features of Emergency Responder 8.6:

Chapter 4 "Configuring Cisco Emergency Responder 8.6".

See the Release Notes for Cisco Emergency Responder 8.6 for a list of hardware and software supported in Emergency Responder 8.6.

Network Hardware and Software Requirements

Emergency Responder 8.6 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 8.6 located at http://www.cisco.com/en/US/products/sw/voicesw/ps842/prod_release_notes_list.html.

Licenses for Cisco Emergency Responder 8.6

Emergency Responder 8.6 uses a web-based system for requesting, creating, and delivering product licenses. Once you register your Emergency Responder product through the Cisco.com website, a file containing the server license is sent to you as a text-file email attachment.

This section describes the following topics:

Licenses for Initial Installation or Upgrades

Server Licenses

User Licenses

Determining Your License Requirements

Licenses for Initial Installation or Upgrades

Emergency Responder 8.6 does not require a license key for initial installation or to perform an upgrade. New server licenses must be installed within 60 days of a new installation or upgrade from Emergency Responder 7.1. Upgrades from Emergency Responder 8.0 or later do not require new server licenses. Unlicensed Emergency Responder 8.6 software operates normally for 60 days after it is installed, with a capacity of 100 phones. Additional user licenses are not effective until a server license is installed. If you do not install a server license within 60 days, the Emergency Responder 8.6 system shuts down.

Server Licenses

You must order server software to obtain server licenses for each Emergency Responder server in a server group. A single license file may contain a license for both Emergency Responder publisher and subscriber, or a separate license file for the Emergency Responder subscriber may be installed on the Emergency Responder publisher at a later time. You must use the MAC-address of the ethernet card on the publisher server to generate a license for the Publisher and Subscriber. Do not use the MAC address of the Emergency Responder subscriber.

To order Emergency Responder server licenses, follow these steps:

Procedure


Step 1 Order Emergency Responder 8.6 using your preferred ordering method. You will receive a Product Authorization Key (PAK) along with Emergency Responder 8.6.

Step 2 Go to https://tools.cisco.com/SWIFT/Licensing/PrivateRegistrationServlet and register your Emergency Responder by supplying the PAK and the Media Access Control (MAC) address of the publisher Emergency Responder server. Do not use the MAC address of the Emergency Responder subscriber.

To obtain the MAC address of the publisher Emergency Responder server, follow these steps:

a. Log in to the Cisco Unified OS Administration website.

b. Go to Show > Network.

c. The MAC address displays in the Ethernet Details section.

After processing, you receive the server license file as a text-file email attachment.


Note For VMware installs, please use HOSTNAME=<License MAC> instead of <Hardware MAC> to generate a license file.


Step 3 Save the server license file to a local server so that it can be uploaded to the Emergency Responder server.

Step 4 Upload the server license file using the Emergency Responder Administration web interface. See the "Uploading the Cisco Emergency Responder License File" section for instructions on how to upload the server license file.


User Licenses

User licenses are normally installed on primary Emergency Responder server, but user licenses are shared by both primary and secondary Emergency Responder servers irrespective of where they are installed.

The total number of user licenses available in a server group at is the sum of the user licenses available on both servers in the server group.

You must purchase user licenses for every endpoint controlled by every Cisco Unified CM cluster supported by Emergency Responder, including hard IP phones, IP softphones, and analog phones. Licensing only some of the endpoints in a Cisco Unified CM cluster is not supported.

To order additional or upgraded Emergency Responder user licenses, perform these steps:

Procedure


Step 1 Order additional or upgraded user licenses. You will receive a Product Authorization Key (PAK) for each additional user license.

Step 2 Go to Cisco.com and register your Emergency Responder by supplying the PAK and the Media Access Control (MAC) address of the primary Emergency Responder server. User licenses are installed on the primary Emergency Responder server. Do not use the MAC address of the Emergency Responder subscriber.


Note For VMware installs, please use HOSTNAME=<License MAC> instead of <Hardware MAC> to generate a license file.


After processing, you receive the user license as a text-file email attachment.

Step 3 Save the user license file to a local server so that it can be uploaded to the primary Emergency Responder server.

Step 4 Upload the user license file. See the "Uploading the Cisco Emergency Responder License File" section for instructions on how to upload the user licenses.



Note From Emergency Responder 8.0 onwards, the license files can only be uploaded on the primary server.



Note From Emergency Responder 8.0 onwards, Server licenses do not include implicit licensing. User license needs to be purchased explicitly.


Determining Your License Requirements

For server licenses:

Order server software to obtain server licenses for each server, primary and secondary, in an Emergency Responder group. You can order two copies of server software together to obtain a single server license for the server group with a node count of two. You can add a secondary server to an existing Emergency Responder group by ordering an additional copy of Emergency Responder software separately.

All the server licenses are based on the Media Access Control (MAC) address of the primary Emergency Responder server. Do not use the MAC address of the Emergency Responder subscriber.

You cannot share a server license between the Publisher server and the Subscriber server. You must order a separate copy of the Emergency Responder software to add a secondary server to an existing Emergency Responder group.

For user licenses:

Order one or more (as required) user license for each Emergency Responder group.

User licenses can be shared between Publisher and Subscriber servers within each Emergency Responder group.

You cannot share Emergency Responder user licenses between different Emergency Responder groups in an Emergency Responder cluster, or between different Emergency Responder clusters. (See the "Understanding Cisco Emergency Responder Clusters and Groups" section for more information about clusters.)

Example

If your Emergency Responder configuration supports 500 users, you must purchase:

One copy of Emergency Responder software to obtain a server license for your Emergency Responder Publisher server.

One copy of Emergency Responder software to obtain a server license for your Emergency Responder Subscriber server. This license is based on the Media Access Control (MAC) address of the primary Emergency Responder server.

Purchase user license for up to 500 users.

You can order two copies of Emergency Responder software together to obtain a single server license for the server group with a node count of two. You can add a secondary server to an existing Emergency Responder group by ordering an additional copy of Emergency Responder software separately.

Uploading License Files

You can upload license files to the Emergency Responder servers using the Emergency Responder Administration web interface. All license files must only be uploaded from the Publisher server when it is up and running. To upload license files, follow these steps:

Procedure


Step 1 Log in to the Emergency Responder Administration website.

Step 2 Select System > License Manager. The License Manager page appears.

Step 3 Click Upload license. The Upload File page appears.

Step 4 Use the Browse... button to select the license file to upload from your local system.

Step 5 Click Upload. The selected license file is uploaded to the Emergency Responder server.



Note From Emergency Responder 8.0 onwards, a server license can only be uploaded from the primary Emergency Responder server.


Related Topics

License Manager

How Cisco Emergency Responder Fits Into Your Network

Figure 1-1 shows how Cisco Emergency Responder (Emergency Responder) fits into your network.

Figure 1-1 How Cisco Emergency Responder Fits Into Your Network

Emergency Responder depends on Cisco Unified Communications Manager for the corporate dial plan, which you must modify to send emergency calls to the Emergency Responder group. See Chapter 3 "Configuring Cisco Unified Communication Manager Versions 6.1 and Later for Cisco Emergency Responder 8.6" for complete information about the required Cisco Unified Communications Manager configuration.

To track phones, Emergency Responder queries Cisco Unified Communications Manager for a list of phones registered with the cluster. Then, Emergency Responder queries the switches on the network (the ones you identified to Emergency Responder) to determine the port to which the phones are connected. Emergency Responder does this tracking at regular intervals during the day so that it can identify when a phone moves. See the "Configuring Switches for Cisco Emergency Responder" section for more information about setting up switches for Emergency Responder. See the "Managing Phones" section for information about configuring switch ports so that Emergency Responder can send emergency calls to the correct PSAP based on port and phone location.

Optionally, you can have an SMTP email server in your network or with a service provider. You can configure Emergency Responder to send email to your onsite alert (security) personnel to notify them of emergency calls. If the server is set up as an email-based paging service, the personnel are paged.

Finally, you 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-1 shows one Emergency Responder group supporting a single Cisco Unified Communications Manager cluster. You can support more than one Cisco Unified Communications Manager cluster with a single Emergency Responder group, as long as the Cisco 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 the "Understanding Cisco Emergency Responder Clusters and Groups" section for a discussion of this installation.

See the "What Happens When an Emergency Call Is Made" section for an explanation of the path an emergency call takes when managed by Emergency Responder.

Related Topics

Understanding Cisco Emergency Responder Clusters and Groups

Determining the Required Number of Cisco Emergency Responder Groups

Deploying Cisco Emergency Responder

What Happens When an Emergency Call Is Made

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

Figure 1-2 illustrates how Emergency Responder routes an emergency call.

Figure 1-2 How Cisco Emergency Responder Routes Emergency Calls

When someone uses extension 3003 to make an emergency call:

1. Cisco Unified Communications 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 the "Cisco Emergency Responder Call Routing Order" section 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 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 (see the "Cisco Emergency Responder Group Settings" section).

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 routing the call correctly lies with the ELIN definition. If you assign the ELINs route pattern to the wrong gateway, the emergency call can be routed to the wrong network. This can send the emergency call to the wrong PSAP.

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, the emergency call network is tandem to the PSTN, so simply 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 reachs the third caller, not the first caller. The likelihood of this problem arising depends on how many ELINs you define for an ERL and the typical rate of emergency calls in the ERL.

Cisco Emergency Responder Call Routing Order

Emergency Responder directs emergency calls based on the location of the phone from which the call is placed. The location of the phone is determined by the following methods, in order of precedence:

Synthetic phones—The MAC address of the phone matches that of a synthetic phone and is assigned to a test Emergency Response Location (ERL). See the "Adding Synthetic Phones" section and the "Configuring Test ERLs" section.

IP Phones tracked behind a switch port—The MAC address of the IP phone is tracked behind a switch port assigned to an ERL. See the "Configuring Switch Ports" section.

IP Phones tracked using IP subnet—The IP address of an IP phone belongs to an IP subnet assigned to an ERL. See the "Configuring IP Subnet-based ERLs" section.

IP Phones tracked by another (remote) Emergency Responder server group in the same Emergency Responder cluster—The remote server group tracks an IP phone behind a switch port or by IP subnet. When an emergency call is received, it is forwarded to the Cisco Unified Communications Manager cluster served by the remote Emergency Responder server group. See the "Phones Moving Between Clusters" section.

Manually configured phones—The line number of the phone is manually assigned to an ERL. See the "Manually Defining a Phone" section.

Unlocated Phones—The MAC address of an IP phone is assigned to an ERL. See the "Identifying Unlocated Phones" section.

Default ERL—None of the preceding criteria is used to determine the phone location. The call is routed to the default ERL. See the "Setting Up the Default ERL" section.


Note MAC or IP address tracking is recommended for Cisco Unified IP Phones. IP phones which are not tracked by MAC or IP address appear as unlocated phones, even if they are assigned a location by manual line number configuration.



Note Manually configured phones can not be assigned a location by Emergency Responder based on a line number that includes a leading "+". If you want Emergency Responder to assign locations to analog telephones based on line number, do not configure them with a leading "+" on Cisco Unified CM.


Customers should resolve problems that prevent IP phones from being tracked by MAC or IP address (see the "Too Many Unlocated Phones" section) so that IP phones are not removed from the Unlocated Phones page. An ERL may be assigned directly to an IP phone on the Unlocated Phones page, but this assignment does not take effect if the phone is assigned a location by manual line number configuration. Use the ERL Debug Tool to determine the ERL assignment in effect for an IP phone that appears on the Unlocated Phones page.

Identifying Unlocated Phones

Emergency Responder defines unlocated phones as those Cisco Unified IP Phones which meet all of the following criteria:

The IP phone is registered to a Cisco Unified Communications Manager known to the Emergency Responder group.

The MAC address of the IP phone is not tracked behind a switch port.

The IP address of the IP phone is not tracked using IP subnets.

The MAC address of the IP phone is not defined as a synthetic phone in Emergency Responder.


Note Cisco Unified IP Phones tracked by a remote Emergency Responder server group and IP phones having line numbers manually assigned to an ERL also appear in the Unlocated Phones screen.


Assigning ERLs to Unlocated Phones

Emergency Responder provides a procedure to assign an ERL to IP phones that are displayed on the Unlocated Phones screen. This assignment associates the MAC address of the unlocated phone with an ERL that is selected by the administrator. These rules apply to this association:

The association of an ERL with an IP phone on the Unlocated Phones page does not change the status of the IP phone; it remains on the Unlocated Phones page due to the fact that the IP phone continues to match the criteria for unlocated phones described previously.

The ERL association is used only when the IP phone is unlocated, as determined by Emergency Responder, using the preceding rule.

For example, Phone A is currently unlocated and appears on the Unlocated Phones page. Using the ERL assignment feature for unlocated phones, Location A is assigned as the ERL for this phone. A subsequent phone tracking cycle finds Phone A behind a switch port and it no longer appears in the Unlocated Phones page. The Phone A-to-Location-A assignment is no longer valid. Because the association is persistent, if the IP phone is unlocated at any future time, the assignment is valid.

Location Information for Calls Forwarded by CTI Applications

If emergency calls are forwarded to 911 by computer telephony integration (CTI) applications, such as Cisco Unity, then the location used for call routing and PSAP reporting is the location of the application server, not the location of the original caller. This remains true even if the application retains the original calling line number, as is made possible in Cisco Unified CM 4.2(3) and 4.3, and in Cisco Unified CM 5.1, 6.0, and 6.1. For this reason, you should dial 911 directly.

Related Topics

Understanding E911 and Cisco Emergency Responder Terminology

Data Integrity and Reliability Considerations

Understanding ERLs

Creating ERLs, page 4-32

Configuring the Calling Search Space for the Gateways Used to Connect to the PSAP

Preparing Your Network For Cisco Emergency Responder

Understanding Cisco Emergency Responder Clusters and Groups

Deploy Cisco Emergency Responder (Emergency Responder) in your network as a pair of redundant servers. One server is designated as the Publisher server and the other as the Subscriber server. Each Emergency Responder Publisher server and Subscriber server make up an Emergency Responder Server Group. Configuration data for the server groups is stored in a database on the Publisher. This data is replicated to the Subscriber.

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 8.6 uses two separate databases:

One database stores Emergency Responder configuration information.

The second database 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 Emergency Responder 8.6, make sure to upgrade both Emergency Responder servers to version 8.6. If phones registered with Cisco Unified CM 8.5 or 8.6 are configured with EnergyWise Power Save Plus mode, then all the Emergency Responder Server Groups in Cluster need to be Emergency Responder 8.6 since earlier versions of Emergency Responder do not support EnergyWise. Major discovery in Emergency Responder 8.6 does not purge phones that are in EnergyWise Power Save Plus mode.


Figure 1-3 shows how Cisco Emergency Responder (Emergency Responder) groups can be joined in a single Emergency Responder cluster.

Figure 1-3 Understanding the Relationship between Cisco Emergency Responder Groups and Cisco Emergency Responder Clusters

In this example:

There are two Cisco Unified Communications Manager clusters, Cisco Unified CM cluster A and Cisco 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 Cisco Unified CM cluster A and Emergency Responder Server Group 2 supports Cisco 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, a 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 e-mail account in the System Administrator Mail ID field when you configure the Emergency Responder Server Group Settings, the system administrator receives an e-mail notification when the standby server handles a call or when the standby server takes over for the primary server. (See the "Configuring a Cisco Emergency Responder Server Group" section.)


To complete the creation of the Emergency Responder cluster, you must create inter-cluster trunks and route patterns to allow the Emergency Responder groups to hand off emergency calls between the groups (see the "Creating Route Patterns for Inter-Cisco Emergency Responder Group Communications" section) and configure these route patterns in Emergency Responder (see the "Configuring Group Telephony Settings For the Cisco Emergency Responder Server" section).


Caution Before you create a 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.


Caution Users on a E.164 dials plan should be aware that the Cisco Emergency Responder is not designed for use with digit strings including + as the leading digit.

Moving Phone Between Clusters

The following scenario illustrates how Emergency Responder treats phones moving between clusters:

Server Group A (SGA) has a phone (Phone_1) that is moving out of SGA.

Emergency Responder discovers Phone_1 in Server Group B (SGB).

The Unlocated Phones page in SGA displays the phone in SGB.

If both the Emergency Responder servers (Publisher and Subscriber) in SGB go down, SGA still displays Phone_1 in SGB.

Calls made from Phone_1 during this time are redirected to SGB and Emergency Responder takes the same steps to route this emergency call when Emergency Responder servers are not there in SGB.

Phone_1 is also treated like any other phone in SGB when both the SGB Emergency Responder servers are down.

If Phone_1 moves to Server Group C (SGC):

It is discovered after the next incremental phone tracking on SGA and then in SGC.

The Unlocated Phones page changes the association of Phone_1 to SGC.

If Phone_1 moves back to SGA, it is discovered in the next incremental phone tracking and displayed under the corresponding switch port.

Be aware of the following when planning your Emergency Responder system:

A single Emergency Responder group cannot support clusters with a mix of Cisco Unified Communications Manager versions. For example, Emergency Responder can support all Cisco Unified Call Manager 4.2 clusters or all Cisco Unified Call Manager 5.1 clusters.

However, a Emergency Responder cluster can contain Emergency Responder groups that support different versions of Cisco Unified Communications Manager. In this way, Emergency Responder can support a mix of Cisco Unified Communications Manager versions in your telephony network.

A Emergency Responder 86 server group can operate with other Emergency Responder 8.6 server groups or with Emergency Responder 1.3 server groups.


Note If you make an emergency call from a Cisco Unified IP Phone using a shared line, the call may terminate on an incorrect ERL across the cluster.



Note Moving of phones discovered and associated with an ERL to a different Cisco Unified CM cluster, tracked by a different Emergency Responder Server Group belonging to the same Emergency Responder cluster, requires the deletion of the ERLs association from the current Emergency Responder Server Group. See Step 7 of Identifying Unlocated Phones to unassign an ERL from the current Emergency Responder Server Group.


Related Topics

How Cisco Emergency Responder Fits Into Your Network

What Happens When an Emergency Call Is Made

Determining the Required Number of Cisco Emergency Responder Groups

To ensure efficient Cisco ER performance, you should take into account the limits each Emergency Responder group can support when planning your Emergency Responder deployment. Keep in mind that a single Cisco Unified Communications Manager cluster can only be supported by one Emergency Responder group, although a single Emergency Responder group can support more than one Cisco Unified Communications Manager cluster.

See the Release Notes for Cisco Emergency Responder 8.6 for the capacities of a single Emergency Responder group with your configuration. Be aware that you might meet the maximum figures for one limitation without reaching the figures for another. For example, you might define 1,000 switches, but have fewer than 30,000 switch ports.

You can install additional groups to manage larger networks. Each Emergency Responder group can work with one or more Cisco Unified Communications Manager clusters.

In addition to these per group limits, you must also consider the territories covered by the service provider's ALI database providers. If your network extends into more than one ALI database provider's territory, you should use the ALI Formatting Tool (AFT) to export ALI records in multiple ALI database formats.

To have a single Emergency Responder group support multiple LECs, follow these steps:

Procedure


Step 1 Obtain an ALI record file output from Emergency Responder in standard NENA format. This file contains the records destined for multiple LECs.

Step 2 Make a copy of the original file for each required ALI format (one copy per LEC).

Step 3 Using the AFT of the first LEC (for example, LEC-A), load a copy of the NENA-formatted file and delete the records of all the ELINs associated with the other LECs. (For information about using the AFT, see Chapter 12 "Using the ALI Formatting Tool.") The information to delete can usually be identified by NPA (or area code).

Step 4 Save the resulting file in the required ALI format for LEC-A, and name the file accordingly.

Step 5 Repeat steps 3 and 4 for each LEC.


If AFTs are not available for each LEC, you can achieve a similar result by editing the NENA-formatted files with a text editor.

Related Topics

Understanding Cisco Emergency Responder Clusters and Groups

Deploying Cisco Emergency Responder

Negotiate ALI Submission Requirements With Your Service Provider

Exporting ALI Information for Submission to Your Service Provider

Chapter 12 "Using the ALI Formatting Tool"

ALI Formatting Tool

Data Integrity and Reliability Considerations

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. Thus, your ERL configuration must be reliable so that the correct ELIN is assigned to the emergency call.

These are the things to consider 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. Thus, 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 the "Manually Defining a Phone" section for information about defining these types of phones.


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


Before Emergency Responder 1.2, if registered phones were not found behind a switch port, Emergency Responder would list the phone in the Unlocated Phones page.

Emergency Responder 1.2 and later locates these phones as follows:

If a registered phone is not found behind a switch port, it may be found 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 the "Using the Cisco Emergency Responder Admin Utility" section.

When you install Emergency Responder 8.6, 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 ER 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 the "Identifying the LAN Switches" section 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 the "Understanding the Network Administrator Role" section and the "Understanding the ERL Administrator Role" section 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 the "Exporting ERL Information" section and "Exporting ALI Information for Submission to Your Service Provider" section for more information.

Related Topics

What Happens When an Emergency Call Is Made

Understanding Cisco Emergency Responder Clusters and Groups

Determining the Required Number of Cisco Emergency Responder Groups

Preparing Users for Cisco Emergency Responder

Preparing Your Network For Cisco Emergency Responder

These topics describe the steps you should take to prepare your network before deploying Cisco Emergency Responder.

Obtain CAMA or PRI Trunks to the PSTN

Obtain DID Numbers from Your Service Provider

Negotiate ALI Submission Requirements With Your Service Provider

Upgrade Switches and Phones

Obtain CAMA or PRI Trunks to the PSTN

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

Related Topics

Configuring the Calling Search Space for the Gateways Used to Connect to the PSAP

Obtain DID Numbers from Your Service Provider

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. Thus, if four people make emergency calls in the space of an hour, if the PSAP calls the ELIN, the PSAP connects to the last caller. This 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 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.


Related Topics

Creating ERLs, page 4-32

Creating ERLs

Negotiate ALI Submission Requirements With Your Service Provider

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.


Related Topics

Understanding ERLs

Overview of ERL Management

Creating ERLs

Exporting ERL Information

Upgrade Switches and Phones

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. This can reduce the cost of maintaining your telephone network, simplifying moves, adds, or changes.

However, Emergency Responder can only 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" section 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.

Related Topics

Configuring Switches for Cisco Emergency Responder

Managing Phones

Preparing Your Staff for Cisco Emergency Responder

Emergency Responder does not replace your existing emergency procedures. Instead, Emergency Responder is a tool you can use to augment those procedures. Before deploying Emergency Responder, consider how it fits into your procedures and how you want to use the Emergency Responder system's capabilities.

These are the main things to consider when deciding how to use Emergency Responder:

When someone makes an emergency call, Emergency Responder notifies the assigned onsite alert (security) personnel (your emergency response teams) of the location of the caller. This information is, for the most part, the ERL name. Consider working with your emergency response teams to come up with an ERL naming strategy that helps them respond quickly to emergencies. Incorporating building names, floor numbers, and other readily understood location information in the name are the types of things to consider.

Emergency Responder lets you define three types of administrative user, so you can divide responsibilities for overall Emergency Responder system administration, network administration, and ERL administration. The skills and knowledge necessary for these tasks might be rare to find in one person. Consider dividing Cisco ER configuration responsibilities according to these skills.

The routing of emergency calls, and the transmission of the correct ALI, is only as good as the reliability of the ALI definitions you submit to your service provider and in the stability of your network topology. Ensure that your ERL administrator understands the importance of keeping the ALI data up-to-date, and that your network administrator understands the importance of maintaining a stable network. See the "Data Integrity and Reliability Considerations" section for more information about maintaining data integrity.

Related Topics

Preparing Onsite Alert (Security) Personnel for Cisco Emergency Responder

Understanding the ERL Administrator Role

Understanding the Network Administrator Role

Understanding the Cisco Emergency Responder System Administrator Role

Deploying Cisco Emergency Responder

These topics describe deployment models for various types of networks. You can use these examples as modules, combining them to form a larger, more complex network.

Deploying Cisco Emergency Responder in One Main Site with One PSAP

Deploying Cisco Emergency Responder in One Main Site with Two or More PSAPs

Deploying Cisco Emergency Responder In One Main Site with Satellite Offices

Deploying Cisco Emergency Responder In One Main Site Serving Two or more Sites

Deploying Cisco Emergency Responder In Two Main Sites

Deploying Cisco Emergency Responder in One Main Site with One PSAP

To support a simple telephony network consisting of a single Cisco Unified Communications Manager 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.

Figure 1-4 shows how Emergency Responder fits into a simple telephony network with a single Cisco Unified Communications Manager cluster.

Figure 1-4 Deploying Cisco Emergency Responder in One Main Site with One PSAP

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

Deploying Cisco Emergency Responder in One Main Site with Two or More PSAPs

Deploying Cisco Emergency Responder In One Main Site with Satellite Offices

Deploying Cisco Emergency Responder In One Main Site Serving Two or more Sites

Deploying Cisco Emergency Responder In Two Main Sites

Related Topics

What Happens When an Emergency Call Is Made

How Cisco Emergency Responder Fits Into Your Network

Determining the Required Number of Cisco Emergency Responder Groups

Installing Cisco Emergency Responder 8.6 on a New System

Configuring Cisco Unified Communication Manager Versions 6.1 and Later for Cisco Emergency Responder 8.6

Deploying Cisco Emergency Responder in One Main Site with Two or More PSAPs

Figure 1-5 illustrates the Emergency Responder configuration with one main site that is served by two or more PSAPs. This example assumes you have one Cisco Unified Communications Manager cluster. If you have more than one, the setup is logically the same as the one discussed in the "Deploying Cisco Emergency Responder In Two Main Sites" section.

Figure 1-5 Deploying Cisco Emergency Responder in One Main Site with Two or More PSAPs

To support this type of network, install two Cisco ER 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 you need two gateways. Of course, 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, Cisco ER 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:

Deploying Cisco Emergency Responder in One Main Site with One PSAP

Deploying Cisco Emergency Responder In One Main Site with Satellite Offices

Deploying Cisco Emergency Responder In One Main Site Serving Two or more Sites

Deploying Cisco Emergency Responder In Two Main Sites

Related Topics

What Happens When an Emergency Call Is Made

How Cisco Emergency Responder Fits Into Your Network

Determining the Required Number of Cisco Emergency Responder Groups

Installing Cisco Emergency Responder 8.6 on a New System

Configuring Cisco Unified Communication Manager Versions 6.1 and Later for Cisco Emergency Responder 8.6

Deploying Cisco Emergency Responder In One Main Site with Satellite Offices

Figure 1-6 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 Cisco Unified Communications Manager cluster on the main site. If the satellite office has its own Cisco Unified Communications Manager cluster, see the "Deploying Cisco Emergency Responder In Two Main Sites" section.

Figure 1-6 Deploying Cisco Emergency Responder in One Main Site with Satellite Offices


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 Cisco ER 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. Thus, 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 you need two gateways. Of course, 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, Cisco ER 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. Cisco ER 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 the "Configuring the SNMP Connection" section for more information.

See these examples to extend this example to other networks:

Deploying Cisco Emergency Responder in One Main Site with One PSAP

Deploying Cisco Emergency Responder in One Main Site with Two or More PSAPs

Deploying Cisco Emergency Responder In One Main Site Serving Two or more Sites

Deploying Cisco Emergency Responder In Two Main Sites


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 Cisco ER in the main office.


Related Topics

What Happens When an Emergency Call Is Made

How Cisco Emergency Responder Fits Into Your Network

Determining the Required Number of Cisco Emergency Responder Groups

Installing Cisco Emergency Responder 8.6 on a New System

Configuring Cisco Unified Communication Manager Versions 6.1 and Later for Cisco Emergency Responder 8.6

Deploying Cisco Emergency Responder In One Main Site Serving Two or more Sites

Figure 1-7 illustrates the Emergency Responder configuration with two or more main sites that are served by two or more PSAPs with one Cisco Unified CM cluster per site.

Figure 1-7 Deploying Emergency Responder in One Main Site Serving Two or More Sites

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 you need one gateways per site. Of course, 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 Cisco 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 Cisco Unified CM Clusters.

Emergency Responder in One Site Serving Two or more sites with EMCC

Using Extension Mobility Cross Cluster (EMCC) between two Cisco Unified CM clusters enables Emergency Responder to provide enhanced support for 911 calls.

Figure 1-7 illustrates how the Emergency Responder is deployed at one site and serves two or more site with the Cisco Unified CM in each site.

In this scenario, the Emergency Responder server is shared by both- an EMCC user's home cluster and the visiting Cisco Unified CM cluster. For Emergency Responder to process, a 911 call is made by an EMCC logged in user, the home Cisco Unified CM cluster must not use an Adjunct Calling Search Space (CSS) to direct the 911 call to the user's visiting cluster.

Instead, the shared Emergency Responder servers supporting both the clusters processes the 911 call in the user's home cluster.

See these examples to extend this example to other networks:

Deploying Cisco Emergency Responder in One Main Site with One PSAP

Deploying Cisco Emergency Responder in One Main Site with Two or More PSAPs

Deploying Cisco Emergency Responder In One Main Site with Satellite Offices

Deploying Cisco Emergency Responder In Two Main Sites

Related Topics

What Happens When an Emergency Call Is Made

How Cisco Emergency Responder Fits Into Your Network

Determining the Required Number of Cisco Emergency Responder Groups

Installing Cisco Emergency Responder 8.6 on a New System

Configuring Cisco Unified Communication Manager Versions 6.1 and Later for Cisco Emergency Responder 8.6

Deploying Cisco Emergency Responder In Two Main Sites

Figure 1-8 illustrates the Emergency Responder configuration with two (or more) main sites, each served by a separate PSAP.

Figure 1-8 Deploying Cisco Emergency Responder in Two Main Sites

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 the "Deploying Cisco Emergency Responder In One Main Site with Satellite Offices" section for information about deploying Cisco ER in those offices.

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

Install two Cisco ER 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 Cisco ER Publisher server in the Chicago Cisco ER group for use as the cluster database. See "8.6 Cisco Emergency Responder Cluster and Cluster DB Host" section.

Install two Cisco ER 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 Cisco ER Publisher server in the Chicago Cisco ER group for use as the cluster database. See "8.6 Cisco Emergency Responder Cluster and Cluster DB Host" section.

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. Of course, 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 Cisco Unified Communications Manager clusters, and create an inter-Cisco ER group route pattern so that Cisco ER can transfer calls between Cisco Unified Communications Manager clusters served by separate Cisco ER groups. The "Creating Route Patterns for Inter-Cisco Emergency Responder Group Communications" section goes into more details about how Cisco ER handles phone movement in this situation.

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

Deploying Cisco Emergency Responder In Two Main Sites as Emergency Responder Cluster with EMCC

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

Figure 1-8 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 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 via Inter Cluster Trunk (ICT) between the two Cisco Unified CM clusters and the visiting Emergency Responder routes the call to appropriate PSAP.


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


See these examples to extend this example to other networks:

Deploying Cisco Emergency Responder in One Main Site with One PSAP

Deploying Cisco Emergency Responder in One Main Site with Two or More PSAPs

Deploying Cisco Emergency Responder In One Main Site with Satellite Offices

Deploying Cisco Emergency Responder In One Main Site Serving Two or more Sites

Related Topics

What Happens When an Emergency Call Is Made

How Cisco Emergency Responder Fits Into Your Network

Determining the Required Number of Cisco Emergency Responder Groups

Installing Cisco Emergency Responder 8.6 on a New System

Configuring Cisco Unified Communication Manager Versions 6.1 and Later for Cisco Emergency Responder 8.6

Deploying Cisco Emergency Responder In Two Main Sites as Emergency Responder Cluster with Adjunct CSS Configuration

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

Figure 1-8 illustrates the Emergency Responder configuration with two (or more) main sites, each served by a separate PSAP.

In this scenario, the two clusters are configured for EMCC. The two Cisco Unified CM cluster have different emergency patterns and thus an adjunct CSS must be configured. When a emergency call is made by an EMCC logged in user, the call is re-directed from the home cluster to the visiting Cisco Unified CM cluster and then offered to Emergency Responder group in the user's visiting cluster.

The visiting Emergency Responder group in the user's visiting cluster takes care of routing the call to the appropriate PSAP.


Note The Cisco Unified CM clusters must have adjunct CSS configured if home cluster and visiting cluster do not share the same emergency pattern. The previous use case, without Adjunct CSS configuration, may be used if the home cluster and visiting cluster share the same emergency pattern.


See these examples to extend this example to other networks:

Deploying Cisco Emergency Responder in One Main Site with One PSAP

Deploying Cisco Emergency Responder in One Main Site with Two or More PSAPs

Deploying Cisco Emergency Responder In One Main Site with Satellite Offices

Deploying Cisco Emergency Responder In One Main Site Serving Two or more Sites

Related Topics

What Happens When an Emergency Call Is Made

How Cisco Emergency Responder Fits Into Your Network

Determining the Required Number of Cisco Emergency Responder Groups

Installing Cisco Emergency Responder 8.6 on a New System

Configuring Cisco Unified Communication Manager Versions 6.1 and Later for Cisco Emergency Responder 8.6

Configuring a Local Route Group in a Wide Area Network Deployment

With an Emergency Responder and Cisco Unified Communications Manager deployment that spans multiple locations over a Wide Area Network (WAN), you may want to configure a Local Route Group (LRG) to ensure that users can make emergency calls if the connection between Emergency Responder and Cisco Unified Communications manager goes down.

To configure LRG, follow these steps:

1. On Cisco Unified Communications Manager Administration, configure the LRG route pattern and route point for 911 emergency call routing.

2. On Cisco Unified Communications Manager Administration, configure any destination route point that is being forwarded in the emergency call route point with the LRG route pattern.

3. On Emergency Responder Administration, configure the LRG route pattern as the default ERL.

While there is a communication failure between Emergency Responder and Cisco Unified Communications Manager, the following Emergency Responder features are not supported:

Onsite Alerts

Web Alerts

Email Alerts

PSAP callback

Device Mobility.

To support device mobility, you must configure device mobility in Cisco Unified Communications Manager to route 911 call to the new LRG location when the phones are moved from one location to another.

Related Topics

What Happens When an Emergency Call Is Made

How Cisco Emergency Responder Fits Into Your Network

Determining the Required Number of Cisco Emergency Responder Groups

Installing Cisco Emergency Responder 8.6 on a New System

Configuring Cisco Unified Communication Manager Versions 6.1 and Later for Cisco Emergency Responder 8.6