RE: Last Call: <draft-ietf-sipcore-199-05.txt> (Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog) to Proposed Standard

"Worley, Dale R (Dale)" <dworley@avaya.com> Tue, 08 February 2011 22:19 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413263A688C; Tue, 8 Feb 2011 14:19:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 SgNhUQM6s2BI; Tue, 8 Feb 2011 14:19:03 -0800 (PST)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 647363A6884; Tue, 8 Feb 2011 14:19:03 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAKtPUU3GmAcF/2dsb2JhbAClPHOjdgKZDYVaBIR7ijc
X-IronPort-AV: E=Sophos;i="4.60,444,1291611600"; d="scan'208";a="263840743"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 08 Feb 2011 17:19:10 -0500
X-IronPort-AV: E=Sophos;i="4.60,444,1291611600"; d="scan'208";a="579823777"
Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 08 Feb 2011 17:19:10 -0500
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.215]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Tue, 8 Feb 2011 17:19:09 -0500
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Cullen Jennings <fluffy@cisco.com>, IESG IESG <iesg@ietf.org>, "ietf@ietf.org IETF" <ietf@ietf.org>
Date: Tue, 08 Feb 2011 17:19:09 -0500
Subject: RE: Last Call: <draft-ietf-sipcore-199-05.txt> (Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog) to Proposed Standard
Thread-Topic: Last Call: <draft-ietf-sipcore-199-05.txt> (Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog) to Proposed Standard
Thread-Index: AcvG9tp8OycZ29IfRDWNxLgLbUB9PwA5d3Cj
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B220A17685A@DC-US1MBEX4.global.avaya.com>
References: <20110207170250.4107.67897.idtracker@localhost>, <3A723B49-1CCB-4E55-8122-FBF58F30D6AF@cisco.com>
In-Reply-To: <3A723B49-1CCB-4E55-8122-FBF58F30D6AF@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Feb 2011 22:19:04 -0000

________________________________________
From: ietf-bounces@ietf.org [ietf-bounces@ietf.org] On Behalf Of Cullen Jennings [fluffy@cisco.com]

I am still not aware of any use case where this actually helps. I searched the IETF and WG lists for email with the subject draft-ietf-sipcore-199 and I do not see a single email that suggests there is support for this draft or the changes in it since the previous LC.
_______________________________________________

I recall discussing the utility of 199 at one of the IETF meetings.  Indeed, I pushed Christer rather hard on the subject.  The primary use is situations where the SIP UAC is a gateway and has to allocate audio processors to each early dialog; 199 gives the downstream elements the ability to release the allocated processors when an early dialog ends, even though the UAC will not see the failure response for some time.

Since then, the proposal has gone through a number of changes that increase its value.  E.g., clarification of how it interacts with 100rel processing, ensuring it works correctly when non-199-aware SIP elements are present, providing warnings against likely errors by implementors, and allowing UACs to generate 199s on their own behalf.  (That latter is significant in the SIP environments I work with, as we put more responsibility on the UAs and make the proxies stateless.)

Dale