My best guess is that if you look at the default messages in the source, that ACK will match up relatively nicely to one of them in there rather than it coming from some sort of corruption.
I would also be interested if you can provide any more information about regressions you've seen. Charles Scott Oaks <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 04/02/2008 07:13 PM Please respond to [EMAIL PROTECTED] To [email protected] cc Subject [Sipp-users] sipp corrupting messages I have a scenario file attached -- but the gist of which is that it does a basic invite: <send> ... invite </send> <recv response="100" optional="global"/> <recv response="180" optional="global"./> <recv response="200"> <action which saves a variable $6 from the contact header></recv> <send> ACK sip:[EMAIL PROTECTED]:[remote_port];transport=[transport];[$6] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: sipp <sip:[EMAIL PROTECTED]:[local_port]>;tag=[pid]SIPpTag00[call_number] To: sut <sip:[EMAIL PROTECTED]:[remote_port]>[peer_tag_param] Call-ID: [call_id] CSeq: [cseq] ACK [routes] Contact: sip:[EMAIL PROTECTED]:[local_port] Max-Forwards: 70 Subject: InviteProxy Performance Test Content-Length: 0 </send> This all works fine, except that sometimes, sipp sends out an ACK formatted like this: ACK sip:[EMAIL PROTECTED]:5045 SIP/2.0 Via: SIP/2.0/TCP 10.5.8.146:5035;branch=z9hG4bK-17387-130--1 From: ... To: ... Call-ID: .... CSeq: 1 ACK Max-Forwards: 70 Contact: .... Content-Length: 0 There are at least three things wrong here: the ACK doesn't have the transport correct (nor the variable), the branch is malformed (not a typo; it does have --1 at the end), and the headers after the CSeq are out of order and don't include the route. I've been unable to track this down -- I believe it may be a combination of two things: first is that we could receive the 180 following the 200 (which is why the 180 is marked optional), and second we could be very congested. I suspect (but haven't been able to tell) that it is a combination of things: a simple test where the 180 is deliberately sent after the 200 doesn't cause the corrupted ACK message to be sent, but the higher load we run, the more it seems to happen. [Also, if I have my UAS never send a 180, the ACK is never corrupted either.] Under normal circumstances, when sipp processes the 200 OK, the ACK is immediately sent (before sipp processes the 180). Is it possible somehow that if the socket is congested, the 180 will be processed before the ACK is forrmatted and put on the pending messages list? That could mess up the route (though I wouldn't think it would mess up the branch), and in fact if I short-circuit the processing of the optional message (immediately returning from call:process_incoming when the global message is found), I never see the corrupted ACK either. Is there something wrong with my understanding of the global optional flag, or is there some bug I still need to track down (and if so, any suggestions would be welcome!). I'm using the stable 3.0 build (I've tried the latest code in the trunk, but it had some performance regressions for me, so I didn't spend a lot of time with it). -Scott ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
uac.xml
Description: Binary data
------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
