limitante sia nel momento in cui si volesse utilizzare la rete telefonica per il trasporto di audio
compresso con una maggiore efficienza, sia nel momento in cui si volesse trasportare audio ad alta
qualità (ad esempio aumentando il bitrate oppure utilizzando un codec con caratteristiche migliori).
Tralasciando momentaneamente il problema che il codec può essere cambiato solamente a prezzo di
cambiare tutti gli apparati d'accesso alla rete telefonica (oppure, per la rete ISDN, tutti i telefoni),
operazione evidentemente onerosa, l'allocazione statica dei 64kbps vanifica ogni sforzo di
compressione migliore in quanto, in ogni caso, per ogni telefonata deve essere allocata tale banda (le
tecnologie di trasporto, ad esempio SONET/SDH, prevedono questo valore come unità minima di
canale trasportabile). Per realizzare il circuito virtuale tra le parti è necessaria inoltre una fase di
segnalazione e di set-up che possono richiedere un tempo anche dell'ordine del secondo, con un
considerevole lavoro di gestione della chiamata da parte della rete. Questi motivi portano a concludere
che, tecnicamente, la tecnologia su cui si basa la telefonia classica può essere migliorata, ed è proprio
su questi punti che andrà a puntare la tecnologia VoIP sviluppata su reti dati.
La totalità delle reti dati oggi esistenti si basa sul concetto di commutazione di pacchetto, ossia la
creazione di un'unità elementare di trasporto che sia in grado di viaggiare in maniera più o meno
autonoma sulla rete, recapitando a destinazione il suo contenuto informativo.
La architettura di rete dati allo stato attuale è la rete IP, caratterizzata da un servizio di tipo best effort,
senza meccanismi di prenotazione di risorse. Gli apparati intermedi (nodi) non creano un circuito
fisico tra le parti, ma instradano il pacchetto nella giusta direzione in base all'informazione contenuta
nell'intestazione dello stesso.
In questo modo non si ha allocazione di risorse riservate, perciò su un link possono transitare
contemporaneamente anche pacchetti appartenenti a flussi diversi, aumentando notevolmente la
percentuale d'utilizzazione della rete rispetto a quella telefonica.
Alcuni pacchetti di uno stesso flusso, però, possono percorrere cammini diversi, possono arrivare a
destinazione fuori sequenza, oppure possono perdersi. In tal caso, l'apparato terminale (ad esempio il
PC) ha il compito di ordinare i pacchetti nella sequenza corretta e richiedere eventualmente la
ritrasmissione di quelli persi, rendendo il trasporto affidabile. Quest'operazione può però non essere
opportuna nel caso di trasmissione della voce in quanto introduce notevoli ritardi ai quali i flussi voce
sono particolarmente sensibili.
La tecnologia a commutazione di pacchetto permette di ovviare facilmente ai problemi descritti nella
sezione precedente dal momento che la mancanza di una preallocazione fissata favorisce la
multiplazione statistica tra le chiamate (quindi sono adottabili tecniche di compressione dei silenzi e
codec più aggressivi come fattore di compressione, fatta salva la compatibilità con gli apparati
terminali), quindi la gestione più efficiente della banda. Inoltre, non avendo il limite dei 64kbps
permette anche il trasporto di traffico con bitrate più elevati, ad esempio per il trasporto di voce con
qualità superiore.
Il costo di una "chiamata" in tecnologia dati è quindi normalmente determinato dalla quantità di dati
che passano, indipendentemente dalla durata della comunicazione.
Infine, la rete IP non ha il call setup, rendendo la gestione della chiamata decisamente meno onerosa.
Tuttavia, questa scelta impone dei vincoli non indifferenti per la gestione della qualità del servizio
spettante alla singola chiamata: questo è il motivo per cui altre tecnologie di reti dati (prime fra tutte
quelle che sono state definite nell’ambito degli operatori telefonici quali X.25, Frame Relay e ATM)
mantengono il concetto di call-setup. Come si vedrà in seguito, uno dei problemi principali della rete
IP è proprio la fornitura di determinate garanzie di qualità alla telefonata.
Ma quando è nato il termine VoIP?
Probabilmente, la prima volta in cui il termine VoIP è arrivato al grande pubblico è stato nel 1995
quando è stata rilasciata la prima versione di un applicazione chiamata "Internet Phone". Questo
software, installato sul proprio personal computer, abilitava gli utenti a comunicare tramite audio e
testo e permetteva di trasmettere e condividere immagini e grafici tramite una whiteboard mediante
l'impiego di normalissimi dispositivi quali un microfono, le casse e, per il video, una videocamera. In
mancanza di questi oggetti hardware il prodotto instaurava una comunicazione al meglio delle sue
possibilità. Ad esempio, in mancanza di una telecamera il software consentiva di ricevere immagini
ma (ovviamente) non di inviarle.
La VoIP era quindi intesa come uno strumento che permettesse di poter effettuare chiamate vocali da
un personal computer all'altro, rendendo possibile una comunicazione in tempo reale con l'aggiunta di
funzionalità avanzate quali video, lavagna condivisa, e altro. Non ultimo, la possibilità di poter
condividere il proprio desktop sul PC offriva la possibilità di operare direttamente su una macchina
2
remota (ad esempio per risolvere problemi di configurazione), funzionalità molto comoda in
determinate occasioni.
Tra i vantaggi, quindi, si segnalavano sicuramente le nuove applicazioni non disponibili con la
tecnologia classica, e il costo ridotto della chiamata.
Il sentore comune tra gli operatori nel settore della telefonia era che la visione precedente di tipo
consumer era decisamente limitante. Infatti, una visione della VoIP che richiedesse necessariamente
la presenza di un personal computer per poter operare presentava notevoli criticità, tra le quali:
ξ non tutti gli utenti dispongono di un PC, mentre quasi tutti dispongono di un telefono: è
accettabile che solo i primi possano disporre di VoIP?
ξ il PC deve essere permanentemente collegato alla rete, pena l'impossibilità di poter ricevere
chiamate
ξ sono possibili solo chiamate PC-to-PC; manca la possibilità di chiamare un utente abbonato
ad un servizio telefonico tradizionale
ξ il PC difficilmente gestisce la mobilità, caratteristica a cui sono ormai abituati gli utenti (il
successo dei telefoni mobili è sotto gli occhi di tutti)
Il problema fondamentale della precedente visione è il fatto che vi sia un nesso obbligatorio tra la
disponibilità di un PC e la possibilità di attivare VoIP. Tuttavia, questa è una visione riduttiva dal
momento che il numero di telefoni installati (e il numero di utilizzatori capaci ad adoperarli) è
decisamente superiore al numero di PC.
Nella visione professionale, quindi, la VoIP è nient'altro che la possibilità di trasportare dei campioni
vocali mediante un'infrastruttura di rete in tecnologia IP. Questo implica una serie di conseguenze:
ξ anche un telefono tradizionale può usufruire di una infrastruttura VoIP, fatto salvo che esista
un gateway (traduttore) che trasforni i segnali vocali tradozionali in pacchetto VoIP
ξ la tecnologia VoIP può affermarsi senza la necessità di dover cambiare i terminali alla
periferia della rete (operazione notoriamente onerosa in termini economici e di tempo
impiegato)
ξ il luogo più adatto per l'adozione della VoIP è sicuramente il backbone della rete telefonica,
dal momento che è necessario cambiare solamente l'interfaccia delle centrali telefoniche
verso il backbone e abilitandole alla trasmissione di pacchetti IP.
Una visione di questo tipo ha, ovviamente, anche alcuni aspetti negativi. Il primo fra tutti è che il
servizio telefonico fornito all'utente finale non si avvantaggia di nessun miglioramento con il
passaggio del backbone telefonico in tecnologia VoIP. In altre parole, il passaggio da una telefonata in
tecnologia classica ad una in tecnologia VoIP non inserisce nessuna novità nel modo con cui l'utente
finale percepisce il servizio. Questo implica che la visione "professionale" della VoIP non è orientata
ad un miglioramento del servizio, ossia non è in grado di fornire quelle nuove possibilità (interazione
audio, video, dati) permesse invece dalla visione "consumer". I motivi dell'adozione di tecnologie
VoIP da parte del gestore telefonico vanno quindi ricercati altrove.
Un dato di fatto è che, ormai, il traffico di tipo dati ha decisamente superato, in volume, il traffico di
tipo telefonico. Dal momento che il mantenimento di due infrastrutture di rete distinte (una per il
traffico telefonico, una per il traffico dati) è inutilmente costoso, gli operatori hanno sempre cercato
una razionalizzazione che è consistita nell'unificare, almeno nelle funzioni di base, le due reti.
In passato (e spesso ancora oggi), il traffico dati veniva quindi trasportato su un'infrastruttura di tipo
telefonico ritagliando, all'interno dei canali telefonici tradizionali (SONET/SDH e altro), alcuni canali
destinati al traffico dati. In molti casi, poi, con l'aumentare del traffico dati sono stati riservati interi
link
5
a questo tipo di traffico, sempre però gestito con la tecnologia precedente. In altre parole, si è
forzato il traffico dati al passaggio su un'infrastruttura di tipo telefonico.
Con l'attuale prevalere del traffico dati, potrebbe diventare più conveniente fare il contrario: costruire
dei canali in tecnologia dati (una fra tutte, Ethernet e i suoi derivati a lunga distanza), quindi forzare la
voce a passare su questi canali. Anche in questo caso l'infrastruttura di rete, sotto certi aspetti, sarebbe
comune tra i due servizi con gli ovvi vantaggi economici e di gestione.
Il secondo motivo che spinge verso integrazione della telefonia su una rete dati è l'esigenza, da parte
di quest'ultima, di poter differenziare diversi tipi di traffico su di essa. Storicamente, la tecnologia IP
(e Internet che è la sua incarnazione più famosa) non ha mai posto in grande risalto la necessità di
poter differenziare, all'interno della rete, il servizio fornito ai pacchetti IP. Banalizzando, un normale
trasferimento file può sopportare senza problemi un rallentamento nel flusso dati, mentre una sessione
interattiva (si pensi al telnet, alla chat, oppure ad un sistema di prenotazioni quali le prenotazioni
3
aeree) richiede che la rete porti a destinazione i pacchetti in tempi estremamente rapidi, senza
rallentamenti.
L'incremento del numero di utilizzatori di reti IP ha fatto sì che nascessero nuove applicazioni (si
pensi ad esempio al video streaming), cambiando profondamente la tipologia di traffico di una rete IP
classica e mettendo chiaramente in risalto come determinate applicazioni abbiano necessità diverse di
altre e come la rete debba essere in grado di trattarle in maniera differente. Questa esigenza si è fatta
pressante con l'adozione delle reti IP anche per scopi commerciali, dove un'azienda può voler un
trattamento preferenziale per il traffico da essa generato ed è ovviamente disposta a pagare un prezzo
maggiore rispetto ad un tipico utente domestico che utilizza la rete per svago.
Nel momento in cui la rete IP è in grado di differenziare il servizio fornito a diverse tipologie di
traffico, il passaggio ad una rete multiservizio è breve. Il più comune esempio di rete multiservizio è
la rete telefonica classica, che è in grado di veicolare le telefonate, il traffico Internet, ma anche il
traffico di servizi diversi quali i POS (Point of Sale, punti di vendita con pagamento in forma
elettronica, ad esempio PagoBancomat), e altri. Il termine multiservizio esprime il concetto che, su
una stessa infrastruttura di rete, vengano veicolati servizi diversi (o, almeno, coì sono percepiti dagli
utenti finali). Infatti, pur presentando le stesse caratteristiche tecniche viste in precedenza per la rete
multiservizio, un applicativo di navigazione web e uno di video streaming non vengono visti come
servizi diversi in quanto il loro traffico viene generato da uno stesso apparato (il PC) e quindi il
servizio percepito dall'utente è un omnicomprensivo "accesso Internet".
La rete IP può quindi trasformarsi in una rete multiservizio dove il cuore della rete è unico (tutto il
traffico è IP), mentre la periferia è ancora distinta a seconda del servizio: troveremo quindi PC con le
varie applicazioni, telefoni, POS, e altro ancora.
Vi sono alcuni motivi che stanno frenando la migrazione da una tecnologia di trasporto di tipo
telefonico ad una di tipo dati:
ξ largo numero di persone (soprattutto negli operatori telefonici) che conoscono bene la
tecnologia telefonica ma non quella dati; un passaggio di tecnologia impica uno sforzo non
indifferente di riconversione del personale
ξ larga base installata (valido soprattutto negli operatori telefonici che forniscono il servizio da
molto tempo); il passaggio alla VoIP richiede la sostituzione di una tecnologia già in campo
e, soprattutto, decisamente collaudata, a fronte di una tecnologia nuova ma che potrebbe
anche riservare sorprese; d'altro canto, perchè sostenere una nuova spesa (la rete in
tecnologia dati) quando la precedente tecnologia è in piedi e funziona benissimo?
ξ il conto della "convenienza" di una tecnologia rispetto all'altra non si fa sui "volumi di
traffico" (aspetto sicuramente a favore dei dati), ma sul profitto che questi generano; questo
parametro è ancora tutt'ora a favore del traffico telefonico.
ξ il passaggio ad una tecnologia di trasporto di tipo dati implica un salto nel buio: mente la
tecnologia telefonica è sufficientemente assestata, quella dati (per reti multiservizio) è solo
agli inizi, e possono verificarsi problemi con la sua adozione su larga scala
Queste problematiche fanno sì che gli operatori telefonici tradizionali siano più lenti al passaggio
verso una tecnologia totalmente dati, mentre nuovi operatori, che non hanno nulla da perdere e devono
affermarsi sul mercato, siano più propensi ad una tecnologia di tipo dati prevalentemente per ragioni
economiche.
Nella visione degli operatori telefonici, quindi, la tecnologia VoIP è delegata al trasporto di fonia sul
proprio backbone, in sostituzione (o spesso affiancamento) delle tecnologie esistenti. Al momento vi
sono ben pochi tentativi seri di conversione integrale di preesistenti reti telefoniche verso la tecnologia
IP.Il modello di adozione di VoIP da parte dei carrier prevede quindi (come si vede in figura) la
definizione di reti di accesso in tecnologia telefonica per il collegamento di terminali di tipo
tradizionale e in tecnologia IP per il collegamento di elaboratori. Mentre la seconda tipologia di rete di
accesso è già nativamente IP e non necessita di alcuna conversione, il traffico raccolto dalla rete
telefonica viene pacchettizzato da un opportuno gateway ed immesso nella rete IP. Il posizionamento
del gateway può essere più o meno vicino alla sorgente del traffico a seconda delle preferenze
dell'operatore. Un gateway molto vicino alla sorgente implica un trasporto di traffico IP più esteso, ma
implica anche un numero di gateway più elevato; per questo motivo la tendenza è quella di inserire i
gateway (almeno inizialmente) in una posizione tale da utilizzare la tecnologia VoIP solo tra le grosse
centrali telefoniche (normalmente poche decine su un territorio nazionale).
4
1.2 - Il processo di creazione di un flusso VoIP
Nel primo paragrafo si è visto i principi della commutazione di circuito e di pacchetto, e la percezione
della tecnologia VoIP sia presso un normale utente consumer, sia presso un operatore telefonico. In
questo secondo paragrafo si entrerà più propriamente ad illustrare le varie fasi necessarie alla
generazione e al recapito di un flusso VoIP e si vedranno i principali parametri da tenere in conto per
garantire la qualità della comunicazione.
Un flusso VoIP per diventare deve essere generato a partire dal processo di campionamento
Tale processo è quello che, data una forma d'onda analogica (quella della nostra voce) ne procede alla
traduzione in formato digitale. Il campionamento può essere considerato istantaneo, ossia non
introduce ritardo percettibile nel processo.
Questa operazione ha sostanzialmente due parametri di funzionamento:
ξ la sensibilità dello strumento, ossia in quanti bit viene trasformata l'informazione; maggiore è
il numero di bit utilizzati, più alta è la precisione del campionamento
ξ il numero di campionamenti al secondo, che esprime la massima frequenza di un segnale
analogico che potrà essere ricostruito dall'apparato ricevente a partire dai segnali generati;
questo parametro è importante per aumentare la risposta in frequenza, ma va tenuto conto che
l'orecchio umano non è particolarmente sensibile a determinati range di frequenza.
La banda utilizzata da un segnale campionato è dato dal prodotto tra le due grandezze precedenti.
Il campionamento viene fatto direttamente dal telefono nel caso di apparecchi digitali (ad esempio i
telefonici ISDN) oppure da un apparato nella più vicina centrale dell'operatore telefonico nel caso di
tradizionali apparecchi analogici.
Il secondo passo consiste nella fase di codifica che spesso è confusa all'interno del processo di
campionamento. La procedura di codifica parte dai risultati digitali "grezzi", prodotti dal processo di
campionamento, e li elabora per ottenere un risultato "migliore", che normalmente equivale ad
abbassare il bitrate (la banda) del dato campionato (compressione). Ci possono essere più tecniche di
codifica; tra le più note possiamo citare:
ξ codifica per differenze: se il campione successivo differisce di poco rispetto al campione
precedente, se ne trasmette la differenze (che richiede un numero di bit inferiore) rispetto al
campione originario (tecnica utilizzata ad esempio dai codec della famiglia ADPCM)
ξ codifica pesata: se determinati campioni sono spesso presente all'interno del flusso vocale, si
adotta una convenzione che li codifichi con un numero di bit inferiore, in modo da
risparmiare banda (tecnica utilizzata ad esempio dalla compressione di files di tipo ZIP)
ξ codifica a perdita: si basa sul principio che, per l'orecchio umano, determinati segnali audio
vengono praticamente ignorati. Questo tipo di codifica fa sì che questi tipi di segnali vengano
cancellati, e la codifica risultante diventi più snella grazie al fatto che ci sono meno dati da
inviare (tecnica utilizzata nella compressione di audio MP3)
Ovviamente queste tecniche possono anche essere combinate insieme nel medesimo codificatore.
Con queste tecniche si possono ottenere compressioni del segnale notevoli (si pensi al formato MP3 a
96kbps, che ha una qualità audio molto parente dei quella di un CD audio che ha un bitrate di circa
600kbps), ma richiedono normalmente una potenza elaborativa non indifferente; inoltre, in particolare
la codifica per differenze, può richiedere la presenza di un campione successivo per poter inviare il
dato attuale. Un tipico esempio è la codifica video utilizzata in MPEG che adotta una codifica
differenziali sia rispetto alla trama precedente che rispetto a quella successiva.
Non è sempre vero quindi che una codifica a più basso bit rate sia intrinsecamente peggiore di una a
più alto bit rate: la differenza viene fatta spesso dall'algoritmo. Non è quindi infrequente trovare degli
ottimi codificatori ad un bit rate molto basso che lavorano in maniera molto simile al codificatore
PCM64, standard della rete telefonica. E' vero invece che un'algoritmo particolarmente ottimizzato per
la voce può trovarsi in grande difficoltà verso altri segnali vocali (ad esempio la musica classica):
algoritmi aggressivi si basano su determinati principi (ad esempio che la voce umana non genera
determinati tipi di frequenze) che possono essere disattesi in caso di sorgenti di tipo diverso.
In generale, la fase di codifica introduce il problema della potenza elaborativa necessaria a portarla a
termine, che può diventare un ostacolo per la VoIP in quanto potrebbe significare l'adozione di una
CPU adeguatamente potente (o di un chip DSP) a bordo di ogni singolo terminale (telefono). Inoltre,
determinati tipi di codifica (in particolar modo quella a perdita) suppongono che il ricevitore ultimo
dei dati sia l'orecchio umano: se così non è (ad esempio il ricevitore è un modem analogico) la
5
codifica a perdita può non essere applicabile in quanto eliminerebbe informazioni che sono invece
vitali per la comunicazione.
A causa delle limitazioni precedenti (potenza elaborativa e inferiore contenuto informativo), spesso le
reti VoIP non implementano l'operazione di codifica così come descritta in questa sezione, limitandosi
a generare i campioni in maniera opportuna con il classico codec PCM64 e ad inviarli alla
destinazione senza elaborazione intermedia. Spesso, l'unica elaborazione fatta è un'eventuale
soppressione dei silenzi, che non genera problemi anche se la sorgente non è di tipo vocale. La
mancata adozione di un algoritmo di codifica evoluto fa sì che si vanifichi uno degli aspetti
interessanti della VoIP, ossia la possibilità di abbassare il bit rate.
La scelta del codec non dipende dunque esclusivamente dai quattro fattori "tecnici" (la complessità di
elaborazione, il ritardo introdotto, la banda richiesta e la qualità del segnale prodotto), ma anche da
considerazioni di tipo logistico (l'aggornamento dei terminali piuttosto che la potenza elaborativa
richiesta nei gateway VoIP) e di tipo commerciale (garantire il servizio "dati" sulla rete telefonica).
Una tecnica che è spesso abilitata nei codec VoIP è la soppressione dei silenzi. Questa si basa su due
semplici osservazioni:
ξ la maggior parte delle conversazioni telefoniche avviene in una modalità half duplex: solo
uno dei due interlocutori parla, mentre l'altro ascolta; di conseguenza uno dei due canali
(andata e ritorno) è normalmente inattivo
ξ la velocità con cui una persona emette dei suoni (cioè "parla") è decisamente limitata rispetto
alle velocità degli elaboratori e ai tempi scelti per la pacchettizzazione. Il tempo tra due
parole può quindi essere visto come un istante di silenzio la cui durata, per un calcolatore,
può essere significativa.
Nel caso in cui un codec sia in grado di gestire la soppressione dei silenzi, i pacchetti vocali (inutili, a
questo punto) non verranno trasmessi.
Questa tecnica, per quanto sia utile per ridurre la banda impiegata in una comunicazione, introduce
due problemi non indifferenti.
ξ Il primo problema è dovuto al fatto che gli utenti telefonici sono abituati ad ascoltare in
sottofondo alla comunicazione una sorta di rumore bianco, il cosiddetto "fruscio di fondo". Si
è però verificato come l'assoluto silenzio della cornetta disturbi la persona umana, che è
portata a pensare che la comunicazione sia stata abbattuta.. Per ovviare a questo primo
problema, spesso il ricevitore genera autonomamente un fruscio che rende più confortevole
la conversazione: il fruscio viene percepito dagli interlocutori come segnale che la
connessione tra i due è ancora attiva.
ξ Il secondo problema deriva dal fatto che non è immediato, per un codificatore, riconoscere
che un utente ha iniziato a parlare. Tendenzialmente, questa operazione richiede un intervallo
temporale che può essere più o meno elevato a seconda della bontà dell'apparato e della
potenza elaborativa a disposizione. In alcuni casi il tempo di riconoscimento del parlato è
così elevato che, a riconoscimento avvenuto, il campione è ormai vecchio e la sua
trasmissione risulterebbe inutile in quanto arriverebbe a destinazione fuori tempo massimo.
In questo caso si verifica che la prima parte (ad esempio la prima sillaba) di una frase viene
sistematicamente persa.
Dal momento che in una telefonata è necessario sia ascoltare la voce che arriva dalla controparte, sia
parlare a nostra volta, è spesso difficile evitare che la voce in arrivo non venga a sua volta captata dal
microfono e ritornata (attenuata) al mittente. Il problema può essere ridotto utilizzando gli auricolari
accoppiati ad un microfono vicino alla bocca: questo è possibile (e consigliato) nell'interazione PC-to-
PC, ma è chiaramente improponibile nel caso di cornetta telefonica.
Se il percorso complessivo richiede meno di una manciata di microsecondi (10 è uin valore
ragionevole), non ci sono particolari problemi in quanto poiché la riflessione è percepita come parte
normale del discorso del parlante. Con un ritardo maggiore, invece, si generano problemi; di solito la
persona che parla sente le proprie parole riflesse e si ferma per cercare di capirle Dal momento che il
ritardo complessivo nei sistemi VoIP può facilmente superare i 200 ms, diventa necessario sopprimere
l'eco.
Questo può essere fatto nel sistema d'elaborazione digitale dell'audio, come parte del processo di
elaborazione eseguito dal codec: il sistema campiona il segnale di ritorno e sottrae qualsiasi replica dei
segnali già inviati: l'efficienza raggiunta è alta, ma la potenza elaborativa aumenta ed è possibile che si
introducano ulteriori ritardi.
6
Un'altra fase molto importante per la generazione di pacchetti VoIP è la pacchettizzazione.Mentre le
precedenti operazioni (campionamento e codifica) possono trovare parzialmente impiego anche su una
rete telefonico di tipo digitale, l'operazione di pacchettizzazione è peculiare delle reti a pacchetto. Un
pacchetto, per sua natura, è composto da una serie di headers necessari affinchè il pacchetto possa
correttamente giungere alla destinazione. Questi headers non sono eliminabili, il che comporta che
debbano essere presenti sia nel caso in cui ci sia un solo byte di dato da trasportare, sia nel caso in cui
ce ne siano molti.
Nel caso della voce su IP, il tipico header ha una dimensione di 58 bytes (18 bytes Ethernet, 20 bytes
IP, 8 bytes UDP, 12 bytes RTP): se, per ogni pacchetto, si trasportasse un solo byte di dato,
l'efficienza diventerebbe pari al circa all'1.7%, che equivale a dire che un flusso voce a 64kbps
genererebbe un traffico di 3.7Mbps. Questo è chiaramente una cosa improponibile,
Essendo questa una cosa improponibile, l'unica soluzione per abbattere il costo (fisso) dell'header è
quella di inserire più campioni nello stesso pacchetto. Ad esempio, inserendo 58 campioni da 1 bytes
l'uno si ottiene un'efficienza del 50%, con un'occupazione di banda di 128kbps. Purtroppo, però, non è
possibile fare il pacchetto grande a piacere, in quanto si aumenterebbe a dismisura il ritardo con cui il
pacchetto viene recapitato.
Per capire questo problema si supponga, ad esempio, di generare un campione (grosso 1 byte) al
secondo e che il tempo necessario a recapitare il dato a destinazione (ossia il ritardo di trasmissione
del campione sul filo) sia di 5 secondi. E' evidente come il destinatario della comunicazione, nel caso
in ogni pacchetto contenga un solo campione, riceverà i dati con un ritardo di 5 secondi. Si supponga
ora di trasportare la voce inserendo 10 campioni nello stesso pacchetto prima di farlo partire. Il ritardo
con cui l'ascoltatore riceverà i dati sarà ora di 15 secondi: 10 necessari a riempire il pacchetto con 10
campioni, quindi altri 5 per recapitare il pacchetto a destinazione. L'esempio precedente porta a
concludere come il numero di campioni per ogni pacchetto non sia una grandezza che può essere
decisa liberamente, in quanto all'aumentare del numero di campioni aumenterà linearmente anche il
ritardo con cui questi dati verranno recapitati a destinazione, rendendo problematica l'interazione in
tempo reale di due persone.
Valori di ritardo di pacchettizzazione ragionevoli sono dell'ordine dei 20-40ms.
7
1.3 - Trasmissione del pacchetto sulla rete dati
La trasmissione dei pacchetti su una rete a commutazione di pacchetto va incontro a delle incertezze
maggiori rispetto alla trasmissione in modalità di commutazione di circuito. Fatto salvo il tempo di
propagazione (ossia il tempo necessario affinchè il segnale si propaghi in un mezzo fisico, che è la
massima velocità a cui possono viaggiare i dati in un mezzo fisico e pari solitamente ai due terzi della
velocità della luce), che è un fattore da tenere in conto anche nella tecnologia a circuito, esistono altri
due fattori che possono rallentare il proseguimento del pacchetto verso la destinazione.
In questa fase nasce un fenomeno detto dell’accodamento che avviene nei nodi interni della rete dati
qualora la somma del traffico in ingresso, e diretta verso uno stesso link in uscita, è maggiore della
capacità del link. In questo caso una parte del traffico verrà memorizzato internamente al router e
verrà smaltito con gradualità, non appena il link in esame è in grado di inviare un nuovo pacchetto.
Questo fenomeno, chiamato anche buffering, provoca un ulteriore ritardo di consegna del pacchetto in
quanto il pacchetto può fermarsi per un periodo di tempo arbitrariamente lungo all'interno del nodo di
rete. Questo fenomeno non è presente nelle reti telefoniche in quanto, grazie alla fase di instaurazione
del circuito (call setup), i nodi intermedi sulla rete accettano la chiamata solamente nel momento in
cui possono garantire che non esisteranno mai situazioni come quella in esame (ossia il traffico in
ingresso è maggiore della capacità di smaltimento del link.
Il problema dell'accodamento può essere risolto in due modi:
ξ adottando anche sulle reti IP un meccanismo di call setup, tale per cui la situazione
precedente è evitata grazie ad un meccanismo di prenotazione delle risorse
ξ adottando un sistema che ovvi parzialmente il problema dell'accodamento, almeno per il
traffico vocale; è ad esempio il caso di accodamento a priorità (o priority scheduling).
Il priority scheduling non è altro che l'idea di creare all'interno di un router, due percorsi di
smaltimento dei dati; uno ad alta priorità, l'altro a priorità standard. Nel momento in cui un pacchetto
entra nel router, questo controlla la tipologia del pacchetto e lo inserisce in uno dei due percorsi (o
code). In altre parole, tutti i pacchetti vocali finiranno insieme nella stessa coda, mentre tutti i
pacchetti dati finiranno nell'altra. L'accortezza sta nel trasmettere sempre, per primi, i pacchetti che
stanno nella coda ad alta priorità, indipendentemente dal numero di pacchetti nell'altra coda. Questo
significa che se i pacchetti vocali (ad alta priorità) sono pochi rispetto alla totalità del traffico, questi
troveranno sempre la coda ad alta priorità libera e quindi saranno trasmessi immediatamente.
Questo sistema non è deterministico, ossia non si garantisce che la coda ad alta priorità sia sempre
libera. Tuttavia, se la rete è ben progettata, con ragionevole certezza i pacchetti voce verranno inoltrati
molto velocemente indipendentemente dal traffico effettivamente scorrente sulla rete.
La soluzione del priority scheduling non è certamente l'unica in questo filone; tuttavia è molto
utilizzata grazie alla sua semplicità.
1.3.1 - Problematiche di trasmissione
Il sistema di priority sceduling illustrato nel punto precedente non permette ancora di risolvere tutti i
problemi. Si supponga infatti, che in router, in mancanza di pacchetti ad alta priorità, inizi la
trasmissione di un pacchetto normale. Se, un istante immediatamente successivo, arrivasse nel router
un pacchetto ad alta priorità, questo è obbligato ad attendere la trasmissione del pacchetto precedente
prima di poter essere immesso sul canale.
In altre parole, il priority queuing permette di passare davanti a tutti i pacchetti in coda tranne,
normalmente, uno: quello attualmente in trasmissione. Questo fenomeno introduce un nuovo ritardo,
anche questo non presente nella commutazione di circuito, inversamente proporzionale alla velocità
del link in uscita: più il collegamento è lento, più il tempo di attesa diventa potenzialmente alto.
Inoltre, anche il pacchetto ad alta priorità necessita di un tempo finito per essere immesso sul canale,
con le stesse modalità del caso precedente. In altre parole, il ritardo a cui va incontro ogni pacchetto è
dato dalla somma del proprio ritardo di trasmissione e da quello del pacchetto immediatamente
precedente ad esso. Questo è dovuto al meccanismo store and forward proprio dei router; questo
fenomeno non esiste se si implementa una tecnica di commutazione di tipo cut through, normalmente
non impiegata a causa della notevole complessità, che è tuttavia la tecnica adottata dalla
commutazione di circuito.
8
Le problematiche di trasmissione più comuni sono quindi:
ξ De-jitter
Non essendo predicibile a priori il ritardo subito da ogni pacchetto nella rete, i pacchetti
arriveranno a destinazione con degli intervalli di tempo variabili tra di essi. In altre parole, i
pacchetti non arriveranno equispaziati, ma la differenza tra i tempi di arrivo di due qualunque
pacchetti consecutivi sarà un numero variabile. Il jitter è una grandezza che rappresenta
esattamente questo fenomeno: il jitter è nullo esclusivamente nel caso in cui i pacchetti
arrivino equispaziati.
Fig. 1-1 – Fenomeno del jitter e del dejitter – [Fonte: www.voip.htm.it]
Il jitter è un problema sui pacchetti vocali, in quanto non permette la riproduzione fedele del
flusso audio. In altre parole, se i pacchetti sono stati generati dalla sorgente con un intervallo
di tempo di 40ms tra uno e il successivo, la loro riproduzione dovrà rispettare il medesimo
intervallo di tempo.
La soluzione al problema del jitter si trova inserendo i pacchetti all'interno di una coda (ad
esempio nel dispositivo di ricezione) ed estraendoli a ritmo costante. La dimensione della
coda dipende dal massimo jitter che può essere inserito dalla rete o, in alternativa, al massimo
intervallo di tempo che si è disposti ad aspettare sul ricevitore, passato il quale il pacchetto
viene considerato perso, anche nel caso di suo arrivo tardivo.
ξ Riordinamento dei pacchetti
Nonostante non sia un fenomeno altamente diffuso, esistono numerosi casi in cui la rete IP
procede ad un riordinamento dei pacchetti, vale a dire che alcuni pacchetti, pur essendo stati
generati dopo di altri, vengono in realtà consegnati per primi alla destinazione. Questo è
chiaramente un problema per i campioni vocali, in quanto la loro riproduzione deve avvenire
strettamente nell'ordine con il quale sono stati generati.
La soluzione al fenomeno è praticamente identica al blocco de-jitter: i pacchetti vengono
inseriti in una coda (normalmente nello stesso dispositivo di ricezione) e riordinati prima di
passarli all'utilizzatore finale. Valgono le stesse considerazioni fatte per il blocco de-jitter in
relazione al dimensionamento della coda stessa. In effetti, de-jitter e riordinamento sono
fenomeni che, spesso, vengono trattati dal medesimo blocco.
ξ Decodifica
Il blocco di decodifica è quello che, partendo dai pacchetti contenenti i campioni vocali,
procede alla loro trasformazione in un flusso analogico, effettuando un lavoro speculare
rispetto ai blocchi di codifica e campionamento.
L'unica particolarità del blocco di decodifica è la necessità di rimpiazzare eventuali pacchetti
mancanti nel flusso vocale in maniera da rendere più possibile confortevole l'ascolto del
flusso vocale. Le soluzioni sono molteplici:
ξ ripetizione dei campioni contenuti nel pacchetto precedente
ξ tecniche predittive, miranti a generare un insieme di campioni "plausibili" partendo
da quelli già in possesso del ricevitore
ξ generazione di silenzio (rumore bianco)
9
Anche in questo caso, le tecniche possono essere combinate insieme per l'ottenimento di un
risultato migliore.
Il ritardo di decodifica è normalmente abbastanza basso, tranne nel caso in cui il campione
attuale dipenda anche da quelli che arriveranno successivamente (con una tecnica identica a
quella già evidenziata per i codec). Normalmente la decodifica richiede meno risorse
computazionali, in quanto deve applicare un algoritmo predefinito. La fase di codifica può
invece essere più onerosa in quanto spesso sono disponibili più tecniche di compressione e il
codificatore deve decidere, in tempo reale, quale adottare per ottenere i risultati migliori.
1.4 - Parametri caratteristici di una sessione vocale
Nel progetto di una rete VoIP è necessario tenere in considerazione i seguenti parametri:
1.4.1 - Ritardo
Il parametro sicuramente più importante è il ritardo. Come ritardo end-to-end si definisce il lasso di
tempo che trascorre tra la ricezione di un'onda analogica da parte del campionatore alla sua
rigenerazione da parte del ricevitore. Normalmente, si preferisce però parlare di ritardo end-to-end
riferito alla rete, che corrisponde al tempo da quando il pacchetto viene ricevuto dal pacchettizzatore a
quando viene consegnato al codificatore.
Dal punto di vista dell'interazione vocale, però, il ritardo end-to-end è poco significativo ed è
necessario considerare quindi il round-trip delay, ossia il ritardo di andata e ritorno. Infatti, non è tanto
importante il tempo necessario ad un segnale per essere trasferito dall'utente A all'utente B, ma il
tempo necessario anche a portare indietro la risposta ad A.
Questa latenza dipende da vari fattori riguardanti sia le prestazioni degli end-point (ad esempio il
codificare) che le prestazioni della rete.
L' ITU ha definito 3 fasce di ritardo end-to-end:
ξ dai 0 ai 150 ms. è accettabile per tutti i tipi di chiamata,
ξ dai 150 ai 400 ms. è accettabile solo per collegamenti intercontinentali,
ξ oltre 400 ms. è inaccettabile per comunicazioni vocali.
Ritardi elevati possono creare alcuni disagi come il Talker Overlap, in cui il chiamante, che è abituato
a ricevere una risposta entro un certo tempo, non sentendola arrivare a causa degli elevati ritardi,
ripete la domanda che si sovrappone alla risposta che sopraggiunge. Questo può provocare problemi
sulla sincronizzazione degli interlocutori rendendo difficile la comunicazione.
Bisogna quindi evitare che i ritardi end-to-end dei pacchetti voce superino il limite dei 150 ms.
I componenti del ritardo, così come si può estrapolare dalle varie fasi necessarie a trasferire un flusso
VoIP, sono i seguenti:
ξ ritardo di codifica
ξ ritardo di pacchettizzazione
ξ ritardo di accodamento (vedi Fig.1-2)
ξ ritardo di trasmissione
ξ ritardo di de-jitter (e di ordinamento)
ξ ritardo di decodifica
Fig.1-2 – Ritardo e riordinamento pacchetti – [Fonte: www.voip.html.it]
10
1.4.2 - Banda
Una caratteristica del traffico vocale è il fatto di essere anelastico. In altre parole, il traffico vocale ha
la necessità di una certa banda che deve essere sempre disponibile. Questa caratteristica lo differenzia
profondamente dal traffico dati tradizionale che è di tipo elastico, ossia non è particolarmente
penalizzato se, in alcuni istanti di tempo (di durata limitata) i pacchetti di una determinata sessione
vengono ritardati dalla rete e non giungono a destinazione se non dopo un certo tempo (ad esempio
alcuni secondi).In altre parole, il traffico vocale non è in grado di adattarsi alle condizioni della rete,
adattando il bitrate a seconda della banda disponibile: una volta definito che una sessione vocale ha la
necessità di, ad esempio, 80kbps, tale banda deve essere disponibile. In caso contrario, i pacchetti
vocali possono essere tranquillamente scartati.Questo si ripercuote, ad esempio, nella fase di progetto
della rete in quanto è inutile procedere alla memorizzazione dei pacchetti vocali all'interno dei router
(buffering) in quanto ne si aumenterebbe il ritardo rendendoli inutili. Ad esempio, nel caso di una rete
con meccanismi di scheduling di tipo priority queuing, le code per i dati possono avere una
dimensione decisamente maggiore rispetto alle code per i pacchetti vocali. Se si riceve un pacchetto
vocale e la coda ad alta priorità è ormai piena, è più conveniente scartarlo in quanto è molto probabile
che al suo arrivo alla destinazione avraà un ritardo troppo elevato. Questa procedura permette di
salvare banda perchè evita la trasmissione del pacchetto (in ritardo) sulla rete, occupando risorse,
quando lo stesso verrà comuque scartato dal nodo ricevente.Un'altra caratteristica del traffico vocale è
che, sebbene la banda richiesta sia tutto sommato modesta (esistono ottimi codificatori con bit rate di
uscita pari a 5.3kbps), questa deve essere disponibile per una maggiore durata temporale. Infatti, le
sessioni dati sono tendenzialmente più corte rispetto ad una sessione voce.
1.4.3 - Perdita
A differenza dei dati, l'orecchio umano (o meglio, il cervello) reagisce bene anche al caso in cui vi sia
la mancanza di alcuni spezzoni di comunicazione. Solitamente si pone la massima percentuale
tollerabile di pacchetti persi pari al 5% del totale dei pacchetti vocali. Sotto questa soglia, la qualità
per l'orecchio umano è decisamente accettabile. In fondo, l'esperienza delle reti mobili con frequenti
disturbi insegna che una percentuale limitata di perdite non è affatto un problema.I pacchetti persi
sono sia quelli che, per qualche motivo, vengono scartati all'interno della rete (ad esempio in caso di
congestione), sia i pacchetti che arrivano oltre una soglia massima. Infatti, il ritardo end-to-end ha
un'importanza molto maggiore rispetto alle perdite in riferimento alla qualità della comunicazione
percepita dall'utente. E' quindi decisamente preferibile accettare un numero di pacchetti persi
maggiore rispetto ad imporre un più alto ritardo end-to-end. Questa considerazione fa sì che, spesso, i
componenti di de-jitter e di riordinamento dei pacchetti vengano dimensionati con "budget di ritardo"
molto ridotti, preferendo quindi scartare pacchetti giunti oltre il ritardo massimo ammesso per non
peggiorare le caratteristiche di interattività.
Altre tecniche sono quelle che vanno sotto il nome di layered encoding: sostanzialmente si codificano
le informazioni fondamentali in una trama, e le informazioni "supplementari" in una successiva. Ad
esempio, nel caso della trasmissione video si potrebbe codificare il quadro video in bianco e nero in
una trama e l'informazione legata al colore in un'altra. Presupposto affinchè tutto funzioni è che la rete
sia in grado di riconoscere l'informazione principale e che questa venga sempre recapitata a
destinazione. In condizioni normali, sia la trama base che il colore verranno recapitati. In caso di
problemi, la rete riconoscerà (in qualche maniera non meglio specificata e dipendente dalla rete
stessa) i pacchetti meno importanti e inizierà a scartarli.
11
1.5 - Conclusione
In conclusione a questo primo capitolo si può riassumere principali argomenti trattati partendo dal
concetto di trasmissione di un segnale vocale.
La trasmissione di un segnale vocale su rete IP non presente di per sé particolari difficoltà: come tutti i
segnali,la voce può essere opportunamente digitalizzata e convertita in un flusso di bit avendo a
disposizione una banda sufficiente avendo a disposizione una banda sufficiente,questi possono poi
essere inviati sul network come dati generici e ricomposti nel segnale originali una volta arrivati a
destinazione. La qualità intrinseca del flusso audio dipende dalla codifica utilizzata: esistono numerosi
codec in grado di offrire qualità e occupazione di banda variabile . Un impianto di IP telephony ben
dimensionato offre generalmente una qualità paragonabile alla telefonia classica e superiore a quella
cellulare.
I problemi nascono semmai quando il traffico voce deve essere garantito in tempo reale e con qualità
sufficiente a sostenere una conversazione intelligibile; le reti IP sono nate come strutture di
comunicazione dati e poco si adattano nella loro forma nativa alle trasmissioni realtime come quelle
telefoniche .
Si tratta innanzitutto di reti a commutazione di pacchetto ,una tecnologia che, a differenza della
commutazione di circuito impiegata dalla rete telefonica tradizionale, non assegna delle risorse
dedicate, se nel caso dei network switched è possibile stabilire un canale fisico che mette in
comunicazione i due terminali e rimane a loro disposizione per tuta la durata della chiamata,in una
rete a pacchetto il traffico è invece segmentato in frammenti che viaggiano autonomamente lungo la
rete per giungere a destinazione.
Questa procedura ha lo scopo di massimizzare l’impiego delle risorse di rete, ma può presentare
numerosi svantaggi per quanto riguarda la comunicazione in tempo reale: è necessario infatti che i
pacchetti arrivino a destinazione con un ritardo adeguato per al conversazione (una latenza superiore
ai 400 ms è considerata inaccettabile), nell’ordine corretto e con una spaziatura temporale costante. I
meccanismi di riordinamento e de-jitter (con jitter si intende appunto la varianza nel ritardo tra i
pacchetti) si basano sulla presenza di un buffer in ricezione,che ha però lo svantaggio di inserire
ulteriore latenza nella comunicazione.
La telefonia su IP non è invece particolarmente minacciata dalla perdita dei dati: la mente umana è in
grado di compensare alla perdita del 5% delle informazioni,grazie a processi di interpolazione
cerebrale. Per questo i protocolli utilizzati,tipicamente RTP ( Real Time Protocol),sfruttano il
trasporto Udp,meno affidabile ma più “reattivo” nella trasmissione su reti IP rispetto al Tcp.
Il problema dei ritardi deve comunque essere affrontato anche a livello di risorse di rete,e proprio per
questi motivi sono introdotti i protocolli di Quality Of Service (Qos),che attribuiscono a determinate
applicazioni delle priorità in termini di ritardi o bit error rate per assicurare una consegna più rapida ai
servizi time sensitive come la telefonia su IP. Gestione della qualità del servizio e dei ritardi di
trasmissione possono adattare una rete nativamente inadeguata come quella IP al flusso vocale in
tempo reale ,ma non sono sufficienti a gestire un impianto di IP telephony: per questo scopo sono
infatti necessari opportuni meccanismi di segnalazione; con questo termine si intendono le funzioni
per inizializzare,gestire e terminare una chiamata. La PSTN (Public Switched Telephone Network) si
avvale del protocollo SS7, un servizio di segnalazione collaudato e lagato a doppio filo con la
tecnologia di rete su cui opera.
Fino a pochi anni fa Internet e l’Ip non disponevano di nulla del genere; oggi le due linee di tendenza
di maggior successo sfruttano la famiglia di standard H.323, nata per la videoconferenza e poi
evolutasi fino a implementare meccanismi di utili al VoIP, e SIP (Session Initiation Protocol), un
protocollo specializzato nella segnalazione su reti IP e considerato dalla maggior parte degli addetti ai
lavori lo standard su cui basarsi per le applicazioni future.
A livello sintattico, SIP è molto simile all’Http e Smtp già diffusi su internet per la trasmissione di
pagine ipertestuali e posta elettronica e questo rende semplice la sua integrazione con applicazioni di
rete ormai affermate come il World Wide Web. Per la localizzazione degli utenti, SIP utilizza un
sistema di Url del tutto analogo a quello impiegato dalla posta elettronica.
Dopo questa carrellata sulle maggiori problematiche che si incontrano nelle varie fasi di generazione
di un flusso VoIP, partendo ovviamente dalla generazione di un pacchetto VoIP per arrivare alla
trasmissione vera e propria, è importante citare come nel capitolo 2 e nel capitolo 3 si fa riferimento
rispettivamente ai due protocolli fondamentali che regolano un flusso multimediale. Lo Standard
12
H.323 sviluppato dall’organo ITU-T nella sua prima versione nel 1996, nel capitolo 2 ,viene
analizzato nelle sue varie caratteristiche così come per quanto concerne il capitolo 3 che vorrà essere
una sorta di analisi dello standard SIP definito dall’organo IETF nel suo RCF 3261 .
Il capitolo 4 riguarda uno studio del centralino software “proprietario” Cisco CallManager” nelle sue
principali funzionalità ponendo l’accento sulle varie problematiche che si incontrano nell’ambito dello
smistamento di un comune flusso VoIP e non solo. Sulla falsa riga del capitolo 4 viene sviluppato il
capitolo 5 ma il centralino telefonico considerato sarà Asterisk : Software PBX Open Source definito
per ambienti Linux / Unix.
Il capitolo 6, in cui si trova una sorta di comparazione degli standard visti e dei due centralini, porta
alla conclusione del lavoro in cui sarà spazio per alcune considerazioni finali in merito al lavoro
svolto.
13
CAPITOLO 2
H.323 – Lo standard VoIP dell’ITU-T
2.1 - Introduzione
Il protocollo H.323 è stato il primo e rimane tuttora uno dei più potenti protocolli standard
internazionali per le comunicazioni multimediali real-time su reti a commutazione di pacchetto, tanto
da essere diventato un punto fermo di riferimento nel mondo del VoIP.
Come tanti altri importanti protocolli di comunicazione, lo Standard H.323 è stato pubblicato dall’ITU
come protocollo di conferencing multimediale. Esso, infatti, definisce in che modo dispositivi, anche
molto diversi tra loro, come computer, telefoni standard, mobile e wireless, PDA, sistemi di video
conferenza, ecc. possano intercomunicare per fornire all'utente un'esperienza del tutto innovativa
rispetto agli standard di comunicazione sinora offerti dalle tradizionali reti PSTN. Con ciò, tuttavia,
non si deve pensare che H.323 sia in grado di offrire servizi solo a terminali, hardware o software, di
tipo VoIP ed in generale appartenenti ad una certa rete a commutazione di pacchetto; H.323, infatti,
nasce come logica estensione dello studio compiuto all'interno della stessa ITU-T sul multimedia
conferencing applicato a reti a commutazione di circuito e convogliato nelle restanti raccomandazioni
della serie H.32x. E' grazie a quest’eredità, dunque, che lo standard H.323 è in grado di interoperare
con una grande varietà di apparati per video ed audio conferenza sviluppati per reti PSTN. In questo
senso, esso permette un passaggio meno drastico dalla vecchia tecnologia alle nuove forme di reti per
telecomunicazioni e realizza, inoltre, una più ampia convergenza di voce, video e dati, potendo
travalicare con estrema facilità, come vedremo, i confini delle reti IP, per cui è nato, e interfacciarsi
con i più tradizionali sistemi di telefonia e trasmissione dati, fornendogli nel contempo servizi in molti
casi assolutamente innovativi.
Come vedremo H.323 non è solo un insieme di regole fisse a cui vari tipi di apparati devono
conformarsi per il buon esito della comunicazione e dell'interoperabilità complessiva del sistema di
telecomunicazione multimediale in questione, ma è, fondamentalmente, un modo assolutamente
nuovo di concepire la comunicazione tra due o più utenti.
Le possibilità offerte dallo standard H.323 sono, infatti, così vaste da rivoluzionare completamente il
concetto stesso di telefonia e comunicazione. Andando oltre la tradizionale comunicazione in tempo
reale di tipo telefonico, lo standard H.323 prevede non solo una comunicazione di tipo multimediale e
multi-utente, ma anche una comunicazione che possa arricchirsi contemporaneamente di tutte le
potenzialità offerte da Internet e dal World Wide Web. Ci si sta, dunque, riferendo ad uno scenario in
cui l'utente del servizio di comunicazione non è più strettamente legato al suo particolare terminale e
numero telefonico, nonché al luogo in cui esso si trova, ma in cui un utente può comunicare
utilizzando un qualunque PC con installato un opportuno applicativo VoIP conforme allo standard,
connesso alla rete e tramite questa ad un server H.323 in grado di fornirgli ogni tipo di supporto e
servizio. In questo senso, l'utente sarà ora libero di cambiare terminale e locazione senza preoccuparsi
della sua raggiungibilità o capacità di accesso al servizio, poiché sarà il server H.323, che delineeremo
in seguito nel capitolo, a preoccuparsi della localizzazione dell'utente sulla rete mediante uno scambio
d’informazioni tra interdomini H.323 facente riferimento a tutta una serie di possibili identificativi
scelti, al momento della registrazione, dall'utente stesso, quali alias, indirizzi IP o semplici numeri
telefonici. Oltre a ciò, l'utente potrà, tra gli altri servizi:
ξ avvalersi dei classici servizi di telefonia rivisti alla luce delle più ampie possibilità offerte
dalla tecnologia a pacchetto (di cui ci occuperemo più tardi e raccolti nella serie di
Raccomandazioni ITU H.450),
ξ aver accesso tramite un'interfaccia HTTP ad una propria rubrica telefonica da cui con un
semplice click possa connettersi direttamente al contatto desiderato, o navigare una pagina
web e decidere di chiedere informazioni ed assistenza su di un certo prodotto direttamente al
servizio clienti della casa produttrice con un semplice click sul logo della stessa (servizio
"Click-to-talk").
14
Questa ovviamente non è che una breve carrellata delle tante possibilità offerte dallo standard H.323,
tanto più che ne nascono continuamente di nuove e quelle già affermate sono comunque in costante
evoluzione. Sin dall'inizio, gli sviluppatori di H.323 hanno voluto creare un protocollo che avrebbe
dovuto essere il Next Generation Network Protocol, il protocollo di comunicazione per eccellenza
sulle nuove reti a pacchetto, sulla piccola LAN del privato come sulle grandi dorsali di comunicazione
internazionali delle grandi compagnie di telecomunicazione. E' con questo obiettivo che i suoi
progettisti hanno dotato H.323 di alcuni punti di forza che sino ad ora lo hanno reso il più conosciuto
e diffuso protocollo di comunicazione multimediale su reti IP nel mondo.
Oltre alle caratteristiche innovative a cui si è già accennato, le potenzialità di H.323 stanno in quattro
punti fondamentali che ne costituiscono il vero fulcro ed anima del suo successo:
1. Il tipo di controllo ibrido
2. L’indipendenza dalla tipologia di rete
3. L'integrazione con gli standards Internet
4. La flessibilità
Tutte queste caratteristiche fin’ora descritte sono la base su cui si appoggierà l’intero sviluppo di
questa tesi che vuole innanzitutto essere uno strumento utile per la comprensione di alcune delle
problematiche che si incontrano nello sviluppo di applicativi Voip che si basano su centralini software
e su protocolli di comunicazione SIP e H.323
Tra i vari problemi del Voice over IP, pongo l’accento sul problema della scalabilità e dell’impatto di
tali applicativi sulle reti IP. Se infatti risulta possibile realizzare strutture di conferenza multimediale,
è anche vero che queste richiedono trasmissioni di video e voce di più utenti e risultano applicazioni
tanto più pesanti quanto più cresce il numero dei partecipanti.
Almeno ad una parte di questi problemi l’ITU cercò di dare una risposta, emanando una
raccomandazione “ombrello” che tenesse conto della situazione di fatto dei vari protocolli usati e
cercando di armonizzarli. Il risultato fu nel 1996 la prima versione della Raccomandazione H.323.
In questo primo capitolo si andrà ,in definitiva , ad analizzare le raccomandazioni del protocollo
H.323, nella versione del 2003, intese come componenti indispensabili per una buona comunicazione
multimediale, l’architettura stessa dello standard, i dispostivi utilizzati e non meno importante
verranno citati alcuni dei più significatici segnali di controllo in una comunicazione multimediale.
2.2 - Scopo della raccomandazione H.323
La raccomandazione H.323 comprende la definizione delle componenti tecniche necessarie per una
comunicazione multimediale (audio, video, dati) che si trovi a lavorare, come sottorete di trasporto, su
una rete a pacchetto (PBN) che potrebbe non garantire una Qualità di servizio (QoS). Queste reti a
pacchetto
possono includere Local Area Network, Enterprise Area Network, Metropolitan Area Network, Intra-
Network e Inter-Network (compreso Internet).
Come anticipato, la prima versione della raccomandazione è del 1996 ed il suo titolo: “ H.323 visual
telephone system and equipment for LANs that provide a nongaranteed quality of service “ chiarisce
come fosse indirizzata esclusivamente alla fornitura del servizio su LAN. Ma dopo soli 2 anni è stata
emanata la più completa “H.323 Packed based multimedia comunication system” rivolta a qualunque
tipo di rete a pacchetto. Lo standard H.323 fa parte della famiglia di raccomandazioni H.32X dell’ITU
definite per servizi di comunicazioni multimediali su differenti reti:
ξ H.324 per la rete PSTN
ξ H.320 per la rete N-ISDN
ξ H.321 e H.310 per la rete B-ISDN
ξ H.322 per reti LAN che forniscono qualità di servizio garantita.
In questo ambito sono stati definiti metodi di codifica del segnale video ( H.26X), del segnale audio
(G.7XX) e gli stessi metodi di segnalazione e di controllo (H.221 e H.242 per ISDN e H.223 e H.245
per GSTN). La raccomandazione H.323 viene detta raccomandazione ombrello in quanto, più che
introdurre nuovi protocolli o nuove codifiche, tenta di armonizzare le indicazioni delle precedenti
raccomandazioni della serie H e di prevedere tutta una famiglia di gateway idonei a garantire
l’interoperabilità di queste con le entità di videotelefonia in internet, o comunque con reti o sistemi di
telecomunicazioni di diverso tipo.
15
Ricevi informazioni sui nostri servizi, sulle offerte e non perdere news e consigli su università e lavoro.
