Re: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Thu, 14 January 2010 08:33 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78373A688F for <sipcore@core3.amsl.com>; Thu, 14 Jan 2010 00:33:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.063
X-Spam-Level:
X-Spam-Status: No, score=-106.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 3B6KAnqldOdp for <sipcore@core3.amsl.com>; Thu, 14 Jan 2010 00:33:55 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id DA5A93A68F5 for <sipcore@ietf.org>; Thu, 14 Jan 2010 00:33:54 -0800 (PST)
X-AuditID: c1b4fb24-b7bb6ae000001052-f2-4b4ed6ee7817
Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 78.58.04178.EE6DE4B4; Thu, 14 Jan 2010 09:33:50 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 09:33:50 +0100
Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 09:33:50 +0100
Message-ID: <4B4ED6EE.5060101@ericsson.com>
Date: Thu, 14 Jan 2010 10:33:50 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: SIPCORE <sipcore@ietf.org>
References: <4B41EDC9.6050204@cisco.com> <4B4D8E95.9@ericsson.com> <4B4DDC8A.6070701@cisco.com> <4B4DEACD.2030801@ericsson.com>
In-Reply-To: <4B4DEACD.2030801@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Jan 2010 08:33:50.0226 (UTC) FILETIME=[4C0BE720:01CA94F4]
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [sipcore] Question on draft-camarillo-sipcore-reinvite-01.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jan 2010 08:33:57 -0000

Hi,

I have put together a new version of the draft:

http://users.piuha.net/gonzalo/temp/draft-ietf-sipcore-reinvite-pre01a.txt

Let me know if you have some comments before I submit it.

Regarding the decision about when a given change in the session state 
has been executed when preconditions are used, I have added a paragraph 
that summarizes our discussions and the following draft:

http://www.watersprings.org/pub/id/draft-camarillo-sipping-precons-00.txt

Please, read Section 5.

Sections 7 and 15 contain new rules to avoid glare situations and race 
conditions. These rules avoid nasty call flows that were able to get the 
UAs out of synch.

Some time ago, we discussed whether or not unreliable provisional 
responses could refresh the remote target. There are several problems 
with unreliable responses updating remote targets. First, we would need 
to define even more rules to avoid glare situations and race conditions. 
Second, SIP does not provide any ordering for unreliable provisional 
responses. Responses arriving out of order at the UAC could easily get 
both UAs out of synch. Therefore, only reliable responses can refresh 
remote targets, as was specified in RFC 3261 anyway.

We also discussed the applicability of the target refresh rules to 
initial INVITEs. The rules in the draft cover them as well so I do not 
think we need to add anything else to that end.

Thanks,

Gonzalo