> 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
