1. NG911 - Next-Generation Emergency Calling Henning Schulzrinne (with Jong Yul Kim, Wonsang Song, Anshuman Rawat, Matthew Mintz-Habib, Amrita Rajagopal and Xiaotao Wu) Dept. of Computer Science Columbia University

2. NG - November 2006 Introduction Emergency calling is a necessary part of consumer voice service –citizen calls PSAP (public safety answering point) for assistance Existing solutions are insufficient –may deliver call to wrong PSAP particularly for nomadic and mobile users –may not deliver location to PSAP –makes it difficult to move call information around e.g., call location to first responder –voice only (+ TDD)

3. NG - November 2006 VoIP emergency communications emergency call dispatch civic coordination emergency alert (“inverse 911”)

4. NG - November 2006 Components of emergency calling Contact well-known number or identifier Route call to location- appropriate PSAP Deliver precise location to call taker to dispatch emergency help nowtransitionall IP 112 911 112 911 dial 112, 911  urn:service:sos selective router VPCDNS phone number  location (ALI lookup) in-band  key  location in-band

5. NG - November 2006 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 location mostly residential or small business stationary, nomadic, wireless

6. NG - November 2006 The core problem Voice Service Provider (VSP) sees emergency call but does not know caller location ISP/IAP knows user location but does not handle call

7. NG - November 2006 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

8. NG - November 2006 Components Location determination Call identification --> service URNs Call routing --> LoST PSAP functionality –IVR, logging, multimedia conferencing, … LoST (public) LoST (private) Internet ESN (county, state, …) PSAP

9. NG - November 2006 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)

10. NG - November 2006 IETF ECRIT working group Emergency Contact Resolution with Internet Technologies Solve four major pieces of the puzzle: –location conveyance (with SIPPING & GEOPRIV) –emergency call identification –mapping geo and civic caller locations to PSAP –discovery of local and visited emergency dial string Not solving –location discovery –inter-PSAP communication and coordination –citizen notification Current status: –finishing general and security requirements –tentative agreement on mapping protocol and identifier –later, to work on overall architecture and UA requirements

11. NG - November 2006 Service URN Idea: Identifiers to denote emergency calls –and other generic (communication) services Described in draft-ietf-ecrit-service-urn-05 (passed WGLC; sent to the IESG) Document defines the following 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. NG - November 2006 ‘counseling’ services urn:service:counselingGeneric counseling service (call center) …:counseling.childrenrun-aways, child abuse …:counseling:mental-healthdiagnostic, treatment, and preventive care … mental health …:counseling:suicidesuicide prevention hotline

13. NG - November 2006 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

14. NG - November 2006 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

15. NG - November 2006 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

16. NG - November 2006 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

17. NG - November 2006 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

18. NG - November 2006 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

19. NG - November 2006 LoST functionality Satisfies the requirements (draft-ietf-ecrit- requirements) for mapping protocols Civic as well as geospatial queries –civic address validation Recursive and iterative resolution 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

20. NG - November 2006 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

21. NG - November 2006 Protocol request (mapping) <findService xmlns="urn:ietf:params:xml:ns:lost1" recursive="true" include="serviceBoundary invalid valid unchecked"> <location profile="urn:ietf:params:lost:location-profile:basic-civic"> <civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> Germany Bavaria Munich Neu Perlach 96 81675 urn:service:sos.police

22. NG - November 2006 LoST “Find Service” response/warning example München Polizei-Abteilung urn:service:sos.police Germany Bavaria Munich 81675 sip:munich-police@example.com xmpp:munich-police@example.com 110 lost:esgw.uber-110.de.example lost:polizei.munchen.de.example

23. NG - November 2006 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

24. NG - November 2006 Geo support Which geo types should be supported? –Point (3D) –Polygon?  may yield ambiguous answers –more complicated shapes? Current proposal –always include 2D-point –may include other shapes

25. NG - November 2006 LoST architecture 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

26. NG - November 2006 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

27. NG - November 2006 Conclusion Opportunity to fundamentally restructure emergency communications –higher reliability with large-scale disasters –lower cost –richer interaction IETF ECRIT and SIP working group converging on core protocols –service URNs –SIP location conveyance –LoST