Re: Fwd: RFC3261 rules

Hello,

like also commented in the issue references previously in this
discussion, Kamailio is a framework for building SIP systems, it is the
config script that can make it to behave as one needs, being that
stricter or looser from the specs point of view. Kamailio tries not to
(hard-)enforce rules in the C code, but provide the tools/components for
the config writers to implement what suit best their needs.

If one wants to shrink the body, for what ever purposes, including the
mismatch of the body, it can do it, e.g.,:

if(is_present_hf("Content-Length") && $cl < $bs) {
    set_body("$(rb{s.substr,0,$cl)", "$ct");
    msg_apply_changes();
}

Cheers,
Daniel

On 21.06.25 20:28, James Browne via sr-users wrote:
> 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
>>>>     <http://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.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!

-- 
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Kamailio Scalability Training - Online, June 16-19, 2025 -- asipto.com

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