CENTRALINI DI NUOVA GENERAZIONE COMPATIBILI CON IL PRESENTE NATI PER IL FUTURO VOCE SU IP

Transcript

1 VOCE SU IP

2 Introduzione CENTRALINI DI NUOVA GENERAZIONE VOCE SU IP 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.

3 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

4 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

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

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

7 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

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

9 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

10 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, dejitter 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.

11 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

12 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,

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

14 Modello di una rete per VoIP CENTRALINI DI NUOVA GENERAZIONE 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.

15 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 corrispondenza biunivoca tra i cavi entranti in una centrale telefonica e gli abbonati da essa servita, il controllo è molto semplice e la telefonata verrà addebitata senza problemi alla persona giusta. Si pensi ora alla stessa situazione in ambito IP e si immagini un'azienda, con la comunissima infrastruttura di rete locale Ethernet, che dota tutti i suoi dipendenti di un telefono IP. Ora, come è possibile impedire ad un utente illegale di collegare il suo telefono IP alla LAN aziendale, per mezzo (magari) di un hub? E' chiaro come, nel caso VoIP, l'autenticazione dell'utente diventa più problematica rispetto alla tecnologia classica. Non solo, ma questo genere di operazioni devono essere fatte da macchine sotto il controllo del gestore della rete: queste funzioni non possono, ovviamente, essere annegate all'interno del terminale utente, contrariamente invece a quanto può essere fatto per la codifica/decodifica della voce (il compito del Media Gateway). L'esempio precedente illustra solo una delle funzioni che, per varie ragioni, non devono essere delegate all'utente. Una seconda ragione particolarmente importante risiede nella complicazione della segnalazione necessaria a poter effettuare la chiamata all'interno della rete (prenotazione di risorse, etc). Analogamente al modello utilizzato nel trasferimento dati classico (il principio dell'instradamento indiretto, o esplicito, del protocollo IP), il terminale utente dovrebbe preoccuparsi di gestire gli applicativi, ma non di capire come inoltrare i pacchetti verso la destinazione finale della comunicazione: questo è il compito di un altro apparato, il default router o gateway, appunto. Per lo stesso principio, quindi, diventa conveniente far sì che il terminale utente abbia una serie limitata di funzioni (sostanzialmente quelle relative al media gateway) e che per altre funzioni più complesse (ad esempio alcune problematiche di segnalazione, il routing) oppure non di sua pertinenza (l'autenticazione) ci si rivolga ad un oggetto ad hoc che, per comodità, si indica ancora come Gateway. Questo non avrà tutte le funzioni descritte nelle Sezioni precedenti ma solo un sottoinsieme, ossia quelle che non sono state trasferite al terminale utente. Le architetture di rete Esistono più modelli architetturali per la realizzazione di una rete VoIP. Le seguenti sezioni illustreranno i vari scenari di migrazione, dando per scontato la progressiva affermazione della tecnologia VoIP sulla tecnologia telefonica. Rete IP come backbone Il primo modello, attualmente quello più in uso presso i grossi gestori telefonici, prevede il mantenimento della periferia della rete (edge) in tecnologia telefonica, mentre il backbone viene convertito in tecnologia IP. Il dialogo tra queste due entità viene fatto attraverso un gateway; una normale telefonata dovrà quindi essere convertita due volte, a meno che il chiamato risieda nella stessa area servita dalla rete telefonica di accesso del chiamante. Questo modello segue, nel deployment della nuova tecnologia, lo stesso modello adottato a suo tempo per la trasformazione della rete telefonica da analogica a digitale. La prima zona interessata dall'aggiornamento fu il backbone in quanto questo richiedeva la sostituzione di un numero limitato di apparati: ad esempio, le centrali telefoniche di transito sono qualche decina su tutto un territorio nazionale. Con l'affermarsi della tecnologia, la digitalizzazione (e quindi la VoIP) si è diffusa fino alla periferia fino a giungere, con l'intruduzione dei terminali ISDN, ad una completa digitalizzazione della rete, terminale utente compreso. Rete mista Il secondo modello è attualmente adottato da alcuni gestori telefonici alternativi i quali, non dispondendo di una preesistente infrastruttura di tipo telefonico, hanno deciso l'adozione della tecnologia VoIP fino alla periferia. Un'altra situazione nella quale si trova un'infrastruttura di questo tipo è nel caso di un'azienda con una nuova sede, dove si opta per un'unica infrastruttura di rete IP sia per il traffico dati che per il traffico telefonico. E' interessante notare come una rete VoIP moderna non prevede normalmente l'utilizzo di PC come terminali utente di tipo telefonico, in quanto l'utente si trova maggiormente a suo agio con un terminale di sembianze "tradizionali". I nuovi telefoni IP sono pertanto degli oggetti con una forma simile a quella a cui si è abituati, ma con un display multifunzione nel quale sono disponibili una serie di opzioni prima impossibili: la rubrica, alcune pagine web di consultazione, e altro a discrezione del fornitore dell'azienda. Nel caso di una classica postazione di lavoro saranno pertanto disponibili sia un PC, che un telefono, ambedue collegati alla rete aziendale in tecnologia IP. E' tuttavia impensabile, allo stato attuale, la creazione di una rete globale IP. Saranno pertanto presenti dei punti di interconnessione tra la rete telefonica (ad esempio quella dei gestori tradizionali) e la rete IP. Nel caso dell'azienda citata in precedenza, vi saà un apparato (ad esempio il gateway telefonico) che, da un lato, gestirà la rete aziendale

16 in tecnologia IP, mentre dall'altro curerà interfacciamento con la rete telefonica, utilizzata per le telefonate che hanno come destinazione utenti esterni. In questa rete è presente un esempio di utilizzo di Gateway anche nel caso della rete IP: i terminali VoIP si appoggeranno ad esso per una serie di funzioni non previste all'interno dell'apparato, come si è visto nella sezione Gateway in reti omogenee. Rete IP Il passo successivo è sicuramente la trasformazione di tutti i terminali utente in tecnologia IP. La rete adotta quindi una tecnologia omogenea. Tuttavia esiste ancora un problema, ossia la notevole mole di servizi di rete intelligente che sono disponibili nella rete telefonica. per questi servizi, che si appoggiano a grossi server e a grosse basi dati), la migrazione alla tecnologia IP può non essere un'operazione semplice ed indolore. E' quindi pensabile che, almeno in un certo lasso di tempo, questi servizi richiedano ancora un'interfaccia di tipo telefonico almeno per la segnalazione. Questo scenario prevede quindi che per permettere le funzioni di rete intelligente sia ancora necessario un gateway tra la rete e i fornitori di questi servizi. L'ultimo passo è, ovviamente, la completa trasformazione della rete in tecnologia IP, dove con rete si intendono sia i terminali utente (e di conseguenza anche il trasporto), sia i servizi della rete intelligente.

17 Protocolli di segnalazione La segnalazione per la telefonia su reti IP deve soddisfare ai seguenti requisiti: indirizzamento: deve essere in grado di localizzare il corretto apparato di terminazione della telefonata; questo non è un compito banale in quanto con l'integrazione delle tecnologie è possibile pensare che la telefonata possa essere diretta ad un terminale di rete fissa, ad un terminale mobile, alla segreteria, alla casella di posta elettronica (o altro ancora) a seconda delle preferenze (ad esempio in base all'ora di chiamata) dell'utente trasporto dei dati: deve essere in grado di trasportare il segnale vocale dalla sorgente alla destinazione con qualità accettabile sicurezza: il contenuto della telefonata non deve essere intercettato; essendo le reti IP molto più aperte rispetto alle reti telefoniche (si pensi alla possibilità di sniffare su una LAN), la tecnologia deve garantire una certa riservatezza della comunicazione supporto dei servizi di rete intelligente: è sempre difficile convincere un utente che, a causa di un aggiornamento tecnologico, non è più supportato un servizio prima disponibile. Di conseguenza, è necessario prevedere, sulla rete VoIP, il supporto almeno al medesimo set di servizi prima disponibili semplicità e trasparenza: non deve appesantire inutilmente la rete e deve essere trasparente a livello utente. La segnalazione è principalmente divisa in due architetture distinte, che però possono coesistere ma non cooperare (allo stato attuale): lo standard H.323, proposto dall'itu (International Telecommunication Union) per sistemi di comunicazione multimediali a pacchetto, e la proposta SIP (Session Initiation Protocol), definita in ambito Internet (IETF) e descritta nell'rfc Allo stato attuale, la suite di protocolli H.323 è l'unica soluzione standard adottata dai produttori di dispositivi per telefonia su IP e in generale per applicazioni multimediali, ed è supportata sia da applicativi PC (ad esempio il Netmeeting di Microsoft), che da dispositivi di rete (router) e da terminali utenti (IP Phone). La proposta SIP, però, sta incontrando sempre maggiore favore a causa della sia ottima integrazione con gli altri protocolli della suite TCP/IP (mentre H.323 nasce per una generica rete a pacchetto) e della sua maggiore semplicità, sia dal punto di vista del protocollo in sè, sia delle specifiche. Infatti, H.323 nasce in ambito telefonico dove le specifiche sono estremamente precise e complete ma anche estremamente complicate; inoltre ingloba, al suo interno, altri componenti precedentemente definiti dall'itu, cosa che ne aumentano notevolmente la complessità. Nonostante il notevole supporto di H.323, quindi, il mondo si sta orientando maggiormente verso SIP per tutte le nuove installazioni. La suite H.323 La raccomandazione H.323 descrive i requisiti tecnici per le comunicazioni multimediali basate su reti a commutazione di pacchetto che non prevedono qualità del servizio, con particolare riferimento alle reti IP. Lo standard è stato originariamente pensato per operare su LAN, ma è stato successivamente adattato anche per l'utilizzo in ambienti WAN. Le entità H.323 forniscono comunicazioni in tempo reale di tipo audio, video e dati. Il supporto dell'audio è obbligatorio, mentre dati e video sono opzionali. Componenti della specifica H.323 La specifica H.323 prevede l'esistenza di quattro oggetti fondamentali: Terminale: dispitivo di interfacciamento con gli utenti e può essere un PC o un apparecchio telefonico; può anche essere un dispositivo che fornisce l'interfacciamento verso un telefono analogico tradizionale Gateway: è l'elemento necessario per fornire la connettività tra reti di tipo diverso. H.323 prevede la possibilità di interconnettere più tipi di rete: la rete IP, la rete telefonica tradizionale (GSTN, General Switched Telephone Network), la trete ISDN, etc. I gateway si occupano di procedere alla traduzione sia dei protocolli di segnalazione che del flusso dati. Gatekeeper: è l'entità principale della segnalazione H.323. Non sono obbligatori, ma forniscono la maggior parte dei servizi: la traduzione degli indirizzi (E.164, alias H.323 e indirizzi IP), instradamento, accounting, autorizzazione e autentificazione dei terminali e dei gateway, il controllo della banda. Multipoint Control Unit (MCU): gestisce le connessioni multipunto per le conferenze di tre o più terminali.

18 Multipoint Control Unit La Multipoint Control Unit è, secondo le specifiche, l'insieme di due componenti logicamente distinti: Multipoint Controller (MC): componente obbligatorio il cui compito comprende la negoziazione delle capacità minime tra tutti i terminali, in modo da poter assicurare un livello minimo di comunicazione; inoltre può tenere sotto controllo le risorse impiegate nel caso di una comunicazione multicast Multipoint Processor (MP): componente facoltativo il cui compito è quello di procedere ad un eventuale adattamento del flusso dati in modo da poter fornire un servizio accettabile per tutti. Tra le funzionalità ammesse in questo oggetto vi è la possibilità di mixing / switching dei flussi video, voce e dati, sotto la supervisione di un MC. La MCU può trovare impiego nei seguenti scenari: conferenza tra tre o più persone, in modalità unicast. In questo scenario, la MCU comunicherà con i vari client in modalità punto-punto conferenza tra tre o più persone, in modalità mista unicast / multicast: in questo caso, la MCU diventa l'interfaccia tra i terminali unicast e multicast; accetterà quindi i flussi unicast, distribuendoli (con la stessa modalità) agli altri utenti unicast e traducendoli in multicast per il resto della rete; farà operazioni analoghe alla ricezione di un flusso multicast. La MCU, come oggetto distinto all'interno della rete, perde ovviamente di significato nel momento in cui tutti i partecipanti utilizzino comunicazioni multicast. Zone Alla base della gestione è definita la zona come l'insieme di elementi H.323 (gateway, terminali e MCU) amministrati da uno e solo un gatekeeper. In una zona devono esistere un solo gatekeeper (non è prevista quindi la ridondanza) e almeno un terminale. Il concetto di zona è completamente indipendente dalla rete sottostante: può essere semplicemente una LAN oppure una topologia più complessa. Formato dei messaggi H.323, come tutta una serie di protocolli ITU, utilizza una codifica di messaggi basata su ASN.1 Questa codifica è tuttavia estremamente complessa da gestire ed è una delle critiche a cui è attualmente sottoposto SIP. Tale codifica, infatti, ha la caratteristica di inglobare tutta una serie di operazioni (quali ad esempio la gestione del byte ordering, e altro) che, nelle reti IP, devono essere fatte manualmente. Il prezzo da pagare per tutto questo è, appunto, una complicazione maggiore in fase di scrittura e, soprattutto, in fase di debugging per verificare la causa di un problema. Architettura di H.323 I protocolli che fanno parte dello standard H.323 si dividono in due categorie secondo il protocollo di trasporto sul quale si appoggiano: Protocolli che si appoggiano su un canale connesso e quindi sicuro quale TCP: H.225 Q.931 costituisce il protocollo per l'instaurazione e l'abbattimento di una chiamata attraverso le fasi di set-up, connect e release. H.245 è il mezzo di comunicazione per lo scambio di parametri utili per lo svolgimento della chiamata, come ad esempio le informazioni sui media utilizzati. Protocolli che si appoggiano su un canale non connesso e quindi inaffidabile come UDP RTP fornisce le funzionalità di trasporto end-to-end per applicazioni multimediali in tempo reale. RTCP il canale di controllo di RTP utile per monitorare la sessione, la qualità del servizio e l'identità dei partecipanti. H.225 RAS Registration Admission and Status protocol fornisce il canale di comunicazione con il gatekeeper. Architettura di un terminale H.323 Tutti i terminali H.323 devono possedere un sistema di controllo, un livello H.225, un'interfaccia di rete e un'unità di codifica audio. Componenti non coperti dalle specifiche La raccomandazione H.323 non specifica le caratteristiche dei seguenti componenti:

19 Dispositivi audio: sovrintendono alla cattura e alla riproduzione di flussi audio Dispositivi video: sovrintendono alla cattura e allla riproduzione di flussi video Dispositivi dati: sovrintendono all'interazione di applicazioni dati (ad esempio la lavagna condivisa) attraverso i protocollo H.323Interfacce utente: sovrintende alla visualizzazione dei flussi audio, video e dati Interfacce rete: è il componente che gestisce l'interfaccia con la rete, per la trasmissione e ricezione di pacchetti IP Interfaccia utente di controllo: sovrintende all'interazione tra l'utente e l'applicativo per la gestione delle informazioni di controlo (apertura / abbattimento chiamate, etc) E' però evidente come questi componenti debbano essere presenti (tranne nel caso del dispositivo video e di quello dati, che sono opzionali) affinchè il terminale possa operare. Quindi, anche se non vengono coperti dalle specifiche, devono obbligatoriamente essere presenti. Audio e video codec Per quanto riguarda le specifiche audio, vengono previste le cinque codifiche maggiori (G.711, G.722, G.723, G.728, G.729), di cui la prima obbligatoria mentre le altre facoltative. Per quanto riguarda le specifiche video, il terminale, se vuole instaurare una comunicazione video, deve essere capace di codificare e decodificare le immagini secondo le specifiche H.261 o H.263. I flussi audio e video sono imbustati in pacchetti RTP e gestiti da coppie di socket UDP, secondo il normale modo operativo di questo protocollo. Receive Path Delay L'audio e il video codec è integrato da un blocco Receive Path Delay, il cui compito è quello di blocco de-jitter in modo da consentire sia l'ottenimento di un flusso regolare, che la sincronizzazione tra i vari flussi della stessa sessione. Livello H.225 Mentre i canali logici di tipo video, audio, dati e controllo sono instaurati in accordo con le procedure specificate nella raccomandazione H.245, il livello H.225 realizza la formattazione dei canali logici. In altre parole, è il responsabile della gestione della trasmissione / ricezione dei pacchetti, creando un canale di comunicazione tra le due parti (terminale - terminale, ad esempio), e ricavando al suo interno una serie di canali logici per le varie esigenze (canali di controllo, etc). Ad ogni canale viene associato un numero di canale logico (LCN-Logical channel Number) arbitrario tra 0 e e una massima larghezza di banda in base alle caratteristiche del trasmettitore e del ricevitore; il canale '0' è però riservato al canale di controllo H.245. In aggiunta, esso esegue la numerazione in sequenza, la rivelazione e la correzione degli errori per ogni mezzo trasmissivo. Controllore RAS Il controllore RAS utilizza i messaggi H.225 per effettuare la registrazione, l'ammissione, i cambiamenti di larghezza di banda, i controlli di status e le procedure di sgancio tra endpoint e Gatekeeper. Il canale RAS è indipendente da quelli di segnalazione chiamate e controllo H.245 e viene aperto tra un endpoint ed un gatekeeper prima di qualsiasi altro canale. E' direttamente correlato al gatekeeper; nel caso in cui questo componente non sia presente (ad esempio in una comunicazione diretta terminale - terminale) non vi sarà neppure il canale RAS. Controllore chiamate Il controllore delle chiamate utilizza la segnalazione H.225 per stabilire una connessione tra due endpoint H.323. Il canale di segnalazione chiamate viene attivato dopo il canale RAS e prima di qualsiasi altro canale tra un endpoint ed un gatekeeper o tra due endpoint se non è presente il gatekeeper. Controllore H.245 Il controllore H.245 usa un canale logico di controllo per la gestione end-to-end dei messaggi che governano le operazioni delle entità H.323, incluso capacità di scambio, apertura e chiusura dei canali logici, richiesta di modi operativi, controllo di flusso, comandi e indicazioni generali. La segnalazione H.245 viene stabilita tra due endpoint o tra endpoint e gatekeeper; per ogni chiamata a cui l'endpoint partecipa deve essere presente un canale di controllo H.245. I terminali che supportano più chiamate contemporanee (gateway, gatekeeper, MCU) devono aprire più canali di controllo.

20 Il canale di controllo H.245 si considera permanentemente attivo per tutta la durata della chiamata. Vi sono due modalità con cui questo canale può essere gestito: come canale distinto come canale logico 0 all'interno dei canali logici gestiti da H.225 (tunneling). Le procedure di apertura e chiusura del canale logico non riguardano il controllore H.245. La raccomandazione H.245 specifica diverse entità di protocollo indipendenti che supportano la segnalazione endto-end. Ogni entità di protocollo è caratterizzata da una sintassi, da una semantica e da un insieme di procedure che specificano lo scambio di messaggi e l'interazione con l'utente. Queste entità di protocollo sono: Determinazione di Master Slave Capacità di scambio Segnalazione del Canale Logico Segnalazione bidirezionale del Canale Logico Richiesta del modo operativo Determinazione del Round Trip Delay Mantenimento della segnalazione di loop Gateway Un gateway possiede le caratteristiche di un terminale H.323 sulla rete dati e le caratteristiche di un terminale telefonico tradizionale su rete a commutazione di circuito; in altre parole, riflettere le caratteristiche di un endpoint di rete dati ad uno della rete telefonica e viceversa in modo trasparente. Il compito del gateway è infatti di provvedere all'appropriata traduzione di formati di trasmissione (es. da G.729 in RTP a G.711 in un canale B ISDN), dei canali di controllo (es. da H.225 a H.221 e viceversa) e delle procedure di segnalazione (es. da H.245 a H.242 e viceversa). Tale sistema di traduzione è specificato dalla raccomandazione H.246. Un gateway, inoltre effettua il setup di una chiamata e la successiva disconnessione sia dal lato rete IP che rete telefonica. I principali ambiti di impiego di un gateway sono i seguenti: Interfaccia tra due reti in tecnologie differenti (ad esempio IP e PSTN): sicuramente l'ambito di impiego più utilizzato Meccanismo di "adattamento" tra due reti IP: ad esempio nel caso in cui si debba passare per una rete con basse capacità dei link, nel qual caso è conveniente inserire un gateway con il solo compito di compressione del flusso audio/video 8ad esempio da G.711 a G.729 per l'audio) Sistema di backup di una rete IP su rete telefonica: è possibile connettere due gateway attraverso una rete a commutazione di circuito per consentire, ad esempio, la comunicazione tra i due terminali H.323 anche in caso di guasto della rete IP nativa. Un endpoint H.323 può comunicare con un altro dello stesso tipo senza invocare l'uso del gateway, il quale può essere omesso se non s'intende effettuare comunicazioni con apparati su rete telefonica tradizionale. Gatekeeper Il gatekeeper è l'intelligenza della rete H.323, in quanto gestisce una "zona" di terminali e fornisce agli endpoint H.323 un meccanismo di controllo delle chiamate. Un gatekeeper è logicamente separato da un endpoint, ma la sua implementazione fisica può coesistere con un terminale, un gateway o con altri apparati di rete non-h.323. In un sistema possono essere presenti più gatekeeper che comunicano tra loro, devono però necessariamente lavorare in zone H.323 diverse. Il gatekeeper deve provvedere alle funzioni seguenti: Traduzione degli indirizzi, da indirizzo alias H.323 a indirizzo a livello di trasporto Controllo d'ammissione alla rete, attraverso l'uso di messaggi RAS Controllo di larghezza di banda Gestione delle zone H.323 Il Gatekeeper può in aggiunta provvedere alle seguenti funzioni opzionali: Autorizzazione delle chiamate, ovvero la possibilità di non accettare una chiamata in base a diversi fattori quali origine, orari, politiche di amministrazione Gestione della banda, per esempio limitando il numero di terminali H.323 presenti contemporaneamente sulla rete Gestione chiamate, per esempio mantenendo una lista dei terminali H.323 con una chiamata in corso per