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 <[email protected]> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sipp-users
