Prima di procedere:
- SIP: Session Initiation Protocol, è il protocollo VoIP per la segnalazione telefonica impiegato da Messagenet;
- Registrazione al Servizio: è la richiesta effettuata da un dispositivo SIP al server Messagenet per la ricezione di chiamate, avente l'obbiettivo di localizzare l'utenza sulla rete internet rendendola disponibile alla ricezione di chiamate per un determinato intervallo di tempo;
Come si presenta (comunemente) un problema di NAT Traversal
Uno dei problemi più frequenti che possono presentarsi nell'utilizzo del servizio VoIP su di un qualsiasi dispositivo si presenta come la difficoltà nel ricevere le chiamate in ingresso nei casi in cui l'apparato (sia esso un software od un telefono IP) dovrebbe squillare apparentemente senza difficoltà.
Questo problema si presenta nella seguente forma:
- il chiamante percepisce un lungo periodo di silenzio, in seguito al quale, dopo 30 o 60 secondi, la chiamata viene deviata in segreteria, o peggio abbattuta con il tono di "occupato veloce" (nel caso la segreteria non sia attiva);
- il dispositivo che sarebbe dovuto squillare si presenta come correttamente registrato al servizio, teoricamente raggiungibile, e non si evidenziano particolari problemi nella maggior parte dei casi ad effettuare chiamate all'esterno;
- il problema non si presenta con continuità: capita che l'apparato squilli correttamente, così come capita invece che la chiamata non giunga a destinazione;
- effettuando un riavvio (od una ri-registrazione al servizio) dell'apparato, le chiamate fatte di lì a poco giungono correttamente allo stesso; il problema torna poi a ripresentarsi di lì a poco;
Se il problema si presenta nelle modalità sopra descritte, è verosimile che ci si trovi di fronte ad un problema noto come NAT Traversal.
Come risolvere in breve
Applichiamo gradualmente i seguenti accorgimenti, fino a risolvere:
- Configurare il dispositivo per una ottimale registrazione e gestione del SIP
- non fornire al proprio apparato indicazione dell'IP pubblico assegnatoci dall'ISP, facendo sì che usi semplicemente il proprio IP locale della LAN;
- disabilitare STUN server sul dispositivo;
- non impiegare ICE sul dispositivo;
- disabilitare ALG SIP sul router, se presente;
- non usare localmente sul dispositivo le porte di default: usare porte "elevate" (e.g. tra 40000 e 50000) sia per il SIP che per l'RTP, non usare localmente la porta 5060;
- Configurare il dispositivo per usare Keep Alive SIP tramite "SIP Options" o simili;
- Configurare il dispositivo con un intervallo di ri-registrazione al servizio più basso, tra i 120 ed i 300 secondi (il default è 3600, troppo elevato per evitare problemi)
Se nulla di tutto ciò risolve:
- Tentare l'utilizzo di STUN (in contraddizione al punto 1) verificando se le condizioni di utilizzo del servizio STUN siano idonee al nostro caso
- Port Forwarding statico sul router (o DMZ nel caso il Port Forwarding non sia applicabile: ATTENZIONE! E' PERICOLOSO!)
Descrizione dettagliata del NAT Traversal tramite un esempio
Il NAT, o Network Address Translation, è quel sistema tramite il quale un comune gateway di rete (come il router di casa appunto) consente a più dispositivi nella rete locale privata di condividere un unico indirizzo pubblico per comunicare all'esterno, mantenendo in memoria un'associazione temporanea tra chi all'interno della rete effettua una richiesta all'esterno e dove essa sia stata inoltrata, in modo tale da potervi restituire la risposta.
http://it.wikipedia.org/wiki/Network_address_translation
Facciamo un esempio:
Il mio PC è collegato al router ADSL ed ha connettività su internet. In questo contesto, al router è stato assegnato dal provider l'indirizzo IP 12.34.56.78 (per esempio) impiega questo indirizzo per parlare con l'esterno, mentre all'interno della mia rete locale LAN egli associa a sè stesso un differente indirizzo privato (ad esempio 192.168.1.1).
Il router inoltre gestisce ed associa ai vari dispositivi nella rete locale tutti gli indirizzi IP privati, e per esempio assegna l'indirizzo locale 192.168.1.3 al mio PC.
Valgono queste regole:
- gli indirizzi locali 192.168.1.1 e 192.168.1.3 (e tutti quelli assegnati ai diversi dispositivi ivi presenti) valgono solo nella LAN e non hanno significato al di fuori di essa
- oltre all'indirizzo 192.168.1.3 indica al mio PC di essere gateway e di dover ricevere sull'indirizzo IP LAN del router (ovvero 192.168.1.1) tutte le richieste che vanno inoltrate all'esterno, sulla rete pubblica internet
- il router quindi, se io col PC cerco di visitare il sito di http://www.messagenet.com, vede arrivare da 192.168.1.3 una richiesta verso il server web di Messagenet, ovvero 212.97.59.74 e provvederà ad inoltrarla ad esso modificandone l'indirizzo mittente (siccome 192.168.1.3 non ha senso all'esterno, utilizzerà l'indirizzo pubblico della rete, ovvero 12.34.56.78 da lui assegnato dal provider) effettuando appunto una "traslazione di indirizzo"
- la richiesta giungerà al server web di Messagenet, il quale fornirà una risposta (ovvero, la pagina da visualizzare) al router verso 12.34.56.78: il mio router, ricordandosi della richiesta fatta da 192.168.1.3 (il mio PC) gli inoltrerà la conseguente risposta, rimettendo a posto l'indirizzo sorgente
Quello descritto sopra è un setup di rete locale con NAT effettuata dal router e consente a tanti dispositivi differenti di connettersi ad internet tramite un solo indirizzo IP: il router mantiene al proprio interno una tabella con le associazioni tra chi ha fatto le richieste e verso dove sono state inoltrate, in modo da gestire il tutto senza configurare manualmente nulla.
Questo porta alle seguenti considerazioni:
- i dispositivi connessi alla rete privata LAN non sono raggiungibili dall'esterno se non grazie al fatto che esista nel router una regola temporanea che consenta ad essi di essere raggiunti (ovvero essi stessi abbiano effettuato precedentemente una richiesta)
- la validità di questa associazione è temporanea: esiste una finestra temporale oltre la quale questa associazione viene eliminata (per consentire ad altri di utilizzarla, per finalità di sicurezza e, più in generale, perchè così è previsto dal protocollo di NAT) e se l'associazione è stata rimossa, di conseguenza, le richieste dall'esterno si fermeranno sul router, senza raggiungere il dispositivo opportuno
Negli utilizzi che prevedono l'associazione di un dispositivo ad un servizio, come per esempio la registrazione SIP di un client al servizio Messagenet per la ricezione delle chiamate, ci si scontra proprio con questo problema; ipotizziamo quanto segue:
- il mio telefono IP avente indirizzo locale 192.168.1.2 effettua la registrazione al servizio per ricevere chiamate da Messagenet: tale registrazione dura per 3600 secondi (un ora) ed i sistemi VoIP di Messagenet (il server sip.messagenet.it) sa di dover mandare al mio dispositivo le chiamate in arrivo
- come per il PC, il dispositivo inoltra al router la richiesta ed il router, impiegando il suo indirizzo pubblico, la fornisce all'esterno; la risposta ottenuta viene poi restituita al dispositivo, il quale sa di essere registrato e pronto a ricevere
- dopo un certo lasso di tempo, diciamo, qualche decina di minuti, qualcuno mi chiama: dal proxy di Messagenet viene inviata al mio router 12.34.56.78 la segnalazione per la chiamata entrante ed egli dovrebbe di conseguenza notificarla al dispositivo all'indirizzo locale 192.168.1.2: questa cosa però non avviene più poichè essendo trascorso del tempo, il router non ha più in memoria l'associazione tra il dispositivo locale 192.168.1.2 ed il server sip.messagenet.it con sè stesso a fare da ponte, e la chiamata non fa squillare il telefono
Come intervenire per evitare e risolvere il problema
Esistono diversi modi di porre rimedio a questa situazione, e l'obbiettivo per tutti resta quello di rendere disponibile il dispositivo alla ricezione di chiamate; questi accorgimenti non sono tutti necessariamente applicabili sui dispositivi esistenti e non sono necessari tutti assieme: occorre valutare quello che meglio si adatta alle condizioni presenti.
- Configurare il dispositivo in modo tale che effettui la registrazione e gestisca la segnalazione telefonica SIP in modo ottimale
- I sistemi di Messagenet implementano diversi accorgimenti per rendersi conto del NAT dietro al quale i dispositivi possono essere posti e la prima cosa che viene tenuta in considerazione è la differenza tra come essi si presentano (nel nostro caso, 192.168.1.2, impiegato nel Contact Field delle REGISTER, che consigliamo di mantenere privato) e la provenienza della richiesta stessa (nel nostro caso 12.34.56.78).
Il nostro proxy, accorgendosi della differenza tra i due indirizzi, saprà che il nostro dispositivo si trova sotto a NAT ed adotterà una serie di accorgimenti relativamente alla segnalazione telefonica tali da limitare nei limiti del possibile l'incorrere del problema. - In merito a questo punto, sconsigliamo l'utilizzo del servizio di STUN, un servizio spesso presente negli apparati il cui obbiettivo è quello di nascondere la presenza del NAT ai server (in questo caso Messagenet) e lasciando al dispositivo la gestione del problema: questo caso è in contraddizione con il punto precedente, e soprattutto può creare problemi nel caso il nostro provider internet usi associare un diverso indirizzo IP pubblico al nostro router nel corso del tempo, cosa che nella maggior parte dei casi viene fatta.
- Esistono dei protocolli che, volendo venire incontro al problema, agiscono sulla segnalazione SIP in transito nel router modificandone i parametri ed i riferimenti: questi accorgiementi, detti ALG, possono minare la corretta gestione della segnalazione telefonica sui nostri sistemi rendendo irraggiungibile il dispositivo in chiamata o dando luogo ad altri problemi, quali ad esempio la mancanza di audio in chiamata.
Si consiglia di verificare se una simile impostazione possa essere attiva sul router impiegato e, nel caso, disabilitarne l'utilizzo.
- I sistemi di Messagenet implementano diversi accorgimenti per rendersi conto del NAT dietro al quale i dispositivi possono essere posti e la prima cosa che viene tenuta in considerazione è la differenza tra come essi si presentano (nel nostro caso, 192.168.1.2, impiegato nel Contact Field delle REGISTER, che consigliamo di mantenere privato) e la provenienza della richiesta stessa (nel nostro caso 12.34.56.78).
-
Configurare il dispositivo per l'utilizzo di Keep Alive SIP, tramite "SIP Options" od altro a tale fine
Come già detto, il focus è quello di mantenere attiva la sessione NAT tra il nostro dispositivo ed il server Messagenet: molti dispositivo hanno nelle loro configurazioni la possibilità di abilitare messaggi SIP aventi lo scopo di mantenere questa associazione "viva" ("keep alive" appunto) contattando il nostro server per avere una risposta rinnovando l'associazione NAT sul router.
Impostando un intervallo di messaggi Keep Alive più breve della finestra temporale di NAT del router avremo la certezza di mantenere sempre attiva tale sessione, rendendo di conseguenza sempre disponibile il dispositivo alla ricezione di chiamate: un buon intervallo che sicuramente raggiunge l'obbiettivo può essere di 20 secondi. - Configurare il dispositivo con un intervallo di ri-registrazione al servizio più basso
Un dispositivo appena registratosi al servizio è ovviamente raggiungibile senza problemi poichè l'associazione tra IP locale e server Messagenet nella tabella di NAT del router è ancora valida.
Molti dispositivi hanno tra i loro parametri di configurazione la possibilità di impostare un "Registration Interval" (o "Register Expiry" o ancora "Register Duration") differente da quello di default (posto a 3600 secondi): abbassandolo a pochi secondi (ad esempio 300, o 180 od alla peggio 60) faremo in modo che il dispositivo si registri più spesso al servizio, rinnovando l'associazione NAT presente nel router e rendersi sempre raggiungibile dall'esterno. - Tentare l'utilizzo di STUN (in contraddizione al punto 1) verificando se le condizioni di utilizzo del servizio STUN siano idonee al nostro caso
Esistono dei casi in cui si è notato che l'impiego di STUN server possa risolvere il problema qui descritto: vale la pena, se non si avessero fino ad ora altre opzioni se non questa, di tentarne l'utilizzo configurando come server STUN "stun.ekiga.net" porta 3478 ed un intervallo per le richiesta STUN relativamente basso (20 secondi). - Port Forwarding statico sul router (o DMZ nel caso il Port Forwarding non sia applicabile)
Se il nostro client non ha modo di essere configurato secondo i parametri precedentemente descritti e ci trovassimo nella condizione di non poter fare altrimenti, dobbiamo agire in modo differente, ovvero sul router e non sul dispositivo ( http://it.wikipedia.org/wiki/Port_forwarding ).
A questo punto, posto che non sia possibile allungare la validità temporale dell'associazione NAT di cui abbiamo parlato, dobbiamo rendere questa associazione duratura nel tempo facendola diventare statica, ed i passi da seguire sono i seguenti:
- diversamente da quanto esposto inizialmente, imponiamo all'apparato di presentarsi con l'IP pubblico del router, se possibile, e passiamo altrimenti al punto successivo
- una volta identificato l'indirizzo locale del dispositivo (ad esempio 192.168.1.2) imponiamo ad esso di mantenere tale indirizzo nel tempo; questo può essere fatto alternativamente:
- associando staticamente l'IP al dispositivo (non utilizzando DHCP)
- riservando l'indirizzo IP del dispositivo in modo tale che DHCP associ sempre tale indirizzo all'apparato
- una volta fissato l'indirizzo, facciamo in modo che il dispositivo in uso impieghi sempre la stessa porta per le richieste in ingresso: il protocollo SIP generalmente impiega la porta 5060 e normalmente è questa la porta sulla quale il nostro dispositivo si aspetterebbe di ricevere le richieste in ingresso; una volta appurato questo fatto, prendiamone nota e procediamo
- effettuiamo il Port Forwarding sul router, facendo in modo che il router stesso inoltri alla porta (punto precedente) del dispositivo tutte le richieste provenienti dall'esterno sulla stessa porta
N.B.: esiste un'ulteriore impostazione più radicale, detta DMZ (o "Virtual Server"), la quale prevede di effettuare forwarding di TUTTE le porte del dispositivo all'esterno, facendo in modo tale che il dispositivo sia praticamente pubblicamente esposto. In questo caso, tutto ciò che arriverà dall'esterno all'indirizzo pubblico del router verrà inoltrato al nostro dispositivo, a prescindere dalla porta.
Questa impostazione è la più radicale ed è ad ogni modo SCONSIGLIABILE poichè espone il nostro dispositivo a forti RISCHI PER LA SICUREZZA: generalmente il dispositivo, oltre ad avere la porta SIP in ascolto per le chiamate in ingresso, espone anche un'interfaccia web di configurazione od altre interfacce riservate con uso differente. Esponendo il dispositivo in DMZ esporremmo al pubblico anche queste ultime, consentendo verosimilmente di accedere all'interfaccia di configurazione anche all'esterno della nostra rete, cosa che generalmente non si vorrebbe: Messagenet SCONSIGLIA di adottare questa impostazione se non si abbia chiari i rischi ai quali si va incontro.
Setup di rete particolari
Esistono certi scenari di utilizzo nei quali il problema di NAT Traversal non è direttamente riconducibile alla sola rete locale LAN gestita da noi utenti, ma che puo' dipendere da fattori esterni quali ad esempio una subnet condivisa nella quale il nostro gateway di rete e' inserito.
Per fare un esempio, ci troviamo in questa condizione in molte reti LAN aziendali, nelle reti ADSL Fastweb (al cui HAG viene associato non un IP pubblico, ma un IP locale di una subnet Fastweb, la quale a sua volta è sotto NAT) od tipologie di connettività fornite da provider internet con rete non cablata (come ad esempio nei ponti radio con antenna WiFi metropolitana sul tetto). In generale, è possibile che la propria connettività quindi sottoposta a più NAT in cascata, non tutti sotto il nostro controllo.
In questi casi può essere difficile effettuare Port Forwarding su di un proprio dispositivo senza avere il supporto del fornitore, il quale può essere restio a fornire queste tipologie di servizio personalizzato o può non voler perseguire questo genere di richiete.
In questo caso, è opportuno assicurarsi che i client in uso abbiano la possibilità di abilitare gli accorgimenti descritti ai punti 1, 2 e 3, che restano in ogni caso i primi da voler perseguire onde evitare l'insorgere del problema.
Informazioni aggiuntive:
In generale la tipologia di problematica descritta in questo articolo è di natura generale e riguarda il funzionamento di un generico apparato IP localizzato in una LAN privata che debba essere raggiunto dall'esterno in vista del proprio funzionamento: in relazione al protocollo SIP ed alla registrazione al servizio per la ricezione di chiamate, la questione è nota e costituisce un fattore da tenere in considerazione a prescindere da Messagenet e dalla tipologia di servizio offerto.
In particolare:
- le diverse descrizioni di template di configurazione presenti in queste pagine di supporto toccano l'argomento esponendo di volta in volta i parametri opportuni da correggere o verificare a seconda del dispositivo in oggetto: il consiglio è quello di fare innanzitutto riferimento a suggerimenti di questo tipo
- il problema trattato è spesso noto ai fornitori stessi dei vari dispositivi ed alla comunità che ne fa uso: è pertanto utile fare riferimento al fornitore del dispositivo per avere ulteriori informazioni sulla configurabilità dello stesso in situazioni con problemi di NAT Traversal
- qualora non si fosse in grado di verificare autonomamente la situazione, si avesse necessità di una verifica puntuale sullo stato di raggiungibilità del dispositivo in uso o si rendessero necessarie ulteriori informazioni in merito, è possibile rivolgersi in modo dedicato al supporto inviando mail alla casella support@messagenet.it