Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination
Henning Schulzrinne <hgs@cs.columbia.edu> Sat, 08 November 2008 21:28 UTC
Return-Path: <ecrit-bounces@ietf.org>
X-Original-To: ecrit-archive@megatron.ietf.org
Delivered-To: ietfarch-ecrit-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 713263A69D3; Sat, 8 Nov 2008 13:28:51 -0800 (PST)
X-Original-To: ecrit@core3.amsl.com
Delivered-To: ecrit@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6FF3A69D3 for <ecrit@core3.amsl.com>; Sat, 8 Nov 2008 13:28:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.592
X-Spam-Level:
X-Spam-Status: No, score=-3.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8T6tgwyyyJyG for <ecrit@core3.amsl.com>; Sat, 8 Nov 2008 13:28:49 -0800 (PST)
Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id A8D8A3A6916 for <ecrit@ietf.org>; Sat, 8 Nov 2008 13:28:49 -0800 (PST)
Received: from [192.168.0.48] (pool-70-21-181-81.nwrk.east.verizon.net [70.21.181.81]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id mA8LSCMc024955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 8 Nov 2008 16:28:34 -0500 (EST)
Message-Id: <8CCBE056-C585-40E9-B656-CFCB0114871E@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
To: Randall Gellens <randy@qualcomm.com>
In-Reply-To: <p06240613c538f7e80d6e@loud.qualcomm.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Sat, 08 Nov 2008 16:28:00 -0500
References: <C5122B8B.CD64%mlinsner@cisco.com> <FCBD2756-A298-4593-BEEF-04A47174507F@cs.columbia.edu> <p06240600c5128d04a432@[10.227.68.106]> <073101c9296f$4ddbd110$e9937330$@net> <p06240613c538f7e80d6e@loud.qualcomm.com>
X-Mailer: Apple Mail (2.929.2)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8
Cc: 'ECRIT' <ecrit@ietf.org>
Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ecrit>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ecrit-bounces@ietf.org
Errors-To: ecrit-bounces@ietf.org
I think there's a subtle difference between "accidental" and "premature" call termination. The former is easy to define: the caller accidentally disconnected, either because of hitting the wrong button or some technical problem, and would have preferred to stay on line. The second is harder to define, since both sides may have a different opinion as to whether the disconnect is "premature". Accidental disconnects are also premature, but not the other way around. The difference is the set where the PSAP wants to continue to talk, but the caller doesn't. We can prevent accidental disconnects largely with UI features, such as requiring user confirmation for hanging up. I think we can also prevent most legitimate premature terminations of the "caller doesn't realize the call taker wants to continue to talk, but has no objection" with appropriate UI design. A simple modal dialogue with "Please wait until the emergency call taker disconnects. Do you really want to terminate the call now?" before sending the BYE will presumably deal with most cases. The correct behavior depends a bit on the device. For example, an iPhone has different possibilities than a traditional place-receiver- on-hook phone (although that type of phone could conceivably switch to speakerphone mode until the user confirms the disconnect, with some kind of alerting to prevent eavesdropping). None of this requires more than recognizing that this is an emergency call. This is tricky for two cases: proxy-recognized calls and return calls. Henning On Nov 6, 2008, at 2:51 PM, Randall Gellens wrote: > At 1:57 PM -0400 10/8/08, Brian Rosen wrote: > >> Sure, UI is important here. Some text on multiline might be >> appropriate >> that is all about UI and But the IETF problem is the signaling: no >> one is >> arguing that it is sometimes the right thing to let the user >> disconnect. So >> it's not an absolute, "don't send BYE" or disable the button on the >> UI. >> There is negotiation of the feature. > > I think the issue of PSAP control over termination is both > signalling and UI. It can't be UI-only, because it needs to be > optionally invoked by the PSAP. Presumably, PSAPs only want to > invoke it when the call is being handled by a call taker, not when > it's in a call queue or IVR, so there definitely needs to be > signalling. Also, the PSAP probably needs to be able to initiate > the signalling regardless of whether it is the called or calling > party. Consider situations where someone places a call, and the > PSAP needs to call back for whatever reason (and there are multiple > possible reasons why the PSAP might need to call back, even in the > presence of this feature). > > Given this, it probably makes sense that control over call > termination be negotiated by SIP signalling that can be sent during > the call by either end. Presumably, the user's device would have > some criteria for accepting such a request to cede termination > control (since you'd want this to be accepted when made by a PSAP > but not when made by a telemarketer). Once the user's device > accepted such a request, presumably it would not send a BYE, and the > UI would indicate the situation to the user, hopefully taking full > advantage of the UI richness afforded by modern devices. > Presumably, a PSAP wanting to invoke the feature would make the > request when the call taker came on the line, thus avoiding problems > with IVRs and call queues. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself > only > -------------- Randomly-selected tag: --------------- > Procedures! Of course, that's what you'd use with a *sophisticated* > machine like this. Procedures. --'Ceaser Smith' in _Hot_Millions_ > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Henning Schulzrinne
- [Ecrit] IETF ECRIT Design Team on Premature Call … Hannes Tschofenig
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Ted Hardie
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Henning Schulzrinne
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Brian Rosen
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… James M. Polk
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Ted Hardie
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Brian Rosen
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… DRAGE, Keith (Keith)
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… DRAGE, Keith (Keith)
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… James M. Polk
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Brian Rosen
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Brian Rosen
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Ted Hardie
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Brian Rosen
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Ted Hardie
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Marc Linsner
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… James M. Polk
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Brian Rosen
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Marc Linsner
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… DRAGE, Keith (Keith)
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Ted Hardie
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Brian Rosen
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… DRAGE, Keith (Keith)
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Brian Rosen
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Ted Hardie
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Brian Rosen
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Marc Linsner
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Brian Rosen
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Henning Schulzrinne
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Marc Linsner
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Randall Gellens
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Brian Rosen
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Randall Gellens
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Brian Rosen
- Re: [Ecrit] IETF ECRIT Design Team on Premature C… Henning Schulzrinne