I've been doing some testing of MSRP clients, using Kamailio as the MSRP
relay. While testing file transfers, I found that certain files were
getting stuck at a consistent offset, though the offset varied depending
on the file. With TCP traces, I found that Kamailio continues to send
200 responses to the file sender, but stops forwarding the chunks to the
receiver. This seems to continue until the TCP read buffer overflows,
at which point further chunks are forwarded as normal (the previous
chunks are lost).
I suspected it may be due to file content, so after narrowing down the
chunk sizes, I've identified the two-character problem sequence: 0a 2d
(a.k.a. line-feed dash). I can reproduce the issue with a simple,
single-chunk message where the body only contains these two characters.
Is Kamailio getting this confused with the start of the MSRP end-line?
An example message is below, with all the CRs and LFs made explicit:
MSRP wm4qf7sj SEND\r\n
To-Path: msrp://192.168.0.74:2855/s.7692.44.867977799;tcp
msrp://192.168.0.74:2855/s.7693.28.862091983;tcp
msrp://192.168.0.144:2855/7k5myvdmx7;tcp\r\n
From-Path: msrp://192.168.0.124:2855/8ka1fpl1bw;tcp\r\n
Message-ID: 3561360866.5sxkocu6\r\n
Success-Report: yes\r\n
Failure-Report: yes\r\n
Content-Disposition: inline\r\n
Byte-Range: 1-2/2\r\n
Content-Type: text/plain\r\n
\r\n
\n-\r\n
-------wm4qf7sj$\r\n
Regards,
Gavin