Restcomm – Load Testing – Part 1

In this tutorial, you will learn how to load test RestComm using SIPp. Load testing is performed to determine a system’s behaviour under both normal and anticipated peak load conditions. It helps to identify the maximum operating capacity of an application.


To run this tutorial you will need the following components:

  1. RestComm with the appropriate RCML application.
  2. An MSS instance responsible for processing the load sent from the RCML application.
  3. SIPp to initiate calls to RestComm.



Restcomm is a Communications Platform to rapidly build voice and text messaging applications, using your existing web development skills. You can install RestComm and the hello-world demo application as explained HERE.

Make sure your MGCP server is configured as follows:




[alert type=”notice”]Although this tutorial is supposed to be run locally, keep in mind that it is recommended to use separate server for RestComm and Media Server.[/alert]

After running the cURL command the address sip:1234@localhost:5080 became bound to the hello-world application. This will be the phone number used by SIPp to communicate with RestComm.

Mobicents Media Server

The Mobicents Media Server is a Java based Real Time Media server that offers streaming, conferencing, recording, playback, IVR, Text To Speech and other rich media features. It can be accessed programmatically via MGCP or a Media Control (JSR 309) driver that runs in Java EE, SIP Servlets and JSLEE containers.

For this tutorial, we need to configure the UDP Manager of the Media Server:




Its worth mentioning that the lowerPort and highestPort properties define a RTP port range that should be large enough to carry the load that the performance test will create. These parameters are optional since MSS default RTP port range is 1024 – 65534. For every call, MSS cyclically starts with the higher available port and for every next call will user the next lower port.

Also, we need to declare the audio codecs supported by the Media Server. The scenario used in this tutorial is configured to use G711 A-law. Below is a list of commonly used codecs:




SIPp is a traffic generator for the SIP protocol. It includes a few basic SipStone user agent scenarios (UAC and UAS) and establishes and releases multiple calls with the INVITE and BYE methods. You can install SIPp as explained in HERE.

SIPp can read XML scenario files describing call flows. For this tutorial, create the following xml file:



Executing Load Tests

Now that all the required components are configured, its time to execute the load test.

By running the following instruction in your command line, SIPp will start generating SIP traffic according to the specified scenario.

[tagline_box link=”” button=”” title=”” description=”sipp -sf ./UAC_G711alaw.xml -s 1234 -l 200 -m 2000 -r 30 -trace_screen -trace_shortmsg -trace_err -recv_timeout 400000 -t un -nr”][/tagline_box]

Let’s shed some light on the command’s parameters:

  • -sf ./UAC_G711alaw.xml indicates the SIPp script to be run.
  • -s 1234 directs the call to sip:1234@localhost:5080 which is the phone number bound to the hello-world application.
  • -l 200 indicates the number of simultaneous calls. Once this limit is reached, traffic is decreased until the number of open calls goes down.
  • -m 2000 indicates the number of calls to be processed before the calls are processed.
  • -r 30 represents the call rate. This value means 30 calls per second.
  • -trace_screen will create a log file containing the statistic screens.
  • trace_shortmsg will create a log file containing sent and received SIP messages.
  • -trace_err will create a log file containing unexpected messages.
  • -recv_timeout 400000 represents the global receive timeout in milliseconds. If an expected message is not received in this time, then the call times out and is aborted.
  • -t un indicates the transport mode is UDP with on socket per call.
  • -nr disables retransmission in UDP mode.

[alert type=”notice”]If you intend to reach high call rates and/or high number of simultaneous SIP calls consider limiting the traces to a minimum.[/alert]

SIPp provides screens to summarise the results of the load test:

  • Scenario Screen – Displays the call flow of the scenario as well as some important informations.
  • Statistics Screen – Displays the main statistics counters. The “Cumulative” column gather all statistics, since SIPp has been launched. The “Periodic” column gives the statistic value for the period considered.
  • Repartition Screen – Displays the distribution of response time and call length, as specified in the scenario.

Result Analysis

The following test cases were executed on a machine with the following specs:

  • MacBook running OSX 10.8.3 (Mountain Lion).
  • Processor 2.4 GHz Intel Core 2 Duo.
  • Memory 4Gb 1067 MHz DDR3

Case 1 – Test run with trace logging activated

Below are the result screens of this test . Keep in mind that the SIPP command was run with trace logging turned on.


Scenario Screen

sipp scenarion screen

Statistics Screen

sipp scenario screen

Repartition Screen

sipp repartition screen

Looking at the results we can immediately see that the system took 434.33 seconds to process 2000 calls, while receiving calls at a rate of 30 calls per second. This means that the system could process 4.602 calls per second. We can also see that out of the 2000 calls only 1480 were successful. A quick search in the errors log will show us the motives why those 520 calls failed:

  • Aborting call on unexpected message for Call-Id ‘’: while expecting ‘180’ (index 2), received ‘SIP/2.0 500 Server Internal Error.
  • 2013-04-26 11:22:10:832 1366971730.832413: Call-Id:, receive timeout on message Basic Sipstone UAC:1 without label to jump to (ontimeout attribute): aborting call.

These kinds of errors were originated due to the stress the system was under. Looking back at the results, we can conclude that our quality of service is a bit poor since one quarter of the calls failed.

Case 2 – Test case run without trace logging

In the previous example we concluded that the system was providing a poor quality of service because it was under too much stress. One immediate strategy to try to alleviate stress is to turn off trace logging. In this way we are saving a file write operation each time a SIP message is sent or received.


Scenario Screen


Statistics Screen


Repartition Screen


Looking at the results we can immediately see a huge improvement when comparing with the previous results. Without trace logging the system took 274.64 seconds to process 2000 calls, while receiving calls at a rate of 30 calls per second. This means that the system could process 7.282 calls per second. Also, all the 2000 calls were processed without errors.

The simple fact of turning off trace logging made possible to process the same amount of calls in almost half of the time and without errors, thus providing a good quality of service. Also, this means that our server can support even higher levels of stress.

Future Work

We strongly encourage you to:

  • Invent your own scenarios.
  • Run SIPp with different sets of parameters and analyse the results. This is an essential step to discover the true load capacity of your server. If needed, use tools like Wireshark to measure response times with a high precision.
  • Test more complex RCML applications.
0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply