Inizia a utilizzare WebRTC

Sam Dutton

WebRTC è un nuovo fronte nella lunga guerra per un web aperto e senza vincoli.

Brendan Eich, inventore di JavaScript

Comunicazione in tempo reale senza plug-in

Immagina un mondo in cui lo smartphone, la TV e il computer possano comunicare su una piattaforma comune. Immagina che sia facile aggiungere videochiamate e condivisione di dati peer-to-peer alla tua app web. Questa è la visione di WebRTC.

Vuoi provare? WebRTC è disponibile su computer e dispositivi mobili in Google Chrome, Safari, Firefox e Opera. Un buon punto di partenza è la semplice app di videochat all'indirizzo appr.tc:

  1. Apri appr.tc nel browser.
  2. Fai clic su Partecipa per entrare in una chat room e consentire all'app di utilizzare la webcam.
  3. Apri l'URL visualizzato alla fine della pagina in una nuova scheda o, meglio ancora, su un altro computer.

Avvio rapido

Non hai tempo di leggere questo articolo o vuoi solo il codice?

In alternativa, vai direttamente al codelab WebRTC, una guida passo passo che spiega come creare un'app di video chat completa, incluso un semplice server di segnalazione.

Una breve storia di WebRTC

Una delle ultime grandi sfide per il web è consentire la comunicazione umana tramite voce e video: la comunicazione in tempo reale, in breve RTC. L'RTC in un'app web dovrebbe essere naturale come l'inserimento di testo in un campo di immissione di testo. Senza di essa, la tua capacità di innovare e sviluppare nuovi modi di interazione con le persone è limitata.

Storicamente, la tecnologia RTC è stata aziendale e complessa, richiedendo tecnologie audio e video costose da concedere in licenza o sviluppare internamente. L'integrazione della tecnologia RTC con contenuti, dati e servizi esistenti è stata difficile e dispendiosa in termini di tempo, in particolare sul web.

La videochiamata di Gmail è diventata popolare nel 2008 e, nel 2011, Google ha introdotto Hangouts, che utilizza Talk (come Gmail). Google ha acquistato GIPS, una società che ha sviluppato molti componenti necessari per l'RTC, come codec e tecniche di cancellazione dell'eco. Google ha reso open source le tecnologie sviluppate da GIPS e si è impegnata con gli organismi di standardizzazione competenti dell'Internet Engineering Task Force (IETF) e del World Wide Web Consortium (W3C) per garantire il consenso del settore. A maggio 2011, Ericsson ha creato la prima implementazione di WebRTC.

WebRTC ha implementato standard aperti per la comunicazione di video, audio e dati in tempo reale senza plug-in. Il bisogno era reale:

  • Molti servizi web utilizzavano RTC, ma richiedevano download, app native o plug-in. tra cui Skype, Facebook e Hangouts.
  • Il download, l'installazione e l'aggiornamento dei plug-in sono complessi, soggetti a errori e fastidiosi.
  • I plug-in sono difficili da implementare, eseguire il debug, risolvere i problemi, testare e gestire e potrebbero richiedere licenze e integrazione con tecnologie complesse e costose. Spesso è difficile convincere le persone a installare i plug-in.

I principi guida del progetto WebRTC sono che le API devono essere open source, senza costi, standardizzate, integrate nei browser web e più efficienti delle tecnologie esistenti.

Dove siamo ora?

WebRTC viene utilizzato in varie app, come Google Meet. WebRTC è stato integrato anche con WebKitGTK+ e le app native Qt.

WebRTC implementa queste tre API: - MediaStream (noto anche come getUserMedia) - RTCPeerConnection - RTCDataChannel

Le API sono definite in queste due specifiche:

Tutte e tre le API sono supportate su dispositivi mobili e computer da Chrome, Safari, Firefox, Edge e Opera.

getUserMedia: per demo e codice, consulta i sample WebRTC o prova gli esempi straordinari di Chris Wilson che utilizzano getUserMedia come input per l'audio web.

RTCPeerConnection: per una semplice demo e un'app di videochat completamente funzionale, consulta rispettivamente Esempi di connessione tra pari WebRTC e appr.tc. Questa app utilizza adapter.js, uno shim JavaScript gestito da Google con l'aiuto della community WebRTC, per astrarre le differenze del browser e le modifiche alle specifiche.

RTCDataChannel: per vedere come funziona, consulta Samples WebRTC per controllare una delle demo del canale di dati.

Il codelab WebRTC mostra come utilizzare tutte e tre le API per creare una semplice app per videochiamate e condivisione di file.

La tua prima esperienza WebRTC

Le app WebRTC devono svolgere diverse operazioni:

  • Ricevere audio, video o altri dati in streaming.
  • Ottenere informazioni sulla rete, come indirizzi IP e porte, e scambiarle con altri client WebRTC (chiamati peer) per abilitare la connessione, anche tramite NAT e firewall.
  • Coordina la comunicazione di segnalazione per segnalare errori e avviare o chiudere sessioni.
  • Scambia informazioni sui contenuti multimediali e sulle funzionalità del client, ad esempio risoluzione e codec.
  • Comunicare audio, video o dati in streaming.

Per acquisire e comunicare i dati in streaming, WebRTC implementa le seguenti API:

  • MediaStream ha accesso a stream di dati, ad esempio dalla fotocamera e dal microfono dell'utente.
  • RTCPeerConnection consente le chiamate audio o video con funzionalità di crittografia e gestione della larghezza di banda.
  • RTCDataChannel consente la comunicazione peer-to-peer di dati generici.

(Di seguito viene discussa in dettaglio la rete e gli aspetti di segnalazione di WebRTC).

API MediaStream (nota anche come API getUserMedia)

L'API MediaStream rappresenta stream di contenuti multimediali sincronizzati. Ad esempio, uno stream acquisito dall'input della fotocamera e del microfono ha tracce video e audio sincronizzate. Non confondere MediaStreamTrack con l'elemento <track>, che è qualcosa di completamente diverso.

Probabilmente il modo più semplice per comprendere l'API MediaStream è osservarla in azione:

  1. Nel browser, vai a Samples WebRTC getUserMedia.
  2. Apri la console.
  3. Controlla la variabile stream, che è a livello globale.

Ogni MediaStream ha un input, che può essere un MediaStream generato da getUserMedia(), e un output, che può essere passato a un elemento video o a un RTCPeerConnection.

Il metodo getUserMedia() prende un parametro oggetto MediaStreamConstraints e restituisce un Promise che si risolve in un oggetto MediaStream.

Ogni MediaStream ha un label, ad esempio 'Xk7EuLhsuHKbnjLWkW4yYGNJJ8ONsgwHBvLQ'. Un array di MediaStreamTrack viene restituito dai metodi getAudioTracks() e getVideoTracks().

Nell'esempio getUserMedia, stream.getAudioTracks() restituisce un array vuoto (perché non c'è audio) e, supponendo che sia collegata una webcam funzionante, stream.getVideoTracks() restituisce un array di un MediaStreamTrack che rappresenta lo stream della webcam. Ogni MediaStreamTrack ha un tipo ('video' o 'audio'), un label (ad esempio 'FaceTime HD Camera (Built-in)') e rappresenta uno o più canali audio o video. In questo caso, è presente una sola traccia video e non è presente audio, ma è facile immaginare casi d'uso in cui ce ne sono di più, ad esempio un'app di chat che riceve stream dalla fotocamera anteriore, dalla fotocamera posteriore, dal microfono e da un'app che condivide il proprio schermo.

Un MediaStream può essere allegato a un elemento video impostando l'attributo srcObject. In precedenza, questa operazione veniva eseguita impostando l'attributo src su un URL di un oggetto creato con URL.createObjectURL(), ma questa operazione è stata ritirata.

getUserMedia può essere utilizzato anche come nodo di input per l'API Web Audio:

// Cope with browser differences.
let audioContext;
if (typeof AudioContext === 'function') {
  audioContext = new AudioContext();
} else if (typeof webkitAudioContext === 'function') {
  audioContext = new webkitAudioContext(); // eslint-disable-line new-cap
} else {
  console.log('Sorry! Web Audio not supported.');
}

// Create a filter node.
var filterNode = audioContext.createBiquadFilter();
// See https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#BiquadFilterNode-section
filterNode.type = 'highpass';
// Cutoff frequency. For highpass, audio is attenuated below this frequency.
filterNode.frequency.value = 10000;

// Create a gain node to change audio volume.
var gainNode = audioContext.createGain();
// Default is 1 (no change). Less than 1 means audio is attenuated
// and vice versa.
gainNode.gain.value = 0.5;

navigator.mediaDevices.getUserMedia({audio: true}, (stream) => {
  // Create an AudioNode from the stream.
  const mediaStreamSource =
    audioContext.createMediaStreamSource(stream);
  mediaStreamSource.connect(filterNode);
  filterNode.connect(gainNode);
  // Connect the gain node to the destination. For example, play the sound.
  gainNode.connect(audioContext.destination);
});

Anche le app e le estensioni basate su Chromium possono incorporare getUserMedia. L'aggiunta di autorizzazioni audioCapture e/o videoCapture al file manifest consente di richiedere e concedere l'autorizzazione una sola volta durante l'installazione. In seguito, all'utente non viene più richiesta l'autorizzazione per l'accesso alla fotocamera o al microfono.

L'autorizzazione deve essere concessa una sola volta per getUserMedia(). La prima volta viene visualizzato un pulsante Consenti nella infobar del browser. L'accesso HTTP per getUserMedia() è stato ritirato da Chrome alla fine del 2015 perché classificato come funzionalità potente.

L'intenzione è potenzialmente quella di attivare un MediaStream per qualsiasi origine dati in streaming, non solo per una videocamera o un microfono. In questo modo, sarà possibile eseguire lo streaming da dati archiviati o da origini dati arbitrarie, come sensori o altri input.

getUserMedia() si anima davvero in combinazione con altre API e librerie JavaScript:

  • Webcam Toy è un'app per fototessera che utilizza WebGL per aggiungere effetti strani e meravigliosi alle foto che possono essere condivise o salvate localmente.
  • FaceKat è un gioco di rilevamento dei volti creato con headtrackr.js.
  • ASCII Camera utilizza l'API Canvas per generare immagini ASCII.
Immagine ASCII generata da idevelop.ro/ascii-camera
Grafica ASCII di gUM!

Vincoli

I vincoli possono essere utilizzati per impostare i valori della risoluzione video per getUserMedia(). Ciò consente anche il supporto di altri vincoli, come le proporzioni, la modalità di orientamento (fotocamera anteriore o posteriore), la frequenza fotogrammi, l'altezza e la larghezza e un metodo applyConstraints().

Per un esempio, consulta Esempi WebRTC getUserMedia: seleziona la risoluzione.

L'impostazione di un valore di vincolo non consentito restituisce DOMException o OverconstrainedError se, ad esempio, la risoluzione richiesta non è disponibile. Per vedere come funziona, consulta Samples WebRTC getUserMedia: seleziona la risoluzione per una demo.

Acquisizione di schermate e schede

Le app di Chrome consentono inoltre di condividere un video in diretta di una singola scheda del browser o dell'intero computer tramite le API chrome.tabCapture e chrome.desktopCapture. Per una demo e ulteriori informazioni, vedi Condivisione schermo con WebRTC. L'articolo è stato pubblicato qualche anno fa, ma è ancora interessante.)

È anche possibile utilizzare la cattura dello schermo come origine MediaStream in Chrome utilizzando il vincolo chromeMediaSource sperimentale. Tieni presente che la cattura dello schermo richiede HTTPS e deve essere utilizzata solo per lo sviluppo perché viene attivata tramite un flag a riga di comando, come spiegato in questo post.

Segnaletica: informazioni su controllo della sessione, rete e contenuti multimediali

WebRTC utilizza RTCPeerConnection per comunicare i dati in streaming tra i browser (noti anche come peer), ma ha bisogno anche di un meccanismo per coordinare la comunicazione e inviare messaggi di controllo, un processo noto come segnalazione. I metodi e i protocolli di segnalazione non sono specificati da WebRTC. La segnalazione non fa parte dell'API RTCPeerConnection.

Gli sviluppatori di app WebRTC possono invece scegliere il protocollo di messaggistica che preferiscono, ad esempio SIP o XMPP, e qualsiasi canale di comunicazione duplex (bidirezionale) appropriato. L'esempio appr.tc utilizza XHR e l'API Channel come meccanismo di segnalazione. Il codelab utilizza Socket.io in esecuzione su un server Node.

I segnali vengono utilizzati per scambiare tre tipi di informazioni:

  • Messaggi di controllo della sessione: per inizializzare o chiudere la comunicazione e segnalare errori.
  • Configurazione di rete: quali sono l'indirizzo IP e la porta del tuo computer per il mondo esterno?
  • Funzionalità multimediali: quali codec e risoluzioni possono essere gestiti dal browser e dal browser con cui vuole comunicare?

Lo scambio di informazioni tramite segnalazione deve essere stato completato correttamente prima che lo streaming peer-to-peer possa iniziare.

Ad esempio, immagina che Alice voglia comunicare con Bob. Ecco un esempio di codice tratto dalla specifica W3C WebRTC, che mostra il processo di segnalazione in azione. Il codice presuppone l'esistenza di un meccanismo di segnalazione creato nel metodo createSignalingChannel(). Tieni inoltre presente che su Chrome e Opera, RTCPeerConnection è attualmente preceduto da un prefisso.

// handles JSON.stringify/parse
const signaling = new SignalingChannel();
const constraints = {audio: true, video: true};
const configuration = {iceServers: [{urls: 'stun:stun.example.org'}]};
const pc = new RTCPeerConnection(configuration);

// Send any ice candidates to the other peer.
pc.onicecandidate = ({candidate}) => signaling.send({candidate});

// Let the "negotiationneeded" event trigger offer generation.
pc.onnegotiationneeded = async () => {
  try {
    await pc.setLocalDescription(await pc.createOffer());
    // Send the offer to the other peer.
    signaling.send({desc: pc.localDescription});
  } catch (err) {
    console.error(err);
  }
};

// Once remote track media arrives, show it in remote video element.
pc.ontrack = (event) => {
  // Don't set srcObject again if it is already set.
  if (remoteView.srcObject) return;
  remoteView.srcObject = event.streams[0];
};

// Call start() to initiate.
async function start() {
  try {
    // Get local stream, show it in self-view, and add it to be sent.
    const stream =
      await navigator.mediaDevices.getUserMedia(constraints);
    stream.getTracks().forEach((track) =>
      pc.addTrack(track, stream));
    selfView.srcObject = stream;
  } catch (err) {
    console.error(err);
  }
}

signaling.onmessage = async ({desc, candidate}) => {
  try {
    if (desc) {
      // If you get an offer, you need to reply with an answer.
      if (desc.type === 'offer') {
        await pc.setRemoteDescription(desc);
        const stream =
          await navigator.mediaDevices.getUserMedia(constraints);
        stream.getTracks().forEach((track) =>
          pc.addTrack(track, stream));
        await pc.setLocalDescription(await pc.createAnswer());
        signaling.send({desc: pc.localDescription});
      } else if (desc.type === 'answer') {
        await pc.setRemoteDescription(desc);
      } else {
        console.log('Unsupported SDP type.');
      }
    } else if (candidate) {
      await pc.addIceCandidate(candidate);
    }
  } catch (err) {
    console.error(err);
  }
};

Innanzitutto, Alice e Bob scambiano informazioni sulla rete. L'espressione trovare candidati si riferisce al processo di ricerca di interfacce di rete e porte utilizzando il framework ICE.

  1. Alice crea un oggetto RTCPeerConnection con un gestore onicecandidate, che viene eseguito quando le reti candidate diventano disponibili.
  2. Alice invia i dati candidati serializzati a Bob tramite il canale di segnalazione in uso, ad esempio WebSocket o un altro meccanismo.
  3. Quando Bob riceve un messaggio del candidato da Alice, chiama addIceCandidate per aggiungerlo alla descrizione del peer remoto.

I client WebRTC (noti anche come peer, o Alice e Bob in questo esempio) devono anche accertare e scambiare informazioni sui contenuti multimediali audio e video locali e remoti, ad esempio la risoluzione e le funzionalità dei codec. L'invio di indicatori per lo scambio di informazioni di configurazione dei contenuti multimediali avviene scambiando un'offerta e una risposta utilizzando il protocollo SDP (Session Description Protocol):

  1. Alice esegue il metodo RTCPeerConnection createOffer(). Al valore restituito viene passato un RTCSessionDescription, la descrizione della sessione locale di Alice.
  2. Nel callback, Alice imposta la descrizione locale utilizzando setLocalDescription() e poi invia questa descrizione della sessione a Bob tramite il suo canale di segnalazione. Tieni presente che RTCPeerConnection non inizierà a raccogliere candidati finché non viene chiamato setLocalDescription(). Questo è codificato nella bozza JSEP IETF.
  3. Roberto imposta la descrizione che Alice gli ha inviato come descrizione remota utilizzando setRemoteDescription().
  4. Bob esegue il metodo RTCPeerConnection createAnswer(), passando la descrizione remota che ha ricevuto da Alice in modo da generare una sessione locale compatibile con la sua. Al callback createAnswer() viene passato un RTCSessionDescription. Bob la imposta come descrizione locale e la invia ad Alice.
  5. Quando Alice riceve la descrizione della sessione di Bob, la imposta come descrizione remota con setRemoteDescription.
  6. Ping!

Gli oggetti RTCSessionDescription sono blob conformi al Session Description Protocol (SDP). In formato serializzato, un oggetto SDP ha il seguente aspetto:

v=0
o=- 3883943731 1 IN IP4 127.0.0.1
s=
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 103 104 0 8 106 105 13 126

// ...

a=ssrc:2223794119 label:H4fjnMzxy3dPIgQ7HxuCTLb4wLLLeRHnFxh810

L'acquisizione e lo scambio di informazioni sulla rete e sui contenuti multimediali possono essere eseguiti contemporaneamente, ma entrambe le procedure devono essere completate prima che possa iniziare lo streaming audio e video tra i peer.

L'architettura di offerta/risposta descritta in precedenza si chiama JavaScript Session Establishment Protocol o JSEP. (Nel video demo di Ericsson per la prima implementazione di WebRTC è presente un'animazione eccellente che spiega il processo di segnalazione e streaming.)

Diagramma dell&#39;architettura JSEP
Architettura JSEP

Una volta completata correttamente la procedura di segnalazione, i dati possono essere trasmessi in streaming direttamente in peer-to-peer tra chi chiama e chi riceve la chiamata oppure, in caso di errore, tramite un server di inoltro intermedio (di cui parleremo più avanti). Lo streaming è compito di RTCPeerConnection.

RTCPeerConnection

RTCPeerConnection è il componente WebRTC che gestisce la comunicazione stabile ed efficiente dei dati in streaming tra i peer.

Di seguito è riportato un diagramma dell'architettura WebRTC che mostra il ruolo di RTCPeerConnection. Come noterai, le parti verdi sono complesse.

Diagramma dell&#39;architettura WebRTC
Architettura WebRTC (da webrtc.org)

Dal punto di vista di JavaScript, la cosa principale da capire da questo diagramma è che RTCPeerConnection protegge gli sviluppatori web dalla miriade di complessità che si nascondono sotto. I codec e i protocolli utilizzati da WebRTC svolgono un'enorme quantità di lavoro per rendere possibile la comunicazione in tempo reale, anche su reti inaffidabili:

  • Nascondimento della perdita di pacchetti
  • Cancellazione dell'eco
  • Adattabilità della larghezza di banda
  • Jitter buffer dinamico
  • Controllo automatico guadagno
  • Riduzione e soppressione del rumore
  • Pulizia delle immagini

Il codice W3C precedente mostra un esempio semplificato di WebRTC dal punto di vista del signaling. Di seguito sono riportate le procedure dettagliate di due app WebRTC funzionanti. Il primo è un semplice esempio per dimostrare RTCPeerConnection, mentre il secondo è un client di video chat completamente operativo.

RTCPeerConnection senza server

Il codice seguente è tratto da Esempi di connessione peer WebRTC, che ha RTCPeerConnection e remoti locali (e video locali e remoti) in una pagina web. Non è molto utile, perché chiamante e chiamato sono nella stessa pagina, ma rende un po' più chiaro il funzionamento dell'API RTCPeerConnection perché gli oggetti RTCPeerConnection nella pagina possono scambiare dati e messaggi direttamente senza dover utilizzare meccanismi di segnalazione intermedi.

In questo esempio, pc1 rappresenta il peer locale (chiamatore) e pc2 il peer remoto (chiamato).

Chiamante

  1. Crea un nuovo RTCPeerConnection e aggiungi lo stream da getUserMedia(): ```js // Servers è un file di configurazione facoltativo. (vedi la discussione su TURN e STUN di seguito). pc1 = new RTCPeerConnection(servers); // ... localStream.getTracks().forEach((track) => { pc1.addTrack(track, localStream); });
  1. Crea un'offerta e impostala come descrizione locale per pc1 e come descrizione remota per pc2. Questo può essere fatto direttamente nel codice senza utilizzare l'indicatore perché sia il chiamante che il chiamato si trovano nella stessa pagina: js pc1.setLocalDescription(desc).then(() => { onSetLocalSuccess(pc1); }, onSetSessionDescriptionError ); trace('pc2 setRemoteDescription start'); pc2.setRemoteDescription(desc).then(() => { onSetRemoteSuccess(pc2); }, onSetSessionDescriptionError );

Chiamato

  1. Crea pc2 e, quando lo stream di pc1 viene aggiunto, mostralo in un elemento video: js pc2 = new RTCPeerConnection(servers); pc2.ontrack = gotRemoteStream; //... function gotRemoteStream(e){ vid2.srcObject = e.stream; }

RTCPeerConnection API e server

Nel mondo reale, WebRTC ha bisogno di server, anche se semplici, quindi possono verificarsi i seguenti casi:

  • Gli utenti si scoprono a vicenda e si scambiano dettagli reali, come i nomi.
  • Le app client WebRTC (peer) scambiano informazioni di rete.
  • I peer scambiano dati sui contenuti multimediali, ad esempio il formato e la risoluzione dei video.
  • Le app client WebRTC attraversano gateway NAT e firewall.

In altre parole, WebRTC ha bisogno di quattro tipi di funzionalità lato server:

  • Rilevamento e comunicazione degli utenti
  • Segnalazioni
  • Attraversamento NAT/firewall
  • Server di inoltro nel caso in cui la comunicazione peer-to-peer non vada a buon fine

Il traversal NAT, la rete peer-to-peer e i requisiti per la creazione di un'app server per il rilevamento e l'invio di indicatori agli utenti non rientrano nell'ambito di questo articolo. Basti dire che il protocollo STUN e la relativa estensione TURN vengono utilizzati dal framework ICE per consentire a RTCPeerConnection di gestire il traversal NAT e altri capricci della rete.

ICE è un framework per la connessione di peer, ad esempio due client di chat video. Inizialmente, ICE tenta di connettere i peer direttamente con la latenza più bassa possibile tramite UDP. In questo processo, i server STUN hanno un'unica attività: consentire a un peer dietro un NAT di scoprire il proprio indirizzo e la propria porta pubblici. Per ulteriori informazioni su STUN e TURN, consulta Creare i servizi di backend necessari per un'app WebRTC.

Trovare candidati per la connessione
Trovare candidati per le connessioni

Se UDP non va a buon fine, ICE prova con TCP. Se la connessione diretta non va a buon fine, in particolare a causa del NAT traversal e dei firewall aziendali, ICE utilizza un server TURN intermedio (di inoltro). In altre parole, ICE utilizza innanzitutto STUN con UDP per connettere direttamente i peer e, se non riesce, passa a un server di inoltro TURN. L'espressione ricerca di candidati si riferisce al processo di ricerca di interfacce e porte di rete.

Percorsi dei dati WebRTC
Percorsi dei dati WebRTC

L'ingegnere WebRTC Justin Uberti fornisce ulteriori informazioni su ICE, STUN e TURN nella presentazione di WebRTC al Google I/O 2013. Le slide della presentazione forniscono esempi di implementazioni di server TURN e STUN.

Un semplice client di videochat

Un buon posto per provare WebRTC, completo di segnalazione e attraversamento di NAT/firewall utilizzando un server STUN, è la demo di video chat all'indirizzo appr.tc. Questa app utilizza adapter.js, uno shim per isolare le app dalle modifiche alle specifiche e dalle differenze di prefisso.

Il codice è volutamente dettagliato nei log. Controlla la console per comprendere l'ordine degli eventi. Di seguito è riportata una procedura dettagliata per il codice.

Topologie di rete

WebRTC, così come attualmente implementato, supporta solo la comunicazione uno a uno, ma potrebbe essere utilizzato in scenari di rete più complessi, ad esempio con più peer che comunicano tra loro direttamente o tramite un'unità di controllo multipunto (MCU), un server in grado di gestire un numero elevato di partecipanti ed eseguire l'inoltro selettivo degli stream, nonché la miscelazione o la registrazione di audio e video.

Diagramma della topologia dell&#39;unità di controllo multipunto
Esempio di topologia dell'unità di controllo multipunto

Molte app WebRTC esistenti dimostrano solo la comunicazione tra browser web, ma i server gateway possono consentire a un'app WebRTC in esecuzione su un browser di interagire con dispositivi come telefoni (noti anche come PSTN) e con sistemi VOIP. A maggio 2012, Doubango Telecom ha reso open source il client SIP sipml5 creato con WebRTC e WebSocket, che (tra gli altri potenziali utilizzi) consente le videochiamate tra browser e app in esecuzione su iOS e Android. In occasione della conferenza Google I/O, Tethr e Tropo hanno dimostrato un framework per le comunicazioni in caso di calamità in una valigetta utilizzando una cella OpenBTS per abilitare le comunicazioni tra cellulari e computer tramite WebRTC. Comunicazione telefonica senza operatore.

Demo di Tethr/Tropo alla conferenza Google I/O 2012
Tethr/Tropo: comunicazioni in caso di calamità in una valigetta

API RTCDataChannel<

Oltre che per audio e video, WebRTC supporta la comunicazione in tempo reale per altri tipi di dati.

L'API RTCDataChannel consente lo scambio peer-to-peer di dati arbitrari con bassa latenza e alto throughput. Per le demo a pagina singola e per scoprire come creare una semplice app di trasferimento file, consulta rispettivamente i Sample WebRTC e il codelab WebRTC.

Esistono molti potenziali casi d'uso per l'API, tra cui:

  • Giochi
  • App desktop remoto
  • Chat di testo in tempo reale
  • Trasferimento file
  • Reti decentralizzate

L'API offre diverse funzionalità per sfruttare al meglio RTCPeerConnection e consentire una comunicazione peer-to-peer efficace e flessibile:

  • Sfruttamento della configurazione della sessione RTCPeerConnection
  • Più canali simultanei con priorità
  • Semantikhe di importazione affidabili e non affidabili
  • Sicurezza integrata (DTLS) e controllo della congestione
  • Possibilità di utilizzo con o senza audio o video

La sintassi è volutamente simile a WebSocket con un metodo send() e un evento message:

const localConnection = new RTCPeerConnection(servers);
const remoteConnection = new RTCPeerConnection(servers);
const sendChannel =
  localConnection.createDataChannel('sendDataChannel');

// ...

remoteConnection.ondatachannel = (event) => {
  receiveChannel = event.channel;
  receiveChannel.onmessage = onReceiveMessage;
  receiveChannel.onopen = onReceiveChannelStateChange;
  receiveChannel.onclose = onReceiveChannelStateChange;
};

function onReceiveMessage(event) {
  document.querySelector("textarea#send").value = event.data;
}

document.querySelector("button#send").onclick = () => {
  var data = document.querySelector("textarea#send").value;
  sendChannel.send(data);
};

La comunicazione avviene direttamente tra i browser, quindi RTCDataChannel può essere molto più veloce di WebSocket anche se è necessario un server di inoltro (TURN) quando il hole-punching per gestire i firewall e i NAT non va a buon fine.

RTCDataChannel è disponibile su Chrome, Safari, Firefox, Opera e Samsung Internet. Il gioco Cube Slam utilizza l'API per comunicare lo stato del gioco. Gioca con un amico o con l'orso. La piattaforma innovativa Sharefest ha consentito la condivisione di file tramite RTCDataChannel e peerCDN, offrendo un'idea di come WebRTC possa abilitare la distribuzione di contenuti peer-to-peer.

Per ulteriori informazioni su RTCDataChannel, consulta la bozza della specifica del protocollo dell'IETF.

Sicurezza

Esistono diversi modi in cui un plug-in o un'app di comunicazione in tempo reale può compromettere la sicurezza. Ad esempio:

  • I contenuti multimediali o i dati non criptati potrebbero essere intercettati tra browser o tra un browser e un server.
  • Un'app potrebbe registrare e distribuire video o audio a insaputa dell'utente.
  • I malware o i virus potrebbero essere installati insieme a un plug-in o un'app apparentemente innocui.

WebRTC offre diverse funzionalità per evitare questi problemi:

  • Le implementazioni di WebRTC utilizzano protocolli sicuri, come DTLS e SRTP.
  • La crittografia è obbligatoria per tutti i componenti WebRTC, inclusi i meccanismi di segnalazione.
  • WebRTC non è un plug-in. I relativi componenti vengono eseguiti nella sandbox del browser e non in un processo separato. I componenti non richiedono un'installazione separata e vengono aggiornati ogni volta che viene aggiornato il browser.
  • L'accesso alla fotocamera e al microfono deve essere concesso esplicitamente e, quando la fotocamera o il microfono sono in esecuzione, questo viene mostrato chiaramente dall'interfaccia utente.

Una discussione completa sulla sicurezza per i contenuti multimediali in streaming non rientra nell'ambito di questo articolo. Per ulteriori informazioni, consulta l'architettura di sicurezza WebRTC proposta dall'IETF.

Conclusioni

Le API e gli standard di WebRTC possono democratizzare e decentralizzare gli strumenti per la creazione e la comunicazione di contenuti, tra cui telefonia, giochi, produzione video, creazione di musica e raccolta di notizie.

Non esiste una tecnologia più disruptive di questa.

Come ha affermato il blogger Phil Edholm, "potenzialmente, WebRTC e HTML5 potrebbero consentire la stessa trasformazione per le comunicazioni in tempo reale che il browser originale ha fatto per le informazioni".

Strumenti per sviluppatori

Scopri di più

Standard e protocolli

Riepilogo del supporto di WebRTC

API MediaStream e getUserMedia

  • Chrome per computer 18.0.1008 e versioni successive; Chrome per Android 29 e versioni successive
  • Opera 18 e versioni successive; Opera per Android 20 e versioni successive
  • Opera 12, Opera Mobile 12 (basato sul motore Presto)
  • Firefox 17 e versioni successive
  • Microsoft Edge 16 e versioni successive
  • Safari 11.2 e versioni successive su iOS e 11.1 e versioni successive su macOS
  • UC 11.8 e versioni successive su Android
  • Samsung Internet 4 e versioni successive

RTCPeerConnection API

  • Chrome per computer 20 e versioni successive; Chrome per Android 29 e versioni successive (senza flag)
  • Opera 18 e versioni successive (attiva per impostazione predefinita); Opera per Android 20 e versioni successive (attiva per impostazione predefinita)
  • Firefox 22 e versioni successive (attivata per impostazione predefinita)
  • Microsoft Edge 16 e versioni successive
  • Safari 11.2 e versioni successive su iOS e 11.1 e versioni successive su macOS
  • Samsung Internet 4 e versioni successive

RTCDataChannel API

  • Versione sperimentale in Chrome 25, ma più stabile (e con interoperabilità con Firefox) in Chrome 26 e versioni successive; Chrome per Android 29 e versioni successive
  • Versione stabile (e con interoperabilità con Firefox) in Opera 18 e versioni successive; Opera per Android 20 e versioni successive
  • Firefox 22 e versioni successive (attivata per impostazione predefinita)

Per informazioni più dettagliate sul supporto multipiattaforma per le API, come getUserMedia e RTCPeerConnection, visita caniuse.com e Stato della piattaforma Chrome.

Le API native per RTCPeerConnection sono disponibili anche nella documentazione su webrtc.org.