[Ecrit] Premature disconnect: UI and call stages

[Henning Schulzrinne <hgs at cs.columbia.edu>]

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

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.

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

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.

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.


Henning