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) IEEE NY Lecture October 18, 2007

2. IEEE NY2 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. IEEE NY3 Modes of emergency communications emergency call civic coordination emergency alert (“inverse 911”) dispatch information “I-am-alive”

4. IEEE NY4 Outline Emergency calling –the challenge of two transitions mobility and VoIP Emergency alerts Emergency coordination

5. IEEE NY5 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/

6. IEEE NY6 Local Switch Automatic Number Identification Automatic Location Identification Collaboration between local phone providers and local public safety agencies

7. IEEE NY7 911 technology failures NY Times (“An S O S for 911 Systems in Age of High-Tech”), 4/6/07: –“40% of … counties, most of them rural or small-town …, cannot yet pinpoint the location of the cellphone callers, though the technology to do so has been available for at least five years.” “In … Okmulgee, Okla., last November, 4-year-old Graciella Mathews- Tiger died in a house fire after a 911 operator who lacked the technology to pinpoint the call misheard the address.” Phase II wireless; billions of dollars spent In Mississippi, only 1 of out 5 counties –“As it ages, it is cracking, with problems like system overload, understaffing, misrouted calls and bug-ridden databases leading to unanswered calls and dangerous errors.” operator (CAMA) trunks, with 8-digit number delivery MSAG and ALI databases

8. IEEE NY8 911 technology failures, cont’d “In Cherokee County [OK], for instance, the volume has increased by 20 percent a year.” “… answer 911 lines, then transfer calls to dispatchers for individual fire and police departments in the county, a system that requires callers to repeat themselves.” –Inefficient call handling –Vermont dispatch-by-printer “Officials in Riverside County, Calif., fed up with misrouted calls, have been advising residents to call the sheriff or local fire department directly.” –incomplete MSAG –cumbersome ALI update procedures

9. IEEE NY9 911 technology failures, cont’d. “In Bessemer, Ala., city employees could not get through to their own 911 system when a colleague had a seizure, at a time when the city and others like it are struggling to upgrade their systems at a cost of hundreds of thousands of dollars.” –specialized technology supplied by small vendors –almost no R&D “Yet even the newest systems cannot adequately handle Internet-based phone services or text messages, which emerged as the most reliable form of communication during Hurricane Katrina.” –mostly voice-only –plus TDD (TTY), plus deaf are switching to IM

10. IEEE NY10 911 problems “Ellis is accused of a relatively new Internet-related crime called "swatting.” Police believe Ellis, of Mukilteo, Wash., used an online service for the hearing impaired and other high-tech methods to make false reports of escalating violence to police departments across the country. … The false reports ended with SWAT team members taking down innocent people at gunpoint and holding them for questioning.” (Erie Times News, Oct. 17, 2007) –no location reporting for TDDs –no user authentication or meta data

11. IEEE NY11 Dept. of Transportation view The 9-1-1 system –based on 30-year old technology –expensive for local 9-1-1 call centers to maintain –incapable of supporting the text, data, images, and video that are increasingly common in personal communications. –Travelers and other citizens cannot now use their “smart” technologies such as telematics, medical alert devices, or wireless computers to directly access 9-1-1 call centers and emergency responders. Emergency centers cannot now send location-targeted hazard alerts and evacuation guidance to motorists or other mobile device users Next-Generation 9-1-1 Initiative slides

12. IEEE NY12 VoIP emergency communications dispatch Contact well- known number or identifier Route call to location- appropriate PSAP Deliver precise location to call taker to dispatch emergency help nowtransitionall IP (“NG911”) 112 911 112 911 112, 911  urn:service:sos SR VPC LoST phone number  location (ALI lookup) in-band  key  location in-band (SIP)

13. IEEE NY13 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)

14. IEEE NY14 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

15. IEEE NY15 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)

16. IEEE NY16 Phase 1Phase 2Phase 3 Phase 4 Four Phases of Emergency Calls

17. IEEE NY17 IETF ECRIT working group Emergency Contact Resolution with Internet Technologies Solve four major pieces of the puzzle: –location conveyance (with SIP & GEOPRIV) –emergency call identification –mapping geo and civic caller locations to PSAP URI –discovery of local and visited emergency dial string Not solving –location discovery --> IETF GEOPRIV WG, IEEE –inter-PSAP communication and coordination –citizen notification Current status: –finishing general and security requirements –agreement on mapping protocol (LoST) and identifier (sos URN) –working on overall architecture and UA requirements

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

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

20. IEEE NY20 ‘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

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

22. IEEE NY22 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

23. IEEE NY23 Locating Caller using LLDP-MED LLDP-MED stands for: * Link Layer Discovery Protocol “ a vendor-neutral Layer 2 protocol that allows a network device to advertise its identity and capabilities on the local network.” Media Endpoint Discovery “ an enhancement to the LLDP that allows discovery of other things including location “ “I am LLDP-MED Capable. I can process location information.” “Your location is: 500 W 120 TH st. New York NY 10027” * From Wikipedia

24. IEEE NY24 DHCP for Location Use MAC address to get location information Mainly for stationary users We modified ISC’s dhcpd DHCP Server or request response DHCPINFORM [MAC=00:11:20:9d:a0:03] DHCPACK [option=0:US:1:NY:2:NEW YORK: 3:NEW YORK:6:AMSTERDAM:19:1214]

25. IEEE NY25 DHCP elements: Administrative Subdivisions A1 national subdivision state, canton, region, province, prefecture A2county, parish, gun (JP), district (IN) A3city, township, shi (JP) A4city division, borough, city district, ward, chou (JP) A5neighborhood, block A6group of streets NENAPIDFDescriptionExample PRD Leading street directionN POD Trailing street suffixSW STS Street suffix or typeAve, Platz HNO House number123 HNS House number suffixA, ½ LMK Landmark or vanity addressColumbia University LOC Additional location informationSouth Wing NAM name (residence and office occupant)Joe’s Barbershop BLDbuilding (structure)Low Library UNITunit (apartment, suite)Apt 42 FLRfloor number4 room number450F ZIPPCpostal/zip code10027-1234 support multiple characte r sets for each

26. IEEE NY26 SkyHook for Location Taken from http://www.skyhookwireless.com Mainly for nomadic, mobile users Wireless device receives signals from Wi-Fi sites in range Skyhook compares signals to its database of geographically known locations Location data is used to direct safety services

27. IEEE NY27 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

28. IEEE NY28 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

29. IEEE NY29 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

30. IEEE NY30 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

31. IEEE NY31 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

32. IEEE NY32 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

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

34. IEEE NY34 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

35. IEEE NY35 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,...)

36. IEEE NY36 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

37. IEEE NY37 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

38. IEEE NY38 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

39. IEEE NY39 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

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

41. IEEE NY41 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

42. IEEE NY42 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 Caching of mappings –return service region –only query again if mobile leaves service region –open issue: “holes” in service region

43. IEEE NY43 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

44. IEEE NY44 Server synchronization Synchronization of forest guides and server clusters –push information to peers –get list of new elements and retrieve mappings existing server new server <m sourceId="lost.example" sourceId="abc123" lastUpdated=“..” />...

45. IEEE NY45 Performance of CU LoST server roughly 170 req/sec --> ~17M / day dual-core P4/3.0 GHz Linux 2.6.19 Postgresql 8.1.4 Tomcat 4.1

46. IEEE NY46 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.

47. IEEE NY47 NENA i3 architecture

48. IEEE NY48 NENA i3 architecture

49. IEEE NY49 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

50. IEEE NY50 NG9-1-1 Prototype Architecture RoutingLocation PSTN

51. IEEE NY51 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

52. IEEE NY52 Calltaker screen Columbia SIPc as SIP UA Mapping software to display caller’s location –Geolynx –Google Maps

53. IEEE NY53 Call logs and recorded sessions

54. IEEE NY54 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

55. IEEE NY55 Challenges for NG911 Technically, much simpler than E911 Phase II –hopefully, cheaper, too –but security challenges: location and identity verification –co-existence between E911 and NG911 –integrating external data (e.g., OnStar) -- from silo to NG911 SOA Logistical challenges –deployment of new infrastructure location and LoST servers Legal and regulatory challenges –will ISPs give out location information to VSPs or customers? –liability for misrouted calls?

56. IEEE NY56 Outline Emergency calling Emergency alerts –multi-modal alerting –beyond siren replacement Emergency coordination

57. IEEE NY57 Emergency alerting “You’d think that after six years, we would have learned something, but when this fire broke out, there was no notification system in place, and the people who live around here didn’t know what to do, said Patricia L. Moore, who lives at 125 Cedar Street, in the shadow of the burned building. Some of us left the building and some of us stayed, but we’re all concerned.” (NY Times, August 20, 2007) So this summer, when St. John's carried out its annual review of security procedures, Dr. Pellow lobbied for a change he had long been considering: a text-messaging system that could send information about an unfolding crisis to individual cellphones. That system underwent the ultimate dry run on Wednesday when a gunman in a mask strode onto the St. John's campus in Jamaica, Queens. Though no one was hurt, the incident showed that large, dispersed crowds -- at least 10,000 students were on the campus at the time -- could respond calmly in the face of alarming information. (NY Times, September 28, 2007)

58. IEEE NY58 Alerting Current emergency notification: –TV and radio (EAS) not helpful when watching YouTube –“Inverse 911” landline only doesn’t alert care takers, relatives –CAP (OASIS) doesn’t specify transport and event notification mechanism Need flexible alerting protocol –authority-citizen –authority-authority (FBI to local police) –citizen-citizen (smoke detector to neighbor)

59. IEEE NY59 CAP 1.1 example KSTO1055887203 KSTO@NWS.NOAA.GOV 2003-06-17T14:57:00-07:00 Actual Alert Public Met SEVERE THUNDERSTORM Immediate Severe Likely same=SVR 2003-06-17T16:00:00-07:00 NATIONAL WEATHER SERVICE SACRAMENTO CA SEVERE THUNDERSTORM WARNING NATIONAL WEATHER SERVICE INDICATED A SEVERE... TAKE COVER. EXTREME NORTH CENTRAL TUOLUMNE COUNTY 38.47,-120.14 38.34,-119.95 38.52,-119.74 38.62,-119.89 38.47,-120.14 fips6=006109 fips6=006009 fips6=006003

60. IEEE NY60 New alerting architecture national authority state or local authority email national authority automated actions (sirens, vents,...) SUB/NOT SMS, IM, voice SUBSCRIBE Event: chemical Area: NJ

61. IEEE NY61 Outline Emergency calling Emergency alerts Emergency coordination

62. IEEE NY62 General requirements Low cost –may only be used very rarely Ease of use –most users are non-techies (or worse) –volunteers with range of capabilities –tools that are familiar to volunteers (web browser vs. custom application) Robust –spikes of usage example: FEMA application crash –outdoor & hostile environment example: sun glare rendered laptops useless no chargers for cell phones unreliable network connections --> delay-tolerant networks, data mules, 7DS, … Daily use, not just major catastrophes –nobody wants to learn a new tool during a hurricane

63. IEEE NY63 Emergency coordination Structured coordination –directories (people, vehicles, equipment,...) see COMCARE effort –resource tracking –“trouble tickets” –avoid current low-bandwidth radio-based coordination –most (?) police cars have laptops with data links Unstructured coordination –unpredictable needs –leverage existing content creation tools: Wikis, blogs, Google Base, Backpack,... –combinations of existing tools (e.g., Google maps and databases)

64. IEEE NY64 Authentication and security Need single-sign on –but with highly dynamic authorization –e.g., mutual aid or volunteers Currently, dominated by user name/password Use model of GETS card? –USB key? –cell phone as authenticator? 0123 4567 8910 Disaster Response Team #1 US CITY EOC

65. IEEE NY65 Example: Sahana Developed in 2004 after tsunami (in three weeks) Open source (PHP, mySQL) Component-based –organization and people registry –inventory management –situation mapping –synchronization allows for disconnected operation –XML synchronization © ACM CACM 2007 50(3)

66. IEEE NY66 LAN Peer-to-peer SIP Why? –no infrastructure available: emergency coordination –don’t want to set up infrastructure: small companies –Skype envy :-) P2P technology for –user location only modest impact on expenses but makes signaling encryption cheap –NAT traversal matters for relaying –services (conferencing, …) how prevalent? New IETF working group just formed –likely, multiple DHTs –common control and look-up protocol? P2P provider A P2P provider B p2p network traditional provider DNS zeroconf generic DHT service

67. IEEE NY67 P2P SIP -- components Multicast-DNS (zeroconf) SIP enhancements for LAN –announce UAs and their capabilities Client-P2P protocol –GET, PUT mappings –mapping: proxy or UA P2P protocol –get routing table, join, leave, … –independent of DHT –replaces DNS for SIP, not proxy

68. IEEE NY68 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 Using P2P SIP for local emergency coordination Integrated alerting system –part of broader structured communication system –possible IETF effort Need for large-scale experiments, not yet another ad-hoc network paper –cooperation with non-technical users

69. IEEE NY69 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