Performance Analysis of Raspberry Pi 3 IP PBX Based on Asterisk

Abstract

IP-PBX have grown considerably in the telecoms and IT industries in recent times due to their low cost, high customizability, open source and hardware-independent nature. Unlike traditional PBX systems that are TDM-based and require a separate wired infrastructure to operate, an IP PBX can be attached to the local LAN and uses SIP with RTP over Internet Protocol (IP) for signaling and data transport, respectively. Asterisk-based IP PBX has become a de facto standard for open-source low-to-medium calling capacity requirements. Single Board Computers (SBCs) are attracting considerable attention from academics, hobbyists and the industry, due to their compact size, low cost, low power, portability and fair processing ability. Raspberry Pi series SBCs are the pioneer in the field, having Pi, Pi2, Pi3 and Pi Zero in production, supporting different processing and storage capabilities. An IP PBX embedded on the raspberry Pi SBC can serve an adequate number of users and provide a tiny platform that can fit in a pocket and be transported anywhere while preserving the functionality of a complete IP PBX. Such systems can be phenomenally successful in situations where large infrastructures cannot be taken, for instance, in warzones or disaster-affected areas where communication networks are damaged, necessitating an immediate requirement for an ad hoc-based communication system. In this paper, we aim to explore the performance of an Asterisk^®-based IP PBX installed on a Raspberry Pi 3 (model B) platform in terms of concurrent call handling using different codecs.

1. Introduction

1.1. Private Branch Exchange (PBX)

Private Branch Exchange (PBX) is a TDM, a telephony system that primarily focuses on providing a private, within-organization, calling facility, i.e., extension-to-extension, while having a limited number of shared lines to Public-Switched Telephone Networks (PSTN) or Cellular Mobile Operators (CMO) for outward dialing, mostly opened on specific extensions and with the use of a predefined code [1,2,3,4]. PBX is an old-fashioned technology consisting of different modules/cards inserted in a cabinet to support multiple services, and requires a proper wired infrastructure for each extension to work, meaning a complex and cumbersome wiring network should be laid before using the traditional PBX. Enterprises/companies use PBX to lessen their calling expenses, since having separate phone lines for each extension can add considerable expenses to their budget, while most of the calling requirement is within premises. Some known vendors for TDM PBX include Alcatel, Panasonic, Siemens, and Nortel. Traditional PBX are vendor-proprietary and provide different types of calling interfaces. For example, analog extensions (for analog audio), digital extensions (for digitized speech), Basic Rate Interface (BRI) and Primary Rate Interface (PRI). BRI provides a 2-Bearer channel at 64 Kbps for voice/data and a 1-Data channel at 16 Kbps for signaling/control traffic. Similarly, PRI provides a 30-Bearer + 1-Data channel at 64 Kbps on E1, and a 23-Bearer + 1-Data channel on T1.

1.2. Hybrid PBX

After the emergence of Voice over IP (VoIP), it has become difficult for PBX vendors to ignore the widespread popularity of VoIP. Hence, they made a transition from traditional PBX and developed new boards supporting VoIP protocols, i.e., SIP and H.323. Hence, single PBX started to support both TDM- and VoIP-based extensions; such PBX are known as Hybrid PBX due to their dual support of TDM and VoIP protocols.

The main issue with TDM or Hybrid PBX is that systems are closed and vendor-proprietary; hence, if one needs to increase the capacity or customize anything, one has to consult a specific vendor. Otherwise, there may be situations when one may want to add one or two extensions but have no spare port, and, in that case, one might have to buy an entire board with 16 or 32 ports, or in the worst cases, an entire cabinet/frame if the previous rack has no vacant slot. Last but not least, due to lack of interoperability between different vendors, once one buys a PBX from vendor A, all accessories, modules, cards and service configurations are only provided by vendor A, and no other vendor will provide support, leading to vendor dependency, market monopoly and high service cost.

1.3. IP PBX

IP PBX or soft PBX is the most advanced form of traditional PBX; it is indeed a PBX system that uses Internet Protocol for carrying signaling and data/voice traffic with numerous added features [5,6,7,8]. Some of the imperative benefits include customizability, hardware independency and availability of open-source solutions. Most IP PBX are open source and can be installed in Linux OS running on a server machine or general purpose computer, providing a cost-effective PBX solution [9,10,11]. Something to consider is to choose a computing platform that provides sufficient CPU and memory resources to handle the desired calling load. IP PBX are also highly customizable in both hardware and software; by using Application Programming Interfaces (APIs), one can easily interface external applications with an IP PBX; on the hardware side, it can support traditional analog/digital extensions through FXS, FXO or E1/T1 cards interfaced through a PCI-E slot [12].

Asterisk^® (Corona, CA, USA) is one of the most popular open-source soft PBX available at this time, facilitating a moderate number of users, providing rich features, industry-wide compatibility and very good documentation [13,14,15,16]. In our implementation, we used a curtailed version of Asterisk^®, which is “RasPBX “designed for Raspberry Pi and other similar single-board computers.

1.4. Single-Board Computer (SBC)

Single-board computers (SBCs) are tiny computing platforms, mostly the size of a credit card, and has all personal computer (PC) components, i.e., CPU, memory, graphic display, USB ports, data storage, network connectivity, etc., embedded on a single PCB [17]. It also supports pluggable modules through USB, GPIO and other interfaces, as shown in Figure 1. SBCs in general can be thought as mini desktop computers with reduced processing, memory and storage capabilities. SBCs are a recent trend in IoT as standalone and miniature products that require low cost, low power and comparatively fewer processing resources [18,19,20,21,22,23]. At present, there are many SBC brands available in the market, i.e., Raspberry Pi, Banana Pi, Orange Pi, ODROID, Latte Panda, PINE, UDOO and C.H.I.P. Among them, Raspberry Pi is considered the pioneer in the field, with Raspberry Pi 1/ 2/ 3/ Zero platforms in production [24]. Our work is based on a Raspberry Pi 3 Model B SBC, which is the second most powerful in its line.

In this paper, we present a theoretical comparison of the different SBCs available in the market with respect to their CPU type, memory, storage and networking options. The subsequent sections of the paper discuss the testbench setup conducted using the Raspberry Pi3 to explore its load-bearing capabilities when used as IP PBX. Test calls were generated using a software-based traffic generator for different voice codecs used in real-world VoIP (voice over IP) communication and relationships were drawn between number of calls vs. CPU, memory, rtt and disk and network utilization.

The organization of rest of the paper is as follows: Section 2 provides a comparison of different SBC platforms followed by configuration details of the Raspberry Pi series. Section 3 presents the test bench hardware and software configuration. Section 4 discusses simulation methodology. Finally, Section 5 presents the simulation results followed by the conclusion in Section 6.

2. Single-Board Computer Configuration Comparison

Single-board computers are improving continuously in price and configuration. The rapid advancements in nano technology and VLSI are making SBCs more powerful, with increased I/O, compact size and lower in price with every passing year [26]. The currently available SBCs can be compared with normal desktop PCs in terms of processing and memory. For example, a UP2 (UP Squared) SBC contains a quad core 1.8 or 2.5 GHz Intel processor, 8 GB of DDR4 RAM, 128 GB of Internal storage, Gigabit Ethernet, 4K display, SATA3 (6 Gbps) port [27]. It can be advantageous in space-constrained areas with stringent performance requirement, however at a relatively high cost.

Table 1. SBC configurations released in [24,27,28,29,30,31,32,33,34,35].

Name	Platform	Processor	Ram	Storage	Connectivity
C.H.I.P.	ARM	1 GHz	512 MB	4 GB	WiFi, BT
Dragonboard	ARM A53	1.2 GHz × 4	1 GB DDR3	micro SD	WiFi, BT
Inforce 6309	ARM A53	1.2 GHz × 4	1 GB DDR3	micro SD	Ethernet, WiFi, BT
NanoPi NEO	ARM A7	1.2 GHz × 4	512 MB DDR3	8 GB	WiFi, BT
ODROID-C2	ARM A53	1.5 GHz × 4	2 GB DDR3	8/16 GB	Ethernet
Orange Pi Lite	ARM A7	1.2 GHz, × 4	512 MB DDR3	micro SD	WiFi
Orange Pi One	ARM A7	1.2 GHz × 4	512 MB DDR3	micro SD	Ethernet
Orange Pi PC Plus	ARM A7	1.6 GHz × 4	1 GB DDR3	8 GB, micro SD	Ethernet, WiFi
Orange Pi Plus 2E	ARM A7	1.6 GHz × 4	2 GB DDR3	16 GB, micro SD	Ethernet, WiFi, IR
Raspberry Pi 3	ARM A53	1.2 GHz × 4	1 GB DDR2	micro SD	Ethernet, WiFi, BT
UDOO X86 Adv	x86 Intel	2.24 GHz	4 GB, DDR3	micro SD	Ethernet
UDOO X86 A Plus	x86 Intel	2.24 GHz	4 GB, DDR3	32 GB, micro SD	Ethernet
UDOO X86 Ultra	x86 Intel	2.56 GHz	8 GB DDR3	32 GB, micro SD	Ethernet
UP	x86 Intel	1.92 GHz × 4	1/2/4 GB DDR3	16–64 GB, micro SD	Ethernet
UP2	x86 Intel	2.5/1.8 GHz × 4	2/4/8 GB DDR4	16–128 GB, micro SD	2 × Ethernet
Latte Panda	x86 Intel	1.8 GHz × 4	2–4 GB DDR3	32–64 GB, micro SD	Ethernet, WiFi, BT

presents detailed specifications of popular SBCs [24,27,28,29,30,31,32,33,34,35].

Raspberry Pi series SBCs have the deepest root and highest popularity of the above-mentioned SBCs in academia, industry and hobbyist. Numerous peripherals and sensor boards have been designed for Raspberry Pi to enhance their functionality and add additional features. These boards are compatible with most other SBCs as well. Most SBCs listed in Table 1 have general purpose input output (GPIO) pins (with different count) to accept external input, i.e., sensor data, etc. GPIO can also be used to interface external programs with SBCs for data processing and decision-making purposes. This makes SBCs a cost-effective automation solution for academia and researchers. SBCs are also suitable for wireless sensor network and IoT projects since both require portable, low cost and low power devices with wireless connectivity.

Table 2. Raspberry Pi series SBCs [24].

Name	Platform	Processor	Ram	Storage	Connectivity
Raspberry Pi 1 A/A+	ARM11	700 MHz	256 MB	micro SD	None
Raspberry Pi 1 B/B+	ARM11	700 MHz	512 MB	micro SD	Ethernet
Raspberry Pi 2 B	ARM7	900 MHz × 4	1 GB DDR2	micro SD	Ethernet
Raspberry Pi 3 B	ARM53	1.2 GHz × 4	1 GB DDR2	micro SD	Ethernet, WiFi, BT
Raspberry Pi Zero	ARM11	1 GHz	512 MB DDR2	micro SD	None

lists the configuration details of Raspberry Pi series SBCs [24]. It can be observed that the Raspberry Pi 3 Model B has the highest CPU, RAM, Wi-Fi and Bluetooth connectivity compared to its ancestors.

3. Test Bench Configuration

This section provides information on the test bench used to perform the simulation, including topology diagram depicting networking details, hardware, and software components. It also presents the detailed hardware specification of the computer system, LAN switch and Raspberry Pi 3 B, as well as software packages used to generate traffic and measure results. The information is vital since a slight change in hardware or software components may have a direct impact on the results produced.

3.1. Topology

In this paper, we evaluated the performance of Raspberry Pi 3 as an SIP server. The topology used for testing is quite simple, comprising a SIP client running SIPp tool as load generator, one Fast Ethernet (FE) Switch to provide Layer 2 connectivity and a SIP server based on Asterisk, as shown in Figure 2. An Intel-x86 laptop was used as SIPp client, while Raspberry Pi3 used as an SIP server.

3.2. Hardware

3.2.1. SIP Server (Rasberry Pi.3)

The hardware specifications of the SIP server are presented in

Table 3. Raspberry Pi 3 Model B (SIP Server) [24].

Raspberry 3 Model B
Processor	1.2 GHz 64-bit quad-core ARMv8 CPU
Memory	1 GB DDR2
Storage	micro SD (16 GB Card)
Network	Ethernet 100 Mbps
	Wi-Fi 802.11n
	Bluetooth 4.1 (BLE)
USB	2.0 × 4
Display	Full HDMI
GPIO	40 Pins
Audio	3.5 mm audio jack/composite video
Interfaces	Camera (CSI), Display (DSI)

. As can be seen from the table, Raspberry Pi 3 is equipped with 1.2 GHz quad core processor, 1 Gb DDR2 ram, Fast Ethernet port, Wi-Fi and Bluetooth for wireless connectivity. For server storage and OS purposes, an external storage or microSD card can be used.

3.2.2. SIP Client (Intel x86 Laptop)

An SIP client was implemented on an Intel x86 laptop using virtual machine and SIPp load generator. The hardware specifications of the laptop are shown in

Table 4. Laptop (SIP Client running SIPp tool).

Laptop
Processor	Intel Core i3 4010U @ 1.70 GHz
Memory	8.00 GB Dual-Channel DDR3 @ 797 MHz
Storage	500 GB Seagate (SATA)
Network	Ethernet 100 Mbps
	Wi-Fi: 802.11n
	Bluetooth
USB	2.0 × 1, 3.0 × 2
Display	Full HD
GPIO	USB interface for serial communication
Audio	3.5 mm audio jack
Interfaces	USB interface

, which include a Core i3 4th generation processor, 8 GB DDR3 ram, one Fats Ethernet port and 802.11n wireless connectivity. During all testing scenarios, the laptop utilization remained within the normal limits and did not experience any bottleneck.

3.2.3. Fast Ethernet Switch

Physical layer 2 connectivity between an SIP client and server was provided using D-Link 4port Fast Ethernet switch, as shown in

Table 5. Fast Ethernet Switch.

Switch
Vendor	D-Link
Speed	100 Mbps
Port	4

. During testing, interface utilization of each end nodes remained well below the port-allocated capacity.

3.3. Software

From the software perspective, an SIP client had Windows 10Pro x64 as the main OS. Within Windows 10, the VirtualBox was used to host UBUNTU x64 to provide Linux environment for an SIPp load generator, as illustrated in Figure 3.

On the Raspberry Pi 3 side, Linux flavor Debian Jessie (Raspbian) was used as main OS, while Asterisk11 was hosted within it as an open-sourced IP PBX and FreePBX13 as GUI interface, as demonstrated in Figure 4. RasPBX is a prebuilt image available on the internet based on the above-mentioned software and was used during testing.

4. Simulation Methodology

Software-based traffic generators are commonly used in development environment for software or hardware bugs testing before releasing to production. In the industry, regression and soak testing frequently employ such traffic generators to emulate real-world traffic before commercial release. Since IP PBX also delas with live calls (TDM/VoIP), to perform benchmark testing, we used a load generator (SIPp) to initiate simultaneous VoIP calls. For the purpose of this paper, we explored the following VoIP codes, i.e., G711a, G711u, G722, G729, GSM and iLBC.

SIPp Load Generator

SIPp is a simple testing tool that allows executing SIP stone scenarios to generate an SIP load on destination server. It contains some basic scenarios prebuilt within the system and can support custom scenarios using an .xml file [36]. Testing can be performed with or without transmitting RTP packet in SIP calls. However, if the RTP need to be transmitted during testing to make it look more real, a dedicated .pcap file for each codec need to be placed in /pcap directory within SIPp installation [37,38,39].

In this paper, we prepared custom scenarios for each codec to generate simultaneous calls with the RTP. Figure 5 presents a sample SIPp interface (during testing) indicating the different testing parameters, i.e., call rate, per call duration, total calls processed, test run time, RTP packet transferred, SIP messages count exchanged and remote host IP. Figure 6 illustrates the test statistics returned by SIPp after the completion of the test. It includes the test elapsed period, call rate, incoming/outgoing/concurrent calls, response time and calls length.

The simulation for each codec was run for about 10 minutes, starting from 2 calls per second (cps) with a constant duration of 5 seconds for each call. This makes the initial concurrent call to be 10 as shown below:

Calls Per Second (CPS) * Each Call duration = Total Concurrent Calls

i.e., 2 calls per second * 5 seconds = 10 concurrent calls or 4 calls per second * 5 seconds = 20 concurrent calls.

Later, we increased 2 cps every minute, which added 10 calls each time, thus making the concurrent calls to be 100 after 10 min. SIPp terminal command used to start testing is presented below:

./sipp -sf uac_pcap_g711u.xml -i 192.168.1.4 -s 100 -r 02 -rp 1000 192.168.1.3 -d 5000 -trace_stat -trace_rtt -stf Stats_g711u.csv

where “uac_pcap_g711u.xml” is the name of the custom scenario file, which is different for each codec; “-i 192.168.1.4” and 192.168.1.3 are the source and destination IPs, respectively; “-r 02 -rp 1000” signifies 02 calls per 1sec rate; “-d 5000” means the duration 05 sec for each call; and “-trace_stat -trace_rtt” represents the SIPp to log stats and RTT followed by the log file name.

5. Results and Discussion

This section presents test results for different performance metric, for instance, CPU load (1 min average), memory utilization, network load, disk usage and round-trip time (RTT). A custom-built Linux script was used on the Raspberry Pi 3 to measure CPU, memory and disk and network utilization, while RTT is measured at the SIP client using the SIPp built-in feature.

5.1. CPU Load

CPU load is an important metric to check system performance during busy hours. Figure 7 depicts the CPU load (1 min average) for G711a, G711u, G722, G729, GSM and iLBC codecs. From the graph, we can observe that CPU utilization by iLBC codec increased exponentially, consuming 58% CPU 100 calls, and the behavior was inconsistent across different datapoints. The rest of the codecs showed a linear increase in CPU with respect to number of calls, but none exceeded more that 12% throughout the testing. H264 codecs could not extend beyond 70 calls due to its high memory utilization, which made the system unresponsive. The above results show that, to achieve a higher CPU efficiency, the right choice of the codec is important.

5.2. Memory Utilization

Memory utilization is another important factor that can create a bottleneck in a live system. Figure 8 presents the memory utilization for G711a, G711u, G722, G729, GSM and iLBC codecs. It is evident from the figure that the memory consumption of the H264 codec was greatest of all and topped at 70 calls, which forced the test to stop. For G711a/G711u, it maxed out at 94% after which the system started to behave inconsistently for rest of the codecs; the behavior was linear and memory utilization of the Raspberry Pi increased with the increase in the number of calls.

5.3. Network Load

The network load for different codecs is shown in Figure 9. RTP codecs differ in their data rates based on internal compression. Some require a high data rate to offer premium quality, i.e., 64 Kbps for G711a & G711u, while others can accommodate a large number of calls in the same bandwidth, i.e., 8 Kbps for G729.

Table 6. Voice codec data rates [40].

Codecs	Data Rate
G711a	64 Kbps
G711u	64 Kbps
G722	64 Kbps
G729	8 Kbps
GSM	13 Kbps
iLBC	13.3 Kbps

lists the different voice codecs data rates:

Figure 9 shows the bandwidth utilization of each codec in terms of the transmitted (TX) and received (RX) bytes. It can be seen from the below graph that the maximum bandwidth was consumed by G711a and G711u codecs, which is relatable as they operate at 64 kbits/s rate and offer the least compression. This can also be seen from the following graph, as both codecs roughly generated around 400 Mbps at 100 calls. The lowest bandwidth consumption was observed in the iLBC codec, which remained below 50 Mbytes at 100 calls. The reason for iLBC consuming less bandwidth than G729 could be due to the fact that iLBC require less bandwidth after encapsulation at the Ethernet level [40]. The high memory utilization of H264 restricted it to 70 calls after which the Raspberry Pi became unresponsive. Bandwidth utilization can be minimized with the use of either high compression codecs, such as g729 and iLBC, or with the use of hardware equipment that offers 1:N E1/T1 compression capability.

An interesting observation obtained from following figure is that the TX and RX graphs follow the same pattern, which is true for real-time voice communication. Another observation is that there is a slight shift in the TX and RX data line, which is due to the round trip time as Tx data takes some time to reach the destination and return; hence, the RX data follow the same but slightly shifted trend.

5.4. Round Trip Time (RTT Max)

The round trip time (RTT) is the time taken for a packet to be send to its destination and its acknowledgement being received. RTT is an important KPI in VoIP to measure communication link quality. A low rtt is desired in almost all cases since it provides better quality, while a high rtt may cause retransmission and delay the communication. The RTT in our experiment was measured through the SIPp tool using the built-in feature. Figure 10 depicts the average RTT values for the G711a, G711u, G722, G729, GSM, H264 and iLBC codecs. The max rtt was observed for the iLBC codec, which increased exponentially as the number of calls exceeded 40. Although the iLBC codec calls went up to 100 during testing, their round-trip time was only captured up to 80 calls by the SIPp tool, probably due to the increasingly high values and thus we only plotted up to 40 calls for simplicity.

Among other the codecs, the max rtt of 78 ms was observed for the G722 codec @100 calls, while H264 showed the lowest, at 92 ms@100calls. VoIP communication can tolerate a packet delay up to 300 ms without being notice by the end user; higher than this, the voice quality started to deteriorate.

5.5. Disk Usage

Disk utilization for different codecs during testing was captured and is presented in Figure 11. A slight variation in disk usage was witnessed during testing; however, no major impact was observed with an increase in calls for the different codecs. In general, disk utilization remained at less than 80% without calling load and went as high as 87% for the H264 codec at 70 calls.

6. Conclusions

In this paper, we discussed the evolution of IP PBX over time, and its popularity among organizations due to its cost effectiveness, high scalability and hardware-friendly nature. Subsequently, tiny computing platforms (SBCs) were discussed, which can emulate the functionality of a complete desktop PC. SBCs are usually equipped with enough processing power to automate a small project requiring mid-to-low-level processing resources. Then, we explored the implementation of a small IP PBX on the Raspberry Pi3 Model B, which can support a few dozen calls. Finally, load testing was performed on the IP PBX using SIPp load generator tool. A comparative analysis was performed for performance metrics CPU, memory, disk, network utilization and round-trip time for different codecs. The meticulous review of statistics for CPU and memory revealed that, at 100 simultaneous calls, the CPU load for G711a, G711u, G722, G729, GSM and H264 remained within 15%, while iLBC showed an exponential rise after 40 calls. At the same load, the memory utilization for most codecs approached 95%, which led towards system instability and higher response times. It was also noticed that, with less than 50 concurrent calls, memory utilization remained steady; however, as calls increased, a rapid growth was seen in memory consumption. The RTT analysis depicted extremely a high delay for the iLBC codec over 40 calls. In addition to this, G722 at 100 calls encountered the highest rtt at around 78 ms, whereas the lowest was seen for H264 at around 12 ms. For most of the other codecs, it remained within 50 ms@100calls. Disk utilization remained stable throughout the test and did not show much variation across the different codecs. Moreover, an IP PBX embedded on the Raspberry Pi3 SBC provides a tiny platform that can be used in several applications such as military, disaster management systems or generating a small-scale network for quick linkage among users.

Based on the present results, it can be suggested that IP PBX implemented on a Raspberry Pi 3 can adequately serve a small number of concurrent calls with the right codec choice, which make it suitable to be used at home, school, small offices or in applications requiring a portable ad hoc communication system for low-traffic handling.