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

From: "Brian Rosen" <[email-masked]>
Date: Wed, 7 Jan 2009 10:14:53 -0500

I managed to not reply all, sorry

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, January 07, 2009 9:22 AM
To: Ted Hardie
Subject: RE: [Ecrit] FW: I-D
Action:draft-rosen-ecrit-premature-disconnect-rqmts-02.txt

> At 8:14 AM -0800 1/6/09, Brian Rosen wrote:
> >Called Party Hold is no longer universally available.
> 
> Thanks for this clarification; it would be nice if future
> versions of the document noted this.
I will do so

> >  It is the fact
> >that some carriers did not require Called Party Hold of their vendors
> that
> >caused the loss of the feature.
> 
> They were able to do this, presumably, because there was no regulatory
> requirement here, eh?
That is correct.  I was not there.  I was told that there was no discussion;
the feature simply disappeared.  The PSAPs complained, the carriers told
them, "sorry, it's gone".  There have been attempts to get it back through
regulation, they have not succeeded.  To my knowledge, this hasn't been an
actual rulemaking.

> 
> >Wireless carriers never implemented it,
> >despite the PSAPs desire for it to be implemented.  I fail to see your
> >point: some jurisdictions have the capability described in the
> requirements
> >now and wish to keep it.  Others used to have it, lost it, and want it
> back.
> >Others don't think they need it, whether they had it or have it.
> 
> I guess I wasn't clear, sorry.  No jurisdiction has it now for all
> calls, because
> no calls coming from wireless devices have this capabilities.  This
> entire
> document casts this as a problem of retaining or restoring a
> capability.
This is correct: it used to be there, it's not any more.  In some
jurisdictions, it's still there in the wireline network.  The fact that it's
never been implemented in the wireless network doesn't detract from the
argument.  The point is that the PSAPs have experience with the
implementation, and it's a positive experience.  There are no negative
experiences that I know of.

> The reality is that it is about creating a new one, because it requires
> the creation of a capability in a completely different technical and
> social
> context.   In a wireline 911 context prior to this, for example, it was
> darned unlikely
> that the caller and PSAP were associated with networks in different
> jurisdictions.
> 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.

> 
> Those are different issues that those faced by the PSTN alone.  Trying
> to put
> forth the requirements from only the PSAP perspective simply isn't
> adequate
> in this context, at least in my personal opinion.
I think, since we're restricted by your request to talking about humans,
only balancing the needs and desires of the caller and the call taker.  The
carrier is not considered.  Within that restriction, we have the situation
described above.

> 
> >"Alerting" is how you describe what is desired in human terms.  The
> human is
> >alerted.  The phone "rings".
> >
> >Please tell me how, on the one hand, I am asked to describe the
> requirements
> >in human terms only, no signaling, and yet have negotiation
> requirements?
> 
> 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).

> 
> >My best answer is PD-7, where it describes that the PSAP controls
> whether
> >premature disconnect control happens on a call-by-call basis and in
> AC-3,
> >where I describe that the human may notice that abandoned call hold up
> >doesn't always happen.
> 
> Can you think of putting these requirements in terms of the user,
> rather than the PSAP's desires?
Isn't this the nut of the problem?  We're asserting that the caller makes
poor judgments in this situation.  We're suggesting that it ought to be a
PSAP decision, with the possibility of a user override.  The user isn't
going to say "oh gee, I'm stressed, you decide".  She is going to hang up
when she shouldn't.  The PSAPs response is alert and regain the connection.

You are stuck on the possibility the user actually does know better than the
PSAP what is happening.  Fine, that is why the override is there.  The
experience is that overrides aren't needed.  That's over many years of lots
of calls.  The stress and mistakes of humans aren't related to the nature of
their communications device; they make the same mistakes with wireless
handsets as they do with wireline phones.  Whether it's VoIP or analog TDM,
the user behaves the same.  Users haven't evolved to handling the stress
better.  The experience we have is relevant to the situation we have here.

The human reactions and experiences are the same, even though the technology
changed.  The user terminates, the PSAP causes the phone to alert, the user
(hopefully) responds, and the call continues.  There isn't any PSTN bias
there.  No one has suggested a better interaction model.

> 
> > I probably could improve the requirements by having
> >both a "PSAP can control" and a "User may notice" in both PD and AC
> >requirements, but I think the point comes across that it's an enabled,
> and
> >negotiated feature.
> >
> >Did you miss this text:
> >When PD-1 is enforced, the caller must not be able to place another
> call
> >until the PSAP allows the call to be released.  This requirement is
> not
> >intended to imply a user interface with multiple lines accessible
> >independently is locked to the single line that placed the emergency
> call.
> >As mistakes can be made, an override mechanism invoked by the caller
> must be
> >feasible.  The implementation must fail safely such that the phone
> cannot be
> >locked and unable to call for help.
> 
> No, I didn't miss it, but I'm apparently missing which part of my
> message
> you're referring to here.  Sorry for being dense.
It discusses how multiline phones are handled and it's the text that
explicitly requires an override, which I read your response as asking for.

> 
> >I don't see how you could have the PSAP control the function on a call
> by
> >call basis, and have it handled by UI alone.
> 
> You are looking at this as PSAP call control, rather than that at the
> base
> requirement--"The user shouldn't stop talking until the call taker says
> it is okay to go."  The UI *can* enforce that if it knows that this is
> the PSAP
> expectation.  That is metadata related to the PSAP's location in your
> system so far (since it is jurisdictional, rather than based on call
> type).  We have ways of informing people about that already.
But that isn't the requirement, that's the problem statement.  In those
terms, the call taker, in some jurisdictions, in some circumstances known
only to the PSAP, wants to hold up a call the user thinks he ought to
terminate.  The call taker needs a mechanism to alert the user and rapidly
resume conversing if/when the user responds.  That's the problem we're
solving.

The device can't know the state of the PSAP without signaling.  The
technology change does provide new capabilities, but it also has new
problems.  In this case, we have the problem that we could lose the PSAP's
BYE.   If the device thinks it ought to hold the call, the PSAP attempts to
terminate, and the BYE is lost, we have a problem.  The requirements state
that should not happen.  We also have more fine grained PSAP state
information.  For example, you don't want the feature enabled if the call is
answered by an IVR.  That is why the requirement has to be that its
negotiated call-by-call.
 
> 
> I am not saying that this is better than what you have in mind, but
> if "Don't send Bye" is agreed to by the user and enforced by the
> device based on metadata associated with the PSAP's location,
> you seem to be a long way toward where you want to be.
As above, "don't send BYE" can brick the phone.  That is why we have
abandoned solutions that don't send BYE.

> 
> This is a long way of saying please stop just repeating things like
> this:
> 
> >  It's important to have the
> >PSAP tell the device that it does or doesn't need the function.   It's
> >important that the PSAP control the alerting.  It's important that the
> PSAP
> >know the "hook state" of the call.
> 
> and have the document describe what the humans need here.  There are
> conflicts in that ("User control of the device should be absolute
> unless voluntarily
> surrendered" is in conflict with "The PSAP call taker should always end
> the
> call"), but we're not addressing those adequately with a document that
> is, forgive me, all over the map like this one.
> 
> As I said before, I don't think this document is ready to be a working
> group
> item.  I remain willing to review later iterations, and I believe that
> the
> working group should continue to do so.

Here is my problem:  

I don't know how to do better what you asked for.  I have tried, 3 times, to
meet your objections, by fundamentally altering the document.  Yet, we're
still on fundamentals; we're not arguing details.  You don't seem willing to
solve the problem, you want me to do it, and you are adamant that you don't
want this to go forward until you are satisfied. 

You aren't saying: "This is a bad idea, and we shouldn't do it".  You have
me in what seems an infinite loop of "maybe if you describe it that way,
I'll accept that it's a problem we should solve". 

You accuse me of having an implementation in mind and cooking the
requirements to meet the implementation.  On the other hand, you seem to be
in the same situation (you want it all device UI).

NENA is pretty hot about this issue.  Of course, that doesn't really matter
to IETF process, but it's not just me, it's the entire North American PSAP
community.  I'm just the point guy.  Whenever there is a new version, a NENA
work group looks it over and helps me fine tune it.  They are completely
mystified over the fuss on this; they understand the problem, they've lived
with it for many years with and without solutions, and it seems completely
obvious to them that we (IETF) should specify a solution.  

Brian

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

---

From: Marc Linsner <[email-masked]>
Date: Wed, 07 Jan 2009 15:48:56 -0500

Brian,

> regulation, they have not succeeded.  To my knowledge, this hasn't been an

It conversation with an old-timer PSTN type, it was hinted that the feature
disappeared due to the lack of regulation and the fear of liability from
bricking the caller's phone.  Without the protection of regulation, the SP
didn't want to take on that liability.  It's somewhat surprising the PSAP
wants to accept that liability.

-Marc-

---

From: Ted Hardie <[email-masked]>
Date: Fri, 9 Jan 2009 14:44:30 -0800

>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.

>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
.
>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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 13 Jan 2009 13:30:07 -0500

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

> From: Ted Hardie [mailto:[email-masked]]
> 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
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 14 Jan 2009 18:18:34 +0100

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

> 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.   

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Brian Rosen
> Sent: Tuesday, January 13, 2009 6:30 PM
> To: 'Ted Hardie'; 'ECRIT'
> Subject: Re: [Ecrit] FW: FW: I-D 
> 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 
> 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
> 
> > >> the correct PSAP for their location and make an emergency call.  
> > >> How does that phone (or that network) treat the requirements for 
> > >> CPH?
> > >have always dealt with the circumstance you are describing 
> adequately:
> > the
> > 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.
> > 
> > > >
> > > >
> > >requirement we have is that the PSAP asserts control, and the user 
> > >can override.  That is described.  To implement that, I think 
> > >signaling
> > needs
> > 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 .
> > > >
> > 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.
> > 
> > this.  Please understand my comments are not meant to 
> frustrate you or 
> > the work; they are meant to help get it right.
> > 
> > 					Ted
>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 14 Jan 2009 09:24:06 -0800

At 10:30 AM -0800 1/13/09, Brian Rosen wrote:
>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.

>"Negotiating"
>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
>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).

>That's not a reasonable response, and I understand that.  We have
>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?

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

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".

>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.

>3 way handshake.

So UA can simply fail to support the feature during this handshake as
a form of negotiation?

> Then, normally, instead of termination, you signal

I guess I don't understand how the UA sends BYE here (and thus how this
remains "either end really does send BYE).
				regards,
					Ted Hardie

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 14 Jan 2009 14:54:01 -0500

I am sorry to be dense, but I can't seem to connect the dots here.

Compatibility with what?

I have agreed to work requirements first, mechanisms later, but we all have
difficulty keeping such priorities. Most of us are engineers at heart and if
we don't see at least one solution, we're likely not going to be able to
continue to work on the problem.  That doesn't mean that better solutions
won't occur to us or others.

In this case, I am definitely not wedded to a particular solution, I do
think the requirements are getting very fuzzy (because of the limitation to
discuss it in human terms only), but I'm soldiering on.  The requirement
that you selectively negotiate call-by-call, that the PSAP understands the
state of the device, and can control termination following negotiation, and
yet fail safe, leads to the proposed solution.  If you have a better idea,
great.

Brian

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Wednesday, January 14, 2009 12:19 PM
> To: Brian Rosen; 'Ted Hardie'; 'ECRIT'
> Subject: 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.
> 
> > > >PSAP call taker better able to determine when to end the call.
> The
> > > networks
> > > >> control?  Since this isn't the same in all jurisdictions, you
> can
> > > have
> > > >> a mismatch both ways.
> > >
> > >
> > >
> > > >negotiation (both so the caller side knows what to do, and the
> PSAP
> > > knows
> > > >You are stuck on the possibility the user actually does know
> better
> > > than the
> > > >PSAP what is happening.
> > >
> > =

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 15 Jan 2009 01:44:14 +0100

My fault. Common fallacy of using the word in connection with only one side. 

What I was trying to say is that we need requirements to deal with operation with entities that want to provide the capability, and those that do not.

But the key point I was making is that you are now mentioning a negotiation mechanism for which there is no underlying requirement.

I would like you to express the requirement in the draft that the solution is meant to meet.

regards

Keith 

> Sent: Wednesday, January 14, 2009 7:54 PM
> To: DRAGE, Keith (Keith); 'Ted Hardie'; 'ECRIT'
> Subject: RE: [Ecrit] FW: FW: I-D 
> I have agreed to work requirements first, mechanisms later, 
> but we all have difficulty keeping such priorities. Most of 
> us are engineers at heart and if we don't see at least one 
> solution, we're likely not going to be able to continue to 
> work on the problem.  That doesn't mean that better solutions 
> In this case, I am definitely not wedded to a particular 
> solution, I do think the requirements are getting very fuzzy 
> (because of the limitation to discuss it in human terms 
> only), but I'm soldiering on.  The requirement that you 
> selectively negotiate call-by-call, that the PSAP understands 
> the state of the device, and can control termination 
> following negotiation, and yet fail safe, leads to the 
> proposed solution.  If you have a better idea, great.
> 
> Brian
> 
> > > 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.
> > 
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of Brian Rosen
> > > 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"
> 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).  
> > > 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.
> > >
> > > 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
> > >
> > > > >> How does that phone (or that network) treat the requirements 
> > > > >> for CPH?
> > > > >stressed people making poor judgments on when to end a 
> call, and 
> > > > >a
> > > > trained
> > > > >are, certainly, more complex.  The requirements, and 
> the proposed
> > > > mechanisms
> > > > >> 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.
> > > >
> > > >
> > > >
> > > > >requirement we have is that the PSAP asserts control, and the 
> > > > >user can override.  That is described.  To implement that, I 
> > > > >think signaling
> > > > needs
> > > > 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
> > > > of the device, unless they surrender that control voluntarily.  
> > > > The extreme example of this is the one Marc mentioned:  no one
> > > else should
> > > > 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.
> > > >

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 15 Jan 2009 15:48:28 -0500

> times when you already acknowledge that the user's judgement
Agree, but we're in "greater good" territory

> abuser's call as well as abused for reaching out for help).
Yeah

> 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.

> 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.

> 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.

> So UA can simply fail to support the feature during this handshake as
Yes.  No protocol police.

> complete,
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