March 2004 SIPPING - IETF 59 (Seoul) 1

Emergency callingdraft-ietf-sipping-sos

draft-schulzrinne-emergency-arch

Henning SchulzrinneColumbia University

with Brian Rosen

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

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

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

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

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

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

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

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

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

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

format negotiation possible (Accept)

March 2004 SIPPING - IETF 59 (Seoul) 11

Location transport

• Three cases:1. UA knows2. only proxy knows3. 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 2004 SIPPING - IETF 59 (Seoul) 12

Options for “proxy knows”

1. Proxy inserts location header2. 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 2004 SIPPING - IETF 59 (Seoul) 13

Location transport – summary

• No perfect solution• Should clearly distinguish uses for

information: routing vs. end system information

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

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

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

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

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

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

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

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