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 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 si intende il trasporto di traffico di tipo vocale su una rete in tecnologia IP. Tuttavia, 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, è necessario innanzitutto capire quali sono le motivazioni di 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 che prevede che gli switch interni della rete commutino per creare un circuito "fisico" diretto fra la parte chiamante e quella chiamata. Questo significa che gli interlocutori dispongono di un canale dedicato non accessibile agli altri utenti per tutta la durata della comunicazione, indipendentemente dal fatto che le parti siano in conversazione attiva o in silenzio. Si ha, così, un'allocazione statica delle risorse e ad ogni circuito viene garantita una banda di 64Kbps bidirezionale (full duplex; l'occupazione globale è pertanto di 128Kbps). La banda costante e il collegamento diretto tra le due parti permettono al segnale vocale di avere qualità garantita per tutta la durata della

2 Pag comunicazione. Tuttavia, questo corrisponde ad avere una bassa percentuale di utilizzazione della rete e quindi non si trae vantaggio dalle proprietà del multiplexing statistico. Infatti, durante una comunicazione vocale un interlocutore passa più della metà del tempo in silenzio in quanto i due interlocutori non parlano contemporaneamente (infatti, quando uno parla l'altro solitamente ascolta in silenzio); inoltre anche tra una parola e l'altra, così come tra due periodi distinti, ci sono degli istanti di silenzio. I 1284 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 con conseguente risparmio nell'allocazione di risorse, sia nel momento in cui si volesse trasportare audio ad alta qualità (ad esempio aumentando la banda 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. Per inciso, le tecnologie di trasporto, ad esempio SONET/SDH, assumono che il canale minimo trasportabile abbia un'ampiezza di banda proprio di 64Kbps. Per realizzare il circuito virtuale tra le parti è necessaria inoltre una fase di segnalazione e di configurazione della rete setup) ( 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 tecnologia di base delle reti dati oggi esistenti si fonda sul concetto di commutazione di pacchetto, ossia sulla creazione di un'unità elementare di trasporto che sia in grado di viaggiare in maniera più o meno autonoma sulla rete e che è in grado di recapitare a destinazione il suo contenuto informativo. Allo stato attuale, la maggiore architettura di rete per il trasporto di dati è la rete IP, caratterizzata da un servizio di tipo best effort e senza meccanismi di prenotazione di risorse. Gli apparati intermedi (nodi) non creano un circuito virtuale tra le parti, ma instradano il pacchetto nella giusta direzione in base all'informazione di destinazione contenuta nell'intestazione del pacchetto stesso. 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 la gestione più efficiente della banda. Infatti, con questa tecnologia l'allocazione di risorse (quando viene fatta) non è statica, perciò su una linea possono transitare contemporaneamente pacchetti appartenenti a flussi diversi, intervallandosi a seconda della disponibilità di

3 Pag banda. In questo modo, la banda che, allocata staticamente dal sistema telefonico, veniva persa a causa della mancanza di dati da trasmettere, qui può essere (temporaneamente) utilizzata per trasmettere pacchetti appartenenti ad altri flussi, aumentando aumentando notevolmente la percentuale d'utilizzazione della rete rispetto a quella telefonica. Pertanto, sono possibili tecniche di compressione dei silenzi, oppure codec più aggressivi relativamente alla banca consumata in modo da ridurre i requisiti di banda richiesti dalla sessione vocale o, in alternativa, è possibile il trasporto di traffico vocale con bitrate più elevati, ad esempio per il trasporto di voce con qualità superiore grazie alla mancanza del limite dei 64Kbps per sessione. Il costo di una "chiamata" in tecnologia dati è quindi normalmente determinato dalla quantità di dati che passano, indipendentemente dalla durata della comunicazione. D'altro canto, la tecnologia a commutazione di pacchetti presenta anche notevoli svantaggi. Ad esempio, alcuni pacchetti di uno stesso flusso 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 eventualmente il trasporto affidabile. Tuttavia, quest'operazione può rivelarsi inopportuna nel caso di trasmissione della voce in quanto introduce notevoli ritardi ai quali i flussi voce sono particolarmente sensibili. 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 possibilità di definire adeguate garanzie di qualità (a livello di trasporto e di recapito dei dati nella rete) alle sessioni vocali Le differenti visioni della Voce su IP Anche se la tecnologia VoIP è citata in molteplici ambiti, non tutti sottintendono la stessa visione del servizio. Infatti, 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

4 Pag 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 (mediante l'impiego di normalissimi dispositivi quali un microfono, le casse e, per il video, una videocamera) gli utenti a comunicare tramite audio e testo e permetteva di trasmettere e condividere immagini e grafici tramite una whiteboard. La VoIP era quindi intesa come uno strumento che permettesse di poter effettuare chiamate vocali da un altro personal computer all'altro, rendendo possibile una comunicazione in tempo reale con l'aggiunta di funzionalità avanzate quali video, lavagna condivisa, e altro. Non ultimo, la possibilità di poter condividere il proprio desktop sul PC offriva la possibilità di operare direttamente su una macchina remota (ad esempio per risolvere problemi di configurazione), funzionalità molto comoda in determinate occasioni. I benefici della tecnologia VoIP "adattata" a questa 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 richieda 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 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 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.

5 Pag Recentemente, questa visione è stata superata da una nuova fase di maturazione del mercato VoIP nella quale numerosi provider hanno lanciato servizi telefonici attraverso la rete IP. In questo modello, il telefono è collegato ad un router IP che è in grado di digitalizzare e pacchettizzare la voce attraverso la connessione geografica (ad es. ADSL). Anche in questo caso la leva principale all'adozione di questa tecnologia sono i costi ridotti: in generale (anche se la cosa può variare a seconda dei provider), le telefonate ad altri utenti VoIP sono gratuite, mentre le telefonate ad utenti tradizionali hanno un costo inferiore rispetto a quanto praticato dagli operatori di telefonia tradizionale. Questa tipologia di servizio mira a rimpiazzare il servizio telefonico tradizionale con la tecnologia VoIP (ad esempio non richiede un PC) ed è pertanto orientato al largo pubblico anzichè ad una cerchia di affezionati come nel caso precedente. In questo caso cadono gran parte delle limitazioni enunciate in precedenza, anche se con questa modalità di servizio non è più possibile sfruttare l'integrazione con nuovi applicativi. Dal punto di vista commerciale, esistono più tipologie di terminale utente che si stanno progressivamente staccando dal mondo PC. Ad esempio, se le prime versioni di Skype (un applicativo molto usato nel mondo consumer) erano applicativi risiedenti sul PC, successivamente sono comparsi dei telefoni USB (che richiedevano ancora la presenza di un PC acceso, ma l'utente poteva telefonare utilizzando un oggetto con la classica forma di un apparato telefonico), per poi essere a loro volta rimpiazzati da terminali stand-alone (o direttamente in grado di generare traffico IP, oppure telefoni tradizionali collegati ad un particolare adattatore in grado di genrare traffico IP). In ambedue le fasi della visione consumer, i servizi di telefonia mobile non vengono intaccati dalla nuova tecnologia VoIP: l'utente domestico non ha altre scelte che continuare ad utilizzare il telefono cellulare con la tecnologia tradizionale. Pertanto, questa visione può essere usata per rimpiazzare la telefonia fissa, ma non ha alcun effetto sulla tecnologia mobile La visione "telecom" della Voce su IP: Telephony over IP Nella visione degli operatori telefonici l'enfasi è data alla sostituzione della classica tecnologia telefonica per il trasporto delle telefonate (commutazione di circuito) con la più efficiente tecnologia a commutazione di pacchetto. In questa visione, il servizio fornito all'utente non cambia, mentre cambia la modalità con cui questo viene erogato; si parla pertanto non di VoIP, bensì 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. Infatti, con il termine VoIP si indica 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 questa tecnologia. Con il termine ToIP si intende invece quell'insieme di tecnologie che permettono il trasporto di telefonate ("carrier grade") su una rete

6 Pag 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, 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 trasformi i segnali vocali tradizionali in pacchetti 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 abilitarle 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 presenta nessuna innovazione 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

7 Pag Un dato di fatto è che, ormai, il volume del traffico di tipo dati ha decisamente superato quello di tipo telefonico. Dal momento che il mantenimento di due infrastrutture di rete distinte (una per il traffico telefonico, una per il traffico dati) può essere 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 ai dati, anche se i link di livello fisico hanno continuato ad essere gestiti attraverso le tecnologie precedenti (es. SONET/SDH). In altre parole, si è veicolato il traffico dati su un'infrastruttura di tipo telefonico. Con l'attuale prevalere del traffico dati, potrebber diventare più conveniente fare il contrario: installare dei canali in tecnologia dati (una fra tutte, Ethernet e i suoi derivati a lunga distanza), quindi forzare la voce a passare su questi canali. Anche in questo caso l'infrastruttura di rete, sotto certi aspetti, sarebbe comune tra i due servizi con gli ovvi vantaggi economici e di gestione. Il secondo motivo che spinge verso integrazione della telefonia su una rete dati è l'esigenza, da parte di quest'ultima, di poter differenziare diversi tipi di traffico su di essa, indipendentemente dalla presenza o meno di traffico telefonico. 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 online) richiede che la rete porti a destinazione i pacchetti in tempi estremamente rapidi. L'incremento del numero di utilizzatori di reti IP ha fatto sì che nascessero nuove applicazioni (ad es. video streaming) e nuove esigenzze (soprattutto di business), cambiando profondamente la tipologia di traffico di una rete IP classica e mettendo chiaramente in risalto come in determinate situazioni ci siano necessità diverse da altre e come la rete debba essere in grado di trattare il traffico 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.

8 Pag 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), con meccanismi di gestione della qualità calibrati ad hoc per la tipologia di traffico. 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, non è facile giustificare una nuova spesa (la rete in tecnologia dati) quando la precedente tecnologia è in già installata e funziona benissimo il conto della "convenienza" di una tecnologia rispetto all'altra non si fa sui "volumi di traffico" (aspetto sicuramente a favore dei dati), ma sul profitto che questi generano; questo parametro è ancora tutt'ora a favore del traffico telefonico il passaggio ad una tecnologia di trasporto di tipo dati implica un salto nel buio: 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

9 Pag 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 degli operatori 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. E' interessante evidenziare come la tecnologia ToIP preveda l'utilizzo di una rete IP, ma non di Internet. Infatti, uno dei problemi della rete IP è la difficoltà di controllare il traffico, compito che è relativamente semplificato nel momento in cui la rete IP ha contorni ben delimitati ed è completamente sotto il controllo di un operatore. Viceversa, nella rete Internet il compito di fornire determinate garanzie di servizio è ancora un campo completamente aperto La visione "enterprise" della Voce su IP 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: possibilità di personalizzazione del servizio telefonico e 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 tramite la quale è possibile variare dinamicamente parametri quali l'inoltro delle chiamate (ad esempio, le chiamate telefoniche vengono terminate sul telefono VoIP, oppure sul telefono cellulare,

10 oppure ancora 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. Inoltre la segreteria telefonica viene resa disponibile via web, oppure i messaggi possono essere recapitati nella casella di posta elettronica, e via dicendo. E' interessante notare che, in linea di principio, molte di queste funzionalità sarebbero implementabili anche in presenza di centralini in tecnologia telefonica; tuttavia è un dato di fatto che gran parte di questi apparati non implementa questi servizi. Per quanto riguarda l'ntegrazione di servizi innovativi, sono sicuramente importanti le videochiamate, la condivisione di applicazioni, il trasferimento di files, e sta emergendo prepotentemente l'integrazione con sistemi di e- presence. Questi sistemi (spesso conosciuti come "instant messaging", dalla loro funzione originale) 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. In caso di necessità l'utente può decidere di inviare un breve messaggio di testo (l'instant message, appunto) oppure attivare una chiamata telefonica, o altro ancora, grazie alla conoscenza (a priori) della disponibilità o meno della persona cercata. Questi motivi fanno sì che nell'ambito enterprise vi sia una visione più completa della tecnologia VoIP e che la motivazione relativa al risparmio economico, tipico della visione degli operatori telefonici, non sia il punto più importante. 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. 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 di rete), sono i nuovi servizi a fare la differenza Il processo di creazione di un flusso VoIP Questa sezione è dedicata 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, lasciando ad una sezione successiva l'esamina delle problematiche di segnalazione La trasmissione di un segnale vocale su rete IP In questa Sezione si esamineranno le varie fasi intermedie necessarie per la trasmissione di un flusso vocale attraverso una rete IP Campionamento

11 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 intervalli di frequenza e quindi può essere limitato considerando che la qualità audio di una telefonata può essere sensibilmente inferiore a quello richiesto per l'ascolto di un cencerto. La banda utilizzata da un segnale campionato è dato dal prodotto tra le due grandezze precedenti. Nella telefonia classica 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. Nel caso di un terminale IP, il campionamento viene effettuato direttamente dal telefono stesso Codifica Spesso la codifica è confusa all'interno del processo di campionamento. Infatti, 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 (attraverso un'opportuna 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 differenza (che richiede un numero di bit inferiore) rispetto al campione originario (tecnica utilizzata ad esempio dai codec della famiglia ADPCM ed MPEG); un tipico esempio è la codifica video utilizzata in MPEG che adotta una codifica differenziale sia rispetto alla trama precedente che rispetto a quella successiva. codifica pesata: se determinati campioni sono spesso presenti 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)

12 codifica a perdita: si basa sul principio che, per l'orecchio umano, determinati segnali audio vengono praticamente ignorati. Questo tipo di codifica fa sì che questi tipi di segnali vengano cancellati, e la codifica risultante diventi più snella grazie al fatto che ci sono meno dati da inviare (tecnica utilizzata nella compressione di audio MP3) Ovviamente queste tecniche possono anche essere combinate insieme nel medesimo codificatore. Con queste tecniche si possono ottenere compressioni del segnale notevoli (si pensi al formato MP3 a 96kbps, che ha una qualità audio molto parente dei quella di un CD audio che ha un bitrate di circa 600kbps), ma richiedono normalmente una potenza elaborativa non indifferente. Inoltre, un secondo svantaggio è che alcune tecniche tendono ad aumentare il ritardo dei dati; in particolare la codifica per differenze può richiedere la presenza di uno o più campioni successivi per poter generare il dato attuale. In ogni caso, in generale non è vero che una codifica a più basso bit rate sia intrinsecamente peggiore di una a più alto bit rate: la differenza viene fatta dall'algoritmo. Non è quindi infrequente trovare degli ottimi codificatori ad un bit rate molto basso che codificano la voce con una qualità paragonabile al codificatore PCM64, standard della rete telefonica. E' vero invece che un'algoritmo particolarmente ottimizzato per la voce può trovarsi in grande difficoltà con altre tipologie di segnali, ad esempio la musica classica: algoritmi aggressivi si basano su determinate ipotesi (ad esempio che la voce umana non genera determinati tipi di frequenze) che possono essere disattese in caso di sorgenti di tipo diverso. La fase di codifica introduce il problema della potenza elaborativa richiesta per il processamento del dato, potenza che può diventare un ostacolo per la VoIP in quanto potrebbe significare l'adozione di una CPU con capacità (o di un chip DSP) non banali 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),

13 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). In particolare, quest'ultimo aspetto ha un'importanza fondamentale per gli operatori telefonici. Ad esempio, il codec G.729 (8Kbps) è ottimo per quanto riguarda la voce, ma non è adatto al trasporto di traffico di diverso tipo (ad esempio modem o fax). Tuttavia, in una rete telefonica quella che appare una telefonata potrebbe essere invece una chiamata fax, e in questo caso dovrebbe essere utilizzato il codec PCM64 per garantire la massima compatibilità con gli applicativi esistenti. Purtroppo però non è banale rendersi conto, in tempo reale, del fatto che una telefonata sia in realtà una chiamata vocale oppure un fax ed adottare il codec di conseguenza: pertanto nel caso di operatori telefonici si assiste spesso all'utilizzo generalizzato del codec PCM64 per garantire la massima compatibilità all'indietro, perdendo così uno dei vantaggi del VoIP, ossia il risparmio di banda Codificatori per VoIP A causa degli svariati campi di applicazione, sono stati sviluppatu diversi tipi di codec, caratterizzati da complessità differenti. Nel decidere quale utilizzare all'interno di una rete VoIP, è importante tenere conto in particolare delle sue caratteristiche in termini di occupazione di banda, di 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 gli operatori telefonici. 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 (Adaptive 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ù

14 approfondita del flusso del parlato prima di codificarlo: la qualità che si ottiene è equivalente a LD-CELP impiegando una banda circa dimezzata (8Kbps), 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 di potenza elaborativa e di consumo energetici propri dei codec, questi codificatori molto aggressivi sono utilizzati prevalentemente nel caso di interazione PC-to-PC, dove non sono presenti le limitazioni di cui sopra Soppressione dei silenzi Una tecnica che è spesso abilitata nei codec VoIP è la soppressione dei silenzi. Questa si basa su due semplici osservazioni: la maggior parte delle conversazioni telefoniche avviene in una modalità half duplex: solo uno dei due interlocutori parla, mentre l'altro ascolta; di conseguenza uno dei due canali (andata e ritorno) è normalmente inattivo la velocità con cui una persona emette dei suoni (cioè "parla") è decisamente limitata rispetto alle velocità degli elaboratori e ai tempi scelti per la pacchettizzazione. Il tempo tra due parole (e a maggior ragione quello tra due frasi) 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, il cosiddetto "fruscio di fondo". Sperimentalmente 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. Nel passato si verificavano alcuni casi in cui il tempo di riconoscimento dell'inizio del parlato era così elevato che, a riconoscimento avvenuto, il campione era ormai vecchio e la sua trasmissione risultava inutile in quanto sarebbe arrivato a destinazione fuori tempo massimo. In questo caso si verificava che la prima parte (ad esempio la prima sillaba) di una frase viene sistematicamente persa Cancellazione dell'eco

15 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 molto vicino alla bocca: questo è possibile (e consigliato) nell'interazione PC-to-PC, ma ad esempio è 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 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 necessaria aumenta ed è possibile che si introducano ulteriori ritardi. E' interessante notare come, nella telefonia classica, i sistemi europei non prevedano i cancellatori d'eco contrariamente a quello degli USA. Infatti, l'estensione geografica di un sistema telefonico, in europa, è tale per cui l'eco non è un fenomeno fastidioso e pertanto i cancellatori erano utilizzati solamente nelle telefonate transnazionali. Viceversa, l'estensione geografia del territorio degli Stati Uniti è tale che non si potesse fare a meno di questi componenti 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% in quanto un flusso voce a 64kbps genererebbe un traffico di ben 3.7Mbps. E' evidente come una prima soluzione per abbattere il costo (fisso) dell'header è quella di inserire più campioni nello stesso pacchetto. Ad esempio, inserendo 58 campioni da 1 byte l'uno si ottiene un'efficienza del 50%, con

16 un'occupazione di banda di 128kbps. Purtroppo, però, non è possibile fare il pacchetto grande a piacere, in quanto aumentando il tempo di pacchettizzazione si arriverebbe ad un valore troppo elevato di ritardo di recapito del pacchetto. Per capire questo problema si supponga, ad esempio, di generare un campione (grosso 1 byte) ogni 125us e che il tempo necessario a recapitare il dato a destinazione (ossia il ritardo di trasmissione del campione sul filo) sia di 10ms. E' evidente come il destinatario della comunicazione, nel caso in ogni pacchetto contenga un solo campione, riceverà i dati con un ritardo di 10,125 ms. 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 11,25 ms: 1,25ms necessari a riempire il pacchetto con 10 campioni, quindi altri 10 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. Nella pratica, valori di ritardo di pacchettizzazione ragionevoli sono dell'ordine dei 20-40ms Trasmissione del pacchetto sulla rete dati La trasmissione di dati su una rete a commutazione di pacchetto va incontro a delle incertezze maggiori rispetto alla trasmissione in modalità di commutazione di circuito. Fatto salvo il tempo di propagazione (ossia il tempo necessario affinchè il segnale si propaghi in un mezzo fisico, che è la massima velocità a cui possono viaggiare i dati in un mezzo fisico e pari solitamente ai due terzi della velocità della luce), che è un fattore da tenere in conto anche nella tecnologia a circuito, esistono altri due fattori che possono rallentare il proseguimento del pacchetto verso la destinazione Problematiche di accodamento Il fenomeno dell'accodamento si verifica nei nodi interni della rete (ad es. router) dati qualora la somma del traffico in ingresso che è diretto verso uno stesso link in uscita è maggiore della capacità del link. In questo caso una parte del traffico verrà memorizzato internamente al nodo e verrà smaltito con gradualità non appena il link in uscita è in grado di accettare 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

17 esame (ossia il traffico in ingresso dovrà essere sempre minore o uguale alla 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 che evita la situazione precedente grazie ad un meccanismo di prenotazione delle risorse adottando un sistema che risolva parzialmente il problema dell'accodamento, almeno per il traffico vocale, quale ad esempio inserire un percorso privilegiato per questo tipo di traffico. Il priority scheduling, che è una delle tecniche più utilizzate in pratica, consiste nella creazione di due percorsi di smaltimento dei dati all'interno dei router; 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. D'altro canto, l'attivazione di una tecnica di scheduling con accodamento a priorità non è sufficiente, da sola, a garantire un buon servizio al traffico vocale. Infatti, questa tecnica funziona solamente se la coda ad alta priorità è ragionevolamente libera, ossia se il traffico ad alta priorità è trascurabile rispetto al resto del traffico. Questo implica che il volume del traffico ad alta priorità dovrebbe essere tenuto sotto controllo, ad esempio con un opportuno monitoraggio del traffico immesso nella rete e questa condizione operativa può essere ottenuta solamente attraverso altri meccanismi aggiuntivi allo scheduling. In particolare, si supponga un Internet Service Provider (ISP) che fornisca ai suoi utenti servizi dati e fonia. Questo dovrà accertarsi che gli utenti non immettano nella rete traffico dati spacciandolo per traffico vocale (ad esempio settando ad arte il byte riservato al Type of Service nel pacchetto IP) nel tentativo di accaparrarsi le risorse migliori nella rete. L'ISP dovrà pertanto avere la cura di attivare dei filtri alla frontiera della sua rete in modo da fare eventualmente un re-marking (ad esempio impostare il campo TOS dei pacchetti IP in ingresso ad un valore neutro) del traffico in ingresso sulla sua rete, accertandosi che solamente il traffico vocale sia marcato ad alta priorità. Questa operazione potrebbe essere fatta in maniera ragionevolmente semplice qualora le sorgenti di traffico vocale fossero ben definito, ad esempio se questo fosse generato da opportuni gateway siti all'interno della rete stessa: a questo punto potrebbe semplicemente impostare il TOS dei pacchetti in uscita da questi oggetti ad un alto livello di priorità, lasciando tutto il resto del traffico ad un livello inferiore. In questo modo l'isp avrebbe relativamente buon gioco a tenere sotto controllo il traffico vocale, permettendo così allo scheduling a priorità di operare al meglio. Tuttavia, questo sistema di controllo dovrebbe essere notevolmente più complesso nel momento in cui si volesse permettere l'utilizzo di telefoni IP direttamente in casa dell'utente perchè a questo punto sarebbe l'utente stesso che genera sia traffico dati, che traffico vocale. In queste condizioni, l'isp si

18 troverebbe nella necessià di analizzare in dettaglio ogni singolo pacchetto generato dall'utente per determinare se questo è un pacchetto vocale (e allora dovrebbe essere trattato ad alta priorià) oppure un pacchetto dati (e allora dovrebbe essere trattato a bassa priorità, indipendentemente dal livello di marcatura presente in esso), con una notevole complicazione nella gestione della rete. Come si vede, le problematiche di qualità del servizio sono notevoli e non è questa la sede nella quale verranno discusse in dettaglio; la conclusione che se ne può trarre in questa sede è che se la rete è ben progettata, con uno scheduling a priorità vi è una ragionevole certezza per cui i pacchetti voce verranno inoltrati molto velocemente indipendentemente dal resto del traffico dati effettivamente presente sulla rete. Infatti, anche la tecnica del priority scheduling è solo una delle possibili soluzioni al problema dell'accodamento, è una delle più utilizzate grazie alla sua semplicità Problematiche di trasmissione Il sistema di priority scheduling illustrato nella sezione precedente lascia ancora scoperti alcuni problemi, ad esempio quelli di trasmissione. Si supponga infatti, che in router, in mancanza di pacchetti ad alta priorità, inizi la trasmissione di un pacchetto normale. Se, in 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. Infatti, il ritardo di trasmissione relativo ad un pacchetto P sarà (nel caso peggiore) il tempo di trasmissione relativo al pacchetto stesso (L/B, dove L è la lunghezza del pacchetto e B la banda del link) sommato al ritardo di trasmissione del pacchetto precedente, che nel caso peggiore è pari ad MTU/B, dove MTU è la dimensione massima dei pacchetti ammessi su quel link. Il ritardo di trasmissione può purtroppo assumere valori notevolmente alti. Ad esempio, in una normale ADSL con 256Kbps di upload, il ritardo di trasmissione minimo (quindi dovuto al pacchetto precedente, e non contando il tempo necessario a trasmettere il pacchetto ad alta priorità) è pari a 47ms, che è un numero decisamente alto in riferimento al budget di ritardo end-to-end ammesso in una telefonata. Dal momento che non tutti i pacchetti sperimenteranno questo ritardo (statisticamente alcuni pacchetti ad alta priorità dovranno fermarsi a causa della presenza di un pacchetto in trasmissione, ma altri troveranno il link libero), il risultato è un notevole aumento del jitter dei pacchetti. Le soluzioni a questo problema non sono molte. A parte il consiglio di utilizzare, ove possibile, link con molta banda (sui quali il

19 fenomeno si riduce) e limitare l'utilizzo di altre applicazioni durante una sessione vocale (ad esempio chiudere tutte le applicazioni che potrebbero generare dei dati mentre è in corso una telefonata), una possibile soluzione consiste nell'abilitare tecniche di PPP interleaving sul link, tecniche che (sebbene parzialmente proprietarie) consentono di "spezzettare" l'invio di un pacchetto IP. In questo modo permettono ad un pacchetto ad alta priorità di essere inviato prima del completamento della trasmissione del pacchetto precedente con un meccanismo simile al concetto di "prehemption" dei sistemi operativi 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 avrà un valore 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 un suo arrivo tardivo Riordinamento dei pacchetti Nonostante non sia un fenomeno altamente diffuso, esistono 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 prima 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 recapitarli 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 operazioni che, spesso, vengono trattati dal medesimo blocco.

20 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 codificatori). Normalmente la decodifica richiede meno risorse computazionali in quanto deve applicare un algoritmo predefinito. La fase di codifica può invece essere più onerosa in quanto spesso sono disponibili più tecniche di compressione e il codificatore deve decidere, in tempo reale, quale adottare per ottenere i risultati migliori Tecniche di correzione dell'errore Alcuni tipi di codifiche vocali prevedono esplicitamente la perdita di pacchetti e quindi il codec si comporta in maniera da limitare il problema. Esistono molte tecniche utilizzate, anche se sono tutte basate sul principio della ridondanza. Alcuni codec, ad esempio, prevedono la codifica di un 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 a bassa qualità contenuta nel pacchetto successivo a quello perso. Queste tecniche inseriscono però alcune problematiche: si ha aumento di banda per portare il campione degradato non funzionano nel caso di perdite "burst" di pacchetti (ossia quando si perdono più pacchetti consecutivi) tendono a peggiorare i valori di ritardo in quanto è necessario aspettare il pacchetto successivo per poter eventualmente generare il segnale vocale

21 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 end-to-end delay (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 in quanto più facile da quantificare. 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 codificatore) che le prestazioni della rete. L' ITU ha definito 3 fasce di ritardo end-to-end: dai 0 ai 150 ms. è accettabile per tutti i tipi di chiamata dai 150 ai 400 ms. è accettabile solo per collegamenti intercontinentali oltre 400 ms. è inaccettabile per comunicazioni vocali. Ritardi elevati possono creare alcuni disagi come 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

22 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 (normalmente limitata in valore assoluto) 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 giungono a destinazione sperimentando un tempo di attraversamento della rete anche di 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 scartati perchè il loro arrivo ritardato oltre una certa soglia risulta inutile. 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 troppo vecchi. 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 avrà un ritardo troppo elevato. Questa procedura permette di salvare banda perchè evita la trasmissione del pacchetto (in ritardo) sulla rete, occupando risorse, quando lo stesso verrà comuque scartato dal nodo ricevente. Un'altra caratteristica del traffico vocale è che, sebbene la banda richiesta sia tutto sommato modesta (esistono ottimi codificatori con bit rate di uscita pari a 5.3kbps), questa deve essere disponibile per una maggiore durata temporale. Infatti, le sessioni voce sono tendenzialmente più lunghe rispetto alle sessioni dati Perdite

23 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 e pertanto si pone solutamente la massima percentuale tollerabile di pacchetti persi in una sessione vocale pari al 5% del totale. Sotto questa soglia la qualità percepita dall'orecchio umano è ancora 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 con un ritardo che eccede una soglia massima. Dal momento che il ritardo end-to-end ha un'importanza molto maggiore rispetto alle perdite (in riferimento alla qualità della comunicazione percepita dall'utente), è decisamente preferibile accettare un numero di pacchetti persi maggiore rispetto ad accettare un più alto ritardo endto-end. Questa considerazione fa sì che, spesso, i componenti di de-jitter e di riordinamento dei pacchetti vengano dimensionati con "budget di ritardo" molto ridotti, preferendo quindi scartare pacchetti giunti oltre il ritardo massimo ammesso per non peggiorare le caratteristiche di interattività della comunicazione. 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, preservando il recapito delle informazioni maggiormente critiche Il trasporto della voce su IP: il protocollo RTP Il protocollo RTP (Real Time Protocol), specificato nella RFC 1889, definisce le modalità con cui sorgente e ricevitore possono scambiarsi dei dati per il trasporto di sessioni real-time con caratteristica di interattività, 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; tuttavia in questo caso la sincronizzazione

24 tra di esse (ad es. "quando si arriva al 5o minuto dell'audio, visualizza la slide successiva") deve essere fatta dall'applicativo (ad esempio usando il campo timestamp presente in RTP) stesso, in quanto questa funzionalità non è prevista all'interno del protocollo. 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 pertanto poste in documenti separati (chiamati Audio / Video Profiles) che definiscono il codice con cui sono identificati in RTP (nel campo PT). RTP non richiede obbligatoriamente un'infrastruttura IP: può essere potenzialmente trasportato su qualunque rete in quanto non è legato ad un particolare formato degli indirizzi. Richiede, però, che i protocolli di livello inferiore siano in grado di effettuare la frammentazione e il riassemblaggio dei pacchetti trasmessi. Nella maggior parte dei casi RTP si appoggia sui protocolli UDP/IP di cui sfrutta le operazioni di multiplazione e (se opportune) di controllo dell'errore. La specifica contenuta nella RFC 1889 affianca a RTP il protocollo ausiliario denominato RTCP (RTP Control Protocol) per monitorare la qualità del servizio, per fornire informazione sui partecipanti e per il controllo della sessione. Ogni connessione RTP/RTCP è caratterizzata da due porte UDP, la prima (che è sempre un numero pari) per l'rtp e la seconda (che è sempre la porta dispari successiva) per l'rtcp. 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. Su questa tematica, alcuni dettagli aggiuntivi verranno forniti dopo la presentazione dell'header RTP Il formato dell'header

25 L'header di un pacchetto RTP è composto da una parte fissa e un'estensione utilizzata per scopi sperimentali, di cui è in genere sconsigliato l'uso quando si possono inserire le informazioni aggiuntive nel payload RTP del pacchetto. La parte fissa dell'header si articola su 12 byte e contiene i seguenti campi: V (Version): indica la versione di RTP utilizzata. La versione contemporanea è la 2. P (Padding): se il bit vale uno, il pacchetto contiene almeno un byte addizionale di riempimento non facenti parte del payload, l'ultimo byte di padding contiene il valore di quanti byte padding sono presenti. X (extension): se impostato ad uno, indica la presenza di un'estensione dell'header. CC (CSRC Count): è il numero di CSRC presenti dopo la parte fissa dell'header. M (Marker): l'interpretazione di questo bit è legata al profilo. PT (Payload Type): identifica il contenuto del pacchetto, nel profilo è fissata staticamente la corrispondenza tra il codice e il formato del payload. Numero di sequenza: è incrementato di uno per ogni pacchetto inviato; può essere utilizzato dal destinatario per accorgersi della perdita di pacchetti e per ricostruire l'ordine corretto della sequenza. Timestamp: riflette l'istante di campionamento del primo ottetto dei dati. L'istante di campionamento deve essere derivato da un clock che si incrementa monotonamente e linearmente nel tempo per permettere i controlli di sincronizzazione e le misure dell'incertezza sugli arrivi dei pacchetti (arrival jitter). SSRC: identificatore della stazione trasmittente; spesso è posto pari all'indirizzo IP della sorgente. 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 RTP Mixer e multicast

26 RTP gestisce anche un'entità chiamata RTP Mixer. Questa entità è in grado di agire come un miscelatore 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 in modo da dar modo ai ricevitori di capire quali sorgenti sono state mixate. Il mixer è particolarmente utile nel caso in cui più sorgenti dotate della sola capacità unicast debbano colloquiare, in quanto permette di semplificare una topologia a maglia completa (da ogni sorgente ad ogni destinazione) con una topologia stellare (da ogni sorgente al mixer). Lo stesso schema può essere utilizato anche per far interoperare conferenze in cui alcune sorgenti hanno capacità multicast con altre unicast: in questo caso il mixer può agire in modo da trasformare il flusso multicast in un flusso unicast. In ogni caso, il mixer è comunque utile per diminuire i requisiti di banda anche in reti multicast. Infatti, il multicast risolve il problema dell'invio simultaneo di N flussi identici ad N destinatari, permettendo di ridurre la quantità di dati trasmessi ad un solo flusso. Questo è sicuramente un grosso vantaggio rispetto al caso in cui N utenti (tutti unicast) uniti in una conferenza devono generare un insieme di flussi tale da realizzare una maglia completa, con il risultato che ogni utente genera (N-1) flussi identici. Tuttavia, sia nel caso degli N utenti unicast, sia nel caso in cui questi siano dotati di capacità (e infrastruttura di rete) multicast, ogni nodo deve comunque ricevere (N-1) flussi dagli altri partecipanti. Questa soluzione richiede pertanto un notevole carico elaborativo sui client, in quanto gli (N-1) flussi sono normalmente inutili: banalmente, l'orecchio umano non è in grado di gestire più flussi contemporanei in maniera distinta e il tutto risulta un unico flusso pari alla composizione dei flussi componenti. Pertanto, la soluzione più efficiente è quella che fa uso di un mixer, la quale non solo risolve il problema di distribuire lo stesso flusso il trasmissione agli (N-1) partecipanti (problema già risolto anche con il multicast), ma permette di compattare gli (N-1) flussi in ricezione creandone uno solo e recapitando solamente questo ai vari destinatari. Un RTP mixer è sicuramente un punto critico della rete, sia dal punto di vista delle prestazioni che da quello dell'affidabilità. Tuttavia, se sull'ultimo punto c'è poco da dire, dal punto di vista delle prestazioni c'è da notare la situazione cambia relativamente poco rispetto agli approcci precedenti: nel caso di multicast ogni client riceve (N-1) flussi ed è il client stesso a dover procedere al mixaggio. Nel caso di mixer, il lavoro è identico, ma effettuato da una macchina sola (il mixer) anzichè fatto sugli N client. In aggiunta, tuttavia, il mixer deve gestire i flussi in uscita inoltrando il risultato del mixaggio ad (N-1) partecipanti, operazione non contemplata dai client classici RTP e porte dinamiche

27 Come evidenziato in precedenza, il protocollo RTP non prevede la definizione di porte "wellknown", il che rappresenta un grosso ostacolo al riconoscimento delle sessioni ai fini della sicurezza o della qualità del servizio. Il problema è dovuto al fatto che RTP non fornisce un meccanismo di multiplexing di più medium all'interno della stessa sessione. Infatti, il campo Payload Type (PT) ha un significato diverso da campi apparentemente simili quali il "protocol type" di altri protocolli. Infatti, il valore di questo campo può variare dinamicamente all'interno di una sessione, ad esempio a seguito di un cambiamento nel codec utilizzato da una sessiona audio (che commuta da un codec ad alta qualità ad uno a bassa qualità). A seguito di questo cambiamento, sarà l'applicativo che riceve il flusso RTP a doversi adattare alla nuova codifica. Inoltre, alcuni valori sono riservati ai "dynamically negotiated codecs", ossia quelle codifiche che vengono decise dinamicamente dagli applicativi e che vengono negoziate in una precedente fase di instaurazione della chiamata (ovviamente al di fuori di RTP), rendendo il valore di questo campo poco significativo se non accoppiato a queste informazioni ulteriori. Potrebbe pertanto accadere che due sessioni (una audio e una video), entrambe "dynamically negotiated", utilizzino lo stesso valore del campo PT. La conseguenza è che il campo PT non può essere utilizzato per discriminare due stream appartenenti alla stessa sessione RTP (ad esempio l'audio e il video, con due valori di PT diversi), ma questa discriminazione deve essere fatta esternamente all'rtp, ad esempio utilizzando porte UDP differenti. Tuttavia, dal momento che non è predicibile il numero di flussi RTP insistenti su un PC (audio, video, lavagna condivisa, etc.), non è possibile definire un insieme di porte "wellknown" e pertanto la specifica ha definito che le porte RTP siano dinamiche Modello generale di una rete 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 "telecom" e "enterprise" della VoIP Gateway tra la rete telefonica e la rete IP

28 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 spesso in tecnologia classica, oppure potrebbero utilizzare terminali IP con basse prestazioni, che rendono più conveniente effettuare una serie di operazioni all'interno della rete anzichè sul terminale utente. In alcuni casi ad esempio quando una delle parti è un terminale intelligente quale un PC, parte di queste funzionalità possono essere inserite nell'end-system Signaling Gateway

29 Questo componente si occupa dell'interfacciamento tra la rete IP e la rete telefonica 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. Tra le operazioni di segnalazione vi sono (tra le più importanti) 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 in una rete IP. 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 responsabile della connessione di controllo e il Media Gateway come il responsabile della connessione dati (audio). Ad esempio, la generazione del tono di libero (che è un segnale di controllo) richiede la generazione di una serie di pacchetti audio con determinate caratteristiche, ossia è un segnale appartenente al media stream 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) Server di supporto in reti omogenee

30 L'impiego di opportuni server, 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: in questo caso è necessario impedire che un utente illegale colleghi il suo telefono IP alla LAN aziendale ed inizi ad operare. 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 e sono orientate principalmente alla visione "telecom" della voce su IP Rete IP come backbone

31 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 sarà 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 controller 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.

32 Rete IP Il passo successivo è sicuramente la trasformazione di tutti i terminali utente in tecnologia IP. La rete adotta quindi una tecnologia omogenea. Tuttavia esiste ancora un problema, ossia la notevole mole di servizi di rete intelligente che sono disponibili nella rete telefonica. Per questi servizi, che si appoggiano a grossi server e a grosse basi dati), la migrazione alla tecnologia IP può non essere un'operazione semplice ed indolore. E' quindi pensabile che, almeno in un certo lasso di tempo, questi servizi richiedano ancora un'interfaccia di tipo telefonico almeno per la segnalazione. Questo scenario prevede quindi che per permettere le funzioni di rete intelligente sia ancora necessario un gateway tra la rete e i fornitori di questi servizi. L'ultimo passo è, ovviamente, la completa trasformazione della rete in tecnologia IP, dove con rete si intendono sia i terminali utente (e di conseguenza anche il trasporto), sia i servizi della rete intelligente 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 insieme di servizi prima disponibili semplicità e trasparenza: non deve appesantire inutilmente la rete e deve essere trasparente a livello utente.

33 Per quanto riguarda la segnalazione, sono state definite due architetture distinte: 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 Questi standard possono eventualmente coesistere su una rete, ma difficilmente cooperano: i gateway H.323-SIP sono molto complessi e poco usati in pratica. Nei pochi casi in cui questa integrazione sia richiesta, spesso la soluzione consiste nell'interfacciare i due mondi tramite la rete telefonica classica (PSTN) e interagire attraverso questa. Allo stato attuale, la suite di protocolli H.323 è l'unica soluzione standard adottata dai produttori di dispositivi per telefonia su IP e in generale per applicazioni multimediali, ed è supportata sia da applicativi PC (ad esempio il Netmeeting di Microsoft), che da dispositivi di rete (router) e da terminali utenti (IP Phone). La proposta SIP, però, sta incontrando sempre maggiore favore a causa della sia ottima integrazione con gli altri protocolli della suite TCP/IP (mentre H.323 nasce per una generica rete a pacchetto) e della sua maggiore semplicità, sia dal punto di vista del protocollo in sè, sia delle specifiche. Infatti, H.323 nasce in ambito telefonico dove le specifiche sono estremamente precise e complete ma anche estremamente complicate; inoltre ingloba, al suo interno, altri componenti precedentemente definiti dall'itu, cosa che ne aumentano notevolmente la complessità. Nonostante il notevole supporto di H.323, quindi, il mondo si sta orientando maggiormente verso SIP per tutte le nuove installazioni.

34 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

35 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 si interfaccia con 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 (PSTN, Public 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.

36 La MCU può non essere necessaria supporto multicast nativo. nel momento in cui la rete abbia il Zone Alla base della gestione è definita la zona come l'insieme di elementi H.323 (gateway, terminali e MCU) amministrati da un solo 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

37 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 quale TCP: H.225 e Q.931, che implementano i meccanismi per l'instaurazione e l'abbattimento di una chiamata attraverso le fasi di set-up, connect e release. H.245, che rappresenta il mezzo di comunicazione per lo scambio di parametri utili per lo svolgimento della chiamata, come ad esempio le informazioni sui media utilizzati. Protocolli che si appoggiano su un canale non connesso e quindi inaffidabile come UDP: RTP, che fornisce le funzionalità di trasporto end-to-end per applicazioni multimediali in tempo reale. RTCP, che implementa 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), che 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

38 Dispositivi dati: sovrintendono all'interazione di applicazioni dati (ad esempio la lavagna condivisa) attraverso il protocollo T.120 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 anche se non vengono coperti dalle specifiche 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 (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' è 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 in riferimento ai pacchetti di controllo Controllore RAS

39 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

40 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: 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

41 Un gateway possiede le caratteristiche di un terminale H.323 sulla rete dati e le caratteristiche di un terminale telefonico tradizionale sulla rete PSTN; 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. 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 si intendono 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

42 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 indirizzi: la coppia indirizzo di rete / identificatore TSAP, e gli indirizzi alias Indirizzi di rete e identificatori TSAP Ogni dispositivo H.323 deve possedere almeno un indirizzo IP per poter essere raggiungibile 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

43 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 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

44 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 sul 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. 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 il gatekeeper è in grado di rilevare eventuali terminali inattivi e pertanto impedire il tentativo di instaurazione di chiamate verso un terminale inesistente. Inoltre, il Gatekeeper si

45 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 chiamata; 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 overhead di controllo Instaurazione di una chiamata 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.

46 Chiamata diretta tra due terminali La fase di call setup inizia quando c'è la richiesta, con un messaggio Q.931 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 (che verrà presentato nella sezione seguente). 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 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.

47 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 (Disengage Request) all'altro endpoint (attraverso il gatekeeper) 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-toend Instradamento dei messaggi di controllo

48 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

49 La chiamata può essere terminata da un endpoint o da un Gatekeeper e viene abbattuta seguendo questi passi: l'endpoint chiude il canale logico relativi ai flussi multimediali; a questo punto trasmette il messaggio (all'endpoint con cui ha una chiamata attiva attraverso il canale logico di controllo H.245) di endsessioncommand per chiudere il canale di controllo stesso aspetta 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.

50 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 definito 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.

51 Anche se la suite SIP specifica numerosi protocolli (d'altro canto l'instaurazione, ad esempio, 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 far sì 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 largamente 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 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, può utilizzare protocolli come SAP (eventualmente in multicast) per l'annuncio di sessioni multimediali. Per quanto riguarda la segnalazione, questa è di tipo end-to-end, ossia tra terminale chiamante e terminale chiamato, senza l'interazione esplicita con i nodi di rete. Questo significa che i router non hanno nessuna conoscenza di una eventuale fase di segnalazione in atto (trattano i pacchetti SIP come normali pacchetti IP) con la conseguenza di aumentare la scalabilità di questo approccio. 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 clientserver, 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, semplicità di funzionamento e di implementazione (caratteristica fondamentale in dispositivi con ridotte capacità elaborative e di memoria) e la possibilità di sfruttare il multicast, mentre TCP offre un servizio connesso utile per il passaggio, ad esempio, attraverso i firewalls. Per quanto riguarda l'efficienza, 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

52 caso, anche con UDP SIP garantisce l'affidabilità dei messaggi definendo meccanismo di three-way handshake (Request, Response, Ack). un Infine, SIP può funzionare anche su TLS, ossia su una connesisone TCP cifrata. Questa modalità di funzionamento è indispensabile nel momento in cui sia fondamentale garantire la sicurezza della transazione (autenticazione + cifratura), ma in questo caso si perde uno dei vantaggi fondamentali del protocollo, ossia i messaggi testuali, inviati in chiaro sulla rete, che garantiscono una notevole facilità di debugging. Peraltro, questa modalità è attualmente ben poco usata anche perchè molti dispositivi, soprattutto quelli embedded, non la supportano per le notevoli risorse necessarie al suo funzionamento. 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. Questa caratteristiche potrebbe diventare critica in futuro dal momento che, da più parti, si tende ad estendere l'header SIP con nuove funzioni o utilizzare questo protocollo in ambiti non originariamente previsti, ambiti che richiedono un maggior numero di dati da inviare Servizi offerti da SIP Nonostante SIP sia un protocollo di segnalazione e possa essere utilizzato per instaurare un notevole numero di servizi, in pratica lo sviluppo è estremamente polarizzato verso le chiamate VoIP. In questo campo SIP può vantare una buona maturità nel numero di funzioni supportate (quante di queste sono poi efficacemente implementate nei prodotti commerciali è però ancora da vedere), e anche il supporto di e-presence (notifica dello stato di un utente, etc) e di instant messaging è accettabile (ma migliorabile), anche se non a livello di altri standard dedicati (es. Jabber). Invece, sono fortemente lacunose le specifiche (e a maggior ragione le implementazioni) relative a file transfer (il trasferimento di file da un utente all'altro) e alla lavagna condivisa, per cui spesso è necessario ricorrere ad altri strumenti nel caso di funzionalità specifiche. SIP inoltre può supportare, in linea di principio, anche la segnalazione relativa a giochi interattivi, ma anche in questo caso non si conoscono implementazioni. Non esiste una ragione tecnica per il mancato sviluppo di alcune direzioni della specifica: l'unica ragione è il fortissimo interesse commerciale nel settore VoIP che ha polarizzato tutti gli sforzi di sviluppo in quella direzione. Inutile dire quanto questa politica sia stata miope dal momento che a questo punto potrebbe diventare problematica l'affermazione per cui la migrazione di una rete telefonica ad una tecnologia IP è giustificata principalmente dal numero di servizi a valore aggiunto che è possibile implementare... che sono stati vistosamente trascurati nella standardizzazione. Tra il resto, questa polarizzazione ha anche fatto tralasciare alcuni aspetti importanti (ma non "mainstream") proprio nel settore VoIP: ad esempio, il supporto di conferenze multiple è ancora alquanto lacunoso Servizi principali nel caso di chiamata VoIP

53 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. Caratteristiche principali dell'architettura SIP La pila protocollare SIP La pila protocollare SIP è decisamente variegata e prevede l'utilizzo di numerosi componenti. Da questo 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. Per quanto riguarda la parte audio/video, i protocolli utilizzati sono esattamente gli stessi implementati in H SDP

54 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, il tempo di inizio / fine del flusso stesso, e altri. In generale, alcuni dei parametri specificati da SDP non sono significativi quando utilizzato nell'ambito di SIP in quanto alcuni sono duplicazioni di omologhi campi già previsti in SIP, altri sono inutili in relazione all'ambito di impiego di SIP per la segnazione relativa a sessioni vocali. Tuttavia, il protocollo SDP viene mantenuto senza variazioni per poter sfruttare il codice (decisamente collaudato) già esistente. Ad esempio, il tempo di inizio/fine del flusso SDP è significativo nel caso nel caso di media streaming (ad esempio si potrà annunciare che un concerto dal vivo inizia alle ore 21.00) e nel caso di "invito" ad una conferenza, specificando quindi l'ora di inizio e quella di fine, ma non ha molto senso nel caso di una telefonata classica. In aggiunta, molti di questi parametri sono ignorati dall'applicazione che non è pertanto in grado di leggerne (e scriverne) il valore. Anche SDP, come SIP, definisce un formato testuale per i messaggi; il messaggio SDP è incluso come parte finale di un messaggio di SIP INVITE 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).

55 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'indirizzo 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. SDP Può essere facilmente esteso sia definendo nuovi attributi, sia utilizzando l'attributo "a=", che però può essere utilizzato solamente in riferimento ai flussi media. Ad esempio, la specifica RTP/AVP specifica un insieme di codifiche che possono essere definite dinamicamente; in altre parole, mentre il valore "3" nel campo di codifica dei media corrisponde univocamente alla GSM, il valore 100 non ha un mapping univoco e può essere pertanto utilizzato per decidere la codifca a run-time. In questo caso può succedere che una riga m" " dell'header SDP specifichi l'utilizzo di un codec (il valore contenuto nel campo Payload Type dell'header RTP) dinamico, indicando che verrà utilizzato per esso il valore X (ad esempio 100). Nella riga successiva del pacchetto SDP (riga a") " verrà quindi specificato il mapping effettivo di questo codec, ad esempio VDVI/ 8000, e così via. L'elenco degli attributi ammessi in SDP è riportato in figura Esempio di messaggi SDP 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

56 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 seguito: del campo e un suo esempio di utilizzo sono riportati di <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 Componenti principali di una rete SIP

57 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 Registrar Server Il Registrar Server implementa il servizio di registrazione degli utenti all'interno della rete SIP. Esso è il primo server SIP ad essere contattato dall'utente, il quale devei registrare la sua presenza in modo da segnalare alla rete SIP il suo attuale mapping SIP username - indirizzo IP. Questo server riveste pertanto un'importanza fondamentale in quanto è quello che deve essere obbligatoriamente presente sulla rete per poter fornire il servizio di localizzazione dell'utente. Grazie a questo fatto, viene normalmente chiamato "SIP server". Il Registrar Server è normalmente anche tenuto ad implementare meccanismi di autenticazione; l'identità di chi si registra può essere verificata sia localmente, sia attraverso un server apposito (il server AAA) che presenta il vantaggio di poter implementare un unico schema di autenticazione all'interno del dominio di rete (single sign-on) Proxy Server

58 La funzione del proxy server è quella solita, ossia un oggetto a cui è possibile delegare in toto la gestione della chiamata. Vista la sua funzione, viene spesso chiamato SIP Outbound Server. Questo server riceverà una richiesta SIP da parte di un SIP UA e dovrà effettuare tutte le operazioni necessarie per portare a destinazione il messaggio, ad esempio localizzare il dominio destinazione, localizzare il relativo SIP server, quindi inoltrare il messaggio a quello stesso server. 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 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 Media Proxy Normalmente i pacchetti appartenenti alla sessione vocale originata da una sessione SIP sono inviati in maniera diretta dall'ua sorgente a quello destinazione, e questa soluzione permette di minimizzare il round-trip time della chiamata. Tuttavia, in alcuni casi non è possibile (o non si vuole) inoltrare il flusso vocale in maniera diretta tra i due UA, e a questo punto la chiamata viene

59 rediretta da un UA ad un Media Proxy che si incarica di inoltrare i pacchetti verso lo UA destinazione. Tra i casi in cui questa soluzione si rende necessaria, un esempio è la necessità di colloquiare con UA posti in reti private (anche se in alcuni casi particolari è la chiamata diretta è ancora possibile), oppure la necessità di garantire una efficace intercettazione delle chiamate (nel qual caso avere un punto di concentrazione delle chiamate rende l'operazione di intercettazione molto più semplice in quanto il meccanismo di intercettazione va implementato semplicemente in quel punto). Il Media Proxy è pertanto un server che riceve i pacchetti RTP relativi alla sessione vocale e li inoltra, con il proprio indirizzo IP sorgente, alla macchina destinazione. In certi casi la macchina destinazione è ancora un secondo Media Proxy (può succedere quando ambedue i domini, sorgente e destinazione, richiedono l'uso di un Media Proxy), il quale li inoltrerà verso lo UA destinazione 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 PSTN Gateway Questo server realizza la funzione di interconnessione tra la rete SIP e la rete VoIP; il suo compito è quello di tradurre sia la segnalazione che i campioni vocali da una tecnologia all'altra. Questo gateway è presente in tutte le soluzioni VoIP per permettere l'interoperabilità delle soluzioni di telefonia tra le varie reti Multi Conference Unit

60 E' un oggetto in grado di realizzare chiamate tra 3 o più persone trasformando la topologia virtuale in una stella, al cui centro viene posta la MCU. Analogamente ad H323, la MCU ha la possibilità di elaborare i flussi multimediali (mixing, switching) per meglio gestire la conferenza. La Multipoint Control Unit può essere pertanto vista come l'insieme di due componenti logicamente distinti: Multipoint Controller (MC): componente il cui compito è quello di controllare il processore dei dati (multipoint processor) fornendo l'intelligenza necessaria all'elaborazione. In particolare, è colui che decide se cancellare alcuni flussi (ad esempio perchè quegli utenti non stanno parlando), se cambiare il bitrate (eventualmente negoziando questo cambiamento con altre entità SIP nella rete), etc. Multipoint Processor (MP): componente il cui compito è quello di elaborare i pacchetti a seconda della logica impostata dal Multipoint Controller. Tra le funzionalità di questo oggetto vi è la possibilità di mixing / switching dei flussi video, voce e dati. 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 è sostanzialmente un RTP Mixer e pertanto, non perde di significato nel momento in cui tutti i partecipanti utilizzino comunicazioni multicast; a questo proposito, si vedano le osservazioni fatte per gli RTP Mixer nell'apposita sezione Consolidamento dei server Normalmente il numero di server presenti in una rete SIP è decisamente inferiore a quelli elencati. Infatti, l'elenco comprende tutti i servizi necessari alla rete per poter funzionare in completezza. In una rete reale alcuni molti servizi potrebbero essere disabilitati, mentre altri servizi vengono consolidati sulla stessa macchina fisica. Ad esempio, normalmente Registrar Server, SIP Proxy e Redirect Server sono inglobati sulla stessa macchina, e spesso anche il Media Proxy è incluso (per lo meno in piccole e medie installazioni). Per altri servizi si utilizzano server già esistenti, ad esempio il DNS per il location server, e il server di autenticazione già presente sulla rete aziendale per il Server AAA.

61 L'architettura distribuita di SIP L'architettura di una rete SIP, vista su scala globale, assomiglia molto all'architettura del servizio di posta elettronica (SMTP). La rete è scomposta in domini SIP, legati al dominio DNS. Così, secondo l'esempio, i domini polito.it, unito.it e google.com sono domini SIP distinti. Questo equivale a dire che ogni dominio è responsabile dell'implementazione del servizio (che può avvenire anche in modalità diverse da dominio a dominio), ed è responsabile dei propri utenti dal momento che, come si vedrà in seguito, ogni utente sarà identificato da un nome nella forma Ogni utente sarà pertanto associato ad un dominio attraverso un legame logico, indipendente dalla sua locazione fisica. In altre parole, l'utente non deve necessariamente trovarsi nella rete fisica di google.com per poter usufruire di questo nome. L'utente in questione potrebbe essere collegato alla rete Internet con un indirizzo IP qualunque; quello che è importante è che l'utente dovrà comunque fare capo ai server presenti nel suo dominio (tranne poche eccezioni) per poter usufruire appieno del servizio SIP, secondo un principio analogo per cui una macchina con nome non necessariamente deve trovarsi nello spazio di indirizzamento IP rilasciato a Google. La natura distribuita dell'architettura ha un impatto positivo sia sulla scalabilità (ogni dominio gestisce i suoi utenti, pertanto non vi è la presenza di un single point of failure a livello mondiale così come altre architetture, ad es. Skype), sia sulla gestibilità / privacy della soluzione. Ad esempio, lo stato di ogni utente (attivo / spento) viene mantenuto dal Register Server del dominio di appartenenza e non viene (a meno di esplicita volontà da parte dell'utente) fatto conoscere a terzi. Con una soluzione completamente centralizzata (es. Skype), il gestore del servizio ha la possibilità di conoscere un certo numero di dati personali dell'utente e non è detto che li utilizzi sempre a fin di bene. Inoltre, ogni dominio può definire le sue modalità e le sue credenziali per accedere al servizio: alcuni utenti potrebbero offrire il servizio a tutti, indistintamente, mentre altri potrebbero decidere di limitarlo a determinate categorie di utenti (es. il servizio SIP viene dato al personale docente ma non agli studenti, etc.). Il problema da risolvere, a questo punto, è quello di definire un meccanismo efficiente per l'interconnettività tra i vari domini. Nel caso del servizio di posta elettronica, l'interoperabilità è garantita attraverso l'implementazione dei record MX (Mail Exchange) all'interno del DNS; in questo caso dovrà essere implementato un qualche servizio equivalente che permetta di determinare, a partire dal nome del dominio, gli indirizzi IP dei server SIP principali a cui è necessario rivolgersi per poter completare una sessione SIP Indirizzamento SIP

62 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 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 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 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

63 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 Interconnessione di domini SIP Configurazione dei server DNS 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.

64 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 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 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. TTL 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. Class Rappresenta la classe "Internet", quindi è sempre IN. SRV 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 Porta a cui il server è in ascolto per quel particolare servizio (nell'esempio la 5060). Target 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.

65 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 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. Class 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

66 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 normalmente tutti i record NAPTR vengono configurati con la stessa preferenza, in quanto l'eventuale bilanciamento del carico viene fatto attraverso i record SRV. Flags 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

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

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

69 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 Scenari di chiamata con ENUM

70 Lo standard ENUM nasce inizialmente per permettere ad un telefono tradizionale (sulla PSTN) di contattare un utente SIP. In questo scenario, l'utente digita il numero di telefono E.164 e sarà cura del VoIP gateway a tradurre tale numero in un URI SIP attraverso l'interazione con il DNS (sia per risolvere il numero E.164 in un indirizzo SIP, sia per localizzare il server SIP relativo al dominio target) e con i relativi server SIP. Un problema aggiuntivo si presenta quando questo standard viene utilizzato per chiamate IP - IP: spesso, in questo caso i softphone utilizzano un meccanismo di autocompletamento del numero telefonico con l'aggiunta del dominio di riferimento per cui, a fronte della digitazione di un certo numero (ad es ) viene generata automaticamente una chiamata verso un URI comprensivo dell'indicazione del dominio (es. Il SIP server incaricato della risoluzione potrà accorgersi della presenza dell'identificatore E.164 grazie al fatto che l'uri inizia con il carattere "+": a questo punto, il SIP server potrà essere configurato per ignorare l'informazione di dominio e tradurrà il numero iniziale attraverso la procedura prevista dallo standard ENUM. Nel caso in cui uno UA sia compatibile ENUM, potrebbe essere egli stesso a procere con la risoluzione ENUM senza interessare alcun SIP proxy, tralasciando pertanto l'aggiunta del suffisso di dominio. Pertanto, ai fini dello standard ENUM, un qualunque numero telefonico E.164 oppure URI SIP iniziante con il carattere "+" deve essere risolto attraverso questo standard; in ogni caso, è possibile personalizzare il comportamento di un server SIP a riconoscere numeri brevi (es. attraverso opportune direttive in modo da facilitare la digitazione di numeri brevi da parte dell'utente 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).

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

72 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. Nel caso in cui questa risoluzione non fosse possibile (il dominio ENUM richiesto non esiste), allora la telefonata viene inoltrata verso il voice gateway predefinito I messaggi SIP In questa sezione verranno presentati i principali messaggi del protocollo SIP Struttura dei messaggi SIP 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 REGISTER

73 Questo messaggio è utilizzato da un client per registrare un indirizzo all'interno di un SIP server; questa registrazione può essere fatta da diversti UA contemporaneamente. 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 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. Il server a cui effettuare la registrazione può non essere dichiarato esplicitamente: per mezzo di opportune interazioni con il DNS (le stesse effettuate all'atto dell'instaurazione di una chiamata) lo UAC può risalire al server nel quale registrarsi a partire dal dominio di appartenenza dell'utente stesso (es. polito.it). Un utente può inoltre registrarsi su diversi siti, usando diversi valori di Call-ID, e definire vari servizi e preferenze tra questi. SIP prevede che ogni dominio debba avere un server di registrazione distinto, creando una infrastruttura decisamente più scalabile rispetto ad altre soluzioni concorrenti (es. MSN, Yahoo, Skype,...) 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 concludere la transazione iniziata da 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. 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

74 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 pendente, ed è utilizzabile solo nella fase di apertura della connessione. Esistono numerosi casi in cui è pensabile generare un messaggio CANCEL. Lo UA squilla, ma l'utente non risponde. Nel caso in cui il chiamato squilli, ma l'utente non risponda alla telefonata, il chiamante può decidere dopo un certo tempo di interrompere una chiamata attraverso un messaggio CANCEL. Cancellazione di richieste pendenti a seguito di "forking" da parte di un proxy server. SIP ammette l'invio di una richiesta di INVITE verso più terminali contemporaneamente (ad esempio il telefono d'ufficio e il telefono mobile), solitamente gestite dal proxy server. Nel momento in cui una delle due richieste viene accettata e il pacchetto di ACK torna al server (il quale lo inoltrerà 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. Risposta negativa da uno UA, in caso di "forking" da parte di un proxy server. Nel caso in cui un SIP proxy duplichi un messaggio di INVITE e, a seguito di questo, riceva un rifiuto da uno dei due UA contattati (messaggio BYE), il proxy trasformerà questo messaggio in un CANCEL comunicando al chiamante che una possibile via di connessione è fallita, ma altre stanno ancora operando per portare a termine la chiamata. 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 OPTIONS

75 Il metodo OPTIONS può essere utilizzato per richiedere informazioni sullo stato di uno UA, 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 SUBSCRIBE, NOTIFY Questo metodo è utilizzato nel caso in cui SIP venga impiegato per la gestione dell'e-presence. Questo metodo permette ad uno UA A di comunicare la volontà di sottoscrivere lo stato dl un UA B. Questo metodo è utilizzato in accoppiata con il metodo NOTIFY, che è incaricato di trasportare effettivamente lo stato dello UA remoto. In altre parole, i messaggi SUBSCRIBE e NOTIFY sono sempre abbinati in quanto il primo definisce la volontà di conoscere lo stato di un utente remoto, mentre il secondo messaggio comunica lo stato stesso. Questi messaggi possono essere recapitati sia allo UA remoto (nel caso il dominio SIP gestisca l'e-presence in modalità peer-to-peer), oppure ad un e-presence server centralizzato, che si incarica di mantenere lo stato di tutti gli utenti del dominio MESSAGE Questo metodo si integra con i metodi precedenti e realizza la funzionalità di instant messaging, permettendo di recapitare ad un UA remoto un messaggio di testo I principali campi dell'header From, To

76 Indicano l'originatore e il terminatore della sessione SIP. I nomi indicati sono indirizzi 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 Contact Il Contact header è di fondamentale importanza per riuscire ad instaurare un dialogo diretto tra due UA. Infatti, SIP prevede che, qualora sia possibile, sue UA debbano iniziare a scambiarsi non solo i flussi media direttamente, ma anche i pacchetti SIP in modo da non sovraccaricare i SIP server. Pertanto, questo header è utilizzato per comunicare allo UA remoto l'indirizzo IP dello UA locale in modo che i due possano scambiarsi pacchetti SIP direttamente 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. E' possibile anche il caso di un UA che inserisce un header VIA: ad esempio, uno UA con due indirizzi IPv4 potrebbe inserire un header VIA contenente il secondo indirizzo IPv4 (non quello sul quale e' stato contattato) in modo da forzare il recapito del messaggio su un indirizzo diverso (e magari migliore) Record Routing

77 Questo header viene eventualmente aggiunto dai server SIP nella fase di inoltro di un messaggio SIP ed indica agli UA che i messaggi non dovranno mai essere scambiati direttamente (cosa permessa dal campo Contact) ma dovranno sempre passare attraverso i proxy stessi. Questo messaggio può essere utilizzato sia per controllare il contenuto dei pacchetti SIP, sia per garantire una migliore connettività nel caso in cui uno (o ambedue) gli UA abbiano indirizzamento privato, nel qual caso non potrebbero essere in grado di scambiarsi i pacchetti in modalità diretta 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 URI, formato da un numero identificativo progressivo e dal dominio in cui questo valore è stato calcolato. Il Call-ID rimane costante per tutta la sessione; 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); tuttavia questo corrisponde di fatto ad aprire una nuova sessione Cseq Il campo Command Sequence include il comando relativo ad una transazione SIP e viene mantenuto per tutta la sua durata. In altre parole, tutti i messaggi conseguenti ad un messaggio INVITE (ad esempio il 180 RINGING, ma anche il 200 OK e, ovviamente, lo stesso messaggio di INVITE) avranno questo parametro pari al valore 1 INVITE. Questo campo cambierà al primo messaggio di una nuova transazione, ad esempio il messaggio ACK Subject Il campo Subject ha il significato a cui si è già abituati ed indica lo scopo della sessione Content-Type, Content-Length, Content-Encoding

78 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 Provisional (meglio conosciuta come Informational)

79 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. Le risposte di tipo 1xx attualmente definite sono indicate in figura 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

80 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. Le risposte attualmente definite sono indicate in figura 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). In ogni caso, la stessa richiesta potrebbe aver successo presso un altro server. Le risposte attualmente definite sono indicate in figura Server-Error

81 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. Le risposte attualmente definite sono indicate in figura 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. Le risposte attualmente definite sono indicate in figura Esempio di messaggi

82 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 Transazioni e Dialoghi Prima di poter illustrare le varie fasi di una chiamata SIP, è opportuno definire i concetti di transazione e di dialogo. Una transazione è composta da una richiesta e dalla corrispondente risposta; risposte del tipo 2xx sono risposte terminali e chiudono una transazione. Ad esempio, in figura sono riportate le transazioni T1 e T2. Tutti i messaggi appartenenti ad una stessa transazione SIP contengono contenere gli stessi valori nei campi di Call-ID, CSeq, To, e From. Una transazione particolare è il messaggio ACK in quanto non richiede risposte. Un dialogo è una relazione tra UA che iniziano quando una risposta a carattere positivo è ricevuta dallo UA iniziale. Ad esempio, in figura è mostrato un dialogo che viene instaurato a seguito di un messaggio di INVITE, il quale è tuttavia al di fuori del dialogo stesso. I messaggi SIP appartenenti ad un dialogo sono caratterizzati dall'essere inviati direttamente dallua mittente all'ua destinazione senza in passaggio intermedio attraverso un proxy, a meno che nell'instaurazione del dialogo sia stata specificata l'opzione "Record Route", che forza i messaggi SIP a ripercorrere esattamente la stessa via dei messaggi iniziali. La comunicazione diretta tra i due UA è possibile attraverso il campo contact dell'header SIP, il quale fornisce il modo per conoscere l'indirizzo IP dello UA remoto. Ad esempio, lo UA chiamato conosce l'indirizzo del chiamante tramite il messaggio di INVITE, mentre il chiamante lo scopre attraverso il messaggio 200OK Risoluzione di un indirizzo SIP

83 Questa procedura si riduce alla ricerca di un certo server SIP. Infatti, sia che si debba ricercare un certo utente (ad esempio in un messaggio di INVITE), sia che si debba fare una registrazione (messaggio REGISTER), questa procedura permette di ricavare l'indirizzo IPv4/IPv6 associato al server SIP responsabile di un certo dominio. Quando 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 trasporto. 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, inserendo tutte le risposte nella sezione "Additional Records" del pacchetto DNS. 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

84 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 indicata in figura. Questa risposta indica che il server supporta TLS su TCP, TCP e UDP, nell'ordine di preferenza indicato. 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à richiedendo la risoluzione del record _sip._tcp.foo.com, di tipo SRV, ottenendo la seconda risposta riportata in figura. 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 Registrazione di un UA SIP La registrazione è effettuata con il messaggio SIP REGISTER. Tuttavia, la procedura è relativamente arzigogolata a causa della necessità (peraltro opzionale) di autenticare la registrazione stessa. Lo UA cerca prima di registrarsi presso il SIP registrar (che corrisponde normalmente al SIP proxy) in maniera autenticata. Se questa operazione è ammessa, il server risponde con un messaggio 200 OK e la procedura termina. Se, come in figura, il server richiede una registrazione autenticata, il messaggio risponde con un errore 401 (Client Error, Unauthorized) indicando una chiave da utilizzare per la successiva antenticazione. A questo punto, lo UA genererà una nuova autenticazione, aggiungendo agli header SIP una nuova riga che contiene la stringa di autenticazione, calcolata in base alla coppia username/password e alla chiave che è stata ricevuta precedentemente dal server. Il server controllerà la validità della registrazione e risponderà quindi con un messaggio 200 OK.

85 La procedura di autenticazione è necessaria sia per evitare furti di identità, sia per verificare che sia abbia effettivamente diritto di accesso alle risorse della rete SIP. In particolare, una risorsa è l'accesso al gateway SIP-PSTN che, essendo una risorsa a pagamento, viene normalmente resa disponibile solamente agli utenti autorizzati del dominio stesso (e normalmente ogni dominio ha il proprio gateway). La procedura di localizzazione del server SIP nel quale fare la registrazione è la stessa che si usa per altre procedure SIP, ossia un set di query NAPTR, SRV e A/AAAA. Pertanto, lo username dell'utente è dato in termini di username (es. bob) e di dominio (normalmente indicato come "realm") di appartenenza (es. foo.com) Il trapezoide di SIP L'inoltro di messaggi SIP per una chiamata complessa (ad esempio un messaggio di INVITE) viene schematizzato da quello che viene denominato il trapezoide SIP. Infatti, questa figura rende l'idea di come alcuni messaggi vengano inoltrati sulla parte superiore del trapezoide (quindi dall'ua chiamante al proprio SIP server, quindi al SIP server del dominio di destinazione, quindi all' UA chiamato), mentre altri, quelli che vengono scambiati quando il dialogo è già stato instaurato, vengano recapitati direttamente tra UA e UA. In particolare, in Figura è riportato un esempio di chiamata con Proxy Server. Il server proxy accetta l'invite request (1), attiva una procedura di location process per ottenere l'indirizzo del server del dominio di destinazione, inoltra il messaggio al server ottenuto al passo precedente, il quale determina l'indirizzo IP dello UA chiamato ed inoltra la chiamata allo stesso (passo 4). Nel contempo, i proxy server generato un messaggio di tipo "informational" all'indietro (i messaggi 100 TRYING dei passi 3 e 5) per informare dell'avvenuta ricezione del messaggio e del fatto che il suo processamento è in corso.

86 Lo UA chiamato genera un segnale per l'utente (ad esempio lo squillo del telefono), generando un nuovo messaggio di tipo information (180 RINGING) che viene ripropagato all'indietro (6, 7, 8). Nel momento in cui il chiamato risponde all'invito, viene generato un messaggio 200OK che chiude la transazione (9, 10, 11). Tutti questi messaggi sono inviati attraverso i proxy grazie alla presenza di opportuni header via all'interno dei messaggi SIP in modo da ripetere (al contrario) esattamente il percorso dei messaggi di andata e "garantire" pertanto il loro recapito al mittente. Infatti, la comunicazione diretta UA-UA potrebbe non essere possibile (ad esempio nel caso in cui almeno uno dei due sia dietro un NAT), mentre la comunicazione attraverso i proxy non dovrebbe avere problemi. La ricezione del messaggio 200 OK è confermata dal chiamante usando un messaggio di tipo ACK (12) che viene normalmente inoltrato in maniera diretta; tuttavia, è obbligatorio il passaggio attraverso i proxy nel caso in cui questi abbiano impostato l'opzione Record Route nei messaggi precedenti. L'invio di messaggi diretti tra UA e UA rende impossibile l'implementazione di funzionalità di controllo di banda nel SIP proxy, in maniera simile all'analoga funzionalità di H.323, peraltro non contemplata da SIP. Il primo messaggio potrebbe essere inviato direttamente dallo UA chiamante verso il SIP proxy del dominio di destinazione qualora il primo fosse in grado di risolvere autonomamente le query al DNS e individuare l'indirizzo IP associato al server in esame. Tuttavia, questa procedura si presta a problemi di autenticazione: il SIP proxy del dominio target non ha la possibilità di verificare l'identità del mittente. Pertanto, i SIP proxy tendono ad accettare messaggi provenienti soltanto da sorgenti "trusted", e quindi provenienti da un altro server proxy che, molto probabilmente, avrà a sua volta fatto le necessarie verifiche dell'identità del chiamante 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 Denial-ofservice 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 Conclusioni

87 L'enfasi verso il protocollo SIP è notevole e molte nuove installazioni di reti VoIP adottano questo standard. Tuttavia, anche se le sue funzionalità non sono sicuramente inferiori a H.323, esistono ancora numerosi problemi da risolvere. In primis, un primo problema è l'enorme interesse commerciale in questo protocollo; se da un lato questa è uan cosa positiva, dall'altra rende la standardizzazione molto più critica a causa dei notevoli interessi in gioco. Pertanto, si incontrano sia problemi di standardizzazione (ad esempio dovuti a diverse cordate concorrenti), sia implementazioni pre-standard, incomplete, o fuori standard del tutto. Tra i principali problemi tecnici da risolvere vi è sicuramente quello della fatturazione (addebitare ad un certo utente l'utilizzo di una determinata risorsa, ad es. un PSTN gateway), quello dell'interazione tra IPv4 e IPv6 (critico nel momento in cui un telefono UMTS, probabilmente IPv6, dovrà chiamare un client IPv4), quello del supporto di NAT e firewayy (che inizialmente non si voleva prendere in considerazione e si è dovuti correre ai ripari con l'avvento di soluzioni alternative), e la qualità del supporto dell'instant Messaging e dell'e-presence, che e' molto limitata rispetto ad altre tecnologie concorrenti. Anche se la tecnologia SIP non può essere ancora considerata matura, le nuove caratteristiche aggiuntive rispetto ad H.323 la fanno sicuramente preferire a quest'ultima.

Capitolo 1. Voce su IP: i concetti fondamentali

Capitolo 1. Voce su IP: i concetti fondamentali 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

Dettagli

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Guida alla scelta della centrale telefonica

Guida alla scelta della centrale telefonica Guida alla scelta della centrale telefonica Per scegliere un centralino telefonico è indispensabile disporre di alcuni dati tecnici (risorse, linee, interni etc.), nonché conoscere le esigenze minime della

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

Centralino telefonico OfficeServ 7200

Centralino telefonico OfficeServ 7200 Centralino telefonico OfficeServ 7200 Samsung OfficeServ 7200 costituisce un unica soluzione per tutte le esigenze di comunicazione di aziende di medie dimensioni. OfficeServ 7200 è un sistema telefonico

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

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

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

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

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

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

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

Centralino telefonico OfficeServ 7400

Centralino telefonico OfficeServ 7400 Centralino telefonico OfficeServ 7400 Samsung OfficeServ 7400 è il sistema di comunicazione all-in-one dedicato alle aziende di medie e grandi dimensioni che necessitano di soluzioni semplici ed integrate

Dettagli

Nuovi modi per comunicare. Risparmiando.

Nuovi modi per comunicare. Risparmiando. Nuovi modi per comunicare. Risparmiando. Relatori: Fiorenzo Ottorini, CEO Attua S.r.l. Alessio Pennasilico, CSO Alba S.a.s. Verona, mercoledì 16 novembre 2005 VoIP Voice over xdsl Gateway GSM Fiorenzo

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

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

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

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

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

RETI GEOGRAFICHE Introduzione alle reti geografiche Trasmissione dati su linea telefonica analogica. Lenee dedicate Reti a commutazione di pacchetto

RETI GEOGRAFICHE Introduzione alle reti geografiche Trasmissione dati su linea telefonica analogica. Lenee dedicate Reti a commutazione di pacchetto 1 2 3 4 5 6 7 8 9 10 11 RETI GEOGRAFICHE Introduzione alle reti geografiche Trasmissione dati su linea telefonica analogica ISDN ADSL RAS Lenee dedicate Reti a commutazione di pacchetto ATM Reti wireless

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

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

Considerazioni / soluzione tema d'esame di Sistemi anno 2005

Considerazioni / soluzione tema d'esame di Sistemi anno 2005 Considerazioni / soluzione tema d'esame di Sistemi anno 2005 Il testo propone come problema la creazione di una classica LAN, capace anche di fornire qualche servizio all'esterno. I servizi richiesti per

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

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

Introduzione al VoIP

Introduzione al VoIP Introduzione al VoIP Cos è il VoIP (Voice over IP)? tecnica che consente la comunicazione telefonica attraverso Internet Reso possibile da prestazioni di accesso ad Internet in rapida crescita negli ultimi

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

Telefonia KastoreVOIP

Telefonia KastoreVOIP Telefonia KastoreVOIP Il VOIP ("Voice Over IP", ovvero "Voce tramite protocollo Internet"), è una tecnologia che permette di effettuare una conversazione telefonica sfruttando la connessione ad Internet

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

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

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

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

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

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

I COMPONENTI DI UNA RETE

I COMPONENTI DI UNA RETE I COMPONENTI DI UNA RETE LE SCHEDE DI RETE (O INTERFACCE 'NIC') Tutti I PC, per poterli utilizzare in rete, devono essere dotati di schede di rete (NIC). Alcuni PC sono dotati di NIC preinstallate. Nello

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

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

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

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

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

l'introduzione a Voice over IP

l'introduzione a Voice over IP Voice over IP (VoIP) l'introduzione a Voice over IP Voice Over IP (VoIP), noto anche come telefonia tramite Internet, è una tecnologia che consente di effettuare chiamate telefoniche tramite una rete di

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

Reti Locali. Lezione tenuta presso l Istituto I.I.S.S. Egidio Lanoce Maglie, 26 Ottobre 2011 Prof Antonio Cazzato

Reti Locali. Lezione tenuta presso l Istituto I.I.S.S. Egidio Lanoce Maglie, 26 Ottobre 2011 Prof Antonio Cazzato Reti Locali Lezione tenuta presso l Istituto I.I.S.S. Egidio Lanoce Maglie, 26 Ottobre 2011 Prof Antonio Cazzato Reti di Calcolatori una rete di calcolatori è costituita da due o più calcolatori autonomi

Dettagli

Programma del corso. Introduzione Rappresentazione delle Informazioni Calcolo proposizionale Architettura del calcolatore Reti di calcolatori

Programma del corso. Introduzione Rappresentazione delle Informazioni Calcolo proposizionale Architettura del calcolatore Reti di calcolatori Programma del corso Introduzione Rappresentazione delle Informazioni Calcolo proposizionale Architettura del calcolatore Reti di calcolatori Sistemi operativi di rete (locale) In una LAN si vogliono condividere

Dettagli

VOIP. (Telefonia su Internet) V1.6: Febbraio 2010 1

VOIP. (Telefonia su Internet) V1.6: Febbraio 2010 1 VOIP (Telefonia su Internet) V1.6: Febbraio 2010 1 V1.6: Febbraio 2010 2 VOIP: Cosa è come funziona come si usa apparati pro e contro costi e risparmi (!!) futuro V1.6: Febbraio 2010 3 bruno: bruno: Il

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

Introduzione 7. In principio era a disco 9 1. Come funziona(va) il telefono 9 2. La rete pubblica (PSTN) 10 3. Voglia di servizi 12

Introduzione 7. In principio era a disco 9 1. Come funziona(va) il telefono 9 2. La rete pubblica (PSTN) 10 3. Voglia di servizi 12 Indice-Sommario Introduzione 7 In principio era a disco 9 1. Come funziona(va) il telefono 9 2. La rete pubblica (PSTN) 10 3. Voglia di servizi 12 Telefonate locali, interurbane, intercontinentali; Audio

Dettagli

D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche

D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche Il Cloud Computing La visualizzazione nella Cloud Problematiche Virtualizzazione della GPU Front end Virtualization

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

INNOVATION CASE. Sistema di controllo del traffico in una galleria autostradale

INNOVATION CASE. Sistema di controllo del traffico in una galleria autostradale Sistema di controllo del traffico in una galleria autostradale INNOVARE: COSA? L IDEA Ovunque nel mondo si assiste ad un aumento della densità del traffico veicolare. Il fenomeno porta con sé un enorme

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

La virtualizzazione dell infrastruttura di rete

La virtualizzazione dell infrastruttura di rete La virtualizzazione dell infrastruttura di rete La rete: la visione tradizionale La rete è un componente passivo del processo che trasporta i dati meglio che può L attenzione è sulla disponibilità di banda

Dettagli

Reti di Calcolatori:

Reti di Calcolatori: Reti di Calcolatori: Internet, Intranet e Mobile Computing a.a. 2007/2008 http://www.di.uniba.it/~lisi/courses/reti/reti0708.htm dott.ssa Francesca A. Lisi lisi@di.uniba.it Orario di ricevimento: mercoledì

Dettagli

Telecomunicazioni RETI DI ELABORATORI

Telecomunicazioni RETI DI ELABORATORI Telecomunicazioni RETI DI ELABORATORI Fino a qualche anno fa, per poter gestire e trasmettere a distanza i dati elaborati si utilizzava il mainframe, in cui tutta la potenza di calcolo era concentrata

Dettagli

IL CENTRALINO VoIP. Schema progetto: Work-flow. Hydra Control

IL CENTRALINO VoIP. Schema progetto: Work-flow. Hydra Control IL CENTRALINO VoIP Molto più di un centralino, e soprattutto, un centralino in cui gli interni possono non avere una collocazione esterna all azienda, senza alcuna posizione fisica. Schema progetto: Work-flow

Dettagli

Simulazione prova scritta di sistemi Abacus per l Esame di Stato. Traccia n 1

Simulazione prova scritta di sistemi Abacus per l Esame di Stato. Traccia n 1 Simulazione prova scritta di sistemi Abacus per l Esame di Stato Traccia n 1 La condivisione delle informazioni e lo sviluppo delle risorse informatiche tramite cui esse possono venire memorizzate e scambiate

Dettagli

esercizi-voip-v1.doc (era esercizi-2007-04-v6.doc) Esercizio 1

esercizi-voip-v1.doc (era esercizi-2007-04-v6.doc) Esercizio 1 esercizi-voip-v1.doc (era esercizi-2007-04-v6.doc) Esercizio 1 Si consideri un sistema VoIP che operi con codifica GSM a R=13 kb/s. L'intervallo di pacchettizzazione è fissato a T=40ms. Si abbia a disposizione

Dettagli