Hi Nils!
the problem is within sipp. I managed to capture the suspect TCP connection and sipp does send broken SIP messages when the TCP connection gets congested (window=0). I now use TLS as then the socket handling is done in openssl (not in sipp) which is probably more stable than the one in sipp. I guess there should not be much difference between TCP and TLS with NULL encryption (only a single TLS connection).
regards klaus
Nils Ohlmeier wrote:
Hi Klaus,
On Wednesday 26 July 2006 17:31, Klaus Darilion wrote:
Scenario: sipp sends INVITE to ser, ser replies with 404. sipp sends 3000 INVITEs per second with TCP. sipp + ser on the same machine, packets will be snet over loopback device.
Suddenly ser reports a bad message:
Jul 26 16:39:31 t4000 ser[14152]: ERROR:parse_first_line: method not followed by SP
Jul 26 16:39:31 t4000 ser[14152]: ERROR:parse_first_line: bad message
rtpmap:0 PCMU/8000 087637 IN IP4 83.136.32.91sg:
message=<p@83.136.32.91:5066>;tag=6688
two things are coming to my mind:
- the log output looks like their are nor CRLF in the SDP but only CR. Please
check with the hexoutput of ethereal how the lines and in this message, and maybe in the last request before.
- the content length if very important for TCP. If the content length of the
previous request is wrong SER would try read the next request from within the SDP of the previous request (the one with the wrong content length). Could you check the Content-Length is correct in the previous requests?
These are just two ideas. I do not blame any software yet ;-)
Nils
Jul 26 16:39:31 t4000 ser[14152]: ERROR: receive_msg: parse_msg failed
Although the message captured looks fine:
INVITE sip:service@83.136.32.91:5060 SIP/2.0 Via: SIP/2.0/TCP 83.136.32.91:5066;branch=z9hG4bK-6688-0 From: sipp sip:sipp@83.136.32.91:5066;tag=6688 To: sut sip:service@83.136.32.91:5060 Call-ID: 6688-14331@83.136.32.91 CSeq: 1 INVITE Contact: sip:sipp@83.136.32.91:5066 Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: 135
v=0 o=user1 53655765 2353687637 IN IP4 83.136.32.91 s=- c=IN IP4 83.136.32.91 t=0 0 m=audio 6002 RTP/AVP 0 a=rtpmap:0 PCMU/8000
Any hints for the problem debugging?
thanks klaus _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers