WebRTC. Videokonferencia a böngészőben. Többfelhasználós csevegés a WebRTC Webrtc hangcsevegés használatával

Preambulum. P2P videocsevegés bekapcsolva WebRTC alap a Skype és más kommunikációs eszközök alternatívája. A WebRTC-n alapuló p2p videocsevegés fő elemei a böngésző és a kapcsolattartó szerver. A P2P videocsevegés olyan peer-to-peer videocsevegés, amelyben a szerver nem vesz részt az információáramlás továbbításában. Az információk közvetlenül a felhasználók böngészői (társak) között, anélkül kerülnek átvitelre további programokat. A p2p videocsevegés a böngészők mellett kapcsolattartó szervereket is használ, amelyek célja a felhasználók regisztrálása, adatok tárolása és a felhasználók közötti váltás biztosítása. A legújabb WebRTC és HTML5 technológiát támogató böngészők azonnali szöveges üzenetküldést és fájlátvitelt, valamint hang- és videokommunikációt biztosítanak IP-hálózatokon keresztül.

Tehát a csevegés, a webes csevegés, a hang- és videocsevegés webes felületen, az IMS, a VoIP olyan szolgáltatások, amelyek kompozit csomagkapcsolt hálózatokon keresztül online kommunikációt biztosítanak. A kommunikációs szolgáltatásokhoz általában szükség van kliens alkalmazások telepítésére a felhasználói eszközökre (számítógépekre, okostelefonokra stb.), vagy bővítmények és bővítmények telepítésére a böngészőkben. A szolgáltatásoknak saját kommunikációs hálózataik vannak, amelyek többsége kliens-szerver architektúrára épül.

A kommunikációs szolgáltatások az IMS-től eltérő alkalmazások, amelyekbe a hang-, videó-, adat- és szövegcsatornák nincsenek integrálva. Az egyes szolgáltatások hálózataiban, . Megjegyzendő, hogy ezek az alkalmazások nem működhetnek egyszerre több kommunikációs hálózatban, pl. Az alkalmazások általában nem tudnak kommunikálni egymással, ezért minden kommunikációs hálózathoz külön alkalmazást kell telepíteni.

A valós idejű kommunikációs szolgáltatások (chat, telefonálás, videokonferencia) integrálásának problémája, pl. a hang-, videó-, adatcsatornák integrációja és az ezekhez való hozzáférés egy alkalmazással (böngészővel) a WebRTC protokollon alapuló peer-to-peer vagy p2p videocsevegésben (peer-to-peer, point-to-point) megoldható. Lényegében a WebRTC-t támogató böngésző egyetlen felületté válik az összes felhasználói eszköz számára (számítógép, okostelefon, iPad, IP-telefon, mobiltelefonok stb.), amelyek kommunikációs szolgáltatásokkal működnek.

A WebRTC biztosítja az összes valós idejű kommunikációt biztosító technológia megvalósítását a böngészőben. A p2p videocsevegés lényege, hogy a multimédiás és szöveges adatok közvetlenül átvitelre kerülnek a felhasználók böngészői között (távoli peering), szerver vagy további programok részvétele nélkül. Így a böngészők nemcsak szinte mindegyikhez biztosítanak hozzáférést információs források Internet, amelyeket szervereken tárolnak, de egyúttal minden valós idejű kommunikációs szolgáltatáshoz és levelezési szolgáltatáshoz (hangposta, email, SMS stb.)

A p2p videocsevegés szerverei (kapcsolati szerverei) kizárólag a felhasználók regisztrálására, a felhasználók adatainak tárolására és a felhasználók böngészői közötti kapcsolat létrehozására (váltásra) szolgálnak. Az első p2p videocsevegést flash technológiával valósították meg. A Flash p2p videocsevegéseket például az alábbiakban használják a közösségi hálózatokon. Flash p2p videocsevegés nem biztosít jó minőség multimédiás adatok továbbítása. Ezen túlmenően, ha a mikrofonból és a videokamerából hang- és videofolyamot kíván továbbítani p2p flash videocsevegésben, telepítenie kell flash plugin egy webböngészőbe.

A távközlési szolgáltatások új generációja azonban magában foglalja a webes kommunikációt is, amely csak a WebRTC protokollokat és a HTML5 specifikációt támogató böngészőket és kapcsolattartó szervereket használ az interneten keresztüli kommunikációhoz. Bármely ilyen böngészővel felszerelt felhasználói eszköz (PC, iPad, okostelefonok stb.) kiváló minőségű hang- és videohívást, valamint azonnali szöveges üzenetek és fájlok átvitelét tud biztosítani.

Tehát a webes kommunikáció új technológiája (p2p chat, video chat) a WebRTC protokoll. A WebRTC, valamint a HTML5, CSS3 és JavaScript lehetővé teszi különféle webes alkalmazások létrehozását. A WebRT a webes kommunikáció (peer-to-peer hálózatok) valós idejű megszervezésére szolgál egy peer-to-peer architektúra segítségével. A WebRTC-n alapuló P2P-csevegések fájlátvitelt, valamint szöveges, hang- és videokommunikációt biztosítanak a felhasználók között az interneten keresztül, kizárólag webböngészők használatával, külső kiegészítők és beépülő modulok használata nélkül.

A p2p chatekben a szervert csak két böngésző közötti p2p kapcsolat létrehozására használják. A WebRTC protokollon alapuló p2p chat kliens részének létrehozásához HTML5, CSS3 és JavaScript használatos. Az ügyfélalkalmazás a WebRTC API-n keresztül kommunikál a böngészőkkel.

A WebRTC-t három JavaScript API valósítja meg:

• RTCPeerConnection;
• MediaStream(getUserMedia);
• RTCDataChannel.

A böngészők az UDP-n futó SRTP-protokoll segítségével továbbítják a médiaadatokat. Mivel a NAT problémákat okoz a NAT útválasztók mögötti böngészőknek (klienseknek), amelyek p2p kapcsolatot használnak az interneten keresztül, a STUN-t a NAT fordítók megkerülésére használják. A STUN egy kliens-szerver protokoll, amely az UDP szállítási protokollon felül fut. A p2p chatekben általában egy nyilvános STUN szervert használnak, és az onnan kapott információkat két böngésző közötti UDP-kapcsolatra használják fel, ha azok NAT mögött vannak.

Példák a WebRTC alkalmazások megvalósítására (p2p csevegés, hang- és videocsevegés):
1. P2P video chat Bistri (egy kattintásos video chat, p2p chat), WebRTC alapú, a Bistriben nyitható meg. A Bistri a böngészőben további programok és bővítmények telepítése nélkül működik. A munka lényege a következő: nyisson meg egy p2p video chat a megadott link segítségével, miután a megnyíló felületen regisztrált, hívjon meg partnereket, majd a peer kliensek listájából válassza ki az online partnert, és kattintson a „videohívásra ” gombot.

Ennek eredményeként a MediaStream (getUserMedia) rögzíti a mikrofont + webkamerát, a szerver pedig jelzőüzeneteket vált a kiválasztott partnerrel. A jelzőüzenetek cseréje után a PeerConnection API csatornákat hoz létre a hang- és videofolyamok továbbításához. Ezenkívül a Bistri azonnali szöveges üzeneteket és fájlokat továbbít. ábrán. Az 1. ábrán a Bistri p2p videocsevegési felület képernyőképe látható.

Rizs. 1. P2P video chat Bistri

2. Twelephone (p2p video chat, p2p chat, SIP Twelephone) - ez a HTML5 és WebRTC alapú kliens alkalmazás, amely lehetővé teszi hang- és videohívások kezdeményezését, valamint azonnali szöveges üzenetek küldését, pl. A Twelephone teszt p2p-csevegést, videocsevegést és SIP Twelephone-t tartalmaz. Meg kell jegyezni, hogy a Twelephone támogatja a SIP protokollt, és most már kezdeményezhet és fogadhat hang- és videohívásokat SIP telefonokról Twitter-fiókja telefonszámként. Kívül, szöveges üzenetek be lehet lépni hanggal a mikrofonon keresztül, a hangfelismerő program pedig az „Üzenet küldése” sorba írja be a szöveget.

A Twelephone egy böngészőalapú internetes telefonálás Google Chrome, a 25-ös verziótól kezdve, további nélkül szoftver. A Twelephone-t Chris Matthieu fejlesztette ki. A Twelephone háttérrendszer a Node.js-re épül. A kiszolgáló (kapcsolattartó szerver) csak p2p kapcsolat létrehozására szolgál két böngésző vagy WebRTC kliens között. A Twelephone alkalmazás nem rendelkezik saját hitelesítési eszközeivel, de egy fiókhoz való kapcsolódásra összpontosít ( fiókot) Twitteren.

ábrán. A 2. ábrán a Twelephone p2p videocsevegési felület képernyőképe látható.

Rizs. 2. P2P Twelephone

3. Csoportos p2p videocsevegés A Conversat.io a legújabb WebRTC és HTML5 technológiákra épül. A Conversat videocsevegés a SimpleWebRTC könyvtáron alapul, és legfeljebb 6 egyenrangú kliens közötti kommunikációra szolgál egy szobában (kommunikációhoz a „Beszélgetés elnevezése” sorban tüntesse fel a társas kliensek közös helyiségének nevét). P2P videocsevegés A Conversat kommunikációs szolgáltatásokat nyújt a felhasználóknak a kapcsolattartó szerveren való regisztráció nélkül. ábrán. A 3. ábra a Conversat p2p videocsevegési felületének képernyőképet mutatja.

Rizs. 3. Csoportos P2P videocsevegés Conversat.io

A WebRTC-n alapuló P2P-videocsevegésben való részvételhez a felhasználóknak telepített böngészővel kell rendelkezniük, amely támogatja a WebRTC protokollt és a HTML5 specifikációt. Jelenleg a Google Chrome böngészők, a 25-ös verziótól kezdve, és Mozilla Firefox A Nightly támogatja a WebRTC protokollt és a HTML5 specifikációt. A WebRTC alkalmazások kép- és hangátviteli minőségben felülmúlják a Flash alkalmazásokat.

A WebRTC-ről szóló anyagok többsége a kódolás alkalmazási szintjére összpontosít, és nem járul hozzá a technológia megértéséhez. Próbáljunk meg mélyebbre menni, és megtudjuk, hogyan jön létre a kapcsolat, mi a munkamenet-leíró és a jelöltek, miért van szükség STUN és TURN szerverekre.

WebRTC Bevezetés

A WebRTC egy böngésző-orientált technológia, amely lehetővé teszi két kliens összekapcsolását videó adatátvitelhez. A fő jellemzők a böngészők belső támogatása (nincs szükség harmadik féltől származó technológiákra, például az Adobe Flash-re), valamint a kliensek csatlakoztatásának lehetősége további szerverek használata nélkül - peer-to-peer kapcsolat (a továbbiakban: p2p).

A p2p kapcsolat létrehozása meglehetősen nehéz feladat, mivel a számítógépek nem mindig rendelkeznek nyilvános IP-címekkel, azaz az interneten található címekkel. Az IPv4-címek kis száma miatt (és biztonsági okokból) kifejlesztették a NAT-mechanizmust, amely lehetővé teszi például otthoni használatra privát hálózatok létrehozását. Sok otthoni útválasztó már támogatja a NAT-ot, és ennek köszönhetően minden otthoni eszköz hozzáfér az internethez, bár az internetszolgáltatók általában egy IP-címet biztosítanak. A nyilvános IP-címek egyediek az interneten, de a privátok nem. Ezért nehéz a p2p csatlakoztatása.

Ennek jobb megértéséhez tekintsünk három helyzetet: mindkét csomópont ugyanazon a hálózaton van (1. ábra), mindkét csomópont különböző hálózaton (az egyik privát, a másik nyilvános) (2. ábra), és mindkét csomópont különböző magánhálózatban van. ugyanazokat az IP-címeket (3. ábra).

1. ábra: Mindkét csomópont ugyanazon a hálózaton

2. ábra: Csomópontok különböző hálózatokban (egy privát, egy nyilvános)

3. ábra: Csomópontok különböző magánhálózatokban, de számszerűen azonos címekkel

A fenti ábrákon a kétkarakteres jelölés első betűje a csomópont típusát jelöli (p = peer, r = router). Az első képen a helyzet kedvező: hálózatuk csomópontjait teljes mértékben azonosítják a hálózati IP-címek, így közvetlenül tudnak kapcsolódni egymáshoz. A második ábrán két különböző hálózat látható hasonló csomópontszámmal. Itt jelennek meg a routerek (routerek), amelyeknek kettő van hálózati felület– a hálózaton belül és a hálózaton kívül. Ezért van két IP-címük. A normál csomópontoknak csak egy interfészük van, amelyen keresztül csak a hálózatukon belül tudnak kommunikálni. Ha a hálózatukon kívülre továbbítanak adatokat, akkor csak a routeren belüli NAT-ot használva (router) és így mások számára láthatóak a router IP-címe alatt – ez az övék külső IP-cím. Tehát a p1 csomópont rendelkezik belső IP = 192.168.0.200 És külső IP = 10.50.200.5 , és az utolsó cím is külső lesz a hálózat összes többi csomópontján. Hasonló a helyzet a p2 csomópontnál. Ezért kommunikációjuk lehetetlen, ha csak belső (saját) IP-címeiket használják. Használhat külső címeket, azaz útválasztó címeket, de mivel ugyanabban a magánhálózatban minden csomópontnak ugyanaz a külső címe, ez meglehetősen nehéz. Ezt a problémát a NAT mechanizmus segítségével lehet megoldani

Mi történik, ha úgy döntünk, hogy a csomópontokat belső címeiken keresztül kapcsoljuk össze? Az adatok nem hagyják el a hálózatot. A hatás fokozása érdekében elképzelheti az utolsó ábrán látható helyzetet - mindkét csomópontnak ugyanaz a belső címe. Ha ezeket használják kommunikációra, akkor minden csomópont önmagával kommunikál.

A WebRTC sikeresen megbirkózik az ilyen problémákkal az ICE protokoll használatával, amely azonban további szerverek (STUN, TURN) használatát igényli. Minderről bővebben alább.

A WebRTC két fázisa

Ha két csomópontot szeretne összekapcsolni a WebRTC protokollon keresztül (vagy csak az RTC-n keresztül, ha két iPhone kommunikál), el kell végeznie néhány előzetes lépést a kapcsolat létrehozásához. Ez az első fázis – a kapcsolat létrehozása. A második fázis a videó adatátvitel.

Érdemes rögtön elmondani, hogy bár a WebRTC technológia sokat használ különféle módokon kommunikáció (TCP és UDP), és rugalmas váltást biztosít közöttük, ez a technológia nem rendelkezik kapcsolati adatok továbbítására szolgáló protokollal. Nem meglepő, mivel két p2p csomópont összekapcsolása nem olyan egyszerű. Ezért szükséges, hogy legyen néhány további olyan adatátviteli módszer, amely semmilyen módon nem kapcsolódik a WebRTC-hez. Lehet socket átvitel, HTTP protokoll, még az is lehet SMTP protokoll vagy Orosz Posta. Ez az átviteli mechanizmus a kezdeti adatot hívják jel. Nem kell sok információt közölni. Minden adatot szöveges formában továbbítanak, és két típusra oszthatók - SDP és Ice Candidate. Az első típus logikai, a második pedig fizikai kapcsolat létrehozására szolgál. Minderről később, de egyelőre csak fontos megjegyezni, hogy a WebRTC olyan információkat ad nekünk, amelyeket egy másik csomóponthoz kell továbbítani. Amint minden szükséges információt továbbítunk, a csomópontok képesek lesznek kapcsolódni, és a segítségünkre már nincs szükség. Tehát a jelzőmechanizmus, amelyet megvalósítanunk kell külön, használva lesz csak csatlakoztatva, de nem használják videoadatok átviteléhez.

Tehát nézzük az első fázist - a kapcsolat létrehozásának fázisát. Több pontból áll. Nézzük először ezt a fázist a kapcsolatot kezdeményező csomópontnál, majd a várakozónál.

• Kezdeményező (hívó):
• Ajánlat a videó adatátvitel elindítására (createOffer)
• SDP SDP beszerzése)
• Jégjelöltjének fogadása Ice jelölt )
• Hívásvárakoztatás (hívott):
• Helyi (saját) médiafolyam fogadása és továbbításra való beállítása (getUserMediaStream)
• Ajánlat fogadása videó adatátvitel megkezdésére és válasz létrehozására (createAnswer)
• Az SDP objektum fogadása és átadása a jelzőmechanizmuson (SDP)
• Jégjelölt objektumok fogadása és átadása jelzőmechanizmuson (Jégjelölt)
• Távoli (idegen) médiafolyam fogadása és megjelenítése a képernyőn (onAddStream)

Az egyetlen különbség a második pontban van.

A lépések látszólagos bonyolultsága ellenére valójában három van belőlük: saját médiafolyam küldése (1. tétel), kapcsolati paraméterek beállítása (2-4. tétel), valaki más médiafolyamának fogadása (5. tétel). A legnehezebb lépés a második lépés, mert ez két részből áll: az alapításból fizikaiÉs logikus kapcsolatokat. Az első jelzi pálya, amelyen keresztül a csomagoknak haladniuk kell, hogy az egyik hálózati csomópontból a másikba kerüljenek. A második jelzi videó/audio paraméterek– milyen minőséget, milyen kodeket használjunk.

Mentálisan a createOffer vagy a createAnswer szakasznak kapcsolódnia kell az SDP és az Ice jelölt objektumok átadásának szakaszaihoz.

Alapvető entitások Médiafolyamok (MediaStream)

A fő entitás a médiafolyam, vagyis a video- és hangadatok, kép és hang folyama. Kétféle médiafolyam létezik – helyi és távoli. A helyi bemeneti eszközöktől (kamera, mikrofon), a távoli pedig a hálózaton keresztül fogad adatokat. Így minden csomópontnak van helyi és távoli szála is. A WebRTC-ben van egy MediaStream interfész a streamekhez, és van egy LocalMediaStream alinterfész is, kifejezetten a helyi adatfolyamokhoz. JavaScriptben csak az elsővel találkozhatunk, de ha libjingle-t használunk, akkor a másodikkal is találkozhatunk.

A WebRTC meglehetősen zavaros hierarchiával rendelkezik egy szálon belül. Minden adatfolyam állhat több médiasávból (MediaTrack), amelyek viszont több médiacsatornából (MediaChannel) állhatnak. És több médiafolyam is létezhet.

Nézzünk meg mindent sorban. Ehhez tartsunk szem előtt néhány példát. Tegyük fel, hogy nem csak egy videót szeretnénk közvetíteni magunkról, hanem az asztalunkról is, amelyen egy papírlap hever, amire írunk valamit. Szükségünk lesz két videóra (us + asztal) és egy hangra (us). Nyilvánvaló, hogy minket és a táblázatot különböző szálakba kell osztani, mert ezek az adatok valószínűleg gyengén függenek egymástól. Ezért két MediaStreamünk lesz – egyet nekünk, egyet pedig az asztalnak. Az első video- és hangadatokat is tartalmaz, a második pedig csak videót (4. ábra).

4. ábra: Két különböző médiafolyam. Egyet nekünk, egyet az asztalunknak

Azonnal világos, hogy egy médiafolyamnak legalább tartalmaznia kell az adatok tárolásának képességét különböző típusok- videó és hang. Ezt figyelembe veszi a technológia, ezért minden adattípust a MediaTrack médiasávon keresztül valósítanak meg. A médiasávnak van egy speciális tulajdonsága , amely meghatározza, hogy videó vagy hang (5. ábra)

5. ábra: A médiafolyamok médiasávokból állnak

Hogyan történik minden a programban? Két médiafolyamot fogunk létrehozni. Ezután létrehozunk két videosávot és egy hangsávot. Hozzáférjünk a kamerákhoz és a mikrofonhoz. Mondjuk el minden sávnak, hogy melyik eszközt használja. Adjunk hozzá egy videó- ​​és hangsávot az első médiafolyamhoz, és egy videosávot egy másik kamerától a második médiafolyamhoz.

De hogyan különböztetjük meg a médiafolyamokat a kapcsolat másik végén? Ehhez minden médiafolyamnak van egy címke tulajdonsága - az adatfolyam címkéje, neve (6. ábra). A médiasávok ugyanazzal a tulajdonsággal rendelkeznek. Bár első pillantásra úgy tűnik, hogy a videót más módon is meg lehet különböztetni a hangtól.

6. ábra: A médiafolyamokat és -sávokat címkék azonosítják

Tehát, ha a médiasávok azonosíthatók egy címkén keresztül, akkor miért kell két médiafolyamot használnunk a példánkban egy helyett? Végül is egy médiafolyamot továbbíthat, de abban különböző sávokat használhat. Eljutottunk a médiafolyamok egy fontos tulajdonságához – hozzájuk szinkronizálni médiasávok. A különböző médiafolyamok nincsenek szinkronizálva egymással, hanem az egyes médiafolyamokon belül az összes sáv egyszerre játsszák.

Így ha azt szeretnénk, hogy szavaink, arcérzelmeink és papírlapunk egyszerre szólaljon meg, akkor érdemes egy médiafolyamot használni. Ha ez nem annyira fontos, akkor jövedelmezőbb a különböző folyamok használata - a kép simább lesz.

Ha néhány műsorszámot le kell tiltani az átvitel során, használhatja a médiasáv engedélyezése tulajdonságát.

Végül érdemes a sztereó hangzásra gondolni. Mint tudják, a sztereó hang két különböző hang. És ezeket külön is át kell adni. Ehhez a médiacsatornákat használják. Egy média hangsávnak sok csatornája lehet (például 6, ha 5+1 hangra van szüksége). Természetesen a médiasávokon belül is vannak csatornák. szinkronizálva. Videóhoz általában csak egy csatornát használnak, de több is használható, például átfedő reklámozásra.

Összefoglalni: Médiafolyamot használunk video- és hangadatok továbbítására. Az egyes médiafolyamokon belül az adatok szinkronizálva vannak. Több médiafolyamot is használhatunk, ha nincs szükségünk szinkronizálásra. Minden médiafolyamon belül kétféle médiasáv található – videóhoz és hanghoz. Általában nem több mint két sáv, de lehet több is, ha több különböző videót kell továbbítania (a beszélgetőpartnerről és az asztaláról). Minden sáv több csatornából állhat, amelyeket általában csak sztereó hangzásra használnak.

A legegyszerűbb videocsevegési helyzetben egy helyi médiafolyamunk lesz, amely két sávból áll - egy videosávból és egy hangsávból, amelyek mindegyike egy fő csatornából áll. A videosáv a kameráért, a hangsáv a mikrofonért, a médiafolyam pedig mindkettő tárolója.

Munkamenet-leíró (SDP)

A különböző számítógépeken mindig más kamerák, mikrofonok, videokártyák és egyéb berendezések lesznek. Sok lehetőségük van. Mindezt össze kell hangolni két hálózati csomópont közötti adatátvitelhez. A WebRTC ezt automatikusan elvégzi és létrehozza különleges tárgy– SDP munkamenet leíró. Adja át ezt az objektumot egy másik csomópontnak, és a médiaadatok átvihetők. Csak egy másik csomóponttal még nincs kapcsolat.

Ehhez bármilyen jelzőmechanizmust használnak. Az SDP továbbítható aljzatokon keresztül, vagy személy által (telefonon mondd el egy másik csomópontnak), vagy az orosz postán. Minden nagyon egyszerű - kap egy kész SDP-t, és el kell küldenie. És amikor megkapja a másik oldalon, vigye át a WebRTC osztályra. A munkamenetleíró szövegként van tárolva, és módosítható az alkalmazásokban, de ez általában nem szükséges. Például, amikor asztali ↔ telefont csatlakoztat, néha kényszerítenie kell a kívánt audio kodek kiválasztását.

A kapcsolat létesítésekor általában meg kell adni valamilyen címet, például URL-t. Ez itt nem szükséges, mivel a jelzőmechanizmuson keresztül Ön maga küldi el az adatokat a célállomásra. Ahhoz, hogy jelezzük a WebRTC-nek, hogy p2p kapcsolatot szeretnénk létesíteni, meg kell hívnunk a createOffer függvényt. A függvény meghívása és egy speciális 'a visszahívás megadása után létrejön egy SDP objektum, amelyet ugyanannak a visszahívásnak adunk át. Mindössze annyit kell tennie, hogy ezt az objektumot a hálózaton keresztül egy másik csomóponthoz (beszélgetőpartnerhez) vigye át. Ezt követően a jelzőmechanizmuson keresztül az adatok a másik végére érkeznek, mégpedig erre az SDP objektumra. Ez a munkamenet-leíró idegen ettől a csomóponttól, ezért hasznos információkat tartalmaz. Ennek az objektumnak a vétele a kapcsolat elindításának jele. Ezért el kell fogadnia ezt, és meg kell hívnia a createAnswer függvényt. Ez a createOffer teljes analógja. Ismét a helyi munkamenet-leíró átadásra kerül a visszahívásnak, és vissza kell adni a jelzőmechanizmuson keresztül.

Érdemes megjegyezni, hogy a createAnswer függvény csak akkor hívható meg, ha valaki más SDP objektumát megkapta. Miért? Mivel a createAnswer hívásakor előállított helyi SDP-objektumnak a távoli SDP-objektumra kell támaszkodnia. Csak ebben az esetben lehetséges a videóbeállítások összehangolása beszélgetőpartnere beállításaival. Ezenkívül ne hívja meg a createAnswer és a createOffer parancsot, mielőtt megkapja a helyi médiafolyamot – ezeknek nem lesz mit írniuk az SDP objektumhoz.

Mivel a WebRTC képes szerkeszteni egy SDP-objektumot, a helyi leíró kézhezvétele után telepíteni kell. Kicsit furcsának tűnhet, hogy át kell adnunk a WebRTC-nek azt, amit ő maga adott nekünk, de ez a protokoll. Távoli fogantyú fogadásakor azt is telepíteni kell. Ezért két leírót kell telepítenie egy csomópontra - a saját és valaki másé (vagyis a helyi és a távoli).

Ezt követően kézfogások a csomópontok tudnak egymás kívánságairól. Például, ha az 1. csomópont támogatja az A és B kodeket, a 2. csomópont pedig a B és C kodeket, akkor mivel mindegyik csomópont ismeri a saját és a másik leíróját, mindkét csomópont a B kodeket választja (7. ábra). A kapcsolódási logika most már létrejött, és a médiafolyamok továbbíthatók, de van egy másik probléma - a csomópontok továbbra is csak jelzőmechanizmussal vannak összekötve.

7. ábra: Codec egyeztetés

Jég jelölt

A WebRTC technológia megpróbál minket összezavarni új módszertanával. A kapcsolat létrehozásakor nincs megadva annak a csomópontnak a címe, amelyhez csatlakozni kíván. Először telepítve logikus kapcsolat, nem fizikai, bár mindig az ellenkezője történt. De ez nem tűnik furcsának, ha nem felejtjük el, hogy harmadik féltől származó jelzőmechanizmust használunk.

Tehát a kapcsolat már létrejött (logikai kapcsolat), de még mindig nincs út, amelyen a hálózati csomópontok adatokat továbbíthatnak. Ez nem ilyen egyszerű, de kezdjük egyszerűen. Legyenek a csomópontok ugyanazon a magánhálózaton. Amint azt már tudjuk, könnyen tudnak kapcsolódni egymáshoz belső IP-címeik segítségével (vagy esetleg másokkal, ha nem TCP/IP-t használnak).

Néhány visszahívás révén, és a WebRTC tájékoztat minket az Ice jelölt objektumokról. Szöveges formában is megjelennek, és a munkamenet-leírókhoz hasonlóan egyszerűen el kell őket küldeni egy jelzőmechanizmuson keresztül. Ha a munkamenetleíró kamera és mikrofon szintű beállításainkról tartalmazott információkat, akkor a jelöltek a hálózaton belüli elhelyezkedésünkről tartalmaznak információkat. Adja át őket egy másik csomópontnak, és az képes lesz fizikailag csatlakozni hozzánk, és mivel már rendelkezik munkamenet-leíróval, logikusan képes lesz csatlakozni, és az adatok „folyni fognak”. Ha eszébe jut, hogy elküldje nekünk jelölt objektumát, azaz információt arról, hogy ő maga hol tartózkodik a hálózaton, akkor kapcsolatba léphetünk vele. Jegyezzünk meg még egy különbséget a klasszikus kliens-szerver interakcióhoz képest. A HTTP szerverrel a kommunikáció kérés-válasz séma szerint történik, a kliens adatokat küld a szervernek, amely feldolgozza és elküldi a kéréscsomagban megadott címet. A WebRTC-ben tudnia kell két címetés kösse össze őket mindkét oldalon.

A különbség a munkamenet-leíróktól az, hogy csak távoli jelölteket kell telepíteni. A szerkesztés itt tilos, és nem jár semmilyen előnnyel. Egyes WebRTC megvalósításokban a jelölteket csak a munkamenetleírók beállítása után kell telepíteni.

Miért csak egy munkamenet-leíró volt, de sok jelölt lehetett? Ugyanis a hálózaton belüli elhelyezkedés nemcsak a belső IP-címe alapján határozható meg, hanem a router külső címe alapján is, és nem feltétlenül csak egy, valamint a TURN szerverek címei alapján. A bekezdés további részét a jelöltek és a különböző magánhálózatokból származó csomópontok összekapcsolásának részletes megvitatásának szenteljük.

Tehát két csomópont ugyanazon a hálózaton van (8. ábra). Hogyan lehet azonosítani őket? IP-címek használata. Nincs más mód. Igaz, továbbra is különböző szállításokat (TCP és UDP) és különböző portokat használhat. Ez az információ, amelyet a jelölt objektum - IP, PORT, TRANSPORT és néhány más - tartalmaz. Használjuk például az UDP szállítást és az 531-es portot.

8. ábra: Két csomópont van ugyanazon a hálózaton

Ekkor, ha a p1 csomópontban vagyunk, akkor a WebRTC egy ilyen jelölt objektumot ad nekünk - . Ez nem pontos formátum, csak egy diagram. Ha a p2 csomóponton vagyunk, akkor a jelölt . A jelzőmechanizmuson keresztül a p1 megkapja a p2 jelöltjét (vagyis a p2 csomópont helyét, nevezetesen annak IP-jét és PORT-ját). Ezután a p1 közvetlenül csatlakozhat a p2-höz. Helyesebben, a p1 adatokat küld a 10.50.150.3:531-re abban a reményben, hogy eléri a p2-t. Nem számít, hogy ez a cím a p2 csomóponthoz vagy valamilyen közvetítőhöz tartozik. Az egyetlen fontos dolog az, hogy az adatok ezen a címen keresztül kerülnek elküldésre, és elérhetik a p2-t.

Mindaddig, amíg a csomópontok ugyanazon a hálózaton vannak, minden egyszerű és könnyű - minden csomópontnak csak egy jelölt objektuma van (mindig a sajátját jelenti, vagyis a hálózaton belüli helyét). De sokkal több jelölt lesz, amikor a csomópontok beépülnek különböző hálózatok.

Térjünk át egy bonyolultabb esetre. Az egyik csomópont az útválasztó mögött (pontosabban a NAT mögött) található, a második pedig ugyanabban a hálózatban lesz, mint ezzel az útválasztóval (például az interneten) (9. ábra).

9. ábra: Az egyik csomópont a NAT mögött van, a másik nem

Ez az eset sajátos megoldást kínál a problémára, amelyet most megvizsgálunk. Otthoni routeráltalában tartalmaz egy NAT táblát. Ez egy speciális mechanizmus, amely lehetővé teszi, hogy az útválasztó magánhálózatán belüli csomópontok hozzáférjenek például webhelyekhez.

Tegyük fel, hogy a webszerver közvetlenül kapcsolódik az Internethez, azaz nyilvános IP * címmel rendelkezik. Legyen ez a p2 csomópont. A p1 csomópont (webkliens) kérést küld a 10.50.200.10 címre. Először is, az adatok az r1 útválasztóhoz, vagy inkább annak útválasztóhoz kerülnek belső interfész 192.168.0.1. Ezután a router megjegyzi a forráscímet (p1 cím), és beírja egy speciális NAT táblába, majd megváltoztatja a forráscímet a sajátjára (p1 → r1). Továbbá a magam módján külső interfészen keresztül a router közvetlenül a p2 webszervernek küldi az adatokat. A webszerver feldolgozza az adatokat, választ generál és visszaküldi. Az r1-et elküldi a routernek, mivel a visszatérési címben van (a router lecserélte a címet a sajátjára). Az útválasztó fogadja az adatokat, megnézi a NAT táblát, és továbbítja az adatokat a p1 csomópontnak. A router itt közvetítőként működik.

Mi a teendő, ha a belső hálózat több csomópontja egyidejűleg hozzáfér a külső hálózathoz? Hogyan fogja megérteni a router, hogy kinek küldje vissza a választ? Ezt a problémát a segítségével oldják meg portok. Amikor egy útválasztó lecseréli a gazdagép címét a sajátjára, a portot is lecseréli. Ha két csomópont hozzáfér az Internethez, akkor az útválasztó lecseréli a forrásportjaikat a következőre különböző. Ezután, amikor a webszervertől érkező csomag visszakerül az útválasztóhoz, az útválasztó a port alapján megérti, hogy kihez van hozzárendelve a csomag. Példa alább.

Térjünk vissza a WebRTC technológiához, pontosabban annak az ICE protokollt használó részére (ezért az Ice jelöltek). A p2 csomópontnak egy jelöltje van (helye a hálózatban 10.50.200.10), és a p1 csomópontnak, amely a NAT-os útválasztó mögött található, két jelölt lesz: helyi (192.168.0.200) és útválasztójelölt (10.50.200.5). Az első nem hasznos, de ennek ellenére létrejön, mivel a WebRTC még nem tud semmit a távoli csomópontról - lehet, hogy ugyanazon a hálózaton van, de lehet, hogy nem. A második jelölt jól jön, és mint már tudjuk, a port (a NAT-on való átjutáshoz) fontos szerepet fog játszani.

A NAT táblában csak akkor jön létre bejegyzés, ha az adatok elhagyják a belső hálózatot. Ezért először a p1 csomópontnak kell továbbítania az adatokat, és csak ezután érheti el a p2 csomópont adatai a p1 csomópontot.

A gyakorlatról mindkét csomópont NAT mögött lesz. Az egyes útválasztók NAT táblájában bejegyzés létrehozásához a gazdagépeknek küldeniük kell valamit a távoli gazdagépnek, de ezúttal sem az előbbi nem tudja elérni az utóbbit, sem fordítva. Ennek az az oka, hogy a csomópontok nem ismerik a külső IP-címeiket, és értelmetlen az adatok belső címekre küldése.

Ha azonban a külső címek ismertek, a kapcsolat könnyen létrejön. Ha az első csomópont adatokat küld a második csomópont útválasztójának, az útválasztó figyelmen kívül hagyja, mivel a NAT táblája még üres. Az első csomópont útválasztójában azonban megjelent egy szükséges bejegyzés a NAT táblában. Ha most a második csomópont adatokat küld az első csomópont útválasztójának, akkor a router sikeresen továbbítja azokat az első csomóponthoz. Most a második útválasztó NAT táblájában is megvannak a szükséges adatok.

A probléma az, hogy a külső IP-cím kiderítéséhez szükség van egy csomópontra, amelyen belül található megosztott hálózat. A probléma megoldására további szervereket használnak, amelyek közvetlenül csatlakoznak az internethez. Segítségükkel a NAT táblában is kincses bejegyzések készülnek.

STUN és TURN szerverek

A WebRTC inicializálásánál meg kell adni az elérhető STUN és TURN szervereket, amelyeket ezentúl ICE szervereknek nevezünk. Ha a szerverek nincsenek megadva, akkor csak ugyanazon a hálózaton (NAT nélkül csatlakozva) lévő csomópontok tudnak csatlakozni. Azonnal érdemes megjegyezni, hogy a 3g hálózatoknál kötelező a TURN szerverek használata.

KÁBÍTÁS szerver egyszerűen egy szerver az interneten, amely visszaküldi a visszaküldési címet, vagyis a küldő csomópontjának címét. Az útválasztó mögötti gazdagép felveszi a kapcsolatot a STUN-kiszolgálóval, hogy bejárja a NAT-ot. A STUN szerverhez érkezett csomag tartalmazza a forráscímet - a router címét, vagyis a csomópontunk külső címét. Ezt a STUN címet küldi vissza a szerver. Így a csomópont megkapja a külső IP-címét és azt a portot, amelyen keresztül elérhető a hálózatról. Ezután a WebRTC ezt a címet használja egy további jelölt létrehozásához (külső útválasztó címe és portja). Most van egy bejegyzés az útválasztó NAT táblájában, amely lehetővé teszi, hogy a szükséges porton a routernek küldött csomagok elérjék a csomópontunkat.

Nézzük meg ezt a folyamatot egy példán keresztül.

Példa (STUN szerver működése)

A STUN szervert s1 jelöli. A router, mint korábban, az r1-en, a csomópont pedig a p1-en keresztül halad. Figyelnie kell a NAT táblát is – r1_nat-ként fogjuk jelölni. Ezenkívül ez a táblázat általában sok rekordot tartalmaz az alhálózat különböző csomópontjairól - ezeket nem adjuk meg.

Tehát az elején van egy üres r1_nat tábla.

2. táblázat: Csomag fejléc

A p1 csomópont elküldi ezt a csomagot az r1 útválasztónak (nem számít, hogyan, a különböző alhálózatok használhatják különböző technológiák). A routernek le kell cserélnie az Src IP forráscímet, mivel a csomagban megadott cím nyilvánvalóan nem alkalmas külső alhálózatra, ráadásul az ilyen tartományból származó címek le vannak foglalva, és az interneten egyetlen címnek sincs ilyen címe. Az útválasztó helyettesíti a csomagot, és létrehozza új bejegyzés táblázatában r1_nat. Ehhez ki kell találnia egy portszámot. Emlékezzünk arra, hogy mivel egy alhálózaton belül több gazdagép is hozzáférhet egy külső hálózathoz, a NAT táblát tárolni kell további információ, így az útválasztó meg tudja határozni, hogy a csomópontok közül melyiket szánja a kiszolgálótól érkező visszatérő csomag. Hagyja, hogy az útválasztó jöjjön létre a 888-as porttal.

Módosított csomag fejléc:

4. táblázat: A NAT tábla egy új bejegyzéssel frissült

Itt az alhálózat IP-címe és portja pontosan megegyezik az eredeti csomagéval. Valójában a visszaküldéskor módunkban áll teljesen visszaállítani őket. A külső hálózat IP-címe a router címe, a port pedig a router által kitaláltra változott.

A valódi port, amelyen a p1 csomópont fogadja a kapcsolatot természetesen 35777, de a szerver adatokat küld kitalált 888-as portot, amelyet az útválasztó a valódi 35777-re cserél.

Tehát az útválasztó lecserélte a forráscímet és a portot a csomag fejlécében, és hozzáadott egy bejegyzést a NAT táblához. Most a csomag elküldésre kerül a hálózaton keresztül a szervernek, vagyis az s1 csomópontnak. A bemeneten az s1 a következő csomaggal rendelkezik:

Src IP Src PORT Cél IP Cél PORT

10.50.200.5	888	12.62.100.200	6000

5. táblázat: STUN szerver kapott csomagot

Összességében a STUN szerver tudja, hogy a 10.50.200.5:888 címről kapott egy csomagot. Most a szerver visszaküldi ezt a címet. Itt érdemes megállni, és még egyszer megnézni, mit néztünk meg. A fenti táblázatok kivonatai ebből fejléc csomagot, egyáltalán nem abból tartalom. A tartalomról nem beszéltünk, mivel nem annyira fontos – valahogy le van írva a STUN protokollban. Most a címen kívül a tartalommal is foglalkozunk. Egyszerű lesz, és tartalmazza a router címét - 10.50.200.5:888, bár mi innen vettük fejléc csomag. Ezt nem szokták megtenni, a protokollok általában nem törődnek a csomópontcímekkel kapcsolatos információkkal, csak az a fontos, hogy a csomagok a rendeltetési helyre kerüljenek. Itt egy olyan protokollt vizsgálunk, amely útvonalat hoz létre két csomópont között.

Tehát most van egy második csomagunk, ami az ellenkező irányba megy:

7. táblázat: A STUN szerver ilyen tartalmú csomagot küld

Ezután a csomag áthalad a hálózaton, amíg el nem éri az r1 útválasztó külső interfészét. Az útválasztó megérti, hogy a csomag nem neki való. Hogy érti ezt? Ezt csak a port határozhatja meg. A 888-as portot nem személyes célokra használja, hanem a NAT-mechanizmushoz használja. Ezért a router ezt a táblázatot nézi. Megnézi a Külső PORT oszlopot, és keres egy sort, amely megegyezik a bejövő csomagból származó célporttal, azaz a 888-assal.

Belső IP Belső PORT Külső IP Külső PORT

192.168.0.200	35777	10.50.200.5	888

8. táblázat: NAT-tábla

Szerencsések vagyunk, létezik ilyen vonal. Ha nincs szerencsénk, a csomagot egyszerűen eldobjuk. Most meg kell értenie, hogy az alhálózat melyik csomópontja küldje el ezt a csomagot. Nem kell sietni, emlékezzünk ismét a portok fontosságára ebben a mechanizmusban. Ugyanakkor az alhálózat két csomópontja kéréseket küldhet a külső hálózatnak. Aztán, ha az útválasztó a 888-as portot találta ki az első csomóponthoz, akkor a másodikhoz a 889-es portot. Tegyük fel, hogy ez történt, vagyis az r1_nat tábla így néz ki:

10. táblázat: Az útválasztó lecseréli a vevő címét

Src IP Src PORT Cél IP Cél PORT

12.62.100.200	6000	192.168.0.200	35777

11. táblázat: Az útválasztó megváltoztatta a vevő címét

A csomag sikeresen megérkezik a p1 csomóponthoz, és a csomag tartalmát megnézve a csomópont megismeri a külső IP-címét, vagyis a külső hálózaton lévő útválasztó címét. Ismeri azt a portot is, amelyen a router átmegy a NAT-on.

Mi a következő lépés? Mi haszna ennek az egésznek? Előny egy bejegyzés az r1_nat táblában. Ha most valaki küld egy csomagot a 888-as porttal az r1 útválasztónak, akkor a router továbbítja ezt a csomagot a p1 csomópontnak. Ez egy kis szűk átjárót hozott létre a rejtett p1 csomóponthoz.

A fenti példából képet kaphat a NAT működéséről és a STUN szerver lényegéről. Általánosságban elmondható, hogy az ICE mechanizmus és a STUN/TURN szerverek pontosan a NAT korlátozások leküzdésére irányulnak.

A csomópont és a szerver között nem egy router lehet, hanem több is. Ebben az esetben a csomópont megkapja annak az útválasztónak a címét, amelyik elsőként fér hozzá ugyanahhoz a hálózathoz, mint a szerver. Más szóval, megkapjuk a STUN szerverhez csatlakoztatott útválasztó címét. A p2p kommunikációhoz pontosan erre van szükségünk, ha nem feledkezünk meg arról a tényről, hogy minden router hozzáadja a nekünk szükséges sort a NAT táblához. Ezért a visszaút ismét ugyanolyan sima lesz.

A TURN szerver egy továbbfejlesztett STUN szerver. Innentől azonnal el kell venni, hogy bármelyik TURN szerver STUN szerverként is működjön. Vannak azonban előnyei is. Ha a p2p kommunikáció nem lehetséges (mint például a 3g hálózatokban), akkor a szerver közvetítő módba kapcsol, azaz közvetítőként működik. Természetesen akkor nem p2p-ről beszélünk, de az ICE mechanizmuson kívül a csomópontok azt hiszik, hogy közvetlenül kommunikálnak.

Milyen esetekben van szükség TURN szerverre? Miért nincs elég STUN szerver? A tény az, hogy többféle NAT létezik. Ugyanúgy cserélik ki az IP-címet és a portot, de némelyikbe kiegészítő védelem van beépítve a „hamisítás” ellen. Például be szimmetrikus A NAT tábla további 2 paramétert tárol - a távoli gazdagép IP-jét és portját. A külső hálózatról érkező csomag csak akkor jut el a NAT-on keresztül a belső hálózatba, ha a forráscím és a port megegyezik a táblázatban rögzítettekkel. Ezért a STUN szerverrel végzett trükk meghiúsul - a NAT tábla tárolja a STUN szerver címét és portját, és amikor az útválasztó csomagot kap a WebRTC beszélgetőpartnertől, eldobja, mert „hamisított”. Nem a STUN szerverről érkezett.

Tehát szükség van egy TURN szerverre abban az esetben, ha mindkét beszélgetőpartner lemarad szimmetrikus NAT (mindegyik a sajátját).

Rövid összefoglaló

Íme néhány kijelentés a WebRTC entitásokról, amelyeket mindig szem előtt kell tartania. Ezeket fentebb részletesen ismertetjük. Ha valamelyik állítás nem tűnik teljesen egyértelműnek, olvassa el újra a vonatkozó bekezdéseket.

• Médiafolyam
  • A video- és hangadatok médiafolyamokba vannak csomagolva
  • A médiafolyamok szinkronizálják az alkotó médiasávokat
  • A különböző médiafolyamok nincsenek szinkronizálva egymással
  • A médiafolyamok lehetnek helyiek és távoliak, a lokális általában kamerához és mikrofonhoz csatlakozik, a távoliak titkosított formában fogadják az adatokat a hálózatról
  • Kétféle médiasáv létezik – videóhoz és hanghoz.
  • A médiasávok be- és kikapcsolhatók
  • A médiasávok médiacsatornákból állnak
  • A médiasávok szinkronizálják az alkotó médiacsatornákat
  • A médiafolyamokon és médiasávokon címkék vannak, amelyek alapján megkülönböztethetők
• Session fogantyú
  • A munkamenet-leíró két hálózati csomópont logikai összekapcsolására szolgál
  • A munkamenet-leíró információkat tárol arról elérhető módokon videó és audio adatok kódolása
  • A WebRTC külső jelzőmechanizmust használ – a munkamenet-leírók (sdp) továbbítása az alkalmazásra hárul
  • A logikai kapcsolódási mechanizmus két szakaszból áll - ajánlat (ajánlat) és válasz (válasz)
  • A munkamenetleíró létrehozása ajánlat esetén nem lehetséges helyi médiafolyam használata nélkül, válasz esetén pedig távoli munkamenetleíró használata nélkül.
  • Az eredményül kapott leírót meg kell adni a WebRTC implementációnak, és nem számít, hogy ez a leíró távolról vagy helyileg érkezik ugyanattól a WebRTC implementációtól
  • A munkamenet-leíró kis mértékben módosítható
• Jelöltek
  • A jégjelölt a hálózat egy csomópontjának címe
  • A csomópont címe lehet a saját, vagy egy útválasztó vagy TURN szerver címe
  • Mindig sok jelölt van
  • A jelölt IP-címből, portból és szállítási típusból (TCP vagy UDP) áll.
  • A jelöltek fizikai kapcsolat létrehozására szolgálnak a hálózat két csomópontja között
  • A jelölteket jelzőmechanizmuson keresztül is el kell küldeni
  • A jelölteket WebRTC implementációkba is át kell adni, de csak távolira
  • Egyes WebRTC-megvalósításokban a jelöltek csak a munkamenetleíró beállítása után küldhetők el
• STUN/TURN/ICE/NAT
  • A NAT egy külső hálózathoz való hozzáférést biztosító mechanizmus
  • Az otthoni útválasztók egy speciális NAT-táblát támogatnak
  • Az útválasztó lecseréli a csomagokban lévő címeket - a forráscímet a sajátjával, ha a csomag külső hálózatra megy, és a vevő címét a belső hálózaton lévő gazdagép címére, ha a csomag külső hálózatról érkezett.
  • Ahhoz, hogy többcsatornás hozzáférést biztosítson egy külső hálózathoz, a NAT portokat használ
  • ICE – NAT átjáró motor
  • STUN és TURN szerverek – asszisztens szerverek a NAT bejáráshoz
  • A STUN szerver lehetővé teszi a szükséges bejegyzések létrehozását a NAT táblában, és visszaadja a gazdagép külső címét is
  • A TURN szerver általánosítja a STUN mechanizmust, és mindig működőképessé teszi
  • A legrosszabb esetben a TURN szervert közvetítőként (továbbítóként) használják, vagyis a p2p kliens-szerver-kliens kapcsolattá alakul.

Napjainkban a WebRTC a „forró” technológia a hang- és videóstreamelésre a böngészőkben. A konzervatív technológiák, mint például a HTTP Streaming és a Flash alkalmasabbak a rögzített tartalom (video on demand) terjesztésére, és lényegesen alulmúlják a WebRTC-t valós idejű és online adások tekintetében, pl. ahol minimális videó késleltetés szükséges ahhoz, hogy a nézők „élőben” lássá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 az online műsorszórási rendszerekben, webináriumokban és más alkalmazásokban, amelyek interaktív kommunikációt igényelnek a videóforrással, a végfelhasználókkal és megoldást igényelnek.

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

A WebRTC technológia működésének tesztelése és egy egyszerű futtatása érdekében online közvetítés, Flashphoner WebRTC Media & Broadcasting Server szerver szoftvert használtunk. A funkciók kimondjá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, így otthon tesztelhettem az online adásokat Windows számítógép Nem sikerült. 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:

A Centos x86_64 6.5-ös verziója volt, minden előre telepített szoftver nélkül az amszterdami adatközpontban. Így csak a szerver és az ssh hozzáférés áll rendelkezésünkre. Azoknak, akik ismerik konzolparancsok Linux, a WebRTC szerver telepítése egyszerűnek és fájdalommentesnek ígérkezik. Szóval mit csináltunk:

1. Töltse le az archívumot:

$wget https://site/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. Aktiválja a licencet:

$cd /usr/local/FlashphonerWebCallServer/bin

$./activation.sh

5. Indítsa el a WCS-kiszolgálót:

$service webcallserver start

6. Ellenőrizze a naplót:

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

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

$ps aux | grep Flashphoner

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

WebRTC online adások tesztelése

Az adások tesztelése egyszerű dolognak bizonyult. A szerveren kívül van egy webkliens 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 az index.html tesztkliens oldalt 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 készen áll a használatra. A webkamerával szemben nincs különösebb követelmény, például 1280x800-as felbontású, szabványos laptopba épített kamerát használtunk.

A Chrome böngésző mindenképpen 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 engedélyezi.

3. Az interfész a video stream sikeres sugárzását jelenti a kamerából a WebRTC szerverre. A jobb felső sarokban egy 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.

Kérjük, vegye figyelembe az alábbi mezőben található linket. Egyedi azonosítót tartalmaz ehhez a streamhez, így bárki csatlakozhat a megtekintéshez. Csak nyissa meg ezt a hivatkozást a böngészőjében. A vágólapra másoláshoz kattintson a „Másolás” gombra.

A valós alkalmazásokban, mint például a webináriumok, előadások, online videoközvetítések vagy interaktív tévézés, 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 azok csatlakozhassanak a kívánt streamekhez, de ez már az alkalmazás logikája. . A WebRTC Media & Broadcasting Server nincs hatással rá, csak videót terjeszt.

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

A WebRTC online broadcast szerver tesztelésének eredményei

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 a szem számára láthatatlan volt. 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: az ilyen tesztekben a Flash nem viselkedik olyan jól, mint a WebRTC. Tehát, ha egy hasonló hálózaton mozgatja a kezét, a képernyőn a mozgás csak egy-két másodperc múlva látható.

A minőséggel kapcsolatban megjegyezzük, hogy a kockákat néha mozgás alapján lehet megkülönböztetni. Ez összhangban van a VP8 kodek természetével és fő céljával – a valós idejű videokommunikáció biztosításával 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ű, futtatása nem igényel komolyabb ismereteket azon túlmenően, hogy haladó felhasználó szinten ismeri a Linuxot, aki képes parancsokat végrehajtani a konzolról ssh-n keresztül és használja 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 a streamhez szintén nem okozott gondot.

A webináriumok és online adások közvetítésének minősége meglehetősen elfogadhatónak bizonyult. Az egyetlen dolog, ami felvetett néhány kérdést, az a videó felbontása volt. A kamera támogatja az 1280x800-as felbontást, de a tesztképen a felbontás nagyon hasonlít a 640x480-asra. Ú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

A böngészőből történő hívások kezdeményezésére szolgáló technológiák már évek óta léteznek: Java, ActiveX, Adobe Flash...Az elmúlt néhány évben világossá vált, hogy a pluginok és balra virtuális gépek Nem tündökölnek a kényelemtől (miért telepítsek egyáltalán semmit?), és ami a legfontosabb, a biztonságtól. Mit kell tenni? Van kijárat!

Egészen a közelmúltig az IP-hálózatok többféle protokollt használtak az IP-telefonáláshoz vagy -videóhoz: a SIP, a legelterjedtebb protokoll, a H.323 és az MGCP, amely a színről jött, a Jabber/Jingle (a Gtalkban használatos), a félig nyitott Adobe RTMP* és természetesen , bezárta a Skype-ot. A Google által kezdeményezett WebRTC projekt megpróbálja megváltoztatni az IP és a webes telefonálás világának helyzetét, softphones, beleértve a Skype-ot is. A WebRTC nemcsak közvetlenül a böngészőn belül valósítja meg az összes kommunikációs lehetőséget, amely ma már szinte minden eszközre telepítve van, hanem egyidejűleg igyekszik megoldani a böngésző felhasználók közötti kommunikáció egy általánosabb problémáját is (különböző adatok cseréje, képernyősugárzás, együttműködés a dokumentumokkal, ill. sokkal több).

WebRTC a webfejlesztő szemszögéből

A webfejlesztők szempontjából a WebRTC két fő részből áll:

• a helyi forrásokból (kamera, mikrofon vagy képernyő) érkező médiafolyamok vezérlése helyi számítógép) a navigator.getUserMedia metódus valósítja meg, amely egy MediaStream objektumot ad vissza;
• peer-to-peer kommunikáció a médiafolyamokat előállító eszközök között, beleértve a kommunikációs módszerek meghatározását és azok közvetlen továbbítását - RTCPeerConnection objektumok (audio és video folyamok küldésére és fogadására) és RTCDataChannel (adatok küldésére és fogadására a böngészőből).

Mit csináljunk?

Meg fogjuk találni, hogyan szervezzünk egyszerű többfelhasználós videocsevegést a böngészők között WebRTC-n alapuló webaljzatok segítségével. Kísérletezni kezdünk a Chrome/Chromiumban, mivel a WebRTC szempontjából a legfejlettebb böngészők, bár a június 24-én megjelent Firefox 22 már majdnem utolérte őket. El kell mondanunk, hogy a szabványt még nem fogadták el, és az API verzióról verzióra változhat. Az összes példát Chromium 28-ban teszteltük. Az egyszerűség kedvéért nem fogjuk ellenőrizni a kód tisztaságát és a böngészők közötti kompatibilitást.

MediaStream

Az első és legegyszerűbb WebRTC összetevő a MediaStream. Hozzáférést biztosít a böngészőnek a helyi számítógép kamerájából és mikrofonjából származó médiafolyamokhoz. Chrome-ban ehhez meg kell hívni a navigator.webkitGetUserMedia() függvényt (mivel a szabvány még nincs véglegesítve, minden függvényhez előtag tartozik, Firefoxban pedig ugyanezt a függvényt navigator.mozGetUserMedia()-nak hívják). Amikor felhívja, a felhasználó megkéri, hogy engedélyezze a kamerához és a mikrofonhoz való hozzáférést. A hívás folytatására csak a felhasználó hozzájárulása után van lehetőség. A szükséges médiafolyam paraméterei és két visszahívási funkció paraméterként kerül átadásra ehhez a funkcióhoz: az elsőt akkor hívja meg, ha sikeresen eléri a kamerát/mikrofont, a másodikat pedig hiba esetén. Először hozzunk létre egy rtctest1.html HTML-fájlt egy gombbal és egy elemmel:

WebRTC – első bemutatkozó videó ( magasság: 240 képpont; szélesség: 320 képpont; szegély: 1 képpont, tömör szürke; ) getUserMedia

Microsoft CU-RTC-Web

A Microsoft nem lenne Microsoft, ha nem reagálna azonnal a Google kezdeményezésére saját, nem kompatibilis, nem szabványos opciójának kibocsátásával, a CU-RTC-Web néven (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web. htm). Bár az IE aránya, ami amúgy is csekély, tovább csökken, a Skype-felhasználók száma reményt ad a Microsoftnak, hogy kiszorítsa a Google-t, és feltételezhető, hogy ezt a szabványt fogják használni a böngészőben. Skype verziók. A Google szabvány elsősorban a böngészők közötti kommunikációra összpontosít; ugyanakkor a beszédforgalom nagy része továbbra is a normál telefonhálózaton marad, és átjárókra van szükség a hálózat és az IP-hálózatok között nemcsak a könnyebb használat vagy a gyorsabb elosztás miatt, hanem a bevételszerzés eszközeként is, amely lehetővé teszi több játékos számára fejleszteni őket. Egy újabb szabvány megjelenése nemcsak azt eredményezheti, hogy a fejlesztők kellemetlenül kell, hogy támogassák egyszerre két egymással össze nem egyeztethető technológiát, hanem a jövőben is szélesebb választékot ad a felhasználónak a lehetséges funkcionalitások és az elérhető műszaki megoldások között. Várj és láss.

Helyi adatfolyam engedélyezése

A HTML-fájlunk címkéin belül deklaráljunk egy globális változót a médiafolyam számára:

Var localStream = null;

A getUserMedia metódus első paraméterének meg kell adnia a kért médiafolyam paramétereit – például egyszerűen engedélyezze a hangot vagy a videót:

Var streamConstraints = ("audio": igaz, "videó": igaz); // Hozzáférés kérése hanghoz és videóhoz egyaránt

Vagy adjon meg további paramétereket:

Var streamConstraints = ( "audio": igaz, "videó": ( "kötelező": ( "maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5"), "opcionális": ) );

A getUserMedia metódus második paraméterét át kell adni a visszahívási függvénynek, amely meghívásra kerül, ha sikeres:

Függvény getUserMedia_success(stream) ( console.log("getUserMedia_success():", stream); localVideo1.src = URL.createObjectURL(stream); // Csatlakoztassa a médiafolyamot a HTML elemhez localStream = stream; // és mentse el globális változóban a további felhasználás érdekében)

A harmadik paraméter egy visszahívási függvény, egy hibakezelő, amelyet hiba esetén hívunk meg

Függvény getUserMedia_error(error) ( console.log("getUserMedia_error():", hiba); )

A getUserMedia metódus tényleges hívása a mikrofonhoz és a kamerához való hozzáférés kérése az első gomb megnyomásakor

Függvény getUserMedia_click() ( console.log("getUserMedia_click()"); navigator.webkitGetUserMedia(streamConstraints, getUserMedia_success, getUserMedia_error); )

Helyileg megnyitott fájlból nem lehet médiafolyamot elérni. Ha megpróbáljuk ezt megtenni, a következő hibát kapjuk:

NavigatorUserMediaError (kód: 1, PERMISSION_DENIED: 1)"

Az így kapott fájlt töltsük fel a szerverre, nyissuk meg a böngészőben, és a megjelenő kérésre engedélyezzük a kamerához és a mikrofonhoz való hozzáférést.

A Beállításokban, a Speciális beállítások link megjelenítése, az Adatvédelem részben és a Tartalom gombban választhatja ki, hogy mely eszközökhöz férhet hozzá a Chrome. A Firefox és az Opera böngészőkben az eszközök közvetlenül a legördülő listából kerülnek kiválasztásra, amikor a hozzáférés engedélyezett.

HTTP protokoll használata esetén a rendszer minden alkalommal engedélyt kér, amikor az oldal betöltése után hozzáférnek a médiafolyamhoz. A HTTPS-re váltás lehetővé teszi a kérés egyszeri megjelenítését, csak a médiafolyamhoz való első hozzáféréskor.

Figyelje meg a pulzáló kört a könyvjelző ikonban és a kamera ikont a címsor jobb oldalán:

RTCMediaConnection

Az RTCMediaConnection egy olyan objektum, amely médiafolyamokat hoz létre és továbbít a hálózaton keresztül a résztvevők között. Ezen túlmenően ez az objektum felelős a média munkamenet leírásának (SDP) generálásáért, információk beszerzéséért az ICE jelöltekről a NAT bejárásához ill. tűzfalak(helyi és STUN használatával) és interakció a TURN szerverrel. Minden résztvevőnek kapcsolatonként egy RTCMediaConnection-nel kell rendelkeznie. A médiafolyamok továbbítása titkosított SRTP protokoll használatával történik.

TURN szerverek

Háromféle ICE jelölt létezik: host, srflx és relay. A gazdagép helyileg fogadott információkat tartalmaz, az srflx-et - hogyan néz ki a csomópont egy külső szerver számára (STUN), valamint a továbbító - a forgalom TURN-szerveren keresztüli proxy-átviteléhez szükséges információkat. Ha a csomópontunk a NAT mögött van, akkor a gazdagépjelöltek tartalmazni fogják helyi címekés haszontalan lesz, az srflx jelöltek csak bizonyos típusú NAT-oknál segítenek, és a relay lesz az utolsó remény, hogy a forgalmat egy köztes szerveren továbbítsák.

Példa egy ICE jelölt host típusú 192.168.1.37 címmel és udp/34022 porttal:

A=jelölt:337499441 2 udp 2113937151 192.168.1.37 34022 typ host generáció 0

Általános formátum a STUN/TURN szerverek meghatározásához:

Var szerverek = ( "iceServers": [ ( "url": "stun:stun.stunprotocol.org:3478" ), ( "url": "turn:user@host:port", "credential": "password" ) ]);

Az interneten számos nyilvános STUN szerver található. Van például egy nagy lista. Sajnos túl kevés problémát oldanak meg. A STUN-nal ellentétben gyakorlatilag nincs nyilvános TURN szerver. Ez annak köszönhető, hogy a TURN szerver médiafolyamokon halad át, ami jelentősen terhelheti mind a hálózati csatornát, mind magát a szervert. Ezért a TURN szerverekhez való csatlakozás legegyszerűbb módja, ha saját kezűleg telepíted (nyilván nyilvános IP-címre lesz szükséged). Véleményem szerint az összes szerver közül a legjobb az rfc5766-turn-server. Még az Amazon EC2-hez is van kész kép.

A TURN-nél nem minden olyan jó, mint szeretnénk, de aktív fejlesztés folyik, és szeretném remélni, hogy egy idő után a WebRTC, ha nem is egyenlő a Skype-mal a címfordítás (NAT) és a tűzfalak minőségében. , legalább észrevehető közelebb fog jönni.

Az RTCMediaConnection egy további mechanizmust igényel a vezérlő információk cseréjére a kapcsolat létrehozásához - bár előállítja ezeket az adatokat, nem továbbítja azokat, és a továbbítást a többi résztvevőnek külön kell megvalósítani.

Az átviteli mód kiválasztása a fejlesztő feladata – legalábbis manuálisan. Amint a szükséges adatok cseréje megtörténik, az RTCMediaConnection automatikusan telepíti a médiafolyamokat (természetesen ha lehetséges).

ajánlat-válasz modell

A médiafolyamok létrehozásához és módosításához az ajánlat/válasz modell (az RFC3264-ben leírtak szerint) és az SDP (Session Description Protocol) használatos. Ezeket a SIP protokoll is használja. Ebben a modellben két ügynök van: Ajánlattevő - az, aki létrehozza a munkamenet SDP-leírását egy új létrehozásához vagy egy meglévő módosításához (SDP-ajánlat), és az Answerer - az, aki megkapja a munkamenet SDP-leírását egy másik ügynököt, és a saját munkamenetleírásával válaszol (Answer SDP). Ugyanakkor a specifikáció egy magasabb szintű protokollt igényel (például SIP vagy saját over web socket, mint esetünkben), amely az SDP ügynökök közötti továbbításáért felelős.

Milyen adatokat kell átadni két RTCMediaConnection között, hogy sikeresen létrehozhassák a médiafolyamokat:

• A csatlakozást elsőként kezdeményező résztvevő Ajánlatot alkot, amelyben egy SDP adatstruktúrát továbbít (ugyanezt a protokollt használják ugyanarra a célra a SIP-ben), amely leírja annak a médiafolyamnak a lehetséges jellemzőit, amelyet továbbítás előtt áll. Ezt az adatblokkot át kell adni a második résztvevőnek. A második résztvevő létrehoz egy Választ az SDP-jével, és elküldi az elsőnek.
• Mind az első, mind a második résztvevő elvégzi a lehetséges ICE jelöltek meghatározását, amelyek segítségével a második résztvevő médiafolyamot tud küldeni nekik. A jelöltek azonosítása után a róluk szóló információkat át kell adni egy másik résztvevőnek.

Alakítási ajánlat

Az ajánlat generálásához két függvényre van szükségünk. Az első meghívásra kerül, ha sikeresen létrejött. A createOffer() metódus második paramétere egy visszahívási függvény, amelyet a végrehajtás során fellépő hiba esetén hívunk meg (feltéve, hogy a helyi szál már elérhető).

Ezenkívül két eseménykezelőre van szükség: az onicecandidate-re az új ICE-jelölt meghatározásakor, az onaddstream pedig egy médiafolyam túloldalról történő csatlakoztatásakor. Térjünk vissza az aktánkhoz. Adjunk hozzá még egyet a HTML-hez az elemes sorok után:

CreateOffer

És az elemmel ellátott sor után (a jövőre vonatkozóan):

Szintén a JavaScript kód elején deklarálunk egy globális változót az RTCPeerConnection számára:

Var pc1;

Az RTCPeerConnection konstruktor meghívásakor STUN/TURN szervereket kell megadni. További információért lásd az oldalsávot; mindaddig, amíg minden résztvevő ugyanazon a hálózaton van, nincs szükség rájuk.

Var szerverek = null;

Az ajánlat elkészítésének paraméterei SDP

Var offerConstraints = ();

A createOffer() metódus első paramétere egy visszahívási függvény, amelyet egy ajánlat sikeres létrehozása esetén hívnak meg

pc1_createOffer_success(desc) függvény ( console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:", desc); pc1.setLocalDescription(desc); // RTCPeerConnection által generált SDP beállítása a setLocalDescription metódussal. // Amikor a távoli oldal elküldi az Answer SDP-jét, akkor azt a setRemoteDescription metódussal kell beállítani // A második oldal megvalósításáig semmit sem teszünk // pc2_receivedOffer(desc); )

A második paraméter egy visszahívási függvény, amelyet hiba esetén hívunk meg

pc1_createOffer_error(error)(console.log("pc1_createOffer_success_error(): error:", error); ) függvény

És deklaráljunk egy visszahívási függvényt, amelyhez az ICE jelöltek átkerülnek, ahogy meghatározzák őket:

Függvény pc1_onicecandidate(event)( if (event.candidate) ( console.log("pc1_onicecandidate():\n"+ event.candidate.candidate.replace("\r\n", ""), event.candidate); // A második oldal megvalósításáig nem teszünk semmit // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

És egy visszahívási funkció a médiafolyam túloldalról történő hozzáadásához (a jövőre nézve, mivel egyelőre csak egy RTCPeerConnection-ünk van):

pc1_onaddstream(event) függvény ( console.log("pc_onaddstream()"); remoteVideo1.src = URL.createObjectURL(event.stream); )

Amikor az „Ajánlat létrehozása” gombra kattint, létrehozunk egy RTCPeerConnection-t, beállítjuk az onicecandidate és onaddstream metódusokat, és a createOffer() metódus meghívásával kérjük az Offer SDP létrehozását:

CreateOffer_click() függvény ( console.log("createOffer_click()"); pc1 = new webkitRTCPeerConnection(servers); // RTCPeerConnection létrehozása pc1.onicecandidate = pc1_onicecandidate; // Visszahívási függvény az ICE jelöltek feldolgozásához pc1.onaddonad =dstream; Visszahívási függvény akkor hívódik meg, ha egy médiafolyam jelenik meg a túloldalról. Még nincs pc1.addStream(localStream); // Adjuk át a helyi médiafolyamot (feltételezve, hogy már megérkezett) pc1.createOffer(// És valójában kérés az Offer pc1_createOffer_success , pc1_createOffer_error, offerConstraints létrehozása); )

Mentsük el a fájlt rtctest2.html néven, töltsük fel a szerverre, nyissuk meg böngészőben és nézzük meg a konzolban, milyen adatok keletkeznek a működése során. A második videó még nem jelenik meg, mivel csak egy résztvevő van. Emlékezzünk vissza, hogy az SDP egy médiamunkamenet paramétereinek leírása, az elérhető kodekek, médiafolyamok és az ICE jelöltek lehetséges opciók az adott résztvevőhöz való csatlakozáshoz.

Válasz SDP megalakítása és az ICE jelöltek cseréje

Mind az Ajánlat SDP-t, mind az ICE jelölteket át kell vinni a másik oldalra, és ott, miután megkapta őket, az RTCPeerConnection meghívja a setRemoteDescription metódusokat az Ajánlat SDP-hez és az addIceCandidate-et minden túloldalról kapott ICE jelölthez; hasonlóan be hátoldal az Answer SDP és a távoli ICE jelöltek számára. Maga a Válasz SDP az Ajánlathoz hasonlóan alakul; a különbség az, hogy nem a createOffer metódus hívódik meg, hanem a createAnswer metódus, és előtte a setRemoteDescription RTCPeerConnection metódus kerül átadásra a hívótól kapott Offer SDP-hez.

Adjunk hozzá még egy videóelemet a HTML-hez:

És a második RTCPeerConnection globális változója az első deklarációja alatt:

Var pc2;

Az ajánlat és az SDP válasz feldolgozása

Az Answer SDP formációja nagyon hasonlít az ajánlathoz. A válasz sikeres formálása esetén meghívott visszahívási funkcióban, hasonlóan az Ajánlathoz, helyi leírást adunk, és a kapott Válasz SDP-t továbbítjuk az első résztvevőnek:

pc2_createAnswer_success(desc) függvény ( pc2.setLocalDescription(desc); console.log("pc2_createAnswer_success()", desc.sdp); pc1.setRemoteDescription(desc); )

A visszahívási funkció, amelyet a válasz generálása során fellépő hiba esetén hív meg, teljesen hasonló az ajánlathoz:

pc2_createAnswer_error(error) függvény ( console.log("pc2_createAnswer_error():", hiba); )

A válasz SDP kialakításának paraméterei:

Var answerConstraints = ( "kötelező": ( "OfferToReceiveAudio":true, "OfferToReceiveVideo":true ) );

Amikor a második résztvevő megkapja az Ajánlatot, létrehozunk egy RTCPeerConnection-t, és az Ajánlattal megegyező módon választ adunk:

Függvény pc2_receivedOffer(desc) ( console.log("pc2_receiveOffer()", desc); // Hozzon létre egy RTCPeerConnection objektumot a második résztvevő számára az elsőhöz hasonlóan pc2 = new webkitRTCPeerConnection(servers); pc2.onicecandidate = pc2 ; // Állítsa be az eseménykezelőt, amikor megjelenik ICE jelölt pc2.onaddstream = pc_onaddstream; // Amikor megjelenik egy adatfolyam, csatlakoztassa a HTML-hez pc2.addStream(localStream); // A helyi médiafolyam átvitele (példánkban a második résztvevőnek ugyanaz van, mint az elsőnek) // Most, amikor a második RTCPeerConnection készen áll, átadjuk neki a kapott Offer SDP-t (az elsőnek átadtuk a helyi adatfolyamot) pc2.setRemoteDescription(new RTCSessionDescription(desc)); // Kérje meg a második kapcsolatot, hogy adatokat generáljon a válaszüzenethez pc2.createAnswer(pc2_createAnswer_success, pc2_createAnswer_error, answerConstraints); )

Ahhoz, hogy a példánkban szereplő Offer SDP-t az első résztvevőről a másodikra ​​vigyük át, töröljük a megjegyzést a pc1 függvényben. CreateOffer siker() hívóvonal:

Pc2_receivedOffer(desc);

Az ICE jelöltek feldolgozásának megvalósításához töröljük a megjegyzéseket az első résztvevő pc1_onicecandidate() ICE jelölt készenléti eseménykezelőjében annak átvitelét a másodikra:

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

A második résztvevő ICE jelölt készenléti eseménykezelője tükörszerű az elsőhöz:

pc2_onicecandidate(event) függvény ( if (event.candidate) ( console.log("pc2_onicecandidate():", event.candidate.candidate); pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

Visszahívási funkció médiafolyam hozzáadásához az első résztvevőtől:

pc2_onaddstream(event) függvény ( console.log("pc_onaddstream()"); remoteVideo2.src = URL.createObjectURL(event.stream); )

A kapcsolat befejezése

Adjunk hozzá még egy gombot a HTML-hez

Rakd le

És egy funkció a kapcsolat megszakításához

Függvény btnHangupClick() ( // Válassza le a helyi videót a HTML elemekről, állítsa le a helyi médiafolyamot, set = null localVideo1.src = ""; localStream.stop(); localStream = null; // Minden résztvevő esetében tiltsa le a videót a HTML-ből elemeket, zárja be a kapcsolatot, állítsa be a mutatót = null remoteVideo1.src = ""; pc1.close(); pc1 = null; remoteVideo2.src = ""; pc2.close(); pc2 = null; )

Mentsük el rtctest3.html néven, töltsük fel a szerverre és nyissuk meg a böngészőben. Ez a példa a médiafolyamok kétirányú átvitelét valósítja meg két RTCPeerConnection között ugyanazon a böngészőlapon belül. Az Ajánlat és Válasz SDP, az ICE jelöltek résztvevők közötti és egyéb információk hálózaton keresztüli cseréjének megszervezéséhez a közvetlen hívási eljárások helyett szükség lesz a résztvevők közötti csere megvalósítására valamilyen közlekedési eszközzel, esetünkben - web socketekkel.

Képernyő közvetítés

A getUserMedia funkció a képernyőt és az adatfolyamot is rögzítheti MediaStreamként a következő paraméterek megadásával:

Var mediaStreamConstraints = ( hang: false, videó: ( kötelező: ( chromeMediaSource: "screen"), opcionális: ) );

A képernyő sikeres eléréséhez több feltételnek kell teljesülnie:

• képernyőkép jelző engedélyezése a getUserMedia()-ban a chrome://flags/,chrome://flags/ helyen;
• a forrásfájlt HTTPS-en (SSL eredetű) keresztül kell letölteni;
• az audio adatfolyamot nem szabad kérni;
• Egy böngészőlapon nem szabad több kérést végrehajtani.

Könyvtárak a WebRTC számára

Bár a WebRTC még nem készült el, már több könyvtár is megjelent az alapján. A JsSIP-et olyan böngészőalapú szoftverek létrehozására tervezték, amelyek SIP-kapcsolókkal működnek, mint például az Asterisk és a Camalio. A PeerJS megkönnyíti az adatcserére szolgáló P2P hálózatok létrehozását, a Holla pedig csökkenti a böngészőkből származó P2P kommunikációhoz szükséges fejlesztések mennyiségét.

Node.js és socket.io

Az SDP és ICE jelöltek cseréjének megszervezése két RTCPeerConnection között a hálózaton keresztül, a Node.js-t használjuk a socket.io modullal.

Leírja a Node.js legújabb stabil verziójának telepítését (Debian/Ubuntu számára).

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

Telepítés mások számára OS leírta

Ellenőrizzük:

$ echo "sys=require("util"); sys.puts("Tesztüzenet");" > nodetest1.js $ nodejs nodetest1.js

Az npm (Node Package Manager) segítségével telepítjük a socket.io-t és a további expressz modult:

$ npm telepítse a socket.io expresst

Teszteljük úgy, hogy létrehozunk egy nodetest2.js fájlt a szerveroldalon:

$ nano nodetest2.js var app = igény("express")() , szerver = igény("http").createServer(app) , io = követelmény("socket.io").listen(server); server.listen(80); // Ha a 80-as port ingyenes app.get("/", függvény (req, res) ( // A gyökéroldal elérésekor res.sendfile(__dirname + "/nodetest2.html"); // elküldi a HTML fájlt ) ) ; io.sockets.on("kapcsolat", függvény (socket) ( // Csatlakozáskor socket.emit("server event", ( hello: "world" )); // üzenet küldése socket.on("kliens esemény" , function (data) ( // és deklarál egy eseménykezelőt, amikor üzenet érkezik az ügyfélkonzolból.log(data); )); ));

És a nodetest2.html az ügyféloldalra:

$ nano nodetest2.html var socket = io.connect("/"); // Websocket szerver URL-je (annak a szervernek a gyökéroldala, ahonnan az oldal betöltődött) socket.on("szerveresemény", függvény (data) ( console.log(data); socket.emit("kliens esemény", () " név": "érték" )); ));

Indítsuk el a szervert:

$ sudo nodejs nodetest2.js

és nyissa meg a http://localhost:80 oldalt (ha helyileg a 80-as porton fut) a böngészőben. Ha minden sikeres, akkor a böngésző JavaScript konzoljában látni fogjuk az eseménycserét a böngésző és a szerver között csatlakozáskor.

Információcsere az RTCPeerConnection között webes socketeken keresztül Kliens rész

Mentsük el a fő példánkat (rtcdemo3.html) új néven rtcdemo4.html. Tegyük bele a socket.io könyvtárat az elembe:

És a JavaScript szkript elején - websocketekhez való csatlakozás:

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

Cseréljük ki a közvetlen hívást egy másik résztvevő funkcióira úgy, hogy üzenetet küldünk neki webaljzatokon keresztül:

függvény createOffer_success(desc) ( ... // pc2_receivedOffer(desc); socket.emit("ajánlat", desc); ... ) függvény pc2_createAnswer_success(desc) ( ... // pc1.setRemoteDescription(desc); socket .emit("answer", desc); ) function pc1_onicecandidate(event) ( ... // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice1", event.candidate); .. . ) function pc2_onicecandidate(event) ( ... // pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice2", event.candidate); ... )

A hangup() függvényben ahelyett, hogy közvetlenül a második résztvevő függvényeit hívnánk meg, üzenetet küldünk webcsatornákon keresztül:

Függvény btnHangupClick() ( ... // remoteVideo2.src = ""; pc2.close(); pc2 = null; socket.emit("hangup", ()); )

És adjon hozzá üzenetfogadó kezelőket:

Socket.on("ajánlat", függvény (adatok) ( console.log("socket.on("ajánlat"):", adat); pc2_receivedOffer(data); )); socket.on("válasz", függvény (adatok) (е console.log("socket.on("válasz"):", data); pc1.setRemoteDescription(new RTCSessionDescription(data)); )); socket.on("ice1", függvény (data) ( console.log("socket.on("ice1"):", data); pc2.addIceCandidate(new RTCIceCandidate(data)); )); socket.on("ice2", függvény (data) ( console.log("socket.on("ice2"):", data); pc1.addIceCandidate(new RTCIceCandidate(data)); )); socket.on("hangup", függvény (data) ( console.log("socket.on("hangup"):", data); remoteVideo2.src = ""; pc2.close(); pc2 = null; ) );

Szerver rész

A szerver oldalon mentse el a nodetest2 fájlt új néven rtctest4.js és az io.sockets.on("connection", function (socket) ( ... ) függvényen belül hozzáadjuk a kliens üzenetek fogadását és küldését:

Socket.on("ajánlat", függvény (data) ( // Amikor megkapjuk az "ajánlat" üzenetet, // mivel ebben a példában csak egy kliens kapcsolat van, // az üzenetet ugyanazon a socket socketen keresztül küldjük vissza .emit("ajánlat" , adat); // Ha szükséges lenne az üzenetet az összes kapcsolaton keresztül továbbítani, // kivéve a feladót: // soket.broadcast.emit("ajánlat", adat); )); socket.on("válasz", függvény (adatok) ( socket.emit("válasz", adat); )); socket.on("ice1", function (data) ( socket.emit("ice1", data); )); socket.on("ice2", függvény (adatok) ( socket.emit("ice2", data); )); socket.on("hangup", function (data) ( socket.emit("lefagy", adat); ));

Ezenkívül változtassuk meg a HTML-fájl nevét:

// res.sendfile(__dirname + "/nodetest2.html"); // A HTML-fájl elküldése res.sendfile(__dirname + "/rtctest4.html");

A szerver indítása:

$ sudo nodejs nodetest2.js

Annak ellenére, hogy mindkét kliens kódja ugyanazon a böngészőlapon fut le, a példánkban szereplő résztvevők közötti minden interakció teljes mértékben a hálózaton keresztül történik, és a résztvevők „leválasztása” nem igényel különösebb nehézséget. Amit azonban tettünk, az is nagyon egyszerű volt – ezek a technológiák jók, mert könnyen használhatók. Még ha néha megtévesztő is. Különösképpen ne felejtsük el, hogy STUN/TURN szerverek nélkül példánk nem fog működni címfordítás és tűzfalak jelenlétében.

Következtetés

Az eredményül kapott példa nagyon konvencionális, de ha kicsit univerzalizáljuk az eseménykezelőket, hogy ne különbözzenek a hívó és a hívott fél között, akkor két objektum, a pc1 és a pc2 helyett, készítsünk egy RTCPeerConnection tömböt és implementáljuk dinamikus alkotásés elemeket eltávolítva teljesen használható videocsevegést kapunk. A WebRTC-hez nem kapcsolódnak speciális adatok, és egy példa egy egyszerű videocsevegésre több résztvevő számára (valamint a cikkben szereplő összes példa szövege) a magazinhoz mellékelt lemezen található. Az interneten azonban már elég sokat találhatsz. jó példák. A cikk elkészítésekor különösen a következőket használták: simpl.info getUserMedia, simpl.info RTCPeerConnection, WebRTC Reference App.

Feltételezhető, hogy a WebRTC-nek köszönhetően hamarosan forradalom fog bekövetkezni nemcsak a hang- és videokommunikáció megértésében, hanem abban is, ahogyan az internet egészét érzékeljük. A WebRTC nem csak a böngészők közötti hívások technológiája, hanem valós idejű kommunikációs technológia is. Az általunk tárgyalt videokommunikáció csak egy kis része lehetséges opciók a használatát. Már van példa képernyőközvetítésre és együttműködésre, sőt, még az RTCDataChannelt használó böngészőalapú P2P tartalomszolgáltató hálózatra is.