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

Hi again, 

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

Personally I never made the the interpretation that the reference 
to 12.2.1.2 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 :-)

Regards
Taisto Qvist

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

inline

>-----Original Message-----
>From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On 
>Behalf Of Paul Kyzivat
>Sent: Wednesday, November 10, 2010 5:17 AM
>To: sipcore@ietf.org
>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.
>

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore