Weiter Leiter wrote:

Not that I'd have any hint, but with debug compiling, ser prints the

what means debug compiling?

received tcp message. I would try to run ser in debugging with remote logging. If the problem still occurs (with the extra debugging overhead), you might have a chance to see what ser sees and break the problems.

is ser able to log 3000 requests/second or logs it only the failed message?

regards klaus

WL.

I feel this is more appropriate for serdev.

On 7/26/06, *Klaus Darilion* <klaus.mailinglists@pernau.at mailto:klaus.mailinglists@pernau.at> wrote:

Hi!

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

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
<http://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 <mailto: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 <http://83.136.32.91>
s=-
c=IN IP4 83.136.32.91 <http://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 <mailto:Serusers@lists.iptel.org>
http://lists.iptel.org/mailman/listinfo/serusers

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