Subject: [Ecrit] Summary ecrit-requirements-00 section 6: Emergency Identifier

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 26 Sep 2005 14:03:17 -0400

Just to summarize my understanding of our discussion last week, here's 
how a rewritten section 6 would look:

--------

A1a: Universal emergency indication -- setup.  For each signalling 
protocol that can be used in an emergency call, it must be possible to 
indicate, as a standard part of the protocol within the call-initiating 
message, that this is an emergency call.

Motivation: such an indication is necessary to trigger emergency 
handling including relaxation of authentication and authorization 
procedures, access to call features otherwise not available, and routing 
toward the PSAP including mapping from location when required.

A1a+: The emergency indication is required beyond the point of mapping.

Motivation: there is a continuing need for a trigger for emergency 
handling procedures in ESRPs beyond the point of mapping.

---------------

A1b: original formulation is seen as redundant, DELETED.  New requirement:

A1b': the mapping protocol also needs an emergency indication.

Motivation: this allows reuse of the mapping protocol and the mapping 
servers for non-emergency purposes.

--------

A1c: emergency marking.  Any device in the signalling path that 
recognizes by some means that the signalling is associated with an 
emergency call MUST add the emergency indication called for in A1a to 
the signalling before forwarding it.

Motivation: this ensures proper handling as an emergency call by 
downstream elements that may not recognize, for example, a local variant 
of a logical emergency address (see requirement A4+).

A1c+: User agents, proxies, and other network elements that may process 
signalling associated with emergency calls should be configured to 
recognize a reasonable repertoire of logical emergency addresses 
(described in requirement A4+ below) as a means to trigger emergency 
marking. Because emergency numbers from one region may have different 
uses in another, it is best if a network entity is able to place a call 
in the context of its point of origin before using a non-local logical 
emergency address as the basis for emergency marking.

Motivation: Out-of-region logical emergency addresses may be emitted by 
an user terminal that has been imported into a given region but is 
configured for a different home region.  The user may have dialled a 
familiar emergency number rather than the local one.  Signalling may 
have crossed regional boundaries before being processed by a network 
entity capable of performing emergency marking and other emergency 
processing.  All of these cases must be handled as emergency calls if at 
  possible.

-----------

A3. Prevention of fraud.
A call identified as an emergency call or marked as such in accordance 
with requirement A1c MUST be routed to a PSAP.

Motivation: this prevents use of the emergency call indication to gain 
access to call features or authentication override for non-emergency 
purposes.

------------

A4+: Logical emergency addresses. For each signalling protocol that can 
be used in an emergency call, reserved addresses should be available to 
use in place of an emergency address prior to the point in the 
signalling path where mapping is done.  The appropriate logical 
emergency address may be based on local convention (e.g., 911, 112, ..., 
in form appropriate to the signalling protocol).  However, it is 
desirable to have a universal logical emergency address or a set of them 
identifying specific emergency services.

Motivation: Any signalling protocol requires the use of some address to 
indicate the called party, and the user terminal may lack the capability 
to determine the actual PSAP address.  The use of local conventions may 
be required as a transition mechanism.  However, such use complicates 
international movement of the user terminal, and evolution to a 
standardized universal logical emergency address or set of addresses is 
preferable.

A4. Minimal configuration.  Any local logical emergency addresses should 
be configured into user terminals automatically, without user intervention.

Motivation: a new user terminal "unofficially imported" into an 
organization from elsewhere should have the same emergency capabilities 
as one officially installed.

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 26 Sep 2005 21:07:24 -0400

Some comments inline.

> servers for non-emergency purposes.

To avoid having two requirements that are essentially supersets of one 
another, we might simply say that it needs to indicate the emergency 
service (such as "fire") in jurisdictions where more than a single 
emergency service contact is provided.

> as one officially installed.

I think one distinction getting a bit lost is between the digits or 
symbols dialed by a user placing an emergency call and the call 
signaling emitted. The configuration is only necessary for the 
digits/symbols, as then the device can automatically translate into the 
"logical identifier". By using examples such as 911, the distinction 
between dial strings and identifiers is getting blurred. We had lots of 
problem with that in the 2806bis discussion and it would be unhelpful to 
muddy the waters again.

Btw, the discussion here addresses ECRIT charter item "A BCP describing 
how to identify a session set-up request is to an emergency response 
center".

Henning