Voce su IP

Introduzione

L'argomento Voce su IP è, sicuramente, uno dei più gettonati dell'intero mondo del networking. Tecnicamente, con questa tecnologia si intende il trasporto di traffico di tipo telefonico (fonia) su una rete in tecnologia IP. Considerando che la tecnologia telefonica è un'invenzione tutt'altro che recente e che la possibilità di effettuare telefonate è ormai di dominio pubblico da oltre un secolo, quali sono i motivi di tutta questa enfasi?

La tecnologia di base

Prima di iniziare la trattazione dell'argomento VoIP, è opportuno fare un breve richiamo alle tecnologie (commutazione di circuito e di pacchetto) che sono alla base rispettivamente della rete telefonica e della rete dati.

Rete telefonica e commutazione di circuito

La rete PSTN (Public Switched Telephony Network) è stata pensata e progettata per il trasporto della voce ed adotta la tecnologia a commutazione di circuito, vale a dire ogni volta che una comunicazione è iniziata, gli switch interni della rete commutano per creare un circuito "fisico" diretto fra la parte chiamante e quella chiamata.

Ciò significa che per tutta la durata della comunicazione, gli interlocutori dispongono di un canale dedicato non accessibile agli altri utenti, indipendentemente dal fatto che le parti siano in conversazione attiva o in silenzio. Si ha, così, un'allocazione statica delle risorse ed ogni circuito garantisce una banda di 64 kbps bidirezionale (full duplex).

La banda costante e il collegamento diretto tra le due parti permettono, al segnale vocale, di avere qualità garantita per tutta la durata della comunicazione, ma al tempo stesso si ha una bassa percentuale di utilizzazione della rete; in altre parole non si trae vantaggio dal fenomeno del multiplexing statistico. Infatti, durante una comunicazione vocale, un interlocutore passa più della metà del tempo in silenzio, in quanto i due interlocutori non parlano contemporaneamente: quando uno parla l'altro (normalmente) resta in silenzio; inoltre anche tra una parola e l'altra ci sono degli istanti di silenzio. I 64 kbps (full-duplex) allocati sono, perciò, usati per meno della metà del periodo della conversazione e la banda libera rimane inutilizzata. Il costo di una chiamata tramite PSTN è basato sulle risorse riservate, dunque in base al tempo d'utilizzo e alla lunghezza del collegamento e non in base alle risorse effettivamente impiegate.

Un altro limite della rete telefonica è l'utilizzo di un codec standard e predeterminato a priori, il PCM64. Questo fattore è 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 telefonica classica può essere migliorata, ed è proprio su questi punto che andrà a puntare la tecnologia VoIP.

La rete dati e la commutazione di pacchetto

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 una linea di collegamento (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 nellpambito degli operatori telefonici quali X.25, Frame Rekapy 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.

La visione "consumer" della Voce su IP

Probabilmente, la prima volta in cui il termine VoIP è arrivato al grande pubblico è stato quando, nel 1995, la Vocaltec ha rilasciato la prima versione dell'applicazione "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 altro 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 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.

La visione "professionale" della Voce su IP

Il sentore comune tra gli operatori del settore era che la visione precedente 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.

Unq 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.

Reti dati multiservizio

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 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, potrebber 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 necessià di poter differenziare, all'interno della rete, il servizio fornito ai pacchetti IP. Banalizzando, un normale tasferimento 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 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. Per rete multiservizio si intente una infrastruttura di rete che è in grado di veicolare su di essa servizi diversi. 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.

Reti VoIP nella visione degli operatori

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).

Uno dei primi prodotti commerciali per realizzare questa infrastruttura è datato agosto 1996, quando la Vocaltec ha rilasciato la prima versione dell'Internet Telephony Gateway, finalizzato ad interfacciare la rete PSTN alla rete IP.

Il processo di creazione di un flusso VoIP

In precedenza 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 questa sezione 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.

La trasmissione di un segnale vocale su rete IP

In questa Sezione si esamineranno le varie fasi intermedie necessarie per la trasmissione di un flusso vocale attraverso una rete IP.

Campionamento

Il processo di campionamento è 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.

Codifica

Spesso la codifica è 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 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).

Codificatori per VoIP

Esistono diversi tipi di codec, caratterizzati da complessità differenti. Nel decidere quale utilizzare all'interno di una rete VoIP, è importante tenere conto di tutte le caratteristiche e, in particolare, dell'occupazione di banda, del ritardo introdotto dalla codifica (e decodifica del segnale) e la qualità della voce riprodotta sul sistema ricevente.

La principale codifica utilizzata per il trasporto della telefonia su linee digitali (come ISDN) è il PCM, descritto nella Raccomandazione ITU-T G.711, che produce un flusso di 64 kbps. Questa codifica è molto semplice e diffusa, per i motivi detti in precedenza, soprattutto tra i carrier.

Per cercare di utilizzare al meglio la banda a disposizione, sono state esaminate a fondo le caratteristiche della voce; il primo passo è quello di sfruttare la forte correlazione presente in una serie di campioni in sequenza: su questo principio si basano i codec ADPCM (Adaptivte Differential PCM). Grazie a questa caratteristica della voce, l'ADPCM invia, dopo un campione completo, una serie di valori differenziali che descrivono i successivi cambiamenti. Normalmente, la tecnica ADPCM è utilizzata alla velocità di 32 kbps, ma può servire per produrre flussi voce anche a 24 e 16 kbps, con un' accettabile perdita di fedeltà; questa categoria di codec, in genere, è descritta dalla Raccomandazione ITU-T G.726.

Un impiego ancora migliore della banda passante è reso possibile dallo sviluppo della codifica Codebook Excited Linear Predictive (CELP), che si basa su un modello matematico della voce umana. Il trasmettitore analizza il flusso del parlato confrontandolo con una serie di modelli e quindi, per ciascun componente della voce, invia un codice corrispondente al modello appropriato, insieme ad alcune informazioni per identificare le variazioni della voce reale rispetto a tale modello. Il ricevitore combina il modello vocale con queste informazioni e sintetizza il flusso del parlato.

Un buon codec CELP può produrre una qualità del tutto analoga a quella di un flusso PCM a 64 kbps, però impiegando 16 kbps. In aggiunta, può utilizzare una banda ancora inferiore, producendo un suono artificiale. I codec CELP di tipo base usati nelle applicazioni VoIP, detti anche Low Delay CELP o LD CELP, sono identificati dalla sigla ITU G.728.

Esistono anche sistemi più complessi come il G.729 (Conjugate Structure Algebraic CELP abbreviato con CS ACELP), che eseguono un'analisi più approfondita del flusso del parlato prima di codificarlo: la qualità che si ottiene è equivalente a LD-CELP impiegando una banda circa dimezzata, ma il ritardo introdotto è doppio.

Lo standard che offre la più elevata compressione, mantenendo una buona qualità della voce, è il DR SCS (Dual Rate Speech Coding Standard) o G.723. Può scendere fino alla velocità di 5,3 kbps e si trova comunemente su sistemi per videoconferenza su linee analogiche.

Stante i limiti sulla scelta dei codec visti in precedenza, questi codificatori molto aggressivi sono utilizzati prevalentemente nel caso di interazione PC-to-PC, dove non sono presenti le limitazioni di cui sopra.

Soppressione dei silenzi

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. 

Cancellazione dell'eco

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.

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.

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.

Problematiche di accodamento

Il fenomeno dell'accodamento 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à.

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.

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.

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)

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.

Tecniche di correzione dell'errore

Alcuni tipi di codifiche vocali prevedono esplicitamente la perdita di pacchetti e quindi il codec si comporta in maniera da ovviare, ove possibile al problema. Esistono molte tecniche utilizzate, anche se sono tutte basate sul principio della ridondanza.

Alcuni codec, ad esempio, prevedono la codifica del campione N con 2 bit rate diversi: il primo, a più alta qualità, è inserito nel pacchetto corrente, mentre il secondo, a qualità (e bit rate) ridotta, è inserito nel pacchetto successivo. Nel caso di perdita del pacchetto corrente è possibile comuque generare un segnale vocale a partire dalla codifica degradata.

Queste tecniche inseriscono però alcune problematiche:

• si ha aumento di banda per portare il campione degradato
• generalmente non coprono il caso di perdite "burst" di pacchetti (ossia quando si perdono più pacchetti consecutivi)
• generalmente richiedono un ritardo più stringente, in quanto è necessario aspettare il pacchetto successivo (che deve, ovviamente, essere arrivato nel tempo prefissato) per poter generare il segnale vocale

Spesso, quindi, queste tecniche non vengono utilizzate in pratica in quanto si sfrutta la capacità di recupero dell'errore propria dell'orecchio umano.

Parametri caratteristici di una sessione vocale

Nel progetto di una rete VoIP è necessario tenere in considerazione i seguenti parametri: banda, percentuale di pacchetti persi, ritardo.

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

• ritardo di trasmissione

• ritardo di de-jitter (e di ordinamento)

• ritardo di decodifica

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.

Perdite

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 paccetti 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.

Il trasporto della voce su IP: il protocollo RTP

Il protocollo RTP (Real Time Protocol), definito nella RFC 1889, riguarda le funzioni al terminale, sorgente e ricevitore per il trasporto di comunicazioni con requisiti di tempo-reale, quali la telefonia o la videoconferenza.

Le funzioni svolte da questo protocollo comprendono la ricostruzione al ricevitore della corretta sequenza dei pacchetti e della loro posizione nella scala dei tempi, consentendo quindi la ricostruzione dei sincronismi. Questo protocollo non permette, nativamente, di sincronizzare più sessioni multimediali tra di loro in quanto ogni sessione RTP è in grado di trasportare un solo flusso. Questo non impedisce, tuttavia, il dialogo tra N soggetti, che è anzi supportato nativamente attraverso lo sfruttamento di un'eventuale tecnologia multicast sulla rete sottostante. Tuttavia in presenza di più sessioni distinte (ad esempio audio e video) è necessario attivare più sessioni RTP.

La sincronizzazione tra sessioni diverse è comunque possibile facendo leva sul timestamp. RTP non fornisce però possibilità evolute quali "quando si arriva al 5o minuto dell'audio, visualizza la slide successiva". Questo genere di sincronizzazioni devono essere fatte dall'applicativo.

RTP gestisce anche un'entità chiamata RTP Mixer. Questa entità agisce come un mixer, appunto, ricevendo le sessioni RTP da più sorgenti e combinandole insieme in un'unica sorgente virtuale, il mixer, appunto. Questo oggetto è utile per diminuire il traffico sulla rete in quanto permette di compattare molte sorgenti in una sola. In questo caso, il pacchetto RTP inserisce gli identificativi delle sorgenti originarie del pacchetto non nel campo SSRC (che è unico) ma nel campo CSRC.

RTP fornisce un mezzo per controllare la trasmissione / ricezione dei dati di tipo real-time, ma non è in alcun modo legato al tipo di codec o al tipo di mezzo fisico (audio o video). RTP è un protocollo di trasporto che garantisce il recapito dei pacchetti e la ricostruzione della corretta sequenza temporale, funzionalità richiesta da qualunque meccanismo di tipo real-time. RTP non specifica però il formato del payload (ad esempio quanti campioni vocali debbano essere trasportati in ogni pacchetto RTP) e si limita a trasportare l'informazione di qual è il payload trasportato, come se fosse un diverso tipo di protocollo.

La specifica delle caratteristiche di pacchettizzazione, dipendenti dal particolare codec utilizzato, sono poste in documenti separati (chiamati audio / video profiles) che definiscono il codice con cui sono identificati in RTP (nel campo PT).

RTP non richiede obbligatoriamente un'infrastruttura IP: può essere potenzialmente trasportato su qualunque rete in quanto non è legato ad un particolare formato degli indirizzi. Richiede, però, che i protocolli di livello inferiore siano in grado di effettuare la frammentazione e il riassemblaggio dei pacchetti trasmessi. Nella maggior parte dei casi RTP si appoggia sui protocolli UDP/IP di cui sfrutta le operazioni di multiplazione e (se opportune) di controllo dell'errore.

La specifica contenuta nella RFC 1889 affianca a RTP il protocollo ausiliario denominato RTCP (RTP Control Protocol) per monitorare la qualità del servizio, per fornire informazione sui partecipanti e per il controllo della sessione. Ogni connessione RTP/RTCP è caratterizzata da una porta UDP, per l'RTP si usa una porta pari, mentre per l'RTCP si usa la porta dispari consecutiva.

A differenza dei principali protocolli di livello applicativo, RTP non riserva alcuna porta particolare all'interno dell'header UDP. Se questo può essere un vantaggio dal punto di vista logistico in quanto permette di decidere la porta a piacere, diventa una grossa limitazione nel momento in cui si voglia privilegiare il flusso RTP all'interno della rete. Infatti, i router intermedi non hanno la possibilità di discriminare il traffico real-time sulla base di una porta nota, complicando notevolmente quindi la possibilità di riconoscimento del flusso multimediale e rendendo difficoltoso, di fatto, il trattamento preferenziale dello stesso.

Un problema analogo avviene nel caso di attraversamento di firewall dove, non essendo disponibili porte note, diventa problematico prevedere su quali porte avverrà il passaggio della sessione real-time. La soluzione proposta da molti costruttori è quella di riservare un certo range di porte per il traffico RTP e configurare gli applicativi ad utilizzare questi valori. Nel caso del firewall non ci sono altre soluzioni; nel caso della differenziazione del traffico in rete è invece possibile agire sul campo Traffic Class del pacchetto IP, forzando diversi valori a seconda che il pacchetto contenga dati oppure traffico real-time.

Il formato dell'header

L'header di un pacchetto RTP è composto da una parte fissa e un'estensione utilizzata per scopi sperimentali, di cui è in genere sconsigliato l'uso quando si possono inserire le informazioni aggiuntive nel payload RTP del pacchetto.

La parte fissa dell'header si articola su 12 byte e contiene i seguenti campi:

• V (Version): indica la versione di RTP utilizzata. La versione contemporanea è la 2.

• P (Padding): se il bit vale uno, il pacchetto contiene almeno un byte addizionale di riempimento non facenti parte del payload, l'ultimo byte di padding contiene il valore di quanti byte padding sono presenti.

• X (extension): se impostato ad uno, indica la presenza di un'estensione dell'header.

• CC (CSRC Count): è il numero di CSRC presenti dopo la parte fissa dell'header.

• M (Marker): l'interpretazione di questo bit è legata al profilo.

• PT (Payload Type): identifica il contenuto del pacchetto, nel profilo è fissata staticamente la corrispondenza tra il codice e il formato del payload.

• Numero di sequenza: è incrementato di uno per ogni pacchetto inviato; può essere utilizzato dal destinatario per accorgersi della perdita di pacchetti e per ricostruire l'ordine corretto della sequenza.

• Timestamp: riflette l'istante di campionamento del primo ottetto dei dati. L'istante di campionamento deve essere derivato da un clock che si incrementa monotonamente e linearmente nel tempo per permettere i controlli di sincronizzazione e le misure dell'incertezza sugli arrivi dei pacchetti (arrival jitter).

• SSRC: identificata la stazione trasmittente.

• CSRC: questo campo è opzionale ed è presente solo se un elemento della rete ha unito in un unico flusso contributi provenienti da diverse sorgenti; al suo interno sono elencati gli SSRC delle singole stazioni.

In ogni sessione la stazione che genera/riceve traffico RTP acquisisce un codice univoco, il SSRC, che permette alla stazione stessa di essere univocamente identificata all'interno della sessione real-time in esame.

Modello di una rete per VoIP

Prima di addentrarsi nelle varie soluzioni tecnologiche per la VoIP, è opportuno introdurre un modello concettuale, di validità generale, per la gestione di una rete VoIP, e orientato in particolar modo alla visione "professionale" della VoIP.

Gateway tra la rete telefonica e la rete IP

L'interfacciamento tra una rete di tipo telefonico e una rete IP è resa possibile da un oggetto apposito, chiamato genericamente Gateway. Logicamente, questo oggetto può essere scomposto nei seguenti componenti:

• Media Gateway
• Signaling Gateway
• Gateway Controller

Le Sezioni seguenti presenteranno le caratteristiche di ognuno di questi componenti.

Media Gateway

Questo oggetto si occupa della traduzione dei dati della sessione VoIP tra la rete telefonica e la rete IP. In altre parole si occupa della eventuale codifica dei dati, della loro pacchettizzazione, eventualmente della soppressione dell'eco, oppure delle operazioni inverse nel momento in cui si voglia interfacciare una rete IP ad una rete telefonica. Si ricordi infatti che, spesso, la rete IP è utilizzata in sostituzione del backbone telefonico, ma la periferia della rete (e quindi la sorgente e la destinazione della telefonata) sono ancora in tecnologia classica.

In alcuni casi ad esempio quando una delle parti è un terminale intelligente quale in PC, parte di queste funzionalità possono essere inserite nell'end-system.

Signaling Gateway

Questo componente si occupa dell'interfacciamento tra reti IP e telefoniche dal punto di vista della segnalazione. La più comune procedura di segnalazione è il cosiddetto "call setup", ossia quella procedura di preparazione della rete affinchè la telefonata sia possibile e che inizia con la composizione del numero sul terminale chiamante e termina quando il chiamante risponde alla comunicazione. Questo compito, molto semplice concettualmente, è in realtà abbastanza complicato a causa della notevole complessità della segnalazione sulla rete telefonica.

Le operazioni di segnalazione sono, in realtà molte: la composizione del numero del chiamato, l'operazione di sgancio/aggiancio della cornetta, l'attivazione di un tono di chiamata (lo "squillo" del telefono), la generazione del tono di libero/occupato a seconda che la chiamata sia andata o meno a buon fine, etc. A queste operazioni di base si aggiungono tutte le procedure di segnalazione proprie della rete intelligente (richiamata su occupato, conversazione a tre, identificativo del chiamante, e altro) che devono essere gestite anche dalla rete telefonica.

Da questo elenco di funzionalità si può dedurre come Signaling e Media Gateway non possano essere entità completamente distinte. In altre parole, non è possibile pensare il Signaling Gateway come il risponsabile della connessione di controllo e il Media Gateway come il responsabile della connessione dati (audio). Ad esempio, la generazione del tono di libero corrisponde alla generazione di una serie di pacchetti audio con determinate caratteristiche, ossia è un segnale che viene portato all'orecchio dell'utente e che vengono riconosciuti come "dati", non "controllo".

Gateway Controller

Il controller si occupa della supervisione e del monitoraggio dell'intero gateway; le principali operazioni svolte sono:

• tenere sotto controllo l'ammontare del traffico (ad esempio, la percentuale di traffico vocale su un canale IP potrebbe non dover superare una certa soglia rispetto all'intera banda disponibile, pena il degradamento della qualità della telefonata)
• controllare se l'utente ha l'autorizzazione a fare / ricevere una certa chiamata
• controllare le generalità dell'utente (ad esempio per aver la possibilità di addebitare, ad ogni utente, una somma pari al numero di telefonate effettuate)

Gateway in reti omogenee

L'impiego di un gateway, contrariamente a quanto si potrebbe pensare, non è limitato all'interfacciamento tra la rete IP e la rete telefonica. Infatti, esistono tutta una serie di operazioni che, anche su una rete con tecnologia omogenea (ad esempio una rete completamente VoIP, compresi gli apparati terminali), devono comunque essere portate a termine e che non possono (o non devono) essere incluse nelle capacità del terminale utente.

Un esempio per tutti è l'autenticazione del chiamante. Nel caso di una telefonata classica, il chiamante è univocamente determinato dal doppino (ossia da un cavo fisico) che arriva nella centrale. Essendoci una corrisponden