Hi Robert, Thanks for the response.
Within the archives, I found http://bugs.sipit.net/show_bug.cgi?id=400 which discusses OPTIONS within dialog. Unfortunately I haven't found much concerning the topic within the old email archives. Thus I'm not positive if all the objections to returning 481 were before or after bug 400 was resolved. The following was the only one I noticed after a quick search: http://www.ietf.org/mail-archive/web/sip/current/msg06338.html. It supports my interpretation. Concerning RFC 5057 section 5.3, OPTIONS 481 is not a response that impacts other usages of the dialog. 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." Concerning RFC 3261 section 12.2.2, it appears to me that the presence of To-tag would be ignored; thus a 481 would never be sent. RFC 3261 section 12.2.2: "If the UAS wishes to reject the request because it does not wish to recreate the dialog, it MUST respond to the request with a 481(Call/Transaction Does Not Exist) status code and pass that to the server transaction. 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." <snip> > My take on the collection of specs is that its _not_ ok for > it to send the 200 OK anyhow and that it is required to send > the 481. I base this primarily on these sentences from 11.2 in 3261: > > The response to an OPTIONS is constructed using > the standard rules for a SIP response as discussed > in Section 8.2.6. The response code chosen MUST be > the same that would have been chosen had the request > been an INVITE. > > Did I miss the point of the question? Just trying to understand what rfc3261 and rfc5057 indicate or tried to indicate concerning 1) if OPTIONS 481 should ever be sent, and 2) the related impacts upon the dialog usages if OPTIONS 481 is received, 3) OPTIONS' ability to temporality revive/recreate the dialog per UAS' desire to return 200. If OPTIONS 481 really MUST be sent and SHOULD trigger subsequent requests/responses to terminate the dialog, I'm sure some would like to use it within early dialogs, subscriptions, and elsewhere. We should likely move this thread to the sip list. Cheers, Brett _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
