1 / 23

A prototype i3 VoIP PSAP implementation

A prototype i3 VoIP PSAP implementation. Henning Schulzrinne, Anshuman Rawat, Matthew Mintz-Habib, Xiaotao Wu and Ron Shacham Dept. of Computer Science Columbia University Walt Magnussen, Willis Marti, Patti Urbina Chris Norton, Clark Yang, Karthik Kannan

herbst
Download Presentation

A prototype i3 VoIP PSAP implementation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A prototype i3 VoIP PSAP implementation Henning Schulzrinne, Anshuman Rawat, Matthew Mintz-Habib, Xiaotao Wu and Ron Shacham Dept. of Computer Science Columbia University Walt Magnussen, Willis Marti, Patti Urbina Chris Norton, Clark Yang, Karthik Kannan Internet2 Technology Evaluation Center Texas A&M University NENA-VON VoIPCIF Santa Clara, CA December 2004

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

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

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

  5. Components No endorsement implied – other components likely will work as well

  6. Prototype * gray features in progress.

  7. Demo prototype Ft. Wayne, IN: August 17, 2004

  8. Call routing • PSAP lookup depends on location type: • DNS for civic locations • Mapinfo Envinsa for geo location

  9. Detail: I3 - DNS-based resolution DHCP INFORM psap.state.vt.gov SIP w/location MAC  loc Perl sip-cgi script psap.state.vt.gov DNS NAPTR: addison.vt.us algonquin-dr.addison.vt.us … proprietary TCP-based protocol 151.algonquin-dr.addison.vt.us.sos-arpa.net

  10. Call taker setup SIPc client receives calls GeoLynx software displays caller location

  11. sipc receives call

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

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

  14. Using IP phones for voice redundant sipd’s XML display shows caller location Apache web server XML display with HTTP retrieval

  15. INVITE REFER INVITE media info INVITE INVITE REFER REFER INVITE media info Emergency call conferencing PSAP brings all related parties into a conference call Hospital Fire department INVITE Conference server Recorder 3rd party call control PSAP Caller

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

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

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

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

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

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

  22. Project Responsibilities • Columbia University – development of I3 components. • TAMU ITEC – I3 field trial and coordination with PSAP entities. • Cisco and Nortel – Support I2 installations

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

More Related