An Architecture for Next-Generation Emergency Services

1. An Architecture for Next-Generation Emergency Services Henning Schulzrinne Columbia University Critical Issues Forum (Santa Clara)

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

3. PSTN vs. Internet Telephony PSTN: Signaling & Media Signaling & Media China Internet telephony: Signaling Signaling Media Australia Belgian customer, currently visiting US

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

5. SIP addressing • Users identified by SIP or tel URIs • sip:alice@example.com • tel: URIs describe E.164 number, not dialed digits (RFC 2806bis) • tel URIs  SIP URIs by outbound proxy • A person can have any number of SIP URIs • The same SIP URI can reach many different phones, in different networks • sequential & parallel forking • SIP URIs can be created dynamically: • GRUUs • conferences • device identifiers (sip:foo@128.59.16.15) • 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

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

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

8. IETF efforts • 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.” • Efforts on 911 services go back to 2001, … • but only recent high-impact efforts • ECRIT BOF at Washington, DC IETF (November 2004) • focuses on call routing problem • likely to be WG soon  see other talk • individuals working both in NENA and IETF WGs

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

10. Three stages to VoIP 911

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

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

13. Architecture components • Common URL for emergency calls • Convey local emergency number to devices • Allow devices to obtain their location • Route calls to right destination

14. Component 1: Common URL for emergency services • Emergency numbers may be dialed from many different places • about 60 (national) different emergency service numbers in the world • 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 • Thus, need common identifier for calls

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

16. Service identification • In some countries, specialized numbers for police, fire, … • We add SIP protocol header that identifies call service: • Accept-Contact: * ;service=“sos.mountain” • Generally, not user visible

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

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

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

20. Translating dialed numbers to emergency identifiers sips:sos@example.com “9-1-1” On many telephone-like systems, only numbers are available  number translation

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

22. Component 3: Determining locations • LLDP-MED: periodic delivery of port and location information to each switch port • particularly suited for floor-level location in enterprises • Conveyed via DHCP from IP-level provider • Formats: • geospatial (longitude, latitude, altitude or floor) • civic (country, administrative units, street) • Provider usually knows • Does not depend on being a voice service provider • 802.11 triangulation • GPS (for mobile devices) • Via configuration protocol (XCAP) • relies on VSP having accurate service location information • User-configured (last resort)

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

24. Conveying location along the call path placing emergency call INVITE sip:sos@example.com From: sip:alice@example.com To: sip:sos@example.com Content-Type: multipart/mixed <gp:locationinfo> <loc:civil> <c:a1>PA</c:a1> <c:a2>University Park</c:a2> <c:zip>10025</c:zip> </loc:civil> </gp:location-info> on boot

25. GEOPRIV = IETF working group for geospatial privacy Location within call signaling not ALI reference Based on GML mark-up GEOPRIV geospatial format <?xml version="1.0" encoding="UTF-8"?> <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"> <tuple id="sg89ae"> <timestamp>2003-06-22T20:57:29Z</timestamp> <status> <gp:geopriv> <gp:location-info> <gml:location> <gml:Point gml:id="point96" srsName="epsg:4326"> <gml:coordinates>31:56:00S 115:50:00E</gml:coordinates> </gml:Point> </gml:location> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry> </gp:usage-rules> </gp:geopriv> </status> </tuple> </presence>

26. GEOPRIV civic format <country>US</country> <A1>NJ</A1> <A2>Bergen</A2> <A3>Leonia</A3> <A6>Westview</A6> <STS>Ave</STS> <HNO>313</HNO> <NAM>Schulzrinne</NAM> <ZIP>07605-1811</ZIP> • Based on NENA XML elements • Except internationalized administrative divisions:

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

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

29. 4. Call Routing • Several possible options to map geo/civic locations under discussion • DNS – discussed next • CRISP/IRIS – XML-based directory protocol currently used for DNS registrars • SOAP (web services) • Possibly combination of these • e.g., use DNS for coarse routing • Only DNS has been fleshed out

30. Routing core requirements • Both civic and geo coordinates • conversion from civic to geo may introduce errors • need to check validity of civic addresses • thus, need to map both point-in-polygon and hierarchical strings • Delegation • service boundaries follow arcane political maps • mapping updates must be done at local level • Scaling • global directory • but not single (logical) server • Caching • can’t go to root directory for each call • must work even if routing machinery is temporarily unavailable • Reliable • WAN-scale automated replication

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

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

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

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

35. Obtaining all sub-regions us.sos. arpa nj.us.sos. arpa CN=us A1=nj A2=bergen A3=leonia

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

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

38. Routing layers firewall boundary

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

40. Testing emergency calls • 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 • Use SIP OPTIONS request  route request, but don’t reach call taker • Also, DNS model allows external consistency checking • e.g., nationwide 911 testing agency

41. INVITE REFER INVITE media info INVITE INVITE REFER REFER INVITE media info Emergency call conferencing PSAP brings all related parties into a conference call Hospital Fire department INVITE Conference server Recorder 3rd party call control PSAP Caller

42. Scaling • NENA: “estimated 200 million calls to 9-1-1 in the U.S. each year” •  approximately 6.3 calls/second • if 3 minute call, about 1,200 concurrent calls • typical SIP proxy server (e.g., sipd) on 1 GHz PC can handle about 400 call arrivals/second • thus, unlikely to be server-bound

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

44. Different perspectives

45. Conclusion • Good news: • 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 • PC-based end system can be maintained as is • use of COTS, across national borders • Challenges: • cannot simply add one more patch to existing circuit-switched 911 system