> > The following is a link to one of the threads: > > > > http://www.ietf.org/mail-archive/web/sipcore/current/msg02020.html > > Thanks, but that thread doesn't handle the case in which > an in-dialog OPTIONS fails due to timeout (no response).
I agree; however it reflects some of the ambiguities related to using OPTIONS to determine/know actual state of the dialog. > > Concerning in-dialog usage of OPTIONS, timeouts, 408, 481, and > etcetera, RFC 5057 attempts to clarify things. > > I already read the RFC 5057, it ratifies what 3261 12.2.1.2 says: > > ---------------------- > 5.2. Transaction Timeouts > > [1] states that a UAC should terminate a dialog (by sending a BYE) > if > no response is received for a request sent within a dialog. > ---------------------- > > But includes some cases in which the UA should consider the dialog > unaffected even if an in-dialog request failed. Yes; and OPTIONS has no "usage". Thus very few responses to OPTIONS would impact dialog; OPTIONS timeout should not impact dialog. RFC 5057 section 5.2 indicates that OPTIONS timeout "will have no effect on the dialog or its usages." "Generally, a transaction timeout should affect only the usage in which the transaction occurred. Other uses sharing the dialog should not be affected. In the worst case of timeout due to total transport failure, it may require multiple failed messages to remove all usages from a dialog (at least one per usage). There are some mid-dialog messages that never belong to any usage. If they timeout, they will have no effect on the dialog or its usages." > But in any case, no specification states that, upon an in-dialog > OPTIONS timeout, the UA should terminate the RTP without sending > a BYE. Am I right? Correct. However if I recall correctly, rfc3261 often only indicates SHOULD send BYE instead of MUST send BYE when the UAC notices a potential issue with dialog; your rfc5057 snippet using "should terminate" re-enforces my recollection. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
