|
|
Cisco Emergency Responder (CER, or Emergency Responder) 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 your 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 Emergency Responder includes the flexibility you need to fit your emergency call configuration to your 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 CER in a manner that fits your legal and security needs.
These topics help you understand emergency call ordinances, how CER helps you meet the ordinances, and what you need to do to deploy CER successfully:
Enhanced 911, or E911, is an extension of the basic 911 emergency call standard in North America. These topics describe E911 requirements and terminology.
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:
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.
Table 1-1 defines some of the key terminology used in this document.
Table 1-1 E911 and Emergency Responder Terminology
|
These topics provide an overview of Emergency Responder and how you can use it in your network.
These are the major features of Cisco Emergency Responder (CER):
These tables list the hardware and software that Emergency Responder supports. The type of support can differ between types of hardware, so read the table carefully to determine how Emergency Responder will work with the devices you use. See the Release Notes for Emergency Responder for the most up-to-date information.
Table 1-2, Part 1 Required Software
Table 1-2, Part 2 Supported Phones
|
Table 1-2, Part 3 Supported Voice-Ready LAN Switches
|
| 1 CER only supports Ethernet ports. |
Figure 1-1 shows how Emergency Responder fits into your network.
Emergency Responder depends on Cisco CallManager for the corporate dial plan, which you must modify to send emergency calls to the CER group. The CER group also stores the CER configuration in the Cisco CallManager's LDAP directory. See "Configuring Cisco CallManager for Emergency Responder," for complete information about the required Cisco CallManager configuration.
To track phones, Emergency Responder queries Cisco CallManager for a list of phones registered with the cluster. Then, CER queries the switches on the network (the ones you have identified to CER) to determine the port to which the phones are connected. CER does this tracking at regular intervals during the day so that it can identify when a phone moves. See the "Configuring Switches for Emergency Responder" section for more information about setting up switches for CER. See the "Managing Phones" section for information on how to configure switch ports so that CER 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 CER 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 CER can route emergency calls to the local public safety answering point (PSAP).
In this diagram, one CER group supports a single Cisco CallManager cluster. You can support more than one Cisco CallManager cluster with a single CER group. If you have a larger network, you can install multiple CER groups and create a CER cluster. See the "Understanding CER Clusters and CER 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 CER manages it.
This topic describes the process Cisco Emergency Responder (CER) uses to handle emergency calls. Understanding this process can help you set up CER correctly and troubleshoot problems you might encounter.
Figure 1-2 illustrates the path of an emergency call.
When someone uses extension 3003 to make an emergency call:
Given this methodology, you should consider these major potential points of failure:
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.
Figure 1-3 shows how CER groups can be joined in a single CER cluster.
In this example, CER groups 1 and 2 form a single CER cluster. This enables CER to handle phone movement between all four Cisco CallManager clusters: CCM-A, CCM-B, CCM-C, and CCM-D.
A CER group should consist of two CER servers: a primary server and a standby server. This redundancy can maintain the emergency call network if something happens to the primary server. The standby server also can handle calls if the primary server is too busy handling other calls or tracking phone movements. If the standby server handles a call, all onsite alert personnel (not only those for the caller's ERL) receive the email notification. When the standby server takes over for the primary server, an additional email notification is sent notifying all onsite alert personnel that this has happened.
You create a cluster when you install the individual CER servers. During installation, you must select two Cisco CallManager servers whose LDAP directories CER will use to store the CER configuration:
To complete the creation of the CER cluster, you must create inter-cluster trunks and route patterns to allow the CER groups to hand off emergency calls between the groups (see the "Creating Route Patterns for Inter-CER-Group Communications" section) and configure these route patterns in CER (see the "Configuring CER Server Group Telephony Settings" section).
 |
Caution Before you create a CER cluster, be aware that the dial plans in all Cisco CallManager clusters supported by the CER 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 CER clusters, which means you cannot support dynamic phone movement between those Cisco CallManager clusters. |
To ensure efficient CER performance, you should take these practical per-CER-group limits into account when planning your CER deployment. Keep in mind that a single Cisco CallManager cluster can only be supported by one CER group, although a single CER group can support more than one Cisco CallManager cluster.
A single CER group can support:
You might meet the maximum figures for one limitation without reaching the figures for another. For example, you might define 1000 switches, but have less than 30,000 switch ports.
You can install additional groups to manage larger networks.
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 CER groups to accommodate those territories. From each CER group, you export the ALI data to send to the ALI database provider: ensure that a single CER group's ALIs only belong to a single ALI database.
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:
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.
Any phones connected to undefined switches are listed as unlocated phones in Emergency Responder. If you changed a defined switch, new or changed ports are assigned to the Default ERL, and should be updated to reflect the correct ERL. 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.
These topics describe the steps you should take to prepare your network before deploying Emergency Responder.
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.
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.
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.
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, 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 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 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.
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.
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 the least, you must know the data format they expect, and the transmission method they require.
Emergency Responder does not include any automated capability for submitting ALIs.
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 enjoy full automation, update your switches to supported models or software versions, and replace your telephones with supported models.
For phones attached to unsupported switches, or for unsupported phones, you can manually assign the phones to ERLs. Thus, these phones are fully supported for emergency calls. The only thing you lose is the automatic tracking capability. See the "Manually Defining a Phone" section for more information.
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 the use you want to make of Emergency Responder's capabilities.
These are the main things to consider when deciding how to make use of 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.
Figure 1-4 shows how CER fits into a simple telephony network where you have a single Cisco CallManager cluster.
To support this type of network, install two CER servers and configure them as a group. During installation, select the same Cisco CallManager server for use as the group and cluster databases.
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:
Figure 1-5 illustrates the CER 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 CER In Two Main Sites" section.
To support this type of network, install two CER servers and configure them as a group. 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, CER 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:
Figure 1-6 illustrates the CER 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 CER In Two Main Sites" section.
|
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 CER servers and configure them as a group. During installation, select the same Cisco CallManager server for use as the group and cluster databases. 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, CER 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. CER 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:
Figure 1-7 illustrates the CER 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:
To support this type of network:
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 CER group route pattern so that CER can transfer calls between Cisco CallManager clusters served by separate CER groups. The "Creating Route Patterns for Inter-CER-Group Communications" section goes into more details about how CER handles phone movement in this situation.
As phones move between sites, CER dynamically updates their ERLs so that emergency calls get routed out of the desired gateway. However, if the WAN link becomes unavailable, CER can not track phone movement between the sites.
See these examples to extend this example to other networks:
Cisco Emergency Responder is designed to route emergency calls to the local public safety answering point (PSAP), and to simplify IP phone mobility with respect to emergency call support. However, if your local ordinances do not require that emergency calls be sent to the local PSAP, you can configure CER so that emergency calls are sent to onsite security. This topic describes how to modify the CER configuration to accomplish this.
When you configure CER in this manner, emergency calls are directed to the onsite alert personnel defined for the caller's ERL. The onsite alert personnel see the caller's extension as the caller ID, and the call history log shows the onsite alert person's extension instead of the route pattern/ELIN. If there is more than one onsite alert person defined for an ERL, CER tries the contacts one by one until the call is answered. If no one answers the call, the call is transferred to the call forwarding number defined for the emergency call number.
Posted: Tue Aug 5 13:29:26 PDT 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
