1 / 27

ECRIT: Emergency Calling

ECRIT: Emergency Calling. Henning Schulzrinne (with Jong Yul Kim, Wonsang Song, Anshuman Rawat, Matthew Mintz-Habib, Amrita Rajagopal and Xiaotao Wu) Dept. of Computer Science Columbia University. Introduction. Emergency calling is a necessary part of consumer voice service

uzuri
Télécharger la présentation

ECRIT: Emergency Calling

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. ECRIT: Emergency Calling 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. Introduction • Emergency calling is a necessary part of consumer voice service • citizen calls PSAP (public safety answering point) for assistance • Existing solutions are insufficient • may deliver call to wrong PSAP • particularly for nomadic and mobile users • may not deliver location to PSAP • makes it difficult to move call information around • e.g., call location to first responder • voice only (+ TDD) SIP 2006 (Paris, February 2006)

  3. VoIP emergency communications emergency call emergency alert (“inverse 911”) dispatch civic coordination SIP 2006 (Paris, February 2006)

  4. Components of emergency calling now transition all IP Contact well-known number or identifier 112 911 112 911 dial 112, 911 urn:service:sos Route call to location-appropriate PSAP selective router VPC DNS Deliver precise location to call taker to dispatch emergency help phone number  location (ALI lookup) in-band  key  location in-band SIP 2006 (Paris, February 2006)

  5. What makes VoIP 112/911 hard? SIP 2006 (Paris, February 2006)

  6. The core problem Voice Service Provider (VSP) sees emergency call but does not know caller location ISP/IAP knows user location but does not handle call SIP 2006 (Paris, February 2006)

  7. Staged deployment • ~6,134 PSAPs in North America • average 2-3 active call takers each • some serve town, some large parts of a state • only ~30% of PSAPs can receive geo coordinates • 30-40% may be voice only • many using 1970s telecom technology • “CAMA” (operator) trunks • limited to delivering 8 (regional) or 10 digits (national) of information • already facing pressure from supporting cellular services • Phase I (cell tower and face) and Phase II (caller geo location) • EU: smaller number of PSAPs, but often without location delivery • Initial version (“I1”): • dial 10-digit administrative number • like telematics services • does not deliver caller location to PSAP SIP 2006 (Paris, February 2006)

  8. 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) SIP 2006 (Paris, February 2006)

  9. Options for location delivery • L2: LLDP-MED (standardized version of CDP + location data) • periodic per-port broadcast of configuration information • L3: DHCP for • geospatial (RFC 3825) • civic (draft-ietf-geopriv-dhcp-civil) • L7: proposals for retrievals • by IP address • by MAC address • by identifier (conveyed by DHCP or PPP) SIP 2006 (Paris, February 2006)

  10. 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 SIP 2006 (Paris, February 2006)

  11. 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 SIP 2006 (Paris, February 2006)

  12. 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 SIP 2006 (Paris, February 2006)

  13. UA recognition & UA resolution location information mapping mapping may recurse DHCP LLDP-MED 9-1-1 (dial string) leonianj.gov INVITE sip:psap@leonianj.gov To: urn:service:sos <location> INVITE sip:psap@leonianj.gov To: urn:service:sos <location> SIP 2006 (Paris, February 2006)

  14. UA recognition & proxy resolution mapping 9-1-1 provider.com INVITE urn:service:sos To: urn:service:sos <location> INVITE sip:psap@leonianj.gov To: urn:service:sos <location> SIP 2006 (Paris, February 2006)

  15. UA recognition & proxy resolution(proxy location determination) mapping 9-1-1 provider.com INVITE urn:service:sos To: urn:service:sos INVITE sip:psap@leonianj.gov To: urn:service:sos Location: <location> SIP 2006 (Paris, February 2006)

  16. Proxy recognition & proxy resolution mapping 9-1-1 provider.com INVITE sip:psap@leonianj.gov To: sip:911@provider.com;user=phone Location: <location> INVITE sip:911@provider.com;user=phone To: sip:911@provider.com;user=phone SIP 2006 (Paris, February 2006)

  17. 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 SIP 2006 (Paris, February 2006)

  18. 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 SIP 2006 (Paris, February 2006)

  19. 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 SIP 2006 (Paris, February 2006)

  20. LUMP: Location-to-URL Mapping VSP1 cluster serving VSP1 replicate root information cluster serves VSP2 123 Broad Ave Leonia Bergen County NJ US root nodes NJ US NY US sip:psap@leonianj.gov search referral Bergen County NJ US Leonia NJ US SIP 2006 (Paris, February 2006)

  21. LUMP architecture G tree guide G G G broadcast (gossip) T1: .us T2: .de G resolver T2 (.de) seeker 313 Westview Leonia, NJ US T3 (.dk) T1 (.us) Leonia, NJ  sip:psap@leonianj.gov SIP 2006 (Paris, February 2006)

  22. 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 (X1,Y1; X2, Y2; …); 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” SIP 2006 (Paris, February 2006)

  23. 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) SIP 2006 (Paris, February 2006)

  24. 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) SIP 2006 (Paris, February 2006)

  25. LUMP geo mapping SIP 2006 (Paris, February 2006)

  26. LUMP: SOAP request SIP 2006 (Paris, February 2006)

  27. Conclusion • Opportunity to fundamentally restructure emergency communications • higher reliability with large-scale disasters • lower cost • richer interaction • IETF ECRIT working group converging on set of solutions • To be done: • finalize mapping protocol • additional transport modes? • configuration of dial strings • overall system architecture SIP 2006 (Paris, February 2006)

More Related