Subject: [Ecrit] draft-rosen-ecrit-premature-disconnect-rqmts-01

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Nov 2008 21:15:54 -0500

Following up on what Ted said, I think one of the problems we may have  
in communicating is that we haven't quite captured all the cases.

Currently, it says "mistakes are inevitablely made", but doesn't  
really identify whose mistakes. (This sounds like something said after  
Katrina...)

I think the crucial distinction is the intent of the user for  
"premature disconnects", where we have roughly three cases:

(1) unintentional, user error (hit wrong button)

(2) unintentional, system error (something wrong in the end system,  
proxy or call path, e.g., our VoIP phone system predictably drops all  
calls after one hour or certain NATs start having a senior moment).

(3) intentional disconnect (user really meant to disconnect), but call  
taker wants to keep talking.

I think we all agree that we want to prevent (1) to the extent  
feasible. The (1) problem goes beyond disconnect. As I just found out  
during the ECRIT session, forgetting to disengage the mute button is  
at least as common as accidentally hanging up.

(2) is much harder, as the end system may not know that anything is  
amiss. In the case I mentioned, the phone keeps on sending audio. I  
don't think we can reasonably solve (2) in this context, as setting up  
a new call may exactly fix the problem, since it gets things unwedged.  
(This is true for the case of our one-hour call limit and may also be  
true for forgetful-NAT cases.)

On (3), we probably disagree how much work the caller needs to declare  
his or her intent, but we seem to agree on the general principle that  
the device owner is ultimately in charge.

Also, in the requirements, I think it would be helpful to distinguish  
two cases, again echoing Ted (and others), namely whether the end  
system reliably knows that it is in an emergency call (or callback) or  
whether it doesn't.

Starting with teasing apart the cases in the Section 1 may help us to  
make progress. I'd also re-title the document from "premature" to  
"unintentional".

Finally, what's feasible for various user actions strongly depends on  
the physical characteristics of the phone, and we probably have  
different pictures in our minds as to the ones we care about. A cell  
phone, LCD-equipped desk phone or soft phone have very different  
possibilities than a hard phone connected via a terminal adapter.  
Obviously, the current experience is mostly with devices that are much  
closer to 2500 sets than smart phones, but that's not exactly the  
future.

Henning
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit