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).
>
> 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 sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sipping <at> ietf.org for new developments on the application of sip