Brett,
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.
I've always thought that dialog matching stuff was a "lower layer"
function before doing method-specific behavior, so that it would get the
481, and only if there was a matching dialog would it then be processed
an OPTIONS message, which can then be processed without regard that it
came within a dialog.
If that is appropriate logic, than it indeed can be used to determine
the existence of the dialog. But then failure due to 481 or anything
else shouldn't cause the sender to tear down any dialog state it might have.
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.
Paul
Brett Tate wrote:
>>>> Also in-dialog OPTIONS is used to verify the state
>>>> of an existing dialog since the UAS is supposed to
>>>> answer "200 OK" in case a dialog with that "To" tag exists.
>>> OPTIONS within a dialog is not a typical request within
>>> dialog. It cannot be used to check dialog state.
>>> RFC 5057 section 5.3 discusses the topic and quotes RFC 3261.
>> Are you sure?
>
> Yes.
>
> <snip>
>
>> The above doesn't explain if a UAS should reply a 404 or 481
>> or 200 if it receives an in-dialog OPTIONS for a non existing
>> dialog, so I'm not sure at all about it...
>
> 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
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
