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@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