[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