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

["DRAGE, Keith \(Keith\)" <[e-mail]>]

Speaking as an amateur who has been working in the telecommunication
industry for 30 years:

There are multiple interests to balance here, and the PSAP provider is
only one of these.

Emergency calls do not override other telecommunication needs, the user
may need to make another call, the telecommunications operator may need
the resources for other purposes, etc. Different regulators specify
different things.

Regards

Keith 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Brian Rosen
> Sent: Wednesday, October 08, 2008 6:57 PM
> To: 'Ted Hardie'; 'Henning Schulzrinne'; 'Marc Linsner'
> Cc: 'ECRIT'
> Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call 
> Termination
> 
> I disagree.
> 
> What we have is a bunch of amateurs on how you handle 
> emergency calls trying to tell the experts that what they 
> want is wrong.
> 
> Every one of the kinds of user related issues that have been 
> raised have occurred enough times that we can listen to the 
> PSAP guys who say "on balance, its better to have the PSAP 
> control disconnect".  It's not foolproof, and I agree that we 
> can't brick a phone, and I agree you can always pull the plug 
> or pull out the battery or whatever.  There are, I believe, 
> jurisdictions to actively don't want this feature, and others 
> who insist it is a REQUIREMENT to have the feature.  There a 
> lots who are "it would be nice".
> 
> Sure, UI is important here.  Some text on multiline might be 
> appropriate that is all about UI and But the IETF problem is 
> the signaling: no one is arguing that it is sometimes the 
> right thing to let the user disconnect.  So it's not an 
> absolute, "don't send BYE" or disable the button on the UI.
> There is negotiation of the feature.
> 
> Brian
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Ted Hardie
> Sent: Wednesday, October 08, 2008 12:30 PM
> To: Henning Schulzrinne; Marc Linsner
> Cc: 'ECRIT'
> Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call 
> Termination
> 
> 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
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
> 
_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit