> > > 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 Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
