1 / 22

Emergency calling draft-ietf-sipping-sos draft-schulzrinne-emergency-arch

Emergency calling draft-ietf-sipping-sos draft-schulzrinne-emergency-arch. Henning Schulzrinne Columbia University with Brian Rosen. Overview. Principles and goals ‘sos’ draft changes Discussion reflects list discussion some items in drafts already updated Open issues:

cdeines
Download Presentation

Emergency calling draft-ietf-sipping-sos draft-schulzrinne-emergency-arch

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. Emergency callingdraft-ietf-sipping-sosdraft-schulzrinne-emergency-arch Henning Schulzrinne Columbia University with Brian Rosen SIPPING - IETF 59 (Seoul)

  2. Overview • Principles and goals • ‘sos’ draft changes • Discussion reflects list discussion • some items in drafts already updated • Open issues: • sos: emergency service identification • arch: DNS architecture • arch: location transport and update • arch: determining local emergency numbers • arch: testing • arch: mid-call behavior SIPPING - IETF 59 (Seoul)

  3. Principles and goals • Support emergency calling in SIP-based systems • not just VoIP, also IM, video, text, … • no changes to SIP • Assume emergency call centers are SIP-enabled • possibly through a gateway • Security and privacy • “sips:” mandated  match DNS-provided ECC with responding ECC • only need host keys • later, trait-based authentication possible (“certified ECC”) • location insertion by UA SIPPING - IETF 59 (Seoul)

  4. ‘sos’ changes • Moved architectural and call routing discussion to new emergency-arch draft • Clarified how local emergency numbers are determined • closely modeled on 3GPP, but default set only if no external configuration • Emergency services identified by callee caps, not URI • More details on testing ? ? SIPPING - IETF 59 (Seoul)

  5. Emergency service identification • Old: sos.fire@example.com • New: only ‘sos’, but add callee capabilities, e.g., • Accept-Contact: *;service=sos.fire • Fits better into call routing architecture • only ‘sos’ needed for coarse routing • ECC and call taker can register for appropriate service specialty • apparently, mountain rescue is sometimes managed separately (Switzerland) • Can no longer be typed directly by human user • assume that users don’t type ‘sos’, but rather numbers or (rarely) select emergency services from menu • Dialplan-by-DNS mapping more difficult • no longer just a string translation SIPPING - IETF 59 (Seoul)

  6. Use of DNS • Define new second-level domain: sos.arpa • Current architecture envisions for three purposes: • get list of national emergency numbers for current location • new record or NAPTR (kludge) • map geospatial location to ECC • tree of service areas • discovered via zone transfer (kludge) or PTR • POLY record containing one or more polygons • firedept.leoniaboro.org  POLY(x1,y1;x2,y2;…) • does not have to follow civil hierarchy • map civil location to ECC • civil location hierarchy • leonia.nj.us.sos.arpa  NAPTR for ‘sos’ service SIPPING - IETF 59 (Seoul)

  7. Use of DNS: notes • Some (most?) countries use ECCs corresponding closely to civil hierarchy • But even in US, sometimes by rate boundary of old PSTN switches • Others, may have regional centers • UK? (Does not really have equivalents of states) • Call routing can be done by • UA • outbound proxy • home proxy (last resort) SIPPING - IETF 59 (Seoul)

  8. Location transport • Location is core component of call routing decision  needs to be available in initial INVITE • Needs to be available to all proxies • Architecturally, location is used for call routing • We put call routing items (Accept-*, caller preferences, …) in SIP headers • easier to find • avoids multi-part MIME in many cases • fits nicely with AIB model SIPPING - IETF 59 (Seoul)

  9. Location transport, cont’d. • Putting location information as header does not imply ability by proxy to add or change it  orthogonal issue! • Does not necessarily imply a certain format (e.g., ;par=value) • but does make format marking more difficult • probably good for call routing  can’t have lots of formats if you want reliable call routing • Accept model of negotiation doesn’t work for proxy-inspected items SIPPING - IETF 59 (Seoul)

  10. Location transport: a comparison • End-to-end location transport and proxy-visible transport are useful, but have very different requirements SIPPING - IETF 59 (Seoul)

  11. Location transport ? • Three cases: • UA knows • only proxy knows • UA knows, but proxy knows better • For (1), have two options: • location header containing LO information • as XML string • in SIP header format (;cn=us;a1=“nj”;retain=“yes”) • XML LO as additional body (multi-part) SIPPING - IETF 59 (Seoul)

  12. Options for “proxy knows” • Proxy inserts location header • Proxy returns 302 response with location information • as header • as Contact URI with ?header information • as body • UA generates new request with this information • UA queries proxy for location and inserts • only works if it knows whom to ask (outbound proxy) SIPPING - IETF 59 (Seoul)

  13. Location transport – summary • No perfect solution • Should clearly distinguish uses for information: routing vs. end system information SIPPING - IETF 59 (Seoul)

  14. Location update ? • Precise location may not be available at time of call • GPS acquisition time after turning on mobile • may only have cell tower/sector • but may be sufficient for routing to right ECC • Want to update location during call to help direct emergency response • Options: • re-INVITE – but don’t want to renegotiate session parameters • UPDATE – same conceptual mismatch • INFO – non-call-state changing • new method? SIPPING - IETF 59 (Seoul)

  15. Determining local emergency numbers • Pre-configured, always: 112 and 911 • but can’t pre-configure all emergency numbers  collision with other services • For travelers, want to support • local (“visited”) emergency number • home emergency number – quick, what’s the emergency number for Japan (transit) or Korea? • if collision with local service number, need override • manageable, since user will recognize that directory assistance looks like the fire department… • Local and maybe home number learned via DNS if current and home country is known • Could also use XCAP: • from outbound proxy XCAP server • home AOR XCAP server • may not work well if home AOR spans many countries (Yahoo, Hotmail) • outbound proxy not always in visited country (e.g., IETF) SIPPING - IETF 59 (Seoul)

  16. Testing emergency calling • Objectives: • can I place an emergency call from my local network? • is the infrastructure working right now? • “past performance does not guarantee future results” • limited use unless there is a reporting mechanism to fix problems • is the call reaching the right ECC? • Should not use human resources • If possible, test not just call routing but also voice path • NATs may allow outbound call, but not two-way audio • Testing modes: • manual (new installation or environment)  always possible, but insufficient • power-up • bad idea when NYC reboots • periodic • centralized – some testing agency SIPPING - IETF 59 (Seoul)

  17. Testing options • End-to-end • UA places OPTIONS call to ECC (say) once a day or when it has moved • movement detection difficult – ECC may change even if within same tower range • load: yearly call volume in one day (if daily) • beyond first hop, doesn’t add much value to repeat test millions of times • would need automated reporting mechanism to be useful for availability testing • To first ESRP • ensures that from current location, call is handled correctly • only need to test if outbound proxy changes • not needed if UA does its own call routing SIPPING - IETF 59 (Seoul)

  18. Testing – recommendation 1 • UA SHOULD have manual testing function • including audio and other media (interactive text, video) • see RTP ping test in AVT • response from ECC SHOULD return service area indication  allow to detect routing failures • not necessarily boundary, but just sanity check • “ECC serving NJ, but I am in Seoul” SIPPING - IETF 59 (Seoul)

  19. Testing – recommendation 2 • No periodic end-to-end test • If UA does call routing, ensure access to sos.arpa • If UA delegates to outbound proxy, ask outbound proxy (OPTIONS with MaxForwards=1) SIPPING - IETF 59 (Seoul)

  20. Testing – recommendation 3 • Suggest that voice service providers or state entities do liveness and availability testing • only if there is some feedback loop • “sorry, emergency calling doesn’t work right now; please don’t have any accidents” is not very helpful • not too far-fetched: radio announcements “911 out of service, please dial sheriff’s department at 555-1212” heard SIPPING - IETF 59 (Seoul)

  21. Mid-call behavior: no hang-up ? • Caller should only be able to hang up with permission of ECC • caveat: optional in current PSTN • cannot be completely enforced • options: • prevent disconnect: refuse (403) BYE sent by caller • alert caller if phone off-hook, but not reachable • common: phone in pocket speed-dials emergency number • 2833 tone, translated into ringing, howler by UA (“mid-call alert”?) • special re-INVITE? • security risk  telemarketer refuses BYE • easy if caller placed call to ‘sips:sos@’ • avoid unidentified emergency calls • could have number-dialed call redirect, but open to mischief • dial 1-800-Siding  sip:sos@sleaze-n-fraud.com • conclusion: support only if UA has recognized emergency call SIPPING - IETF 59 (Seoul)

  22. Conclusion • Outline of operation reasonably clear • Request that emergency-arch be made sipping WG item • emergency calling is chartered [check] • But a number of detailed design decisions to be made • Bar BOF? SIPPING - IETF 59 (Seoul)

More Related