Lo scopo di questo articolo è familiarizzare con la sua struttura e il principio di funzionamento utilizzando un esempio demo di video chat peer-to-peer (video chat p2p). A tale scopo, utilizzeremo la demo di chat video multiutente webrtc.io-demo. Può essere scaricato dal link: https://github.com/webRTC/webrtc.io-demo/tree/master/site.

Va notato che GitHub è un sito o un servizio web per lo sviluppo collaborativo di progetti web. Su di esso, gli sviluppatori possono pubblicare i codici dei loro sviluppi, discuterli e comunicare tra loro. Inoltre, alcune grandi aziende IT ospitano i loro repository ufficiali su questo sito. Il servizio è gratuito per i progetti open source. GitHub è un repository di librerie open source.

Quindi, posizioneremo l'esempio demo della video chat peer-to-peer scaricata da GitHub sull'unità C di un personal computer nella directory creata per la nostra applicazione "webrtc_demo".

Riso. 1

Come risulta dalla struttura (Fig. 1), la video chat peer-to-peer è costituita da script client script.js e script server.js implementati nel linguaggio di programmazione JavaScript. Lo script (libreria) webrtc.io.js (CLIENT) - fornisce l'organizzazione delle comunicazioni in tempo reale tra i browser su uno schema peer-to-peer: "client-client", e webrtc.io.js (CLIENT) e webrtc .io.js (SERVER), utilizzando il protocollo WebSocket, forniscono una comunicazione full-duplex tra browser e web server secondo l'architettura "client-server".

Lo script webrtc.io.js (SERVER) è incluso nella libreria webrtc.io e si trova nella directory node_modules \ webrtc.io \ lib. L'interfaccia di video chat index.html è implementata in HTML5 e CSS3. Il contenuto dei file dell'applicazione webrtc_demo può essere visualizzato con uno degli editor html, ad esempio "Notepad ++".

Verificheremo come funziona la chat video nel file system del PC. Per eseguire il server (server.js) su un PC, è necessario installare il runtime node.js. Node.js consente l'esecuzione del codice JavaScript al di fuori del browser. Puoi scaricare node.js dal link: http://nodejs.org/ (versione v0.10.13 il 15/07/13). Nella pagina principale del sito node.org, fai clic sul pulsante di download e vai su http://nodejs.org/download/. Per gli utenti Windows, scaricare prima win.installer (.msi), quindi eseguire win.installer (.msi) sul PC e installare nodejs e "npm package manager" nella directory Program Files.

Riso. 2

Pertanto, node.js è costituito da un ambiente di sviluppo e dall'esecuzione di codice JavaScript, nonché da un insieme di moduli interni che possono essere installati utilizzando il gestore di pacchetti npm o il gestore.

Per installare i moduli, è necessario eseguire il comando nella riga di comando dalla directory dell'applicazione (ad esempio, "webrtc_demo"): npm install nome_modulo... Durante l'installazione dei moduli, il gestore npm crea una cartella node_modules nella directory da cui è stata eseguita l'installazione. Nel processo, nodejs connette automaticamente i moduli dalla directory node_modules.

Quindi, dopo aver installato node.js, apri una riga di comando e aggiorna il modulo express nella cartella node_modules della directory webrtc_demo utilizzando il gestore di pacchetti npm:

C: \ webrtc_demo> npm install express

Il modulo express è un framework web per node.js o un framework web per lo sviluppo di applicazioni. Per avere accesso globale a express, puoi installarlo in questo modo: npm install -g express.

Quindi aggiorniamo il modulo webrtc.io:

C: \ webrtc_demo> npm installa webrtc.io

Quindi, sulla riga di comando, avvia il server: server.js:

C: \ webrtc_demo> nodo server.js

Riso. 3

Tutto, il server funziona correttamente (Figura 3). Ora, utilizzando un browser Web, è possibile accedere al server tramite l'indirizzo IP e scaricare la pagina Web index.html, da cui il browser Web estrarrà il codice dello script del client - script.js e il codice dello script webrtc.io.js, e eseguirli. Affinché la video chat peer-to-peer funzioni (per stabilire una connessione tra due browser), è necessario da due browser che supportano webrtc indirizzare il server di segnalazione in esecuzione su node.js tramite l'indirizzo IP.

Di conseguenza, l'interfaccia della parte client dell'applicazione di comunicazione (video chat) si aprirà con una richiesta di autorizzazione per accedere alla telecamera e al microfono (Fig. 4).

Riso. 4

Dopo aver fatto clic sul pulsante "Consenti", la fotocamera e il microfono sono collegati per la comunicazione multimediale. Inoltre, i dati testuali possono essere comunicati tramite l'interfaccia di video chat (Fig. 5).

Riso. 5

Si dovrebbe notare che. Il server sta segnalando ed è principalmente destinato a stabilire una connessione tra i browser degli utenti. Node.js viene utilizzato per eseguire lo script server.js che fornisce la segnalazione WebRTC.

I netizen europei sono divisi in due parti: secondo un sondaggio dell'Istituto per l'analisi dell'opinione pubblica di Allenbach (Germania), Skype, chat e sistemi di messaggistica istantanea sono diventati parte integrante della vita quotidiana di 16,5 milioni di adulti e bambini, 9 milioni utilizzano questi servizi caso per caso e 28 milioni non li toccano.

Questo potrebbe cambiare man mano che Firefox ora si integra tecnologia di comunicazione in tempo reale (WebRTC), così come il cliente stesso. Avviare una chat audio e video ora non è più difficile che aprire un sito web. Al contrario, servizi come Facebook e Skype si affidano a soluzioni client indipendenti e creazione di account.

WebRTC non è solo facile da usare. Questo metodo consente anche di impostare connessione diretta tra due browser... Pertanto, i dati audio e video non passano attraverso il server, dove può verificarsi un sovraccarico o il cui amministratore non è particolarmente sensibile alla privacy o alla protezione dei dati. Grazie alla connessione diretta, WebRTC non necessita di registrazione né di un account con alcun servizio.

Per iniziare una conversazione, devi solo seguire il link. La comunicazione rimane privata perché il flusso di dati è crittografato. Google ha iniziato a impegnarsi attivamente nella comunicazione in tempo reale attraverso un browser nel 2011, quando ha pubblicato il codice sorgente della sua implementazione di WebRTC.

Poco dopo, Chrome e Firefox hanno ottenuto i propri motori WebRTC. Attualmente, le loro varianti mobili sono dotate sia di questa tecnologia che del motore WebView 3.6 installato con Android 5.0, utilizzato dalle applicazioni.

Per la comunicazione in tempo reale, nel visualizzatore web devono essere implementate le interfacce JavaScript appropriate. Con GetUserMedia, il software attiva l'acquisizione da sorgenti audio e video, ovvero da webcam e microfono. RTCPeerConnection è responsabile dell'instaurazione di una connessione, nonché della comunicazione stessa.

Parallelamente all'integrazione del browser, un gruppo di lavoro del World Wide Web Consortium (W3C) ha accelerato il processo di standardizzazione di WebRTC. Dovrebbe essere completato nel 2015.

WebRTC si accontenta di poco

Per utilizzare il servizio WebRTC non sono necessarie molte risorse, poiché il server connette solo gli interlocutori. Anche stabilire una connessione non è particolarmente difficile. Innanzitutto, il browser segnala al server WebRTC che prevede di avviare una chiamata. Riceve un collegamento HTTPS dal server: la comunicazione è crittografata. L'utente invia questo link al suo interlocutore. Il browser chiede quindi all'utente il permesso di accedere alla webcam e al microfono.

Per stabilire una connessione diretta in streaming con l'interlocutore, il browser riceve il suo indirizzo IP e i dati di configurazione dal servizio WebRTC. Il visualizzatore web dell'interlocutore fa lo stesso.

Per mantenere la connessione in streaming funzionante e di buona qualità, nel browser funzionano tre motori. Due di loro ottimizzano e comprimono i dati audio e video, il terzo è responsabile del loro trasporto. Invia i dati tramite SRTP(Secure Real-time Transport Protocol) che consente lo streaming crittografato in tempo reale.

Se una connessione diretta fallisce, WebRTC cerca un altro percorso. Ad esempio, ciò accade quando le impostazioni di rete impediscono al server STUN di riportare l'indirizzo IP. Lo standard WebRTC prevede che in questo caso la conversazione avrà luogo, ma con l'inclusione intermedia del server TURN (Traversal Using Relays around NAT). Quindi, sul sito web netscan.co, puoi verificare se WebRTC è implementato sul tuo computer e con il tuo accesso al Web.

Come avviene la connessione

Innanzitutto, è necessario registrare la conversazione (1). Il servizio WebRTC fornisce un collegamento che deve essere inviato all'interlocutore. Il browser, utilizzando il server STUN, trova il proprio indirizzo IP (2), lo invia al servizio e riceve l'IP del partner per stabilire una connessione diretta (3). Se STUN fallisce, la conversazione viene reindirizzata utilizzando il server TURN (4).

La comunicazione tramite la tecnologia WebRTC in un browser viene avviata utilizzando il codice JavaScript. Successivamente, tre motori sono responsabili della comunicazione: i motori voce e video raccolgono dati multimediali dalla webcam e dal microfono e il motore di trasporto combina le informazioni e invia il flusso in forma crittografata utilizzando il protocollo SRTP (Secure Real-time Protocol).

Quali browser funzionano con WebRTC

Chrome e Firefox sono dotati di un motore WebRTC che utilizza servizi come talky.io. Il browser di Mozilla può funzionare direttamente con il proprio client.

Google e Mozilla continuano a sviluppare l'idea della comunicazione in tempo reale: Chrome può ospitare una conferenza WebRTC con più partecipanti e il nuovo client Firefox Hello è sviluppato in collaborazione con la controllata del colosso delle telecomunicazioni Telefonica. Apple rimane in disparte per ora, non dovremmo ancora aspettarci WebRTC in Safari. Tuttavia, ci sono molte app iOS e plug-in alternativi per Safari.

Microsoft sta seguendo un corso leggermente diverso. In qualità di proprietario del servizio Skype competitivo, questa azienda non si arrenderà così facilmente a WebRTC. Invece, Microsoft sta sviluppando una tecnologia chiamata ORTC (Object Real-Time Communications) per Internet Explorer.

Le differenze da WebRTC, come altri codec e protocolli per stabilire un contatto con il server, sono insignificanti e nel tempo è probabile che si evolvano oltre allo standard WebRTC, che includerà queste discrepanze. Quindi, solo Apple è rimasta indietro, come al solito.

Foto: Compagnie manifatturiere; goodluz / Fotolia.com

Le tecnologie per le chiamate dal browser sono state per molti anni: Java, ActiveX, Adobe Flash ... Negli ultimi anni è diventato chiaro che i plugin e le macchine virtuali di sinistra non brillano di convenienza (perché dovrei installare qualcosa affatto?) E, soprattutto, la sicurezza ... Cosa fare? C'è un'uscita!

Fino a poco tempo fa, nelle reti IP venivano utilizzati diversi protocolli per la telefonia IP o il video: SIP, il protocollo più comune, che sta uscendo di scena H.323 e MGCP, Jabber/Jingle (usato in Gtalk), Adobe RTMP* semiaperto e , ovviamente, Skype proprietario. Il progetto WebRTC, avviato da Google, sta cercando di rivoluzionare il mondo della telefonia IP e web rendendo superflui tutti i softphone, Skype compreso. WebRTC non solo implementa tutte le funzionalità di comunicazione direttamente all'interno del browser, che ormai è installato su quasi tutti i dispositivi, ma cerca contemporaneamente di risolvere il problema più generale della comunicazione tra gli utenti del browser (scambio di dati vari, trasmissione di schermate, collaborazione con documenti, e tanto altro Di più).

WebRTC dal lato dello sviluppatore web

Dal punto di vista di uno sviluppatore web, WebRTC si compone di due parti principali:

• il controllo dei flussi multimediali dalle risorse locali (fotocamera, microfono o schermo del computer locale) è implementato dal metodo navigator.getUserMedia, che restituisce un oggetto MediaStream;
• comunicazione peer-to-peer tra dispositivi che generano flussi multimediali, inclusa la definizione di metodi di comunicazione e il loro trasferimento diretto - oggetti RTCPeerConnection (per l'invio e la ricezione di flussi audio e video) e RTCDataChannel (per l'invio e la ricezione di dati dal browser).

Cosa facciamo?

Scopriremo come organizzare la più semplice chat video multiutente tra browser basata su WebRTC utilizzando i web socket. Iniziamo a sperimentare in Chrome/Chromium, come i browser più avanzati in termini di WebRTC, anche se Firefox 22, rilasciato il 24 giugno, li ha quasi raggiunti. Va detto che lo standard non è ancora stato adottato e l'API può cambiare da versione a versione. Tutti gli esempi sono stati testati in Chromium 28. Per semplicità, non controlleremo la pulizia del codice e la compatibilità tra browser.

MediaStream

Il primo e più semplice componente WebRTC è MediaStream. Fornisce al browser l'accesso ai flussi multimediali dalla fotocamera e dal microfono del computer locale. In Chrome, per questo è necessario chiamare la funzione navigator.webkitGetUserMedia () (poiché lo standard non è ancora completo, tutte le funzioni hanno un prefisso e in Firefox questa stessa funzione si chiama navigator.mozGetUserMedia ()). Quando lo chiami, all'utente verrà richiesto il permesso di accedere alla videocamera e al microfono. Sarà possibile proseguire la chiamata solo dopo che l'utente avrà prestato il proprio consenso. I parametri del flusso multimediale richiesto e le due funzioni di callback vengono passati come parametri di questa funzione: la prima verrà chiamata in caso di accesso riuscito alla telecamera/microfono, la seconda in caso di errore. Per prima cosa, creiamo un file HTML rtctest1.html con un pulsante e un elemento

getUserMedia

Microsoft CU-RTC-Web

Microsoft non sarebbe Microsoft se, in risposta all'iniziativa di Google, non avesse rilasciato immediatamente la propria versione non standard incompatibile chiamata CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web. htm). Sebbene la quota di IE, che è già piccola, continui a diminuire, il numero di utenti Skype dà a Microsoft la speranza di spremere Google e si può presumere che questo standard verrà utilizzato nella versione browser di Skype. Lo standard di Google si concentra principalmente sulla comunicazione tra browser; allo stesso tempo, la maggior parte del traffico voce rimane ancora nella normale rete telefonica e sono necessari gateway tra questa e le reti IP non solo per facilità d'uso o distribuzione più veloce, ma anche come mezzo di monetizzazione, che consentirà a più giocatori per svilupparli... L'emergere di un altro standard potrebbe non solo portare a una spiacevole necessità per gli sviluppatori di supportare due tecnologie incompatibili contemporaneamente, ma anche a lungo termine offrire all'utente una scelta più ampia di possibili funzionalità e soluzioni tecniche disponibili. Aspetta e vedi.

Abilitazione del flusso locale

All'interno dei tag del nostro file HTML, dichiariamo una variabile globale per il flusso multimediale:

Var localStream = null;

Il primo parametro del metodo getUserMedia deve specificare i parametri del flusso multimediale richiesto, ad esempio abilitare solo l'audio o il video:

Var streamConstraints = ("audio": vero, "video": vero); // Richiedi l'accesso sia all'audio che al video

Oppure specificare parametri aggiuntivi:

Var streamConstraints = ("audio": true, "video": ("obbligatorio": ("maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5"), "opzionale":) );

Il secondo parametro al metodo getUserMedia deve essere passato a una funzione di callback che verrà chiamata se viene eseguita correttamente:

Funzione getUserMedia_success (stream) (console.log ("getUserMedia_success ():", stream); localVideo1.src = URL.createObjectURL (stream); // Collega il flusso multimediale all'elemento HTML

Il terzo parametro è la funzione di callback, un gestore di errori che verrà chiamato in caso di errore

Funzione getUserMedia_error (error) (console.log ("getUserMedia_error ():", errore);)

In realtà chiamando il metodo getUserMedia - richiedendo l'accesso al microfono e alla fotocamera quando viene premuto il primo pulsante

Funzione getUserMedia_click () (console.log ("getUserMedia_click ()"); navigator.webkitGetUserMedia (streamConstraints, getUserMedia_success, getUserMedia_error);)

Non è possibile accedere al flusso multimediale da un file aperto localmente. Se proviamo a farlo, otteniamo un errore:

NavigatorUserMediaError (codice: 1, PERMISSION_DENIED: 1) "

Carichiamo il file risultante sul server, apriamolo in un browser e, in risposta alla richiesta che appare, consentiamo l'accesso alla telecamera e al microfono.

Puoi selezionare i dispositivi a cui Chrome accederà in Impostazioni, Mostra collegamento impostazioni avanzate, sezione Privacy, pulsante Contenuto. Nei browser Firefox e Opera, i dispositivi vengono selezionati direttamente dall'elenco a discesa quando l'accesso è consentito.

Con HTTP, l'autorizzazione verrà richiesta ogni volta che si accede al flusso multimediale dopo che la pagina è stata caricata. Il passaggio a HTTPS ti consentirà di visualizzare la richiesta una volta, solo al primo accesso al flusso multimediale.

Presta attenzione al cerchio pulsante nell'icona sul segnalibro e all'icona della fotocamera sul lato destro della barra degli indirizzi:

RTCMediaConnection

RTCMediaConnection è un oggetto progettato per stabilire e trasmettere flussi multimediali sulla rete tra i partecipanti. Inoltre, questo oggetto è responsabile della generazione della descrizione della sessione multimediale (SDP), dell'ottenimento di informazioni sui candidati ICE per l'attraversamento di NAT o firewall (locali e tramite STUN) e dell'interazione con il server TURN. Ogni partecipante deve avere una RTCMediaConnection per connessione. I flussi multimediali vengono trasmessi utilizzando il protocollo SRTP crittografato.

TURN server

I candidati ICE sono di tre tipi: host, srflx e relay. L'host contiene le informazioni ricevute localmente, srflx - come il nodo guarda a un server esterno (STUN) e relay - le informazioni per il proxy del traffico attraverso il server TURN. Se il nostro nodo è dietro NAT, i candidati host conterranno indirizzi locali e saranno inutili, i candidati srflx aiuteranno solo con determinati tipi di NAT e l'inoltro sarà l'ultima speranza per passare il traffico attraverso un server intermedio.

Un esempio di un candidato ICE di tipo host, con indirizzo 192.168.1.37 e porta udp/34022:

A = candidato: 337499441 2 udp 2113937151 192.168.1.37 34022 typ generazione host 0

Formato generale per specificare i server STUN / TURN:

Var server = ("iceServers": [("url": "stun: stun.stunprotocol.org: 3478"), ("url": "turn: [e-mail protetta]: porta "," credenziale ":" password ")]);

Ci sono molti server STUN pubblici su Internet. Ad esempio, c'è un lungo elenco. Sfortunatamente, risolvono troppo pochi problemi. Non ci sono praticamente server TURN pubblici, a differenza di STUN. Ciò è dovuto al fatto che il server TURN passa i flussi multimediali attraverso se stesso, il che può caricare in modo significativo sia il canale di rete che il server stesso. Pertanto, il modo più semplice per connettersi ai server TURN è installarlo da soli (è chiaro che è richiesto un IP pubblico). Di tutti i server, rfc5766-turn-server è il migliore secondo me. C'è anche un'immagine già pronta per Amazon EC2.

Con TURN, non tutto è buono come vorremmo, ma lo sviluppo attivo è in corso e spero che dopo qualche tempo WebRTC, se non uguale a Skype nella qualità del passaggio attraverso la traduzione degli indirizzi (NAT) e i firewall, almeno notevolmente si avvicinerà.

RTCMediaConnection richiede un meccanismo aggiuntivo per lo scambio di informazioni di controllo per stabilire una connessione - sebbene generi questi dati, non li trasmette e il trasferimento ad altri partecipanti deve essere implementato separatamente.

La scelta del metodo di trasferimento è responsabilità dello sviluppatore, anche se manualmente. Non appena avviene lo scambio dei dati necessari, RTCMediaConnection imposterà automaticamente i flussi multimediali (se possibile, ovviamente).

Modello offerta-risposta

Per stabilire e modificare i flussi multimediali, vengono utilizzati il ​​modello di offerta/risposta (descritto in RFC3264) e il protocollo di descrizione della sessione (SDP). Sono utilizzati anche dal protocollo SIP. In questo modello si distinguono due agenti: Offerente - colui che genera una descrizione della sessione SDP per crearne una nuova o modificarne una esistente (Offerta SDP), e Risponditore - colui che riceve una descrizione della sessione SDP da un altro agente e risponde a it con la propria descrizione della sessione (Answer SDP). Allo stesso tempo, la specifica richiede la presenza di un protocollo di livello superiore (ad esempio, SIP o i propri socket su web, come nel nostro caso), che è responsabile del trasferimento di SDP tra gli agenti.

Quali dati devono essere trasferiti tra due RTCMediaConnection affinché possano stabilire correttamente flussi multimediali:

• Il primo partecipante che avvia la connessione forma un'Offerta, nella quale trasmette una struttura dati SDP (lo stesso protocollo viene utilizzato allo stesso scopo in SIP) descrivendo le possibili caratteristiche del flusso mediatico che sta per iniziare a trasmettere. Questo blocco dati deve essere trasferito al secondo partecipante. Il secondo partecipante forma una risposta con il suo SDP e la invia al primo.
• Sia il primo che il secondo partecipante eseguono la procedura per determinare i possibili candidati ICE, con l'aiuto del quale il secondo partecipante può trasmettere loro il flusso multimediale. Quando i candidati vengono identificati, le informazioni su di essi devono essere trasmesse a un altro partecipante.

Formazione dell'offerta

Per formare un'Offerta, abbiamo bisogno di due funzioni. Il primo verrà chiamato se è stato formato con successo. Il secondo parametro del metodo createOffer() è una funzione di callback che viene chiamata in caso di errore durante la sua esecuzione (a condizione che il flusso locale sia già disponibile).

Inoltre, sono necessari due gestori di eventi: onicecandidate quando si definisce un nuovo candidato ICE e onaddstream quando si collega un flusso multimediale dall'altra parte. Torniamo al nostro file. Aggiungi a HTML dopo le righe con elementi uno in più:

creareOfferta

E dopo la linea con l'elemento

Inoltre, all'inizio del codice JavaScript, dichiariamo una variabile globale per RTCPeerConnection:

Var pc1;

Quando si chiama il costruttore RTCPeerConnection, è necessario specificare i server STUN/TURN. Vedi la barra laterale per maggiori dettagli; fintanto che tutti i partecipanti sono sulla stessa rete, non sono necessari.

Server Var = nullo;

Parametri per la preparazione dell'offerta SDP

Var offerConstraints = ();

Il primo parametro del metodo createOffer() è una funzione di callback che viene chiamata quando un'offerta viene generata correttamente.

Funzione pc1_createOffer_success (desc) (console.log ("pc1_createOffer_success (): \ ndesc.sdp: \ n" + desc.sdp + "desc:", desc); pc1.setLocalDescription (desc); // Imposta RTCPeerConnection generato dall'offerta SDP utilizzando il metodo setLocalDescription. // Quando il lato remoto invia la sua risposta SDP, dovrà essere impostato utilizzando il metodo setRemoteDescription // Fino all'implementazione del secondo lato, non eseguire alcuna operazione // pc2_receivedOffer (desc);)

Il secondo parametro è una funzione di callback che verrà chiamata in caso di errore

Funzione pc1_createOffer_error (error) (console.log ("pc1_createOffer_success_error (): errore:", errore);)

E dichiareremo una funzione di callback a cui verranno passati i candidati ICE così come sono definiti:

Funzione pc1_onicecandidate (event) (if (event.candidate) (console.log ("pc1_onicecandidate (): \ n" + event.candidate.candidate.replace ("\ r \ n", ""), event.candidate); // Fino all'implementazione del secondo lato, non eseguire alcuna operazione // pc2.addIceCandidate (new RTCIceCandidate (event.candidate));))

E anche una funzione di callback per aggiungere un flusso multimediale dal lato opposto (per il futuro, dal momento che finora abbiamo solo un RTCPeerConnection):

Funzione pc1_onaddstream (event) (console.log ("pc_onaddstream ()"); remoteVideo1.src = URL.createObjectURL (event.stream);)

Quando si fa clic sul pulsante "createOffer", creare una RTCPeerConnection, impostare i metodi onicecandidate e onaddstream e richiedere la formazione dell'Offerta SDP chiamando il metodo createOffer():

Funzione createOffer_click () (console.log ("createOffer_click ()"); pc1 = new webkitRTCPeerConnection (server); // Crea RTCPeerConnection pc1.onicecandidate = pc1_onicecandidate; // Funzione di callback per elaborare i candidati ICE pc1._onaddstream = pc1 // Richiamata funzione che viene chiamata quando appare un media stream dall'altra parte, non è ancora disponibile pc1.addStream (localStream); // Trasferiamo il media stream locale (supponiamo che sia già stato ricevuto) pc1.createOffer (// E in realtà richiediamo la formazione di Offer pc1_createOffer_success , pc1_createOffer_error, offerConstraints);)

Salviamo il file come rtctest2.html, mettiamolo sul server, apriamolo in un browser e vediamo nella console quali dati vengono generati durante il suo funzionamento. Il secondo video non apparirà ancora, poiché c'è un solo partecipante. Ricorda che SDP è una descrizione dei parametri della sessione multimediale, i codec disponibili, i flussi multimediali e i candidati ICE sono possibili opzioni per la connessione a un determinato partecipante.

Rispondi alla formazione SDP e allo scambio di candidati ICE

Sia l'Offerta SDP che ciascuno dei candidati ICE devono essere passati all'altro lato e lì, dopo averli ricevuti da RTCPeerConnection, chiamare i metodi setRemoteDescription per l'Offerta SDP e addIceCandidate per ciascun candidato ICE ricevuto dall'altro lato; Allo stesso modo al contrario per Answer SDP e candidati ICE remoti. La stessa Risposta SDP si forma con le stesse modalità dell'Offerta; la differenza è che non viene chiamato il metodo createOffer, ma il metodo createAnswer e prima di questo RTCPeerConnection l'Offerta SDP ricevuta dal chiamante viene passata dal metodo setRemoteDescription.

Aggiungiamo un altro elemento video all'HTML:

E una variabile globale per la seconda RTCPeerConnection sotto la prima:

Var pc2;

Elaborazione SDP di offerte e risposte

La generazione della risposta SDP è molto simile all'offerta. Nella funzione di callback, chiamata a formazione riuscita della Risposta, analogamente all'Offerta, diamo la descrizione locale e passiamo la risposta SDP ricevuta al primo partecipante:

Funzione pc2_createAnswer_success (desc) (pc2.setLocalDescription (desc); console.log ("pc2_createAnswer_success ()", desc.sdp); pc1.setRemoteDescription (desc);)

La funzione di callback, chiamata in caso di errore durante la formazione di una risposta, è del tutto simile a Offer:

Funzione pc2_createAnswer_error (error) (console.log ("pc2_createAnswer_error ():", errore);)

Parametri per la generazione di Answer SDP:

Var answerConstraints = ("obbligatorio": ("OfferToReceiveAudio": true, "OfferToReceiveVideo": true));

Quando un'offerta viene ricevuta dal secondo partecipante, creare una RTCPeerConnection e formare una risposta in modo simile all'offerta:

Funzione pc2_receivedOffer (desc) (console.log ("pc2_receiveOffer ()", desc); // Crea un oggetto RTCPeerConnection per il secondo partecipante allo stesso modo del primo pc2 = new webkitRTCPeerConnection (server); pc2.onicecandidate = pc2_onicecandidate; // Imposta un gestore di eventi candidato ICE pc2.onaddstream = pc_onaddstream; // Quando viene visualizzato lo stream, collegalo all'HTML

Per passare l'Offerta SDP dal primo partecipante al secondo nell'ambito del nostro esempio, togliamo il commento nella funzione pc1 creareOfferta success() stringa di chiamata:

Pc2_receivedOffer (desc);

Per implementare l'elaborazione dei candidati ICE, decommentare il gestore dell'evento di disponibilità del candidato ICE del primo partecipante pc1_onicecandidate() per passarlo al secondo:

Pc2.addIceCandidate (nuovo RTCIceCandidate (event.candidate));

Il secondo gestore di eventi di disponibilità dei partecipanti per i candidati ICE è rispecchiato come il primo:

Funzione pc2_onicecandidate (event) (if (event.candidate) (console.log ("pc2_onicecandidate ():", event.candidate.candidate); pc1.addIceCandidate (nuovo RTCIceCandidate (event.candidate));))

Funzione di callback per l'aggiunta di un flusso multimediale dal primo partecipante:

Funzione pc2_onaddstream (event) (console.log ("pc_onaddstream ()"); remoteVideo2.src = URL.createObjectURL (event.stream);)

Terminare la connessione

Aggiungiamo un altro pulsante all'HTML

Appendere

E una funzione per terminare la connessione

Funzione btnHangupClick () (// Disconnetti il ​​video locale dagli elementi HTML

Salviamolo come rtctest3.html, mettiamolo sul server e apriamolo in un browser. Questo esempio implementa lo streaming multimediale bidirezionale tra due RTCPeerConnection all'interno dello stesso segnalibro del browser. Per organizzare lo scambio di Offerta e Risposta SDP, candidati ICE tra partecipanti e altre informazioni attraverso la rete, invece di una chiamata diretta di procedure, sarà necessario attuare lo scambio tra i partecipanti utilizzando un qualche tipo di trasporto, nel nostro caso, prese web.

Trasmissione sullo schermo

La funzione getUserMedia può anche catturare uno schermo e trasmettere come MediaStream specificando i seguenti parametri:

Var mediaStreamConstraints = (audio: false, video: (obbligatorio: (chromeMediaSource: "screen"), opzionale:));

Per accedere con successo alla schermata, devono essere soddisfatte diverse condizioni:

• abilita il flag dello screenshot in getUserMedia () in chrome: // flags /, chrome: // flags /;
• il file sorgente deve essere caricato su HTTPS (origine SSL);
• il flusso audio non deve essere richiesto;
• più richieste non devono essere eseguite in una scheda del browser.

Librerie per WebRTC

Sebbene WebRTC non sia ancora terminato, esistono già diverse librerie basate su di esso. JsSIP è progettato per creare softphone basati su browser che funzionano con switch SIP come Asterisk e Camalio. PeerJS semplificherà la creazione di reti P2P per lo scambio di dati e Holla ridurrà la quantità di sviluppo richiesta per la comunicazione P2P dai browser.

Node.js e socket.io

Per organizzare lo scambio di candidati SDP e ICE tra due RTCPeerConnection sulla rete, utilizziamo Node.js con il modulo socket.io.

Viene descritta l'installazione dell'ultima versione stabile di Node.js (per Debian / Ubuntu)

$ sudo apt-get install python-software-properties python g ++ make $ sudo add-apt-repository ppa: chris-lea / node.js $ sudo apt-get update $ sudo apt-get install nodejs

Viene descritta l'installazione per altri sistemi operativi

Controlliamo:

$ echo "sys = require (" util "); sys.puts (" Messaggio di prova ");" > nodetest1.js $ nodejs nodetest1.js

Installa socket.io e l'add-on express usando npm (Node Package Manager):

$ npm install socket.io express

Verifichiamo creando un file nodetest2.js per il lato server:

$ nano nodetest2.js var app = require ("express") (), server = require ("http"). createServer (app), io = require ("socket.io"). listen (server); server.ascolta (80); // Se la porta 80 è gratuita app.get ("/", funzione (req, res) (// Quando si accede alla pagina principale res.sendfile (__ dirname + "/nodetest2.html"); // invia il file HTML )) ; io.sockets.on ("connessione", funzione (socket) (// Quando si connette socket.emit ("evento server", (ciao: "mondo")); // invia messaggio socket.on ("evento client", function (data) (// e dichiara un gestore di eventi quando arriva un messaggio dal client console.log (data);));));

E nodetest2.html per il lato client:

$ nano nodetest2.html

Avviamo il server:

$ sudo nodejs nodetest2.js

e apri la pagina http: // localhost: 80 (se in esecuzione localmente sulla porta 80) in un browser. Se tutto va a buon fine, nella console JavaScript del browser vedremo lo scambio di eventi tra il browser e il server al momento della connessione.

Scambio di informazioni tra RTCPeerConnection su websocket

Parte cliente

Salviamo il nostro esempio principale (rtcdemo3.html) con il nuovo nome rtcdemo4.html. Colleghiamo la libreria socket.io nell'elemento:

E all'inizio dello script JavaScript - connessione ai websocket:

Var socket = io.connect ("http: // localhost");

Sostituiamo la chiamata diretta di funzioni di un altro partecipante inviandogli un messaggio tramite socket web:

Function createOffer_success (desc) (... // pc2_receivedOffer (desc); socket.emit ("offer", desc); ...) function pc2_createAnswer_success (desc) (... // pc1.setRemoteDescription (desc); socket .emit ("answer", desc);) function pc1_onicecandidate (event) (... // pc2.addIceCandidate (new RTCIceCandidate (event.candidate)); socket.emit ("ice1", event.candidate); .. .) function pc2_onicecandidate (event) (... // pc1.addIceCandidate (new RTCIceCandidate (event.candidate)); socket.emit ("ice2", event.candidate); ...)

Nella funzione hangup(), invece di chiamare direttamente le funzioni del secondo partecipante, passa il messaggio tramite socket web:

Funzione btnHangupClick () (... // remoteVideo2.src = ""; pc2.close (); pc2 = null; socket.emit ("hangup", ());)

E aggiungi gestori per ricevere il messaggio:

Socket.on ("offerta", funzione (dati) (console.log ("socket.on (" offerta "):", dati); pc2_receivedOffer (dati);)); socket.on ("risposta", funzione (dati) (e console.log ("socket.on (" risposta "):", dati); pc1.setRemoteDescription (nuovo RTCSessionDescription (dati));)); socket.on ("ice1", function (data) (console.log ("socket.on (" ice1 "):", data); pc2.addIceCandidate (nuovo RTCIceCandidate (data));)); socket.on ("ice2", function (data) (console.log ("socket.on (" ice2 "):", data); pc1.addIceCandidate (nuovo RTCIceCandidate (data));)); socket.on ("hangup", function (data) (console.log ("socket.on (" hangup "):", data); remoteVideo2.src = ""; pc2.close (); pc2 = null;) );

parte server

Lato server, salva il file nodetest2 con il nuovo nome rtctest4.js e aggiungi la ricezione e l'invio di messaggi client all'interno della funzione io.sockets.on ("connection", function (socket) (...):

Socket.on ("offerta", funzione (dati) (// Quando viene ricevuto il messaggio "offerta", // poiché in questo esempio c'è solo una connessione client, // invia il messaggio indietro attraverso lo stesso socket socket.emit ("offer", data); // Se fosse necessario inviare un messaggio attraverso tutte le connessioni, // tranne il mittente: // soket.broadcast.emit ("offer", data);)); socket.on ("risposta", funzione (dati) (socket.emit ("risposta", dati);)); socket.on ("ice1", function (data) (socket.emit ("ice1", data);)); socket.on ("ice2", function (data) (socket.emit ("ice2", data);)); socket.on ("hangup", function (data) (socket.emit ("hangup", data);));

Inoltre, cambieremo il nome del file HTML:

// res.sendfile (__ nomedir + "/nodetest2.html"); // Invia il file HTML res.sendfile (__ dirname + "/rtctest4.html");

Avvio del server:

$ sudo nodejs nodetest2.js

Nonostante il codice di entrambi i client venga eseguito all'interno dello stesso segnalibro del browser, tutta l'interazione tra i partecipanti nel nostro esempio viene eseguita completamente attraverso la rete e non richiede particolari difficoltà per "separare" i partecipanti. Tuttavia, ciò che abbiamo fatto è stato anche molto semplice: queste tecnologie sono buone per la loro facilità d'uso. Anche se a volte inganna. In particolare, non dimentichiamo che senza i server STUN/TURN il nostro esempio non può funzionare in presenza di address translation e firewall.

Conclusione

L'esempio risultante è molto condizionale, ma se universalizziamo leggermente i gestori di eventi in modo che non differiscano sul chiamante e sul chiamato, invece di due oggetti pc1 e pc2, creiamo un array RTCPeerConnection e implementiamo la creazione dinamica e la rimozione di elementi

Possiamo presumere che molto presto, grazie a WebRTC, ci sarà una rivoluzione non solo nella nostra comprensione delle comunicazioni voce e video, ma anche nel modo in cui percepiamo Internet in generale. WebRTC si posiziona non solo come tecnologia per le chiamate da un browser a un browser, ma anche come tecnologia di comunicazione in tempo reale. La videocomunicazione che abbiamo analizzato è solo una piccola parte delle possibili opzioni per il suo utilizzo. Esistono già esempi di screencasting e collaborazione e persino una rete di distribuzione di contenuti P2P basata su browser che utilizza RTCDataChannel.

Oggi WebRTC è la tecnologia più in voga per lo streaming di audio e video nei browser. Le tecnologie conservative come HTTP Streaming e Flash sono più adatte alla distribuzione di contenuti registrati (video on demand) e sono significativamente inferiori a WebRTC in termini di trasmissioni in tempo reale e online, ad es. dove è richiesta una latenza video minima per consentire agli spettatori di vedere cosa sta succedendo "dal vivo".

La possibilità di una comunicazione in tempo reale di alta qualità deriva dalla stessa architettura WebRTC, in cui viene utilizzato il protocollo UDP per il trasporto di flussi video, che è la base standard per la trasmissione video con ritardi minimi ed è ampiamente utilizzato nei sistemi di comunicazione in tempo reale.

La latenza della comunicazione è importante nei sistemi di trasmissione online, nei webinar e in altre applicazioni in cui è richiesta la comunicazione interattiva con la sorgente video, gli utenti finali e la soluzione.

Un altro buon motivo per provare WebRTC è sicuramente una tendenza. Oggi ogni browser Android Chrome supporta questa tecnologia, che garantisce milioni di dispositivi pronti a guardare la trasmissione senza installare alcun software o configurazione aggiuntiva.

Per testare la tecnologia WebRTC in azione e lanciare una semplice trasmissione online su di essa, abbiamo utilizzato il software Flashphoner WebRTC Media & Broadcasting Server. Le funzionalità dichiarano la possibilità di trasmettere flussi WebRTC in modalità uno-a-molti, oltre al supporto per telecamere IP e sistemi di videosorveglianza tramite protocollo RTSP; in questa panoramica, ci concentreremo sul webcasting e sulle sue caratteristiche.

Installazione di WebRTC Media & Broadcasting Server

Poiché non esisteva una versione server per Windows e non volevo installare una macchina virtuale come VMWare + Linux, non potevo testare le trasmissioni online sul mio computer Windows di casa. Per risparmiare tempo, abbiamo deciso di fare un'istanza su un cloud hosting come questo:

Era Centos x86_64 versione 6.5 senza alcun software preinstallato nel datacenter di Amsterdam. Quindi, tutto ciò che abbiamo a nostra disposizione è il server e l'accesso ssh ad esso. Per chi ha familiarità con i comandi della console Linux, l'installazione del server WebRTC promette di essere semplice e indolore. Quindi cosa abbiamo fatto:

1. Scarica l'archivio:

$ wget https: //site/download-wcs5-server.tar.gz

2. Disimballare:

$ tar -xzf download-wcs5-server.tar.gz

3. Installare:

$ cd FlashphoneWebCallServer

Durante l'installazione, inserire l'indirizzo IP del server: XXX.XXX.XXX.XXX

4. Attiva licenza:

$ cd / usr / local / FlashphonerWebCallServer / bin

$. / attivazione.sh

5. Avvia il server WCS:

$ service webcallserver start

6. Registro di controllo:

$ tail - f /usr/local/FlashphonerWebCallServer/logs/flashphoner_manager.log

7. Verificare che siano in atto due processi:

$ ps aux | grep Flashphone

Il processo di installazione è completo.

Testare le trasmissioni online di WebRTC

Testare le trasmissioni si è rivelato una cosa semplice. Oltre al server è presente un client web, che consiste in una dozzina di file Javascript, HTML e CSS ed è stato da noi distribuito nella cartella /var/www/html durante la fase di installazione. L'unica cosa da fare era inserire l'indirizzo IP del server nella configurazione flashphoner.xml in modo che il client web potesse stabilire una connessione al server tramite Websocket HTML5. Descriviamo il processo di test.

1. Apri la pagina del client di prova index.html nel browser Chrome:

2. Per avviare la trasmissione, è necessario premere il pulsante "Start" al centro dello schermo.
Prima di fare ciò, devi assicurarti che la webcam sia collegata e pronta per l'uso. Non ci sono requisiti speciali per una webcam, ad esempio, abbiamo utilizzato una fotocamera standard integrata in un laptop con una risoluzione di 1280 × 800.

Il browser Chrome chiederà sicuramente l'accesso alla fotocamera e al microfono in modo che l'utente capisca che il suo video verrà inviato al server Internet e gli permetta di farlo.

3. L'interfaccia è una trasmissione riuscita del flusso video dalla telecamera al server WebRTC. Nell'angolo in alto a destra, l'indicatore indica che il flusso sta andando al server, nell'angolo in basso c'è un pulsante Stop per interrompere l'invio del video.

Notare il collegamento nella casella sottostante. Contiene un identificatore univoco per questo stream, quindi chiunque può partecipare alla visualizzazione. È sufficiente aprire questo collegamento in un browser. Per copiarlo negli appunti, fare clic sul pulsante "Copia".

In applicazioni reali come webinar, conferenze, trasmissioni video online o TV interattiva, gli sviluppatori dovranno implementare la distribuzione di questo identificatore a determinati gruppi di spettatori in modo che possano connettersi ai flussi necessari, ma questa è la logica dell'applicazione. Server di trasmissione e media WebRTC non lo riguarda, ma si occupa solo della distribuzione del video.

5. La connessione viene stabilita e lo spettatore vede il flusso sullo schermo. Ora può inviare il collegamento a qualcun altro, interrompere la riproduzione dello streaming o attivare la modalità a schermo intero utilizzando i controlli nell'angolo in basso a destra.

Risultati del test del server WebRTC delle trasmissioni online

Durante i test, la latenza sembrava perfetta. Il ping al datacenter era di circa 100 millisecondi e la latenza era invisibile agli occhi. Quindi, possiamo assumere che il ritardo reale sia lo stesso 100 più o meno poche decine di millisecondi per il tempo di buffering. Rispetto al video Flash: in tali test, Flash non si comporta bene come WebRTC. Quindi, se muovi la mano su una rete simile, il movimento sullo schermo può essere visto solo dopo uno / due secondi.

Per quanto riguarda la qualità, notiamo che a volte si possono distinguere cubi sui movimenti. Ciò è in linea con la natura del codec VP8 e il suo scopo principale: fornire comunicazioni video in tempo reale con una qualità accettabile e senza ritardi di comunicazione.

Il server è abbastanza semplice da installare e configurare; per avviarlo non sono necessarie competenze serie se non la conoscenza di Linux a livello di un utente avanzato, che può eseguire comandi dalla console tramite ssh e utilizzare un editor di testo. Di conseguenza, siamo riusciti a stabilire una trasmissione online uno a molti tra i browser. Anche il collegamento di spettatori aggiuntivi allo stream non ha causato problemi.

La qualità della trasmissione si è rivelata abbastanza accettabile per i webinar e le trasmissioni online. L'unica cosa che ha sollevato alcune domande è stata la risoluzione video. La fotocamera supporta 1280x800, ma la risoluzione nell'immagine di prova è molto simile a 640x480. Apparentemente, questa domanda deve essere chiarita con gli sviluppatori.

Video per testare la trasmissione da una webcam
tramite server WebRTC

WebRTC è un'API fornita da un browser che consente di organizzare una connessione P2P e trasferire dati direttamente tra browser. Ci sono parecchi tutorial su Internet per scrivere la tua video chat usando WebRTC. Ad esempio, ecco un articolo su Habré. Tuttavia, sono tutti limitati alla connessione di due client. In questo articolo cercherò di parlare di come organizzare la connessione e lo scambio di messaggi tra tre o più utenti utilizzando WebRTC.

L'interfaccia RTCPeerConnection è una connessione peer-to-peer tra due browser. Per connettere tre o più utenti, dovremo organizzare una rete mesh (una rete in cui ogni nodo è connesso a tutti gli altri nodi).
Useremo il seguente schema:

1. All'apertura della pagina, controlliamo la presenza di un ID camera in location.hash
2. Se l'ID della camera non è specificato, ne generiamo uno nuovo
3. Inviamo un server di segnalazione "y un messaggio che vogliamo entrare nella stanza specificata
4. Il server di segnalazione invia una nuova notifica utente al resto dei client in questa stanza.
5. I clienti che sono già nella stanza inviano un'offerta SDP al nuovo arrivato
6. Il principiante risponde all'offerta

0. Server di segnalazione

Come sai, sebbene WebRTC fornisca una connessione P2P tra i browser, richiede comunque un trasporto aggiuntivo per scambiare messaggi di servizio. In questo esempio, tale trasporto è un server WebSocket scritto in Node.JS utilizzando socket.io:

Var socket_io = require ("socket.io"); module.exports = function (server) (var users = (); var io = socket_io (server); io.on ("connection", function (socket) (// Il nuovo utente vuole unirsi alla stanza socket.on (" room ", funzione (messaggio) (var json = JSON.parse (messaggio); // Aggiunge il socket all'elenco degli utenti utenti = socket; if (socket.room! == non definito) (// Se il socket è già in qualche stanza, esci da socket.leave (socket.room);) // Inserisci la stanza richiesta socket.room = json.room; socket.join (socket.room); socket.user_id = json.id; // Invia ad altri client in questa stanza un messaggio su un nuovo partecipante che si unisce a socket.broadcast.to (socket.room) .emit ("new", json.id);)); // Messaggio relativo a WebRTC (offerta SDP, risposta SDP o candidato ICE) socket.on ("webrtc", function (message) (var json = JSON.parse (message); if (json.to! == undefined && users! == undefined) (// Se il messaggio contiene un destinatario e questo destinatario noto al server, inviamo un messaggio solo a lui... users.emit ("webrtc", messaggio); ) else (// ... altrimenti, considera il messaggio come un broadcast socket.broadcast.to (socket.room) .emit ("webrtc", messaggio);))); // Qualcuno ha disconnesso socket.on ("disconnect", function() (// Quando un client si disconnette, avvisa gli altri di esso socket.broadcast.to (socket.room) .emit ("leave", socket.user_id); delete utenti;)); )); );

1.index.html

Il codice sorgente per la pagina stessa è piuttosto semplice. Non ho deliberatamente prestato attenzione al layout e ad altre bellezze, poiché questo articolo non parla di questo. Se qualcuno vuole renderla bella, non sarà difficile.

2.main.js

2.0. Ottenere collegamenti agli elementi della pagina e alle interfacce WebRTC

var chatlog = document.getElementById ("chatlog"); var messaggio = document.getElementById ("messaggio"); var connection_num = document.getElementById ("connection_num"); var room_link = document.getElementById ("room_link");

Dobbiamo ancora utilizzare i prefissi del browser per fare riferimento alle interfacce WebRTC.

Var PeerConnection = window.mozRTCPeerConnection || window.webkitRTCPeerConnection; var SessionDescription = window.mozRTCSessionDescription || finestra.RTCSessionDescription; var IceCandidate = window.mozRTCIceCandidate || finestra.RTCIceCandidate;

2.1. Determinazione dell'ID della camera

Qui abbiamo bisogno di una funzione per generare una stanza e un ID utente univoci. Useremo l'UUID per questi scopi.

Funzione uuid () (var s4 = function () (return Math.floor (Math.random () * 0x10000) .toString (16);); return s4 () + s4 () + "-" + s4 () + "-" + s4 () + "-" + s4 () + "-" + s4 () + s4 () + s4 ();)

Ora proviamo a estrarre l'ID della stanza dall'indirizzo. Se non ne viene specificato nessuno, ne genereremo uno nuovo. Mostriamo il collegamento alla stanza corrente sulla pagina e, in un solo passaggio, generiamo l'ID utente corrente.

Var ROOM = location.hash.substr (1); if (! ROOM) (ROOM = uuid ();) room_link.innerHTML = "Link alla stanza"; var ME = uuid ();

2.2. Websocket

Subito dopo l'apertura della pagina, ci collegheremo al nostro server di segnalazione, invieremo una richiesta per entrare nella stanza e specificheremo i gestori dei messaggi.

// Indichiamo che quando il messaggio viene chiuso, una notifica al riguardo dovrebbe essere inviata al server var socket = io.connect ("", ("sincronizzazione allo scarico": true)); socket.on ("webrtc", socketReceived); socket.on ("nuovo", socketNewPeer); // Invia immediatamente una richiesta per entrare nella stanza socket.emit ("stanza", JSON.stringify ((id: ME, stanza: ROOM))); // Funzione di supporto per l'invio di messaggi di indirizzo relativi a WebRTC Funzione sendViaSocket (type, message, to) (socket.emit ("webrtc", JSON.stringify ((id: ME, to: to, type: type, data: message ) ));)

2.3. Impostazioni di connessione peer

La maggior parte degli ISP fornisce NAT tramite la connettività Internet. Questo rende la connessione diretta meno banale. Quando creiamo una connessione, dobbiamo specificare un elenco di server STUN e TURN che il browser tenterà di utilizzare per attraversare NAT. Indicheremo anche un paio di opzioni aggiuntive per la connessione.

Var server = (iceServers: [(url: "stun: 23.21.150.121"), (url: "stun: stun.l.google.com: 19302"), (url: "turn: numb.viagenie.ca", credenziale: "la tua password va qui", nome utente: " [e-mail protetta]")]); var options = (opzionale: [(DtlsSrtpKeyAgreement: true), // richiesto per la connessione tra Chrome e Firefox (RtpDataChannels: true) // richiesto in Firefox per utilizzare l'API DataChannels])

2.4. Connessione di un nuovo utente

Quando un nuovo peer viene aggiunto alla stanza, il server ci invia un messaggio nuovo... Secondo i gestori dei messaggi sopra, la funzione verrà chiamata socketNuovoPeer.

Var peer = (); function socketNewPeer (data) (peers = (candidateCache:); // Crea una nuova connessione var pc = new PeerConnection (server, opzioni); // Inizializzala initConnection (pc, data, "offer"); // Salva il peer nell'elenco peers peers.connection = pc; // Crea un DataChannel attraverso il quale verranno scambiati i messaggi var channel = pc.createDataChannel ("mychannel", ()); channel.owner = data; peers.channel = canale; // Installa i gestori eventi channel bindEvents (channel); // Crea offerta SDP pc.createOffer (function (offer) (pc.setLocalDescription (offer);));) function initConnection (pc, id, sdpType) (pc.onicecandidate = function ( event) ( if (event.candidate) (// Quando viene trovato un nuovo candidato ICE, aggiungerlo all'elenco per ulteriori invii peers.candidateCache.push (event.candidate);) else (// Quando il rilevamento del candidato è completo, l'handler verrà chiamato nuovamente, ma senza candidato // In questo caso, invieremo prima l'offerta SDP al peer, oppure Risposta SDP (a seconda del parametro della funzione) ... sendViaSocket (sdpType, pc.localDescription, id); // ... e quindi tutti i candidati ICE precedentemente trovati per (var i = 0; i< peers.candidateCache.length; i++) { sendViaSocket("candidate", peers.candidateCache[i], id); } } } pc.oniceconnectionstatechange = function (event) { if (pc.iceConnectionState == "disconnected") { connection_num.innerText = parseInt(connection_num.innerText) - 1; delete peers; } } } function bindEvents (channel) { channel.onopen = function () { connection_num.innerText = parseInt(connection_num.innerText) + 1; }; channel.onmessage = function (e) { chatlog.innerHTML += "

"; }; }

2.5. Offerta SDP, risposta SDP, candidato ICE

Quando uno di questi messaggi viene ricevuto, chiamiamo il gestore di messaggi corrispondente.

Funzione socketReceived (data) (var json = JSON.parse (data); switch (json.type) (case "candidate": remoteCandidateReceived (json.id, json.data); break; case "offer": remoteOfferReceived (json. id, json.data); break; case "risposta": remoteAnswerReceived (json.id, json.data); break;))

2.5.0 Offerta SDP

funzione remoteOfferReceived (id, dati) (createConnection (id); var pc = peers.connection; pc.setRemoteDescription (new SessionDescription (dati)); pc.createAnswer (funzione (risposta) (pc.setLocalDescription (risposta);)); ) function createConnection (id) (if (peers === undefined) (peers = (candidateCache:); var pc = new PeerConnection (server, opzioni); initConnection (pc, id, "answer"); peers.connection = pc ; pc.ondatachannel = function (e) (peers.channel = e.channel; peers.channel.owner = id; bindEvents (peers.channel);)))

2.5.1 Risposta SDP

function remoteAnswerReceived (id, data) (var pc = peers.connection; pc.setRemoteDescription (new SessionDescription (data));)

2.5.2 Candidato ICE

function remoteCandidateReceived (id, data) (createConnection (id); var pc = peers.connection; pc.addIceCandidate (new IceCandidate (data));)

2.6. Invio di un messaggio

Premendo il pulsante Spedire la funzione è chiamata invia messaggio... Tutto ciò che fa è passare attraverso l'elenco dei peer e provare a inviare a tutti il ​​messaggio specificato.