Hi, >>>>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). >> >>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 :) >>However, that does NOT mean that any SDP previously sent in an >>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. 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 >>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)? > >The mechanisms are there to refresh the target, but are >fraught with race conditions to the point that it is unwise >to attempt. > > Paul > > > Regards, > > > > Christer > > > > > > > > > > > > > > > >>> 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 > >> > > > _______________________________________________ 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
