Lo strato applicativo di Internet
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.
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.
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.
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.
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.
Vedi Wikipedia
Vedi Wikipedia
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.
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.
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.
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
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.
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.
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!