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?
Thanks,
-- Alex
22 aug 2013 kl. 10:07 skrev Alex Balashov abalashov@evaristesys.com:
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?
Guessing that a URI with a user name should be forwarded to that address. URIs pointing to the domain of the server should be responded by the server.
/O
On 08/22/2013 04:25 AM, Olle E. Johansson wrote:
Guessing that a URI with a user name should be forwarded to that address. URIs pointing to the domain of the server should be responded by the server.
Yes, but shouldn't sip:user@proxy_ip and sip:proxy_ip both be serviced by the server?
22 aug 2013 kl. 10:27 skrev Alex Balashov abalashov@evaristesys.com:
On 08/22/2013 04:25 AM, Olle E. Johansson wrote:
Guessing that a URI with a user name should be forwarded to that address. URIs pointing to the domain of the server should be responded by the server.
Yes, but shouldn't sip:user@proxy_ip and sip:proxy_ip both be serviced by the server?
If it's to an IP address I would answer 404 Not Found to both, SIP is domain based :-)
user@ip is propably a 404, but yes, if a UA use this for keepalive we should propably answer - but in that case you don't really need a full options answer, just any 200 Ok will do. Or?
/O
On 08/22/2013 04:34 AM, Olle E. Johansson wrote:
22 aug 2013 kl. 10:27 skrev Alex Balashov abalashov@evaristesys.com:
On 08/22/2013 04:25 AM, Olle E. Johansson wrote:
Guessing that a URI with a user name should be forwarded to that address. URIs pointing to the domain of the server should be responded by the server.
Yes, but shouldn't sip:user@proxy_ip and sip:proxy_ip both be serviced by the server?
If it's to an IP address I would answer 404 Not Found to both, SIP is domain based :-)
user@ip is propably a 404, but yes, if a UA use this for keepalive we should propably answer - but in that case you don't really need a full options answer, just any 200 Ok will do. Or?
Sure, which is why the stateless 200 OK solution works.
But it seems to me that options_reply() ought to answer with a 404 Not Found; it's what other UASs (like Asterisk) do...
22 aug 2013 kl. 10:37 skrev Alex Balashov abalashov@evaristesys.com:
On 08/22/2013 04:34 AM, Olle E. Johansson wrote:
22 aug 2013 kl. 10:27 skrev Alex Balashov abalashov@evaristesys.com:
On 08/22/2013 04:25 AM, Olle E. Johansson wrote:
Guessing that a URI with a user name should be forwarded to that address. URIs pointing to the domain of the server should be responded by the server.
Yes, but shouldn't sip:user@proxy_ip and sip:proxy_ip both be serviced by the server?
If it's to an IP address I would answer 404 Not Found to both, SIP is domain based :-)
user@ip is propably a 404, but yes, if a UA use this for keepalive we should propably answer - but in that case you don't really need a full options answer, just any 200 Ok will do. Or?
Sure, which is why the stateless 200 OK solution works.
But it seems to me that options_reply() ought to answer with a 404 Not Found; it's what other UASs (like Asterisk) do...
The Asterisk answer depends on your dialplan :-)
/O
On 08/22/2013 04:38 AM, Olle E. Johansson wrote:
The Asterisk answer depends on your dialplan :-)
Well, true, true. If there's a matching route, it'll answer affirmatively.
Alex Balashov writes:
But it seems to me that options_reply() ought to answer with a 404 Not Found; it's what other UASs (like Asterisk) do...
your sip proxy should check if the request is for itself or for a local user. if for local user, forward. if for itself and the request is options, call options_reply on it. if neither, reply with 404.
-- juha
Alex Balashov writes:
Yes, but shouldn't sip:user@proxy_ip and sip:proxy_ip both be serviced by the server?
if sip proxy is serving 'user' then usually it forwards any request to contact of that user. of course your policy may differ, i.e., you may require that host part is domain name, but in that case sip proxy should reject the request.
-- juha
On 08/22/2013 04:34 AM, Juha Heinanen wrote:
Alex Balashov writes:
Yes, but shouldn't sip:user@proxy_ip and sip:proxy_ip both be serviced by the server?
if sip proxy is serving 'user' then usually it forwards any request to contact of that user. of course your policy may differ, i.e., you may require that host part is domain name, but in that case sip proxy should reject the request.
Sure, and I have no problem with a rejection. I just need some kind of response.
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
-
Alex Balashov -
Daniel-Constantin Mierla -
Juha Heinanen -
Olle E. Johansson