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:ca...@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

--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States

Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

_______________________________________________
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

Reply via email to