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

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)