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

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 10 Mar 2009 17:32:28 -0400

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

---

From: Ted Hardie <[email-masked]>
Date: Tue, 10 Mar 2009 14:59:46 -0700

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.

>(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"?

>Some or all emergency calls would have this feature, indicated on a 

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.

>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".

>microphones", i.e., the ability to silently listen in on the caller is 

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.

>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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 10 Mar 2009 18:33:03 -0400

> Thanks for this very detailed summary of the call; since I got a day  

Just to avoid misunderstandings: We discussed other issues and I'm not  
claiming to capture everybody's opinion or input.
> to "smartphone" or are they potentially a different class of

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.

> am missing some aspect of the conversation, of course, please let me

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.

> "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.

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

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 10 Mar 2009 18:37:29 -0400

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: [email-masked] [mailto:[email-masked]] 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,

>Some or all emergency calls would have this feature, indicated on a 

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.

				Ted

---

From: <[email-masked]>
Date: Tue, 10 Mar 2009 21:46:37 -0400

"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 : [email-masked] [mailto:[email-masked]] 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

Brian

-----Original Message-----

Henning,

                                Ted

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 12 Mar 2009 19:21:03 +0200

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.  

>From: [email-masked] [mailto:[email-masked]] 
>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:
>
>(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.
>
>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.
>
>(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 
>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.
>