Emergency calling draft-ietf-sipping-sos draft-schulzrinne-emergency-arch Henning Schulzrinne Columbia University

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

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 2004 SIPPING - IETF 59 (Seoul) 2

Principles and goals • Support emergency calling in SIP-based systems – not just Vo. IP, 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 2004 SIPPING - IETF 59 (Seoul) 3

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

Emergency service identification • Old: sos. fire@example. com • New: only ‘sos’, but add callee capabilities, e. g. , – Accept-Contact: *; service=sos. fire C 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) D Can no longer be typed directly by human user D assume that users don’t type ‘sos’, but rather numbers or (rarely) select emergency services from menu D Dialplan-by-DNS mapping more difficult D no longer just a string translation March 2004 SIPPING - IETF 59 (Seoul) 5

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(x 1, y 1; x 2, y 2; …) – 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 2004 SIPPING - IETF 59 (Seoul) 6

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 2004 SIPPING - IETF 59 (Seoul) 7

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 2004 SIPPING - IETF 59 (Seoul) 8

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 2004 SIPPING - IETF 59 (Seoul) 9

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

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; a 1=“nj”; retain=“yes”) – XML LO as additional body (multi-part) March 2004 SIPPING - IETF 59 (Seoul) 11

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 1. only works if it knows whom to ask (outbound proxy) March 2004 SIPPING - IETF 59 (Seoul) 12

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

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 2004 SIPPING - IETF 59 (Seoul) 14

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 D may not work well if home AOR spans many countries (Yahoo, Hotmail) D outbound proxy not always in visited country (e. g. , IETF) March 2004 SIPPING - IETF 59 (Seoul) 15

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 2004 SIPPING - IETF 59 (Seoul) 16

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

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 2004 SIPPING - IETF 59 (Seoul) 18

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 Max. Forwards=1) March 2004 SIPPING - IETF 59 (Seoul) 19

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 March 2004 SIPPING - IETF 59 (Seoul) 20

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 March 2004 SIPPING - IETF 59 (Seoul) 21

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? March 2004 SIPPING - IETF 59 (Seoul) 22