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

[Bob Penfield <[e-mail]>]

inline

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of Paul Kyzivat
>Sent: Wednesday, November 10, 2010 5:17 AM
>To: [e-mail]
>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 13.2.2.4, 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 13.2.2.4, 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 12.2.1.2 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
>>     12.2.1.2.  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.
>