ECRIT requirements update draft-schulzrinne-ecrit-requirements-01

1
ECRIT requirements updatedraft-schulzrinne-ecrit-
requirements-01

• IETF 63
• Aug 02, 2005
• Roger Marshall rmarshall_at_telecomsys.com

2
Issues since the interim meeting

• Moved security-related requirements to new
  security draft
• Allocated operational or best practice items to
  future BCP document
• Cleaned up many requirements (ref. email summary
  5/18/05)
• A1, A3 noted as needing reworded awaits
  submitted text
• R5 - H. Schulzrinne submitted text not yet
  agreed to
• D5 - reworded security requirement (M. Linsner)
• J. Polk 114 changes submitted commented and/or
  changes made
• J. Polk addl changes submitted to the list 8/01

3

• A1. Universal
• Each device and all network elements MUST
  recognize one or more universal (global)
  emergency identifiers, regardless of the location
  of the device, the service provider used (if any)
  or other factors. Examples of these might
  include 911, 112, and sos.

4

• A3. Recognizable
• Emergency calls MUST be recognizable by user
  agents, proxies and other network elements. To
  prevent fraud, an address identified as an
  emergency number for call features or
  authentication override MUST also cause routing
  to a PSAP.

5
Action resolve R5

• R5. Minimum Connectivity An emergency call
  should succeed as long as there is a working
  network path between the caller and the PSAP. In
  particular, reliance during call set-up and calls
  on entities and network paths that are located
  elsewhere should be minimized.
• Example A caller in New York who needs to
  contact a PSAP in the same city shouldn't have to
  get information from some entity in Texas to make
  that call, as the call would then fail if the New
  York to Texas path is unavailable. (To avoid
  this, the caller could, for example, have cached
  mapping information, use a local server that has
  the necessary information, or use other
  mechanisms to avoid such off-path dependencies.)
• Ed. No resolution yet agreed to for the above
  requirement.

6
Action submitted D5 (M. Linsner)

• D5 Call setup latency The ECRIT mechanism MUST
  minimize the added call setup time such that the
  user experience does not perceive abnormal delay.
• Motivation The additional properties of
  emergency calling include the need to route the
  call based on the user location. It is possible
  that the ECRIT mechanism will add to the call
  setup time when compared to non-emergency call
  setup latency. PSTN experience has shown that
  the end user will abandon a call setup if they
  perceive that the call setup is not progressing
  in timely manner. This action is exacerbated
  when a user is dealing with an emergency
  situation. If the ECRIT mechanism increases call
  setup times by factors of 1.5 or more, the user
  experience may be impacted such that calls are
  abandoned prematurely. Although hard numbers are
  not offered, the user should perceive no
  additional call setup time when using the ECRIT
  mechanism compared to establishing non-emergency
  calls.

7
Next steps

• Next draft iteration will renumber requirements
• Send comments to the list