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), amelyek két hálózati interfésszel rendelkeznek - a hálózatukon 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) néhány előzetes lépést meg kell tenni a kapcsolat létrehozásához. 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 sokféle kommunikációs módszert alkalmaz munkája során ( 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 a helyi szálhoz. 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 legalább tartalmaznia kell a különböző típusú adatok - videó és hang - tárolásának képességét. 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 lesz 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, 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érkeztünk a médiafolyamok egyik 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á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 tudják, a sztereó hang két különböző hang. É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 lehet több is, ha több különböző videót kell átvinned (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)

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 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. Ez a munkamenet-leíró idegen ettől a csomóponttól, ezért hasznos információkat tartalmaz. 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 út a hálózati csomópontok számára az adatok továbbításához. 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 érkeznek, é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ásainkra vonatkozó információkat tartalmazott, 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 kapcsolódni. Megjegyezzük itt 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ím. 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ásokat ( 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 pontos formátum, 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 egy 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 közös hálózaton található csomópontra van szüksége. 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 egyszerűen egy szerver az interneten, amely visszaküldi a visszaküldési címet, vagyis a küldő gazdagépének címét. 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 nyilvánvalóan 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 új bejegyzést hoz létre a táblájá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 csomópont is hozzáférhet egy külső hálózathoz, akkor a táblázatban NAT további információkat kell tárolni, hogy az útválasztó meg tudja határozni, hogy e több gazdagép közül melyikre szánja a szerverről érkező visszatérő csomagot. 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ím és port, de némelyikük beépített kiegészítő védelemmel rendelkezik a „hamisítás” ellen. 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 a videó- ​​és hangadatok elérhető kódolási módszereiről.
  • 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 külső hálózatba megy, és a vevő címét 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.

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. Így a hang- és képadatok nem haladnak á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. Közvetlen kapcsolat esetén a WebRTC nem igényel regisztrációt vagy fiókot semmilyen szolgáltatáshoz.

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 mobilverzióik ezzel a technológiával és az alkalmazások által használt Android 5.0-val telepített WebView 3.6 motorral is fel vannak szerelve.

A valós idejű kommunikációhoz a megfelelő JavaScript felületeket kell megvalósítani a webes megjelenítőben. A GetUserMedia segítségével a szoftver lehetővé teszi a rögzítést hang- és videoforrásokról, azaz webkameráról és mikrofonról. Az RTCPeerConnection felelős a kapcsolat létrehozásáért, valamint magáért a kommunikációért.

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

A WebRTC megelégszik kevéssel

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

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

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

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

Hogyan jön létre a kapcsolat

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

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

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

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

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

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

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

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

A böngészőből való hívás technológiái sok évesek: Java, ActiveX, Adobe Flash... Az elmúlt néhány évben világossá vált, hogy a beépülő modulok és a bal oldali virtuális gépek nem ragyognak a kényelemtől (miért telepítsek semmit a minden?), és ami a legfontosabb, a biztonság . Mit kell tenni? Van kijárat!

Egészen a közelmúltig számos protokollt használtak az IP-hálózatokban IP-telefonáláshoz vagy -videóhoz: a SIP, a legáltalánosabb protokoll, a H.323 és az MGCP, 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 úgy próbálja megfordítani az IP és webes telefonálás világát, hogy minden softphone-t, így a Skype-ot is elavulttá teszi. A WebRTC nemcsak közvetlenül a böngészőben valósítja meg az összes kommunikációs képessé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ó általánosabb feladatát (különböző adatok cseréje, képernyőfordítás, együttműködés a dokumentumokkal, ill. sokkal több).

WebRTC egy webfejlesztőtől

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

• a helyi erőforrásokból (kamera, mikrofon vagy helyi számítógép képernyője) származó médiafolyamok kezelését a navigator.getUserMedia metódus valósítja meg, amely egy MediaStream objektumot ad vissza;
• médiafolyamokat generáló eszközök közötti peer-to-peer kommunikáció, 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ük meg a WebRTC-n alapuló legegyszerűbb többjátékos videocsevegést a böngészők között webaljzatok segítségével. Kezdjük a kísérletezést 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 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.

médiafolyam

Az első és legegyszerűbb WebRTC összetevő a MediaStream. A böngésző számára hozzáférést biztosít 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 ugyanez a függvény neve navigator.mozGetUserMedia()). Amikor hívják, a felhasználó felkéri, hogy engedélyezze a hozzáférést a kamerához és a mikrofonhoz. A hívás folytatására csak a felhasználó hozzájárulása után van lehetőség. A kívánt médiafolyam és két visszahívási funkció paraméterei adódnak át ehhez a funkcióhoz: az elsőt a kamera/mikrofon sikeres elérése esetén hívja meg, a másodikat pedig hiba esetén. Először hozzunk létre egy rtctest1.html HTML fájlt egy gombbal és egy elemmel

getUserMedia

Microsoft CU-RTC-Web

A Microsoft nem lenne Microsoft, ha a Google kezdeményezésére válaszul nem adná ki azonnal saját, inkompatibilis egyéni változatát, a CU-RTC-Web-et (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web.htm). . Bár az IE már amúgy is csekély részesedése tovább csökken, a Skype-felhasználók száma reményt ad a Microsoftnak a Google nyomulására, és feltételezhető, hogy a Skype böngészős verziójában is ezt a szabványt fogják használni. 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 hagyományos telefonhálózatban marad, és a hálózat és az IP-hálózatok közötti átjárókra nemcsak a könnyebb használat vagy a gyorsabb elosztás miatt van szükség, hanem a bevételszerzés eszközeként is, amely több játékos számára teszi lehetővé fejleszteni őket. Egy újabb szabvány megjelenése nemcsak azt eredményezheti, hogy a fejlesztők kellemetlen igényt támasztanak két, egymással össze nem egyeztethető technológia egyidejű támogatására, hanem a jövőben is szélesebb választékot biztosítanak 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 szál engedélyezése

Belső címkék HTML-fájlunkban deklaráljunk egy globális változót a médiafolyam számára:

VarlocalStream = null;

A getUserMedia metódus első paramétere a kért médiafolyam paramétereinek megadása – 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" ), "nem kötelező": ) );

A getUserMedia metódus második paramétere egy visszahívási függvény átadása, amely sikeresen meghívásra kerül:

Függvény getUserMedia_success(stream) ( console.log("getUserMedia_success():", stream); localVideo1.src = URL.createObjectURL(stream); // Médiafolyam csatolása HTML elemhez

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 – hozzáférés kérése a mikrofonhoz és a kamerához az első gomb megnyomásakor

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

A helyileg megnyitott fájlból nem lehet elérni a médiafolyamot. Ha ezt próbáljuk megtenni, hibaüzenetet kapunk:

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.

Kiválaszthatja, hogy a Chrome mely eszközöket érje el a Beállítások, Speciális beállítások link megjelenítése, Adatvédelem szakasz és Tartalom gomb segítségével. Firefox és Opera böngészőkben az eszközök közvetlenül a legördülő listából kerülnek kiválasztásra a hozzáférés megadásakor.

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

Ügyeljen a lapon lévő ikonban lévő lüktető körre és a címsáv jobb oldalán lévő kamera ikonra:

RTCMediaConnection

RTCMediaConnection - egy objektum, amely médiafolyamok létrehozására és átvitelére szolgál a hálózaton keresztül a résztvevők között. Ezen túlmenően ez az objektum felelős a médiamunkamenet-leírás (SDP) létrehozásáért, a NAT-on vagy a tűzfalakon (helyi és STUN-t használó) való áthaladáshoz szükséges információk beszerzéséért, valamint a TURN szerverrel való interakcióért. Minden résztvevőnek kapcsolatonként egy RTCMediaConnection-nel kell rendelkeznie. A médiafolyamok továbbítása titkosított SRTP protokollon keresztül történik.

TURN szerverek

Háromféle ICE jelölt létezik: host, srflx és relay. A gazdagép helyileg szerzett információkat tartalmaz, az srflx azt jelenti, hogy a gazdagép hogyan néz ki egy külső kiszolgáló számára (STUN), a relay pedig a TURN szerveren keresztüli proxy forgalomra vonatkozó információ. Ha a csomópontunk NAT mögött van, akkor a host jelöltek helyi címeket tartalmaznak, és használhatatlanok, az srflx jelöltek csak bizonyos típusú NAT-ok esetén segítenek, és a továbbítás az utolsó remény, hogy a forgalmat egy köztes szerveren továbbítsák.

Példa egy host típusú ICE jelöltre 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 servers = ( "iceServers": [ ( "url": "stun:stun.stunprotocol.org:3478" ), ( "url": "turn: [e-mail védett]:port", "credential": "jelszó" ) ]);

Az interneten számos nyilvános STUN szerver található. Egy nagy lista például a . Sajnos túl kevés problémát oldanak meg. A STUN-nal ellentétben gyakorlatilag nincs nyilvános TURN szerver. Ez annak a ténynek köszönhető, hogy a TURN szerver átengedi magán a médiafolyamokat, 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. Alatta van még egy kész kép is az Amazon EC2-hez.

A TURN-nél nem minden úgy van jól, mint szeretnénk, de aktív fejlesztés folyik, és szeretném remélni, hogy egy idő után a WebRTC, ha nem is a Skype-mal egyenlő a címfordítás (NAT) áthaladásának minőségében, ill. tűzfalak, akkor legalább érezhetően közelebb kerüljenek.

Az RTCMediaConnection-nek egy további mechanizmusra van szüksége 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 többi résztvevő általi továbbítást külön kell megvalósítani.

Az átviteli mód megválasztása a fejlesztő felelőssége – legalábbis manuálisan. Amint a szükséges adatok kicserélődnek, az RTCMediaConnection automatikusan beállítja 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 (ajánlat / válasz; az RFC3264-ben leírtak szerint) és az SDP protokoll (Session Description Protocol) használatos. Ezeket a SIP protokoll is használja. Ebben a modellben két ügynököt különböztetnek meg: Ajánlattevő - az, aki létrehozza az SDP-munkamenet 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 az SDP-munkamenet leírását egy másik ügynöktől, és válaszol. hozzá saját munkamenetleírásával (SDP válasz). 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 átviteléért felelős.

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

• Az első csatlakozást kezdeményező fél Ajánlatot alkot, amelyben elküld egy SDP adatstruktúrát (ugyanezt a protokollt ugyanarra a célra használják a SIP-ben), amely leírja annak a médiafolyamnak a lehetséges jellemzőit, amelyet éppen közvetíteni készül. Ezt az adatblokkot át kell adni a második résztvevőnek. A második résztvevő választ generál 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ára szolgáló eljárást, melynek segítségével a második résztvevő át tudja juttatni nekik a médiafolyamot. 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.

Ajánlat kialakítása

Az ajánlat kialakításához két funkcióra van szükségünk. Az elsőt sikeres kialakítása esetén hívjuk meg. 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 adatfolyam már elérhető).

Ezenkívül két eseménykezelőre van szükség: az onicecandidate-re, amikor egy új ICE-jelöltet definiálnak, és az onaddstream-et, amikor egy médiafolyam csatlakozik a távoli oldalról. Térjünk vissza az aktánkhoz. Hozzáadás a HTML-hez az elemeket tartalmazó sorok után még egy:

CreateOffer

És az elemmel ellátott sor után

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

varpc1;

Az RTCPeerConnection konstruktor meghívásakor meg kell adnia a STUN/TURN szervereket. További részleteké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 SDP kiépítési lehetőségei

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); // A theConne által generált RTCPeerction beállítása SDP setLocalDescription metódus felajánlása. // Amikor a távoli oldal elküldi az Answer SDP-t, akkor azt a setRemoteDescription metódussal kell beállítani // Amíg a második oldal nincs implementálva, ne csináljon semmit // 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álunk egy visszahívási függvényt, amelyet az ICE jelöltek a definíció szerint továbbítanak:

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

Valamint 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 eddig csak egy RTCPeerConnection-ünk van):

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

Amikor a „createOffer” gombra kattint, hozzon létre egy RTCPeerConnection-t, állítsa be az onicecandidate és onaddstream metódusokat, és kérje Offer SDP létrehozását a createOffer() metódus meghívásával:

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.onaddonadstream =d pc1.onaddonad / Visszahívási függvény akkor hívható meg, ha van médiafolyam a túloldalról, de még nem létezik pc1.addStream(localStream); // A helyi médiafolyam átadása (feltételezve, hogy már megkapta) pc1.createOffer(// És valójában kérje az Ajánlat létrehozását pc1_createOffer_success , pc1_createOffer_error, offerConstraints); )

Mentsük el a fájlt rtctest2.html néven, tegyü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 a médiamunkamenet-paraméterek leírása, az elérhető kodekek, médiafolyamok és az ICE jelöltek lehetséges opciók a 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 adni a másik oldalra, és ott, miután megkapta őket az RTCPeerConnection-től, hívja meg a setRemoteDescription metódusokat az Ajánlat SDP-hez és addIceCandidate-et minden túloldalról kapott ICE jelölthez; hasonlóan fordítva az Answer SDP és a távoli ICE jelölteknél. 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 átadja a hívótól kapott Offer SDP-t.

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:

Varpc2;

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

A válasz kialakítása SDP nagyon hasonló az ajánlathoz. A válasz sikeres formálása esetén meghívott visszahívási funkcióban az Ajánlathoz hasonlóan 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 válasz generálása közben fellépő hiba esetén meghívott visszahívás teljesen hasonló az Ajánlathoz:

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

Paraméterek az Answer SDP generálásához:

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

Amikor a második résztvevő ajánlatot kap, hozzon létre egy RTCPeerConnection-t, és adjon meg egy választ az ajánlathoz hasonlóan:

pc2_receivedOffer(desc) függvény ( console.log("pc2_receiveOffer()", desc); // Hozzon létre egy RTCPeerConnection objektumot a második résztvevő számára, hasonlóan az elsőhöz pc2 = new webkitRTCPeerConnection(servers); pc2.onicecandidate = pc2_onice Állítsa be az eseménykezelőt, amikor az ICE jelölt pc2.onaddstream = pc_onaddstream; // Amikor megjelenik egy adatfolyam, csatlakoztassa a HTML-hez

Annak érdekében, hogy az ajánlati SDP-t az első résztvevőtől a másodikhoz vigye, a példánk részeként törölje a megjegyzést a pc1 függvényben CreateOffer success() hívási karakterlánc:

Pc2_receivedOffer(desc);

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

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); )

Kapcsolat megszakítása

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

rakd le

És egy funkció a kapcsolat befejezésére

Függvény btnHangupClick() ( // Helyi videó letiltása HTML elemekből

Mentsük el rtctest3.html néven, tegyük fel a szerverre és nyissuk meg a böngészőben. Ez a példa kétirányú médiastreamelést valósít meg két RTCPeerConnection között ugyanazon a böngészőlapon. 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 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, a közvetlen hívás helyett. eljárások.

Screen Broadcast

A getUserMedia funkcióval a képernyőt és a streamet MediaStreamként is rögzítheti 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 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 streamet nem szabad kérni;
• több kérést nem szabad ugyanazon a böngészőlapon benyújtani.

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

A WebRTC ugyan még nem készült el, de már több erre épülő könyvtár is megjelent. 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 leegyszerűsíti az adatcseréhez szükséges 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

A többi operációs rendszer telepítését ismertetjük

Nézzük meg:

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

Az npm (Node Package Manager) segítségével telepítse a socket.io fájlt és a kiegészítő expressz modult:

$ npm telepítse a socket.io expresst

Ellenőrizzü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"); // adja meg a HTML fájlt ) ) ; io.sockets.on("kapcsolat", függvény (socket) ( // Csatlakozáskor socket.emit("szerver esemény", ( 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

Indítsuk el a szervert:

$ sudo nodejs nodetest2.js

és nyissa meg a http://localhost:80 oldalt (ha helyileg a 80-as porton fut) egy 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

Ügyfél oldal

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

És a JavaScript szkript elején - web socket kapcsolat:

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) (e 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ény belsejében adja hozzá a kliens üzenetek fogadását és küldését:

Socket.on("ajánlat", függvény (data) ( // Az "ajánlat" üzenet fogadásakor // mivel ebben a példában csak egy kliens kapcsolat van, // küldje vissza az üzenetet ugyanazon a socket.emit( "ajánlat" , adat); // Ha szükséges lenne az üzenet továbbítása minden kapcsolaton // kivéve a feladót: // socket.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 módosítsa a HTML-fájl nevét:

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

Szerver indítása:

$ sudo nodejs nodetest2.js

Annak ellenére, hogy mindkét kliens kódja ugyanazon a böngészőlapon belül 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 zajlik, és már nem nehéz a résztvevőket „elteríteni”. Amit azonban tettünk, az is nagyon egyszerű volt – ezek a technológiák jók a könnyű használatukhoz. Bár néha megtévesztő. 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 feltételes, de ha kissé 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 valósítsuk meg az elemek dinamikus létrehozását és törlését.

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, hogy miként tekintjük az Internetet egészében. A WebRTC nem csak böngésző-böngésző hívástechnológia, hanem valós idejű kommunikációs technológia is. Az általunk elemzett videokommunikáció csak egy kis része a lehetséges felhasználási lehetőségeknek. Már van példa képernyőmegosztásra (képernyőmegosztás), együttműködésre, sőt, az RTCDataChannel segítségével böngésző alapú P2P tartalomszolgáltató hálózatra is.

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

Mi az a WebRTC?

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

Mit kell tudni a WebRTC-ről?

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

Sergey Yutsaitis, Cisco, Video+Conference 2016

Hogyan működik a WebRTC

Az ügyfél oldalon

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

A WebRTC szerver oldalán

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

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

A WebRTC szerver a médiaforgalmat is fogadja a WebRTC társaktól, és adott esetben asztali vagy mobilalkalmazások segítségével továbbítja a konferencia résztvevőinek.

A szabvány előnyei

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

A szabvány hátrányai

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

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

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

WebRTC a videokonferencia piac számára

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

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

Speciális megoldásokban használható

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

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

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

Verseny a vakuval

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

WebRTC videó bemutatók

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

Kodekek a WebRTC-ben

Audiokodekek

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

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

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

Opus egy alacsony kódolási késleltetésű (2,5 ms-tól 60 ms-ig), változó bitsebességű támogatással és nagy tömörítéssel rendelkező kodek, amely ideális a változó sávszélességű hálózatokon történő audio streaminghez. Az Opus egy hibrid megoldás, amely egyesíti a SILK (Voice Compression, Human Speech Distortion Elimination) és a CELT (Audio Data Encoding) kodekek legjobb tulajdonságait. A kodek ingyenesen elérhető, az azt használó fejlesztőknek nem kell jogdíjat fizetniük a szerzői jogok tulajdonosainak. Más audio kodekekhez képest az Opus minden bizonnyal sok szempontból nyer. Elhomályosította az olyan népszerű, alacsony bitsebességű kodekeket, mint az MP3, Vorbis, AAC LC. Az Opus visszaállítja a hang "képét" az eredetihez közelebb, mint az AMR-WB és a Speex. Ez a kodek a jövő, ezért a WebRTC technológia megalkotói beépítették a támogatott hangszabványok kötelező körébe.

Videokodekek

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

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

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

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

WebRTC API

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

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

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

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

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

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

RTC adatcsatorna. A Data Channel protokoll támogatása viszonylag nemrég jelent meg a böngészőkben, így ez az API csak abban az esetben jöhet számításba, ha a WebRTC-t Mozilla Firefox 22+ és Google Chrome 26+ böngészőkben használják. Ezzel a résztvevők szöveges üzeneteket válthatnak a böngészőben.

WebRTC kapcsolat

Támogatott asztali böngészők

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

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

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

WebRTC, Microsoft és Internet Explorer

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

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

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

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

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

0. Jelzőszerver

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

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

1. index.html

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

2.main.js

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

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

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

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

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

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

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

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

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

2.2. webes aljzat

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

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

2.3. Peer kapcsolat beállításai

A legtöbb internetszolgáltató NAT-on keresztül biztosít internetkapcsolatot. Emiatt a közvetlen kapcsolat nem válik annyira triviálissá. A kapcsolat létrehozásakor meg kell adnunk a STUN és TURN szerverek listáját, amelyeket a böngésző megpróbál a NAT megkerülésére használni. Néhány további csatlakozási lehetőséget is jelezünk.

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

2.4. Új felhasználó csatlakoztatása

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

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

"; }; }

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

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

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

2.5.0 SDP ajánlat

function remoteOfferReceived(id, data) ( createConnection(id); var pc = peers.connection; pc.setRemoteDescription(new SessionDescription(data)); pc.createAnswer(function(answer) ( pc.setLocalDescription(answer); )); ) függvény createConnection(id) ( if (peers === undefined) ( peers = (candidateCache: ); var pc = new PeerConnection(server, options); initConnection(pc, id, "answer"); peers.connection = pc ; pc.ondatachannel = function(e) ( peers.channel = e.channel; peers.channel.owner = id; bindEvents(peers.channel); ) ) )

2.5.1 SDP válaszok

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

2.5.2 ICE jelölt

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

2.6. Üzenet küldése

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