Hello,
On 8/22/13 10:07 AM, Alex Balashov wrote:
Hello,
The options_reply() function does not answer OPTIONS pings that contain a username in the request URI. To its credit, the documentation does say that, too:
http://kamailio.org/docs/modules/4.0.x/modules/siputils.html#idp131056
The question is: why not? I do not see anything in RFC 3261 Section 11.1 ("Construction of an OPTIONS Request") that seems to rule out an OPTIONS request with a user part:
http://tools.ietf.org/html/rfc3261#section-11.1
Quite a few UAs out there, including, notably, Metaswitch, do send user parts in the OPTIONS RURI. To deal with them, I am forced to simply
sl_send_reply("200", "OK");
instead of using options_reply().
What is the underlying theory?
I think the reason was that requests with username have to be routed to that username and answered by its device. OPTIONS can be used to discover capabilities and if I want to discover your device capabilities I will send it to alex@balashov.com . The server is identified only by ip:port.
If you want to use the function on server even when there is a username, you can do $rU=$null; before it. Not sure if really makes sense to change the code, but then the condition can be also in config file like if($rU==$null) {options_reply();}
Because OPTIONS for keepalive doesn't really look for capabilities of the other endpoint, I am simply replying with sl_send_reply(), it's more lightweight.
Cheers, Daniel