Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination

"Brian Rosen" <br@brianrosen.net> Thu, 06 November 2008 20:17 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 5C0573A6813; Thu, 6 Nov 2008 12:17:16 -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 A3EB13A6813 for <ecrit@core3.amsl.com>; Thu, 6 Nov 2008 12:17:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.195
X-Spam-Level:
X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599]
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 pRCOxeSLrjCg for <ecrit@core3.amsl.com>; Thu, 6 Nov 2008 12:17:13 -0800 (PST)
Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id A693F3A67E3 for <ecrit@ietf.org>; Thu, 6 Nov 2008 12:17:13 -0800 (PST)
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <br@brianrosen.net>) id 1KyBH6-0002Jn-OI; Thu, 06 Nov 2008 14:16:20 -0600
From: Brian Rosen <br@brianrosen.net>
To: 'Randall Gellens' <randy@qualcomm.com>, 'Ted Hardie' <hardie@qualcomm.com>, 'Henning Schulzrinne' <hgs@cs.columbia.edu>, 'Marc Linsner' <mlinsner@cisco.com>
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>
In-Reply-To: <p06240613c538f7e80d6e@loud.qualcomm.com>
Date: Thu, 06 Nov 2008 15:16:17 -0500
Message-ID: <03d101c9404c$8a8899b0$9f99cd10$@net>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AclASsE0mpFKELNjR4CHUkwGuirmXgAAaRsw
Content-Language: en-us
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Source:
X-Source-Args:
X-Source-Dir:
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ecrit-bounces@ietf.org
Errors-To: ecrit-bounces@ietf.org

Seems fairly reasonable.  I think it's acceptable to be "offer by UAC,
accept by UAS".  I don't think you need the reverse.

Brian

-----Original Message-----
From: Randall Gellens [mailto:randy@qualcomm.com] 
Sent: Thursday, November 06, 2008 2:52 PM
To: Brian Rosen; 'Ted Hardie'; 'Henning Schulzrinne'; 'Marc Linsner'
Cc: 'ECRIT'
Subject: Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination

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