1 / 38

Emergency Calling in SIP

Emergency Calling in SIP. Henning Schulzrinne (with Anshuman Rawat, Matthew Mintz-Habib, Amrita Rajagopal and Xiaotao Wu) Dept. of Computer Science Columbia University hgs@cs.columbia.edu. Overview. VoIP emergency communications What makes emergency calling hard? Stages of deployment

andrew
Download Presentation

Emergency Calling in SIP

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. Emergency Calling in SIP Henning Schulzrinne (with Anshuman Rawat, Matthew Mintz-Habib, Amrita Rajagopal and Xiaotao Wu) Dept. of Computer Science Columbia University hgs@cs.columbia.edu Emergency calling

  2. Overview • VoIP emergency communications • What makes emergency calling hard? • Stages of deployment • I1: quick fixes • I2: backward-compatible • I3: end-to-end IP • Initial prototype • NENA + IETF efforts Emergency calling

  3. VoIP emergency communications emergency call emergency alert (“inverse 911”) dispatch civic coordination Emergency calling

  4. E911 TANDEM OFFICE SUBSCRIBER SRDB END OFFICE ANI PSAP COMMONEQUIPMENT ALI HOST ATTENDENT POSITIONS 7 3 7 2 5 4 5 6 1 Current wireline calls dial 911, 112 route call to right PSAP map ANI to civic location (Brian Rosen) Emergency calling

  5. MSC ESNE (Selective Router) Cellsite Ai Di (ISUP) CAMA CRDB PSAP E12 E3 (ANSI-41) (ANSI-41) E11 (LSP) PDE MPC ESME (ALI Database) E5 E2 (ESP) MSC Mobile Switching Center MPC Mobile Position Center CRDB Coordinate Routing Database PDE Position Determining Entity Wireless (Phase II) Calls (Brian Rosen) Emergency calling

  6. Components of emergency calling now transition all IP Contact well-known number or identifier 112 911 112 911 dial 112, 911 signal sos@ Route call to location-appropriate PSAP selective router VPC DNS Deliver precise location to call taker to dispatch emergency help phone number  location (ALI lookup) in-band  key  location in-band Emergency calling

  7. What makes VoIP 112/911 hard? Emergency calling

  8. The core problem VSP sees emergency call but does not know caller location ISP/IAP knows user location but does not handle call Emergency calling

  9. More than pain… • Multimedia from the caller • video capture from cell phones • video for sign language • text messaging and real-time text for the deaf • Data delivery • caller data: floor plan, hazmat data, medical alerts • measurement data input: automobile crash data, EKGs, … • Delivering video to the caller • e.g., CPR training • Load balancing and redundancy • currently only limited secondary PSAP • VoIP can transfer overload calls anywhere • Location delivery • carry location with forwarded and transferred calls • multiple location objects (civic + geo) Emergency calling

  10. Core long-term requirements • Media-neutral • voice (+TDD) first, IM and video later • Work in systems without a voice service provider • many enterprises will provide their own local voice services • Allow down-stream call data access • as well as access to other “tertiary” data about the incident • Globally deployable • independent of national emergency number (9-1-1, 1-1-2, etc.) • respect jurisdictional boundaries – minimize need for cross-jurisdictional coordination • allow usage even if equipment and service providers are not local • travel, imported equipment, far-flung locations • Testable: • verifiable civic addresses (“MSAG validation”) • call route validation • Secure and reliable Emergency calling

  11. Staged deployment • ~6,134 PSAPs in North America • average 2-3 active call takers each • some serve town, some large parts of a state • only ~30% of PSAPs can receive geo coordinates • 30-40% may be voice only • many using 1970s telecom technology • “CAMA” (operator) trunks • limited to delivering 8 (regional) or 10 digits (national) of information • already facing pressure from supporting cellular services • Phase I (cell tower and face) and Phase II (caller geo location) • EU: smaller number of PSAPs, but often without location delivery • Initial version (“I1”): • dial 10-digit administrative number • like telematics services • does not deliver caller location to PSAP Emergency calling

  12. Three stages to VoIP 911 Emergency calling

  13. IP domain Emergency Services Provider Network PSTN E9 - 1 - 1 Selective Call server/ Router ESGW(s ) proxy server VPC SRDB VPC VPC DHCP ALI ALI DB ESZ DB LIS RDB MSAG VDB DBMS DNS I2 architecture (draft) Routing Proxy & Redirect server(s ) v6 v4 v5 v4 E9 - 1 - 1 PSAP Selective Router v1 IP Domain v2 v2 User Agent v - e2 v0 v8 v3 location information service v7 VoIP positioning center routing database validation database Emergency calling

  14. I3: Location-based call routing – UA knows its location GPS INVITE sips:sos@ 48° 49' N 2° 29' E outbound proxy server DHCP 48° 49' N 2° 29' E  Paris fire department Emergency calling

  15. I3 (long-term) architecture components • Common URL for emergency calls • sips:sos@home-domain • Convey local emergency number to devices • Allow devices to obtain their location • directly via GPS • indirectly via DHCP (MAC  switch port  location database) • on LAN via LLDP (802.1ab, TIA LLDP-MED) • initially, often through manual configuration • Route calls to right destination • using look-up in device or proxy Emergency calling

  16. Location, location, location • Location  locate right PSAP & speed dispatch • In the PSTN, local 9-1-1 calls remain geographically local • In VoIP, no such locality for VSPs • most VSPs have close to national coverage • Thus, unlike landline and wireless, need location information from the very beginning • Unlike PSTN, voice service provider doesn’t have wire database information • VSP needs assistance from access provider (DSL, cable, WiMax, 802.11, …) Emergency calling

  17. Options for location delivery • L2: LLDP-MED (standardized version of CDP + location data) • periodic per-port broadcast of configuration information • L3: DHCP for • geospatial (RFC 3825) • civic (draft-ietf-geopriv-dhcp-civil) • L7: proposals for retrievals • by IP address • by MAC address • by identifier (conveyed by DHCP or PPP) Emergency calling

  18. DHCP for locations • modified dhcpd (ISC) to generate location information • use MAC address backtracing to get location information 8:0:20:ab:d5:d DHCP server CDP + SNMP 8:0:20:ab:d5:d 458/17 DHCP answer: sta=DC loc=Rm815 lat=38.89868 long=77.03723 458/17  Rm. 815 458/18  Rm. 816 Emergency calling

  19. Location-related problems • Delivery • How does call or end system get location information? • Validation • Does the civic address exist and does it have an associated PSAP? • “MSAG validation” • Verification • Is this the real address of the user (rather than an attempt to mislead)? • Privacy • Avoid revealing location information to third parties • Avoid location disclosure outside an emergency call Emergency calling

  20. Columbia/MapInfo prototype • Goal: build prototype VoIP SIP-based emergency calling system • including caller end system • call routing (DNS) • PSAP infrastructure • Use commodity components where possible • Test reliability and redundancy Emergency calling

  21. Components No endorsement implied – other components likely will work as well Emergency calling

  22. Call routing Emergency calling

  23. Call routing proposals • DNS • map civic to label hierarchy • drill-down search for geo • IRIS • whois-like lookup protocol (registry) • LUMP • uses SOAP (web services) • architecture for reliability • no root server – P2P among entry nodes Emergency calling

  24. 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 Emergency calling

  25. IRIS-based resolution <request xmlns="urn:ietf:params:xml:ns:iris1"> <searchSet> <findEconByCivic xmlns="urn:ietf"> <civilAddress> <country>US</country> <A1>New York</A1> <A3>New York</A3> <A6>Broadway</A6> </civilAddress> <service>police</service> </findEconByCivic> </searchSet> </request> • IRIS = modern “whois” search protocol, over BEEP • only specifies query, not update <response xmlns="urn:ietf:params:xml:ns:iris1"> <resultSet> <answer> <emergencyContact xmlns="urn:ietf:“ authority="nyc.example“ registryType="econ1“ entityClass="econ" entityName="nypd"> <displayName>NYPD</displayName> <uri>sip://nypd.example/</uri> </emergencyContact> </answer> </resultSet> </response> Emergency calling

  26. LUMP: Location-to-URL Mapping VSP1 cluster serving VSP1 replicate root information cluster serves VSP2 123 Broad Ave Leonia Bergen County NJ US root nodes NJ US NY US sip:psap@leonianj.gov search referral Bergen County NJ US Leonia NJ US Emergency calling

  27. 3rd party call control Emergency calling

  28. 3rd Party Call Control Flow Emergency calling

  29. Call taker setup SIPc client receives calls GeoLynx software displays caller location Emergency calling

  30. GeoLynx displays location GeoLynx listens for commands from SIPc Emergency calling

  31. 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 Emergency calling

  32. 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 Emergency calling

  33. Current standardization efforts • NENA (National Emergency Number Association) • I2 and I3 architecture • requirements based on operational needs of PSAPs • ETSI OCG – EMTEL • exploratory – also emergency notification • NRIC • goals and long-term architecture • IETF: • individual and SIPPING drafts for identifier, call routing, architecture • SIP and DNS usage • possibly new protocols for lookups • ECRIT WG for mapping part just getting started Emergency calling

  34. draft-taylor-sipping-emerg-scen-01 (expired) scenarios, e.g., hybrid VoIP-PSTN draft-schulzrinne-sipping-emergency-req abstract requirements and definitions draft-schulzrinne-sipping-emergency-arch overall architecture for emergency calling draft-ietf-sipping-sos describes ‘sos’ SIP URI draft-rosen-dns-sos new DNS resource records for location mapping draft-hardie-ecrit-iris uses IRIS for lookup RFC 3825 “Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information” draft-ietf-geopriv-dhcp-civil-06 DHCP option for civic addresses Current IETF documents Emergency calling

  35. Conclusion • Emergency calling services necessary condition for first-line wireline-replacement services • US: large numbers of PSAPs financially exhausted from Phase II wireless support • often 1970s technology – end of bailing wire reached • Long-term opportunity for better services Emergency calling

  36. I2 interfaces Emergency calling

  37. I1.5: Level 3 ESGW solution • uses Level 3 as CLEC to feed ALI information to local ILEC • requires emergency services GW for each tandem • only works for non-ported numbers • does not work for mobile users Emergency calling

  38. I1.5: Global Crossing VoIP 911 transport Emergency calling

More Related