Post on 24-Dec-2015
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?