Lo scopo di questo articolo è di familiarizzare con la sua struttura e il principio di funzionamento su un campione demo di una chat video peer-to-peer (chat video p2p). A tale scopo, utilizzeremo la demo di chat video peer-to-peer 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. codice sorgente. GitHub è un repository di librerie open source.
Quindi, scaricato da GitHub un campione demo di una video chat peer-to-peer, lo posizioneremo sul disco C personal computer nella directory creata per la nostra applicazione "webrtc_demo".
Riso. 1
Come segue dalla struttura (Fig. 1), la video chat peer-to-peer è costituita dagli script client script.js e server.js implementati nella lingua Programmazione javascript. Script (libreria) webrtc.io.js (CLIENT) - fornisce l'organizzazione delle comunicazioni in tempo reale tra i browser secondo uno schema peer-to-peer: "client-client" e webrtc.io.js (CLIENT) e webrtc .io.js (SERVER), utilizzando il protocollo WebSocket, forniscono la comunicazione duplex tra il browser e il web server utilizzando 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 chat video 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 il principio del funzionamento della chat video sistema di file pc. Per eseguire il server (server.js) su un PC, è necessario installare il runtime node.js. Node.js ti consente di eseguire codice JavaScript al di fuori del browser. Puoi scaricare node.js dal link: http://nodejs.org/ (versione v0.10.13 del 15/07/13). Nella pagina principale del sito node.org, fai clic sul pulsante di download e vai su http://nodejs.org/download/. Per utenti Windows prima scarica win.installer (.msi), quindi esegui win.installer (.msi) su PC e installa nodejs e "npm package manager" nella directory Program Files.
Riso. 2
Pertanto, node.js è costituito da un ambiente di sviluppo ed esecuzione JavaScript, nonché da un insieme di moduli interni che possono essere installati utilizzando il gestore di pacchetti npm o il gestore di pacchetti.
Per installare i moduli, è necessario riga di comando dalla directory dell'applicazione (ad esempio, "webrtc_demo") eseguire il comando: npm install module_name . Durante l'installazione dei moduli, il gestore npm crea una cartella node_modules nella directory da cui è stata eseguita l'installazione. Durante l'esecuzione, nodejs include automaticamente i moduli dalla directory node_modules.
Quindi, dopo aver installato node.js, apri la 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 piattaforma di sviluppo di applicazioni web. 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, avviamo il server: server.js:
C:\webrtc_demo>nodeserver.js
Riso. 3
Tutto, il server funziona correttamente (Figura 3). Ora, utilizzando un browser Web, è possibile contattare il server tramite indirizzo IP e scaricare la pagina Web index.html, da cui il browser Web estrarrà il codice dello script client - script.js e il codice dello script webrtc.io.js, ed eseguirli. Affinché una video chat peer-to-peer funzioni (per stabilire una connessione tra due browser), è necessario che due browser che supportano webrtc contattino il server di segnale in esecuzione su node.js tramite indirizzo ip.
Di conseguenza, l'interfaccia della parte client dell'applicazione di comunicazione (chat video) 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, tramite l'interfaccia di chat video, è possibile comunicare con dati testuali (Fig. 5).
Riso. 5
Si dovrebbe notare che . Il server sta segnalando ed è progettato principalmente per stabilire una connessione tra i browser degli utenti. Lo script server.js che fornisce la segnalazione WebRTC utilizza Node.js per l'esecuzione.
WebRTC è un'API fornita dal browser che consente di organizzare una connessione P2P e trasferire i dati direttamente tra i browser. Ci sono alcuni tutorial su Internet su come scrivere la tua chat video 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 una connessione e uno 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:
Come sai, sebbene WebRTC fornisca la possibilità di connessione P2P tra browser, richiede comunque un trasporto aggiuntivo per lo scambio di messaggi di servizio. In questo esempio, il 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) ( // Vuoi che un nuovo utente si unisca alla room socket.on( "room ", function(message) ( var json = JSON. parse(message); // Aggiunge il socket all'elenco degli utenti users = socket; if (socket.room !== undefined) ( // Se il socket è già in qualche stanza, lasciala 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 questa stanza ha un messaggio sull'adesione di un nuovo partecipante 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 ha un destinatario e questo destinatario è noto al server, inviamo un messaggio solo a lui... users.emit("webrtc", message); ) else ( // ...altrimenti considera il messaggio come un broadcast socket.broadcast.to(socket.room).emit("webrtc", message); ) )); // Qualcuno si è disconnesso socket.on("disconnect", function() ( // Quando un client si disconnette, avvisa gli altri socket.broadcast.to(socket.room).emit("leave", socket.user_id); delete users; )); )); );
1. indice.htmlIl codice sorgente per la pagina stessa è abbastanza semplice. Non ho deliberatamente prestato attenzione al layout e ad altre cose belle, poiché questo articolo non riguarda questo. Se qualcuno vuole renderla bella, non sarà difficile.
WebRTC Chat Demo Connesso a 0 peer
Inviare
Dobbiamo ancora utilizzare i prefissi del browser per accedere alle interfacce WebRTC.
Var PeerConnection = window.mozRTCPeerConnection || window.webkitRTCPeerConnection; var SessionDescription = window.mozRTCSessionDescription || window.RTCSessionDescription; var IceCandidate = window.mozRTCIceCandidate || window.RTCIceCandidate;
2.1. Determinazione dell'ID della stanzaQui abbiamo bisogno di una funzione per generare una stanza e un ID utente univoci. Useremo UUID per questo scopo.
Funzione uuid () ( var s4 = function() ( return Math.floor(Math.random() * 0x10000).toString(16); ); return s4() + s4() + "-" + s4() + "-" + s4() + "-" + s4() + "-" + s4() + s4() + s4(); )
Ora proviamo ad estrarre l'ID della camera dall'indirizzo. Se questo non è impostato, ne genereremo uno nuovo. Visualizzeremo un collegamento alla stanza corrente sulla pagina e, allo stesso tempo, genereremo un identificatore per l'utente corrente.
VarROOM = location.hash.substr(1); if (!ROOM) ( ROOM = uuid(); ) room_link.innerHTML = "Link alla stanza"; varME = uuid();
2.2. presa webImmediatamente dopo aver aperto la pagina, ci collegheremo al nostro server di segnalazione, invieremo una richiesta per entrare nella stanza e specificheremo i gestori dei messaggi.
// Specifichiamo che quando il messaggio è chiuso, dobbiamo inviare una notifica al server riguardo a questo var socket = io.connect("", ("sync disconnect on unload": true)); socket.on("webrtc", socketReceived); socket.on("nuovo", socketNewPeer); // Invia immediatamente una richiesta per entrare nella stanza socket.emit("room", JSON.stringify((id: ME, room: ROOM))); // Funzione di aiuto per inviare messaggi mirati relativi alla funzione WebRTC sendViaSocket(type, message, to) ( socket.emit("webrtc", JSON.stringify((id: ME, to: to, type: type, data: message))); )
2.3. Impostazioni di connessione peerLa maggior parte degli ISP fornisce connettività Internet tramite NAT. Per questo motivo, una connessione diretta diventa non così banale. Quando creiamo una connessione, dobbiamo specificare un elenco di server STUN e TURN che il browser tenterà di utilizzare per bypassare il NAT. Specifichiamo anche un paio opzioni aggiuntive per connettere.
Var server = ( iceServers: [ (url: "stun:23.21.150.121"), (url: "stun:stun.l.google.com:19302"), (url: "turn:numb.viagenie.ca", credenziali: "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. Collegamento di un nuovo utenteQuando un nuovo peer viene aggiunto alla stanza, il server ci invia un nuovo messaggio. Secondo i gestori di messaggi di cui sopra, verrà chiamata la funzione socketNewPeer.
var pari = (); function socketNewPeer(data) ( peers = (candidateCache: ); // Crea una nuova connessione var pc = new PeerConnection(server, options); // Inizializzala initConnection(pc, data, "offer"); // Memorizza il peer nella lista peers peers.connection = pc; // Crea un DataChannel attraverso il quale verranno scambiati i messaggi var channel = pc.createDataChannel("mychannel", ()); channel.owner = data; peers.channel = channel; // Installa i gestori di eventi bindEvents(channel); // Crea un'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, aggiungilo all'elenco per ulteriori invii peers.candidateCache.push(event.candidate); ) else ( // Quando la scoperta dei candidati è completato, il gestore verrà chiamato di nuovo, ma senza candidato // In questo caso, inviamo prima al peer un'offerta SDP o una risposta SDP (a seconda del parametro della funzione)... sendViaSocket(sdpType, pc.localDescription, id) ; // ...e poi 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 += "Peer says: " + e.data + ""; }; }
2.5. Offerta SDP, risposta SDP, candidato ICEQuando viene ricevuto uno di questi messaggi, chiamiamo il corrispondente gestore di messaggi.
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 SDP offer function remoteOfferReceived(id, data) ( createConnection(id); var pc = peers.connection; pc.setRemoteDescription(new SessionDescription(data)); pc.createAnswer(function(answer) ( pc.setLocalDescription(answer ); )); ) funzione createConnection(id) ( if (peers === undefined) ( peers = (candidateCache: ); var pc = new PeerConnection(server, options); 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 Funzione di risposta SDP remoteAnswerReceived(id , data) ( var pc = peers.connection; pc.setRemoteDescription(new SessionDescription(data)); ) 2.5.2 Funzione candidata ICE remoteCandidateReceived(id, data) ( createConnection(id); var pc = peers.connection; pc. addIceCandidate(new IceCandidate(data)); ) 2.6. Invio di un messaggioQuando si fa clic sul pulsante Invia, viene chiamata la funzione sendMessage. Tutto ciò che fa è scorrere l'elenco dei peer e provare a inviare il messaggio specificato a tutti.
Preambolo. La chat video P2P basata su WebRTC è un'alternativa a Skype e ad altri mezzi di comunicazione. Gli elementi principali della chat video p2p basata su WebRTC sono un browser e un server di contatto. Le chat video P2P sono chat video peer-to-peer in cui il server non prende parte alla trasmissione flussi informativi. Le informazioni vengono trasferite direttamente tra i browser degli utenti (peering) senza programmi aggiuntivi. Oltre ai browser, le chat video p2p utilizzano server di contatto progettati per registrare gli utenti, archiviare dati su di loro e fornire il passaggio da un utente all'altro. I browser che supportano le più recenti tecnologie WebRTC e HTML5 forniscono messaggi e file di testo istantanei, oltre a fornire comunicazioni vocali e video su reti IP.
Quindi, chat, web chat, chat vocali e video nell'interfaccia web, IMS, VoIP sono servizi che forniscono comunicazioni online attraverso reti composite a commutazione di pacchetto. Di norma, i servizi di comunicazione richiedono l'installazione di applicazioni client sui dispositivi degli utenti (PC, smartphone, ecc.) o l'installazione di plug-in ed estensioni nei browser. I servizi hanno le proprie reti di comunicazione, la maggior parte delle quali sono costruite su un'architettura "client-server".
I servizi di comunicazione sono applicazioni, ad eccezione di IMS, in cui i canali voce, video, dati e testo non sono integrati. Nelle reti di ciascun servizio, . Va notato che queste applicazioni non possono funzionare contemporaneamente in più reti di comunicazione, ad es. le applicazioni, di norma, non possono interagire tra loro, per cui è necessario installare un'applicazione separata per ciascuna rete di comunicazione.
Il problema dell'integrazione dei servizi di comunicazione in tempo reale (chat, telefonia, videoconferenza), ovvero l'integrazione di canali voce, video, trasmissione dati e l'accesso ad essi tramite un'unica applicazione (browser) può essere risolta in chat video peer-to-peer o p2p (peer-to-peer, point-to-point) basate sul protocollo WebRTC . Infatti, un browser che supporta WebRTC diventa un'unica interfaccia per tutti i dispositivi dell'utente (PC, smartphone, iPad, telefoni IP, cellulari ecc.) che lavorano con i servizi di comunicazione.
È WebRTC che fornisce l'implementazione nel browser di tutte le tecnologie che forniscono comunicazioni in tempo reale. L'essenza delle chat video p2p è che i dati multimediali e di testo vengono trasferiti direttamente tra i browser degli utenti (peering remoti) senza la partecipazione di un server e programmi aggiuntivi. Pertanto, i browser non solo forniscono l'accesso a quasi tutti risorse di informazione Internet, che vengono archiviati su server, ma diventano anche un mezzo di accesso a tutti i servizi di comunicazione in tempo reale e ai servizi di posta ( segreteria telefonica, e-mail, SMS, ecc.)
I server (server di contatto) delle chat video p2p sono destinati esclusivamente alla registrazione degli utenti, all'archiviazione dei dati sugli utenti e alla creazione di una connessione (passaggio) tra i browser degli utenti. Le prime chat video p2p sono state implementate utilizzando tecnologie flash. Le chat video Flash p2p vengono utilizzate, ad esempio, nei social network. Le chat video Flash p2p non forniscono alta qualità trasmissione di dati multimediali. Inoltre, per emettere un flusso vocale e video da un microfono e una videocamera nelle chat video flash p2p, è necessario installare un plug-in flash in un browser web.
Ma i servizi di telecomunicazione di nuova generazione includono le comunicazioni web, che utilizzano solo browser e server di contatto che supportano i protocolli WebRTC e la specifica HTML5 per comunicare su Internet. Qualsiasi dispositivo utente (PC, iPad, smartphone, ecc.) dotato di tale browser può fornire chiamate vocali e video di alta qualità, nonché trasferire messaggi di testo istantanei e file.
Quindi, la nuova tecnologia delle comunicazioni web (chat p2p, chat video) è il protocollo WebRTC. WebRTC insieme a HTML5, CSS3 e JavaScript consente di creare varie applicazioni web. WebRT è progettato per organizzare le comunicazioni web (reti peer-to-peer) in tempo reale utilizzando un'architettura peer-to-peer. Le chat P2P basate su WebRTC forniscono il trasferimento di file, nonché la comunicazione di testo, voce e video degli utenti su Internet utilizzando solo browser Web senza l'uso di componenti aggiuntivi e plug-in esterni nel browser.
Nelle chat p2p, il server viene utilizzato solo per stabilire una connessione p2p tra due browser. Per creare la parte client di una chat p2p basata sul protocollo WebRTC, vengono utilizzati HTML5, CSS3 e JavaScript. L'applicazione client comunica con i browser tramite l'API WebRTC.
WebRTC è implementato da tre API JavaScript:
I browser trasmettono dati multimediali utilizzando il protocollo SRTP, che funziona su UDP. Poiché NAT crea problemi per i browser (client) dietro i router NAT che utilizzano connessioni p2p su Internet, STUN viene utilizzato per aggirare i traduttori NAT. STUN è un protocollo client/server che viene eseguito sopra il protocollo di trasporto UDP. Nelle chat p2p, di norma, viene utilizzato un server STUN pubblico e le informazioni ricevute da esso vengono utilizzate per una connessione UDP tra due browser se si trovano dietro NAT.
Esempi di implementazione di applicazioni WebRTC (chat p2p, chat web vocali e video):
1. La chat video Bistri P2P (chat video con un clic, chat p2p), basata su WebRTC, può essere aperta su Bistri. Bistri funziona nel browser senza installare programmi e plug-in aggiuntivi. L'essenza del lavoro è la seguente: apri una video chat p2p utilizzando il link specificato, dopo esserti registrato nell'interfaccia che si apre, invita i partner, quindi seleziona il partner che è online dall'elenco dei client peer e fai clic su "videochiamata "bottone.
Di conseguenza, MediaStream (getUserMedia) acquisirà il microfono + la webcam e il server scambierà messaggi di segnalazione con il partner selezionato. Dopo lo scambio dei messaggi di segnalazione, l'API PeerConnection crea canali per la trasmissione di flussi vocali e video. Inoltre, Bistri esegue il trasferimento di messaggi di testo istantanei e file. Sulla fig. La figura 1 mostra uno screenshot dell'interfaccia di chat video p2p di Bistri.
Riso. 1. Bistri di chat video P2P
2. Twelephone (p2p video chat, p2p chat, SIP Twelephone) è un'applicazione client basata su HTML5 e WebRTC che consente di effettuare chiamate vocali e video, nonché di inviare messaggi di testo istantanei, ad es. Twelephone include chat p2p di prova, chat video e SIP Twelephone. Va notato che Twelephone supporta il protocollo SIP e ora puoi effettuare e ricevere chiamate vocali e video dai telefoni SIP utilizzando il tuo account Twitter come numero di telefono. Inoltre, i messaggi di testo possono essere inseriti a voce attraverso il microfono e il programma di riconoscimento vocale inserisce il testo nella riga "Invia un messaggio".
Twelephone è una telefonia web basata su browser Google Chrome, a partire dalla versione 25, senza ulteriori Software. Twelephone è stato progettato da Chris Matthieu. Parte server Twelephone è basato su Node.js. Il server (server di contatto) viene utilizzato solo per stabilire una connessione p2p tra due browser o client WebRTC. L'app Twelephone non ha fondi propri autorizzazione, ma incentrato sulla connessione a un account ( account) su Twitter.
Sulla fig. La Figura 2 mostra uno screenshot dell'interfaccia di chat video p2p di Twelephone.
Riso. 2.Bifono P2P
3. Video chat p2p di gruppo su cui si basa Conversat.io le ultime tecnologie WebRTC e HTML5. La chat video Conversat si basa sulla libreria SimpleWebRTC ed è progettata per comunicare con un massimo di 6 client peer in una stanza (per la comunicazione, specificare il nome della stanza comune per i client peer nella riga "Nomina la conversazione"). Video chat P2P Conversat fornisce servizi di comunicazione agli utenti senza registrarsi sul server di contatto. Sulla fig. La figura 3 mostra uno screenshot dell'interfaccia di chat video p2p di Conversat.
Riso. 3. Chat video P2P di gruppo Conversat.io
Per partecipare alle chat video P2P basate su WebRTC, gli utenti devono disporre di un browser installato che supporti il protocollo WebRTC e la specifica HTML5. Attualmente, i browser Google Chrome, a partire dalla versione 25, e Mozilla Firefox Nightly supportano il protocollo WebRTC e la specifica HTML5. Le applicazioni WebRTC sono superiori alle applicazioni Flash in termini di qualità di trasmissione di immagini e suoni.
Le tecnologie per le chiamate dal browser esistono da molti anni: Java, ActiveX, Adobe Flash... Negli ultimi anni è diventato chiaro che i plugin e se ne sono andati macchine virtuali non brillano di comodità (perché dovrei installare qualcosa?) e, soprattutto, di sicurezza. Cosa fare? C'è un'uscita!
Fino a poco tempo fa, sulle reti IP venivano utilizzati diversi protocolli per la telefonia o il video IP: SIP, il protocollo più comune uscito dalla scena, H.323 e MGCP, Jabber/Jingle (utilizzato in Gtalk), Adobe RTMP semi-aperto* e, ovviamente, Skype chiuso. Il progetto WebRTC, avviato da Google, sta cercando di ribaltare il mondo dell'IP e della telefonia web rendendo tutto superfluo. softphone compreso Skype. WebRTC non si limita a implementare tutto capacità di comunicazione direttamente all'interno del browser, che è ormai installato su quasi tutti i dispositivi, ma allo stesso tempo cerca di risolvere un compito più generale di comunicazione tra gli utenti del browser (scambio di dati vari, screen casting, collaborazione con documenti e molto altro).
WebRTC da uno sviluppatore webDal punto di vista di uno sviluppatore web, WebRTC si compone di due parti principali:
Scopriremo come organizzare la video chat multiplayer più semplice tra browser basati su WebRTC utilizzando i socket web. Cominciamo a sperimentare in Chrome/Chromium, in quanto 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 è stato ancora adottato e l'API potrebbe cambiare da versione a versione. Tutti gli esempi sono stati testati in Chromium 28. Per semplicità, non monitoreremo la pulizia del codice e la compatibilità tra browser.
mediastreamIl primo e più semplice componente WebRTC è MediaStream. Fornisce al browser l'accesso ai flussi multimediali dalla videocamera e dal microfono del computer locale. In Chrome, ciò richiede la chiamata della funzione navigator.webkitGetUserMedia() (poiché lo standard non è ancora finalizzato, tutte le funzioni hanno un prefisso e in Firefox la stessa funzione è chiamata navigator.mozGetUserMedia()). Quando viene chiamato, all'utente verrà richiesto di consentire l'accesso alla videocamera e al microfono. Sarà possibile proseguire la chiamata solo dopo che l'utente avrà espresso il proprio consenso. I parametri del flusso multimediale richiesto e due funzioni di callback vengono passati come parametri a questa funzione: la prima verrà chiamata in caso di accesso riuscito alla videocamera/microfono, la seconda in caso di errore. Innanzitutto, creiamo un file HTML rtctest1.html con un pulsante e un elemento:
WebRTC - video del primo incontro ( altezza: 240px; larghezza: 320px; bordo: 1px grigio fisso; ) getUserMedia
Microsoft non sarebbe Microsoft se, in risposta all'iniziativa di Google, non rilasciasse immediatamente la propria variante personalizzata incompatibile chiamata CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web. hm). Sebbene la quota di IE, già piccola, continui a diminuire, il numero di utenti Skype dà speranza a Microsoft di spingere Google e si può presumere che questo standard verrà utilizzato nel browser. Versioni Skype. Lo standard di Google si concentra principalmente sulla comunicazione da browser a browser; allo stesso tempo, la maggior parte del traffico voce rimane nella norma rete telefonica, e i gateway tra esso e le reti IP sono necessari non solo per facilità d'uso o distribuzione più rapida, ma anche come mezzo di monetizzazione che consentirà Di più giocatori per svilupparli. La comparsa di un altro standard può non solo portare a una spiacevole necessità per gli sviluppatori di supportare due tecnologie incompatibili contemporaneamente, ma anche in futuro offrire all'utente una scelta più ampia di possibili funzionalità e soluzioni tecniche disponibili. Aspetta e vedi.
Abilita thread localeAll'interno dei tag del nostro file HTML, dichiareremo una variabile globale per il flusso multimediale:
VarlocalStream = nullo;
Il primo parametro del metodo getUserMedia è specificare i parametri del flusso multimediale richiesto, ad esempio abilitare semplicemente audio o video:
Var streamConstraints = ("audio": true, "video": true ); // Richiedi l'accesso sia all'audio che al video
Oppure specificare parametri aggiuntivi:
Var streamConstraints = ("audio": true, "video": ("mandatory": ("maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5" ), "optional": ) );
Il secondo parametro del metodo getUserMedia consiste nel passare una funzione di callback che verrà chiamata se ha esito positivo:
Funzione getUserMedia_success(stream) ( console.log("getUserMedia_success():", stream); localVideo1.src = URL.createObjectURL(stream); // Collega il flusso multimediale all'elemento HTML localStream = stream; // e memorizzalo in una variabile globale per un ulteriore utilizzo)
Il terzo parametro è una funzione di callback, un gestore di errori che verrà chiamato in caso di errore.
Funzione getUserMedia_error(errore) ( console.log("getUserMedia_error():", errore); )
La chiamata effettiva al metodo getUserMedia, che richiede l'accesso al microfono e alla videocamera 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 nel browser e, in risposta alla richiesta che appare, consentiamo l'accesso alla telecamera e al microfono.
Puoi selezionare a quali dispositivi Chrome accederà in Impostazioni, link Mostra impostazioni avanzate, sezione Privacy, pulsante Contenuto. IN Browser Firefox e i dispositivi Opera vengono selezionati dall'elenco a discesa direttamente quando l'accesso è consentito.
Quando si utilizza il protocollo HTTP, l'autorizzazione verrà richiesta ogni volta che si accede a un flusso multimediale dopo il caricamento della pagina. 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 sulla scheda e all'icona della fotocamera sul lato destro della barra degli indirizzi:
RTCMediaConnectionRTCMediaConnection: un oggetto progettato per stabilire e trasferire flussi multimediali sulla rete tra i partecipanti. Inoltre, questo oggetto è responsabile della generazione di una descrizione della sessione multimediale (SDP), dell'ottenimento di informazioni sui candidati ICE per il passaggio attraverso NAT o firewall (locali e utilizzando STUN) e dell'interazione con il server TURN. Ogni partecipante deve disporre di un RTCMediaConnection per connessione. I flussi multimediali vengono trasmessi tramite il protocollo SRTP crittografato.
TURN serverEsistono tre tipi di candidati ICE: host, srflx e relay. L'host contiene informazioni ottenute localmente, srflx è l'aspetto dell'host su un server esterno (STUN) e relay è l'informazione per il proxy del traffico attraverso il server TURN. Se il nostro nodo è dietro un NAT, i candidati host conterranno indirizzi locali e saranno inutili, i candidati srflx aiuteranno solo con determinati tipi di NAT e il relay sarà l'ultima speranza per far 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 generazione host typ 0
Formato generale per specificare i server STUN/TURN:
Var server = ( "iceServers": [ ("url": "stun:stun.stunprotocol.org:3478" ), ( "url": "turn: [e-mail protetta]:port", "credential": "password" ) ]);
Ci sono molti server STUN pubblici su Internet. Un elenco lungo, ad esempio, è . Sfortunatamente, risolvono troppo pochi dei problemi. Non ci sono praticamente server TURN pubblici, a differenza di STUN. Ciò è dovuto al fatto che il server TURN trasmette 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 (ovviamente, avrai bisogno di un IP pubblico). Di tutti i server, secondo me, il migliore è rfc5766-turn-server . Sotto c'è persino un'immagine già pronta per Amazon EC2.
Con TURN, non tutto va bene come vorremmo, ma è in corso uno sviluppo attivo e spero che dopo qualche tempo WebRTC, se non raggiunge Skype in termini di qualità del passaggio attraverso la traduzione degli indirizzi ( NAT) e firewall, almeno si avvicinano notevolmente.
RTCMediaConnection necessita di un meccanismo aggiuntivo per lo scambio di informazioni di controllo per stabilire una connessione: sebbene generi questi dati, non li trasmette e la trasmissione da parte di altri partecipanti deve essere implementata separatamente.
La scelta del metodo di trasmissione è responsabilità dello sviluppatore, almeno manualmente. Non appena i dati necessari vengono scambiati, RTCMediaConnection imposterà automaticamente i flussi multimediali (se possibile, ovviamente).
modello offerta-rispostaPer stabilire e modificare i flussi multimediali, vengono utilizzati il modello di offerta / risposta (offerta / risposta; descritto in RFC3264) e il protocollo SDP (Session Description Protocol). Sono utilizzati anche dal protocollo SIP. In questo modello si distinguono due agenti: Offerente - colui che genera una descrizione di sessione SDP per crearne una nuova o modificarne una esistente (Offer SDP), e Risponditore - colui che riceve una descrizione di sessione SDP da un altro agente e risponde a con la propria descrizione della sessione (Risposta SDP). Allo stesso tempo, la specifica richiede un protocollo di livello superiore (ad esempio, SIP o il proprio over web socket, come nel nostro caso), che è responsabile del trasferimento SDP tra gli agenti.
Quali dati devono essere passati tra due RTCMediaConnection in modo che possano stabilire correttamente i flussi multimediali:
Offerta Formazione Per formare un'offerta, abbiamo bisogno di due funzioni. Il primo sarà chiamato in caso di formazione riuscita. Il secondo parametro del metodo createOffer() è una funzione di callback chiamata in caso di errore durante la sua esecuzione (a condizione che filo locale 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'altro lato. Torniamo al nostro fascicolo. Aggiungiamone un altro all'HTML dopo le righe con gli elementi:
creareOfferta
E dopo la riga con l'elemento (per il futuro):
Inoltre, all'inizio del codice JavaScript, dichiareremo una variabile globale per RTCPeerConnection:
varpc1;
Quando si chiama il costruttore RTCPeerConnection, è necessario specificare i server STUN/TURN. Vedere la barra laterale per maggiori dettagli; fintanto che tutti i partecipanti si trovano sulla stessa rete, non sono richiesti.
var server = null;
Opzioni per Provisioning Offerta SDP
var offerConstraints = ();
Il primo parametro del metodo createOffer() è una funzione di callback richiamata dopo la corretta formazione di un'Offerta
Funzione pc1_createOffer_success(desc) ( console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:", desc); pc1.setLocalDescription(desc); // Imposta la RTCPeerConnection generata dal Offer SDP metodo setLocalDescription. // Quando il lato remoto invia il suo SDP di risposta, dovrà essere impostato utilizzando il metodo setRemoteDescription // Fino a quando il secondo lato non sarà implementato, non fare nulla // pc2_receivedOffer(desc); )
Il secondo parametro è una funzione di callback che verrà chiamata in caso di errore
Funzione pc1_createOffer_error(errore)( console.log("pc1_createOffer_success_error(): errore:", errore); )
E dichiareremo una funzione di callback che verrà passata ai candidati ICE così come sono definiti:
Function pc1_onicecandidate(event)( if (event.candidate) ( console.log("pc1_onicecandidate():\n"+ event.candidate.candidate.replace("\r\n", ""), event.candidate); // Non fare nulla finché non viene implementato il secondo lato // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )
Oltre a una funzione di callback per aggiungere un flusso multimediale dall'altro lato (per il futuro, poiché finora abbiamo solo un RTCPeerConnection):
Funzione pc1_onaddstream(event) ( console.log("pc_onaddstream()"); remoteVideo1.src = URL.createObjectURL(event.stream); )
Quando fai clic sul pulsante "createOffer", crea una RTCPeerConnection, imposta i metodi onicecandidate e onaddstream e richiedi la formazione di un Offer SDP chiamando il metodo createOffer():
Funzione createOffer_click() ( console.log("createOffer_click()"); pc1 = new webkitRTCPeerConnection(servers); // Crea una RTCPeerConnection pc1.onicecandidate = pc1_onicecandidate; // Funzione di richiamata per elaborare i candidati ICE pc1.onaddstream = pc1_onaddstream; / / Funzione di callback chiamata quando c'è un flusso multimediale dall'altro lato, non esiste ancora pc1.addStream(localStream); // Passa il flusso multimediale locale (supponendo che sia già stato ricevuto) pc1.createOffer(// E in realtà richiedere la formazione dell'Offerta 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 verrà ancora visualizzato, in quanto vi è un solo partecipante. Ricordiamo che SDP è una descrizione dei parametri della sessione multimediale, codec disponibili, flussi multimediali e candidati ICE sono possibili opzioni per la connessione a questo partecipante.
Formazione di Answer SDP e scambio di candidati ICESia l'Offer 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'Offer SDP e addIceCandidate per ogni candidato ICE ricevuto dall'altro lato; allo stesso modo al contrario per Answer SDP e candidati ICE remoti. La stessa Answer SDP è formata in modo analogo all'Offerta; la differenza è che non viene chiamato il metodo createOffer, ma il metodo createAnswer e, prima di questo RTCPeerConnection, il metodo setRemoteDescription passa l'Offer SDP ricevuto dal chiamante.
Aggiungiamo un altro elemento video all'HTML:
E una variabile globale per il secondo RTCPeerConnection sotto la dichiarazione del primo:
Varpc2;
Elaborazione offerta e risposta SDPFormare una risposta SDP è molto simile a un'offerta. Nella funzione di richiamata richiamata dopo la corretta formazione della risposta, analogamente all'offerta, forniremo una descrizione locale e passeremo 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 generazione della risposta è del tutto simile all'offerta:
Funzione pc2_createAnswer_error(errore) ( console.log("pc2_createAnswer_error():", errore); )
Parametri per la generazione di Answer SDP:
Var answerConstraints = ("mandatory": ("OfferToReceiveAudio":true, "OfferToReceiveVideo":true ) );
Quando il secondo partecipante riceve un'Offerta, crea una RTCPeerConnection e forma una Risposta allo stesso modo dell'Offerta:
Funzione pc2_receivedOffer(desc) ( console.log("pc2_receiveOffer()", desc); // Crea un oggetto RTCPeerConnection per il secondo partecipante simile al primo pc2 = new webkitRTCPeerConnection(servers); pc2.onicecandidate = pc2_onicecandidate; // Imposta il gestore dell'evento quando il candidato ICE pc2.onaddstream = pc_onaddstream; // Quando viene visualizzato un flusso, collegalo all'HTML pc2.addStream(localStream); // Passa il flusso multimediale locale (nel nostro esempio, il secondo partecipante ha lo stesso flusso come il primo) // Ora, quando il secondo RTCPeerConnection è pronto, passagli l'Offer SDP ricevuto (abbiamo passato il flusso locale al primo) pc2.setRemoteDescription(new RTCSessionDescription(desc)); // Chiedi al secondo connessione per generare i dati per il messaggio di risposta pc2.createAnswer(pc2_createAnswer_success, pc2_createAnswer_error, answerConstraints); )
Per trasferire l'Offerta SDP dal primo partecipante al secondo, come parte del nostro esempio, decommentare nella funzione pc1 creareOfferta success() stringa di chiamata:
Pc2_receivedOffer(desc);
Per implementare l'elaborazione dei candidati ICE, decommentare nel gestore dell'evento di prontezza del candidato ICE del primo partecipante pc1_onicecandidate() la sua trasmissione al secondo:
Pc2.addIceCandidate(new RTCIceCandidate(event.candidate));
Il gestore dell'evento di prontezza del candidato ICE del secondo partecipante è simile al primo:
Funzione pc2_onicecandidate(event) ( if (event.candidate) ( console.log("pc2_onicecandidate():", event.candidate.candidate); pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )
Funzione di richiamata 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 una connessioneAggiungiamo un altro pulsante in HTML
appendere
E una funzione per terminare la connessione
Function btnHangupClick() ( // Disconnette il video locale dagli elementi HTML, interrompe il flusso multimediale locale, set = null localVideo1.src = ""; localStream.stop(); localStream = null; // Per ogni partecipante, disabilita il video dagli elementi HTML , chiudi connessione, imposta puntatore = null remoteVideo1.src = ""; pc1.close(); pc1 = null; remoteVideo2.src = ""; pc2.close(); pc2 = null; )
Salviamolo come rtctest3.html, mettiamolo sul server e apriamolo nel browser. Questo esempio implementa lo streaming multimediale bidirezionale tra due RTCPeerConnection all'interno della stessa scheda del browser. Per organizzare lo scambio di offerte e risposte SDP, candidati ICE tra i partecipanti e altre informazioni attraverso la rete, sarà necessario implementare lo scambio tra i partecipanti utilizzando un qualche tipo di trasporto, nel nostro caso, web socket, invece di una chiamata diretta a procedure.
Trasmissione dello schermoCon la funzione getUserMedia, puoi anche acquisire lo schermo e trasmetterlo in streaming come MediaStream specificando i seguenti parametri:
Var mediaStreamConstraints = ( audio: false, video: ( obbligatorio: ( chromeMediaSource: "screen" ), facoltativo: ) );
Per accedere correttamente allo schermo, devono essere soddisfatte diverse condizioni:
Sebbene WebRTC non sia ancora completo, sono già apparse 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.ioPer 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 aggiornamento apt-get$ 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
Usando npm (Node Package Manager) installa socket.io e modulo aggiuntivo esprimere:
$ npm installa socket.io express
Controlliamo creando un file nodetest2.js 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 è libera app.get("/", function (req, res) ( // Quando si accede alla pagina principale res.sendfile(__dirname + "/nodetest2.html"); // fornire il file HTML ) ); io.sockets.on("connessione", funzione (socket) ( // Alla connessione 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 var socket = io.connect("/"); // URL del server web socket (pagina principale del server da cui è stata caricata la pagina) socket.on("evento server", funzione (dati) ( console.log(data); socket.emit("evento client" , ( " nome": "valore" )); ));
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 quando connesso.
Scambio di informazioni tra RTCPeerConnection tramite web socket lato clientSalviamo il nostro esempio principale (rtcdemo3.html) con il nuovo nome rtcdemo4.html. Includi la libreria socket.io nell'elemento:
E all'inizio dello script JavaScript - connessione web socket:
var socket = io.connect("http://localhost");
Sostituiamo una chiamata diretta alle funzioni di un altro partecipante inviandogli un messaggio tramite web socket:
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); .. . ) funzione 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, invieremo un messaggio tramite web socket:
Funzione btnHangupClick() ( ... // remoteVideo2.src = ""; pc2.close(); pc2 = null; socket.emit("hangup", ()); )
E aggiungi i gestori di ricezione dei messaggi:
Socket.on("offer", function (data) ( console.log("socket.on("offer"):", data); pc2_receivedOffer(data); )); socket.on("answer", function (data) (e console.log("socket.on("answer"):", data); pc1.setRemoteDescription(new RTCSessionDescription(data)); )); socket.on("ice1", function (data) ( console.log("socket.on("ice1"):", data); pc2.addIceCandidate(new RTCIceCandidate(data)); )); socket.on("ice2", funzione (dati) ( console.log("socket.on("ice2"):", dati); pc1.addIceCandidate(new RTCIceCandidate(data)); )); socket.on("hangup", function (data) ( console.log("socket.on("hangup")):", data); remoteVideo2.src = ""; pc2.close(); pc2 = null; ));
Parte serverSul lato server, salva il file nodetest2 con il nuovo nome rtctest4.js e all'interno della funzione io.sockets.on("connection", function (socket) ( ... ) aggiungi la ricezione e l'invio di messaggi client:
Socket.on("offer", function (data) ( // Quando viene ricevuto un messaggio "offer", // poiché la connessione client in questo esempio solo uno, // invia un messaggio indietro tramite lo stesso socket socket.emit("offer", data); // Se fosse necessario inoltrare il messaggio su tutte le connessioni // tranne il mittente: // socket.broadcast.emit("offer", data); )); socket.on("risposta", funzione (dati) ( socket.emit("risposta", dati); )); socket.on("ice1", funzione (dati) ( socket.emit("ice1", dati); )); socket.on("ice2", funzione (dati) ( socket.emit("ice2", dati); )); socket.on("hangup", function (data) ( socket.emit("hangup", data); ));
Inoltre, cambia il nome del file HTML:
// res.sendfile(__dirname + "/nodetest2.html"); // Invia il file HTML res.sendfile(__dirname + "/rtctest4.html");
Avvio server:
$ sudo nodejs nodetest2.js
Nonostante il codice di entrambi i client venga eseguito all'interno della stessa scheda del browser, tutte le interazioni tra i partecipanti nel nostro esempio vengono eseguite completamente attraverso la rete e non è più difficile "diffondere" i partecipanti. Tuttavia, ciò che abbiamo fatto è stato anche molto semplice: queste tecnologie sono utili per la loro facilità d'uso. Anche se a volte ingannevole. In particolare, non dimentichiamo che senza server STUN/TURN, il nostro esempio non potrà funzionare in presenza di traduzione indirizzi e firewall.
ConclusioneL'esempio risultante è molto condizionale, ma se universalizziamo leggermente i gestori di eventi in modo che non differiscano tra la parte chiamante e quella chiamata, invece di due oggetti pc1 e pc2, creiamo un array di RTCPeerConnection e implementiamo creazione dinamica ed eliminando elementi, ottieni una chat video completamente utilizzabile. Questo non è più specifico di WebRTC e un esempio della video chat più semplice per più partecipanti (così come i testi di tutti gli esempi dell'articolo) si trova sul disco fornito con la rivista. Tuttavia, ci sono già molti buoni esempi su Internet. In particolare, durante la preparazione dell'articolo, sono stati utilizzati: simpl.info getUserMedia , simpl.info RTCPeerConnection , WebRTC Reference App .
Si può presumere che molto presto, grazie a WebRTC, ci sarà una rivoluzione non solo nella nostra comprensione delle comunicazioni vocali e video, ma anche nel modo in cui percepiamo Internet nel suo insieme. WebRTC si posiziona non solo come tecnologia di chiamata da browser a browser, ma anche come tecnologia di comunicazione in tempo reale. Il link video che abbiamo analizzato ne è solo una piccola parte. opzioni il suo utilizzo. Esistono già esempi di condivisione dello schermo (condivisione dello schermo) e collaborazione e persino una rete di distribuzione di contenuti P2P basata su browser che utilizza RTCDataChannel.
Oggi, WebRTC è la tecnologia "calda" 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, consentendo agli spettatori di vedere cosa sta succedendo "dal vivo".
La possibilità di una comunicazione in tempo reale di alta qualità deriva dall'architettura WebRTC stessa, in cui i flussi video vengono trasportati utilizzando Protocollo UDP, che è una base standard per la trasmissione video con ritardi minimi ed è ampiamente utilizzata nei sistemi di comunicazione in tempo reale.
La latenza della comunicazione è importante nei sistemi di live streaming, webinar e altre applicazioni in cui è richiesta una comunicazione interattiva con la sorgente video, gli utenti finali e la soluzione.
Un altro buon motivo per provare WebRTC è sicuramente una tendenza. Oggi tutti AndroidChrome il browser supporta questa tecnologia, che garantisce che milioni di dispositivi siano pronti a guardare la trasmissione senza installare software e configurazioni aggiuntivi.
Per testare la tecnologia WebRTC in azione e lanciare una semplice trasmissione online su di essa, abbiamo utilizzato il software server Flashphoner WebRTC Media & Broadcasting Server. Le funzionalità dichiarano la possibilità di trasmettere flussi WebRTC in modalità uno-a-molti, nonché il supporto per telecamere IP e sistemi di videosorveglianza tramite il protocollo RTSP; in questa recensione, ci concentreremo sulle trasmissioni web-web e sulle loro caratteristiche.
Installazione di WebRTC Media & Broadcasting ServerPerchè per Sistemi Windows non esisteva una versione server e non volevo installare una macchina virtuale come VMWare + Linux, testare le trasmissioni online a casa Computer Windows Non ha funzionato. Per risparmiare tempo, abbiamo deciso di prendere un'istanza su cloud hosting come questa:
Era un Centos x86_64 versione 6.5 senza alcun software preinstallato in un data center di Amsterdam. Pertanto, tutto ciò che abbiamo a nostra disposizione è un server e l'accesso ssh ad esso. Per coloro che hanno familiarità con comandi della console Linux, l'installazione di un server WebRTC promette di essere facile e indolore. Quindi cosa abbiamo fatto:
1. Scarica l'archivio:
$wget https://sitoweb/download-wcs5-server.tar.gz
2. Disimballare:
$tar -xzf download-wcs5-server.tar.gz
3. Installa:
$cd FlashphonerWebCallServer
Durante l'installazione, inserire l'indirizzo IP del server: XXX.XXX.XXX.XXX
4. Attiva la licenza:
$cd /usr/local/FlashphonerWebCallServer/bin
$./attivazione.sh
5. Avviare il server WCS:
Avvio di $service webcallserver
6. Controlla il registro:
$tail - f /usr/local/FlashphonerWebCallServer/logs/flashphoner_manager.log
7. Verificare che siano presenti due processi:
$ps ausiliario | grep Flashphone
Il processo di installazione è completo.
Testare i live streaming WebRTCTestare le trasmissioni si è rivelato una cosa semplice. Oltre al server, c'è un client web, che consiste in una dozzina di file Javascript, HTML e CSS ed è stato distribuito da noi nella cartella /var/www/html durante la fase di installazione. L'unica cosa che doveva essere fatta 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 index.html del client di prova in Browser Chrome e:
2. Per avviare la trasmissione, è necessario fare clic sul pulsante "Avvia" al centro dello schermo.
Prima di fare ciò, devi assicurarti che la webcam sia connessa e pronta per funzionare. Non ci sono requisiti speciali per una webcam, ad esempio, abbiamo utilizzato una fotocamera standard per laptop integrata con una risoluzione di 1280 × 800.
Il browser Chrome chiederà sicuramente l'accesso alla videocamera e al microfono in modo che l'utente capisca che il suo video verrà inviato al server Internet e gli consenta di farlo.
3. L'interfaccia è una traduzione riuscita del flusso video dalla telecamera al server WebRTC. Nell'angolo in alto a destra, l'indicatore indica che lo streaming sta andando al server, nell'angolo in basso c'è un pulsante "Stop" per interrompere l'invio del video.
Dai un'occhiata al link qui sotto. Contiene un identificatore univoco per questo flusso, quindi chiunque può unirsi alla vista. Basta aprire questo collegamento in un browser. Per copiarlo negli appunti, è necessario fare clic sul pulsante "Copia".
In applicazioni reali come webinar, conferenze, trasmissioni video online o TV interattive, gli sviluppatori dovranno implementare la distribuzione di questo identificatore a determinati gruppi di spettatori in modo che possano connettersi ai flussi desiderati, ma questa è la logica dell'applicazione. WebRTC Media & Broadcasting Server non lo influenza, ma distribuisce solo video.
5. La connessione viene stabilita e lo spettatore vede lo streaming sullo schermo. Ora può inviare il collegamento a qualcun altro, interrompere la riproduzione in streaming o abilitare la modalità a schermo intero utilizzando i controlli nell'angolo in basso a destra.
Durante i test, la latenza sembrava essere perfetta. Il ping al data center era di circa 100 millisecondi e il ritardo non era visibile a occhio nudo. Da qui, possiamo supporre che il ritardo reale sia lo stesso 100 più o meno qualche decina di millisecondi per il tempo di buffering. Rispetto al video Flash, Flash non si comporta bene come WebRTC in questi test. 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 puoi distinguere i cubi sui movimenti. Ciò è in linea con la natura del codec VP8 e il suo obiettivo principale è fornire comunicazioni video in tempo reale con una qualità accettabile e senza ritardi di comunicazione.
Il server è abbastanza facile da installare e configurare, non richiede competenze serie per eseguirlo, ad eccezione della conoscenza di Linux a livello di utente avanzato che può eseguire comandi dalla console tramite ssh e utilizzare editor di testo. Di conseguenza, siamo riusciti a impostare una trasmissione online uno-a-molti tra i browser. Anche il collegamento di altri visualizzatori allo stream non ha causato problemi.
La qualità della trasmissione si è rivelata abbastanza accettabile per webinar e trasmissioni online. L'unica cosa che ha causato alcune domande è stata la risoluzione del video. La fotocamera supporta 1280x800, ma la risoluzione dell'immagine di prova è molto simile a 640x480. Apparentemente, questo problema deve essere chiarito con gli sviluppatori.
Video sui test trasmessi da una webcam
