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
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev