[SR-Users] TCP: Strange Device Behaviour

[Carsten Bock]

Hi,

I have a device here, which does some sort of strange things:

I have SIP Message, e.g. with a length of 1100 Bytes and the devices adds
"0" to the end to meet the MTU of the network (for a single TCP frame),
some sort of TCP padding. The following TCP Frame contains only the next
message. Looking at the trace in Wireshark, sngrep or similar, all of them
try to re-assemble the next message in the TCP stream, but however don't
decode them as SIP due to to first couple of zero's in the message.

Looking at Kamailio, it seems not to have any issues with this and
decodes/parses the message properly (they show up on Homer properly);
however it also forwards the message INCLUDING the first couple of zero's
even on UDP.

To make it complitely irritating, the phone itself would ignore such
packets, if we would forward them to the phone with starting zeros.

Has anyone seen anything like this and is it standards-compliant? Any
proper and easy way to get rid of the starting "zero's" from a message
before forwarding these messages? I could always "hack" something into
src/core/tcp_read.c, but I wonder if there is already a proper way?

Any ideas anyone?

Thanks,
Carsten

--
Carsten Bock I Managing Director
ng-voice GmbH

Millerntorplatz 1 I 20359 Hamburg I Germany
www.ng-voice.com

Mobile +49 (0)179-20 21 244 I Direct +49 (0)40-52 47 593-40 I Fax +49
(0)40-52 47 593-99

Sitz der Gesellschaft: Hamburg
Registergericht: Amtsgericht Hamburg, HRB 120189
Geschäftsführer: Carsten Bock, Dr. David Bachmann
Ust-ID: DE279344284

Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
http://www.ng-voice.com/imprint/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190823/62574ed9/attachment.html>