Capitolo 1. Voce su IP: i concetti fondamentali

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Capitolo 1. Voce su IP: i concetti fondamentali"

Transcript

1 Voce su IP Page 1 Capitolo 1. Voce su IP: i concetti fondamentali 1.1. 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. Tuttavia, questo corrisponde ad avere una bassa percentuale di utilizzazione della rete e quindi 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

2 Voce su IP Page 2 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),

3 Voce su IP Page 3 quindi la gestione più efficiente della banda. Inoltre, non avendo il limite dei 64kbps permette anche il trasporto di traffico con bitrate più elevati, ad esempio per il trasporto di voce con qualità superiore. Il costo di una "chiamata" in tecnologia dati è quindi normalmente determinato dalla quantità di dati che passano, indipendentemente dalla durata della comunicazione. Infine, la rete IP non ha il call setup, rendendo la gestione della chiamata decisamente meno onerosa. Tuttavia questa scelta impone dei vincoli non indifferenti per la gestione della qualità del servizio spettante alla singola chiamata: questo è il motivo per cui altre tecnologie di reti dati (prime fra tutte quelle che sono state definite nell'ambito degli operatori telefonici quali X.25, Frame Relay e ATM) mantengono il concetto di call-setup. Come si vedrà in seguito, uno dei problemi principali della rete IP è proprio la fornitura di determinate garanzie di qualità alla telefonata Le differenti visioni della Voce su IP Della tecnologia Voce su IP si fa un gran parlare, ma non tutti sottintendono la stessa visione del servizio che può essere offerto all'utente finale. Mentre la tecnologia di base è la stessa, gruppi di utenti diversi ne immaginano scenari di utilizzo differenti. In particolare, è possibile evidenziare come esistano tre possibili bacini di utenza della tecnologia VoIP: l'utente domestico (visione "consumer") l'operatore telefonico (visione "telecom") l'utente aziendale (visione "enterprise") 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

4 Voce su IP Page 4 macchina remota (ad esempio per risolvere problemi di configurazione), funzionalità molto comoda in determinate occasioni. I benefici della tecnologia VoIP "adattata" ad una visione consumer sono principalmente il costo ridotto della chiamata e la possibilità di utilizzo di nuove applicazioni non disponibili con la tecnologia telefonica classica. D'altro canto, questa visione può essere decisamente limitante. Infatti, una visione della VoIP che richiede necessariamente la presenza di un personal computer per poter operare presenta 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). Pertanto, è difficile rimpiazzare il servizio fornito dai telefoni cellulari in quanto richiederebbe che i PC si possano spostare con l'utente e siano sempre collegati alla rete IP Il problema fondamentale di questa visione è pertanto il fatto che vi sia un nesso obbligatorio tra la disponibilità di un PC e la possibilità di attivare la tecnologia VoIP La visione "telecom" della Voce su IP: Telephony over IP Nella visione degli operatori telefonici, la visione "consumer" della VoIP è riduttiva dal momento che la quantità di Personal Computer presenti nel mondo (e il numero di utilizzatori capaci ad adoperarli) è decisamente inferiore al numero di telefoni. Nella visione degli operatori telefonici si tende pertanto a non considerare il PC come uno strumento abilitante alla tecnologia VoIP, sostituendolo con il classico terminale telefonico. Non si parla più di VoIP, ma si preferisce il termine Telephony over IP (ToIP) per indicare il trasporto di telefonate attraverso una infrastruttura di rete in tecnologia IP. La tecnologia ToIP è un sovrinsieme della tecnologia VoIP. Con il termine VoIP si indica infatti un insieme di tecnologie per il trasporto di campioni vocali su una rete IP e le necessarie tecnologie di segnalazione necessarie ad effettuare la chiamata tra due entità con tecnologia VoIP. Con il termine ToIP si intende invece quell'insieme di tecnologie che permettono il trasporto di telefonate su una rete IP. Questo comprende quindi non solo le tecnologie precedenti (VoIP) per quanto riguarda il mondo IP, ma anche una serie di tecnologie "legacy" per permettere al mondo telefonico di interfacciarsi con il mondo IP. Ad esempio, è necessario prevedere un modo per trasportare la segnalazione SS#7 (ad esempio generate da due centrali telefoniche tradizionali, ora interconnesse da una rete IP) sulla rete IP,

5 Voce su IP Page 5 prevedere un meccanismo di conversione della segnalazione SS#7 nella corrispondente segnalazione prevista dalle tecnologie VoIP (ad esempio per interfacciare una centrale telefonica "legacy" con una in tecnologia completamente IP), prevedere l'implementazione dei servizi di rete intelligente sia a livello di segnalazione, sia a livello di apparati (server) dedicati a tali servizi, e così via. Questo implica una serie di conseguenze: anche un telefono tradizionale può usufruire di una infrastruttura VoIP, fatto salvo che esista un gateway (traduttore) che trasforni i segnali vocali tradozionali in pacchetto VoIP la tecnologia VoIP può affermarsi senza la necessità di dover cambiare i terminali alla periferia della rete (operazione notoriamente onerosa in termini economici e di tempo impiegato) il luogo più adatto per l'adozione della VoIP è sicuramente il backbone della rete telefonica, dal momento che è necessario cambiare solamente l'interfaccia delle centrali telefoniche verso il backbone e abilitandole alla trasmissione di pacchetti IP. Una visione di questo tipo ha, ovviamente, anche alcuni aspetti negativi. Il primo fra tutti è che il servizio telefonico fornito all'utente finale non si avvantaggia di nessun miglioramento con il passaggio del backbone telefonico in tecnologia VoIP. In altre parole, il passaggio da una telefonata in tecnologia classica ad una in tecnologia VoIP non inserisce nessuna novità nel modo con cui l'utente finale percepisce il servizio. Questo implica che la visione "telecom" 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 e principalmente nella prospettiva di una maggior economicità di gestione dell'infrastruttura ToIP: le ragioni della scelta 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.

6 Voce su IP Page 6 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?

7 Voce su IP Page 7 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: mentre 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 Esempio di rete ToIP 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 La visione "enterprise" della Voce su IP

8 Voce su IP Page 8 La visione che una azienda ha della tecnologia VoIP è normalmente più avanzata rispetto alle visioni precedenti, che vengono fuse ed armonizzate insieme. Si mantiene pertanto la centralità del telefono tradizionale, ma si riconosce che l'adozione di questa tecnologia non porta gli sperati vantaggi se non viene unita ad altre tecnologie proprie del mondo dei Personal Computer. La visione enterprise della VoIP si focalizza pertanto sul fornire all'utente un servizio migliore, che viene tradotto in due linee portanti: la personalizzazione del servizio telefonico e la possibilità di integrare servizi innovativi tipici di un PC. Per quanto riguarda la personalizzazione del servizio telefonico, i sistemi VoIP offrono normalmente all'utente un'interfaccia web tramile la quale è possibile variare dinamicamente parametri quali l'inotro delle chiamate (ad esempio, al mattino le chiamate telefoniche vengono terminate sul telefono VoIP dell'ufficio, al pomeriggio sul telefono cellulare, alla sera sul numero di casa) anche in base a differenti parametri (giorno/ora di ricevimento della chiamata, identità del chiamante, etc), la visualizzazione del traffico effettuato, le chiamate perse, etc. Per quanto riguarda l'ntegrazione di servizi innovativi, sono sicuramente importanti le videochiamate, la condivisione di applicazioni, il trasferimento di files, ma probabilmente l'applicativo più importante è l'integrazione con sistemi di e-presence. Questi sistemi (spesso conosciuti come "instant messaging", dalla loro funzione principale) permettono di mantenere una lista di contatti e visualizzare, in ogni momento, lo stato del contatto stesso (online, online ma occupato, impegnato in una riunione, etc). Questo permette di conoscere immediatamente la disponibilità o meno di una persona. Alla bisogna, l'utente può decidere di inviare un breve messaggio di testo (l'instant message, appunto) oppure attivare una chiamata telefonica, o altro ancora. Questi motivi fanno sì che nell'ambito enterprise vi sia una visione più ampia della tecnologia VoIP e che la motivazione relativa al risparmio economico, tipico della visione degli operatori telefonici, non sia particolarmente importante. Infatti, anche se spesso l'adozione della tecnologia VoIP porta ad un leggero risparmio economico (soprattutto su edifici nuovi grazie all'unificazione del cablaggio e degli apparati attivi), sono i nuovi servizi a fare la differenza. Questo non esclude l'utilizzo di tecnologie VoIP per abbattere i costi telefonici (magari tra più sedi della stessa azienda), ma non è il punto fondamentale 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

9 Voce su IP Page 9 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

10 Voce su IP Page 10 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

11 Voce su IP Page 11 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:

12 Voce su IP Page 12 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 millisecondi (10 è un 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.

13 Voce su IP Page 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

14 Voce su IP Page 14 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

15 Voce su IP Page 15 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

16 Voce su IP Page 16 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

17 Voce su IP Page 17 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:

18 Voce su IP Page 18 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 Talker il 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.

19 Voce su IP Page 19 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

20 Voce su IP Page 20 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

21 Voce su IP Page 21 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).

22 Voce su IP Page 22 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

23 Voce su IP Page 23 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

24 Voce su IP Page 24 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 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

25 Voce su IP Page 25 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'introduzione 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 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

26 Voce su IP Page 26 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 Principali 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

27 Voce su IP Page 27 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.

28 Voce su IP Page 28 Capitolo 2. La suite di protocolli H Introduzione La raccomandazione H.323 è orientata alla definizione di uno standard per 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

29 Voce su IP Page 29 La specifica H.323 prevede l'esistenza di quattro oggetti fondamentali: Terminale: dispositivo 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 rete 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 autenticazione 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 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.

30 Voce su IP Page 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 spesso succede nei protocolli definiti dall'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 H.323 nel confronto con 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 nella fase di scrittura degli applicativi H.323 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.

31 Voce su IP Page 31 Protocolli che si appoggiano su un canale non connesso inaffidabile come UDP e quindi 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: 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.323 Interfaccia utente: sovrintende alla visualizzazione dei flussi audio, video e dati Interfaccia di 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.

32 Voce su IP Page 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 denominato Receive Path Delay, il cui compito è quello di de-jitting 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

33 Voce su IP Page 33 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. 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:

34 Voce su IP Page 34 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 end-to-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, riflette 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 (ad 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.

35 Voce su IP Page 35 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 indicare più velocemente che il numero chiamato è occupato 2.4. Indirizzamento L'indirizzamento su una rete H.323 prevede l'impiego di due tipi diversi di indirizzo: la coppia indirizzo di rete / identificatore TSAP, e gli indirizzi alias Indirizzi di rete e identificatori TSAP

36 Voce su IP Page 36 Ogni dispositivo H.323 deve possedere almeno un indirizzo di livello rete (indirizzo IP) che lo identifica unicamente all'interno della rete. Questo indirizzo, però, non è sufficiente per portare a termine la comunicazione: infatti sarà necessario attivare, sulla stessa macchina, delle connessioni di controllo e delle connessioni dati. L'identificazione di queste connessioni viene fatto con gli identificatori TSAP (Transport layer Service Acces Point), che consentono la coesistenza di più canali di comunicazione per lo stesso indirizzo di rete. Gli identificatori TSAP possono essere noti a priori (sostanzialmente, le well known ports del TCP/UDP), oppure negoziati a run-time. Fanno parte della prima categoria quelli per il canale di segnalazione delle chiamate (per tutti i terminali H.323), e quello per il canale RAS nel caso di gatekeeper. Infatti, questi indirizzi vengono utilizzati per l'instaurazione della comunicazione e devono pertanto essere di tipo well-known, pena l'impossibilità, da parte del chiamante, di poter aprire la chiamata. Fanno invece parte della seconda categoria gli identificatori TSAP per i canali di controllo H.245, audio, video e dati. Nel caso della disponibilità di un Gatekeeper, gli identificatori well-known TSAP del terminale possono essere impostati a valori non standard: sarà infatti cura del Gatekeeper, nel caso di una chiamata diretta verso il terminale in esame, ad istruire appropriatamente il chiamante ad usare i TSAP effettivi anzichè quelli standard Indirizzi alias Un endpoint può anche avere uno o più indirizzi alias ad esso associati, rappresentanti l'endpoint stesso, univoci all'interno di una zona H.323. Un alias può essere un indirizzo E.164 (numero di telefono), un identificatore H.323 (es. un indirizzo di o un nickname) o qualsiasi altro indirizzo definito nella raccomandazione H.225. Questi indirizzi hanno il compito di rendere più semplice l'identificazione del terminale utente mediante l'impiego di un nome più conosciuto rispetto all'indirizzo IP. Gli indirizzi alias sono disponibili solamente nel caso in cui la rete preveda un Gatekeeper, il quale, a fronte di una chiamata, si occupa della loro traduzione in indirizzi IP Operazioni H Attivazione del canale RAS e registrazione presso il Gatekeeper

37 Voce su IP Page 37 Il Canale RAS (Registration, Admission and Status) è un canale di comunicazione inaffidabile tra un endpoint e il Gatekeeper. Questo canale, con finalità diverse, viene instaurato da qualunque oggetto H.323, sia esso un terminale utente, un gateway, una MCU, oppure un MC. Infatti, il Gatekeeper agisce come un "controllore" della zona di sua competenza e deve avere il tutto sotto controllo. L'attivazione del canale RAS passa obbligatoriamente per l'individuazione del Gatekeeper con cui aprire la comunicazione. Una volta che il Gatekeeper viene localizzato, il canale RAS viene aperto e, attraverso di esso, viene fatta la registrazione del terminale al Gatekeeper in questione con il conseguente abbinamento degli indirizzi alias all'indirizzo di rete appropriato. I messaggi utilizzati sono quelli definiti nella raccomandazione H Ricerca del Gatekeeper L'assegnazione di un Gatekeeper ad un endpoint può avvenire in modo statico, semplicemente dicendo a quest'ultimo l'indirizzo del Gatekeeper a cui fare riferimento, oppure in modo dinamico (automatico). La ricerca automatica consente un carico di lavoro minore dal punto di vista di amministrazione della rete e permette inoltre di sostituire in qualsiasi momento un Gatekeeper senza dover riconfigurare manualmente tutti i terminali che erano registrati su di esso. La procedura dinamica prevede che un endpoint invii ad un indirizzo di multicast (Discovery Multicast Address, , con porta UDP 1718) un messaggio di Gatekeeper Request (GRQ), al quale uno o più Gatekeeper potranno rispondere con un messaggio Gatekeeper Confirmation (GCF), indicante la loro presenza nel sistema e la disponibilità per un'eventuale registrazione, oppure con un messaggio Gatekeeper Reject (GRJ) nel caso non intendano registrare il terminale. Nel caso in cui un terminale riceva la conferma da più Gatekeeper deve sceglierne uno e procedere alla registrazione con esso. Allo scopo di fornire ridondanza all'interno di un sistema che lo preveda, il messaggio GCF può indicare una lista di gatekeeper alternativi da utilizzare in caso di guasto. Inoltre, il messaggio GCF include anche l'identificativo TSAP a cui richiedere l'apertura del canale RAS del Gatekeeper, utile nel caso in cui questo abbia un valore non standard. Questo processo di ricerca automatica si ripete nel caso in cui un endpoint verifichi un'assenza di risposta da parte di un gatekeeper entro lo scadere di un timeout o un problema in fase di registrazione Registrazione al Gatekeeper Il processo di registrazione consente ad un endpoint di comunicare ad un gatekeeper la propria presenza all'interno di una zona ed il proprio identificatore TSAP. Nel caso l'endpoint sia un terminale utente ha la facoltà di comunicare anche i propri alias,che invece non sono supportati per Gateway, MCU e MC.

38 Voce su IP Page 38 Inoltre, l'endpoint comunica anche la natura del terminale stesso (terminale utente, Gateway, etc). Tale processo, simile al caso della procedura ricerca del gatekeeper, deve avvenire prima che sia effettuata qualsiasi chiamata, ed inizia con l'invio da parte di un endpoint di un messaggio Registration Request (RRQ) all'indirizzo del Canale RAS di un gatekeeper, il quale potrà rispondere con un messaggio Registration Confirmation (RCF) o Registration Reject (RRJ). Il pacchetto RRQ contiene, tra le altre cose, anche un campo TimeToLive che specifica l'intervallo di refresh desiderato, a cui segue la conferma (o la modifica) di tale valore nella RCF. La durata della registrazione può essere decisa in fase di setup specificando un valore TimeToLive nel messaggio RRQ. Il messaggio RRQ deve essere ripetuto periodicamente tramite messaggi RRQ più "leggeri", con il bit KeepAlive settato. Inoltre, il gatekeeper è abilitato a processare richieste multiple dallo stesso endpoint. La ripetizione periodica della registrazione (modello soft state), permette di aumentare la robustezza del sistema in quanto i terminali inattivi vengono riconosciuti dal Gatekeeper, impedendo quindi il tentativo di instaurazione di chiamate verso un terminale inesistente. Inoltre, il Gatekeeper si trova nelle condizioni di dover gestire solamente i terminali attivi, con gli ovvi vantaggi del mantenere sempre uno stato coerente. E' possibile annullare la registrazione al Gatekeeper utilizzando una procedura analoga alla precedente con messaggi di tipo Unregister. Un terminale che vuole cancellare la propria registrazione invia un messaggio di Unregister Request (URQ) al gatekeeper che risponde con un messaggio di Unregister Confirmation (UCF); se il terminale non era preventivamente registrato riceve dal gatekeeper un Unregister Reject (URJ). La registrazione può essere annullata anche dal Gatekeeper stesso (ad esempio se viene riconosciuta una fase di shutdown): il Gatekeeper invierà un messaggio URQ al terminale, che risponderà con un messaggio UCF Ammissione e cambiamento di banda Il Canale RAS è utilizzato anche per l'invio di messaggi con funzioni di controllo di accesso e gestione della banda. In particolare, questa procedura è richiesta per l'instaurazione di una chiamata attraverso il Gatekeeper. I messaggi di tipo Admission Request (ARQ) sono utilizzati da un endpoint per indicare ad un Gatekeeper l'autorizzazione ad effettuare una chiamat; contestualmente viene anche specificata la banda richiesta. A sua volta, il Gatekeeper ha la facoltà di rispondere con messaggi Admission Confirm (ACF) nei quali comunica l'autorizzazione all'instaurazione della chiamata (ad esempio l'utente potrebbe non essere autorizzato a chiamare determinati numeri telefonici); contestualmente può accettare o ridurre il valore della banda richiesta. Nel caso in cui la chiamata non sia possibile, il Gatekeeper risponderà con un messaggio Admission Reject (ARJ) che terminerà il processo. La banda può anche essere rinegoziata durante la chiamata stessa tramite i messaggi di cambiamento di banda Bandwidth Change Request (BRQ). Il valore richiesto è un limite superiore aggregato del flusso di bit trasmessi e ricevuti, dei canali audio e video escluso l'header RTP e ogni altro overheader di controllo Instaurazione di una chiamata

39 Voce su IP Page 39 L'instaurazione di una chiamata consiste in più fasi che dipendono dalla presenza o meno del Gatekeeper, e dalla configurazione che ad esso è stata assegnata. Si tratterà prima il caso dell'apertura di una chiamata diretta tra due terminali utente, quindi si passerà a vedere cosa cambia nel caso in cui vi sia anche un Gatekeeper. Il canale di Segnalazione Chiamata è utilizzato per il trasporto affidabile di messaggi H.225 di controllo chiamate. In reti in cui è assente un Gatekeeper, tali messaggi sono scambiati direttamente dai due endpoint coinvolti in una chiamata. Nel caso sia invece presente un Gatekeeper, i messaggi sono inizialmente inviati a quest'ultimo, il quale poi indicherà se continuare l'invio al medesimo o direttamente all'endpoint destinatario della chiamata Chiamata diretta tra due terminali La fase di call setup inizia quando c'è la richiesta, con un messaggio H.225 SetupRequest, da parte di un'endpoint, di instaurare una chiamata. L'altro endpoint risponderà con un Call Proceeding, indicante che la richiesta è stata presa in considerazione. A questo punto, il destinatario della chiamata deve essere in grado di rispondere con un messaggio di Alerting per comunicare al mittente di aver avvisato l'utente finale. Nel caso di connessione tra reti di diversa natura con un gateway, quest'ultimo deve rispondere con un alerting solo dopo che ha ricevuto un'indicazione di ring dalla rete telefonica. In realtà, il messaggio di Alerting è opzionale e il destinatario può rispondere anche con messaggi di Connect o Release Complete, purchè la risposta arrivi entro 4 secondi, dopo di che, in mancanza di risposta, il chiamante genererà un nuovo messaggio di Setup. Il messaggio di Connect deve essere inviato solo se è possibile aprire un canale di controllo H Gatekeeper Direct Endpoint Nella configurazione in cui entrambi gli endpoint sono registrati sullo stesso gatekeeper, il gatekeeper stesso può scegliere, come già visto in precedenza, due metodi di segnalazione, direct endpoint o gatekeeper routed. Nel primo caso, il primo terminale inizierà una fase di Admission Control verso il Gatekeeper (ARQ - ACF/ARJ) per la negoziazione della banda della chiamata e per la determinazione dell'indirizzo del terminale chiamato. Ottenuta una risposta positiva, il messaggio di Setup verrà inviato direttamente al secondo terminale, usando l'indirizzo (IP + TSAP) ottenuto dal Gatekeeper. Nel caso in cui il terminale chiamato accetti la richiesta, inizierà a sua volta uno scambio di messaggi ARQ/ACF con il Gatekeeper; in caso di conclusione positiva di questa fase, inverà un messaggio di Alerting (e poi

40 Voce su IP Page 40 Connect) direttamente al chiamante; in caso negativo invierà invece un messaggio di Release Complete per chiudere la chiamata. La fase di setup è conclusa quando il secondo terminale invia un messaggio di Connect contenente l'identificativo TSAP del canale di controllo H.245, necessario per poter attivare la segnalazione H.245. Da questo momento in poi, la chiamata è stabilita. Tuttavia, mentre il canale di controllo RAS e i flussi multimediali sono instaurati direttamente tra i due endpoint, i messaggi di segnalazione H.245 vengono inviati comunque attraverso il gatekeeper. Ovviamente, anche i messaggi di chiusura vengono inviati attraverso il gatekeeper: un primo endpoint invia un messaggio DRQ all'altro endpoint (attraverso il gaterkeeper) a cui seguirà un messaggio DCF/ DRJ (sempre attraverso il gatekeeper) Gatekeeper Routed Call Questa procedura è concettualmente analoga alla precedente, con la differenza che in questo caso i messaggi di chiamata passano completamente attraverso il Gatekeeper, che agisce pertanto come un "router" nei confronti dei due endpoint. Viceversa, i flussi multimediali sono instaurati direttamente end-to-end, senza l'intermediazione del gatekeeper. Esiste un ulteriore scenario, chiamato Gatekeeper Proxy, che fa sì che anche i flussi multimediali vengano inviati attraverso il gatekeeper. Con quest'ultima modalità (spesso implementata nei prodotti, ma non specificata dallo standard) non vi è alcun scambio di dati end-to-end Instradamento dei messaggi di controllo

41 Voce su IP Page 41 Dopo aver stabilito il canale di segnalazione, vi sono due metodi, equivalenti ai due precedenti, per instradare il canale di controllo H.245. Nel primo caso il canale è instaurato direttamente tra gli endpoint, nel secondo caso si fa uso del Gatekeeper che gestisce direttamente il controllo delle chiamate. Il primo metodo (canale diretto) è utilizzato quando non si fa uso di Gatekeeper nella rete; in presenza di Gatekeeper si preferisce sempre il secondo metodo (il primo è sperimentale) Comunicazione iniziale e scambio informazioni di capacità Il canale di controllo H.245, appena instaurato, serve per aprire il canale dei media (Media Channels) dove ci sarà il trasporto dei dati multimediali. Il primo messaggio H.245 inviato è il TerminalCapabilitySet, che serve per annunciare la capacità del terminale di ricevere e inviare il flusso multimediale: descrive le caratteristiche della compressione audio e video usata, il massimo jitter supportato, la capacità di multiplexare più flussi (nel caso di conferenza). Ad ogni richiesta deve seguire un messaggio di Ack. Il messaggio OpenLogicalChannel contiene invece informazioni sul canale di controllo del flusso multimediale, l'indirizzo di rete e l'identificatore TSAP usati dall'endpoint per le comunicazioni RTCP. L'ACK di questo messaggio contiene sia i dati del canale di controllo del flusso multimediale RTCP che i dati, TSAP e indirizzo di rete, del canale multimediale RTP Comunicazioni multimediali A questo punto, è possibile lo scambio dei dati multimediali (attraverso RTP e RTCP) con l'endpoint remoto Terminazione chiamata

42 Voce su IP Page 42 La chiamata può essere terminata da un endpoint o da un Gatekeeper. la chiamata viene abbattuta seguendo questi passi: Il flusso audio non è più continuo e l'endpoint chiude il canale logico dell'audio. Deve trasmettere il messaggio,all'endpoint con cui ha una chiamata attiva, sul canale logico di controllo H.245, di endsessioncommand per chiudere il canale di controllo stesso. Deve aspettare di ricevere il messaggio di endsessioncommand dall'endpoint remoto. Se il canale di segnalazione H.225 è aperto deve chiuderlo con l'invio di un messaggio di Release Complete. I due endpoint devono notificare ai gatekeeper il rilascio della banda con dei messaggi di BRQ (Bandwidth Change Request). Se l'endpoint si stacca dalla rete, dovrà notificarlo al Gatekeeper con messaggi di tipo DRQ (Disengage Request), a cui seguirà un messaggio DCF (Disengage Confirmation) oppure DRJ (Disengage Reject) Conclusioni La suite di protocolli H.323 ha avuto una notevole diffusione come soluzione per implementare la telefonia su IP sia nel mondo aziendale che nel mondo dei telecom provider. Attualmente, la gran parte delle implementazioni VoIP (anche di grandi operatori internazionali, ad esempio quelli che offrono telefonate a lunga distanza a costi ridotti) adotta questo standard. Tuttavia, lo standard è estremamente complesso e le nuove implementazioni stanno progressivamente migrando alla tecnologia SIP. Molti vendor, ad esempio, offrono apparati che possono essere aggiornati alla tecnologia SIP con un semplice cambio di release software. Dalla parte di H.323 rimane una maggior solidità nelle implementazioni; tuttavia, il futuro per questo standard è ormai segnato.

43 Voce su IP Page 43 Capitolo 3. La suite di protocolli SIP 3.1. Introduzione Il Session Initiation Protocol (SIP) nasce in ambito IETF con la creazione del SIP Working Group, in collaborazione con il MMUSIC Working Group (Multiparty Multimedia Session Control). La proposta nasce dall'esperienza di MBone dove si erano implementati alcuni applicativi audio/ video, i quali avevano implementato delle semplici primitive di segnalazione. SIP nasce come alternativa alla suite H.323 ponendo, a suo vantaggio, la semplicità. SIP è un protocollo di segnalazione di livello applicativo che ha come scopo l'instaurazione, la modifica e la terminazione di una chiamata o di una sessione multimediale/dati. Tra le caratteristiche peculiari di SIP vi è l'idea di inserire l'intelligenza (ove possibile) alla periferia della rete lasciando al backbone il compito di smistamento dei pacchetti; il risultato è l'ottenimento di eccellenti caratteristiche di scalabilità. Inoltre, SIP può operare con qualsiasi protocollo di livello inferiore (IP, Frame Relay, X.25, ATM...) ma, essendo stato studiato per il mondo Internet, si interfaccia più facilmente con IP. Anche se la suite SIP specifica numerosi protocolli (d'altro canto la realizzazione di una telefonata non è un compito semplice), SIP definisce componenti piccoli e mono-funzionali, in modo da evitare la duplicazione (o commistione) di funzioni e fare si che siano modulari, a differenza di quello che succede in H.323 dove per una funzione elementare sono necessarie interazioni di più protocolli. Inoltre, il protocollo SIP, per questioni di semplicità, cerca di riutilizzare altri componenti precedentemente definiti in ambito IETF e sufficientemente disponibili e si limita a definire puramente funzioni di controllo. Ad esempio, non specifica la trasmissione dei dati multimediali (audio, video), demandando questo compito al già collaudato protocollo RTP/RTCP. Per lo stesso motivo, SIP non si preoccupa di riservare la banda per una chiamata, demandando questo compito al terminale utente, se questo è interessato: per far questo, il terminale potrà sfruttare altri protocolli già definiti in ambito IETF. In particolare, SIP può inviare al terminale chiamato invitato le informazioni necessarie per l'allocazione di risorse sulla rete: è fortemente integrato, infatti, con il protocollo SDP, Session Description Protocol, e con RSVP, Resource reservation Protocol, che hanno il compito di dare una descrizione dettagliata delle risorse necessarie all'instaurazione della chiamata e di riservarle. Infine,

44 Voce su IP Page 44 può utilizzare protocolli come SAP (eventualmente in multicast) per l'annuncio di sessioni multimediali. SIP offre un supporto trasparente di "name mapping" e adattamento dei servizi per agevolare la "personal mobility". Gli utenti possono quindi originare e ricevere chiamate e accedere i servizi telefonici da ogni terminale e in ogni posto, e la rete ha l'abilità di identificare l'utente e i suoi spostamenti. La mobilità personale è basata sull'uso di un'identificazione unica dell'utente. Visto l'enorme successo del World Wide Web dovuto all'estrema semplicità dei protocolli utilizzati, il protocollo SIP segue la stessa filosofia ed utilizza un modello di interazione di tipo client-server, con messaggi la cui sintassi è text-based sul modello del protocollo HTTP. Inoltre, utilizzando molti dei concetti già noti, l'integrazione con altre tecnologie ne risulta facilitata. Ad esempio, gli indirizzi SIP sono molto simili agli indirizzi di , semplificando pertanto anche l'interazione con utente. SIP può utilizzare come protocollo di livello di trasporto sia UDP sia TCP: il primo offre il vantaggio di un maggior controllo sui tempi di trasmissione, la possibilità di ricerche parallele e il multicast, mentre TCP offre un servizio connesso utile per il passaggio, ad esempio, attraverso i firewalls. Inoltre, il TCP permette di utilizzare la stessa connessione per l'inoltro di più messaggi di Request/ Response, diminuendo l'overhead connesso all'apertura della connessione TCP. In ogni caso, anche con UDP SIP garantisce l'affidabilità dei messaggi definendo un meccanismo di three-way handshake (Request, Response, Ack). Nel caso di UDP, SIP non ammette la frammentazione: tutto il messaggio deve essere contenuto in un singolo pacchetto, la cui dimensione (a livello IP) dovrà essere pari alla MTU della rete o pari al massimo a 1500 bytes SIP e sicurezza Il protocollo SIP offre ovviamente anche caratteristiche di sicurezza: in primo luogo permette l'autenticazione dell'utente ma offre anche meccanismi contro attacchi del tipo Denialof-service o contro l'equivalente dello Spam, le mail commerciali non richieste. In aggiunta, poiché i messaggi SIP sono puramente testuali e quindi molto facilmente decifrabili, c'è la possibilità di criptare il corpo del messaggio o di nascondere i nodi intermedi attraverso cui la richiesta è giunta a destinazione. Una politica di questo tipo potrebbe generare loop in quanto i nodi successivi non conoscono da quali nodi è messaggio è transitato, e quindi potrebbero rimandarlo erroneamente indietro; sono però disponibili alcune strategie per impedirlo Servizi principali previsti da SIP

45 Voce su IP Page 45 SIP offre cinque servizi principali per instaurare e terminare una chiamata: Localizzazione dell'utente: determina quale sia l'end system da usare per la comunicazione Ricerca delle capacità dell'utente: determina le caratteristiche dell'utente in termini di risorse audio/video e i parametri da usare Disponibilità dell'utente: riconosce la volontà del chiamato di comunicare o meno Setup della chiamata: stabilisce i parametri della chiamata Gestione della chiamata: include le operazioni di trasferimento e gestione delle chiamate 3.2. La pila protocollare SIP La pila protocollare SIP è decisamente variegata e prevede l'utilizzo di numerosi componenti. Da quanto punto di vista la situazione può sembrare analoga a quella di H.323; tuttavia, ogni componente è indipendente (o quasi) dagli altri, la divisione delle funzionalità è abbastanza netta, e la semplicità del tutto è decisamente superiore. Pertanto, non si verificano quelle commistioni di protocolli per cui una singola funzionalità viene realizzata attraverso l'impiego di differenti protocolli, ognuno di essi utilizzato in minima parte rispetto alle sue funzionalità globali SDP Il protocollo SDP (Session Description Protocol) è utilizzato per la descrizione della sessione multimediale: descrive, ad esempio, il numero di flussi multimediali impegnati e le relative caratteristiche del codec, l'indirizzo/porta utilizzata dalla sessione sulla rete, la banda impiegata, l'originatore del flusso, e il tempo di inizio / fine del flusso stesso. L'ultimo parametro è significativo nel caso di media streaming (ad esempio si potrà annunciare che un concerto live inizia alle ore 21.00) e nel caso di "invito" ad una conferenza, specificando quindi l'ora di inizio e quella di fine. Anche SDP, come SIP, definisce un formato testuale per i messaggi; il messaggio SDP è incluso come parte finale di un messaggio di SIP INVITE.

46 Voce su IP Page Formato dei messaggi SDP Un messaggio SDP è diviso in più sezioni: iniziamente vengono riportate le informazioni relative all'intera sessione, quindi seguono (e sono opzionali) quelle relative ai media fisici che ci si propone di attivare. La sezione iniziale ha sempre l'attributo di versione ("v = ") nella prima riga; le sezioni dei media iniziano quando viene incontrata una riga "m = ". Nella prima sezione è obbligatorio almeno una riga relativa alle impostazioni temporali della sessione t (" = ") che definisce l'istante di inizio e di fine della sessione (con una sintassi un po' convoluta, essendo il tempo espresso in secondi con la stessa notazione utilizzata da NTP). SDP definisce numerosi campi ("attributi") che possono essere inclusi in un messaggio. Di questi, alcuni sono obbligatori, mentre altri sono a discrezione dell'utente. Tra i campi a carattere generale riferiti all'intera sessione si trovano il creatore della sessione, la chiave di cifratura, la banda presunta espressa o in modalità CT (Conference Total, ossia l'intera banda occupata dalla sessione multimediale), oppure AS (Application-Specific Maximum, ossia la banda occupata dal solo utente in esame), l'iundirizzo di mail e il numero di telefono del creatore della sessione, ecc. Altri campi sono invece riferiti al singolo media, ad esempio il tipo di media, la porta UDP sulla quale verrà recapitato, il Payload Type utilizzato in RTP, etc. Gli attributi sono associati alla sezione nella quale sono presenti. Ad esempio, l'attributo k=" " (chiave crittografica) o il generico attributo "a=" valgono per l'intera sessione se sono inseriti nella sezione iniziale, oppure si riferiscono ad un singolo media se sono presenti in una sezione "media". In generale i valori a livello di sessione sono validi anche per tutti i media, a meno che siano esplicitamente ridefiniti all'interno della descrizione del media stesso. L'elenco dei messaggi ammessi in SDP è riportato in figura Esempio di messaggi SDP

47 Voce su IP Page 47 In figura sono riportati alcuni esempi di messaggi SDP. E' possibile notare come nel primo esempio venga annunciata una sessione di puro audio, mentre nel secondo caso la sessione comprende audio, video e una lavagna condivisa. Tra gli attributi più importanti (e non immediatamente intuitivi da interpretare), è possibile citare i seguenti. Attributo " o =": Identificativo del creatore della sessione e identificativo della sessione stessa. La definizione del campo e un suo esempio di utilizzo sono riportati di seguito: <username> <session id> <version> <network type> <address type> <address> mhandley IN IP Sia per il campo "Session ID" che per il campo "version" è consigliato utilizzare un numero derivato da NTP per garantire l'unicità della sessione. Attributo "c =": Informazioni relative alla connessione. La definizione del campo e un suo esempio di utilizzo sono riportati di seguito: <network type> <address type> <connection address> IN IP Questo attributo deve essere sempre presente (o globalmente alla sessione, oppure uno per media). In questo caso la sessione verrà attivata su internet (IN), da una macchina IPv4 con indirizzo RTP/RTCP Svolgono il compito solito, ossia il primo è responsabile del trasferimento dei dati multimediali, mentre il secondo controlla l'andamento della sessione, in particolar modo dal punto di vista della qualità. E' cioè in grado di accorgersi se la chiamata ha una qualità accettabile; in caso negativo, questa informazione può essere usata dai componenti di livello superiore per poter prendere gli opportuni provvedimenti (ad esempio passare ad un codec con meno richieste di banda) RTSP Il Real-Time Streaming Protocol controlla l'interazione dell'utente con un server di streaming multimediale, e controlla il modo con cui uno spezzone multimediale viene riprodotto sul terminale utente. E' in grado, ad esempio, di inviare comandi di start/stop, pause, avanzamento veloce, etc. Un server RTSP è utile sia nel caso di media streaming classico (ad esempio Video on Demand), sia nel caso in cui l'utente voglia ascoltare messaggi registrati, quali potrebbero essere quelli memorizzati nella propria segreteria telefonica.

48 Voce su IP Page Componenti principali di SIP L'architettura SIP prevede l'impiego di numerosi componenti, elencati in figura User Agent Questo oggetto è nient'altro che il terminale utente, che include obbligatoriamente due componenti: User Agent Client: si occupa delle procedure necessarie a far partire una chiamata User Agent Server: è in ascolto di eventuali chiamate in arrivo; si occupa della gestione delle chiamate in ingresso Proxy Server La funzione del proxy server è quella solita, ossia un oggetto a cui è possibile delegare in toto la gestione della chiamata. Questo server agirà come "server" nei confronti della macchina originante la chiamata, e come "client" nei confronti del terminale destinazione. Il vantaggio nell'utilizzazione di un proxy server è che l'intelligenza bordo del terminale utente può essere limitata, vantaggio che si presenta in particolar modo per i telefoni IP. In questo caso, i terminali utente non devono preoccuparsi di tutte le procedure di segnalazione nella loro interezza (risoluzione del nome, etc), ma possono delegare il tutto al proxy. Infatti, spesso il Proxy Server è utilizzato in aziende che fanno uso di telefoni IP anzichè di PC come terminali utente Redirect Server

49 Voce su IP Page 49 Il Redirect Server agisce come un "deviatore" di chiamata: accetta una chiamata in ingresso a cui risponde con un messaggio indicante che non è il server stesso il terminatore finale, ma la chiamata deve essere rediretta verso un altro oggetto. Questo oggetto diventa estremamente utile per poter implementare servizi a valore aggiunto di redirezione della chiamata, in quanto questo server diventa il terminatore di tutte le chiamate di una certa zona. Se opportunamente configurato, questo server potrà indicare al chiamante che il chiamato risponde ad un numero telefonico tradizionale, oppure ad una casella di voice mail, o altro ancora, a seconda delle caratteristiche della chiamata (ad esempio in base all'orario della chiamata, oppure all'originatore della stessa, etc.) Media Server Il Media Server si occupa della riproduzione / registrazione di flussi multimediali sulla rete. Un impiego del Media Server può essere la generazione di un ritornello audio di attesa nel momento in cui il chiamato è già impegnato in un'altra comunicazione, oppure come segreteria telefonica nel quale registrare i messaggi, etc. In generale, anche questo componente (come il Redirect Server) permette l'implementazione di servizi a valore aggiunto Location Server Il Location Server implementa un servizio di risoluzione degli indirizzi. Infatti, è necessario, a fronte di un indirizzo del tipo tradurlo nell'indirizzo IP effettivo del terminale che dovrà accettare la chiamata. L'operazione di traduzione impiega i classici server già conosciuti: il DNS e LDAP Server AAA Il server di AAA (Authentication, Authorization, Accounting) è necessario per inserire, all'interno della rete, funzionalità di gestione dal punto di vista della sicurezza. Solitamente questo servizio viene implementato da un server RADIUS, il quale si preoccuperà prima di capire l'identità dell'utente, poi di verificare se l'utente è autorizzato a far partire una certa chiamata, quindi a tenere traccia della chiamata stessa per le necessarie operazioni di contabilizzazione Multi Conference Unit E' un oggetto in grado di realizzare chiamate tra 3 o più persone, con le stesse caratteristiche dell'omologo componente presente in H.323. Anche in

50 Voce su IP Page 50 questo caso, la MCU ha la possibilità di elaborare i flussi multimediali (mixing, switching) per meglio gestire la conferenza Indirizzamento SIP definisce che ogni utente deve avere un indirizzo SIP. Questo implica che l'indirizzo non è legato al terminale, ma individua l'utente. Un terminale, a sua volta, avrà un indirizzo fisico, ma normalmente questo è ricavato (ad esempio attraverso la consultazione di un server DNS/ LDAP) dall'indirizzo dell'utente. Questa scelta favorisce la mobilità degli utenti dal momento che la chiamata per uno stesso utente verrà diretta su terminali diversi (indirizzi fisici) a seconda delle regole impostate. Per comodità, si è ritenuto che il formato adottato dagli indirizzi di fosse appropriato anche per i servizi SIP. Non solo, ma si è ritenuto opportuno estendere il formato dell'indirizzo e- mail in modo da utilizzare lo stesso identificativo personale per servizi diversi attraverso la definizione di un opportuno prefisso applicativo. Così, ad esempio, l'indirizzo può essere utilizzato per inviare una a Mario Rossi, mentre l'indirizzo può essere usato per attivare una sessione SIP. L'indirizzo SIP è, come anche gli indirizzi di posta elettronica, case-insentitive. La parte iniziale dell'indirizzo (nomeutente), è il nome dell'utente o un numero telefonico, la parte finale (dominio.com), può essere il nome di dominio oppure l'indirizzo di un server SIP (che comprende anche il caso in cui sia l'indirizzo effettivo del terminale utente). Grazie a questo meccanismo molto flessibile per la definizione degli indirizzi, SIP supporta anche l'interlavoro con la rete telefonica classica: un'indirizzo nella forma può indicare la volontà di raggiungere l'utente telefonico indicato attraverso un gateway tra mondo IP e mondo telefonico che sta presso il Politecnico di Torino. In quest'ultimo caso si deve indicare, attraverso il parametro user=phone, che l'identificativo è un numero telefonico. Nel caso in cui l'url SIP coincide con il nome della persona più il nome dell'azienda la privacy dell'utente, che consiste nell'avere un numero privato, può sembrare compromessa; tuttavia, a differenza della telefonia tradizionale, i meccanismi di SIP consentono un livello di autenticazione e di controllo di accesso che permettono comunque di regolare l'arrivo delle chiamate verso il proprio numero. Il controllo può essere inserito sia un un server (ad esempio il Redirect Server), sia direttamente all'interno del terminale utente, il quale può rifiutare le chiamate non autorizzate o indesiderate. L'URL SIP è usata nei messaggi per indicare la sorgente (From), la destinazione corrente (Request-URI) e finale (To) della richiesta; è utilizzata inoltre per indicare gli indirizzi verso cui reindirizzare i messaggi. Il parametro password può essere presente nell'url SIP, ma il suo uso è fortemente sconsigliato nel caso in cui venga utilizzato un protocollo di trasporto differente da TLS/TCP, poiché l'indirizzo del destinatario del messaggio è inviato in chiaro Parametri di indirizzamento

51 Voce su IP Page 51 Anche se l'indirizzo è il parametro fondamentale per la raggiungibilità di un utente, non è l'unico: esiste tutta una serie di parametri opzionali che possono definire meglio le caratteristiche della chiamata. Questi parametri sono inseriti nell'url SIP dopo l'indicazione dell'host e sono separati da punti e virgole. Tra i parametri principali vi sono: Parametri di trasporto: determinano il protocollo di trasporto (UDP oppure TCP; il protocollo di default è UDP) Indirizzi multicast: il campo maddr indica l'indirizzo del "server" da contattare per questo utente, che si sostituisce all'indirizzo del campo host ed è tipicamente un indirizzo multicast. Time To Live: il parametro ttl determina il valore time-to-live del pacchetto UDP multicast, deve essere presente solo nel caso di indirizzo multicast e protocollo UDP. Il figura sono riportati alcuni esempi di URL SIP. Nel primo caso, ad esempio, si cercherà di contattare l'utente usando il multicast con un ttl di 15. Nel caso in cui la porta non sia presente, la chiamata SIP procede utilizzando la porta 5060 del protocollo di trasporto prescelto Configurazione dei server DNS per la gestione dell'indirizzamento Mentre gli utenti conoscono l'esistenza di un server attraverso il suo nome (es. la localizzazione del server stesso da parte della rete viene fatta attraverso l'indirizzo numerico (es ). Questo meccanismo permette non solo di disaccoppiare la visione dell'utente dal funzionamento interno alla rete, ma anche di fornire all'utente un identificativo mnemonico fisso, senza dover per questo impedire all'amministratore della rete di procedere ad un cambio di indirizzo IP della macchina in esame. Per lo stesso motivo, anche il nome del servizio deve essere separato dalla macchina che fornisce il servizio stesso. Questa filosofia è utilizzata da numerosi servizi, primo fra tutti il servizio di . Anche SIP utilizza questo approccio, che richiede però un certo lavoro per "tradurre" un URI associato ad un utente in un insieme di parametri (indirizzo IP della macchina da contattare, protocollo di trasporto da usare, porta) necessari all'instaurazione della chiamata. La RFC 3263 indica pertanto che l'indirizzo IP, la porta e il protocollo di trasporto da usare per una sessione SIP debbano essere determinate attraverso l'interazione con un server DNS. SIP richiede che venga stabilito anche il protocollo di trasporto in quanto questo protocollo può essere imbustato in UDP, TCP, SCTP, oppure TLS/TCP a seconda delle esigenze. Il DNS fornisce due tipi di record che sono di interesse per il protocollo SIP: SRV e NAPTR, che servono per ricavare (con una procedura piuttosto complessa ma molto flessibile) i parametri necessari per localizzare il server SIP responsabile di un certo dominio a cui appartiene l'utente chiamato. Tuttavia, alcune implementazioni fanno uso del solo record SRV.

52 Voce su IP Page Record SRV I record SRV (specificati nella RFC 2782) sono nella forma indicata in figura, dove il significato dei campi è il seguente: Service Rappresenta il tipo di servizio da risolvere; in questo caso e' SIP oppure SIPS nel caso in cui si usi il trasporto sicuro (TLS su TCP). Si noti come il nome del servizio è conosciuto dall'applicativo che sta effettuando la risoluzione (ad esempio perchè è contenuto all'interno dell'indirizzo, es. Transport Indica il protocollo di trasporto da utilizzare, in questo esempio UDP; altri valori sono TCP e SCTP. Name TTL Class SRV Dominio a cui il record in esame si riferisce: il record nell'esempio indica che quel record si riferisce a tutte le richieste per il dominio.polito.it. Indica la durata (in secondi) del record stesso ed è usato per definire la massima durata della sua validità quando viene memorizzato all'interno della cache di un altro DNS. Rappresenta la classe "Internet", quindi è sempre IN. E' la parola chiave che identifica questo record come un record SRV. Priority La priorità può essere utilizzata per definire quale record ha la precedenza, nel caso in cui ne esistano piu' di uno. Nel caso di due record con diversa priorità, viene utilizzato sempre quello a priorità maggiore (corrispondente al valore più basso); gli altri vengono utilizzati solamente qualora attraverso il primo non si ottenga risposta. Weight Quando esistono più record SRV con la stessa priorità, questo parametro determina proporzionalmente quale dei record dovrà essere utilizzato. Ad esempio, in presenza di due record con la stessa priorità ma con pesi 10 e 20, il secondo verrà utilizzato il doppio delle volte del primo. Questo meccanismo è utilizzato per fare bilanciamento di carico tra gli host. Porta Target Porta a cui il server è in ascolto per quel particolare servizio (nell'esempio la 5060). Nome del server che è responsabile del servizio secondo i parametri specificati. Questo nome può essere letterale, nel qual caso è necessario una ulteriore risoluzione (di un record A / AAAA) per ottenerne l'indirizzo IP.

53 Voce su IP Page 53 In figura è riportata un estratto della configurazione del DNS per gestire una certa affidabilità e il bilanciamento di carico tra due server, server1 e server2. Dopo una parte iniziale nel quale si indicano le informazioni relative al dominio nel record SOA (Start Of Authority) e i record A nel quale vengono specificati gli indirizzi IP di alcune macchine (tra le quali server1 e server2), i record seguenti indicano che nel caso di chiamata SIP con trasporto UDP è da preferire server1 (che ha priorità più bassa), mentre nel caso di chiamata SIP con trasporto TCP le chiamate devono essere inoltrate in proporzione di 2 a 1 rispettivamente a server1 e a server2, ad esempio perchè la prima macchina è decisamente più performante della seconda Record NAPTR I record NAPTR (specificati nella RFC 3263) vengono utilizzati per determinare la tipologia di trasporto da usare per accedere ad un servizio. Infatti, i record SRV specificano il server (e la porta) da contattare a fronte di un determinato protocollo di trasporto che deve essere noto a priori. Tuttavia, non danno la possibilità di indicare quale protocollo di trasporto (TCP, UDP,...) debba essere preferito. I record NAPTR sono nella forma indicata in figura, dove il significato dei campi è il seguente. Domain-name Indica il dominio a cui questo record si riferisce e che corrisponde alla porzione dell'indirizzo SIP che sta a destra del segno (as esempio polito.it per TTL Class Indica la durata (in secondi) del record stesso ed è usato per definire la durata della sua validità quando viene memorizzato all'interno della cache di un altro DNS. Rappresenta la classe "Internet", quindi è sempre IN. NAPTR E' la parola chiave che identifica questo record come un record NAPTR. Order Indica l'ordine nel quale i record NAPTR devono essere esaminati nel caso ne esistano più di uno, partendo dal valore più basso. Se il record con ordine più basso contiene l'indicazione di utilizzare un trasporto che non è supportato dall'applicativo (o che non può essere utilizzato per esplicita volontà dell'utente), si passa ad esaminare il prossimo record NAPTR, fino a quando se ne trova uno che può essere usato (oppure si abortisce il servizio). Preference Come nei record SRV, i record NAPTR hanno un valore di preferenza espressa in modo crescente. Nel caso in cui esistano più record NAPTR compatibili con le richieste dell'applicazione, questo parametro determina proporzionalmente quale dei record dovrà essere utilizzato. Ad esempio, in presenza di due record con lo stesso valore di ordine ma con preferenza 10 e 20, il secondo verrà utilizzato il doppio delle volte del primo. Questo parametro è poco utilizzato nel caso di servizi SIP e

54 Voce su IP Page 54 Flags normalmente tutti i record NAPTR vengono configurati con la stessa preferenza, in quanto l'eventuale bilanciamento del carico viene fatto attraverso i record SRV. I Flag dipendono dall'applicazione; nell'esempio, il flag "s" indica che non sono necessarie ulteriori operazioni di lookup per localizzare il record SRV relativo; pertanto, tutte le informazioni necessarie sono presenti in questo record NAPTR. Service Indica il protocollo di trasporto da utilizzare e può assumere i valori SIP+D2U (per UDP), SIP+D2T (per TCP), SIP+D2S (per SCTP), SIPS+D2T (per TLS/TCL). RegExp E' un campo che può essere utilizzato per contenere una espressione regolare (regular expression) che può essere utilizzata per rimpiazzare, al volo, una parte del campo Target. Tuttavia, è consigliabile evitare di impostare questo campo per evitare inutili complicazioni. Target Nome del record SRV che contiene i parametri per utilizzare il servizio secondo il trasporto specificato. In figura è riportato un estratto della configurazione del DNS precedente con l'aggiunta dei record NAPTR. Questi record specificano che debba essere utilizzato, di preferenza, il trasporto TLS/TCP, quindi TCP e, come ultima scelta, UDP. I record NAPTR non sono strettamente necessari; tuttavia, la RFC3263 definisce che, qualora presenti, dovrebbero essercene almeno tre per coprire i principali protocollo di trasporto possibili (TLS/TCP, TCP, UDP), con l'ordine di priorità indicato nell'elenco. In altre parole, ove possibile si consiglia l'utilizzo di SIP sicuro, lasciando SIP su UDP come ultima opzione Lo standard ENUM Nonostante lo standard SIP preveda l'adozione di indirizzi alfanumerici nella forma perchè di più facile memorizzazione, il vecchio standard E-164 che definisce un identificativo telefonico come una sequenza di numeri a 12 cifre (es ) ha ancora delle ragioni per esistere. In prima battuta, l'identificativo SIP non è familiare alla stragrande maggioranza degli utenti che sono abituati al numero telefonico. Inoltre (e più importante), l'identificativo SIP non è compatibile le tastiere numeriche dei telefoni tradizionali e di molti telefoni SIP (la quasi totalità dispone solamente di tasiera numerica). Il problema è pertanto sia di tipo operativo (non è pensabile di sostituire tutti i terminali telefonici esistenti; inoltre, per problemi di spazio, non è pensabile avere una tastiera alfanumerica sui telefoni cellulari), che di tipo sociale: alcuni utenti mal digerirebbero un telefono con tastiera alfanumerica (ad esempio persone anziane), ed inoltre spesso l'utente si sente maggiormente a suo agio con una telefono dotato di una tastiera numerica tradizionale.

55 Voce su IP Page 55 Lo standard ENUM (telephone NUmber Mapping, definito nella RFC 2916, poi aggiornata con la RFC3761) offre una soluzione al problema di capire se, dato un numero telefonico in formato tradizionale E.164, questo numero corrisponda ad un terminale che è raggiungibile attraverso la rete IP e, in caso affermativo, l'indirizzo IP del terminale stesso. Inoltre permette anche di specificare differenti mezzi con il quale l'utente stesso può essere contattato (telefono, , fax, etc) lasciando al chiamante la possibilità di scegliere il mezzo più opportuno. Questo permette ad un utente SIP di essere associato ad un unico identificativo che può essere rimappato su un certo numero di dispositivi fisici a seconda delle preferenze dell'utente stesso (es. ufficio/casa), e delle necessità del chiamante (es. fax / telefonata). Infatti, sulla rete telefonica coesistono numerosi servizi: ad esempio sia un telefono che un fax sono identificati da un numero, ma il servizio che offrono è ben diverso e un utente ha ben chiaro se vuole inviare un fax oppure telefonare. La mera risoluzione del numero telefonico non è quindi sufficiente in quanto l'uri da utilizzare dipende anche dal servizio stesso. Per questo motivo, a fronte di una richiesta di tipo ENUM, la risposta conterrà sempre una lista di URI disponibili per quell'utente: sarà poi a cura del chiamante selezionare quello adatto relativo al servizio di cui intende usufruire. ENUM è applicabile in due distinti scenari: un utente SIP (con la sola tastiera numerica) che chiama un altro utente SIP un gateway PSTN-SIP, che riceve una chiamata lato PSTN e la deve inoltrare verso un utente SIP. In particolare, questo scenario necessita di una preventiva elaborazione della chiamata lato PSTN in quanto la rete telefonica deve in qualche modo identificare il gateway di uscita (ad esempio, la numerazione E-164 assegnata agli utenti SIP potrebbe essere disgiunta da quella della telefonia tradizionale) Il problema, però, è lo stesso, indipendentemente dallo scenario considerato: associare all'indirizzo E.164 il corrispondente identificativo SIP. ENUM propone una soluzione a questo problema attraverso l'impiego del DNS, ossia inserendo in esso opportune informazioni che permettano la traduzione di un indirizzo E.164 in un indirizzo SIP. Lo standard ENUM non affronta invece un terzo scenario, apparentemente simile ai precedenti (in quando richiede anch'esso una traduzione E SIP), ossia la traduzione di un indirizzo E-164 nell'indirizzo di un opportuno gateway VoIP da utilizzare qualora il destinatario finale sia un utente sulla rete PSTN. Il problema principale è quello contabilizzazione delle chiamate: per inoltrare una chiamata verso un numero PSTN è necessario selezionare un gateway di uscita e pagare, al gestore del gateway, il costo della telefonata. Pertanto, la scelta del gateway non è una scelta puramente tecnica ma dipende da altri fattori quali gli accordi di interscambio di traffico, le procedure di addebito della chiamata (che devono essere ribaltate dal gateway, che fisicamente effettua la chiamata verso la PSTN, all'effettivo chiamante), etc. Pertanto, lo standard ENUM non affronta questo problema.

56 Voce su IP Page 56 Lo standard ENUM non affonta il problema duale: tradurre un indirizzo SIP in un indirizzo E.164: questo problema è gestibile attraverso le normali funzionalità di "alias" di SIP, dove ad un utente possono corrispondere più nomi logici associati allo stesso dispositivo fisico, oppure collegati tra di loro attraverso operazioni di "redirect" delle chiamate Principi di funzionamento Data una entità (che può essere un terminale utente, un SIP proxy oppure un gateway) che dispone di un indirizzo E.164, il primo passo consiste nel ricavare da esso un identificativo con cui interagire con il DNS, e quindi procedere ad una serie di interrogazioni per ricavare l'indirizzo SIP del chiamato. La traduzione tra numero telefonico e identificativo del dominio è indicata in figura: si scrive per intero il numero telefonico (compreso di prefisso nazionale), ne si invertono le cifre, si inserisce il carattere "." tra ogni cifra, e si appende in coda il suffisso e164.arpa. A questo punto è possibile effettuare una query di tipo NAPTR verso il DNS alla ricerca di tutti i record DNS associati a tale entry. All'interno del DNS potranno essere trovati record NAPTR come ad esempio quelli indicati in figura, dove il significato dei campi è quello già visto in precedenza; vi sono però alcuni valori nuovi che assumono il significato seguente: Flag Vale sempre "u" e indica che la risposta che si ottiene da questa query è di tipo terminale (ossia non richiede una nuova richiesta NAPTR per ottenere la risposta definitiva); questo non esclude tuttavia che si debba procedere a nuove query (magari anche NAPTR), ma queste saranno relative a record diversi rispetto all'attuale E2U+SIP Indica la tecnologia utilizzata nella traduzione del record; in questo caso si traduce un indirizzo E164 in un URI ("E2U"), il quale è di tipo SIP ("+SIP") Indica una espressione regolare secondo lo standard POSIX e la stringa nella quale verrà inserito il dell'espressione stessa; l'espressione regolare e la stringa sono nella forma:!regexp!string! Nel caso dell'esempio, l'espressione regolare seleziona tutto il record iniziale (seleziona tutti i caratteri (".*") che sono compresi tra l'inizio ("^") e la fine ("$") della stringa) che viene pertanto rimpiazzato dal valore indicato nella stringa che segue l'espressione regolare, ottenendo la stringa se si è interessati ad un servizio SIP, e così via. L'utente che ha chiesto la risoluzione utilizzerà (in funzione dell applicazione e delle eventuali preferenze) l'indirizzo più opportuno.

57 Voce su IP Page Esempio di risoluzione con ENUM La figura riporta un esempio di risoluzione completa che fa uso dello standard ENUM. In questo caso, il numero telefonico viene risolto prima in un insieme di URI disponibili per quell'utente (attraverso un certo numero di richieste al DNS che dipendono dalla lunghezza della catena di delega), quindi viene selezionato l'uri preferito a seconda del servizio che si vuole utilizzare per interagire. A questo punto sarà necessario una nuova interazione con il DNS per conoscere gli identificativi necessari all'instaurazione del collegamento (ad esempio il protocollo di trasporto, l'indirizzo IP e la porta UDP/TCP) attraverso nuove risoluzioni DNS di record NAPTR e SRV Creazione dell'infrastruttura DNS per ENUM La creazione dell'infrastruttura per il supporto di ENUM deve avvernire su scala mondiale. Tuttavia, l'assegnazione della gestione del dominio responsabile della risoluzione ENUM (poi definito in e164.arpa) ha generato numerose discussioni politiche. Ad esempio, c'era la proposta di assegnarlo ad un'organizzazione neutrale, senza interessi nè economici nè politici, quella di assegnarlo all'itu, e altro. La soluzione è stata trovata definendo un dominio di primo livello (Top Level Domain, in termini propri della tecnologia DNS) chiamato e164.arpa, definendone l'itu come responsabile amministrativo, ma assegnando il controllo dal punto di vista operativo all'iab che ha a sua volta delegato le operazioni all'ente di registrazione europeo (RIPE). RIPE gestisce quindi la delega al TLD, ma ogni nazione deve a sua volta implementare un record per quanto riguarda il prefisso nazionale, e da qui seguono a cascata i vari operatori telefonici e i singoli utenti. La risoluzione di record ENUM è pertanto effettuata a cascata, nello stesso modo con cui viene implementata la risoluzione inversa degli indirizzi IP/IPv6 (attraverso i domini in-addr.arpa e ip6.arpa). Il problema più grosso di questa soluzione è nel caso in cui gli spazi di indirizzamento tra diversi soggetti (ad esempio diversi operatori) non siano disgiunti, in quanto diventa problematico la creazione di un meccanismo di delega basato su prefissi telefonici. In altre parole, non è più possibile dire che, all'interno degli operatori italiani, se il numero inizia per "0" è necessario rivolgersi all'operatore X1, mentre se inizia per "1" è necessario proseguire la risoluzione con le strutture dell'operatore X2 e così via. Infatti, i vari meccanismi di number portability impediscono questo tipo di soluzione Esempio di rete VoIP con un impiego minimale di ENUM

58 Voce su IP Page 58 La gestione dell'infrastruttura ENUM è decisamente complessa e richiede l'interazione di un mumero di soggetti molto elevato. Può quindi presentarsi il caso di un'azienda che decide di implementare una infrastruttura SIP al suo interno e che ha pertanto la necessità di tradurre dei numeri telefonici in indirizzi SIP solo se l'utente chiamato appartiene alla rete interna (e quindi risiede sulla stessa infrastruttura VoIP). Anche se l'utilizzo di ENUM può essere una soluzione, questa è decisamente complessa in quanto è necessario prima effettuare una risoluzione ENUM, quindi se la risposta è affermativa inoltrare la chiamata attraverso SIP, in caso contrario inoltrare la chiamata al PSTN gateway. In molte aziende si utilizza una soluzione molto più semplice: si personalizza il SIP proxy con una regola che permette di riconoscere i "numeri telefonici brevi" (la numerazione interna all'azienda): se il numero digitato dall'utente è di questo tipo, la chiamata deve essere inoltrata attraverso SIP (in quanto è diretta ad un altro telefono VoIP dell'azienda), in caso contrario (se il numero chiamato ha un numero di cifre superiori alla numerazione interna all'azienza) viene inoltrata verso il SIP-PSTN gateway e da lì fatta proseguire come telefonata tradizionale. Questo sistema evita sia l'uso di ENUM (intesa come infrastruttura globale; risoluzioni NAPTR possono essere ancora necessarie), sia il problema della fatturazione delle chiamate telefoniche originate da una rete VoIP: tutte le chiamate uscenti dal SIP-PSTN gateway saranno originate dal utenti dell'azienda stessa, quindi l'azienda pagherà solamente per le chiamate effettuate dai propri dipendenti. In questo esempio, il DNS potrebbe essere configurato come in figura. Viene inserito all'interno del DNS un solo record NAPTR che si riferisce alla numerazione telefonica interna. Se il record di cui si chiede la risoluzione appartiene a questa zona, il DNS procederà alla sostituzione della stringa in ingresso secondo l'espressione regolare indicata, ottenendo l'url SIP dell'utente da chiamare I messaggi SIP In questa sezione verranno presentati i principali messaggi del protocollo SIP Struttura dei messaggi SIP

59 Voce su IP Page 59 Un messaggio SIP è di tipo: Request: se diretto da client a server Response: se diretto da server a client Entrambi i tipi di messaggio consistono in una start-line, uno o più campi di header, una linea vuota di ritorno carrello (CRLF Carriage Return Line Feed) che indica la fine degli header, e un messagge-body opzionale, così come l'esempio in Figura. Il corpo del messaggio può essere, ad esempio, un messaggio SDP contenente le specifiche del flusso multimediale. Il tipo di messaggio trasportato all'interno di un messaggio SIP è definito con lo standard MIME, analogamente alla procedura in uso per la posta elettronica. Nella parte Header del messaggio si trovano informazioni relative agli utenti interessati al messaggio, il percorso che esso deve compiere prima di giungere alla destinazione, ecc. Anche i messaggi di risposta riprendono la filosofia di HTTP ed includono quindi un codice di errore (suddiviso in classi a seconda della tipologie dell'errore) e una descrizione testuale dell'errore stesso Tipologie di messaggi INVITE La richiesta INVITE si usa per chiedere al destinatario di partecipare ad una chiamata; quest'ultimo, se accetta la chiamata, deve rispondere con un ACK request, altrimenti invia un BYE request. La richiesta di tipo INVITE tipicamente contiene, nel corpo del messaggio, una descrizione della sessione multimediale che si vuole instaurare mediante il protocollo SDP, al fine di comunicare le informazioni necessarie sulla capacità di trasmissione al chiamato. Nel messaggio SDP sarà indicato il tipo di flussi di dati che è in grado di ricevere e decodificare e, possibilmente, quelli che egli intende inviare. Una richiesta di INVITE può essere inviata anche a connessione instaurata per poter rinegoziare i parametri di una chiamata. In questo caso, la richiesta avrà un Call-ID uguale al precedente, mentre il numero contenuto in CSeq sarà maggiore: il chiamato sarà tenuto a controllare i cambiamenti nella descrizione della sessione e rispondere opportunamente (possibilmente dopo aver chiesto conferma all'utente) ACK E' utilizzato per comunicare l'accettazione di un messaggio di INVITE. Nel messaggio di ACK può essere contenuto un payload di tipo SDP indicate la descrizione della sessione, così come accettata dall'utente. Ad esempio, a fronte di un codec audio G.711, il chiamato potrebbe indicare l'utilizzo di un codec G.729. Nel caso in cui questo dato venga a mancare, il chiamante utilizzerà la descrizione della sessione a lui proposta nel messaggio SDP iniziale.

60 Voce su IP Page 60 Il messaggio di ACK (così come anche il messaggio di BYE) non è una classica risposta al messaggio di INVITE. Infatti, il messaggio ACK viene inviato dallo stesso soggetto che ha precedentemente inviato l'invite. Il messaggio di INVITE ha una risposta che può essere, ad esempio, 200 OK; il messaggio ACK viene generato dal chiamante se costui accetta la risposta, che può contenere, ad esempio, una codifica diversa da quella originariamente prevista BYE Il messaggio di BYE comunica al chiamante che la chiamata non è possibile. Questo messaggio può essere generato da ambedue le parti (chiamato / chiamante) e in qualunque momento (fase di instaurazione della chiamata oppure con chiamata già attiva). Nel caso in cui la chiamata sia attiva, l'utente che riceve un BYE deve cessare immediatamente l'invio dei flussi dati CANCEL Il metodo CANCEL cancella una richiesta ancora pendende, ed è utilizzabile solo nella fase di apertura della connessione. Infatti, SIP ammette l'apertura di una connessione verso più terminali contemporaneamente (ad esempio il telefono d'ufficio e il telefono mobile), solitamente gestite da un server (proxy, ad esempio). Nel momento in cui una delle due richieste viene accettata e il pacchetto di ACK torna al server (il quale lo propagherà all'utente), il risultato della seconda richiesta perderà di importanza. A questo punto, il server potrà inviare un messaggio CANCEL verso la destinazione da cui ancora attende risposta, cancellando le richieste ancora pendenti ed evitando un inutile sovraccarico della rete. Questo metodo cancella tutte le richieste non ancora soddisfatte, che abbiano gli stessi parametri Call-ID, To, From e Cseq, ma non quelle definitive, e può essere utilizzato in ogni momento della chiamata. Nel caso in cui una delle due fallisca, questo non implica che la chiamata debba essere abbattuta. In questo caso, il terminale che fa fallire la chiamata genererà un CANCEL (o meglio, il terminale genererà un BYE, ma il proxy che ha duplicato la chiamata lo trasformerà in CANCEL), permettendo al chiamante che una possibile via di connessione è fallita, ma altre stanno ancora operando per portare a termine la chiamata OPTIONS Il metodo OPTIONS può essere utilizzato per richiedere informazioni sullo stato di un server, sui tipi di flussi di dati che può accettare e generare, sui metodi supportati. Un possibile impiego di questo metodo è per richiedere, ad un terminale che è attualmente impegnato in una chiamata (e che quindi non può rispondere positivamente ad messaggio INVITE), i parametri audio/video compatibili con il terminale stesso, per poterli utilizzare in un successivo messaggio di INVITE REGISTER Questo messaggio è utilizzato da un client per registrare un indirizzo all'interno di un SIP server; questa registrazione può essere fatta da locazioni fisiche anche diverse. La registrazione può essere fatta sia in unicast, che in multicast all'indirizzo well-known "all SIP server" sip.mcast.net ( ). In questo secondo caso, il dominio amministrativo di validità della registrazione

61 Voce su IP Page 61 deve essere in qualche modo limitato (ad esempio con un valore del campo Time To Live del pacchetto IP), per evitare la registrazione in troppi server. Un utente può inoltre registrarsi su diversi siti, usando diversi valori di Call- ID, e definire vari servizi e preferenze tra questi I principali campi dell'header From, To Indicano l'originatore e il terminatore della sessione SIP. I nomi indicati sono URL SIP, secondo la terminologia già vista. Una particolarità è che questi campi sono legati alla sessione SIP, e non a chi ha generato il messaggio in esame. Di conseguenza i campi From e To rimangono invariati nel passaggio tra il messaggio di richiesta e il messaggio di risposta VIA Il campo VIA è usato nel caso in cui una transazione SIP richieda l'interazione di parecchi server proxy. In questo caso ogni server introduce una nuova riga (con l'indicazione di sé stesso) di tipo VIA all'interno dell'header SIP. Questo permette di ricostruire il percorso del messaggio, consentendo al messaggio di risposta di compiere lo stesso percorso, ma in senso inverso. Gli header di tipo VIA sono aggiunti e tolti dinamicamente al messaggio: una nuova riga VIA viene aggiunta man mano che il messaggio avanza verso la destinazione, mentre le stesse righe vengono tolte nel percorso all'indietro Call-ID E' una stringa che identifica univocamente una sessione SIP (ad esempio una sessione di invito oppure di registrazione). Normalmente ha la forma di un URL, formato da un numero identificativo progressivo e dal dominio in cui questo valore è stato calcolato. Il Call-ID può cambiare ad esempio nel caso in cui, in una sessione, si generi un nuovo messaggio di INVITE per cambiare i parametri operativi (codec, ad esempio) della sessione Cseq

62 Voce su IP Page 62 Il campo Command Sequence include il comando che ha generato la sessione e viene mantenuto per tutta la sua durata. In altre parole, in una sessione INVITE questo parametro manterrà sempre lo stesso valore sia per i messaggi di richiesta, sia per i messaggi di risposta Subject Il campo Subject ha il significato a cui si è già abituati ed indica lo scopo della sessione Content-Type, Content-Length, Content-Encoding Questi campi presentano le principali caratteristiche del payload del pacchetto SIP, ove presente. Il campo Content-Type indica il tipo di payload con una codifica di tipo MIME, ad esempio una mail. Il campo Content-Length indica la lunghezza del payload stesso. Infine, il campo Content-Encoding indica le operazioni che, eventualmente, devono essere fatte sul payload per poterlo leggere. Ad esempio, una mail può essere codificata in diversi formati (UTF-8, UTF-7, etc) e questa informazione deve essere conosciuta dal destinatario per poter interpretare correttamente i dati trasmessi Codici di errore Analogamente al protocollo HTTP, anche SIP definisce delle classi di risposta che, con codici di errore distinti, permettono di ricostruire meglio l'accaduto Informational La classe di tipo 1xx indica che il server o il proxy contattato deve compiere ulteriori operazioni e non ha una risposta definitiva. Il client deve attendere una ulteriore informazione dal server che è obbligato a inviare una messaggio 1xx se ritiene di impiegare più di 200ms per ottenere una risposta definitiva.

63 Voce su IP Page 63 Le risposte di tipo 1xx attualmente definite sono le seguenti: 100: Trying 180: Ringing 181: Call Is Being Forwarded 182: Queued Success La richiesta ha avuto successo e deve terminare la ricerca. L'unico codice definito è 200; OK. l'informazione contenuta nella risposta dipende dal metodo usato nella richiesta: BYE: la chiamata è stata terminata, il corpo del messaggio è vuoto CANCEL: la ricerca è stata cancellata, il corpo del messaggio è vuoto INVITE: il chiamato ha accettato di partecipare, il corpo del messaggio indica le capacità di ricezione del chiamato OPTIONS: il chiamato ha accettato di rendere disponibili le sue capacità di ricezione, includendole nel corpo del messaggio REGISTER: la registrazione ha avuto successo Redirection Le risposte 3xx divulgano informazioni sulla nuova localizzazione dell'utente o sui servizi alternativi che possono soddisfare la richiesta attraverso l'impiego del campo Contact dell'header SIP. Ogni reindirizzamento non deve suggerire nessun indirizzo già contenuto nel cammino definito dagli header Via della richiesta: 300: Multiple Choices 301: Moved Permanently 302: Moved Temporarily 303: See Other 305: Use Proxy 380: Alternative Service Client-Error Le risposte 4xx sono riferite a delle richieste fallite. Il client non deve riprovare a inviare la richiesta senza modificarla (ad esempio, potrebbe dover aggiungere l'appropriata autorizzazione).

64 Voce su IP Page 64 In ogni caso, la stessa richiesta potrebbe aver successo presso un altro server. I codici previsti sono i seguenti: 400: Bad Request 401: Unauthorized 402: Payment Required 403: Forbidden 404: Not Found 405: Method Not Allowed 406: Not Acceptable 407: Proxy Authentication Required 408: Request Timeout 409: Conflict 410: Gone 411: Length Required 413: Request Entity Too Large 414: Request-URI Too Large 415: Unsupported Media Type 420: Bad Extension 480: Temporarily not available 481: Call Leg/Transaction Does Not Exist 482: Loop Detected 483: Too Many Hops 484: Address Incomplete 485: Ambiguous 486: Busy Here Server-Error Le risposte 5xx indicano un fallimento dovuto alla responsabilità di un particolare server. Non sono fallimenti definitivi e non devono terminare una ricerca se altri indirizzi non sono ancora stati provati: 500: Internal Server Error 501: Not Implemented

65 Voce su IP Page : Bad Gateway 503: Service Unavailable 504: Gateway Time-out 505: SIP Version not supported Global-Failure Le risposte di tipo 6xx indicano che un server ha una informazione definitiva riguardo un particolare utente, non solo circa la richiesta specifica indicata nel request-uri: 600: Busy Everywhere 603: Decline 604: Does not exist anywhere 606: Not Acceptable Esempio di messaggi In Figura sono riportati due messaggi di una sessione di tipo INVITE. E' possibile notare come tra il primo messaggio (Request) e il secondo (Response) ci siano i campi From, To, Call-ID e Cseq che rimangono invariati. Si può notare anche come i parametri SDP della sessione cambino tra i due messaggi: cambiano sia parametri relativi all'audio, sia (ovviamente) le informazioni del flusso audio in termini di indirizzo/porta (in quanto in una telefonata vi sono due flussi) Le principali operazioni SIP In questa sezione verranno illustrate le principali fasi del protocollo SIP Transazione

66 Voce su IP Page 66 Prima di poter illustrare le varie fasi di una chiamata SIP, è opportuno definire la transazione, che racchiude sostanzialmente una chiamata SIP dal momento in cui il SIP Client (UAC) emette un pacchetto di Invite. Una volta che l'host è riuscito a risolvere l'indirizzo del server SIP, il client SIP invia una o più richieste SIP a questo server e riceverà una o più risposte dallo stesso. L'insieme di queste operazioni si identificano come transazioni SIP. Tutte le risposte ad una richiesta devono contenere gli stessi valori nei campi di Call-ID, CSeq, To, e From Risoluzione di un indirizzo SIP Quanto un client (che puà essere uno User Agent oppure un SIP Proxy) si trova a dover risolvere un indirizzo SIP, deve innanzitutto controllare se l'uri contiene l'indicazione esplicita della porta da utilizzare oppure un indirizzo numerico. In questi due casi, l'uri indica l'host finale e, al più, è richiesta una risoluzione DNS di tipo A (oppure AAAA per indirizzi IPv6) per ricavare l'indirizzo IP dell'host. In caso contrario (l'indirizzo non è numerico, oppure non vi è indicata alcun numero di porta), il client SIP richiede la risoluzione di un record NAPTR per il dominio richiesto, ricavando il protocollo di trasport. Se questo è disponibile, procede con il relativo record SRV, ricavando l'host e la porta del server SIP da contattare. In caso invece il record NAPTR non sia disponibile, crea una richiesta direttamente per un record SRV, indicando in essa i protocolli di trasporto ammessi dall'utente. All'ottenimento di un record SRV può essere necessario ancora risolvere il nome del server in un indirizzo numerico, con un ulteriore query di tipo A/AAAA. Alcuni server DNS sono in grado di anticipare le mosse del client: a seguito di una richiesta di tipo NAPTR, sono in grado di confezionare una risposta che contiene tutti i record voluti, ossia NAPTR, SRV e A/AAAA. Questo consente di ridurre il numero di interrogazioni al DNS necessarie per risolvere un indirizzo. Nel caso in cui il record SRV non fosse disponibile, il client fa un ultimo tentativo di risolvere il nome indicato nell'uri come se fosse un host, richiedendo quindi la risoluzione di un record A/AAAA. In questo caso, il client contatterà la controparte utilizzando il protocollo UDP che dovrebbe essere il minimo comun denominatore tra tutte le implementazioni SIP, oppure il trasporto TLS/TCP nel caso in cui l'utente richieda una sessione sicura. Tuttavia, potrebbe essere possibile anche utilizzare il protocollo TCP in casi particolari, ad esempio quando ci si rende conto di avere richieste la cui dimensione è superiore alla massima MTU ammissibile sul percorso Esempio di risoluzione di indirizzo SIP

67 Voce su IP Page 67 Si supponga un host che deve contattare l'utente SIP con identificativo La sua prima azione sarà di contattare il DNS responsabile del dominio foo.com, richiedendogli l'elenco dei record NAPTR, ed ottenendo la risposta seguente: ; order pref flags service regexp replacement IN NAPTR "s" "SIPS+D2T" "" _sips._tcp.foo.com IN NAPTR "s" "SIP+D2T" "" _sip._tcp.foo.com IN NAPTR "s" "SIP+D2U" "" _sip._udp.foo.com Questa risposta indica che ikl server supporta TLS su TCP, TCP e UDP, in questo ordine di preferenza. Se, ad esempio, il client supporta solamente TCP e UDP, verrà utilizzato il trasporto TCP in quanto questo record ha ordine inferiore. Il client proseguirà richiedenbdo la risoluzione del record _sip._tcp.foo.com, di tipo SRV, ottenendo la seguente risposta: ;; Priority Weight Port Target IN SRV server1.foo.com IN SRV server2.foo.com Questa risposta farà si che il client contatterà probabilmente la macchina server2 (in quanto ha un peso doppio di server1, a parità di priorità) sulla porta 5060, con il protocollo TCP. Nel caso in cui non fosse noto l'indirizzo IP della macchina server2.foo.com, verrebbe nuovamente contattato il DNS con la richiesta di risoluzione del record A/AAAA per server2.foo.com. Questa macchina, una volta contattata, dovrà avere coscienza dell'esistenza dell'utente bob e dovrà essere in grado di recapitare la chiamata a destinazione Chiamata con Proxy Server In Figura è riportato un esempio di chiamata con Proxy Server. Il server proxy accetta l'invite request (passo 1), contatta il server delle locazioni (passo 2), ottiene l'indirizzo preciso della posizione attuale del chiamato (passo 3), e invia un SIP INVITE request all'indirizzo ritornato dal location server (passo 4). L'user agent server allerta l'utente (passo 5) e ritorna un success indication al proxy server (passo 6) che, a sua volta, ritorna la risposta al chiamante (passo 7). La ricezione del messaggio è confermata dal chiamante usando un messaggio di tipo ACK (passo 8) che viene inoltrata al chiamato attraverso il server proxy (passo 9) oppure direttamente. Per chiarezza nel disegno si è in realtà tralasciato un messaggio. Infatti, l'utente impiega tipicamente parecchio tempo (confrontato alla velocità di reti ed elaboratori) a rispondere alla chiamata. Tuttavia, mentre il messaggio 200 OK può essere inviato solamente quando l'utente ha accettato la chiamata, SIP impone un tempo massimo entro cui la risposta va data. In questo caso, il terminale chiamato è tenuto a rispondere con un messaggio 180 Ringing, informando il chiamante che l'operazione è ancora in corso, per poi inviare il messaggio definitivo non appena ha ricevuto una conferma dall'utente.

68 Voce su IP Page Chiamata con Redirect Server Il Redirect Server è utilizzato per informare il chiamante dell'effettiva locazione del chiamato. In questo modo la chiamata potrà essere diretta tra le due controparti, senza alcuna intermediazione (proxy, etc). In questo caso, il Redirect Server accetta la chiamata (passo 1), verifica l'effettiva locazione dell'utente contattando un Location Server (passi 2 e 3), quindi, anzichè contattare personalmente il nuovo indirizzo trovato, lo notifica al chiamante (passo 4). Il chiamante è tenuto, a questo punto, a confermare al Redirect Server la risposta ottenuta, inviando un messaggio ACK (passo 5). A questo punto la chiamata procede secondo i passi già visti in precedenza: un nuovo INVITE è inviato direttamente alla destinazione (passo 6), la quale procederà a far squillare il terminale (passo 7), e ad inviare una risposta non appena sarà possibile (passo 8; anche qui potrebbe esserci una risposta temporanea di tipo 180 Ringing). L'instaurazione della chiamata si conclude con l'invio di un messaggio di acknowledge (passo 9) verso il chiamato Esempio di chiamata complessa L'utente Watson che lavora sull'host saturn.bell-tel.com si registra, nella fase di inizializzazione della macchina, con una richiesta multicast sul server SIP locale bell-tel.com. In questa registrazione comunica, tra le altre cose, che il suo User Agent si aspetta di ricevere le richieste sulla porta 3890 di UDP. Tutti gli inviti per l'utente che arriveranno sul server sip.bell-tel.com saranno deviati a utilizzanto il protocollo UDP e la porta La registrazione scade dopo due ore. A questo punto di supponga che l'utente Bell chiami Watson al suo indirizzo pubblico In questo messaggio sarà incluso un messaggio SDP che indicherà le caratteristiche della sessione; in questo caso è presente solo audio e l'host mittente sarà kton.bell-tel.com utilizzzando la porta Le codifiche supportate saranno 0(PCMU), 3(GSM), 4(G.723), 5(DVI4). Di conseguenza il canale RTCP sarà aperto sulla porta 3457.

69 Voce su IP Page 69 L'accettazione della chiamata è confermata dal server (100 Trying), dopo una ricerca sui database (passo 3). A questo punto, il server comunica che la chiamata è stata inviata al destinatario (passo 4). Sono tutavia presenti due chiamate attualmente in coda per il presente utente. E' quindi necessario aspettare che le chiamate precedenti terminino; la chiamata corrente è accodata alle precedenti (passo 5). Nel momento in cui una delle precedenti chiamate termina, il server notifica l'evento al client: adesso ci sono solamente più due chiamate in coda (passo 6). Finalmente le chiamate precedenti sono terminate: il server manda la risposta 200 OK, indicante che la chiamata è stata accettata dal destinatario. Il corpo del messaggio indica le capacità di ricezione del mittente: il destinatario può ricevere solo PCMU e GSM (RTP Payload Type 0 e 3) e il canale audio RTP è identificato dalla porta 5004, mentre quello RTCP è sulla porta 5005 (passo 7). La chiamata è stata deviata sul server boston.bell-tel.com, (header Contact). Ora Watson può inviare il flusso audio alla porta 3456 di kton.bell-tel.com e Bell alla porta 5004 del boston.bell-tel.com. Dopo che i due utenti hanno concordato i parametri del flusso audio, Bell conferma la chiamata con un ACK (passo 8).

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

CENTRALINI DI NUOVA GENERAZIONE COMPATIBILI CON IL PRESENTE NATI PER IL FUTURO VOCE SU IP VOCE SU IP 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

Dettagli

Capitolo 1. Voce su IP: i concetti fondamentali

Capitolo 1. Voce su IP: i concetti fondamentali Pag Capitolo 1. Voce su IP: i concetti fondamentali 1.1. Introduzione L'argomento Voce su IP è, sicuramente, uno dei più gettonati dell'intero mondo del networking. Tecnicamente, con questa tecnologia

Dettagli

Atlantis Land Technical Resources Product: A02-RAV211 Subject: TECNOLOGIA VoIP Language: Italiano

Atlantis Land Technical Resources Product: A02-RAV211 Subject: TECNOLOGIA VoIP Language: Italiano Atlantis Land Technical Resources Product: A02-RAV211 Subject: TECNOLOGIA VoIP Language: Italiano TECNOLOGIA VoIP INTRODUZIONE In questo documento verranno trattati i caratteri principali della tecnologia

Dettagli

Voce su IP. Il flusso vocale. Fulvio Risso. Politecnico di Torino

Voce su IP. Il flusso vocale. Fulvio Risso. Politecnico di Torino Voce su IP Il flusso vocale Fulvio Risso Politecnico di Torino fulvio.risso[at]polito.it http://netgroup.polito.it/netlibrary/voip-intro/text.htm#9 Mario Baldi Politecnico di Torino mario.baldi[at]polito.it

Dettagli

VoIP. Corso di Laboratorio di Telematica A.A. 2004-2005. Francesco Chiti Andrea De Cristofaro

VoIP. Corso di Laboratorio di Telematica A.A. 2004-2005. Francesco Chiti Andrea De Cristofaro Corso di Laboratorio di Telematica A.A. 2004-2005 Francesco Chiti Andrea De Cristofaro VoIP Copyright Università degli Studi di Firenze - Disponibile per usi didattici Vedere i termini di uso in appendice

Dettagli

Multimedialità e Web. VoIP

Multimedialità e Web. VoIP Università degli Studi di Napoli Parthenope Multimedialità e Web VoIP M. Del Prete A. Guadagno 1 Sommario 1. VoIp concetti generali 2. La tecnologia di base Rete telefonica e commutazione di circuito Rete

Dettagli

VoIP - Voice over Internet Protocol. 1 Introduzione alla Telefonia su Internet Network.

VoIP - Voice over Internet Protocol. 1 Introduzione alla Telefonia su Internet Network. VoIP - Voice over Internet Protocol. 1 Introduzione alla Telefonia su Internet Network. La trasmissione di voce in tempo reale su di una rete IP (Internet Protocol), conosciuta anche come Voice over IP

Dettagli

Voice Over IP 1. TELEFONARE SU INTERNET

Voice Over IP 1. TELEFONARE SU INTERNET Voice Over IP In pochi anni la telefonia fissa è stata superata dal traffico di quella mobile. È lecito aspettarsi che nei prossimi anni la trasmissione dati supererà quella della voce raccogliendo una

Dettagli

Livello di Rete. Gaia Maselli maselli@di.uniroma1.it

Livello di Rete. Gaia Maselli maselli@di.uniroma1.it Livello di Rete Gaia Maselli maselli@di.uniroma1.it Queste slide sono un adattamento delle slide fornite dal libro di testo e pertanto protette da copyright. All material copyright 1996-2007 J.F Kurose

Dettagli

Offerta Tecnico Commerciale rev. 0.2 Servizi VoIP.Tel

Offerta Tecnico Commerciale rev. 0.2 Servizi VoIP.Tel Offerta Tecnico Commerciale rev. 0.2 Servizi VoIP.Tel 07/07/06 Pag. 1 di 7 1 DESCRIZIONE GENERALE 3 2 DOMINIO ERRORE. IL SEGNALIBRO NON È DEFINITO. 3 WEB HOSTING ERRORE. IL SEGNALIBRO NON È DEFINITO. 4

Dettagli

Per essere inviato il dato deve essere opportunamente codificato in modo da poter essere trasformato in SEGNALE, elettrico oppure onda luminosa.

Per essere inviato il dato deve essere opportunamente codificato in modo da poter essere trasformato in SEGNALE, elettrico oppure onda luminosa. La trasmissione dell informazione N.R2 La comunicazione tra due calcolatori si realizza tramite lo scambio di dati su un canale di comunicazione, esiste quindi un TRASMETTITORE che invia dei dati e un

Dettagli

RETI INTERNET MULTIMEDIALI

RETI INTERNET MULTIMEDIALI RETI INTERNET MULTIMEDIALI VoIP: Problematiche di Deployment Il documento è adattato da materiale cortesemente messo a disposizione dai Prof. Antonio Capone, Flaminio Borgonovo e Stefano Paris IL DIMENSIONAMENTO

Dettagli

Introduzione. Livello applicativo Principi delle applicazioni di rete. Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio 2-1

Introduzione. Livello applicativo Principi delle applicazioni di rete. Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio 2-1 Introduzione Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio Livello applicativo Principi delle applicazioni di rete 2-1 Pila di protocolli Internet Software applicazione: di

Dettagli

RETI INTERNET MULTIMEDIALI. VoIP: Problematiche di Deployment

RETI INTERNET MULTIMEDIALI. VoIP: Problematiche di Deployment RETI INTERNET MULTIMEDIALI VoIP: Problematiche di Deployment IL DIMENSIONAMENTO SU LAN Soluzione IPTel (PBX virtuali) Gateway con rete PSTN ISDN/PSTN IP Eth. phones Call manager (gatekeeper) Server H.323

Dettagli

INTRODUZIONE. La prima cosa che qualcuno mi risponde è quasi sempre: "sicuramente usi Skype, ne ho già sentito parlare".

INTRODUZIONE. La prima cosa che qualcuno mi risponde è quasi sempre: sicuramente usi Skype, ne ho già sentito parlare. INTRODUZIONE Ho iniziato ad usare il VoIP l anno scorso e, con il passare del tempo, mi sono reso conto che con tale tecnologia si può realmente risparmiare sui costi telefonici da rete fissa (e non solo!).

Dettagli

SUITE PROTOCOLLI TCP/IP ( I protocolli di Internet )

SUITE PROTOCOLLI TCP/IP ( I protocolli di Internet ) PARTE 2 SUITE PROTOCOLLI TCP/IP ( I protocolli di Internet ) Parte 2 Modulo 1: Stack TCP/IP TCP/IP Protocol Stack (standard de facto) Basato su 5 livelli invece che sui 7 dello stack ISO/OSI Application

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca. Parte II Lezione 1

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca. Parte II Lezione 1 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Parte II Lezione 1 Martedì 4-03-2014 1 TESTO DI RIFERIMENTO RETI DI CALCOLATORI

Dettagli

Elementi di Reti per Telecomunicazioni

Elementi di Reti per Telecomunicazioni Elementi di Reti per Telecomunicazioni (Parte II) Topologie ed Interfacciamento di Reti Corso di Telecomunicazioni Anno Accademico 2004/2005 Contenuti Introduzione alle reti di TLC. Topologie di Reti per

Dettagli

La Core Network. Domanda fondamentale: come vengono trasferiti i dati attraverso la rete? Maglia di router interconnessi

La Core Network. Domanda fondamentale: come vengono trasferiti i dati attraverso la rete? Maglia di router interconnessi La Core Network Maglia di router interconnessi Domanda fondamentale: come vengono trasferiti i dati attraverso la rete? o Commutazione di pacchetto: i dati sono spediti attraverso la rete in quantità discrete

Dettagli

Reti di calcolatori: Introduzione

Reti di calcolatori: Introduzione Reti di calcolatori: Introduzione Vittorio Maniezzo Università di Bologna Reti di computer e Internet Rete: sistema di collegamento di più computer mediante una singola tecnologia di trasmissione Internet:

Dettagli

Svantaggi della Commutazione di Circuito. Commutazione di Pacchetto. Struttura di un Pacchetto

Svantaggi della Commutazione di Circuito. Commutazione di Pacchetto. Struttura di un Pacchetto Università degli studi di Salerno Laurea in Informatica I semestre / Commutazione di Pacchetto Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Svantaggi della Commutazione

Dettagli

Principi fondamentali

Principi fondamentali Principi fondamentali Elementi di base Definizione di rete di calcolatori Tipologia di connessioni Architettura di rete Prestazioni di una rete di calcolatori Conclusioni 1 1 Bit e Byte BIT = BInary digit

Dettagli

La telefonia digitale VoIP per studi e piccole imprese

La telefonia digitale VoIP per studi e piccole imprese La telefonia digitale VoIP per studi e piccole imprese Ordine degli Ingegneri di Bergamo 14 novembre 2007 ing. Bruno A. Zambetti Huge! srl Commissione Informatica ODI BG bruno.zambetti@huge.it - www.huge.it

Dettagli

Tecnologie Radio Cellulari. Reti Cellulari. Forma e Dimensione delle Celle. Organizzazione di una Rete Cellulare

Tecnologie Radio Cellulari. Reti Cellulari. Forma e Dimensione delle Celle. Organizzazione di una Rete Cellulare I semestre 04/05 Tecnologie Radio Cellulari Reti Cellulari Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Università degli studi di Salerno Laurea in Informatica

Dettagli

Classificazione delle applicazioni multimediali su rete

Classificazione delle applicazioni multimediali su rete Universita' di Verona Dipartimento di Informatica Classificazione delle applicazioni multimediali su rete Davide Quaglia a.a. 2006/2007 1 Sommario Architettura di riferimento Classificazione per funzionalità

Dettagli

A cura di: Dott. Ing. Elisabetta Visciotti. e.visciotti@gmail.com

A cura di: Dott. Ing. Elisabetta Visciotti. e.visciotti@gmail.com A cura di: Dott. Ing. Elisabetta Visciotti e.visciotti@gmail.com Il termine generico rete (network) definisce un insieme di entità (oggetti, persone, ecc.) interconnesse le une alle altre. Una rete permette

Dettagli

Servizi Internet multimediali

Servizi Internet multimediali Servizi Internet multimediali Appunti di Sistemi A cura del prof. ing. Mario Catalano F.Castiglione 1 F. Castiglione Applicazioni Elastiche Un utente umano attende informazioni da un server; Preferibile

Dettagli

Reti di computer. Agostino Lorenzi - Reti di computer - 2008

Reti di computer. Agostino Lorenzi - Reti di computer - 2008 Reti di computer Telematica : termine che evidenzia l integrazione tra tecnologie informatiche e tecnologie delle comunicazioni. Rete (network) : insieme di sistemi per l elaborazione delle informazioni

Dettagli

Internet, così come ogni altra rete di calcolatori possiamo vederla suddivisa nei seguenti componenti:

Internet, così come ogni altra rete di calcolatori possiamo vederla suddivisa nei seguenti componenti: Pagina 1 di 8 Struttura di Internet ed il livello rete Indice Struttura delle reti Estremità della rete Il nucleo della rete Reti a commutazione di pacchetto e reti a commutazione di circuito Funzionalità

Dettagli

Reti di computer- Internet- Web. Concetti principali sulle Reti Internet Il Web

Reti di computer- Internet- Web. Concetti principali sulle Reti Internet Il Web Reti di computer- Internet- Web Concetti principali sulle Reti Internet Il Web Condivisione di risorse e comunicazione con gli altri utenti n n n Anni 70: calcolatori di grandi dimensioni, modello timesharing,

Dettagli

Università di Genova Facoltà di Ingegneria. dist. Qualità del Servizio (QdS) Prof. Raffaele Bolla. Qualità del Servizio (QdS)

Università di Genova Facoltà di Ingegneria. dist. Qualità del Servizio (QdS) Prof. Raffaele Bolla. Qualità del Servizio (QdS) Università di Genova Facoltà di Ingegneria 1. Servizi Multimediali e su IP 1.1 Introduzione alle QoS su IP Prof. Raffaele Bolla dist! Due possibili QdS: Misurata sul traffico generato dal servizio (traffico

Dettagli

Università di Genova Facoltà di Ingegneria

Università di Genova Facoltà di Ingegneria Università di Genova Facoltà di Ingegneria Reti di Telecomunicazioni e Telemedicina 1 9. Servizi Multimediali e Qualità del Servizio (QdS) su IP Prof. Raffaele Bolla dist Reti per servizi multimediali

Dettagli

Reti di Telecomunicazioni 1

Reti di Telecomunicazioni 1 Reti di Telecomunicazioni 1 Corso on-line - AA2004/05 Blocco 3 Ing. Stefano Salsano e-mail: stefano.salsano@uniroma2.it 1 Le sorgenti di traffico in una rete di TLC 2 Tipi di flussi di informazione Messaggi

Dettagli

RETI INTERNET MULTIMEDIALI. Esercitazione 4

RETI INTERNET MULTIMEDIALI. Esercitazione 4 RETI INTERNET MULTIMEDIALI Esercitazione 4 1 ESERCIZI RIEPILOGATIVI 2 Esercizio 1 Token Bucket + Leaky Bucket Un Token Bucket con capacità del buffer dei token pari a q TB,MAX =500 kb, rate di picco p

Dettagli

Fondamenti di reti WAN

Fondamenti di reti WAN Indice generale Fondamenti di reti WAN...... Definizione:... Fondamenti di reti WAN Il termine Public Switched Telephone Network (PSTN) è riferito al servizio offerto dalla ditta telefonica per connettere

Dettagli

MotoTRBO IPSC: le chiamate.!

MotoTRBO IPSC: le chiamate.! MotoTRBO IPSC: le chiamate. Versione del documento v1.0 Aggiornato a Febbraio 2014 Realizzazione a cura di Armando Accardo, IK2XYP Email: ik2xyp@ik2xyp.it Team ircddb-italia http://www.ircddb-italia.it

Dettagli

3 Caratteristiche del servizio

3 Caratteristiche del servizio 3 Caratteristiche del servizio Il GPRS offre all utente la possibilità di inviare e ricevere dati in modalità a commutazione di pacchetto, con diverse modalità e qualità. Il servizio di trasporto è particolarmente

Dettagli

Laboratorio di Informatica. Le reti telematiche e Internet

Laboratorio di Informatica. Le reti telematiche e Internet Le reti telematiche e Internet Lezione 6 1 Insieme di cavi, protocolli, apparati di rete che collegano tra loro computer distinti i cavi trasportano fisicamente le informazioni opportunamente codificate

Dettagli

Panasonic. KX-TDA Hybrid IP -PBX Systems Informazioni di base per connessioni Voice Over IP

Panasonic. KX-TDA Hybrid IP -PBX Systems Informazioni di base per connessioni Voice Over IP Panasonic PIT-BC-PBX Panasonic KX-TDA Hybrid IP -PBX Systems Informazioni di base per connessioni Voice Over IP Centrali Telefoniche KX-TDA 15/30/100/200 Informazione Tecnica N 021 Panasonic Italia S.p.A.

Dettagli

Tecniche di Comunicazione Multimediale

Tecniche di Comunicazione Multimediale Tecniche di Comunicazione Multimediale Standard di Comunicazione Multimediale Le applicazioni multimediali richiedono l uso congiunto di diversi tipi di media che devono essere integrati per la rappresentazione.

Dettagli

Introduzione alle reti di calcolatori

Introduzione alle reti di calcolatori Introduzione alle reti di calcolatori Definizioni base. Collegamenti diretti e indiretti Strategie di multiplazione Commutazione di circuito e di pacchetto Caratterizzazione delle reti in base alla dimensione

Dettagli

informatica distribuita

informatica distribuita Reti di computer Negli anni settanta, si è affermato il modello time-sharing multi-utente che prevede il collegamento di molti utenti ad un unico elaboratore potente attraverso terminali Gli anni ottanta

Dettagli

Soluzione per la VIDEOCONFERENZA EW2

Soluzione per la VIDEOCONFERENZA EW2 Soluzione per la VIDEOCONFERENZA EW2 1.Descrizione della Soluzione La soluzione per la audio/videoconferenza EW2 proposta da Gruppo SIGLA consente di comunicare e collaborare a distanza, senza muoversi

Dettagli

Modello OSI e architettura TCP/IP

Modello OSI e architettura TCP/IP Modello OSI e architettura TCP/IP Differenza tra modello e architettura - Modello: è puramente teorico, definisce relazioni e caratteristiche dei livelli ma non i protocolli effettivi - Architettura: è

Dettagli

RETI INTERNET MULTIMEDIALI. Esercitazione 2

RETI INTERNET MULTIMEDIALI. Esercitazione 2 RETI INTERNET MULTIMEDIALI Esercitazione 2 1 VOIP 2 Esercizio 1 Dimensionamento Si consideri un sistema VoIP che operi con codifica G.729 a r=8 kbit/s. L'intervallo di pacchettizzazione è fissato a T=20ms.

Dettagli

Modulo 8 - Reti di reti

Modulo 8 - Reti di reti Modulo 8 - Reti di reti Modulo 8 - Reti di reti Nelle precedenti lezioni abbiamo parlato dei tipi elementari di topologia di rete: a bus, ad anello, a stella. Si è detto anche che le reti vengono tradizionalmente

Dettagli

Lezione 4. Le Reti ed i Protocolli

Lezione 4. Le Reti ed i Protocolli Lezione 4 Le Reti ed i Protocolli Come nasce internet I computer, attraverso i software applicativi, consentono di eseguire moltissime attività. Nel corso degli anni è emersa la necessità di scambiare

Dettagli

IP Internet Protocol

IP Internet Protocol IP Internet Protocol Vittorio Maniezzo Università di Bologna Vittorio Maniezzo Università di Bologna 13 IP - 1/20 IP IP è un protocollo a datagrammi In spedizione: Riceve i dati dal livello trasporto e

Dettagli

Reti commutate. Reti commutate. Reti commutate. Reti commutate. Reti e Web

Reti commutate. Reti commutate. Reti commutate. Reti commutate. Reti e Web Reti e Web Rete commutata: rete di trasmissione condivisa tra diversi elaboratori Composte da: rete di trasmissione: costituita da (Interface Message Processor) instradamento rete di calcolatori: computer

Dettagli

VoIP e. via SOLUZIONI E INNOVAZIONE PER LA COMUNICAZIONE

VoIP e. via SOLUZIONI E INNOVAZIONE PER LA COMUNICAZIONE VoIP e via SOLUZIONI E INNOVAZIONE PER LA COMUNICAZIONE VoIP è Voice over IP (Voce tramite protocollo Internet), acronimo VoIP, è una tecnologia che rende possibile effettuare una conversazione telefonica

Dettagli

Capitolo 6. Wireless LAN: via i fili!

Capitolo 6. Wireless LAN: via i fili! Capitolo 6 Wireless LAN: via i fili! Spesso la realizzazione di una rete impone maggiori problemi nella realizzazione fisica che in quella progettuale: il passaggio dei cavi all interno di apposite guide

Dettagli

Reti di Telecomunicazioni 1

Reti di Telecomunicazioni 1 Reti di Telecomunicazioni 1 AA2011/12 Parte 5 Ing. Francesco Zampognaro e-mail: zampognaro@ing.uniroma2.it Lucidi Prof. Stefano Salsano 1 Ulteriori attributi e classificazione dei servizi 2 1 Attributi

Dettagli

Università degli Studi di Cagliari Corso di Laurea Specialistica in Ingegneria Elettronica SISTEMI OPERATIVI

Università degli Studi di Cagliari Corso di Laurea Specialistica in Ingegneria Elettronica SISTEMI OPERATIVI Università degli Studi di Cagliari Corso di Laurea Specialistica in Ingegneria Elettronica SISTEMI OPERATIVI SISTEMI A ORIENTAMENTO SPECIFICO I SISTEMI MULTIMEDIALI Obiettivi! Identificare le caratteristiche

Dettagli

Reti di calcolatori. Condivisione di risorse e comunicazione con gli altri utenti

Reti di calcolatori. Condivisione di risorse e comunicazione con gli altri utenti Reti di calcolatori Condivisione di risorse e comunicazione con gli altri utenti Reti di calcolatori Anni 70: calcolatori di grandi dimensioni, modello time-sharing, centri di calcolo Anni 80: reti di

Dettagli

) *!' " * +! #"#, ( -. - ( 0 0 00. - #

) *!'  * +! ##, ( -. - ( 0 0 00. - # ! " $% & ' ( ) *!' " * +! ", ( -. - /. - 0 0( ( ) $% * ++! " * +, ( -. - ( 0 0 00. - / 12! ) 1 1 3 /4**' $% * 3* 0 5 6 0!56" * 7'! "( - $% ' /. - 0560, 8 * 56 *, * 9$, $% 0560 :+; * " 3 *' $% ' /*, '(

Dettagli

Capitolo 7 Reti multimediali

Capitolo 7 Reti multimediali Capitolo 7 Reti multimediali Reti di calcolatori e Internet: Un approccio top-down 3 a edizione Jim Kurose, Keith Ross Pearson Education Italia 2005 7-1 Multimedia - Qualità del servizio: di cosa si tratta?

Dettagli

10 argomenti a favore dell over IP

10 argomenti a favore dell over IP Quello che i fornitori di telecamere analogiche non dicono 10 argomenti a favore dell over IP Le telecamere di rete non sono certo una novità, infatti il primo modello è stato lanciato nel 1996. Nei primi

Dettagli

Introduzione (parte III)

Introduzione (parte III) Introduzione (parte III) Argomenti della lezione Ripasso degli argomenti del primo corso: il livello di trasporto, il meccanismo di controllo delle congestioni e le applicazioni Il livello di trasporto

Dettagli

Integrazione di impianti

Integrazione di impianti Corso DOMOTICA ED EDIFICI INTELLIGENTI UNIVERSITA DI URBINO Docente: Ing. Luca Romanelli Mail: romanelli@baxsrl.com Integrazione di impianti come esempio di convergenza su IP utile per la domotica Domotica

Dettagli

Modulo 8 Ethernet Switching

Modulo 8 Ethernet Switching Modulo 8 Ethernet Switching 8.1 Ethernet Switching 8.1.1 Bridging a livello 2 Aumentando il numero di nodi su un singolo segmento aumenta la probabilità di avere collisioni e quindi ritrasmissioni. Una

Dettagli

Anno Accademico 2013-2014. Lucidi del corso di Reti di Calcolatori e Comunicazione Digitale. Introduzione ( parte II) Topologie di rete

Anno Accademico 2013-2014. Lucidi del corso di Reti di Calcolatori e Comunicazione Digitale. Introduzione ( parte II) Topologie di rete INFORMATICA e COMUNICAZIONE DIGITALE Anno Accademico 2013-2014 Lucidi del corso di Reti di Calcolatori e Comunicazione Digitale Introduzione ( parte II) Prof. Sebastiano Pizzutilo Dipartimento di Informatica

Dettagli

Servizi di videoconferenza

Servizi di videoconferenza Servizi di videoconferenza Documento redatto per: Contesto operativo Il servizio consiste nella erogazione di sessioni di multi videoconferenza HD a diversi tipi di utenza: sale conferenza equipaggiate

Dettagli

I nostri clienti possono utilizzare servizi come: Connettività Internet xdsl Connettività Internet Wireless Linee telefoniche su rete dati

I nostri clienti possono utilizzare servizi come: Connettività Internet xdsl Connettività Internet Wireless Linee telefoniche su rete dati SSERV IIZ II E SSOLUZ IION II D II CONNETT IIV IITA VOCE E DAT II Le soluzioni di Internet Comunication del gruppo S.T. permettono al cliente la realizzazione di infrastrutture voce-dati adeguate alle

Dettagli

Parte II: Reti di calcolatori Lezione 23

Parte II: Reti di calcolatori Lezione 23 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Parte II: Reti di calcolatori Lezione 23 Giovedì 22-05-2014 1 Reti wireless Una

Dettagli

Relazione di elettronica

Relazione di elettronica ANTINORO ANGELO 5IA 16/04/2007 Relazione di elettronica I MODEM INDICE Premessa Le telecomunicazione Il significato di modem Tipi di modem Modem in banda base I modem fonici La modulazione La modulazione

Dettagli

Reti locali LAN (Local Area Networks)

Reti locali LAN (Local Area Networks) Reti locali LAN (Local Area Networks) Una LAN è un sistema di comunicazione che permette ad apparecchiature indipendenti di comunicare tra di loro, entro un'area delimitata, utilizzando un canale fisico

Dettagli

Materiali per il Modulo 1 E.C.D.L.

Materiali per il Modulo 1 E.C.D.L. Materiali per il Modulo 1 E.C.D.L. Queste due sigle indicano LAN Local Area Network Si tratta di un certo numero di Computer (decine centinaia) o periferici connessi fra loro mediante cavi UTP, coassiali

Dettagli

Informatica Generale Andrea Corradini. 10 - Le reti di calcolatori e Internet

Informatica Generale Andrea Corradini. 10 - Le reti di calcolatori e Internet Informatica Generale Andrea Corradini 10 - Le reti di calcolatori e Internet Cos è una rete di calcolatori? Rete : È un insieme di calcolatori e dispositivi collegati fra loro in modo tale da permettere

Dettagli

Reti, Protocolli e Indirizzi. DIMENSIONE della RETE. Arpanet e Internetworking. Topologia a Stella

Reti, Protocolli e Indirizzi. DIMENSIONE della RETE. Arpanet e Internetworking. Topologia a Stella Premessa breve Reti, Protocolli e Indirizzi Lo sviluppo delle telecomunicazioni ha avuto due fattori determinanti : L esistenza di una rete esistente (quella telefonica) La disponibilita di HW e SW adeguati

Dettagli

Il VoIP nel mondo di Internet e l evoluzione del carrier telefonico. Relatore: Ing. Carrera Marco - Audit Technical Manager Switchward

Il VoIP nel mondo di Internet e l evoluzione del carrier telefonico. Relatore: Ing. Carrera Marco - Audit Technical Manager Switchward Il VoIP nel mondo di Internet e l evoluzione del carrier telefonico. Relatore: Ing. Carrera Marco - Audit Technical Manager Switchward Sommario 1) L evoluzione della comunicazione: dalla rete PSTN alla

Dettagli

Scopi e classificazioni

Scopi e classificazioni Reti di calcolatori Scopi e classificazioni Samuel Rota Bulò DAIS Università Ca Foscari di Venezia Classificazione reti R1.1 Reti Nozione di rete, molto diffusa in diversi contesti Ogni rete corrisponde

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15. Pietro Frasca. Parte II Lezione 1

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15. Pietro Frasca. Parte II Lezione 1 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15 Parte II Lezione 1 Giovedì 5-03-2015 TESTO DI RIFERIMENTO RETI DI CALCOLATORI E INTERNET un

Dettagli

Sistema di diffusione Audio/Video su streaming.

Sistema di diffusione Audio/Video su streaming. 1 Sistema di diffusione Audio/Video su streaming. IL Progetto. Il progetto illustrato nel seguito prevede mediante la tecnologia di streaming la diffusione di audio/video su misura del cliente al 100%,

Dettagli

Connettività Domenica 19 Dicembre 2010 17:32 - Ultimo aggiornamento Lunedì 24 Novembre 2014 19:34

Connettività Domenica 19 Dicembre 2010 17:32 - Ultimo aggiornamento Lunedì 24 Novembre 2014 19:34 La Suite di servizi Origine.net può essere erogata su reti di telecomunicazioni in tecnolgia Wired e/o Wireless. In base alle esigenze del cliente ed alla disponibilità di risorse tecnologiche, Origine.net

Dettagli

Il livello Network del TCP/IP. Il protocollo IP (versione 4)

Il livello Network del TCP/IP. Il protocollo IP (versione 4) Il livello Network del TCP/IP. Il protocollo IP (versione 4) L architettura TCP/IP (il cui nome più preciso è ) è formata da diversi componenti, che si posizionano nello stack dei protocolli a partire

Dettagli

L'architettura di rete TCP/IP OSI: Fisico - Data link

L'architettura di rete TCP/IP OSI: Fisico - Data link Pagina 1 di 11 L'architettura di rete TCP/IP OSI: Fisico - Data link Per poter rendere sicura una rete bisogna prima aver capito molto bene in quale modo funziona. Ecco quindi che in questa breve lezione

Dettagli

Programmi Applicativi

Programmi Applicativi Programmi Applicativi Giovanni Malnati Politecnico di Torino 1999 Applicativi H.323/T.120 Vari livelli di implementazione dello standard In generale, esiste compatibilità tra i diversi prodotti, ma non

Dettagli

La classificazione delle reti

La classificazione delle reti La classificazione delle reti Introduzione Con il termine rete si intende un sistema che permette la condivisione di informazioni e risorse (sia hardware che software) tra diversi calcolatori. Il sistema

Dettagli

Cos è un protocollo? Ciao. Ciao 2:00. tempo. Un protocollo umano e un protocollo di reti di computer:

Cos è un protocollo? Ciao. Ciao 2:00. <file> tempo. Un protocollo umano e un protocollo di reti di computer: Cos è un protocollo? Un protocollo umano e un protocollo di reti di computer: Ciao Ciao Hai l ora? 2:00 tempo TCP connection request TCP connection reply. Get http://www.di.unito.it/index.htm Domanda:

Dettagli

SISTEMI DI TELECOMUNICAZIONI

SISTEMI DI TELECOMUNICAZIONI SISTEMI DI TELECOMUNICAZIONI RETI TELEFONICHE Generalità Nessuna dipendenza dall estensione della rete Copertura locale Interconnessione a lunga distanza Trasporto della voce a commutazione di circuito

Dettagli

Le tecnologie ed i componenti di Ethernet

Le tecnologie ed i componenti di Ethernet Le tecnologie ed i componenti di Ethernet Hub, Bridge, Switch Ethernet Tecnologia LAN dominante: Economica:

Dettagli

Capitolo 1 - parte 2. Corso Reti ed Applicazioni Mauro Campanella

Capitolo 1 - parte 2. Corso Reti ed Applicazioni Mauro Campanella Capitolo 1 - parte 2 Corso Reti ed Applicazioni Mauro Campanella Modello a strati 5 4 applicazione trasporto Il modello che useremo prevede 5 strati che svolgono servizi per gli altri strati attraverso

Dettagli

Reti di Calcolatori. Lezione 2

Reti di Calcolatori. Lezione 2 Reti di Calcolatori Lezione 2 Una definizione di Rete Una moderna rete di calcolatori può essere definita come: UN INSIEME INTERCONNESSO DI CALCOLATORI AUTONOMI Tipi di Rete Le reti vengono classificate

Dettagli

Video Comunicazione su Rete Internet

Video Comunicazione su Rete Internet Video Comunicazione su Rete Internet 1 Introduzione alla comunicazione video su rete Internet. La rapida evoluzione dell Information Technology negli ultimi anni ha contribuito in maniera preponderante

Dettagli

Rete Internet Prova in Itinere Mercoledì 23 Aprile 2008

Rete Internet Prova in Itinere Mercoledì 23 Aprile 2008 Rete Internet Prova in Itinere Mercoledì 23 Aprile 2008 NB: alcune domande hanno risposta multipla: si richiede di identificare TUTTE le risposte corrette. Cognome: Nome: Corso di laurea e anno: Matricola:

Dettagli

Reti di Trasporto 2008- Quesiti verifica parte 3 e parte 4

Reti di Trasporto 2008- Quesiti verifica parte 3 e parte 4 Quesiti-verifica2-08-con-soluzioni-v1.doc Reti di Trasporto 2008- Quesiti verifica parte 3 e parte 4 1 Si consideri il segmento di rete ATM mostrato in figura in cui i nodi A, B, E e F sono commutatori

Dettagli

VideoStreaming su IP

VideoStreaming su IP VideoStreaming su IP Anno Accademico 2007/2008 Agenda Principi di video Streaming Come prevenire gli errori e come mascherarli Appendice Come si realizza la codifica/decodifca Protocollidirete Overview

Dettagli

INFORMATICA CORSO DI INFORMATICA DI BASE ANNO ACCADEMICO 2015/2016 DOCENTE: SARRANTONIO ARTURO

INFORMATICA CORSO DI INFORMATICA DI BASE ANNO ACCADEMICO 2015/2016 DOCENTE: SARRANTONIO ARTURO INFORMATICA CORSO DI INFORMATICA DI BASE ANNO ACCADEMICO 2015/2016 DOCENTE: SARRANTONIO ARTURO PROGRAMMA algoritmi, linguaggi di programmazione, traduttori, sistemi operativi e reti. Sistemi operativi

Dettagli

CLASSIFICAZIONE DELLE RETI

CLASSIFICAZIONE DELLE RETI CLASSIFICAZIONE DELLE RETI A seconda dei ruoli dei computer le reti si classificano in: Reti Client Server in cui sono presenti computer con ruoli diversi, alcuni funzionano da client e uno o più da server

Dettagli

Introduzione alla telefonia su IP

Introduzione alla telefonia su IP Introduzione alla telefonia su IP Mario Baldi Synchrodyne Networks, Inc. baldi@synchrodyne.com Pietro Nicoletti Studio Reti, s.a.s. p.nicol@inrete.it IPtelIntro_i - 1 Copyright: si veda nota a pag. Nota

Dettagli

RETI DI CALCOLATORI. Il traffico dati è quello caratterizzato per lo studio che stiamo facendo ed è caratterizzato da almeno 3 qualità.

RETI DI CALCOLATORI. Il traffico dati è quello caratterizzato per lo studio che stiamo facendo ed è caratterizzato da almeno 3 qualità. RETI DI CALCOLATORI Il traffico dati è quello caratterizzato per lo studio che stiamo facendo ed è caratterizzato da almeno 3 qualità. - NON CONTINUITA TEMPORALE O INTERMITTENZA: al server viene fatta

Dettagli

RETI TELEMATICHE / RETI DI CALCOLO Capitolo II Servizi di comunicazione geografici

RETI TELEMATICHE / RETI DI CALCOLO Capitolo II Servizi di comunicazione geografici Prof. Giuseppe F. Rossi E-mail: giuseppe.rossi@unipv.it Homepage: http://www.unipv.it/retical/home.html UNIVERSITA' DEGLI STUDI DI PAVIA Facoltà di Ingegneria - Sede distaccata di Mantova MASTER DI 1 LIVELLO

Dettagli

Programmazione in Rete

Programmazione in Rete Programmazione in Rete a.a. 2005/2006 http://www.di.uniba.it/~lisi/courses/prog-rete/prog-rete0506.htm dott.ssa Francesca A. Lisi lisi@di.uniba.it Orario di ricevimento: mercoledì ore 10-12 Sommario della

Dettagli

IPBX Office IPBX Office

IPBX Office IPBX Office IPBX Office IPBX Office include, oltre a tutte le funzioni di un centralino tradizionale, funzionalità avanzate quali ad esempio: voice mail con caselle vocali illimitate e personalizzate, risponditore

Dettagli

INFORMATICA LIVELLO BASE

INFORMATICA LIVELLO BASE INFORMATICA LIVELLO BASE INTRODUZIONE 3 Fase Che cos'è una rete? Quali sono i vantaggi di avere una Rete? I componenti di una Rete Cosa sono gi Gli Hub e gli Switch I Modem e i Router Che cos è un Firewall

Dettagli

Cenni sulle principali tecnologie di rete. IZ3MEZ Francesco Canova www.iz3mez.it francesco@iz3mez.it

Cenni sulle principali tecnologie di rete. IZ3MEZ Francesco Canova www.iz3mez.it francesco@iz3mez.it Cenni sulle principali tecnologie di rete IZ3MEZ Francesco Canova www.iz3mez.it francesco@iz3mez.it Oltre la LAN Perché uscire? connessione di più edifici geograficamente lontani della stessa società connessione

Dettagli

Prova di Esame - Rete Internet (ing. Giovanni Neglia) Lunedì 24 Gennaio 2005, ore 15.00

Prova di Esame - Rete Internet (ing. Giovanni Neglia) Lunedì 24 Gennaio 2005, ore 15.00 Prova di Esame - Rete Internet (ing. Giovanni Neglia) Lunedì 24 Gennaio 2005, ore 15.00 NB: alcune domande hanno risposta multipla: si richiede di identificare TUTTE le risposte corrette. Cognome: Nome:

Dettagli

Reti basate sulla stack di protocolli TCP/IP

Reti basate sulla stack di protocolli TCP/IP Reti basate sulla stack di protocolli TCP/IP Classe V sez. E ITC Pacioli Catanzaro lido 1 Stack TCP/IP Modello TCP/IP e modello OSI Il livello internet corrisponde al livello rete del modello OSI, il suo

Dettagli