Awesome!
Understood perfectly.
Thank you very much Pavel.
Best regards,
Joel.
On Mon, Jan 25, 2016 at 1:46 AM, sindelka <sinde...@ttc.cz> wrote:
> Hi Joel,
>
> One last thing, do the CSeq look ok? Although it works, I want to make
> sure they really are OK.
>
>
> The CSeq value consists of a number and method name, so formally you've
> defined them OK.
>
> The relationship between the CSeq numbers (monotonous growth by 1) is only
> relevant within a given dialog, and the initial value of the number in a
> given dialog is arbitrary (CSeq numbers need not start from 1). So from the
> point of view of the recipient of the MESSAGEs, even same numbers in both
> requests, or a lower number in the newer request, would be fine because the
> Call-IDs are different.
>
> From the point of view of SIPp itself, all the requests it sends belong to
> the same "call", but as SIPp does not check the CSeq of responses, you are
> safe here as well.
>
> If you would eventually need to check that the contents of a response is
> correct, you would have to use a regexp action to compare the expected and
> received values (of the modified Call-ID and/or the CSeq), and mark the
> call as failed if they would not match.
>
> P.
>
>
> Dne 25.1.2016 v 8:18 Joel Serrano napsal(a):
>
> 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> 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/>
>> 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
>> 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
