Inter Asterisk Xchange

Da Wikipedia, l’enciclopedia libera.

In telecomunicazioni e informatica IAX (acronimo per Inter Asterisk Xchange) è un protocollo di comunicazione utilizzato da Asterisk, un server PBX open source della Digium. Si usa per abilitare connessioni VoIP tra i server Asterisk e tra server e client che utilizzano lo stesso protocollo.Il protocollo IAX2 fu creato da Mark Spencer per Asterisk per il segnale VoIP. Il protocollo crea delle sessioni interne e queste sessioni possono utilizzare qualunque codec per la trasmissione della voce. Il protocollo Inter-Asterisk Exchange essenzialmente fornisce il controllo e la trasmissione del flusso di dati su reti IP. IAX è estremamente flessibile e può essere utilizzato per ogni tipo di flussi di dati, compreso il video anche se è stato progettato soprattutto per il controllo delle chiamate vocali sulle reti IP. Il progetto del protocollo IAX fu basato su vari standard di controllo e trasmissione tra cui il Session Initiation Protocol (SIP, che è il più comune), Media Gateway Control Protocol (MGCP) e Real-time Transport Protocol (RTP).

Il principale obiettivo del protocollo IAX fu quello di minimizzare la larghezza di banda necessaria per la trasmissione dell’informazione prestando particolare attenzione al controllo, alle chiamate vocali individuali e al supporto nativo per l’utilizzo trasparente su reti con NAT. La struttura di base del protocollo IAX permette di miscelare i segnali e più flussi di dati su un singolo flusso UDP tra due computer. Lo IAX è un protocollo binario ed è organizzato in modo da minimizzare l’overhead in particolare riguardo ai flussi vocali. IAX2 è un protocollo robusto e completo rimanendo al contempo semplice. È indipendente dal codec e dal numero di flussi quindi può essere usato in teoria per il trasporto di qualunque tipo di dato (questa caratteristica diventerà utile quando il videotelefono diventerà comune).

Utilizza un singolo flusso dati UDP (di solito sulla porta 4569) per comunicare tra i due sistemi sia per il controllo che per i dati. Il traffico voce è trasmesso in banda rendendo più semplice per l’IAX2 l’attraversamento di un firewall e più probabile che lavori dietro una rete con NAT (il protocollo SIP invece utilizza un flusso fuori banda RTP per il trasporto delle informazioni).

Supporta il trunking per trasportare su un singolo collegamento dati e segnali per più canali. Quando è attivo il trunking più chiamate sono unite in un singolo insieme di pacchetti quindi un singolo datagramma IP può trasportare informazioni relative a più chiamate riducendo l’effettivo overhead senza creare ritardi addizionali. Questo è un vantaggio notevole per gli utilizzatori del VoIP dove le intestazioni IP occupano una grossa percentuale della larghezza di banda.
Utilizzo della banda

Il protocollo IAX permette di sfruttare efficacemente la banda disponibile per trasmettere il massimo numero di canali possibile. Si può utilizzare IAX in una di due configurazioni: trunk, no-trunk. Nella prima si ottimizza la segnalazione trasmettendo in un singolo pacchetto IP/UDP i campioni relativi a più canali voce, mentre nella seconda i canali voce utilizzano pacchetti IP differenti.

Se prendiamo come esempio una trasmissione con codec G.729, che ha periodo di campionamento di 20ms, ovvero che trasmette il flusso vocale in gruppi di 2 campioni di 10ms ciascuno, abbiamo che in un singolo pacchetto IP/UDP, con un header IAX di 8 byte, e 2 byte aggiuntivi per singolo canale voce, possiamo trasmettere decine di canali, con un limite non vincolante dato dall’MTU di rete, con solo 2byte aggiuntivi per ogni canale a partire dal secondo.

In modalità non trunk ogni singolo canale voce richiede 4byte di header IAX, e per ogni 20ms di campioni. Considerando quindi una lunghezza fissa dell’header IP/UDP di 28bytes, ogni pacchetto trasmesso ha dimensione 28+4+20=52 bytes, un risparmio rispetto l’uso di RTP, che implica 12byte di overhead per pacchetto, ma sicuramente un overhead eccessivo rispetto IAX in modalità trunk.

E dopo tutta questa teoria vediamo come si comporta Asterisk e la nostra radio vedendo nel dettaglio il file di configurazione iax.conf.

È possibile aggiungere ulteriori sezioni utente, specificando un contesto e una password utilizzata per le connessioni con quel dato “nome” di autenticazione. Il controllo dell’accesso basato su IP limitato è consentito mediante l’uso delle parole chiave “Permetti” e “Nega”. Sono consentite più regole. È possibile specificare più contesti consentiti, nel qual caso il primo sarà l’impostazione predefinita. Puoi anche sovrascrivere l’ID chiamante * in modo che quando ricevi una chiamata imposti l’ID chiamante * in modo che corrisponda a ciò che desideri invece di fidarti di ciò che fornisce l’utente remoto. Sono supportati tre metodi di autenticazione: MD5, testo normale e rsa. Il meno sicuro è “testo normale”, che invia le password in chiaro attraverso la rete. “Md5” utilizza una disposizione somma md5 challenge / response, ma richiede comunque che entrambe le estremità abbiano accesso in testo normale al segreto. “Rsa” consente la conoscenza segreta unidirezionale tramite chiavi pubbliche / private. Se viene utilizzata l’autenticazione “rsa”, “inkeys” è un elenco di chiavi pubbliche accettabili sul sistema locale che possono essere utilizzate per autenticare il peer remoto, separate dal carattere “:”. “Outkey” è una singola chiave privata da utilizzare per autenticarsi dall’altra parte. Le chiavi pubbliche sono denominate /var/lib/asterisk/keys/<name>.pub mentre le chiavi private sono denominate / var / lib / asterisk / keys / <name> .key. Le chiavi private dovrebbero essere sempre crittografate 3DES. passiamo ora al concreto vedendo nel dettaglio il file che si trova all’interno di allstar .

Le contrattazioni con il server  precedenti consentono solo l’utilizzo di codec GSM, ADPCM e ULAW per le connessioni in uscita. Questo è il contenuto standard della stanza [general]  inclusa in iax.conf

[general]

bindaddr=0.0.0.0

disallow=all

allow=gsm

allow=g726aal2

allow=ulaw

jitterbuffer=yes

forcejitterbuffer=yes

dropcount=2

maxjitterbuffer=4000

maxjitterinterps=10

resyncthreshold=1000

maxexcessbuffer=80

minexcessbuffer=10

jittershrinkrate=1

tos=0x1E

autokill=yes

delayreject=yes

iaxthreadcount=30

iaxmaxthreadcount=150

La stanza [radio] controlla i tipi di codec che possono essere usati, come vengono selezionati (o negoziati) e il contesto da chiamare in extensions.conf quando si verifica una connessione in entrata da un nodo remoto. La sezione [radio] è simile a questa  suggerita :

; Incoming radio connections [radio]

type=user

disallow=all

allow=g726aal2

allow=gsm

codecpriority=host

context=radio-secure

transfer=no

La configurazione consente solo connessioni in entrata (tipo = utente) e solo codec ADPCM e GSM (disallow = all, allow = g726aal2 e allow = gsm). L’ordine di selezione (negoziazione) è determinato da questa macchina (codecpriority = host) ed è nell’ordine specificato dalle istruzioni allow (prima ADPCM, secondo GSM). Il contesto da chiamare in extensions.conf è radio-secure (context = radio-secure). E i trasferimenti di chiamata a sistemi esterni non sono consentiti (trasferimento = no) Aggiungere il supporto per un altro codec è abbastanza semplice. Ad esempio, se vogliamo consentire l’uso del codec ulaw sulle connessioni in entrata, tutto ciò che sarebbe richiesto è aggiungere un’istruzione allow = ulaw alla stanza [radio] .

[radio] type=user

disallow=all

allow=ulaw

allow=g726aal2

allow=gsm

codecpriority=host

context=radio-secure

transfer=no

collegamento via IAX2                                                  collegamento via USRP