Skip to content

Conversation

thorsager
Copy link
Contributor

@thorsager thorsager commented Mar 21, 2024

As stated in "RFC3261 - 20.14 Content-Length" the header must be used to determine message-size when transporting SIP over TCP.

The Content-Length header is utilized to determine the payload size if it is present, otherwise payload size will be determined by the size of the buffer being parsed.

The setTruncated flag will also be set during parsing if the buffer being parsed does not contain enough data, to honor the Content-Length header.

@mosajjal
Copy link
Contributor

it's RFC RFC3261 not RFC3162

@mosajjal
Copy link
Contributor

furthermore, the SIP decoder works regardless of transport layer protocol. but the mandate of content-length is only for TCP not UDP.

@thorsager
Copy link
Contributor Author

furthermore, the SIP decoder works regardless of transport layer protocol. but the mandate of content-length is only for TCP not UDP.

While that is true the RFC also states:

Applications SHOULD use this field to indicate the size of the
message-body to be transferred, regardless of the media type of the
entity.

Could it not then be argued that if the header is there, it should be used?

to determine message-size when transporting SIP over TCP.

The Content-Length header is utilized to determine the payload size
if it is present, otherwise payload size will be determined by the
size of the buffer being parsed.

The setTruncated flag will also be set during parsing if the buffer
being parsed does not contain enough data, to honor the Content-Length
header.
@thorsager thorsager force-pushed the content-length-on-sip branch from 96cadf7 to 7ea3e2d Compare March 23, 2024 10:38
@mosajjal
Copy link
Contributor

mosajjal commented Apr 6, 2024

will this break any TCP SIP that doesn't have the content-length header? at the very least there must be some tests for that scenario. I'm reluctant to merge anything breaking especially when it's a "should" in RFC not a MUST

@thorsager
Copy link
Contributor Author

thorsager commented Apr 6, 2024

will this break any TCP SIP that doesn't have the content-length header? at the very least there must be some tests for that scenario. I'm reluctant to merge anything breaking especially when it's a "should" in RFC not a MUST

That makes total sense, they way it has been implemented, it SHOULD not change current behavior if the header is not there, but I will add tests to ensure this fact.

To ensure backwards compatibility, get .GetContentLength() method will no longer return the actual size of the payload, but ONLY reflect the content of the "Content-Length" header, and returning 0 if the header is not set.

Also updated tests to ensure the above.
@thorsager
Copy link
Contributor Author

will this break any TCP SIP that doesn't have the content-length header? at the very least there must be some tests for that scenario. I'm reluctant to merge anything breaking especially when it's a "should" in RFC not a MUST

On second thought .. the RFC does state that the "Content-Length" header MUST be used when on protocols like TCP

The Content-Length header field indicates the size of the message-
body, in decimal number of octets, sent to the recipient.
Applications SHOULD use this field to indicate the size of the
message-body to be transferred, regardless of the media type of the
entity. If a stream-based protocol (such as TCP) is used as
transport, the header field MUST be used.

But as tests currently does not cover decoding any requests without the "Content-Length" header, I will add this, also I will ensure the behavior of the .GetContentLength() does not change, compared to the current implementation.

This test will show that length of the message body is only limited if the Content-Length header is present.
@thorsager
Copy link
Contributor Author

I added one more test to show that length of the message body is only limited when the Content-Length header is present in the message. I see no reason in pushing the message through IP and UDP/TCP respectively, as the parser acts the same regardless of the transport.

@mosajjal mosajjal self-assigned this Apr 21, 2024
@mosajjal mosajjal merged commit 3c76dea into gopacket:master May 24, 2024
Copy link
Contributor

@mosajjal mosajjal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good now. thanks for your patience. will merge.

@thorsager thorsager deleted the content-length-on-sip branch May 27, 2024 15:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants