Re: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt

["Brian Rosen" <br at brianrosen.net>]

> At 10:30 AM -0800 1/13/09, Brian Rosen wrote:
> >I'm trying to solve a problem where the user is doing the wrong thing.
> By
> >definition, his opinion is that he should terminate the call.
> 
> And you are substituting the PSAP call taker's judgement for
> the individual user's because it is statistically better.  But,
> as the "intruder" case discussed below makes clear, there are
> times when you already acknowledge that the user's judgement
> is better.
Agree, but we're in "greater good" territory

> >I do understand the "intruder" problem.
> 
> I'm glad that we have at least this common ground.
> 
> 
> >I'd like to be able to solve that
> >in the best possible way.  If the user really knew what was happening,
> they
> >would pull the battery out of the device, because any phone can be
> called
> >any time.
> 
> Note that in the "abuser" version of this, it really makes a difference
> as
> to who calls (and the abused may be hurt for failing to respond to the
> abuser's call as well as abused for reaching out for help).
Yeah

> 
> >That's not a reasonable response, and I understand that.  We have
> >a balance to strike.  Of course the override could and probably should
> be
> >proactive (that is, if you should be able to invoke the override
> before you
> >terminate).
> 
> Do you see it as reasonable to invoke the over-ride before the
> call starts?  That is, start the call in a state so that the PSAP knows
> it would not get the right to control the ending?
Yes, I do think it's reasonable.  We would have to discuss the advice to
implementers on how trivial it is to engage. It shouldn't be trivial, but it
shouldn't be very hard.

> 
> I would be more comfortable with this capability, as it also addresses
> the other concern--use/abuse of this facility by non-PSAP uses.  If
> users
> can start a call in way that prevents this facility being used, users
> can
> choose to operate in this manner in contexts where they fear abuse
> of the facility.
> 
> > That is also not a complete answer.  It seems to me that the
> >incidence of bad judgment causing serious problems is so much more
> common
> >than the intruder's shouldn't hear alerting that we ought to
> compromise in a
> >way that facilitates the former rather than the latter.  Although I'm
> not
> >entirely comfortable taking that position, I'm a heck of a lot more
> >comfortable with that then any other proposed solution.
> 
> I would guess that you're not comfortable with it for the same reason
> I am not.  It's hard to face someone whose situation got worse with
> the reasoning "well, statistically things got better".
Well, no.  I'm uncomfortable because the cost of being wrong could be high.
The reason I continue to be interested in having it is that the cost of not
having it is yet higher in the aggregate.  We can rely on the older U.S. and
Canadian experience.  Despite the fact that it's not universal, it was/is
implemented.  The problem situation you are positing is just as possible on
a Canadian wireline phone as it is on a wireless phone.   There are many,
many years of experience on how often it's helpful, and what kind of
problems it causes.  Newer technology doesn't fundamentally change anything
about the scenarios we're describing.

> 
> >I'm not at all worried about the "least surprise" issue with people
> coming
> >in from other jurisdictions.  Surprise is the most common reaction to
> people
> >in the jurisdictions it's been implemented in, mostly because you
> don't make
> >emergency calls very often.  Most Canadians don't know that the PSAP
> can
> >control termination on wireline calls.
> 
> This sounds like a great way to further fluster folks who are already
> apparently too nervous to do the right thing.
Again, we have experience to guide us here.  Yes, you get surprise, but you
also get results.  We don't have to guess how big a problem the surprise
causes.

> 
> >The current proposed mechanism is that you negotiate the feature with
> a full
> >3 way handshake.
> 
> So UA can simply fail to support the feature during this handshake as
> a form of negotiation?
Yes.  No protocol police.

> 
> > Then, normally, instead of termination, you signal
> >hookstate.  If you get stuck (the signaling of hookstate doesn't
> complete,
> >or the override is triggered), you terminate.  The PSAP has a way to
> alert.
> >All that is required to make this work in complex networks is that the
> >negotiation mechanism and the hookstate signaling mechanism is
> transparent
> >to networks and devices other than the UAS and the UAC.  If either end
> >really does send BYE, the call terminates.
> 
> I guess I don't understand how the UA sends BYE here (and thus how this
> remains "either end really does send BYE).
It sends BYE if:
 a) The override is triggered
 b) Signaling fails (e.g. the hookstate switch change signaling fails to
complete)
 c) Anything else bad happens and we're in danger of bricking the phone

So if the intermediate networks screw up, and the hookstate change signaling
gets screwed up, the UA sends BYE and the call is terminated.

Brian


_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit