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(a)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(a)lists.iptel.org
>
http://lists.iptel.org/mailman/listinfo/serusers