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
