Re: Fwd: RFC3261 rules

James Browne via sr-users <[email protected]>
Newsgroups gmane.comp.voip.ser
Message-ID <CAEpCD+pXt-4Ff0ZnGeRW5z72mn5oekhZMhr8a1+APC2eN5UQ_A@mail.gmail.com>
I read your pcap file. I thought it was invalid, but it looks valid to me,
even though it's strange and I've never seen this nonsense in normal SIP
traffic.

RFC3261 Section 18.3
   In the case of message-oriented transports (such as UDP), if the
   message has a Content-Length header field, the message body is
   assumed to contain that many bytes.  If there are additional bytes in
   the transport packet beyond the end of the body, they MUST be
   discarded.

Therefore it looks to me that any server/client should simply ignore
anything after the header when the Content-Length is zero.

I don't see that error "dropping insane message" in kamailio source code,
so I suppose your config file generates that.
The sanity module, which Antonio mentions, would drop this message, so I
guess that's what's happening in your config.
- content length - (128) - checks if the size of the body matches with the
value from the Content-Length header.

James



On Sat, 31 May 2025 at 07:27, Sergey Safarov via sr-users <
[email protected]> 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
> [image: image.png]
>
> I have checked RFC3261 and do not see a definition of "x00" chars.
> Also in the same RFC, present a reference to the RFC2234
> <https://datatracker.ietf.org/doc/html/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 --
> [email protected]
> To unsubscribe send an email to [email protected]
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
>

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the sender!
image.png (image/png, 328.3 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.