Hi Pavel,
* Sorry for the off-topic questions, you are right and they don't
belong to this thread (won't happen again).
* I tried removing the "next" from the <recv> inside non-3pcc
scenario, but still the same issue, it would wait for ever, so I have
moved on going toward the 3pcc way.
* Now that I understand how the 3PCC works, I have a "working"
scenario. In order for it to work, I had to change in the
3pcc_timer.xml two things, you were right that it requires a fudge
INVITE for it to start, otherwise it complains with: "Unable to
determine send mode of the tool (server, client)". The other change
was is the sendCmd, although it was receiving correctly the msg, it
was answering without a caller-id and that was making the main die
because it wouldn't recognize the msg without a caller-id. I used
-trace_msg to see this.
Before:
<sendCmd>
<![CDATA[
[last_Call-ID:]
]]>
</sendCmd>
After:
<sendCmd>
<![CDATA[
Call-ID: [call_id]
]]>
</sendCmd>
Solved that, the scenario works as described initially, but, I have
realized that what I wan't to achieve is not working 100%.
Going back to the explanation:
A-- main sends INVITE
B-- uas sends 100, 180, 183, OK
C-- main sends ACK
D-- main sendCmd to timer
E-- timer counts to X (defined in -d parameter). || main may receive a
MESSAGE or BYE during this timer and it will do what it has to do.
F-- timer reaches X, and sendCmd back to main
G-- main recvCmd and sends BYE to uas. (call ends).
If during the timer, main receives a (or multiple) MESSAGE(s) it will
responde OK, if it receives a BYE it will respond OK and end the call,
so we are good here.
My issue now, is that I need the timer to be reset on every MESSAGE
received.
So te be more specific, I have set the -d timer on the command to 1
minute:
# sipp -sf 3pcc_timer.xml -3pcc localhost:9001 -p 5061 -d 60000
-trace_err -trace_msg -trace_shortmsg
I run the main with:
# sipp -s test X.X.X.X:6061 -r 1 -l 1 -m 1 -i X.X.X.X -sf main.xml
-inf fields.csv -3pcc localhost:9001 -trace_err -trace_msg -trace_shortmsg
(I'm using latest version to avoid known issues: SIPp
v3.4.1-SCTP-PCAP-RTPSTREAM)
Right now, after 1 minute, the call will end, doesn't matter if it has
processed 0 MESSAGES or 100 MESSAGES. It will only end before the
minute if it receives a BYE from the uas. This is correct and I what I
requested in the first email.
Can I add something so the timer resets if it receives a MESSAGE? So
the idea would be for the call to end 1 minute after the _last_
MESSAGE was received or directly after 1 minute if no MESSAGE is
received at all.
I tried changing this:
[...]
<sendCmd>
<![CDATA[
[last_Call-ID:]
]]>
</sendCmd>
<label id="wait_for_BYE_or_MESSAGE"/>
<recv request="MESSAGE" optional="true"
next="respond_received_MESSAGE"/>
<recv request="BYE" optional="true" next="respond_received_BYE"/>
<recvCmd next="send_my_own_BYE"/>
<label id="respond_received_BYE"/>
<send next="end_of_call">
<![CDATA[
...
SIP/2.0 200 OK
...
]]>
</send>
<label id="respond_received_MESSAGE"/>
<send next="wait_for_BYE_or_MESSAGE">
<![CDATA[
...
SIP/2.0 200 OK
...
]]>
</send>
<label id="send_my_own_BYE"/>
[...]
to this:
[...]
<label id="wait_for_BYE_or_MESSAGE"/>
<sendCmd>
<![CDATA[
[last_Call-ID:]
]]>
</sendCmd>
<recv request="MESSAGE" optional="true"
next="respond_received_MESSAGE"/>
<recv request="BYE" optional="true" next="respond_received_BYE"/>
<recvCmd next="send_my_own_BYE"/>
<label id="respond_received_BYE"/>
<send next="end_of_call">
<![CDATA[
...
SIP/2.0 200 OK
...
]]>
</send>
<label id="respond_received_MESSAGE"/>
<send next="wait_for_BYE_or_MESSAGE">
<![CDATA[
...
SIP/2.0 200 OK
...
]]>
</send>
<label id="send_my_own_BYE"/>
[...]
NOTE: I have moved the <label id="wait_for_BYE_or_MESSAGE"/>before the
sendCmd, and that works partially: on every MESSAGE received, a new
sendCmd is executed and received by the timer, but it doesn't reset,
so when the very first timer ends, it sends back the msg and the main
ends the call even though there maybe 1 o 2 (or whatever) commands
still pending to be processed.
I don't know if I am explaining myself correctly. I didn't note this
in my first email because I have realized this was necessary as a
result of testing with the working 3PCC scenario. My bad, sorry.
Again thank you very much for your help and time.
Best regards,
Joel.
On Thu, Jan 21, 2016 at 3:39 AM, sindelka <sinde...@ttc.cz
<mailto:sinde...@ttc.cz>> wrote:
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.
