IETF Logo Mail Archive

Re: [Sip] Possible improvement in draft-ietf-sipcore-invfix (CANCEL processing)

Iñaki Baz Castillo <ibc@aliax.net> Sun, 02 May 2010 10:43 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 C3F473A6835 for <sip@core3.amsl.com>; Sun, 2 May 2010 03:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.081
X-Spam-Level:
X-Spam-Status: No, score=-0.081 tagged_above=-999 required=5 tests=[AWL=-0.818, BAYES_40=-0.185, 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 jT6PMX-Iwr-d for <sip@core3.amsl.com>; Sun, 2 May 2010 03:43:42 -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 1E7673A67D3 for <sip@ietf.org>; Sun, 2 May 2010 03:43:42 -0700 (PDT)
Received: by pzk12 with SMTP id 12so959472pzk.32 for <sip@ietf.org>; Sun, 02 May 2010 03:43:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.141.15.4 with SMTP id s4mr2628224rvi.112.1272797004233; Sun, 02 May 2010 03:43:24 -0700 (PDT)
Received: by 10.140.252.19 with HTTP; Sun, 2 May 2010 03:43:24 -0700 (PDT)
In-Reply-To: <4BDCFCE8.6040107@cisco.com>
References: <r2zcc1f582e1004301537w2f5a81b2xcbbd290a7a6f6e02@mail.gmail.com> <4BDCFCE8.6040107@cisco.com>
Date: Sun, 02 May 2010 12:43:24 +0200
Message-ID: <x2gcc1f582e1005020343t46f18e23mcbfc191e38398e4b@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: Paul Kyzivat <pkyzivat@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: sip@ietf.org
Subject: Re: [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: Sun, 02 May 2010 10:43:42 -0000

2010/5/2 Paul Kyzivat <pkyzivat@cisco.com>:
> Iñaki,
>
> I don't understand what the point is of sending, or forwarding, this CANCEL.
> There is nothing left to cancel. The only possibility would be if the INVITE
> had been forked somewhere along the path. But if it had, the forking proxy
> would have seen the 200 and sent a CANCEL on its own. So there is no reason
> for the UAC to send a CANCEL in this case.

Hi Paul, I do know that the UAC shouldn't send the CANCEL, but it
could occur (race conditions, 200 reply lost in the network...). So
the proxy must know how to behave when a CANCEL arrives for an INVITE
transaction in "Accepted" state, something that doesn't make sense in
the original 3261 specification as the proxy terminates the INVITE
transaction when the 200 arrives (immediately).

I think innfix draft should clarify it: what should do a proxy when a
CANCEL arrives and matches an INVITE transaction in "Accepted" state?


-- 
Iñaki Baz Castillo
<ibc@aliax.net>

v2.23.0 | Report a Bug | By Email