SIP load testing with SIPp

Posted by Alex Brett on August 31, 2011

When developing our VoIP services naturally we need to test them. In addition to the obvious functional testing (e.g. making sure that when you tell the system to send calls to your mobile it really does, and not to someone else’s!), we also need to perform load or stress testing to verify the system will not fail under large amounts of traffic.

One of the most useful tools we use for doing this is the open source project SIPp. This is a very powerful tool, and internally we use it with a number of custom scenarios designed to create load on the areas we know to be potential bottlenecks within our system. In this article however I am going to focus on using its built-in scenarios for simple load testing, and for simplicity the example is based on installing onto a fresh Debian Squeeze installation – for other systems similar packages etc will be required.

For best results, install SIPp on another host on the same network as your VoIP server (otherwise any CPU load introduced by your VoIP server might affect how much load SIPp can generate).

1. Install required packages
$ sudo apt-get install build-essential libncurses5-dev

2. Download, extract and compile SIPp
$ wget "" -O sipp.svn.tar.gz
$ tar -xzf sipp.svn.tar.gz
$ cd sipp.svn
$ make

3. Set up the SIP server
Note these instructions are for configuring the Asterisk open source PBX, for other platforms you will need to consult the documentation.

First, define the SIP peer by adding to the end of sip.conf:

Next set up some extensions that we will use to test by adding to the end of extensions.conf (this assumes a default Asterisk installation where the demo context exists, if not then point calls at some other context that has e.g. an IVR menu or similar):
exten => 1001,1,Answer
exten => 1001,n,SetMusicOnHold(default)
exten => 1001,n,WaitMusicOnHold(20)
exten => 1001,n,Hangup
exten => 1002,1,Answer
exten => 1002,n,Goto(demo,s,1)
exten => 1002,n,Hangup

Finally load the new configuration into asterisk:
$ asterisk -rx 'module reload'

4. Start testing

There are various simple tests that can be done without creating your own scenarios, such as:

1. Simple concurrent call test

$ ./sipp -sn uac -d 10000 -s 1001 <asterisk's IP address> -l 10
This will execute 10 concurrent calls (the -l parameter) with each call lasting 10s (the -d parameter in ms) to extension 1001. Note that this simple test does not actually establish an RTP connection, and thus does not actually place full load on the system.

2. Testing with media

$ ./sipp -sn uac -d 10000 -s 1002 <asterisk's IP address> -l 10 -mp 5606
This executes 10 concurrent calls, each lasting 10s to extension 1002 using the ulaw codec.

When running SIPp will display a screen showing various statistics such as the number of calls in progress, the number completed and some information about the SIP messages it has sent. It also shows any errors it has received. To stop a test, simply press ‘q’.

By playing around with the duration (-d) and limit (-l) parameters you can normally find the limit of your system’s scalability. It is also often an idea to leave the test running at a reasonable call level for a long period of time, this will help identify any memory leaks or similar that will likely cause problems over time.

Note that while SIPp will verify that an RTP connection is established, it will not check the quality – the simplest way to do this is to set up your call load using SIPp, then make a manual call through the system to check the quality is acceptable.


  • If the machine you are running SIPp on has multiple network interfaces, it may not correctly identify which interface to use for the outbound traffic – to correct this use the -bind_local option, e.g. to use the IP address for outbound traffic you would add “-bind_local
  • If you stop a test without letting all the calls clean up, and then attempt to start another, the new one may report errors as it receives SIP messages from the server relating to calls initiated by the previous test – it’s always best to let a test fully clean up