Recently I’ve had the opportunity to deploy and test a call centre PBX product to gauge if its viable to offer as a product and how it will sit within our infrastructure.
Installing and poking around the GUI is all well and good but to really find out how a PBX behaves it needs some traffic, to find outs its performance in regards to resources but also to find out what a vendor’s interpretation of an advertised feature actually is.
To generate sample calls, instead of registering handsets/softphones and dialling manually it would be better to automate this, and SIPp is the perfect tool for this.
SIPp is an open source SIP testing tool for stress testing PBX’s, but it can also be used more modestly so it can generate more real-world scenarios to simulate typical calls. This can also be beneficial when testing and reviewing complex call flows through a system before deploying.
Environment
In this example I would be using a local CentOS 7 Virtual Machine to host the SIPp application, with the PBX sitting remotely and network access via VPN for the testing period.
The PBX will also have a trunk set to allow calls in from the CentOS box and a DDI assigned.
Installation
Installation on CentOS is easiest via yum and the EPEL repositories.
From a clean install run:
yum update
yum install epel-release
yum install sipp
Operation
Once installed its as easy to run as running the program from the command line, but getting the results you are looking for requires a lot of switches and a scenario file.
The simplest way to look at this is the switches take care of the targeting and rate of the calls, where the scenario file simulates the calling person, and can be set to imitate speech (RTP streams), dtmf inputs and even introduce packet loss to measure quality of calls. Essentially a profile of a call is contained within the scenario file.
As an example, this is a typical command I use for testing a very modest call load:
sipp -sf file.xml -trace_err -trace_msg -i 10.20.30.40 -r 1 -rp 10000 -l 100 -m 50 -s 12345678901 10.100.100.100
To break down this command and make it more understandable:
- -sf {FILENAME} – Scenario file.
- -trace_err – Print errors to file, for troubleshooting.
- -trace_msg – Print verbose log to file, for troubleshooting.
- -i {IPADDRESS} – RTP stream (Audio) source.
- -r {NUMBER} – Call Rate – Rate that calls are attempted.
- -rp {NUMBER} – Rate Period – Number defined in Call Rate are spread over the Rate Period.
- -l {NUMBER} – Max number of concurrent calls.
- -m {NUMBER} – Total number of calls to attempt.
- -s {NUMBER}- SIP number to dial and server.
- “10.100.100.100” – PBX server IP
Scenario File
As mentioned, the scenario file contains the simulation of a call from a calling party.
SIPp has a number of template scenario files in XML format available on their Sourceforge page, these can be download and modified as needed.
For example, below is my modification of the uac_pcap.xml template, this is a simple file that connects and plays an RTP stream (from a pcap file) for two minutes before hanging up:
<scenario name="UAC with media">
<!-- CALL SETUP -->
<send retrans="500">
<![CDATA[
INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: 01234567890 <sip:01234567890@[local_ip]:[local_port]>;tag=[call_number]
To: sut <sip:[service]@[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[local_ip_type] [local_ip]
t=0 0
m=audio [auto_media_port] RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11,16
]]>
</send>
<recv response="100" optional="true">
</recv>
<recv response="180" optional="true">
</recv>
<send>
<![CDATA[
ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number]
To: sut <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<!-- PLAY RTP STREAM -->
<nop>
<action>
<exec play_pcap_audio="pcap/g711a_600.pcap"/>
</action>
</nop>
<!-- SET CALL LENGTH -->
<pause milliseconds="120000"/>
<send retrans="500">
<![CDATA[
BYE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number]
To: sut <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 2 BYE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<recv response="200" crlf="true">
</recv>
<!-- definition of the response time repartition table (unit is ms) -->
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<!-- definition of the call length repartition table (unit is ms) -->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
Personal Observations
This is a great tool for automation in the testing phase of a new platform deployment, and you can easily generate calls in numbers considered unfeasible when using traditional desk and soft phones, plus this method allows all phones in the test bed to become call recipients, increasing the user base to more accurately test a platform.
In addition to the PBX this tool also tests the network that provides connectivity to the phone system, this was highlighted to me when testing with traffic going over a VPN, and discovered that the VPN gateway could not cope with more than 10 concurrent calls despite having enough bandwidth available.
As a final note I recommend to start a test with minimal call volume ad scale from there. Whilst SIPPp can simulate calls, these aren’t as organic as the real world. I managed to knock a live system offline with as little as 100 generated calls, due in part to 100 SIP invites being sent within one second.
Oh, and don’t introduce a load of test calls to a flow where the final destination is a voicemail, I found that out the hard way!