Karl Brose wrote:
If the response to an OPTIONS is generated by a proxy server, the proxy returns a 200 (OK), listing the capabilities of the server. The response does not contain a message body.
Allow, Accept, Accept-Encoding, Accept-Language, and Supported header fields SHOULD be present in a 200 (OK) response to an OPTIONS request. If the response is generated by a proxy, the Allow header field SHOULD be omitted as it is ambiguous since a proxy is method agnostic. Contact header fields MAY be present in a 200 (OK) response and have the same semantics as in a 3xx response. That is, they may list a set of alternative names and methods of reaching the user. A Warning header field MAY be present.
This is what asterisk is doing, or?
Please explain where and how you think Asterisk is not following the RFC, and I'll look into it.
The other alternative would be to act as a UAS, but that may be confusing. Is any phone using this for checking if an URL is busy or not? In dialogue or out of dialogue?
Just want to know if there's anything out there to test with.
Thank you for looking this up. /O _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
