Menu
▾
▴
sipp-commits
|
From: <dve...@us...> - 2009-10-23 16:17:57
|
Revision: 590
http://sipp.svn.sourceforge.net/sipp/?rev=590&view=rev
Author: dverbeir
Date: 2009-10-23 16:17:50 +0000 (Fri, 23 Oct 2009)
Log Message:
-----------
Doc: Updated ims_bench doc to reflect support for TCP mode and a few minor other doc changes.
Modified Paths:
--------------
doc/trunk/src/documentation/content/xdocs/ims_bench/images/ims_bench_sys_overview.jpg
doc/trunk/src/documentation/content/xdocs/ims_bench/index.xml
doc/trunk/src/documentation/content/xdocs/ims_bench/intro.xml
doc/trunk/src/documentation/content/xdocs/ims_bench/reference.xml
Modified: doc/trunk/src/documentation/content/xdocs/ims_bench/images/ims_bench_sys_overview.jpg
===================================================================
(Binary files differ)
Modified: doc/trunk/src/documentation/content/xdocs/ims_bench/index.xml
===================================================================
--- doc/trunk/src/documentation/content/xdocs/ims_bench/index.xml 2009-08-04 14:23:48 UTC (rev 589)
+++ doc/trunk/src/documentation/content/xdocs/ims_bench/index.xml 2009-10-23 16:17:50 UTC (rev 590)
@@ -26,6 +26,15 @@
<p>To learn how to use IMS Bench SIPp and how to create scenarios that take advantage of
the features it brings, please refer to the <link href="reference.html">Reference documentation</link>.</p>
+ <p><b>New features in SVN revision 587 (28-Jul-2009):</b></p>
+ <ul>
+ <li>Support for SIP traffic over TCP. SIP traffic between each SIPp
+ instance and the System Under Test goes over a pair of TCP sockets.</li>
+ <li>Support in the <i>ims_bench</i> Perl script, for scenarios without
+ pre-registration. The script can now generate user data files suitable
+ for tests without a pre-registration phase (e.g. for Application Server
+ testing).</li>
+ </ul>
</body>
</document>
Modified: doc/trunk/src/documentation/content/xdocs/ims_bench/intro.xml
===================================================================
--- doc/trunk/src/documentation/content/xdocs/ims_bench/intro.xml 2009-08-04 14:23:48 UTC (rev 589)
+++ doc/trunk/src/documentation/content/xdocs/ims_bench/intro.xml 2009-10-23 16:17:50 UTC (rev 590)
@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
+<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.2//EN" "http://apache.org/forrest/dtd/document-v12.dtd">
<document>
<header>
@@ -165,7 +165,7 @@
<p>The current implementation does not support IPSec. This means that the connection
between the Test Systems and the P-CSCF component of the SUT is using unencrypted
- SIP messages over UDP.
+ SIP messages over UDP or TCP.
One should be aware that IPSec processing is likely to have a high performance impact
on the P-CSCF component. The current implementation is therefore
not suitable for evaluating the performance of a P-CSCF as it would normally be
@@ -183,7 +183,7 @@
<p>The following are the known areas that have been intentionally left out:</p>
<ul>
- <li> Other transports than UDP (TCP, TLS) (known to be broken)</li>
+ <li> Other transports than UDP and TCP (TLS)</li>
<li> IPv6 support (known to be broken)</li>
<li> 3PCC operation (presumably broken)</li>
<li> PCAP Play (not tested)</li>
@@ -205,11 +205,15 @@
is loaded with the full set of scenarios. Originating scenario attempts are started
according to a statistical distribution, and the scenario to execute is itself selected
at random, as well as the users involved in the scenario. Each SIPp instance has its static
- set of users that it emulates. Each user is assigned a unique IP address + UDP port
+ set of users that it emulates.</p>
+ <p>In UDP mode, each user is assigned a unique IP address + UDP port
combination. By default, each SIPp instance has a single IP address and assigns different
UDP ports to the users, but a compile time option and corresponding configuration allow
supporting many IP addresses in a single SIPp instance in order to make the setup more
realistic and avoid that traffic be blocked by overflow attack protections at the SUT.</p>
+ <p>In TCP mode, each SIPp instance has a single IP address and creates one pair of TCP sockets to
+ the SUT. The first socket is used for server side scenarios, and the second one is used for client
+ side scenarios. All users emulated by the SIPp instance share this single pair of TCP sockets.</p>
<p>The manager is responsible for
<ol>
@@ -304,18 +308,29 @@
scenarios to remain very simple as they don't have to accommodate multiple possible
paths and outcomes.</td></tr>
- <tr><td>One UDP port per User</td>
+ <tr><td>One UDP port per User (in UDP mode)</td>
<td>In order to be as realistic as possible, each user is associated with its own
IP address + UDP port combination. Default operation uses a single IP address.
One can then run multiple SIPp instances on the same system, each running on a
different (real or virtual) IP address.</td></tr>
- <tr><td>Multiple IP addresses</td>
+ <tr><td>Multiple IP addresses (in UDP mode)</td>
<td>Optionally, to make it even more realistic or to optimize performance of the
test system (Linux IP stack may scale better with the number of IP addresses than
with the number of ports), it is also possible to distribute the users onto many
IP addresses within the same SIPp instance.</td></tr>
+ <tr><td>One pair of TCP sockets per SIPp instance (in TCP mode)</td>
+ <td>Since each SIPp instance can simultaneously execute multiple scenarios, possibly
+ with both the client side user and the server side user represented by the same SIPp
+ instance, the incoming SIP traffic must be properly routed to the relevant emulated
+ user. In TCP mode, this is efficiently achieved by means of a single pair of TCP
+ sockets per SIPp instance. The first socket carries SIP traffic for server side
+ scenarios, and the second one is used for client side scenarios. All users
+ represented by the SIPp instance share this single pair of TCP sockets.
+ As in UDP mode, multiple SIPp instances can run on the same system, each one
+ assigned to a different (real or virtual) IP address.</td></tr>
+
<tr><td>Poisson distribution for scenario attempts</td>
<td>New scenario attempts can be initiated following a statistical Poisson
distribution; the user reservation procedure is scheduled so that the actual SIP
Modified: doc/trunk/src/documentation/content/xdocs/ims_bench/reference.xml
===================================================================
--- doc/trunk/src/documentation/content/xdocs/ims_bench/reference.xml 2009-08-04 14:23:48 UTC (rev 589)
+++ doc/trunk/src/documentation/content/xdocs/ims_bench/reference.xml 2009-10-23 16:17:50 UTC (rev 590)
@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
+<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN" "http://forrest.apache.org/dtd/document-v20.dtd">
<document>
<header>
@@ -74,11 +74,32 @@
Timer frequency (1000 HZ) --->
General setup --->
() Local version - append to kernel release <- set your own kernel prefix
+</source>
+ <p>Then, rebuild your kernel and point your /etc/grub.conf to it.
+ <b>Wait! ...</b> Before you rebuild your kernel, you may want to include the
+ change for the next item below and only rebuild once!</p>
+
+<source>
make dep bzImage modules modules_install install
-
- (modify /etc/grub.conf to point to this new kernel)</source></li>
+</source></li>
<li>
+ <p>When a SIPp load-generator instance must represent a large number of users
+ (beyond a few 10K users), and when it is configured to use a different IP + UDP
+ port combination for each user, the system may exhibit poor performance
+ (very long delay at startup, high CPU utilisation) making it unsuitable as a
+ Test System. This may be due to the default size of internal hash tables within
+ the IP stack of the Linux kernel.</p>
+ <p>In order to avoid this problem, you can change the UDP_HTABLE_SIZE constant and
+ rebuild your kernel (see above).
+ At time of writing, this setting was not an exposed kernel parameter and must
+ be changed directly in the source code, at
+ /usr/src/redhat/BUILD/kernel-2.6.18/linux-2.6.18.i686/include/net/udp.h
+ (assuming sources as in above example). The constant can be set to 32768.</p>
+ <p>This only applies to UDP mode. This parameter has no (positive) impact on
+ TCP mode performance.</p>
+ </li>
+ <li>
<p>In order for the timing precision to remain when measuring a time difference
between two different physical systems, all systems that constitute the Test
System should be synchronized with a better precision than what the standard NTP
@@ -439,7 +460,7 @@
<p>Here is an example of the command to issue on one of the test systems to start one
of the SIPp instances, assuming that the manager is at 192.168.1.1, that the instance
will use 192.168.1.20 and that the SUT is at 192.168.1.100 and listens for SIP traffic
- on port 5060:
+ on UDP port 5060:
<source>./sipp -id 1 -i 192.168.1.20 -user_inf ./ims_users_1.inf
-rmctrl 192.168.1.1:5000 192.168.1.100:5060
-trace_err -trace_cpumem -trace_scen -trace_retrans</source></p>
@@ -587,7 +608,7 @@
Client:
<source>
Call-rate(length) Port Total-time Total-calls Remote-host
- <i>[Desactivated]</i>(0 ms)/1.000s 5060 10.00 s 0 <i><b><sut_address></b></i>(UDP)
+ <i>[Desactivated]</i>(0 ms)/1.000s 5060 10.00 s 0 <i><b><sut_address></b></i>(<i><b><UDP or TCP></b></i>)
0 new calls during 1.000 s period 1 ms scheduler resolution
0 calls (limit 0) Peak was 0 calls, after 0 s
0 Running, 0 Paused, 0 Woken up, 0 Sync
@@ -597,7 +618,7 @@
Server:
<source>
Port Total-time Total-calls Transport
- 5060 695.00 s 0 UDP
+ 5060 695.00 s 0 <i><b><UDP or TCP></b></i>
0 new calls during 1.000 s period 1 ms scheduler resolution
0 calls Peak was 0 calls, after 0 s
@@ -889,7 +910,7 @@
<!-- ********************************************* -->
<!-- ********************************************* -->
<anchor id="multi_scenario" /><section><title>Multi-scenario mode</title>
- <p><comment>NEW!</comment>A key feature in IMS Bench SIPp is its support for
+ <p>A key feature in IMS Bench SIPp is its support for
multiple scenarios within a single SIPp instance. Multiple scenarios
are uploaded by the manager to the SIPp instance(s) and each call is
executing one of the scenarios.</p>
@@ -1015,12 +1036,17 @@
scenario creates.</li>
</ol>
- <p>In addition, IMS Bench SIPp will assign a different combination
+ <p>In UDP mode, IMS Bench SIPp will assign a different combination
of IP address and UDP port number to each user that it represents.
- This makes the traffic more realistic. Depending on the transport
- mode used, it will distribute the users on the configured IP addresses
+ This makes the traffic more realistic. It will distribute the users
+ on one IP address or optionally, on several configured IP addresses,
and then on the available ports on that address
(see also <link href="#transports">SIPp Transport Modes</link>).</p>
+ <p>In TCP mode, each IMS Bench SIPp instance has a single IP address
+ and creates one pair of TCP sockets to the SUT. The first socket is
+ used for server side scenarios, and the second one is used for client
+ side scenarios. All users represented by the SIPp instance share this
+ single pair of TCP sockets.</p>
</section>
<!-- ********************************************* -->
@@ -1048,7 +1074,7 @@
option) and that can be checked against a specified maximum value are
called "metrics".</p>
- <p>These metrics are defined within the scenario file in a <comment>new</comment>
+ <p>These metrics are defined within the scenario file in a new
<info> section, as in the following example:</p>
<source><![CDATA[
<info>
@@ -1107,7 +1133,7 @@
of the manager or when the manager exits.</p>
<p>The 'q' key is however still handled in the SIPp instance as well. If you press it,
SIPp will stop placing new calls and will wait until all current calls go to their end.
- During this phase, <comment>(NEW!)</comment> SIPp will regularly look at all calls that are
+ During this phase, SIPp will regularly look at all calls that are
executing a pause command and will shorten the duration of this pause so as to
speed up the exit while still trying to complete all calls in their normal flow.
SIPp will then exit.</p>
@@ -1817,7 +1843,7 @@
<tr>
<td><strong>[%<<i>param</i>>]</strong></td>
<td>-</td>
- <td><comment>NEW!</comment>Use to inject a global generic parameters
+ <td>Use to inject a global generic parameters
(see <code>-key</code> command line option and manager
<a href="#scen_params">scenario parameters</a>).<br/>
Example: <code><pause poisson="true" mean="%RingTime"/></code></td>
@@ -1998,7 +2024,7 @@
by using the content of the variables for <a href="#branching">conditional
branching</a>.
- <p><comment>NEW!</comment>With the introduction by IMS
+ <p>With the introduction by IMS
Bench SIPp of the concept of users, it is now also possible
to store results of regular expression matching into
user variables. These variables can then be used just
@@ -2250,7 +2276,7 @@
<!-- ********************************************* -->
<anchor id="inffile" /><section><title>Injecting values from an external CSV during calls</title>
- <p><comment>NEW!</comment>In addition to the standard value injection mechanism provided by SIPp,
+ <p>In addition to the standard value injection mechanism provided by SIPp,
IMS Bench SIPp supports a new, more user-centric mode of operation.
This is triggered by the use of the <code>-user_inf</code> command line
parameter. For the standard SIPp mode of operation, please refer to the
@@ -2258,7 +2284,7 @@
<p>When the <code>-user_inf</code> command line parameter is used
to specify a user data file, corresponding user entities are created
- within SIPp and are each assigned a different IP and port combination.
+ within SIPp and, in UDP mode, are each assigned a different IP and port combination.
Data from the specified file is also loaded into user specific data
fields which can then be used within the scenarios.</p>
@@ -2289,15 +2315,18 @@
</source>
<p>In this example, all users are initially in pool 0 (for example, the pool
of not registered users). The meaning of the remaining fields
- depends of what the scenario files do with them but in case of
+ depends on what the scenario files do with them but in case of
the provided IMS Benchmark scenarios, the user data fields have
- the following meaning:</p>
+ the following meaning, and can be specified in the associated entries in
+ the <i>Users provisioning</i> menu of the <i>ims_bench</i> tool:</p>
<ul>
- <li>username part of the public identity of the user</li>
- <li>domain part of the public identity of the user</li>
- <li>authentication username</li>
- <li>authentication realm</li>
- <li>authentication password (AKA Key value)</li>
+ <li>username part of the public identity of the user: <i>PublicIdentityFormat</i></li>
+ <li>domain part of the public identity of the user: <i>UserDomain</i>
+ <br/>or IP address of the IMS Bench SIPp instance: <i>when DontPreRegisterButUseSippIP = 1</i>
+ (in order to execute scenarios without the need for a pre-registration phase)</li>
+ <li>authentication username: <i>PrivateIdentityFormat</i></li>
+ <li>authentication realm: <i>UserRealm</i></li>
+ <li>authentication password (AKA Key value): <i>UserPasswordFormat</i></li>
<li>example extra data - not used</li>
</ul>
@@ -2322,7 +2351,7 @@
it goes to the label only if variable [$m] is set. This allows you
to look for some string in a received packet and alter the
flow either on that or a later part of the script.</p>
- <warning>If you add special cases at the end, don’t forget to put
+ <warning>If you add special cases at the end, don't forget to put
a label at the real end and jump to it at the end of the normal flow.</warning>
<p><strong>Example:</strong></p>
<p>The following example corresponds to the embedded '<a href="#scenario_branch">branchc</a>' (client side) scenario.
@@ -2359,7 +2388,7 @@
take the challenge into account in order to compute a response in a
next message.</p>
- <p><comment>NEW!</comment> In addition, the <code>auth_assign_to</code> argument
+ <p>In addition, the <code>auth_assign_to</code> argument
can specify, in the same <recv> command as the one where auth="true" is
specified, a user or call variable into which to store the challenge for
later usage (in a subsequent call and possibly for a different scenario
@@ -2437,9 +2466,13 @@
<section><title>Various Topics</title>
<anchor id="transports" /><section><title>SIPp Transport Modes</title>
- <p>From the transport modes supported by the standard SIPp, only UDP transport is
- currently supported by IMS Bench SIPp. It however adds a few options in the way UDP
- is used, making it more closely resemble a set of separate client devices.</p>
+ <p>From the transport modes supported by the standard SIPp, IMS Bench SIPp currently
+ supports:</p>
+ <ul>
+ <li>UDP transport, on top of which it adds a few options (see below) making
+ it more closely resemble a set of separate client devices</li>
+ <li>TCP transport</li>
+ </ul>
<section><title>UDP one socket per user</title>
<p>In UDP "one socket per user" mode, each user that a
SIPp instance represents corresponds to a separate UDP port that SIPp uses
@@ -2447,12 +2480,18 @@
<p>All users however share a single IP address.</p>
</section>
<section><title>UDP multiple IP addresses</title>
- <p>In UDP multiple IP addresses mode, SIPp distributes the users it
+ <p>In UDP "multiple IP addresses" mode, SIPp distributes the users it
represents among a set of configured IP addresses. In case there are more
users than IP addresses, different UDP ports are used for users that share
the same IP address, thereby giving a unique IP adddress / UDP port combination
to each user.</p>
</section>
+ <section><title>TCP one pair of sockets per SIPp instance</title>
+ <p>In TCP mode, each SIPp instance has a single IP address and creates one pair
+ of TCP sockets to the SUT. The first socket carries SIP traffic for server side
+ scenarios, and the second one is used for client side scenarios.</p>
+ <p>All users represented by the SIPp instance share this single pair of TCP sockets.</p>
+ </section>
</section> <!-- Tansport Modes -->
<section><title>Running SIPp in background</title>
@@ -2504,8 +2543,7 @@
by pressing 3, 6, 7, 8 or 9. You can also save the values
in a CSV file using the -trace_stat option (see below).</p>
- <p><comment>NEW!</comment>IMS Bench SIPp extends this mechanism
- in several ways:</p>
+ <p>IMS Bench SIPp extends this mechanism in several ways:</p>
<p>As most IMS Bench scenarios require measuring several
delays, the start_rtd and rtd attributes have been extended to
@@ -2610,9 +2648,9 @@
Number of unexpected specific messages received for new Call-ID.
The message has been automatically answered by a 200 OK
Currently, implemented for 'PING' message only.</li>
- <li>Retransmissions:<comment> not documented </comment>Number of UDP retransmission.</li>
- <li>Retransmissions2:<comment> NEW </comment>Stat collected at the server side are added to the client side.</li>
- <li>FailedTimeoutInRtdOp:<comment> NEW </comment>Number of calls that exceed the defined <a href="#Time+Metrics">metrics</a> or for which the timeout specified in an rtd evaluation action was exceeded.</li>
+ <li>Retransmissions: Number of UDP retransmission.</li>
+ <li>Retransmissions2: Stat collected at the server side are added to the client side.</li>
+ <li>FailedTimeoutInRtdOp: Number of calls that exceed the defined <a href="#Time+Metrics">metrics</a> or for which the timeout specified in an rtd evaluation action was exceeded.</li>
</ul>
<p>In addition, two other statistics are gathered:</p>
<ul><li>ResponseTime (see previous section)</li>
@@ -2622,6 +2660,7 @@
and <a href="#calllengthrep">CallLengthRepartition</a> commands in the scenario.</p>
</section> <!-- Counters -->
</section> <!-- Statistics -->
+
<section><title>Error handling</title>
<p>SIPp has advanced features to handle errors and unexpected events.
They are detailed in the following sections.</p>
@@ -2649,6 +2688,7 @@
be simply dropped.</li>
</ul>
</section>
+
<section><title>Retransmissions (UDP only)</title>
<p>A retransmission mechanism exists in UDP transport mode.
To activate the retransmission mechanism, the "send" command must include
@@ -2665,6 +2705,7 @@
using the <code>-nr</code> command line option to globally disable the
retransmission mechanism.</p>
</section>
+
<section><title>Log files (error + log + screen)</title>
<p>There are several ways to trace what is going on during your SIPp runs.</p>
<ul>
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <xsi...@us...> - 2010-10-15 11:15:59
|
Revision: 592
http://sipp.svn.sourceforge.net/sipp/?rev=592&view=rev
Author: xsimonar
Date: 2010-10-15 11:15:53 +0000 (Fri, 15 Oct 2010)
Log Message:
-----------
Doc: Update ims_bench doc to reflect support of Call Forwarding scenarios and other new features
Modified Paths:
--------------
doc/trunk/src/documentation/content/xdocs/ims_bench/index.xml
doc/trunk/src/documentation/content/xdocs/ims_bench/reference.xml
Modified: doc/trunk/src/documentation/content/xdocs/ims_bench/index.xml
===================================================================
--- doc/trunk/src/documentation/content/xdocs/ims_bench/index.xml 2010-10-15 11:04:09 UTC (rev 591)
+++ doc/trunk/src/documentation/content/xdocs/ims_bench/index.xml 2010-10-15 11:15:53 UTC (rev 592)
@@ -26,6 +26,28 @@
<p>To learn how to use IMS Bench SIPp and how to create scenarios that take advantage of
the features it brings, please refer to the <link href="reference.html">Reference documentation</link>.</p>
+ <p><b>New features and Fixes in SVN revision 591 (15-Oct-2010):</b></p>
+ <ul>
+ <li>Support for automatic re-registration of the users. The users can now be re-registerd for instance after 1/2 hour, using new <start_scen> action in registration scenarios .</li>
+ <li>Support for Call Forwarding and VoiceMail scenarios. See new scenarios sut_fwd_A.xml, sut_fwd_B.xml and sut_fwd_C.xml</li>
+ <li>Support for UDP Keep-Alive. See <a href="reference.html#KeepAlive">Keep Alive</a></li>
+ <li>Support for generating load to multiple SUT by setting <multiple_sut> parameter to 1 within the configuration section of manager.xml;</li>
+ <li>Support gcc-4.4 C++ stdlib changes, which changes the prototypes for many of the str*() family of functions.</li>
+
+ <li>(Fix) Changed the way sipp react to 4xx messages in reply to INVITES. Content of ACK message is now based on the INVITE content, not hard-coded anymore.
+</li>
+ <li>(Fix) Fixed a race condition in CManager:CheckTimeEvents which could in rare cases cause some statistics to be be incorrectly set to 0.</li>
+ <li>(Fix) Fixed a segmentation fault when the last run of a bench is a run with a max_calls condition, and the manager is not run in full automated mode (-e switch)</li>
+ <li>(Fix) Increased maximum number of RTD from 5 to 20 </li>
+ <li>(Fix) The test was stopped when no scenario was <i>completed</i> in the step, with a message "no scenario <i>attempted</i> in this step". The test is now stopped only if the number of attempted scenario in the step is zero. A test with attempted scenario but no successfull ones in a step would not stop for this reason (if there are failed ones, it would stop because of over-ihs). This helps with tests with small steps and very long scenarios (long call duractions for instance).
+</li> </ul>
+
+ <p><b>New features and Fixes in SVN revision 589 (4-Aug-2009):</b></p>
+ <ul>
+ <li>Increased system limits (e.g. number of SIPP test systems)</li>
+ <li>Cleaned up lots of warning related to const char*. Also made parts of manager code more readable.</li>
+ <li>(Fix) Fixed max_calls condition when used in other run than first one or in multiple runs</li>
+ </ul>
<p><b>New features in SVN revision 587 (28-Jul-2009):</b></p>
<ul>
<li>Support for SIP traffic over TCP. SIP traffic between each SIPp
Modified: doc/trunk/src/documentation/content/xdocs/ims_bench/reference.xml
===================================================================
--- doc/trunk/src/documentation/content/xdocs/ims_bench/reference.xml 2010-10-15 11:04:09 UTC (rev 591)
+++ doc/trunk/src/documentation/content/xdocs/ims_bench/reference.xml 2010-10-15 11:15:53 UTC (rev 592)
@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
+<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN" "http://forrest.apache.org/dtd/document-v20.dtd">
<document>
<header>
@@ -301,6 +301,16 @@
<tr><td><b>max_time_offset</b></td>
<td>Maximum offest (in microseconds) allowed between each TS
and the manager (0 = not checked)</td></tr>
+ <tr><td><b>multiple_sut</b></td>
+ <td>Support for generating load from one manager to multiple SUT.
+ For instance, to have a manager supporting 8 sipp connected to 2 SUT
+ you need to have 4 SIPP connected to the first SUT and 4 to the other SUT.
+ By default (multiple_sut = 0), a sipp user is calling a user from a sipp with
+ a groupid different from its groupid (the groupid is specified using -groupid sipp
+ command line). So, it might call one of the 4 SIPP connected to the other SUT.
+ If multiple_sut parameter is set then a sipp user will be calling a user from
+ a sipp with the the SAME groupid. So, if all SIPP connected to the same SUT share
+ the same groupid, then they will only call SIPP connected to the same SUT.</td></tr>
</table><br/>
</li>
<li><anchor id="scen_params" /><strong>Scenario Parameters</strong>
@@ -1291,14 +1301,14 @@
<tr>
<td></td>
<td>rrs</td>
- <td><strong>R</strong>ecord <strong>R</strong>oute <strong>S</strong>et. if this attribute is set to "true",
+ <td><strong>R</strong>ecord <strong>R</strong>oute <strong>S</strong>et. If this attribute is set to "true",
then the "Record-Route:" header of the message received is stored and can be recalled using the <strong>[routes]</strong> keyword.</td>
<td><code><recv response="100" rrs="true"></code>.</td>
</tr>
<tr>
<td></td>
<td>auth</td>
- <td><a href="#authentication">Authentication</a>. if this attribute is set to "true",
+ <td><a href="#authentication">Authentication</a>. If this attribute is set to "true",
then the "Proxy-Authenticate:" header of the message received is stored and is used to build
the <strong>[authentication]</strong> keyword.</td>
<td><code><recv response="407" auth="true"></code>.</td>
@@ -1565,7 +1575,11 @@
<td>type</td>
<td>
The command sends a (non-SIP) message to the partner SIPp instance. In case no partner has been assigned yet to the scenario,
- a partner SIPp instance is selected at random (uniform) before sending the message.
+ a partner SIPp instance is selected at random (uniform) before sending the message (except if partner_id parameter is specified,
+ in which case the sipp instance specified by the partner_id parameter is choosen - this partner_id parameter is usefull when sending
+ call to a voicemail or a C party in a call forwarding scenario for instance).
+ Username and domain parameters can be specified in the req_user command to select a well-defined user (typically used together
+ with the partner_id parameter in a voicemail or a call-forwarding scenario).
</td>
<td>
<source>
@@ -1574,7 +1588,17 @@
<param name="from_uri" value="[field0]@[field1]"/>
<param name="call_id" value="[call_id]"/>
</sendRmt>
+</source> or (in case of Voicemail or call forwarding)
+<source>
+<sendRmt type="req_user">
+ <param name="scenario" value="ims_uas"/>
+ <param name="from_uri" value="[field0]@[field1]"/>
+ <param name="user_name" value="[field5]"/>
+ <param name="user_domain" value="[field6]"/>
+ <param name="partner_id" value="[field7]"/>
+</sendRmt>
</source><br/>
+
</td>
</tr>
<tr>
@@ -2116,11 +2140,32 @@
file where the actual SIP scenario really starts.</td>
<td><source><exec int_cmd="set_start_time"/></source></td></tr>
<tr><td><code>set_target_ip</code></td>
- <td>Forces the target IP to the one of the partner SIPp (To be used in
- "loop-back" configuration, SIPp against SIPp without any SUT in
- between).</td>
+ <td>If used w/o parameter, forces the target IP to the one of the partner SIPp
+ (To be used in "loop-back" configuration, SIPp against SIPp without any SUT in
+ between).
+ If used with a parameter, forces the target IP to the parametrer specified
+ (Parameter can be obtained through a regexp parsing the Via header for instance)
+ </td>
<td>
- <source><exec int_cmd="set_target_ip"/></source></td></tr>
+ <source><exec int_cmd="set_target_ip"/></source>
+ or
+ <source><ereg regexp="[0-9]{1,3}[.][0-9]{1,3}[.][0-9]{1,3}[.][0-9]{1,3}[:][0-9]*"
+ search_in="hdr" occurence="1" header="Via:" assign_to="3" /></source>
+ <source><exec int_cmd="set_target_ip" parm=="[$3]" /></source>
+ </td></tr>
+ <tr><td><code>start_scen</code></td>
+ <td>Launches a new scenario from a scenario file.This is useful to perform
+ for instance automatic re-registration: the registration scenario can end
+ launching a "pause" scenario doing a pause followed by lauching the
+ re-registration scenario. The re-registration scenario would do the re-registration and
+ end lauching the "pause" scenario.</td>
+ <td>
+ <source><exec int_cmd="start_scen" parm="sut_rereg"/></source></td></tr>
+ <tr><td><code>keep_alive_on</code><br/><code>keep_alive_off</code></td>
+ <td>Send UDP Keep-Alive to the remote SIPP if keep_alive_period command line has been set
+ when starting SIPP. See <a href="#KeepAlive">Keep Alive</a></td>
+ <td>
+ <source><exec int_cmd="keep_alive_on"/></source></td></tr>
</table>
<p>Example that stops the execution of the script on receiving a 603 response:</p>
<source><![CDATA[ <recv response="603" optional="true">
@@ -2302,7 +2347,9 @@
user will initially be placed in.</li>
<li>Subsequent columns hold the static user data fields that
scenarios can refer to using the [field<i>n</i>] keyword.</li>
- </ul>
+ <li>The port used by a user is usually sequentially choosen. It can also be specified
+ using PORT=xxxx in the inf file e.g. PORT=5060.This is mainly used when simulating
+ Voicemail which must run on a port configured by the SUT</li> </ul>
<p>Example:</p>
<source>
@@ -2311,6 +2358,7 @@
0;subs000002;ims.test;usim000002;sp1.ims.test;pass000002;data2_1
0;subs000003;ims.test;usim000003;sp1.ims.test;pass000003;data3_1
0;subs000004;ims.test;usim000004;sp1.ims.test;pass000004;data4_1
+0;subs000005;ims.test;usim000005;sp1.ims.test;pass000004;data5_1;PORT=5060
...
</source>
<p>In this example, all users are initially in pool 0 (for example, the pool
@@ -2529,6 +2577,28 @@
this exit code by using "<code>echo ?</code>" command.</p>
</section>
+ <anchor id="KeepAlive" /><section><title>UDP Keep-Alive support for NAT pinhole tunneling</title>
+ <p>SIP users may be configured to periodically send small 4-byte UDP packets
+ to their remote (typically a proxy). This serves to keep any NAT pinholes
+ open, so that the SIP server can contact the client later thru the NAT box.
+ To enable: </p>
+ <ul>
+ <li><code>-keep_alive_period <secs></code> command line option
+ where <secs> is the period between keep alive messages. Typically ~20sec.</li>
+ <li>Add scenario action <source><exec int_cmd="keep_alive_on"/></source>.
+ Typically this would occur at the end of the registration scenario.</li>
+ <li>Add scenario action <source><exec int_cmd="keep_alive_off"/></source>
+ Typically at end of de-registration scenario (At point where it is ok for pinhole to close</li>
+ </ul>
+ <p>Keep alives are implemented on a per-user basis: the int_cmd changes the state for each user.
+ (e.g., the keep alive state is remembered into the next call for that user.
+ The keep_alive_period defaults to zero, which disable sending and keep alives.</p>
+ <p>As currently implemented, enabling keep alives, esp. For many users, may have a negative effect
+ on latency measurements. Sending keep alives requires walking thru the entire user list.
+ This occurs every 2 secs. Note that this overhead is entirely avoided when the keep alive period
+ is set to zero. Thus there is no performance impact when this feature is not enabled.</p>
+ </section>
+
<section><title>Statistics</title>
<section><title>Response times</title>
@@ -2768,6 +2838,7 @@
<tr><td>-ip_field nr</td><td>Set which field from the injection file contains the IP address from which the client will send its messages.<br/>
If this option is omitted and the '-t ui' option is present, then field 0 is assumed.<br/>
Use this option together with '-t ui'</td></tr>
+<tr><td>-keep_alive <secs></td><td>Send small 4-byte UDP packets to their remote where <secs> is the period between keep alive messages. Typically ~20sec.See <a href="#KeepAlive">Keep Alive</a> </td></tr>
<tr><td>-key keyword value</td><td>Set the generic parameter named "keyword" to "value".</td></tr>
<tr><td>-l calls_limit</td><td>Set the maximum number of simultaneous calls. Once this limit is reached, traffic
is decreased until the number of open calls goes down. <br/>
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
Thanks for helping keep SourceForge clean.
X