Scott if you can run say 10 calls that exhibit this behavior with -trace_msg and -trace_error that could go a long way to diagnosing the problem.
The matching code did change between the 3.0 and the latest release, but I didn't think that the default logic had been changed. The new logic is to support the start_txn and response_txn attributes of send and receive, respectively. Previously, the CSeq was used and the matching was imprecise (and the default is). But now you can explicitly mark them like: <send start_txn="invite" /> ... </send> <recv resposne_txn="invite" reply="100" /> <recv resposne_txn="invite" reply="180" /> <recv resposne_txn="invite" reply="200" /> The string "invite" in here is just a name, it can be anything. When the message is sent, its branch ID is stored in a table, and replies are validated against that branch. You can actually prevent an optional="global" message from taking over the control flow by doing advance_state="false", but I would prefer to fix the matching for your scenario. Charles Scott Oaks <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 04/03/2008 12:54 PM Please respond to [EMAIL PROTECTED] To Charles P Wright/Watson/[EMAIL PROTECTED] cc [email protected] Subject Re: [Sipp-users] sipp corrupting messages On Wed, 2008-04-02 at 23:05, Charles P Wright wrote: > 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. Yes, it turns out to be the case, but why we get to that code is still a mystery -- it's coming from abortCall() and likely process_unexpected() but I can't quite catch that. Still, this happens quite rarely, and there's a more general issue with the ACKs that I'll show below (originally, I thought it was all the same, but it turns out not to be). > I would also be interested if you can provide any more information about > regressions you've seen. I'm beginning to think that what I'm seeing is a different manifestation of the same symptom I see in the stable build. In general, I see more errors and a longer reported avg call length (maybe 20-30% more) at the end of a run -- but the call length is, I suspect, at least partly because of the extra error processing time. It could also be a compile issue -- I can't compile the latest code with the SunStudio compiler I used for the stable code, though I don't really think that there is a signficant difference between that at gcc these days. About those errors -- I'm increasingly convinced that something is wrong in the combination of optional messages received out of order and congestion. If I run 100 calls in the latest code (well, the latest I checked out, which is SVN version 424), the uac reports this: Call limit reached (-m 100), 0.494 s period 1 ms scheduler resolution 0 calls (limit 1536) Peak was 62 calls, after 0 s 0 Running, 100 Paused, 0 Woken up 17 dead call msg (discarded) 0 out-of-call msg (discarded) 2 open sockets Messages Retrans Timeout Unexpected-Msg INVITE ----------> 100 0 0 100 <---------- 100 0 0 0 180 <---------- 85 0 0 0 200 <---------- E-RTD1 122 0 0 0 ACK ----------> 122 0 Pause [ 0ms] 122 0 BYE ----------> 122 0 0 200 <---------- 78 0 0 22 There's just some bad call-matching going on there; there shouldn't 22 extra 200OK received to from the INVITE; clearly they belong to the BYE (and then the 22 extra BYEs cause 22 481s to be received). For comparison, here's what I see in the stable build: Call limit reached (-m 1000), 0.660 s period 9 ms scheduler resolution 172 calls (limit 1536) Peak was 858 calls, after 1 s 0 Running, 172 Paused, 0 Woken up 0 out-of-call msg (discarded) 2 open sockets 0/0/12 TCP errors (send/recv/cong) Messages Retrans Timeout Unexpected-Msg INVITE ----------> 1000 0 0 100 <---------- 1000 0 0 0 180 <---------- 933 0 0 0 200 <---------- E-RTD1 1000 0 0 0 ACK ----------> 829 0 Pause [ 0ms] 829 0 BYE ----------> 829 0 0 200 <---------- 828 0 0 0 At this point, the uac never sends anything else; for some reason it has dropped 171 200 responses and not sent out an ACK. [But I don't see 171 of the abort-call generated ACKs either -- possibly there are two different things going on.] If a GLOBAL optional message is received out of order, perhaps it should just be ignored (that is, after incrementing the recv counter, call::process_incoming() could return without processing the rest)? That certainly fixes the issue for me (on both the stable and trunk builds). Or perhaps there could be an optional="ingore" tag for that case? -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
