4 Mar
2016
4 Mar
'16
10:28 a.m.
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
--
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