Example: Asterisk.CLI core set verbose 10 Console verbose was 2 and is now 10. Asterisk.CLI core set debug 10 Core debug was OFF and is now 10. Asterisk.CLI sip set debug on SIP Debugging enabled Asterisk.CLI fax set debug on FAX Debug Enabled dm.CLI Note: Depending on version of your Asterisk system, the sip set debug command may be. Set: Set a variable for use in the extension logic (example: file1=/tmp/to ) Application: Asterisk Application to run (use instead of specifiying context, extension and priority) Data: The options to be passed to application; Other parameters AlwaysDelete: Yes/No - If the file's modification time is in the future, the call file will not be deleted.
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.
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:
- 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:
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.
- Install the configuration for the call generator:
- Install the pcap file played by the call generator:
- Install the configuration for the modified answer engine:
- Install the main test control script:
- Install the evaluation script for the call record created during the control call:
Phone Call From Asterisk
On device A – test subject
- Install the initialization script of the testing session:
Configure the Asterisk A server
Asterisk Call Manager
- Create test and control SIP accounts:
- Create the test context:
- Enable the configurations:
Configure the Asterisk B server
- Create the control context:
- Enable the configuration:
Testing
The test launch involves:
Call From Asterisk
- 1. Open a new terminal and launch the main script of the test: 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:
On device B
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:
The server load is further determined with the formula:
This formula is available for the usual case in which USER_HZ (CLK_TCK ) 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:
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:
- System fanless Norhtec MicroClient Jr DXMaximum 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 - System fanless VIAMaximum 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 - System Asus Pundit R350 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 - System GIGABYTE towerMaximum 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
We await your commentaries and suggestions at [email protected] as well as on the VOIP - totul despre voice over ip, on 'Determine the maximum capacity of an Asterisk server' topic.
Bibliography:
Skip to end of metadataGo to start of metadataAnother example is to use callfiles and Local channels so that you can execute some dialplan prior to performing a Dial(). We'll construct a callfile which will then utilize a Local channel to lookup a bit of information in the AstDB and then place a call via the channel configured in the AstDB.
First, lets construct our callfile that will use the Local channel to do some lookups prior to placing our call. More information on constructing callfiles is located in the doc/callfiles.txt file of your Asterisk source.
Our callfile will simply look like the following:
Add the callfile information to a file such as 'callfile.new' or some other appropriately named file.
Our dialplan will perform a lookup in the AstDB to determine which device to call, and will then call the device, and upon answer, Playback() the silence/1 (1 second of silence) and the tt-weasels sound files.
Before looking at our dialplan, lets put some data into AstDB that we can then lookup from the dialplan. From the Asterisk CLI, run the following command:
We've now put the device destination (SIP/0004f2040001) into the 201/device key within the phones family. This will allow us to lookup the device location for extension 201 from the database.
We can then verify our entry in the database using the 'database show' CLI command:
Now lets create the dialplan that will allow us to call SIP/0004f2040001 when we request extension 201 from the extensions context via our Local channel.
Then, we can perform a call to our device using the callfile by moving it into the /var/spool/asterisk/outgoing/ directory.
Then after a moment, you should see output on your console similar to the following, and your device ringing. Information about what is going on during the output has also been added throughout.
You'll see the line above as soon as Asterisk gets the request from the callfile.
This is where we performed our lookup in the AstDB. The value of SIP/0004f2040001 was then returned and saved to the DEVICE channel variable.
We perform a check to make sure ${DEVICE} isn't NULL. If it is, we'll just hangup here.
Now we call our device SIP/0004f2040001 from the Local channel.
We answer the call.
We then start playing back the files.
At this point we now see the Local channel has been optimized out of the call path. This is important as we'll see in examples later. By default, the Local channel will try to optimize itself out of the call path as soon as it can. Now that the call has been established and audio is flowing, it gets out of the way.
We can now see the tt-weasels file is played directly to the destination (instead of through the Local channel which was optimized out of the call path) and then a NOTICE stating the call was completed.