Cisco Emergency Responder Administration Guide 1.2(3)
Planning for Cisco Emergency Responder
Downloads: This chapterpdf (PDF - 543.0KB) The complete bookPDF (PDF - 2.59MB) | Feedback

Planning for Cisco Emergency Responder

Table Of Contents

Planning for Cisco Emergency Responder

Understanding Enhanced 911 (E911)

Overview of Enhanced 911 Requirements

Understanding E911 and Cisco Emergency Responder Terminology

Understanding Cisco Emergency Responder

Cisco Emergency Responder

Cisco Emergency Responder Features

Cisco Emergency Responder 1.2(1) Enhancements

Cisco Emergency Responder 1.2(2) Enhancements

Cisco Emergency Responder 1.2(3) Enhancements

Network Hardware and Software Requirements

Cisco Emergency Responder 1.2(x) Licenses

License Keys for Cisco Emergency Responder

Determining Your License Requirements

How Cisco Emergency Responder Fits Into Your Network

What Happens When an Emergency Call Is Made

Cisco Emergency Responder's Call Routing Order

Understanding Cisco Emergency Responder Clusters and Groups

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 Two Main Sites


Planning for Cisco Emergency Responder


Cisco Emergency Responder (Cisco ER) 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 might have similar ordinances.

Because emergency call ordinances can differ from location to location within a country, region, state, or even metropolitan area, Cisco ER includes the flexibility you need to 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 need to do extensive planning and research before you can deploy Cisco ER in a manner that fits your legal and security needs.

Cisco Emergency Responder 1.2(3) is introduced to enable Cisco Emergency Responder to work with Cisco CallManager 4.1(2).

These topics help you understand emergency call ordinances, how Cisco ER helps you meet the ordinances, and what you need to do to deploy Cisco ER 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

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.

In 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 is responsible for talking to the caller and arranging 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's location information must be displayed at the emergency operator's 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 for any reason, 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, and is used to route emergency calls from that ELIN to the correct local PSAP. Information that is presented to the PSAP to help the PSAP locate the emergency caller. In Cisco Emergency Responder (Cisco ER), 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 PSTN.

DID

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

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. Cisco ER routes the call to the service provider's network, where the call is routed to the local public safety answering point (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. This 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 Cisco ER, you assign switch ports and phones to ERLs, and ERL definitions include ALI data.

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 emergency service number (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 Cisco ER, 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 Cisco ER.

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. Cisco ER uses the NENA formats for ALI data export files. Your service provider might have additional restrictions on data format, so ensure that your ALI entries abide by your service provider's rules.

PSAP

Public safety answering point. This is the organization that receives emergency calls, for example, the 911 operator. The PSAP 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 Cisco Emergency Responder and how you can use it in your network.

Cisco Emergency Responder

Network Hardware and Software Requirements

Cisco Emergency Responder 1.2(x) Licenses

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

The following sections provide information on the features of Cisco Emergency Responder (Cisco ER.)

Cisco Emergency Responder Features

Cisco Emergency Responder 1.2(1) Enhancements

Cisco Emergency Responder 1.2(2) Enhancements

Cisco Emergency Responder 1.2(3) Enhancements

Cisco Emergency Responder Features

These are the major features of Cisco Emergency Responder (Cisco ER):

Compatibility with any emergency number, for example, 911 in North America, 999 in the United Kingdom, 112 in much of Europe, and so forth.

Ability to automatically track movement of many types of phones and to update the ERL of the moved phones without requiring manual intervention. This ensures that emergency calls are routed to the local PSAP even if a phone moves between cities, states, or even countries, and that the correct ALI is presented to the PSAP operator.

Extensive import/export capabilities to help simplify data entry and update.

Four levels of user authority, so that you can assign configuration responsibilities to the required people without exposing all parts of the configuration.

Server redundancy, so that the loss of one server does not disable your emergency call system.

Clustering capability, so that servers can hand calls off to other locations if another location needs to route a call to the PSAP. This allows phone movement between office buildings served by separate phone systems.

Emergency call logging, so that you can track the locations and frequency of emergency calls made on your network.

Real-time onsite security alerting, so that onsite personnel are notified when someone makes an emergency call. Personnel are called with information about the extension of the emergency caller, and they are sent a real-time web-based alert with detailed information about the caller's location. If you configure an email address, they are also sent an email. If the email address is for an email-based pager, they are paged.

Emergency response location (ERL) management:

Ability to create ERLs of any size, from one individual office to as large as you want. This lets you define ERLs that fit your needs and that meet the requirements of your local ordinances.

Ability to export automatic location information (ALI) in a variety of formats, so that you can transmit the ALI to your service provider in the format they require.

Ability to manually assign ERLs to analog phones and other types of phones that Cisco ER cannot automatically track.

Cisco Emergency Responder 1.2(1) Enhancements

This section highlights the feature enhancements for Cisco Emergency Responder 1.2 (Cisco ER 1.2):

Support for Cisco CallManager 3.3.

Greater Scalability—Cisco ER 1.2 uses an MSDE (Microsoft SQL Server Desktop Engine) database instead of the Cisco CallManager directory to store Cisco ER configuration data. And, Cisco ER 1.2 separates the Location Tracking Service From Cisco ER Service to provide support for more phones and more emergency calls.

Cisco ER 1.2 can scale up to 10,000 manually configured phones and 10,000 call history records. Refer to Table 1-7 for the scalability numbers for your Cisco Media Convergence Server (MCS) platform.


Note The maximum number of ERLs that you can configure for Cisco ER is defined by the number of route patterns Cisco CallManager supports.


Using the MSDE database also reduces directory look-ups on the Cisco CallManager directory server thereby minimizing impact on Cisco CallManager performance.


Note As with earlier versions of Cisco ER, Cisco ER 1.2 uses the Cisco CallManager directory for storing Cisco ER cluster information.


Support for CiscoWorks IP Telephony Environment Monitor 2.0 (ITEM)—CiscoWorks ITEM is a suite of network management applications that monitor and manage IP telephony implementations. To use ITEM to monitor the health and functionality of Cisco ER, you create test ERLS with synthetic phones. See the "Configuring Test ERLs" section.

Real-time Web Alerts—Cisco ER 1.2 displays 911 calls in the web alert screen immediately after the emergency call is received and routed by Cisco ER call-routing service. For information on setting web alerts, see "Identifying Security Personnel (Onsite Alert Personnel)" section.

Support for IP Subnet-based (Layer 3) ERLs—With Cisco ER 1.2, you can configure IP Subnets and assign ERLs to the configured subnets; Cisco ER then routes the emergency calls from the IP Subnet and its assigned ERL. This feature can be used to track phones connected to third-party switches.


Note This configuration is useful in environments where strict IP addressing rules are followed and cubicle-level location is not required.


For more information, see the "Configuring IP Subnet-based ERLs" section.

Tracking 802.11b Endpoints—Cisco Wireless IP 7920 Phones and Cisco IP SoftPhones running on 802.11b can be located and tracked using subnet-based ERLs.

Cisco ER cannot locate or track 802.11b wireless endpoints to a Cisco Access Point. It is recommended that:

You configure a subnet-ERL for each access point.

You identify the switch port to which the access point is connected and you assign the 802.11b wireless endpoint to the subnet ERL that is configured for that access point.

For more information, see the "Configuring IP Subnet-based ERLs" section.

Cisco IP SoftPhone Tracking Enhancements—With Cisco CallManager 3.3 and later, Cisco ER 1.2 can use Cisco CallManager's CTI device table to track movements of Cisco IP SoftPhones, just like it tracks movements of other non-CDP hardware phones.

Cisco ER Admin Utility—You can use this tool:

To change the password for CERSQLAdmin account.

To point a subscriber server to a different publisher server.

To restart Cisco ER services.

To restart database services.

To update the access attributes of the Cisco ER cluster directory.

For more information, see the"Using the Cisco ER Admin Utility" section.

Support for Cisco IP Telephony Applications  Backup Utility Version 3.5.44—The Cisco IP Telephony Applications Backup Utility 3.5.44 provides a reliable and convenient way to perform regularly scheduled automatic or user-invoked backups of your data. You can use the utility with Cisco ER 1.2 to manually perform periodic directory backups. For more information, see the "Backing Up and Recovering Data" section.

Configurable Emergency Number—Cisco ER 1.2 allows you to modify the emergency number that is automatically configured when you install Cisco ER. To modify the emergency number, you unregister the previous route point and register the route point for the new number. See the "Modifying the Emergency Number" section for more information.

Enhancements in CTI Failover Support—Cisco ER 1.2 supports two levels of CTI failover: a tertiary CTI server can be used if both primary and secondary CTI servers are out of the network. To enable this additional CTI failover support, you configure the primary, secondary, and tertiary CTI Manager. See the "Identifying the Cisco CallManager Clusters" section for more information.

ERL Debug Tool—The ERL Debug Tool takes the phone extension as the search criteria and displays the ERL for the phone. Use this diagnostic tool to verify the Cisco ER configuration during ERL creation and assignment phase and to troubleshoot calls directed to incorrect ERLs. See the "Using the Cisco ER Admin Utility" section for information on using this diagnostic tool.

Enhanced ERL Import Mechanism—In Cisco ER 1.2, the ERL Import file can contain the building tags, making the import task less error-prone. The building tag file will contain PS-ALI details that have already been verified with the local PS-ALI service provider.

PS-ALI to CSV Conversion Tool—Use this tool if your ALI data is in a NENA 2.0 format, such as in PBX deployments. The tool converts ALI files from a NENA 2.0 format into a csv (Comma Separated Value) text file. You can then modify the csv file (for example, to add or change an ERL name), and save the modified ERL details by importing the file into Cisco ER.

Bulk Import/Export of Manual Phone Configuration—Use the bulk import mechanism to facilitate bulk creation of manually-configured phones.

Password Encryption—Cisco ER 1.2 uses a password encryption method to authenticate the user name and password login. Encryption makes it difficult for unauthorized personnel to access login credentials, thus improving network security.

Adding Cisco ER Servers—With Cisco ER 1.2, you add the Cisco ER servers to a Cisco ER group when you start the Cisco ER services; you no longer insert servers from the Cisco ER Group > Server Settings page. The publisher server is added as the primary Cisco ER server and the subscriber server is added as the standby Cisco ER server. (Refer to the "Installing Cisco Emergency Responder 1.2(1) on a New System" section.)

You now use the Server Settings page to update server settings, for example, to change the server name, to change the trace/debug settings, or to delete servers. For more information, see Configuring Cisco Emergency Responder Servers.

Default ERLs—If a phone is not assigned to any ERL, Cisco ER 1.2 uses the default ERL to route calls from that phone.

Cisco ER 1.2 does not automatically place ports under the Default ERL, nor place Unlocated Phones under the Default ERL. With Cisco ER 1.2, you cannot configure switch ports, unlocated phones, manually-configured phones, or IP subnet to the default ERL.


Note During the migration of data in an upgrade scenario, if any manually-configured phone is assigned to the default ERL, it will remain there until it is modified.


Remote Server Groups—When phones are discovered in the remote server group:

The local Cisco ER displays them in the Unlocated Phones page with the Remote Server Group name associated with it.

In the remote Cisco ER, the phone is displayed under the Switch Port page or under the IP Subnet Phone page where it was discovered, with the phone type as Unknown.

You no longer access the Remote Server Group Port/ERL details from the Administration page.

Viewing Switch Port Associations—Cisco ER 1.2 sorts ports by Switch IP, Module, and then Port ID. As a result, the display of associated ports on top of search results is changed. To see all the switch ports with phones, use "Phone Mac is not empty." The Switch Host Name-based search is removed in Cisco ER 1.2.

Adding User Licenses—With Cisco ER 1.2, you can add user licenses beyond the 100 users licensed with the server key in the following increments: 100; 500; 1,000; 5,000; 10,000. For more information, refer to "Cisco Emergency Responder 1.2(x) Licenses" section.

Cisco Emergency Responder 1.2(2) Enhancements

This section highlights the feature enhancements for Cisco Emergency Responder (Cisco ER) 1.2(2):

Support for Cisco CallManager 4.0

Dynamic modification of the calling party number. This feature reduces the number of route patterns that Cisco ER requires. You no longer configure a route pattern for every ELIN number on the Cisco CallManager. Instead, you can configure multiple ELIN numbers for a single route pattern on Cisco ER and you can do so across ERLs. Note that ELIN numbers still must be unique.

Cisco Emergency Responder 1.2(3) Enhancements

This section highlights the feature enhancements for Cisco Emergency Responder 1.2(3):

Support for Cisco CallManager 4.1(2)— OS 2000.2.6 SR2 is required.

Cisco CallManager 4.1(2) Interactions:

When configuring Cisco CallManager 4.1(2) and Cisco ER 1.2(3), do not configure the Time of Day feature in the partition used for emergency calls (see the "Creating a Cisco Emergency Responder Partition" section.)

Cisco ER 1.2(3) does not support Forced Authorization Codes (FAC) or Client Matter Codes (CMC).

Supported Upgrade Paths:

From Cisco ER 1.1(4) to Cisco ER 1.2(3)

From Cisco ER 1.2(1) to Cisco ER 1.2(3)

From Cisco ER 1.2(2) to Cisco ER 1.2(3


Note For new installations of Cisco ER 1.2(3), install Cisco ER 1.2(1) (see the "Installing Cisco Emergency Responder 1.2(1) on a New System" section) and then upgrade to Cisco ER 1.2(3).


Supported New Devices:

Cisco Catalyst 2950-24SX; Cisco Catalyst 2950-48SX; Cisco Catalyst 2950-48T

Cisco Catalyst 3560

Cisco Catalyst 3750

Cisco Catalyst 4510R

Cisco Catalyst 6503

Cisco Catalyst 6509 NEB-A

For a complete list of hardware and software that Cisco ER 1.2(3) supports, see the "Network Hardware and Software Requirements" section.

Port Naming Convention—To support switches such as the Cisco Catalyst 3750 which have ports that can be uniquely identified by Switch ID, Module ID and Port ID combination, Cisco ER 1.2(3) uses the following port naming convention in the Switch Port administration page:

IfName: New field display name for port as given for the switch CLI (for example Fa1/5 or Gi2/0/1)

Port Identifier: replaces the Module ID/Port ID.
It contains {optional} <<Switch ID (for stackable switches like the Cisco Catalyst 3750)>> / <<relative position of the module in switch>> / <<relative position of port in the module>>

Search on Port IfName replaces the Module ID/Port ID search.

For more information, see the "Switch Port Details" section.

Related Topics

Understanding Enhanced 911 (E911)

Network Hardware and Software Requirements

How Cisco Emergency Responder Fits Into Your Network

Determining the Required Number of Cisco Emergency Responder Groups

Data Integrity and Reliability Considerations

Understanding ERLs

Network Hardware and Software Requirements

These tables list the hardware and software that Cisco Emergency Responder (Cisco ER) 1.2(3) supports. The type of support can differ between types of hardware, so read the table carefully to determine how Cisco ER will work with the devices you use.


Note For the latest information about supported hardware and software, see the Release Notes for Cisco Emergency Responder 1.2(3).


Table 1-2—Other software that you must install to use Cisco ER 1.2(3).

Table 1-3—Optional software that is recommended for use with Cisco ER 1.2(3).

Table 1-4—The different types of phones that support Cisco ER 1.2(3). However, the type of support Cisco ER 1.2(3) supplies differs depending on the type of phone and the type of switch port to which the phone is attached.

Table 1-5—The switches supported for automatic tracking. You can use other switches, but you might have to manually define phones attached to those switches.


Note Cisco Emergency Responder (Cisco ER) does not support Cisco Integrated Communications System (ICS) 7750 servers.


Table 1-6—Supported Media Convergence Server Platforms.

Table 1-7— Scalability of supported Media Convergence Server Platforms.

Table 1-2 Required Software 

Item
Minimum Software Version
Description

Cisco CallManager

3.1(4b)

Cisco ER 1.2(3) also supports:

Cisco CallManager 3.1(4b)

Cisco CallManager 3.2(2) spB
Cisco CallManager 3.2(2c) Cisco CallManager 3.2(2c) spE Cisco CallManager 3.2(2c) spF Cisco CallManager 3.2(2c) spG

Cisco CallManager 3.2(3)

Cisco CallManager 3.3(2) spA
Cisco CallManager 3.3(2) spB
Cisco CallManager 3.3(2) spC

Cisco CallManager 3.3(3)

Cisco CallManager 3.3(4)

Cisco CallManager 4.0(2a)

Cisco CallManager 4.1(2)

The software that runs the telephony network. The Cisco CallManager directory is used by Cisco ER to store cluster information.

Cisco CallManager Operating System

OS 2000.2.6 SR2

Be sure to install or upgrade your OS version to OS 2000.2.6 SR2, before upgrading to Cisco ER 1.2(3).

The Cisco ER 1.2(3) upgrade checks the installed operating system and aborts the upgrade if OS 2000.2.6 SR2 is not found.

Web browser

Netscape Navigator 4.5 up to, but not including, 6.x

Microsoft Internet Explorer 5.0 and higher

Navigator is supported on Solaris, Windows NT, and Windows 95.

Internet Explorer is supported on Windows 2000, Windows NT, and Windows 95.


Table 1-3 Optional And Recommended Software 

Item
Minimum Software Version
Description

Email server

Any SMTP email server

Used to send email notifications to onsite alert (security) personnel. If you use an SMTP email-based paging server, personnel are paged instead of emailed.

Cisco IP Telephony Applications Backup Utility

Version 4.0(5)

Used as a reliable and convenient way to perform regularly scheduled automatic or user-invoked backups of your data. Use the utility with Cisco ER 1.2(x) to manually perform periodic directory backups.

Ciscoworks IP Telephony Environment Monitor (ITEM)

Version 2.0

Used to monitor the health and functionality of Cisco ER 1.2(x).

McAfee Netshield

Version 7.1

Used to help protect your system from virus attacks.

Cisco Security Agent (CSA)

See the CSA software download page for the latest versions of CSA files:

http://www.cisco.com/cgi-bin/tablebuild.pl/cmva-3des

See the Cisco Compatibility Matrix for information regarding supported software releases:

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/index.htm

For information about using McAfee Netshield and the Cisco Security Agent (CSA), refer to this URL:
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/sec_vir/index.htm

Used to help protect your system from security and network attacks.


Table 1-4 Supported Phones 

Phones
Description
Phones automatically tracked using CDP

Cisco IP Phone models 7970, 7960, 7940, 7935, 7912, 7910, 7905G, 7902

All other Skinny phones with CDP support, with the exception of ATA devices

Cisco IP Communicator 1.1

These phones do not require special Cisco ER configuration. However, ensure that you enable CDP (Cisco Discovery Protocol) on the switches.

Note When running on Cisco CallManager 4.0 or earlier, Cisco ER 1.2((3) displays the phone type for the Cisco IP Phone models 7902, 7905G, and 7912 as "OTHER."

Note Although ATA phones support CDP and SCCP, Cisco ER cannot automatically track them. You can add ATA phones manually and assign them to an ERL. Cisco ER will route calls from ATA phones based on the assigned ERL.

Phones automatically tracked using CAM tables

Cisco IP SoftPhone 1.2 and 1.3

Cisco IP Phone models 12 SP+ and VIP 30

To automatically track these phones, you must enable CAM tracking when you add the switches to the Cisco ER configuration. Phones that do not use CDP are tracked using the CAM table on all supported switch platforms for Native and AUX Vlans.

See the "Identifying the LAN Switches" section for more information.

Phones that you can track using IP subnet

Wireless phones, such as Cisco Wireless IP Phone 7920, and Cisco IP SoftPhones running on 802.11b

Supported Cisco IP Phones connected to Cisco or third-party switches that are not discovered or recognized by Cisco ER

To track these phones, you must configure the subnet and then assign ERLs to the configured subnets.

See "Configuring IP Subnet-based ERLs" section.

Phones that you can manually define

Analog phones, for example, phones connected to VG248 and ATA devices

Generic H.323 or SIP endpoints. Supported H.323 phones are Microsoft NetMeeting and Tandberg.

Any phone otherwise supported for automatic tracking that is connected to an unsupported switch port

These phones are only supported if their calls are routed by Cisco CallManager.

See the "Manually Defining a Phone" section for information on defining these phones in the Cisco ER configuration.



Note Cisco  ER supports SNMP version 1, version 2 and version 2c of a LAN switch.


.

Table 1-5 Supported Voice-Ready LAN Switches 

Series
(Ethernet ports only)
Notes
Device Supported
System Object ID from CISCO-PRODUCTS-MIB

Catalyst 2900 XL

12.1.9.EA1 and higher

2908 XL

1.3.6.1.4.1.9.1.170

2916 MXL

1.3.6.1.4.1.9.1.171

2924 XL

1.3.6.1.4.1.9.1.183

2924 CXL

1.3.6.1.4.1.9.1.184

2924 XLV

1.3.6.1.4.1.9.1.217

2924 CXLV

1.3.6.1.4.1.9.1.218

2912 XL

1.3.6.1.4.1.9.1.219

2924 MXL

1.3.6.1.4.1.9.1.220

2912 MXFL

1.3.6.1.4.1.9.1.221

2900

1.3.6.1.4.1.9.5.12

2926

1.3.6.1.4.1.9.5.35

2948 G

1.3.6.1.4.1.9.5.42

2980 G

1.3.6.1.4.1.9.5.49

2980 GA

1.3.6.1.4.1.9.5.51

Catalyst 2950

12.1.9.EA1 and higher

2950-12

1.3.6.1.4.1.9.1.323

2950-24

1.3.6.1.4.1.9.1.324

2950-24SX

1.3.6.1.4.1.9.1.480

2950-48SX

1.3.6.1.4.1.9.1.560

2950-48T

1.3.6.1.4.1.9.1.559

2950C-24

1.3.6.1.4.1.9.1.325

2950T-24

1.3.6.1.4.1.9.1.359

2950G-12

1.3.6.1.4.1.9.1.427

2950G-24

1.3.6.1.4.1.9.1.428

2950G-48

1.3.6.1.4.1.9.1.429

2950S-24

1.3.6.1.4.1.9.1.430

2950G-24DC

1.3.6.1.4.1.9.1.472

Catalyst 3500 XL

Cisco IPS 12.0(5)XU or higher

If you are using 3500 clusters, you must assign an IP address to each 3500 switch.

3508 GXL

1.3.6.1.4.1.9.1.246

3512 XL

1.3.6.1.4.1.9.1.247

3524 XL

1.3.6.1.4.1.9.1.248

3548 XL

1.3.6.1.4.1.9.1.278

3524 PWR XL

1.3.6.1.4.1.9.1.287

Catalyst 3550

12/1/6/EA1a or higher

3550-24

1.3.6.1.4.1.9.1.366

3550-24PWR

1.3.6.1.4.1.9.1.485

3550-48

1.3.6.1.4.1.9.1.367

3550-12T

1.3.6.1.4.1.9.1.368

3550-12G

1.3.6.1.4.1.9.1.431

3550-24DC

1.3.6.1.4.1.9.1.452

Catalyst 3560

Cisco IOS 12.2(20)SE or higher

3560-24PS

1.2.6.1.4.1.9.1.563

3560-48PS

1.2.6.1.4.1.9.1.564

Cisco 3725 Multiservice Access Router

Image version:
IOS 12.2(8)T5

 

1.3.6.1.4.1.9.1.414

Cisco 3745 Multiservice Access Router

Image version:
IOS 12.2(13)T

 

1.3.6.1.4.1.9.1.436

Catalyst 3750

Cisco IOS 12.2(20)SE or higher

3750-24

1.3.6.1.4.1.9.1.511

3750-48

1.3.6.1.4.1.9.1.512

3750-24TS

1.3.6.1.4.1.9.1.513

3750-24T

1.3.6.1.4.1.9.1.514

37XX Stack

1.3.6.1.4.1.9.1.516

3750G-12Sfp

1.3.6.1.4.1.9.1.530

3750-48PS

1.3.6.1.4.1.9.1.535

3750-24PS

1.3.6.1.4.1.9.1.536

3750G-16TD

1.3.6.1.4.1.9.1.591

3750G-24PS

1.3.6.1.4.1.9.1.602

3750G-48PS

1.3.6.1.4.1.9.1.603

3750G-48TS

1.3.6.1.4.1.9.1.604

3750G-24TS1U

1.3.6.1.4.1.9.1.618

Catalyst 4000/4500

Catalyst OS 5.5 or higher

4003

1.3.6.1.4.1.9.5.40

4912 G

1.3.6.1.4.1.9.5.41

4006

1.3.6.1.4.1.9.5.46

4500

1.3.6.1.4.1.9.1.14

4503

1.3.6.1.4.1.9.5.58

4506

1.3.6.1.4.1.9.5.59

Catalyst 4000

Cisco IOS 12.1(13)EW

4000 C

1.3.6.1.4.1.9.1.448

4503

1.3.6.1.4.1.9.1.503

4506

1.3.6.1.4.1.9.1.502

4507

1.3.6.1.4.1.9.1.501

4510R

1.3.6.1.4.1.9.1.537

Catalyst 5000

Catalyst OS 6.x

5000

1.3.6.1.4.1.9.5.7

5002

1.3.6.1.4.1.9.5.29

Catalyst 5500

 

5500

1.3.6.1.4.1.9.5.17

5505

1.3.6.1.4.1.9.5.34

5509

1.3.6.1.4.1.9.5.36

Catalyst 6000

Catalyst OS

6503

1.3.6.1.4.1.9.1.5.56

   

6509 NEB-A chassis

1.3.6.1.4.1.9.5.61

 

Catalyst OS 5.5 or higher

If using an MSFCW module, Cisco IOS 12.1(3a)XL

6006

1.3.6.1.4.1.9.5.38

6009

1.3.6.1.4.1.9.5.39

6509

1.3.6.1.4.1.9.5.44

6506

1.3.6.1.4.1.9.5.45

6509 SP

1.3.6.1.4.1.9.5.47

6513

1.3.6.1.4.1.9.5.50

Catalyst 6000

Cisco IOS

6503

1.3.6.1.4.1.9.1.449

6006

1.3.6.1.4.1.9.1.280

6009

1.3.6.1.4.1.9.1.281

6506

1.3.6.1.4.1.9.1.282

6509

1.3.6.1.4.1.9.1.283

6509 NEB-A chassis

1.3.6.1.4.1.9.1.534

6509 SP

1.3.6.1.4.1.9.1.310

6513

1.3.6.1.4.1.9.1.400


Cisco ER runs on Cisco Media Convergence Server (MCS) hardware platforms (with Windows 2000 and voice applications). You can also use equivalent Cisco-certified servers. Cisco ER 1.2(3) supports the MCS platforms shown in Table 1-6; Table 1-7 lists scalability for these MCS platforms.


Note The number of ERLs that can be deployed is determined by the number of route patterns and translation patterns configurable in Cisco CallManager.



Note Cisco ER servers support a maximum of 500 CTI-based Cisco IP SoftPhones.



Note Cisco Emergency Responder (Cisco ER) does not support Cisco Integrated Communications System (ICS) 7750 servers.

Table 1-6 Supported Cisco ER 1.2(3) MCS Platforms

MCS-7815
MCS-7825
MCS-7835
MCS-7845
H
I
H
I
H
I
H
I

--

2.0

2.2

--

2.4

2.4

2.4

--

--

3.0

3.0

3.0

3.0

3.0

3.0

--


Table 1-7 Supported Cisco ER 1.2(3) MCS Platforms and Scalability

Scalability
MCS 7815
MCS 7825
MCS 7835
MCS 7845

Switches

200

500

1,000

2,000

Switch Ports

12,000

30,000

60,000

120,000

Manual Phones

1,000

2,500

5,000

10,000

Roaming Phones (remote Cisco ER group)

600 per
Cisco ER cluster

1,200 per Cisco ER cluster

2,000 per Cisco ER cluster

3,000 per Cisco ER cluster

IP Phones

6,000

12,000

20,000

30,000



Table 1-8 lists configurations that Cisco ER does not support.

Table 1-8 Non-Supported Configurations

Non-Supported Configurations
Notes

Hub topologies

 

DSL, VPN, IDSN and other remote or dial-in technologies

Cisco ER cannot support telecommuters who have phones linked into your network over these types of lines

Survivable remote site telephony (SRST)

If you deploy Cisco ER over a WAN link, the link must be active for Cisco ER to work correctly.


Cisco Emergency Responder 1.2(x) Licenses

This section describes the following topics:

License Keys for Cisco Emergency Responder

Determining Your License Requirements

License Keys for Cisco Emergency Responder

Table 1-9 describes the license keys for Cisco Emergency Responder 1.2(x) (Cisco ER).

Table 1-9 License Keys for Cisco Emergency Responder 1.2(x) 

License Key
Purpose
Where To Find the Key
When To Enter The Key

Operating System (OS) License Key

This provides the base operating system that Cisco ER requires.

FVHD IAZA ROFJ DERJ

You are prompted to enter the OS license key when you install the operating system for Cisco CallManager.

The operating system is part of the Cisco CallManager Spirian CD-ROMs. When you enter the OS key, the Spirian script will install only the operating system, not Cisco CallManager.

You must install the operating system before you install Cisco ER.

For information about installing the Cisco CallManager OS, see this URL:
http://www.cisco.com/univercd/cc/td/
doc/product/voice/iptel_os/index.htm

Server License Key

This license allows use of Cisco ER for up to 100 users beyond the 60-day evaluation period.

The document containing this key, Server License Key for Cisco Emergency Responder, ships with the Cisco ER software.

After installing the product, enter the server license key through the Cisco ER administration interface. See Step 2 of the "Entering the Cisco Emergency Responder License Key" section.

You must purchase a server license for each Cisco ER server, that is, one for the primary Cisco ER server and one for the Cisco ER standby server.

The server license allows 100 users each; two service licenses allow 200 users without purchase of additional user licenses.

Note Cisco ER does not display the 100-user license key in the Cisco ER web interface.

You do not have to wait for the 60-day demonstration period to expire. You may enter the Server License Key any time after you have installed Cisco ER.

If you have not entered the Server License Key by the time the 60-day demonstration period expires, Cisco ER stops working until you enter the Server License Key.

User License Key

This is the key for the number of user licenses that you purchase for Cisco ER above the 200 users licensed with the two Service Licenses (100 per Server License).

With Cisco ER 1.2(x), you can add user licenses in the following increments: 100; 500; 1,000; 5,000; 10,000..

The document containing this key ships with the Cisco ER software.

If you buy additional user licenses subsequent to your Cisco ER purchase, you will receive the user keys separately.

After installing the Server License Key, enter the User License Key through the Cisco ER administration interface.

See Step 3 of the "Entering the Cisco Emergency Responder License Key" section.

Note Be sure to install the Server License Key on the Cisco ER server before installing the User License Key.

Note For upgrade installations, all Cisco ER1.1 licenses are imported as part of the upgrade. Cisco ER displays the licenses in the web interface as they appeared in Cisco ER 1.1.


Determining Your License Requirements

For server licenses:

Order two server licenses for each Cisco ER group: one server license for the primary server and a separate server license for the backup server.

You cannot share a server license between the primary server and the backup server.

For user licenses:

Order one user license for each Cisco ER group.

User licenses can be shared between primary and backup servers within each Cisco ER group. This includes both 100-user licenses provided by the primary and secondary server license.

You cannot share Cisco Emergency Responder user licenses between different Cisco ER groups in a Cisco ER cluster, or between different Cisco ER clusters.

Example

If your Cisco ER configuration supports 500 users, you need to purchase:

One service license for your primary Cisco ER server; this also provides for 100 users

One service license for your backup Cisco ER server; this provides for another100 users.

Three additional user licenses for 100 users each.

How Cisco Emergency Responder Fits Into Your Network

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

Figure 1-1 How Cisco ER Fits Into Your Network

Cisco ER depends on Cisco CallManager for the corporate dial plan, which you must modify to send emergency calls to the Cisco ER group. With Cisco ER 1.2(x), the Cisco ER group stores the Cisco ER configuration in the MSDE (Microsoft SQL Server Desktop Engine) database. The Cisco CallManager's LDAP directory continues to store the Cisco ER cluster information. See Chapter 3 "Configuring Cisco CallManager for Cisco Emergency Responder," for complete information about the required Cisco CallManager configuration.

To track phones, Cisco ER queries Cisco CallManager for a list of phones registered with the cluster. Then, Cisco ER queries the switches on the network (the ones you have identified to Cisco ER) to determine the port to which the phones are connected. Cisco ER 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 Cisco ER. See the "Managing Phones" section for information on how to configure switch ports so that Cisco ER 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 Cisco ER 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 Cisco ER can route emergency calls to the local public safety answering point (PSAP).

In this diagram, one Cisco ER group supports a single Cisco CallManager cluster. You can support more than one Cisco CallManager cluster with a single Cisco ER group, as long as the Cisco CallManagers are running the same software version. If you have a larger network, you can install multiple Cisco ER groups and create a Cisco ER cluster. See the "Understanding Cisco Emergency Responder Clusters and Groups" section for a discussion of this more complex 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 Cisco ER.

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 (Cisco ER) uses to handle emergency calls. Understanding this process can help you set up Cisco ER correctly and troubleshoot problems you might encounter.

Figure 1-2 illustrates the path of an emergency call.

Figure 1-2 How Cisco Emergency Responder Routes Emergency Calls

When someone uses extension 3003 to make an emergency call:

Cisco CallManager routes the call to Cisco ER.

Cisco ER gets the route pattern configured for the emergency response location (ERL) of the caller. Refer to the "Cisco Emergency Responder's Call Routing Order" section for information on the order of call routing.

Cisco ER converts the calling party's 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.

Cisco ER 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 ER Group Settings" section).

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

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

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 Cisco ER, and Cisco ER converts the ELIN to the last cached extension associated with the ELIN. The call is then routed to the extension.

You should consider these major potential points of failure:

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 ELIN's 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.

Finally, 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 in an ERL. Cisco ER 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 will reach 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's Call Routing Order

Cisco ER directs emergency calls based on the ERL assigned to the phone from which a call is made. Most of the time, the ERL determination is based on the switch port to which the phone is connected.

However, if the switch port is not assigned to an ERL, Cisco ER determines the ERL for the phone in the following routing order:

1. Synthetic phone ERL (if the calling phone's MAC is configured)

2. Switch port in which the phone is tracked (if configured to an ERL)

3. IP subnet ERL (if the phone IP is found in any configured IP Subnet)

4. Phones found behind some other Cisco ER Server Group (route to that Cisco ER Server Group)

5. Phones with manual-entry ERL (if the calling phone extension is configured)

6. Unlocated phones ERL (if configured to an ERL)

7. Default ERL

Related Topics

Understanding E911 and Cisco Emergency Responder Terminology

Data Integrity and Reliability Considerations

Understanding ERLs

Setting Up the ELIN Numbers to Route Emergency Calls and Enable PSAP Callbacks

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

Cisco ER 1.2(x) uses an MSDE (Microsoft SQL Server Desktop Engine) database instead of a Cisco CallManager directory to store Cisco ER configuration information. During installation, you install the MSDE database as either a publisher (primary) or a subscriber (backup) Cisco ER server. Each publisher server and subscriber server make up a Cisco ER Server Group.

Cisco ER 1.2(x) continues to use the Cisco CallManager Directory to store Cisco ER cluster information. Cisco ER Server Groups that point to the same Cisco CallManager directory make up a Cisco ER Cluster.


Note Cisco ER 1.1(x) and Cisco ER 1.2(x) cannot be deployed in the same Cisco ER group. If you are upgrading to Cisco ER 1.2(x), make sure to upgrade both Cisco ER servers to version 1.2(x).


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

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

In this example:

There are two Cisco CallManager clusters, CCM cluster A and CCM cluster B.

Cisco ER Server Group 1 and Cisco ER Server Group 2 form a single Cisco ER cluster.

Cisco ER Server Group 1 supports CCM cluster A and Cisco ER Server Group 2 supports CCM cluster B.

LDAP-A1, CCM-A1's directory, stores the Cisco ER cluster information for both Cisco ER server groups.

Each Cisco ER server has an MSDE database containing the Cisco ER configuration information.


Note For Cisco ER intra-cluster phone tracking to work accurately, a Cisco ER server in the cluster must be able to be found by host name and must be able to be reached on the network from all other Cisco ER servers.


If you enter the system administrator's e-mail account in the System Administrator Mail ID field when you configure the Cisco ER Server Group Settings (see the "Configuring a Cisco Emergency Responder Server Group" section), 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.

To complete the creation of the Cisco ER cluster, you must create inter-cluster trunks and route patterns to allow the Cisco ER 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 Cisco ER (see the "Configuring Group Telephony Settings For the Cisco Emergency Responder Server" section).


Caution Before you create a Cisco ER cluster, be aware that the dial plans in all Cisco CallManager clusters supported by the Cisco ER cluster must be unique. For example, extension 2002 can only be defined in one Cisco CallManager cluster. If you have overlapping dial plans, you must have separate Cisco ER clusters, which means you cannot support dynamic phone movement between those Cisco CallManager clusters.

The following scenario illustrates how Cisco ER treats phones moving between clusters:

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

Cisco ER discovers Phone_1 in Server Group B (SGB).

The Unlocated Phones page in SGA will display the phone in SGB.

Now, if both the Cisco ER servers (master and standby) in SGB go down, SGA will still display Phone_1 in SGB.

Calls made from Phone_1 during this time will be redirected to SGB and Cisco ER will take the same steps to route this emergency call when Cisco ER servers are not there in SGB.

Phone_1 will also be treated like any other phone in SGB when both the SGB Cisco ER servers are down.

If Phone_1 moves to Server Group C (SGC):

Then it will be discovered after the next incremental phone tracking on SGA and then in SGC.

And, the Unlocated Phones page will change the association of Phone_1 to SGC.

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

Be aware of the following when planning your Cisco ER system:

A single Cisco ER group cannot support clusters with a mix of Cisco CallManager versions. For example, Cisco ER can support all Cisco CallManager 3.2 clusters or all Cisco CallManager 3.3 clusters. However, a Cisco ER cluster can contain Cisco ER groups that support different versions of Cisco CallManager. In this way, Cisco ER can support a mix of Cisco CallManager versions in your telephony network.

A Cisco ER 1.2(x) server group can operate only with Cisco ER server groups of version 1.2(x); it cannot communicate with Cisco ER 1.1(x).

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 Emergency Responder (Cisco ER) performance, you should take the limits each Cisco ER group can support into account when planning your Cisco ER deployment. Keep in mind that a single Cisco CallManager cluster can only be supported by one Cisco ER group, although a single Cisco ER group can support more than one Cisco CallManager cluster.

Refer to Table 1-7 for the capacities of a single Cisco ER 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 Cisco ER group can work with one or more Cisco CallManager 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 must also divide your Cisco ER groups to accommodate those territories. From each Cisco ER group, you export the ALI data to send to the ALI database provider: ensure that a single Cisco ER group's ALIs only belong to a single ALI database.

Related Topics

Understanding Cisco Emergency Responder Clusters and Groups

Deploying Cisco Emergency Responder

Negotiate ALI Submission Requirements With Your Service Provider

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 the gateway 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 will be used for the port, and the wrong ALI sent to the PSAP.

This type of change will not normally result in an incorrectly routed call, because it is unlikely that a single LAN switch will connect 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.

If you have phones that Cisco ER cannot automatically track, ensure that any moves, adds, or changes to these phones also result in an update to the Cisco ER configuration. See the "Manually Defining a Phone" section for information on defining these types of phones.

Prior to Cisco ER 1.2(x), if registered phones were not found behind a switch port, Cisco ER would list the phone in the Unlocated Phones page.

Cisco ER 1.2(x) locates these phones as described here:

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, Cisco ER lists the phone in the Unlocated Phones page.

To determine the ERL that Cisco ER will use for call routing, use the ERL Debug Tool to search for the phone. The search yields the current ERL that will be used in routing the emergency call from this phone and also why Cisco ER chose that ERL. For more information, see the "Using the Cisco ER Admin Utility" section.

When you install Cisco ER 1.2(x), 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 not separated by a WAN link. 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 Cisco ER 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 Cisco ER and clicking Locate Switch Ports. See the "Identifying the LAN Switches" section for more information.

Any phones connected to undefined switches are listed as unlocated phones in Cisco ER. If you changed a defined switch, new or changed ports become ports without any ERL association. You should assign ERLs for the new or changed switch ports. See the "Understanding the Network Administrator's Role" section and the "Understanding the ERL Administrator's Role" section for information on 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. If you have an option, work with your service provider to 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's number rather than a generic number (such as the main number of the site). Otherwise, the PSAP will 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 any 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, if you have 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 to have 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 will connect 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, Cisco Emergency Responder (Cisco ER) uses those ELINs in sequence until all are used, then reuses the ELINs in order. Cisco ER maintains the link between the ELIN and the extension of the actually emergency caller for up to three hours.

Because you need to 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 that the number of DIDs you obtain is not related to the number of emergency calls Cisco ER can handle. Because Cisco ER 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

Setting Up the ELIN Numbers to Route Emergency Calls and Enable PSAP Callbacks

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 PSAP's screens to help them locate the caller.

Cisco ER 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 the least, you must know the data format they expect, and the transmission method they require.

Cisco ER does not include any automated capability for submitting ALIs.


Tip Before deploying Cisco ER throughout your enterprise, 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 can have slightly different rules concerning ALI information. Cisco ER allows you to create ALI data according to the general NENA standards, but your service provider or database provider might have stricter rules.


Related Topics

Understanding ERLs

Overview of ERL Management

Creating ERLs

Exporting ERL Information

Upgrade Switches and Phones

The most powerful capability of Cisco Emergency Responder (Cisco ER) 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, Cisco ER 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

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

These are the main things to consider when deciding how to make use of Cisco ER:

When someone makes an emergency call, Cisco ER 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 will help 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.

Cisco ER lets you define three types of administrative user, so you can divide responsibilities for overall Cisco ER 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 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's Role

Understanding the Network Administrator's Role

Understanding the Cisco Emergency Responder System Administrator's 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 Two Main Sites

Deploying Cisco Emergency Responder in One Main Site with One PSAP

Figure 1-4 shows how Cisco Emergency Responder (Cisco ER) fits into a simple telephony network where you have a single Cisco CallManager cluster.

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

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 Two Main Sites

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

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 1.2(1) on a New System

Configuring Cisco CallManager for Cisco Emergency Responder

Overview of Cisco Emergency Responder Configuration

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

Figure 1-5 illustrates the Cisco Emergency Responder (Cisco ER) configuration if you have one main site that is served by two or more PSAPs. This example assumes you have one Cisco CallManager 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 ER 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. During installation, select the same Cisco CallManager server for use as the group and cluster databases.

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 will 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 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 1.2(1) on a New System

Upgrading from Cisco Emergency Responder 1.1(4) to Cisco Emergency Responder 1.2(3)

Configuring Cisco CallManager for Cisco Emergency Responder

Overview of Cisco Emergency Responder Configuration

Deploying Cisco Emergency Responder In One Main Site with Satellite Offices

Figure 1-6 illustrates the Cisco Emergency Responder (Cisco ER) configuration if you have one main site that serves one or more satellite offices, that is, where the phones in the satellite office are run from the Cisco CallManager cluster on the main site. If the satellite office has its own Cisco CallManager cluster, see the "Deploying Cisco Emergency Responder In Two Main Sites" section.

Figure 1-6 Deploying Cisco ER 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.

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 even 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 will 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's 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 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 1.2(1) on a New System

Upgrading from Cisco Emergency Responder 1.1(4) to Cisco Emergency Responder 1.2(3)

Configuring Cisco CallManager for Cisco Emergency Responder

Overview of Cisco Emergency Responder Configuration

Deploying Cisco Emergency Responder In Two Main Sites

Figure 1-7 illustrates the Cisco Emergency Responder (Cisco ER) configuration if you have 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 the "Deploying Cisco Emergency Responder In One Main Site with Satellite Offices" section for information on 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 on deploying Cisco ER in that site.

Figure 1-7 Deploying Cisco ER in Two Main Sites

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. During installation, select the CCM-CHI Cisco CallManager server for use as the cluster directory.

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. During installation, select the CCM-NYC Cisco CallManager server for use as the cluster directory.

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 even 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 CallManager clusters, and create an inter-Cisco ER group route pattern so that Cisco ER can transfer calls between Cisco CallManager 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.

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

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 1.2(1) on a New System

Upgrading from Cisco Emergency Responder 1.1(4) to Cisco Emergency Responder 1.2(3)

Configuring Cisco CallManager for Cisco Emergency Responder

Overview of Cisco Emergency Responder Configuration