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

From: "Roger Marshall" <[email-masked]>
Date: Thu, 13 Oct 2005 19:32:26 -0700

Tom:
Subj: Section 6, Emergency Identifier
Thanks for your extensive input.  Quite a lot different here now.

Please see my comments inline. 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Tom-PT Taylor
>Sent: Monday, September 26, 2005 11:03 AM
>To: ECRIT; Henning Schulzrinne
>Subject: [Ecrit] Summary ecrit-requirements-00 section 
>6:Emergency Identifier
>
>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.

Slight rewording of the requirement, (motivation left alone), from 
how you have it,

A1a: Universal emergency indication - call setup.  For each 
signaling protocol that is used to set up an emergency call, 
there MUST be an indication, as a standard part of the message 
protocol, that it is an emergency call.

>
>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.

This is probably a good idea.  I have reformed this new requirement
some, as follows:

A1a+: Universal emergency indication - sustained.  There MUST be
retained, 
(or supplied) an universal emergency indication as a standard part of
the message 
protocol all through call routing, even after the mapping protocol has
been invoked.

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.

Please see my response to Henning's subsequent email on this one.

>
>--------
>
>
>
>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+).

Above requirement accepted as is.included with minor editing changes as
follows:

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

Motivation: Marking 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.

Condensed above requirement into the following requirement and
motivation text:

A1c+.  Network Element Initiated Marking: User 
agents, proxies, and other network elements that process signaling 
associated with emergency calls SHOULD be configured to recognize a 
reasonable selection of logical emergency identifiers (described in 
requirement A4+ below) as a means to initiate emergency marking.

Motivation:  Since user devices roam, emergency identifiers may vary 
from region to region.  It is therefore important that a network entity
be 
able to perform mapping and/or call routing within the context of its
own 
point of origin rather than relying on non-local logical emergency 
identifiers as the only basis for emergency marking of calls.

>
>-----------
>
>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.

Changed as proposed within draft.

>
>------------
>
>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.

Condensed the text above to be included in draft as follows:

A4+: Emergency Identifier Replacement. For each signaling 
protocol that can be used in an emergency call, reserved 
addresses SHOULD be allowed to replace the original 
emergency identifier, based on local conventions, regulations, 
Or preference (in the case of an enterprise, for example). 

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.  Note: Such use complicates international 
movement of the user terminal, and evolution to a standardized 
universal logical emergency identifier or set of identifiers 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.

Again, please see my response to Henning's subsequent email on this one.

Roger Marshall

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

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