Identifying a Caller’s Location for Emergency Response

October 19, 2011 - 0 Comments

If someone in your corporate building makes an emergency call, will responders know where to go? Years ago a phone was always in one location, and the phone number was as good as an address for identifying where you were. With IP telephony features for mobility, and with software phones that travel with your laptop, it can be hard to identify the physical location where a call is coming from.

At Cisco, we use several approaches to providing the right location information for emergency response. And we’ve learned how a simple portion of our dial plan can have a dramatic and painful impact on our Emergency Response system. You may find these ideas helpful for configuring emergency calling and response capabilities at your own sites.

At Cisco, we use Cisco Emergency Responder to connect an emergency call to the right responders and give them the location information they need. This solution automatically identifies the physical location of a Cisco IP phone and correlates that location with the phone’s direct inward dial (DID) number each time the phone registers with the Cisco Unified Communications Manager (Cisco UCM). Because responders can view this data online, they can both pinpoint the caller’s physical location and return a call if disconnected.

The Extension Mobility feature gives me the convenience of working in a different company office. But if I need to make an emergency call, where should it go? We have configured our phones so that emergency calls always go over a local trunk to local responders.

A similar question comes up when employees use softphone clients to place calls when they work at home, at a customer site, or while traveling. In this case, it is impossible to know the employee’s physical location, which means a call may be routed to the wrong dispatch center and delay response. Because of this issue, Cisco has decided not to support emergency calling by employees using softphone clients, backspace. Instead, we tell them to use a landline phone.

Another factor to consider is whether different types of facilities need different call routing procedures. For example, emergency calls made within our San Jose campus are routed first to our internal Security Operations Center (SOC). This allows our on-campus personnel to take immediate action and coordinate the response by local police, fire, and medical personnel. If a call to the SOC is not answered after two rings, it is forwarded immediately to the local emergency dispatch center so there is no delay in response.

For our smaller offices, we always route emergency calls to local authorities over a local circuit that provides the appropriate physical address information.

Here’s one problem that we’ve run into with Emergency Response that’s worth a word of warning: be careful with your dial plan. We have some legitimate phone numbers on our dial plan that are similar to the local emergency number, and emergency responders had told us that too many Cisco people are accidentally mis-dialing the emergency number instead. These nuisance calls are a serious problem for emergency responders, and they’ve warned us about the potential costs – fines of over $5000 per nuisance call, or even a removal of the emergency service entirely. For example, in the U.S. the emergency number is “911”, and one of our locations is in the “919” area code. Cisco employees dialing “9” for an outside line, then “1” (the US country code), then “919” can often end up dialing “911” instead, which immediately gets routed to emergency responders and becomes a nuisance call. We’ve had to change our dial plan to require us to dial “9-911” in the US, which has significantly reduced the number of mis-dialed nuisance calls.

Routing an emergency call to the right responders is an important part of your Cisco UCM configuration. By considering these scenarios, along with local laws and practices, you can create the right routing, and pass along the right information, so that your employees can get help when it’s most needed.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.