[Sip] Possible improvement in draft-ietf-sipcore-invfix (CANCEL processing)
Iñaki Baz Castillo <ibc@aliax.net> Fri, 30 April 2010 22:37 UTC
Return-Path: <ibc@aliax.net>
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A291A3A6C70 for <sip@core3.amsl.com>; Fri, 30 Apr 2010 15:37:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.216
X-Spam-Level:
X-Spam-Status: No, score=-0.216 tagged_above=-999 required=5 tests=[AWL=-1.139, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3]
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 7sik3k7VC3bs for <sip@core3.amsl.com>; Fri, 30 Apr 2010 15:37:47 -0700 (PDT)
Received: from mail-pz0-f182.google.com (mail-pz0-f182.google.com [209.85.222.182]) by core3.amsl.com (Postfix) with ESMTP id CBB833A6A3F for <sip@ietf.org>; Fri, 30 Apr 2010 15:37:43 -0700 (PDT)
Received: by pzk12 with SMTP id 12so464226pzk.32 for <sip@ietf.org>; Fri, 30 Apr 2010 15:37:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.141.88.16 with SMTP id q16mr1409939rvl.156.1272667046875; Fri, 30 Apr 2010 15:37:26 -0700 (PDT)
Received: by 10.140.252.19 with HTTP; Fri, 30 Apr 2010 15:37:26 -0700 (PDT)
Date: Sat, 01 May 2010 00:37:26 +0200
Message-ID: <r2zcc1f582e1004301537w2f5a81b2xcbbd290a7a6f6e02@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: sip@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] Possible improvement in draft-ietf-sipcore-invfix (CANCEL processing)
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Apr 2010 22:37:48 -0000
Hi, RFC 3261 clearly states that an INVITE transaction is terminated upon receipt of a 200. So let's imagine a proxy between alice and bob: - alice sends INVITE to the proxy. - The proxy relays it to bob. - bob replies 200. - The proxy relays the 200 to alice and terminates the INVITE transaction. - For some reason alice sends now a CANCEL. - The proxy doesn't match a transaction for this CANCEL so it would relay it statelessly as section 16.10 states: If a response context is not found, the element does not have any knowledge of the request to apply the CANCEL to. It MUST statelessly forward the CANCEL request (it may have statelessly forwarded the associated request previously). This makes sense because such "response context" doesn't exist after the 200 was processed by the proxy. However "invfix" draft adds a new state "Accepted" so when the proxy relays the 200 the transaction remains in "Accepted" state for a while. What should happen then if the UAC sends a CANCEL? does the "response context" still exist or not? So I suggest that "invfix" draft also changes the section 16.10 of RFC 3261: If no transaction in proceeding state is found, the element does not have any knowledge of the request to apply the CANCEL to. It MUST statelessly forward the CANCEL request (it may have statelessly forwarded the associated request previously). This is, even if the transaction still exists (under "Accepted" state) the proxy has nothing to CANCEL so it shouldn't reply 200 to the CANCEL. Instead it should forward it statelessly. I think this requires some clarification in the original specification of the RFC 3261. Best regards. -- Iñaki Baz Castillo <ibc@aliax.net>
- [Sip] Possible improvement in draft-ietf-sipcore-… Iñaki Baz Castillo
- Re: [Sip] Possible improvement in draft-ietf-sipc… Paul Kyzivat
- Re: [Sip] Possible improvement in draft-ietf-sipc… Iñaki Baz Castillo
- Re: [Sip] Possible improvement in draft-ietf-sipc… Paul Kyzivat
- Re: [Sip] Possible improvement in draft-ietf-sipc… Iñaki Baz Castillo
- Re: [Sip] Possible improvement in draft-ietf-sipc… Christer Holmberg
- Re: [Sip] Possible improvement in draft-ietf-sipc… Iñaki Baz Castillo
- Re: [Sip] Possible improvement in draft-ietf-sipc… Harbhanu