Inizia a utilizzare WebRTC

Sam Dutton

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

Brendan Eich, inventore di JavaScript

Comunicazione in tempo reale senza plug-in

Immagina un mondo in cui telefono, TV e computer potrebbero comunicare su una piattaforma comune. Immagina che sia stato facile aggiungere chat video e condivisione di dati peer-to-peer alla tua app web. Questa è la visione di WebRTC.

Vuoi provare? WebRTC è disponibile su desktop e dispositivi mobili in Google Chrome, Safari, Firefox e Opera. Un buon punto di partenza è la semplice app per video chat 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.

Guida rapida

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

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

Una brevissima storia di WebRTC

Una delle ultime grandi sfide per il web è consentire la comunicazione umana attraverso voce e video: la comunicazione in tempo reale o RTC in breve. Il protocollo RTC dovrebbe essere naturale in un'app web, come nel caso dell'inserimento di un testo. Senza questo strumento, hai limitazioni nella tua capacità di innovare e sviluppare nuovi modi di interagire con le persone.

In passato, RTC è una piattaforma aziendale complessa, che richiede che le tecnologie audio e video costose siano concesse in licenza o sviluppate internamente. Integrare la tecnologia RTC con i contenuti, i dati e i servizi esistenti è stato difficile e dispendioso in termini di tempo, soprattutto 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 RTC, come codec e tecniche di cancellazione dell'eco. Google ha reso open source le tecnologie sviluppate da GIPS e ha collaborato con organismi di standard pertinenti dell'Internet Engineering Task Force (IETF) e del World Wide Web Consortium (W3C) per garantire il consenso del settore. Nel maggio 2011, Ericsson ha creato la prima implementazione di WebRTC.

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

  • Molti servizi web utilizzavano RTC, ma avevano bisogno di download, app native o plug-in. tra cui Skype, Facebook e Hangouts.
  • Scaricare, installare e aggiornare i plug-in è un'operazione complessa, soggetta a errori e fastidiosa.
  • I plug-in sono difficili da implementare, eseguire il debug, risolvere i problemi, testare e gestire e possono richiedere licenze e integrazione con tecnologie complesse e costose. Spesso è difficile persuadere gli utenti a installare i plug-in.

I principi guida del progetto WebRTC sono che le sue 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 anche integrato con le app native WebKitGTK+ e Qt.

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

Le API sono definite in queste due specifiche:

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

getUserMedia: per demo e codice, vedi Esempi di WebRTC o prova gli fantastici esempi di Chris Wilson che utilizzano getUserMedia come input per l'audio del web.

RTCPeerConnection: per una demo semplice e un'app di video chat completamente funzionale, vedi Esempi di connessione peer WebRTC e appr.tc, rispettivamente. Questa app utilizza adapter.js, uno shim JavaScript gestito da Google con l'aiuto della community WebRTC, per eliminare le differenze nel browser e le modifiche alle specifiche.

RTCDataChannel: per vedere come funziona, consulta gli esempi di WebRTC per provare una delle demo sui canali dati.

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

Il tuo primo WebRTC

Le app WebRTC devono svolgere diverse operazioni:

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

Per acquisire e comunicare dati in modalità flusso, WebRTC implementa le seguenti API:

  • MediaStream può accedere agli stream di dati, ad esempio dalla videocamera e dal microfono dell'utente.
  • RTCPeerConnection consente di effettuare chiamate audio o videochiamate con servizi per la crittografia e la gestione della larghezza di banda.
  • RTCDataChannel consente la comunicazione peer-to-peer di dati generici.

In seguito, parleremo in modo dettagliato della rete e degli aspetti relativi alla segnalazione di WebRTC.

API MediaStream (nota anche come API getUserMedia)

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

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

  1. Nel browser, vai a Esempi WebRTC getUserMedia.
  2. Apri la console.
  3. Esamina la variabile stream, in ambito globale.

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

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

Ogni MediaStream ha un label, ad esempio 'Xk7EuLhsuHKbnjLWkW4yYGNJJ8ONsgwHBvLQ'. I metodi getAudioTracks() e getVideoTracks() restituiscono un array di MediaStreamTrack.

Per l'esempio getUserMedia, stream.getAudioTracks() restituisce un array vuoto (perché non è presente audio) e, supponendo che sia connessa una webcam funzionante, stream.getVideoTracks() restituisce un array di un MediaStreamTrack che rappresenta lo stream dalla webcam. Ogni MediaStreamTrack ha un tipo ('video' o 'audio'), label (ad esempio 'FaceTime HD Camera (Built-in)') e rappresenta uno o più canali di audio o video. In questo caso, c'è solo una traccia video e nessun 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 lo schermo.

È possibile collegare un elemento MediaStream a un elemento video impostando l'attributo srcObject. In precedenza, questa operazione era possibile impostando l'attributo src su un URL dell'oggetto creato con URL.createObjectURL(), ma questo attributo è stato ritirato.

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);
});

Le app e le estensioni basate su Chromium possono anche incorporare getUserMedia. L'aggiunta delle autorizzazioni audioCapture e/o videoCapture al manifest consente di richiedere e concedere l'autorizzazione una sola volta al momento dell'installazione. Successivamente, all'utente non viene richiesta l'autorizzazione per accedere alla fotocamera o al microfono.

L'autorizzazione deve essere concessa una sola volta per getUserMedia(). La prima volta, viene visualizzato un pulsante Consenti nella barra delle informazioni del browser. L'accesso HTTP per getUserMedia() è stato ritirato da Chrome alla fine del 2015 in quanto è stato classificato come funzione potente.

Lo scopo potrebbe essere quello di abilitare MediaStream per qualsiasi origine dati di streaming, non solo per una videocamera o un microfono. Ciò consentirebbe di trasmettere flussi di dati archiviati o origini dati arbitrarie, come sensori o altri input.

getUserMedia() prende vita in combinazione con altre API e librerie JavaScript:

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

Vincoli

Puoi utilizzare i vincoli per impostare valori per la risoluzione video di getUserMedia(). Ciò consente inoltre di supportare altri vincoli, ad esempio proporzioni, modalità rivolta (fotocamera anteriore o posteriore), frequenza fotogrammi, altezza e larghezza e un metodo applyConstraints().

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

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

Acquisizione schermo e schede

Le app di Chrome consentono inoltre di condividere un video in diretta di una singola scheda del browser o dell'intero desktop tramite le API chrome.tabCapture e chrome.desktopCapture. Per una demo e ulteriori informazioni, consulta Condivisione dello schermo con WebRTC. L'articolo risale a pochi anni fa, ma è ancora interessante.)

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

Segnalazione: controllo sessione, rete e informazioni sui contenuti multimediali

WebRTC utilizza RTCPeerConnection per comunicare i flussi di dati tra i browser (noti anche come peer), ma necessita 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 vengono specificati da WebRTC. La segnalazione non fa parte dell'API RTCPeerConnection.

Gli sviluppatori di app WebRTC possono però scegliere qualsiasi protocollo di messaggistica, ad esempio SIP o XMPP, e un 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.

La segnalazione viene utilizzata per scambiare tre tipi di informazioni:

  • Messaggi di controllo della sessione: per inizializzare o chiudere la comunicazione e segnalare errori.
  • Configurazione di rete: verso il mondo esterno, quali sono l'indirizzo IP e la porta del tuo computer?
  • Funzionalità multimediali: quali codec e risoluzioni possono essere gestiti dal tuo 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 Roberto. Ecco un esempio di codice dalla specifica WebRTC di W3C, 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, il prefisso 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 si scambiano informazioni di rete. L'espressione candidati alla ricerca si riferisce al processo di individuazione delle interfacce e delle porte di rete utilizzando il framework ICE.

  1. Alice crea un oggetto RTCPeerConnection con un gestore onicecandidate, che viene eseguito quando le candidature di rete diventano disponibili.
  2. Alice invia i dati serializzati dei candidati a Roberto tramite qualsiasi canale di segnalazione che usa, ad esempio WebSocket o qualche altro meccanismo.
  3. Quando Mario riceve un messaggio da Alice per il candidato, chiama addIceCandidate per aggiungere il candidato alla descrizione delle app peer da remoto.

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

  1. Alice esegue il metodo createOffer() RTCPeerConnection. Il risultato viene inviato come risultato della descrizione della sessione locale di Alice (RTCSessionDescription).
  2. Nel callback, Alice imposta la descrizione locale utilizzando setLocalDescription(), quindi invia questa descrizione della sessione a Roberto tramite il canale di segnalazione. Tieni presente che RTCPeerConnection non inizierà a raccogliere candidati finché non verrà chiamata la parola setLocalDescription(). Questo codice è codificato nella bozza JSEP IETF.
  3. Roberto imposta la descrizione inviata da Alice come descrizione remota utilizzando setRemoteDescription().
  4. Roberto esegue il metodo createAnswer() RTCPeerConnection, trasmettendo la descrizione remota che ha ricevuto da Alice in modo da poter generare una sessione locale compatibile con la sua. Il callback createAnswer() ha ricevuto un RTCSessionDescription. Roberto la imposta come descrizione locale e la invia ad Alice.
  5. Quando Alice riceve la descrizione della sessione di Roberto, la imposta come descrizione remota con setRemoteDescription.
  6. Ping!

Gli oggetti RTCSessionDescription sono BLOB conformi al Session Description Protocol, SDP. Un oggetto SDP serializzato 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 di rete e sui contenuti multimediali può essere effettuato contemporaneamente, ma entrambi i processi devono essere completati prima che possa iniziare lo streaming audio e video tra peer.

L'architettura di offerta/risposta descritta in precedenza è denominata JavaScript Session Preparement Protocol o JSEP. C'è un'animazione eccellente che spiega il processo di segnalazione e streaming nel video dimostrativo di Eric per la sua prima implementazione WebRTC.

Diagramma dell&#39;architettura JSEP
Architettura JSEP

Una volta completato correttamente il processo di segnalazione, i dati possono essere trasmessi direttamente in modalità peer-to-peer, tra il chiamante e il chiamante o, in caso di errore, attraverso un server di inoltro intermedio (ulteriori informazioni in merito più avanti). Il flusso di dati è compito di RTCPeerConnection.

RTCPeerConnection

RTCPeerConnection è il componente WebRTC che gestisce la comunicazione stabile ed efficiente dei flussi di dati tra peer.

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

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

Dal punto di vista di JavaScript, l'aspetto principale da capire in questo diagramma è che RTCPeerConnection protegge gli sviluppatori web dalla miriade di complessità sottostanti. I codec e i protocolli utilizzati da WebRTC eseguono un enorme lavoro per rendere possibile la comunicazione in tempo reale, anche su reti non affidabili:

  • Occultamento perdita pacchetti
  • Cancellazione dell'eco
  • Adattabilità alla larghezza di banda
  • Tuffo jitter 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 degli indicatori. Di seguito sono riportate le procedure dettagliate di due app WebRTC funzionanti. Il primo è un semplice esempio per dimostrare RTCPeerConnection e il secondo è un client di chat video completamente operativo.

RTCPeerConnection senza server

Il seguente codice è estratto dalla connessione peer di esempi WebRTC, che ha RTCPeerConnection locali e remote (e video locali e remoti) su un'unica pagina web. Non è di alcuna utilità (il chiamante e il chiamante sono sulla 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 (chiamante) e pc2 rappresenta il peer remoto (chiamato).

Chiamante

  1. Crea un nuovo RTCPeerConnection e aggiungi il flusso da getUserMedia(): ```js // Servers è un file di configurazione facoltativo. (Consulta la discussione su TURN e STUN in 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. Questa operazione può essere eseguita direttamente nel codice senza utilizzare la segnalazione, poiché sia il chiamante sia il chiamante si trovano sulla stessa pagina: js pc1.setLocalDescription(desc).then(() => { onSetLocalSuccess(pc1); }, onSetSessionDescriptionError ); trace('pc2 setRemoteDescription start'); pc2.setRemoteDescription(desc).then(() => { onSetRemoteSuccess(pc2); }, onSetSessionDescriptionError );

Destinatario della chiamata

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

API RTCPeerConnection più server

Nel mondo reale, WebRTC ha bisogno di server, per quanto semplici, quindi si può verificare quanto segue:

  • Gli utenti si scoprono e si scambiano dettagli reali, ad esempio i nomi.
  • Le app client WebRTC (peer) scambiano informazioni di rete.
  • I concorrenti 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 richiede quattro tipi di funzionalità lato server:

  • Comunicazione e scoperta da parte degli utenti
  • Segnalazioni
  • Attraversamento NAT/firewall
  • Relay server in caso di errore di comunicazione peer-to-peer

NAT Traversal, networking peer-to-peer e i requisiti per creare un'app server per il rilevamento e la segnalazione degli utenti non rientrano nell'ambito di questo articolo. Basti pensare che il protocollo STUN e la sua estensione, TURN, vengono utilizzati dal framework ICE per consentire a RTCPeerConnection di gestire NAT Traversal e altri aspetti peculiari della rete.

ICE è un framework per la connessione di colleghi, 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 una singola attività: abilitare un peer dietro un NAT per scoprirne l'indirizzo pubblico e la porta. Per ulteriori informazioni su STUN e TURN, consulta Creazione dei servizi di backend necessari per un'app WebRTC.

Trovare candidati per la connessione
Ricerca di candidati per la connessione

Se UDP non riesce, ICE prova TCP. Se la connessione diretta non va a buon fine, in particolare a causa dell'attacco NAT Traversal aziendale e dei firewall, ICE utilizza un server TURN intermedio. In altre parole, ICE utilizza prima STUN con UDP per connettere direttamente i peer e, in caso di errore, torna a un server di inoltro TURN. L'espressione candidati alla ricerca fa riferimento al processo di individuazione di interfacce e porte di rete.

Percorsi dati WebRTC
Percorsi dati WebRTC

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

Un semplice client per chat video

Un buon punto di prova con WebRTC, completo di segnalazione e NAT/Firewall Traversal mediante un server STUN, è la demo della chat video all'indirizzo appr.tc. Questa app utilizza adapter.js, uno shim per isolare le app dalle modifiche alle specifiche e dalle differenze nei prefissi.

Il codice è volutamente dettagliato nella sua registrazione. Controlla la console per comprendere l'ordine degli eventi. Di seguito è riportata una procedura dettagliata dettagliata del codice.

Topologie di rete

WebRTC, così come attualmente implementato, supporta solo la comunicazione one-to-one, ma potrebbe essere utilizzato in scenari di rete più complessi, ad esempio con più peer che comunicano tra loro direttamente o attraverso un'unità di controllo multipunto (MCU), un server in grado di gestire un numero elevato di partecipanti e di inoltrare selettivamente i flussi e il mix 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 la comunicazione solo tra browser web, ma i server gateway possono consentire a un'app WebRTC in esecuzione su un browser di interagire con dispositivi quali i telefoni (noti anche come PSTN) e con sistemi VOIP. Nel maggio 2012, Doubango Telecom ha reso open source il client SIP sipml5 realizzato con WebRTC e WebSocket, che (tra gli altri possibili utilizzi) consente di effettuare videochiamate tra browser e app in esecuzione su iOS e Android. Alla conferenza Google I/O, Tethr e Tropo hanno dimostrato un framework per le comunicazioni in caso di emergenza in una valigetta utilizzando una cella OpenBTS per consentire le comunicazioni tra feature phone e computer tramite WebRTC. Comunicazioni telefoniche senza operatore!

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

API RTCDataChannel<

così come 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 velocità effettiva elevata. Per demo di una sola pagina e per imparare a creare una semplice app per il trasferimento di file, vedi rispettivamente gli esempi di WebRTC e il codelab WebRTC.

Esistono molti potenziali casi d'uso dell'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 flessibile e potente:

  • Utilizzo della configurazione della sessione RTCPeerConnection
  • Più canali simultanei con assegnazione delle priorità
  • Semantica di distribuzione affidabile e inaffidabile
  • Sicurezza integrata (DTLS) e controllo della congestione
  • Possibilità di utilizzare 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 forwarding (TURN) in caso di errori di hole-punching per far fronte a firewall e NAT.

RTCDataChannel è disponibile in 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 l'orso! L'innovativa piattaforma Sharefest consentiva la condivisione di file tramite RTCDataChannel e peerCDN ha offerto un'idea di come WebRTC avrebbe potuto consentire la distribuzione di contenuti peer-to-peer.

Per ulteriori informazioni su RTCDataChannel, consulta le specifiche di protocollo di IETF.

Sicurezza

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

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

WebRTC presenta diverse funzionalità che consentono di evitare questi problemi:

  • Le implementazioni 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 suoi 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 videocamera e al microfono deve essere concesso esplicitamente e, quando la fotocamera o il microfono sono in esecuzione, l'interfaccia utente lo mostrerà chiaramente.

Questo articolo non comprende una discussione completa sulla sicurezza per lo streaming di contenuti multimediali. Per ulteriori informazioni, consulta la sezione Proposed WebRTC Security Architecture (Architettura di sicurezza WebRTC proposta) proposta da 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 musicale e raccolta di notizie.

La tecnologia non diventa molto più dirompente di così.

Come ha inserito il blogger Phil Edholm: "Potenzialmente, WebRTC e HTML5 potrebbero consentire per la comunicazione in tempo reale la stessa trasformazione 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 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 (attivate 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 l'interoperabilità di Firefox) in Chrome 26 e versioni successive; Chrome per Android 29 e versioni successive
  • Versione stabile (e con interoperabilità di Firefox) in Opera 18 e versioni successive; Opera per Android 20 e versioni successive
  • Firefox 22 e versioni successive (attivate per impostazione predefinita)

Per informazioni più dettagliate sul supporto multipiattaforma per le API, come getUserMedia e RTCPeerConnection, consulta caniuse.com e Chrome Platform Status.

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