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