Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination

[Ted Hardie <[e-mail]>]

At 7:03 AM -0700 10/8/08, Henning Schulzrinne wrote:
>No requirement stands on its own. Particularly in this case, proposed
>solutions have had severe side effects that may well outweigh whatever
>call handling functionality is gained. Thus, we need to look at the
>whole picture, not just one requirement.

The "whole picture" issue is the key point here, and I agree with
Henning that some of the key issues we need to treat  are
whether the mechanism interferes with the user's use of the phone,
whether it creates security vulnerabilities, and whether it
has privacy implications.  I also worry, personally, that the
introduction of this requirement implies either a new requirement
for a negotiation phase or that other responders take up this
behavior.  Both possibilities introduce fragility into the system
and its deployment.

As an additional point, I really question whether the right place to do this
is in the network protocol.  The majority of this behavior is actually
better achieved in the UI, at least in my opinion.  Having the phone
software disable the terminate button for emergency calls and emit
a warning when it is pressed gets the 80% of the 80/20 with no
protocol behavior at all.  I think you'd have to have some UI
changes anyway, simply because this requirement violates the
principle of least surprise.  If I think pressing the red button ends
a call and it does for every call but calls to 911 in Canada, you're
going to want some additional UI signal to let the user known the
call didn't end. 

Having the PSAPs say "We have a requirement" is a useful part of
the dialog on this, and goodness knows that the IETF is not filled
with the sum total of expertise in this area.  But we may well
have the expertise to say "This belongs in some other part of the
system in a world based on multi-line phones using VoIP; the
circuit switched model for this won't work well here".  In fact,
I think we *have* said that, and we're trying to achieve consensus
while talking past each other.  To quote my favorite flying squirrel:
"That trick never works".

				Ted




>For example, any such
>mechanism must not brick a caller's phone, must not create the ability
>to eavesdrop on users and must not increase security vulnerabilities.
>It may also help to have a less-mechanism-focused requirement. Since
>the user has placed the receiver on hook (on a traditional phone, at
>least), from a user perspective, this is no different than being
>called back, unless you indeed make the phone non-operable.
>
>In the end, the user also has a right to be left alone. If the caller
>no longer wants to talk to the PSAP, forcing him to do that seems
>inappropriate and may well be against the law (or at least should be,
>in a society that calls itself free). We want to prevent accidental
>disconnects, but the PSAP has no right to take over the user's phone,
>listen to the user's environment without permission or perform other
>intrusive acts. Unfortunately, the current requirement document does
>not reflect any of these concerns.
>
>Henning
>
>On Oct 8, 2008, at 9:19 AM, Marc Linsner wrote:
>
>> Brian,
>>
>> I have no problem entertaining new requirements.  I simply want the
>> motivation ("We have to do this because") to be spun correctly.
>>
>> I also believe this demands a viewpoint from the 'other' party, the
>> PSAP
>> customer, Joe Citizen.
>>
>> If in fact a solution can to designed that fulfills the requirement
>> and
>> protects Joe's desires, I have no problem.
>>
>> -Marc-
>>
>
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit