1. Next-Generation Emergency Calling (NG911) Henning Schulzrinne Dept. of Computer Science, Columbia University, New York hgs@cs.columbia.edu (with Jong Yul Kim, Wonsang Song, Anshuman Rawat, Matthew Mintz-Habib, Amrita Rajagopal and Xiaotao Wu; LoST is joint work with Hannes Tschofenig, Andrew Newton and Ted Hardie) SIP Workshop April 25, 2008

2. April 20082 Outline Emergency calling –the challenge of two transitions: mobility and VoIP –Emergency alerts Emergency alerting –beyond siren replacement Emergency coordination –going beyond ad hoc networks emergency call coordination alert

3. April 20083 Modes of emergency communications emergency call civic coordination emergency alert (“inverse 911”) dispatch information “I-am-alive”

4. April 20084 Background on 9-1-1 Established in Feb. 1968 –1970s: selective call routing –late 1990s: 93% of population/96% of area covered by 9-1-1 –95% of 9-1-1 is Enhanced 9-1-1 –US and Canada Roughly 200 mio. calls a year (6 calls/second) –1/3 wireless 6146 PSAPs in 3135 counties –most are small (2-6 call takers) –83.1% of population have some Phase II (April 2007) “12-15 million households will be using VoIP as either primary or secondary line by end of 2008” (NENA) http://www.nena.org/

5. April 20085 Local Switch Automatic Number Identification Automatic Location Identification Collaboration between local phone providers and local public safety agencies

6. April 20086 Why is this a hard problem? More than just installing software and buying new PCs –mapping (GIS systems can’t use Google Maps) –training Decentralized system –6000+ PSAPs –estimated cost of upgrade: $340m (=> $57,000/PSAP) 233 million US mobile phone subscribers Cost-plus ILEC MSAG –the MSAG update protocol: fax –no incentive to upgrade –no incentive to cooperate with CLECs and VSPs –unclear ownership of database Issues of control and “turf” –consolidation efficiency vs. local knowledge –funding: state vs. county vs. town (volunteer fire department)

7. April 20087 What makes VoIP 112/911 hard? POTSPSTN-emulation VoIPend-to-end VoIP (landline) phone number limited to limited area landline phone number anywhere in US (cf. German 180) no phone number or phone number anywhere around the world regional carriernational or continent- wide carrier enterprise “carrier” or anybody with a peer- to-peer device voice provider = line provider (~ business relationship) voice provider ≠ ISP national protocols and call routing probably North America + EU international protocols and routing location = line locationmostly residential or small business stationary, nomadic, wireless

8. April 20088 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)

9. April 20089 Phase 1Phase 2Phase 3 Phase 4 Four Phases of Emergency Calls

10. April 200810 Emergency numbers Each country and region has their own –subject to change Want to enable –traveler to use familiar home number –good samaritan to pick up cell phone Some 3/4-digit numbers are used for non-emergency purposes (e.g., directory assistance) Emergency number

11. April 200811 Service URN Idea: Identifiers to denote emergency calls –and other generic (communication) services Described in IETF ECRIT draft draft-ietf-ecrit-service-urn Emergency service identifiers: sos General emergency services sos.animal-control Animal control sos.fire Fire service sos.gas Gas leaks and gas emergencies sos.marineMaritime search and rescue sos.mountainMountain rescue sos.physicianPhysician referral service sos.poisonPoison control center sos.policePolice, law enforcement

12. April 200812 Services under discussion “211” (social service referral), “311” (non-emergency government services) Emergency services (first responders) –used by PSAP, not civilians –e.g., urn:service:es:police Non-emergency commercial services –urn:service:restaurant.italian –urn:service:transportation.taxi

13. April 200813 Location, location, location,... Voice Service Provider (VSP) sees emergency call but does not know caller location ISP/IAP knows user location but does not handle call

14. April 200814 Location determination options MethodCDP or LLDP- MED DHCPHELDGPSmanual entry LayerL2L3L7 (HTTP)-user advantagessimple to implement built into switch direct port/room mapping simple to implement network locality traverses NATs can be operated by L2 provider accurate mobile devices no carrier cooperation no infrastructure changes no carrier cooperation problemsmay be hard to automate for large enterprises mapping MAC address to location? mapping IP address to switch port? indoor coverage acquisition time fails for mobile devices unreliable for nomadic UseEthernet LANsEnterprise LANs Some ISPs DSL, cablemobile devicesfall back

15. April 200815 Components of NG911 system Location determination Call identification --> service URNs Call routing --> LoST PSAP functionality –IVR, logging, multimedia conferencing, … LoST (public) LoST (private) Internet ESN (county, state, …) PSAP

16. April 200816 UA recognition & UA resolution INVITE urn:service:sos To: urn:service:sos Route: sip:psap@leonianj.gov 9-1-1 (dial string) mapping INVITE urn:service:sos To: urn:service:sos Route: sip:fire@leonianj.gov leonianj.gov mapping may recurse location information DHCP LLDP-MED identification TBD

17. April 200817 UA recognition & proxy resolution 9-1- 1 mapping INVITE urn:service:sos To: urn:service:sos INVITE urn:service:sos To: urn:service:sos Route: sip:psap@leonianj.gov (outbound proxy) provider.com

18. April 200818 UA recognition & proxy resolution (proxy location determination) 9-1- 1 mapping INVITE urn:service:sos To: urn:service:sos INVITE sip:psap@leonianj.gov To: urn:service:sos Geolocation: provider.com

19. April 200819 Proxy recognition & proxy resolution 9-1- 1 mapping INVITE sip:911@provider.com;user=phone To: sip:911@provider.com;user=phone INVITE urn:service:sos To: sip:911@provider.com;user=phone Geolocation: Route: sip:psap@leonianj.gov provider.com

20. LoST: A Protocol for Mapping Geographic Locations to Public Safety Answering Points Henning Schulzrinne, Hannes Tschofenig, Andrew Newton, Ted Hardie

21. April 200821 Problem: Finding the correct PSAP Which PSAP should the e-call go to? –Usually to the PSAP that serves the geographic area –Sometimes to a backup PSAP –If no location, then ‘default’ PSAP –solved by LoST

22. April 200822 LoST functionality Mapping of location to parameters (e.g., URL) Civic as well as geospatial queries –civic address validation Recursive and iterative resolution Pre-querying and caching for efficiency and robustness –query ahead of emergency call (e.g., at boot time for stationary devices) –no re-querying while moving Fully distributed and hierarchical deployment –can be split by any geographic or civic boundary –same civic region can span multiple LoST servers Indicates errors in civic location data  debugging –but provides best-effort resolution Supports overlapping service regions –e.g., contested regions (Kashmir, Palestine, Taiwan,...)

23. April 200823 LoST: Location-to-URL Mapping cluster serves VSP 2 NY US NJ US Bergen County NJ US 123 Broad Ave Leonia Bergen County NJ US cluster serving VSP 1 replicate root information search referral root nodes Leonia NJ US sip:psap@leonianj.gov VSP 1 LoST

24. April 200824 LoST Architecture T1 (.us) T2 (.de) T3 (.dk) G G G G G broadcast (gossip) T1:.us T2:.de resolver seeker 313 Westview Leonia, NJ US Leonia, NJ  sip:psap@leonianj.gov tree guide

25. April 200825 LoST Properties Minimizes round trips: –caching individual mappings –returns coverage regions (“hinting”) civic (“all of C=US, A1=NY”) or geo (polygon) Facilitates reuse of Transport Layer Security (TLS) Returns emergency service numbers for a region Query for supported Service URN types

26. April 200826 LoST: Query example Uses HTTP or HTTPS <findService xmlns="urn:…:lost1” recursive="true" serviceBoundary="value" > Germany Bavaria Munich Neu Perlach 96 urn:service:sos.police

27. April 200827 LoST “Find Service” response/warning example München Polizei-Abteilung urn:service:sos.police Germany Bavaria Munich 81675 sip:munich-police@example.com 110

28. April 200828 Validation Determine if civic location is (partially) valid Returns XML tag names of components: –validated and used for mapping –no attempt to validate (and not used) e.g., house number –known to be invalid Return (default) PSAP based on validated elements May return list of guesses for correct addresses, if requested country A1 A3 A6 PC

29. April 200829 Advanced LoST functionality Get list of (emergency) services supported –by server –for a region Obtain service regions –identified by globally-unique tag -34.407 150.883 urn:service:sos urn:service:sos.ambulance urn:service:sos.animal-control

30. April 200830 INVITE urn:service:sos SIP/2.0 To: urn:service:sos Call-ID: 763782461@192.168.1.106 Via: SIP/2.0/TCP 192.168.1.106:4064;rport Content-Type: multipart/mixed; boundary From: sip:caller@irt.cs.columbia.edu Contact: CSeq: 1 INVITE Content-Length: 1379 ------ =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY= MIME-Version: 1.0 content-Type: application/sdp Content-Transfer-Encoding: 8bit v=0 o=eddie 1127764654 1127764654 IN IP4 192.168.1.106 s=SIPC Call c=IN IP4 160.39.54.70 t=0 0 m=audio 10000 RTP/AVP 0 3 m=video 20000 RTP 31 SDP header fields request line ------- =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY= MIME-Version: 1.0 Content-Type: application/pidf+xml Content-Transfer-Encoding: 8bit <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0" entity="sip:calltaker_ny2@irt.cs.columbia.edu"> us ny new york amsterdam 1214 Manual sip:eddie@160.39.54.70:5060 2005-09-26T15:57:34-04:00 ------- =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY=-- PIDF-LO SIP message for Location Info.

31. April 200831 Using LoST for non-emergency services Emergency services: “who serves location X” –one answer desired Non-emergency services: “what services are within radius R of location X” –restaurants, banks, ATMs, hospitals Can use LoST with minor extensions: –shapes allow queries like “show restaurants within Prague city limits” (polygon) or “within 5 miles of where I am” (circle) –restrict number of responses –allow multiple responses

32. April 200832 Current activities IETF ECRIT working group –finishing LoST, architecture, synchronization NENA –architecture –transition documents –web services for queries DOT –NG911 project with BAH, Columbia & TAMU as sub-contractor –building proof-of-concept, based on earlier NTIA work –“National architecture for NG9-1-1 system” & “Transition plan for NG9-1- 1 implementation” Lots of other activities –e.g., semi-annual Emergency Services Coordination Workshop

33. April 200833 NG9-1-1 Prototype Architecture RoutingLocation PSTN

34. April 200834 LoST Cluster SIP proxy call taker SOS caller (1)Location Location + Service Identifier (2) INVITE PSAP URL To: urn:service:sos (5) INVITE PSAP URL To: urn:service:sos (6)(4) dial emergency dial- string or push emergency button Emergency Call Flow (3) PSAP URL + emergency dial-string INVITE call taker From: caller (7)(7) Media Stream

35. April 200835 Calltaker screen Columbia SIPc as SIP UA Mapping software to display caller’s location –Geolynx –Google Maps

36. April 200836 Call logs and recorded sessions

37. April 200837 NG911 trial: Lessons learned Tested NG911 prototype in 3 PSAPs in TX and VA Surprise: PSAP is really a conferencing system –LanguageLine, first responders, … Surprise: no uniform incident description –every jurisdiction uses their own variation and level of detail What is desirable behavior –rather than current behavior –e.g., for transfer, overflow Need to integrate call taker management –presence (availability) –a specialized call center Special requirements: partial mute –not typically supported on conference servers

38. April 200838 Conclusion Need for loosely-coupled suite of tools for emergency coordination –connecting rather than stovepipe systems –narrow interfaces rather than global master architecture NG911 as opportunity to update emergency calling –robustness –features (multimedia, connectivity) –COTS Need for large-scale experiments, not yet another ad- hoc network paper –cooperation with non-technical users

39. April 200839 More information A VoIP Emergency Services Architecture and Prototype –M. Mintz-Habib, A. Rawat, H. Schulzrinne, and X. Wu, ICCCN 2005, Oct. 2005 An Enhanced VoIP Emergency Services Prototype –Jong Yul Kim, Wonsang Song, and Henning Schulzrinne, ISCRAM 2006, May 2006 Providing emergency services in Internet telephony –H. Schulzrinne & K. Arabshian, IEEE Internet Computing, May/June 2002 Requirements for Emergency Context Resolution with Internet Technologies, draft-ietf-ecrit- requirements Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information, RFC 4776 Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information, RFC 3825 A Presence-based GEOPRIV Location Object Format, RFC 4119 A Uniform Resource Name (URN) for Services, draft-ietf-ecrit-service-urn LoST: A Location-to-Service Translation Protocol, draft-ietf-ecrit-lost Best current practices for third party call control (3pcc) in the session initiation protocol (SIP), RFC 3725 GETS: http://gets.ncs.gov/ LoST server at http://honamsun.cs.columbia.edu/lost_homepage/ NG911 project information at http://ng911.tamu.edu and DOT 911 project http://ng911.tamu.edu DOT 911 project