A WebRTC (Web Real Time Communications) egy szabvány, amely leírja a streaming audioadatok, videoadatok és tartalmak átvitelét a böngészőből és a böngészőbe valós időben, bővítmények vagy egyéb bővítmények telepítése nélkül. A szabvány lehetővé teszi, hogy a böngészőt videokonferencia-terminállá alakítsa, csak nyisson meg egy weboldalt a kommunikáció megkezdéséhez.

Mi az a WebRTC?

Ebben a cikkben mindent megtudunk, amit a WebRTC technológiáról tudni kell egy átlagos felhasználó számára. Tekintsük a projekt előnyeit és hátrányait, fedjünk fel néhány titkot, mondjuk el, hogyan működik, hol és mire használják a WebRTC-t.

Mit kell tudni a WebRTC-ről?

A videó szabványok és technológiák fejlődése

Sergey Yutsaitis, Cisco, Video+Conference 2016

Hogyan működik a WebRTC

Az ügyfél oldalon

• A felhasználó megnyit egy HTML5 címkét tartalmazó oldalt
• A böngésző hozzáférést kér a felhasználó webkamerájához és mikrofonjához.
• A felhasználói oldalon található JavaScript-kód szabályozza a kapcsolati paramétereket (a WebRTC-kiszolgáló vagy más WebRTC-kliensek IP-címeit és portjait) a NAT és a tűzfal megkerüléséhez.
• Amikor információt kap a beszélgetőpartnerről vagy a kiszolgálón kevert konferenciával folytatott streamről, a böngésző elkezdi egyeztetni a használt audio- és videokodekeket.
• Megkezdődik az adatok kódolása és streamelése a WebRTC kliensek között (esetünkben a böngésző és a szerver között).

A WebRTC szerver oldalán

A két résztvevő közötti adatcseréhez nincs szükség videoszerverre, de ha több résztvevőt szeretne egy konferencián összevonni, akkor egy szerver szükséges.

A videoszerver különféle forrásokból fogadja a médiaforgalmat, átalakítja és elküldi a WebRTC-t terminálként használó felhasználóknak.

A WebRTC szerver a médiaforgalmat is fogadja a WebRTC társaktól, és továbbítja azt a konferencia résztvevőinek asztali alkalmazások, ill. mobil eszközök, ha van.

A szabvány előnyei

• Nincs szükség szoftver telepítésére.
• Nagyon jó kommunikációs minőség a következőknek köszönhetően:
  • Modern video (VP8, H.264) és audio kodekek (Opus) használata.
  • Az adatfolyam minőségének automatikus beállítása a csatlakozási feltételekhez.
  • Beépített visszhang- és zajszűrő.
  • A résztvevők mikrofonjainak automatikus szintszabályozása (AGC).
• Magas szintű biztonság: minden kapcsolat biztonságos és titkosított a TLS és SRTP protokolloknak megfelelően.
• Van egy beépített mechanizmus a tartalom rögzítésére, például az asztalra.
• Bármilyen HTML5 és JavaScript alapú vezérlőfelület megvalósításának lehetősége.
• Az interfész integrálása bármilyen háttérrendszerrel WebSockets használatával.
• Nyílt forráskódú projekt – beágyazhatja termékébe vagy szolgáltatásába.
• Valódi többplatformos: ugyanaz a WebRTC alkalmazás bármelyiken ugyanolyan jól működik operációs rendszer, asztali vagy mobil, feltéve, hogy a böngésző támogatja a WebRTC-t. Ezzel rengeteg erőforrást takaríthatunk meg a szoftverfejlesztéshez.

A szabvány hátrányai

• Csoportos hang- és videokonferenciák szervezéséhez videokonferencia szerverre van szükség, amely keveri a résztvevőktől származó videót és hangot, mert a böngésző nem tudja, hogyan kell több bejövő adatfolyamot szinkronizálni egymással.
• Minden WebRTC megoldás nem kompatibilis egymással, mert a szabvány csak a kép- és hangátviteli módszereket írja le, az előfizetők megszólításának, elérhetőségük nyomon követésének, az üzenetek és fájlok cseréjének, ütemezésének és egyéb dolgoknak a megvalósítását az eladóra hagyja.
• Más szóval, nem fog tudni hívni egy fejlesztő WebRTC alkalmazásából egy másik fejlesztő WebRTC alkalmazását.
• A csoportos konferencia keverés sok számítási erőforrást igényel, ezért az ilyen típusú videokommunikáció vásárlást igényel fizetett előfizetés vagy befektetés az infrastruktúrájába, ahol minden konferencia 1 fizikai magot igényel egy modern processzorból.

WebRTC titkai: Hogyan profitálnak a szállítók a bomlasztó webtechnológiából

Tzachi Levent-Levi, Bloggeek.me, Video+Conference 2015

WebRTC a videokonferencia piac számára

A videokonferencia-terminálok számának növekedése

A WebRTC technológia erős hatást gyakorolt ​​a videokonferencia piac fejlődésére. Az első WebRTC-támogatással rendelkező böngészők 2013-as megjelenése után a videokonferencia-terminálok potenciális száma világszerte azonnal 1 milliárd eszközzel nőtt. Valójában minden böngésző videokonferencia-terminálná vált, amely kommunikációs minőségét tekintve nem rosszabb hardveres társainál.

Használja speciális megoldásokban

A különféle JavaScript-könyvtárak és felhőszolgáltatási API-k WebRTC-támogatással történő használata megkönnyíti a videotámogatás hozzáadását bármely webprojekthez. Korábban a valós idejű adatátvitel megkövetelte a fejlesztőktől, hogy megtanulják a protokollok működését, és más cégek munkáját is használhassák, ami legtöbbször további licencelést igényelt, ami növelte a költségeket. A WebRTC-t már aktívan használják olyan szolgáltatásokban, mint a „Hívás a webhelyről”, „Online támogatási csevegés” stb.

A Skype for Linux korábbi felhasználói

2014-ben a Microsoft bejelentette a Skype for Linux projekt támogatásának megszüntetését, ami nagy bosszúságot okozott az informatikusok körében. A WebRTC technológia nincs az operációs rendszerhez kötve, hanem böngésző szinten valósul meg, pl. A Linux-felhasználók a WebRTC-alapú termékeket és szolgáltatásokat a Skype teljes értékű helyettesítőjeként láthatják majd.

Verseny a vakuval

A WebRTC és a HTML5 halálos csapást jelentett Flash technológiák, amely már korántsem a legjobb éveit élte. 2017 óta a vezető böngészők hivatalosan leállították a Flash támogatását, és a technológia végleg eltűnt a piacról. De a Flash-t meg kell adni, mert ő volt az, aki létrehozta a webkonferencia piacot, és felajánlotta a böngészőkben való élő kommunikáció technikai lehetőségeit.

WebRTC videó bemutatók

Dmitry Odintsov, TrueConf, Video+konferencia 2017. október

Kodekek a WebRTC-ben

Audio kodekek

Az audioforgalom WebRTC-ben történő tömörítéséhez Opus és G.711 kodekeket használnak.

G.711- a legrégebbi hangkodek magas bitsebességgel (64 kbps), amelyet leggyakrabban a hagyományos telefonrendszerekben használnak. A fő előny a minimális számítási terhelés a könnyű tömörítési algoritmusok használatának köszönhetően. A kodek más alacsony szint a hangjelek tömörítését, és nem vezet be további hangkésleltetést a felhasználók közötti kommunikáció során.

A G.711-et számos eszköz támogatja. Az ezt a kodeket használó rendszerek könnyebben használhatók, mint a más audiokodekeken alapuló rendszerek (G.723, G.726, G.728 stb.). Ami a minőséget illeti, a G.711 4,2 pontot kapott a MOS tesztelés során (a 4-5-ös pontszám a legmagasabb, és jó minőséget jelent, hasonló az ISDN hangforgalmának minőségéhez, sőt még magasabb is).

Opus egy alacsony kódolási késleltetésű (2,5 ms-tól 60 ms-ig terjedő) kodek, amely támogatja a változó bitsebességet és magas szint tömörítés, amely ideális az audio streaminghez változókkal rendelkező hálózatokon áteresztőképesség. Az Opus egy hibrid megoldás, amely egyesíti legjobb teljesítmény SILK (hangtömörítés, emberi beszéd torzulásainak kiküszöbölése) és CELT (audio adatkódolás) kodekek. A kodek ingyenesen elérhető, az azt használó fejlesztőknek nem kell jogdíjat fizetniük a szerzői jogok tulajdonosainak. Más audio kodekekhez képest az Opus minden bizonnyal sok szempontból nyer. Elhomályosította az olyan népszerű, alacsony bitsebességű kodekeket, mint az MP3, Vorbis, AAC LC. Az Opus visszaállítja a hang "képét" az eredetihez közelebb, mint az AMR-WB és a Speex. Ez a kodek a jövő, ezért a WebRTC technológia megalkotói beépítették a támogatott hangszabványok kötelező körébe.

Videókodekek

A WebRTC videokodek kiválasztásának kérdései több évig tartottak a fejlesztőknek, végül a H.264 és a VP8 használata mellett döntöttek. Szinte minden modern böngésző támogatja mindkét kodeket. A videokonferencia-kiszolgálóknak csak egyet kell támogatniuk a WebRTC-vel való együttműködéshez.

VP8 egy ingyenes, nyílt licenccel rendelkező videokodek, amely nagy videofolyam-dekódolási sebességgel és fokozottan ellenáll a képkockák elvesztésének. A kodek univerzális, könnyen beépíthető hardverplatformokra, így a videokonferencia-rendszerek fejlesztői gyakran használják termékeikben.

Fizetett videokodek H.264 sokkal korábban vált ismertté, mint bátyja. Ez egy kodek, amely mentés közben nagymértékben tömöríti a videofolyamot Jó minőség videó. Ennek a kodeknek a nagy elterjedtsége a hardveres videokonferencia-rendszerek között arra utal, hogy a WebRTC szabványban használják.

A Google és a Mozilla aktívan népszerűsíti a VP8 kodeket, míg a Microsoft, az Apple és a Cisco a H.264-et (a hagyományos videokonferencia rendszerekkel való kompatibilitás biztosítása érdekében). És itt egy nagyon nagy probléma merül fel a felhő alapú WebRTC megoldások fejlesztői számára, mert ha a konferencia minden résztvevője egy böngészőt használ, akkor elég egyszer keverni a konferenciát egy kodekkel, és ha a böngészők különbözőek és közöttük van Safari / Edge, akkor a konferenciát kétszer különböző kodekekkel kell kódolni, ami megduplázza a rendszerkövetelmények a médiaszerverre, és ennek eredményeként a WebRTC szolgáltatásokra való előfizetés költségei.

WebRTC API

A WebRTC technológia három fő API-n alapul:

• (a webböngésző felelős azért, hogy audio- és videojeleket fogadjon a kamerákról vagy a felhasználó asztaláról).
• RTCPeerConnection(felelős a böngészők közötti kapcsolatért a kamerától, a mikrofontól és az asztaltól kapott médiaadatok „cseréjére”. Ezen API „feladatai” továbbá a jelfeldolgozás (megtisztítása az idegen zajtól, a mikrofon hangerejének beállítása) és a használt audio- és videokodekek) .
• RTC adatcsatorna(kétirányú adatátvitelt biztosít egy kiépített kapcsolaton keresztül).

Mielőtt hozzáférne a felhasználó mikrofonjához és kamerájához, a böngésző kéri ezt az engedélyt. NÁL NÉL Google Chrome a hozzáférést a "Beállítások" részben előre konfigurálhatja, az Opera és a Firefox esetében az eszközök kiválasztása közvetlenül a hozzáféréskor történik a legördülő listából. Az engedélykérés mindig megjelenik a HTTP protokoll használatakor, és egyszer, ha HTTPS-t használ:

RTCPeerConnection. Minden WebRTC konferencián részt vevő böngészőnek hozzáféréssel kell rendelkeznie ehhez az objektumhoz. Az RTCPeerConnection használatának köszönhetően a médiaadatok egyik böngészőből a másikba még a NAT-on és a tűzfalakon is áthaladhatnak. A médiafolyamok sikeres továbbításához a résztvevőknek a következő adatokat kell kicserélniük egy átviteli eszköz, például webes socket segítségével:

• a kezdeményező résztvevő elküldi a második résztvevőnek egy Offer-SDP-t (adatstruktúra, az általa továbbítandó médiafolyam jellemzőivel);
• a második résztvevő generál egy „választ” - Answer-SDP, és elküldi a kezdeményezőnek;
• majd ICE jelöltek cseréjét szervezik a résztvevők között, ha találnak ilyeneket (ha a résztvevők NAT vagy tűzfalak mögött vannak).

A résztvevők közötti csere sikeres befejezése után a médiafolyamok (audió és videó) átvitelét közvetlenül megszervezik.

RTC adatcsatorna. A Data Channel protokoll támogatása viszonylag nemrég jelent meg a böngészőkben, így ez az API csak olyan esetekben jöhet számításba, ahol WebRTC-t használnak Mozilla böngészők Firefox 22+ és Google Chrome 26+. Ezzel a résztvevők cserélhetnek szöveges üzenetek a böngészőben.

WebRTC kapcsolat

Támogatott asztali böngészők

• Google Chrome (17+) és minden Chromium-motoron alapuló böngésző;
• Mozilla Firefox (18+);
• Opera (12+);
• Safari (11+);

Támogatott mobil böngészők Androidhoz

• Google Chrome (28+);
• Mozilla Firefox (24+);
• Opera Mobile (12+);
• Safari (11+).

WebRTC, Microsoft és Internet Explorer

A Microsoft nagyon sokáig hallgatott a WebRTC támogatásáról internet böngészőés az új Edge böngésző. A redmondi srácok nem igazán szeretik a technológiát olyan felhasználók kezébe adni, akiket nem ők irányítanak, ez a fajta politika. De fokozatosan elindultak a dolgok, mert. A WebRTC-t már nem lehetett figyelmen kívül hagyni, és bejelentették a WebRTC szabványból levezetett ORTC projektet.

A fejlesztők szerint az ORTC a WebRTC szabvány kiterjesztése JavaScript és HTML5 alapú továbbfejlesztett API-készlettel, ami hétköznapi nyelvre lefordítva azt jelenti, hogy minden a régi lesz, csak a Microsoft fogja irányítani a szabványt, nem a Google. és annak fejlődése. A kodekek készlete kibővült a H.264 és néhány G.7XX sorozatú audiokodek támogatásával, amelyeket telefonos és hardveres videokonferencia-rendszerekben használnak. Talán lesz beépített támogatás az RDP-hez (tartalomátvitelhez) és az üzenetkezeléshez. Az Internet Explorert használók egyébként nem járnak szerencsével, az ORTC támogatás csak az Edge-ben lesz. És persze egy ilyen protokoll- és kodekkészlet csekély vérrel illeszkedik a Skype for Business-hoz, amely még több üzleti alkalmazást nyit meg a WebRTC számára.

Az európai internetezők két részre oszlanak: az allenbachi (Németország) Közvélemény-elemző Intézet felmérése szerint a Skype, a chat- és azonnali üzenetküldő rendszerek 16,5 millió felnőtt és gyermek, 9 millió ember mindennapi életének szerves részévé váltak. esetről esetre veszik igénybe ezeket a szolgáltatásokat, és 28 millióan nem nyúlnak hozzájuk.

A helyzet változhat, hiszen immár a Firefox is be van építve valós idejű kommunikációs technológia (WebRTC), valamint maga az ügyfél is. Az audio- és videocsevegés indítása most nem nehezebb, mint egy webhely megnyitása. Az olyan szolgáltatások viszont, mint a Facebook és a Skype, külön klienst használó megoldásokra és fiók létrehozására támaszkodnak.

A WebRTC nem csak egyszerűen használható. Ez a módszer lehetővé teszi még a beállítást is közvetlen kapcsolat két böngésző között. Ily módon a hang- és képadatok nem jutnak át olyan szerveren, ahol torlódás léphet fel, vagy ahol az adminisztrátor nem különösebben érzékeny a magánéletre vagy az adatvédelemre. A közvetlen kapcsolatnak köszönhetően a WebRTC nem igényel regisztrációt ill fiók bármely szolgáltatásban.

Beszélgetés indításához csak a linket kell követnie. A kommunikáció privát marad mert az adatfolyam titkosított. Valós idejű kommunikáció böngészőn keresztül Google 2011-ben kezdett aktívan részt venni, amikor közzétette WebRTC implementációjának forráskódját.

Röviddel ezután a Chrome és a Firefox megkapta a saját WebRTC motorját. Jelenleg azok mobil lehetőségek mind ezzel a technológiával, mind az alkalmazások által használt Android 5.0-val telepített WebView 3.6 motorral.

A valós idejű kommunikációhoz a megfelelő JavaScript felületeket kell megvalósítani a webes megjelenítőben. A GetUserMedia használata szoftver aktiválja a rögzítést hang- és videoforrásokból, azaz webkamerából és mikrofonból. Az RTCPeerConnection felelős a kapcsolat létrehozásáért, valamint magáért a kommunikációért.

Párhuzamosan a böngésző integrációjával munkacsoport A World Wide Web Consortium (W3C) szorgalmazza a WebRTC szabványosítási folyamatát. 2015-ben kell elkészülnie.

A WebRTC megelégszik kevéssel

A WebRTC szolgáltatás használata nem igényel sok erőforrást, mivel a szerver csak a haverokat köti össze. A kapcsolat létrehozása sem különösebben nehéz. Először a böngésző jelzi a WebRTC szervernek, hogy hívás kezdeményezését tervezi. HTTPS hivatkozást kap a szervertől - a kapcsolat titkosított. A felhasználó elküldi ezt a linket beszélgetőpartnerének. A böngésző ezután engedélyt kér a felhasználótól a webkamera és a mikrofon eléréséhez.

A másik féllel való közvetlen streaming kapcsolat létrehozásához a böngésző megkapja IP-címét és konfigurációs adatait a WebRTC szolgáltatástól. A haver webböngészője ugyanezt teszi.

Annak érdekében, hogy a streaming kapcsolat zavartalanul és jó minőségben működjön, három motor dolgozik a böngészőben. Közülük kettő optimalizálja és tömöríti az audio- és videoadatokat, a harmadik pedig ezek szállításáért felel. keresztül küldi az adatokat SRTP protokoll(Secure Real-time Transport Protocol), amely valós idejű titkosított adatfolyamot tesz lehetővé.

Ha a közvetlen kapcsolat meghiúsul, a WebRTC másik elérési utat keres. Ez például akkor történik, amikor hálózati beállítások megakadályozza, hogy a STUN szerver jelenteni tudja az IP-címet. A WebRTC szabvány előírja, hogy ebben az esetben a beszélgetés megtörténik, de közben a TURN szerver (Traversal Using Relays around NAT) bevonásával. Tehát a netscan.co webhelyen ellenőrizheti, hogy a WebRTC implementálva van-e az Ön számítógépén és a web-hozzáféréssel.

Hogyan jön létre a kapcsolat

Először regisztrálnia kell egy beszélgetést (1). A WebRTC szolgáltatás egy hivatkozást biztosít, amelyet el kell küldeni a beszélgetőpartnernek. A böngésző a STUN-szerver segítségével megkeresi saját IP-címét (2), elküldi a szolgáltatásnak, és megkapja a partner IP-jét a közvetlen kapcsolat létrehozásához (3). Ha a STUN sikertelen, a beszélgetést a TURN szerver (4) segítségével irányítja át.

A WebRTC technológiát használó kommunikáció a böngészőben JavaScript kóddal indul. Ezt követően három motor felel a kommunikációért: a hang- és videómotorok a webkamerából és a mikrofonból gyűjtik a multimédiás adatokat, a szállítómotor pedig egyesíti az információkat, és a Secure Real-time Protocol (SRTP) segítségével titkosított formában küldi el a streamet.

Mely böngészők működnek a WebRTC-vel

A Chrome és a Firefox WebRTC motorral van felszerelve, amely olyan szolgáltatásokat használ, mint a talky.io. A Mozilla böngésző közvetlenül képes együttműködni saját kliensével.

A Google és a Mozilla tovább fejleszti a valós idejű kommunikáció ötletét: a Chrome több résztvevős WebRTC-konferenciát tud rendezni, a Firefox új Hello-kliensét pedig a Telefonica távközlési óriáscég leányvállalata fejleszti. Az Apple egyelőre a pálya szélén marad, a WebRTC-re még nem kell számítani a Safariban. A Safarihoz azonban rengeteg alternatív iOS-alkalmazás és -bővítmény létezik.

A Microsoft egy kicsit más irányt követ. A versenyképes Skype szolgáltatás tulajdonosaként ez a cég nem fog ilyen könnyen megadni magát a WebRTC előtt. Ehelyett a Microsoft az ORTC (Object Real-Time Communications) nevű technológiát fejleszti az Internet Explorer számára.

A WebRTC-től való eltérések, mint például a szerverrel való kapcsolatfelvételhez szükséges különböző kodekek és protokollok, csekélyek, és idővel valószínűleg kiegészítik a WebRTC szabványt, amely magában foglalja ezeket a különbségeket. Így – szokás szerint – csak az Apple marad le.

Fénykép: gyártó vállalatok; goodluz/Photolia.com

A WebRTC egy böngésző által biztosított API, amely lehetővé teszi a P2P kapcsolat megszervezését és a böngészők közötti közvetlen adatátvitelt. Az interneten jó néhány oktatóanyag található arról, hogyan írhat saját videocsevegést, mikor WebRTC segítség. Itt van például egy cikk Habréról. Mindazonáltal mindegyik két kliens összekapcsolására korlátozódik. Ebben a cikkben megpróbálok beszélni arról, hogyan lehet kapcsolatot és üzenetváltást megszervezni három vagy több felhasználó között a WebRTC használatával.

Az RTCPeerConnection felület egy peer-to-peer kapcsolat két böngésző között. Három vagy több felhasználó összekapcsolásához meg kell szerveznünk egy mesh hálózatot (olyan hálózatot, amelyben minden csomópont az összes többi csomóponthoz kapcsolódik).
A következő sémát fogjuk használni:

1. Az oldal megnyitásakor ellenőrizzük a szobaazonosító meglétét hely.hash
2. Ha a szobaazonosító nincs megadva, hozzon létre egy újat
3. Egy jelzőszervernek küldünk egy üzenetet, hogy csatlakozni akarunk a megadott helyiséghez
4. A jelzőszerver új felhasználói értesítést küld a szobában lévő többi kliensnek
5. Azok az ügyfelek, akik már a szobában vannak, SDP-ajánlatot küldenek az újonnan érkezőnek
6. A jövevény válaszol az ajánlatra "s

0. Jelzőszerver

Mint ismeretes, bár a WebRTC lehetőséget biztosít a P2P kapcsolatra a böngészők között, a szolgáltatási üzenetek cseréjéhez még szükség van egy további szállításra. Ebben a példában az átvitel egy WebSocket-kiszolgáló, amelyet Node.JS-ben írnak a socket.io használatával:

var socket_io = igény("socket.io"); module.exports = function (szerver) ( var users = (); var io = socket_io(szerver); io.on("kapcsolat", function(socket) ( // Új felhasználót szeretne csatlakozni a szobához socket.on( "szoba ", function(message) ( var json = JSON. parse(message); // A socket hozzáadása a felhasználók listájához user = socket; if (socket.room !== undefined) ( // Ha a socket már valamelyik szobában hagyja el socket.leave(socket.room); ) // Adja meg a kért helyiséget socket.room = json.room; socket.join(socket.room); socket.user_id = json.id; // Küldés más ügyfeleknek ez a szoba üzenetet tartalmaz egy új résztvevőhöz való csatlakozásról socket.broadcast.to(socket.room).emit("new", json.id; )); // WebRTC-vel kapcsolatos üzenet (SDP ajánlat, SDP válasz vagy ICE jelölt) socket.on("webrtc", function(message) ( var json = JSON.parse(message); if (json.to !== undefined && users !== undefined) ( // Ha az üzenet a kiszolgáló által ismert címzett és ez a címzett üzenetet küld csak neki... users.emit("webrtc", üzenet); ) else ( // ...egyébként tekintsük az üzenetet broadcast socket.broadcast.to(socket.room).emit("webrtc", üzenet); ) ); // Valaki megszakította a kapcsolatot socket.on("disconnect", function() ( // Ha egy kliens megszakad, értesítsen másokat socket.broadcast.to(socket.room).emit("leave", socket.user_id); felhasználók törlése; )); )); );

1. index.html

Maga az oldal forráskódja meglehetősen egyszerű. Szándékosan nem figyeltem az elrendezésre és más szép dolgokra, mivel ez a cikk nem erről szól. Ha valaki szépíteni akarja, az nem lesz nehéz.

2.main.js

2.0. Hivatkozások lekérése oldalelemekre és WebRTC felületekre

var chatlog = document.getElementById("chatlog"); var üzenet = document.getElementById("üzenet"); var csatlakozási_szám = document.getElementById("kapcsolat_száma"); var room_link = document.getElementById("szoba_link");

A WebRTC felületek eléréséhez továbbra is böngésző előtagokat kell használnunk.

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

2.1. A szobaazonosító meghatározása

Itt szükségünk van egy függvényre, amely egyedi helyiséget és felhasználói azonosítót generál. Erre a célra az UUID-t fogjuk használni.

Függvény uuid () ( var s4 = function() ( return Math.floor(Math.random() * 0x10000).toString(16); ); return s4() + s4() + "-" + s4() + "-" + s4() + "-" + s4() + "-" + s4() + s4() + s4(); )

Most próbáljuk meg kinyerni a szobaazonosítót a címből. Ha ez nincs beállítva, akkor újat generálunk. Az oldalon megjelenítjük az aktuális szobára mutató hivatkozást, és ezzel egyidejűleg azonosítót generálunk az aktuális felhasználó számára.

VarROOM = location.hash.substr(1); if (!ROOM) ( ROOM = uuid(); ) room_link.innerHTML = "Hivatkozás a szobához"; varME = uuid();

2.2. webes aljzat

Az oldal megnyitásakor azonnal kapcsolódunk jelzőszerverünkhöz, kiküldjük a terembe való belépési kérelmet és megadjuk az üzenetkezelőket.

// Megadjuk, hogy az üzenet bezárásakor erről értesítést kell küldenünk a szervernek. var socket = io.connect("", ("sync disconnect on unload": true)); socket.on("webrtc", socketReceived); socket.on("new", socketNewPeer); // Azonnal küldjön egy kérést a szoba belépésére socket.emit("szoba", JSON.stringify((id: ME, room: ROOM))); // Segítő funkció a WebRTC függvényhez kapcsolódó címüzenetek küldéséhez sendViaSocket(type, message, to) ( socket.emit("webrtc", JSON.stringify((id: ME, to: to, type: type, data: message )) ));)

2.3. Peer kapcsolat beállításai

A legtöbb internetszolgáltató NAT-on keresztül biztosít internetkapcsolatot. Emiatt a közvetlen kapcsolat nem válik annyira triviálissá. A kapcsolat létrehozásakor meg kell adnunk a STUN és TURN szerverek listáját, amelyeket a böngésző megpróbál a NAT megkerülésére használni. Meghatározunk egy párat is további beállítások kapcsolódni.

Var szerver = ( iceServers: [ (url: "stun:23.21.150.121"), (url: "stun:stun.l.google.com:19302"), (url: "turn:numb.viagenie.ca", hitelesítő adatok: "ide megy a jelszava", felhasználónév: " [e-mail védett]") ] ); var options = ( opcionális: [ (DtlsSrtpKeyAgreement: true), // szükséges a Chrome és a Firefox közötti kapcsolathoz (RtpDataChannels: true) // szükséges a Firefoxban a DataChannels API használatához ] )

2.4. Új felhasználó csatlakoztatása

Amikor egy új társ kerül a szobába, a szerver üzenetet küld nekünk új. A fenti üzenetkezelőknek megfelelően a függvény meghívásra kerül socketNewPeer.

var peers = (); függvény socketNewPeer(data) ( peers = (candidateCache: ); // Új kapcsolat létrehozása var pc = new PeerConnection(server, options); // Inicializálja initConnection(pc, data, "ajánlat"); // Tárolja a peer a listában peers peers.connection = pc; // Hozzon létre egy DataChannel-t, amelyen keresztül üzenetek cserélődnek. var channel = pc.createDataChannel("mychannel", ()); channel.owner = adatok; peers.channel = csatorna; // Eseménykezelők telepítése bindEvents(channel); // SDP-ajánlat létrehozása pc.createOffer(function(ajánlat) ( pc.setLocalDescription(ajánlat); )); ) function initConnection(pc, id, sdpType) ( pc.onicecandidate = function ( event) ( if (event.candidate) ( // Ha új ICE jelöltet talál, adja hozzá a listához a peers.candidateCache.push(event.candidate); ) else ( // Ha a jelöltek felfedezése elkészült, a kezelő újra felhívásra kerül, de jelölt nélkül // Ebben az esetben először SDP ajánlatot küldünk a peernek, ill. Az SDP válasza (függvényparamétertől függően)... sendViaSocket(sdpType, pc.localDescription, id); // ...és ezután az összes korábban talált ICE jelölt (var i = 0; i< peers.candidateCache.length; i++) { sendViaSocket("candidate", peers.candidateCache[i], id); } } } pc.oniceconnectionstatechange = function (event) { if (pc.iceConnectionState == "disconnected") { connection_num.innerText = parseInt(connection_num.innerText) - 1; delete peers; } } } function bindEvents (channel) { channel.onopen = function () { connection_num.innerText = parseInt(connection_num.innerText) + 1; }; channel.onmessage = function (e) { chatlog.innerHTML += "

"; }; }

2.5. SDP ajánlat, SDP válasz, ICE jelölt

Ha ezek közül az üzenetek egyike érkezik, felhívjuk a megfelelő üzenetkezelőt.

Függvény socketReceived(data) ( var json = JSON.parse(data); kapcsoló (json.type) ( "jelölt" eset: remoteCandidateReceived(json.id, json.data); szünet; kis- és nagybetű "ajánlat": remoteOfferReceived(json. id, json.data); break; kis- és nagybetű "válasz": remoteAnswerReceived(json.id, json.data); break; ) )

2.5.0 SDP ajánlat

function remoteOfferReceived(id, data) ( createConnection(id); var pc = peers.connection; pc.setRemoteDescription(new SessionDescription(data)); pc.createAnswer(function(answer) ( pc.setLocalDescription(answer); )); ) függvény 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 SDP válasz

függvény remoteAnswerReceived(id, data) ( var pc = peers.connection; pc.setRemoteDescription(new SessionDescription(data)); )

2.5.2 ICE jelölt

függvény remoteCandidateReceived(id, data) ( CreateConnection(id); var pc = peers.connection; pc.addIceCandidate(new IceCandidate(data)); )

2.6. Üzenet küldése

A gomb megnyomásával Küld függvényt hívják üzenet küldése. Mindössze annyit tesz, hogy végigmegy a partnerek listáján, és megpróbálja mindenkinek elküldeni a megadott üzenetet.

Napjainkban a WebRTC a "forró" technológia az audio- és videostreamelésre a böngészőkben. A konzervatív technológiák, mint pl HTTP Streamingés a Flash alkalmasabb a rögzített tartalom (video on demand) terjesztésére, és lényegesen alulmúlja a WebRTC-t valós idejű és online adások tekintetében, pl. ahol minimális videó késleltetés szükséges, így a nézők „élőben” láthatják, mi történik.

A kiváló minőségű valós idejű kommunikáció lehetősége magából a WebRTC architektúrából adódik, ahol az UDP protokollt használják a videó folyamok továbbítására, amely a minimális késleltetésű videó továbbítás standard alapja, és széles körben használatos a valós idejű kommunikációs rendszerekben.

A kommunikációs késleltetés fontos élő közvetítési rendszerekben, webináriumokban és más alkalmazásokban, ahol interaktív kommunikációra van szükség a videó forrásával, a végfelhasználókkal és a megoldással.

Egy másik jó ok a WebRTC kipróbálására határozottan trend. Ma minden Android Chrome böngésző támogatja ezt a technológiát, amely biztosítja, hogy több millió eszköz álljon készen az adás megtekintésére további szoftverek és konfigurációk telepítése nélkül.

A WebRTC technológia működési tesztelésére és egy egyszerű online adás indítására a Flashphoner WebRTC Media & Broadcasting Server szerver szoftvert használtuk. A funkciók deklarálják a WebRTC adatfolyamok egy-a többhez módban történő sugárzásának lehetőségét, valamint az IP-kamerák és a videó megfigyelőrendszerek támogatását az RTSP protokollon keresztül; Ebben az áttekintésben a web-web adásokra és azok funkcióira fogunk összpontosítani.

WebRTC Media & Broadcasting Server telepítése

Mert azért Windows rendszerek nem volt szerververzió, és nem akartam olyan virtuális gépet telepíteni, mint a VMWare + Linux, tesztelni az online adásokat Windows otthon számítógép meghibásodott. Az időmegtakarítás érdekében úgy döntöttünk, hogy példát veszünk a felhőalapú tárhelyszolgáltatásról, például:

Ez egy Centos x86_64 6.5-ös verzió volt, minden előre telepített szoftver nélkül egy amszterdami adatközpontban. Így csak egy szerver és ssh hozzáférés áll rendelkezésünkre. Azoknak, akik ismerik konzolparancsok Linux, telepítés WebRTC szerverek azt ígéri, hogy egyszerűen és fájdalommentesen elmúlik. Szóval mit csináltunk:

1. Archívum letöltése:

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

2. Kicsomagolás:

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

3. Telepítés:

$cd FlashphonerWebCallServer

A telepítés során adja meg a szerver IP-címét: XXX.XXX.XXX.XXX

4. Licenc aktiválása:

$cd /usr/local/FlashphonerWebCallServer/bin

$./activation.sh

5. WCS szerver indítása:

$service webcallserver start

6. Napló ellenőrzése:

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

7. Ellenőrizze, hogy két folyamat működik-e:

$ps aux | grep Flashphoner

A telepítési folyamat befejeződött.

WebRTC élő közvetítések tesztelése

A közvetítések tesztelése egyszerű dolognak bizonyult. A szerveren kívül van egy webes kliens is, amely tucatnyi Javascript, HTML és CSS fájlból áll, és a telepítés során mi telepítettük a /var/www/html mappába. Csak annyit kellett tenni, hogy a flashphoner.xml konfigurációba be kellett írni a szerver IP-címét, hogy a webkliens HTML5 Websocketeken keresztül tudjon kapcsolatot létesíteni a szerverrel. Ismertesse a tesztelési folyamatot.

1. Nyissa meg a tesztkliens index.html oldalát a Chrome böngészőben:

2. A sugárzás elindításához kattintson a képernyő közepén található "Start" gombra.
Mielőtt ezt megtenné, meg kell győződnie arról, hogy a webkamera csatlakoztatva van, és használatra kész. A webkamerával szemben nincs különösebb követelmény, például szabványos beépített laptop kamerát használtunk 1280 × 800 felbontással.

A Chrome böngésző minden bizonnyal hozzáférést fog kérni a kamerához és a mikrofonhoz, hogy a felhasználó megértse, hogy videója elküldésre kerül az internetes szerverre, és lehetővé teszi számára ezt.

3. Az interfész a videofolyam sikeres sugárzását jelenti a kamerából a WebRTC szerverre. A jobb felső sarokban a jelző jelzi, hogy a stream a szerverre megy, az alsó sarokban pedig egy "Stop" gomb található a videó küldésének leállításához.

Vessen egy pillantást az alábbi linkre. Egyedi azonosítót tartalmaz ehhez az adatfolyamhoz, így bárki csatlakozhat a nézethez. Csak nyissa meg ezt a hivatkozást egy böngészőben. A vágólapra másoláshoz kattintson a "Másolás" gombra.

Az olyan valós alkalmazásokban, mint a webináriumok, előadások, online videoközvetítések vagy interaktív tévéadások, a fejlesztőknek meg kell valósítaniuk ennek az azonosítónak a szétosztását a nézők bizonyos csoportjai számára, hogy csatlakozhassanak a kívánt streamekhez, de ez az alkalmazás logikája. WebRTC média- és műsorszóró szerver nem érinti, csak a videó terjesztésével foglalkozik.

5. A kapcsolat létrejön, és a néző látja az adatfolyamot a képernyőn. Most már elküldheti a linket valakinek, leállíthatja a stream lejátszását vagy engedélyezheti teljes képernyős mód a jobb alsó sarokban található vezérlők segítségével.

WebRTC szerver tesztelési eredmények online adásokhoz

A tesztek során a várakozási idő tökéletesnek tűnt. Az adatközpontba érkező ping körülbelül 100 ezredmásodperc volt, és a késés nem volt látható a szemnek. Innentől kezdve feltételezhetjük, hogy a valódi késleltetés ugyanaz, mint 100 plusz-mínusz néhány tíz milliszekundum a pufferelési időre. A Flash videóhoz képest ezekben a tesztekben a Flash nem teljesít olyan jól, mint a WebRTC. Tehát, ha egy hasonló hálózaton mozgatja a kezét, akkor a mozgás a képernyőn csak egy/két másodperc múlva látható.

A minőséggel kapcsolatban megjegyezzük, hogy néha meg lehet különböztetni a kockákat a mozgásokon. Ez összhangban van a VP8 kodek természetével, és fő célja a valós idejű videokommunikáció biztosítása elfogadható minőségben és kommunikációs késések nélkül.

A szerver telepítése és konfigurálása meglehetősen egyszerű, nem igényel komolyabb készségeket a futtatásához, kivéve a Linux ismerete haladó szinten, aki képes parancsokat végrehajtani a konzolról ssh-n keresztül és használni szöveg szerkesztő. Ennek eredményeként sikerült beállítani egy-a-többhöz online adást a böngészők között. További nézők csatlakoztatása sem okozott problémát.

A webináriumok és online adások közvetítésének minősége meglehetősen elfogadhatónak bizonyult. Csak a videó felbontása okozott néhány kérdést. A kamera támogatja az 1280x800-as felbontást, de a tesztképen a felbontás nagyon hasonló a 640x480-hoz. Úgy tűnik, ezt a kérdést tisztázni kell a fejlesztőkkel.

Videó a webkameráról történő tesztelésről
WebRTC szerveren keresztül

Ennek a cikknek az a célja, hogy megismerkedjen annak felépítésével és működési elvével egy peer-to-peer videocsevegés (p2p videocsevegés) demómintáján. Erre a célra a többfelhasználós peer-to-peer videocsevegés demót használjuk a webrtc.io-demo. Letölthető a következő linkről: https://github.com/webRTC/webrtc.io-demo/tree/master/site.

Meg kell jegyezni, hogy a GitHub egy webprojektek közös fejlesztésére szolgáló webhely vagy webszolgáltatás. Ezen a fejlesztők közzétehetik fejlesztéseik kódjait, megvitathatják azokat és kommunikálhatnak egymással. Ezenkívül néhány nagy IT-cég ezen az oldalon tárolja hivatalos adattárait. A szolgáltatás ingyenes a nyílt forráskódú projektek számára. A GitHub nyílt forráskódú könyvtárak tárháza.

Tehát a GitHubról letöltött egy peer-to-peer videocsevegés demómintáját a C lemezre helyezzük. személyi számítógép a "webrtc_demo" alkalmazásunkhoz létrehozott könyvtárban.

Rizs. egy

Amint a szerkezetből (1. ábra) következik, a peer-to-peer videocsevegés a JavaScript programozási nyelven implementált kliens script.js és szerver server.js szkriptekből áll. Szkript (könyvtár) webrtc.io.js (CLIENT) - biztosítja a böngészők közötti valós idejű kommunikáció megszervezését egy peer-to-peer séma szerint: "kliens-ügyfél", valamint webrtc.io.js (CLIENT) és webrtc .io.js (SERVER), a WebSocket protokoll használatával duplex kommunikációt biztosítanak a böngésző és a webszerver között a "kliens-szerver" architektúra használatával.

A webrtc.io.js (SERVER) parancsfájl a webrtc.io könyvtárban található, és a node_modules\webrtc.io\lib könyvtárban található. Az index.html videocsevegési felület HTML5-ben és CSS3-ban van megvalósítva. A webrtc_demo alkalmazásfájlok tartalma megtekinthető valamelyik html szerkesztővel, például "Notepad++".

Ellenőrizzük a videocsevegés működési elvét fájlrendszer PC. A szerver (server.js) PC-n történő futtatásához telepítenie kell a node.js futási környezetet. A Node.js lehetővé teszi JavaScript kód futtatását a böngészőn kívül. A node.js fájl letölthető a következő linkről: http://nodejs.org/ (verzió 0.10.13, 2013. 07. 15.). A Főoldal node.org webhelyen kattintson a letöltés gombra, és lépjen a http://nodejs.org/download/ oldalra. Mert Windows felhasználók először töltse le a win.installer (.msi) fájlt, majd futtassa a win.installer (.msi) programot a számítógépen, és telepítse a nodejs-t és az „npm csomagkezelőt” a Program Files könyvtárba.

Rizs. 2

Így a node.js egy JavaScript fejlesztői és végrehajtási környezetből, valamint egy sor belső modulból áll, amelyek az npm csomagkezelővel vagy csomagkezelővel telepíthetők.

A modulok telepítéséhez szükséges parancs sor az alkalmazáskönyvtárból (például "webrtc_demo") hajtsa végre a következő parancsot: npm telepítési modul_neve. A modulok telepítése során az npm manager létrehoz egy node_modules mappát abban a könyvtárban, ahonnan a telepítés történt. Futás közben a nodejs automatikusan tartalmazza a modulokat a node_modules könyvtárból.

Tehát a node.js telepítése után nyissa meg a parancssort, és frissítse az expressz modult a webrtc_demo könyvtár node_modules mappájában az npm csomagkezelő segítségével:

C:\webrtc_demo>npm install express

Az expressz modul a node.js vagy webalkalmazás-fejlesztő platform webes keretrendszere. Az expressz globális eléréséhez a következőképpen telepítheti: npm install -g express.

Ezután frissítjük a webrtc.io modult:

C:\webrtc_demo>npm telepítse a webrtc.io-t

Ezután a parancssorban elindítjuk a szervert: server.js:

C:\webrtc_demo>nodeserver.js

Rizs. 3

Minden, a szerver sikeresen működik (3. ábra). Most egy webböngészővel kapcsolatba léphet a szerverrel ip-címen, és letöltheti az index.html weboldalt, amelyről a webböngésző kibontja a kliens szkript kódját - script.js és webrtc.io.js szkriptkód, és kivégezni őket. Ahhoz, hogy a peer-to-peer videocsevegés működjön (a kapcsolat létrehozásához két böngésző között), két webrtc-t támogató böngészőnek fel kell vennie a kapcsolatot a node.js-n futó jelkiszolgálóval ip-címen.

Ennek eredményeként megnyílik a kommunikációs alkalmazás (video chat) kliens részének felülete a kamera és a mikrofon hozzáférési engedélykérésével (4. ábra).

Rizs. négy

Az "Engedélyezés" gombra kattintás után a kamera és a mikrofon csatlakoztatva van a multimédiás kommunikációhoz. Emellett a videocsevegési felületen keresztül szöveges adatokkal is kommunikálhatunk (5. ábra).

Rizs. 5

Megjegyzendő . A szerver jelzés, és főként arra szolgál, hogy kapcsolatot létesítsen a felhasználók böngészői között. A WebRTC jelzést biztosító server.js szkript Node.js-t használ a futtatáshoz.