Subject: [Sip] Remote Target on Established Dialog and Remote Target Refresh

From: "David Roan" <[email-masked]>
Date: Tue, 5 Feb 2008 17:24:22 -0600

Thanks to everyone who responded to my earlier query (Target Refresh Request
and Contact Header thread).

I now have a similar query for establishing the Remote Target. Please
forgive the length in advance and feel free to insert corrections/input as
necessary.

From section 12.1 of RFC 3261, the following is stated:
Within this specification, only 2xx and 101-199 responses with a To tag,
where the request was INVITE, will establish a dialog.

This seems to indicate that either a 2xx or 101-199 response (with a To tag)
to the initial INVITE can establish a dialog (confirmed vs early dialog
respectively), correct?

Then, from section 12.1.1 of RFC 3261, the following is added about the
response that establishes the dialog:
When a UAS responds to a request with a response that establishes a dialog
(such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field
values from the request into the response (including the URIs, URI
parameters, and any Record-Route header field parameters, whether they are
known or unknown to the UAS) and MUST maintain the order of those values.
The UAS MUST add a Contact header field to the response.

This seems to indicate that the first 101-199 response sent from the
UAS/received at the UAC (with a To Tag) must contain a Contact header (to
set the Remote Target at the UAC), correct? So, if the Contact header is not
received in this response, this would be considered a violation of the spec
and an invalid response, correct? Also, according to the following section (
12.1.2), this also sets up the dialog state (items like the route set, if
not empty, and the Remote Target).

Section 12.2 of RFC 3261 goes into additional details of when the Remote
Target can be changed (ie, Remote Target Refresh):
Requests within a dialog MAY contain Record-Route and Contact header
fields.  However, these requests do not cause the dialog's route set to be
modified, although they may modify the remote target URI. Specifically,
requests that are not target refresh requests do not modify the dialog's
remote target URI, and requests that are target refresh requests do.  For
dialogs that have been established with an INVITE, the only target refresh
request defined is re-INVITE (see Section 14).  Other extensions may define
different target refresh requests for dialogs established in other ways.
      Note that an ACK is NOT a target refresh request.
Target refresh requests only update the dialog's remote target URI, and not
the route set formed from the Record-Route.  Updating the latter would
introduce severe backwards compatibility problems with RFC 2543-compliant
systems.

This seems to indicate that after the 101-199 response is received (that
establishes the dialog), only the re-INVITE and its 2xx response and UPDATE
(per RFC 3311) and its 2xx response can change the Remote Target. Therefore,
if a subsequent provisional response to the INVITE (ie, 180 Ringing that
followed a 183 Session Progress) is received, it is not allowed to update
the Remote Target if it contains a Contact header, correct? What about an
UPDATE received in the early dialog state? This would also allow the Remote
Target to be updated, correct?

Thanks again,
David Roan
_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Feb 2008 19:07:20 -0500

David,

I think everything you have said is right. These are some very fuzzy areas.

Note that an *unreliable* provisional response can establish an early 
dialog. But because it is unreliable the UAS can't immediately know if 
the UAC is aware of the dialog.

It is somewhere between very tricky and impossible to change the target 
during an early dialog. If you haven't found it yet, you should take a 
look at the race-examples draft 
(draft-ietf-sipping-race-examples-04.txt) for more discussion of this 
sort of subtle point.

	Thanks,
	Paul

David Roan wrote:
> Thanks to everyone who responded to my earlier query (Target Refresh 
> Request and Contact Header thread).
> 
> forgive the length in advance and feel free to insert corrections/input 
> as necessary.
> 
> This seems to indicate that either a 2xx or 101-199 response (with a To 
> tag) to the initial INVITE can establish a dialog (confirmed vs early 
> dialog respectively), correct?
> 
> When a UAS responds to a request with a response that establishes a 
> dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route 
> header field values from the request into the response (including the 
> URIs, URI parameters, and any Record-Route header field parameters, 
> whether they are known or unknown to the UAS) and MUST maintain the 
> order of those values. The UAS MUST add a Contact header field to the 
> response.
> 
> UAS/received at the UAC (with a To Tag) must contain a Contact header 
> (to set the Remote Target at the UAC), correct? So, if the Contact 
> header is not received in this response, this would be considered a 
> violation of the spec and an invalid response, correct? Also, according 
> to the following section (12.1.2), this also sets up the dialog state 
> (items like the route set, if not empty, and the Remote Target).
> 
> fields.  However, these requests do not cause the dialog's route set to 
> be modified, although they may modify the remote target URI. 
> Specifically, requests that are not target refresh requests do not 
> modify the dialog's remote target URI, and requests that are target 
> refresh requests do.  For dialogs that have been established with an 
> INVITE, the only target refresh request defined is re-INVITE (see 
> Section 14).  Other extensions may define different target refresh 
> requests for dialogs established in other ways.
> Target refresh requests only update the dialog's remote target URI, and 
> not the route set formed from the Record-Route.  Updating the latter 
> would introduce severe backwards compatibility problems with RFC 
> 2543-compliant systems.
> 
> establishes the dialog), only the re-INVITE and its 2xx response and 
> UPDATE (per RFC 3311) and its 2xx response can change the Remote Target. 
> Therefore, if a subsequent provisional response to the INVITE (ie, 180 
> Ringing that followed a 183 Session Progress) is received, it is not 
> allowed to update the Remote Target if it contains a Contact header, 
> correct? What about an UPDATE received in the early dialog state? This 
> would also allow the Remote Target to be updated, correct?
> 
> Thanks again,
> David Roan
> 
> 
> ------------------------------------------------------------------------
>

---

From: "David Roan" <[email-masked]>
Date: Tue, 5 Feb 2008 20:27:01 -0600

Hi Paul,

Thanks for the response.

So, if the provisional responses are sent reliably, the provisional
response would have an acking mechanism similar to the 2xx to ensure the
dialog is established (ie, the chance of lost messaging is greatly
diminished by the resending of Provisional Responses and the PRACK request),
correct?

I checked RFC 3262 wrt this and found the following:
If a provisional response is received for an initial request, and that
response contains a Require header field containing the option tag 100rel,
the response is to be sent reliably.  If the response is a 100 (Trying) (as
opposed to 101 to 199), this option tag MUST be ignored, and the procedures
below MUST NOT be used.
The provisional response MUST establish a dialog if one is not yet created.

This does not really indicate a dialog state, but this would still be an
early dialog, right? Or, would it be confirmed since, like the 2xx, there is
an ACK mechanism to ensure it is received?

Thanks again for the insight and the pointer to the race condition draft,
David Roan

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Tue, 5 Feb 2008 22:16:41 -0500

This will be an early dialog.

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of David Roan
	Sent: Tuesday, February 05, 2008 9:27 PM
	To: Paul Kyzivat (pkyzivat)
	Cc: [email-masked]
	Subject: Re: [Sip] Remote Target on Established Dialog and
Remote TargetRefresh

	Hi Paul,
	 
	Thanks for the response.
	 
	So, if the provisional responses are sent reliably, the
provisional response would have an acking mechanism similar to the 2xx
to ensure the dialog is established (ie, the chance of lost messaging is
greatly diminished by the resending of Provisional Responses and the
PRACK request), correct?
	 
	I checked RFC 3262 wrt this and found the following:
	If a provisional response is received for an initial request,
and that response contains a Require header field containing the option
tag 100rel, the response is to be sent reliably.  If the response is a
100 (Trying) (as opposed to 101 to 199), this option tag MUST be
ignored, and the procedures below MUST NOT be used.
	The provisional response MUST establish a dialog if one is not
yet created.
	 
	This does not really indicate a dialog state, but this would
still be an early dialog, right? Or, would it be confirmed since, like
the 2xx, there is an ACK mechanism to ensure it is received?
	 
	Thanks again for the insight and the pointer to the race
condition draft,
	David Roan

		David,
		
		I think everything you have said is right. These are
some very fuzzy areas.
		
		Note that an *unreliable* provisional response can
establish an early
		dialog. But because it is unreliable the UAS can't
immediately know if
		the UAC is aware of the dialog.
		
		It is somewhere between very tricky and impossible to
change the target
		during an early dialog. If you haven't found it yet, you
should take a
		look at the race-examples draft
		(draft-ietf-sipping-race-examples-04.txt) for more
discussion of this
		sort of subtle point.
		
		       Thanks,
		       Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Feb 2008 12:10:23 -0500

David Roan wrote:
> diminished by the resending of Provisional Responses and the PRACK 
> request), correct?

Right.

3261 is very carefully worded, because it only provides one way of 
establishing a dialog, and doesn't include reliable provisionals, but 
the specs for reliable provisionals were progressed in parallal so 3261 
"left room" for them as well as for other ways of establishing a dialog 
(like SUB/NOT).

> response contains a Require header field containing the option tag 
> 100rel, the response is to be sent reliably.  If the response is a 100 
> (Trying) (as opposed to 101 to 199), this option tag MUST be ignored, 
> and the procedures below MUST NOT be used.
> early dialog, right? Or, would it be confirmed since, like the 2xx, 
> there is an ACK mechanism to ensure it is received?

It is still an early dialog, but its a way of *knowing* you have one.

	Thanks,
	Paul

> On Feb 5, 2008 6:07 PM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     David,
> 
>      > Use [email-masked]
>     <mailto:[email-masked]> for questions on current sip
>      > Use [email-masked] <mailto:[email-masked]> for new
>     developments on the application of sip
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 Feb 2008 18:47:49 +0100

Hi, 

>>response would have an acking mechanism similar to the 2xx to ensure 
>>the dialog is established (ie, the chance of lost messaging is greatly

>3261 is very carefully worded, because it only provides one 
>way of establishing a dialog, and doesn't include reliable 
>provisionals, but the specs for reliable provisionals were 
>progressed in parallal so 3261 "left room" for them as well 
>as for other ways of establishing a dialog (like SUB/NOT).

Even if you don't use PRACK, I guess any other mid-dialog request from
the UAC to the UAS would also "indication" that the early dialog has
been established.

However, that does NOT mean that any SDP previously sent in an
unreliable 18x would be regarded as an offer/answer.

Also, regarding Paul's earlier comment that a target cannot be updated
during the early dialog. It is possible using UPDATE, isn't it (yes, I
agree with possible race condition issues)?

Regards,

Christer

>>If a provisional response is received for an initial 
>>request, and that response contains a Require header field containing
the option tag 
>>This does not really indicate a dialog state, but this would still be 
>>an early dialog, right? Or, would it be confirmed since, like the 2xx,

> > Thanks again for the insight and the pointer to the race condition 
> > draft, David Roan
> > 
> some very fuzzy
> >     areas.
> >      > Within this specification, only 2xx and 101-199 
> responses with a
> >     To tag,
> >      > Section 12.2 of RFC 3261 goes into additional 
> details of when the
> >     Remote
> >      > fields.  However, these requests do not cause the 
> dialog's route
> >     set to
> >      > Target refresh requests only update the dialog's 
> remote target
> >     URI, and
> >      > UPDATE (per RFC 3311) and its 2xx response can 
> change the Remote
> >     Target.
> >      > correct? What about an UPDATE received in the early 
> dialog state?
> >     This
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Feb 2008 13:03:12 -0500

> the UAC to the UAS would also "indication" that the early dialog has

Yes, I think an intelligent UA can infer that receipt of an in-dialog 
request implies that the other end knows of the dialog. I am however 
unaware of any normative language about this. As a result YMMV when 
attempting such usage.

> unreliable 18x would be regarded as an offer/answer.

I'm not certain what you are saying. To paraphrase what I think you 
might mean:

A new offer MUST NOT be sent within an early dialog that has not been 
confirmed with reliable response.

> agree with possible race condition issues)?

The mechanisms are there to refresh the target, but are fraught with 
race conditions to the point that it is unwise to attempt.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 Feb 2008 19:10:42 +0100

Hi, 

>>>>the dialog is established (ie, the chance of lost messaging is 
>>>>greatly diminished by the resending of Provisional Responses and 
>>>>the PRACK request), correct?
>>>Right.
>>>

>>>the specs for reliable provisionals were progressed in parallal so 
>>>3261 "left room" for them as well as for other ways of establishing a

>>>dialog (like SUB/NOT).
>> 
>>Even if you don't use PRACK, I guess any other mid-dialog 
>>request from the UAC to the UAS would also "indication" that the early

>>dialog has been established.
> 
>Yes, I think an intelligent UA can infer that receipt of an 
>in-dialog request implies that the other end knows of the 
>dialog. I am however unaware of any normative language about 
>this. As a result YMMV when attempting such usage.

I am not sure whether we would need any extra text: the 18x creates the
early dialog (as far as the UAC is concerned), and on early dialogs you
can send mid-dialog requests.

Now, whether all implementations out there work that way I don't know :)

>I'm not certain what you are saying. To paraphrase what I 
>think you might mean:
> 
>A new offer MUST NOT be sent within an early dialog that has 
>not been confirmed with reliable response.

Correct.

And, an SDP that was sent unreliably is NOT an answer (or offer) even if
mid-dialog requests has been received from the UAC after that.

Regards,

Christer

>The mechanisms are there to refresh the target, but are 
>fraught with race conditions to the point that it is unwise 
>to attempt.

> >>> If a provisional response is received for an initial request, and 
> >>> that response contains a Require header field containing
> > the option tag
> >>> 100rel, the response is to be sent reliably.  If the 
> response is a 
> >>> 100
> >>> (Trying) (as opposed to 101 to 199), this option tag MUST be 
> >>> This does not really indicate a dialog state, but this 
> would still 
> >>> be an early dialog, right? Or, would it be confirmed 
> since, like the 
> >>> 2xx,
> > 
> condition 
> >>>      > This seems to indicate that either a 2xx or 
> 101-199 response
> >>>     (with a To
> >>>      > Then, from section 12.1.1 of RFC 3261, the 
> following is added
> >>>     about the
> >>>      > violation of the spec and an invalid response, 
> correct? Also,
> >>>     according
> >>>      > Therefore, if a subsequent provisional response to 
> the INVITE
> >>>     (ie, 180
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments on the application of sip
> >>
> > 
>

---

From: [email-masked]
Date: Wed, 6 Feb 2008 13:12:56 -0500

From: "David Roan" <[email-masked]>

   the Remote Target if it contains a Contact header, correct?

Everything you say is correct, as far as I know.  But there is one
treacherous point that many phones do not get right:  If a 1xx is
received, it establishes an early dialog, and sets the remote target.
If a second 1xx is received *with a different to-tag*, it establishes
*another* early dialog, and sets the remote target of that dialog.
Thus, the remote targets in the two 1xx responses are entirely
unconnected.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Feb 2008 14:42:04 -0500

inline.

	Paul

> can send mid-dialog requests.

That works for the UAC. The UAS sent the 1xx and thinks there is an 
early dialog, and the UAC received it and agrees, so it can send a new 
request in-dialog.

The problem is for the UAS. It has *sent* the 1xx with to-tag so it 
thinks there is a dialog, but the UAC may never receive it. Now if the 
UAS sends an in-dialog request, it is a *bit* of a stretch to assume the 
UAC will be prepared to receive and handle it.

This *is* discussed in the race-examples draft. The assumption is that 
the UAC *ought* to make this inference, but there may be no normative 
support for it. The exception is for SUB/NOT, where there is a 
requirement to handle a NOTIFY where no dialog has yet been established. 
This is a very similar case.

> Now, whether all implementations out there work that way I don't know :)

Yes, that *is* the question. And further, whether an implementation that 
*doesn't* act that way can be declared non-compliant.
_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip