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 a...@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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
