Comunicazioni real-time nel web: attività di standardizzazione in ambito IETF e W3C

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Reti di Calcolatori Comunicazioni real-time nel web: attività di standardizzazione in ambito IETF e W3C Anno Accademico 2011/2012 Candidato: Martusciello Ciro matr. N46/660

2 Alla mia famiglia e a tutti coloro che hanno creduto in me.

3 Indice Introduzione 4 Capitolo 1. Le organizzazioni internazionali W3C (World Wide Web Consortium) IETF (Internet Engineering Task Force) 7 Capitolo 2. Standard di Comunicazione Real-Time nel Web WebRTC (W3C) e RTCWEB (IETF) Modello architetturale RTC Segnalazione Struttura concettuale API WebRTC 13 Capitolo 3. HTML5 15 Capitolo 4. Protocolli nel Web Real-Time RTP / RTCP Header RTP RTCP VoIP SIP SDP 22 Capitolo 5. Il problema dei Codec 23 Sviluppi futuri 25 Bibliografia 26 III

4 Introduzione L innovazione tecnologica sta man mano trasformando il web che conosciamo nel IoT (Internet of Things Internet delle cose). Oltre ai dispositivi convenzionali come PC, smartphone, TV, console di gioco, ecc., troveremo connessi in rete oggetti domestici come frigoriferi, lavatrici, forni a microonde, allarmi ecc. Gli utenti del web di domani dovranno interfacciarsi con una rete che mira alla comunicazione istantanea (Real-Time Communication RTC) tra end-users, che questi siano persone o applicazioni. Nasce quindi l esigenza di standardizzare protocolli e interfacce di comunicazione che rendano possibile tale interazione. Organizzazioni internazionali, come il W3C e la IETF, lavorano a tal proposito. Negli ultimi anni, infatti, gli studi sono stati concentrati prevalentemente sull innovazione del Web Real-Time (RT). Gli sviluppatori web dovranno quindi avere la possibilità di integrare servizi di comunicazione audio/video in qualsiasi sito Internet. Un applicazione web in esecuzione su un dispositivo, deve poter essere in grado di inviare e ricevere file multimediali attraverso un accesso sicuro alle periferiche del dispositivo stesso, quali, per esempio, microfono e webcam. 4

5 Di conseguenza, i browser presenti su ogni dispositivo connesso in rete, dovranno dare la possibilità di accedere a tali servizi da ogni piattaforma (fissa o mobile che sia, indipendentemente dal sistema operativo). È soprattutto interesse degli sviluppatori di web browser investire in tali tecnologie, per essere maggiormente competitivi sul mercato del futuro. Tra le società già al lavoro in tal senso troviamo: Google (Chrome), Mozilla (Firefox), Microsoft (Internet Explorer), Apple (Safari). La sfida dei giganti del mercato menzionati è quella di integrare l innovazione del web RT nei propri servizi, garantendone la qualità e migliorando l efficienza in banda, soprattutto per quanto riguarda i dispositivi mobili. La problematica principale, che gli organi di standardizzazione cercano di risolvere, risiede principalmente nel fatto che si vuol rendere possibile una comunicazione multimediale tra browser, senza passare per un web server. Si parla dunque di comunicazione browser-to-browser in una rete Peer-to-Peer (P2P). È in via di sviluppo, presso il W3C, la standardizzazione di un interfaccia specifica (la API WebRTC) che permetta ai web browser di interfacciarsi con i dispositivi multimediali disponibili (utilizzando un linguaggio di scripting come JavaScript). La IETF, parallelamente, si occupa di standardizzare uno stack di protocolli utilizzabili al fine di rendere possibile l approccio di comunicazione browser-tobrowser (attraverso RTCWEB). Inoltre, è essenziale stabilire meccanismi di protezione per la sicurezza degli endusers e l integrità dei dati trasmessi (che, in questo contesto, sono rappresentati da flussi multimediali). 5

6 Capitolo 1 Le organizzazioni internazionali 1.1 W3C (World Wide Web Consortium) Il W3C (World Wide Web Consortium) è un organizzazione internazionale fondata nel 1994 da Tim Berners-Lee presso il MIT (Massachusetts Institute of Technology). Figura 1 - logo W3C Il W3C ha lo scopo di sviluppare e validare standard per l utilizzo e l evoluzione del web. Gli standard sono inerenti ai linguaggi di markup (HTML), ai linguaggi di scripting (JavaScript) e soprattutto all interazione tra utente e applicazioni tramite interfacce (definizione di API per l accesso ai dispositivi). Per questo motivo si può assumere che il lavoro del W3C è di tipo Client-side. Il W3C è composto da circa 400 membri, tra cui grandi aziende informatiche, compagnie telefoniche e di telecomunicazioni, organizzazioni no-profit e università. La forza di questa organizzazione sta nel fatto che combina gli interessi delle più grandi aziende internazionali, per le quali l evoluzione del web è fondamentale. 6

7 Infatti, per poter approvare una Recommendation (documento redatto al termine della revisione inerente uno standard), questa deve essere controllata diverse volte dai membri dell organizzazione stessa, aventi interessi differenti in quanto appartenenti ad aziende con un proprio mercato. Come risultato finale si ottiene un documento che, di fatto, standardizza la nuova tecnologia o modifica uno standard obsoleto. Il motto del W3C: Lead the web to its full potential Portare il web al suo massimo potenziale. 1.2 IETF (Internet Engineering Task Force) La IETF (Internet Engineering Task Force) è, come il W3C, un organizzazione internazionale. A differenza della prima, questa è un organizzazione composta da tecnici, Figura 2 - logo IETF ricercatori e sviluppatori, ognuno dei quali è iscritto a titolo personale e non in riferimento ad un azienda. La IETF si occupa sostanzialmente della definizione di standard inerenti all evoluzione tecnologica del web. È meno Client-side rispetto al W3C ed è, quindi, più orientata agli aspetti tecnici della rete. Gli standard sono, infatti, inerenti a protocolli, privacy, sicurezza, riusabilità. Le persone che ne fanno parte sono suddivise in working groups, ognuno dei quali è specializzato in un argomento particolare. 7

8 Ogni gruppo termina un lavoro pubblicando una RFC (Request for Comments), che sarà poi visionata dalla IESG (Internet Engineering Steering Group) per diventare concretamente uno standard. Le RFC sono pubbliche e tutti gli standard approvati dalla IETF sono open-source. Il motto della IETF: Rough consensus and running code Consenso diffuso e codice funzionante. W3C e IETF collaborano, quindi, affinché gli sviluppatori web del futuro siano in grado di integrare servizi RT in ogni sito Internet. Per rendere possibile questa realtà, nasce il bisogno di standardizzare: - Regole di comunicazione (come i protocolli da utilizzare), delle quali si occupa la IETF. - Interfacce da rendere disponibili per l accesso alle nuove funzionalità RT, per esempio le API (Application Programming Interface) sviluppate dal W3C. 8

9 Capitolo 2 Standard di Comunicazione Real-Time nel Web I gruppi di lavoro WebRTC e RTCWEB, appartenenti rispettivamente al W3C e alla IETF, lavorano in modo coordinato per definire sia le API, sia i protocolli di comunicazione di base, che servono a stabilire una connessione sicura ed affidabile tra due browser (comunicazione browser-to-browser) in una rete P2P. [1] 2.1 WebRTC (W3C) e RTCWEB (IETF) La API WebRTC ha come scopo quello di definire un interfaccia di comunicazione per una qualsiasi applicazione web (in esecuzione su un dispositivo) che permetta all applicazione stessa di inviare e ricevere flussi multimediali RT in una rete P2P. Inoltre, tale interfaccia, deve fare in modo che l applicazione possa comunicare con le periferiche multimediali dedicate, come microfono, altoparlanti e webcam. Se si riuscirà ad ottenere questo set di funzionalità, si avrà un ampliamento dello standard HTML5 (discusso nel cap. 3), che stabilisce, per ora, un modello di comunicazione tra web server e browser per streaming multimediali. 9

10 Figura 3 Schema di riferimento delle iniziative WebRTC (W3C) e RTCWEB (IETF) [2] In Figura 3 possiamo avere una visione, ad alto livello, della distinzione delle attività di standardizzazione, da parte del W3C e della IETF. Il gruppo WebRTC (W3C) sta formalizzando interfacce JavaScript (il linguaggio di scripting maggiormente utilizzato per la programmazione nel Web) che rendano possibile l integrazione di funzionalità RT in un sito Internet. In particolare, queste interfacce (o API), dovranno permettere di: Accedere ai dispositivi di acquisizione audio/video degli utenti. Stabilire connessioni dirette tra browser (browser-to-browser) per consentire lo scambio bidirezionale di flussi multimediali (audio, video, dati). Visualizzare tali flussi sul proprio terminale (fisso o mobile). [2] 10

11 Il gruppo RTCWEB (IETF) si occupa, invece, di stabilire con quali modalità dovranno essere utilizzati i protocolli di trasporto concreto dei flussi multimediali. Tali protocolli sono usati anche nelle comunicazioni VoIP (cap. 4). In particolare, RTCWEB definisce: L utilizzo del protocollo RTC (cap. 4) per il trasporto audio/video. Meccanismi NAT Trasversal (basati sui protocolli STUN, TURN, ICE) per le reti non direttamente raggiungibili da Internet. Codec audio e video da utilizzare. [2] 2.2 Modello architetturale RTC Il modello architetturale RTC (Real-Time Communication), illustrato in Figura 4, è il cosiddetto modello trapezoidale. [1] Tale modello mette in risalto il fatto che le applicazioni web presenti in un terminale (scritte in HTML o in JavaScript), possano comunicare con il browser attraverso la API WebRTC. Tale interfaccia deve quindi inglobare funzionalità di segnalazione, gestione delle connessioni, codifica/decodifica dei flussi multimediali, NAT. Il problema essenziale risulta prevalentemente quello di gestire, in tempo reale, un flusso di comunicazione continuo tra due browser, senza intermediari lungo il percorso (come, ad esempio, i web server). 11

12 Figura 4 - Modello architetturale RTC [1] 2.3 Segnalazione Nelle reti di comunicazione VoIP, il protocollo di segnalazione utilizzato è il SIP (cap. 4). Per quanto riguarda il WebRTC, invece, non si è ancora deciso quale protocollo di segnalazione utilizzare. In effetti, l idea è quella di demandare all applicazione stessa la responsabilità della segnalazione (e quindi del protocollo da usare). Di conseguenza, diverse applicazioni possono decidere di implementare diversi protocolli di segnalazione, indipendentemente dalla API WebRTC. Le informazioni che, invece, i browser dovranno necessariamente scambiarsi, riguardano la descrizione della sessione multimediale (ICE) e le caratteristiche dei file multimediali da inviare/ricevere (tipo, formato, ecc.). 12

13 2.4 Struttura concettuale API WebRTC Come già introdotto, la API WebRTC (W3C) ha lo scopo di fornire ai browser tutte le funzionalità per la gestione di flussi multimediali in real-time. Il progetto dell interfaccia, da parte del W3C, si è incentrato su tre concetti fondamentali: PeerConnection, MediaStreams, DataChannel. PeerConnection Rappresenta una corrispondenza diretta con un peer remoto, oppure, più tecnicamente, con un istanza della stessa applicazione sul peer remoto. Per garantire l attraversamento dei router NAT, da parte dei flussi multimediali UDP, il meccanismo PeerConnection adotta i protocolli ICE (Interactive Connectivity Establishment), STUN (Session Traversal Utilities for NAT) e TURN (Traversal Using Relays around NAT). MediaStreams Rappresenta un astrazione di flusso multimediale reale (audio o video), che può provenire, o essere inviato, da/verso un host remoto. Si parla di LocalMediaStream quando si vuol rappresentare un flusso multimediale proveniente da un dispositivo di acquisizione locale (microfono o webcam). Il LocalMediaStream è ciò a cui l applicazione web deve richiedere l accesso, che sarà consentito o negato da parte dei selettori presenti nell interfaccia del browser. Per il trasporto dello stream multimediale viene utilizzato il protocollo SRTP (Secure Real-Time Transport Protocol). Il monitoraggio delle statistiche di trasmissione è affidato al protocollo RTCP (cap. 4). 13

14 DataChannel Rappresenta un servizio di trasporto generico che consente ai web browser di scambiarsi dati di ogni genere (multimediali e non). Per i dati non multimediali, la IETF ha standardizzato l utilizzo del protocollo SCTP (Stream Control Transmission Protocol) che garantisce, insieme ai protocolli DTLS, ICE e UDP, una soluzione al problema del NAT e l integrità dei dati trasmessi. SCTP è stato scelto poiché consente alle applicazioni di aprire diversi flussi multimediali indipendenti contemporaneamente verso uno stesso peer. Ogni flusso rappresenta un canale monodirezionale, sul quale i dati multimediali viaggiano in modo sequenziale, ordinatamente e non. Figura 5 - Stack dei protocolli RTCWEB [1] 14

15 Capitolo 3 HTML5 HTML5 rappresenta un modello di comunicazione tra web server e browser per streaming multimediali. Sarà concretamente uno standard solo nel 2014 e le versioni successive saranno revisionate e pubblicate dal W3C, sottoforma di Recommendation, a partire dal Figura 6 - Logo HTML L evoluzione introdotta da HTML5, rispetto alle versioni precedenti, risiede in due aspetti fondamentali: Aumentare la coesione tra la struttura di un testo (definita dai markup), la sua formattazione, i contenuti multimediali di una pagina web e i suoi fogli di stile CSS (Cascading Style Sheets). Supportare la memorizzazione di contenuti web in locale, in modo da consentire la visualizzazione di tali contenuti anche offline. 15

16 HTML5 sarà quindi più fluido ed intuitivo per i web developers. Saranno poi eliminate diverse funzionalità, reputate poco utili nelle versioni precedenti (poiché utilizzate molto raramente). Tra le novità, hanno notevole spicco i nuovi tag introdotti (<video> e <audio>) per la gestione e il controllo di file multimediali. Verranno migliorati ed estesi tag di controllo per la formattazione del testo e per la gestione della navigazione nei menu. Sarà possibile integrare un servizio di geolocalizzazione, dovuto alle esigenze e potenzialità dei nuovi sistemi operativi mobili. Figura 7 - HTML5 come combinazione di Markup, JavaScript, CSS3 e Multimedia [4] HTML5 offre, quindi, una vasta gamma di innovazioni rispetto alle versioni precedenti. Non è più un semplice linguaggio di markup, ma abbraccia concetti differenti quali: connettività, gestione dati offline, multimedialità, prestazioni elevate, integrazione con sistemi antecedenti, controllo tipografico flessibile (CSS3). 16

17 Capitolo 4 Protocolli nel Web Real-Time I protocolli di trasporto tipici dello stack TCP/IP sono TCP e UDP. Il primo, TCP, garantisce una consegna affidabile in termini di garanzia di consegna dei pacchetti e di ricezione nello stesso ordine in cui sono stati inviati. TCP stabilisce una connessione, tra mittente e destinatario, che viene chiusa solo al termine dell intera trasmissione e, inoltre, utilizza tutta la banda a sua disposizione. Ci si rende subito conto che TCP, proprio per i suoi eccessivi controlli sull affidabilità delle trasmissioni, non è adatto a streaming multimediali. La trasmissione di un flusso dati multimediale non richiede tutte queste garanzie, è ben più importante gestire i ritardi concedendo la riproduzione dello streaming, tollerando anche qualche perdita. Per questo motivo, per trasmettere un flusso di dati multimediali, è più indicato il protocollo UDP. UDP è non-affidabile poiché non garantisce la consegna dei pacchetti e non stabilisce alcuna connessione tra mittente e destinatario. Di conseguenza, risulta più leggero e quindi più adatto allo streaming multimediale. 17

18 4.1 RTP / RTCP Il protocollo adibito al trasporto di flussi multimediali è l RTP (Real-Time Transport Protocol). RTP si appoggia ad UDP (i pacchetti RTP sono incapsulati in datagrammi UDP, come mostra la Figura 8) ed è dichiarato come protocollo di livello Trasporto nello stack TCP/IP, anche se lo si potrebbe collocare a livello Applicazione. Infatti, ogni applicazione deve implementare l RTP per l incapsulamento in pacchetti UDP. Figura 8 - Incapsulamento RTP in UDP Quindi, i pacchetti RTP sono visti dall applicazione attraverso una socket UDP (una socket è un interfaccia che si frappone tra il livello applicativo e quello di trasporto, può essere vista come un file). Inoltre, RTP, supporta sia trasmissioni unicast, sia multicast. 18

19 La gestione di eventuali pacchetti persi e della ricostruzione ordinata della sequenza è demandata all applicazione client. Per ogni sessione creata è possibile trasmettere un unico flusso multimediale. Quindi, se per esempio si volesse assistere ad una videoconferenza, dovrebbero essere attive due sessioni: una per l audio e l altra per il video. In questo modo, si ha la possibilità di scegliere anche uno solo dei due flussi. Comunque, RTP mette a disposizione un tipo alternativo di incapsulamento, che rende possibile la fusione di due flussi multimediali in un unica sessione Header RTP Figura 9 - RTP Header Pyload Type: numero identificativo che indica il tipo di contenuto multimediale (Motion JPEG, H.261, MPEG1, MPEG2, ecc.). Sequence Number: rende possibile un ordinamento dei pacchetti (a carico dell applicazione client). Timestamp: istante di campionamento del primo byte del file multimediale; serve ad eliminare il jitter (variazione di ampiezza, frequenza o fase) dovuto al canale. Synchronization Source Identifier (SSRC): identificatore della sorgente dello stream. Ve n è uno per ogni flusso. Miscellaneous Fields: campi generici. 19

20 4.1.2 RTCP Talvolta RTP è associato al protocollo RTCP (Real-Time Control Protocol), che non è sempre implementato. RTCP è un protocollo di monitoraggio della trasmissione e consiste nello scambio di messaggi (report) tra mittente e destinatario. Ogni report contiene informazioni riguardo la QoS (Quality of Service) della trasmissione, come il numero di pacchetti persi, il jitter e il RTT (Round Trip Time). I report sono divisi in due categorie principali: - Sender Reports (SR), contenenti informazioni sulla sorgente. - Receiver Reports (RR), contenenti statistiche del client. Nel caso di trasmissioni multicast, RTCP consente ad ogni partecipante di conoscere il numero di partecipanti e, per limitare il traffico di messaggi, l intervallo temporale tra due report è proporzionale proprio al numero di partecipanti alla sessione. [6] Figura 10 - Struttura di trasmissione report RTCP [6] 20

21 4.2 VoIP VoIP (Voice over IP) è il protocollo (di livello Applicazione) utilizzato per effettuare conversazioni telefoniche servendosi del web, anziché della consueta linea telefonica. Infatti, VoIP trasforma il segnale vocale (analogico) in formato digitale e lo propaga nella rete sottoforma di pacchetti dati; a destinazione sarà riconvertito in analogico. In questo modo, il vantaggio principale offerto da VoIP è l eliminazione dell obbligo di riserva della banda (commutazione di circuito) per conversazioni telefoniche e sfrutta invece la comunicazione IP (commutazione di pacchetto). Per poter trasportare la voce sottoforma di pacchetti, VoIP utilizza il protocollo RTP; mentre per riconvertire i dati in voce, sincronizzarla e riordinarla cronologicamente a destinazione, può utilizzare diversi protocolli, tra cui SIP. [7] Tra le applicazioni che hanno avuto maggior successo implementando la tecnologia VoIP c è Skype. Grazie al VoIP, Skype ha dato la possibilità di stabilire comunicazioni, telefoniche e in videoconferenza, tra utenti sparsi in tutto il Figura 11 - Logo Skype mondo, a costi ridottissimi e qualità apprezzabile. Tra gli svantaggi del VoIP emerge la qualità non eccellente delle telefonate. Questa è dovuta principalmente ai ritardi (congestione della rete) e alla perdita eventuale di pacchetti. Tuttavia sono in via di sviluppo software che sopperiranno, al meglio, a tali problemi. 21

22 4.3 SIP SIP (Session Initiation Protocol) è un protocollo di segnalazione (a livello Rete) sviluppato dalla IETF, applicato a comunicazioni IP (come VoIP). Infatti, SIP è utilizzato per stabilire, gestire e concludere tali sessioni di comunicazione. Le principali responsabilità attribuite al protocollo SIP sono: Localizzazione degli utenti coinvolti nella comunicazione. Identificazione di: disponibilità, parametri di sessione e media utilizzati. Instaurazione della sessione. Gestione e terminazione della sessione. 4.4 SDP Il protocollo SDP (Session Description Protocol) è associato all utilizzo del protocollo SIP e offre un formato per la descrizione di una sessione. Tra i parametri descrittivi della sessione in corso, SDP specifica: informazioni inerenti il mittente; Time Description (tempi della sessione), caratteristiche dei media trasmessi e versione del protocollo. Combinando l utilizzo dei protocolli SIP e SDP è possibile stabilire una comunicazione multimediale in RT tra due peer (instaurazione da parte di SIP) e stabilizzare lo streaming nella sessione (tramite la negoziazione delle risorse gestita da SDP). 22

23 Capitolo 5 Il problema dei Codec Un Codec è un dispositivo hardware, o un software, capace di digitalizzare un segnale analogico (codificare/decodificare), in modo da poterlo memorizzare su un supporto apposito o trasmetterlo lungo un canale di comunicazione. [3] Il lavoro di standardizzazione per la comunicazione real-time nel web (RTC), compiuto dal W3C e dalla IETF, non ha ancora stabilito un set di codec (audio/video) da utilizzare. La scelta dei codec è un operazione complicata, in quanto è oggetto di discussioni e scontri dettati dagli interessi delle aziende produttrici di web browser. Uno dei problemi principali riguarda i brevetti e le licenze per l implementazione dei codec nei browser. Microsoft e Apple, per esempio, detengono i brevetti per i codec audio G e i codec video H.264. Google e Mozilla, invece, adottano una politica open-source e, di conseguenza, hanno necessità di utilizzare tecnologie libere, come i codec audio Opus e i codec video VP8. 23

24 Figura 12 - Qualità dei codec audio in funzione del bit-rate [2] In verde: codec senza licenza e open-source In blu: codec senza licenza ma non open-source In rosso: codec con licenze a pagamento e non open-source Altri parametri di discussione sono: - La qualità dei codec (Figura 12), poiché la richiesta di trasmissioni ad alta fedeltà audio/video è sempre maggiore. - L interoperabilità e l adattamento dei codec a sistemi di comunicazione esistenti. Grazie alle enormi quote di mercato (più del 50%) detenute da Google (con il browser Chrome) e da Mozilla (con il browser Firefox), la probabile decisione definitiva sarà quella di rendere obbligatori i codec open-source (Opus e VP8) negli standard e stabilire quanto e come utilizzare i codec licenziati da Microsoft e Apple. Sarà poi il mercato, e quindi gli utenti finali, a stabile che tipo di codec utilizzare in base ai browser più diffusi e ai parametri citati. [2] 24

25 Sviluppi futuri Il web che conosciamo si evolverà radicalmente verso una rete di comunicazioni istantanee, senza barriere dovute al tempo (grazie alla RTC) e allo spazio (grazie all integrazione dei dispositivi mobili in Internet). Nel frattempo che W3C ed IETF lavorano alla standardizzazione di tale realtà, diverse aziende sviluppano già applicazioni innovative e predisposte ad adattarsi alla RTC. Figura 13 Evoluzione del rapporto tra costi di realizzazione (in blu) e numero di servizi richiesti (in rosso) nella RTC [2] I problemi principali di tale tecnologia, che si cercano continuamente di aggirare, sono dovuti essenzialmente all adattamento delle reti esistenti verso il real-time. Un esempio di miglioramento, in termini di qualità ed efficienza in banda, è dato dal nuovo codec video della CISCO, H.265, adibito alle videoconferenze. [9] In conclusione, è chiaro che il Web Real-Time aprirà le porte a nuove frontiere della comunicazione tra esseri umani (e tra macchine) ovunque nel mondo e si spera possa migliorare la qualità della vita e del lavoro in ogni settore della società. 25

26 Bibliografia [1] S.P.Romano, S.Loreto Real-Time Communications in the Web [2] A.Baravaglio, A.Cuda, E.Marocco WebRTC: la nuova sfida nelle comunicazioni real-time audio/video Bibliografia web [3] Wikipedia The free enciclopedia HTML5 - VoIP - SIP - Codec - [4] HTML5 Italia: [5] Computer Engineering Group - Università Degli Studi di Parma Protocollo RTP - [6] Gruppo Comics RTP/RTCP Slide del corso di Reti di Calcolatori I [7] Mondo VoIP - [8] SDP: Description-Protocol#outer_page_11 [9] M.Dalmazzoni 2012 Cisco ridefinisce lo standard del video con H