I am seeing what I think is the same thing. I have two sipp communicating with each other doing 1000 1 second calls. As I crank the call rate to 20 per second, the answer side sees about 25 unexpected messages. If I set the call rate to 200 per second, the answer side sees about 220 unexpected messages.
I have not diagnosed this scenario further yet, but when I stick our RTP proxy in the middle (which is what I am really testing) I do see some log messages (from our proxy) that are missing the call id. Any more thoughts on this? My solution, I guess, will be to launch 20 sipps for the calling side, each sending 10 calls per second. Ed -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Klaus Darilion Sent: Wednesday, July 26, 2006 5:51 PM To: [email protected] Subject: [Sipp-users] TCP problems under high load Hi! I made some tests with ser and sipp with high TCP load. Scenario: sipp sends INVITE, ser answers with 404. After some seconds (~3000 INVITEs/s) ser reports bad SIP messages. I used ngrep to sniff the TCP flow, and found out, that sometimes some INVITE requests are missing (no continuous increasing call id). As the sequence number in the TCP packages sent by sipp are continuous, I suspect sipp to "forget" to put some data into the sending socket. Maybe this is caused due to nonblocking socket operation and buggy handling of EAGAIN? I attach the discussion from the ser mailing list with my detailed analysis. Thread: http://lists.iptel.org/pipermail/serusers/2006-July/029809.html maybe someone can review the code for sending messages. btw: is it possible to use sipp in blocking mode? thanks klaus tcp_read_req already receives a broken message: 3(30034) calling receive_msg(0x2a9635cb40, 520, ) 3(30034) tcp_read_req: preparing for new request, kept 3056 bytes 3(30034) read= 0 bytes, parsed=536, state=4, error=1 3(30034) tcp_read_req: last char=0x0A, parsed msg= INVITE sip:serviINVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0 Via: SIP/2.0/TCP 83.136.32.91:5062;branch=z9hG4bK-20964-0 From: sipp <sip:[EMAIL PROTECTED]:5062>;tag=20964 To: sut <sip:[EMAIL PROTECTED]:5060> Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE Contact: sip:[EMAIL PROTECTED]:5062 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 3(30034) tcp_read_req: end of header part 3(30034) - received from: port 32978 3(30034) tcp_read_req: headers: INVITE sip:serviINVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0 Via: SIP/2.0/TCP 83.136.32.91:5062;branch=z9hG4bK-20964-0 From: sipp <sip:[EMAIL PROTECTED]:5062>;tag=20964 To: sut <sip:[EMAIL PROTECTED]:5060> Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE Contact: sip:[EMAIL PROTECTED]:5062 Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: 135 . 3(30034) tcp_read_req: content-length= 135 3(30034) tcp_read_req: body: 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 3(30034) calling receive_msg(0x2a9635cb40, 536, ) 3(30034) ERROR:parse_first_line: bad request first line 3(30034) ERROR: at line 0 char 52: 3(30034) ERROR: parsed so far: INVITE sip:serviINVITE sip:[EMAIL PROTECTED]:5060 3(30034) ERROR:parse_first_line: bad message 3(30034) ERROR: parse_msg: message=<INVITE sip:serviINVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0 I traced the message with tcpdump: the message before the suspect one is (note the last line!!!): INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0 Via: SIP/2.0/TCP 83.136.32.91:5062;branch=z9hG4bK-20924-0 From: sipp <sip:[EMAIL PROTECTED]:5062>;tag=20924 To: sut <sip:[EMAIL PROTECTED]:5060> Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE Contact: sip:[EMAIL PROTECTED]:5062 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 INVITE sip:servi the next message is: INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0 Via: SIP/2.0/TCP 83.136.32.91:5062;branch=z9hG4bK-20964-0 From: sipp <sip:[EMAIL PROTECTED]:5062>;tag=20964 To: sut <sip:[EMAIL PROTECTED]:5060> Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE Contact: sip:[EMAIL PROTECTED]:5062 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 Thus (sipp uses increasing call id), the requests 20925 - 20963 are missing in the network dump. Lost during capture? No, because the sequence numbers of the packets are fine - no gap. Thus, I suspect sipp to "loose" some data. Hmmm. Any alternatives to sipp? ------------------------------------------------------------------------ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE V _______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
