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