Christer Holmberg wrote:
> 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.
> 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.
> 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
