Hi Joel,
I'll follow your idea of subthreads and hope that if someone else needs
to read that conversation, they won't get lost. So my answers are inside
your text.
P.
Dne 21.1.2016 v 5:40 Joel Serrano napsal(a):
Hi Pavel,
First of all, thank you very much for such a detailed explanation.
I'm separating my answer in blocks so we can keep the
multi-conversation in one thread :)
-----------
** I checked the sip capture, and yes, the messages belong to the
dialog, so they have the same Call-Id, etc. (this is good as it makes
things "easier").
-----------
I tried your version without 3PCC:
[...]
<recv request="MESSAGE" optional="true" next="respond_received_MESSAGE"/>
<recv request="BYE" next="respond_received_BYE" timeout="5000"
ontimeout="send_my_own_BYE"/>
[...]
In this case:
If I get a MESSAGE, it will respond with the OK, and go back to
waiting, so far ok, but after 5 seconds of waiting (the timeout) the
flow doesn't jump to "send_my_own_BYE" and the BYE is not sent, it
stays waiting for ever.
If I force the UAS to send a BYE, it will jump correctly to
"respond_received_BYE" and respond with an OK, so the call ends correctly.
So, as an initial approach, I would only need to figure out why it
waits for the BYE for ever instead of sending it after the timeout
value (in this case, 5 seconds).
When we get this sorted out, I might have to go with 3PCC to avoid the
"failed calls" if we hit the timeout (but that is definitely secondary
at the moment).
Do you know why it can be that it waits for the BYE for ever?
I've checked my older scenarios where I was using the "timeout" and
"ontimeout" attributes and they look the same as above with one
negligible exception: I didn't use the "next" attribute, because it is
not necessary if the "send 200(BYE)" immediately follows the "recv BYE
within a timeout". In the example I've given, I've provided the "next"
attribute only in order to make it more illustrative through use of
self-explaining label names for both possible output branches of the
command.
So as I can see no typo in your command, before digging any deeper, the
first question has to be "what version of SIPp do you use"? The reason
is that
- the timeout and ontimeout attributes have been introduced as late as
in SIPp 3.2 if I'm not mistaken, while label naming (in addition to the
original numbering-only) has been introduced a bit earlier,
- SIPp silently ignores any unrecognized attributes of the commands.
So if you use 3.2 or newer SIPp, send me your complete scenario, leaving
the mailing list out, we'll eventually post the results of the
investigation to the mailing list.
I guess you've identified my copy-paste error and you send Cseq with BYE
in the 200 response to the received BYE (instead of my Cseq with MESSAGE
in the 200 to BYE).
-----------
In your second version, the 3PCC, I don't understand quite well how is
the use of the sendCmd and recvCmd or the concept "twin scenario". Can
you please give me more details on how that works?
Do I need to run several instances of sipp with different XMLs to
achieve the "twin scenario" or can I do it with all in one XML? Does
the -3pcc parameter need to be specified in the command?
I've described that in detail in the thread for which I've provided the
link to the mailing list archive, but briefly:
- yes, you need a separate scenario for the "twin" (timer) instance, as
each instance is a separate process bound to its own socket etc., and
you cannot ask the sipp binary to fork into two processes, each running
a different scenario. So your batch file for routine operation would
look like
sipp -p 5062 -sf 3pcc_timer.xml -bg -...
sipp -p 5060 -sf main.xml -...
But while debugging, run the timer instance without the -bg in its own
window, and start it before the main instance as well (because, quite
logically, UAS scenarios should be started before UAC scenarios if they
are intended to cooperate).
- the 3pcc_timer scenario should look like
<recvCmd/>
<pause/>
<sendCmd>
<![CDATA[
[last_Call-id:]
]]>
</sendCmd>
<pause milliseconds="32000"/>
Written this way, you would control the duration of the first pause (and
thus of those calls which the main scenario would actively terminate)
using the -d parameter of the sipp shell command used to start the timer
instance, while the second pause, whose duration is explicitly stated in
the scenario, is there to let the main instance finish the activity it
has to do after receiving the 3pcc command from the timer instance. I
had some problems with the timer instance (or even a particular call in
it, I don't remember exactly) terminating the twin call of the main
instance if it had nothing more to do itself. But the overall case may
have been slightly different from the one we discuss here - the timer
instance was most likely an UAC one and the main one was UAS, while in
the current case the roles are swapped. So you can try to remove the
last pause from the timer scenario, but I recommend you to do do so only
after debugging the basic idea.
If eventually sipp would complain that it cannot determine whether the
3pcc_timer is a UAC or a UAS scenario, put a fudge <recv
request="INVITE" optional="true"/> before the <recvCmd/>, that should
stop the complaints.
-----------
And some offtopic questions:
Anyting offtopic is a bad idea on any "spread-the-wisdom" platform like
this mailing list, because no one else can find such off-topic
information they'd be possibly interested in because the thread subject
doesn't give a clue about its presence. We have no "tags" or "keywords"
here to assist in search. Nevertheless, find my answers below the questions.
1) Can I put several "exec" statements inside one "nop"/"action"? Example:
<nop>
<action>
<exec play_pcap_audio="rec1.pcap"/>
<exec play_pcap_audio="rec2.pcap"/>
<exec play_pcap_audio="rec3.pcap"/>
</action>
</nop>
Or do they need to be each "exec" in a unique "action" ? Or maybe even
one "nop" + "action" per "exec"?
You can specify several actions within a single <action> tag, and I'd
say there may even safely be several <exec> actions. But several <exec
play_pcap_audio=.../> actions started in the same <action> make no
sense, so I have never tried it and so I don't know the intensity of the
resulting fireworks. A pcapplay starts replaying an RTP stream from a
single local socket to a single remote socket (as indicated by the
SDPs), so doing so several times in parallel is to no good even if SIPp
would somehow manage to do that.
2) If you play a pcap audio, does the execution stop until the play is
complete, or does it continue and therefor you have to add a "pause"
of the pcap length in order for the flow to not continue until the
play has finished? Example of a 10 second duration pcap:
<nop>
<action>
<exec play_pcap_audio="test.pcap"/>
</action>
</nop>
<pause milliseconds="10000"/>
As written in the documentation, <exec play_pcap_audio=.../> starts a
new internal thread and the scenario execution is not paused until the
replay action ends, so the timing must (and, more important, may) be
provided using additional means. So in your case, you may start
replaying a pcap simultaneously with sending the ACK, and the handling
of the received MESSAGEs will not interrupt the replay. However, an end
of the respective call does stop the replay if I remember right. This is
not the case if you <exec> an external command, though. Once you start
an external command, it lives its own life regardless what happens to
the call which has triggered it.
So chaining several play_pcap_audios is a doggy business if you also
need to use external timing of the call (through received BYE messages
or 3pcc commands). So better merge them into one in advance, which is a
separate topic.
3) In the non-3PCC I don't have the <pause/> parameter because the
duration is "hard-coded" to the timeout value when waiting for the
BYE, correct?
Exactly. The "timeout" attribute of <recv> is almost the same as the
"milliseconds" attribute of <pause>, except that the value of the
"timeout" attribute must (currently?) be a constant, so you cannot
calculate it dynamically during call run like you can with
"milliseconds". So if you ever need this, you have to use 3pcc and
deliver the required pause duration to the timer instance, using a
forged header (such as "P-my-pause-duration:") of the <sendCmd> payload
and regexp-based extraction of the value from that header in the
<recvCmd> in the timer scenario.
4) In the 3PCC version (although I don't quite understand how that
works yet) where should the <pause/> go to be able to modify the call
duration with the "-d" parameter in the command?
As already detailed above. Any <pause/> without the "milliseconds"
attribute in a scenario has a duration specified by the -d command line
parameter.
-----------
Thank you again for your help.
Best regards,
Joel.
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
