[sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite

Taisto Qvist <taisto.qvist@ericsson.com> Wed, 10 November 2010 09:31 UTC

Return-Path: <taisto.qvist@ericsson.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 546803A6A89 for <sipcore@core3.amsl.com>; Wed, 10 Nov 2010 01:31:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id IyDXRsNwLXkJ for <sipcore@core3.amsl.com>; Wed, 10 Nov 2010 01:31:36 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net []) by core3.amsl.com (Postfix) with ESMTP id 7D5273A6897 for <sipcore@ietf.org>; Wed, 10 Nov 2010 01:31:30 -0800 (PST)
X-AuditID: c1b4fb39-b7b54ae000003464-0a-4cda668b51ac
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain []) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D6.AD.13412.B866ADC4; Wed, 10 Nov 2010 10:31:56 +0100 (CET)
Received: from ESESSCMS0351.eemea.ericsson.se ([]) by esessmw0256.eemea.ericsson.se ([]) with mapi; Wed, 10 Nov 2010 10:31:55 +0100
From: Taisto Qvist <taisto.qvist@ericsson.com>
To: "sipcore@ietf.org" <sipcore@ietf.org>
Date: Wed, 10 Nov 2010 10:31:54 +0100
Thread-Topic: draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite
Thread-Index: AcuAuhzOVcSGX/UmT9ieOdD0TB0HPg==
Message-ID: <613AADD0FA18314792D9A3F64FE2FB740D35B051A7@ESESSCMS0351.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite
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: Wed, 10 Nov 2010 09:33:45 -0000

Hi folks, 
A while ago I started a discussion concerning how a client should be have when it receives a new contact in the 2xx of an initial INVITE, compared to the early dialog-establishing 183.
My reading of chapter, rfc3261, tells me that a client should NOT update its remote target with the Contact of the 2xx. 
The Contact of the 2xx, should be the same as the 1xx.
I have now read draft-ietf-sipcore-reinvite-06 and I am trying to interpret the results, since even if that document mainly concerns re-invite, chapter 4.9 discusses the early dialog created by an initial request.
The document does not however mention(?) differences in contact:uri between the initial 1xx, and the final 2xx to the INVITE.
The draft mandates that a successfull response, a reliable provisional response, or an in-dialog request to the new target implies a successfull change of contact-uri.
Should I therefore assume that since a 2xx in a normal (initial) invite, is also retransmitted reliably, that a UAC which receives a new contact in the 2xx compared to the contact in a 1xx(wether it has been sent reliably or not), MUST update its remote target?
Since this (seems to) contradict, I would very much appreciate your views.
   If the dialog identifier in the 2xx response matches the dialog
   identifier of an existing dialog, the dialog MUST be transitioned to
   the "confirmed" state, and the route set for the dialog MUST be
   recomputed based on the 2xx response using the procedures of Section  Otherwise, a new dialog in the "confirmed" state MUST be
   constructed using the procedures of Section 12.1.2.

>>    Note that the only piece of state that is recomputed is the route
>>    set.  Other pieces of state such as the highest sequence numbers
      (remote and local) sent within the dialog are not recomputed.  The
      route set only is recomputed for backwards compatibility.  RFC
      2543 did not mandate mirroring of the Record-Route header field in
      a 1xx, only 2xx.  However, we cannot update the entire state of
      the dialog, since mid-dialog requests may have been sent within
      the early dialog, modifying the sequence numbers, for example.

Additionally, I was a bit surprised by the following text, in the above draft.

   Note also that a given UAS can
   establish additional early dialogs, which can have different targets,
   by returning additional unreliable provisional responses with
   different To tags.

Since rfc3261, chapter says:

   A UAS MAY send as many provisional responses as it likes.  Each of these MUST
   indicate the same dialog ID.  However, these will not be delivered reliably.

Which implies to me, that a *single* UAS can not send multiple 1xx with different 

Taisto Qvist