From: Klaus D. <kla...@pe...> - 2006-07-27 14:18:33
|
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 use= d 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 t= o "forget" to put some data into the sending socket. Maybe this is caused due to nonblocking socket operation and buggy=20 handling of EAGAIN? I attach the discussion from the ser mailing list with my detailed=20 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=3D 0 bytes, parsed=3D536, state=3D4, error=3D1 3(30034) tcp_read_req: last char=3D0x0A, parsed msg=3D INVITE sip:serviINVITE sip:service@83.136.32.91:5060 SIP/2.0 Via: SIP/2.0/TCP 83.136.32.91:5062;branch=3Dz9hG4bK-20964-0 From: sipp <sip:sipp@83.136.32.91:5062>;tag=3D20964 To: sut <sip:service@83.136.32.91:5060> Call-ID: 20964-30136@83.136.32.91 CSeq: 1 INVITE Contact: sip:sipp@83.136.32.91:5062 Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: 135 v=3D0 o=3Duser1 53655765 2353687637 IN IP4 83.136.32.91 s=3D- c=3DIN IP4 83.136.32.91 t=3D0 0 m=3Daudio 6002 RTP/AVP 0 a=3Drtpmap: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:service@83.136.32.91:5060 SIP/2.0 Via: SIP/2.0/TCP 83.136.32.91:5062;branch=3Dz9hG4bK-20964-0 From: sipp <sip:sipp@83.136.32.91:5062>;tag=3D20964 To: sut <sip:service@83.136.32.91:5060> Call-ID: 20964-30136@83.136.32.91 CSeq: 1 INVITE Contact: sip:sipp@83.136.32.91:5062 Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: 135 . 3(30034) tcp_read_req: content-length=3D 135 3(30034) tcp_read_req: body: v=3D0 o=3Duser1 53655765 2353687637 IN IP4 83.136.32.91 s=3D- c=3DIN IP4 83.136.32.91 t=3D0 0 m=3Daudio 6002 RTP/AVP 0 a=3Drtpmap: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:service@83.136.32.91:5060 3(30034) ERROR:parse_first_line: bad message 3(30034) ERROR: parse_msg: message=3D<INVITE sip:serviINVITE sip:service@83.136.32.91:5060 SIP/2.0 I traced the message with tcpdump: the message before the suspect one is (note the last line!!!): INVITE sip:service@83.136.32.91:5060 SIP/2.0 Via: SIP/2.0/TCP 83.136.32.91:5062;branch=3Dz9hG4bK-20924-0 From: sipp <sip:sipp@83.136.32.91:5062>;tag=3D20924 To: sut <sip:service@83.136.32.91:5060> Call-ID: 20924-30136@83.136.32.91 CSeq: 1 INVITE Contact: sip:sipp@83.136.32.91:5062 Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: 135 v=3D0 o=3Duser1 53655765 2353687637 IN IP4 83.136.32.91 s=3D- c=3DIN IP4 83.136.32.91 t=3D0 0 m=3Daudio 6002 RTP/AVP 0 a=3Drtpmap:0 PCMU/8000 INVITE sip:servi the next message is: INVITE sip:service@83.136.32.91:5060 SIP/2.0 Via: SIP/2.0/TCP 83.136.32.91:5062;branch=3Dz9hG4bK-20964-0 From: sipp <sip:sipp@83.136.32.91:5062>;tag=3D20964 To: sut <sip:service@83.136.32.91:5060> Call-ID: 20964-30136@83.136.32.91 CSeq: 1 INVITE Contact: sip:sipp@83.136.32.91:5062 Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: 135 v=3D0 o=3Duser1 53655765 2353687637 IN IP4 83.136.32.91 s=3D- c=3DIN IP4 83.136.32.91 t=3D0 0 m=3Daudio 6002 RTP/AVP 0 a=3Drtpmap:0 PCMU/8000 Thus (sipp uses increasing call id), the requests 20925 - 20963 are=20 missing in the network dump. Lost during capture? No, because the=20 sequence numbers of the packets are fine - no gap. Thus, I suspect sipp to "loose" some data. Hmmm. Any alternatives to sipp= ? |