March 2004SIPPING - IETF 59 (Seoul)1 Emergency calling draft-ietf-sipping-sos draft-schulzrinne-emergency-arch Henning Schulzrinne Columbia University with Brian Rosen

March 2004SIPPING - 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

March 2004SIPPING - 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

March 2004SIPPING - 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

March 2004SIPPING - IETF 59 (Seoul)5 Emergency service identification Old: 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

March 2004SIPPING - 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

March 2004SIPPING - 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)

March 2004SIPPING - 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

March 2004SIPPING - 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

March 2004SIPPING - IETF 59 (Seoul)10 Location transport: a comparison End-to-end location transport and proxy-visible transport are useful, but have very different requirements Location for call routingCallee/caller location information must be visible to every proxyonly relevant to caller or callee can be signed, but not encryptedencryption desirable easy to find and identify in requestdoesn’t matter format negotiation not feasible  must agree on format format negotiation possible (Accept)

March 2004SIPPING - IETF 59 (Seoul)11 Location transport Three cases: 1.UA knows 2.only proxy knows 3.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)

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

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

March 2004SIPPING - 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?

March 2004SIPPING - 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)

March 2004SIPPING - 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

March 2004SIPPING - IETF 59 (Seoul)17 Testing options 1.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 2.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

March 2004SIPPING - 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”

March 2004SIPPING - 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)

March 2004SIPPING - 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 ” heard

March 2004SIPPING - 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 avoid unidentified emergency calls –could have number-dialed call redirect, but open to mischief –dial Siding  conclusion: support only if UA has recognized emergency call

March 2004SIPPING - 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?