{"id":13421,"date":"2020-08-23T19:30:32","date_gmt":"2020-08-23T19:30:32","guid":{"rendered":"http:\/\/abstracta.us\/blog\/?p=13421"},"modified":"2025-05-05T21:22:38","modified_gmt":"2025-05-05T21:22:38","slug":"voip-performance-testing","status":"publish","type":"post","link":"https:\/\/abstracta.us\/blog\/performance-testing\/voip-performance-testing\/","title":{"rendered":"VoIP Performance Testing for a Mental Health Hotline App"},"content":{"rendered":"\n

How we used SIPp for VoIP performance testing over the SIP protocol<\/h1>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Not too long ago, some of my colleagues and I helped to run performance tests for a new mobile app with a hotline called \u201cYo Te Escucho<\/a>\u201d (which translates in English to \u201cI hear you\u201d). It was created during the COVID-19 crisis as a non-profit, voluntary initiative in Uruguay. The hotline connects anyone who wants to simply speak and be heard (safely and anonymously) by a trained person. The main objective is to be able to provide people with a channel of communication and empathetic listening. Sparked as a response to the negative impacts of the virus, the initiative is expected to continue in the long-term, even when it\u2019s no longer around.
<\/p>\n\n\n\n

In this post, we want to share how we went about performance testing the mobile app\u2019s VoIP technology as well as everything we learned about the tool, SIPp<\/a>, for performance tests over the SIP protocol (which is basically known as VoIP, Voice Over the Internet). We\u2019ll go through the basics of the protocols involved and then see how to use the SIPp tool to simulate concurrent calls on the system. All this of course, from the experience of a real volunteer project, which makes it much more interesting! <\/p>\n\n\n\n

Thanks to my colleagues, Pablo Richieri<\/a>, who also worked on the project, for helping me write this post and to Andr\u00e9i Guchin<\/a> for leading the effort. <\/p>\n\n\n\n

<\/span>Project Background<\/span><\/h2>\n\n\n\n

Our role in this project was to conduct performance tests<\/strong> on the mobile app in order to observe the system\u2019s performance when it experiences the maximum number of currrencurent calls that it was designed to support. <\/p>\n\n\n\n

The hotline application has two types of users: those who make the calls (‘callers’) and those who are available to answer them (‘listeners’), using the SIP protocol<\/strong> to establish communication. <\/p>\n\n\n\n

We soon learned that the typical tools we use for performance testing such as JMeter or Gatling don\u2019t support this protocol by default. So, we had to investigate what the SIP protocol consists of, how to capture it and which tool we could use to automate the flow of the call from both the caller and listener side. We achieved this with the SIPp tool, which was recommended by 3CX<\/a>, the VoIP service provider for the hotline.<\/p>\n\n\n\n

<\/span>What is VoIP?<\/strong><\/span><\/h2>\n\n\n\n

The VoIP (Voice Over IP) protocol is used to make and transmit telephone calls over an IP network. Its goal is to packetize audio streams in order to transport them.<\/p>\n\n\n\n

Most of these calls use the SIP protocol (Session Initiation Protocol), either through the use of physical telephones as well as softphones.<\/p>\n\n\n\n

Physical SIP phones<\/strong> look a lot like traditional phones, however they\u2019re developed for use on IP networks. (Think of the clunky phone you typically see on everyone\u2019s desk in an office!)<\/p>\n\n\n\n

\"example<\/figure><\/div>\n\n\n\n

Softphones<\/strong> on the other hand, are software applications used on computers, tablets or smartphones and behave exactly like a normal IP phone, allowing to perform calls as well as additional features like video conferencing, presentations, etc.<\/p>\n\n\n\n

\"example<\/figure><\/div>\n\n\n\n

<\/span>What is SIP – Session Initiation Protocol?<\/strong><\/span><\/h2>\n\n\n\n

SIP is a protocol used to establish a \u201csession\u201d between two or more participants, modify it and eventually terminate the session. It\u2019s found its greatest use in the world of IP telephony. This protocol bears a significant resemblance to the HTTP protocol. The messages are text-based and the request-response mechanism makes error resolution very easy.<\/p>\n\n\n\n

We have two types of SIP messages, requests and status messages. Among the most common requests are: REGISTER, INVITE, ACK (acknowledge), INFO, NOTIFY, UPDATE, BYE, etc. And in the states we will find response codes in the range between 100 and 600, for example: 100 (Trying), 180 (Ringing), 200 (OK), 407 (You need to authenticate), etc.<\/p>\n\n\n\n

SIP messages describe the identity of the participants in a call and how the participants can be reached over an IP network. Once the exchange of configuration messages is complete, communication can be exchanged using another protocol, typically RTP (Real-Time Transmission Protocol).<\/p>\n\n\n\n

SIP was developed by the IETF and published as RFC 3261, and its flexibility has made it possible to almost completely replace the H.323 protocol in the VoIP world.<\/p>\n\n\n\n

<\/span>How to Capture Traffic with the SIP Protocol?<\/strong><\/span><\/h2>\n\n\n\n

The tool we recommend to capture this protocol is Wireshark<\/a>, a protocol analyzer that allows you to see all the traffic that passes through a network and filter it by protocols.<\/p>\n\n\n\n

The different sections that we will find in Wireshark that are very useful when it comes to automating the flow are shown below:<\/p>\n\n\n\n

<\/div>\n\n\n\n
\"vopi<\/figure>\n\n\n\n
  1. In this section you can filter both by protocols and by IPs<\/li>
  2. The IP from which the messages are sent is displayed<\/li>
  3. The IP that receives the messages is displayed<\/li>
  4. In this section you can see what protocol is being used<\/li>
  5. In this section we can see if the message is a request or a status message (status)<\/li>
  6. By selecting one of the captured packets, we can view in this section the information regarding the protocols of each of the network layers. If we select \u201cSession Initiation Protocol\u201d in \u201cMessage Headers\u201d we will be able to see all the SIP protocol headers that are sent in that message that we will then use to automate the call.<\/li><\/ol>\n\n\n\n

    <\/span>What is SIPp? <\/strong><\/span><\/h2>\n\n\n\n

    SIPp is an Open Source tool that allows us to generate one or more calls using the SIP protocol, emulating both clients and servers.<\/p>\n\n\n\n

    By default it provides some basic scenarios that are ready to run, but it also allows us to import our own scenarios that we will create in XML format.<\/p>\n\n\n\n

    In these scenarios we will describe call flows from the simplest to the most complex, being able to regulate the number of calls per period of time, the use of authentications, sending audio or video using the RTP protocol, among others.<\/p>\n\n\n\n

    In this link<\/a>, you can download SIPp and find its documentation, which easily explains how to install it (we recommend doing it in Linux).<\/p>\n\n\n\n

    <\/span>Using SIPp <\/strong><\/span><\/h2>\n\n\n\n

    If you want to use the tool, all you have to do is perform the following steps: <\/p>\n\n\n\n

    To begin, it\u2019s run from the command line using “sipp”.<\/p>\n\n\n\n

    # .\/sipp<\/strong><\/p>\n\n\n\n

    Then we indicate the IP address to which our calls will be directed.<\/p>\n\n\n\n

    # .\/sipp 127.0.0.1<\/strong><\/p>\n\n\n\n

    And finally the “-sf” flag is used to execute a scenario created by us or “-sn” to use one of those already included, followed by the scenario file that we are going to execute.<\/p>\n\n\n\n

    # .\/sipp 127.0.0.1 -sf my_scenario.xml<\/strong><\/p>\n\n\n\n

    With this we could already execute a simple scenario without problems, but we have a great variety of options that will allow us to execute more complex scenarios.  <\/p>\n\n\n\n

    Next we will see some of these options that we believe will be very useful when making your scenarios more robust. <\/p>\n\n\n\n

    -h:<\/strong> Shows help information on the screen<\/p>\n\n\n\n

    -aa: <\/strong>Activates an automatic response with the code “200 OK” for all INFO, UPDATE and NOTIFY requests. This is useful to be able to avoid all these messages that generally do not contribute much to the user, they only inform.<\/p>\n\n\n\n

    -m:<\/strong> Determines the maximum number of calls to execute and stops the test when that number of calls is processed<\/p>\n\n\n\n

    -r:<\/strong> Configures the number of calls per time period that we want to generate. By default, 10 calls are generated per second. This setting is dynamically editable during the test using the following keys:<\/p>\n\n\n\n