Re: [Ecrit] Premature disconnect: UI and call stages

[<g.caron at bell.ca>]

"What I didn't realize is it's much worse than that.  If the phone just alerts, then the PSAP doesn't know the user is attempting to disconnect; she just hears silence (SIP phones shouldn't ringback, that's a local function)."

I was going to point this out on the call but we've timed out. It seems to me that UI-only alerting could potentially cause confusion at both ends. The call taker should have the ability to cause alerting based on his assessment of the situation as Brian pointed out.

Guy

-----Message d'origine-----
De : ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] De la part de Brian Rosen
Envoyé : 10 mars 2009 18:37
À : 'Ted Hardie'; 'Henning Schulzrinne'; 'ECRIT'
Objet : Re: [Ecrit] Premature disconnect: UI and call stages

I think the mechanisms apply equally to text and video devices, and expect
there are a range of UIs for such devices.  They tend to have software, and
thus look more like the third class.  Could be exceptions, like a TTY into
an ATA.

I think we did not agree on DC.  I think Henning is mischaracterizing what
some of us are asking for.  It's not disconnect control explicitly.  It's
allowing the PSAP call taker to:
1. Understand what is happening (that is, know that the caller is trying to
hang up)
2. Make a judgment that it's inappropriate to do so
3. Be able to cause an alert when the call taker believes it's appropriate
to do so
4. Provide the ability of the caller to either undo what he tried to do, or
override and really terminate the call

The call taker can always terminate.

We are advocating substituting the judgment of the call taker for the
initial judgment of the caller, but providing an override for the caller to
terminate.  That is substantively different from opt-in.  The whole point of
this is that callers make many more mistakes than call takers do in these
situations, and allowing the call taker to invoke alerting, as well as
providing some way for the call to resume if the caller responds is the most
appropriate behavior.

Call takers need information; automatic things happening that the call taker
doesn't understand is bad.  The call taker wants to know what the user is
doing (hanging up the phone, picking the phone back up, ...).  Alerting is
selective: first you decide if termination is appropriate  If it's not, you
make a judgment of whether alerting is appropriate.  Then you watch and see
what the user is doing.

I clearly wasn't thinking straight on the call when Henning was describing
his "UI-only" concept.  He wants the device to alert by itself if disconnect
is attempted on the caller side and resume the call if the caller picks back
up.  The problem I pointed out was that there is significant time between
the user (attempting to) hang up and the time the call taker decides if it's
appropriate to do, and if it is, disconnect from the PSAP side.  During that
time, the phone would be (inappropriately) alerting.  What I didn't realize
is it's much worse than that.  If the phone just alerts, then the PSAP
doesn't know the user is attempting to disconnect; she just hears silence
(SIP phones shouldn't ringback, that's a local function).  You have to
signal the disconnect attempt to get the call taker to make the judgment
call whether it's appropriate or not.  Then the call taker signals the
alert, if that's appropriate, and if the user attempts to resume, then that
needs to be signaled.

Brian

-----Original Message-----
From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf Of
Ted Hardie
Sent: Tuesday, March 10, 2009 6:00 PM
To: Henning Schulzrinne; ECRIT
Subject: Re: [Ecrit] Premature disconnect: UI and call stages

Henning,

Thanks for this very detailed summary of the call; since I got a day job
interrupt that prevented me from attending, I really appreciate it.  I
have a couple of clarification questions, below.

At 2:32 PM -0700 3/10/09, Henning Schulzrinne wrote:
>A few of the interested parties had a beer-less phone bar discussion
>on the requirements for preventing premature disconnects. Among
>others, two issues came up:
>
>(1) We need to keep in mind that there are at least three types of UAs:
>
>(black phone) Analog phone, either with a hook switch or something
>like a cordless phone, connected via an ATA. The only user interface
>capabilities are ringing and possibly caller-ID injection.
>
>(dumb Etherphone) SIP phone, with no display and a hook switch
>
>(smartphone) soft phone, smart phone, Ethernet phone with GUI

I believe that there is an underlying question here about whether
the mechanisms being described will only be used for user-agents
where voice is the primary mode of communication.  Will there be an
equivalent need for devices using real-time text or other
session-based modes that are not voice based?  Do these collapse
to "smartphone" or are they potentially a different class of
"dumb Etherphone"?

>The mechanism should work for all of these, but some devices allow for
>different, more sophisticated, user interactions. For example, devices
>with a GUI can prevent interruption of the audio path by appropriate
>user confirmation. That is clearly not possible if the receiver is
>placed on-hook on an old electromechanical phone, as the audio path is
>interrupted by a mechanical switch.
>
>(2) There seem to be two separable goals:
>
>(ADP) Accidental disconnect prevention: Make it difficult for the user
>to accidentally disconnect before the call is over. Premature
>disconnect could happen either by inadvertent action (press End button
>by accident) or by putting the phone back into the cradle, while the
>call taker wants to continue the conversation. The second case is more
>of a potential misunderstanding, rather than a UI accident, but that
>distinction may not matter.
>
>Some or all emergency calls would have this feature, indicated on a
>call-by-call basis.

Just to be clear, I do not think that lumping these in Accidental is really
much
better than calling it all "Premature".  There is a class that really is
fully
accidental (inadvertant action, according to the paragraph above).
The other, "potential misunderstanding" seems to shade into some
party making a value judgement about when the call should end.
I'd suggest keeping "Accidental" for just the inadvertent case.  If I
am missing some aspect of the conversation, of course, please let me
know.

>(DC) Disconnect control: Allow the call taker to manage the disconnect
>process *at the instant the caller disconnect attempt occurs*. At that
>time, the call taker decides whether to let the disconnect proceed and
>terminate the call or ask the user to continue/resume the call, via
>some alerting mechanism. In that case, the user indicates the desire
>to disconnect to the call taker, which the call taker can agree to or
>not.
>
>The current requirement document states (ADP) as the fundamental
>requirement (which I think we all agree on), but also implies (DC).

Did the folks on the call generally agree or disagree with DC as a
requirement?  It is a little hard to tell from what follows (you have users
"express the choice" which doesn't quite mean "retain control").

My position on this point remains that the user must volunteer to
let the call taker take this level of control and that any opt-in mechanism
is fundamentally fine by me.  Without user opt-in, I remain concerned
about a system in which that the user  "indicates the desire to disconnect/
with the call taker agreeing or not agreeing".


>Separately, we also seem to agree that the call taker needs to be able
>to call back the user on the same device, but that's a separate problem.
>
>We agree, I believe, that the caller should be able to express the
>choice not to continue the conversation, e.g., by ignoring the
>alerting or by confirming the disconnect. We also agree that "open
>microphones", i.e., the ability to silently listen in on the caller is
>not something we want.

I hadn't realized that anyone was currently requesting this.  I also
don't want this, and I'm relieved to find it didn't have support on
the call.

>If we have (ADP), but not (DC), we would satisfy the core requirement
>of preventing premature disconnect, as the UI mechanism for indicating
>"do not hang up yet" or "do you really want to hang up" is presumably
>similar. However, as Brian pointed out, you could get the situation
>that the call taker is accepts that the user hangs up and has no
>desire to continue the conversation. In that case, the phone would
>presumably produce a spurious alert and/or require an unnecessary user
>disconnect confirmation.
>
>Clearly, ADP requires no disconnect-time signaling; DC does.

This seems to imply that ADP works the same way (that is, it has
the same confirmation) no matter what the PSAP does.  The PSAP
wouldn't even see the attempt to hang up until the confirmation
occurred.  Is that your understanding?

Thanks again for the quick udpate,

                                Ted



>
>Henning
>_______________________________________________
>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

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