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

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

I managed to not reply all, sorry

-----Original Message-----
From: Brian Rosen [mailto:br at brianrosen.net] 
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
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit