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

1. ECRIT requirements updatedraft-schulzrinne-ecrit-requirements-01 IETF 63 Aug 02, 2005 Roger Marshall rmarshall@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 add’l 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