New version for Tenora Conference application

Citind pe lista Asterisk-users despre o incercare de instalare a uni dialpan de tip n-way mi-am facut timp saptamana aceasta sa sa ma uit peste aplicatia de conferinte pe care o avem instalata pe centrala noastra (Centos+Asterisk+FreePBX).

Este adevarat ca nu am facut prea multe verificari ale acestei aplicatii cand am facut upgrade-ul de la Asterisk 1.2 la 1.4 insa acum am vazut ca aveam o problema in partea de log: variabila de canal ${TIMESTAMP} nu mai este disponibila in versiunea1.4a astfel incat a trebuit sa o inlocuiesc cu ${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)}.

Toata partea care tine de log a fost rescrisa si am adaugat facilitatea unui participant de tip administrator de a putea introduce in conferinta un alt participant, care va fi apelat de catre centrala Asterisk. Aceasta facilitate a fost ceruta de mai mult timp insa deabia acum a putut fi implementata.

Initial am configurat in [applicationmap] secventele "*9" (pentru introducere in conferinta) si "*7" (pentru renuntare) insa testele facute ulterior au (re)adus in discutie faptul ca transmiterea de DTMF-uri prin reteaua GSM este intarziata.

Cu alte cuvinte: transmiterea unei secvente DTMF este intarziata la fiecare cod cu un delay de aproximativ 1.5-2 secunde. Aceasta face ca secventa "*9" sa fie interpretata de Asterisk ca doua secvente distincte "*" si "9", cele doua DTMF-uri fiind detectate separat rezultatul final fiind ca sistemul nu va executa codul de dialplan dorit. Aceasta problema nu afecteaza citirea unor variabile (Read), unde exista posibilitatea setarii numarului maxim de digiti si a unui timer de inactivitate.

Log Asterisk pentru citirea unei variabile (100)

[Sep 25 12:41:10] DEBUG[21921] chan_dahdi.c: DTMF digit: 1 on DAHDI/20-1
[Sep 25 12:41:12] DEBUG[21921] chan_dahdi.c: DTMF digit: 0 on DAHDI/20-1
[Sep 25 12:41:13] DEBUG[21921] chan_dahdi.c: DTMF digit: 0 on DAHDI/20-1
[Sep 25 12:41:14] DEBUG[21921] chan_dahdi.c: DTMF digit: # on DAHDI/20-1

Log Asterisk pentru receptionarea secventei DTMF *9 tastata de pe un telefon mobil

[Sep 24 17:42:36] DEBUG[13098] channel.c: Got DTMF begin on channel (DAHDI/26-1)
[Sep 24 17:42:36] DEBUG[13098] chan_dahdi.c: DTMF digit: * on DAHDI/26-1
[Sep 24 17:42:36] DEBUG[13098] channel.c: Got DTMF end on channel (DAHDI/26-1)
[Sep 24 17:42:38] DEBUG[13098] channel.c: Got DTMF begin on channel (DAHDI/26-1)
[Sep 24 17:42:38] DEBUG[13098] chan_dahdi.c: DTMF digit: 9 on DAHDI/26-1
[Sep 24 17:42:38] DEBUG[13098] channel.c: Got DTMF end on channel (DAHDI/26-1)

Desigur ca primul pas ar fi fost sa verific daca exista un timer pentru "Features Applications" si pe care sa-l pot mari insa abordarea a fost mai simpla: schimbarea secventele mentionate mai sus prin eleiminarea unui digit ("*"). Testele efectuate ulterior au aratat ca aceasta schimbare (secvente cu un singur cod DTMF) a fost benefica.

Explicatia este ca DTMF-urile se transmit de telefoanele mobile in mod OUT-BAND catre MSC-uri iar acestea transmite informatia IN-BAND. Rata de transmise din MSC este fixa, astfel incat daca utilizatorul introduce o secventa DTMF mai rapida, tonurile corspunzatoare codurilor DTMF vor fi injectate in canalul audio cu pauza setata in MSC. In masura in care voi gasi mai multe informatii le voi adauga ulterior.

Continuind cu verificarea codului s-a observat ca modul in care se facea inregistrarea discutiilor purtate in camera de conferinta virtuala era gresit. Apelul aplicatiei de conferinta (MeetMe) utiliza optiunea "r" pentru fiecare participant. Cand se intra in camera de conferinta se activa optiunea de inregistrare a convorbirilor intr-un fisier, numele acestuia fiind personalizat. Insa daca acel participant "iese" mai devreme / "intra" mai tarziu din/in conferinta, inregistrarea va fi trunchiata. Ca sa nu mai vorbim de aspectul ca vor fi mai multe inregistrari (pentru fiecare participant), multe dintre ele fiind in paralel - deci o incarcare suplimentara a sistemului.

Este clar ca aceasta abordare a fost gresita si am schimbat-o prin renuntarea la optiunea "r" pentru fiecare participant si introducerea in conferinta a unui participant fals. Acesta va fi de tip "listen" (doar ascultare) si va fi singurul ce va inregistra conferinta, pana la sfarsitul ei. Sfarsitul acesteia se face cand ultimul participant iese din camera de conferinta. Pentru a fi sigur ca ceva nu scapa de sub control s-a limitat la 3600 de secunde (1 ora) durata maxima a inregistrarii pe care utilizatorul fals o face.

Nu pot decat sa sper ca noua versiune (0.6) va fi mult mai folosita decat pana acum.