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

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 21 Sep 2005 21:12:55 -0400

I think section 6 can back off slightly from the solution we all know is 
out there, and state the requirements a little more precisely.  I would 
rewrite the requirements as follows:

"A1a: Universal identifier -- setup.  For each signalling protocol that 
can be used in an emergency call, it must be possible to indicate, 
within every message associated with that call, that this is an 
emergency call."

Remark: does every message have to be flagged, or only the call 
initiating message?

Further remark: using sos.* in the R-URI actually fulfills two purposes: 
it flags an emergency call, and it provides a dummy emergency address 
until a real one can be determined.  If my rewriting of the requirement 
is accepted, we have a further requirement for a dummy emergency address.

"A1a+: Dummy emergency address: 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 dummy emergency address may 
be based on local convention (e.g., 911, 112, ...)."

Point of discussion: do we still need an emergency indicator in the 
signalling beyond the point of mapping?  I think we do: use case, to 
allow non-emergency calls (e.g., test calls) to go to the same URI if 
required.

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

A1b: Universal identifier -- mapping.
I'm not sure what this requirement is saying as written. The motivation 
suggests that the requirement is that signalling must contain an 
indication that it is associated with an emergency call, that is 
recognizable by any device in the signalling path that is capable of 
invoking the mapping service.

I do see a possible requirement that the mapping protocol must carry an 
indication that a given request is associated with an emergency call. 
The motivation for that requirement would be the possibility of use of 
the same protocol to the same mapping server for non-emergency purposes. 
  Then what would be needed is a purpose identifier with "emergency" as 
one of those purposes.  I suspect recent discussion is ahead of me on 
that one.

---------

A1c: Emergency marking.
In terms of my rewriting of A1a, this is two requirements:
A1c: 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.

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 dummy emergency addresses (per 
requirement A1a+) as a means to trigger emergency marking.

----------

A3: Recognizable.
I think the motivation is the requirement.  The stated requirement is 
surely covered already in A1a and A1c.  Hence the requirement should be 
stated as:

"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 a dummy emergency address to gain 
access to call features or authentication override for non-emergency 
purposes."

---------

A4 gets tweaked slightly: substitute the phrase "local dummy emergency 
addresses" for "local emergency identifiers".

Tom Taylor

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Sep 2005 09:28:49 -0400

> Remark: does every message have to be flagged, or only the call 

This is a little trickier than it might seem, security-wise. You want to 
be sure that people can only use an 'emergency' indicator for messages 
that actually go to the PSAP if such an indicator triggers special 
behavior. It would be bad, for example, if special BYE behavior is 
triggered by such an indicator and I could send random folks such marked 
messages and network elements in the middle would respect the flag.

> allow non-emergency calls (e.g., test calls) to go to the same URI if 

We do need an indicator in the signaling message as proxies may treat 
the message differently, e.g., in terms of authorization requirement. If 
the phone does the mapping, the outbound proxy needs to know that this 
is an emergency call and maybe suspend authorization.

This actually raises an interesting issue: an outbound proxy may want to 
verify that the call actually goes to a PSAP before suspending Digest 
requirements. You wouldn't want something like

INVITE sip:[email-masked]
To: urn:service:sos

to enable free gateway calls.

> requirement A1a+) as a means to trigger emergency marking.

As noted below, 'dummy' is not the term I would use here.

Agreed.

> addresses" for "local emergency identifiers".

I don't like the word "dummy". This is a logical identifier, but 
otherwise a fully real (service) identifier. This is not fundamentally 
different from

sip:[email-masked]

being redirected within IBM to

sip:[email-masked]

based on my identity or location.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 22 Sep 2005 10:00:18 -0400

Henning Schulzrinne wrote:
> Tom-PT Taylor wrote:
> 
>> I think section 6 can back off slightly from the solution we all know 
>> is out there, and state the requirements a little more precisely.  I 
>> would rewrite the requirements as follows:
>>
>> "A1a: Universal identifier -- setup.  For each signalling protocol 
>> that can be used in an emergency call, it must be possible to 
>> indicate, within every message associated with that call, that this is 
>> an emergency call."
>>
[PTT] Agreed.  Is this covered by A3?  Beyond that, I was asking if 
people even saw a requirement for marking messages beyond the initial 
message.
> 
> 
>>
>> Further remark: using sos.* in the R-URI actually fulfills two 
>> purposes: it flags an emergency call, and it provides a dummy 
>> emergency address until a real one can be determined.  If my rewriting 
>> of the requirement is accepted, we have a further requirement for a 
>> dummy emergency address.
>>
>> "A1a+: Dummy emergency address: 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 dummy 
>> emergency address may be based on local convention (e.g., 911, 112, 
>> ...)."
>>
[PTT] Hmm.  Maybe another requirement, but it's tough to implement once 
the call is in the network.  The general idea is clearly that for any 
call-initiating signalling containing the emergency indication, the 
address to which the call is being directed MUST be consistent with an 
emergency destination. The question is, if an inconsistency is found, is 
the call rejected, redirected to a PSAP, or is the emergency indicator 
cleared?
>> I'm not sure what this requirement is saying as written. The 
>> motivation suggests that the requirement is that signalling must 
>> contain an indication that it is associated with an emergency call, 
>> that is recognizable by any device in the signalling path that is 
>> capable of invoking the mapping service.
>>
[PTT] It would be good to know that I have understood this one 
correctly.  If so, I'll offer alternative text to make it more clear.

>> I do see a possible requirement that the mapping protocol must carry 
>> an indication that a given request is associated with an emergency 
>> call. The motivation for that requirement would be the possibility of 
>> use of the same protocol to the same mapping server for non-emergency 
>> purposes.  Then what would be needed is a purpose identifier with 
>> "emergency" as one of those purposes.  I suspect recent discussion is 
>> ahead of me on that one.
> 
> 
[PTT] Do people see this as a real requirement?
>> 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 dummy emergency 
>> addresses (per requirement A1a+) as a means to trigger emergency marking.
> 
> 
[PTT] Agreed.
>> surely covered already in A1a and A1c.  Hence the requirement should 
>> be stated as:
>>
[PTT] Instead of "dummy emergency address" how about "logical emergency 
address" then?

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Sep 2005 21:08:31 -0400

> people even saw a requirement for marking messages beyond the initial 

I currently do not see a requirement, although several of the 
alternatives proposed will make it almost harder *not* to do this.

> the call rejected, redirected to a PSAP, or is the emergency indicator 

A reasonable argument can be made that a provider should only reject the 
call if it actually costs them money. There have been proposals for 
using 800# for PSAPs in some cases, for example, and you wouldn't want 
to accidentally reject such a call.

Also, this is only a problem if the call is un-authenticated. In most 
residential cases, all calls will be authenticated, so you'd have to 
have a combination of factors to have things go wrong:

- mapping check fails
- no authentication available (so that you have to invoke special treatment)
- call is to a PSTN number (rather than an on-net call)
- which is not a freephone number

For i3, this combination should not happen since one wouldn't call 
regular PSTN numbers except through an ESGW.

> correctly.  If so, I'll offer alternative text to make it more clear.

This may well overlap strongly with A1a. The idea is that any call 
routing entity (SIP proxy) in the call path may need to do mapping and 
thus be able to recognize when that should happen (for emergency calls 
only).

> [PTT] Do people see this as a real requirement?

The mapping protocol proposals all seem to have some indication of the 
(emergency) service required, which seems to cover that need.

> [PTT] Instead of "dummy emergency address" how about "logical emergency 

Works, or "emergency service identifier". I hate to add yet more 
something-addresses to the stew and this is something that identifies 
the service rather than allows you to (directly) get to it.

Henning