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. A böngészőn keresztüli valós idejű kommunikációban a Google már 2011-ben kezdett aktívan részt venni, amikor közzétette a WebRTC megvalósításá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.

A streaming kapcsolat zökkenőmentes működése érdekében jó minőségű, három motor működik 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.

Kommunikáció: WebRTC technológiák a böngészőben JavaScript kóddal indul el. 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 internet böngésző.

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

Kedves barátaim, mint már tudjátok, rendszeresen frissítünk benneteket új technológiákkal, ma bemutatom a WebRTC technológiát, amelyet Google, amely lehetővé teszi a felhasználók számára, hogy közvetlenül a böngészőben beszéljenek video- és hanganyaggal anélkül, hogy egy beépülő modul használata szükséges- Webhelyek vagy alkalmazások. A felhasználók közötti közvetlen video- és hangkapcsolat közvetlenül a böngészőben történik.
A Mozilla által támogatott WebRTC technológia Firefox böngészők Google Chromeés bármilyen operációs rendszer, Az Opera hamarosan csatlakozik.
Mi az a WebRTC és mi?
A WebRTC a Web Real Time Communication rövidítése, ez a technológia lehetővé teszi az audio- és videocsevegés megnyitását közvetlenül a böngészőben anélkül, hogy ehhez más beépülő modulokra, alkalmazásokra vagy szolgáltatásokra lenne szükség az interneten. A kapcsolat közvetlenül a böngésző és a böngésző között jön létre.
Ahol az ismert szolgáltatások (Skype, Yahoo Messenger, Apple FaceTime, Google Hago stb.) olyan szervert igényelnek, amely összeköti a felhasználókat a forgalom kezdeményezéséhez és kezeléséhez. Ezen szolgáltatások igénybevételéhez regisztrálnunk kell, és fel kell állítani egy listát az ügyfelekről és a kapcsolatokról.
A WebRTC-vel nincs szükségünk olyan szerverekre, alkalmazásokra vagy szerverekre, amelyek csatlakoznak a közbenjáráshoz.
A WebRTC előnyei:
1. Nincs több olyan alkalmazás, amely erőforrást és akkumulátort fogyaszt.
2. A chatek privátabbak (viszonylag).
3. A kapcsolatfelvétel történhet helyileg, nem a Flos US szerverei a helyi kapcsolatokhoz.
4. Egyszerűség, könnyű használat.
5. Lehetőség további fejlődés, és más irányokba.
6. A kommunikáció stabil és független a külső csatlakozások amelyek néha rendkívül instabilok.
Az oktatóanyagban egy demót használtam, amit a Google-nél fejlesztettek ki, ez a demó meglehetősen egyszerű, fejlettebb funkciók és gyorsabb kapcsolatok használhatják a WebRTC-t támogató alkalmazások egyikét, könnyebben használhatóak. Hamarosan a WebRTC alkalmazásokról is készítünk egy bemutatót.
Hogyan kell használni a WebRTC demót?
Nagyon egyszerűen kattintson az alábbi linkre, és automatikusan létrehoz egy csevegést. a szoba összekapcsolásához el kell küldenie egy barátot/barátnőt, akivel kapcsolatba szeretne lépni.
Barátod/barátnőd és a tied, de csak a legtöbbet használd legújabb verziói Mozilla Firefox vagy a Google Chrome.

WebRTC bemutató(Bevezető chat hang - videó)

Figyelem:
A demó nem túl stabil, csak bemutató céllal készült. Korlátozott ideig használható, amely alatt kisebb csatlakozási hibák léphetnek fel.
Ha kapcsolódási problémái vannak, próbáljon meg másik csevegést létrehozni.

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, i. 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 az élő streaming 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ésének 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 otthon 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:

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, a WebRTC szerver telepítése egyszerűnek és fájdalommentesnek ígérkezik. 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

Az anyag nagy része rajta WebRTC a kódírás alkalmazási szintjére összpontosít, és nem járul hozzá a technológia megértéséhez. Próbáljunk mélyebbre menni, és megtudjuk, hogyan jön létre a kapcsolat, mi a munkamenet leírója és a jelöltek, mik KÁBÍTÁSés FORDULAT szerver.

WebRTC

Bevezetés

A WebRTC egy böngésző alapú technológia, amely lehetővé teszi két kliens összekapcsolását videó adatátvitelhez. A fő jellemzők a belső böngésző támogatása (nincs szükség harmadik féltől származó beágyazott technológiákra, mint pl Adobe Flash ) és a kliensek csatlakoztatásának lehetősége további szerverek használata nélkül - kapcsolat ponttól-pontig(További, p2p).

Hozzon létre kapcsolatot p2p- meglehetősen nehéz feladat, mivel a számítógépeknek nem mindig van nyilvános IP címek, azaz az interneten található címek. A kis mennyiség miatt IPv4 címekre (és biztonsági okokból) egy mechanizmust dolgoztak ki NAT, amely lehetővé teszi privát hálózatok létrehozását, például otthoni használatra. Sok otthoni útválasztó már támogatja NATés ennek köszönhetően minden otthoni eszköz rendelkezik internet-hozzáféréssel, bár az internetszolgáltatók általában biztosítanak ilyet IP cím. nyilvános IP A címek egyediek az interneten, de a privát címek nem. Szóval kapcsolódj p2p- nehéz.

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

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

2. ábra: Csomópontok különböző hálózatokon (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 jelzi (p = egyenrangú, r = router). Az első ábrán a helyzet kedvező: hálózatuk csomópontjait hálózatonként teljesen azonosítják IP címeket, és ezért közvetlenül kapcsolódhatnak egymáshoz. A második ábrán két különböző hálózatunk van, amelyeknek hasonló csomópontszámai vannak. Itt megjelennek az útválasztók (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 nekik kettő van IP címek. A normál csomópontoknak csak egy interfészük van, amelyen keresztül csak a saját hálózatukon tudnak kommunikálni. Ha a hálózatukon kívülre továbbítanak adatokat, akkor csak a segítségével NAT az útválasztó (router) belsejében, és ezért alatta mások számára látható IP a router címe az övék külső IP cím. Így a csomópont p1 van belső IP = 192.168.0.200 és külső IP = 10.50.200.5 , amelynek utolsó címe a hálózatán lévő összes többi gazdagépen kívül is van. Hasonló a helyzet a node esetében is p2. Ezért kapcsolatuk lehetetlen, ha csak a belső (saját) IP címek. Használhat külső címeket, azaz útválasztók címeit, 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 mechanizmus oldja meg NAT

Mi történik, ha mégis úgy döntünk, hogy a csomópontokat belső címükön keresztül csatlakoztatjuk? 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.

WebRTC sikeresen megbirkózik az ilyen problémákkal a protokoll használatával JÉG, ami azonban további szerverek használatát igényli ( KÁBÍTÁS, FORDULAT). Mindezt alább.

A WebRTC két fázisa

Két csomópont összekapcsolása protokollon keresztül WebRTC(vagy egyszerűen RTC ha kettő össze van kötve iPhone‘a) szükséges végrehajtani néhányat előzetes akciók kapcsolatot létesíteni. Ez az első fázis – a kapcsolat létrehozása. A második fázis a videó adatok továbbítása.

Azonnal le kell mondani, hogy bár a technológia WebRTC munkájában sokat használ különböző módokon kommunikáció ( TCPés UDP), és rugalmas váltást biztosít közöttük, ez a technológia nem rendelkezik protokollal a kapcsolati adatok átadására. Nem meglepő, mert csatlakoztasson két csomópontot p2p Nem olyan könnyű. Ezért szükséges, hogy legyen néhány további adatátvitel módja, nem kapcsolódik WebRTC. Ez lehet socket átvitel, protokoll http, akár protokoll is lehet SMTP vagy Orosz Posta. Ez az átviteli mechanizmus elsődleges adatot hívják jel. Nem kell sok információt átadni. Minden adatot szövegként továbbítanak, és két típusra oszthatók − SDPés Jégjelölt. Az első típus logikai, a második pedig fizikai kapcsolat létrehozására szolgál. Erről később, de most fontos emlékezni erre WebRTC olyan információkat ad nekünk, amelyeket egy másik csomóponthoz kell továbbítani. Miután minden szükséges információt továbbítottunk, a csomópontok képesek lesznek kapcsolódni, és a segítségünkre többé nem lesz szükség. Tehát a jelzőmechanizmust meg kell valósítanunk külön, használva lesz csak csatlakoztatva, és nem használják videoadatok átviteléhez.

Nézzük tehát az első fázist, a kapcsolat beállítási fázisát. Több elemből áll. Tekintsük ezt a fázist először a kapcsolatot kezdeményező csomópontnál, majd a várakozónál.

• Kezdeményező (hívó - hívó):
  1. Ajánlat a videó adatátvitel elindítására (createOffer)
  2. A tiéd megszerzése SDP SDP)
  3. A tiéd megszerzése Jég jelölt Jég jelölt)
• Várakozó hívás ( callee):
  1. Helyi (saját) médiafolyam beszerzése és átvitelre való beállítása (getUserMediaStream)
  2. Ajánlat fogadása videó adatátvitel megkezdésére és válasz létrehozására (createAnswer)
  3. A tiéd megszerzése SDP tárgyat és átengedni a jelzőmechanizmuson ( SDP)
  4. A tiéd megszerzése Jég jelölt tárgyak és átvitelük a jelzőmechanizmuson keresztül ( Jég jelölt)
  5. 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 bekezdésben 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. o.), kapcsolati paraméterek beállítása (2-4. oldal), valaki más médiafolyamának fogadása (5. oldal). A legnehezebb 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 a csomagoknak haladniuk kell ahhoz, 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ális szakaszban CreateOffer vagy létrehozniVálasz kapcsolódni kell az átviteli szakaszokhoz SDPés Jég jelölt tárgyakat.

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 a 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. NÁL NÉL WebRTC van egy felület a streamekhez médiafolyamés van egy alinterfész is LocalMediaStream kifejezetten azért helyi szál. NÁL NÉL JavaScript csak az elsővel találkozhatsz, és ha használod lib csilingel, akkor a másodikkal is találkozhatunk.

NÁL NÉL WebRTC meglehetősen zavaros hierarchia van a szálon belül. Minden adatfolyam több médiasávból állhat ( médiasáv), amely több médiacsatornából is állhat ( MediaChannel). És lehet több médiafolyam is.

Vegyünk mindent sorjában. 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 (mi + asztal) és egy hangra (mi). 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 kettőnk lesz médiafolyam‘a – egyet nekünk, egyet 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 a médiafolyamnak tartalmaznia kell legalább az adattartalmat különböző típusok- videó és hang. Ezt figyelembe veszi a technológia, ezért minden adattípus egy médiasávon keresztül valósul meg. médiasáv. A médiasávnak van egy speciális tulajdonsága kedves, amely meghatározza, hogy mi van előttünk - videó vagy hang (5. ábra)

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

Hogyan zajlik majd 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 tulajdonsága címke– patakcímke, annak 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, és 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 átvihet egy médiafolyamot, és különböző sávokat használhat benne. elértük fontos tulajdon médiafolyamok – ők 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átszott.

Így ha azt akarjuk, hogy szavaink, érzelmeink az arcon és a papírdarabunk egyszerre szólaljanak 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 egy műsorszámot le kell tiltani az átvitel során, akkor használhatja a tulajdonságot engedélyezve van médiasávok.

A végén érdemes a sztereó hangzásra gondolni. Mint tudod, a sztereó hang két különböző hangzás. És külön is kell őket küldeni. Ehhez csatornákat használnak. MediaChannel. Egy audio médiasávnak sok csatornája lehet (például 6, ha 5+1 hangra van szüksége). A médiapályán belül természetesen a csatornákon is szinkronizálva. Videóhoz általában csak egy csatornát használnak, de több is használható például hirdetési fedvényekhez.

Ö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 szám, de több is lehet, ha több különböző videót kell átvinnie (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.

Munkamenetleíró (SDP)

Nál nél különböző számítógépek mindig lesznek különböző kamerák, mikrofonok, videokártyák és egyéb felszerelések. Sok lehetőségük van. Mindezt össze kell hangolni két hálózati csomópont közötti médiaadatátvitelhez. WebRTC ezt automatikusan megteszi, és létrehoz egy speciális objektumot - a munkamenet leíróját SDP. Adja át ezt az objektumot egy másik csomópontnak, és küldhet médiaadatokat. Csak egy másik csomóponttal még nincs kapcsolat.

Ehhez bármilyen jelzőmechanizmust használnak. SDP akár aljzatokon keresztül is továbbítható, akár ember (telefonon mondd el egy másik csomópontnak), akár Orosz Posta is. Minden nagyon egyszerű - készen kapsz SDPés el kell küldeni. És a kézhezvétel után a másik oldalon - át az osztályra WebRTC. A munkamenet leírója szövegként van tárolva, és módosíthatja az alkalmazásokban, de általában nincs rá szükség. Például az asztali↔telefon csatlakoztatásakor néha kényszerítenie kell a kívánt audiokodek kiválasztását.

Általában kapcsolat létesítésekor meg kell adni például valamilyen címet URL. Itt erre nincs szükség, hiszen Ön a jelzőmechanizmuson keresztül küldi el az adatokat a célállomásra. Jelezni WebRTC amit telepíteni akarunk p2p kapcsolathoz meg kell hívnia a createOffer függvényt. Miután meghívta ezt a függvényt, és különleges értéket adott neki visszahív‘a lesz létrejön SDP tárgyat, és átadta ugyanahhoz visszahív. 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 másik végén a jelzőmechanizmuson keresztül érkeznek adatok, mégpedig ezen SDP egy tárgy. Ennek a csomópontnak ez a munkamenetleírója idegen, ezért hordoz hasznos információ. Ennek az objektumnak a fogadása a kapcsolat indí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. Vissza a tiédhez visszahívátad egy helyi munkamenet-leírót, és azt vissza kell adni a jelzőmechanizmuson keresztül.

Érdemes megjegyezni, hogy a createAnswer függvény csak akkor hívható meg, ha valaki mástól kapott SDP tárgy. Miért? Mert helyi SDP a createAnswer meghívásakor generált objektumnak a távolira kell támaszkodnia SDP egy tárgy. Csak ebben az esetben lehetséges a videóbeállítások összehangolása a beszélgetőpartner beállításaival. Ezenkívül ne hívja meg a createAnswer és a createOffer parancsot, amíg meg nem érkezik a helyi médiafolyam - nekik nincs mit írniuk SDP egy tárgy .

óta ben WebRTC lehet szerkeszteni SDP objektumot, akkor a helyi leíró beszerzése után be kell állítani. Kicsit furcsának tűnhet az átadás WebRTC amit ő maga adott nekünk, de ez a protokoll. Amikor kap egy távirányítót, azt is be kell állítania. Ezért két leírót kell telepítenie egy csomópontra - a saját és valaki másé (azaz helyi és távoli).

Ilyenek után kézfogások a csomópontok tudnak egymás kívánságairól. Például, ha a csomópont 1 támogatja a kodekeket Aés B, és a csomópont 2 támogatja a kodekeket Bés C, akkor mivel mindegyik csomópont ismeri a saját és a másik leíróját, mindkét csomópont választ egy kodeket B(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

Jelöltek (Jég jelölt)

Technológia WebRTCúj módszertanával próbál összezavarni minket. 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 ennek 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 nincs mód a hálózati csomópontok adatátvitelére. Ez nem ilyen egyszerű, de kezdjük egyszerűen. Legyenek a csomópontok ugyanabban a magánhálózatban. Mint már tudjuk, belsőjükön keresztül könnyen kapcsolódhatnak egymáshoz IP címek (vagy esetleg más, ha nem használjuk TCP/IP).

Némelyiken keresztül visszahív'és WebRTC elmondja nekünk Jég jelölt tárgyakat. Szöveges formában is jönnek, és csakúgy, mint a munkamenet-leírókat, csak a jelzőmechanizmuson keresztül kell elküldeni őket. 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 ő fizikailag tud csatlakozni hozzánk, és mivel már rendelkezik munkamenet-leíróval, logikusan tud csatlakozni, és az adatok „folyni fognak”. Ha nem felejti el elküldeni nekünk a jelölt objektumát, vagyis információt arról, hogy hol van a hálózaton, akkor tudunk vele kapcsolatba lépni. Megjegyezzük itt még egy különbséget a klasszikus kliens-szerver interakcióhoz képest. Kommunikáció a HTTP szerver 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ímre. NÁL NÉL WebRTC tudni 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 beállítani. A szerkesztés itt tilos, és nem hozhat semmilyen hasznot. Egyes megvalósításokban WebRTC a jelölteket csak a munkamenet-leírók beállítása után kell beállítani.

És miért csak egy ülésleíró volt, de sok jelölt lehet? Mivel a hálózatban elfoglalt hely nemcsak a belső alapján határozható meg IP címet, hanem az útválasztó külső címét is, és nem feltétlenül egyet, valamint a címeket FORDULAT szerverek. 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 ugyanabban a hálózatban van (8. ábra). Hogyan lehet azonosítani őket? Használva IP címek. Nincs más mód. Igaz, továbbra is használhatsz különböző szállítási módokat ( TCPés UDP) és különböző portok. Ez az információ, amelyet a jelölt objektum tartalmaz - IP, KIKÖTŐ, SZÁLLÍTÁSés néhány más. Használjuk például UDP szállítás és 531 kikötő.

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

Majd ha egy csomópontban vagyunk p1, akkor WebRTC ad nekünk egy ilyen jelölt tárgyat - . Ez nem egy pontos formátum, hanem csak egy diagram. Ha csomóban vagyunk p2, akkor a jelölt az . A jelzőmechanizmuson keresztül p1 jelöltet kap p2(azaz a csomópont helye p2, mégpedig az övé IPés KIKÖTŐ). Akkor p1 tud kapcsolódni p2 közvetlenül. Helyesebb, p1 adatokat küld a címre 10.50.150.3:531 abban a reményben, hogy elérik p2. Nem számít, ha ez a cím egy csomóponthoz tartozik p2 vagy valamilyen közvetítő. Az egyetlen fontos dolog az, hogy az adatok ezen a címen keresztül kerülnek elküldésre, és elérhetik p2.

Mindaddig, amíg a csomópontok ugyanabban a hálózatban vannak - minden egyszerű és könnyű - minden csomópontnak csak egy jelölt objektuma van (mindig a sajátját, vagyis a hálózatban elfoglalt 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 lesz (pontosabban a NAT mögött), a második pedig ugyanabban a hálózatban lesz ezzel az útválasztóval (például az interneten) (9. ábra).

9. ábra: Egy gazdagép a NAT mögött, egy másik nem

Ez az eset sajátos megoldást kínál a problémára, amelyet most megvizsgálunk. Az otthoni útválasztó általában tartalmaz egy táblázatot NAT. 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 csatlakozik az Internethez, vagyis rendelkezik publikussal IP* cím. Legyen csomó p2. Csomó p1(webkliens) kérést küld a címre 10.50.200.10 . Először az adatok a routerhez kerülnek r1, vagy inkább az övén belső felület 192.168.0.1 . Ezt követően az útválasztó megjegyzi a forráscímet (cím p1), és beírja egy speciális táblázatba NAT, majd megváltoztatja a forráscímet a sajátjára ( p1 → r1). Továbbá szerint külső felületen a router közvetlenül a webszervernek küldi az adatokat p2. A webszerver feldolgozza az adatokat, választ generál, majd visszaküldi. Elküldi a routernek r1, mivel ő van a visszatérési címben (a router megváltoztatta a címet a sajátjára). A router adatokat fogad, megnézi a táblázatot NATés elküldi az adatokat a csomópontnak p1. A router itt közvetítőként működik.

De mi van akkor, ha a belső hálózatból egyszerre több csomópont is hozzáfér a külső hálózathoz? Hogyan fogja megérteni a router, hogy kinek küldje vissza a választ? Ez a probléma megoldva a portok. Amikor az ú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önféle. Ezután, amikor a webszervertől érkező csomag visszajön az útválasztóhoz, az útválasztó megérti azt a portot, amelyhez ez a csomag hozzá van rendelve. Egy példa alább látható.

Vissza a Technológiához WebRTC, vagy inkább annak használó részére JÉG protokoll (tehát Jég jelöltek). Csomó p2 egy jelöltje van (helye a hálózatban - 10.50.200.10 ), és a csomópont p1, amely egy NAT-os útválasztó mögött található, két jelöltje lesz - helyi ( 192.168.0.200 ) és router jelölt ( 10.50.200.5 ). Az első nem hasznos, de mégis létrejön, hiszen WebRTC még nem tud semmit a távoli gazdagéprő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 kikötőnek fontos szerepe lesz (a továbbjutásban NAT).

Táblázat bejegyzés NAT csak akkor jön létre, amikor az adatok kilépnek a belső hálózatból. Ezért a csomópont p1 először az adatokat kell továbbítani, és csak ezt követően a csomópont adatait p2 eljuthat a csomóponthoz p1.

A gyakorlatról mindkét csomópont mögött lesz NAT. Bejegyzés létrehozása táblázatban NAT Minden útválasztónak a csomópontoknak küldeni kell valamit a távoli csomópontnak, de ezúttal sem az első nem érheti el a másodikat, sem fordítva. Ez annak a ténynek köszönhető, hogy a csomópontok nem ismerik a külsőjüket IP címekre, és az adatok belső címekre küldése értelmetlen.

Ha azonban a külső címek ismertek, akkor a kapcsolat könnyen létrejön. Ha az első csomópont adatokat küld a második csomópont útválasztójának, akkor a router figyelmen kívül hagyja azokat, mivel a táblája NAT míg üres. A táblázat első csomópontjának útválasztójában azonban NAT rekordra volt szükség. 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ópontnak. Most az asztal NAT a második útválasztó rendelkezik a szükséges adatokkal.

A probléma az, hogy ahhoz, hogy megismerje a külső IP címet, akkor egy csomópontra van szükség közös 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 létrejönnek a táblázatban szereplő kincses rekordok is. NAT.

STUN és TURN szerverek

Inicializáláskor WebRTC elérhető KÁBÍTÁSés FORDULAT szerverek, amelyekre úgy fogunk hivatkozni JÉG szerverek. Ha a szerverek nincsenek megadva, akkor csak ugyanabban a hálózatban lévő csomópontok (csatlakozva hozzá anélkül NAT). Azonnal meg kell jegyezni, hogy azért 3g- hálózatokat kell használni FORDULAT szerverek.

KÁBÍTÁS szerver csak egy szerver az interneten, amely visszatér visszaszállítási cím, amely a küldő gazdagép címe. Az útválasztó mögötti csomópont eléri KÁBÍTÁS szerveren kell keresztülmenni NAT. A csomag, ami megérkezett KÁBÍTÁS szerver, tartalmazza a forráscímet - az útválasztó címét, vagyis a csomópontunk külső címét. Ezt a címet KÁBÍTÁS szerver és visszaküldi. Így a csomópont megkapja a külsőjét IP cím és port, amelyen keresztül elérhető a hálózatról. További, WebRTC ennek a címnek a használata további jelöltet hoz létre (külső útválasztó címe és portja). Most a táblázatban NAT az útválasztónak van egy bejegyzése, amely a szükséges porton a routernek küldött csomagokat továbbítja a csomópontunknak.

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

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

KÁBÍTÁS a szervert jelöli s1. Router, mint korábban, át r1, és a csomóponton keresztül p1. A táblázatot is követnie kell NAT- jelöljük úgy r1_nat. Ezenkívül ez a táblázat általában sok bejegyzést tartalmaz különböző alhálózati csomópontokból – ezeket nem adjuk meg.

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

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

Csomó p1 elküldi ezt a csomagot a routernek r1(bárhogyan is, a különböző alhálózatokban különböző technológiák használhatók). Az útválasztónak ki kell cserélnie a forráscímet src IP, mivel a csomagban megadott cím biztosan nem alkalmas a külső alhálózatra, ráadásul ebből a tartományból a 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 rekord az asztalodban r1_nat. Ehhez ki kell találnia egy portszámot. Emlékezzünk arra, hogy mivel egy alhálózaton belül több csomópont is hozzáférhet egy külső hálózathoz, akkor a táblázatban NAT meg kell tartani további információígy az útválasztó meg tudja határozni, hogy a kiszolgálótól érkező visszatérő csomag melyik állomás közül melyikre szánja. Hagyja, hogy a router találjon ki egy portot 888 .

Módosított csomag fejléc:

4. táblázat: A NAT-tábla új bejegyzéssel frissítve

Itt IP az alhálózat 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. IP a külső hálózat címe a router címe, a port pedig a router által kitaláltra változott.

Az igazi port, amelyhez a csomópont p1 elfogadja a kapcsolatot – ez természetesen 35777 , de a szerver adatokat küld a címre kitalált kikötő 888 , amelyet a router az igazira változtat 35777 .

Tehát az útválasztó megváltoztatta a forráscímet és a portot a csomag fejlécében, és hozzáadott egy bejegyzést a táblázathoz NAT. Most a csomag elküldésre kerül a hálózaton keresztül a szervernek, vagyis a csomópontnak s1. a bejáratnál, s1 van ez a csomag:

src IP	Src PORT	Cél IP	CÉGKIKÖTŐ
10.50.200.5	888	12.62.100.200	6000

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

Teljes KÁBÍTÁS a szerver tudja, hogy kapott egy csomagot a címről 10.50.200.5:888 . Most a szerver visszaküldi ezt a címet. Itt érdemes megállni, és újra átgondolni, amit az imént gondoltunk. A fenti táblázatok részét képezik fejléc csomagot, egyáltalán nem belőle tartalom. A tartalomról nem beszéltünk, hiszen az nem olyan fontos – valahogy le van írva a jegyzőkönyvben KÁBÍTÁS. Most a címen kívül a tartalmat is figyelembe vesszük. Egyszerű lesz, és tartalmazza az útválasztó címét - 10.50.200.5:888 bár mi onnan vettük fejléc csomag. Ezt nem szokták megtenni, általában a protokollok nem törődnek a csomópontok címére vonatkozó információkkal, csak az a fontos, hogy a csomagok célba kerüljenek. Itt egy olyan protokollt tekintünk, amely útvonalat hoz létre két csomópont között.

Tehát most van egy második tétel, amely 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 útválasztó külső interfészét r1. Az útválasztó megérti, hogy a csomag nem neki való. Ő hogy érti? Ezt csak a kikötő találja meg. Kikötő 888 nem személyes céljaira használja, hanem a mechanizmushoz használja NAT. Ezért a router belenéz ebbe a táblázatba. Nézi az oszlopot Külső PORTés keres egy megfelelő karakterláncot CÉGKIKÖTŐ a bejövő csomagból, azaz 888 .

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, hogy létezik ilyen vonal. Ha nem lenne szerencsés, akkor a csomagot egyszerűen eldobnák. Most meg kell értenie, hogy az alhálózati csomópontok közül melyik küldje el ezt a csomagot. Ne kapkodjunk, foglaljuk össze a portok fontosságát 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 első csomóponthoz a router talált egy portot 888 , akkor a másodikra ​​kitalál egy portékát 889 . Tegyük fel, hogy ez történt, vagyis az asztal r1_natígy néz ki:

10. táblázat: A router hamis vevő címe

src IP	Src PORT	Cél IP	CÉGKIKÖTŐ
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 csomóponthoz p1és a csomag tartalmát megnézve a csomópont megismeri annak külsőjét IP cím, vagyis a router címe a külső hálózatban. Ismeri azt a portot is, amelyen az útválasztó áthalad NAT.

Mi a következő lépés? Mi haszna ennek az egésznek? A haszon egy bejegyzés a táblázatban r1_nat. Ha most valaki elküldi a routernek r1 port csomag 888 , akkor az útválasztó továbbítja ezt a csomagot a gazdagépnek p1. Így egy kis szűk átjáró jött létre a rejtett csomóponthoz p1.

A fenti példából képet kaphat a működéséről. NATés a lényeg KÁBÍTÁS szerver. Általában a mechanizmus JÉGés KÁBÍTÁS/FORDULÁS a szerverek csak a korlátozások leküzdését célozzák NAT.

A csomópont és a szerver között több útválasztó is lehet, de több is. Ebben az esetben a csomópont megkapja annak az útválasztónak a címét, amelyik elsőként lép be ugyanabba a hálózatba, mint a szerver. Más szóval, megkapjuk a csatlakoztatott útválasztó címét KÁBÍTÁS szerver. Mert p2p A kommunikáció az, amire szükségünk van, ha nem felejtjük el, hogy minden routerben a szükséges vonal hozzáadódik a táblázathoz NAT. Így a visszaút ismét ugyanolyan sima lesz.

FORDULAT a szerver javult KÁBÍTÁS szerver. Ebből azonnal következik, hogy bármely FORDULAT a szerver működhet és hogyan KÁBÍTÁS szerver. Vannak azonban előnyei is. Ha egy p2p kommunikáció nem lehetséges (mint pl 3g hálózatok), majd a szerver átkapcsol átjátszó módba ( relé), azaz közvetítőként működik. Természetesen bármelyikről p2p akkor ez nem kérdés, hanem kívül esik a mechanizmus keretein JÉG a csomópontok úgy gondolják, hogy közvetlenül kommunikálnak.

Milyen esetekben szükséges FORDULAT szerver? Miért nem elég KÁBÍTÁS szerverek? Az tény, hogy több típusa van NAT. Ugyanazt cserélik IP címet és portot, de némelyikük beépített kiegészítő védelem"hamisítástól". Például be szimmetrikus asztal NAT 2 további paraméter mentve - IPés a távoli gazdagép portja. A külső hálózatról érkező csomag áthalad NAT a belső hálózatra csak akkor, ha a forrás címe és portja megegyezik a táblázatban rögzítettekkel. Ezért a hangsúly KÁBÍTÁS szerver meghibásodik - táblázat NAT címet és portot tárol KÁBÍTÁS szervert, és amikor az útválasztó csomagot kap tőle WebRTC beszélgetőpartnere, elveti, mivel „hamisítják”. Nem onnan jött KÁBÍTÁS szerver.

Ily módon FORDULAT szerverre van szükség, ha mindkét beszélgetőpartner mögötte van szimmetrikus NAT(mindegyik a magáét).

Rövid összefoglaló

Íme néhány állítás az entitásokról WebRTC amit mindig szem előtt kell tartani. 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 szinkronban
  • A médiafolyamok lehetnek helyiek és távoliak, a lokálishoz általában kamera és mikrofon 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
  • WebRTC külső jelzőmechanizmust használ - a munkamenetleírók továbbításának feladatát ( sdp) az alkalmazásra esik
  • A logikai kapcsolódási mechanizmus két szakaszból áll - egy javaslatból ( ajánlat) és válasz ( válasz)
  • A munkamenet leíró generálása nem lehetséges helyi médiafolyam használata nélkül ajánlat esetén ( ajánlat), és nem lehetséges távoli munkamenet-leíró használata nélkül válasz esetén ( válasz)
  • A kapott leírót meg kell adni a megvalósításhoz WebRTC, és nem számít, hogy ezt a leírót távolról vagy helyileg ugyanabból a megvalósításból szerezzük be WebRTC
  • A munkamenet-leíró kis mértékben módosítható
• Jelöltek
  • jelölt ( Jég jelölt) a hálózat csomópontjának címe
  • A csomópont címe lehet a saját, vagy egy router címe, ill FORDULAT szerverek
  • Mindig sok jelölt van
  • A jelölt a következőkből áll IP cím, kikötő és a szállítás típusa ( TCP vagy UDP)
  • 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 a jelzőmechanizmuson keresztül is el kell küldeni
  • A jelölteknek megvalósításon is át kell menniük WebRTC, de csak távoli
  • Egyes megvalósításokban WebRTC A jelöltek csak a munkamenetleíró beállítása után adhatók át
• STUN/TURN/ICE/NAT
  • NAT– egy külső hálózathoz való hozzáférést biztosító mechanizmus
  • Az otthoni útválasztók egy speciális táblázatot támogatnak NAT
  • Az útválasztó lecseréli a csomagokban lévő címeket - a forráscímet a sajátjával, ha a csomag a külső hálózatba megy, és a célcímet a belső hálózatban lévő gazdagép címére, ha a csomag külső hálózatról érkezett.
  • Többcsatornás hozzáférés biztosítása külső hálózathoz NAT portokat használ
  • JÉG- bypass mechanizmus NAT
  • KÁBÍTÁSés FORDULAT szerverek - segítő szerverek az áthidaláshoz NAT
  • KÁBÍTÁS a szerver lehetővé teszi a szükséges bejegyzések létrehozását a táblázatban NAT, és visszaadja a csomópont külső címét is
  • FORDULAT- általánosít a szerver KÁBÍTÁS mechanizmust, és mindig működőképessé teszi
  • A legrosszabb esetekben FORDULAT a szervert közvetítőként használják ( relé), vagyis p2p kliens-szerver-kliens kapcsolattá alakul.