Problems with Multiple SIP Packets in a TCP Stream

[pksml85]

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]

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