Re: [Sip] RFC 3261 - 16.10 (CANCEL processing in a Proxy)
"Vijay K. Gurbani" <vkg@bell-labs.com> Tue, 19 April 2011 14:54 UTC
Return-Path: <vkg@bell-labs.com>
X-Original-To: sip@ietfc.amsl.com
Delivered-To: sip@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E9E6EE0691 for <sip@ietfc.amsl.com>; Tue, 19 Apr 2011 07:54:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.599
X-Spam-Level:
X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0HFzrs+Nu4G for <sip@ietfc.amsl.com>; Tue, 19 Apr 2011 07:54:19 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfc.amsl.com (Postfix) with ESMTP id 13F77E0664 for <sip@ietf.org>; Tue, 19 Apr 2011 07:54:18 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p3JEsCKD025989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Apr 2011 09:54:12 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3JEsCJ1026910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Apr 2011 09:54:12 -0500
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p3JEsBSs001997; Tue, 19 Apr 2011 09:54:12 -0500 (CDT)
Message-ID: <4DADA292.6060906@bell-labs.com>
Date: Tue, 19 Apr 2011 09:56:18 -0500
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9
MIME-Version: 1.0
To: ibc@aliax.net
References: <BANLkTi=mob149EFPTffkCUa+j-2dd=9k7A@mail.gmail.com>
In-Reply-To: <BANLkTi=mob149EFPTffkCUa+j-2dd=9k7A@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Cc: sip@ietf.org
Subject: Re: [Sip] RFC 3261 - 16.10 (CANCEL processing in a Proxy)
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 19 Apr 2011 14:54:20 -0000
On 04/19/2011 09:31 AM, Iñaki Baz Castillo wrote: [...] > BTW, could an always-stateful proxy reply 481 upon receipt of a CANCEL > not matching a server transaction? or should it ignore it? (this is > not contemplated in RFC 3261 as it mandates statelessly forwarding of > the CANCEL, but I hope such requeriment should be removed/relaxed in a > future revision of SIP protocol). Consider what happens if a stateful proxy proxies an INVITE downstream and then promptly crashes. It is duly chastised and quickly brought up again, and it now sees a CANCEL to the INVITE it had previously proxied downstream before crashing (assume that all the transaction state was wiped out when the proxy crashed). What should it do now? If it issues a locally generated 481, it allows the downstream server that received the INVITE to continue processing it. If it sends the CANCEL statelessly, it may hit the same downstream server and cease processing. Regardless of the behaviour of the proxy, things will still tend to work out okay since by the old SIP mantra, each transaction completes independently of others. So, regardless of whether the proxy generates a 481 (CANCEL) or sends the CANCEL downstream allowing the downstream server to generate a final response (say 2xx-class) for the CANCEL, the state machinery of the upstream UAC remains idempotent with respect to a reply. That is, the 481 or 2xx for the CANCEL closes the pending CANCEL transaction at the UAC, and it now waits for a final response for the INVITE it send out earlier. All this said, I believe that most SIP servers that operate statefully simply send out a 481 on a CANCEL they cannot match to a pending transaction. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/
- [Sip] RFC 3261 - 16.10 (CANCEL processing in a Pr… Iñaki Baz Castillo
- Re: [Sip] RFC 3261 - 16.10 (CANCEL processing in … Vijay K. Gurbani
- Re: [Sip] RFC 3261 - 16.10 (CANCEL processing in … Iñaki Baz Castillo
- Re: [Sip] RFC 3261 - 16.10 (CANCEL processing in … Vijay K. Gurbani
- Re: [Sip] RFC 3261 - 16.10 (CANCEL processing in … Iñaki Baz Castillo