Lo strato applicativo di Internet

Streaming e comunicazione Web

Questo capitolo è svolto in modo parziale, incompleto e frammentario. Sperabilmente, i suoi contenuti saranno approfonditi ed estesi. In tutti i modi, c'è già qualche incipit interessante.

Introduzione

Trattiamo prima dello Streaming, ovvero la trasmissione e la fruizione di contenuti multimediali (audio e/o video) via Internet in modalità unidirezionale, ossia da una unica sorgente verso uno o più destinatari, senza che questi ultimi possano (debbano, vogliano) a loro volta inviare contenuti multimediali indietro al mittente.

Passiamo poi alla comunicazione Web, ovvero alle soluzioni in via di definizione che mirano a rendere il browser web l'unica interfaccia alla fruzione di applicazioni multimediali, sia di streaming che di comunicazione interpersonale e di gruppo, senza ricorrere a player esterni o plugin specifici.

Concludono il capitolo cenni a servizi on-line.

Streaming

Nella ricezione streaming sono fatte salve alcune funzionalità che potremmo definire tipiche di video-registratori e riproduttori di CD, MP3 e DVD, come la messa in pausa, il riavvolgimento e il fast forward, e l'accesso diretto ad un determinato istante temporale. Ma anche se l'unidirezionalità di base rende quasi ovvia una impostazione di tipo client-server della architettura, vi sono molti altri aspetti, come

che determinano importanti alternative realizzative, così variegate, da causare di fatto un rallentamento della affermazione della tecnologia. Dal punto di vista delle applicazioni di erogazione e fruizione dei contenuti, il principale spartiacque può identificarsi nelle alternative tra soluzioni aderenti a standard pubblici e soluzioni proprietarie.

Le soluzioni aderenti a standard pubblici sono conformi alle indicazioni contenute in documenti normativi come quelli emessi da IETF, ed hanno l'obbiettivo di favorire l'interoperabilità di apparati ed applicazioni di fornitori diversi, ma accomunati dal supporto a protocolli comuni come quello per il controllo (l'RTSP) dell'interazione tra client e server, quelli comuni al VoIP (l'SDP, l'RTP) per la descrizione ed il trasporto dei contenuti, ed a formati di codifica e pacchettizzazione descritti da standard pubblici.

Le soluzioni proprietarie tendono invece ad offrire soluzioni integrate, fornendo ad esempio sia i componenti server che i client, adottando protocolli e codec coperti da brevetto, applicando sistemi di protezione che impediscono la fruizione non autorizzata.

Infine, è da citare un approccio che di fatto consente di realizzare le funzioni basilari dell streaming (come ad esempio il posizionamento intermedio) anche con un protocollo nato per tutt'altro, come per l'HTTP streaming.

RTSP

Il Real Time Streaming Protocol è descritto nella RFC 2326, e da allora, soggetto a revisione. E' un protocollo strettamente Client-Server, e si occupa solo del controllo della riproduzione (inizio, pausa, posizionamento, arresto), delegando rispettivamente a SDP ed RTP i compiti di descrivere il contenuto, e di trasportare i dati multimediali. Sotto molti aspetti l'RTSP somiglia all'HTTP, ma a differenza di questo è stateful, in quanto la possibilità per il client di mettere in pausa la riproduzione, obbliga il server a ricordare per la durata della sessione, le informazioni relative ai suoi client. Svolgiamo un rapidissimo esempio del suo funzionamento, discutendo il seguente capture, in cui i messaggi inviati dal client sono indicati in rosso:

  1  OPTIONS rtsp://labtel.ing.uniroma1.it/spider-man2.mp4 RTSP/1.0
  2  CSeq: 9
  3  User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20)
  4
  5  RTSP/1.0 200 OK
  6  Server: DSS/5.5.4 (Build/489.13; Platform/Linux; Release/Darwin; )
  7  Cseq: 9
  8  Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD
  9
 10  DESCRIBE rtsp://labtel.ing.uniroma1.it/spider-man2.mp4 RTSP/1.0
 11  CSeq: 10
 12  Accept: application/sdp
 13  User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20)
 14
 15  RTSP/1.0 200 OK
 16  Server: DSS/5.5.4 (Build/489.13; Platform/Linux; Release/Darwin; )
 17  Cseq: 10
 18  Last-Modified: Fri, 13 Aug 2004 03:20:55 GMT
 19  Cache-Control: must-revalidate
 20  Content-length: 1223
 21  Date: Tue, 08 Apr 2008 04:48:00 GMT
 22  Expires: Tue, 08 Apr 2008 04:48:00 GMT
 23  Content-Type: application/sdp
 24  x-Accept-Retransmit: our-retransmit
 25  x-Accept-Dynamic-Rate: 1
 26  Content-Base: rtsp://labtel.ing.uniroma1.it/spider-man2.mp4/
 27
 28  v=0
 29  o=StreamingServer 3416618880 1092367255000 IN IP4 151.100.122.171
 30  s=/spider-man2.mp4
 31  u=http:///
 32  e=admin@
 33  c=IN IP4 0.0.0.0
 34  t=0 0
 35  a=control:*
 36  a=isma-compliance:1,1.0,1
 37  a=mpeg4-iod: "data:application/mpeg4-iod;base64,AoCAgxsAT///DwP/A4CAghgACUD0ZGF0YTphcHBsaWNh...."
 38  a=range:npt=0- 126.45500
 39  m=audio 0 RTP/AVP 96
 40  a=control:trackID=5
 41  a=rtpmap:96 mpeg4-generic/22050/2
 42  a=mpeg4-esid:1
 43  a=fmtp:96 streamtype=5; profile-level-id=15; mode=AAC-hbr; config=139000; SizeLength=13; IndexLength=3; IndexDeltaLength=3; Profile=1;
 44  m=video 0 RTP/AVP 97
 45  a=control:trackID=8
 46  a=rtpmap:97 MP4V-ES/6003
 47  a=mpeg4-esid:2
 48  a=fmtp:97 profile-level-id=1; config=000001b003000001b509000001000000012000845d4c283c2080a31f;

 49  SETUP rtsp://labtel.ing.uniroma1.it/spider-man2.mp4/trackID=5 RTSP/1.0
 50  CSeq: 11
 51  Transport: RTP/AVP;unicast;client_port=32906-32907
 52  User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20)
 53
 54  RTSP/1.0 200 OK
 55  Server: DSS/5.5.4 (Build/489.13; Platform/Linux; Release/Darwin; )
 56  Cseq: 11
 57  Last-Modified: Fri, 13 Aug 2004 03:20:55 GMT
 58  Cache-Control: must-revalidate
 59  Session: 6519445514613088315
 60  Date: Tue, 08 Apr 2008 04:48:00 GMT
 61  Expires: Tue, 08 Apr 2008 04:48:00 GMT
 62  Transport: RTP/AVP;unicast;source=151.100.122.171;client_port=32906-32907;server_port=6970-6971;ssrc=3C06B58A
 63
 64  SETUP rtsp://labtel.ing.uniroma1.it/spider-man2.mp4/trackID=8 RTSP/1.0
 65  CSeq: 12
 66  Transport: RTP/AVP;unicast;client_port=32910-32911
 67  Session: 6519445514613088315
 68  User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20)
 69
 70  RTSP/1.0 200 OK
 71  Server: DSS/5.5.4 (Build/489.13; Platform/Linux; Release/Darwin; )
 72  Cseq: 12
 73  Session: 6519445514613088315
 74  Last-Modified: Fri, 13 Aug 2004 03:20:55 GMT
 75  Cache-Control: must-revalidate
 76  Date: Tue, 08 Apr 2008 04:48:00 GMT
 77  Expires: Tue, 08 Apr 2008 04:48:00 GMT
 78  Transport: RTP/AVP;unicast;source=151.100.122.171;client_port=32910-32911;server_port=6970-6971;ssrc=0E4A8A71
 79
 80  PLAY rtsp://labtel.ing.uniroma1.it/spider-man2.mp4/ RTSP/1.0
 81  CSeq: 13
 82  Session: 6519445514613088315
 83  Range: npt=0.000-
 84  User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20)
 85
 86  RTSP/1.0 200 OK
 87  Server: DSS/5.5.4 (Build/489.13; Platform/Linux; Release/Darwin; )
 88  Cseq: 13
 89  Session: 6519445514613088315
 90  Range: npt=0.00000-126.45500
 91  RTP-Info: url=rtsp://labtel.ing.uniroma1.it/spider-man2.mp4/trackID=5;seq=1461;rtptime=700028915, url=rtsp://labtel.ing.uniroma1.it/spider-man2.mp4/trackID=8;seq=43098;rtptime=1922010545
 92
 93  TEARDOWN rtsp://labtel.ing.uniroma1.it/spider-man2.mp4/ RTSP/1.0
 94  CSeq: 14
 95  Session: 6519445514613088315
 96  User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20)
 97
 98  RTSP/1.0 200 OK
 99  Server: DSS/5.5.4 (Build/489.13; Platform/Linux; Release/Darwin; )
100  Cseq: 14
101  Session: 6519445514613088315
102  Connection: Close

Il client inizia il dialogo interrogando il server a riguardo dei metodi disponibili, mediante il metodo OPTIONS. Come si vede, anche in questo caso i messaggi convogliano informazioni semantiche mediante l'uso di intestazioni, come Cseq, che si incrementa di uno ad ogni nuovo messaggio del client, ed è citato uguale nella relativa risposta.

Alla riga 5 il sever risponde con una sintassi ormai nota, formata da una prima linea contenente un codice numerico di successo, ed alla riga 10 il client passa a chiedere la descrizione di una URI di cui si desidera la riproduzione. Questa descrizione è fornita nella risposta di riga 15, mediante un elemento SDP contenuto nel body della risposta stessa. Notiamo che negli header di questa risposta sono presenti elementi indicanti la data del contenuto originario, la data attuale, intestazioni dedicate ai proxy ed al controllo cache, ed intestazioni più propriamente dedicare allo streaming. Per quanto riguarda l'SDP, notiamo una serie di linee a= (righe 36-38) mediante le quali si asserisce l'adesione alle specifiche ISMA, un Initial Object Descriptor di mpeg4, e la durata in secondi dell'intero clip. Quindi, alla linea 39 troviamo la linea a= relativa all'audio, associato al payload type dinamico 96, e per il quale non è ancora stata negoziata una porta. Le linee 40-43 indicano che l'audio è associato alla traccia 5 (il file da cui si parte, contiene audio e video del clip multiplati assieme nello stesso file, ma suddivisi in differenti tracce), e che il PT 96 corrisponde ad un audio mpeg4, campionato a 22050 Hz, stereo, più altre indicazioni specifiche. Le righe 44-48 descrivono invece il media video, associato al PT dinamico 97, corrispondente ad un MP4, presente sulla traccia 8 del file originale.

Il server RTSP dovrà demultiplare i flussi audio e video presenti nel file originale, e generare per ognuno di essi un diverso flusso RTP, mantenendo per questi la possibilità di rimanere sincronizzati.

Alla riga 49 il client inizia a predisporre il server alla trasmissione, comunicando (riga 51) le porte su cui intende ricevere RTP ed RTCP per quanto rigurda l'audio, che sono riscontrate dal server alla riga 62; inoltre alla riga 59 il server assegna alla richiesta un identificativo di sessione. Questo identificativo è citato alla riga 67, assieme alla richiesta di SETUP pe il media video (riga 64), che viene a sua volta riscontrato dal server con la risposta che inizia alla riga 70.

Finalmente, alla riga 80 il client richiede il PLAY dei media associati alla sessione appena definita, riscontrato dal sever alla riga 86. Infine, la riga 93 rappresenta la richiesta del client di arrestare la riproduzione.

Soluzioni Proprietarie

Real

Real Networks è il fornitore di una architettura di streaming composta da server (Helix, versione di valutazione), client (RealPlayer), encoder (RealProducer), e codec (RealAudio, RealVideo). Può essere ritenuta la prima soluzione commerciale per la distribuzione multimediale su Internet. Mentre la componente di controllo è attuata in accordo all'RTSP, il trasporto usa (preferenzialmente) un protocollo proprietario (RDT), così come anche il codec non segue gli standard pubblici. Viene inoltre definito un formato di descrizione indicato come Real Audio Metadata (.ram), ed un linguaggio di sincronizzazione tra contenuti multimediali e presentazioni testuali, il Synchronized Multimedia Integration Language (.smil). Infine, il player è in grado di riprodurre anche altri formati e contenitori, e gran parte del codice sorgente alla base della soluzione di Real, è stato rilasciato con licenza OpenSource.

Windows Media

Vedi Wikipedia

Quicktime

Vedi Wikipedia

Flash

Il plugin Flash di Adobe risulta installato nel 99% dei browser web, ed anche se la riproduzione video risulta penalizzata rispetto ad applicazioni player dedicate, la sua estrema diffusione ed integrazione nelle pagine web è la ragione della sua adozione quasi universale. Per diverso tempo questo plugin si è limitato a riprodurre files ShockWaveFlash (con estensione .swf), un formato proprietario di grafica vettoriale, che si è poi evoluto a formato contenitore di codifiche multimediali. Successivamente, si è definito un ulteriore formato detto Flash Video (con estensione .flv), che può essere riprodotto anche da un player esterno al browser. Un file flv può essere ricevuto come singolo oggetto per una successiva riproduzione, oppure visionato durante la ricezione in forma di download progressivo HTTP, o in streaming RTMP. Quest'ultimo è il protocollo con cui il Flash Player si collega in TCP presso il server, e su questa unica connessione realizza diversi canali virtuali su cui multiplare i dati audio, video, i messaggi RPC di Actionscript, ed i messaggi di controllo come per la negoziazione dei parametri (es. di banda) e di riproduzione (es. play/stop).

Nonostante la licenza proprietaria neghi il diritto di sviluppare un Player diverso, ne esistono diverse realizzazioni indipendenti come ad esempio JW FLV Player. Sebbene nel 2009 Adobe abbia annunciato di aver reso pubbliche le specifiche di RTMP, queste mancano di importanti dettagli. Allo stesso tempo, Adobe ha lanciato lo Open Screen Project con il quale integra il proprio Flah Player in un runtime detto AIR (Adobe Integrated Runtime) eseguito al di fuori del Browser, ed esteso ai dispositivi mobili.

Comunicazione Web

HTML5

Questo avanzamento di HTML nasce ad opera di un gruppo di lavoro che ne cura la versione di sviluppo, e la sua prima versione ha visto la luce da parte del W3C nell'ottobre 2014. Le nuove caratteristiche spaziano dalla grafica vettoriale alla memorizzazione locale di dati, al drag-and-drop, alle applicazioni off-line, al supporto della indicizzazione da parte di motori di ricerca ed a quello delle formule matematiche, oltre che per i sensori per la geolocalizzazione, il movimento e l'orientamento. Ma il motivo per cui questo argomento si trova qui, è che anche il linguaggio di markup si arricchisce di nuovi elementi, come <video>  e <audio> esplicitamente orientati alla multimedialità, rendendo possibile lo streaming direttamente all'interno del browser, senza bisogno di plugin aggiuntivi come il Flash Player.

WebRTC

E' una iniziativa (sito ufficiale) tesa ad estendere le funzionalità di un browser web al fine di permettere la Comunicazione Real-Time di contenuti multimediali e multiparte in modo nativo, senza quindi ricorrere a plugin od applicazioni esterne. La normativa a riguardo viene sviluppata da W3C per quanto riguarda la definizione di tre nuove API Javascript, e da IETF per quanto riguarda i procolli coinvolti.

Lo stack relativo è rappresentato nella figura a lato, in cui viene evidenziato come il codice Javascript provveda a scambiare segnalazione con il sito web che l'utente sta visitando, o con un server di segnalazione terzo, anche ricorrendo ai WebSocket, che permettono una comunicazione pienamente bidirezionale, consentendo al browser di ricevere anche eventi asincroni (RFC 6455). Sempre il codice Javascript accede poi alle funzioni offerte da WebRTC mediante le tre nuove API

API Descrizione
MediaStream Consente di ottenere un flusso audio/video proveniente dalla telecamera e dal microfono installato sul device dell’utente (metodo getUserMedia)
RTCPeerConnection Gestisce la connessione e la comunicazione di flussi di dati tra due device in connessione peer-to-peer
RTCDataChannel Consente l’interscambio di flussi di dati arbitrari tra due device in connessione peer-to-peer

mentre invece i dati multimediali e/o di altra natura viaggiano direttamente tra i due browser: per questo motivo, anche se mediata da web, la comunicazione è da ritenersi di tipo peer to peer, ed i server web non sono per nulla coinvolti nell'uso di banda dei flussi multimediali.

Lo   schema di comunicazione può avvalersi della semplice architettura a triangolo mostrata a sinistra, in cui entrambi i browser stanno visitando il medesimo sito web, oppure quella a trapezio mostrata sotto, in cui i diversi siti web si scambiano la segnalazione necessaria a mettere i due utenti in comunicazione, avvalendosi di un protocollo esistente come SIP o Jingle.

Essendo ora il web server in grado di esprimere i messaggi di segnalazione via SIP, è relativamente immediato estendere le capacità di comunicazione a partire dal browser a tutta la comunità SIP, o Jabber, o perché no, raggiunere anche utenti di rete telefonica, disponendo dell'opportuno gateway. Le compatibilità ora illustrate sono rese possibili dalla scelta di IETF di riutilizzare i protocolli già adottati nel caso del VoIP, come l'RTC per il trasporto dei dati tra i browser, l'SDP per la descrizione dei codec disponibili, ed ICE per la gestione di firewall e NAT.

Ma torniamo alle API Javascript. Dato che il codice in esecuzione nel browser che ne esegue le chiamate ha origine dal server web che si sta visitando (e che viene visitato dagli altri partecipanti alla sessione), esso può realizzare il processo di controllo sessione in modo del tutto autonomo, avvalendosi appunto di queste chiamate, e dialogare con il server web mediante protocolli di segnalazione preesistenti o sviluppati ex novo. Il WebRTC non si occupa di questi aspetti, quanto invece di definire le API suddette, ed i protocolli di comunicazione tra pari. L'attivazione di questi ultimi passa dall'invocazione di RTCPeerConnection, mediante la quale l'applicazione Javascript esegue i passi descritti come Javascript Session Establishment Protocol (JSEP), ossia

Servizi on-line

Piattaforme Web TV

Sono quei siti che funzionano come vetrina per i contenuti a disposizione presso una medesima infrastruttura di aggregazione per i contributi offerti da una singola entità (come nel caso di un broadcaster che replica le proprie trasmissioni via etere anche via Internet) o di singoli individui. Alcune di queste piattaforme consentono anche l'attivazione di canali live, e molto probabilmente fanno uso di CDN.

Internet Radio

Sicuramente la banda necessaria a trasmettere un segnale audio è sensibilmente inferiore a quella per audio +  video, e dunque il principio delle streaming Internet è a maggior ragione applicabile al caso delle radio.


Riferimenti

Capitolo: Sperimentazione








Realizzato con Document made with Kompozer da Alessandro Falaschi -
x
Logo

Lo Strato Applicativo
di Internet

Dal TCP al VoIP, dal DNS all'Email alla crittografia, tutto ciò che accade dietro le quinte di Internet, completo di cattura del traffico.
Scopri come effettuare il download, ricevere gli aggiornamenti, e contribuire!