RETI MOBILI E MULTIMEDIALI Università degli Studi di Roma “La Sapienza” Dipartimento INFOCOM RETI MOBILI E MULTIMEDIALI Aldo Roveri Lezioni dell’ a.a. 2009-2010 1

VI. Multimedia Aldo Roveri, “RETI MOBILI E MULTIMEDIALI” Univ. di Roma “La Sapienza” - a.a. 2009-2010

CONTENUTI VI.1 Compressione audio e video VI.2 L’operazione di streaming VI.3 Streaming audio/video memorizzato VI.4 Servizi audio e video interattivi VI.5 Controllo della multimedialità

Multimedia VI.1 Compressione audio e video

Digitalizzazione della voce La voce telefonica analogica ha una larghezza di banda lorda di 4 kHz; può quindi essere campionata con una frequenza di 8 kHz: ciò produce 8000 campioni/s. Secondo la codifica PCM standard, ogni campione è codificato con 8 bit; il segnale numerico risultante ha quindi un ritmo uguale a 64 kbit/s.

Digitalizzazione dei suoni musicali (1/2) Se si desidera riprodurre suoni ad alta fedeltà (HF), la larghezza di banda lorda del segnale analogico viene normalmente assunta uguale a 22,050 kHz per ogni canale (tra i due di una riproduzione stereo). Il campionamento per ogni canale deve essere allora alla frequenza di 44,100 kHz.

Digitalizzazione dei suoni musicali (2/2) Utilizzando una codifica a 16 bit/campione il segnale digitale che ne risulta per musica HF mono-canale ha un ritmo uguale 44,1 x 16 = 705,6 kbit/s , mentre per musica HF stereo (due canali) il ritmo binario è uguale a 44,1 x 16 x 2 = 1,411 Mbit/s. Per un trasferimento o una memorizzazione è necessaria un’operazione di compressione.

Digitalizzazione di dati video (1/5) Un segnale video è il risultato di una sequenza di immagini fisse che vengono presentate su uno schermo con una velocità tale da dare l’impressione del movimento: i nostri occhi non possono infatti distinguere le singole immagini quando queste vengono riprodotte in sequenza con sufficiente velocità.

Digitalizzazione di dati video (2/5) Per ingannare l’occhio umano con l’impressione del movimento sono sufficienti 25 immagini/s, ma per evitare effetti di tremolio dell’immagine ogni immagine viene ridisegnata una seconda volta; ne consegue che la presentazione è equivalente a 50 immagini/s. D’altra parte ogni immagine è composta da una matrice di pixel (Picture Elements), il cui numero (in verticale e in orizzontale) costituisce la risoluzione dell’immagine.

Digitalizzazione di dati video (3/5) Ogni pixel viene rappresentato da una sequenza di bit, che specifica il colore del pixel: per immagini in bianco e nero basta 1 bit/pixel; per immagini a colori il numero di bit per ogni pixel dipende dal numero di colori impegnati.

Digitalizzazione di dati video (4/5) La risoluzione standard di ogni immagine (quadro) di un segnale televisivo su schermo di formato 4:3 contiene 720x576 pixel, mentre per un sistema ad alta definizione (HD TV) su uno schermo di formato 16:9 la risoluzione prevede un quadro contenente 1920x1152 pixel.

Digitalizzazione di dati video (5/5) Se allora ciascuno dei tre colori primari (rosso, verde, blu) è codificato con 8 bit e se quindi ogni pixel è rappresentato con 24 bit, ogni immagine di un segnale televisivo a colori con risoluzione standard è codificabile con 720 x 576 x 24 ≈ 9,95 Mbit. Conseguentemente il segnale televisivo, che è una sequenza di immagini di questo tipo, viene numerizzato con un ritmo binario, che è uguale a 25 x 9,95 ≈ 248,8 Mbit/s e che per essere trasferito o memorizzato richiede un’operazione di compressione.

Tecniche di compressione (1/2) Nella compressione di segnali numerici audio e video si adottano attualmente due principali tecniche di compressione: quella predittiva quella percettiva. Si distinguono poi tecniche di tipo lossless, senza perdita di informazione, lossy, con perdita di informazione.

Tecniche di compressione (2/2) Una tecnica di compressione è qualificabile attraverso il cosiddetto rapporto di compressione e cioè il rapporto tra i due ritmi a monte e a valle dell’operazione di codifica. Com’è intuitivo, le tecniche lossy consentono di conseguire un maggior rapporto di compressione rispetto a quelle lossless, ma a spese di una minore qualità del risultato auditivo o visivo.

Compressione del segnale telefonico (1/5) Nelle reti mobili (ove è importante contenere i ritmi del segnale trasferito) la voce telefonica è codificata con una tecnica chiamata AMR (Adaptive MultiRate). Il codificatore AMR è un dispositivo integrato singolo con otto possibili velocità emesse; i ritmi che ne risultano sono controllabili dalla rete di accesso radio e non dipendono dalla effettiva attività della sorgente.

Compressione del segnale telefonico (2/5) Tra i ritmi riportati nella Tab.VI.1 vanno segnalati quello di 12,2 kbit/s che è impiegato nel GSM e che, nella versione a pieno ritmo (EFR), è ulteriormente impiegato in UMTS, ove il codificatore è in grado di modificare il proprio ritmo binario ogni 20 ms.

Compressione del segnale telefonico (3/5) Codec Ritmo binario (kbit/s) AMR_12.20 12.20 (GSM- EFR) AMR_10.20 10.20 AMR_7.95 7.95 AMR_7.40 7.40 (IS-641) AMR_6.70 6.70 (PDC-EFR) AMR_5.90 5.90 AMR_5.15 5.15 AMR_4.75 4.75 AMR_SID 1.80 Tab.VI.1

Compressione del segnale telefonico (4/5) Lo schema di codifica in AMR è il cosiddetto ACELP (Algebraic Code Excited Linear Prediction coder): ogni 20 ms (e quindi ogni 160 campioni estratti alla frequenza di 8kHz), il segnale vocale è analizzato per estrarne i parametri del modello CELP; i bit dei parametri vocali emessi dal codificatore sono poi pesati in funzione della loro importanza soggettiva prima di essere emessi.

Compressione del segnale telefonico (5/5) Lato sorgente si impiega un rivelatore di tratti di voce attiva (VAD – Voice Activity Detector) e si valuta il rumore acustico di sottofondo; questo rumore (Comfort Noise) viene trasferito al lato ricevente, che provvede, con trame apposite ad intervalli regolari dette SID (Silence Descriptor), a riprodurlo nei periodi in cui non sono ricevute trame vocali.

Compressione dei dati audio (1/3) Nella compressione predittiva, detta anche differenziale, si codifica la differenza tra ogni campione e una predizione di questo effettuata sulla base dei campioni precedenti. Il vantaggio risiede nella minore dinamica dei campioni differenza e quindi nella possibilità di codificarli con un minore numero di bit rispetto alla codifica di ogni campione con ampiezza quale risulta dal campionamento del segnale di sorgente.

Compressione dei dati audio (2/3) Un esempio di questa tecnica è rappresentato dal DPCM (Differential PCM) che codifica un segnale telefonico al ritmo di 32 kbit/s; un segnale vocale con banda lorda di 7kHz (e quindi con qualità migliore rispetto al segnale telefonico) al ritmo di 64 kbit/s.

Compressione dei dati audio (3/3) Nella compressione percettiva si sfruttano alcune caratteristiche del sistema uditivo; alcuni suoni, in frequenza e nel tempo, non ci fanno percepire altri suoni. La codifica MP3 (MPEG-1 Audio Layer 3) utilizza queste caratteristiche producendo segnali audio digitali a velocità comprese tra 112 e 128 kbit/s con rapporti di compressione che corrispondentemente variano tra 12 :1 e 10:1. Il ritmo di codifica cresce passando al Layer 2 (tra 192 e 256 kbit/s) e al Layer 1 (384 kbit/s). Si tratta in ogni caso di codifiche di tipo lossy.

Compressione dei dati video: immagini fisse (1/3) Nello standard JPEG (Joint Photographic Experts Group) la compressione, che è usualmente di tipo lossy, è attuata in tre passi l’immagine è segmentata in blocchi di 8 x 8 pixel e di ogni blocco di 64 pixel viene calcolato il contenuto spettrale nello spazio con una Discrete Cosine Transform (DCT) bidimensionale;

Compressione dei dati video: immagini fisse (2/3) segue una quantizzazione effettuata tramite opportune matrici che pesano i coefficienti di ordine più basso (che rappresentano le frequenze spaziali minori) con un passo di quantizzazione più piccolo e viceversa per i coefficienti di ordine più alto; si conclude con una codifica entropica e con una eliminazione delle ridondanze di tipo statistico; la componente continua della DCT è codificata in DPCM.

Compressione dei dati video: immagini fisse (3/3) Il rapporto di compressione che si può raggiungere è determinato essenzialmente dal parametro di scalatura per la matrice di quantizzazione; si può raggiungere un rapporto di compressione 15:1 senza alterare visibilmente la qualità dell’immagine

Compressione dei dati video: immagini in movimento (1/2) La compressione MPEG (Moving Picture Experts Group) è specifica per immagini in movimento Si attua riducendo la ridondanza delle singole immagini (codifica intraframe) e delle relazioni tra immagini successive (codifica interframe). Nella sua prima versione (MPEG-1) lo standard è stato predisposto per la memorizzazione di dati su CD e opera a una velocità di 1,5 Mbit/s.

Compressione dei dati video: immagini in movimento (2/2) La seconda versione (MPEG-2) è stata progettata per i DVD e opera a velocità più alte, da 3 a 6 Mbit/s; è impiegata nella formazione del segnale diffuso nella TV digitale terrestre e satellitare. Le compressioni effettuate nei due standard MPEG-1 e MPEG-2 sono di tipo lossy.

Multimedia VI.2 L’operazione di streaming

Classi di applicazioni multimediali Ci riferiamo alle operazioni di streaming di informazioni audio/video e, in questo ambito, distinguiamo tre classi a cui corrispondono modalità di attuazione ed esigenze prestazionali tra loro diverse. Le tre classi sono streaming audio/video memorizzato; streaming audio/video in tempo reale; streaming audio/video in tempo reale interattivo.

Perdite di pacchetti (1/5) Per ognuna di queste tre classi, occorre tenere conto che Internet offre un servizio di rete “best-effort” (a meno di interventi correttivi su cui si parlerà nel seguito) e che tale tipo di servizio può portare a mancanza di controllo su perdite di pacchetti ; ritardi di trasferimento dei pacchetti.

Perdite di pacchetti (2/5) Le perdite hanno origine nei buffer dei router attraversati dai pacchetti nel loro transito dall’origine alla destinazione; sono sostanzialmente dovute all’evento di trabocco di questi buffer e al conseguente scarto dei pacchetti che non possono essere inoltrati verso un collegamento in uscita. Altre cause di perdita sono dovute a disturbi di natura varia quali si presentano, ad esempio, in collegamenti wireless.

Perdite di pacchetti (3/5) Se lo streaming riguarda solo un flusso audio/video, il grado di perdita (quota parte dei pacchetti persi rispetto a quelli emessi all’origine) non è una prestazione critica, nel senso che possono essere tollerati gradi di perdita di valore contenuto, orientativamente non superiore al 10%, ma in ogni caso con valore limite dipendente da ogni specifica applicazione.

Perdite di pacchetti (4/5) Quando lo si reputi necessario, si può contenere l’effetto delle perdite in ricezione, con il mascheramento delle perdite attuato con l’interpolazione dei dati mancanti con quelli ricevuti; in trasmissione, con l’impiego di codici correttori d’errore (FEC), di schemi di interallacciamento (interleaving) e, in generale, di ridondanza a bassa velocità e a bassa risoluzione.

Perdite di pacchetti (5/5) I gradi di perdita possono essere fortemente contenuti con l’adozione di TCP come protocollo di trasporto in luogo di UDP e compatibilmente con la prestazione di ritardo.

Ritardi di trasferimento (1/4) Il ritardo di trasferimento di un pacchetto da estremo a estremo è la somma dei tempi di trasmissione e dei ritardi di propagazione, di elaborazione e di accodamento nei router attraversati dal pacchetto sul suo percorso da estremo a estremo.

Ritardi di trasferimento (2/4) Il ritardo di un pacchetto ha in generale natura aleatoria: dipende infatti da vari parametri legati alla trasmissione del pacchetto stesso e al collegamento che è di supporto alla trasmissione; si manifesta quindi con realizzazioni che presentano un valor medio, che chiameremo ritardo di base e che dipende, a parità del collegamento, dal carico sui nodi e sui rami della rete; fluttuazioni all’intorno del ritardo di base, che sostanzialmente dipendono dalla variabilità delle durate di permanenza dei pacchetti nei buffer dei router e che sono denominate jitter di pacchetto.

Ritardi di trasferimento (3/4) I valori dei ritardi di base possono assumere valori non particolarmente stringenti nelle due classi di streaming con file memorizzati o in tempo reale, con un limite più stretto per la seconda classe rispetto alla prima, ma in ogni caso entro valori di qualche decina di secondi. Nel caso invece della classe di streaming interattivo, il ritardo di base deve avere un valore tale da non pregiudicare l’interattività della comunicazione.

Ritardi di trasferimento (4/4) Ad esempio, nel caso di trasferimenti in campo telefonico, ritardi di base inferiori a 150 ms non sono percepiti dall’orecchio umano. Se il ritardo cresce nell’intervallo tra 150 e 400 ms, la qualità della comunicazione, seppure peggiorata, è ancora accettabile. Tale qualità peggiora in modo da pregiudicare l’interattività della comunicazione se il ritardo supera orientativamente il valore di 400 ms.

Jitter di pacchetto (1/4) Nel trasferimento di dati audio/video in tempo reale (interattivo o meno) assume importanza sulla qualità dell’informazione ricevuta il jitter di pacchetto, e cioè la variabilità del ritardo con cui arrivano i pacchetti che contengono i dati. Per una corretta riproduzione dei dati audio/video in tempo reale è necessario che il jitter sia di valore il più possibile contenuto.

Jitter di pacchetto (2/4) Gli effetti del jitter possono essere contenuti aggiungendo, in emissione, ad ogni pacchetto l’istante relativo di generazione; scegliendo opportunamente, in ricezione, l’inizio della riproduzione; memorizzando i dati ricevuti in un buffer di riproduzione, in attesa dell’inizio della riproduzione; prevedendo di dotare i pacchetti di numeri di sequenza, che consentano il riordino dei pacchetti in ricezione; scartando i pacchetti che pervengono dopo l’inizio della riproduzione.

Jitter di pacchetto (3/4) In Fig.VI.1 è mostrato il trattamento in ricezione di pacchetti emessi a intervalli costanti e trasferiti con ritardi affetti da jitter; sono considerati i tempi di permanenza nel buffer di riproduzione e, in particolare, viene mostrato il caso di scarto di un pacchetto.

Jitter di pacchetto (4/4) V(0) D(1) V(1) D(2) V(2) D(3) V(3) D(4) V(4) D(5) D(6) V(6) t(1) t(2) t(3) t(4) t(5) t(6) t(0) Pacchetto scartato Asse riproduzione emissione T Fig.VI.1

Multimedia VI.3 Streaming audio/video memorizzato

Streaming audio/video memorizzato (1/3) Il contenuto multimediale è memorizzato su un server e può essere trasferito a un client che ne fa richiesta. La riproduzione del file presso il client deve essere continua , e cioè deve poter essere in sincronia con i tempi di registrazione originali; ciò impone limiti critici al ritardo dei dati, che devono essere ricevuti dal client in tempo utile per la loro riproduzione.

Streaming audio/video memorizzato (2/3) Questo vincolo di riproduzione continua non impedisce che, con una opportuna modalità di controllo, il client abbia la possibilità di interagire con il server per ottenere funzioni tipiche di un registratore audio/video operante in locale, quali il fermo-riproduzione e la possibilità di spostarsi in avanti o all’indietro. Il trasferimento del file è usualmente di tipo unicast.

Streaming audio/video memorizzato (3/3) Nel modulo, che presso il client consente di riprodurre il file trasferito, devono essere previste varie funzioni quali: la decompressione dei file audio/video durante la riproduzione; la rimozione del jitter quando necessario per la qualità della riproduzione e con le modalità chiarite in precedenza; il contenimento delle perdite quando necessario per la qualità della riproduzione; la modalità più semplice è ottenuta mascherando le perdite con l’interpolazione dei dati mancanti con quelli ricevuti.

Streaming con media player (1/3) Un file audio/video memorizzato potrebbe essere trasferito come un qualsiasi altro file. Ad esempio si potrebbe usare un browser e trasferire il file residente su un server web attraverso il protocollo HTTP. In questa ipotesi il server web potrebbe spedire il file in forma compressa al browser. Il browser, dopo aver memorizzato il file, potrebbe utilizzare un’ applicazione ausiliaria, chiamata media player , che permette di ascoltare l’audio e di vedere il video e che quindi ne consente la riproduzione (Fig VI.2).

Streaming con media player (2/3) Fig.VI.2

Streaming con media player (3/3) Il trasferimento del file audio/video effettuato in questo modo ha un grosso inconveniente: dato che file di questo tipo hanno in generale grandi dimensioni anche se in forma compressa e dato che una loro riproduzione può avvenire solo dopo un loro trasferimento completo, l’utente, in funzione del collegamento utilizzato con il server, deve aspettare tempi anche molto lunghi prima di usufruire del contenuto del file; ciò può essere inaccettabile.

Streaming con metafile (1/3) Per risolvere questo problema, il media player si connette direttamente al server per ottenere da questo il file audio/video e per poterlo riprodurre durante la ricezione. Per questo scopo il server web memorizza due file: il file audio/video; un metafile , che contiene informazioni riguardo al file audio/video.

Streaming con metafile (2/3) In questa modalità il browser richiede al server web l’accesso al file audio/video; ottiene dal serve web il metafile che viene passato al media player; il media player richiede al server web il vero file audio/video, utilizzando le informazioni del metafile; Con tale procedura (Fig.VI.3) è possibile cominciare a riprodurre il file prima di completarne il trasferimento.

Streaming con metafile (3/3) Fig.VI.3

Streaming con media server (1/4) La soluzione con metafile, in cui il media player interagisce con un server web, ha un’ulteriore inconveniente rispetto a quella in Fig.VI.2. Tale inconveniente è legato all’uso del protocollo HTTP che, a sua volta, usa il protocollo TCP; questo offre un trasferimento affidabile (con controllo degli errori), ma con possibili ritardi legati alla riemissione dei file rivelati errati.

Streaming con media server (2/4) Per uno streaming di dati audio/video è più importante avere il trasferimento dei dati con ritardo contenuto piuttosto che con bassi tassi di errore. Per superare l’inconveniente al server web si aggiunge un altro server, che viene detto media server. Il server web provvede, a richiesta, a fornire il metafile, mentre il trasferimento del file è a cura del media server.

Streaming con media server (3/4) Rispetto al caso precedente, è il metafile a specificare il media server dal quale si può ottenere il file audio/video. Con questa variante, illustrata in Fig.VI.4, il trasferimento del file dal media server al media player avviene con l’uso di UDP (invece di TCP)

Streaming con media server (4/4) Fig.VI.4

RTSP (1/3) RTSP (Real-Time Streaming Protocol) è un protocollo di controllo predisposto per aggiungere funzionalità allo streaming di un file audio/video. In particolare RTSP controlla, come mostrato in Fig.VI.5, il trasferimento del file attraverso

RTSP (2/3) l’instaurazione di una connessione dal media player al media server; l’inoltro di comandi di riproduzione (comprensivi di inizio, pause, etc.) da parte del media player; il successivo invio del flusso di dati audio/video da parte del media server; la chiusura della connessione comandata dal media player.

RTSP (3/3) Fig.VI.5

Multimedia VI.4 Servizi audio e video in tempo reale

Streaming dal vivo (1/2) Lo streaming di un evento dal vivo, detto anche streaming in tempo reale, non è sostanzialmente diverso da uno streaming di un file memorizzato: quindi vale quanto già detto in VI.3. Le differenze sostanziali sono due: il file da distribuire viene prodotto in tempo reale; la distribuzione è multicast (a differenza di quella unicast che si adotta quando il file è memorizzato).

Streaming dal vivo (2/2) Valgono per il resto le stesse considerazioni svolte per un file memorizzato: la riproduzione deve poter essere continua e nel modulo di ricezione devono essere previste la rimozione del jitter e il contenimento delle perdite.

Streaming audio/video in tempo reale interattivo Rispetto ai due precedenti casi di streaming, questa terza classe prevede, oltre allo scambio di dati audio/video, anche l’interazione tra gli utenti coinvolti nella comunicazione.

Multicast Si ribadisce che i dati audio/video in tempo reale debbono essere diffusi in modalità multicast per meglio fronteggiare il carico sulla rete che si determina per effetto della grande quantità di dati da trasferire.

Mixing Quando più sorgenti spediscono dati, come ad es. in una video conferenza, il traffico in rete è composto da più flussi video. Per fare convergere il traffico in un unico flusso di dato video è necessario combinare i dati emessi dalle varie sorgenti; tale operazione è chiamata mixing. Un mixer combina quindi i segnali audio/video di più sorgenti in un unico segnale.

Protocolli per streaming in tempo reale (1/2) Lo streaming di dati audio/video in tempo reale attraverso Internet richiede alcuni completamenti protocollari nello strato di trasporto. Un primo punto riguarda TCP, che presenta caratteristiche non adatte per questo tipo di comunicazione; infatti non supporta il trasferimento multicast anche se offre la possibilità di numerare i pacchetti; possiede un meccanismo di controllo d’errore che non è compatibile con il carattere in tempo reale dello streaming.

Protocolli per streaming in tempo reale (2/2) UDP è invece più adatto in quanto supporta il trasferimento multicast e non prevede ritrasmissione a seguito di errori; non prevede però alcun supporto per i tempi di riproduzione, per l’ordinamento dei pacchetti e per il mixing. Si è resa quindi necessaria l’introduzione di nuovi protocolli: questi sono RTP e RTCP.

RTP (1/4) Il traffico di dati audio/video in tempo reale richiede l’utilizzo del protocollo RTP (Real-time Transport Protocol) in aggiunta all’UDP; RTP porta a quest’ultimo gli element mancanti per la gestione del traffico in tempo reale e interattivo, e cioè i tempi di riproduzione, l’ordinamento dei dati e il mixing. La collocazione di RTP nella pila protocollare di Internet è mostrata nella Fig.VI.6. Nelle Fig.VI.7 è mostrato il formato dell’intestazione di un pacchetto RTP, mentre in Tab.VI.2 ne viene fornito il contenuto.

RTP (2/4) Fig.VI.6

RTP (3/4) Fig.VI.7

RTP (4/4) Tab.VI.2

RTCP (1/2) RTCP (Real-time Transport Control Protocol) offre funzionalità di controllo per gestire il protocollo RTP. Prevede cinque tipi di messaggi come mostrato nella Fig.VI.8.

RTCP (2/2) Fig.VI.8

Multimedia VI.5 Controllo della multimedialità

Multimedia protocol stack IPv4/MPLS - IPv6/MPLS TCP UDP H.323 SDP SIP RSVP RTCP RTP Mpeg, H.261, … Flussi Multimediali Qualità di Servizio Segnalazione Reservation Measurement Transport Network Application

SIP: Aspetti generali (1/3) SIP (Session Initiation Protocol) è un protocollo di controllo (segnalazione) di strato applicativo. Consente di instaurare, modificare e terminare sessioni multimediali audio & video conference Chiamate telefoniche. Consente il supporto della personal mobility ad un utente è associato unico identificatore, qualsiasi sia la sua localizzazione in rete

SIP: Aspetti generali (2/3) SIP supporta le seguenti funzionalità Localizzazione degli utenti Individuazione degli end-system coinvolti nella sessione Controllo della disponibilità di un utente a partecipare a una sessione Negoziazione dei parametri di una sessione Determinazione dei media coinvolti nella sessione e dei relativi parametri (es. codec) Instaurazione della sessione Gestione della sessione Modifica dei parametri Attivazione di nuovi servizi Terminazione della sessione

SIP: Aspetti generali (3/3) Modello transazionale Client/Server Il Client emette la richiesta di attivazione di una funzione (Metodo) Il Server invia immediatamente una risposta provvisoria e, al termine del processamento della richiesta, una risposta definitiva I messaggi SIP possono essere trasferiti mediante un qualsiasi protocollo di trasporto (TCP, UDP, TLS, ecc.) UDP e TCP sono i protocolli più utilizzati Client Server Request Response Provisonal Response

SIP: Formato di un messaggio Protocollo testuale Un messaggio è composto da Una Start Line Uno o più Message-Header Message-Body (opzionale) start-line message-header 1 message-header 2 … message header n CRLF (empty line) [message-body] Request-line / status-line Generic-message Start-line

SIP: Entità logiche (1/4) User Agent (UA) User Agent Client (UAC) È l’entità che emette una richiesta di attivazione di un metodo; Il ruolo di client è limitato solo alla durata della transazione. User Agent Server (UAS) È l’entità che emette le risposte ad una richiesta SIP; Il ruolo di server è limitato solo alla durata della transazione.

SIP: Entità logiche (2/4) Proxy Server È un’entità intermedia che agisce per conto dell’utente che richiede un metodo nella sua procedura di esecuzione; Una funzionalità tipica di un proxy è l’instradamento della richiesta verso l’utente di destinazione; Agisce sia come UAC che come UAS. Registrar Riceve le richieste di registrazione degli utenti SIP in un dominio; Gestisce le informazioni di localizzazione degli utenti; Agisce come un Location Server (es. GSM HLR).

SIP: Entità logiche (3/4) Redirect Server E’ un UAS che ha il compito di comunicare ad un UA o a un proxy verso quale indirizzo deve essere inviata una richiesta in modo che questa raggiunga l’utente finale; Utilizza il servizio di localizzazione. Back-to-Back User Agent (B2BUA) E’ un entità di disaccoppiamento che riunisce il ruolo di UAS e UAC; Riceve una richiesta, la processa (ruolo di UAS), determina le modalità di completamento della richiesta stessa e genera una nuova richiesta per completare la procedura (ruolo di UAC).

SIP: Entità logiche (4/4) UAC Proxy Request Response UAS UAC B2BUA Request Response UAS

Tipologie di Proxy SIP Stateless proxy Un proxy che non mantiene nessuna informazione di stato relativa ad una transazione. Si limita a rilanciare i messaggi di richiesta e di risposta. Stateful proxy Un proxy che mantiene informazioni di stato di una transazione. Call stateful proxy Un proxy che memorizza tutte le informazioni di stato associate ad una sessione durante tutto il suo svolgimento.

Architettura SIP SIP Layer Control path Data path IP Network Registrar Proxy Server Registrar (Location Server) Redirect UAC UAS IP Network SIP Layer Control path Data path Router

SIP: Indirizzamento L’indirizzamento SIP è basato sul URI (Uniform Resource Identifier), che identifica una qualsiasi risorsa di comunicazione (es. un utente, una mailbox, un terminale telefonico PSTN, ecc.) Un SIP URI contiene tutte le informazioni necessarie a iniziare e mantenere una sessione con la risorsa associata host name (obbligatorio) user name, port number, parameters, ecc. (opzionali) Ad una URI è associato l’indirizzo di rete della risorsa mediante l’operazione di registrazione ad un SIP Registrar La spazio di indirizzamento è virtualmente infinito

SIP: Forma generale di un SIP URI Sip:user:password@host:port;uri-parameters?header user:password identifica la risorsa di comunicazione di un host a cui si riferisce l’indirizzo la password è opzionale host identifica l’host che supporta la risorsa SIP contiene normalmente l’indirizzo IP port numero della porta a cui deve essere indirizzata la richiesta

SIP: Forma generale di un SIP URI uri-parameters parametri associati alla richiesta (separati da “;”) es. transport, ttl, ecc. il formato di ciascun parametro è del tipo “nome=value” header header fields associati alla richiesta (separati da “&”) il formato di ciascun header è del tipo “hnome=hvalue”

Esempi di indirizzi SIP sip:alice@atlanta.com sip:alice:secretword@atlanta.com;transport=tcp sip:+1-212-555-1212:1234@gateway.com;user=phone sip:alice@192.0.2.4 sip:another-proxy.biloxi.com;transport=UDP Normalmente è utilizzata la forma semplificata sip:user@host

Metodi Base INVITE È utilizzato per iniziare una sessione Include nel body la descrizione dei parametri della sessione (SDP) L’invio successivo di un altro INVITE (RE-INVITE) è utilizzato per modificare i parametri di una sessione già instaurata ACK È utilizzato per confermare l’avvenuta l’instaurazione di una sessione E’ emesso solo in risposta ad un INVITE BYE È utilizzato per terminare una sessione

Metodi Base CANCEL È utilizzato per cancellare un richieta il cui processamento non è stato ancora completato OPTIONS È utilizzato per chiedere informazioni sulle funzionalità di un server REGISTER È utilizzato per effettuare la registrazione di un utente ad un Registrar Consente di creare l’associazione tra l’utente e il suo attuale indirizzo di rete

Metodi Addizionali INFO PRACK COMET REFER SUBSCRIBE UNBSCRIBE NOTIFY È utilizzato per trasferire messaggi di segnalazione durante lo svolgimento di una sessione PRACK Riscontro provvisorio COMET Notifica di accettazione di una precondizione REFER Consente di richiedere l’instaurazione di una sessione tra due specificate risorse (Third Party Call) SUBSCRIBE Iscrizione al servizio (instant messaging) UNBSCRIBE Cancellazione dal servizio (instant messaging) NOTIFY Notifica di messaggi entranti (instant messaging) MESSAGE Messaggio(instant messaging)

Risposte (1/2) Sono definite sei classi di risposte Le risposte sono codificate con un codice a 3 digit Il primo digit codifica la classe della risposta Gli altri due digit indicano il tipo particolare di risposta 1xx - Provisional La richiesta è stata ricevuta ed è in corso di elaborazione 2xx – Success La richiesta è stata completata con successo 3xx – Redirection La richiesta deve essere inoltrata verso un’altra locazione 4xx – Client error La richiesta contiene un errore e non può essere completata 5xx – Server error La richiesta sebbene corretta non può essere completata dal server 6xx – Global Failure La richiesta non può essere completata da nessun server

Risposte (2/2)

Esempio di Messaggio INVITE (1/4)) INVITE sip:userB@there.com SIP/2.0 Via: SIP/2.0/UDP pcA.here.com:5060; branch=z9hG4bk776asdhds Max-Forwards: 70 To: User B <sip:userB@there.com> From: User A <sip:userA@here.com> Call-ID: 4598998103413@4.3.2.1 CSeq: 314159 INVITE Contact: <sip:UserA@here.com> Content-Type: application/sdp Content-Length: 142 “Message Body” La prima linea contiene il nome del metodo (INVITE) L’URI del estinatario della richiesta La versione corrente di SIP (2.0) Le linee che seguono sono una lista di header-fields Via Versione di SIP Protocollo di trasporto usato Indirizzo IP (o il nome) del richiedente Numero di porta Il parametro “branch” identifica la transazione

Esempio di Messaggio INVITE (2/4) INVITE sip:userB@there.com SIP/2.0 Via: SIP/2.0/UDP pcA.here.com:5060; branch=z9hG4bk776asdhds Max-Forwards: 70 To: User B <sip:userB@there.com> From: User A <sip:userA@here.com> Call-ID: 4598998103413@4.3.2.1 CSeq: 314159 INVITE Contact: <sip:UserA@here.com> Content-Type: application/sdp Content-Length: 142 “Message Body” Max-Forwards Limita il numero di hop che la richiesta può compiere prima di arrivare a destinazione To Nome del destinatario URI del destinatario originale From Nome del richiedente URI del richiedente

Esempio di Messaggio INVITE (3/4) INVITE sip:userB@there.com SIP/2.0 Via: SIP/2.0/UDP pcA.here.com:5060; branch=z9hG4bk776asdhds Max-Forwards: 70 To: User B <sip:userB@there.com> From: User A <sip:userA@here.com> Call-ID: 4598998103413@4.3.2.1 CSeq: 314159 INVITE Contact: <sip:UserA@here.com> Content-Type: application/sdp Content-Length: 142 “Message Body” Call-ID Identificatore unico della chiamata È l’unione di una stringa random e del nome (o indirizzo) del richiedente Cseq (Command Sequence) Contiene un numero intero e il nome del metodo È un contatore sequenziale delle richieste inoltrate all’interno della chiamata Contact SIP URI che indica il modo (indirizzo IP o nome) per contattare direttamente il richiedente

Esempio di Messaggio INVITE (4/4) INVITE sip:userB@there.com SIP/2.0 Via: SIP/2.0/UDP pcA.here.com:5060; branch=z9hG4bk776asdhds Max-Forwards: 70 To: User B <sip:userB@there.com> From: User A <sip:userA@here.com> Call-ID: 4598998103413@4.3.2.1 CSeq: 314159 INVITE Contact: <sip:UserA@here.com> Content-Type: application/sdp Content-Length: 142 “Message Body” Content-Type Descrizione the “message body” Content-Length Lunghezza in ottetti del message body Message Body Contiene la descrizione dei parametri di sessione richiesti Tipo di media (es. audio, video) Codec utilizzati Sampling rate Si utilizza il protocollo SDP

Esempio di Messaggio 200 OK (1/2) SIP/2.0 200 OK Via: SIP/2.0/UDP proxyB.there.com:5060; branch=z9hG32k776aedfaa Via: SIP/2.0/UDP proxyA.here.com:5060; branch=z9hG4bk216efc66s Via: SIP/2.0/UDP pcA.here.com:5060; branch=z9hG4bk776asdhds Max-Forwards: 70 To: User B <sip:userB@there.com> From: User A <sip:userA@here.com> Call-ID: 4598998103413@4.3.2.1 CSeq: 314159 INVITE Contact: <sip:UserB@there.com> Content-Type: application/sdp Content-Length: 131 “Message Body” La prima linea contiene Codice della risposta (200) Una frase di illustrazione (OK) Gli header field Via, To, From, Call-ID e Cseq sono copiati dal messaggio INVITE ricevuto Nel campo Via sono indicati anche gli indirizzi dei proxy attraversati dal messaggio INVITE Il messaggio di risposta segue lo stesso percorso seguito dal messaggio INVITE

Esempio di Messaggio 200 OK (2/2) SIP/2.0 200 OK Via: SIP/2.0/UDP proxyB.there.com:5060; branch=z9hG32k776aedfaa Via: SIP/2.0/UDP proxyA.here.com:5060; branch=z9hG4bk216efc66s Via: SIP/2.0/UDP pcA.here.com:5060; branch=z9hG4bk776asdhds Max-Forwards: 70 To: User B <sip:userB@there.com> From: User A <sip:userA@here.com> Call-ID: 4598998103413@4.3.2.1 CSeq: 314159 INVITE Contact: <sip:UserB@there.com> Content-Type: application/sdp Content-Length: 131 “Message Body” Contact SIP URI che indica il modo (indirizzo IP o nome) per contattare direttamente UserB Message Body Contiene la descrizione dei parametri di sessione accettati dal destinatario (UserB) Possono essere diversi da quelli richiesti dalla sorgente Si utilizza il protocollo SDP

Instaurazione di una sessione Sequenza di passi Registrazione, identificazione e localizzazione dell’utente “chiamato” Determinazione dei media che caratterizzano la sessione e dei relativi parametri Determinazione della volontà dell’utente “chiamato” a stabilire la sessione con l’utente “chiamante” Instaurazione della sessione Eventuale modifica della sessione (es. call transfer) Terminazione della sessione

Esempio di instaurazione di una sessione UserA proxyA.here.com proxyB.there.com UserB Invite (1) Invite (2) Invite (4) 100 Trying (3) 200 OK (9) 100 Trying (5) 180 Ringing (6) 180 Ringing (7) 180 Ringing (8) 200 OK (10) 200 OK (11) ACK (12) Media session BYE (13) 200 OK (14)

Osservazioni (1/2) L’indirizzo del SIP server “proxyA.here.com” deve essere configurato nel terminale d’utente o può essere acquisito tramite DHCP. I proxy ricevono il messaggio di INVITE, individuano l’hop successivo e rilanciano il messaggio aggiornando il campo Via Un proxy individua il destinatario dell’hop successivo con una procedura di “address resolution”. Ogni proxy emette a ritroso un messaggio 100 trying che indica che la procedura è in progress. L’indirizzo dello UserB è ottenuto dall’ultimo proxy mediante una query al location server del dominio a cui appartiene UserB (there.com). Il terminale di UserB avverte l’utente finale dell’arrivo di una chiamata e in attesa della risposta emette un messaggio 180 ringing che indica all’utente chiamante che si è in attesa della risposta.

Osservazioni (2/2) Il percorso dei messaggi a ritroso è individuato dalla sequenza memorizzata nel campo Via Ogni proxy individua l’elemento successivo e rimuove il proprio riferimento dal campo via. Quando l’utente UserB risponde al segnale di chiamata viene emesso il messaggio 200 OK che indica l’avvenuta risposta dell’utente chiamato. Il messaggio 200 OK contiene i parametri della chiamata che l’utente UserB accetta Negoziazione dei parametri in due fasi (offerta e risposta). La procedura si conclude con l’invio da parte di UserA di un messaggio ACK che indica la conclusione positiva della fase di instaurazione Il messaggio ACK non è elaborato dai proxy perché entrambi gli utenti, mediante il campo Contact, hanno acquisito gli indirizzi del corrispondente.

Registrazione La procedura consente di registrare la presenza di un utente in un dominio e di individuare il suo indirizzo di rete. Esempio Registrazione della presenza dell’utente jiri@iptel.org Associazione dell’utente jiri@iptel.org all’indirizzo di rete 195.37.78.173 UAC SIP Registrar Location Server jiri@iptel.org (195.37.78.173) REGISTER sip:iptel.org SIP/2.0 From: sip:jiri@iptel.org To: sip:jiri@iptel.org Contact: <sip:195.37.78.173> Expires: 3600 Jiri @ 195.37.78.173 (procedura non SIP) SIP/2.0 200 OK

Address resolution e location service UserA DNS Server SIP Proxy UserB DNS Query (1) DNS Record (2) INVITE (3) 100 Trying (4) Query (5) Response (6) INVITE (7) 200 OK (8) 200 OK (4)

Location Service Location Register Caller@sip.com SIP jiri@iptel.org INVITE sip:jiri@iptel.org SIP/2.0 From: sip:caller@sip.com To: sip:jiri@iptel.org Call-ID: 345678@sip.com INVITE sip:jiri@195.37.78.173 SIP/2.0 From: sip:caller@sip.com To: sip:jiri@iptel.org Call-ID: 345678@sip.com OK 200 From: sip:Caller@sip.com To: sip: jiri@iptel.org Call-ID: 345678@sip.com OK 200 From: sip:Caller@sip.com To: sip: jiri@iptel.org Call-ID: 345678@sip.com Caller@sip.com SIP Proxy jiri@iptel.org

SDP La negoziazione dei media e dei parametri associati è realizzata mediante SDP (Session Description Protocol). SDP è un linguaggio testuale di descrizione. Il paradigma di negoziazione è di tipo offerta-risposta L’offerta è contenuta nel messaggi INVITE La risposta nel messaggio 200 OK Nell’offerta uno UA dichiara per ogni media Tipo Insieme di Codec supportati IP address Port number Nella risposta l’altro UA dichiara i media accettati e quelli rifiutati

Esempio di body SDP (offerta) m=video 4004 RTP/AVP 14 26 Media – media type (video), port number, type (RTP/Audio Video Profile), number (profili 14 o 26) a=rtpmap:14 MPA/90000 Attributo – lista attributi profilo 14: codec MPA; sampling rate 90 kHz a=rtpmap:26 jbeg/90000 Attributo – lista attributi profilo 26: codec JBEG; sampling rate 90 kHz v=0 o= s= c=IN IP4 128.3.2.1 t= m=video 4004 RTP/AVP 14 26 a=rtpmap:14 MPA/90000 a=rtpmap:26 jbeg/90000 m=audio 4006 RTP/AVP 0 4 a=rtpmap:0 PCMU/8000 a=rtpmap:4 GSM/8000 m=audio 4006 RTP/AVP 0 4 Media – media type (audio), port number, type (RTP/AVP profile), number (profili 0 o 4) a=rtpmap:0 PCMU/8000 Attributo – lista attributi profilo 0: codec PCM (μ law); sampling rate 8 kHz a=rtpmap:4 GSM/8000 Attributo – lista attributi profilo 4: codec GSM; sampling rate 8 kHz v=0 versione corrente di SDP o= ; s= ; t= Origine, Subject, Time (non usati da SIP) c=IN IP4 128.3.2.1 Connessione - Internet (IN), IP4, indirizzo

Esempio di body SDP (risposta) m=video 0 RTP/AVP 14 La destinazione declina l’offerta del video (numero di porta 0) m=audio 6002 RTP/AVP 4 La destinazione accetta l’offerta dell’audio (numero di porta diverso da 0 e sceglie il profilo 4) a=rtpmap:4 GSM/8000 Attributo – lista attributi profilo 4: codec GSM; sampling rate 8 kHz v=0 o= s= c=IN IP4 16.22.3.1 t= m=video 0 RTP/AVP 14 m=audio 6002 RTP/AVP 4 a=rtpmap:4 GSM/8000

Modifica dei parametri di sessione UA Invite sdp1 (1) 180 Ringing (2) 200 OK (3) ACK (4) Invite sdp2 (5) 180 Ringing (6) ACK (8) Media Session New Media Session Una delle due parti può richiedere la modifica dei parametri di sessione mediante l’invio di un messaggio INVITE (RE-INVITE) Il nuovo messaggio di INVITE deve contenere il Call-ID della sessione che si vuole modificare La procedura di modifica segue lo stesso schema della procedura di instaurazione Una procedura di modifica non può iniziare fino a che non si è esaurita la fase di instaurazione o una richiesta di modifica precedente

Gestione della mobilità in SIP (1/2) Un utente in una rete visited si registra sul Foreign Proxy (FP) disponibile Il FP provvede ad avvertire l’Home Proxy (HP)

Gestione della mobilità in SIP (2/2) L’HP provvede a redirigere una chiamata entrante verso la rete visited

SIP verso Mobile IP (MIP) MIP è il protocollo utilizzato per le applicazioni mobile Internet Mobile-IPv4 è inefficiente a causa dell’instra-damento triangolare Mobile-IPv6 usa meccanismi simili a SIP registration and reinvitations per evitare il triangular routing SIP potrebbe essere la soluzione per gestire in modo unico la mobilità in Internet.

Telefonia in Internet (1/3) VoIP (Voice over IP) è una applicazione di telefonia su Internet. Una chiamata telefonica può essere gestita con l’impiego di SIP. A titolo d’esempio, l’evoluzione di una chiamata con SIP è mostrata in Fig.VI.9, mentre la Fig.VI.10 illustra la procedura SIP per l’identificazione del chiamante.

Telefonia in Internet (2/3) Fig.VI.9

Telefonia in Internet (3/3) Fig.VI.10