Hello Sergey,
I ran into a similar issue, with both SIP requests and SIP replies. In the end I narrow it down to a particular check that doesn't produce an error log: content length - (128) That particular check is comparing UDP and SIP length against the value of the Content- Length header. Here's the patch that will outline the issue.
diff --git a/src/modules/sanity/sanity.c b/src/modules/sanity/sanity.c index 81f2b1b9bf..2f417d2822 100644 --- a/src/modules/sanity/sanity.c +++ b/src/modules/sanity/sanity.c @@ -619,7 +619,7 @@ int check_cl(sip_msg_t *msg) if(sanity_reply(msg, 400, "Content-Length mis-match") < 0) { LM_WARN("failed to send 400 via sl reply\n"); } - LM_DBG("check_cl failed\n"); + LM_WARN("check_cl failed: [%i - %ld] != [%ld]\n", msg->len, body - msg->buf, get_content_length(msg)); return SANITY_CHECK_FAILED; } LM_DBG("check_cl passed\n");
Hope this helps, Ovidiu
On Sat, May 31, 2025 at 3:38 AM Sergey Safarov via sr-users sr-users@lists.kamailio.org wrote:
Could you look at the attached PCAP with OPTIONS message. When OPTIONS message is received, then Kamailio generates error logs like
dropping insane message from 10.140.6.38:60083
After checking the PCAP, I see extra %x00 characters after the OPTIONS message in the same UDP frame. Example
I have checked RFC3261 and do not see a definition of "x00" chars. Also in the same RFC, present a reference to the RFC2234 where is described "space chars", "white space". According to RFC2223, char %x00 cannot be treated as "space" and should be treated as control (CTL) char. Also, RFC3261 does not use "CTL" chars.
Using these two RFC, I can conclude, OPTIONS in the attached PCAP breaks RFC requirements, and we can request partner fix this issue on their equipment.
Is anything else in the RFC can be used to justify that the given examples of OPTIONS messages violate RFCs?
Sergey
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!