Thank you for your investigation... I am also able to confirm similar behaviour on my sipp. I tried by adding below timeout/ontimeout values for the optional messages and they seem to be firing on respective timeouts. I feel that if its an "optional" message, then it should not even have a timeout as there is a legitimate possibility of not receiving that message ? I will post this question in GitHub to see...
<recv response="100" optional="true"> </recv> <recv response="183" optional="true" rtd="true" rrs="true" timeout="4000" ontimeout="wait4180"> </recv> <label id="wait4180" /> <recv response="180" optional="true" rtd="true" rrs="true" timeout="3000" ontimeout="wait4200ok"> </recv> <label id="wait4200ok" /> <recv response="200" rtd="true" rrs="true" timeout="4000" ontimeout="cancelandclearregistration"> </recv> Scenario run ------------------------------ Scenario Screen -------- [1-9]: Change Screen -- Call rate (length) Port Total-time Total-calls Remote-host 10.0(0 ms)/1.000s 5060 25.90 s 1 10.201.134.240:5060(UDP) Call limit 1 hit, 0.0 s period 0 ms scheduler resolution 0 calls (limit 675) Peak was 1 calls, after 0 s 0 Running, 2 Paused, 0 Woken up 0 dead call msg (discarded) 0 out-of-call msg (discarded) 0 open sockets 0/0/0 UDP errors (send/recv/cong) 0 open sockets 0/0/0 UDP errors (send/recv/cong) Messages Retrans Timeout Unexpected-Msg REGISTER ----------> 1 0 500 <---------- 0 0 0 0 200 <---------- 0 0 0 0 401 <---------- 1 0 0 0 REGISTER ----------> 1 0 200 <---------- 1 0 0 0 Pause [ 4000ms] 1 0 INVITE ----------> 1 0 500 <---------- 0 0 0 0 100 <---------- 1 0 0 0 183 <---------- E-RTD1 0 0 1 0 180 <---------- E-RTD1 0 0 1 0 200 <---------- E-RTD1 0 0 1 0 ACK ----------> 0 0 Pause [ 500ms] 0 0 [ NOP ] Pause [ 8000ms] 0 0 BYE ----------> 0 0 200 <---------- E-RTD1 0 0 0 0 Pause [ 4000ms] 1 0 CANCEL ----------> 1 0 500 <---------- 0 0 0 0 200 <---------- 1 0 0 0 487 <---------- E-RTD1 1 0 0 0 ACK ----------> 1 0 Pause [ 2000ms] 1 0 REGISTER ----------> 1 0 500 <---------- 0 0 0 0 200 <---------- 1 0 0 0 480 <---------- 0 0 0 0 401 <---------- 0 0 0 0 REGISTER ----------> 0 0 0 200 <---------- 0 0 0 0 Pause [ 4000ms] 1 0 On Sat, Mar 28, 2020 at 8:26 PM Šindelka Pavel <sinde...@ttc.cz> wrote: > > So with sipp 3.995 (the last version available at sourceforge, which is > closest to the 3.3 I was using before migrating to the new laptop), the > ontimeout attribute works as expected (i.e. when the timeout elapses, the > scenario execution jumps to the label indicated in the ontimeout attribute - > see the scenario screen below), but as I've suggested earlier, the presence > of <recv response´"xxx" optional="true"/> before the <recv response="200" > timeout="3000" ontimeout="some_label"/> causes the timeout not to ever > happen. Which I've concluded to be quite logical back then when I was dealing > with it myself, and as I could work that around, I gave up trying to > understand that in detail quite quickly. > > Now, I gave it a bit more, so I've configured also the 100 and 180 with > timeout and ontimeout, where the timeout for the 100 was different from the > one for the 180 and the 200 (I've commented out the rest of optional > responses). Regardless whether the 100's timeout was longer or shorter than > the one for the 180 and the 200, it always fired first. > > So there are two differences in 3.6 as compared to 3.3: > > optional messages preceding the mandatory one with ontimeout now don't > prevent the timer from firing (improvement), > the ontimeout value is not used (regression). > > Given that, I'd think that someone has made modifications to the handling of > optional messages when a timeout is specified for the mandatory one following > them, and this may have included some mistake in processing of the ontimeout > attribute. > > Hence I suggest you to raise an issue at github. Maybe with a note that it > should be selectible whether a expiration of this particular timeout is > considered a call failure or not, as when we want to send a BYE only if the > remote peer didn't within some time, it may not always be considered a > failure. > > Other than that, sipp kept saying it cannot load or parse your scenario file > until I've copy-pasted it to another one using a text editor. Changing > iso-8859-2 to iso-8859-1 in the original file did not help. <label id="3"/> > was missing in it, but with the copy, sipp just complained about absence of > label 3, not about a problem with the whole file. Weird. So maybe do the same > and try again before filing a bug, the 3.6 parser has been reworked as > compared to 3.3, so the same problem with the file may cause a different > outcome there. > > P. > > ------------------------------ Scenario Screen -------- [1-9]: Change Screen > -- > Call-rate(length) Port Total-time Total-calls Remote-host > 10.0(0 ms)/1.000s 5060 15.20 s 1 127.0.0.1:5082(UDP) > > Call limit reached (-m 1), 1.006 s period 16 ms scheduler resolution > 1 calls (limit 615) Peak was 1 calls, after 0 s > 0 Running, 2 Paused, 4 Woken up > 0 dead call msg (discarded) 0 out-of-call msg (discarded) > 3 open sockets > 0 Total RTP pckts sent 0.000 last period RTP rate (kB/s) > > Messages Retrans Timeout Unexpected-Msg > REGISTER ----------> 1 0 > 200 <---------- 1 0 0 0 > 500 <---------- 0 0 0 0 > 401 <---------- 0 0 0 0 > REGISTER ----------> 0 0 > 200 <---------- 0 0 0 0 > Pause [ 4000ms] 1 0 > INVITE ----------> 1 0 > 200 <---------- 0 0 1 0 > > ACK ----------> 0 0 > Pause [ 500ms] 0 0 > [ NOP ] > Pause [ 8000ms] 0 0 > BYE ----------> 1 0 > 200 <---------- 0 0 0 0 > > Pause [ 4000ms] 0 0 > REGISTER ----------> 0 0 > 200 <---------- 0 0 0 0 > 500 <---------- 0 0 0 0 > 480 <---------- 0 0 0 0 > 401 <---------- 0 0 0 0 > REGISTER ----------> 0 0 0 > 200 <---------- 0 0 0 0 > Pause [ 4000ms] 0 0 > ------- Waiting for active calls to end. Press [q] again to force exit. > ------- > > _______________________________________________ Sipp-users mailing list Sipp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sipp-users