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

["Brian Rosen" <[e-mail]>]

I do not accept that the telecommunications industry can override a
reasonable requirement like this making an argument that "the operator may
need resources for other purposes".  This is an individual call, and we're
talking about disconnect under control of one of two humans.  There aren't
many 'resources' that are available for 'other purposes'.  PSAPs aren't
dictators, nor do they have veto rights, but this is a pretty reasonable
requirement I believe.  Regulation is an area we have to be cognizant of,
and I do think we will have areas where this gets regulated on or off, but
that just shows that the feature does need to be negotiated.

We have experience here.  Lots of experience.  The experience says that the
value of the feature is much greater than the problems it creates, at least
when implemented the way it is/was implemented.  Different technology brings
different challenges, but the core requirement, and it's value judgment,
doesn't change.  One of the things I have to keep repeating to PSAPs is that
in this change from TDM termination (at the PSAP) to IP termination, lots
and lots of technology is changing.  Nearly every subsystem they now have
will be obsolete. However, the way the call taker handles a call won't
fundamentally change.  They still answer a call the way any call taker in
any call center answers a call, they still "say" the local equivalent of
"9-1-1, what is your emergency?".

The experience answering millions of calls suggests that the caller is
better served when the call taker controls disconnect.  It isn't ALWAYS
true.  It's mostly true.  That's the basis of a good requirement.

Brian
-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[e-mail]] 
Sent: Wednesday, October 08, 2008 2:46 PM
To: Brian Rosen; Ted Hardie; Henning Schulzrinne; Marc Linsner
Cc: ECRIT
Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call Termination

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