c

Essendo utilizzatore anche di linee telefoniche VoIP erogate da Skypho - noto al pubblico come interfaccia semplice e immediata ai servizi telefonici (e non solo) di Eutelia, seguo da vicino l'evolversi di tale "coppia". Dall'inizio di Marzo 2007, Eutelia ha sostituito i propri server proxy di erogazione del servizio al pubblico, mettendo "in ginocchio" alcuni utilizzatori di centralini basati sul software Asterisk.

Va subito detto che la problematica presentatasi non ha colpito, invece, la maggior parte degli utilizzatori di normali ATA o telefoni IP (se non sapete cosa si intende con tali definizioni, leggete qui). Tali utenti costituiscono la maggioranza dei privati, mentre le aziende normalmente impiegano centralini, i quali sono sempre più spesso basati su Asterisk. Sorvoliamo sul motivo per cui "Asterisk si e gli altri no", esula dallo scopo di questa pagina.

Questa è un'occasione in cui ho serie difficoltà a mantenermi tra il gergo tecnico e l'universalmente comprensibile, non me ne volete se dovessi "sconfinare".

Il problema

{mosgoogle right}

Ricordiamo innanzi tutto che (come mi è stato raccomandato dal servizio clienti Skypho, da me in precedenza contattato non sapendo che fosse stata operata una totale sostituzione) non è buona pratica utilizzare l'indirizzo IP nelle tuple di gestione. E' vero che impiegarlo permette di non far fare ad Asterisk richieste al DNS, ma qualora - come è accaduto in questa circostanza - il proxy di riferimento dovesse cambiare indirizzo IP, occorre modificare ogni tupla in cui l'indirizzo IP non risulta più attivo, sostituendolo con quello nuovo. E', invece, pratica molto migliore far girare sul proprio centralino Asterisk il DNS Caching Server, che produrrà un risparmio di tempo equivalente ma eviterà il presentarsi di simili "malintesi".

Finora, chi ha programmato Asterisk per collegarsi, mediante protocollo SIP, ai server VoIP di Eutelia (ciò vale anche per Skypho e per tutti i rivenditori di servizio Eutelia) lo ha fatto definendo un trunk di collegamento con il fornitore, nelle varianti più o meno complesse, in questo modo (gli esempi si riferiscono a Trixbox con interfaccia Freepbx ma per le altre configurazioni il concetto è lo stesso):

SIP.CONF

register=numerotelefono:password@voip.eutelia.it/interno

dove numerotelefono è il numero di rete telefonica pubblica assegnato, password è la password di accesso al server VoIP, interno è l'interno connesso ad Asterisk a cui erano inviate le chiamate in ingresso provenienti dalla linea VoIP.

TRUNK (alcuni preferiscono usare solo la prima parte, definendosi "friend" anziché "peer" per l'ingresso" e "user" per l'uscita: riporto il doppio metodo per chiarezza):

Porzione per le chiamate in ingresso

[Eutelia]

username=numerotelefono

type=peer

secret=password

qualify=yes

port=5060

insecure=very

host=voip.eutelia.it

fromuser=numerotelefono

dtmfmode=auto

disallow=all

context=from-trunk

canreinvite=no

allow=alaw

allow=ulaw 

Porzione per le chiamate in uscita

[numerotelefono]

username=numerotelefono

type=user

secret=password

qualify=yes

port=5060

host=voip.eutelia.it

fromuser=numerotelefono

dtmfmode=auto

disallow=all

context=from-internal

canreinvite=yes

allow=alaw

allow=ulaw 

Questa soluzione, che fino a pochi giorni fa ha funzionato in modo ineccepibile, dava per scontato che il server SIP a cui si era collegati non inviasse alcun DID al centralino Asterisk, il quale si limitava a raccogliere la chiamata e inviarla all'interno dichiarato nella tupla di registrazione.

La recente operazione di aggiornamento ha cambiato (rendendolo più aderente alle specifiche) il modo di contattare il destinatario, rendendolo - tra l'altro - analogo a quello richiesto per ricevere le chiamate per i clienti di Broadvoice.

L'assenza di una mirata modifica alle impostazioni di programmazione per adeguarsi a tale variazione produce, per chi chiama una linea urbana VoIP di Eutelia connessa con il centralino Asterisk, nella maggior parte dei casi, un cocente "Eutelia, informazione gratuita: l'utente selezionato non è al momento raggiungibile", pur permettendo - se non avete usato l'indirizzo IP al posto del FQDN - di effettuare regolarmente chiamate in uscita.

La soluzione

Se il server SIP invia il DID, non possiamo far finta di nulla: occorre gestirlo. In Asterisk, lo si deve creare con un "nome" identico al DID che ci viene inviato. Se, per esempio, il numero che abbiamo fosse 0234567890, dovremo:

1) creare un apposito DID in extensions.conf:

exten => 0234567890,1,Set(FROM_DID=0234567890)

(in Trixbox si trova in extensions_additional.conf e lo si può fare da Freepbx)

3) Gestire l'instradamento della chiamata in ingresso a partire dal DID creato.

Quest'ultima operazione è a "piacere" o a "necessità" dell'utilizzatore: può esser fatto verso uno specifico interno, verso un gruppo, una coda o un risponditore.

Garantito che questa operazione - peraltro ancora non necessaria con altri fornitori (es. Messagenet o Voiptalk), riporterà alla luce le vostre linee telefoniche in ingresso.

NON chiamate l'assistenza tecnica Eutelia: la rumena che vi risponderà, poverina, sa a malapena - forse - di cosa stiamo parlando. Proverà a dirlo ai tecnici, ma l'unica cosa che essi capiranno è che c'è un utente a cui Asterisk non funziona e le chiederanno di rispondervi che è Asterisk a dar problemi: non potete certo aspettarvi che vi dicano cosa cambiare nella configurazione. Evitate anche di scrivere a Skypho, se potete, o li ucciderete di e-mail. Spero solo che mettano ben in evidenza un avviso con il link per far leggere questa pagina.

E per qualsiasi dubbio, come al solito, scrivetemi.

Condividere questa pagina su: