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

Harbhanu <harbhanu@huawei.com> Tue, 25 May 2010 05:50 UTC

Return-Path: <harbhanu@huawei.com>
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 9246E3A69BE for <sip@core3.amsl.com>; Mon, 24 May 2010 22:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.695
X-Spam-Level:
X-Spam-Status: No, score=-0.695 tagged_above=-999 required=5 tests=[AWL=1.604, BAYES_00=-2.599, 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 VHojcKlIksit for <sip@core3.amsl.com>; Mon, 24 May 2010 22:50:07 -0700 (PDT)
Received: from szxga05-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2F1663A69AA for <sip@ietf.org>; Mon, 24 May 2010 22:50:04 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2Y00HIOO777Z@szxga05-in.huawei.com> for sip@ietf.org; Tue, 25 May 2010 13:49:55 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2Y00G0CO764V@szxga05-in.huawei.com> for sip@ietf.org; Tue, 25 May 2010 13:49:55 +0800 (CST)
Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L2Y00LMGO74FL@szxml04-in.huawei.com> for sip@ietf.org; Tue, 25 May 2010 13:49:54 +0800 (CST)
Date: Tue, 25 May 2010 11:19:51 +0530
From: Harbhanu <harbhanu@huawei.com>
In-reply-to: <AANLkTikG37fIUFG9Djb3P4SP1BDA56sT1wSaWNyNX9Vu@mail.gmail.com>
To: 'Iñaki Baz Castillo' <ibc@aliax.net>, 'Christer Holmberg' <christer.holmberg@ericsson.com>
Message-id: <893E240AB09A4A4AA67A8AEF0CCA2B88@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4325
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: quoted-printable
Thread-index: Acr7W8IRy3e0hvLKQNSD0w7lq+et4gAbmlcg
References: <r2zcc1f582e1004301537w2f5a81b2xcbbd290a7a6f6e02@mail.gmail.com> <4BDCFCE8.6040107@cisco.com> <x2gcc1f582e1005020343t46f18e23mcbfc191e38398e4b@mail.gmail.com> <4BDDBED0.3020600@cisco.com> <w2wcc1f582e1005021117o191d2222v370ee4b941d922bd@mail.gmail.com> <FF84A09F50A6DC48ACB6714F4666CC7465C556F11E@ESESSCMS0354.eemea.ericsson.se> <AANLkTikG37fIUFG9Djb3P4SP1BDA56sT1wSaWNyNX9Vu@mail.gmail.com>
Cc: sip@ietf.org, 'Paul Kyzivat' <pkyzivat@cisco.com>
Subject: Re: [Sip] Possible improvement in draft-ietf-sipcore-invfix (CANCELprocessing)
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: Tue, 25 May 2010 05:50:10 -0000

IMO it's correct for proxy to reply with '200 CANCEL', evne incase it has
already forwarded a final response.
Here, since the UAC will receive the final response of INVITE, then it will
send a BYE.

We can relate its similarity to handling of CANCEL at UAS after being sent
an INVITE 2xx, as per 3261 itself -
   If the transaction for the original request still exists, the behavior of
the UAS on receiving a CANCEL request depends on whether it has already sent
a final response for the original request.

Also, similar race might happen when there are multiple stateful proxies in
path and CANCEL and INVITE 2xx are converging towards each other from
different UA ends.

Thus as said below, it simply means "Ok, I got the request".

Regards,
Harbhanu

****************************************************************************
***********
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Iñaki
Baz Castillo
Sent: Monday, May 24, 2010 6:31 PM
To: Christer Holmberg
Cc: sip@ietf.org; Paul Kyzivat
Subject: Re: [Sip] Possible improvement in draft-ietf-sipcore-invfix
(CANCELprocessing)

2010/5/24 Christer Holmberg <christer.holmberg@ericsson.com>:
>
> Hi,
>
> My understanding is that 200 OK for the CANCEL only means "Ok, I got the
request".
>
> It is the INVITE response that matters. If the INVITE transaction was
cancelled, the UAC would not have received a 200 OK for the INVITE.


Hi, let me re-explain my example (assuming the proxy implements invfix
draft:


- alice sends INVITE to the proxy.
- The proxy relays it to bob.
- bob replies 200.
- The proxy relays the 200 to alice. The INVITE transaction in the
proxy remains in "Accepted" state (invfix addition).
- alice sends now a CANCEL (before receiving the 200 for the INVITE).
- The proxy receives the CANCEL and matches the existing INVITE
transaction (in "Accepted" state), what should it reply? "200
Canceled"? there is nothing to cancel right now as a 200 was already
received by the proxy.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors@cs.columbia.edu for questions on how to develop a SIP
implementation.
Use dispatch@ietf.org for new developments on the application of sip.
Use sipcore@ietf.org for issues related to maintenance of the core SIP
specifications.