1. NG911 project status 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. NG911 project meeting (College Station, February 2006) Options for location delivery GPS L2: LLDP-MED (standardized version of CDP + location data) –periodic per-port broadcast of configuration information –currently implementing CDP L3: DHCP for –geospatial (RFC 3825) –civic (draft-ietf-geopriv-dhcp-civil) L7: proposals for retrievals –for own IP address ( draft-linsner-geopriv-lcp) –by IP address –by MAC address –by identifier (conveyed by DHCP or PPP)

3. NG911 project meeting (College Station, February 2006) Phase 3 : Routing to Correct PSAP

4. NG911 project meeting (College Station, February 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

5. NG911 project meeting (College Station, February 2006) Emergency identifier requirements Direct user interface, without “dialing” number –but do NOT require user to input this identifier directly –i.e., separate user interface from protocol identifier! Reach emergency help in any country, without knowledge of local numbers –also, universally recognizable by proxies regardless of location of caller Deployable incrementally –even if not all entities support the mechanism Testable without impacting PSAP (human) resources

6. NG911 project meeting (College Station, February 2006) Defining an (emergency) services URN URN = universal resource name –identifies resource, not its network location –translated by protocol (e.g., DNS) into location(s) New: service URN urn:service:service Identifies a generic service, not a specific resource Uses mapping protocol: –{identifier, location}  URL(s) Can be used anywhere a URN or URL is allowed, e.g.: –web pages –result returned by mapping protocol –request and To URI in SIP For emergency services: –urn:service:sos, urn:service:sos.fire, urn:service:sos.police, urn:service:sos.marine, urn:service:sos.mountain, urn:service:sos.rescue, urn:service:sos.poison, urn:service:sos.suicide, urn:service:sos.mental-health Could also be used for other services: urn:service:directory

7. NG911 project meeting (College Station, February 2006) UA recognition & UA resolution INVITE sip:psap@leonianj.gov To: urn:service:sos 9-1-1 (dial string) mapping INVITE sip:psap@leonianj.gov To: urn:service:sos leonianj.gov mapping may recurse location information DHCP LLDP-MED

8. NG911 project meeting (College Station, February 2006) UA recognition & proxy resolution 9-1- 1 mapping INVITE urn:service:sos To: urn:service:sos INVITE sip:psap@leonianj.gov To: urn:service:sos provider.com

9. NG911 project meeting (College Station, February 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 Location: provider.com

10. NG911 project meeting (College Station, February 2006) Proxy recognition & proxy resolution 9-1- 1 mapping INVITE sip:911@provider.com;user=phone To: sip:911@provider.com;user=phone INVITE sip:psap@leonianj.gov To: sip:911@provider.com;user=phone Location: provider.com

11. NG911 project meeting (College Station, February 2006) Phase 1 & 2 : Identifying Emergency Calls & Determining Caller Location

12. NG911 project meeting (College Station, February 2006) DHCP for locations modified dhcpd (ISC) to generate location information use MAC address backtracking to get location information DHCP server DHCP answer: 0:US:1:CA:2:LOS ANGELES: 3:LONG BEACH:6:HYATT AVE:19:300 DHCPINFORM 00:11:20:9d:a0:03

13. NG911 project meeting (College Station, February 2006) DHCP for locations (cont.) # ip_phone 1 host sip0011209da003 { next-server ng911serv.irt.cs.columbia.edu; hardware ethernet 00:11:20:9d:a0:03; fixed-address 128.59.17.59; option tftp-server-name "128.59.19.174"; option host-name "sip0011209da003"; #0:US:1:CA:2:LOS ANGELES:3:LONG BEACH:6:HYATT AVE:19:300 option loc-civil 55:53:2:1:2:43:41:2:b:4c:4f:53:20:41:4e:47:45:4c:45:53:3:a:4c:4f:4e:47:20:42: 45:41:43:48:6:9:48:59:41:54:54:20:41:56:45:13:3:33:30:30; } dhcpd.conf

14. NG911 project meeting (College Station, February 2006) Emergency dial strings ~60 different dial strings in use –some countries separate fire/police/…, others don’t –some are used for other services PBX, information, prefix, … Needs to support both home and visited dial string when traveling Home = dial string at home location of traveler –traveler may not know local conventions Visited = dial string at visited location –fellow tourist picks up phone –babysitter in ex-pat household Configure –via DHCP –via SIP configuration mechanism –via location mapping

15. NG911 project meeting (College Station, February 2006) LUMP: Mapping service URNs + locations to URLs Common problem: –{geo or civic location, service}  set of URLs –e.g., {Broadway/NY, “911”}  fire@psap.nyc.gov –also applies to anything from towing service to pizza delivery Need to be able to validate addresses ahead of emergency –does this street address resolve to a PSAP? –can the ambulance find the address? Service providers don’t trust each other (fully) –e.g., who gets to include Jerusalem in its map –service may depend which warlord you belong to –can’t wait for UN (or ICANN) to create global emergency services database Suggested approach: new distributed mapping protocol –LUMP: location-to-URL mapping protocol –uses SOAP, but special service URLs

16. NG911 project meeting (College Station, February 2006) LUMP: overview Support global-scale resolution of service identifiers (e.g., service URNs) + locations to other URLs Attempts to be reliable and scalable –borrow concepts, but not protocol limitations, from DNS Architecture: “Forest of trees with a cloud above” –avoid root as only deployment alternative Uses standard web services building blocks

17. NG911 project meeting (College Station, February 2006) LUMP: 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

18. NG911 project meeting (College Station, February 2006) LUMP 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

19. NG911 project meeting (College Station, February 2006) Caching Generally, UA caches lookup results –query: “I’m at (X,Y), what’s my PSAP?” –answer: “Your PSAP is sip:psap@town.gov as long as you stay in polygon (X 1,Y 1 ; X 2, Y 2 ; …); this is valid for 12 hours” almost no impact of node mobility on query frequency –same for civic: “as long as you stay on Main Street, your town” civic only relevant for nomadic users –actual PSAP coverage area may be larger  just an optimization Almost always avoids query during emergency call –MAY re-query during call –load distribution via DNS given frequency of calls for one resolver, likely to be no DNS caching anyway Further optimization: query with timestamp (or etag) of last answer –answer: “still the same, thanks for asking”

20. NG911 project meeting (College Station, February 2006) Performance notes US: only about 6 calls/second for whole country –on average, but may spike during mass casualty events Use TCP (or TCP/TLS) for reliability Expect 1-2 queries/day/client Typical: >> 100 queries/second/server –almost all rows will be cached in memory only about 6,000 rows –one server  8,640,000 queries –probably N+1 spared –data center cost: $300/month/server  $0.0003/user/month (1Mq/day)

21. NG911 project meeting (College Station, February 2006) Implementation status Prototype implementation at Columbia University: –includes referrals –both geo and civic coordinates –from draft WSDL (with minor fixes) Server –Axis (Apache) SOAP server –Postgres SQL geo database does polygon intersection Client –Java app (web page) –Tcl (for our SIP client)

22. NG911 project meeting (College Station, February 2006) LUMP geo mapping

23. NG911 project meeting (College Station, February 2006) LUMP: SOAP request

24. NG911 project meeting (College Station, February 2006) Calltaker Routing Using SIP caller preferences/callee capabilities –Example: caller language preference automatically route to call taker who speaks French Accept-Language: fr

25. NG911 project meeting (College Station, February 2006) Phase 4 : Call Presentation

26. NG911 project meeting (College Station, February 2006) Controller (psapd) Flow

27. NG911 project meeting (College Station, February 2006) PSAP interface using GeoLynx or Google Maps as “GIS”

28. NG911 project meeting (College Station, February 2006) Ongoing work (Spring 2006) Track LUMP specification SIPc –DHCP support –DB for CDP –Call history window for call back –Determine if call dropped without normal termination messaging –Call taker blocking others from call SIPc + psapd –Emergency number determination –Civic address validation using MSAG psapd –Transfer to another psapd –TLS support and testing Other –Video push –sipd must handle “486 Busy” from psapd –Assign unique number to each incident –Associate multiple calls with an incident System-wide –Pre-determined limit of simultaneous calls –Incoming Call Queue at the option of the PSAP Incident specific announcements Prioritize calls in queue –Overflow calls to designated backup IP PSAP Indications of overflow for originating and destination PSAP –Adding information in PIDF-LO –Call taker re-bids location information Caller updates location information Re-routing calls when location changes Interaction with external elements –TDD support

29. NG911 project meeting (College Station, February 2006) Conclusion IETF ECRIT working group converging on set of solutions –mapping protocol –emergency identifier –location conveyance –to be done: UA requirements Demo implementation of LUMP Multi-call taker PSAP approximation Working on solving core I3 & PSAP requirements from NENA documents