Articole & Tutoriale VoIP

Determinarea capacitatii maxime a unei centrale Asterisk

08 Mar 2010
http://www.modulo.ro/modulo/downloads/sipp/start-test.sh

Sunt situatii in care se doreste determinarea capacitatii maxime de procesare a unei centrale Asterisk in sensul identificarii numarului maxim de apeluri pe care un anumit server il poate sustine (intr-o configuratie hardware si software specifica). Datorita arhitecturii unei astfel de centrale (bazata pe un calculator de tip x86) nu exista o formula de calcul prin care sa fie obtinut acest parametru. Alte centrale VoIP proprietare ofera valoarea acestui parametru, calculat in principal pe baza resurselor hardware alocate pentru procesarea apelurilor VoIP in carduri/procesoare specializate, avand astfel un avantaj competitiv fata de centralele open-source Asterisk.

Testele de performanta ale unei centrale Asterisk sunt bazate pe analiza subiectiva a canalului audio pe masura ce numarul de apeluri simultane este crescut, metoda empirica si efectuata de cele mai multe ori manual. In lipsa unor parametrii specifici fiecarui apel care sa indice degradarea calitatii canalului audio, a fost pusa in practica o metoda care evalueaza capacitatea unei centrale Asterisk in mai multi pasi: verificarea duratei unei pauze de 1 secunda (indicator empiric al incarcarii unui server), verificarea duratei medii a raspunsului primit in urma transmiterii unor mesaje SIP de tip INVITE (se evalueaza parametrul RTT- Round Trip Time) si verificarea calitatii unui apel prin inregistrarea acestuia intr-un al doilea server Asterisk . Daca toate aceste teste ofera rezultate satisfacatoare se considera ca serverul ce se testeaza mai poate procesa apeluri suplimentare.

Aceasta metoda nu este perfecta (in sensul mentinerii unor evaluari empirice) insa ofera posibilitatea automatizarii sesiunilor de testare. In cele ce urmeaza ne propunem sa detaliam metoda de testare, pusa in practica de catre Modulo Consulting, pentru a descrie modul in care se ruleaza testele precum si furnizarea unor rezultate obtinute prin aceasta metoda.

Descrierea metodei

In diagrama de mai jos se poate observa modul in care se face testarea: centrala Asterisk ruleaza pe masina A iar simulatorul de apeluri VoIP (am folosit numai apeluri SIP) ruleaza pe masina B. Tot pe masina B ruleaza un server auxiliar Asterisk, folosit pentru validarea calitatii canalului audio al unui apel de control.

Diagrama load test program

Pentru generarea controlata a unor apeluri SIP am folosit pachetul open-source SIPp, fiind rulate initial doua instante sipp [1] : generatorul de apeluri (configuratie de tip client: uac_pcap, codec alaw) si motorul de raspuns (configuratie de tip server: uas, codec ulaw). Aceste configuratii sunt incluse deja in pachetul SIPp si ofera un scenariu de transcodare minimala intre cele 2 codecuri G.711. Functionarea este simpla: generatorul de apeluri (utilizator sipp_2) apeleaza o anumita extensie din centrala Asterisk, extensie la care raspunde motorul de raspuns (utilizator sipp_1). Generatorul de apeluri va reda un prompt iar motorul de raspuns va functiona in regim de "ecou" (retransmite tot ce receptioneaza), in acest mod simulandu-se cat mai real o conversatie telefonica de tip duplex (in care ambii parteneri pot vorbi).

Pentru a genera apeluri fara transcodare sau cu transcodare catre codecul GSM s-a modificat configuratia motorului de raspuns, noua configuratie fiind uas.modulo.xml. De asemenea s-a observat ca pachetele RTP care sunt continute in fisierul inclus in pachetul SIPp (de exemplu g711a.pcap) au o lungime de 240 octeti, mai mare decat lungimea cu care serverul Asterisk lucreaza (160 octeti = 20 ms x 8000 octeti/secunda). Aceasta face ca la fiecare 2 pachete de 240 octeti receptionate de la generatorul de apeluri sa fie transmise 3 pachete de 160 octeti catre motorul de raspuns, ceea ce se traduce prin trafic si incarcare suplimentara a centralei. Pentru a face o testare cat mai aproape de realitate s-a decis folosirea unor pachete RTP de 160 octeti si am inregistrat [4] , intr-un fisier de tip pcap (dtmf.1234567890.G711_PCMU.pcap), un apel de aproximativ 10 secunde in format ulaw si care contine codurile DTMF 1234567890 plus un prompt standard Asterisk (hello-world). Pentru a folosi acest fisier am modificat configuratia generatorului de apeluri, noua configuratie fiind uac_pcap.modulo.xml. O alta modificare a fost efectuata asupra lungimii apelului: de la o lungime fixa de 9 secunde la o lungime variabila, intre 10 si 15 de secunde realizand astfel o distributie mai naturala a apelurilor.

Configuratiile Asterisk (configuratia SIP si logica de apel) din centrala A au fost modificate astfel incat sa fie posibila selectia codec-ului prin care motorul de raspuns va raspunde generatorului de apeluri. Astfel, in functie de extensia apelata de generatorul de apeluri, este ales ca destinatie un anumit utilizator SIP pentru care este valid un singur tip de codec:

  • 1002 => apelare sipp1_gsm = codec gsm => transcodare ulaw la gsm;
  • 1003 => apelare sipp1_ulaw = codec ulaw => fara transcodare (ulaw la ulaw);
  • 1004 => apelare sipp1_alaw = codec_alaw => transcodare ulaw la alaw.

Controlul unei instante sipp se poate face local (din consola in care a fost pornit) sau de la distanta fiind posibil astfel implementarea unui mecanism de control al generatorului de apeluri. Controlul se face prin intermediul scriptului sipp-controller.sh care ruleaza pe masina B. Acest script mai are si rolul de a salva date statistice transmise de scriptul care porneste testul pe masina A (start-test.sh).

Rolurile celor doua scripturi sunt detaliate mai jos:

  • start-test.sh - ruleaza pe masina ce se doreste a fi testata (A) si asteapta comenzi (pe portul TCP 8880) de la scriptul de control sipp-controller.sh
    • initializeaza o noua sesiune de test
    • periodic:
      • culege si transmite informatii utile pentru analiza ulterioara (incarcare procesor, memorie libera, numar de apeluri simultane, etc.);
      • evalueaza durata unei pauze de 1 secunda fata de 2 nivele de decizie (configurabile prin parametrii SLEEP_L1 si SLEEP_L2):
        • pana in 1.15 secunde (15% crestere) se considera ca testul este trecut, numarul de apeluri simultane putand sa creasca;
        • intre 1.15 si 1.25 secunde (25% crestere) se considera ca testul este trecut insa numarul de apeluri simultane nu va creste;
        • peste 1.25 secunde se considera ca testul nu a trecut si numarul de apeluri simultane va trebui sa scada;

          Obs:Valoarea celor doua nivele de decizie sunt alese arbitrar de echipa de testare, fiind urmarita obtinerea unui nivel acceptabil de administrare a centralei Asterisk testate in momentul in care este supra incarcata.

      • transmite setul de informatii culese si decizia de evaluare catre scriptul de control sipp-controller.sh.
      • incearca sa detecteze o comanda de micsorare a numarului de apeluri simultane si opreste testul daca acest contorul ajunge la valoarea 5 (configurabil prin parametrul DOWN_MAX);
  • sipp-controler.sh - ruleaza pe masina cu care se face testarea (B) si asteapta comenzi
    • la comanda de initializare a unei noi sesiuni de test porneste doua instante sipp (motorul de raspuns si generatorul de apeluri);
    • pentru fiecare set de informatii primit:
      • se evalueaza durata medie RTT pentru un numar de 10 apeluri SIP de tip INVITE. Aceasta se realizeaza prin intermediul unei a treia instante sipp, care ruleaza cu scenariul implicit de tip client uac . Apelurile initiate de aceasta instanta sunt transmise catre acelasi motor de raspuns ca si instanta generatorului de apeluri;
      • dupa evaluarea valorii medii RTT se verifica aceasta valoare fata de 2 nivele setate in testare (configurabile prin parametrii SIPP_RTT_L1 si SIPP_RTT_L2): 100% si 125% din valoarea parametrului SIPP_RTT_MAX cu care s-a facut initializarea sesiunii de test;
        • daca valoarea nu depaseste 100% se considera ca testul este trecut, numarul de apeluri simultane putand sa creasca;
        • daca valoarea este peste 125% se considera ca testul nu a trecut si numarul de apeluri simultane va trebui sa scada;

          Obs: Valoarea recomandata [5] pentru SIPP_RTT_MAX este de 100 ms iar cele 2 nivele au fost definite arbitrar de echipa de testare pentru a asigura un interval in care nu se ia nici o decizie.

      • se initiaza un apel de control cu scopul de evaluare a calitatii canalului audio. Apelul este initiat si inregistrat de masina B, printr-un mecanism de tip “call file", apelandu-se o extensie a centralei Asterisk testate care functioneaza in regim de “ecou". De pe masina B se reda un prompt oarecare (s-a ales promptul standard Asterisk helo-world) si, la terminarea apelului, se verifica fisierul ce contine inregistrarea canalului audio transmis de centrala Asterisk. Verificarea se face printr-o metoda foarte simpla: daca lungimea fisierului este egala cu cea detectata in momentul pornirii testului se considera ca testul este trecut si numarul de apeluri simultane poate creste. Daca exista orice diferenta se considera ca testul nu a trecut si numarul de apeluri simultane va trebui sa scada;
      • salveaza, prin facilitatea syslog, setul de informatii primit de la masina A si extins cu informatiile si rezultatul testelor efectuate pe masina B;
      • in functie de rezultatul testelor se ia o decizie de modificare a numarului de apeluri simultane;
    • la comanda de oprire a testului:
      • trimite comanda de oprire catre cele 2 instante sipp pornite la initializare (generatorul de apeluri si motorul de raspuns);
      • salveaza intr-un fisier separat, localizat in directorul /var/log, toate informatiile colectate pentru sesiunea de test respectiva.

Asa cum se mentioneaza mai sus, testul se opreste automat dupa detectarea a 5 decizii de scadere a numarului de apeluri simultane. Rezultatul testului se considera a fi valoarea imediat inferioara fata de cea mai mica valoare a numarului de apeluri simultane pentru care s-a raportat ca unul din cele 3 teste nu a trecut.

Pentru a verifica aceasta valoare se poate rula ulterior un test de volum care sa confirme daca centrala Asterisk poate sustine acest numar de apeluri pe o perioada mai indelungata de timp (de exemplu 24 de ore). Instantele sipp pot oferi statistici interesante referitoare la timpii in care mesajele de semnalizare SIP au fost procesate si, mai important, daca au aparut erori sau nu pe tot timpul testului.

Note:

  1. In afara de determinarea numarului maxim de apeluri simultane procesate corect de centrala Asterisk se mai pot imagina si alte teste, cum ar fi, determinarea numarului maxim de apeluri intr-o conferinta sau numarul maxim de conferinte cu cate 5 utilizatori.
  2. In orice moment, pentru a verifica functionarea corecta a centralei se poate face un apel de tip MusicOnHold, calitatea canalului audio urmand sa confirme daca totul este in regula sau nu.
  3. Testarea trebuie sa tina cont de traficul destul de mare care urmeaza sa fie generat prin folosirea unui codec de tip G.711 (~87 kbps [2] pentru fiecare apel, pe ambele sensuri: RX si TX) si de aceea trebuie verificata latimea de banda estimata fata de capacitatea interfetelor de retea. Recomandarea noastra este de a avea instalate pe ambele masini interfete de acelasi tip (Fast sau Giga Ethernet Full Duplex) si conectarea lor prin intermediul unui switch corespunzator. Utilizarea unui router intre cele doua servere va afecta in mod sigur testele prin introducerea unor intarzieri in transmiterea pachetelor si de aceea nu recomandam o astfel de conectare.
  4. Se recomanda ca inaintea pornirii testelor sa se verifice care este numarul maxim de fisiere deschise de un proces (ulimit -n). Acest parametru este modificat, de obicei, in scriptul de pornire a aplicatiei asterisk si ar trebui sa aiba o valoare care sa asigure ca nu exista o limitare in acest sens. Recomandam setarea acestui parametru la valoarea 4096, valoare care ar trebui sa asigure resurse pentru procesarea unui numar foarte mare de apeluri. Pentru a verifica cate fisiere deschise are un anumit proces (de exemplu asterisk) putem utiliza urmatoarea comanda:
	[root@tenora ~]# ls -l /proc/$(cat /var/run/asterisk.pid)/fd | wc -l 743

Instalarea componentelor

Pe masina B:

  1. Instalarea pachetului SIPp

    Acesta se face conform instructiunilor de instalare pe care le puteti consulta aici. In cazul nostru am folosit un server Centos pentru care exista deja compilat acest pachet. Instalarea s-a facut prin intermediul proiectului EPEL, detaliile utilizarii acestui serviciu fiind disponibile aici.

    Nota: pentru a preveni conflicte intre pachetele disponibile prin EPEL si alte servicii de distribuire a pachetelor va recomandam instalarea yum-plugin-priorities si utilizarea optiunii priority din fisierele de configurare corespunzatoare.

    rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
    yum install sipp
  2. Instalarea configuratiei pentru generatorul de apeluri:
    cd /usr/share/sipp
    wget http://www.modulo.ro/modulo/downloads/sipp/uac_pcap.modulo.xml
  3. Instalarea fisierului pcap redat de generatorul de apeluri:
    cd /usr/share/sipp/pcap
    wget http://www.modulo.ro/modulo/downloads/sipp/dtmf.1234567890.G711_PCMU.pcap
  4. Instalarea configuratiei pentru motorul de raspuns modificat:
    cd /usr/share/sipp
    wget http://www.modulo.ro/modulo/downloads/sipp/uas.modulo.xml
  5. Instalarea scriptului principal de control a testului:
    cd /usr/share/sipp
    wget http://www.modulo.ro/modulo/downloads/sipp/sipp-controller.sh
    chmod +x sipp-controller.sh
  6. Instalarea scriptului de evaluare a inregistrarii efectuate in cadrul apelului de control:
    cd /etc/asterisk/load_tests
    wget http://www.modulo.ro/modulo/downloads/sipp/eval-audio.sh
    chmod +x eval-audio.sh

Pe masina A - care urmeaza sa fie testata:

  1. Instalarea scriptului de initiere a unei sesiuni de testare:
    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

Configurarea serverului Asterisk A

  1. Crearea de conturi SIP pentru testare si control:
    [sipp_1](!)
    type=friend
    username=sipp_1
    host=<adresa_IP_a_motorului_de_raspuns>
    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=<adresa_IP_a_generatorului_de_apeluri>
    port=5062
    context=sipp-test
    dtmfmode=rfc2833
    insecure=very
    canreinvite=no
    nat=yes
    disallow=all
    allow=ulaw
  2. Crearea unui context pentru testare:
    [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. Activarea configuratiilor:
    asterisk -rx "reload"

Configurarea serverului Asterisk B

  1. Crearea unui context pentru control:
    [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. Activarea configuratiilor:
    asterisk -rx "reload"

Testare

Pornirea testului se face in modul urmator:

    Pe masina B

  1. Deschiderea unui nou terminal si pornirea scriptului principal de control al testului:
    cd /usr/share/sipp/
    ./sipp-controller.sh <adresa_IP_a_masinii_B>

    Parametrul cu care se ruleaza scriptul sipp-controller.sh reprezinta adresa IP a masinii B ce va fi folosita pe parcursul testelor. Atentie: nu se va folosi adresa locala 127.0.0.1!

    Pe masina A

  2. Deschiderea unui nou terminal si monitorizarea incarcarii ( de exemplu prin intermediul comenzii top).
  3. Deschiderea unui nou terminal si pornirea scriptului de initializare a testului:
    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>

Parametrii mentionati mai sus au urmatoarea semnificatie (intre paranteze este data valoarea implicita):

  • FINAL_DEC (4) = valoarea contorului la care se activeaza, pe masina B, decizia de modificare a numarului simultan de apeluri;
  • SLEEP (15) = pauza care se face (in secunde) intre 2 citiri a datelor statistice si evaluarea comenzii de tip `sleep 1`
  • SIPP_RTT_MAX (100) = durata (in ms) fata de care se evalueaza, pe masina B, valoarea medie a parametrului RTT
  • SIPP_CONTROLLER_IP = adresa IP a masinii unde ruleaza scriptul sipp-controller.sh (masina B)
  • SIPP_CONTROLLER_PORT (8080) = portul TCP pe care scriptul sipp-controller.sh asteapta comenzi
  • ASTERISK_CALL_EXTENSION (1002, 1003 sau 1004) = extensia ce va fi apelata de generatorul de apeluri in cadrul testului respectiv - se va alege in functie de tipul testului de transcodare care se doreste a fi efectuat;
  • ASTERISK_IP = adresa IP a centralei Asterisk ce este supusa testelor (masina A)
  • ASTERISK_PORT (5060) = portul UDP prin care centrala Asterisk ce este supusa testelor realizeaza comunicatia SIP
  • SIPP_UAC_RATE_SCALE (1) = numarul de apeluri simultane cu care se creste/scade la primirea comenzilor de tip up/down - recomandare: 2 sau 5;

    Toti parametrii, in afara de SLEEP, SIPP_CONTROLLER_IP si SIPP_CONTROLLER_PORT, sunt transmisi catre scriptul de control sipp-controller.sh si sunt folositi pentru initializarea testului pe masina B.

    Nota: Este recomandat ca inainte de inceperea testului, pe masina A sa se faca o repornire a serverului Asterisk si sa fie oprite orice servicii care nu sunt strict necesare (ca de exemplu iptables sau Flash Operator Panel) dar care incarca in mod inutil sistemul. Logica de apel a fost configurata ca orice apel sa fie oprit dupa maxim 30 de secunde insa pot aparea situatii cand, datorita supraincarcarii serverului, unele apeluri sa ramana deschise. De aceea, dupa finalizarea unui test, este indicat sa se verifice daca au ramas astfel de apeluri “agatate" (asterisk -rx "sip show channels"), caz in care se va reporni serverul Asterisk (asterisk -rx "restart now").

    Monitorizarea testului se face in cele 2 console in care s-au pornit scripturile sipp-controller.sh si start-test.sh, pe ecran fiind afisate informatii referitoare la datele colectate precum si asupra deciziilor luate (nop=no operation = pastrarea numarului de apeluri simultane constant, up = cresterea numarului de apeluri simultane, down = scaderea numarului de apeluri simultane). Datele colectate de pe masina A sunt transmise si salvate pe masina B, fiind disponibile urmatoarele informatii:

  • momentul in care s-au inregistrat datele (in format unix time, adica numarul de secunde ce au trecut de la 1 Ian 1970).
  • numarul de canale si de apeluri simultane ce sunt raportate de serverul Asterisk,
  • incarcarea procesorului (contorul de Jiffies in care procesorul este idle [3] )
  • memoria ocupata (in kB [3] )
  • incarcarea medie (load average , numarul mediu, din ultimul minut a proceselor aflate in coada de procesare sau care asteapta sa primeasca acces la disc [3] )
  • durata comenzii "sleep 1", rulata cu prioritate maxima (renice -20);

La aceste date se adauga informatiile procesate direct pe masina B:

  • durata medie a valorii RTT (Round Trip Time) pentru 10 apeluri SIP de tip INVITE (in ms). La calcularea valorii medii s-a decis ca valoarea cea mai mica si cea mai mare sunt excluse);
  • lungimea (in octeti) a fisierului in care s-a facut inregistrarea apelului de control;
  • decizia (nop/up/down) si motivul (sleep/rtt/audio).

Aceste date sunt utile pentru a face o analiza ulterioara a comportarii centralei pe masura ce numarul de apeluri creste. Datele salvate sunt transmise prin facilitatea syslog in format CSV, cu eticheta sipp-controller-info-<TEST_ID>, unde TEST_ID este o valoare generata automat in momentul pornirii testului. La finalizarea testului datele sunt extrase automat in directorul /var/log, intr-un fisier cu denumirea <TEST_ID>.<EXTENSION>.<ADRESA_IP>.csv, informatiile fiind sub forma:

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

Pentru a determina incarcarea serverului se va folosi urmatoarea formula:

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

Acesta formula este valabila pentru cazul uzual in care USER_HZ (CLK_TCK [3] ) are valoarea 100 (cazul uzual al sistemelor actuale). Aceasta valoare poate fi determinata prin comanda getconf CLK_TCK. Daca aceasta valoare difera de 100 se va folosi formula de mai jos:

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

Generatorul de apeluri este pornit de catre scriptul sipp-controller.sh cu o valoare egala cu 0 pentru numarul de apeluri simultane. Cu alte cuvinte nu genereaza apeluri si asteapta comenzi primite pe portul de comanda. La fiecare crestere sau scadere numarul de apeluri simultane mentinut de generatorul de apeluri este modificat cu un numar egal cu parametrul SIPP_UAC_RATE_SCALE. Acest parametru va decide in mod direct durata testului alaturi de, recomandarea noastra fiind de a alege valoarea 2 pentru o centrala de capacitate mica, respectiv valoarea 5 pentru o centrala de capacitate mai mare

Rezultatele testului

Folosind aceasta metoda au fost testate patru servere Asterisk, dupa cum urmeaza:

Servere Asterisk
  1. Sistem 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     -   -    -    -        -     -    -     -    -     -    -    -    -
    ==
    

    numar maxim de apeluri simultane:

    38 fara transcodare (ulaw/ulaw)
    34 cu transcodare G.711 (ulaw/alaw)
    16 cu transcodare G.711 la GSM

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

    Diagrama sistem Nortech
  2. Sistem 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     -    -    -    -        -     -    -     -    -     -    -    -    -
    	===

    numar maxim de apeluri simultane:

    130 fara transcodare (ulaw/ulaw)
    120 cu transcodare G.711 (ulaw/alaw)
    48 cu transcodare G.711 la GSM

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

    Digrama sistem VIA
  3. Sistem 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     -   -    -    -        -     -    -     -    -     -    -    -    -
    	===

    numar maxim de apeluri simultane:

    176 fara transcodare (ulaw/ulaw);
    156 cu transcodare G.711 (ulaw/alaw);
    90 cu transcodare G.711 la GSM.

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

    Digrama sistem Asus
  4. Sistem 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     -     -     -     -     -     -     -     -     -     -     -
    	===

    numar maxim de apeluri simultane:

    320 fara transcodare (ulaw/ulaw);
    312 cu transcodare G.711 (ulaw/alaw);
    240 cu transcodare G.711 la GSM.

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

    Diagrama sistem Gigabyte

Asteptam comentariile si sugestiile dumneavoastra pe adresa info@modulo.ro cat si pe forumul VOIP - totul despre voice over ip, cu subiectul "Determinarea capacitatii maxime de procesare a unei centrale Asterisk".

Bibliografie:

[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