[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
