[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Mar 10, 2009, at 5:59 PM, Ted Hardie wrote:


Henning,
Thanks for this very detailed summary of the call; since I got a day job
Just to avoid misunderstandings: We discussed other issues and I'm not claiming to capture everybody's opinion or input. 

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"?
Good question. I think the discussion focused on voice, but I suspect the issues are not altogether dissimilar for real-time text or video- for-signing, for example. I think you raise an important issue that the requirements document should note.
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.
This distinction only occurred to me while writing the note. I didn't mean to make a strong distinction between accidental and premature, but I think the "fat finger" and "misunderstanding" part may make a difference in terms of user behavior and expectations. In the case of fat finger, the user may not have realized that anything is amiss.
(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").
That's one of the points we probably did not agree on. I hope I'm not misrepresenting Brian when I say that he considers it a MUST have, while I and maybe others consider it as something worth investigating, but not a hard requirement. 





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".
We didn't discuss opt-in vs. opt-out. Part of this relates to another issue, namely what happens during the time that the call taker requests the call to continue:
(1) it just alerts, and the user can shut off the alert, but no other functions of the phone are affected.
(2) It changes the ability of the phone to place other calls, for example.
(3) The speaker/headset would continue to be connected to the call taker. 

(4) It keeps the line open, i.e., the microphone continue to operate.
We agreed that open microphones are bad, so the user would always disconnect the microphone when indicating "I want to disconnect", until he picks up again.
I think it would also be helpful for the document to acknowledge this issue. My perception is that we're talking (1) and (2), but not (3) and (4).
It's not clear to me whether by opt-in you mean a general user configuration ("my phone doesn't play by these rules") or a per-call opt-in. 






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?


Correct.
At the danger of further muddying the waters, there is also the possibility to combine ADP with a plain indication of UI actions, in the spirit of KPML or RFC 2833bis, which simply tells the call taker side what's happening ("hook flash"), but has no direct influence on call state. 




Thanks again for the quick udpate,

				Ted