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

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



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
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit