Re: [Sipping] Rollback issue: a proposal

Paul Kyzivat <pkyzivat@cisco.com> Tue, 03 March 2009 14:50 UTC

Return-Path: <pkyzivat@cisco.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 CC9A63A6A0C for <sipping@core3.amsl.com>; Tue, 3 Mar 2009 06:50:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[AWL=3.897, BAYES_00=-2.599, 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 22+pBeuEUCfJ for <sipping@core3.amsl.com>; Tue, 3 Mar 2009 06:50:07 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id CF02D3A69EB for <sipping@ietf.org>; Tue, 3 Mar 2009 06:50:07 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.38,296,1233532800"; d="scan'208";a="149840455"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 03 Mar 2009 14:50:34 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n23EoYaU004124; Tue, 3 Mar 2009 09:50:34 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n23EoYB1002322; Tue, 3 Mar 2009 14:50:34 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Mar 2009 09:50:34 -0500
Received: from [161.44.174.105] ([161.44.174.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Mar 2009 09:50:34 -0500
Message-ID: <49AD43B9.7070108@cisco.com>
Date: Tue, 03 Mar 2009 09:50:33 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
References: <49AD3182.10707@ericsson.com>
In-Reply-To: <49AD3182.10707@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 Mar 2009 14:50:34.0195 (UTC) FILETIME=[681D1A30:01C99C0F]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1758; t=1236091834; x=1236955834; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com> |Subject:=20Re=3A=20[Sipping]=20Rollback=20issue=3A=20a=20p roposal |Sender:=20 |To:=20Gonzalo=20Camarillo=20<Gonzalo.Camarillo@ericsson.co m>; bh=1qzUBdL0qh8c8UIvMB0witHKUNW7aY7D3mLUvaNz9ek=; b=LrcifPaSYUDSiRYBuGc3YqtppjG5gyTxewI0Iqn0KjYlxkp2JtSyJSSq/3 37pSj9udoTxN/XFQ72LSPQ9V9ExdLpHyvCgma0GPySQFXqe5Z4EW2ykbN+yu uPqdz6b3vd;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
Cc: sipping <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 14:50:08 -0000

Gonzalo,

Very concise documents!

In terms of best practice I think they are good.

In terms of what to do if one finds oneself in a position where these 
procedures aren't used, I think it is still not entirely clear. Even so, 
I think we might be able to structure guidance around that. I think we 
also must still decide if we need to make a *normative* change here or not.

A key part of the doc is the guideline: don't send an error response to 
the reinvite unless no changes have been made since the reinvite was 
sent. As long as that guidance is followed I think most things are good.

Having the UAS send another o/a when the above wasn't followed seems 
like a good idea. Of course there is a window in there until that o/a is 
completed, and the state during that time (and offered in that offer) 
should still be defined if possible.

	Thanks,
	Paul

Gonzalo Camarillo wrote:
> Hi,
> 
> I have put together the following draft. It contains a proposal for the 
> rollback issue that has been discussed on the list:
> 
> http://www.ietf.org/internet-drafts/draft-camarillo-sipping-reinvite-00.txt
> 
> I have also written another short draft on an issue related to 
> preconditions that was also discussed on the list in one of the 
> rollback-related threads:
> 
> http://www.ietf.org/internet-drafts/draft-camarillo-sipping-precons-00.txt
> 
> Comments are welcome.
> 
> Cheers,
> 
> Gonzalo
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
>