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
Hi Inside Sanity module there is a Function sanity_reply() which should send a reply with a reason why sanity failed
May be useful as well
*Antony* satskiy.a@gmail.com
сб, 31 трав. 2025 р. о 09:50 Sergey Safarov via sr-users < sr-users@lists.kamailio.org> пише:
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 -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
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 < sr-users@lists.kamailio.org> 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 -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
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 < sr-users@lists.kamailio.org> 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 < sr-users@lists.kamailio.org> 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 -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
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 sr-users@lists.kamailio.org 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 sr-users@lists.kamailio.org 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 -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
[1] RFC2234 https://datatracker.ietf.org/doc/html/rfc2234
It's not an issue. https://kamailio.org/docs/modules/5.8.x/modules/sanity.html#sanity.p.default... "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, < sr-users@lists.kamailio.org> 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 < sr-users@lists.kamailio.org> 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 < sr-users@lists.kamailio.org> 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 -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
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... "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, sr-users@lists.kamailio.org 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 <sr-users@lists.kamailio.org> 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 <sr-users@lists.kamailio.org> 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 -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
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... "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, sr-users@lists.kamailio.org 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 <sr-users@lists.kamailio.org> 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 <sr-users@lists.kamailio.org> 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 -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org 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
In my understanding, RFC-defined behaviour should be used by default. Without a special config prepared.
Please check issue with double "To" headers. https://kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio.org/th...
Second "To" header also can be stripped at the Kamailio config. Here is kamailio config example https://github.com/2600hz/kazoo-configs-kamailio/blob/master/kamailio/sanity... Security advisory https://nvd.nist.gov/vuln/detail/CVE-2018-14767
Why this need to "hardcoded" in the C code and we do not force Kamailio admin to use config workarround? Why "To" header RFC-defined behaviour need to hardcored in the C code, but for message body is not?
Sergey
On Sun, 2025-06-22 at 09:16 +0200, 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"); 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...
"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, sr-users@lists.kamailio.org 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 sr-users@lists.kamailio.org 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 sr-users@lists.kamailio.org 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 -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org
To unsubscribe send an email to sr-users-leave@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
[1] RFC2234 https://datatracker.ietf.org/doc/html/rfc2234
On 22.06.25 12:57, Sergei Safarov wrote:
In my understanding, RFC-defined behaviour should be used by default. Without a special config prepared.
You actually go into extremes here ... so, "without a special config prepared", you have:
route {
}
You want to say that with such config, Kamailio has to do what? Stateless or stateful forwarding? With or without authentication? With or without record routing? With or without accounting? With or without NAT traversal? And so on ...
If you wish, you can write c code for a new module that you can call "autopilot" that does exactly what you want with an empty config (so you don't need a special config prepared) if that feels the right way that you want, contributions are welcome as always.
Please check issue with double "To" headers. https://kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio.org/th...
Second "To" header also can be stripped at the Kamailio config. Here is kamailio config example https://github.com/2600hz/kazoo-configs-kamailio/blob/master/kamailio/sanity... Security advisory https://nvd.nist.gov/vuln/detail/CVE-2018-14767
Why this need to "hardcoded" in the C code and we do not force Kamailio admin to use config workarround?
It was no way to strip the 2nd To header at that moment from config, either remove all or none. The workaround was to drop such message with the options available back then, not to strip the header.
And if you would have taken the time to properly understand what kind of that problem was, instead or trying to compare apples with oranges, probably you would have noticed it was a crash in the c code. Later I added header iterators that give more flexible access to the list of headers.
Why "To" header RFC-defined behaviour need to hardcored in the C code, but for message body is not?
It was not the RFC that had needed to be hardcoded, but a fix for a crash because of a bug in the C code.
Then the message body is not the main business of the proxy, it is the end point that has to understand and process it. The Kamailio philosophy is to be implicitly as less intrusive as possible, and let the config writer to do the hard-enforcing rules. Because you may want to build a highly scalable load balancer that does not care if some (any or all) headers or body are ok, but it has to dispatch huge volume of SIP traffic at highest rate possible, so the next-hop cluster of SIP servers can get the partitioned traffic for processing.
That's why it has an incremental (lazy) parser, not a deep-down one, and probably one likes better a SIP LB that routes many thousands of call setups per second in an admin-defined policies config, than a C-hardcoded one with all policies that one would thinks about from specs point of view at the rate of a few tens of call setups per second, with any change requiring to edit c code, recompile and reinstall.
Remember that msg_apply_chages() came quite late in the lifetime of the project. A SIP proxy was meant for routing policies, add/remove headers (Via, Record-/Route, ...).
We can loop and spiral in this discussion endless, but that's not going to change Kamailio's design/philosophy in handling SIP traffic. It is what made SER/Kamailio popular and maintained for about a quarter of a century right now: fixing broken SIP traffic as the admin wanted, not strictly as the specs required. If it is not a crash, it is the admin that decides what can be fixed and how.
Of course, if you don't like what can be done with a couple of config actions right now, you can add a new function to incorporate them behind. I did it many times, mainly to simplify the config for the common use cases (e.g., the rtpproxy/rtpengine manage instead of the offer/answer/destroy options, or auth_check instead of the www-/proxy_authorize() for REGISTER/other-methods, and probably the list can continue...).
Daniel
Sergey
On Sun, 2025-06-22 at 09:16 +0200, 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"); 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... "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, sr-users@lists.kamailio.org 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 sr-users@lists.kamailio.org 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 sr-users@lists.kamailio.org 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 -- > sr-users@lists.kamailio.org > To unsubscribe send an email to sr-users-leave@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply > only to the sender! __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Hello Sergey,
I ran into a similar issue, with both SIP requests and SIP replies. In the end I narrow it down to a particular check that doesn't produce an error log: content length - (128) That particular check is comparing UDP and SIP length against the value of the Content- Length header. Here's the patch that will outline the issue.
diff --git a/src/modules/sanity/sanity.c b/src/modules/sanity/sanity.c index 81f2b1b9bf..2f417d2822 100644 --- a/src/modules/sanity/sanity.c +++ b/src/modules/sanity/sanity.c @@ -619,7 +619,7 @@ int check_cl(sip_msg_t *msg) if(sanity_reply(msg, 400, "Content-Length mis-match") < 0) { LM_WARN("failed to send 400 via sl reply\n"); } - LM_DBG("check_cl failed\n"); + LM_WARN("check_cl failed: [%i - %ld] != [%ld]\n", msg->len, body - msg->buf, get_content_length(msg)); return SANITY_CHECK_FAILED; } LM_DBG("check_cl passed\n");
Hope this helps, Ovidiu
On Sat, May 31, 2025 at 3:38 AM Sergey Safarov via sr-users sr-users@lists.kamailio.org 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
I have checked RFC3261 and do not see a definition of "x00" chars. Also in the same RFC, present a reference to the 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 -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
-
Antonio -
Aymeric Moizard -
Daniel-Constantin Mierla -
James Browne -
Ovidiu Sas -
Sergei Safarov -
Sergey Safarov