Re: [Sipping] Rollback issue: a proposal

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Tue, 03 March 2009 16:16 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C58C33A6955 for <sipping@core3.amsl.com>; Tue, 3 Mar 2009 08:16:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.313
X-Spam-Level:
X-Spam-Status: No, score=-4.313 tagged_above=-999 required=5 tests=[AWL=1.336, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4]
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 JjBxEdR3SGAl for <sipping@core3.amsl.com>; Tue, 3 Mar 2009 08:16:09 -0800 (PST)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 88C923A6984 for <sipping@ietf.org>; Tue, 3 Mar 2009 08:16:08 -0800 (PST)
Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A907521132; Tue, 3 Mar 2009 17:16:34 +0100 (CET)
X-AuditID: c1b4fb3c-ac007bb000001b43-59-49ad57e218d3
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 88A0221087; Tue, 3 Mar 2009 17:16:34 +0100 (CET)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Mar 2009 17:16:34 +0100
Received: from [131.160.126.201] ([131.160.126.201]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Mar 2009 17:16:34 +0100
Message-ID: <49AD57E1.5060403@ericsson.com>
Date: Tue, 03 Mar 2009 18:16:33 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: gaoyang <gao.yang.seu@hotmail.com>
References: <49AD3182.10707@ericsson.com> <BAY115-W486685A56C504AC046B629D4A60@phx.gbl>
In-Reply-To: <BAY115-W486685A56C504AC046B629D4A60@phx.gbl>
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 Mar 2009 16:16:34.0294 (UTC) FILETIME=[6BC5B960:01C99C1B]
X-Brightmail-Tracker: AAAAAA==
Cc: sipping@ietf.org
Subject: Re: [Sipping] Rollback issue: a proposal
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2009 16:16:12 -0000

Hi,

> Comments for 
> http://www.ietf.org/internet-drafts/draft-camarillo-sipping-reinvite-00.txt
>  
> 1. I think that it is BCP level. And the solution can be effective by 
> restricting Non-2xx when Offer/Answer pair has been exchanged.

yes, we will need to decide on the status (BCP vs. PS vs. Informational)
at some point.

> 2. Your proposal considered legacy UAS. But currently, the situation is 
> legacy UAC with legacy UAS. And it is the original issue.

the draft describes the behavior of a new UAC that faces a legacy UAS,
which is the interesting situation. Other situations are not interesting
because a legacy UAC will be able to do the right thing when facing a
new UAS and if we have a legacy UAC against a legacy UAS, there is
nothing we can do because they were implemented some time ago and are
already out there.

> 3. "In order to undo changes that were already executed, the UAS uses a new
>    offer/answer exchange or a target refresh request."
> If the new offer/answer exchange need precondition, the other side can 
> reject it with 504. then the modification(undo changes) may not be done 
> by UPDATE/200OK. And Re-INVITE can not be used here(for the pending 
> original Re-INVITE).

The whole point is that the UAS should not send an error response. It
should send a 200 (OK) to the re-INVITE and then use traditional
mechanisms (i.e., UPDATEs or re-INVITEs) to modify the session if needed.


> Comments for 
> http://www.ietf.org/internet-drafts/draft-camarillo-sipping-precons-00.txt
>  
> 1. "However, the fact that the UAs can start using the new media 
> parameters does not mean that they need to start using them 
> immediately." Yes.

we agree on this one, then.

> More than one Offer/Answer pais before Precondition Ok, and Caller can 
> be answerer for some and Callee for the others. Then the two sides may 
> waiting peer using new parameters
> after Precondition OK. It may be deadlock.

No, they will not be a deadlock because the UAS is in charge of starting
using the new parameters and of initiating a new offer/answer exchange.

Thanks for your comments,

Gonzalo