1 / 40

An Architecture for Next-Generation Emergency Services

An Architecture for Next-Generation Emergency Services. Henning Schulzrinne Columbia University. 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

berke
Download Presentation

An Architecture for Next-Generation Emergency Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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 • 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-arch-00 • overall architecture for emergency calling • draft-ietf-sipping-sos-00 • describes ‘sos’ SIP URI • draft-rosen-dns-sos-00 • 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 • 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. 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

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

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

  32. 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?

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

  34. 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 …

  35. 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

  36. Routing layers firewall boundary

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

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

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

  40. 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

More Related