You got the question right.
And you got the right answer too. :-)
Thanks,
Paul
Robert Sparks wrote:
> So I've lost track of the question during the musing.
>
> I _think_ the fundamental question being asked is this:
>
> Is an endpoint required to reject (with a 481) an OPTIONS request that
> arrives with at to-tag but does not match any existing dialog state.
> (Assuming some earlier requirement hasn't forced another error code). Or
> is it OK if it just sends
> a 200 OK anyhow.
>
> My take on the collection of specs is that its _not_ ok for it to send
> the 200 OK anyhow and that it is required to send
> the 481. I base this primarily on these sentences from 11.2 in 3261:
>
> The response to an OPTIONS is constructed using the standard rules
> for a SIP response as discussed in Section 8.2.6. The response code
> chosen MUST be the same that would have been chosen had the request
> been an INVITE.
>
> Did I miss the point of the question?
>
> On May 15, 2008, at 12:48 PM, Paul Kyzivat wrote:
>
>> [Including Robert in hopes of getting his insight on this.]
>>
>> I certainly agree that receiving a 481 to an OPTIONS would not imply
>> that there is no INVITE-usage, or any other *particular* usage. It at
>> best would indicate that there is no *dialog*, and hence *no* usages
>> of that dialog can exist. It is far less clear that *not* getting a
>> 481 implies that there *is* a dialog usage. (It may be permissible to
>> allow a dialog to linger after all its usages have disappeared.)
>>
>> But, that still means that if one received a 481 for an OPTIONS, one
>> should be able to conclude that any usages of that dialog you thought
>> were good are in fact gone.
>>
>> However we must first determine if an "in dialog" OPTIONS is to
>> receive a 481 if the dialog doesn't exist, or conversely if it is to
>> be processed as if received outside any dialog.
>>
>> The problem with reading 3261 for answers to this is that it uses
>> "dialog" inconsistently - sometimes to truly mean the dialog and
>> sometimes to mean the dialog usage. RFC 5057 treats this more
>> carefully. It says:
>>
>> According to [1], "an OPTIONS request received within a dialog
>> generates a 200 OK response that is identical to one constructed
>> outside a dialog and does not have any impact on that dialog". Thus,
>> OPTIONS does not belong to any usage. Only those failures discussed
>> in Section 5.1 and Section 5.2 that destroy entire dialogs will have
>> any effect on the usages sharing the dialog with a failed OPTIONS
>> request.
>>
>> That also doesn't directly answer this question. I think it says that
>> if the response to an "in dialog" OPTIONS is one of those that destroy
>> the entire dialog, then that happens. I don't think we can draw any
>> conclusion about the converse from this.
>>
>> Lets see what Robert has to say.
>>
>> Thanks,
>> Paul
>>
>> Brett Tate wrote:
>>>> The ambiguous part has to do with whether an OPTIONS received with a
>>>> dialog id should get a 481 response if the dialog doesn't exist.
>>> Since OPTIONS defined within rfc2543 and rfc3261, many tried to get
>>> OPTIONS approved (so workable if not actually desired) as a poor man's
>>> dialog ping mechanism to obtain 481 if dialog/call no longer exists to
>>> avoid the need of a re-INVITE or methods defined within other RFCs.
>>> Unfortunately AFAIK, nobody was successful in the attempt.
>>> My understanding of rfc3261 and rfc5057 is that an OPTIONS cannot cause
>>> a 481. And if a OPTIONS 481 is returned, the UAC cannot interpret the
>>> 481 to indicate any or all usages of the dialog should be
>>> destroyed/released.
>>> <snip>
>>>> BUT, as application layer logic, I think it would still be ok to
>>>> note that the OPTIONS failed with a 481, then note that the
>>>> application has only an INVITE usage in that dialog, and *decide*
>>>> this would be a good time to send a BYE to the INVITE.
>>> I don't disagree; however AFAIK it is not per rfc3261 and rfc5057. If
>>> the OPTIONS 481 should be sent and received as indication that the
>>> INVITE dialog usage no longer exists, it would have been a nice
>>> mechanism to avoid using re-INVITE.
>>> <snip>
>>>>> RFC 5057 section 5.3: "OPTIONS does not belong to any
>>>> usage. Only those failures discussed in Section 5.1 and Section 5.2
>>>> that destroy entire dialogs will have any effect on the usages
>>>> sharing the dialog with a failed OPTIONS request."
>>>>> Thus if a device decides to return a 481, per rfc 5057 is
>>>> would not tear down any usages. The appropriate response is per
>>>> rfc3261; however some vendors do not exactly follow rfc3261. If
>>>> within the dialog, some vendors return OPTIONS based upon this
>>>> particular call.
>>>>>
>>>>> RFC 3261 section 12.2.2:
>>>>>
>>>>> "Requests that do not change in any way the state of a
>>>> dialog may be received within a dialog (for example, an OPTIONS
>>>> request). They are processed as if they had been received outside
>>>> the dialog."
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
