Re: Fwd: RFC3261 rules

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!