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

[Ted Hardie <hardie at qualcomm.com>]

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