[SR-Users] options_reply() - ruri contains username

[Daniel-Constantin Mierla]

Hello,

when r-uri contains an username, then the OPTIONS should be routed to
that user, so its device can reply. The rule for user devices is to
reply to an OPTIONS like it would be an INVITE, but without starting
actually any call, usefull to discover the capability of the device
(e.g., supported codecs).

Anyhow, if you remove the username ($rU=$null), does it work fine?

Cheers,
Daniel

On 02/03/16 18:20, Alex Balashov wrote:
> Hello,
>
> This may have been discussed before, but when options_reply() from the
> siputils module is used to respond to OPTIONS requests and those
> OPTIONS requests come in with an RURI containing a user part, the
> following error is emitted to the logs:
>
>    LM_ERR("ruri contains username\n");
>
> No reply for the OPTIONS ping is given in this scenario.
>
> OPTIONS pings against a username are very common, and I can find no
> justification for this check in my interpretation of RFC 3261
> scripture. According to Section 11.1 ("Construction of an OPTIONS
> request"):
>
>    An OPTIONS request is constructed using the standard rules for a SIP
>    request as discussed in Section 8.1.1.
>
> Moreover, the example request line given in that very section is:
>
>    OPTIONS sip:carol at chicago.com SIP/2.0
>
> Might it perhaps be agreeable to remove this constraint? Or is there
> some rationale for its presence that I have simply failed to grasp?
>
> Thanks!
>
> -- Alex
>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, March 7-9, 2016 - http://www.asipto.com