Re: Fwd: RFC3261 rules

It's not an issue.
https://kamailio.org/docs/modules/5.8.x/modules/sanity.html#sanity.p.default_checks
"By default all implemented checks are included in the execution of the
sanity_check function."

By running it with no argument, you're asking kamailio to do exactly what
it then does: reject the request.
My previous reply also suggested this: if value 128 is included (which is
included by default), then the Content-Length will be checked.
I'll put a note in the issue, too.

James


On Sat 21 Jun 2025, 09:42 Sergei Safarov via sr-users, <
[email protected]> wrote:

> Thanks for good reference to RFC
>
> I have described issue at
> https://github.com/kamailio/kamailio/issues/4290
>
>
> On Fri, 2025-06-13 at 09:51 +0200, Aymeric Moizard via sr-users wrote:
>
> Hi Sergey,
>
> The extra chars are acceptable for UDP, as James reported.
>
> Several things:
>
> 1/ the port reported in logs 60083 is not the same as your OPTIONS (just
> worth to say: is your error for another message? I guess not...)
>
> 2/ Your OPTIONS contains a Tag in From, but it doesn't contain a "branch"
> in the Via header: so your OPTIONS looks to be a mix of
> old rfc2543 and not compliant to rfc3261.
>
> The Via header should contain a branch and it should start with the magic
> cookie: "z9hG4bK", such as:
>
> Via: SIP/2.0/UDP 192.168.1.1:51253;branch=z9hG4bKyjoyW1QOas
>
> Looking at sanity code, it doesn't look to be the reason for failure...
>
> Aymeric
>
> Antisip - http://www.antisip.com
>
> Le jeu. 12 juin 2025, 22:38, James Browne via sr-users <
> [email protected]> a écrit :
>
> 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!
>
> __________________________________________________________
> 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!
>

__________________________________________________________
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!