Archivio

Archive for novembre 2009

Più servers Asterisk, un unico centralino

27/11/2009 1 commento

Tra i file di configurazione di Asterisk, vincono a pari merito la il premio per i più inutilizzati extensions.ael e dundi.conf. La comunità degli utilizzatori del famoso IPPBX non sembra aver apprezzato lo sforzo di Mark Spencer e soci nel creare qualcosa di più dei soliti servizi. Eppure si tratta di due funzionalità molto potenti che semplificherebbero di molto la vita dei progettatori. Di AEL abbiamo già parlato in un precedente post, oggi volevo parlarvi dei miei esperimenti con DUNDi.

A cosa serve questo nuovo protocollo della premiata ditta Digium? A fare quello che tutti i progettatori di reti VoIP basate su Asterisk chiedevano da anni, anche se, quando la soluzione è arrivata nessuno se ne accorto. Con DUNDi è possibile condividere i piani di numerazione di macchine diverse, senza dover ricreare gli interni su ciascuna macchina. L’uovo di colombo è questo protocollo cifrato che interroga i vari servers alla ricerca dell’interno cercato, ricevendo come risposta l’indirizzo esatto a cui sparare la chiamata, sempre se esiste. La tecnica non è innovativa, dato che viene usata da tutti i principali software per il peer2peer ma unita alle qualità di Asterisk, fornisce un qualcosa di rivoluzionario.

Com’è ormai usanza di questo blog, voglio mostrarvi un semplice esempio applicativo. A tale proposito supponiamo di avere due aziende, la Acme Corporation e la Experience Ltd, dotate entrambi del loro bel Asterisk Server, con connesso un flusso primario dal quale ricevono e fanno chiamate. Ad un certo punto la Acme compra la Experience e le due aziend econdividono la stessa rete. Gli amministratori decidono di unificare i centralini per non passare dalla rete telefonica nazionale, quando la chiamata è da un interno di un’azienda all’altra. Le due macchine sono così fatte:

Asterisk Acme :                   IP address 192.168.1.10                   MAC Address: 11:11:11:11

Asterisk Experience :          IP address 192.168.2.10                   MAC Address: 22:22:22:22

Si decide di creare un link DUNDì tra le due, cosa fattibile in pochi semplici passi.

Generazione delle chiavi pubbliche e private

In Asterisk Acme, sotto il path /var/lib/asterisk/keys digitare:

astgenkey -n Acme

verranno generati due files, Acme.key e Acme.pub . Acme.pub deve essere copiato nella stessa sottodirectory nel server Asterisk Experience. La stessa operazione andrà eseguita, in verso opposto, sostituendo “Experience” nel comando astgenkey, nell’Asterisk di Experience Ltd.

DUNDi.conf

A questo punto bisogna configurare il DUNDi, dichiarando le altre macchine che compongono il mega centralino. Nel nostro caso è facile perché sono solo due, ma il principio è lo stesso anche per molte macchine.

Nella prima sezione del file dundi.conf si dichiarano informazioni sulla collocazione della macchina locale e sul criterio di interrogazione delle altre macchine. Per il server Acme sarà:

[general]
organization= Acme Corporation
locality= Zona indistriale
stateprov= Milano
country=It
email=amministratore@acme.com
phone=+39.0255.144.915
bindaddr=0.0.0.0
port=4520
entityid=11:11:11:11  ; Per convenzione il MAC del server
cachetime=3600
ttl=5                 ; 2000 + ttl * 200 = 3000ms di attesa massima per le query DUNDi
autokill=yes
secretpath=dundi
storehistory=no

Segue poi una sezione in cui si dichiarano i criteri di ricerca degli interni nelle altre macchine e nella macchina locale. Sparo la parte di configurazione e poi l’analizzo:

[mappings]
priv => ext-condivise,0,IAX2,priv:${SECRET}@192.168.1.10/${NUMBER},nopartial

Il canale di ricerca DUNDi si chiama priv. E’ uno solo ma se ne possono avere quanti se ne vuole. Se una macchina esterna interroga questo server alla ricerca di un interno, si deve controllare un contesto del file extensions.conf chiamato [ext-condivise] per avere una risposta. E’ quindi possibile condividere solo gli interni che si vuole, vedremo poi come. Se l’interno che l’altro server cerca esiste, questo è contattabile in IAX sparando la chiamata al contesto IAX che si chiama priv. Esiste quindi un contesto IAX che accetta chiamate con autenticazione criptata, che accede ai contesti extensions di questa macchina.

L’ultima parte di questo file di configurazione è la dichiarazione dei servers che compongono il mega centralino. Si avranno tante sezioni come quella che segue. Nel nostro caso è solo una perché si ha un solo server da controllare, oltre il locale.

[22:22:22:22] ; MAC address del server Experience
model = symmetric
host = 192.168.2.10 ; IP del server Experience
inkey = Experience
outkey = Acme
include = priv
permit = priv
qualify = yes
order = primary

Et voila, il file dundi.conf è servito. Da notare che abbiamo citato parti dell’extensions.conf e dello iax.conf che dobbiamo andare a creare. Per la macchina Experience, il file dundi.conf sarà esattamente simmetrico, apportando le giuste modifiche.

IAX.conf

La parte IAX è forse la più semplice. Inanzi tutto è bene specificare che si poteva usare anche il SIP o l’H323 come protocollo, ma in Asterisk tutto è più semplice usando IAX per il trunking. Si tratta di creare un contesto per accettare le chiamate dagli altri server sulla base di un’autenticazione del tipo chiave pubblica/chiave privata ( a questo servono i file creati al primo step).

[general]
bindport = 4569
bindaddr = 0.0.0.0
disallow=all
allow=alaw
allow=gsm
mailboxdetail=yes

[priv]
type=friend
dbsecret=dundi/secret
context=incoming-dundi

La prima parte è un semplice contesto general di iax.conf. Nella seconda si dice che si accettano chiamate nel contesto [priv] , l’autenticazione usa il dbsecret del DUNDi e il contesto in extensions.conf che gestisce la chiamata si chiama [incoming-dundi]. Il dbsecret del DUNDi è un campo del DB interno Asterisk che viene continuamente modificato dal processo DUNDi secondo le chiavi segrete locali e pubbliche remote. Questo iax.conf può essere copiato pari pari nella macchina Experience, oppure basta aggiungere il contesto [priv].

Extensions.conf

Per finire l’opera bisogna popolare il file extensions.conf con tutti i contesti definiti nei precedenti files. Devo premettere che ho implementato questa soluzione tra due macchine con Freepbx , quindi non ho toccato extensions.conf, bensì extensions_custom.conf, ma la sostanza non cambia. Per prima cosa si crea un contesto dove si mostrano i numeri condivisi, come segue:

[ext-condivise]
exten => 0211144947,1,NoOp
exten => 0211144945,1,NoOp
exten => 0211144939,1,NoOp

Ho scelto di pubblicare i numeri esterni del centralino e non gli effettivi interni, perché volevo che le chiamate in arrivo dall’altro centralino fossero trattate come quelle in arrivo dalla Rete Telefonica. Così l’operatore di Experience che era abituato a fare il numero pubblico di un collega Acme, non si accorgerà del passaggio. Un interno è pubblicato e visibile agli altri server se si trova in questo contesto. Poi si crea il contesto che gestisce le chiamate in arrivo dal trunk iax:

[incoming-dundi]
include => from-trunk

Sempre perché lavoro su freepbx, ho incluso il context from-trunk, dove la chiamata viene trattata come se arrivasse dalla PSTN. Quando l’operatore Experience chiama il numero del collega Acme, il DUNDi fa un’interrogazione criptata sul contesto [ext-condivise] cercando il numero chiamato e, se lo trova, spara la chiamata sul trunk iax che la fa gestire dal contesto [incoming-dundi]. Sembra complicato ma ha una logica lapalissiana.

A questo punto manca solo un contestino per fare le query nell’altro verso: dalla macchina Acme a quella Experience. Segue lo striminzito contesto:

[lookupdundi]
switch => DUNDi/priv

Switch è l’extension che scatena la query usando il protocollo DUNDi sul contesto DUNDi chiamato [priv]. That’s all folks a livello di files di configurazione. Su Freepbx ho dovuto creare un trunk custom per sparare le chiamate prima sul DUNDi e poi, se non esisteva il chiamato sull’altro server, sulla rete telefonica pubblica.

Infine basta mettere come prima scelta nell’outboundroute generale il trunk appena creato, prima dell’uscita su PSTN. E il gioco è fatto.

Annunci

Un softphone per Ubuntu Karmic Koala

Alla fine ho fatto il grande passo, eliminando Windows dal mio PC e sostituendolo con una Ubuntu nuova di fabbrica, la Karmic Kola (9.10). Tra i tanti software di cui trovare un equivalente linux, c’era l’indispensabile softphone. Per chi non lo sapesse, un softphone non è altro che un telefono software che appare sul desktop, con il quale si può chiamare in tutto il mondo utilizzando un paio di cuffie con microfono, stile call center. Il più famoso è Skype, ma ho sviluppato negli anni un’allergia per tutto ciò che è proprietario e chiuso, preferendo gli applicativi che si aprono a standard ben noti e replicabili. Perciò mi sono messo alla ricerca di un softphone che supportasse protocollo SIP, al fine di usarlo con il mio provider VoIP di riferimento: Eutelia.

Il primo tentativo è stato con il famoso X-Lite della Counterpath. Non vi nascondo la delusione nel vedere che lo sviluppo per sistema operativo Linux si è fermata alla prima versione. Vengono richieste le librerie stdc++ versione 5.0, che Ubuntu non usa più da tempo e quindi uno se le deve scaricare a mano. Il resto è storia: il vecchio manuale su EuteliaVoIP vi guiderà facilmente nella configurazione.

Qualcuno dirà: ma c’è Ekiga, perché non usi quello? Semplicemente è rozzo, anche se ha molte funzionalità, tra cui la video chiamata. Mi sa che gli sviluppatori dovrebbero pensare a drgli una sistemata, anche dal punto di vista estetico.

Una simpatica novità è stato Twinkle, software installabile con un click dal repository Ubuntu. Come molti softphones free, Twinkle è l’aggancio che una società che vende traffico VoIP usa per farsi nuovi clienti. Ciò non togliè che è utilizzabile con qualunque operatore e la cosa è spiegata molto chiaramente allo start-up. Per iniziare ad usarlo ho preferito l’opzione più dura, la creazione manuale di un profilo (Profile Editor).

A questo punto, dopo aver dato un nome qualsiasi al profilo, si inseriscono i dati dell’account:

e quando la stella diventa gialla, siete registrati. Cosa, tra l’altro prontamente comunicata nel log della finestra centrale. L’interfaccia è essenziale ma non manca nulla. Molta comoda la finestrella su cui poter copiare i numeri di telefono presi dalle mail ricevute o da documenti di testo. Si hanno due linee, quindi è possibile mettere in attesa e switchare sulla seconda linea o fare conferenze a tre. Si può inserire il DND (non disturbarmi) così da non riceve re nessuna chiamata, si può mettere in attesa o trasferire ad un altro numero (con Eutelia non funziona per volontà del provider, non del telefono), si possono creare rubriche da utilizzare con un click, nonché accounts con altri operatori per avere più numeri di telefono sullo stesso softphone. Simpatica anche la possibilità, in stile cellulare, di inserire brani diversi che vengono suonati al posto dello squillo tradizionale.

Il secondo test è stato Zoiper, un softphone pensato per interagire con Asterisk, ma utilizzabile con qualunque provider. Zoiper non è nel repository ma l’installazione è semplicissima: basta collegarsi a http://www.zoiper.com, andare nella sezione download e scegliere quello più adatto al proprio hardware. Nel mio caso ho scelto “Jaunty with ALSA 32 bit” che funziona bene anche con Karmic Koala. L’installatore pacchetti Debian farà il resto per voi, facendovi trovare l’applicativo sotto Applicazioni/Internet.

Premete sul link “I do not want use this service” per evitare di usare Zoiper come voip provider e passare alla configurazione del vostro account. Selezionate da menu Zoiper/Preferences e sulla barra di sinistra che appare cliccate su “Create new SIP account”. A questo punto inseriamo i soliti parametri:

Premendo OK e ritornando su preferences, si può verificare se la cosa è andata in porto (si leggerà Registered) o no. A questo punto le opzioni sono molteplici, tra cui, udite udite, inviare un file tiff come FAX. I miei test non hanno dato esiti esaltanti ma va apprezzata l’innovazione dell’idea. Se Zoiper vi piace, ce n’è una versione più potente a pagamento, che supporta anche video e altre funzionalità avanzate.

In conclusione, ancora una volta il software libero ha dimostrato di essere completamente autonomo in campo VoIP…c’è ancora qualcuno che lo vede come roba da nerds?

Asterisk Extension Language (AEL): chi era costui?

12/11/2009 2 commenti

Asterisk è ormai sulla bocca di tutti. Chi si occupa di VoIP in maniera professionale ha sentito nominare almeno una volta questo fantastico software (quasi) open, non fosse altro per le decine di funzionalità che implementa.

Chi lo usa da tempo sa che, per gestire il comportamento di una chiamata, è necessario dettagliare, step by step, tutti i passaggi e le applicazioni che entrano in gioco, con una programmazione che ricorda il Basic di qualche decennio fa:

exten => 123,1,Answer
exten => 123,2,Wait(1)
exten => 123,3,Voicemail(123)
exten => 123,4,Hangup

Questo sistema, abbastanza intuitivo, ha un senso nella configurazione di dialplans molto brevi ma risulta illeggibile e complicato da usare se è necessario fare ricorso a salti condizionati (gotoif), condizioni temporali (gotoiftime) etc. etc.

Esiste orma dalla release 1.2 di Asterisk un linguaggio di programmazione (AEL appunto) realizzato per porre rimedio all’illeggibilità del dialplan tradizonale. Solo per fare un esempio, il codice che ho appena scritto, in AEL diventa:

123 => { Answer();
         Wait(1)
         Voicemail(123);
         Hangup();
       }

Si noti la maggior leggibilità: ogni chiamata con destinazione 123 viene gestita secondo quanto posto tra parentesi graffe.

Se il tradizionale dial plan veniva inserito nel file extensions.conf , il dial plan scritto in AEL sarà contenuto in extensions.ael. Un compilatore si preoccuperà poi di tradurre il nostro codice AEL nella forma “step by step” comprensibile ad Asterisk. l vantaggio in effetti è nella leggibilità del codice e nella possibilità di usare la programmazione strutturata, cosa non da poco, specialmente quando si sviluppano applicazioni complesse.

Mi sembrava interessante far notare questa funzionalità poco utilizzata di Asterisk, perché, lavorando nel VoIP non ho mai ricevuto configurazioni dai clienti fatte in AEL, mentre potrebbe essere il modo migliore per avvicinarsi a questo IPPBX.

Vi lascio con un esempio nelle due versioni. La macro seguente è un classico: chiama il numero che le viene passato come argomento, se non risponde o è occupato manda la chiamata in segreteria.

[macro-stdexten]
; Questo è un commento: macro standard per chiamare una extension
; ${ARG1} - Casella di posta
; ${ARG2} - extension da chiamare

; in main context do exten => 1000,1,Macro(stdexten,1000,1000)

exten => s,1,Dial(${ARG2},20) ; Prova a chiamare
exten => s,2,Goto(s-${DIALSTATUS},1) ; Se non va in porto ...
exten => s-BUSY,1,Voicemail(b${ARG1}) ; se occupato vai alla voicemail
exten => s-BUSY,2,Hangup ; Se premono #, chiudi
exten => s-NOANSWER,1,Voicemail(u${ARG1}) ; Se non risponde vai alla vociemail
exten => s-NOANSWER,2,Hangup ; Se premono #, chiudi
exten => _s-.,1,Playback(byebye) ; in tutti gli altri casi...byebye
exten => _s-.,2,Hangup ; chiudi

In AEL diventa :

macro std-exten( ext , mailbox ) {
       Dial(${ext},20);
       switch(${DIALSTATUS) {
       case BUSY:
               Voicemail(b${ext});
               Hangup();

       case NOANSWER:
               Voicemail(u${ext});
               Hangup();

       default:
               Voicemail(u${ext});
               Hangup();
       };

};
Categorie:Voip:Asterisk Tag:,