Re: Fwd: RFC3261 rules

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.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
> > > [1] 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!


[1] RFC2234 https://datatracker.ietf.org/doc/html/rfc2234

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