[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] Premature disconnect: UI and call stages
Some background: At the virtual interim meeting it became clear that we got
stuck with this work.
So, Marc and I wanted to chat with some ECRIT WG members (who have expressed
a strong opinion about this subject) in order to figure out whether we can
move this topic along somehow.
As such, this was not an official ECRIT working group conference call.
The following persons participed in this call:
* Guy Caron
* Brian Rosen
* Randall Gellens
* Henning Schulzrinne
* Keith Drage
* Roger Marschall
* Marc Linsner
* Hannes Tschofenig
* (Ted Hardie was excused.)
At the end of the call I asked Henning to post the problem classification he
mentiond during the call to the mailing list. This is what you see below.
Ciao
Hannes
PS: I think Roger took some more detailed notes.
>-----Original Message-----
>From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
>On Behalf Of Henning Schulzrinne
>Sent: 10 March, 2009 23:32
>To: ECRIT
>Subject: [Ecrit] Premature disconnect: UI and call stages
>
>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
>_______________________________________________
>Ecrit mailing list
>Ecrit at ietf.org
>https://www.ietf.org/mailman/listinfo/ecrit
>