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?
-----------
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?
-----------
And some offtopic 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"?
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"/>
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?
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?
-----------
Thank you again for your help.
Best regards,
Joel.
On Wed, Jan 20, 2016 at 3:35 AM, sindelka <sinde...@ttc.cz> wrote:
> Hi Joel,
>
> first: given your requirements, please forget about a "simple" scenario.
>
> second: can you re-confirm that the MESSAGE requests do come within the
> dialog initiated by the INVITE, i.e. that they are logically related to and
> only meaningful within the scope of that dialog (call), and thus they
> technically have the same Call-ID, local tag and remote tag like the
> 200(INVITE) and the ACK? Because this is critically important to choose the
> right way of handling them in the scenario. A wireshark trace (pcap) which
> contains the INVITE, 200(INVITE), ACK and MESSAGE, 200(MESSAGE) is fine if
> you are not sure about the answer.
>
> third: until recent, SIPp required that sending of any message (except the
> very first one in an UAC scenario) was triggered by exactly one of two
> possible events:
> - reception of a SIP or 3PCC message,
> - expiration of a "pause" timer.
>
> These two methods could not (and still cannot) be used in parallel, but
> there is a recently introduced set of "recv" attributes, called "timeout"
> and "ontimeout". Use of these attributes may be your way out for simple
> cases (with some drawbacks mentioned below).
>
> In your flow graph, you wrote "loop until I get a BYE" at one place, but
> "the BYE can be sent from the UAC or the UAS" on another. Taken strictly,
> these two things are contradictory. So what you actually want the scenario
> to do is the following: "start waiting for an incoming message for N
> seconds. While waiting, serve appropriately any message which possibly
> comes in, but unless it is a BYE, continue waiting; if those N seconds
> expire and none of the received messages was a BYE, send it yourself".
>
> If the MESSAGEs are actually not part of the dialog initiated by the
> INVITE sent by your UAC scenario, you can (and have to) serve them at other
> place than where you wait for the eventual BYE. Doing so requires to
> involve 3PCC as I've suggested at this link:
> http://sourceforge.net/p/sipp/mailman/message/34707334/ (except that in
> your case, you would handle MESSAGE instead of OPTIONS).
>
> In this case, where you only have to decide whether to send the BYE
> yourself or process an incoming one, you could say after the "send ACK":
>
> <recv request="BYE" next="respond_received_BYE" timeout="10000"
> ontimeout="send_my_own_BYE"/>
>
>
> But as said, use of timeout and ontimeout would not save you from using
> the 3PCC as use of 3PCC would be necessary to handle incoming out-of-dialog
> MESSAGEs, so you may as well use 3PCC for timing the own BYE instead of the
> timeout and ontimeout attributes.
>
> If the MESSAGEs are really part of the dialog as you wrote, you wouldn't
> need to use 3PCC to handle them, but without 3PCC you would be unable to
> schedule your own BYE to a fixed time after sending the ACK regardless the
> number of received MESSAGEs. So if you can and want to avoid 3PCC, you may
> use:
>
> ...INVITE, 100, 180, 200 ...
>
> <send>
> ...
> ACK...
> ...
> </send>
>
> <label id="wait_for_BYE_or_MESSAGE"/>
>
> <recv request="MESSAGE" optional="true" next="respond_received_MESSAGE"/>
>
> <recv request="BYE" next="respond_received_BYE" timeout="5000"
> ontimeout="send_my_own_BYE"/>
>
>
>
> <label id="respond_received_BYE"/>
>
> <send next="end_of_call">
> ...
> 200...
> ...
> Cseq: [cseq] MESSAGE
> ...
> </send>
>
>
>
> <label id="respond_received_MESSAGE"/>
>
> <send next="wait_for_BYE_or_MESSAGE">
> ...
> 200...
> ...
> Cseq: [cseq] MESSAGE
> ...
> </send>
>
>
>
> <label id=""send_my_own_BYE"/>
>
> <send...
> ...
> BYE...
> ...
> </send>
>
> <recv response="200"/>
>
>
>
> <label id="end_of_call"/>
>
>
> This way, you would send your own BYE if no message would have been
> received during 5 seconds since you've sent your last one (ACK or
> 200(MESSAGE)).
>
> If you need a fixed time between the ACK and your own BYE, regardless the
> number of MESSAGEs to come in the meantime, you would need a 3PCC twin
> scenario which would receive a command from the basic one and send its own
> command back after a pause. The basic scenario would then look the
> following way:
>
> ...INVITE, 100, 180, 200 ...
>
> <send>
> ...
> ACK...
> ...
> </send>
>
> <sendCmd>
> ...
> [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">
> ...
> 200...
> ...
> Cseq: [cseq] MESSAGE
> ...
> </send>
>
>
>
> <label id="respond_received_MESSAGE"/>
>
> <send next="wait_for_BYE_or_MESSAGE">
> ...
> 200...
> ...
> Cseq: [cseq] MESSAGE
> ...
> </send>
>
>
>
> <label id=""send_my_own_BYE"/>
>
> <send...
> ...
> BYE...
> ...
> </send>
>
> <recv response="200"/>
>
> <label id="end_of_call"/>
>
>
>
> Use of timeout and ontimeout in your scenario affects call statistics,
> because a call in which a timeout has expired is counted as a failed one.
> So if this is an issue for you, you have to use 3PCC. For me it wasn't.
>
> I don't exclude I don't remember the details of use of timeout and
> ontimeout attributes properly, so if it doesn't work for you, come back to
> me, I'll dig in my old scenarios.
>
> Also feel free to ask about other things, I may have been unclear
> somewhere.
>
> Pavel
>
> Dne 20.1.2016 v 3:53 Joel Serrano napsal(a):
>
> Hi everybody,
>
> I'm new to the list. I'm trying to create a simple scenario with SIPp but
> I'm running into the following problem:
>
> During an active call, the UAC might receive a MESSAGE request from the
> UAS and it has to answer with a 200 OK to that MESSAGE.
>
> This can happen X times.
>
> Also, it is possible that the BYE comes from the UAS, we have to consider
> that option too.
>
> With my current config, I get a message when the script starts that says
> "<recv> before <send> sequence without a mandatory message. Please remove
> one 'optional=true'..."
>
>
> SIPp UAC Remote UAS
> |(1) INVITE |
> |--------------------->|
> |(2) 100 (Optional) |
> |<---------------------|
> |(3) 180 (Optional) |
> |<---------------------|
> |(4) 183 (Optional) |
> |<---------------------|
> |(5) 200 |
> |<---------------------|
> |(6) ACK |
> |--------------------->|
> | |
> |(7) MESSAGE (Optional)| -----+
> |<---------------------| |
> | | +---- Loop until I get a BYE
> |(8) 200 (Optional) | |
> |--------------------->| -----+
> | |
> |(7) BYE | -----+
> |<-------------------->| |
> | | +---- The BYE can be sent from the UAC
> or the UAS.
> |(9) 200 | |
> |<-------------------->| -----+
>
>
>
> My scenario.xml is the as follows:
>
>
> <scenario name="Test UAC">
> <send retrans="500">
> <![CDATA[
> INVITE [...]
> ]]>
> </send>
>
> <recv response="100" optional="true">
> </recv>
>
> <recv response="180" optional="true">
> </recv>
>
> <recv response="183" optional="true">
> </recv>
>
> <recv response="200" rtd="true">
> </recv>
>
> <send>
> <![CDATA[
> ACK [...]
> ]]>
> </send>
>
> <recv request="MESSAGE" optional="true">
> </recv>
>
> <send>
> <![CDATA[
> SIP/2.0 200 OK
> [last_Via:]
> [last_From:]
> [last_To:];tag=[call_number]
> [last_Call-ID:]
> [last_CSeq:]
> Content-Length: 0
> ]]>
> </send>
>
> <pause/>
>
> <send retrans="500">
> <![CDATA[
> BYE [...]
> ]]>
> </send>
>
> <recv response="200" crlf="true">
> </recv>
>
> <ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
>
> <CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
>
> </scenario>
>
> I run the script with:
>
> sipp -d 20000 -s *52 X.X.X.X:5060 -r 1 -l 1 -m 1 -trace_msg -trace_err -i
> public_ip -sf scenario.xml -inf database.csv
>
>
> I have read the conditional branching documentation:
>
> http://sipp.sourceforge.net/doc/reference.html#branching
>
> I have also found this previous post in the list with a similar problem:
>
> http://sourceforge.net/p/sipp/mailman/message/9014449/
>
>
> So for the MESSAGE I think I have to play with the next and label
> parameters, but I have tried several combinations and I can't get it to
> work.
>
> For the BYE being able to come from UAC if timeout is reached or from UAS
> before the timeout is reached is another problem I don't know how to handle.
>
> If there is any more documentation I have missed that can help me figure
> this out I would be more than welcome to read it.
>
> All help/comments are appreciated.
>
>
> Thanks in advance.
>
> 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
> listSipp-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/sipp-users
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
------------------------------------------------------------------------------
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
