David Roan wrote:
> 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?
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).
> 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?
It is still an early dialog, but its a way of *knowing* you have one.
Thanks,
Paul
> 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]
> <mailto:[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]
> <mailto:[EMAIL PROTECTED]> for questions on current sip
> > Use [EMAIL PROTECTED] <mailto:[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
