2. April 26, 2004 Critical Issues Forum (Baltimore) 1 An Architecture for Next- Generation Emergency Services Henning Schulzrinne Columbia University

3. April 26, 20042 Overview How does VoIP differ from landline and wireless PSTN? How does VoIP differ from landline and wireless PSTN? Getting from here to there: I1, I2 and I3 Getting from here to there: I1, I2 and I3 IETF efforts IETF efforts status status assumptions assumptions Common URL for emergency services Common URL for emergency services Routing emergency calls Routing emergency calls Common location format Common location format Configuration of local emergency call numbers Configuration of local emergency call numbers Security issues Security issues

4. April 26, 20043 PSTN vs. Internet Telephony Signaling & Media Signaling Media PSTN: Internet telephony: China Belgian customer, currently visiting US Australia

5. April 26, 20044 SIP trapezoid outbound proxy a@foo.com: 128.59.16.1 registrar 1 st request 2 nd, 3 rd, … request voice traffic RTP destination proxy (identified by SIP URI domain)

6. April 26, 20045 SIP addressing Users identified by SIP or tel URIs Users identified by SIP or tel URIs sip:alice@example.com sip:alice@example.com tel: URIs describe E.164 number, not dialed digits (RFC 2806bis) tel: URIs describe E.164 number, not dialed digits (RFC 2806bis) tel URIs  SIP URIs by outbound proxy tel URIs  SIP URIs by outbound proxy A person can have any number of SIP URIs A person can have any number of SIP URIs The same SIP URI can reach many different phones, in different networks The same SIP URI can reach many different phones, in different networks sequential & parallel forking sequential & parallel forking SIP URIs can be created dynamically: SIP URIs can be created dynamically: GRUUs GRUUs conferences conferences device identifiers (sip:foo@128.59.16.15) device identifiers (sip:foo@128.59.16.15) Registration binds SIP URIs (e.g., device addresses) to SIP “address-of-record” (AOR) Registration binds SIP URIs (e.g., device addresses) to SIP “address-of-record” (AOR) tel:110 sip:sos@domain domain  128.59.16.17 via NAPTR + SRV

7. April 26, 20046 How does VoIP differ from landline and wireless PSTN? Telephone companies are no longer needed Telephone companies are no longer needed there are still carriers for DSL and cable “IP dial tone” there are still carriers for DSL and cable “IP dial tone” but unaware of type of data carried but unaware of type of data carried VSP may be in another state or country VSP may be in another state or country Corporations and universities don’t have email carriers, either Corporations and universities don’t have email carriers, either voice service provider (RTP, SIP) ISP (IP, DHCP, DNS) dark fiber provider Yahoo MCI NYSERNET

8. April 26, 20047 Why is VoIP ≠ wireless? VoIP devices may not have phone numbers as lookup keys VoIP devices may not have phone numbers as lookup keys e.g., sip:hgs@cs.columbia.edu e.g., sip:hgs@cs.columbia.edu Location information for devices is civic, not longitude/latitude Location information for devices is civic, not longitude/latitude e.g., service address for VSPs e.g., service address for VSPs GPS not available (nor functional) on indoor devices GPS not available (nor functional) on indoor devices plus, accuracy of 50 m (67%) or 150 m spans many buildings… plus, accuracy of 50 m (67%) or 150 m spans many buildings… no floor information no floor information Cell phones don’t work in our building… Cell phones don’t work in our building… so A-GPS is unlikely to work there, either so A-GPS is unlikely to work there, either Plus, wireless E911 complexity due to old signaling mechanism Plus, wireless E911 complexity due to old signaling mechanism 50m

9. April 26, 20048 IETF efforts IETF = Internet Engineering Task Force IETF = Internet Engineering Task Force “The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. It is open to any interested individual.” “The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. It is open to any interested individual.”(IETF) Efforts on 911 services go back to 2001, … Efforts on 911 services go back to 2001, … but only recent high-impact efforts but only recent high-impact efforts individuals working both in NENA and IETF WGs individuals working both in NENA and IETF WGs

10. April 26, 20049 Current IETF drafts draft-taylor-sipping-emerg-scen-01 draft-taylor-sipping-emerg-scen-01 scenarios, e.g., hybrid VoIP-PSTN scenarios, e.g., hybrid VoIP-PSTN draft-schulzrinne-sipping-emergency-arch-00 draft-schulzrinne-sipping-emergency-arch-00 overall architecture for emergency calling overall architecture for emergency calling draft-ietf-sipping-sos-00 draft-ietf-sipping-sos-00 describes ‘sos’ SIP URI describes ‘sos’ SIP URI draft-rosen-dns-sos-00 draft-rosen-dns-sos-00 new DNS resource records for location mapping new DNS resource records for location mapping

11. April 26, 200410 Three stages to VoIP 911 spec. available? use 10- digit admin. number? mobilitycallback number to PSAP? caller location to PSAP? PSAP modificatio n ALI (DB) modification new services I1nowallowedstationarynononononone I2 Dec. 2004 nostationarynomadicyesyes no (8 or 10 digit) updatenone I3 late 2004 late 2004nostationarynomadicmobileyesyesIP-enabled ALI not needed MSAG replaced by DNS location in- band GNPmultimedia international calls

12. April 26, 200411 Architectural assumptions and goals for I3 SIP-based for interchange SIP-based for interchange other protocols (e.g., H.323) via gateway other protocols (e.g., H.323) via gateway avoid complexity of multiple protocols everywhere avoid complexity of multiple protocols everywhere H.248/MGCP not used for interdomain signaling  not needed here H.248/MGCP not used for interdomain signaling  not needed here International International devices bought anywhere can make emergency calls anywhere devices bought anywhere can make emergency calls anywhere limit biases in address formats, languages, … limit biases in address formats, languages, … avoid built-in bias for “911” or “112” (mostly) avoid built-in bias for “911” or “112” (mostly) use term “ECC” (emergency call center) instead of “PSAP” use term “ECC” (emergency call center) instead of “PSAP” Multimedia Multimedia support non-audio media if available in PSAP support non-audio media if available in PSAP e.g., images or video for situational awareness e.g., images or video for situational awareness

13. April 26, 200412 Goals, cont’d. Support other communications modes Support other communications modes IM IM maybe email later maybe email later Support access for callers with disabilities Support access for callers with disabilities real-time text real-time text video for sign language video for sign language Easy access to external data Easy access to external data hazmat records hazmat records sensor data (collision data, video images, …) sensor data (collision data, video images, …)

14. April 26, 200413 Architecture components 1. Common URL for emergency calls 2. Convey local emergency number to devices 3. Allow devices to obtain their location 4. Route calls to right destination

15. April 26, 200414 Component 1: Common URL for emergency services Emergency numbers may be dialed from many different places Emergency numbers may be dialed from many different places about 60 (national) different emergency service numbers in the world about 60 (national) different emergency service numbers in the world many are used for other services elsewhere (e.g., directory assistance) many are used for other services elsewhere (e.g., directory assistance) End systems, proxies and gateways should be able to tell easily that a call is an emergency call End systems, proxies and gateways should be able to tell easily that a call is an emergency call Thus, need common identifier for calls Thus, need common identifier for calls

16. April 26, 200415 Common URL for emergency calls IETF draft suggests “sip:sos@home-domain” IETF draft suggests “sip:sos@home-domain” home-domain: domain of caller home-domain: domain of caller Can be recognized by proxies along the way Can be recognized by proxies along the way short cut to emergency infrastructure short cut to emergency infrastructure If not, it reaches home proxy of subscriber If not, it reaches home proxy of subscriber Call can be routed from there easily Call can be routed from there easily global access to routing information (see later) global access to routing information (see later)

17. April 26, 200416 Service identification In some countries, specialized numbers for police, fire, … In some countries, specialized numbers for police, fire, … We add SIP protocol header that identifies call service: We add SIP protocol header that identifies call service: Accept-Contact: * ;service=“sos.mountain” Generally, not user visible Generally, not user visible sos.fire fire brigade sos.rescueambulance sos.marine marine guard sos.policepolice sos.mountain mountain rescue sos.test only testing

18. April 26, 200417 Other call identifiers Using SIP caller preferences/callee capabilities Using SIP caller preferences/callee capabilities Caller languages Caller languages automatically route to PSAP or call taker that speaks French automatically route to PSAP or call taker that speaks French Accept-Language: fr Accept-Language: fr Caller media preferences Caller media preferences automatically route to PSAP or call taker that can deal with typed text automatically route to PSAP or call taker that can deal with typed text Accept-Contact: *;text;require Accept-Contact: *;text;require

19. April 26, 200418 Component 2: Translating dialed digits Always available: 112 and 911 Always available: 112 and 911 Configuration mechanisms: Configuration mechanisms: SIM cards (GSM phones) SIM cards (GSM phones) XCAP configuration XCAP configuration local (outbound) proxy local (outbound) proxy home proxy home proxy DNS DNS Default configuration if no other information available: Default configuration if no other information available: 000, 08, 110, 999, 118 and 119 000, 08, 110, 999, 118 and 119

20. April 26, 200419 Emergency number configuration via DNS NAPTR 100 10 "u" "SOS" "/110/sips:sos.police@notfall.de/i de.sos.arpa country=DE DHCP server add 110 to list of emergency dial strings

21. April 26, 200420 Translating dialed numbers to emergency identifiers “9-1-1”no.URIservice911sossos 110sossos.police 112sossos.fire On many telephone-like systems, only numbers are available  number translation sips:sos@example.com

22. April 26, 200421 GEOPRIV and SIMPLE architectures target location server location recipient rule maker presentity caller presence agent watcher callee GEOPRIV SIP presence SIP call PUBLISH NOTIFY SUBSCRIBE INVITE publication interface notification interface rule interface INVITE

23. April 26, 200422 Component 3: Determining locations Conveyed via DHCP from IP-level provider Conveyed via DHCP from IP-level provider Formats: Formats: geospatial (longitude, latitude, altitude or floor) geospatial (longitude, latitude, altitude or floor) civic (country, administrative units, street) civic (country, administrative units, street) Provider usually knows Provider usually knows Does not depend on being a voice service provider Does not depend on being a voice service provider 802.11 triangulation 802.11 triangulation GPS (for mobile devices) GPS (for mobile devices) Via configuration protocol (XCAP) Via configuration protocol (XCAP) relies on VSP having accurate service location information relies on VSP having accurate service location information User-configured (last resort) User-configured (last resort)

24. April 26, 200423 Enhancing DHCP for locations use MAC address backtracing to get location information use MAC address backtracing to get location information can use existing DHCP servers and clients can use existing DHCP servers and clients DHCP server 458/17  Rm. 815 458/18  Rm. 816 DHCP answer: sta=DC loc=Rm815 lat=38.89868 long=77.03723 8:0:20:ab:d5:d CDP + SNMP 8:0:20:ab:d5:d  458/17

25. April 26, 200424 Conveying location along the call path INVITE sip:sos@example.com From: sip:alice@example.com To: sip:sos@example.com Content-Type: multipart/mixed PA University Park 10025 on boot placing emergency call

26. April 26, 200425 GEOPRIV geospatial format GEOPRIV = IETF working group for geospatial privacy GEOPRIV = IETF working group for geospatial privacy Location within call signaling Location within call signaling not ALI reference not ALI reference Based on GML mark-up Based on GML mark-up <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0" entity="pres:geotarget@example.com"> 2003-06-22T20:57:29Z 31:56:00S 115:50:00E no 2003-06-23T04:57:29Z

27. April 26, 200426 GEOPRIV civic format Based on NENA XML elements Based on NENA XML elements Except internationalized administrative divisions: Except internationalized administrative divisions: A1 national subdivisions (state, region, province, prefecture) A2 county, parish, gun (JP), district (IN) A3 city, township, shi (JP) A4 city division, borough, city district, ward, chou (JP) A5 neighborhood, block A6street US NJ Bergen Leonia Westview Ave 313 Schulzrinne 07605-1811

28. April 26, 200427 Location-based call routing – UA knows its location GPS 48° 49' N 2° 29' E INVITE sips:sos@ DHCP outbound proxy server 48° 49' N 2° 29' E  Paris fire department

29. April 26, 200428 Location-based call routing – network knows location IP 48° 49' N 2° 29' E TOA include location info in 302 INVITE sips:sos@ INVITE sips:sos@paris.gendarme.fr map location to (SIP) domain outbound proxy

30. April 26, 200429 A quick review of DNS DNS = mapping from hierarchical names to resource records DNS = mapping from hierarchical names to resource records commonly, but not necessarily IP addresses commonly, but not necessarily IP addresses Authoritative server for each domain operated by domain Authoritative server for each domain operated by domain e.g., columbia.edu server is owned & operated by Columbia University e.g., columbia.edu server is owned & operated by Columbia University pc.example.com leonia.nj.us caches results leonia.nj.us?

31. April 26, 200430 A quick review of DNS Thus, globally visible database, with delegated control of content Thus, globally visible database, with delegated control of content Replication of DNS servers mandatory Replication of DNS servers mandatory at least 2, often more at least 2, often more automatically synchronized automatically synchronized Robustness by caching Robustness by caching typically life time of 24 hours typically life time of 24 hours end system may not notice outage of authoritative server end system may not notice outage of authoritative server Host security  modification control Host security  modification control DNS security (DNSsec) to ensure authenticity of content DNS security (DNSsec) to ensure authenticity of content

32. April 26, 200431 How does the PSAP find the caller’s location? Largest difference to existing E911 system Largest difference to existing E911 system In-band, as part of call setup In-band, as part of call setup carried in body of setup message carried in body of setup message rather than by reference into external database rather than by reference into external database May be updated during call May be updated during call moving vehicles moving vehicles late availability of information (GPS acquisition delay) late availability of information (GPS acquisition delay) Also possible: subscribe to location information Also possible: subscribe to location information

33. April 26, 200432 Using DNS for determining PSAPs Define new domain, e.g., sos.arpa Define new domain, e.g., sos.arpa.arpa used for infrastructure functions.arpa used for infrastructure functions top-level queries done only rarely top-level queries done only rarely results are cached at client results are cached at client *.us.sos. arpa *.sos. arpa *.nj.us.sos. arpa     firedept.leonia.nj.gov leonia.nj.us.sos.arpa?

34. April 26, 200433 Obtaining all sub-regions us.sos. arpa nj.us.sos. arpaus.sos.arpaPTRal.us.sos.arpaus.sos.arpaPTRak.us.sos.arpa us.sos.arpaPTRnj.us.sos.arpa …PTR… CN=us A1=nj A2=bergen A3=leonianj.us.sos.arpaPTRsussex.nj.us.sos.arpanj.us.sos.arpaPTRpassaic.nj.us.sos.arpa nj.us.sos.arpaPTRbergen.nj.us.sos.arpa …PTR…

35. April 26, 200434 What about geo addresses? Store one DNS record for each PSAP Store one DNS record for each PSAP or whatever the last caller-visible SIP proxy is or whatever the last caller-visible SIP proxy is could be state, county, city, … could be state, county, city, … Point to record containing PSAP boundary Point to record containing PSAP boundary retrieved via HTTP (web) retrieved via HTTP (web) cached as needed cached as needed Records polygon edges of PSAP service area (longitude-latitude tuples) Records polygon edges of PSAP service area (longitude-latitude tuples) Same descent of hierarchy Same descent of hierarchy at each level, search all leaves for match at each level, search all leaves for match Bergen Passaic Atlantic …

36. April 26, 200435 Address hiding Some advocate hiding IP addresses of PSAPs (or groups of PSAPs) Some advocate hiding IP addresses of PSAPs (or groups of PSAPs) Not clear what this means Not clear what this means if call made, IP address will be returned in packets if call made, IP address will be returned in packets Can, however, have different perimeters Can, however, have different perimeters source address of SIP and audio packets

37. April 26, 200436 Routing layers firewall boundary

38. April 26, 200437 Privacy and authentication Want to ensure privacy of call setup information Want to ensure privacy of call setup information prevent spoofing of call origins prevent spoofing of call origins but can’t enforce call authentication but can’t enforce call authentication need to authenticate call destination need to authenticate call destination ideally, certificate for PSAPs ideally, certificate for PSAPs but initially just verify that reached DNS-indicated destination but initially just verify that reached DNS-indicated destination use TLS (SSL), as in https:// use TLS (SSL), as in https:// host certificates widely available host certificates widely available just need a domain name and a credit card just need a domain name and a credit card

39. April 26, 200438 Testing emergency calls Current E911 system has no good way to test 911 reachability without interfering with emergency services Current E911 system has no good way to test 911 reachability without interfering with emergency services With VoIP, more distributed system  more need for testing With VoIP, more distributed system  more need for testing Use SIP OPTIONS request  route request, but don’t reach call taker Use SIP OPTIONS request  route request, but don’t reach call taker Also, DNS model allows external consistency checking Also, DNS model allows external consistency checking e.g., nationwide 911 testing agency e.g., nationwide 911 testing agency

40. April 26, 200439 Open issues Technical (protocol) issues: Technical (protocol) issues: details of DNS records details of DNS records top-level DNS domain? top-level DNS domain? how to do testing with minimal impact? how to do testing with minimal impact? Operational issues: Operational issues: who runs sos.arpa and us.sos.arpa? who runs sos.arpa and us.sos.arpa? export of MSAG information into DNS? export of MSAG information into DNS? will DSL and cable modem carriers provide location information? will DSL and cable modem carriers provide location information? Funding issues: Funding issues: use IP-layer funding for 911, not voice services use IP-layer funding for 911, not voice services

41. April 26, 200440 Conclusion Good news: Good news: VoIP-based 911 is not nearly as hard as Phase II wireless VoIP-based 911 is not nearly as hard as Phase II wireless can be leveraged to provide simpler Phase II services for non-VoIP terminals can be leveraged to provide simpler Phase II services for non-VoIP terminals PC-based end system can be maintained as is PC-based end system can be maintained as is use of COTS, across national borders use of COTS, across national borders Challenges: Challenges: cannot simply add one more patch to existing circuit- switched 911 system cannot simply add one more patch to existing circuit- switched 911 system