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

Bob Penfield <> Wed, 10 November 2010 14:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 218873A6965 for <>; Wed, 10 Nov 2010 06:03:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ox8dtu2iEfJ2 for <>; Wed, 10 Nov 2010 06:03:38 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2514F3A6851 for <>; Wed, 10 Nov 2010 06:03:37 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 10 Nov 2010 09:04:01 -0500
Received: from ([]) by mail ([]) with mapi; Wed, 10 Nov 2010 09:04:01 -0500
From: Bob Penfield <>
To: Paul Kyzivat <>, "" <>
Date: Wed, 10 Nov 2010 09:04:00 -0500
Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite
Thread-Index: AcuAwH6ei6Kd+huyQ8W42wxgtQfNWQAHkcFw
Message-ID: <429446390BA91242867940DBE798A06B8B929076DD@mail>
References: <> <>
In-Reply-To: <>
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
Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Nov 2010 14:03:39 -0000


>-----Original Message-----
>From: [] On Behalf Of Paul Kyzivat
>Sent: Wednesday, November 10, 2010 5:17 AM
>Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite
>On 11/10/2010 5:31 PM, Taisto Qvist wrote:
>> 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.
>I'm interested to hear Gonzalo's take on this.
>IMO the most reasonable thing to do in this circumstance is to honor the 
>new contact in the 2xx. This is probably contrary to 3261. Whether it is 
>supported by ...sipcore-reinvite... may be debatable.

The text below indicates that procedures in should be used when 
the 2xx matches an existing early dialog. These are the same procedures for
a target refresh requests. That section has no procedures for constructing 
the route set, but does indicate that the remote target is updated. I have
always used the Contact from the 2xx final response as the remote target of
the confirmed dialog.

>>     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.
> Note that the route-set doesn't include the contact. Maybe that was your 
> point.