Hi Pavel & Norbert.
With your explanation I managed to achieve what I needed, using the
advice from both.
So I my scenario.xml I use the setdst parameter, and also I modify the
Call-IDs for the initial and last MESSAGE so they differ between
Server1 and Server2. It works perfectly.
If anyone else runs into this problem, my XML for the scenario looks
like this:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<scenario name="Test UAC">
<Global variables="regserver,regport,regtransport" />
<nop display="To Server1">
<action>
<setdest host="[$regserver]" port="[$regport]"
protocol="[$regtransport]"/>
</action>
</nop>
<send retrans="500">
<![CDATA[
...
MESSAGE sip...
CSeq: 20 MESSAGE
Call-ID: INITMSG-///[call_id]
...
]]>
</send>
<recv response="200">
</recv>
<nop display="To Server2">
<action>
<setdest host="[remote_ip]" port="[remote_port]"
protocol="[transport]"/>
</action>
</nop>
<send retrans="500">
<![CDATA[
...
INVITE sip...
Call-ID: [call_id]
CSeq: 1 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 sip...
Call-ID: [call_id]
CSeq: 1 ACK
...
]]>
</send>
<pause/>
<send retrans="500">
<![CDATA[
...
BYE sip...
Call-ID: [call_id]
CSeq: 2 BYE
...
]]>
</send>
<recv response="200" crlf="true">
</recv>
<!-- definition of the response time repartition table (unit is ms)
-->
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<!-- definition of the call length repartition table (unit is ms)
-->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
<nop display="To Server1">
<action>
<setdest host="[$regserver]" port="[$regport]"
protocol="[$regtransport]"/>
</action>
</nop>
<send retrans="500">
<![CDATA[
...
MESSAGE sip...
CSeq: 21 MESSAGE
Call-ID: ENDMSG-///[call_id]
...
]]>
</send>
<recv response="200">
</recv>
</scenario>
I can confirm this is working with the following cli command:
# sipp -s test IP_Server1:Port_Server1 -d 30000 -sf scenario.xml -inf
database.csv -trace_err -set regserver IP_Server2 -set regport
Port_Server2 -set regtransport udp
One last thing, do the CSeq look ok? Although it works, I want to make
sure they really are OK.
Thank you again.
Best regards,
Joel.
On Fri, Jan 22, 2016 at 6:03 AM, sindelka <sinde...@ttc.cz
<mailto:sinde...@ttc.cz>> wrote:
Hi Joel,
the simple answer is that what you are looking for is the <setdest
...> action:
<setdest host="[$host]" port="[$port]" protocol="[$transport]" />
Using this action, you can override the message destination
specified at the command line for each call (thread) separately,
and you can do that multiple times in the same call. SIPp neither
looks at the request-uri host part when deciding where to send a
message, nor cares from where a previous incoming message to the
thread has come when sending new requests (and I'm even not 100%
sure it cares when sending responses).
If you want extra comfort, you may use command line parameters to
specify the host, port, and maybe transport values of the two
hosts (Server1, Server2) as values of global variables, and refer
to those global values in the scenario when performing the setdest.
Now the complex part are some issues with the rest of your
scenario once you solve the issue of two remote servers for the
same "call".
See the explanation how SIPp uses Call-ID to identify a thread
(call) when executing a scenario at
http://sourceforge.net/p/sipp/mailman/message/34707334/ .
So the Call-ID, and also the From tag if you let SIPp generate it
automatically, will be the same in *both* the MESSAGEs (and also
the INVITE, ACK, BYE) sent by the same SIPp call. Not only that
this could cause trouble if the Server1 and Server2 send SIP
messages to each other and reuse the Call-IDs received from your
scenario in those messages; it may cause trouble if the recipient
of the MESSAGEs would only look at Call-ID and not other
identifiers, namely the From tag and Via branch (like e.g. SIPp
itself normally does in order to save the processing time). At
SIPp side, the risk of misunderstanding a received retransmission
of a 200 response to an older request as being a 200 response to a
newer request exists as well, but it actually requires things to
go terribly wrong to really become an issue.
Next, as RFC 3428 states clearly, nothing prevents a MESSAGE from
being sent as an in-dialog message, but itself it cannot initiate
a dialog establishment. So if the first one didn't belong to a
dialog previously established by some other request (such as
INVITE, REFER or SUBSCRIBE), the second one must also not contain
a To: tag (so you cannot use things like [last_To:]. If the two
MESSAGE requests actually are sent within a pre-existing dialog,
the incrementation of Cseq is another thing you have to care
about, because it should monotonously increment by one with each
new request within a dialog. So you'd have to have a separate
variable for cseq numbers you would be sending to one of the
servers, which you would use instead of the [cseq] automatic one
used for the other server, and increment it manually using an
action, or you would have to use the 3pcc to couple two scenarios.
Using the 3pcc would solve the Cseq trouble but the Call-ID one
would remain.
So if you encounter an issue with the Server1 confusing the newer
MESSAGE for a retransmission of an older one, and use of different
CSeq for each MESSAGE despite that they do not belong to a dialog
doesn't help it, you could make use of the following property of
SIPp (quoting from the documentation):
Note: [call_id] can be pre-pended with an arbitrary string using
'///'. Example: Call-ID: ABCDEFGHIJ///[call_id] - it will still
be recognized by SIPp as part of the same call.
If you would modify the call-id value in the MESSAGE requests you
send in some other way, the scenario would not recognize the
call-id value in the 200 responses to them and would treat it as
an unexpected messages. But doing this only makes sense if the
recipient of the MESSAGE requests is not another SIPp scenario.
Pavel
Dne 22.1.2016 v 4:16 Joel Serrano napsal(a):
Hello everybody,
I would like to know if it is possible to send msgs to different
endpoints with sipp.
Example:
Server1 SIPp UAC Server2
|(1) MESSAGE | |
|<---------------------| |
|(2) 200 | |
|--------------------->| |
| |(3) INVITE |
| |--------------------->|
| |(3) 100 (Optional) |
| |<---------------------|
| |(4) 180 (Optional) |
| |<---------------------|
| |(5) 200 |
| |<---------------------|
| |(6) ACK |
| |--------------------->|
| |(7) BYE |
| |--------------------->|
| |(8) 200 |
| |<---------------------|
|(9) MESSAGE | |
|<---------------------| |
|(10) 200 | |
|--------------------->| |
I tried hardcoding the Server1 IP and Port inside the
scenario.xml file, but for some reason it would send the msgs to
Server2 with the information inside the scenario.xml file. (I
assume that it is because Server2 is what was specified via
command line)
Is it possible to send different msg types to different servers
with one same scenario.xml file?
I have seen a similar scenario here:
http://sipp.sourceforge.net/doc/reference.html#3PCC
http://sipp.sourceforge.net/doc/reference.html#3PCC+Extended
I would like to confirm if you need to use 3pcc/3pcc-extended for
something like this or if there is way to do it with only one XML
file?
Maybe some override parameter for the destination server and port
that you can use inside the xml?
Thanks in advanced.
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
<mailto: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
<mailto:Sipp-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/sipp-users
