1 Performance evaluation of the Asterisk PBX Luís Sousa Instituto Superior Técnico Av. Rovisco Pais, Lisboa, Portugal Abstract Currently PBX (Private Branch exchange) are an almost indispensable tool in the enterprise world. The PBXs allow employees to make connections among the internal telephones of an enterprise and also connect them to the public switched telephone network (PSTN). With the increased use of Internet, there is a need to understand what are the services offered, how to configure and evaluate the performance of a PBX with support for voice over IP (VoIP). The Asterisk PBX is a cost free and open source software for Linux, which supports multiple protocols (SIP, SCCP, H.323, IAX2, etc). The main focus of this dissertation is the Asterisk software, which is described in detail. Instructions about installation and configuration are given and results of tests with various configurations with the aim of evaluating the performance of the Asterisk PBX are presented. 1 Introduction The increase use of the Internet has made arise various technologies of voice over IP (VoIP). Comparing with traditional telephony (circuit switched), the VoIP is more scalable, has the ability to reduce costs and allows the integration of new features. In a data network perspective, the VoIP has become the voice in "only" one more application. Regarding a traditional PBX system, a VoIP PBX allow beyond existing functions, new ones, like connect employees that work from home with office PBX on broadband connections, easily connect offices in different geographic locations, offer voic integrated with account. These features are performed using the Internet or through a private IP network. In this dissertation are examined in some detail, issues that should be taken into consideration to implement a VoIP PBX system, more specifically the Asterisk PBX, as well as questions about your performance. The Asterisk PBX is a cost free and open source software for Linux, which supports multiple protocols (SIP, SCCP, H.323, IAX2, etc). The Asterisk allows both the use of phones in software and VoIP telephony devices. A point to point call means that there is a user (calling party) that calls to another user (called party) and establish a telephone call. A conference call is a telephone call in which the calling party could have more than one called party that could enter or exit at any time in a conference, since conference call is active. In an interactive voice response, or IVR, Asterisk PBX as the ability to answer the call and interact with the callers with pre-recorded audio to further direct callers on how to proceed. In different scenarios is analyzed the performance of Asterisk PBX depending on the type of sound encoding used, number of simultaneous calls and number of calls per second. Parameters such as: the load on the network, use of computer resources (CPU and memory) and response time of the Asterisk PBX, are measured.
2 2 Voice Over Internet Protocol (VoIP) Voice over IP, or VoIP, can be defined with a set of technologies and components that together provide to a user the possibility of establishing voice calls through the Internet or other packet-switched networks. Through VoIP we can get several additional services beyond voice calls, such as voic , fax, IVR (Interactive Voice Response), conference calls, instant messaging, etc. In order to allow the existence of these services there are set several protocols, such as, SIP (Session Initiation Protocol), one of the signaling protocols most used in VoIP, RTP (Real Time Transport Protocol), which helps to ensure the transmission of packets in real time applications and SDP (Session Description Protocol) a protocol that provides a standard representation for describing streaming media initialization parameters. To analyze the performance of a VoIP software, such as the Asterisk PBX, we must understand what are the network conditions that may adversely affect the performance for VoIP. These are mainly the latency, jitter and packets loss. The latency is the time that a packet takes to travel from one point A to point B network. The jitter is the variation of latency on a range of packages. The packet loss is the number of packets sent from a given point of the network that never reach the point B. Due to the audio in VoIP be sent in real time by UDP, a packet that is received out of order is discarded.  In VoIP, codec (a combination of Coder - decoder), can be defined as an algorithm used to encode and decode voice streams. Codecs are used to convert an analog voice signal to digitally encoded version and vice versa. There are several ways to encode and decode the streams of voice. Codecs can vary in the sound quality, the bandwidth required, the computational requirements, etc.  3 PBX Asterisk The Asterisk is a cost free open source software for Linux, developed by Mark Spencer. This software gives full functionality of a PBX (Private Branch exchange) traditional and provides additional features such as IVR (Interactive Voice Response). The Asterisk is essentially a VoIP PBX that supports multiple protocols used in VoIP (SIP, SCCP, H.323, IAX2, etc.). Asterisk allows the use of software phones and VoIP telephony devices. With Asterisk is also possible inter-operate with the traditional telephone systems, in this case additional hardware is needed.  4. Analysis and traffic capture software One way of assessing the performance of the PBX Asterisk, is using tools, usually in software, which allows the capture of packets (sniffers). The use of these kinds of tools can also diagnose errors, producing statistics and have a graphical view of traffic flow data (for the PBX Asterisk, the data traffic mostly VoIP) in network. A software tool for capturing and analyzing traffic data is the Wireshark . The Wireshark has a simple and intuitive graphical interface, and also be used in a text-only mode. To test the SIP performance in Asterisk PBX there are several software tools, such as SiPP , a software developed by HP and its main features are: SIP basic scenarios included, ability to create complex SIP scenarios by changing the files in XML format, producing a set of statistics in real time, TCP and UDP transport, possibility of dynamically adjust the load of calls and the possibility of sending RTP traffic. 5 Performance evaluation of Asterisk PBX 5.1 Point to point calls In the scenario of point to point calls, when a user (calling party) makes a call to another user (called party), the Asterisk PBX routes the call to a called party that as been set previously and "negotiate" the codec the his want to use. Asterisk PBX acts as an intermediary in the call. The aim of this test is to understand what the maximum number of simultaneous calls that the Asterisk PBX supports, and what impact when it is necessary to make transcoding, that is, make possible the communication between two terminals even if they do not use the same voice codec.
3 To evaluate the performance of point to point calls, load tests were conducted. That was used 5 computers connected in network through an 8 port 10/100 Mbps hub. The first series of test was performed based on PBX Asterisk installation of a computer with a 2.6 GHz Pentium Celeron processor. Then tests were performed using a weakest computer, a Pentium 350 MHz. The configurations of the remaining elements of network are: a computer that generates SIP calls, using the Sipp application in order to load the Asterisk PBX. There was another computer that acts as SIP call receiver, running the Sipp application. Finally there is also a computer that captures all traffic on the network. Figure 1 illustrates the network configuration used and the characteristics of each computer. Figure 1. Network connections and description of elements used in point to point calls. In load tests performed, the Sipp application Sipp is configured to generate SIP calls and another computer was configured as a SIP call receiver. Figures 2 show the flow of SIP and RTP messages expected. Figure 2. SIP and RTP flow messages, used in point to point calls When a caller (SIP call generator) makes a call the extension , that was routed to the recipient (SIP call receiver), then the caller transmits RTP voice traffic for 60 seconds, which may be encoded in several ways: G711a, GSM, ilbc or Speex. The recipient receives the voice traffic and echoes it back to the sender. The Asterisk PBX allows the codec used by the sender to transmit the voice traffic to be different from that recipient use/support, in this case the Asterisk PBX is responsible for transcoding of codec. In load tests, are generated three calls per second. The variable parameter is the number of simultaneous calls which serves to test the limit for which there is no retransmission of messages due to timeout, for lack of response from the Asterisk PBX.
4 Results: We conducted several tests lasting about 3 minutes. Codec G711a Speex Gsm ilbc Max. Simultaneos calls Duration of test (seconds) 223,02 226,75 224,58 229,55 Total calls Network information Downlink (MB) 457,90 224,00 193,90 172,70 Uplink (MB) 456,9 223,4 193,4 172,3 Network load DownLink 17,23 8,29 7,25 6,31 (Mbit/s) UpLink 17,19 8,27 7,23 6,30 RTP voice streams Jitter (ms) Average 5,59-6,74 - Latency (ms) Average 44,86 276,45 73,3 76,34 Number of RTP streams analyzed Nº RTP streams with loss % average lost RTP stream 0,2 2,77 0,51 4,7 System PBX Asterisk % CPU 74,1 70,41 72,23 65,42 Table 1. Results for maximum simultaneous calls in point to point scenario. Graphic 1. Maximum number of simultaneous calls obtained for the different codecs, with the Asterisk PBX running on a standard PC. Analysis of results The use of different codecs in the transmitter and the receiver implies a significant increase in processing because the need to transcode voice traffic for Asterisk PBX. The biggest processing means more consumption of resources (mostly CPU) in a computer running Asterisk PBX. With the increased consumption of CPU to perform transcoding of codec's, the number of simultaneous calls supported by Asterisk PBX is greatly reduced. When using only the codec g711 in a call, the Asterisk PBX supports the maximum of 125 simultaneous calls. In cases where the sender uses the codec g711a and receiver the GSM codec (or vice versa), the number of simultaneous calls supported by Asterisk PBX is 50. In other words, 60% fewer calls. When the same codec is used, g711a, Speex, ilbc or GSM, we can see that the largest number of simultaneous calls that supports the Asterisk PBX is linked to the number of bytes required to transmit information of voice, a less complex voice codec, consume higher bandwidth to transmit voice information. In the case of using the codec g711a a call, the PBX Asterisk supports 125 calls simultaneously. But if a codec is used more complex,
5 that is, the more it compresses voice, such as ilbc codec, the PBX Asterisk supports 145 simultaneous calls, plus 13.8%. According to the G.114 recommendations  the maximum values for latency, 400 ms, and the recommended value of 150 ms are not exceeded. To minimize jitter the destination application should have a buffer that rearranges the timely order of the packets, and is sized to take into account a certain range of network delay variation. 5.2 Conference calls In a conference call scenario, when a user makes a call to an extension, the Asterisk PBX routes the call to a "room" conference previously set in the system, depending on the configuration for an extension may be asked to issuing the call the insertion of a code to access the conference. In the tests, when a user enters a conference, remains connected for 1 minute, during which is generated voice traffic. This is the worst possible case. To complement this test different codecs are used in various tests. We want understand the performance of the Asterisk PBX in a conference call scenario. Determine the maximum number of simultaneous calls, i.e. maximum number of users that a conference "room" supports. And also what that happens when there is more than a conference. To make conference calls using Asterisk PBX is needed a MeetMe module, which needs the time source to work. There are hardware devices developed under the project Zaptel , suitable for this purpose. However, we can create a virtual timer, ztdummy , which uses kernel resources to achieve the same effect only with software. To evaluate the performance of point to point calls, load tests were conducted. That was used 4 computers connected in a networked through an 8 port 10/100 Mbps hub. The tests were carried out based on Asterisk PBX installation of a computer with a 2.6 GHz Pentium Celeron processor. To generate SIP calls are used two computers, running a total of 4 instances of the application Sipp. Figure 3 illustrates the network configuration used and the description of each computer. Figure 3. Network connections and description of elements used in conference calls. When a user (SIP call genarator, application Sipp-mode client) makes a call for extension 8500, 8600, 8700 or 8800, are routed to a "room" for the conference. If it is the only participant in the conference, the user is advised by the Asterisk PBX, if already are other users in the conference only hears a tone. The tone is also sent to all participants at the entry or exit of a user in the conference call in progress. Figures 4, illustrates the flow of SIP and RTP messages, as the load tests conducted for conference calls.
6 Figure 4. SIP and RTP flow messages, used in conference calls. Tests were carried out over a period of approximately 3 minutes. This figure is not accurate because the client Sipp "expects" that all outstanding calls end (soft exit). The variable used to test the system load is the maximum number of simultaneous calls. That are generated in all tests two calls per second. Each call is the approximate duration of 1 minute audio voice over RTP plus SIP signaling, on average 01:00:027 minutes per call, as the test for point to point calls. Results: Network load (Mbit/s) Simultaneously conferences Codec Max. Simultaneously calls Total Bytes Received (Mb) Bytes Transmitted (Mb) DownLink UpLink Duration time (sec.) 1 G711a ,13 5, Gsm ,7 36,2 1,53 1,47 206,57 1 ilbc ,6 0,77 0,76 196,18 1 Speex ,4 14,6 0,77 0,64 191,13 4 G711a , ,93 4,63 188,62 4 Gsm ,2 29 1,36 1,31 186,2 4 ilbc ,1 11,9 0,55 0,54 183,62 4 Speex ,4 14,1 0,8 0,65 183,65 Table 3. Statistics of network information obtained by the command ifconfig and summary of the application Sipp. Graphic 2. Comparison of the number of simultaneous calls obtained by the number of conferences simultaneously.
7 The conference calls require that the system transcode the audio received from various sources in linear PCM, then mix all audio streams, to finally recode for multiple output streams. If the codec is more complex, i.e. compresses more audio voice, that will be greater processing required in this process. The codecs that use higher compression (have lower load on the network), but the number of calls simultaneously supported a conference is lower. With the increased number of conferences, the total number of calls with Asterisk PBX decreases, which is expected because each conference requires some processes. Even in cases where there is only one conference results as regards the number of calls at the same time are significantly lower than the figures obtained in the scenario calls for point to point, to the codecs, g711a, gsm, Speex, ilbc, we have least 28%, 61.5%, 84.61% and 79.31% simultaneous calls, respectively. This difference can be explained with the processing required for conference calls made on the first point. Comparing the results can be concluded that the main limitation of the number of simultaneous calls is the ability of processing (CPU). The factor that contributes most to the increase in processing is the complexity of the codec. 5.3 Interactive Voice Response (IVR) In Interactive Voice Response (IVR) scenario configured to evaluate the performance of the Asterisk PBX, when a user makes a call to an extension, the Asterisk PBX answer the call. Through a pre-recorded audio, then are given to user several options to choose from a voice menu, which can be selected using the DTMF tones (dual-tone multi-frequency) (the phone keys). In this scenario the tests are divided into two parts. The first part of the scenario used, IVR user needs only a DTMF tone (the key phone 1) to be selected an option from the menu. In the second part, to select the option user must send five DTMF tones, the (the key phone 5, 4, 3, 2 and 1). The aim is to ascertain what impact caused when several DTMF tones are used in an IVR context. In IVR test scenario, voice traffic only use g711a codec. SIP calls generator, Sipp application in client mode, is structured as follows: When user makes the connection Sipp to extension 2000, the Asterisk PBX returns the following menu of voice: - Main menu - Press zero for help - To hear your account balance - Press one In first part: the SIPp client choose DTMF tone 1. In second part: the SIPp client chooses the DTMF tones The balance of your account is. To evaluate the performance of IVR calls, load tests were conducted. That was used 4 computers connected in a networked through an 8 port 10/100 Mbps hub. The tests were performed based on Asterisk PBX installation of a computer with a 2.6 GHz Pentium Celeron processor. Finally, as the previous tests, there is still a computer that captures all traffic on the network. Figure 5 illustrates the network configuration used and the description of each computer. Figure 5. Network connections and description of elements used in IVR.
8 In load tests performed, the application Sipp is configured to generate SIP calls. Figure 6 illustrate the flow of messages SIP and RTP, according to tests performed to load the IVR calls. The time to pause, PAUSE [6s] and PAUSE [1,4 s], refers to the time for which the generator machine is receiving audio RTP from Asterisk PBX, for 6 seconds and 1,4 seconds respectively. The time to pause, PAUSE [0,2 s], want to simulate the time it would be necessary to wait between the input of DTMF tones. In this case 0,2 seconds. Figure 6. SIP and RTP flow messages, used in IVR. Results: Calls per second Total calls Duration of test (seconds) 188,69 188,86 188,92 188,96 188,96 189,07 Network information Downlink (MB) 2,3 4,5 6,8 9,1 9,9 10,7 Uplink (MB) 46,2 92,5 138,9 184,5 199,6 213,1 Network load Downlink 0,10 0,20 0,31 0,41 0,44 0,48 (Mbit/s) Uplink 2,06 4,11 6,17 8,19 8,86 9,46 RTP voice streams Jitter (ms) Média 65,22 64,9 66,27 24,89 65,74 66,13 Latência (ms) Média 22,79 22,63 24,01 24,89 24,46 24,3 System PBX Asterisk CPU (%) 40,29 74,38 87,7 92,82 95,98 96,51 Table 3. Statistics obtained for testing IVR (5 DTMF)
9 Graphic 3. Percentage use of CPU depending on the number of calls generated per the second. Analysis of results Analysis of results Throw the graphic 3, we could see that the load test made to the IVR scenario to a 1 DTMF tone Asterisk PBX supports more 3 calls per second than the scenario that 5 DTMF tones are used. This is due to the fact that the processing 1 DTMF tone requires less processing than the 5 DTMF tones that should collect and interpret more RTP data, so that the limit is reached earlier than Asterisk PBX. The values of the order of 100 ms in jitter were found in the transmission of the DTMF tones, making the average of jitter rise. However, results for the jitter and latency obtained quite satisfactory and acceptable to VoIP, as explained in the analysis of results for the calls point to scenario. 6 Conclusions and future work By conducting these tests we can get a sense of the potential that the PBX Asterisk PBX VoIP presents as a VoIP PBX. The main key about VoIP calls is to realize what percentage of traffic will require intensive processing due to high compression codecs, in the case of the performance tests conducted, the gsm, Speex and ilbc codecs. A 2.6 GHz CPU support 125 calls G.711 without transcoding, and could rise to 145 for codecs that require less bandwidth, such as the ilbc codec. If there is transcoding, the processing in Asterisk PBX significantly increases and the number of calls supported is 50 in the case of transcoding G711 to GSM, falling to 15 in case of transcode voice in a call with ilbc to Speex, two codecs with low bitrate, which means more processing to compress the voice. If there is a conference, the number of G.711 calls supported drops to 90, and down to 20 when using the Speex codec that requires less bandwidth, but requires the greatest processing. With another conference in parallel, the number of calls G.711 supported in each conference are 40 and 10 for Speex. This number decreased if more conferences arise, given that each conference requires some processing itself. When the Asterisk PBX has IVR services, are supported 17 G.711 calls per second in a case where only 1 DTMF tone is required to select an option. If they are required 5 DTMF tones to select an option, the number of calls per second decreased to 14. In the case of a limited computer with a CPU at 350 MHz, we have 55 that are supported G.711 and calls for a codec that requires less bandwidth, ilbc, we get 65 calls. The maximum number of calls supported by the system is heavily dependent on the codec used. With the technology available today, computers with greater processing power (CPU's with 2 and 4 cores), the values achieved are easily overcome, since the system most requested feature is the processor. As the PBX Asterisk is an open source software, with great acceptance, there is a large community of users and various testimonies of practical implementations of Asterisk systems that can be found on the Internet. Contributing to the increase of the existing documentation, fixing any existing bugs and developing new modules to increase functionality. For example, modules that allow to monitor what happens in Asterisk PBX via a Web interface, modules for creating dial plan graphically in a simple, drag and drop icons. One important point that is not addressed in this dissertation is the Mean Opinion Score (MOS) - measuring the quality of voice, in different points of the load system. This is a good topic for future work. Another topic of interest that was not tested due to the characteristics of the application Sipp, is examining the performance for point to point calls in that the audio is sent directly between the phones, reducing the load on the Asterisk PBX, when there is no transcoding.
10 Integrating the Asterisk PBX with the Ser , could be interesting for analyzing the performance of Asterisk when SER processing of signaling. When there is more than an Asterisk server, integration with the SER is also interesting because it allows, load balancing, allows the creation of redundant system and is responsible for making the registrations SIP in a scalable manner. As a supplement Asterisk PBX can be connected to VoIP provider over broadband Internet, which allows calls to the public switched telephone network (PSTN). Check the performance of the PBX for those calls, in addition to internal calls tested in this dissertation. And analyze the performance for other scenarios than the three discussed here. References: 1. Switching to VoIP, Theodore Wallingford, O Reilly, 30/06/ SIP: Session Initiation Protocol, J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler. IETF RFC 3261, Junho de 2002, 3. SDP: Session Description Protocol, M. Handley, V. Jacobson, C. Perkins, IETF RFC 4566, Julho de 2006, 4. RTP: A Transport Protocol for Real-Time Applications. H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. IETF RFC Julho de 2003., 5. Asterisk: The Future of Telephony, Jared Smith, Jim Van Meggelen, Leif Madsen, O Reilly, Multimedia Communication: Directions and Innovation, Jerry D. Gibson, Academic Press, Outubro de Voice over IP Fundamentals, Jonathan Davidson, James Peters, Manoj Bhatia, Satish Kalidindi, Sudipto Mukherjee, Cisco Press, Agosto de Building Telephony Systems with Asterisk, D Gomillion, B Dempster, Packt Publishing, 30/09/ VOIP Wiki - a reference guide to all things VOIP, 10. Homepage Asterisk Netweb s Asterisk Guide for Newbies, 13. The Asterisk handbook version 2, Wireshark Sean Walberg, Expose VoIP Problems Using Wireshark, Linux Jornal, 01/03/2007, 16. Sipp SER One-way transmission time. ITU-T Recommendation G.114, Maio de Zaptel (Zapata Telephony) Asterisk timer ztdummy -