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

From: Taisto Qvist <[email-masked]>
Date: Wed, 10 Nov 2010 10:31:54 +0100

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

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 13.3.1.1 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 
tags?

Regards
Taisto Qvist

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Nov 2010 18:17:15 +0800

> 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 early dialog, modifying the sequence numbers, for example.

Note that the route-set doesn't include the contact. Maybe that was your 
point.

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

Perhaps this is a matter of terminology.
If you prefer, consider the same box to contain multiple UAs, each of 
which received a forked copy of the request. Then each returns a single 
response with a unique to-tag.

There are a number of cases where this is a viable strategy for handling 
various problems.

	Thanks,
	Paul

> Regards
> Taisto Qvist
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Bob Penfield <[email-masked]>
Date: Wed, 10 Nov 2010 09:04:00 -0500

inline

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
>Sent: Wednesday, November 10, 2010 5:17 AM
>To: [email-masked]
>Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite
>
>
>> 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.
>> 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?
>>

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.

---

From: Taisto Qvist <[email-masked]>
Date: Thu, 11 Nov 2010 10:05:39 +0100

Minor comments below

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: den 10 november 2010 11:17
To: [email-masked]
Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite

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 early dialog, modifying the sequence numbers, for example.

Note that the route-set doesn't include the contact. Maybe that was your point.
[TQ] Yepp :-)

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

Perhaps this is a matter of terminology.
If you prefer, consider the same box to contain multiple UAs, each of which received a forked copy of the request. Then each returns a single response with a unique to-tag.
There are a number of cases where this is a viable strategy for handling various problems.

[TQ]
It most certainly is. But when I read that paragraph it doesnt indicate a generic endpoint which consists of multiple UAS:es that received several forked requests.
Too me, it claims that a single UAS, that has received a *single* request, can respond to that single transaction, with multiple provisional responses, creating 
multiple early dialogs by using different tags. That seems to completely contradict rfc3261. 

But maybe I'm just beeing a bit to literal, although for interoperability reasons, I think that maybe we should be :-)

/Taisto

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Nov 2010 22:41:58 +0800

> But maybe I'm just beeing a bit to literal, although for interoperability reasons, I think that maybe we should be :-)

The way to think of this (its a conceptual model, not a real one) is 
that the UA may choose to virtually fork the request to several of its 
evil twins. Then each one of those can independently handle the request, 
with its own to-tag.

The fact that the forking happened without any message passing is 
irrelevant to the UAC - it all looks to the same as if the forking 
really happened.

	Thanks,
	Paul

---

From: Taisto Qvist <[email-masked]>
Date: Thu, 18 Nov 2010 15:50:32 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Penfield
Sent: den 10 november 2010 15:04
To: Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite

inline

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