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.
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:
The roles of the two scripts are detailed below:
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:
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.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 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.
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:
- 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.
- 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.
- 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. 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:
- 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
- Install the configuration for the call generator:
cd /usr/share/sipp wget http://www.modulo.ro/modulo/downloads/sipp/uac_pcap.modulo.xml
- 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
- Install the configuration for the modified answer engine:
cd /usr/share/sipp wget http://www.modulo.ro/modulo/downloads/sipp/uas.modulo.xml
- 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
- 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
- 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
- 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
- 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) - Enable the configurations:
asterisk -rx "reload"
Configure the Asterisk B server
- 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> &)
- Enable the configuration:
asterisk -rx "reload"
Testing
The test launch involves:- 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. Open a new terminal and monitor the load (for example the top command).
- 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>
On device B
- 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);
- 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).
<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)*100The 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:- 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:
The CPU load vs the number of simultaneous calls, for each of the 3 transcoding scenarios38 without transcoding (ulaw/ulaw) 34 with G.711 transcoding (ulaw/alaw) 16 with G.711 to GSM
- 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:
incarcarea procesorului fata de numarul de apeluri simultane, in cele 3 cazuri de transcodare130 without transcoding (ulaw/ulaw) 120 with G.711 transcoding (ulaw/alaw) 48 with G.711 to GSM transconding
- 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:
The CPU load vs the number of simultaneous calls, for each of the 3 transcoding scenarios176 without transcoding (ulaw/ulaw); 156 with G.711 transcoding (ulaw/alaw); 90 with G.711 to GSM transconding.
- 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:
The CPU load vs the number of simultaneous calls, for each of the 3 transcoding scenarios320 without transcoding (ulaw/ulaw); 312 with G.711 transcoding (ulaw/alaw); 240 with G.711 to GSM transconding
Comments