This will be an early dialog.
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of David Roan
Sent: Tuesday, February 05, 2008 9:27 PM
To: Paul Kyzivat (pkyzivat)
Cc: [email protected]
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
On Feb 5, 2008 6:07 PM, Paul Kyzivat <[EMAIL PROTECTED]> wrote:
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 [EMAIL PROTECTED] for questions on
current sip
> Use [EMAIL PROTECTED] for new developments on the
application of sip
_______________________________________________
Sip mailing list http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
