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