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

Taisto Qvist <> Thu, 18 November 2010 14:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BAD603A6836 for <>; Thu, 18 Nov 2010 06:49:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uyRkDhgSnYHM for <>; Thu, 18 Nov 2010 06:49:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5BA793A6818 for <>; Thu, 18 Nov 2010 06:49:46 -0800 (PST)
X-AuditID: c1b4fb39-b7cabae000005002-0b-4ce53d395b2f
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 8D.20.20482.93D35EC4; Thu, 18 Nov 2010 15:50:33 +0100 (CET)
Received: from ([]) by ([]) with mapi; Thu, 18 Nov 2010 15:50:33 +0100
From: Taisto Qvist <>
To: Bob Penfield <>, Paul Kyzivat <>, "" <>
Date: Thu, 18 Nov 2010 15:50:32 +0100
Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite
Thread-Index: AcuAwH6ei6Kd+huyQ8W42wxgtQfNWQAHkcFwAZPnBlA=
Message-ID: <>
References: <> <> <429446390BA91242867940DBE798A06B8B929076DD@mail>
In-Reply-To: <429446390BA91242867940DBE798A06B8B929076DD@mail>
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: 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: Thu, 18 Nov 2010 14:49:47 -0000

Hi again, 

I would really like to get more peoples opinion of this. 

Personally I never made the the interpretation that the reference 
to was valid in this case. That text explicitly says:

   When a UAC receives a 2xx response to a target refresh request, it
   MUST replace the dialog's remote target URI with the URI from the
   Contact header field in that response, if present.

..and since I didnt see this 2xx, for an initial invite, as a target 
refresh request.

I fine either way, I just think its a bit confusing and want to
clear the mist a bit, since I've had problems with this.

Having it clarified in "black and white" in an RFC wouldnt be all 
bad either :-)

Taisto Qvist

-----Original Message-----
From: [] On Behalf Of Bob Penfield
Sent: den 10 november 2010 15:04
To: Paul Kyzivat;
Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite


>-----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.

sipcore mailing list