Iñaki Baz Castillo wrote:
> El Thursday 15 May 2008 14:42:09 Brett Tate escribió:
>>> 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.
>
> Thanks for pointing to that RFC 5057.
>
> Anyway, AFAIK there are some softsitches (like some Cisco) that use in-dialog
> OPTION to monitorize the status of a dialog.
Now that I look at it, section 5.3 of 5057 may be less than crystal
clear on this point.
If the OPTIONS is sent within a dialog, AFAIK it will indeed monitor
dialog state to the extent that it will fail with a 481 if there is no
dialog matching its from- and to-tags and Call-ID.
However it will not provide any information on the status of any
particular usage within that dialog.
*If* it is known that the dialog only had a single usage (the normal
case) then it provides *some* evidence of the continued existence of
that usage. But it is in general impossible to know there was a single
usage. For instance, a REFER may have been sent within the dialog,
resulting in a refer subscription usage sharing the dialog. Then the
INVITE-usage could have gone away leaving only the refer subscription
within the dialog. An OPTIONS at that time would still conclude that the
dialog existed even though the INVITE did not. This would typically not
be a problem since the INVITE, REFER, and OPTIONS are typically all sent
by the same entity, but that depends upon application design.
(I won't pretend to agree with everything Cisco products do in their sip
usage.)
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
