As a company developing VoIP software, we need a solid developing and testing SIP ecosystem. SIP (Session Initiation Protocol) is a signaling protocol used for initiating, maintaining, modifying and terminating real-time sessions that involve video, voice, messaging and other communications applications and services between two or more endpoints on IP networks. It is one of the most popular protocols in VoIP.
In this article, we are going to describe some SIP tools we usually use and how we use them. These tools allow us to make calls, check that the SIP messages are well formed and make load testing.
Pjsua is an open source command line SIP user agent (softphone). It is part of the PJSIP SIP Open Source library. Despite its simple command line appearance, it does pack many features. This tool helps us to setup SIP User Agents and establish calls between them and servers.
The main pjsua screen shows the keys to activate the different functions:
Making a call
To make a call just press m and select a destination from the buddy list or put it manually:
In the other end, the call is received and a notification is showed. You can answer the call by pressing a or reject it by pressing h.
Other options we use
A STUN (Session Traversal of User Datagram Protocol [UDP] Through Network Address Translators [NATs]) server allows NAT clients to setup phone calls to a VoIP provider hosted outside of the local network. To define the STUN server use the
$ pjsua --stun-srv=<STUN_Server_IP>
Pjsua offers the ability to enable or disable codecs you want to use for the calls with the arguments
$ pjsua --add-codec=<to_enable_codec_name> --dis-codec=<to_disable_codec_name>
Pjsua provides the ability to set the SIP URL of the account, for example to customize
From header and
Contact header with arguments
pjsua --id=<SIP_URL> --contact=<SIP_URL>
We also usually use configuration files in which we define a list of arguments. You can specify which configuration file you want to load with the
Configuration file contains the desired arguments:
--stun-srv=10.10.10.10 --dis-codec=speex/16000/1 --add-codec=PCMU/8000/1 --add-buddy sip:firstname.lastname@example.org:5060
As you can see, pjsua provides some other commands with interesting functionalities and a big list of arguments to modify its behaviour. With this tool, we are able to make calls between systems in a very simple way.
Sngrep is a tool to capture SIP traffic and display the call flow in a terminal nicely. It is made by Irontec and it is in development. Sngrep supports live capture to display realtime SIP packets and can also be used as “.pcap” viewer.
When you execute sngrep tool it starts capturing packages and shows the call list screen. This screen shows the list of calls that have been captured from sngrep until that moment.
Entering in a call from the call list, you can see the flow for the selected call. In this screen you can see the SIP messages and you can move around to any of these messages to see the SIP package content.
Selecting two SIP messages with space bar, sngrep compares them and shows their diff.
Saving .pcap files
You can select the calls you want to save from call list and save them into a .pcap file. This is very useful to see the calls later on sngrep or with another tool like Wireshark.
Viewing .pcap files
To open a .pcap file with sngrep, just execute the next command:
$ sngrep -I sngrep_test.pcap
And you will see the call list screen with the calls extracted from the .pcap file, in the same way you see it when sngrep is capturing traffic.
It includes a few basic user agent scenarios (UAC and UAS) and establishes and releases multiple calls with the INVITE and BYE methods. It can also read custom XML scenario files describing from very simple to complex call flows. It displays statistics about running tests (call rate, round trip delay and message statistics) and provides dynamically adjustable call rates.
A SIPp scenario is an XML file containing the steps for the call to be run. Steps mainly consist on sending SIP packets, handling the expected responses and some other actions like executing commands or pausing the scenario. The scenario will be run sequentially, and SIPp will display the various steps, number of successful completions and failures for each. SIPp is a very strict tool, so it’s important to know that SIPp consider an error anything that is not happening exactly as defined. SIPp comes with a number of built-in scenarios, but you can use your custom scenarios.
As part of our testing, we have a bunch of SIPp custom scenarios for each VoIP product. These scenarios allow us also to test very specific product’s behaviours, designing scenarios for each of them and checking them later in automated test processes. In order to perform field validation for received messages, we use regular expressions (regexp) in our scenarios.
The simplest scenario we use for testing products with SIPp is the following:
With the next commands, you can run SIPp based on this scenario. In most cases, the first SIPp User Agent that we start is the one that is supposed to receive the first SIP message (callee):
SCENARIO="my_scenario.xml" CALL_RATE=5 MAX_CALLS=100 CALLEE_IP=10.10.10.11 $ sipp -sf $SCENARIO -r $CALL_RATE -m $MAX_CALLS -bind_local $CALLEE_IP -i $CALLEE_IP -inf users.csv -p 5060
After that, we have to run the caller User Agent, which is the one that triggers the call:
SCENARIO="my_scenario.xml" CALL_RATE=5 MAX_CALLS=100 CALLER_IP=10.10.10.10 $ sipp -sf $SCENARIO -r $RATE -m $MAX_CALLS -bind_local $CALLER_IP -i $CALLER_IP -inf users.csv -p 5060 SERVER_IP:5060
While running, SIPp shows information about the calls running. This information includes the call rate, total calls, the SIP messages sent and received and other interesting statistics:
Note that you can adjust rate, pause traffic or change to other scenario screens to see more information. In the end, SIPp shows final statistics:
As you can see, this is a good tool to see how the calls are working on our systems. It gives us a lot of information about the calls, and it’s very useful to know if a product is able to manage a specific number of calls and call rate. Playing with the call rate and number of calls, we can check for this scenario if calls are failing or how many resources the product is taking from the machine.
This post shares the tools we use to develop and test our VoIP applications. Handling SIP calls involves a high number of messages between User Agents and it could be pretty challenging. These tools highly facilitate both development, testing and troubleshooting of all the SIP products that we have in our stack. They allow us to check the information we need about calls in a easy way, and also to make load tests to check how the product performs under stress conditions, simulating a real production environment.