A prototype i3 VoIP PSAP implementation

Henning Schulzrinne, Anshuman Rawat, Matthew Mintz-Habib, Xiaotao Wu and Ron Shacham

Dept. of Computer ScienceColumbia University

Walt Magnussen, Willis Marti, Patti UrbinaChris Norton, Clark Yang, Karthik KannanInternet2 Technology Evaluation Center

Texas A&M University

NENA-VON VoIPCIFSanta Clara, CADecember 2004

Overview

A quick review of I3 assumptions Goals of project Prototype architecture and experiences Scaling and robustness Next steps

Our I3 assumptions

VoIP (SIP) capable end systems SIP-capable PSAP Location inserted by origin

outbound proxy originating device (e.g., via DHCP) either geospatial or civic location

Goals of prototype

Provide a platform for quick experimentation Determine easy vs. hard parts of problem Experiment with redundancy and robustness Use off-the-shelf components where possible Modes

Phase II wireless (based on ALI lookup) I3 VoIP end-to-end, with in-band location

information

Components

sipd SIP proxy server

database-backed DNS server

SIP phone

web server

SQL database for call routing

sipc SIP user agent

geo-coding, PSAP boundaries

GIS software for call location plotting

No endorsement implied – other components likely will work as well

* gray features in progress.

Prototype

911112

sip:sos@domainw/location or w/out location

geo location

POTS/Wireless Network

IP Network

911

IP Gateway

sip:sos@domainwithout location

Envinsa Server

sip:psap@domainwith location

location

GeoLynx Display

ALI ServerDHCP Server

DNS Server**

DHCP InformMAC Address

Location Info

TCP Socket Telephone Number

PSAP Info

HTTP SOAPLatitude/Longitude

Location Info

VerifiedLocation Info

civil location**

Ft. Wayne, IN: August 17, 2004

Demo prototype

911112

sip:sos@domainwith location

geo location

POTS/Wireless Network

IP Network

911

IP Gateway

sip:sos@domainwithout location

ALI Server Envinsa Server

TCP SocketTelephone Number

LocationInfo

PSAPInfo HTTP SOAP

Latitude/Longitude

sip:psap@domainwith location

location

GeoLynx Display

Call routing

PSAP lookup depends on location type: DNS for civic locations Mapinfo Envinsa for geo location

Detail: I3 - DNS-based resolution

151.algonquin-dr.addison.vt.us.sos-arpa.net

Perl sip-cgi script

DNS NAPTR:addison.vt.usalgonquin-dr.addison.vt.us…

psap.state.vt.gov

psap.state.vt.gov

proprietaryTCP-basedprotocol

DHCP INFORM

SIP w/locationMAC loc

SIPc client receives calls GeoLynx software displays caller location

Call taker setup

sipc receives call

GeoLynx receives commands and displays location.Caller location displayed on map.Caller information displayed in GUI.GeoLynx listens for commands from SIPc…

GeoLynx displays location

Demo Ft. Wayne, IN (August 17, 2004)

Using IP phones for voice

XML displaywith HTTP retrieval

XML displayshows caller location

redundant sipd’s

Apacheweb server

Emergency call conferencing

INVITE

3rd partycall control

INVITE

INVITE

REFER

REFER

REFER

Conferenceserver

PSAP

Recorder

Firedepartment

HospitalPSAP brings all related parties into a conference call

INVITE

media info

INVITEmedia info

Caller

INVITE

Scaling

NENA: “estimated 200 million calls to 9-1-1 in the U.S. each year”

approximately 6.3 calls/second if 3 minute call, about 1,200 concurrent calls

typical SIP proxy server (e.g., sipd) on 1 GHz PC can handle about 400 call arrivals/second

thus, unlikely to be server-bound

Next steps for our prototype

Custom user interface for call taker Add voice recording and conferencing

using our software conference server “Data mining”

collect and display statistical data about calls Integration of police/fire/EMS

direct transmission of call-related data via simple IM application requires only Internet access

Difficulties

Difficult to get good test environment access to PDE IP access to ALI (often, jury-rigged telnet

interfaces) access to MSAG and ALI data “friendly” PSAPs one option

but open, network-accessible test lab would be better longer-term: may need “plug fests”

see SIPit effort – vendors collaborating in friendly, non-public interop test efforts rapid elimination of protocol and implementation problems

Conclusion

A first prototype of I3 PSAP integrates Phase II wireless call delivery

Shown that it is possible to integrate existing GIS applications with I3

Based on COTS technology, with modest modifications

Additional operational support in progress

NTIA VoIP i3 PSAP Project

Partners Texas A&M University Columbia University (Dr. Henning Schulzrinne co-PI) The University of Virginia National Emergency Number Association (NENA) The State of Texas Commission on State Emergency

Communications (CSEC) The State of Virginia Division of Public Safety Communications of

the Virginia Information Technologies Agency (VITA). Internet 2 Brazos County Texas E911 District City of College Station Texas Cisco Nortel

Project Goals & Duration

To build and install in an operational PSAP an i3 PSAP prototype system

Provide functional comparison to existing i2 systems

Provide VoIP E911 workshops designed to expand Internet based 911 services awareness

Project to begin on 1 October, 2004 and conclude on 31 September, 2006

Project Responsibilities Columbia University – development of I3

components. TAMU ITEC – I3 field trial and coordination

with PSAP entities.

Cisco and Nortel – Support I2 installations

Thank you – Now for Questions Contact info –

Walt Magnussen Telecom@tamu.edu Ph 979-845-5588

Henning Schulzrinne hgs@cs.columbia.edu Ph 212-939-7005