Multimedia su Internet

Multimedia su Internet Giancarlo Fortino g.fortino@unical.it http://paride.deis.unical.it/~fortino 1

Multimedia su Internet Internet fino a 10 anni fa era usata quasi esclusivamente per trasportare dati relativi ad email, file e messaggistica in genere. Oggi, si stanno aprendo nuovi scenari che contemplano la telefonia su Internet, il multimedia conferencing, trasmissione di seminari e meeting, simulazioni distribuite, videogame distribuiti ed altre applicazioni in realtime. Aree di applicazioni di ricerca con requisiti in tempo reale includono la telemedicina, gruppi di lavoro distribuiti, apprendimento a distanza (teleteaching) e mondi virtuali. 2

Multimedia su Internet: vantaggi e svantaggi Vantaggi TCP/IP standard DE-FACTO Risorsa facilmente accessibile Bassi costi Svantaggi Banda limitata Condivisione e Congestione Eterogeneità Supporto non nativo di parametri di QoS Multimedia su Internet 3

Multimedia Internetworking Il multimedia internetworking comprende le infrastrutture di rete, i protocolli, i modelli, le applicazioni, le tecniche che sono in corso di sviluppo per supportare applicazioni multimediali distribuite su Internet. Multimedia su Internet 4

Flussi multimediali su IP-unicast 1/2 Con IP unicast un host X che vuole trasmettere informazioni ad N destinatari diversi, deve necessariamente trasmettere N copie di ogni pacchetto, una copia per ogni destinatario. In questo modo si comprende che per trasmettere flussi di informazioni di una certa entità, come è possibile avere nel caso di flussi di dati multimediali, si arriverebbe facilmente, già con un N piccolo, alla congestione del tratto di rete L1 che connette l host X al resto di Internet, e sicuramente si sovraccaricherebbero altri nodi interessati a questo traffico. Multimedia su Internet 5

Flussi multimediali su IP-unicast 2/2 Host X To A To B L1 Internet From X From X Host A Host B Comunicazione Multipunto Senza uso di IP-multicast To C To D From X Host C Replicazione Del Pacchetto From X Host D Multimedia su Internet 6

Flussi multimediali su IP-multicast 1/2 Il multicast e un sistema di trasmissione dei pacchetti IP su rete che differisce dalla tradizionale trasmissione punto- punto, utilizzata su Internet. Invece con l IP multicast l host X dovrà trasmettere solo una copia di ogni pacchetto ad un indirizzo multicast (detto anche indirizzo di gruppo), sarà il sottosistema di rete, utilizzando degli opportuni algoritmi di istradamento, a recapitare le informazioni ad ogni destinatario senza congestionare la rete, anche per un N molto grande. Multimedia su Internet 7

Flussi multimediali su IP-multicast 2/2 Internet Dal Gruppo X Host A Host X Al Gruppo X L1 Dal Gruppo X Dal Gruppo X Host B Host C Comunicazione multipunto che utilizza IP-multicast. Nessuna Replicazione Dal Gruppo X Host D Multimedia su Internet 8

IP-Multicast Indirizzamento di classe D. {224.0.0.1, 239.255.255.255} L IGMP (Internet Group Management Protocol) è il protocollo utilizzato dai router per conoscere l esistenza nella loro sottorete di host membri di indirizzi di gruppo (HMQ, HMR). Routing Multicast Denso: Distance Vector Multicast Routing Protocol (DVMRP), Multicast Open Shortest Path First (MOSPF), Protocol-Independent Multicast - Dense Mode (PIM-DM) Sparso: Core Based Trees (CBT), Protocol-Independent Multicast - Sparse Mode (PIM-SM) Steve Deering presso la Stanford University Multimedia su Internet 9

MBone 1/2 MBone (Multicast Backbone) è la dorsale multicast di Internet Ha dei requisiti minimi di banda (>500Kbps) All inizio, nel 1992, MBone era una rete virtuale, in quanto non esistevano router capaci di instradare traffico multicast, quindi gli unici router multicast erano WS che eseguivano un applicazione software che simulava un router multicast (mrouted) In seguito molti produttori di dispositivi per reti (p.e., CISCO) cominciarono a costruire router multicast, e ormai MBone sta diventando una realtà in ogni senso. In questa fase di transizione, ancora oggi in corso, isole di reti con capacità multicast sono connesse l una all altra attraverso collegamenti unicast denominati tunnel Multimedia su Internet 10

MBone 2/2 Multimedia su Internet 11

Protocolli applicativi per il multimedia I protocolli TCP/IP furono progettati per gestire tipo di traffico ordinario, e in questo contesto funzionano egregiamente. Il traffico di flussi di dati multimediali possiede caratteristiche differenti, tra cui stringenti vincoli temporali, per cui esiste la richiesta di nuovi tipi di protocolli. Come esempio basti pensare che per un applicazione multimediale è più tollerabile una piccola perdita di pacchetti che ricevere tutti i pacchetti di un flusso dati attendendo che il TCP ritrasmetta con comodo i pacchetti persi, quando si accorge della loro perdita. Il percorso che i pacchetti di un flusso di dati seguono sulla rete può variare dinamicamente, ma non esistono nel TCP meccanismi per garantire il mantenimento di una data larghezza di banda tra mittente e destinatario per tutta la durata della connessione. Il TCP non fornisce informazioni sulle temporizzazioni tra pacchetti appartenenti ad uno stesso flusso dati, molto importanti per supportare il multimedia. Per far fronte a queste esigenze ed accrescere l architettura di Internet, per poterla rendere adatta alle comunicazioni multimediali, sono stati sviluppati vari protocolli di alto livello come RTP/RTCP, SRM, RSVP, ecc. Multimedia su Internet 12

Il protocollo RTP/RTCP 1/8 RTP (Real Time Transport Protocol versione 2) (Schulzrinne et alter, 1996) è un protocollo di trasporto dati a livello applicativo per applicazioni real-time. Esso è accompagnato dal protocollo RTCP (Real Time Control Protocol) ed è uno standard Internet, definito nel RFC 1889 del IETF AVT WG, dal Gennaio 1996. RTP non è legato ad un tipo particolare di dati multimediali, ma è utilizzabile da tutte quelle applicazioni che lavorano in tempo reale, e perciò richiedono il rispetto di specifici vincoli di tempo per il trasporto dei loro dati attraverso una rete di comunicazione. RTP fornisce alle applicazioni che lo utilizzano servizi come identificazione del tipo di dati trasportati (payload type), numeri di sequenza e indicizzazione temporale (timestamping) dei pacchetti. RTP non fornisce tutte le funzionalità tipiche dei protocolli di trasporto. Infatti per trasportare i pacchetti RTP si fa uso tipicamente del protocollo UDP (anche se si possono usare altri protocolli), di cui si usano servizi quali multiplexing e checksum. Multimedia su Internet 13

Il protocollo RTP/RTCP 2/8 Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V=2 P X CC M PT sequence number +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ timestamp +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ synchronization source (SSRC) identifier +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ contributing source (CSRC) identifiers... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ defined by profile length +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ header extension Multimedia su Internet 14

Il protocollo RTP/RTCP 3/8 I primi 12 ottetti sono presenti in ogni pacchetto, mentre la lista dei CSRC (Contributing SouRCe) è presente solo quando è inserita da un mixer (un'entità che riunisce diversi flussi RTP in un unico flusso; il CRSC identifica le sorgenti dei flussi originari miscelati). Versione (V): questo campo di 2 bit identifica la versione di RTP usata nel pacchetto (attualmente esiste la versione 2). Padding (P): è un campo di un bit che, se è settato (1), indica che il pacchetto contiene uno o più ottetti di riempimento posti in coda ai dati, ma che non ne fanno parte. L ultimo ottetto usato per il riempimento indica il numero totale degli ottetti di padding presenti. Estensione (X): è un campo di un bit che, se è settato (1), indica la presenza di un estensione dell header, posta dopo l ultimo CSRC (se presenti). Il campo length indica il numero di parole di 32 bit presenti nell header exstension, mentre il campo indicato con defined by profile sono liberamente utilizzabili da chi definisce l estensione. Il meccanismo delle estensioni permette di sperimentare l uso di campi addizionali nell header senza richiedere un cambio della versione di RTP. Multimedia su Internet 15

Il protocollo RTP/RTCP 4/8 Contatore dei CSRC (CC): contiene il numero di CSRC che seguono la parte fissa dell header. Marker (M): è un campo di un bit, la cui interpretazione dipende dal profilo dei dati trasportati. Può indicare il confine (l ultimo pacchetto) di un frame video, trasportato in più pacchetti RTP. Payload Type (PT): è un campo di 7 bit che indica il tipo di dati trasportati. La specifica dei codici utilizzati nel PT è contenuta in opportuni RFC detti profile. Uno di questi è l'rfc 1890 AVP (Audio Video Profile), contenente i codici PT per i vari sistemi di codifica standard dell audio e del video. Sequence Number: campo di 16 bit, viene incrementato di uno per ogni pacchetto RTP trasmesso. Un ricevitore può usarlo per individuare perdite di pacchetti, e per riordinare i pacchetti ricevuti fuori ordine. Il sequence number del primo pacchetto di un flusso RTP è scelto in modo casuale. Multimedia su Internet 16

Il protocollo RTP/RTCP 5/8 Timestamp : campo a 32 bit che riflette l istante di campionamento del primo ottetto dati contenuto nel pacchetto RTP. Il timestamp è derivato da un orologio incrementato monotonicamente e linearmente, per permettere la sincronizzazione e il calcolo dello jitter. Quindi la risoluzione di questo orologio deve essere tale da garantire l accuratezza necessaria per queste elaborazioni. Il valore del timestamp del primo pacchetto di un flusso RTP è scelto casualmente. Pacchetti RTP consecutivi possono avere lo stesso timestamp: questo significa che essi trasportano dati logicamente correlati (come nel caso di un frame video trasportato in più pacchetti consecutivi). Per alcuni tipi di payload, i timestamp di pacchetti consecutivi non sono necessariamente ordinati secondo un andamento monotono non decrescente (p.e., MPEG). Synchronized SouRCe (SSRC): campo a 32 bit che identifica la sorgente dei dati trasportati. Gli SSRC sono scelti casualmente, e con l accortezza che essi siano unici all interno di una stessa sessione multimediale. Contributing SouRCe (CSRC): da 0 a 15 campi di 32 bit ognuno; identificano le sorgenti dei dati contenuti nel pacchetto. I CSRC sono inseriti dai mixer usando gli SSRC dei flussi multimediali miscelati. Un pacchetto che sia in tal modo generato, conterrà come SSRC quello del mixer. Multimedia su Internet 17

Il protocollo RTP/RTCP 6/8 L header del pacchetto RTP trasporta quindi le informazioni necessarie per la temporizzazione e la sincronizzazione "intra-stream" dei flussi multimediali, e le informazioni necessarie alle applicazioni, che lo utilizzano, per monitorare ed eventualmente correggere perdite di pacchetti, oppure il loro arrivo fuori ordine. Il protocollo non implementa nessun meccanismo per correggere questi ed altri errori, né fornisce primitive necessarie alla contrattazione della qualità del servizio Il protocollo RTCP è un protocollo di controllo che lavora insieme a RTP. I pacchetti di controllo RTCP sono trasmessi periodicamente in una sessione da ogni partecipante a tutti gli altri, per creare il feedback necessario per il controllo dell andamento della sessione Multimedia su Internet 18

Il protocollo RTP/RTCP 7/8 Fornisce all applicazione che lo usa le informazioni riguardanti la qualità della distribuzione dei dati. Sia i trasmittenti che i riceventi inviano pacchetti RTCP contenenti statistiche che includono il numero dei pacchetti spediti, quello dei pacchetti persi, una stima della varianza statistica del tempo di interarrivo dei pacchetti (interarrival jitter). Queste informazioni sono utili ad esempio ai trasmittenti per adattare dinamicamente la loro velocità di trasmissione alle variazioni del carico della rete (congestione); i riceventi possono comprendere se i problemi di ricezione sono generati da cause locali o globali; altri agenti di terze parti (es., monitor) possono valutare il rendimento nelle comunicazioni multicast della rete da loro gestita; I pacchetti RTCP trasportano l identificatore, a livello di trasporto, della sorgente di pacchetti RTP (CNAME, canonical name), necessario per tenere traccia dei partecipanti di una sessione; RTCP controlla il traffico dei suoi pacchetti, tenendolo al di sotto di un limite fissato al 5% (al massimo) del traffico complessivo della sessione, per evitare di sprecare risorse di rete necessarie ad RTP per gestire senza problemi anche un grande numero di partecipanti (scalabilità). Questo controllo viene effettuato variando il numero dei pacchetti trasmessi nell unità di tempo, tenendo conto del numero totale dei partecipanti alla sessione; RTCP può trasportare le informazioni minime per controllare i partecipanti di una sessione, come ad esempio il nome, l indirizzo di posta elettronica, il numero di telefono, ecc. Multimedia su Internet 19

Il protocollo RTP/RTCP 8/8 PT encoding audio/video clock rate channels name (A/V) (Hz) (audio) 0 PCMU A 8000 1 1 1016 A 8000 1 2 G721 A 8000 1 3 GSM A 8000 1 4 unassigned A 8000 1 5 DVI4 A 8000 1 6 DVI4 A 16000 1 7 LPC A 8000 1 8 PCMA A 8000 1 9 G722 A 8000 1 10 L16 A 44100 2 11 L16 A 44100 1 12 unassigned A 13 unassigned A 14 MPA A 90000 15 G728 A 8000 1 16--23 unassigned A 24 unassigned V 25 CelB V 90000 26 JPEG V 90000 27 unassigned V 28 nv V 90000 29 unassigned V 30 unassigned V 31 H261 V 90000 32 MPV V 90000 33 MP2T AV 90000 34--71 unassigned? 72--76 reserved N/A N/A N/A 77--95 unassigned? 96--127 dynamic? Multimedia su Internet 20

Altri protocolli SRM Scalable Reliable Multicast. Supporta lo scambio affidabile di messaggi multicast LRMP Light Weight Reliable Multicast Protocol RTSP Real Time Streaming Protocol. Supporta il controllo remoto di un processo di streaming RSVP ReSource reservation Protocol. Supporta la riservazione di risorse lungo una rete IP SAP Session Announcement Protocol. Supporta l annuncio di sessioni multimediali su Mbone SDP Session Description Protocol. Supporta la descrizione di sessioni multimediali Multimedia su Internet 21

Modelli applicativi Il modello LWS (Light- Weight Session) è stato sviluppato presso il LBL (Lawrence Berkeley Laboratory) (Van Jacobson) in collaborazione con Xerox PARC, MIT e ISI. E un modello di comunicazione per applicazioni collaborative. Il modello LWS, una generalizzazione dell IP multicast, nasce dalla critica agli enormi svantaggi delle soluzioni ed approcci orientati alla connessione per l'implementazione di applicazioni multimediali quali: lavoro collaborativo e videoconferenza interattiva. Il modello A/L (Announce/Listening) Multimedia su Internet 22

Light-Weight Session: Motivazioni Troppo onere elaborativo sugli utenti, i quali dovevano conoscere tutti gli altri partecipanti e i dettagli della topologia di rete. Possibilità di scalabilità minime: se ognuno parla ed ascolta ogni altro, si creerebbero O (n 2 ) connessioni per n partecipanti. Nessuna affidabilità: la conferenza fallirebbe se solo una delle connessioni si interrompesse. Intolleranza: esistono non poche difficoltà a far entrare nuovi membri in una conferenza già attiva. Lentezza: in una conferenza si comunicherebbe ad una velocità non superiore a quella a cui può comunicare il partecipante più lento. Multimedia su Internet 23

Light-Weight Session Il modello LWS è caratterizzato dal fatto di non porre nessun tipo di carico elaborativo sugli utenti, possiede tutta la scalabilità, la tolleranza agli errori e la robustezza di IP, gestisce connessioni discontinue, e riesce ad avere un buon rendimento anche in situazioni in cui i partecipanti usano collegamenti con larghezze di banda molto diverse. I blocchi che compongono LWS sono: IP (datagrammi trasportati secondo la logica best-effort ); IP multicast; Recupero degli errori di sincronizzazione tramite tecniche di adattamento in ricezione; Strato di trasporto sottile (secondo il modello Application Layer Framing (ALF) di Clark, MIT) Multimedia su Internet 24

Applicazioni multimediali su MBone Su MBone sono state realizzate molte applicazioni multimediali le quali permettono di inviare audio, video, testo, grafici in modalità interattiva ed integrata. Tali applicazioni sono costruite con un approccio che si fonda sul modello ALF (Application Level Framing), sul modello Light- Weight Sessions e sul modello receiver-based. Il controllo della conferenza è completamente distribuito, e ciò su MBone da i seguenti vantaggi: inerente tolleranza all errore e proprietà di scalabilità. Tra le applicazioni multimediali di conferencing nell ambito del Group Communication gli MBone Tools, sviluppati presso la UCB (Università di Berkeley in California) ed attualmente manutenuti presso il UCL, sono certamente i più famosi, usati e testati. Essi sono composti da VIC, per inviare e ricevere video, VAT, per inviare e ricevere audio, Session Directory (SDR), per annunciare sessioni multimediali su MBone, WhiteBoard (WB), per scambiare messaggistica testuale e grafica all interno di un gruppo. Multimedia su Internet 25

VIC 1/2 Video Conference Tool (VIC) è stato progettato da S. McCanne e Van Jacobson in modo da avere un architettura flessibile ed estendibile per supportare configurazioni ed ambienti eterogenei (reti con larghezze di banda molto differenti). Si basa sul protocollo RTP (versione 2), e può funzionare sia per comunicazioni multicast che unicast. VIC include una particolare implementazione della tecnica di codifica H.261, detta Intra- H.261, con cui si ottengono prestazioni generali migliori (es. rapporti di compressione maggiori), rispetto all H.261 standard. Inoltre sono supportati il formato dati di NV, il CellB della Sun, ed il Motion-JPEG. Tramite un meccanismo detto Conference Bus (che si basa su uno scambio di messaggi multicast su UDP, sul loopback dell host su cui sono in esecuzione contemporaneamente più MBone Tool), VIC riesce ad evidenziare le immagini relative allo speaker corrente perché riceve da VAT, che sta ricevendo lo stream audio, un appropriato messaggio. Il Conference Bus può supportare messaggistica per implementare meccanismi di floor-control. Inoltre VIC implementa un meccanismo per limitare il traffico complessivo di una sessione multimediale, basandosi sul TTL della sessione stessa. Multimedia su Internet 26

VIC 2/2 Multimedia su Internet 27

VAT 1/2 Videoconference Audio Tool (VAT) è stato progettato da S. McCanne e Van Jacobson e permette a più host di partecipare ad una audio-conferenza in uno scenario multicast o unicast. VAT permette di trasmettere e ricevere flussi audio in differenti codifiche, come PCM, ADPCM, GSM, LPC, e di utilizzare inoltre trasmissioni criptate. Multimedia su Internet 28

VAT 2/2 Multimedia su Internet 29

WB 1/2 WB (Whiteboard) permette di condividere tra più host documenti in tempo reale (opera sia in unicast che in multicast). I documenti possono essere nel formato Adobe PostScript, oppure in formato testo (ASCII). Quando un utente decide di condividere un documento in una sessione, questo verrà trasmesso a tutti i partecipanti alla sessione. Il controllo della sessione è informale e debole, ovvero chiunque può controllare la sessione condivisa. In tal caso l utente che possiede il controllo della sessione, può scrivere testo, disegnare grafici, fare annotazioni libere all interno del documento condiviso. Per evitare che possano esserci interferenze provenienti da utenti non autorizzati, WB implementa un meccanismo di criptaggio. WB basa le sue comunicazioni su un protocollo proprietario detto WB protocol, simile ma incompatibile con RTP. Si basa sui concetti di SRM. Multimedia su Internet 30

WB 2/2 Multimedia su Internet 31

Altre applicazioni TOOL SD (Session Directory) e SDR (Session DiRectory Tool) RAT (Robust Audio Tool) RtpTools (recorder e player) ICast IP/TV NTE (Network Text Editor) Java RTP player (JMF) Sistemi VideoRecording on-demand (MVoD, MoD, IMJ, ViCRO, Colibrary) DVE (Distributed Virtual Environment) ecc. Multimedia su Internet 32

Framework per lo sviluppo di sistemi multimediali su Internet I frameworks multimediali sono ambienti di programmazione che permettono di creare e semplificare lo sviluppo di differenti applicazioni multimediali permettendo il riuso di codice e di pattern di progetto. Il middleware multimediale è uno strato software basato su rete il cui obiettivo è quello di scalare ed integrare applicazioni e protocolli per il multimedia su ambienti massivamente eterogenei. MASH toolkit. In corso di sviluppo presso il Berkeley Multimedia Research Center (BMRC) dell Università di Berkeley. Java Media Framework. Promosso dalla Sun. RealMedia SDK, Windows Media Player SDK, NetMeeting SDK, ecc. Multimedia su Internet 33

Caratteristiche delle applicazioni future Sincronizzazione di flussi multimediali multipli (p.e., lyp sinc) Adattatività alle condizioni di rete (monitoring e transcoding, p.e., mediagateway) Robustezza (ridondanza e priorità, p.e., PET) Interattività Multimedia su Internet 34