Syftet med den här artikeln är att bekanta dig med dess struktur och funktionsprincip på ett demoprov av en peer-to-peer videochatt (p2p videochatt). För detta ändamål kommer vi att använda peer-to-peer videochattdemon för flera användare webrtc.io-demo. Den kan laddas ner från länken: https://github.com/webRTC/webrtc.io-demo/tree/master/site .
Det bör noteras att GitHub är en webbplats eller webbtjänst för gemensam utveckling av webbprojekt. På den kan utvecklare lägga upp koder för sin utveckling, diskutera dem och kommunicera med varandra. Dessutom har vissa stora IT-företag sina officiella arkiv på den här webbplatsen. Tjänsten är gratis för projekt med öppen källkod. källkod. GitHub är ett arkiv med öppen källkodsbibliotek.
Så, laddat ner från GitHub ett demoprov av en peer-to-peer videochatt, vi kommer att placera den på disk C personlig dator i den skapade katalogen för vår applikation "webrtc_demo".
Ris. 1
Som följer av strukturen (fig. 1) består peer-to-peer-videochatt av klientscript.js och server.js-skript implementerade på språket JavaScript-programmering. Skript (bibliotek) webrtc.io.js (KLIENT) - tillhandahåller organisation av realtidskommunikation mellan webbläsare enligt ett peer-to-peer-schema: "klient-klient", och webrtc.io.js (KLIENT) och webrtc .io.js (SERVER), med hjälp av WebSocket-protokollet, tillhandahåller de duplexkommunikation mellan webbläsaren och webbservern med hjälp av "klient-server"-arkitekturen.
Skriptet webrtc.io.js (SERVER) ingår i webrtc.io-biblioteket och finns i katalogen node_modules\webrtc.io\lib. Videochattgränssnittet index.html är implementerat i HTML5 och CSS3. Innehållet i webrtc_demo-applikationsfilerna kan ses med en av html-redigerarna, till exempel "Anteckningar++".
Vi kommer att kontrollera principen för videochattdrift i filsystem PC. För att köra servern (server.js) på en PC måste du installera node.js runtime. Node.js låter dig köra JavaScript-kod utanför webbläsaren. Du kan ladda ner node.js från länken: http://nodejs.org/ (version v0.10.13 den 15/07/13). På node.orgs huvudsida klickar du på nedladdningsknappen och går till http://nodejs.org/download/. För Windows-användare ladda först ner win.installer (.msi), kör sedan win.installer (.msi) på PC och installera nodejs och "npm package manager" i Program Files-katalogen.
Ris. 2
Således består node.js av en JavaScript-utvecklings- och exekveringsmiljö, samt en uppsättning interna moduler som kan installeras med hjälp av npm-pakethanteraren eller pakethanteraren.
För att installera moduler måste du kommandorad från programkatalogen (till exempel "webrtc_demo") kör kommandot: npm install module_name . Under installationen av moduler skapar npm-hanteraren en node_modules-mapp i katalogen från vilken installationen utfördes. När den körs inkluderar nodejs automatiskt moduler från katalogen node_modules.
Så, efter att ha installerat node.js, öppna kommandoraden och uppdatera expressmodulen i mappen node_modules i webrtc_demo-katalogen med hjälp av npm-pakethanteraren:
C:\webrtc_demo>npm installera express
Expressmodulen är ett webbramverk för node.js ellerform. För att ha global åtkomst till express kan du installera det så här: npm install -g express .
Sedan uppdaterar vi webrtc.io-modulen:
C:\webrtc_demo>npm installera webrtc.io
Sedan, på kommandoraden, startar vi servern: server.js:
C:\webrtc_demo>nodeserver.js
Ris. 3
Allt, servern fungerar framgångsrikt (Figur 3). Nu, med hjälp av en webbläsare, kan du kontakta servern via ip-adress och ladda ner webbsidan index.html, från vilken webbläsaren kommer att extrahera klientskriptkoden - script.js och webrtc.io.js skriptkoden, och avrätta dem. För att en peer-to-peer videochatt ska fungera (för att upprätta en anslutning mellan två webbläsare) är det nödvändigt från två webbläsare som stöder webrtc för att kontakta signalservern som körs på node.js via ip-adress.
Som ett resultat kommer gränssnittet för klientdelen av kommunikationsapplikationen (videochatt) att öppnas med en begäran om tillstånd att komma åt kameran och mikrofonen (fig. 4).
Ris. 4
Efter att ha klickat på "Tillåt"-knappen ansluts kameran och mikrofonen för multimediakommunikation. Genom videochattgränssnittet kan du dessutom kommunicera med textdata (fig. 5).
Ris. 5
Det bör nämnas att . Servern signalerar och är huvudsakligen utformad för att upprätta en anslutning mellan användarnas webbläsare. Server.js-skriptet som tillhandahåller WebRTC-signalering använder Node.js för att köras.
WebRTC är ett webbläsarförsett API som låter dig organisera en P2P-anslutning och överföra data direkt mellan webbläsare. Det finns en hel del tutorials på Internet om hur du skriver din egen videochatt med WebRTC. Här är till exempel en artikel om Habré. De är dock alla begränsade till att ansluta två klienter. I den här artikeln kommer jag att försöka prata om hur man organiserar en anslutning och utbyte av meddelanden mellan tre eller flera användare med WebRTC.
RTCPeerConnection-gränssnittet är en peer-to-peer-anslutning mellan två webbläsare. För att ansluta tre eller fler användare måste vi organisera ett mesh-nätverk (ett nätverk där varje nod är ansluten till alla andra noder).
Vi kommer att använda följande schema:
Som ni vet, även om WebRTC ger möjlighet till P2P-anslutning mellan webbläsare, kräver det fortfarande en extra transport för utbyte av tjänstmeddelanden. I det här exemplet är transporten en WebSocket-server skriven i Node.JS med socket.io:
var socket_io = require("socket.io"); module.exports = function (server) ( var users = (); var io = socket_io(server); io.on("connection", function(socket) ( // Vill att en ny användare ska gå med i rummet socket.on( "rum", function(meddelande) ( var json = JSON. parse(meddelande); // Lägg till socket i listan över användare användare = socket; if (socket.room !== odefinierat) ( // Om socket är redan i något rum , lämna det socket.leave(socket.room); ) // Ange det begärda rummet socket.room = json.room; socket.join(socket.room); socket.user_id = json.id; // Skicka till andra kunder detta rum har ett meddelande om att gå med i en ny deltagare socket.broadcast.to(socket.room).emit("new", json.id); )); // WebRTC-relaterat meddelande (SDP-erbjudande, SDP-svar eller ICE-kandidat) socket.on("webrtc", function(meddelande) ( var json = JSON.parse(meddelande); if (json.to !== odefinierade && användare !== odefinierade) ( // Om meddelandet har en mottagare och denna mottagare som servern känner till, skickar vi ett meddelande endast till honom... users.emit("webrtc", meddelande); ) else ( // ...annars betrakta meddelandet som en broadcast-socket.broadcast.to(socket.room).emit("webrtc", meddelande); ) )); // Någon frånkopplade socket.on("disconnect", function() ( // När en klient kopplar från, meddela andra socket.broadcast.to(socket.room).emit("leave", socket.user_id); ta bort användare; )); )); );
1. index.htmlKällkoden för själva sidan är ganska enkel. Jag uppmärksammade medvetet inte layout och andra vackra saker, eftersom den här artikeln inte handlar om det. Om någon vill göra henne vacker blir det inte svårt.
WebRTC Chat Demo Ansluten till 0 kamrater
skicka
Vi måste fortfarande använda webbläsarprefix för att komma åt WebRTC-gränssnitt.
Var PeerConnection = window.mozRTCPeerConnection || window.webkitRTCPeerConnection; var SessionDescription = window.mozRTCSessionDescription || window.RTCSessionDescription; var IceCandidate = window.mozRTCIceCandidate || window.RTCIceCandidate;
2.1. Fastställande av rums-IDHär behöver vi en funktion för att generera ett unikt rum och användar-ID. Vi kommer att använda UUID för detta ändamål.
Funktion uuid () ( var s4 = function() ( return Math.floor(Math.random() * 0x10000).toString(16); ); return s4() + s4() + "-" + s4() + "-" + s4() + "-" + s4() + "-" + s4() + s4() + s4(); )
Låt oss nu försöka extrahera rums-ID från adressen. Om detta inte är inställt kommer vi att skapa en ny. Vi kommer att visa en länk till det aktuella rummet på sidan, och samtidigt genererar vi en identifierare för den aktuella användaren.
VarROOM = location.hash.substr(1); if (!ROOM) ( ROOM = uuid(); ) room_link.innerHTML = "Länka till rummet"; varME = uuid();
2.2. webbuttagOmedelbart efter att sidan öppnas kommer vi att ansluta till vår signalserver, skicka en begäran om att komma in i rummet och ange meddelandehanterare.
// Vi specificerar att när meddelandet stängs måste vi skicka ett meddelande till servern om denna var socket = io.connect("", ("sync disconnect on unload": true)); socket.on("webrtc", socketReceived); socket.on("ny", socketNewPeer); // Skicka omedelbart en begäran om att komma in i rummet socket.emit("rum", JSON.stringify((id: MIG, rum: ROOM))); // Hjälparfunktion för att skicka riktade meddelanden relaterade till WebRTC-funktionen sendViaSocket(typ, meddelande, till) ( socket.emit("webrtc", JSON.stringify((id: MIG, till: till, typ: typ, data: meddelande))); )
2.3. Inställningar för peer-anslutningDe flesta internetleverantörer tillhandahåller Internetanslutning via NAT. På grund av detta blir en direkt koppling inte så trivial. När vi skapar en anslutning måste vi ange en lista över STUN- och TURN-servrar som webbläsaren kommer att försöka använda för att kringgå NAT. Vi anger också ett par ytterligare alternativ att ansluta.
Var server = ( iceServers: [ (url: "stun:23.21.150.121"), (url: "stun:stun.l.google.com:19302"), (url: "turn:numb.viagenie.ca", credential: "ditt lösenord går hit", användarnamn: " [e-postskyddad]") ] ); var options = ( valfritt: [ (DtlsSrtpKeyAgreement: true), // krävs för anslutning mellan Chrome och Firefox (RtpDataChannels: true) // krävs i Firefox för att använda DataChannels API ] )
2.4. Ansluter en ny användareNär en ny peer läggs till i rummet skickar servern ett nytt meddelande till oss. Enligt meddelandehanterarna ovan kommer socketNewPeer-funktionen att anropas.
var jämnåriga = (); function socketNewPeer(data) ( peers = (candidateCache: ); // Skapa en ny anslutning var pc = new PeerConnection(server, optioner); // Initiera den initConnection(pc, data, "erbjudande"); // Lagra peeren i listan peers peers.connection = pc; // Skapa en DataChannel genom vilken meddelanden kommer att utbytas var channel = pc.createDataChannel("mychannel", ()); channel.owner = data; peers.channel = channel; // Installera händelsehanterare bindEvents(kanal); // Skapa ett SDP-erbjudande pc.createOffer(function(offer) ( pc.setLocalDescription(offer); )); ) function initConnection(pc, id, sdpType) ( pc.onicecandidate = function ( event) ( if (event.candidate) ( // När en ny ICE-kandidat hittas, lägg till den i listan för vidare sändning av peers.candidateCache.push(event.candidate); ) else ( // När upptäckten av kandidater är avslutad, kommer hanteraren att anropas igen, men utan kandidat // I det här fallet skickar vi till peeren ett SDP-erbjudande eller ett SDP-svar först (beroende på funktionsparametern)... sendViaSocket(sdpType, pc.localDescription, id) ; // ...och sedan alla tidigare hittade ICE-kandidater för (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. SDP-erbjudande, SDP-svar, ICE-kandidatNär ett av dessa meddelanden tas emot anropar vi motsvarande meddelandehanterare.
Funktion 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 "answer": remoteAnswerReceived(json.id, json.data); break; ) )
2.5.0 SDP erbjuder funktion remoteOfferReceived(id, data) ( createConnection(id); var pc = peers.connection; pc.setRemoteDescription(new SessionDescription(data)); pc.createAnswer(function(answer) ( pc.setLocalDescription(answer) ); )); ) funktion createConnection(id) ( if (peers === odefinierad) ( peers = (candidateCache: ); var pc = new PeerConnection(server, alternativ); initConnection(pc, id, "svar"); peers.connection = pc; pc.ondatachannel = function(e) ( peers.channel = e.channel; peers.channel.owner = id; bindEvents(peers.channel); ) ) ) 2.5.1 SDP svarsfunktion remoteAnswerReceived(id , data) ( var pc = peers.connection; pc.setRemoteDescription(new SessionDescription(data)); ) 2.5.2 ICE-kandidatfunktion remoteCandidateReceived(id, data) ( createConnection(id); var pc = peers.connection; pc. addIceCandidate(ny IceCandidate(data)); ) 2.6. Skickar ett meddelandeNär du klickar på knappen Skicka anropas sendMessage-funktionen. Allt det gör är att gå igenom listan över kamrater och försöka skicka det angivna meddelandet till alla.
Inledning. P2P-videochatt baserad på WebRTC är ett alternativ till Skype och andra kommunikationsmedel. Huvudelementen i p2p-videochatt baserad på WebRTC är en webbläsare och en kontaktserver. P2P-videochatt är peer-to-peer-videochatt där servern inte deltar i överföringen informationsflöden. Information överförs direkt mellan användarnas webbläsare (peerings) utan några ytterligare program. Förutom webbläsare använder p2p-videochatt kontaktservrar som är utformade för att registrera användare, lagra data om dem och ge växling mellan användare. Webbläsare som stöder de senaste WebRTC- och HTML5-teknikerna tillhandahåller direkta textmeddelanden och filer, samt ger röst- och videokommunikation över IP-nätverk.
Så, chattar, webbchatt, röst- och videochatt i webbgränssnittet, IMS, VoIP är tjänster som tillhandahåller onlinekommunikation via paketförmedlade sammansatta nätverk. Som regel kräver kommunikationstjänster antingen installation av klientapplikationer på användarenheter (datorer, smartphones etc.), eller installation av plugin-program och tillägg i webbläsare. Tjänsterna har sina egna kommunikationsnätverk, varav de flesta är byggda på en "klient-server"-arkitektur.
Kommunikationstjänster är applikationer, med undantag för IMS, där röst-, video-, data- och textkanaler inte är integrerade. I nätverken för varje tjänst, . Det bör noteras att dessa applikationer inte samtidigt kan fungera i flera kommunikationsnätverk, d.v.s. applikationer kan som regel inte interagera med varandra, vilket gör att en separat applikation måste installeras för varje kommunikationsnätverk.
Problemet med att integrera kommunikationstjänster i realtid (chatt, telefoni, videokonferenser), d.v.s. integration av röst-, video-, dataöverföringskanaler och åtkomst till dem med en applikation (webbläsare) kan lösas i peer-to-peer eller p2p videochatt (peer-to-peer, punkt-till-punkt) baserat på WebRTC-protokollet . Faktum är att en webbläsare som stöder WebRTC blir ett enda gränssnitt för alla användarenheter (datorer, smartphones, iPads, IP-telefoner, mobiltelefoner etc.) som arbetar med kommunikationstjänster.
Det är WebRTC som tillhandahåller implementering i webbläsaren av all teknik som tillhandahåller realtidskommunikation. Kärnan i p2p-videochatt är att multimedia- och textdata överförs direkt mellan användarnas webbläsare (fjärrpeering) utan deltagande av en server och ytterligare program. Således ger webbläsare inte bara tillgång till nästan alla informationsresurser Internet, som lagras på servrar, men som också blir ett sätt att få tillgång till alla realtidskommunikationstjänster och e-posttjänster ( röstbrevlåda, e-post, SMS, etc.)
Servrar (kontaktservrar) för p2p-videochatt är endast avsedda för att registrera användare, lagra data om användare och upprätta en anslutning (växling) mellan användarnas webbläsare. De första p2p-videochattarna implementerades med hjälp av flashteknik. Flash p2p videochatt används till exempel i sociala nätverk. Flash p2p videochatt tillhandahåller inte hög kvalitetöverföring av multimediadata. Dessutom, för att mata ut röst- och videoström från en mikrofon och en videokamera i p2p flash-videochatt, måste du installera en flash-plugin i en webbläsare.
Men den nya generationens telekommunikationstjänster inkluderar webbkommunikation, som endast använder webbläsare och kontaktservrar som stöder WebRTC-protokoll och HTML5-specifikationen för att kommunicera över Internet. Alla användarenheter (PC, iPad, smartphones, etc.) som är utrustade med en sådan webbläsare kan ge högkvalitativa röst- och videosamtal, samt överföra direkta textmeddelanden och filer.
Så den nya tekniken för webbkommunikation (p2p-chattar, videochattar) är WebRTC-protokollet. WebRTC tillsammans med HTML5, CSS3 och JavaScript låter dig skapa olika webbapplikationer. WebRT är designat för att organisera webbkommunikation (peer-to-peer-nätverk) i realtid med hjälp av en peer-to-peer-arkitektur. P2P-chattar baserade på WebRTC tillhandahåller filöverföring, såväl som text-, röst- och videokommunikation för användare över Internet med enbart webbläsare utan användning av externa tillägg och plugin-program i webbläsaren.
I p2p-chattar används servern endast för att upprätta en p2p-anslutning mellan två webbläsare. För att skapa klientdelen av en p2p-chatt baserad på WebRTC-protokollet används HTML5, CSS3 och JavaScript. Klientapplikationen kommunicerar med webbläsare via WebRTC API.
WebRTC implementeras av tre JavaScript API:er:
Webbläsare överför multimediadata med hjälp av SRTP-protokollet, som körs ovanpå UDP. Eftersom NAT skapar problem för webbläsare (klienter) bakom NAT-routrar som använder p2p-anslutningar över Internet, används STUN för att kringgå NAT-översättare. STUN är ett klient/server-protokoll som körs ovanpå UDP-transportprotokollet. I p2p-chattar används som regel en offentlig STUN-server, och informationen som tas emot från den används för en UDP-anslutning mellan två webbläsare om de ligger bakom NAT.
Exempel på implementering av WebRTC-applikationer (p2p-chattar, röst- och videowebbchattar):
1. Bistri P2P-videochatt (videochatt med ett klick, p2p-chatt), baserat på WebRTC, kan öppnas på Bistri. Bistri fungerar i webbläsaren utan att installera ytterligare program och plug-ins. Kärnan i arbetet är som följer: öppna en p2p-videochatt med den angivna länken, efter registrering i gränssnittet som öppnas, bjud in partners, välj sedan partnern som är online från listan över peer-klienter och klicka på "videosamtal " knapp.
Som ett resultat kommer MediaStream (getUserMedia) att fånga mikrofonen + webbkameran, och servern kommer att utbyta signaleringsmeddelanden med den valda partnern. Efter att signaleringsmeddelanden har utbytts skapar PeerConnection API kanaler för att överföra röst- och videoströmmar. Dessutom utför Bistri överföringen av snabbtextmeddelanden och filer. På fig. Figur 1 visar en skärmdump av Bistri p2p-videochattgränssnittet.
Ris. 1. P2P Videochatt Bistri
2. Twelephone (p2p videochatt, p2p chat, SIP Twelephone) är en klientapplikation baserad på HTML5 och WebRTC som låter dig ringa röst- och videosamtal, samt skicka direkta textmeddelanden, d.v.s. Twelephone inkluderar test p2p-chatt, videochatt och SIP Twelephone. Det bör noteras att Twelephone stöder SIP-protokollet och nu kan du ringa och ta emot röst- och videosamtal från SIP-telefoner med ditt Twitter-konto som telefonnummer. Dessutom kan textmeddelanden matas in med rösten genom mikrofonen, och röstigenkänningsprogrammet matar in text i raden "Skicka ett meddelande".
Twelephone är en webbläsarbaserad webbtelefoni Google Chrome, från och med version 25, utan ytterligare programvara. Twelephone designades av Chris Matthieu. Server del Twelephone är byggd ovanpå Node.js. Servern (kontaktservern) används endast för att upprätta en p2p-anslutning mellan två webbläsare eller WebRTC-klienter. Twelephone-appen har inte egna medel auktorisering, men fokuserade på att ansluta till ett konto ( konto) på Twitter.
På fig. Figur 2 visar en skärmdump av Twelephone p2p-videochattgränssnittet.
Ris. 2.P2P Twinphone
3. Grupp p2p videochatt Conversat.io är baserad på den senaste tekniken WebRTC och HTML5. Conversat-videochatten är baserad på SimpleWebRTC-biblioteket och är designad för att kommunicera med upp till 6 peer-klienter i ett rum (för kommunikation, ange namnet på det gemensamma rummet för peer-klienter på raden "Namnge konversationen"). P2P videochatt Conversat tillhandahåller kommunikationstjänster till användare utan att registrera sig på kontaktservern. På fig. Figur 3 visar en skärmdump av Conversat p2p-videochattgränssnittet.
Ris. 3. Gruppera P2P-videochatt Conversat.io
För att delta i WebRTC-baserade P2P-videochattar måste användare ha en webbläsare installerad som stöder WebRTC-protokollet och HTML5-specifikationen. För närvarande stöder webbläsarna Google Chrome, från och med version 25, och Mozilla Firefox Nightly WebRTC-protokollet och HTML5-specifikationen. WebRTC-applikationer är överlägsna Flash-applikationer när det gäller bild- och ljudöverföringskvalitet.
Tekniker för att ringa från webbläsaren har funnits i många år: Java, ActiveX, Adobe Flash... Under de senaste åren har det blivit tydligt att plugins och vänster virtuella maskiner de lyser inte med bekvämlighet (varför ska jag installera något alls?) och, viktigast av allt, säkerhet. Vad ska man göra? Det finns en utgång!
Fram till nyligen har flera protokoll använts i IP-nätverk för IP-telefoni eller video: SIP, det vanligaste protokollet som kommer från scenen, H.323 och MGCP, Jabber/Jingle (används i Gtalk), den halvöppna Adobe RTMP* och, naturligtvis, det stängda Skype. WebRTC-projektet, initierat av Google, försöker vända världen av IP och webbtelefoni genom att göra allt onödigt. datortelefoner inklusive Skype. WebRTC implementerar inte bara allt kommunikationsförmåga direkt inuti webbläsaren, som nu är installerad på nästan alla enheter, men samtidigt försöker den lösa en mer generell uppgift med kommunikation mellan webbläsaranvändare (utbyte av olika data, skärmcasting, samarbete med dokument och mycket mer).
WebRTC av en webbutvecklareUr en webbutvecklares synvinkel består WebRTC av två huvuddelar:
Vi kommer att ta reda på hur man organiserar den enklaste videochatt för flera spelare mellan webbläsare baserade på WebRTC med hjälp av webbuttag. Låt oss börja experimentera med Chrome/Chromium, som de mest avancerade webbläsarna när det gäller WebRTC, även om Firefox 22, som släpptes den 24 juni, nästan kom ikapp dem. Det måste sägas att standarden ännu inte har antagits, och API:t kan ändras från version till version. Alla exempel testades i Chromium 28. För enkelhetens skull kommer vi inte att övervaka kodens renhet och kompatibilitet över webbläsare.
mediaströmDen första och enklaste WebRTC-komponenten är MediaStream. Det ger webbläsaren tillgång till mediaströmmar från kameran och mikrofonen på den lokala datorn. I Chrome kräver detta att funktionen navigator.webkitGetUserMedia() anropas (eftersom standarden inte är klar ännu, alla funktioner kommer med ett prefix, och i Firefox kallas samma funktion navigator.mozGetUserMedia()). När den anropas kommer användaren att uppmanas att tillåta åtkomst till kameran och mikrofonen. Det kommer att vara möjligt att fortsätta samtalet först efter att användaren har gett sitt samtycke. Parametrarna för den nödvändiga mediaströmmen och två återuppringningsfunktioner skickas som parametrar till denna funktion: den första kommer att anropas vid lyckad åtkomst till kameran/mikrofonen, den andra - vid fel. Låt oss först skapa en HTML-fil rtctest1.html med en knapp och ett element:
WebRTC - första mötesvideo (höjd: 240px; bredd: 320px; kant: 1px fast grått; ) getUserMedia
Microsoft skulle inte vara Microsoft om det, som svar på Googles initiativ, inte omedelbart släppte sin egen inkompatibla anpassade variant som heter CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web. htm). Även om andelen IE, som redan är liten, fortsätter att minska, ger antalet Skype-användare Microsoft hopp om att pressa Google, och det kan antas att denna standard kommer att användas i webbläsaren. Skype-versioner. Google-standarden fokuserar främst på kommunikation från webbläsare till webbläsare; samtidigt förblir huvuddelen av rösttrafiken fortfarande i det normala telefonnät, och gateways mellan den och IP-nätverk behövs inte bara för enkel användning eller snabbare distribution, utan också som ett sätt att tjäna pengar som gör det möjligt Mer spelare för att utveckla dem. Utseendet på en annan standard kan inte bara leda till ett obehagligt behov för utvecklare att stödja två inkompatibla teknologier samtidigt, utan också i framtiden ge användaren ett bredare urval av möjliga funktioner och tillgängliga tekniska lösningar. Vänta och se.
Aktivera lokal trådInuti taggarna i vår HTML-fil kommer vi att deklarera en global variabel för mediaströmmen:
VarlocalStream = null;
Den första parametern i getUserMedia-metoden är att ange parametrarna för den begärda mediaströmmen - till exempel, aktivera helt enkelt ljud eller video:
Var streamConstraints = ( "audio": true, "video": true ); // Begär tillgång till både ljud och video
Eller ange ytterligare alternativ:
Var streamConstraints = ( "audio": true, "video": ( "obligatorisk": ( "maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5"), "valfritt": ) );
Den andra parametern till getUserMedia-metoden är att skicka en återuppringningsfunktion som kommer att anropas om den lyckas:
Funktion getUserMedia_success(stream) ( console.log("getUserMedia_success():", stream); localVideo1.src = URL.createObjectURL(stream); // Anslut mediaströmmen till HTML-elementet localStream = stream; // och lagra den i en global variabel för vidare användning)
Den tredje parametern är en återuppringningsfunktion, en felhanterare som kommer att anropas vid ett fel.
Funktion getUserMedia_error(error) ( console.log("getUserMedia_error():", error); )
Själva anropet till getUserMedia-metoden - begär åtkomst till mikrofonen och kameran när den första knappen trycks ned
Funktion getUserMedia_click() ( console.log("getUserMedia_click()"); navigator.webkitGetUserMedia(streamConstraints, getUserMedia_success, getUserMedia_error); )
Det är inte möjligt att komma åt mediaströmmen från en fil som öppnats lokalt. Om vi försöker göra detta får vi ett felmeddelande:
NavigatorUserMediaError (kod: 1, PERMISSION_DENIED: 1)"
Låt oss ladda upp den resulterande filen till servern, öppna den i webbläsaren och, som svar på begäran som visas, tillåta åtkomst till kameran och mikrofonen.
Du kan välja vilka enheter Chrome kommer åt i Inställningar, Visa avancerade inställningar länk, Sekretessavsnitt, Innehållsknapp. I Firefox webbläsare och Opera-enheter väljs direkt från rullgardinsmenyn när åtkomst tillåts.
När du använder HTTP-protokollet kommer tillstånd att begäras varje gång en mediaström öppnas efter att sidan har laddats. Om du byter till HTTPS kan du visa begäran en gång, bara vid den allra första åtkomsten till mediaströmmen.
Var uppmärksam på den pulserande cirkeln i ikonen på fliken och kameraikonen till höger i adressfältet:
RTCMediaConnectionRTCMediaConnection - ett objekt utformat för att etablera och överföra mediaströmmar över nätverket mellan deltagare. Dessutom är detta objekt ansvarigt för att generera en mediasessionsbeskrivning (SDP), erhålla information om ICE-kandidater för att passera genom NAT eller brandväggar (lokala och använda STUN), och interagera med TURN-servern. Varje deltagare måste ha en RTCMediaConnection per anslutning. Mediaströmmar sänds över det krypterade SRTP-protokollet.
TURN-servrarDet finns tre typer av ICE-kandidater: värd, srflx och relä. Värden innehåller information som erhållits lokalt, srflx är hur värden ser ut för en extern server (STUN), och relä är information för proxysändning av trafik genom TURN-servern. Om vår nod ligger bakom en NAT, kommer värdkandidater att innehålla lokala adresser och kommer att vara värdelösa, srflx-kandidater kommer bara att hjälpa till med vissa typer av NAT och relä kommer att vara det sista hoppet att skicka trafik genom en mellanliggande server.
Ett exempel på en ICE-kandidat av typen värd, med adress 192.168.1.37 och port udp/34022:
A=kandidat:337499441 2 udp 2113937151 192.168.1.37 34022 typ värdgeneration 0
Allmänt format för att specificera STUN/TURN-servrar:
Var servrar = ( "iceServers": [ ( "url": "stun:stun.stunprotocol.org:3478" ), ( "url": "turn: [e-postskyddad]:port", "credential": "lösenord" ) ]);
Det finns många offentliga STUN-servrar på Internet. En stor lista är till exempel . Tyvärr löser de för få av problemen. Det finns praktiskt taget inga offentliga TURN-servrar, till skillnad från STUN. Detta beror på att TURN-servern för mediaströmmar genom sig själv, vilket kan belasta både nätverkskanalen och själva servern avsevärt. Därför är det enklaste sättet att ansluta till TURN-servrar att installera det själv (uppenbarligen behöver du en offentlig IP). Av alla servrar, enligt min mening, är den bästa rfc5766-turn-server . Under den finns till och med en färdig bild för Amazon EC2.
Med TURN är inte allt så bra som vi skulle vilja, men en aktiv utveckling pågår, och jag skulle vilja hoppas att WebRTC efter en tid, om det inte kommer ikapp Skype när det gäller kvaliteten på att passera adressöversättning ( NAT) och brandväggar, kommer då åtminstone märkbart närmare.
RTCMediaConnection behöver en ytterligare mekanism för att utbyta kontrollinformation för att upprätta en anslutning - även om den genererar dessa data, överför den inte den, och överföring från andra deltagare måste implementeras separat.
Valet av överföringsmetod ligger på utvecklaren – åtminstone manuellt. Så snart nödvändig data har utbytts kommer RTCMediaConnection att ställa in mediaströmmar automatiskt (om möjligt, naturligtvis).
erbjudande-svar-modellFör att etablera och modifiera mediaströmmar används erbjudande/svarsmodellen (erbjudande/svar; beskriven i RFC3264) och SDP-protokollet (Session Description Protocol). De används också av SIP-protokollet. I denna modell särskiljs två agenter: Offerer - den som genererar en SDP-sessionsbeskrivning för att skapa en ny eller modifiera en befintlig (Offer SDP), och Answerer - en som får en SDP-sessionsbeskrivning från en annan agent och svarar på det med sin egen sessionsbeskrivning (Answer SDP). Samtidigt kräver specifikationen ett protokoll på högre nivå (till exempel SIP eller egna över webbuttag, som i vårt fall), som ansvarar för att överföra SDP mellan agenter.
Vilken data behöver skickas mellan två RTCMediaConnections så att de framgångsrikt kan etablera mediaströmmar:
Erbjudandebildning För att skapa ett erbjudande behöver vi två funktioner. Den första kommer att anropas om den lyckas bildas. Den andra parametern i metoden createOffer() är en återuppringningsfunktion som anropas i händelse av ett fel under dess exekvering (förutsatt att lokal tråd redan tillgänglig).
Dessutom behövs två händelsehanterare: en kandidat när du definierar en ny ICE-kandidat och onaddstream när du ansluter en mediaström från den andra sidan. Låt oss gå tillbaka till vår fil. Låt oss lägga till ytterligare en i HTML-koden efter raderna med elementen:
skapa Erbjudande
Och efter raden med elementet (för framtiden):
I början av JavaScript-koden kommer vi också att deklarera en global variabel för RTCPeerConnection:
varpc1;
När du anropar RTCPeerConnection-konstruktorn måste du ange STUN/TURN-servrarna. Se sidofältet för mer information; så länge alla deltagare är på samma nätverk, är de inte obligatoriska.
var servrar = null;
Alternativ för Provision Offer SDP
var offerConstraints = ();
Den första parametern i metoden createOffer() är en återuppringningsfunktion som anropas efter framgångsrik bildning av ett erbjudande
Funktion pc1_createOffer_success(desc) ( console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:", desc); pc1.setLocalDescription(desc); // Ställ in RTCPeerConnection som genereras av Erbjud SDP setLocalDescription-metoden. // När den andra sidan skickar sin Answer SDP, måste den ställas in med metoden setRemoteDescription // Tills den andra sidan är implementerad, gör ingenting // pc2_receivedOffer(desc); )
Den andra parametern är en återuppringningsfunktion som kommer att anropas vid ett fel
Funktion pc1_createOffer_error(error)( console.log("pc1_createOffer_success_error(): error:", error); )
Och vi kommer att deklarera en återuppringningsfunktion som kommer att passera ICE-kandidater som de definieras:
Funktion pc1_onicecandidate(event)( if (event.candidate) ( console.log("pc1_onicecandidate():\n"+ event.candidate.candidate.replace("\r\n", ""), event.candidate); // Gör ingenting förrän den andra sidan är implementerad // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )
Samt en återuppringningsfunktion för att lägga till en mediaström från andra sidan (för framtiden, eftersom vi bara har en RTCPeerConnection än så länge):
Funktion pc1_onaddstream(event) ( console.log("pc_onaddstream()"); remoteVideo1.src = URL.createObjectURL(event.stream); )
När du klickar på knappen "createOffer", skapar du en RTCPeerConnection, ställer in metoderna onicecandidate och onaddstream och begär bildandet av en Offer SDP genom att anropa createOffer()-metoden:
Funktion createOffer_click() ( console.log("createOffer_click()"); pc1 = new webkitRTCPeerConnection(servrar); // Skapa en RTCPeerConnection pc1.onicecandidate = pc1_onicecandidate; // Callback-funktion för att bearbeta ICE-kandidater pc1.onaddstream = / pc1_onaddstream; / Återuppringningsfunktionen anropas när det finns en mediaström från bortre sidan, den existerar inte ännu pc1.addStream(localStream); // Skicka den lokala mediaströmmen (förutsatt att den redan har tagits emot) pc1.createOffer(// Och faktiskt begära bildandet av Erbjudandet pc1_createOffer_success , pc1_createOffer_error, offerConstraints); )
Låt oss spara filen som rtctest2.html, lägga den på servern, öppna den i en webbläsare och se i konsolen vilken data som genereras under dess drift. Den andra videon kommer inte att visas ännu, eftersom det bara finns en deltagare. Kom ihåg att SDP är en beskrivning av mediasessionsparametrarna, tillgängliga codecs, mediaströmmar och ICE-kandidater är möjliga alternativ för att ansluta till denna deltagare.
Bildande av Answer SDP och utbyte av ICE-kandidaterBåde Offer SDP och var och en av ICE-kandidaterna måste skickas till den andra sidan, och där, efter att ha mottagit dem från RTCPeerConnection, anropa setRemoteDescription-metoderna för Offer SDP och addIceCandidate för varje ICE-kandidat som tas emot från den andra sidan; på liknande sätt omvänt för Answer SDP och fjärranslutna ICE-kandidater. Själva Answer SDP är utformad på samma sätt som Erbjudandet; Skillnaden är att inte createOffer-metoden anropas, utan createAnswer-metoden, och innan denna RTCPeerConnection skickar setRemoteDescription-metoden Offer SDP mottaget från den som ringer.
Låt oss lägga till ytterligare ett videoelement i HTML:en:
Och en global variabel för den andra RTCPeerConnection under deklarationen av den första:
Varpc2;
Bearbetar erbjudande och svar SDPAtt bilda en SDP för svar är mycket likt ett erbjudande. I återuppringningsfunktionen som anropas efter framgångsrik bildning av svaret, på samma sätt som erbjudandet, kommer vi att ge en lokal beskrivning och skicka den mottagna svars-SDP till den första deltagaren:
Funktion pc2_createAnswer_success(desc) ( pc2.setLocalDescription(desc); console.log("pc2_createAnswer_success()", desc.sdp); pc1.setRemoteDescription(desc); )
Återuppringningsfunktionen som anropas i händelse av ett fel när svaret genereras är helt lik Erbjudandet:
Funktion pc2_createAnswer_error(error) ( console.log("pc2_createAnswer_error():", error); )
Parametrar för att generera Answer SDP:
Var answerConstraints = ( "obligatorisk": ( "OfferToReceiveAudio":true, "OfferToReceiveVideo":true) );
När den andra deltagaren får ett erbjudande, skapa en RTCPeerConnection och bilda ett svar på samma sätt som erbjudandet:
Funktion pc2_receivedOffer(desc) ( console.log("pc2_receiveOffer()", desc); // Skapa ett RTCPeerConnection-objekt för den andra deltagaren liknande den första pc2 = new webkitRTCPeerConnection(servrar); pc2.onicecandidate = pc2_onicecandidate; // Set händelsehanteraren när ICE-kandidat pc2.onaddstream = pc_onaddstream; // När en ström visas, anslut den till HTML-filen pc2.addStream(localStream); // Skicka den lokala mediaströmmen (i vårt exempel har den andra deltagaren samma ström som den första) // Nu, när den andra RTCPeerConnection är klar, skicka den mottagna Offer SDP till den (vi skickade den lokala strömmen till den första) pc2.setRemoteDescription(new RTCSessionDescription(desc)); // Fråga den andra anslutning för att generera data för svarsmeddelandet pc2.createAnswer(pc2_createAnswer_success, pc2_createAnswer_error, answerConstraints); )
För att överföra Erbjudande SDP från den första deltagaren till den andra, som en del av vårt exempel, avkommentarer du i pc1-funktionen skapa Erbjudande success() anropssträng:
Pc2_receivedOffer(desc);
För att implementera bearbetningen av ICE-kandidater, ta bort kommentarer i ICE-kandidatberedskapshändelsehanteraren för den första deltagaren pc1_onicecandidate() dess överföring till den andra:
Pc2.addIceCandidate(ny RTCIceCandidate(event.candidate));
Den andra deltagarens ICE-kandidatberedskapshändelsehanterare är spegellik den första:
Funktion pc2_onicecandidate(event) ( if (event.candidate) ( console.log("pc2_onicecandidate():", event.candidate.candidate); pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )
Återuppringningsfunktion för att lägga till en mediaström från den första deltagaren:
Funktion pc2_onaddstream(event) ( console.log("pc_onaddstream()"); remoteVideo2.src = URL.createObjectURL(event.stream); )
Avbryter en anslutningLåt oss lägga till en annan knapp i HTML
Lägg på
Och en funktion för att avsluta anslutningen
Funktion btnHangupClick() ( // Koppla bort lokal video från HTML-element, stoppa lokal mediaström, set = null localVideo1.src = ""; localStream.stop(); localStream = null; // För varje deltagare, inaktivera video från HTML-element , nära anslutning, ställ in pekare = null remoteVideo1.src = ""; pc1.close(); pc1 = null; remoteVideo2.src = ""; pc2.close(); pc2 = null; )
Låt oss spara den som rtctest3.html, lägga den på servern och öppna den i webbläsaren. Det här exemplet implementerar tvåvägsmedieströmning mellan två RTCPeerConnections inom samma webbläsarflik. För att organisera utbytet av Offer and Answer SDP, ICE-kandidater mellan deltagare och annan information via nätverket, kommer det att vara nödvändigt att genomföra utbytet mellan deltagare med hjälp av någon form av transport, i vårt fall, webbuttag, istället för ett direktsamtal till förfaranden.
SkärmsändningMed getUserMedia-funktionen kan du också fånga skärmen och streama som en MediaStream genom att ange följande parametrar:
Var mediaStreamConstraints = ( ljud: falskt, video: ( obligatoriskt: ( chromeMediaSource: "skärm" ), valfritt: ) );
För framgångsrik åtkomst till skärmen måste flera villkor vara uppfyllda:
Även om WebRTC ännu inte är komplett, har flera bibliotek baserade på det redan dykt upp. JsSIP är designat för att skapa webbläsarbaserade mjukvarutelefoner som fungerar med SIP-switchar som Asterisk och Camalio. PeerJS kommer att förenkla skapandet av P2P-nätverk för datautbyte, och Holla kommer att minska mängden utveckling som krävs för P2P-kommunikation från webbläsare.
Node.js och socket.ioFör att organisera utbytet av SDP- och ICE-kandidater mellan två RTCPeerConnections över nätverket använder vi Node.js med modulen socket.io.
Installation av den senaste stabila versionen av Node.js (för Debian/Ubuntu) beskrivs
$ sudo apt-get installera python-software-properties python g++ gör $ sudo add-apt-repository ppa:chris-lea/node.js $ sudo apt-get uppdatering$ sudo apt-get install nodejs
Installation för andra operativsystem beskrivs
Låt oss kolla:
$ echo "sys=require("util"); sys.puts("Testmeddelande");" > nodetest1.js $ nodejs nodetest1.js
Använd npm (Node Package Manager) installera socket.io och ytterligare modul uttrycka:
$ npm installera socket.io express
Låt oss kontrollera det genom att skapa en nodetest2.js-fil för serversidan:
$ nano nodetest2.js var app = require("express")() , server = require("http").createServer(app) , io = require("socket.io").listen(server); server.listen(80); // Om port 80 är gratis app.get("/", funktion (req, res) ( // Vid åtkomst till rotsidan res.sendfile(__dirname + "/nodetest2.html"); // ge HTML-filen ) ); io.sockets.on("anslutning", funktion (socket) ( // Vid anslutning socket.emit("serverhändelse", ( hej: "världen")); // skicka meddelande socket.on("klienthändelse", function (data) ( // och deklarera en händelsehanterare när ett meddelande kommer från klienten console.log(data); )); ));
Och nodetest2.html för klientsidan:
$ nano nodetest2.html var socket = io.connect("/"); // URL för webbsocketservern (rotsidan för servern från vilken sidan laddades) socket.on("serverhändelse", funktion (data) ( console.log(data); socket.emit("klienthändelse" , ("namn": "värde")); ));
Låt oss starta servern:
$ sudo nodejs nodetest2.js
och öppna sidan http://localhost:80 (om den körs lokalt på port 80) i en webbläsare. Om allt är lyckat, i konsolen Webbläsare JavaScript vi kommer att se utbytet av händelser mellan webbläsaren och servern när den är ansluten.
Informationsutbyte mellan RTCPeerConnection via webbsockets KlientsidanLåt oss spara vårt huvudexempel (rtcdemo3.html) under det nya namnet rtcdemo4.html. Inkludera socket.io-biblioteket i elementet:
Och i början av JavaScript-skriptet - webbsocket-anslutning:
var socket = io.connect("http://localhost");
Låt oss ersätta ett direktanrop till en annan deltagares funktioner genom att skicka honom ett meddelande via webbuttag:
Funktion createOffer_success(desc) ( ... // pc2_receivedOffer(desc); socket.emit("offer", desc); ... ) funktion pc2_createAnswer_success(desc) ( ... // pc1.setRemoteDescription(desc); socket .emit("svar", desc); ) funktion pc1_onicecandidate(event) ( ... // pc2.addIceCandidate(ny RTCIceCandidate(event.candidate)); socket.emit("ice1", event.candidate); .. . ) function pc2_onicecandidate(event) ( ... // pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice2", event.candidate); ... )
I funktionen hangup(), istället för att direkt anropa funktionerna för den andra deltagaren, skickar vi ett meddelande via webbsockets:
Funktion btnHangupClick() ( ... // remoteVideo2.src = ""; pc2.close(); pc2 = null; socket.emit("lägg på", ()); )
Och lägg till hanterare för meddelandemottagning:
Socket.on("erbjudande", funktion (data) ( console.log("socket.on("erbjudande"):", data); pc2_receivedOffer(data); )); socket.on("svar", funktion (data) (e console.log("socket.on("svar"):", data); pc1.setRemoteDescription(ny RTCSessionDescription(data)); )); socket.on("ice1", function (data) ( console.log("socket.on("ice1"):", data); pc2.addIceCandidate(ny RTCIceCandidate(data)); )); socket.on("ice2", function (data) ( console.log("socket.on("ice2"):", data); pc1.addIceCandidate(ny RTCIceCandidate(data)); )); socket.on("lägg på", funktion (data) ( console.log("socket.on("lägg på")):", data); remoteVideo2.src = ""; pc2.close(); pc2 = null; ) );
Server delPå serversidan, spara nodetest2-filen under det nya namnet rtctest4.js och inuti io.sockets.on("connection", funktion (socket) ( ... )-funktionen lägg till att ta emot och skicka klientmeddelanden:
Socket.on("erbjudande", funktion (data) ( // När ett "erbjudande"-meddelande tas emot, // eftersom klientanslutningen i detta exempel bara en, // skicka ett meddelande tillbaka via samma socket socket.emit("erbjudande", data); // Om det var nödvändigt att vidarebefordra meddelandet på alla anslutningar // förutom avsändaren: // socket.broadcast.emit("erbjudande", data); )); socket.on("svar", funktion (data) ( socket.emit("svar", data); )); socket.on("ice1", funktion (data) ( socket.emit("ice1", data); )); socket.on("ice2", funktion (data) ( socket.emit("ice2", data); )); socket.on("lägg på", funktion (data) ( socket.emit("lägg på", data); ));
Ändra dessutom namnet på HTML-filen:
// res.sendfile(__katalognamn + "/nodetest2.html"); // Skicka HTML-filen res.sendfile(__katalognamn + "/rtctest4.html");
Serverstart:
$ sudo nodejs nodetest2.js
Trots att koden för båda klienterna körs inom samma webbläsarflik, sker all interaktion mellan deltagarna i vårt exempel helt och hållet via nätverket och det är inte längre svårt att "sprida" deltagarna. Men vad vi gjorde var också väldigt enkelt - dessa tekniker är bra för deras användarvänlighet. Fast ibland vilseledande. I synnerhet, låt oss inte glömma att utan STUN/TURN-servrar kommer vårt exempel inte att kunna fungera i närvaro av adressöversättning och brandväggar.
SlutsatsDet resulterande exemplet är mycket villkorat, men om vi något universaliserar händelsehanterare så att de inte skiljer sig mellan de anropande och anropade parterna, istället för två objekt pc1 och pc2, skapa en array av RTCPeerConnection och implementera dynamiskt skapande och ta bort element får du en helt användbar videochatt. Detta är inte längre specifikt för WebRTC, och ett exempel på den enklaste videochatten för flera deltagare (liksom texterna i alla exempel på artikeln) finns på skivan som följer med tidningen. Men det finns redan många bra exempel på Internet. I synnerhet när man förberedde artikeln användes följande: simpl.info getUserMedia , simpl.info RTCPeerConnection , WebRTC Reference App .
Det kan antas att det mycket snart, tack vare WebRTC, kommer att ske en revolution inte bara i vår förståelse av röst- och videokommunikation, utan också i hur vi uppfattar Internet som helhet. WebRTC är inte bara positionerat som en webbläsare-till-webbläsare-samtalsteknik, utan också som en kommunikationsteknik i realtid. Videolänken vi analyserade är bara en liten del av den. alternativ dess användning. Det finns redan exempel på skärmdelning (skärmdelning) och samarbete, och till och med ett webbläsarbaserat P2P-innehållsleveransnätverk som använder RTCDataChannel.
Idag är WebRTC den "heta" tekniken för att streama ljud och video i webbläsare. Konservativa teknologier, som HTTP Streaming och Flash, är mer lämpade för att distribuera inspelat innehåll (video on demand) och är betydligt sämre än WebRTC vad gäller realtids- och onlinesändningar, d.v.s. där minimal videolatens krävs, så att tittarna kan se vad som händer "live".
Möjligheten till högkvalitativ realtidskommunikation kommer från själva WebRTC-arkitekturen, där videoströmmar transporteras med hjälp av UDP-protokoll, som är en standardbas för videoöverföring med minimala fördröjningar och används flitigt i realtidskommunikationssystem.
Kommunikationsfördröjning är viktig i livestreamingsystem, webbseminarier och andra applikationer där interaktiv kommunikation med videokällan, slutanvändare och lösning krävs.
En annan bra anledning att prova WebRTC är definitivt en trend. Idag alla Android Chrome webbläsaren stöder denna teknik, vilket säkerställer att miljontals enheter är redo att titta på sändningen utan att installera någon ytterligare programvara och konfigurationer.
För att testa WebRTC-tekniken i aktion och starta en enkel online-sändning på den använde vi servermjukvaran Flashphoner WebRTC Media & Broadcasting Server. Funktionerna förklarar möjligheten att sända WebRTC-strömmar i en-till-många-läget, samt stöd för IP-kameror och videoövervakningssystem via RTSP-protokollet; i denna recension kommer vi att fokusera på webbsändningar och deras funktioner.
Installera WebRTC Media & Broadcasting ServerFör för Windows-system det fanns ingen serverversion, och jag ville inte installera en virtuell maskin som VMWare + Linux, testa online-sändningar i hemmet Windows-dator Det funkade inte. För att spara tid bestämde vi oss för att ta ett exempel på molnvärd så här:
Det var en Centos x86_64 version 6.5 utan någon förinstallerad programvara i ett Amsterdams datacenter. Allt vi har till vårt förfogande är alltså en server och ssh-åtkomst till den. För den som är bekant med konsolkommandon Linux, att installera en WebRTC-server lovar att vara enkelt och smärtfritt. Så vad vi gjorde:
1. Ladda ner arkiv:
$wget https://website/download-wcs5-server.tar.gz
2. Packa upp:
$tar -xzf download-wcs5-server.tar.gz
3. Installera:
$cd FlashphonerWebCallServer
Ange serverns IP-adress under installationen: XXX.XXX.XXX.XXX
4. Aktivera licensen:
$cd /usr/local/FlashphonerWebCallServer/bin
$./activation.sh
5. Starta WCS-servern:
$service webbsamtalsserver startar
6. Kontrollera loggen:
$tail - f /usr/local/FlashphonerWebCallServer/logs/flashphoner_manager.log
7. Kontrollera att två processer är på plats:
$ps aux | grep Flashphoner
Installationsprocessen är klar.
Testar WebRTC liveströmmarAtt testa sändningar visade sig vara en enkel sak. Utöver servern finns en webbklient, som består av ett dussin Javascript-, HTML- och CSS-filer och distribuerades av oss till mappen /var/www/html under installationsfasen. Det enda som behövdes göras var att ange serverns IP-adress i flashphoner.xml config så att webbklienten kunde upprätta en anslutning till servern via HTML5 Websockets. Låt oss beskriva testprocessen.
1. Öppna sidan för testklienten index.html i Chrome webbläsare e:
2. För att börja sända måste du klicka på "Start"-knappen i mitten av skärmen.
Innan du gör detta måste du se till att webbkameran är ansluten och redo att gå. Det finns inga speciella krav på en webbkamera, till exempel använde vi en standard inbyggd bärbar datorkamera med en upplösning på 1280 × 800.
Chrome-webbläsaren kommer definitivt att be om åtkomst till kameran och mikrofonen så att användaren förstår att hans video kommer att skickas till internetservern och låter honom göra det.
3. Gränssnittet är en framgångsrik översättning av videoströmmen från kameran till WebRTC-servern. I det övre högra hörnet indikerar indikatorn att strömmen går till servern, i det nedre hörnet finns en "Stopp"-knapp för att sluta skicka videon.
Ta en titt på länken nedan. Den innehåller en unik identifierare för den här strömmen, så vem som helst kan gå med i vyn. Öppna bara den här länken i en webbläsare. För att kopiera den till urklipp måste du klicka på knappen "Kopiera".
I verkliga applikationer som webbseminarier, föreläsningar, videosändningar online eller interaktiv TV måste utvecklare implementera distributionen av denna identifierare till vissa grupper av tittare så att de kan ansluta till önskade strömmar, men detta är logiken i applikationen. WebRTC Media & Broadcasting Server påverkar inte den, utan distribuerar bara video.
5. Anslutningen upprättas och tittaren ser strömmen på skärmen. Nu kan han skicka länken till någon annan, stoppa uppspelning av streaming eller aktivera helskärmsläge med kontrollerna i det nedre högra hörnet.
Under tester verkade latensen vara perfekt. Pinget till datacentret var cirka 100 millisekunder och fördröjningen var inte synlig för ögat. Härifrån kan vi anta att den verkliga fördröjningen är samma 100 plus eller minus några tiotals millisekunder för buffringstiden. Jämfört med Flash-video presterar Flash inte lika bra som WebRTC i dessa tester. Så om du flyttar din hand på ett liknande nätverk, kan rörelsen på skärmen ses först efter en / två sekunder.
Angående kvaliteten noterar vi att man ibland kan urskilja kuber på rörelser. Detta är i linje med VP8-codecens natur och dess huvudsakliga mål är att tillhandahålla videokommunikation i realtid med acceptabel kvalitet och utan kommunikationsförseningar.
Servern är ganska enkel att installera och konfigurera, den kräver inga seriösa kunskaper för att köra den, förutom kunskap om Linux på nivån för en avancerad användare som kan utföra kommandon från konsolen via ssh och använda textredigerare. Som ett resultat lyckades vi sätta upp en en-till-många online-sändning mellan webbläsare. Att koppla ytterligare tittare till streamen orsakade inte heller problem.
Sändningskvaliteten visade sig vara ganska acceptabel för webbseminarier och onlinesändningar. Det enda som väckte några frågor var upplösningen på videon. Kameran stöder 1280x800, men upplösningen på testbilden är väldigt lik 640x480. Tydligen måste denna fråga klargöras med utvecklarna.
Video om testsändning från en webbkamera
