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