Status: Beta version
Year: 2013
Author: Luis Martin Gil. INdigital Telecom
SIPp is a great tool created by HP which allows to generate SIP traffic. A SIPp execution requires an scenario to run, the scenario defines the messages that are going to be sent and received as well as another logic. Multiple parameters can be defined. Also, it has a flexible way to define its highly customizable scenarios.
SIPp makes easy to simulate different SIP traffic flows. SIPp is sometimes used as a powerful SIP bulk load tester. The traditional SIPp execution forces the user to run the desired SIPp command manually. The fact of manually run a high number of SIPp commands has obvious disadvantages such as human errors or waste of time. SIPp lacks of ways to automate it. This is where sipptam starts to make sense. If you just have a couple of SIPp scenarios to run against your device under test (SIP UA, SIP proxy, SIP b2bua) manual execution could be allowed, when you have N number of SIPp scenarios and N gets high, you have to look for SIPp automation, sipptam is what you are looking for. sipptam automates the use of SIPp.
Distributed system to run SIPp instances. Three basic type of entities in the {sipptam} world.
sipptam, manager which reads the scenarios and parameters, it distributes the SIPp jobs among the slaves (sipptas), checks the status and outputs the result back to the user.sipptas, slave which performs SIPp jobs. It provides an API for executing SIPp jobs in the box where it is running.dut, device under test. Device to test such as asterisk, opensips, kamailio.
Syncing the execution of scenarios is something that definitely can make the testrun to pass or to fail. Sipptam makes sure the execution is made as the user wants. The order which scenarios are selected defines the scenarios order execution. Let's see an example.
We have a folder with multiple scenarios:
(...)/tmp/test-0000.xml/tmp/test-0001_a.xml/tmp/test-0001_b.xml/tmp/test-0002_a.xml/tmp/test-0002_b.xml/tmp/test-0002_c.xml/tmp/test-0003.xml/tmp/test-0004_a.xml/tmp/test-0004_b.xml(...)
A testrun defined with this scenarioPath="/tmp/test-0002_*.xml" would select these scenarios:
/tmp/test-0002_a.xml/tmp/test-0002_b.xml/tmp/test-0002_c.xml
Again, the order which scenarios are selected defines the scenarios order execution. In this example, /tmp/test-0002_a.xml will run first, /tmp/test-0002_b.xml will run second and /tmp/test-0002_c.xml will run third. The last scenario selected (/tmp/test-0002_c.xml in this example) is likely to be the one which sends the first INVITE in the scenario, this way the user makes sure the first two scenarios are already waiting for this INVITE and the testrun is properly syncronized and executed.
SIPp instances need to bind to a specific port. This port is dynamicaly provided by the sipptas.
Scenarios are executed using randomized tas jobs{port and host}. Since most of the scenarios are talking SIP each other we might need to know which is the IP or port of the other scenario in the same testrun. Sipptam provides a way to define this in the scenarios:
!sipptas(host( X ))!!sipptas(port( X ))!Where X is an integer which refers to the scenario that is going to be executed in that position. Based on our previous example,/tmp/test-0002_a.xml, will be0/tmp/test-0002_b.xml, will be1/tmp/test-0002_c.xml, will be2So if you want to refer to the ip and port of the tas running the/tmp/test-0002_a.xmlscenario, we have to refer to it in the other scenarios as !sipptas(host(0))! and !sipptas(port(0))!.
Imagine we have a transfer scenarios using the REFER model, we might have to know where we are referring the call to. In this case we will refer the call to the scenario which is going to be executed in position 2 in the testrun.
(...)
Refer-To: sip:refered_user@!sipptas(host(2))!:!sipptas(port(2))!
(...)
]]>
Different ways to define how the execution is going to be done:
parallel: All the testruns at the same time.serial: Each testrun at a time.
Using parallel mode really makes the different from the manual use of SIPp. This mode allow us to run different scenarios at the same time against the dut. This is not supported by SIPp by any means.
Different ways to define how many executions of the testruns:
tries: Number of times to execute the same testrun.
Different ways to define the call rate and the maximum number of calls:
ratio: calls per second.max: maxinum number of calls.
Let's see an example, (notice that t1 defines the end of the execution of the testruns in a parallel mode, t2 is when using serial mode).
Configuration is made through an XML file passed at runtime.
You can find one here
You can find the schema of the XML configuration file here
- Mandatory. Cardinality : 1.
- sipptam.duthost, device under test host
- sipptam.port, device under test port
<sipptam duthost="10.22.22.112" dutport="5060">
- Mandatory. Cardinality : Unbounded.
- tas.host, host to communicate with the tas.
- tas.port, port to communicate with the tas.
- tas.jobs, max jobs to assign to this tas.
<tas host="10.22.22.200" port="8008" jobs="25"/>
- Mandatory. Cardinality : Unbounded.
- testrun.id, identifier for the testrun.
- testrun.scenarioPath, path where to find the scenarios of the testrun.
- testrun.configLink, link to the configuration of the testrun. Config must be defined.
- testrun.modLink, max jobs to assign to this testrun. Mod must be defined. Optional.
<testrun id="test-0001"
scenarioPath="/usr/local/share/sipptam/scenarios/test-001*.xml"
configlink="simple"
modlink="one"/>
- Mandatory. Cardinality : Unbounded.
- config.id, identifier for the configlink.
- config.ratio, semicolon separated list of ratio (SIPp parameter, calls per seconds).
- config.max, semicolon separated list of calls (SIPp parameter, maximum calls to make).
- config.pause, seconds to pause between every {ratio, max} combination.
- config.tries, number of times to execute every {ratio, max} combination.
<config id="advanced"
ratio="5;10"
max="20;60"
pause="5.0"
tries="2"/>
- Optional. Cardinality : Unbounded.
- mod.id, identifier for the configlink.
<mod id="one">
<replace regex="(.*_a.xml)" src="__notusednow1__" dst="tmp1a"/>
<replace regex="(.*_a.xml)" src="__notusednow2__" dst="tmp1a"/>
<injection regex="(.*)" path="/usr/local/share/sipptam/injections/injection1.sample.csv"/>
</mod>
- Optional. Cardinality : Unbounded.
- mod.replace.regex, scenarios from the testrun which match this regex will use this
replacemodification. - mod.replace.src, string to be replaced in the scenario.
- mod.replace.dst, string to replace in the scenario.
<replace regex="(.*_a.xml)" src="__notusednow2__" dst="tmp1a"/>
Injection modification are used to inject values from external files. Files injectected will be passed with the scenarios that apply. Please check the -inf param of SIPp here.
- Optional. Cardinality : Unbounded.
- mod.injection.regex, scenarios from the testrun which match this regex will use this
injectionmodification. - mod.injection.path, injection file to attach to the .
<injection regex="(.*)" path="/usr/local/share/sipptam/injections/injection1.sample.csv"/>
- Mandatory. Cardinality : 1.
- advanced.execMode, execution mode. parallel will run all the testruns at the same time. serial will run one testrun after another in the way they are defined.
- advanced.scenarioValidate, checks that all the scenarios loaded in the testruns pass basic XML validation.
- advanced.regexValidate, checks that the regex defined by the user are correct.
<advanced execMode="parallel"
scenarioValidate="False"
regexValidate="True"/>
TODO.
TODO.
TODO.