[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt
At the risk of backward engineering, I don't find a requirement at the moment that would lead to this being adopted as a solution.
I believe I made comments to the effect that we need to deal with compatibility in my review.
Keith
> The current proposed mechanism is that you negotiate the
> feature with a full
> 3 way handshake. 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.
> -----Original Message-----
> From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
> On Behalf Of Brian Rosen
> Sent: Tuesday, January 13, 2009 6:30 PM
> To: 'Ted Hardie'; 'ECRIT'
> Subject: Re: [Ecrit] FW: FW: I-D
> Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt
>
> 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. "Negotiating"
> with the user is not possible. We can do something and
> provide an override, but it doesn't work to negotiate with the user.
>
> I do understand the "intruder" problem. 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. 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). 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'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.
>
> The current proposed mechanism is that you negotiate the
> feature with a full
> 3 way handshake. 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.
>
> Brian
>
> > -----Original Message-----
> > From: Ted Hardie [mailto:hardie at qualcomm.com]
> > Sent: Friday, January 09, 2009 5:45 PM
> > To: Brian Rosen; 'ECRIT'
> > Subject: Re: [Ecrit] FW: FW: I-D Action:draft-rosen-ecrit-premature-
> > disconnect-rqmts-02.txt
> >
> > > > But the system we've put together here allows for someone in
> > Toronto
> > >> whose only working phone happens to tunnel back to Germany to
> > determine
> > >> the correct PSAP for their location and make an emergency call.
> > >> How does that phone (or that network) treat the requirements for
> > >> CPH?
> > >There is no fundamental change in the social context.
> > >You still have
> > >stressed people making poor judgments on when to end a call, and a
> > trained
> > >PSAP call taker better able to determine when to end the call. The
> > networks
> > >are, certainly, more complex. The requirements, and the proposed
> > mechanisms
> > >have always dealt with the circumstance you are describing
> adequately:
> > the
> > >feature is enabled call by call at the PSAP and works
> across complex
> > >networks such as the ones you describe.
> >
> > I believe that the mechanisms you've described so far would
> only work
> > across complex networks provided every network in the world
> was aware
> > of and obedient to this signalling. The "don't tear down flows"
> > requirement
> > is pretty much not how things work in many networks now, and this
> > would require all networks now to watch for signalling and
> keep state
> > in a way they do not.
> >
> > Could we get there? With enough will, certainly. But
> "works across
> > complex networks" does not seem to describe the current
> state of play.
> > It is possible that I am misunderstanding the mechanisms proposed.
> > That wouldn't be unlikely and would probably be at least partly my
> > fault, since I've been among those asking for the
> requirements to be
> > worked out prior to the mechanisms being developed. Sorry, if so.
> >
> > > >
> > > >
> > > > Perhaps by making a requirement that there is a need
> for agreement
> > >> here between the human user and the PSAP on who should have this
> > >> control? Since this isn't the same in all jurisdictions, you can
> > have
> > >> a mismatch both ways.
> >
> >
> >
> > >But there isn't a negotiation between the caller and the
> PSAP. The
> > >requirement we have is that the PSAP asserts control, and the user
> > >can override. That is described. To implement that, I think
> > >signaling
> > needs
> > >negotiation (both so the caller side knows what to do, and the PSAP
> > knows
> > >whether it's going to be able to assert control).
> >
> > And here is the crux of the matter. The PSAPs want to
> assert control.
> > That will violate the principle of least surprise for at least some
> > users who come from different jurisdictions or whose phones using
> > other technologies do not behave this way, and it will not
> be desired
> > by others even if they aren't surprised by it .
> > > >
> > >You are stuck on the possibility the user actually does know better
> > than the
> > >PSAP what is happening.
> >
> > I see a tension here you do not. The user should always be
> in control
> > of the device, unless they surrender that control voluntarily. The
> > extreme example of this is the one Marc mentioned: no one
> else should
> > be able to brick your phone in an emergency. The other
> examples given
> > have been knocked back as unlikely (the abuser/home
> intruder example,
> > where the hang up *must* happen, the anonymous tip example, etc.).
> > Maybe those are unlikely in the world these PSAPs serve. But the
> > possibility of abuse here is also pretty scary, even if it abuse by
> > authorities in jurisdictions different from the current
> users of the
> > related feature.
> >
> > We have to get this right if we do it, and that means we
> have to treat
> > the desires of both parties. From my way of thinking that
> implies a
> > much more negotiated approach than the "PSAP desires control this"
> > tone of the proposals to date. Absent a willingness to do
> that, I will
> > move on to the position "this is a bad idea, let's not do it".
> > You may well get rough consensus over my objections, but I would
> > rather than you heard them and took them seriously.
> >
> > If I have not said so lately, let me repeat: thanks for
> your work on
> > this. Please understand my comments are not meant to
> frustrate you or
> > the work; they are meant to help get it right.
> >
> > Ted
>
> _______________________________________________
> Ecrit mailing list
> Ecrit at ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit