Re: Fwd: RFC3261 rules

On 22.06.25 09:16, Daniel-Constantin Mierla wrote:
>
> 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");
>
$cT has to be instead of $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
>>>>>
>>>>>
>>>>>     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

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