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
Hello,
can you try with the patch from this commit?
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=b255c406...
Cheers, Daniel
On 11/8/12 12:09 PM, Gavin Llewellyn wrote:
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi,
Gavin is on holiday today and Monday morning. I will rebuild and update our test system so he can test it Monday afternoon.
Thanks,
Peter
On Fri, 2012-11-09 at 11:09 +0100, Daniel-Constantin Mierla wrote:
Hello,
can you try with the patch from this commit?
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=b255c406...
Cheers, Daniel
On 11/8/12 12:09 PM, Gavin Llewellyn wrote:
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Daniel,
Sorry for my slow response - that patch fixes the issue, thank you.
Regards, Gavin
On 09/11/2012 10:09, Daniel-Constantin Mierla wrote:
Hello,
can you try with the patch from this commit?
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=b255c406...
Cheers, Daniel
On 11/8/12 12:09 PM, Gavin Llewellyn wrote:
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Daniel-Constantin Mierla -
Gavin Llewellyn -
Peter Dunkley