Re: [Sipp-users] ontimeout label does not work - sipp 3.6

[sshark wsk]

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...

  
  
  
  

  

  
  

  

  
  

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 s1  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  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  before the  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'

Re: [Sipp-users] ontimeout label does not work - sipp 3.6

[Šindelka Pavel]

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 || before 
the || 
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. 
|| 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

Re: [Sipp-users] ontimeout label does not work - sipp 3.6

[Šindelka Pavel]

Oops... I've tried to run your scenario and realized that I haven't 
compiled sipp at my new Windows laptop under cygwin yet (and the one 
saved from the old one asks for old libraries not available any more by 
peaceful means). So it won't be fast I'm afraid as I never did that 
before, last time a colleague did that for me who is not a colleague any 
more.


P.

Dne 26.03.2020 v 1:25 sshark wsk napsal(a):

Hi Alberto,

Thank you, honestly I could not find any difference from the line you 
have used. I tried it with below and my sipp does not go the label 
after timeout
ontimeout="BYE_AND_REGISTER">


I agree to your comment about sending CANCEL instead of BYE

I even compiled SIPp yesterday and tried, still same. Running on 
Ubuntu 18.04, hope it's not a reason :)

SIPp v3.6.0-23-g4dad7f2-SCTP-PCAP-RTPSTREAM

@Pavel Sindelka <mailto:sindelk...@gmail.com> - Were you able to test 
my scenario file and see if it worked or not...


Thanks for all the help
sshark


On Tue, Mar 24, 2020 at 11:29 PM Alberto Valente 
mailto:alberto-r-vale...@telecom.pt>> 
wrote:


I had the idea of having a similar scenario some time ago. I found
time to look for it and tested it in version 3.6.0 and it works
(it just doesn’t unregisters the calling subscriber).

I run it with  sudo sipp -sf ims/regInvCancel.xml -i
source-ip-address -inf csv/csvfile.csv remote-address:remote-port -m 1

The csv file has a line (may have more) like:

+351123456789;[authentication username=+351123456789
password=somepassword];somefqdn.com
<http://somefqdn.com>;3600;+351987654321;+3512;

+351123456789 – Subscriber to register and originate call

[authentication username=+351123456789 password=somepassword –
Authentication user and password

somefqdn.com <http://somefqdn.com> – subscriber realm

3600: time to use for register duration

;+351987654321 . Number to call

Just one note. If call is not answered send BYE is not the right
option.  A CANCEL request shall be used instead.

Best regards;

<http://altice.pt/>

*Alberto Valente*
DEO/EFV - Core Network and Service platforms Engineering

+351 963288480 / +351 215000290
alberto.r.vale...@telecom.pt <mailto:alberto.r.vale...@telecom.pt>
Rua Tomás Ribeiro Nº2
1050-229 LISBOA
*altice.pt* <http://altice.pt>

facebook <https://www.facebook.com/alticeportugal>linkedin
<https://www.linkedin.com/company/altice-portugal/>twitter
<http://twitter.com/altice_portugal>sapovideos
<http://videos.sapo.pt/alticeportugal>youtube
<http://www.youtube.com/alticeportugal>

AVISO DE CONFIDENCIALIDADE
Esta mensagem e quaisquer ficheiros anexos a ela contêm informação
confidencial, propriedade da Altice Portugal e/ou das demais
sociedades que com ela se encontrem em relação de domínio,
Fundação Altice Portugal e ACS, destinando-se ao uso exclusivo do
destinatário. Se não for o destinatário pretendido, não deve usar,
distribuir, imprimir ou copiar este e-mail. Se recebeu esta
mensagem por engano, por favor informe o emissor e elimine-a
imediatamente.
Obrigado

*From:*Šindelka Pavel [mailto:sinde...@ttc.cz
<mailto:sinde...@ttc.cz>]
*Sent:* terça-feira, 24 de março de 2020 07:24
*To:* sshark wsk mailto:sshark...@gmail.com>>
*Cc:* sipp-users@lists.sourceforge.net
<mailto:sipp-users@lists.sourceforge.net>
*Subject:* Re: [Sipp-users] ontimeout label does not work - sipp 3.6

Please post the complete scenario. I'll run it using an older SIPp
version on which my own scenarios with |ontimeout| work properly.

P.

Dne 24.03.2020 v 0:46 sshark wsk napsal(a):

Hi Pavel,

Thanks for your email

1. I am trying this flag for the first time. I have not tried
it with earlier SIPp versions. I just provided what version I
am testing on as I saw some threads showing that older
versions do not support this functionality.

2. I tried with optional recv lines removed, still same. It
timeout but it is treated as failed rather than jumping to
de-register sequence.

3. I have entire scenario in one file (reg, invite/answer,
dereg) and using the same call_id. I can see the registration
& call setup progresses until 180

BR,

sshark

On Tue, Mar 24, 2020 at 2:37 AM Šindelka Pavel
mailto:sinde...@ttc.cz>> wrote:

Hi Sshark,

1. you've indicated a particular version of SIPp; have you
done that because your scenario did work in previous
versions and with this one it stopped, or did you just
want to provide as much information as possible but you
actually haven't tried this particular scenario 

Re: [Sipp-users] ontimeout label does not work - sipp 3.6

[sshark wsk]

Hi Alberto,

Thank you, honestly I could not find any difference from the line you have
used. I tried it with below and my sipp does not go the label after timeout


I agree to your comment about sending CANCEL instead of BYE

I even compiled SIPp yesterday and tried, still same. Running on Ubuntu
18.04, hope it's not a reason :)
SIPp v3.6.0-23-g4dad7f2-SCTP-PCAP-RTPSTREAM

@Pavel Sindelka  - Were you able to test my scenario
file and see if it worked or not...

Thanks for all the help
sshark


On Tue, Mar 24, 2020 at 11:29 PM Alberto Valente <
alberto-r-vale...@telecom.pt> wrote:

> I had the idea of having a similar scenario some time ago. I found time to
> look for it and tested it in version 3.6.0 and it works (it just doesn’t
> unregisters the calling subscriber).
>
>
>
> I run it with  sudo sipp -sf ims/regInvCancel.xml -i source-ip-address
> -inf csv/csvfile.csv remote-address:remote-port -m 1
>
>
>
> The csv file has a line (may have more) like:
>
>
>
> +351123456789;[authentication username=+351123456789
> password=somepassword];somefqdn.com;3600;+351987654321;+3512;
>
>
>
> +351123456789 – Subscriber to register and originate call
>
> [authentication username=+351123456789 password=somepassword –
> Authentication user and password
>
> somefqdn.com – subscriber realm
>
> 3600: time to use for register duration
>
> ;+351987654321 . Number to call
>
>
>
> Just one note. If call is not answered send BYE is not the right option.
> A CANCEL request shall be used instead.
>
>
>
> Best regards;
>
>
>
> <http://altice.pt/>
>
>
>
> *Alberto Valente*
> DEO/EFV - Core Network and Service platforms Engineering
>
>
>
> +351 963288480 / +351 215000290
> alberto.r.vale...@telecom.pt
> Rua Tomás Ribeiro Nº2
> 1050-229 LISBOA
> *altice.pt* <http://altice.pt>
>
>
>
> [image: facebook] <https://www.facebook.com/alticeportugal>[image:
> linkedin] <https://www.linkedin.com/company/altice-portugal/>[image:
> twitter] <http://twitter.com/altice_portugal>[image: sapovideos]
> <http://videos.sapo.pt/alticeportugal>[image: youtube]
> <http://www.youtube.com/alticeportugal>
>
>
>
> AVISO DE CONFIDENCIALIDADE
> Esta mensagem e quaisquer ficheiros anexos a ela contêm informação
> confidencial, propriedade da Altice Portugal e/ou das demais sociedades que
> com ela se encontrem em relação de domínio, Fundação Altice Portugal e ACS,
> destinando-se ao uso exclusivo do destinatário. Se não for o destinatário
> pretendido, não deve usar, distribuir, imprimir ou copiar este e-mail. Se
> recebeu esta mensagem por engano, por favor informe o emissor e elimine-a
> imediatamente.
> Obrigado
>
>
>
> *From:* Šindelka Pavel [mailto:sinde...@ttc.cz]
> *Sent:* terça-feira, 24 de março de 2020 07:24
> *To:* sshark wsk 
> *Cc:* sipp-users@lists.sourceforge.net
> *Subject:* Re: [Sipp-users] ontimeout label does not work - sipp 3.6
>
>
>
> Please post the complete scenario. I'll run it using an older SIPp version
> on which my own scenarios with ontimeout work properly.
>
> P.
>
> Dne 24.03.2020 v 0:46 sshark wsk napsal(a):
>
> Hi Pavel,
>
>
>
> Thanks for your email
>
>
>
> 1. I am trying this flag for the first time. I have not tried it with
> earlier SIPp versions. I just provided what version I am testing on as I
> saw some threads showing that older versions do not support this
> functionality.
>
> 2. I tried with optional recv lines removed, still same. It timeout but it
> is treated as failed rather than jumping to de-register sequence.
>
> 3. I have entire scenario in one file (reg, invite/answer, dereg) and
> using the same call_id. I can see the registration & call setup progresses
> until 180
>
>
>
> BR,
>
> sshark
>
>
>
>
>
> On Tue, Mar 24, 2020 at 2:37 AM Šindelka Pavel  wrote:
>
> Hi Sshark,
>
> 1. you've indicated a particular version of SIPp; have you done that
> because your scenario did work in previous versions and with this one it
> stopped, or did you just want to provide as much information as possible
> but you actually haven't tried this particular scenario with any previous
> SIPp version?
>
> 2. I remember I had some trouble to make ontimeout work in one of the
> older releases (and I haven't changed the scenarios since, so don't read it
> as "and it worked flawlessly in the never ones"), but I cannot remember the
> details (except that even with the ontimeout handling defined next to the
> timeout specification, a call where a timeout has elapsed is always
> counted as a failed one which is sometimes

Re: [Sipp-users] ontimeout label does not work - sipp 3.6

[Alberto Valente]

I had the idea of having a similar scenario some time ago. I found time to look 
for it and tested it in version 3.6.0 and it works (it just doesn’t unregisters 
the calling subscriber).

I run it with  sudo sipp -sf ims/regInvCancel.xml -i source-ip-address -inf 
csv/csvfile.csv remote-address:remote-port -m 1

The csv file has a line (may have more) like:

+351123456789;[authentication username=+351123456789 
password=somepassword];somefqdn.com;3600;+351987654321;+3512;

+351123456789 – Subscriber to register and originate call
[authentication username=+351123456789 password=somepassword – Authentication 
user and password
somefqdn.com – subscriber realm
3600: time to use for register duration
;+351987654321 . Number to call

Just one note. If call is not answered send BYE is not the right option.  A 
CANCEL request shall be used instead.

Best regards;

[cid:image001.png@01D601D7.58F388C0]<http://altice.pt/>

Alberto Valente
DEO/EFV - Core Network and Service platforms Engineering

+351 963288480 / +351 215000290
alberto.r.vale...@telecom.pt<mailto:alberto.r.vale...@telecom.pt>
Rua Tomás Ribeiro Nº2
1050-229 LISBOA
altice.pt<http://altice.pt>

[facebook]<https://www.facebook.com/alticeportugal>[linkedin]<https://www.linkedin.com/company/altice-portugal/>[twitter]<http://twitter.com/altice_portugal>[sapovideos]<http://videos.sapo.pt/alticeportugal>[youtube]<http://www.youtube.com/alticeportugal>

AVISO DE CONFIDENCIALIDADE
Esta mensagem e quaisquer ficheiros anexos a ela contêm informação 
confidencial, propriedade da Altice Portugal e/ou das demais sociedades que com 
ela se encontrem em relação de domínio, Fundação Altice Portugal e ACS, 
destinando-se ao uso exclusivo do destinatário. Se não for o destinatário 
pretendido, não deve usar, distribuir, imprimir ou copiar este e-mail. Se 
recebeu esta mensagem por engano, por favor informe o emissor e elimine-a 
imediatamente.
Obrigado

From: Šindelka Pavel [mailto:sinde...@ttc.cz]
Sent: terça-feira, 24 de março de 2020 07:24
To: sshark wsk 
Cc: sipp-users@lists.sourceforge.net
Subject: Re: [Sipp-users] ontimeout label does not work - sipp 3.6


Please post the complete scenario. I'll run it using an older SIPp version on 
which my own scenarios with ontimeout work properly.

P.
Dne 24.03.2020 v 0:46 sshark wsk napsal(a):
Hi Pavel,

Thanks for your email

1. I am trying this flag for the first time. I have not tried it with earlier 
SIPp versions. I just provided what version I am testing on as I saw some 
threads showing that older versions do not support this functionality.
2. I tried with optional recv lines removed, still same. It timeout but it is 
treated as failed rather than jumping to de-register sequence.
3. I have entire scenario in one file (reg, invite/answer, dereg) and using the 
same call_id. I can see the registration & call setup progresses until 180

BR,
sshark


On Tue, Mar 24, 2020 at 2:37 AM Šindelka Pavel 
mailto:sinde...@ttc.cz>> wrote:

Hi Sshark,

1. you've indicated a particular version of SIPp; have you done that because 
your scenario did work in previous versions and with this one it stopped, or 
did you just want to provide as much information as possible but you actually 
haven't tried this particular scenario with any previous SIPp version?

2. I remember I had some trouble to make ontimeout work in one of the older 
releases (and I haven't changed the scenarios since, so don't read it as "and 
it worked flawlessly in the never ones"), but I cannot remember the details 
(except that even with the ontimeout handling defined next to the timeout 
specification, a call where a timeout has elapsed is always counted as a failed 
one which is sometimes not desirable, but you're not that far yet). So can you 
try without the  between the  and 
 ? It's not a solution, it 
is a diagnostic step, but I'm afraid this type of setup (optional messages and 
one mandatory one with a timeout specified) may not have been addressed in the 
SIPp code.

3. I hope you don't actually send REGISTER and INVITE with the same Call-ID 
value, as a normal SIP stack would fail on that. This one is not related to 
ontimeout, it's related to how SIP itself works.

Pavel


Dne 23.03.2020 v 13:43 sshark wsk napsal(a):
Hi Alberto,

Thank you for your suggestion. I have tried with below flag. However still the 
it does not work


Is it possible to do some debug mode/prints to see why it does not work

BR,
Sshark

On Mon, Mar 23, 2020 at 8:01 PM Alberto Valente 
mailto:alberto-r-vale...@telecom.pt>> wrote:
I think you must use something like



Where xx stands for the number of milliseconds you want to wait for the 200 
OK Mresponse

Best regards
[cid:image001.png@01D601D7.58F388C0]<http://altice.pt/>

Alberto Valente
DEO/EFV - Core Network and Service platforms Engineering

+351 963288480 / +351 215000290
alberto.r.va

Re: [Sipp-users] ontimeout label does not work - sipp 3.6

[Šindelka Pavel]

Please post the complete scenario. I'll run it using an older SIPp 
version on which my own scenarios with |ontimeout| work properly.


P.

Dne 24.03.2020 v 0:46 sshark wsk napsal(a):

Hi Pavel,

Thanks for your email

1. I am trying this flag for the first time. I have not tried it with 
earlier SIPp versions. I just provided what version I am testing on as 
I saw some threads showing that older versions do not support this 
functionality.
2. I tried with optional recv lines removed, still same. It 
timeout but it is treated as failed rather than jumping to de-register 
sequence.
3. I have entire scenario in one file (reg, invite/answer, dereg) and 
using the same call_id. I can see the registration & call setup 
progresses until 180


BR,
sshark


On Tue, Mar 24, 2020 at 2:37 AM Šindelka Pavel > wrote:


Hi Sshark,

1. you've indicated a particular version of SIPp; have you done
that because your scenario did work in previous versions and with
this one it stopped, or did you just want to provide as much
information as possible but you actually haven't tried this
particular scenario with any previous SIPp version?

2. I remember I had some trouble to make ontimeout work in one of
the older releases (and I haven't changed the scenarios since, so
don't read it as "and it worked flawlessly in the never ones"),
but I cannot remember the details (except that even with the
|ontimeout| handling defined next to the |timeout| specification,
a call where a timeout has elapsed is always counted as a failed
one which is sometimes not desirable, but you're not that far
yet). So can you try without the || between the || and _ ? It's not a solution, it is a
diagnostic step, but I'm afraid this type of setup (optional
messages and one mandatory one with a timeout specified) may not
have been addressed in the SIPp code.

3. I hope you don't actually send |REGISTER| and |INVITE| with the
same |Call-ID| value, as a normal SIP stack would fail on that.
This one is not related to |ontimeout|, it's related to how SIP
itself works.

Pavel


Dne 23.03.2020 v 13:43 sshark wsk napsal(a):

Hi Alberto,

Thank you for your suggestion. I have tried with below flag.
However still the it does not work


Is it possible to do some debug mode/prints to see why it does
not work

BR,
Sshark

On Mon, Mar 23, 2020 at 8:01 PM Alberto Valente
mailto:alberto-r-vale...@telecom.pt>> wrote:

I think you must use something like



Where xx stands for the number of milliseconds you want
to wait for the 200 OK Mresponse

Best regards



*Alberto Valente*
DEO/EFV - Core Network and Service platforms Engineering

+351 963288480 / +351 215000290
alberto.r.vale...@telecom.pt

Rua Tomás Ribeiro Nº2
1050-229 LISBOA
*altice.pt* 

facebook linkedin
twitter
sapovideos
youtube


AVISO DE CONFIDENCIALIDADE
Esta mensagem e quaisquer ficheiros anexos a ela contêm
informação confidencial, propriedade da Altice Portugal e/ou
das demais sociedades que com ela se encontrem em relação de
domínio, Fundação Altice Portugal e ACS, destinando-se ao uso
exclusivo do destinatário. Se não for o destinatário
pretendido, não deve usar, distribuir, imprimir ou copiar
este e-mail. Se recebeu esta mensagem por engano, por favor
informe o emissor e elimine-a imediatamente.
Obrigado

*From:*sshark wsk [mailto:sshark...@gmail.com
]
*Sent:* sábado, 21 de março de 2020 04:17
*To:* sipp-users@lists.sourceforge.net

*Subject:* [Sipp-users] ontimeout label does not work - sipp 3.6

Dear Users,

I have sipp version - SIPp
v3.6-dev-112-g8c0e358-TLS-PCAP-RTPSTREAM

I have prepared a UAC scenario where

1. User sends SIP registration

2. Gets 401/200 OK and registers

3. Sends INVITE

3. Waits for 100/180/200

4. Sends ACK

5. Pauses for 4s and sends BYE

6. De-register the user

In step 3, I would like to timeout if User B does not answer
(not receiving 200 OK within a certain time) with below



 Unfortunately above does not work

I run SIPp with below flags

./sipp 192.168.1.1 -bind_local -i 10.10.10.1 -mp 5 -t u1
-p 5060 -recv_timeout 3200 -sf register_and_call.xml -inf
 

Re: [Sipp-users] ontimeout label does not work - sipp 3.6

[sshark wsk]

Hi Pavel,

Thanks for your email

1. I am trying this flag for the first time. I have not tried it with
earlier SIPp versions. I just provided what version I am testing on as I
saw some threads showing that older versions do not support this
functionality.
2. I tried with optional recv lines removed, still same. It timeout but it
is treated as failed rather than jumping to de-register sequence.
3. I have entire scenario in one file (reg, invite/answer, dereg) and using
the same call_id. I can see the registration & call setup progresses until
180

BR,
sshark


On Tue, Mar 24, 2020 at 2:37 AM Šindelka Pavel  wrote:

> Hi Sshark,
>
> 1. you've indicated a particular version of SIPp; have you done that
> because your scenario did work in previous versions and with this one it
> stopped, or did you just want to provide as much information as possible
> but you actually haven't tried this particular scenario with any previous
> SIPp version?
>
> 2. I remember I had some trouble to make ontimeout work in one of the
> older releases (and I haven't changed the scenarios since, so don't read it
> as "and it worked flawlessly in the never ones"), but I cannot remember the
> details (except that even with the ontimeout handling defined next to the
> timeout specification, a call where a timeout has elapsed is always
> counted as a failed one which is sometimes not desirable, but you're not
> that far yet). So can you try without the  optional="true"> between the  and  ontimeout="do_something" ... > ? It's not a solution, it is a diagnostic
> step, but I'm afraid this type of setup (optional messages and one
> mandatory one with a timeout specified) may not have been addressed in the
> SIPp code.
>
> 3. I hope you don't actually send REGISTER and INVITE with the same
> Call-ID value, as a normal SIP stack would fail on that. This one is not
> related to ontimeout, it's related to how SIP itself works.
>
> Pavel
>
>
> Dne 23.03.2020 v 13:43 sshark wsk napsal(a):
>
> Hi Alberto,
>
> Thank you for your suggestion. I have tried with below flag. However still
> the it does not work
> 
>
> Is it possible to do some debug mode/prints to see why it does not work
>
> BR,
> Sshark
>
> On Mon, Mar 23, 2020 at 8:01 PM Alberto Valente <
> alberto-r-vale...@telecom.pt> wrote:
>
>> I think you must use something like
>>
>>
>>
>> > ontimeout="BYE_AND_DEREGISTER">
>>
>>
>>
>> Where xx stands for the number of milliseconds you want to wait for
>> the 200 OK Mresponse
>>
>>
>>
>> Best regards
>>
>> 
>>
>>
>>
>> *Alberto Valente*
>> DEO/EFV - Core Network and Service platforms Engineering
>>
>>
>>
>> +351 963288480 / +351 215000290
>> alberto.r.vale...@telecom.pt
>> Rua Tomás Ribeiro Nº2
>> 1050-229 LISBOA
>> *altice.pt* 
>>
>>
>>
>> [image: facebook] [image:
>> linkedin] [image:
>> twitter] [image: sapovideos]
>> [image: youtube]
>> 
>>
>>
>>
>> AVISO DE CONFIDENCIALIDADE
>> Esta mensagem e quaisquer ficheiros anexos a ela contêm informação
>> confidencial, propriedade da Altice Portugal e/ou das demais sociedades que
>> com ela se encontrem em relação de domínio, Fundação Altice Portugal e ACS,
>> destinando-se ao uso exclusivo do destinatário. Se não for o destinatário
>> pretendido, não deve usar, distribuir, imprimir ou copiar este e-mail. Se
>> recebeu esta mensagem por engano, por favor informe o emissor e elimine-a
>> imediatamente.
>> Obrigado
>>
>>
>>
>> *From:* sshark wsk [mailto:sshark...@gmail.com]
>> *Sent:* sábado, 21 de março de 2020 04:17
>> *To:* sipp-users@lists.sourceforge.net
>> *Subject:* [Sipp-users] ontimeout label does not work - sipp 3.6
>>
>>
>>
>> Dear Users,
>>
>>
>>
>> I have sipp version - SIPp v3.6-dev-112-g8c0e358-TLS-PCAP-RTPSTREAM
>>
>>
>>
>> I have prepared a UAC scenario where
>>
>> 1. User sends SIP registration
>>
>> 2. Gets 401/200 OK and registers
>>
>> 3. Sends INVITE
>>
>> 3. Waits for 100/180/200
>>
>> 4. Sends ACK
>>
>> 5. Pauses for 4s and sends BYE
>>
>> 6. De-register the user
>>
>>
>>
>> In step 3, I would like to timeout if User B does not answer (not
>> receiving 200 OK within a certain time) with below
>>
>> 
>>
>>  Unfortunately above does not work
>>
>>
>>
>> I run SIPp with below flags
>>
>> ./sipp 192.168.1.1 -bind_local -i 10.10.10.1 -mp 5 -t u1 -p 5060
>> -recv_timeout 3200 -sf register_and_call.xml -inf USER_A.csv -m 1 -trace_msg
>>
>>
>>
>> Hope you can assist me
>>
>>
>>
>> Thank You
>>
>> sshark
>>
>>
>>
>>
>>
>
>
> ___
> Sipp-users mailing 
> listSipp-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/sipp-users
>
> ___
> Sipp-users mailing list
> Sipp-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listin

Re: [Sipp-users] ontimeout label does not work - sipp 3.6

[Šindelka Pavel]

Hi Sshark,

1. you've indicated a particular version of SIPp; have you done that 
because your scenario did work in previous versions and with this one it 
stopped, or did you just want to provide as much information as possible 
but you actually haven't tried this particular scenario with any 
previous SIPp version?


2. I remember I had some trouble to make ontimeout work in one of the 
older releases (and I haven't changed the scenarios since, so don't read 
it as "and it worked flawlessly in the never ones"), but I cannot 
remember the details (except that even with the |ontimeout| handling 
defined next to the |timeout| specification, a call where a timeout has 
elapsed is always counted as a failed one which is sometimes not 
desirable, but you're not that far yet). So can you try without the 
|| between the || and _response="200" ontimeout="do_something" ... > ? It's not a solution, it 
is a diagnostic step, but I'm afraid this type of setup (optional 
messages and one mandatory one with a timeout specified) may not have 
been addressed in the SIPp code.


3. I hope you don't actually send |REGISTER| and |INVITE| with the same 
|Call-ID| value, as a normal SIP stack would fail on that. This one is 
not related to |ontimeout|, it's related to how SIP itself works.


Pavel


Dne 23.03.2020 v 13:43 sshark wsk napsal(a):

Hi Alberto,

Thank you for your suggestion. I have tried with below flag. However 
still the it does not work



Is it possible to do some debug mode/prints to see why it does not work

BR,
Sshark

On Mon, Mar 23, 2020 at 8:01 PM Alberto Valente 
mailto:alberto-r-vale...@telecom.pt>> 
wrote:


I think you must use something like



Where xx stands for the number of milliseconds you want to
wait for the 200 OK Mresponse

Best regards



*Alberto Valente*
DEO/EFV - Core Network and Service platforms Engineering

+351 963288480 / +351 215000290
alberto.r.vale...@telecom.pt 
Rua Tomás Ribeiro Nº2
1050-229 LISBOA
*altice.pt* 

facebook linkedin
twitter
sapovideos
youtube


AVISO DE CONFIDENCIALIDADE
Esta mensagem e quaisquer ficheiros anexos a ela contêm informação
confidencial, propriedade da Altice Portugal e/ou das demais
sociedades que com ela se encontrem em relação de domínio,
Fundação Altice Portugal e ACS, destinando-se ao uso exclusivo do
destinatário. Se não for o destinatário pretendido, não deve usar,
distribuir, imprimir ou copiar este e-mail. Se recebeu esta
mensagem por engano, por favor informe o emissor e elimine-a
imediatamente.
Obrigado

*From:*sshark wsk [mailto:sshark...@gmail.com
]
*Sent:* sábado, 21 de março de 2020 04:17
*To:* sipp-users@lists.sourceforge.net

*Subject:* [Sipp-users] ontimeout label does not work - sipp 3.6

Dear Users,

I have sipp version - SIPp v3.6-dev-112-g8c0e358-TLS-PCAP-RTPSTREAM

I have prepared a UAC scenario where

1. User sends SIP registration

2. Gets 401/200 OK and registers

3. Sends INVITE

3. Waits for 100/180/200

4. Sends ACK

5. Pauses for 4s and sends BYE

6. De-register the user

In step 3, I would like to timeout if User B does not answer (not



receiving 200 OK within a certain time) with below



 Unfortunately above does not work

I run SIPp with below flags

./sipp 192.168.1.1 -bind_local -i 10.10.10.1 -mp 5 -t u1 -p
5060 -recv_timeout 3200 -sf register_and_call.xml -inf USER_A.csv
-m 1 -trace_msg

Hope you can assist me

Thank You

sshark



___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] ontimeout label does not work - sipp 3.6

[sshark wsk]

Hi Alberto,

Thank you for your suggestion. I have tried with below flag. However still
the it does not work


Is it possible to do some debug mode/prints to see why it does not work

BR,
Sshark

On Mon, Mar 23, 2020 at 8:01 PM Alberto Valente <
alberto-r-vale...@telecom.pt> wrote:

> I think you must use something like
>
>
>
>  ontimeout="BYE_AND_DEREGISTER">
>
>
>
> Where xx stands for the number of milliseconds you want to wait for
> the 200 OK Mresponse
>
>
>
> Best regards
>
> 
>
>
>
> *Alberto Valente*
> DEO/EFV - Core Network and Service platforms Engineering
>
>
>
> +351 963288480 / +351 215000290
> alberto.r.vale...@telecom.pt
> Rua Tomás Ribeiro Nº2
> 1050-229 LISBOA
> *altice.pt* 
>
>
>
> [image: facebook] [image:
> linkedin] [image:
> twitter] [image: sapovideos]
> [image: youtube]
> 
>
>
>
> AVISO DE CONFIDENCIALIDADE
> Esta mensagem e quaisquer ficheiros anexos a ela contêm informação
> confidencial, propriedade da Altice Portugal e/ou das demais sociedades que
> com ela se encontrem em relação de domínio, Fundação Altice Portugal e ACS,
> destinando-se ao uso exclusivo do destinatário. Se não for o destinatário
> pretendido, não deve usar, distribuir, imprimir ou copiar este e-mail. Se
> recebeu esta mensagem por engano, por favor informe o emissor e elimine-a
> imediatamente.
> Obrigado
>
>
>
> *From:* sshark wsk [mailto:sshark...@gmail.com]
> *Sent:* sábado, 21 de março de 2020 04:17
> *To:* sipp-users@lists.sourceforge.net
> *Subject:* [Sipp-users] ontimeout label does not work - sipp 3.6
>
>
>
> Dear Users,
>
>
>
> I have sipp version - SIPp v3.6-dev-112-g8c0e358-TLS-PCAP-RTPSTREAM
>
>
>
> I have prepared a UAC scenario where
>
> 1. User sends SIP registration
>
> 2. Gets 401/200 OK and registers
>
> 3. Sends INVITE
>
> 3. Waits for 100/180/200
>
> 4. Sends ACK
>
> 5. Pauses for 4s and sends BYE
>
> 6. De-register the user
>
>
>
> In step 3, I would like to timeout if User B does not answer (not
> receiving 200 OK within a certain time) with below
>
> 
>
>  Unfortunately above does not work
>
>
>
> I run SIPp with below flags
>
> ./sipp 192.168.1.1 -bind_local -i 10.10.10.1 -mp 5 -t u1 -p 5060
> -recv_timeout 3200 -sf register_and_call.xml -inf USER_A.csv -m 1 -trace_msg
>
>
>
> Hope you can assist me
>
>
>
> Thank You
>
> sshark
>
>
>
>
>
___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] ontimeout label does not work - sipp 3.6

[Alberto Valente]

I think you must use something like



Where xx stands for the number of milliseconds you want to wait for the 200 
OK Mresponse

Best regards
[cid:image001.png@01D600F1.AD83C260]

Alberto Valente
DEO/EFV - Core Network and Service platforms Engineering

+351 963288480 / +351 215000290
alberto.r.vale...@telecom.pt
Rua Tomás Ribeiro Nº2
1050-229 LISBOA
altice.pt

[facebook][linkedin][twitter][sapovideos][youtube]

AVISO DE CONFIDENCIALIDADE
Esta mensagem e quaisquer ficheiros anexos a ela contêm informação 
confidencial, propriedade da Altice Portugal e/ou das demais sociedades que com 
ela se encontrem em relação de domínio, Fundação Altice Portugal e ACS, 
destinando-se ao uso exclusivo do destinatário. Se não for o destinatário 
pretendido, não deve usar, distribuir, imprimir ou copiar este e-mail. Se 
recebeu esta mensagem por engano, por favor informe o emissor e elimine-a 
imediatamente.
Obrigado

From: sshark wsk [mailto:sshark...@gmail.com]
Sent: sábado, 21 de março de 2020 04:17
To: sipp-users@lists.sourceforge.net
Subject: [Sipp-users] ontimeout label does not work - sipp 3.6

Dear Users,

I have sipp version - SIPp v3.6-dev-112-g8c0e358-TLS-PCAP-RTPSTREAM

I have prepared a UAC scenario where
1. User sends SIP registration
2. Gets 401/200 OK and registers
3. Sends INVITE
3. Waits for 100/180/200
4. Sends ACK
5. Pauses for 4s and sends BYE
6. De-register the user

In step 3, I would like to timeout if User B does not answer (not receiving 200 
OK within a certain time) with below

 Unfortunately above does not work

I run SIPp with below flags
./sipp 192.168.1.1 -bind_local -i 10.10.10.1 -mp 5 -t u1 -p 5060 
-recv_timeout 3200 -sf register_and_call.xml -inf USER_A.csv -m 1 -trace_msg

Hope you can assist me

Thank You
sshark


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users