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

1
Emergency callingdraft-ietf-sipping-sosdraft-sch
ulzrinne-emergency-arch

• Henning Schulzrinne
• Columbia University
• with Brian Rosen

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

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

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

?
?
5
Emergency service identification

• Old sos.fire_at_example.com
• New only sos, but add callee capabilities,
  e.g.,
• Accept-Contact servicesos.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 dont type sos, but rather
  numbers or (rarely) select emergency services
  from menu
• Dialplan-by-DNS mapping more difficult
• no longer just a string translation

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,y1x2,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

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)

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

9
Location transport, contd.

• 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., parvalue)
• but does make format marking more difficult
• probably good for call routing ? cant have lots
  of formats if you want reliable call routing
• Accept model of negotiation doesnt work for
  proxy-inspected items

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 doesnt matter
format negotiation not feasible ? must agree on format format negotiation possible (Accept)
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 (cnusa1njretainyes)
  
• XML LO as additional body (multi-part)

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)

13
Location transport summary

• No perfect solution
• Should clearly distinguish uses for information
  routing vs. end system information

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 dont want to renegotiate session
  parameters
• UPDATE same conceptual mismatch
• INFO non-call-state changing
• new method?

15
Determining local emergency numbers

• Pre-configured, always 112 and 911
• but cant pre-configure all emergency numbers ?
  collision with other services
• For travelers, want to support
• local (visited) emergency number
• home emergency number quick, whats 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)

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

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, doesnt 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

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

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 MaxForwards1)

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 doesnt work right now
  please dont have any accidents is not very
  helpful
• not too far-fetched radio announcements 911 out
  of service, please dial sheriffs department at
  555-1212 heard

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 sipssos_at_
• avoid unidentified emergency calls
• could have number-dialed call redirect, but open
  to mischief
• dial 1-800-Siding ? sipsos_at_sleaze-n-fraud.com
• conclusion support only if UA has recognized
  emergency call

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?