Marco's Informatik Blog

I toni dtmf sono molto importanti nella telefonia, sia classica che ip, basti pensare che sono indispensabili per i menù dei vari IVR (che personalemente odio )
Nella stragrande maggioranza dei telefoni IP, per impostazione predefinita abbiamo toni dtmf in-band (oppure in-audio), ma questa modalità può dar problemi con la voicemail.
Inoltre questa modalità funziona se c’è abilitato il codec ulaw (o alaw), altrimenti la compressione potrebbe “danneggiare” il tono distorcendolo.
Per funzionare con le voicemail i toni dovranno essere rfc2833 o SIP info.
Altresì potete impostare auto, così facendo Asterisk se un dispositivo non sarà in grado di gestire un tono rfc2833, sarà usato inband.
Dimenticavo, dtmfmode= auto, rfc2833 o inband in sip.conf o iax.conf o in ogni singola estensione.

Social Bookmarks

Hide Sites

Continuiamo la carrellata di post dedicati al collegamento di più Asterisk.
Adesso mettiamola sul difficile! Colleghiamo quattro server!
Dobbiamo decidere se optare per una configurazione peer to peer (dove tutti i server hanno le “rotte” per gli altri) oppure un server “centrale” che conterrà le rotte per tutti gli altri, ed ogni server avrà una riga nel dialplan per indirizzare le chiamate per gli altri verso questo “hub”.
Analiziamo brevemente vantaggi e svantaggi delle due soluzioni

Vantaggi P2P

Se un centralino cade, tutti gli altri sono raggiungibili senza problemi, indipendentemente dal nodo offline.
Le chiamate inoltre sono “spalmate” tra i vari PBX, con minore uso di risorse.
Svantaggi P2P

Ogni centralino deve avere una “tabella di routing” che va costantemente aggiornata (su tutti i pbx, ogni volta viene aggiunto un nuovo nodo).
E’ anche vero che questi eventi sarebbero rari e non dipenderebbero dall’aggiunta di interni, ma solo di nuove rotte. (un conto è avere 8-10 server, un conto 100).
Vantaggi “HUB”

Un unico “master” che contiene le rotte di tutti i centralini, quindi una sola tabella da aggiornare.
Controllo centralizzato delle chiamate, rotte, monitoraggio e così via.
Svantaggi “HUB”

Tutto il traffico tra i nodi passa da questa macchina, gli svantaggi sono ovviamente maggior carico sul server, e se muore questo sono drammi!

Cenni su iax.conf e extensions.conf
In ognuno dei due casi sarà opportuno mettere come context predefinito in sip.conf e iax.conf qualcosa del tipo from-internet, per intercettare le telefonate provenienti da centralini “esteri”.
“p2p”
in iax.conf saranno presenti tanti utenti quanti sono i centralini -1, quindi qualcosa nella forma (dove con il contesto locali si intende qualcosa che fa parte della stessa “rete”, potrebbe essere usato anche rete-asterisk”)

ESEMPIO PBX-A
[pbx-b]
type=user
host=IP_DI_B
context=locali
secret=*********
trunk=yes
[pbx-c]
type=user
host=IP_DI_C
context=locali
secret=*********
trunk=yes
…
…

inoltre saranno necessari i vari peer per comunicare con gli altri PBX (per non dover scrivere utente e password nel dialplan)

[trunk_to_b]
type=peer
host=IP_DI_B
username=pbx-a
secret=*********
context=locali
[trunk_to_c]
type=peer
host=IP_DI_C
username=pbx-a
secret=**********
context=locali
……
……

Useremo invece che la classica dial, switch, che permette di effetuare il “forwarding” delle telefonate verso un altro pbx
Es. numerazione PBX-B 31XXX, PBX-C 32XXX, PBX-D 33XXX

exten=>_31XXX,1,Goto(switch_to_b,${EXTEN},1)
exten=>_32XXX,1,Goto(switch_to_c,${EXTEN},1)
exten=>_33XXX,1,Goto(switch_to_d,${EXTEN},1)
[switch_to_b]
switch => IAX2/trunk_to_b/locali
[switch_to_c]
switch => IAX2/trunk_to_c/locali
[switch_to_d]
switch => IAX2/trunk_to_d/locali

Come risulta ovvio nel caso del p2p, tutti avranno le regole per raggiungere gli altri, mentre nel caso dell’uso dell’hub, lui avrà le regole per raggiunegre tutti gli altri, mentre tutti i PBX normali avranno una cosa del tipo

exten=>_3XXXX,1,Goto(switch_to_hub,${EXTEN},1)
[switch_to_hub]
switch => IAX2/trunk_to_hub/chose_way
Quindi nell’HUB

[chose_way]
exten=>_30XXX,1,Goto(switch_to_a,${EXTEN},1)
exten=>_31XXX,1,Goto(switch_to_b,${EXTEN},1)
exten=>_32XXX,1,Goto(switch_to_c,${EXTEN},1)
exten=>_33XXX,1,Goto(switch_to_d,${EXTEN},1)

Ovviamente poi ogni centralino avrà un pattern per matchare le estensioni dei propri utenti locali, che possono avere anche più dispositivi.

[locali]
…….
…….
…….
exten=>30123,1,Dial(SIP/xlite&SIP/GXP2000,30,r)
exten=>30999,1,Dial(SIP/pippo,30,r)

Ogni utente sarà appunto un type=user ed ogni dispositivo un type=friend

Social Bookmarks

Hide Sites

Non sapevo come intitolare questo post, sono andato sulla banalità!
Per un progetto che stiamo portando avanti con un’Università, sto facendo varie prove, tra cui “interconessione” tra 2 PBX, utilizzo pratico di ENUM, fallback delle linee e tante amenità simili.
Alla base della mia demo ci sono 2 server Asterisk, uno di front-end puramente IP, un altro di back-end con una scheda Zaptel a cui è collegato un gateway gsm.
Il sistema riceve telefonate sia SIP che IAX, telefonando direttamente via questi indirizzi al PBX, oppure facendo risolvere questi servizi da ENUM (vedi qualche mio post precedente).
Innanzittutto il context di default in sip.conf e iax.conf sarà from-internet, intercettando così tutto il traffico che proviene “dall’esterno”.
In extensions.conf avremo:

[from-internet]
exten=>390577xxxxxx,1,Dial(SIP/xlite,30)
exten=>390577xxxxxx,2,GotoIf(($[${DIALSTATUS}=CHANNELUNAVAIL]?3:4)
exten=>390577xxxxxx,3,Goto(switch_to_backend,MIOCELLULARE,1)
exten=>390577xxxxxx,4,Goto(102)
exten=>390577xxxxxx,102,Hangup

Nella prima linea abbiamo che tutte le telefonate a quel numero telefonico saranno indirizzate verso l’estenzione xlite, il mio softphone.
Se questo non è collegato, la variabile DIALSTATUS assumerà valore CHANNELUNAVAIL e la chiamata (alla linea 3) sarà switchata verso il server di back-end.
La funzione switch permette di effettuare il forwarding delle chiamate verso un altro server , loggandosi con un utente di quel server e “dirottando” la chiamata in un contesto del dialplan del server remoto.
In generale switch ha questa sintassi

switch => IAX2/user:[key]@server/context

Quindi nell’extensions.conf del server di front-end avremo:

[switch_to_backend]
switch => IAX2/user:password@ip_server_backend/from-internal

Nel contesto from-internal del server di back-end ovviamente c’è un pattern che “intercetta” le chiamate verso i cellulari, quindi la chiamata sarà dirottata verso i gateway GSM (sono due porte FXO, gruppo 3, a ricerca ciclica)

exten=>_3XXX.,1,Dial(ZAP/r3/${EXTEN})

Complesso?
Non troppo!!In vostro soccorso può giungere il grandissimo voip-info.org, sia per extensions.conf che per la connessione tra due server Asterisk (e mi ci metto anche io)

Social Bookmarks

Hide Sites

Ovvero collegare due (o più centralini) Asterisk tra di loro, ad esempio collegare 2 sedi distaccate della stessa azienda, o più semplicemente parlare “a gratis” tra amici!
Sfrutteremo il protocollo nativo IAX per la comunicazione tra centralini, non è obbligatorio, ma dato che è sicuramente più semplice da usare di SIP e H.323 per questo scopo, inoltre non risente troppo della presenza di eventuali NAT.
La prima cosa da fare è configurare 2 utenti, uno per centralino, per poter ricevere le comunicazioni dall’altro, e due altri “utenti” per poter effettuare le chiamate.
Una breve puntualizzazione sui type di Asterisk:

user (può ricevere)
peer (può chiamare)
friend (può chiamare e ricevere)

Chiameremo (con molta fantasia) PBXA e PBXB.
In iax.conf di A avremo 

[to_B]
type=peer
host=IP B
username=utente_a
secret=miapasswd
context=locali

[utente_b]
type=user
host=IP B
context=locali
secret=miapasswd
trunk=yes

Ed in extensions.conf avremo: 

[outbound_to_B]
exten=>_NUMERAZIONE-PER-B,1,Dial(IAX2/to_B/${EXTEN})

Per il PBXB avremo una configurazione speculare.
Buona conversazione!! 

Social Bookmarks

Hide Sites