VoIP Articles & Tutorials

Determine the maximum capacity of an Asterisk PBX

30 Jul 2012

Sometimes, determining of the maximum processing capacity of an Asterisk server is a mandatory requirement. In most cases, the maximum processing capacity signifies the maximum number of calls that a certain server (in a specific hardware and software configuration) can support. A generally applicable formula to compute processing capacity cannot be used because X86 servers available on the market differ vastly, both in hardware and software. VoIP proprietary PBXes usually provide maximum capacity, computed based on the installed hardware resources, thus having a competitive advantage as compared to open-source Asterisk servers.

Asterisk performance tests are based on the subjective analysis of the audio channel while the number of simultaneous calls is being slowly increased. It is an empirical method, usually conducted manually. In the absence of specific call parameters that potentially show the decrease of quality over the audio channel, a method has been developed which evaluates the capacity of an Asterisk server in several steps: check the real duration of a 1 second pause (empirical sign of a server overloading), check the medium duration until an answer is received after sending SIP INVTE type messages (the RTT parameter is evaluated – Round Trip Time) and check the call quality by recording it into a second Asterisk server. If all these tests yield satisfactory results, it is considered the server under the measured load can process additional calls.

This method is not perfect (because it is empirically obtained) yet it offers the possibility of automating testing sessions. In what follows we wish to minutely describe this testing method developed by Modulo Consulting, as well as providing the results obtained.

Method Description

In the diagram below we can observe how testing is carried out: the Asterisk server runs on device A and the VoIP call simulator runs on device B (we used only SIP calls).An auxiliary Asterisk server runs on device B, used for validating the audio quality of the control call channel.

Diagrama load test program

In order to generate controlled SIP we used the open-source SIPp package, initially running two sipp [1] instances: the call generator (client type configuration: uac_pcap, alaw codec) and the answer engine (server type configuration: uas, ulaw codec). These configurations are already included in the SIPp package and offer a minimal transcoding scenario between the 2 G.711 codecs. The scenario is simple: the call generator (sipp_2 user) calls a certain extension from the Asterisk server, and the call is answered by the answer engine (sipp_1 user). The call generator will play a prompt and the answer engine shall function in “echo” regime (resending everything that it receives). The result is a close simulation of a real (duplex) call conversation (in which both partners talk).

In order to generate calls with or without transcoding to the GSM codec, the configuration of the answer engine has been changed. The new configuration is uas.modulo.xml. It has been also noticed that RTP packets which are included in the SIPp packet (for example g711a.pcap) are 240 bits long, which is bigger than the length with which the Asterisk server works (160 bits = 20 ms x 8000 bits/second). This means that for every 2 packets of 240 bits received from the call generator, 3 packets of 160 bits are sent to the answer engine, which translates into additional traffic and loading of the server. In order to make tests as close to reality as possible we used RTP packets of 160 bits and we recorded [4]  in a pcap file (dtmf.1234567890.G711_PCMU.pcap) a call of approximately 10 seconds (ulaw format) which contains the DTMF 1234567890 codes plus a standard Asterisk prompt (hello-world). In order to use this file we changed the call generator setup. The new setup is uac_pcap.modulo.xml. Another change was made to the length of the call: from a fixed length of 9 seconds to a variable length, between 10 and 15 seconds thus realizing a more natural distribution of calls.

The Asterisk configurations (SIP setup and call logic) from server A have been modified in order to make possible codec selection, through which the answer engine will respond to the call generator. Thus, depending on the extension called by the call generator, a specific SIP user for which only one type of codec is valid, is chosen as destination:

  • 1002 => sipp1_gsm = codec gsm =>ulaw transcoding into gsm;
  • 1003 => sipp1_ulaw call = codec ulaw =>without transcoding (ulaw to ulaw);
  • 1004 => sipp1_alaw call = codec_alaw =>ulaw to alaw transcoding.

The examination of a sip instance can be made locally (from the console in which it was initiated) or from distance thus making possible the insertion of a control mechanism of the call generator. The control is made through the sipp-controller.sh script which runs on device B. This script also has the role of saving statistical data sent by the script which launches the test on device A (start-test.sh).

The roles of the two scripts are detailed below:

  • start-test.sh - runs on the devices which is tested (A) and awaits commands (on the TCP 8880 port) from the sipp-controller.sh control script
    • it initiates a new test session;
    • periodically:
      • it gathers and sends useful information for later analysis (processor loading, free memory, number of simultaneous calls, etc.);
      • it evaluates the length of 1 second pause compared to 2 decision levels (configurable through SLEEP_L1 and SLEEP_L2 parameters);
        • up to 1.15 seconds (15% growth) the test is considered passed, the number of simultaneous calls being able to grow;
        • between 1.15 and 1.25 seconds (25% growth) the test is considered passed but the number of simultaneous calls should not grow further;
        • above 1.25 seconds the test is considered failed, and the number of simultaneous calls should decrease;

          Note: The values of the two decision levels are chosen arbitrary by the testing team, with the scope of obtaining an acceptable administration level of the tested Asterisk server when it is overloaded.

      • It sends the gathered information and the evaluation decision to the sipp-controller.sh control script.
      • It tries to detect a command of reducing the number of simultaneous calls and stops the test if the counter reaches value 5 (configurable through DOWN_MAX parameter);
  • sipp-controler.sh - runs on the device auxiliary to the test (B) and awaits commands
    • upon the initialization command of a new test session, it starts two sipp instances (the call generator and answer engine)
    • for each set of received data:
      • The medium RTT length for a number of 10 INVITE SIP calls is evaluated. This is made through a third sip instance, which runs with the default uac client scenario. The calls made by this instance are sent to the same answer engine, similarly with the calls generated by the call generator instance;
      • After evaluating the medium RTT length, this value is compared to two levels set in the testing (configurable through SIPP_RTT_L1 and SIPP_RTT_L2 parameters): 100% and 125% from the SIPP_RTT_MAX parameter value used in the initialization of the test session;
        • If the value does not exceed 100%, the test is considered passed, the number of calls being able to grow;
        • If the value exceeds 125%, the test is considered failed, the number of calls being obliged to decrease;

          Note: The recommended value [5] for SIPP_RTT_MAX is 100 ms and the two levels had been arbitrary defined by the testing team in order to ensure an interval in which no decision is made.

      • It launches a control call with the purpose of evaluating the quality of the audio channel. The call is initiated and registered by device B, through a “call file", type mechanism, by calling an extension of the tested Asterisk server which runs in “echo" regime. From device B a random prompt is played (standard Asterisk hello-world prompt has been chosen) . When the call is finished, the file which contains the recording of the audio channel (sent by Asterisk) is checked. The check is made through a simple method: if the length of the file is equal to the one detected in the beginning, the test is considered passed and the number of simultaneous calls may grow. If there is any difference, the test is considered failed and the number of simultaneous calls must decrease;
      • It saves (through syslog), the set of data received from device A and the corresponding set of data and results of the tests made on device B;
      • Depending of the test result, a decision on changing the number of simultaneous calls will be made;
    • Upon the test ending command:
      • It sends the stop command to the two sipp instances launched at the beginning of the test (call generator and answer engine);
      • It saves into a different file, located in /var/log , all information gathered by the respective test session.

As mentioned above, the test automatically ends after the detection of 5 decisions of decreasing the number of simultaneous calls. The test result is considered to be the next value lower than the lowest number of simultaneous calls for which one of the three tests did not pass.

In order to check this value one can later run a volume test. It will confirm whether the Asterisk server can support that specific number of simultaneous calls on a longer duration (for example 24 hours). The sipp instances can offer interesting statistics regarding the durations in which the SIP signaling messages have been processed and, more important, if any errors occurred during tests SIP signaling messages have been processed and, more importantly, if any errors occurred during tests..

Note:

  1. Besides determining of the maximum number of simultaneous calls correctly processed by the Asterisk server, other tests can also be imagined, like determining the maximum number of active calls in a conference, or the maximum number of conferences with 5 users.
  2. At any given time, in order to check the correct functioning of the server a MusicOnHold type call can be made, the quality of the audio call thus confirming if everything works properly or not.
  3. The testing must take into account the rather large traffic generated when using a G.711 type codec (~87 kbps [2] for each call, on both ways: RX and TX). That is why the estimated bandwidth must be checked against the capacity of network interfaces. Our recommendation is to install on both devices the same type of interfaces (Fast or Giga Ethernet Full Duplex) and to connect them through a proper switch. Using a router between the two servers will surely affect the tests by introducing delays in packet sending. Therefore we do not recommend such a connection.
  4. 4. Before test launch, it is recommended to check what is the maximum number of files a process can open (ulimit –n). This parameter is usually modified, in the initialization script of the asterisk application to a value that avoids limitations. We recommend to set this parameter to 4096, value which should ensure resources for processing a large number of calls. In order to check how many open file descriptors a certain process has (for example asterisk), we can use the following command:
	[root@tenora ~]# ls -l /proc/$(cat /var/run/asterisk.pid)/fd | wc -l

Installing the components

On Device B:

  1. Install the SIPp package

    This is done according the setup instructions which you can visit here. In our case we used a Centos server for which this package is already compiled. The installation was made through the EPEL project (more details on this service are available here.

    Note: in order to prevent conflicts between packages available through EPEL and other package distribution services we recommend installing the yum-plugin-priorities in order to prevent conflicts between packages available through EPEL and other services of package distribution we recommend installing the.

    rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
    yum install sipp
  2. Install the configuration for the call generator:
    cd /usr/share/sipp 
    wget http://www.modulo.ro/modulo/downloads/sipp/uac_pcap.modulo.xml
  3. Install the pcap file played by the call generator:
    cd /usr/share/sipp/pcap
    wget http://www.modulo.ro/modulo/downloads/sipp/dtmf.1234567890.G711_PCMU.pcap
  4. Install the configuration for the modified answer engine:
    cd /usr/share/sipp
    wget http://www.modulo.ro/modulo/downloads/sipp/uas.modulo.xml
  5. Install the main test control script:
    cd /usr/share/sipp
    wget http://www.modulo.ro/modulo/downloads/sipp/sipp-controller.sh
    chmod +x sipp-controller.sh
  6. Install the evaluation script for the call record created during the control call:
    cd /etc/asterisk/load_tests
    wget http://www.modulo.ro/modulo/downloads/sipp/eval-audio.sh
    chmod +x eval-audio.sh

On device A – test subject

  1. Install the initialization script of the testing session:
    mkdir /etc/asterisk/load_tests
    cd /etc/asterisk/load_tests
    wget http://www.modulo.ro/modulo/downloads/sipp/start-test.sh
    chmod +x start-test.sh

Configure the Asterisk A server

  1. Create test and control SIP accounts:
    [sipp_1](!)
    type=friend
    username=sipp_1
    host=<answer_engined_IP_address>
    port=5061
    context=sipp-test
    dtmfmode=rfc2833
    insecure=very
    canreinvite=no
    nat=yes
    disallow=all
    
    [sipp_1_g723](sipp_1)
    allow=g723
    
    [sipp_1_gsm](sipp_1)
    allow=gsm
    
    [sipp_1_ulaw](sipp_1)
    allow=ulaw
    
    [sipp_1_alaw](sipp_1)
    allow=alaw
    
    [sipp_1_g729](sipp_1)
    allow=g729
    
    [sipp_2]
    type=friend
    username=sipp_2
    host=<call_generator_IP_address>
    port=5062
    context=sipp-test
    dtmfmode=rfc2833
    insecure=very
    canreinvite=no
    nat=yes
    disallow=all
    allow=ulaw
  2. Create the test context:
    [sipp-test]
    
    exten => 001,1,Answer
    exten => 001,n,Echo
    
    exten => 002,1,Answer
    exten => 002,n,MusicOnHold
    
    exten => 003,1,Answer
    exten => 003,n,SendDTMF(1234567890)
    exten => 003,n,Hangup
    
    exten => 1001,1,Dial(SIP/sipp_1_g723,10,L(30000))
    exten => 1002,1,Dial(SIP/sipp_1_gsm,10,L(30000))
    exten => 1003,1,Dial(SIP/sipp_1_ulaw,10,L(30000))
    exten => 1004,1,Dial(SIP/sipp_1_alaw,10,L(30000))
    exten => 1008,1,Dial(SIP/sipp_1_g729,10,L(30000))
    
    exten => _3XX1,1,Set(SIP_CODEC=g723)
    exten => _3XX2,1,Set(SIP_CODEC=gsm)
    exten => _3XX3,1,Set(SIP_CODEC=ulaw)
    exten => _3XX4,1,Set(SIP_CODEC=alaw)
    exten => _3XXX,2,Answer
    exten => _3XXX,3,MeetMe(${EXTEN:0:1},cdM)
  3. Enable the configurations:
    asterisk -rx "reload"

Configure the Asterisk B server

  1. Create the control context:
    [sipp-control]
    exten => 700,1,Monitor(ulaw,rec-700)
    exten => 700,n,Playback(orig-hello-world)
    exten => 700,n,Hangup
    
    exten => h,1,NoOp
    exten => h,n,System(/etc/asterisk/load_tests/eval-audio.sh rec-700-in.ulaw <controller IP>
    <controller port> &)
  2. Enable the configuration:
    asterisk -rx "reload"

Testing

The test launch involves:

    On device B

  1. 1. Open a new terminal and launch the main script of the test:
    cd /usr/share/sipp/
    ./sipp-controller.sh <adresa_IP_a_masinii_B>

    The command line parameter of the sipp-controller.sh script is the IP address of device B that is used for the tests. Attention: do not use the local address 127.0.0.1!

    On device A

  2. 2. Open a new terminal and monitor the load (for example the top command).
  3. 3. Open a new terminal and start the test initialization script:
    cd /etc/asterisk/load_tests
    start-test.sh <FINAL_DEC>
                    <SLEEP> <SIPP_RTT_MAX>
    		<SIPP_CONTROLLER_IP>
    		<SIPP_CONTROLLER_PORT>
    		<ASTERISK_CALL_EXTENSION>
    		<ASTERISK_IP>
    		<ASTERISK_PORT>
    		<SIPP_UAC_RATE_SCALE>

The above mentioned parameters have the following significance (the default value is within brackets):

  • FINAL_DEC (4) =the counter value for which, on device B, the modification of the number of simultaneous calls activates;
  • SLEEP (15) = the pause (in seconds) made between two readings of statistic data and the evaluation of the “sleep 1” command
  • SIPP_RTT_MAX (100) = the duration (in ms) against which, on device B, the medium value of the RTT parameter is evaluated
  • SIPP_CONTROLLER_IP =the IP address of the device where sipp-controller.sh runs (device B)
  • SIPP_CONTROLLER_PORT (8080) =the TCP port where sipp-controller.sh script awaits commands
  • ASTERISK_CALL_EXTENSION (1002, 1003 sau 1004) = the extension which will be called by the call generator – it will be chosen depending on the type of transcoding test desired;
  • ASTERISK_IP = the IP address of the Asterisk server which is under tests (device A)
  • ASTERISK_PORT (5060) = the UDP port used for SIP communication by the Asterisk server (device A)
  • SIPP_UAC_RATE_SCALE (1) = the number of simultaneous calls which are added or removed upon receiving the up/down commands – recommendation: 2 or 5;

    All parameters, besides SLEEP, SIPP_CONTROLLER_IP and SIPP_CONTROLLER_PORT, are sent to the sipp-controller.sh control script and are used for test initialization on device B.

    Note: Before the test launch on device A it is recommended to restart the Asterisk server and to turn off any other unnecessary services (such as iptables or Flash Operator Panel) that could cause additional system load. Although call logic has been configured such that any call exceeding 30 seconds is stopped, under server overloading some of these calls are left open. That is why, after finishing a test, it is recommended to check if any calls have remained “hung” (asterisk -rx "sip show channels"). If that is the case, the Asterisk server will be restarted (asterisk -rx "restart now").

    The test monitoring is done through the two consoles in which the scripts sipp-controller.sh and start-test.sh have been launched. The data related to the collected information as well as the decisions made (nop = no operation = constant number of simultaneous calls, up = increase the number of simultaneous calls, down = decrease the number of simultaneous calls) is displayed on screen. Data gathered from device A is transmitted and saved on device B, the following information being available:

  • The moment in which data has been recorded (in unix time format, meaning the number of seconds which had passed since Jan 1st 1970)
  • The number of channels and simultaneous calls that are reported by the Asterisk server
  • CPU loading (the Jiffies meter, in which the CPU is idle [3] )
  • Occupied memory (in kB[3] )
  • Load average (the medium number, from the last minute of the processes waiting in the processing queue to access the disk [3] )
  • The duration of the “sleep 1” command, run with maximum priority (renice -20);

The following data is generated by device B itself:

  • Average duration of RTT (Round Trip Time) for 10 INVITE SIP calls (in ms). The smallest and the biggest value are excluded from the average value calculus;
  • The length (in bits) of the file in which the recording of the control call has been made;
  • The decision taken (nop/up/down) and the test reason (sleep/rtt/audio).

This data is useful in case of a subsequent analysis of the server behaviour while the number of calls grows. The saved data is sent through the syslog facility, in CSV labeled sipp-controller-info-, where TEST_ID has an automatically generated value at the test launch. At the test end, the data is automatically saved into /var/log / in a file named <TEST_ID>.<EXTENSION>.<ADRESA_IP>.csv, in the format:

<unix_time>,<active_channels>,<active_calls>,<cpu_idle_jiffies>,<free_mem>,<load_avg_1min>,<rtt_avg>,
<audio_stamp><decision>

The server load is further determined with the formula:

cpu_load=100-Delta(cpu_idle_jiffies)/CPU_NUMBERS/Delta(unix_time) [%]

This formula is available for the usual case in which USER_HZ (CLK_TCK [3] ) is 100 (the usual case of current systems). This value can be obtained using the command getconf CLK_TCK. If the value returned is different, the following formula shall be used:

cpu_load=100-Delta(cpu_idle_jiffies)/CPU_NUMBERS/USER_HZ/Delta(unix_time)*100

The call generator is launched by the sipp-controller.sh sipp-controller.sh script with the number of simultaneous calls set to zero. In other words it does not generate calls and it awaits commands received via the command port. At each increase or decrease command, the number of simultaneous calls is modified with the value of the SIPP_UAC_RATE_SCALE. parameter. This parameter directly decides the test duration. Our recommendation is to choose 2 for a small capacity server or 5 for a large capacity server.

Test results

Using this procedure, four Asterisk servers have been tests as follows:

Servere Asterisk
  1. System fanless Norhtec MicroClient Jr DX
    Xcore86 DX 1GHz,Onboard DDR 256 MB,Integrated r6040 10/100 Mbps LAN, CF
    bogomips: 2000
    Astlinux 0.7.0 (Asterisk 1.4.29, Linux 2.6.27.29-astlinux)
    show translations
    ===
    Translation times between formats (in milliseconds) for one second of data
    Source Format (Rows) Destination Format (Columns)
    
           g723 gsm ulaw alaw g726aal2 adpcm slin lpc10 g729 speex ilbc g726 g722
    g723     -   -    -    -        -     -    -     -    -     -    -    -    -
    gsm      -   -    8    8       20     9    7    55    -     -    -   20    -
    ulaw     -  20    -    1       14     3    1    49    -     -    -   14    -
    alaw     -  20    1    -       14     3    1    49    -     -    -   14    -
    g726aal2 -  30   12   12        -    13   11    59    -     -    -   24    -
    adpcm    -  20    2    2       14     -    1    49    -     -    -   14    -
    slin     -  19    1    1       13     2    -    48    -     -    -   13    -
    lpc10    -  45   27   27       39    28   26     -    -     -    -   39    -
    g729     -   -    -    -        -     -    -     -    -     -    -    -    -
    speex    -   -    -    -        -     -    -     -    -     -    -    -    -
    ilbc     -   -    -    -        -     -    -     -    -     -    -    -    -
    g726     -  31   13   13       25    14   12    60    -     -    -    -    -
    g722     -   -    -    -        -     -    -     -    -     -    -    -    -
    ==
    

    Maximum number of simultaneous calls:

    38 without transcoding (ulaw/ulaw)
    34 with G.711 transcoding (ulaw/alaw)
    16 with G.711 to GSM

    The CPU load vs the number of simultaneous calls, for each of the 3 transcoding scenarios

    Diagrama sistem Nortech
  2. System fanless VIA
    VIA C7 Esther 1.2GHz,1 GB, VIA Velocity VT6120 Gigabit Ethernet Adapter, VIA EPIA EN12000EG
    	bogomips: 2395.76
    	Astlinux-0.7.0 (Asterisk 1.4.29, Linux 2.6.20-astlinux)
    	show translations
    	===
    	Translation times between formats (in milliseconds) for one second of data
    	Source Format (Rows) Destination Format (Columns)
    	
    		g723 gsm ulaw alaw g726aal2 adpcm slin lpc10 g729 speex ilbc g726 g722
    	g723     -    -    -    -        -     -    -     -    -     -    -    -    -
    	gsm    	 -    -    4    4        8     4    3    16    -     -    -    8    -
    	ulaw     -   10    -    1        6     2    1    14    -     -    -    6    -
    	alaw     -   10    1    -        6     2    1    14    -     -    -    6    -
    	g726aal2 -   14    6    6        -     6    5    18    -     -    -   10    -
    	adpcm    -   10    2    2        6     -    1    14    -     -    -    6    -
    	slin     -    9    1    1        5     1    -    13    -     -    -    5    -
    	lpc10    -   16    8    8       12     8    7     -    -     -    -   12    -
    	g729     -    -    -    -        -     -    -     -    -     -    -    -    -
    	speex    -    -    -    -        -     -    -     -    -     -    -    -    -
    	ilbc     -    -    -    -        -     -    -     -    -     -    -    -    -
    	g726     -   14    6    6       10     6    5    18    -     -    -    -    -
    	g722     -    -    -    -        -     -    -     -    -     -    -    -    -
    	===

    Maximum number of simultaneous calls:

    130 without transcoding (ulaw/ulaw)
    120 with G.711 transcoding (ulaw/alaw)
    48 with G.711 to GSM transconding

    incarcarea procesorului fata de numarul de apeluri simultane, in cele 3 cazuri de transcodare

    Digrama sistem VIA
  3. System Asus Pundit R350
    Intel Celeron 2.66 GHz, 438 MB, RTL8139 10/100 MBps LAN
    	bogomips: 5324
    	Trixbox 2.6.2.3 (Asterisk 1.4.22-4, Linux 2.6.18-128.1.10.el5)
    	show translations
    	===
    	Translation times between formats (in milliseconds) for one second of data
    	Source Format (Rows) Destination Format (Columns)
    	
    		g723 gsm ulaw alaw g726aal2 adpcm slin lpc10 g729 speex ilbc g726 g722
    	g723     -   -    -    -        -     -    -     -    -     -    -    -    -
    	gsm    	 -   -    2    2        2     2    1     4    -    14   16    2    -
    	ulaw     -   3    -    1        2     2    1     4    -    14   16    2    -
    	alaw     -   3    1    -        2     2    1     4    -    14   16    2    -
    	g726aal2 -   3    2    2        -     2    1     4    -    14   16    1    -
    	adpcm    -   3    2    2        2     -    1     4    -    14   16    2    -
    	slin     -   2    1    1        1     1    -     3    -    13   15    1    -
    	lpc10    -   4    3    3        3     3    2     -    -    15   17    3    -
    	g729     -   -    -    -        -     -    -     -    -     -    -    -    -
    	speex    -  19   18   18       18    18   17    20    -     -   32   18    -
    	ilbc     -   4    3    3        3     3    2     5    -    15    -    3    -
    	g726     -   3    2    2        1     2    1     4    -    14   16    -    -
    	g722     -   -    -    -        -     -    -     -    -     -    -    -    -
    	===

    Maximum number of simultaneous calls:

    176 without transcoding (ulaw/ulaw);
    156 with G.711 transcoding (ulaw/alaw);
    90 with G.711 to GSM transconding.

    The CPU load vs the number of simultaneous calls, for each of the 3 transcoding scenarios

    Digrama sistem Asus
  4. System GIGABYTE tower
    Intel Pentium Dual CPU E2180 2GHz, 2 GB, RTL8111/8168B Gigabit Ethernet controller LAN, Gigabyte 945GCM-S2L
    	bogomips: 2 x 4000
    	Vicidialnow CE 1.3 (Asterisk 1.2.30.2, CentOS 5.4, Linux 2.6.18-164.el5.vnow, )
    	show translations
    	===
    	Translation times between formats (in milliseconds)
    	Source Format (Rows) Destination Format(Columns)
    	
    		g723   gsm  ulaw  alaw  g726 adpcm  slin lpc10  g729 speex  ilbc
    	g723     -     -     -     -     -     -     -     -     -     -     -
    	gsm      -     -     2     2     2     2     1     3     -    21     -
    	ulaw     -     2     -     1     2     2     1     3     -    21     -
    	alaw     -     2     1     -     2     2     1     3     -    21     -
    	g726     -     2     2     2     -     2     1     3     -    21     -
    	adpcm    -     2     2     2     2     -     1     3     -    21     -
    	slin     -     1     1     1     1     1     -     2     -    20     -
    	lpc10    -     2     2     2     2     2     1     -     -    21     -
    	g729     -     -     -     -     -     -     -     -     -     -     -
    	speex    -     2     2     2     2     2     1     3     -     -     -
    	ilbc     -     -     -     -     -     -     -     -     -     -     -
    	===

    Maximum number of simultaneous calls:

    320 without transcoding (ulaw/ulaw);
    312 with G.711 transcoding (ulaw/alaw);
    240 with G.711 to GSM transconding

    The CPU load vs the number of simultaneous calls, for each of the 3 transcoding scenarios

    Diagrama sistem Gigabyte

We await your commentaries and suggestions at vanzari@tenora.ro as well as on the VOIP - totul despre voice over ip, on "Determine the maximum capacity of an Asterisk server" topic.

Bibliography:

[1] How to test an Asterisk server using SIPp

[2] Bandwidth consumption

[3] Linux Programmer's Manual

[4] How to record your self-made pcap file

[5] SIPstone - Benchmarking SIP Server Performance