Re: [Ecrit] IETF ECRIT Design Team on Premature Call Termination
Marc Linsner <mlinsner@cisco.com> Wed, 08 October 2008 23:09 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 3D8933A6BCF; Wed, 8 Oct 2008 16:09:17 -0700 (PDT)
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 253393A6BCF for <ecrit@core3.amsl.com>; Wed, 8 Oct 2008 16:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.442
X-Spam-Level:
X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315]
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 GVFL6xfCVW6d for <ecrit@core3.amsl.com>; Wed, 8 Oct 2008 16:09:14 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 997AF3A691D for <ecrit@ietf.org>; Wed, 8 Oct 2008 16:09:14 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,381,1220227200"; d="scan'208";a="23689408"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 08 Oct 2008 23:09:56 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m98N9uQU006086; Wed, 8 Oct 2008 19:09:56 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m98N9uue015750; Wed, 8 Oct 2008 23:09:56 GMT
Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Oct 2008 19:09:56 -0400
Received: from [10.116.195.115] ([10.116.195.115]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Oct 2008 19:09:55 -0400
User-Agent: Microsoft-Entourage/12.12.0.080729
Date: Wed, 08 Oct 2008 19:09:54 -0400
From: Marc Linsner <mlinsner@cisco.com>
To: Brian Rosen <br@brianrosen.net>
Message-ID: <C512B602.CDE7%mlinsner@cisco.com>
Thread-Topic: [Ecrit] IETF ECRIT Design Team on Premature Call Termination
Thread-Index: Ackpjn5t94UDpSNVRr+DCVTYUeiODgAAXtAgAAK/5N4=
In-Reply-To: <005601c92993$17feb6b0$47fc2410$@net>
Mime-version: 1.0
X-OriginalArrivalTime: 08 Oct 2008 23:09:55.0699 (UTC) FILETIME=[FA404C30:01C9299A]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5776; t=1223507396; x=1224371396; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20<mlinsner@cisco.com> |Subject:=20Re=3A=20[Ecrit]=20IETF=20ECRIT=20Design=20Team= 20on=20Premature=20Call=20=20=20Termination |Sender:=20 |To:=20Brian=20Rosen=20<br@brianrosen.net>; bh=7re7bweHGGRbVP6UZlf1g81ZwL7wEhsPX0k2L1YbhAo=; b=qVLQw8rc3vAJWGmsETpjX7LmyWYCRh4KrB4DY4FBP34RaFrHc5sPT0mMF3 GHgyXWprsSdAG1N/LaJN5jWIL9tCEK6z3XXhsp6CMK72tYStECh8oaD2Qwru FHHrmhM4Ct;
Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
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
Brian, What document contains your proposed mechanisms? -Marc- On 10/8/08 6:13 PM, "Brian Rosen" <br@brianrosen.net> wrote: > Ted > > Lots of systems get used even when they don't meet the user's requirements. > That's what happened. I don't mean to imply that the whole thing won't work > without this feature. On the other hand, as you know, sometimes > implementers ignore requirements for financial or other reasons. I don't > think that applies here in ecrit, but it may. I just don't see how you take > a situation where carriers flat out refused to meet the requirement as > justification for not considering the requirement, or negating its > importance. The 9-1-1 system "worked" without any location. When wireless > first started, it didn't provide ANY location at all. Are you suggesting > that the location reporting requirement be dropped because millions of 9-1-1 > calls were completed without it? > > Then, I think you drop immediately into mechanism issues. You, for example, > get worried about some new negotiation phase. No one has suggested that. > The proposals that are at the front of the table use the existing > Supported/Required option negotiation mechanism. The UA indicates that it > can support the option in Supported. The PSAP indicates that it can > implement the option, and desires to employ it on the specific call, by > including it in Required. If the UA sees it in Required, and it sent it in > Supported, it enables the function. If it doesn't understand it, or doesn't > see it in Required, it's not enabled. In some folk's preferred > implementation, you use the existing Hold signaling (SDP sendrecv=inactive) > to indicate "hook state", and rather than sending BYE from the UA. The PSAP > terminates the call. The UA can terminate if it doesn't complete the > ReINVITE that signals a hook state change. I think that avoids the "brick" > problem. There is NO added latency. It doesn't use any resources that > weren't already allocated for the call. You do something similar with > CANCEL. > > Brian (who is still listening) > > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Wednesday, October 08, 2008 5:41 PM > To: Brian Rosen; 'DRAGE, Keith (Keith)'; 'Henning Schulzrinne'; 'Marc > Linsner' > Cc: 'ECRIT' > Subject: RE: [Ecrit] IETF ECRIT Design Team on Premature Call Termination > > At 1:42 PM -0700 10/8/08, Brian Rosen wrote: >> I do not accept that the telecommunications industry can override a >> reasonable requirement like this making an argument that "the operator may >> need resources for other purposes". This is an individual call, and we're >> talking about disconnect under control of one of two humans. There aren't >> many 'resources' that are available for 'other purposes'. PSAPs aren't >> dictators, nor do they have veto rights, but this is a pretty reasonable >> requirement I believe. > > I continue to believe we're talking past each other here, and my experience > has been that folks talking past each other tend to get louder and listen > less. I'm trying to avoid that by trying to go back to the basics here, > and I hope you'll take that in the spirit meant--trying to avoid this > turning > into a situation where anyone stops listening. > > At the base line, I think one of the issues is your use of the term > "requirement". A group of PSAP operators would like the system > that replaces the current system to have specific characteristics. One > of the desired characteristics is that only a PSAP call-taker can terminate > a call which has reached the PSAP. > > If Marc is correct, the Canadian jurisdiction PSAPs live without this > characteristic > for about two-thirds of their calls. The system clearly works when this > characteristic is not present. It may be a very strong desire, but there is > no overall system failure when it is not present. U.S. PSAPs had this > characteristic and it was dropped, over their objections. The 911 system > continues to work here, even without this. Call-backs and other methods > are used instead. The PSAP operators feel that this is not as good, and > they > are the experts on what works for them here; no one is denying this. > > But some of us have serious concerns about adding protocol mechanisms > to the ECRIT system to support this characteristic, especially if they > necessitate > the introduction of a negotiation phase that is not currently present. The > risks here are quite real, and they are obvious enough that even amateurs > can > see them. If a negotiation phase adds significant latency, rates of > call abandonment *will* go up. To take a ridiculous number, if it > takes 20 seconds to do this negotiation, supporting this is out of the > question. Way too many people will give up completely or be in > seriously worse straits to make that sensible. That number is clearly > not probable, but it indicates the need to balance. That same need > for balance is needed in other arenas: the need to maintain the > privacy of the user may be mandated or desired in some jurisdictions; > the need to maintain the security of the communication channel; the > need for the caller to make other calls; and, yes, the need to free > resources so that *other* callers can make their own calls > (which in disaster situations may also be to emergency services). > > I know I would feel more like I'm being heard if you acknowledged > that there are other needs to balance here, and I hope you hear that > I understand that PSAP operators have experience with this system > that I do not. > regards, > Ted Hardie > > > > > _______________________________________________ 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