Il blog di DiRete

Asterisk: niente audio sui client sip remoti e firewall Sonicwall.

Il nostro centralino Asterisk è ormai ad un eccellente livello di funzionalità. Ogni giorno impariamo cose nuove e siamo ormai praticamente pronti al test da qualche cliente ed alla commercializzazione del pacchetto (vedremo, a breve, di costruire un’offerta commerciale).

Oggi, però, abbiamo riscontrato (nuovamente) un problema già visto in passato: i softphone (usiamo eyebeam) connessi da reti remote si autenticano correttamente sul centralino, ma l’audio non passa.
“Sniffando” il traffico (sul ns. server linux il comando è: tcpdump -i eth0 -n -v not port 22 (not port 22 serve per evitare che ci si autosniffi essendo collegati in ssh)) si scopre che i pacchetti RPT (Real Time Transport Protocol) vengono mandati da asterisk all’ip privato del softphone.

Si apre quindi il tema, annoso, del VOIP su reti nattate. Premesso che il centralino non è nattato ma ha un ip pubblico sulla scheda di rete, il client non è nella stessa situazione e viene nattato dal router della connessione dietro cui si trova.

La soluzione standard, “banalmente” è quella di aggiungere una riga al file sip.conf:

nat = yes

o, se come noi usate l’ottimo voiceone (ne parleremo a breve), potete anche impostare il nat direttamente sulle singole estensioni che userete fuori dalla rete dell’ufficio (non che non lo si possa fare senza voiceone, ma con quest’ultimo è, evidentemente, tutto più semplice)

Questo, di per sè, sistema le cose … a patto … di non avere un firewall Sonicwall con attivo il flag su ” Enable SIP Transformations”, perché in quel caso, il sonic ci metterà uno zampino malefico e non funzionerà nulla!!!

In effetti, dal manuale, è chiaro che il firewall con quell’opzione attiva si occupa di cambiare l’ip scritto dentro i pacchetti ma, secondo logica, dovrebbe farlo correttamente, non al contrario (l’esempio, a onor del vero, è per il caso opposto: sip client in lan nattato e proxy asterisk remoto non nattato):

Selecting Enable SIP Transformations transforms SIP messages between LAN (trusted) and WAN/DMZ (untrusted). You need to check this setting when you want the SonicWALL security appliance to do the SIP transformation. If your SIP proxy is located on the public (WAN) side of the SonicWALL and SIP clients are on the LAN side, the SIP clients by default embed/use their private IP address in the SIP/Session Definition Protocol (SDP) messages that are sent to the SIP proxy, hence these messages are not changed and the SIP proxy does not know how to get back to the client behind the SonicWALL. Selecting Enable SIP Transformations enables the SonicWALL to go through each SIP message and change the private IP address and assigned port. Enable SIP Transformation also controls and opens up the RTP/RTCP ports that need to be opened for the SIP session calls to happen. NAT translates Layer 3 addresses but not the Layer 7 SIP/SDP addresses, which is why you need to select Enable SIP Transformations to transform the SIP messages.
Tip: In general, you should check the Enable SIP Transformations box unless there is another NAT traversal solution that requires this feature to be turned off. SIP Transformations works in bi- directional mode, meaning messages are transformed going from LAN to WAN and vice versa.

Far crescere le linee telefoniche …

In DiRete abbiamo una borchia ISDN NT1 PLUS con 2 canali voce e 7 numeri di telefono.

Utilizziamo i 7 numeri per le chiamate dirette (al fax o ad alcuni interni o, ancora, ad un servizio particolare (EOLO ha il suo numero dedicato)).

Le linee ed i numeri sono poi gestiti da un centralino Asterisk (opensource!) con l’ottima interfaccia di Voiceone (progetto italiano !!!). Il tutto condito (attualmente, ma in via di evoluzione per ragioni tecniche che nn vi spiego ora x non tediarvi) da una scheda ISDN Diva Pro di Dialogic che si occupa della compressione vocale e della gestione della qualità della conversazione.

Bene. Oggi 2 canali voce cominciano a starci un po’ strettini … e non vorremmo aggiungere numeri telefonici per portare nuovi canali, poiché non vogliamo complicare la vita ai clienti. Abbiamo quindi contattato Telecom per capire che alternative ci fossero ed abbiamo scoperto che l’ufficio contattato ben si merita il titolo di UCCS: Ufficio Complicazioni Cose Semplici!

Ecco la proposta:

dall’attuale

1 borchia
2 canali voce
7 numeri telefonici

si può passare a

2 borchie configurate in c.d. “selezione passante”
4 canali voce
1 solo numero telefonico !!! 🙁

GULP! e i 6 numeri aggiuntivi? SI PERDONO !!!

In alternativa … si può prendere un accesso primario, ma c’è un minimo di 15 canali (gulp!) ed un costo decisamente più alto …

Ufffffff …

qcuno conosce qche alternativa (al momento direi … non VOIP …) 😉

Che figuraccia! (però siamo simpatici!)

Da qualche giorno sul centralino di DiRete (per i curiosi è un centralino voip basato su linux, asterisk e voiceone, magari un giorno ve lo racconto meglio 😉 ) abbiamo attivato l’IVR (Interactive Voice Response), ovvero quel sistema automatico di risposta e gestione delle chiamate che chiede di premere 1 per parlare con tizio, 2 con caio e quant’altro.

Abbiamo cercato di fare le cose per bene, poiché noi stessi odiamo gli IVR nei quali ci si perde e quindi, tanto per fare un esempio, se non viene effettuata alcuna scelta nel tempo utile si è comunque portati alla casella vocale e si può lasciare un messaggio per essere richiamati.

Per i clienti con contratto di assistenza (anche per EOLO !!! Annunceremo il contratto tra pochi giorni !!!), poi, faremo apposite regole di instradamento atte a velocizzare ulteriormente la chiamata quando il numero è riconosciuto come appartenente ad un cliente con contratto attivo.

La registrazione dei messaggi dell’IVR è stata affidata al sottoscritto … Non amo moltissimo la mia voce registrata ma mi son dato da fare. Durante i test, però, per non rendere la cosa troppo noiosa, ho ben pensato di registrare qche messaggio un po’ … ehm … poco formale (direi, piuttosto, decisamente irriverente).

Beh, manco a dirlo per un errore di programmazione … uno dei messaggi più assurdi è stato il messaggio della casella vocale STANDARD (quella che si sente ad uffici chiusi o quando gli operatori sono tutti impegnati e si supera il tempo di attesa massimo (attualmente 180 secondi)). Vi lascio immaginare i commenti. Abbiam fatto una bella figuraccia, non c’è che dire … specie con chi non ci conosce … e ora capisco perché tanti messaggi vuoti in casella vocale … ma abbiamo aperto una strada che, probabilmente, ripercorreremo il primo aprile dell’anno prossimo o in altre occasioni particolari, mettendo in linea degli IVR “alternativi” 😉

Se avete ascoltato un messaggio strano, quindi, ora sapete perché e, naturalmente, ci scusiamo sin d’ora! Non era uno scherzo, ma un erroraccio di gestione … 😛