Tempo fa mi sono state sottoposte alcune domande riguardanti il VoIP, soprattutto come utilizzarlo in presenza di firewall e NAT che possono rendere impossibile la comunicazione a voce su IP. Dalla semplice risposta che mi ero proposto di scrivere, ne \u00e8 scaturito qualcosa di un po’ pi\u00f9 articolato, che prende di petto alcuni dei problemi nei quali incorrono gli utilizzatori del VoIP, tentando di dare una semplice spiegazione teorica. Il testo \u00e8 diviso in due differenti parti, per dare al lettore il tempo di assimilare i contenuti in maniera graduale. L’inizio riprende alcune domande che mi sono state poste, per poi passare a un approfondimento teorico.<\/p>\n
Ci sono altri protocolli che mi sarebbe utile avere?<\/p><\/blockquote>\n
Al limite il protocollo proprietario di Skype<\/a>, se vuoi usare questo servizio per chiamare e ricevere, oppure IAX<\/a> per il supporto dei centralini Asterisk.<\/a> A dire la verit\u00e0, il discorso sarebbe un poco pi\u00f9 complesso, ma esula da ci\u00f2 che ci interessa ora.<\/p>\n
Ora, non penso proprio che tu possa implementare un centralino Asterisk<\/a> a casa e comunque potresti interfacciarti tramite SIP<\/a>.<\/p>\n
Per Skype, si tratta di un protocollo proprietario. Questo dipende da te. Esistono in commercio, e li trovi in qualsiasi magazzino di elettronica (Mediaworld, Euronics, Saturn, per esempio), degli ATA<\/a> Skype. Con questa soluzione, per\u00f2, rimani vincolato a questa architettura, mentre con SIP puoi interfacciarti a parecchi provider VoIP<\/a> sul mercato. Hai pi\u00f9 soluzioni aperte, o come sarei tentato di dire, pi\u00f9 Sorgenti Aperte.<\/p>\n
Al limite, verifica di avere SIP2 (RFC 3261<\/a>). Non starei ad approfondire i protocolli di trasporto e i codec: per un\u2019utenza domestica sono dettagli che hanno poco senso. Prendi un prodotto \u201cmainstream\u201d e inizia a telefonare, vedrai che andr\u00e0 tutto bene.<\/p>\n
<\/p>\n
:: Supporto STUN: se stai dietro a un router, il supporto STUN ti
\n :: consente comunque di collegarti al provider VoIP.<\/p>\nDi cosa si tratta esattamente? Mi occorrono altri supporti?<\/p><\/blockquote>\n
Lo STUN<\/strong> (Simple Traversal of User Datagram Protocol Through Network Address Translators \u2013 RFC 3489<\/a>) \u00e8 un protocollo che permette di aggirare un problema che si verifica quando chi vuole usare il VoIP si trova dietro a un router<\/a> o a un firewall<\/a>.<\/p>\n
In pratica, per instaurare una telefonata bisogna creare un circuito di dati fra due client che instaurano una connessione. Un circuito \u00e8 identificato da una coppia di tuple INDIRIZZO:PORTA. In pratica, il canale di trasmissione si instaura nel seguente modo:<\/p>\n
PORTA \u2014\u2014\u2014\u2014\u2013 PORTA
\nIP \u2014\u2014\u2014\u2014\u2013 IP<\/code><\/p>\nCio\u00e8 i due client devono conoscere i reciproci indirizzi IP e porte attraverso cui \u00e8 possibile far scorrere il flusso di dati (la telefonata).<\/p>\n
Quale \u00e8 il problema? Il problema sta nel fatto che se hai un router di mezzo, tipico il router ADSL domestico, questo esegue un NAT<\/strong> (Network Address Translation – RFC 3022<\/a>) tra l\u2019indirizzo IP pubblico e l\u2019IP del computer o dell\u2019ATA usato per chiamare. Ovvero:<\/p>\n
IP_INTERFACCIA_PROVIDER_VERSO_UTENTE
\n|
\n|
\n|
\nIP_INTERFACCIA_PUBBLICA_ROUTER_UTENTE
\n|
\n|
\n|
\nIP_INTERFACCIA_ETHERNET_INTERNA_ROUTER
\n|
\n|
\n|
\nIP_INTERFACCIA_ETHERNET_CLIENT_VOIP<\/code><\/p>\nOra, come puoi ben vedere, il client che usi per chiamare, sia esso il PC di casa o l\u2019ATA, sta in fondo alla catena e conosce solo il proprio indirizzo IP, tipicamente appartenente a una classe privata (192.168.x.x, 10.x.x.x, da 172.16.x.x a 172.31.x.x – BEST CURRENT PRACTICE 0005<\/a> – RFC 1918<\/a>), non visibile da internet e quindi il tuo ATA o il programma che usi per effettuare le chiamate non conosce due informazioni fondamentali:<\/p>\n
\n
- Quale \u00e8 l\u2019indirizzo IP che il provider ha assegnato in quel momento al router della propria rete<\/li>\n
- Quali sono le porte UDP (User Datagram Protocol) disponibili per ricevere i dati inviati dal dal provider VoIP e che consistono, primariamente, nel flusso di dati che contiene l\u2019audio del proprio interlocutore.<\/li>\n<\/ol>\n
Perch\u00e9 abbiamo bisogno di sapere queste due informazioni? Beh, ci vuole un po\u2019 di teoria.<\/p>\n
Quando ti colleghi a internet da dietro un firewall tu hai un IP privato, non raggiungibile da internet. Ma se richiedi una pagina a un server web, come fa questo a spedirtela, visto che non sa pu\u00f2 raggiungere il tuo indirizzo privato che, per definizione, \u00e8 irraggiungibile da internet?<\/p>\n
Il trucco c\u2019\u00e8, ma non si vede e si chiama Network Address Translation, detto anche NAT o IP Masquerading. Come funziona? Semplicemente, \u00e8 il router a giocare un ruolo attivo: quando vede che il PC della rete privata tenta di stabilire una connessione verso l\u2019esterno, gioca un piccolo scherzo ai pacchetti che lo attraversano per uscire e ne riscrive l\u2019IP di origine. Gi\u00e0, perch\u00e9 ogni pacchetto porta in s\u00e9 almeno quattro informazioni fondamentali: l\u2019IP e la porta che lo hanno generato, l\u2019IP e la porta verso cui \u00e8 destinato. Il router, modifica l\u2019IP di provenienza del pacchetto in uscita, facendolo corrispondere all\u2019IP della propria interfaccia pubblica, facilmente raggiungibile da internet.<\/p>\n
A questo punto, il server, il servizio, il corrispondente che voglia rispondere al pacchetto inviato, non dovr\u00e0 fare altro che leggere l\u2019IP di provenienza per sapere a quale indirizzo inviare la risposta. Ora, la risposta viene inviata all\u2019indirizzo pubblico del router che, vedendosi arrivare il pacchetto sulla connessione sa gi\u00e0 da dove si \u00e8 originata quest\u2019ultima e non fa altro che riscrivere l\u2019IP di destinazione del pacchetto di risposta, per rinviarlo al computer (o ATA) nella rete interna che solo lui, il router, pu\u00f2 vedere \u201cdall\u2019esterno\u201d, visto che ha un piede fuori e uno dentro.<\/p>\n
Il concetto fondamentale che sta dietro al NAT \u00e8 quello della connessione: il router si \u201csegna\u201d gli indirizzi (e le porte) reali dei due estremi della connessione e poi opera le traduzioni appropriate affinch\u00e9 i due estremi abbiano l\u2019illusione di comunicare direttamente.<\/p>\n
Dove sta l\u2019inghippo? Sta nell\u2019eventualit\u00e0 in cui una connessione venga originata dall\u2019esterno. In questo caso, chi sta fuori pu\u00f2 solo indicare come destinatario l\u2019indirizzo IP pubblico del router ma poi, quest\u2019ultimo, non avendo alcuna connessione gi\u00e0 attiva di riferimento, non sa dove reindirizzare i pacchetti. Questo a meno di utilizzare un bi-nat, chiamato anche full cone nat. In questo caso, ogni porta dell\u2019IP pubblico del router viene mappata sulla corrispondente di un preciso indirizzo privato interno e si ha una situazione simile a quella in cui la macchina interna fosse esposta direttamente a internet.<\/p>\n
Comunque, come fare il tuo computer a sapere a quale porta mettersi in ascolto? E, poi, sar\u00e0 raggiungibile su una data porta, su protocollo UDP (User Datagram Protocol – STANDARD 00006<\/a>)? Gi\u00e0, perch\u00e9 le connessioni VoiP utilizzano il protocollo RTP (Real-time Transport Protocol – STANDARD 00064<\/a>), generalmente su porte UDP. O meglio, il protocollo RTP pu\u00f2 usare come trasporto anche TCP (STANDARD 00001<\/a>), SCTP (RFC 3309<\/a>), etc., ma viene comunemente usato UDP dato che questo \u00e8 il mezzo di trasporto ideale per le comunicazioni in streaming broadcast e multicast. Il perch\u00e9 \u00e8 presto detto: a differenza del TCP che ha un meccanismo di controllo dell\u2019integrit\u00e0 dei pacchetti, l\u2019UDP non ce l\u2019ha, risultando pi\u00f9 veloce. Semplificando, nel momento di spedire un pacchetto, il TCP gli assegna un numero sequenziale che verr\u00e0 letto dallo stack TCP del ricevente: se il pacchetto \u00e8 arrivato nella giusta sequenza ed entro un tempo limite, il ricevente spedisce un OK al mittente e attende il pacchetto seguente. Gestendo le risposte, il mittente sa quali pacchetti sono arrivati correttamente, quali devono essere rispediti un\u2019altra volta e quali nuovi pacchetti inviare.<\/p>\n
Con UDP no. Vi \u00e8 una verifica sull\u2019integrit\u00e0 del singolo pacchetto, ma non della connessione. Il protocollo UDP non sa se un pacchetto \u00e8 arrivato nella giusta sequenza e in tempo. Ed \u00e8 per questo che nelle comunicazioni multimediali che utilizzano questo protocollo di trasposto pu\u00f2 capitare di trovare buchi e interruzioni nella trasmissione: non vi \u00e8 modo di richiedere il reinvio di un pacchetto perso e non \u00e8 previsto, a livello di protocollo, un meccanismo di ritrasmissione dei dati.<\/p>\n
Comodo ma poco affidabile: non dovendo fermarsi a controllare cosa \u00e8 arrivato e cosa no, che cosa bisogna rinviare e cosa no, il protocollo UDP consente di inviare dati a una velocit\u00e0 maggiore rispetto al TCP, ma non assicura una corretta trasmissione.<\/p>\n
Ora, abbiamo visto come un client possa trovarsi dietro a un router, ma anche a due o tre, dipende dal tipo di rete in cui \u00e8 immerso e a seconda della sua topologia si possono riscontrare quattro diversi tipi di NAT (RFC 4008<\/a>):<\/p>\n
Full Cone:<\/strong> \u00e8 un tipo di NAT che prevede una corrispondenza biunivoca fra indirizzo esterno del router\/firewall e indirizzo interno di un unico client: Quando un client con un preciso indirizzo IP interno spedisce un pacchetto verso l\u2019esterno, il suo IP\/PORTA di origine vengono rimappati sul corrispondente IP\/PORTA pubblici del router\/firewall. Se un pacchetto viene inviato a una PORTA\/IP pubblica del router, questo viene reindirizzato a 1 indirizzo preciso della rete interna. In pratica \u00e8 come se una sola macchina della rete interna venisse a trovarsi sul perimetro esterno, quasi come se la sua scheda di rete avesse l\u2019indirizzo pubblico del router. Quasi come.<\/p>\n
Restricted Cone:<\/strong> Come per il Full Cone NAT, 1 IP\/PORTA interno \u00e8 mappato sull\u2019IP\/PORTA esterno del router\/firewall. A differenza del Full Cone NAT, dall\u2019esteno possono raggiungere l\u2019IP interno solo quei pacchetti che fanno parte di una connessione stabilita dal client interno verso l\u2019esterno. In pratica, i pacchetti di una connessione autonomamente generata dalla rete esterna al router, non vengono reindirizzati al all\u2019IP\/PORTA del client della rete interna, mentre vengono rimappati quelli che \u201ctornano\u201d dall\u2019esterno come risposta a pacchetti generati da una connessione proveniente dal client della rete interna. E\u2019 la configurazione classica di un router\/firewall domestico.<\/p>\n
Port Restricted Cone:<\/strong> Assomiglia al Restricted Cone NAT, con un\u2019ulteriore restrizione sulle porte: un pacchetto proveniente dalla rete esterna al router\/firewall e dotato di una precisa tupla IP\/PORTA pu\u00f2 essere reindirizzato verso il client della rete interna solo se il client della rete interna ha PRIMA inviato un pacchetto al medesimo IP\/PORTA del mittente. In pratica, se una macchina esterna ha come indirizzo 88.22.56.98 e ha spedito un pacchetto dalla porta 16643, questo raggiunger\u00e0 il client della rete interna, passando attraverso il router\/firewall, solo se PRIMA il client della rete interna avr\u00e0 mandato un pacchetto all\u2019indirizzo 88.22.56.98, sulla porta 16643.
\n
\nSymmetric:<\/strong> Un Symmetric NAT \u00e8 qualcosa di \u201cunico\u201d: come nel full nat, una connessione originata da una IP\/PORTA interna verso un IP\/PORTA esterna avr\u00e0 una mappatura IP\/PORTA pubblica sull\u2019interfaccia esterna del router. La differenza risiede nella destinazione e nella \u201cdinamicit\u00e0\u201d del mapping: ogni volta che o l\u2019IP o la PORTA di destinazione cambiano, verr\u00e0 utilizzato un mapping diverso sull\u2019interfaccia esterna del router, ovvero una differente combinazione IP\/PORTA pubblica. In pi\u00f9, solo l\u2019host esterno che riceve un pacchetto pu\u00f2 replicare con un pacchetto UDP verso l\u2019host con indirizzo privato. Questa \u00e8 una configurazione tipica di una rete aziendale.<\/p>\nIl tutto suona un po\u2019 strano? Ebbene si, in effetti le definizioni di nat si sprecano e variano a seconda delle implementazioni e, direi, delle mode.<\/p>\n
Comunque, due client che vogliano iniziare una comunicazione SIP (RFC 3261<\/a>) si trovano generalmente in questa messe di problemi: di solito ognuno di loro sta dietro uno o pi\u00f9 router\/firewall, conosce solo il proprio IP interno e non sa nemmeno a quali restrizioni \u00e8 sottoposto il traffico.<\/p>\n
Ma cosa \u00e8, a grandi linee, SIP? Prendendo direttamente dal preambolo della RFC 3261 che lo descrive, SIP, Session Initiation Protocol, \u00e8 un protocollo a livello di applicazione utilizzato per creare, modificare e terminare sessioni con uno o pi\u00f9 partecipanti, sessioni che possono includere telefonate via internet, distribuzione di contenuti multimediali e conferenze multimediali. Nel momento stesso in cui un interlocutore viene invitato (signaling) in una sessione, il protocollo SIP veicola in questo invito una serie di informazioni riguardanti i tipi di media che possono essere utilizzati in modo che tutti i partecipanti possano adottare uno o pi\u00f9 media comuni, anche contemporaneamente, attraverso i quali scambiare i dati.<\/p>\n
Non solo, SIP \u00e8 in grado di utilizzare una serie di proxy server dedicati per veicolare al meglio le richieste verso l\u2019utente, per autenticare e autorizzare gli utenti all\u2019utilizzo di un dato servizio, implementare le regole di routine delle chiamate e offrire in genere servizi all\u2019utente. In pi\u00f9, SIP offre una funzione di registrazione che permette agli utenti di inviare ai proxy le informazioni riguardanti la loro posizione, in modo da facilitare il routine delle chiamate.<\/p>\n
Attenzione, per\u00f2: SIP \u00e8 un protocollo a livello di applicazione, non un protocollo di trasporto e non ha nemmeno il controllo totale delle comunicazioni che contribuisce a gestire. Ci\u00f2 significa che serve a far comunicare le applicazioni, non a veicolare i dati e, infatti, pu\u00f2 essere pensato come un componente che sta al di sopra di altri protocolli come RTP (Real-Time Transport Protocol – RFC 1889<\/a>), RTSP (Real-Time Streaming Protocol – RFC 2326<\/a>), MEGACO (Media Gateway Control Protocol – RFC 3015<\/a>), SDP (Session Description Protocol \u2013 RFC 2327<\/a>). SIP non fornisce quindi un vero e proprio servizio di comunicazione ma solo un insieme di funzioni di base per iniziare, gestire e terminare le connessioni, gestite a loro volta da altri protocolli pi\u00f9 specifici.<\/p>\n
Volendo, si pu\u00f2 pensare a SIP come a uno strumento di localizzazione: consente di localizzare i partecipanti a una conversazione e di scoprire quali funzioni multimediali sono in grado di condividere.<\/p>\n
Ora, per\u00f2, torniamo sull\u2019argomento STUN. Dato che due client sono normalmente dietro un NAT, come possono questi arrivare a conoscere il proprio indirizzo pubblico, da comunicare al proxy cui registrarsi, le porte UDP disponibili e la modalit\u00e0 di NAT adottata?<\/p>\n
Qui entra in gioco il protocollo STUN, basato su un\u2019architettura client\/server: il client \u00e8 implementato nell\u2019applicazione VoIP, o nell\u2019ATA, il server all\u2019interno di proxy dedicati visibili su internet.<\/p>\n
Il punto di svolta sta proprio in questo \u201cvisibili su internet\u201d: un provider VoIP che voglia rendere pi\u00f9 semplice ai propri utenti una chiamata pu\u00f2 creare un proxy STUN che abbia un indirizzo pubblico raggiungibile su internet: sar\u00e0 il proxy ricevere una richiesta dal client posto sulla rete privata, ad analizzare dall\u2019esterno il router\/firewall che impedisce la libera comunicazione e a inviare verso la rete privata tutte le informazioni necessarie ad aggirare il blocco.<\/p>\n
Ma come?<\/p>\n","protected":false},"excerpt":{"rendered":"
Tempo fa mi sono state sottoposte alcune domande riguardanti il VoIP, soprattutto come utilizzarlo in presenza di firewall e NAT che possono rendere impossibile la comunicazione a voce su IP. Dalla semplice risposta che mi ero proposto di scrivere, ne \u00e8 scaturito qualcosa di un po’ pi\u00f9 articolato, che prende di petto alcuni dei problemi …<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[69],"tags":[129,472,87,479,104,105,141,151],"class_list":{"0":"post-438","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"hentry","6":"category-voip","7":"tag-applicazioni","8":"tag-fon","9":"tag-ftp","10":"tag-internet","11":"tag-mac","12":"tag-pc","13":"tag-skype","14":"tag-web","16":"without-featured-image"},"_links":{"self":[{"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/posts\/438","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/comments?post=438"}],"version-history":[{"count":0,"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/posts\/438\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/media?parent=438"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/categories?post=438"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/tags?post=438"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}