Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems with Multiple SIP Packets in a TCP Stream #466

Open
pksml85 opened this issue Dec 7, 2023 · 1 comment
Open

Problems with Multiple SIP Packets in a TCP Stream #466

pksml85 opened this issue Dec 7, 2023 · 1 comment

Comments

@pksml85
Copy link

pksml85 commented Dec 7, 2023

I have had the unfortunate realization that Acrobits Groundwire packs multiple SIP messages into one TCP stream. And sngrep isn't able to properly handle the multiple messages. It only deals with the first SIP message. I bring this up because Groundwire is a highly-recommended and used app for VoIP communications.

I'm discovering that some of these streams are upwards of 4 kilobytes. Groundwire is obviously trying to be efficient with multiple messages in the same packet, but it's causing me lots of headaches...

Here is one such example from the raw view in sngrep:

sanitized_multiple_sip_messages.txt

The Problem: In the attached file, I have a SUBSCRIBE request and a REGISTER request arriving in the same packet. Sngrep logs it as a SUBSCRIBE message, but the REGISTER message never gets put into the record for REGISTERs for [email protected]. When I open up the REGISTERs for [email protected], I only see the REGISTER requests made after the request in the attached file.

My Request: Would it be possible to have sngrep check to see if more than one SIP message came in on the packet, and then sort appropriately? I guess I should first ask if this is even proper SIP syntax to send more than one SIP message at a time in the same packet.

Thank you for your consideration!

(Even more info: Actually, Groundwire is stacking more than just two SIP messages into the stream, but the packet gets truncated by the VPN connection, and the partial SIP message that does make it through is not being parsed by sngrep... I see no problem with sngrep's not parsing a partial SIP message.)

@Kaian
Copy link
Member

Kaian commented Dec 11, 2023

Hi!

The TODO list contains two entries related to this for a long time ago. TCP reassembly is a total mess and I tried to improve it in the glib-2 branch if you want to try to compile it (using CMake) and check if something improves.

sngrep/TODO

Lines 4 to 17 in a863151

capture:
* Improve TCP assembly
We assume a packet is complete when PSH flag is set. In some cases
this is not true and we have multiples SIP messages into what we
consider an assembled packet. It's require to evaluate if a packet
contains a SIP message every time we assemble a new segment.
* Improve long run performance
Right now, sngrep stores a lot of information in memory making it quite
dangerous in long runs. We implemented a dialog limit to avoid being
afraid of leaving an unattended sngrep, but it ended being also used
by internal structures as a max size reference. While the limit is still
a good idea, it will be nice to decouple it from the internals, allowing
even unlimited captures if specified by the user at own risk.

Best Regards

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants