Section 14.5. Emergency Dispatch911

14.5. Emergency Dispatch/911

E911, or Enhanced 911, is the common American PSTN's public safety protocol for emergency situations. PSTN subscribers dial 911 and are connected to the fire department or police dispatcher at the closest PSAP (public safety answer point). Between the subscriber's CO and the PSAP are dedicated trunks that carry ALI (automatic location identification) signals from the phone company to the PSAP, so that emergency personnel can know the geographic location of the emergency taking place. This is particularly useful for fires and emergency medical responses.

14.5.1. E911 on the PSTN

The federal government mandates that all ILECs are required to provide 911 signaling service by way of dedicated trunks. In turn , the local public safety authorities collect a tax, usually through phone bills, to fund operation of the system. Public Utilities Commissions enforce the compliance of 911 operations, and the FCC approves standards that are used in the system.

Competitive LECs that don't have switching facilities can use those of the ILECs in order to route 911 calls.

14.5.1.1 E911 on wireless providers' networks

In addition to LECs, wireless voice carriers are now required to provide Enhanced 911 services with ALI signaling. All the major carriers have chosen the Global Positioning System (GPS) as a method of providing accurate location information to the PSAP during emergencies.

14.5.1.2 E911 on the converged network

As long as your PSTN trunks come from a LEC and the entire premises served by those trunks are at a single postal address, the default E911 service will work fine. Just make sure that your dial-plan permits 911 dialing. If it doesn't, it could literally have fatal consequences. There are essentially two ways to handle 911 calls from a VoIP network in accordance with FCC and public safety standards:

• Attach a LEC's POTS line or PRI circuit to each office location on the network for local routing of 911 calls, rather than handling them centrally in another location

• Use a PBX-attached database server that can pinpoint the locations of users who dial 911, and pass that information to the PSTN

A third option exists when direct PSTN connectivity just isn't possible, such as a VoIP network whose only outlet to the PSTN is a VoIP trunk that has no ALI service attached:

• Use local dial-plan configuration to route calls to "extension 911" out to the local authority via a standard 10-digit E.164 phone number

14.5.1.3 911 on large VoIP networks

In situations in which the private premises is very largesay, a college campus, a high-rise building, or several floors of a skyscraperE911 is more tricky to implement. If you had a VoIP network with two offices that were 50 miles apart and a single PSTN connect point served both offices, public safety workers could be dispatched to the wrong office. This is because the E911 ALI signals would reference the postal address of the connect point, even if the emergency occurred at the other office!

Routing all 911 calls in an Asterisk context to a POTS trunk is very easy. Just make an extension called 911 and use the Dial( ) command with an outbound trunk group :

 exten => 911,1,Dial(Zap/g1/911) 

Fortunately, there are a few ways around this problem. Probably the easiest (though not necessarily the most economical) way to deal with E911 is to put a LEC's POTS line at each remote location and reserve it for use only when somebody dials 911 at that location. That way, the PSAP would get the call via the local CO closest to that location. You could also use this POTS line as a failover line if the WAN link from the remote office failed; this way, people there could still make PSTN calls.

Another way of dealing with the E911 issue is to use database servers that store location data about each endpoint or TDM gateway. This way, when somebody dials 911, the PBX can pull the location of her endpoint from the database and supply it, via ALI signals, to the municipality. Such a solution would mean being able to send ALI signals through the LEC's network, rather than having them originate there. This is an expensive proposition that makes sense in only the largest environments. If you had 10 floors of a skyscraper, 3 floors of the skyscraper across the street from it, and 1,400 users, then you would benefit from this technology. Cisco makes such a solution. They call it the Cisco Emergency Responder.

14.5.1.4 Private Switch ALI

If Duane works in Lexington half the time and Lousville the other half of the time, he may tote a WiFi SCCP phone back and forth to both offices. This SCCP phone may register with two different CallManager serversso who knows who will be reached when Duane dials 911 on it? Aside from statically linking endpoint assets to locations, Cisco Emergency Responder (CER) also provides a simple way for mobile users like Duane to use the same phone to reach the closest PSAP from many geographically disparate locales.

CER relates geography and floor plans, not just to endpoint assets, but to network identifiers that aren't mobile, like MAC hardware addresses. The Cisco Discovery Protocol (CDP) is enlisted to find out where on the network each endpoint is at any given moment, then CER correlates that network location with a physical postal address. Finally, the call is connected to the PSAP using a PRI channel whose ALI address matches that which exists in the CER database. Cisco calls this technique Private Switch ALI, or PSALI.

14.5.1.5 Mapped ALI

Several companies that hail from the computer-aided dispatching software business offer software tools for Mapped ALI, an ALI solution that integrates geographic information systems (GIS) technologies such as GPS. Telecontrol Corp., Telecommunications Systems Inc. (http://www.telecomsys.com), and Contact One (http://www.contactone.com) each offer Mapped ALI solutions for service providers and public safety organizations. The approach of Mapped ALI is different from that of PSALI, because it doesn't require any stationary infrastructure like Ethernet switches. This makes it ideal in wireless applications or in hosted PBX situations in which you, as the service provider, don't have control over the customer's network. Not all PSAPs are able to use Mapped ALI technology.

14.5.1.6 POTS pass-through

Of course, all of these solutions work only when there's power. If the lights go out, so do the IP phones, the PBX, and the CER server, if you have one. Now, you wouldn't put in a phone system without a battery backup, but even a top-quality UPS can fail. In such a situation, you need to be able to reach an emergency dispatcher without the use of any of your VoIP gearbecause none of it will be operational.

To solve this problem, connect an analog telephone to a pass-through port on the PBX server. A pass-through port is a connector on a POTS trunk interface that allows a standard phone to be used with the trunk directly, circumventing the PBX even when the PBX has no power . Digium's X100P card has a pass-through port that you can use to make calls on the attached POTS trunks even when the host PC is turned off. So, the POTS pass-through phone, which draws its power from the CO through the POTS trunk, becomes your link to the PSAP during a total blackout power failure.

14.5.1.7 Dial-around

In networks with no POTS lines or PRIs connected to a LEC, such as a VoIP network that gets its PSTN connectivity by way of VoIP trunks, there's no reliable way of sending ALI signals to the PSAP. Some VoIP TSPs are working on this problem; others aren't planning on offering a solution. This doesn't mean you can't reach an emergency dispatcher with VoIP. It just means that the dispatcher won't know your location.

Still, dialing 911 won't work with most TSPs. You'll have to reprogram your on-premises VoIP gateway or IP phone to "translate" 9-1-1 into the full E.164 telephone number of the PSAP. To make matters worse , it's not always easy to find out what this number is. With the ubiquity of 911, these numbers aren't generally publicized. You may be able to get only the local fire department's or police department's administrative phone numberand in an emergency, this isn't who you're going to want on the phone. Do the research and find out how to get through to the emergency dispatcher (and not some receptionist ) via a 10-digit phone number. Then, you can program your VoIP devices to connect 911 calls to that number. An example of such a configuration is given in Project 14.5.

14.5.2. Project 14.5. Use VoIP Dial-Around to Connect 911 Calls

14.5.2.1 What you need for this project:

• Asterisk

• VoIP trunk service from an Asterisk-friendly TSP like VoicePulse

This is very much a hack! The FCC and your local public safety offices would much prefer you to use a solution that supports ALI, like those discussed earlier. But if you absolutely cannot support ALI by providing a POTS line or PRI, this project shows you how to route 911 calls using only a VoIP TSP and Asterisk.

If you use a service such as VoicePulse Open Access, then you are permitted to have a single SIP call ongoing at any time. If your VoIP trunk has this restriction, then dialing 911 from one phone while that trunk is in use won't result in a connection to the emergency dispatcher. Instead, you'll just get a busy signal. That wouldn't be good.

Fortunately, Asterisk allows you to " hijack " channels in priority situations such as a 911 call. The dial-plan command that does the job is SoftHangup( ) . You supply it with the channel name , and it hangs up the channel so a call can be originated on it. So, a very rough hack to hang up the line and grab it to make a 911 call would be as follows :

 exten => 911,1,SetVar(LocalPSAP=440-361-9000)     exten => 911,2,SoftHangup(SIP/VOICEPULSE)     exten => 911,3,Dial(SIP/VOICEPULSE/${LocalPSAP}) 

The second priority in this example hangs up the channel, while the third priority places a call to the local public safety answering point, whose phone number has been stored in ${LocalPSAP} with a SetVar command in priority 1.

This is fine when you have only one SIP trunk channel at your disposal for 911 calls, but if you have more than one, you wouldn't want to automatically hang up a channel based on some proprietary setting in the dial-plan. The ChanIsAvail( ) command will help us determine which of several SIP trunk channels can be used to place the callkind of like an outbound hunt group. Consider this dial-plan snippet:

 exten => 911,1,ChanIsAvail(SIP/VOICEPULSE1&SIP/VOICEPULSE2)     exten => 911,2,SetVar(LocalPSAP=440-361-9000)     exten => 911,3,Dial(${AVAILCHAN}/${LocalPSAP})     exten => 911,4,Hangup(  )     exten => 911,102,SoftHangup(SIP/VOICEPULSE1)     exten => 911,103,Dial(SIP/VOICEPULSE1/${LocalPSAP}) 

In this example, priority 1 checks to see if either of the two named SIP channels is available (these correspond to SIP peers in sip.conf ). If one is available, its channel name is stored in ${AVAILCHAN} and processing continues at the next priority, 2.

Priority 2 sets the phone number of the public safety dispatcher as in the previous example. Priority 3 dials that number to connect the 911 call on the available SIP channel.

If no channels are available in priority 1, the priority becomes 1+101, or 102. Since no channels are available, priority 102 hangs up a channel arbitrarily so priority 103 can place the emergency call.

14.5.3. Administrator Tools

In legacy telephony, the tools of the system administrator ranged from a primitive serial terminal all the way up to a dedicated desktop software application that allowed administrative control over the phone system. Traditional PBX CPUs, such as those made by old-schoolers Isoetec, AT&T, and Executone, used a 2,400-baud serial connection to an RS-232 port for management of channels, trunks, and subscribers.

Later model phone systems offered dedicated Windows-based software for managing these things. Most recently, the administrator tools have become web-based. Administering phone systems has become easier and easier, even as PBX systems have grown increasingly feature rich. Commercial softPBX platforms extend telephony administration further than ever before by using desktop and web-based applications with CTI to give administrators point-and-click power.

14.5.3.1 Asterisk's administrative interface

Asterisk doesn't come with any administrative applications other than the (rather limited) Astman. As a result, if you want to administer Asterisk, you're going to be making a lot of visits to the command line and a host of text-based config files, just as we've done in many of the projects herein.

This makes Asterisk administration more akin to an old-school, fridge - sized PBX than to a next-generation VoIP telephony platform. Fortunately, some excellent third-party solutions exist to fill the void. Some are simple command-line tools, while others are XML applications that run on softphones. The are even full-blown, turn-key web-administration solutions for Asterisk.

14.5.3.2 AMP

Probably the most ambitious one of these is the Asterisk Management Portal, or AMP. This package is a set of Perl and PHP scripts that not only automate administration of the Asterisk PBX via a web interface, but truly transform it into a turnkey, entry-level PBX product suitable for deployment to offices with a single inbound trunk group. When you load AMP onto an Asterisk PBX system, it uses MySQL to store the system configuration and dial-plan, and a group of custom Perl scripts to mirror that stored configuration with the active configuration of Asterisk.

Even though Asterisk no longer supports MySQL for CDR, because of license conflicts, AMP still uses MySQL to store its dial-plan.

AMP turns the Asterisk PBX into a basic, small-office phone system that supports any number of SIP or IAX phones and any number of Zaptel channels. The Zaptel channels are all considered "inbound" and the SIP/IAX phones are all considered private extensions. Extensions can be grouped together in ring groups very easily using the web interface, as can simple IVR call flows and call-parking zones. You can download AMP from http:// sourceforge .net/projects/amportal.

14.5.3.3 AM

Asterisk Manager (not Astman and not Asterisk Manager API, which are different pieces of software) provides a simple, Perl-driven web interface for configuring Asterisk's dial-plan and SIP peer configurations (see Figure 14-2). Intended to deal with adds, moves, and changes of private extensions, AM gives you more flexibility in programming the dial-plan than AMP. But AM is more of a convenience tool for an administrator who's already familiar with Asterisk than it is a total turnkey solution. You can get AM from http://astman.sourceforge.net.

14.5.3.4 AstConsoleAstConsole

These packages provide those running Asterisk on Mac OS X the ability to maintain SIP extensions and monitor the PBX in a friendly Aqua interface. AstConsole can also connect (via Asterisk Manager API) to remote Asterisk servers to manage and monitor.

Figure 14-2. The Asterisk Management Portal web interface

The VoicePulse Connect Assistant provides Mac system operators with an easy GUI for configuring trunk connections to VoicePulse's long-distance termination service. These software packages can be downloaded from http://www. sunrise -tel.com/.

14.5.3.5 Open H.323 administrative GUIs

A number of GUI add-ons for Open H.323 exist. A simple Java-based gatekeeper status monitoring tool that allows you to disconnect registered users is available from http://unix. freshmeat .net/projects/gkgui. For the GnuGK, there's a Windows-based console snap-in that allows remote observation and control of the gatekeeper. It's called GnuGK Control Center, and you can download it from http://www.gnugk-cc.com.

14.5.3.6 Other administrator GUI tools

For more sources of tasty, GUI admin goodies , take a look at the supplier references in Chapter 16.