Vita Da Zazu

A seguito di un aggiornamento di Asterisk e qui sono stato stupido per non aver prima fatto un backup , ricordate bambini, il backup è una cosa importante, più delle forbici dalla punta arrotondata!

Insomma, mi sono ritrovato con il mio centralino casalingo che non effettuava più chiamate uscenti da nessun account VOIP;

dato che prima funzionava, poi ha smesso, 2+2=3,5… la colpa è dell’aggiornamento!

Quindi, armato di pazienza e anche di tempo, perché ho perso 4 o 5 giorni dietro al problema bestemmiofero, sono giunto a riscrivere una configurazione funzionante anche nell’ultima relase di asterisk…

vado qui ad illustrare:

per completezza questo è quanto serve dentro extensions.conf affinché quanto scritto sopra funzioni:

[incoming]

exten => cheapnet,1,Dial(SIP/INTERNO)
exten => messagenet,1,Dial(SIP/INTERNO)

[outgoing]

exten => _53.,1,Dial(SIP/${EXTEN}@messagenet)
exten => _XXX.,1,Macro(dial-failover,SIP/${EXTEN}@messagenet,SIP/${EXTEN}@cheapnet)

[macro-dial-failover]

exten => s,1,Dial(${ARG1})
exten => s,2,Goto(s-${DIALSTATUS},1)
exten => s-CONGESTION,1,Dial(${ARG2})

Quando ci serve?

Se si hanno nella stessa rete due tipologie di apparati che si vuol tenere “separati”… diciamo così.

la situazione si è verificata passando dalla telefonia analogica al voip;

questo ha comportato l’introduzione di tanti telefoni IP, e per più motivi è bene che stiano su una classe a sé.

Si dovranno quindi gestire due tipologie di apparati:

i PC e i telefoni Grandstream, impossibile gestire i telefoni con ip fisso, sono troppi, per ogni eventuale modifica servirebbe uno schiavo per editarli tutti, quindi, dato che gli schiavi sono proibiti, bisogna fare tutto con DHCP .

La configurazione è più semplice del previsto:

DHCPD3 che già veniva usato per gestire la rete, prevede la possibilità di analizzare alcune informazioni fornite dai client quando richiedono un IP, nello specifico io ho focalizzato il mio interesse sul “vendor class identifier” che generalmente identifica il produttore/modello dell’apparecchio

tutti i telefoni Grandstream hanno come vendor class identifier una stringa del genere:  Grandstream [MODEL NAME]

da questa quindi si può facilmente operare una “discriminazione” rispetto ad un qualunque PC

nel file /etc/dhcp3/dhcpd.conf andranno definiti i pattern di controllo che a seconda del caso assegneranno un IP di pool differenti, in questo modo:

dhcpd.conf

ddns-update-style none;
authoritative;
log-facility local7;
option ntp-servers it.pool.ntp.org;

#matching classes
class “ip_phones” {

match if substring (option vendor-class-identifier, 0, 11) = “Grandstream”;
}

class “computers” {

match if not (substring (option vendor-class-identifier, 0, 11) = “Grandstream”);
}

shared-network exemple.local {

subnet 172.16.150.0 netmask 255.255.254.0

{
pool {

allow members of “ip_phones”;
option domain-name “phones.exemple.it”;
option domain-name-servers 208.67.222.222, 208.67.220.220;
range 172.16.150.21 172.16.150.200;
option subnet-mask 255.255.254.0;
option broadcast-address 172.16.151.255;
option routers 172.16.151.254;
default-lease-time 1440;
max-lease-time 7200;
}

}

subnet 10.10.20.0 netmask 255.255.255.0

{
pool {

allow members of “computers”;
option domain-name “computers.exemple.it”;
option domain-name-servers 208.67.222.222, 208.67.220.220;
range 10.10.20.21 10.10.20.190;
option subnet-mask 255.255.255.0;
option broadcast-address 10.10.20.255;
option routers 10.10.20.254;
default-lease-time 1440;
max-lease-time 7200;
}

}

}

Con la direttiva “allow members” possiamo gestire perfettamente tutto il traffico, questo ci permette di avere anche più di due pool, possiamo inoltre definire più pattern di verifica e accettare in un pool più tipologie:

se un giorno verranno introdotti dei telefoni Snom, potranno essere comunque assegnati alla LAN telefonica verificando sempre il loro vendor class identifier

Lavorando in un’azienda multisede, dopo aver sostituito tutti i vecchi centralini analogici con Asterisk, la prima richiesta fatta è:

si può far sì che le nostre telefonate infra-sede siano gratuite?

La risposta è ovviamente si (a patto che le sedi da collegare abbiano una connessione adsl, o comunque a banda larga ma questo è un altro discorso)

dopo un minimo di studio della problematica sono arrivato alla scelta di IAX come protocollo di interconnessione asterisk to asterisk.

Oltre ad essere il protocollo nativo di asterisk, iax ha anche altri vantaggi; per esempio:

• può incapsulare tutto il traffico in un unico canale;
• usa una sola porta di comunicazione;
• l’attraversamento delle NAT è nativo, e non da problemi;
• permette di selezionare il punto di arrivo nel dialplan di destinazione  sin dall’origine….

…e comunque tante altre piccole funzionalità che nell’insieme lo rendono imbattibile.

INSOMMA COME SI INTERCONNETTONO DUE CENTRALINI IN MANIERA SEMPLICE?

la soluzione è stata più semplice del previsto e l’idea di base è paragonabile a quella su cui si basa una VPN

ma veniamo al sodo:

abbiamo due centralini (Homer e Marge) di cui vado ad illustrare iax.conf:

Le righe da inserire in extensions.conf a questo punto sono abbastanza semplici e logiche;

occorre una riga nel contesto di uscita con un prefisso di nostro gradimento (99) per chiamare gli interni dell’altro e una riga per le chiamate entranti:

Le chiamate “fromiax” le redirigo in outgoing perché nel mio caso questo è anche il contesto in cui si trovano gli interni.

Ora si pone un piccolo problema:

come distinguere chi chiama dall’altra sede?

Se la reception nella sede “Marge” chiama un interno nella sede “Homer” quest’ultimo vedrà arrivare una chiamata da “Reception”, indistinto dalla reception locale;

questo effetto collaterale può generare molta confusione e per ovviare a ciò ho pensato ad una piccola macro, questa imposta il CallerID a seconda della sede di provenienza, extensions.conf quindi andrà così modificato:

buon asterisk a tutti.

informazioni d base tratte da: astrecipes.net

Ok, se sei arrivato qui hai tentato di aggiornare il firmware di un GXP-2000 e qualcosa è andato storto.

Non è detto che un aggiornamento fallito comporti l’aver “brickato” definitivamente il telefono…

come capire se il nostro telefono è recuperabile?

i sintomi di un brick reversibile sono:

• led tutti accesi e luce MWI lampeggiante;
• una scritta sullo schermo ci informa che sta tentando il recovery del firmware via TFTP.

In queste condizioni il nostro telefono può essere resuscitato;

armati di buona volontà iniziamo ad allestire la sala operatoria:

personalmente uso OpenSUSE come sistema operativo, quindi alcuni dei comandi usati saranno prettamente validi solo su questa distribuzione.

Ci occorrerà un server TFTP:

# zypper in atftp

ora dobbiamo configurare ed attivare il server TFTP;

per prima cosa occorre creare la cartella “root” del nostro server (per comodità io l’ho creata sul mio desktop):

$ mkdir /home/zazu/Scrivania/tftp

ora scarichiamo dal sito della Granstream l’ultimo firmware disponibile per il GXP2000 e scompattiamo il tutto dentro la nostra cartella “tftp”, i files strettamente necessari sono: “boot55.bin” e “gxp2000.bin” ma per sicurezza meglio metterli tutti

adesso dobbiamo avviare il server, lo facciamo molto semplicemente con questo comando:

# atftpd --daemon /home/zazu/Scrivania/tftp/

per verificarne il funzionamento, con “netstat -natup | grep 69″ possiamo verificare l’esistenza del server tftp in ascolto.

PASSO 2

Configuriamo la rete e abbassiamo SuSEfirewall.

Consiglio di mettere uno switch tra noi e il telefono per evitare di perdere le configurazioni della nostra scheda di rete;

i parametri da impostare sono i seguenti:

# rcSuSEfirewall2 stop
# ifconfig eth0 168.75.215.188 netmask 0.0.0.0 up
# route add default gw 168.75.215.188

Adesso accendiamo il nostro Grandstream (collegato allo switch) e se tutto è corretto questo inizierà il recovery  TFTP  e sarà in grado di recuperare il firmware dal nostro computer

quando avrà finito sarà diventato nuovamente funzionante