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