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/