Většina materiálu na WebRTC se zaměřuje na aplikační úroveň psaní kódu a nepřispívá k pochopení technologie. Zkusme jít hlouběji a zjistit, jak ke spojení dochází, co je deskriptor relace a kandidáti, jací jsou OMRÁČIT a OTOČIT SE server.

WebRTC

Úvod

WebRTC je technologie založená na prohlížeči, která umožňuje propojit dva klienty pro přenos video dat. Hlavními funkcemi jsou interní podpora prohlížeče (není potřeba vestavěných technologií třetích stran, jako např adobe flash) a možnost připojení klientů bez použití dalších serverů - připojení peer-to-peer(Dále, p2p).

Navažte spojení p2p- poměrně obtížný úkol, protože počítače nemají vždy veřejné IP adresy, tedy adresy na internetu. Vzhledem k malému množství IPv4 adres (a pro bezpečnostní účely) byl vyvinut mechanismus NAT, která umožňuje vytvářet privátní sítě například pro domácí použití. Mnoho domácích routerů nyní podporuje NAT a díky tomu mají všechna domácí zařízení přístup k internetu, i když poskytovatelé internetu jej většinou poskytují IP adresa. veřejnost IP Adresy jsou na internetu jedinečné, soukromé adresy nikoli. Tak se připojte p2p- obtížné.

Abyste tomu lépe porozuměli, zvažte tři situace: oba uzly jsou ve stejné síti (obrázek 1), oba uzly jsou v různých sítích (jeden soukromý, druhý veřejný) (Obrázek 2) a oba uzly jsou v různých privátních sítích se stejným IP adresy (Obrázek 3).

Obrázek 1: Oba uzly ve stejné síti

Obrázek 2: Uzly v různých sítích (jeden v soukromém, jeden ve veřejném)

Obrázek 3: Uzly v různých privátních sítích, ale s číselně stejnými adresami

Na obrázcích výše první písmeno ve dvouznakovém zápisu označuje typ uzlu (p = peer, r = router). Na prvním obrázku je situace příznivá: uzly v jejich síti jsou zcela identifikovány sítí IP adresy, a proto se k sobě mohou přímo připojit. Na druhém obrázku máme dvě různé sítě, které mají podobná čísla uzlů. Zde se objevují routery (routery), které mají dvě síťová rozhraní – uvnitř své sítě a mimo svou síť. Proto mají dvě IP adresy. Běžné uzly mají pouze jedno rozhraní, přes které mohou komunikovat pouze ve své vlastní síti. Pokud předávají data někomu mimo jejich síť, tak jedině s pomocí NAT uvnitř routeru (routeru) a tudíž viditelné pro ostatní pod IP adresa routeru je jejich externí IP adresa. Tedy uzel p1 tady je interiér IP = 192.168.0.200 a externí IP = 10.50.200.5 , přičemž poslední adresa je také externí vůči všem ostatním hostitelům v jeho síti. U uzlu je situace podobná p2. Proto je jejich spojení nemožné, pokud pouze jejich vnitřní (vlastní) IP adresy. Můžete použít externí adresy, tedy adresy routerů, ale protože všechny uzly ve stejné privátní síti mají stejnou externí adresu, je to docela obtížné. Tento problém je řešen mechanismem NAT

Co se stane, pokud se přesto rozhodneme propojit uzly prostřednictvím jejich vnitřních adres? Data neopustí síť. Pro umocnění efektu si můžete představit situaci znázorněnou na posledním obrázku – oba uzly mají stejné vnitřní adresy. Pokud je použijí ke komunikaci, pak každý uzel bude komunikovat sám se sebou.

WebRTC se s takovými problémy úspěšně vypořádá pomocí protokolu LED, což však vyžaduje použití dalších serverů ( OMRÁČIT, OTOČIT SE). To vše níže.

Dvě fáze WebRTC

Pro připojení dvou uzlů pomocí protokolu WebRTC(nebo jednoduše RTC pokud jsou spojeny dva iPhone„a) k navázání spojení je třeba provést určité předběžné kroky. Toto je první fáze – navázání spojení. Druhou fází je přenos video dat.

Ihned je třeba říci, že i když technologie WebRTC ve své práci používá různé komunikační metody ( TCP a UDP) a má flexibilní přepínání mezi nimi, tato technologie nemá protokol pro předávání dat připojení. Není divu, protože spojte dva uzly p2p není tak snadné. Proto je nutné nějaké mít další způsob přenosu dat, nesouvisející s WebRTC. Může to být soketový přenos, protokol HTTP, může to být i protokol SMTP nebo ruská pošta. Tento přenosový mechanismus hlavní se nazývá data signál. Není třeba přenášet mnoho informací. Všechna data jsou přenášena jako text a jsou rozdělena do dvou typů − SDP a Ledový kandidát. První typ se používá pro navázání logického připojení a druhý pro fyzické připojení. Více o tom později, ale prozatím je důležité si to pamatovat WebRTC nám poskytne nějaké informace, které bude třeba přenést do jiného uzlu. Jakmile přeneseme všechny potřebné informace, uzly se budou moci připojit a naše pomoc již nebude potřeba. Takže signální mechanismus, který musíme implementovat odděleně, bude použito pouze při připojení, a nebudou použity při přenosu video dat.

Podívejme se tedy na první fázi, fázi nastavení připojení. Skládá se z několika položek. Zvažte tuto fázi nejprve pro uzel, který iniciuje připojení, a poté pro čekající.

• Iniciátor (volající - volajícího):
  1. Nabídka zahájení přenosu dat videa (createOffer)
  2. Získání vašeho SDP SDP)
  3. Získání vašeho Kandidát na led Kandidát na led)
• Čekání hovoru ( volaný):
  1. Získání místního (vlastního) mediálního streamu a jeho nastavení pro přenos (getUserMediaStream)
  2. Přijmout nabídku na zahájení přenosu dat videa a vytvořit odpověď (createAnswer)
  3. Získání vašeho SDP předmět a jeho průchod signálním mechanismem ( SDP)
  4. Získání vašeho Kandidát na led předměty a jejich přenos signálním mechanismem ( Kandidát na led)
  5. Příjem vzdáleného (cizího) mediálního streamu a jeho zobrazení na obrazovce (onAddStream)

Jediný rozdíl je ve druhém odstavci.

Přes zdánlivou složitost kroků jsou ve skutečnosti tři: odeslání vlastního mediálního streamu (str. 1), nastavení parametrů připojení (str. 2-4), příjem mediálního streamu někoho jiného (str. 5). Nejtěžší je druhý krok, protože se skládá ze dvou částí: založení fyzický a logický spojení. První naznačuje cesta, po které musí jít pakety, aby se dostaly z jednoho síťového uzlu do druhého. Druhý naznačuje video/audio parametry- jakou kvalitu použít, jaké kodeky použít.

Mentální fáze vytvořit nabídku nebo vytvořitOdpověď by měly být připojeny k převodovým stupňům SDP a Kandidát na led objektů.

Základní entity

Mediální streamy (MediaStream)

Hlavní entitou je mediální tok, tedy tok obrazových a zvukových dat, obrazu a zvuku. Existují dva typy mediálních toků – místní a vzdálené. Místní přijímá data ze vstupních zařízení (kamera, mikrofon) a vzdálené přes síť. Každý uzel má tedy místní i vzdálené vlákno. V WebRTC existuje rozhraní pro streamy mediální stream a existuje také podrozhraní LocalMediaStream speciálně pro místní vlákno. V JavaScript můžete narazit pouze na první, a pokud používáte lib znělka, pak lze narazit i na druhý.

V WebRTC uvnitř vlákna je poněkud matoucí hierarchie. Každý stream se může skládat z několika mediálních stop ( mediální stopa), který se může skládat z několika mediálních kanálů ( MediaChannel). A také může existovat několik samotných mediálních streamů.

Zvažme vše v pořádku. Za tímto účelem si uveďme několik příkladů. Řekněme, že chceme přenášet nejen video sebe, ale i video našeho stolu, na kterém leží papír, na který budeme něco psát. Budeme potřebovat dvě videa (my + stůl) a jedno audio (my). Je jasné, že my a tabulka bychom měli být rozděleni do různých vláken, protože tato data jsou na sobě pravděpodobně slabě závislá. Proto budeme mít dva mediální stream„a – jeden pro nás a jeden pro stůl. První bude obsahovat obrazová i zvuková data a druhá bude obsahovat pouze video (obrázek 4).

Obrázek 4: Dva různé toky médií. Jeden pro nás, jeden pro náš stůl

Okamžitě je jasné, že mediální stream by měl obsahovat alespoň možnost obsahovat data různých typů – video a audio. To je v technologii zohledněno, a proto je každý typ dat implementován prostřednictvím mediální stopy. mediální stopa. Mediální stopa má zvláštní vlastnost druh, který určuje, co je před námi - video nebo zvuk (obrázek 5)

Obrázek 5: Mediální toky se skládají z mediálních stop

Jak bude vše v programu probíhat? Vytvoříme dva mediální streamy. Poté vytvoříme dvě video stopy a jednu zvukovou stopu. Pojďme získat přístup ke kamerám a mikrofonu. Řekněme každé stopě, které zařízení použít. Pojďme přidat video a audio stopu do prvního mediálního toku a video stopu z jiné kamery do druhého mediálního toku.

Jak ale rozlišíme mediální toky na druhém konci připojení? Za tímto účelem má každý mediální stream vlastnost označení– označení proudu, jeho název (obrázek 6). Stejnou vlastnost mají mediální stopy. I když se na první pohled zdá, že video lze od zvuku odlišit i jinak.

Obrázek 6: Toky médií a stopy jsou označeny štítky

Pokud lze tedy mediální stopy identifikovat pomocí štítku, proč tedy potřebujeme pro náš příklad použít dva mediální toky místo jednoho? Koneckonců, můžete přenést jeden mediální stream a použít v něm různé stopy. Došli jsme k důležité vlastnosti mediálních toků – oni synchronizovat mediální stopy. Různé mediální toky nejsou synchronizovány mezi sebou, ale v rámci každého mediálního toku jsou všechny stopy hrál ve stejnou dobu.

Pokud tedy chceme, aby naše slova, naše emoce na obličeji a náš kus papíru byly přehrávány současně, pak se vyplatí použít jeden mediální proud. Pokud to není tak důležité, pak je výhodnější použít různé proudy - obraz bude hladší.

Pokud je třeba stopu během přenosu deaktivovat, můžete vlastnost použít povoleno mediální stopy.

Nakonec byste měli přemýšlet o stereo zvuku. Jak víte, stereo zvuk jsou dva různé zvuky. A také je třeba je posílat samostatně. K tomu slouží kanály. MediaChannel. Zvuková mediální stopa může mít mnoho kanálů (například 6, pokud potřebujete zvuk 5+1). Uvnitř mediální stopy, kanály, samozřejmě také synchronizované. Pro video se obvykle používá pouze jeden kanál, ale lze jich použít několik, například pro reklamní překryvy.

Shrnout: k přenosu obrazových a zvukových dat používáme mediální stream. V rámci každého mediálního toku jsou data synchronizována. Pokud nepotřebujeme synchronizaci, můžeme použít více mediálních streamů. V rámci každého mediálního toku jsou dva typy mediálních stop – pro video a pro zvuk. Obvykle nejsou více než dvě stopy, ale může jich být více, pokud potřebujete přenést několik různých videí (účastníka a jeho stolu). Každá stopa se může skládat z několika kanálů, což se obvykle používá pouze pro stereo zvuk.

V nejjednodušší situaci videochatu budeme mít jeden lokální mediální stream, který se bude skládat ze dvou stop - video stopy a zvukové stopy, z nichž každá bude obsahovat jeden hlavní kanál. Video stopa je zodpovědná za kameru, zvuková stopa je pro mikrofon a mediální stream je kontejnerem obou.

Deskriptor relace (SDP)

Různé počítače budou mít vždy různé kamery, mikrofony, grafické karty a další vybavení. Existuje mnoho možností, které mají. To vše musí být koordinováno pro přenos mediálních dat mezi dvěma síťovými uzly. WebRTC provede to automaticky a vytvoří speciální objekt - popisovač relace SDP. Předejte tento objekt jinému uzlu a můžete odesílat mediální data. Jen zatím není spojení s jiným uzlem.

K tomu se používá jakýkoli signalizační mechanismus. SDP lze přenášet i přes zásuvky, dokonce i osobou (řekněte to jinému uzlu telefonicky), dokonce i ruskou poštou. Vše je velmi jednoduché - dostanete hotové SDP a je potřeba to poslat. A po obdržení na druhé straně - převod na oddělení WebRTC. Popisovač relace je uložen jako text a můžete jej změnit ve svých aplikacích, ale obvykle to není nutné. Například při připojení stolního↔telefonu je někdy potřeba vynutit výběr požadovaného zvukového kodeku.

Obvykle při navazování spojení musíte zadat například nějakou adresu URL. Zde to není potřeba, protože vy sami odešlete data do cíle prostřednictvím signalizačního mechanismu. Indikovat WebRTC co chceme nainstalovat p2p připojení musíte zavolat funkci createOffer. Po zavolání této funkce a přidělení speciální zpětné volání‚bude vytvořeno SDP objektu a předán témuž zpětné volání. Vše, co je po vás požadováno, je přenést tento objekt přes síť do jiného uzlu (partnera). Poté na druhém konci přijdou data přes signalizační mechanismus, konkrétně tento SDP objekt. Tento deskriptor relace je tomuto uzlu cizí, a proto nese užitečné informace. Příjem tohoto objektu je signálem k zahájení spojení. Proto s tím musíte souhlasit a zavolat funkci createAnswer. Jedná se o úplnou analogii createOffer . Zpět k vašemu zpětné volání projde lokálním deskriptorem relace a bude muset být předán zpět přes signalizační mechanismus.

Stojí za zmínku, že funkci createAnswer můžete volat až poté, co obdržíte někoho jiného SDP objekt. Proč? Protože místní SDP objekt, který bude generován při volání createAnswer, se musí spoléhat na vzdálené SDP objekt. Pouze v tomto případě je možné sladit nastavení videa s nastavením partnera. Také nevolejte createAnswer a createOffer, dokud neobdržíte místní mediální stream – nebudou mít do čeho zapisovat SDP objekt .

Protože v WebRTC je možné upravit SDP objekt, pak po získání místního popisovače je nutné jej nastavit. Může se to zdát trochu divné projít WebRTC co nám sama dala, ale takový je protokol. Když obdržíte dálkovou rukojeť, musíte ji také nastavit. Na jeden uzel tedy musíte nainstalovat dva deskriptory – svůj vlastní a cizí (tedy místní a vzdálený).

Po takovém podání rukou uzly vědí o svých přáních. Například pokud uzel 1 podporuje kodeky A a B a uzel 2 podporuje kodeky B a C, protože každý uzel zná své vlastní a cizí deskriptory, oba uzly si vyberou kodek B(Obrázek 7). Logika připojení je nyní vytvořena a lze přenášet streamy médií, ale je tu další problém - uzly jsou stále spojeny pouze signalizačním mechanismem.

Obrázek 7: Vyjednávání kodeku

Kandidáti (kandidát na led)

Technika WebRTC snaží se nás zmást svou novou metodikou. Při navazování spojení není zadána adresa uzlu, se kterým se chcete spojit. Nejprve nainstalováno logický připojení, ne fyzický, i když se vždy dělal opak. Ale to se nebude zdát divné, pokud nezapomeneme, že používáme signalizační mechanismus třetí strany.

Takže spojení již bylo navázáno (logické spojení), ale zatím neexistuje žádná cesta pro síťové uzly k přenosu dat. Není to tak jednoduché, ale začněme jednoduše. Nechte uzly být ve stejné privátní síti. Jak již víme, mohou se k sobě snadno připojit prostřednictvím svého vnitřního IP adresy (nebo možná nějaké jiné, pokud se nepoužívají TCP/IP).

Prostřednictvím některých zpětné volání'a WebRTCříká nám Kandidát na led objektů. Přicházejí také v textové podobě a stejně jako u deskriptorů relací je stačí odeslat prostřednictvím signalizačního mechanismu. Pokud deskriptor relace obsahoval informace o našem nastavení na úrovni kamery a mikrofonu, pak kandidáti obsahují informace o naší poloze v síti. Předejte je jinému uzlu a ten se k nám bude moci fyzicky připojit, a protože už má deskriptor relace, může se logicky připojit a data „potečou“. Pokud nám nezapomene poslat svůj kandidátský objekt, tedy informaci o tom, kde se v síti nachází, tak se s ním budeme moci spojit. Zaznamenáváme zde ještě jeden rozdíl oproti klasické interakci klient-server. Komunikace s HTTP serverem probíhá podle schématu požadavek-odpověď, klient odesílá data serveru, který je zpracuje a odešle přes adresu uvedenou v paketu požadavku. V WebRTC potřebuji vědět dvě adresy a spojte je na obou stranách.

Rozdíl od popisovačů relace je v tom, že je třeba nastavit pouze vzdálené kandidáty. Úpravy jsou zde zakázány a nemohou přinést žádné výhody. V některých implementacích WebRTC kandidáty je třeba nastavit až poté, co byly nastaveny úchyty relace.

A proč byl pouze jeden deskriptor relace, ale může být mnoho kandidátů? Protože umístění v síti může být určeno nejen její vnitřní IP adresu, ale také externí adresu routeru, a ne nutně jednu, stejně jako adresy OTOČIT SE servery. Zbytek odstavce bude věnován podrobné diskusi o kandidátech a způsobu připojení uzlů z různých privátních sítí.

Dva uzly jsou tedy ve stejné síti (obrázek 8). Jak je identifikovat? Používáním IP adresy. Není jiná cesta. Pravda, stále můžete používat různé transporty ( TCP a UDP) a různé porty. Toto jsou informace, které jsou obsaženy v kandidátském objektu - IP, PŘÍSTAV, DOPRAVA a některé další. Nechte např. použít UDP doprava a 531 přístav.

Obrázek 8: Dva uzly jsou ve stejné síti

Pak pokud jsme v uzlu p1, pak WebRTC nám dá takový kandidátský objekt - . Nejedná se o přesný formát, ale pouze o schéma. Pokud jsme v uzlu p2, pak je kandidátem . Prostřednictvím signalizačního mechanismu p1 obdrží kandidáta p2(tj. umístění uzlu p2, totiž jeho IP a PŘÍSTAV). Pak p1 může se spojit s p2 přímo. správnější, p1 odešle data na adresu 10.50.150.3:531 v naději, že dosáhnou p2. Nezáleží na tom, zda tato adresa patří k uzlu p2 nebo nějakého prostředníka. Důležité je pouze to, že data budou zasílána přes tuto adresu a mohou se dostat p2.

Dokud jsou uzly ve stejné síti - vše je jednoduché a snadné - každý uzel má pouze jeden kandidátský objekt (vždy myšleno jeho vlastní, tedy jeho umístění v síti). Ale bude mnohem více kandidátů, až budou uzly odlišný sítí.

Přejděme ke složitějšímu případu. Jeden uzel bude za routerem (přesněji za NAT) a druhý uzel bude ve stejné síti s tímto routerem (například na internetu) (obrázek 9).

Obrázek 9: Jeden hostitel za NAT, druhý ne

Tento případ má konkrétní řešení problému, kterým se nyní zabýváme. Domácí router obvykle obsahuje tabulku NAT. Jedná se o speciální mechanismus navržený tak, aby umožnil uzlům v privátní síti routeru přístup například k webovým stránkám.

Předpokládejme, že webový server je přímo připojen k internetu, to znamená, že má veřejný IP* adresa. Ať je to uzel p2. Uzel p1(webový klient) odešle požadavek na adresu 10.50.200.10 . Nejprve jdou data do routeru r1, nebo spíše na jeho interiér rozhraní 192.168.0.1 . Poté si router pamatuje zdrojovou adresu (adresu p1) a zapíše jej do speciální tabulky NAT, poté změní zdrojovou adresu na svou vlastní ( p1 → r1). Dále podle externí router odesílá data přímo na webový server p2. Webový server zpracuje data, vygeneruje odpověď a odešle ji zpět. Odesílá do routeru r1, protože je to on, kdo je ve zpáteční adrese (směrovač změnil adresu na svou). Router přijímá data, dívá se do tabulky NAT a odešle data do uzlu p1. Router zde funguje jako prostředník.

Ale co když několik uzlů z vnitřní sítě přistupuje k vnější síti současně? Jak router pochopí, komu má poslat odpověď zpět? Tento problém je vyřešen pomocí porty. Když router nahradí adresu hostitele svou vlastní, nahradí také port. Pokud dva uzly přistupují k internetu, router nahradí jejich zdrojové porty rozličný. Poté, když se paket z webového serveru vrátí zpět do routeru, router bude rozumět portu, kterému je tento paket přiřazen. Příklad je níže.

Zpět k Technologii WebRTC, nebo spíše k jeho části, která používá LED protokol (proto Led kandidáti). Uzel p2 má jednoho kandidáta (jeho umístění v síti - 10.50.200.10 ) a uzel p1, který je umístěn za routerem s NAT, bude mít dva kandidáty – místní ( 192.168.0.200 ) a kandidát na směrovač ( 10.50.200.5 ). První z nich není užitečný, ale přesto je generován, protože WebRTC o vzdáleném hostiteli zatím nic neví – může a nemusí být ve stejné síti. Druhý kandidát se bude hodit a jak již víme, důležitou roli bude hrát port (projít NAT).

Vstup do tabulky NAT generované pouze tehdy, když data opustí interní síť. Proto uzel p1 musí nejprve přenést data a teprve poté data uzlu p2 se může dostat do uzlu p1.

Na praxi oba uzly bude pozadu NAT. Chcete-li vytvořit položku v tabulce NAT každý router musí uzly něco poslat vzdálenému uzlu, ale tentokrát ani první nemůže dosáhnout druhého, ani naopak. To je způsobeno tím, že uzly neznají svůj vnější IP adresy a zasílání dat na interní adresy nemá smysl.

Pokud jsou však známy externí adresy, pak se spojení snadno naváže. Pokud první uzel posílá data do routeru druhého uzlu, router je bude ignorovat, protože jeho tabulka NAT zatímco je prázdný. Nicméně v routeru prvního uzlu v tabulce NAT byl potřeba záznam. Pokud nyní druhý uzel posílá data do routeru prvního uzlu, router je úspěšně přenese do prvního uzlu. Nyní stůl NAT druhý router má data, která potřebujete.

Problém je v tom, že chcete znát své vnější IP adresu, potřebujete uzel umístěný na společné síti. K vyřešení tohoto problému se používají další servery, které jsou přímo připojeny k internetu. S jejich pomocí se také vytvářejí cenné záznamy v tabulce. NAT.

Servery STUN a TURN

Při inicializaci WebRTC dostupný OMRÁČIT a OTOČIT SE servery, které budeme označovat jako LED servery. Pokud servery nejsou specifikovány, pak pouze uzly ve stejné síti (k ní připojené bez NAT). Hned je třeba poznamenat, že pro 3g- musí být použity sítě OTOČIT SE servery.

OMRÁČIT server je jednoduše server na internetu, který vrací zpáteční adresu, tedy adresu hostitele odesílatele. Uzel za routerem přistupuje OMRÁČIT server procházet NAT. Balíček, který přišel OMRÁČIT server, obsahuje zdrojovou adresu - adresu routeru, tedy externí adresu našeho uzlu. Tato adresa OMRÁČIT serveru a odešle zpět. Uzel tak získá svou vnější IP adresu a port, přes který je přístupný ze sítě. Dále, WebRTC použití této adresy vytvoří dalšího kandidáta (externí adresu routeru a port). Nyní v tabulce NAT router má záznam, který předává pakety odeslané routeru na požadovaném portu do našeho uzlu.

Podívejme se na tento proces na příkladu.

Příklad (operace serveru STUN)

OMRÁČIT server bude označen s1. Router, jako předtím, skrz r1 a uzel skrz p1. Budete se také muset řídit tabulkou NAT- označme to jako r1_nat. Navíc tato tabulka obvykle obsahuje mnoho položek z různých uzlů podsítě - nebudou uvedeny.

Takže na začátku máme prázdný stůl r1_nat.

Tabulka 2: Záhlaví paketu

Uzel p1 odešle tento paket do routeru r1(bez ohledu na to lze v různých podsítích použít různé technologie). Router musí provést náhradu zdrojové adresy src IP, jelikož adresa uvedená v paketu zjevně není vhodná pro externí podsíť, navíc jsou adresy z tohoto rozsahu rezervovány a ani jedna adresa na internetu takovou adresu nemá. Směrovač provede substituci v paketu a vytvoří novou položku ve své tabulce r1_nat. K tomu potřebuje přijít s číslem portu. Připomeňme, že protože několik uzlů v podsíti může přistupovat k externí síti, pak v tabulce NAT musí být uloženy další informace, aby router mohl určit, kterému z těchto několika hostitelů je návratový paket ze serveru určen. Nechte router přijít s portem 888 .

Změněné záhlaví balíčku:

Tabulka 4: Tabulka NAT aktualizována o nový záznam

Tady IP adresa a port pro podsíť jsou přesně stejné jako u původního paketu. Opravdu, při postbacku musíme mít způsob, jak je úplně obnovit. IP adresa pro externí síť je adresa routeru a port se změnil na ten, který router vymyslel.

Skutečný port, ke kterému uzel p1 přijímá spojení – to samozřejmě 35777 , ale server odesílá data do fiktivní přístav 888 , kterou router změní na real 35777 .

Router tedy změnil zdrojovou adresu a port v hlavičce paketu a přidal záznam do tabulky NAT. Nyní je paket odeslán přes síť na server, tedy uzel s1. u vchodu, s1 má tento balíček:

src IP	Src PORT	Cílová IP	DEST PORT
10.50.200.5	888	12.62.100.200	6000

Tabulka 5: Server STUN přijal paket

Celkový OMRÁČIT server ví, že přijal paket z adresy 10.50.200.5:888 . Nyní server odešle tuto adresu zpět. Stojí za to se zde zastavit a vrátit se k tomu, co jsme právě zvažovali. Výše uvedené tabulky jsou součástí záhlaví balík, vůbec ne z něj obsah. O obsahu jsme nemluvili, protože to není tak důležité - je to nějak popsáno v protokolu OMRÁČIT. Nyní se budeme zabývat kromě názvu také obsahem. Bude to jednoduché a bude obsahovat adresu routeru - 10.50.200.5:888 i když jsme to vzali z záhlaví balík. To se často nedělá, protokoly se většinou nestarají o informace o adresách uzlů, důležité je pouze to, aby byly pakety doručeny na místo určení. Zde uvažujeme protokol, který stanoví cestu mezi dvěma uzly.

Takže teď máme druhou várku, která jde opačným směrem:

Tabulka 7: Server STUN odešle paket s tímto obsahem

Dále paket putuje sítí, dokud nedosáhne vnějšího rozhraní routeru r1. Router chápe, že balíček není určen pro něj. Jak tomu rozumí? To lze zjistit pouze podle přístavu. Přístav 888 nepoužívá pro své osobní účely, ale využívá pro mechanismus NAT. Proto se router podívá do této tabulky. Podívá se na sloup Externí PORT a hledá řetězec, který odpovídá DEST PORT z příchozího balíčku, tzn 888 .

vnitřní IP	Interní PORT	externí IP	Externí PORT
192.168.0.200	35777	10.50.200.5	888

Tabulka 8: Tabulka NAT

Máme štěstí, že taková linka existuje. Pokud by to štěstí nemělo, pak by byl paket jednoduše zahozen. Nyní musíte pochopit, který z uzlů podsítě by měl tento paket odeslat. Nespěchejme, pojďme si zrekapitulovat důležitost portů v tomto mechanismu. Současně mohly dva uzly v podsíti odesílat požadavky do vnější sítě. Pak, pokud pro první uzel router přišel s portem 888 , pak by na druhý přišel s portem 889 . Předpokládejme, že se to stalo, tedy stůl r1_nat vypadá takto:

Tabulka 10: Adresa přijímače falešného routeru

src IP	Src PORT	Cílová IP	DEST PORT
12.62.100.200	6000	192.168.0.200	35777

Tabulka 11: Router změnil adresu přijímače

Paket úspěšně dorazí do uzlu p1 a pohledem na obsah paketu se uzel dozví o jeho vnějším IP adresa, tedy adresa routeru ve vnější síti. Zná také port, kterým router prochází NAT.

Co bude dál? K čemu to všechno je? Benefit je záznam v tabulce r1_nat. Pokud teď někdo pošle na router r1 portový balíček 888 , pak router předá tento paket hostiteli p1. Do skrytého uzlu tak vznikl malý úzký průchod p1.

Z výše uvedeného příkladu můžete získat určitou představu o tom, jak to funguje. NAT a podstatou OMRÁČIT server. Obecně platí, že mechanismus LED a OMRAČENÍ/OTOČENÍ servery jsou zaměřeny pouze na překonání omezení NAT.

Mezi uzlem a serverem může být více než jeden směrovač, ale několik. V tomto případě uzel obdrží adresu routeru, který jako první vstoupí do stejné sítě jako server. Jinými slovy, získáme adresu připojeného routeru OMRÁČIT server. Pro p2p komunikace je přesně to, co potřebujeme, pokud nezapomeneme na to, že v každém routeru se do tabulky přidá linka, kterou potřebujeme NAT. Takže cesta zpět bude zase stejně hladká.

OTOČIT SE server je vylepšen OMRÁČIT server. Z toho okamžitě vyplývá, že jakýkoli OTOČIT SE server může fungovat a jak OMRÁČIT server. Existují však i výhody. Pokud p2p komunikace není možná (jako např 3g sítě), pak se server přepne do režimu opakovače ( relé), to znamená, že funguje jako zprostředkovatel. Samozřejmě o jakémkoli p2p pak to není otázka, ale mimo rámec mechanismu LED uzly si myslí, že komunikují přímo.

V jakých případech je to nutné OTOČIT SE server? Proč nestačí OMRÁČIT servery? Faktem je, že existuje několik typů NAT. Nahrazují to samé IP adresa a port, ale některé z nich mají vestavěnou dodatečnou ochranu proti „falšování“. Například v symetrický stůl NAT Jsou uloženy další 2 parametry - IP a port vzdáleného hostitele. Prochází paket z externí sítě NAT do vnitřní sítě pouze v případě, že zdrojová adresa a port odpovídají těm, které jsou uvedeny v tabulce. Proto zaměření OMRÁČIT server selže - tabulka NAT ukládá adresu a port OMRÁČIT server a když router přijme paket od WebRTC partnera, odhodí ho, protože je „zfalšován“. Nepocházel z OMRÁČIT server.

Takto OTOČIT SE server je potřeba, když jsou oba partneři pozadu symetrický NAT(každý za své).

Stručné shrnutí

Zde je několik prohlášení o entitách WebRTC které je třeba mít stále na paměti. Jsou podrobně popsány výše. Pokud se vám některý z výroků nezdá zcela jasný, přečtěte si příslušné odstavce znovu.

• mediální stream
  • Obrazová a zvuková data jsou zabalena do mediálních toků
  • Toky médií synchronizují mediální stopy, které tvoří
  • Různé mediální streamy nejsou synchronizovány
  • Mediální streamy mohou být lokální i vzdálené, k lokálnímu bývá připojena kamera a mikrofon, vzdálené přijímají data ze sítě v šifrované podobě
  • Existují dva typy mediálních stop – pro video a pro zvuk.
  • Mediální stopy mají možnost zapnutí/vypnutí
  • Mediální stopy se skládají z mediálních kanálů
  • Mediální stopy synchronizují mediální kanály, které tvoří
  • Mediální toky a mediální stopy mají štítky, podle kterých je lze rozlišit
• Rukojeť relace
  • Deskriptor relace se používá k logickému propojení dvou síťových uzlů
  • Deskriptor relace ukládá informace o dostupných metodách kódování pro video a audio data.
  • WebRTC používá externí signalizační mechanismus – úkol předávat deskriptory relace ( sdp) připadá na aplikaci
  • Mechanismus logického spojení se skládá ze dvou fází – návrh ( nabídka) a odpověď ( Odpovědět)
  • Generování deskriptoru relace není možné bez použití místního mediálního streamu v případě nabídky ( nabídka) a není možné bez použití deskriptoru vzdálené relace v případě odpovědi ( Odpovědět)
  • Výsledný deskriptor musí být předán implementaci WebRTC a nezáleží na tom, zda je tento handle získán vzdáleně nebo lokálně ze stejné implementace WebRTC
  • Je možné mírně upravit popisovač relace
• Kandidáti
  • Kandidát ( Kandidát na led) je adresa uzlu v síti
  • Adresa uzlu může být vaše vlastní, nebo to může být adresa routeru popř OTOČIT SE servery
  • Kandidátů je vždy mnoho
  • Kandidát se skládá z IP adresa, přístav a druh dopravy ( TCP nebo UDP)
  • Kandidáti se používají k vytvoření fyzického spojení mezi dvěma uzly v síti
  • Kandidáty je také třeba odeslat prostřednictvím signalizačního mechanismu
  • Kandidáti také musí projít implementacemi WebRTC, ale pouze na dálku
  • V některých implementacích WebRTC Kandidáty lze předat pouze po nastavení deskriptoru relace
• OMRAČENÍ/OTOČENÍ/LED/NAT
  • NAT– mechanismus pro poskytování přístupu k externí síti
  • Domácí routery podporují speciální tabulku NAT
  • Router nahrazuje adresy v paketech - zdrojovou adresu svou vlastní, v případě, že paket jde do vnější sítě, a adresu přijímače adresou hostitele ve vnitřní síti, pokud paket přišel z vnější sítě
  • Poskytování vícekanálového přístupu k externí síti NAT používá porty
  • LED- bypass mechanismus NAT
  • OMRÁČIT a OTOČIT SE servery - pomocné servery pro obcházení NAT
  • OMRÁČIT server umožňuje vytvářet potřebné položky v tabulce NAT a také vrátí externí adresu uzlu
  • OTOČIT SE server zobecňuje OMRÁČIT mechanismus a zajišťuje, aby vždy fungoval
  • V nejhorších případech OTOČIT SE server se používá jako prostředník ( relé), tzn p2p se změní na spojení klient-server-klient.

Evropští uživatelé internetu se dělí na dvě části: podle průzkumu Institutu pro analýzu veřejného mínění v Allenbachu (Německo) se systémy Skype, chat a instant messaging staly nedílnou součástí každodenního života pro 16,5 milionů dospělých a dětí, 9 milionů používat tyto služby případ od případu a 28 milionů se jich nedotkne.

Situace se může změnit, protože Firefox je nyní integrován komunikační technologie v reálném čase (WebRTC), stejně jako samotný klient. Zahájení audio a video chatu nyní není o nic obtížnější než otevření webové stránky. Služby jako Facebook a Skype naopak spoléhají na řešení využívající samostatného klienta a vytvoření účtu.

WebRTC se nejen snadno používá. Tato metoda dokonce umožňuje nastavit přímé spojení mezi dvěma prohlížeči. Zvuková a obrazová data tedy neprocházejí serverem, kde může docházet k přetížení nebo kde správce není zvlášť citlivý na soukromí nebo ochranu dat. S přímým připojením WebRTC nevyžaduje registraci ani účet u žádné služby.

Chcete-li zahájit konverzaci, stačí kliknout na odkaz. Komunikace zůstává soukromá protože datový tok je šifrovaný. Komunikaci v reálném čase prostřednictvím prohlížeče se Google začal aktivně věnovat již v roce 2011, kdy zveřejnil zdrojový kód své implementace WebRTC.

Krátce poté dostaly Chrome a Firefox své vlastní motory WebRTC. V současné době jsou jejich mobilní verze vybaveny jak touto technologií, tak enginem WebView 3.6 nainstalovaným s Androidem 5.0, který využívají aplikace.

Pro komunikaci v reálném čase musí být ve webovém prohlížeči implementována příslušná JavaScriptová rozhraní. S GetUserMedia software umožňuje zachytit ze zdrojů zvuku a videa, tedy z webové kamery a mikrofonu. RTCPeerConnection zodpovídá za navázání spojení, stejně jako za samotnou komunikaci.

Souběžně s integrací prohlížeče prosazuje pracovní skupina World Wide Web Consortium (W3C) proces standardizace WebRTC. Hotovo by mělo být v roce 2015.

WebRTC se spokojí s málem

Použití služby WebRTC nevyžaduje mnoho zdrojů, protože server pouze spojuje kamarády. Navázání spojení také není nijak zvlášť obtížné. Nejprve prohlížeč signalizuje serveru WebRTC, že plánuje zahájit hovor. Přijímá HTTPS odkaz ze serveru - připojení je šifrované. Uživatel odešle tento odkaz svému partnerovi. Prohlížeč poté požádá uživatele o povolení přístupu k webové kameře a mikrofonu.

Pro navázání přímého streamingového spojení s druhou stranou obdrží prohlížeč její IP adresu a konfigurační data ze služby WebRTC. Kamarádův webový prohlížeč dělá totéž.

Aby streamované připojení fungovalo plynule a v dobré kvalitě, pracují v prohlížeči tři enginy. Dva z nich optimalizují a komprimují audio a video data, třetí je zodpovědný za jejich transport. Odesílá data přes protokol SRTP(Secure Real-time Transport Protocol), který umožňuje šifrované streamování v reálném čase.

Pokud se přímé připojení nezdaří, WebRTC hledá jinou cestu. Například k tomu dochází, když nastavení sítě brání serveru STUN v nahlášení IP adresy. Standard WebRTC stanoví, že v tomto případě bude konverzace probíhat, ale s přechodným zahrnutím serveru TURN (Traversal Using Relays around NAT). Takže na webu netscan.co můžete zkontrolovat, zda je WebRTC implementováno na vašem počítači a s vaším přístupem na web.

Jak se vytváří spojení

Nejprve musíte zaregistrovat konverzaci (1). Služba WebRTC poskytuje odkaz, který je třeba odeslat účastníkovi rozhovoru. Prohlížeč pomocí STUNserveru zjistí svou vlastní IP adresu (2), odešle ji službě a obdrží IP partnera pro navázání přímého spojení (3). Pokud STUN selže, konverzace je přesměrována pomocí TURNserveru (4).

Komunikace pomocí technologie WebRTC v prohlížeči je spouštěna pomocí JavaScript kódu. Poté jsou za komunikaci zodpovědné tři enginy: hlasové a video enginy shromažďují multimediální data z webové kamery a mikrofonu a transportní engine kombinuje informace a odesílá stream v zašifrované podobě pomocí Secure Real-time Protocol (SRTP).

Které prohlížeče pracují s WebRTC

Chrome a Firefox jsou vybaveny modulem WebRTC, který využívá služby jako talky.io. Prohlížeč Mozilla může pracovat přímo s vlastním klientem.

Google a Mozilla pokračují v rozvíjení myšlenky komunikace v reálném čase: Chrome může hostit WebRTC konferenci s více účastníky a nový klient Hello ve Firefoxu je vyvíjen s pomocí dceřiné společnosti telekomunikačního gigantu Telefonica. Apple zatím zůstává stranou, WebRTC v Safari zatím nečekejte. Existuje však spousta alternativních aplikací a pluginů pro iOS pro Safari.

Microsoft jde trochu jiným směrem. Jako vlastník konkurenční služby Skype se tato společnost nechystá před WebRTC tak snadno kapitulovat. Místo toho Microsoft vyvíjí technologii nazvanou ORTC (Object Real-Time Communications) pro Internet Explorer.

Rozdíly od WebRTC, jako jsou různé kodeky a protokoly pro navazování kontaktu se serverem, jsou nepatrné a postupem času se pravděpodobně stanou doplněním standardu WebRTC, který bude tyto rozdíly zahrnovat. Pozadu tak zůstává pouze Apple – jako obvykle.

Fotka: výrobní společnosti; goodluz/Photolia.com

Technologie pro volání z prohlížeče jsou staré mnoho let: Java, ActiveX, Adobe Flash... Za posledních pár let se ukázalo, že plug-iny a ponechané virtuální stroje nezáří pohodlností (proč bych si měl něco instalovat na všechny?) a hlavně bezpečnost . Co dělat? Je tu východ!

Až donedávna se v IP sítích pro IP telefonii nebo video používalo několik protokolů: SIP, nejběžnější protokol, který se objevuje na scéně, H.323 a MGCP, Jabber/Jingle (používaný v Gtalku), polootevřený Adobe RTMP* a, samozřejmě zavřený Skype. Projekt WebRTC, iniciovaný společností Google, se snaží zvrátit svět IP a webové telefonie tím, že všechny softwarové telefony, včetně Skype, jsou zastaralé. WebRTC neimplementuje pouze všechny komunikační možnosti přímo uvnitř prohlížeče, který je dnes nainstalován téměř na každém zařízení, ale zároveň se snaží řešit obecnější úkol komunikace mezi uživateli prohlížeče (výměna různých dat, překlad obrazovky, spolupráce s dokumenty, mnohem více).

WebRTC od webového vývojáře

Z pohledu webového vývojáře se WebRTC skládá ze dvou hlavních částí:

• správa mediálních toků z místních zdrojů (kamera, mikrofon nebo obrazovka místního počítače) je implementována metodou navigator.getUserMedia, která vrací objekt MediaStream;
• peer-to-peer komunikace mezi zařízeními generujícími mediální streamy, včetně definice komunikačních metod a jejich přímého přenosu – objekty RTCPeerConnection (pro odesílání a příjem audio a video streamů) ​​a RTCDataChannel (pro odesílání a příjem dat z prohlížeče).

Co děláme?

Zjistíme, jak uspořádat nejjednodušší videochat pro více hráčů mezi prohlížeči založenými na WebRTC pomocí webových soketů. Začněme experimentovat v Chrome/Chromium, jakožto nejpokročilejších prohlížečích z hlediska WebRTC, i když Firefox 22, vydaný 24. června, je téměř dohnal. Je třeba říci, že standard ještě nebyl přijat a API se může verze od verze měnit. Všechny příklady byly testovány v Chromiu 28. Pro jednoduchost nebudeme sledovat čistotu kódu a kompatibilitu mezi prohlížeči.

mediální stream

První a nejjednodušší komponentou WebRTC je MediaStream. Poskytuje prohlížeči přístup k mediálním tokům z kamery a mikrofonu místního počítače. V Chrome to vyžaduje volání funkce navigator.webkitGetUserMedia() (protože standard ještě není dokončen, všechny funkce mají předponu a ve Firefoxu se stejná funkce nazývá navigator.mozGetUserMedia()). Po jejím zavolání bude uživatel vyzván k povolení přístupu ke kameře a mikrofonu. V hovoru bude možné pokračovat až poté, co uživatel dá souhlas. Této funkci jsou předány parametry požadovaného mediálního streamu a dvě funkce zpětného volání: první bude volána v případě úspěšného přístupu ke kameře/mikrofonu, druhá v případě chyby. Nejprve si vytvořte HTML soubor rtctest1.html s tlačítkem a prvkem

getUserMedia

Microsoft CU-RTC-Web

Microsoft by nebyl Microsoft, kdyby v reakci na iniciativu Google okamžitě nevydal svou vlastní nekompatibilní vlastní variantu s názvem CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web.htm). . Přestože podíl IE, již tak malého, stále klesá, počet uživatelů Skypu dává Microsoftu naději, že Google zatlačí a dá se předpokládat, že tento standard bude použit i v prohlížečové verzi Skype. Standard Google se zaměřuje především na komunikaci mezi prohlížeči; zároveň většina hlasového provozu stále zůstává v konvenční telefonní síti a brány mezi ní a IP sítěmi jsou potřebné nejen pro snadné použití nebo rychlejší distribuci, ale také jako prostředek monetizace, který umožní více hráčům rozvíjet je. Vzhled dalšího standardu může nejen vést k nepříjemné potřebě vývojářů podporovat dvě nekompatibilní technologie najednou, ale také v budoucnu dát uživateli širší výběr možné funkčnosti a dostupných technických řešení. Počkej a uvidíš.

Povolit místní vlákno

Uvnitř štítky V našem souboru HTML deklarujme globální proměnnou pro stream médií:

VarlocalStream = null;

Prvním parametrem metody getUserMedia je specifikovat parametry požadovaného mediálního streamu – například jednoduše povolit zvuk nebo video:

Var streamConstraints = ( "audio": true, "video": true ); // Žádost o přístup ke zvuku i videu

Nebo zadejte další parametry:

Var streamConstraints = ( "audio": true, "video": ( "mandatory": ( "maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5" ), "nepovinné": ) );

Druhým parametrem metody getUserMedia je předání funkce zpětného volání, která bude volána, pokud bude úspěšná:

Funkce getUserMedia_success(stream) ( console.log("getUserMedia_success():", stream); localVideo1.src = URL.createObjectURL(stream); // Připojení streamu médií k prvku HTML

Třetím parametrem je funkce zpětného volání, obsluha chyb, která bude volána v případě chyby.

Funkce getUserMedia_error(error) ( console.log("getUserMedia_error():", chyba); )

Vlastní volání metody getUserMedia – vyžádání přístupu k mikrofonu a kameře po stisknutí prvního tlačítka

Funkce getUserMedia_click() ( console.log("getUserMedia_click()"); navigator.webkitGetUserMedia(streamConstraints, getUserMedia_success, getUserMedia_error); )

Není možné získat přístup k mediálnímu proudu ze souboru otevřeného lokálně. Pokud se o to pokusíme, dostaneme chybu:

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

Nahráme výsledný soubor na server, otevřeme jej v prohlížeči a v reakci na požadavek, který se objeví, povolme přístup ke kameře a mikrofonu.

Chcete-li vybrat, ke kterým zařízením bude Chrome přistupovat, přejděte do Nastavení, Zobrazit odkaz na pokročilá nastavení, část Ochrana osobních údajů, tlačítko Obsah. V prohlížečích Firefox a Opera se zařízení vybírají z rozevíracího seznamu přímo při udělení přístupu.

Při použití protokolu HTTP bude po načtení stránky vyžadováno oprávnění při každém přístupu k mediálnímu streamu. Přepnutí na HTTPS vám umožní zobrazit požadavek jednou, pouze při prvním přístupu k mediálnímu streamu.

Věnujte pozornost pulzujícímu kruhu v ikoně na kartě a ikoně fotoaparátu na pravé straně adresního řádku:

Připojení RTCMedia

RTCMediaConnection - objekt určený k vytvoření a přenosu mediálních toků po síti mezi účastníky. Kromě toho je tento objekt zodpovědný za generování popisu mediální relace (SDP), získávání informací o kandidátech ICE pro průchod NAT nebo firewally (lokální a používající STUN) a interakci se serverem TURN. Každý účastník musí mít jedno připojení RTCMediaConnection na připojení. Toky médií jsou přenášeny přes šifrovaný protokol SRTP.

TURN servery

Existují tři typy kandidátů ICE: hostitel, srflx a relé. Host obsahuje informace získané lokálně, srflx je to, jak hostitel vypadá na externím serveru (STUN), a relay jsou informace pro proxy provoz přes server TURN. Pokud je náš uzel za NAT, pak kandidáti na hostitele budou obsahovat místní adresy a budou k ničemu, kandidáti srflx pomohou pouze s určitými typy NAT a přenos bude poslední nadějí na přenos provozu přes zprostředkující server.

Příklad kandidáta ICE typu hostitel s adresou 192.168.1.37 a portem udp/34022:

A=candidate:337499441 2 udp 2113937151 192.168.1.37 34022 typ generace hostitele 0

Obecný formát pro specifikaci serverů STUN/TURN:

Var servers = ( "iceServers": [ ( "url": "stun:stun.stunprotocol.org:3478" ), ( "url": "turn: [e-mail chráněný]:port", "credential": "heslo" ) ]);

Na internetu je mnoho veřejných STUN serverů. Velký seznam je například . Bohužel řeší příliš málo problémů. Na rozdíl od STUN prakticky neexistují žádné veřejné servery TURN. To je způsobeno skutečností, že server TURN prochází mediální streamy skrz sebe, což může výrazně zatížit jak síťový kanál, tak samotný server. Nejjednodušší způsob, jak se připojit k serverům TURN, je tedy nainstalovat si je sami (samozřejmě budete potřebovat veřejnou IP). Ze všech serverů je podle mého názoru nejlepší rfc5766-turn-server . Pod ním je dokonce již hotový obrázek pro Amazon EC2.

S TURN není vše tak dobré, jak bychom si přáli, ale probíhá aktivní vývoj a chtěl bych doufat, že po nějaké době se WebRTC, pokud se nebude vyrovnat Skype, pokud jde o kvalitu průchodu překladem adres (NAT) a firewally, pak se alespoň znatelně přiblížit.

RTCMediaConnection potřebuje pro navázání spojení další mechanismus pro výměnu řídících informací – tato data sice generuje, ale nepřenáší je a přenos ostatními účastníky musí být realizován samostatně.

Volba způsobu přenosu je v kompetenci vývojáře – alespoň ručně. Jakmile dojde k výměně potřebných dat, RTCMediaConnection automaticky nastaví streamy médií (pokud je to samozřejmě možné).

model nabídka-odpověď

K vytvoření a úpravě mediálních toků se používá model nabídka / odpověď (nabídka / odpověď; popsáno v RFC3264) a protokol SDP (Session Description Protocol). Používá je také protokol SIP. V tomto modelu se rozlišují dva agenti: Offerer - ten, kdo generuje popis SDP relace za účelem vytvoření nového nebo modifikuje existující (Offer SDP), a Answerer - ten, kdo obdrží popis relace SDP od jiného agenta a odpovídá. na to s jeho vlastním popisem relace (Odpověď SDP). Specifikace zároveň vyžaduje protokol vyšší úrovně (například SIP nebo jeho vlastní přes webové zásuvky, jako v našem případě), který je zodpovědný za přenos SDP mezi agenty.

Jaká data je třeba předat mezi dvěma připojeními RTCMediaConnection, aby mohla úspěšně navázat mediální toky:

• První strana, která zahájí spojení, vytvoří nabídku, ve které odešle datovou strukturu SDP (stejný protokol se pro stejný účel používá v SIP) popisující možné charakteristiky mediálního toku, který se chystá začít vysílat. Tento datový blok musí být přenesen na druhého účastníka. Druhý účastník vygeneruje odpověď se svým SDP a zašle ji prvnímu.
• První i druhý účastník provádějí postup pro určení možných kandidátů ICE, pomocí kterého jim druhý účastník může přenést mediální stream. Jakmile jsou kandidáti identifikováni, informace o nich by měly být předány jinému účastníkovi.

Formace nabídky

K vytvoření nabídky potřebujeme dvě funkce. První bude vyvolán v případě jeho úspěšného vytvoření. Druhým parametrem metody createOffer() je funkce zpětného volání volaná v případě chyby při jejím provádění (za předpokladu, že je již dostupný místní stream).

Navíc jsou potřeba dva obslužné programy událostí: onicecandidate, když je definován nový kandidát ICE, a onaddstream, když je mediální tok připojen ze vzdálené strany. Vraťme se k našemu souboru. Přidat do HTML za řádky s prvky ještě jeden:

vytvořit nabídku

A po řádku s prvkem

Na začátku kódu JavaScript také deklarujeme globální proměnnou pro RTCPeerConnection:

varpc1;

Při volání konstruktoru RTCPeerConnection musíte zadat servery STUN/TURN. Další podrobnosti viz postranní panel; Pokud jsou všichni účastníci ve stejné síti, nejsou vyžadováni.

var servery = null;

Možnosti pro poskytování služeb SDP

var offerConstraints = ();

Prvním parametrem metody createOffer() je funkce zpětného volání volaná po úspěšném vytvoření nabídky

Funkce pc1_createOffer_success(desc) ( console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:", desc); pc1.setLocalDescription(desc); // Nastavení RTCPeerConnection generovaného Nabídněte metodu SDP setLocalDescription. // Když vzdálená strana odešle svou odpověď SDP, bude nutné ji nastavit pomocí metody setRemoteDescription // Dokud nebude implementována druhá strana, nedělejte nic // pc2_receivedOffer(desc); )

Druhým parametrem je funkce zpětného volání, která bude volána v případě chyby

Funkce pc1_createOffer_error(error)( console.log("pc1_createOffer_success_error(): error:", error); )

A deklarujeme funkci zpětného volání, která bude předána kandidátům ICE, jak jsou definováni:

Funkce pc1_onicecandidate(event)( if (event.candidate) ( console.log("pc1_onicecandidate():\n"+ event.candidate.candidate.replace("\r\n", ""), event.candidate); // Nedělejte nic, dokud nebude implementována druhá strana // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

Stejně jako funkce zpětného volání pro přidání mediálního streamu ze vzdálené strany (pro budoucnost, protože zatím máme pouze jedno RTCPeerConnection):

Funkce pc1_onaddstream(event) ( console.log("pc_onaddstream()"); remoteVideo1.src = URL.createObjectURL(event.stream); )

Když kliknete na tlačítko „createOffer“, vytvořte RTCPeerConnection, nastavte metody onicecandidate a onaddstream a požádejte o vytvoření nabídky SDP voláním metody createOffer():

Funkce createOffer_click() ( console.log("createOffer_click()"); pc1 = nový webkitRTCPeerConnection(servers); // Vytvoření připojení RTCPeerConnection pc1.onicecandidate = pc1_onicecandidate; // Funkce zpětného volání pro zpracování kandidátů ICE pc1.onaddonad = pc1_onaddonad; / Funkce zpětného volání volaná, když existuje mediální stream ze vzdálené strany, zatím neexistuje pc1.addStream(localStream); // Předání místního mediálního streamu (za předpokladu, že již byl přijat) pc1.createOffer(// A vlastně požádat o vytvoření nabídky pc1_createOffer_success , pc1_createOffer_error, offerConstraints); )

Uložme soubor jako rtctest2.html, dáme ho na server, otevřeme v prohlížeči a v konzoli uvidíme, jaká data se při jeho provozu generují. Druhé video se zatím neobjeví, protože je pouze jeden účastník. Připomeňme, že SDP je popis parametrů mediální relace, dostupné kodeky, mediální toky a kandidáti ICE jsou možnými možnostmi připojení k tomuto účastníkovi.

Vytvoření odpovědi SDP a výměna kandidátů ICE

Nabídka SDP i každý z kandidátů ICE musí být předány druhé straně a tam, po jejich obdržení z RTCPeerConnection, zavolejte metody setRemoteDescription pro nabídku SDP a addIceCandidate pro každého kandidáta ICE přijatého z druhé strany; podobně obráceně pro Answer SDP a vzdálené ICE kandidáty. Samotný Answer SDP je tvořen obdobně jako Nabídka; rozdíl je v tom, že se nevolá metoda createOffer, ale metoda createAnswer a před tím se předá metoda RTCPeerConnection setRemoteDescription Offer SDP přijatá od volajícího.

Pojďme do HTML přidat další prvek videa:

A globální proměnná pro druhé RTCPeerConnection pod deklarací první:

Varpc2;

Zpracování nabídky a odpovědi SDP

Vytvoření odpovědi SDP je velmi podobné nabídce. Ve funkci zpětného volání vyvolané po úspěšném vytvoření odpovědi, podobně jako v nabídce Offer, uvedeme místní popis a předáme přijatý SDP odpovědi prvnímu účastníkovi:

Funkce pc2_createAnswer_success(desc) ( pc2.setLocalDescription(desc); console.log("pc2_createAnswer_success()", desc.sdp); pc1.setRemoteDescription(desc); )

Funkce zpětného volání volaná v případě chyby při generování odpovědi je zcela podobná nabídce:

Funkce pc2_createAnswer_error(error) ( console.log("pc2_createAnswer_error():", chyba); )

Parametry pro generování odpovědi SDP:

Var answerConstraints = ( "povinné": ( "OfferToReceiveAudio":true, "OfferToReceiveVideo":true) );

Když druhý účastník obdrží nabídku, vytvořte RTCPeerConnection a vytvořte odpověď stejným způsobem jako nabídka:

Funkce pc2_receivedOffer(desc) ( console.log("pc2_receiveOffer()", desc); // Vytvoří objekt RTCPeerConnection pro druhého účastníka, podobný prvnímu pc2 = nový webkitRTCPeerConnection(servers); pc2.onicecandidate = pc2 //onicecandidate;; Nastavit obslužnou rutinu události, když kandidát ICE pc2.onaddstream = pc_onaddstream; // Když se objeví stream, připojte jej k HTML

Chcete-li přenést nabídku SDP z prvního účastníka na druhého, v rámci našeho příkladu odkomentujte ve funkci pc1 vytvořit nabídkuŘetězec volání success():

Pc2_receivedOffer(desc);

Chcete-li implementovat zpracování kandidátů ICE, odkomentujte v obslužné rutině události připravenosti kandidáta ICE prvního účastníka pc1_onicecandidate() její přenos druhému:

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

Obsluha události připravenosti kandidáta ICE druhého účastníka je zrcadlově podobná prvnímu:

Funkce pc2_onicecandidate(event) ( if (event.candidate) ( console.log("pc2_onicecandidate():", event.candidate.candidate); pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

Funkce zpětného volání pro přidání mediálního streamu od prvního účastníka:

Funkce pc2_onaddstream(event) ( console.log("pc_onaddstream()"); remoteVideo2.src = URL.createObjectURL(event.stream); )

Ukončení spojení

Pojďme přidat další tlačítko v HTML

zavěsit

A funkce pro ukončení spojení

Funkce btnHangupClick() ( // Zakáže místní video z prvků HTML

Uložme to jako rtctest3.html, dáme to na server a otevřeme v prohlížeči. Tento příklad implementuje obousměrné streamování médií mezi dvěma RTCPeerConnections na stejné kartě prohlížeče. Pro organizaci výměny Offer and Answer SDP, ICE kandidátů mezi účastníky a dalších informací prostřednictvím sítě bude nutné implementovat výměnu mezi účastníky pomocí nějakého druhu transportu, v našem případě webových soketů, namísto přímého volání na postupy.

Vysílání obrazovky

Pomocí funkce getUserMedia můžete také zachytit obrazovku a streamovat jako MediaStream zadáním následujících parametrů:

Var mediaStreamConstraints = ( audio: false, video: ( povinné: ( chromeMediaSource: "screen" ), volitelné: ) );

Pro úspěšný přístup na obrazovku musí být splněno několik podmínek:

• povolit příznak snímku obrazovky v getUserMedia() v chrome://flags/,chrome://flags/;
• zdrojový soubor je nutné stáhnout přes HTTPS (původ SSL);
• audio stream nesmí být požadován;
• více požadavků by nemělo být zadáno na stejné kartě prohlížeče.

Knihovny pro WebRTC

Ačkoli WebRTC ještě není dokončen, několik knihoven na něm založených se již objevilo. JsSIP je navržen pro vytváření softwarových telefonů založených na prohlížeči, které pracují s přepínači SIP, jako jsou Asterisk a Camalio. PeerJS zjednoduší vytváření P2P sítí pro výměnu dat a Holla sníží množství vývoje potřebného pro P2P komunikaci z prohlížečů.

Node.js a socket.io

Abychom mohli organizovat výměnu kandidátů SDP a ICE mezi dvěma připojeními RTCPeerConnection přes síť, používáme Node.js s modulem socket.io.

Je popsána instalace nejnovější stabilní verze Node.js (pro Debian/Ubuntu).

$ 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

Je popsána instalace pro jiné operační systémy

Pojďme zkontrolovat:

$ echo "sys=require("util"); sys.puts("Testovací zpráva");" > nodetest1.js $ nodejs nodetest1.js

Pomocí npm (Node Package Manager) nainstalujte socket.io a další expresní modul:

$ npm nainstalovat socket.io express

Pojďme to zkontrolovat vytvořením souboru nodetest2.js na straně serveru:

$ nano nodetest2.js var app = require("express")() , server = require("http").createServer(app) , io = require("socket.io").listen(server); server.listen(80); // Pokud je port 80 bezplatný app.get("/", funkce (req, res) ( // Při přístupu na kořenovou stránku res.sendfile(__dirname + "/nodetest2.html"); // zadejte soubor HTML ) ); io.sockets.on("connection", function (socket) ( // On connection socket.emit("server event", ( hello: "world" )); // send message socket.on("client event", function (data) ( // a deklarovat obsluhu události, když zpráva dorazí z klienta console.log(data); )); ));

A nodetest2.html pro stranu klienta:

$nano nodetest2.html

Spustíme server:

$ sudo nodejs nodetest2.js

a otevřete stránku http://localhost:80 (pokud běží lokálně na portu 80) v prohlížeči. Pokud je vše úspěšné, v konzoli JavaScript prohlížeče uvidíme výměnu událostí mezi prohlížečem a serverem při připojení.

Výměna informací mezi RTCPeerConnection prostřednictvím webových soketů

Strana klienta

Uložme náš hlavní příklad (rtcdemo3.html) pod novým názvem rtcdemo4.html. Zahrňte do prvku knihovnu socket.io:

A na začátku skriptu JavaScript - připojení webového soketu:

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

Nahraďte přímé volání funkcí jiného účastníka zasláním zprávy přes webové sokety:

Funkce createOffer_success(desc) ( ... // pc2_receivedOffer(desc); socket.emit("offer", desc); ... ) funkce pc2_createAnswer_success(desc) ( ... // pc1.setRemoteDescription(desc); socket .emit("odpověď", desc); ) funkce 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); ... )

Ve funkci hangup() místo přímého volání funkcí druhého účastníka odešleme zprávu prostřednictvím webových soketů:

Funkce btnHangupClick() ( ... // remoteVideo2.src = ""; pc2.close(); pc2 = null; socket.emit("hangup", ()); )

A přidejte obslužné nástroje pro příjem zpráv:

Socket.on("nabídka", funkce (data) ( console.log("socket.on("nabídka"):", data); pc2_receivedOffer(data); )); socket.on("odpověď", funkce (data) (e console.log("socket.on("odpověď"):", data); pc1.setRemoteDescription(new RTCSessionDescription(data)); )); socket.on("ice1", funkce (data) ( console.log("socket.on("ice1"):", data); pc2.addIceCandidate(new RTCIceCandidate(data)); )); socket.on("ice2", funkce (data) ( console.log("socket.on("ice2":", data); pc1.addIceCandidate(new RTCIceCandidate(data)); )); socket.on("zavěšení", funkce (data) ( console.log("socket.on("zavěšení")):", data); remoteVideo2.src = ""; pc2.close(); pc2 = null; ));

Serverová část

Na straně serveru uložte soubor nodetest2 pod novým názvem rtctest4.js a do funkce io.sockets.on("connection", function (socket) ( ... ) přidejte příjem a odesílání klientských zpráv:

Socket.on("nabídka", funkce (data) ( // Při přijetí zprávy "nabídka", // protože v tomto příkladu existuje pouze jedno připojení klienta, // odešlete zprávu zpět přes stejný soket socket.emit( "nabídka" , data); // Pokud by bylo nutné přeposlat zprávu na všechna spojení // kromě odesílatele: // socket.broadcast.emit("nabídka", data); )); socket.on("odpověď", funkce (data) ( socket.emit("odpověď", data); )); socket.on("ice1", funkce (data) ( socket.emit("ice1", data); )); socket.on("ice2", funkce (data) ( socket.emit("ice2", data); )); socket.on("zavěšení", funkce (data) ( socket.emit("zavěšení", data); ));

Kromě toho změňte název souboru HTML:

// res.sendfile(__dirname + "/nodetest2.html"); // Odeslání souboru HTML res.sendfile(__dirname + "/rtctest4.html");

Start serveru:

$ sudo nodejs nodetest2.js

Navzdory skutečnosti, že kód obou klientů je spouštěn na stejné kartě prohlížeče, veškerá interakce mezi účastníky v našem příkladu probíhá zcela prostřednictvím sítě a není již obtížné účastníky „rozšířit“. To, co jsme však udělali, bylo také velmi jednoduché – tyto technologie jsou dobré pro jejich snadné použití. I když někdy klamné. Zejména nezapomínejme, že bez serverů STUN / TURN nebude náš příklad fungovat v přítomnosti překladu adres a firewallů.

Závěr

Výsledný příklad je velmi podmíněný, ale pokud mírně univerzalizujeme obsluhu událostí tak, aby se mezi volající a volanou stranou nelišily, místo dvou objektů pc1 a pc2 vytvořte pole RTCPeerConnection a implementujte dynamické vytváření a mazání prvků

Dá se předpokládat, že velmi brzy díky WebRTC dojde k revoluci nejen v našem chápání hlasové a video komunikace, ale také v tom, jak vnímáme internet jako celek. WebRTC je umístěn nejen jako technologie volání mezi prohlížeči, ale také jako komunikační technologie v reálném čase. Videokomunikace, kterou jsme analyzovali, je jen malou částí možných možností jejího využití. Již existují příklady sdílení obrazovky (sdílení obrazovky) a spolupráce a dokonce i síť pro doručování obsahu P2P založená na prohlížeči pomocí RTCDataChannel.

WebRTC (Web Real Time Communications) je standard, který popisuje přenos streamovaných audio dat, video dat a obsahu z prohlížeče a do prohlížeče v reálném čase bez instalace pluginů nebo jiných rozšíření. Standard umožňuje proměnit prohlížeč ve videokonferenční terminál, stačí otevřít webovou stránku a zahájit komunikaci.

Co je WebRTC?

V tomto článku probereme vše, co je o technologii WebRTC pro běžného uživatele známo. Podívejme se na výhody a nevýhody projektu, odhalíme některá tajemství, řekneme si, jak funguje, kde a k čemu slouží WebRTC.

Co potřebujete vědět o WebRTC?

Vývoj video standardů a technologií

Sergey Yutsaitis, Cisco, Video+Conference 2016

Jak funguje WebRTC

Na straně klienta

• Uživatel otevře stránku obsahující značku HTML5
• Prohlížeč požaduje přístup k webové kameře a mikrofonu uživatele.
• Kód JavaScript na stránce uživatele řídí parametry připojení (IP adresy a porty serveru WebRTC nebo jiných klientů WebRTC), aby se obešly NAT a Firewall.
• Při příjmu informací o partnerovi nebo o streamu s konferencí smíchanou na serveru prohlížeč začne vyjednávat o použitých audio a video kodecích.
• Začíná proces kódování a streamování dat mezi klienty WebRTC (v našem případě mezi prohlížečem a serverem).

Na straně serveru WebRTC

Pro výměnu dat mezi dvěma účastníky není vyžadován video server, ale pokud chcete spojit několik účastníků do jedné konference, je server vyžadován.

Video server bude přijímat mediální provoz z různých zdrojů, převádět jej a odesílat uživatelům, kteří používají WebRTC jako terminál.

Server WebRTC bude také přijímat mediální provoz od kolegů WebRTC a předávat jej účastníkům konference pomocí desktopových nebo mobilních aplikací, pokud existují.

Výhody standardu

• Není nutná žádná instalace softwaru.
• Velmi vysoká kvalita komunikace díky:
  • Využití moderních video (VP8, H.264) a audio kodeků (Opus).
  • Automatické přizpůsobení kvality streamu podmínkám připojení.
  • Vestavěné potlačení ozvěny a šumu.
  • Automatické ovládání úrovně mikrofonů účastníků (AGC).
• Vysoká úroveň zabezpečení: všechna připojení jsou zabezpečená a šifrovaná podle protokolů TLS a SRTP.
• K dispozici je vestavěný mechanismus pro zachycení obsahu, jako je plocha.
• Schopnost implementovat jakékoli ovládací rozhraní založené na HTML5 a JavaScriptu.
• Schopnost integrovat rozhraní s libovolnými back-end systémy pomocí WebSockets.
• Projekt s otevřeným zdrojovým kódem – můžete jej vložit do svého produktu nebo služby.
• Skutečná multiplatformní: stejná aplikace WebRTC bude fungovat stejně dobře na jakémkoli operačním systému, stolním počítači nebo mobilu, za předpokladu, že prohlížeč podporuje WebRTC. To ušetří spoustu prostředků na vývoj softwaru.

Nevýhody standardu

• Pro pořádání skupinových audio a video konferencí je nutný videokonferenční server, který by míchal video a audio od účastníků, protože prohlížeč neví, jak synchronizovat více příchozích streamů mezi sebou.
• Všechna řešení WebRTC jsou vzájemně nekompatibilní, protože standard popisuje pouze metody pro přenos videa a zvuku, implementaci metod pro oslovování účastníků, sledování jejich dostupnosti, výměnu zpráv a souborů, plánování a další věci ponechává na dodavatele.
• Jinými slovy, nebudete moci volat z aplikace WebRTC jednoho vývojáře do aplikace WebRTC jiného vývojáře.
• Mixování skupinových konferencí vyžaduje velké množství výpočetních zdrojů, proto tento typ video komunikace vyžaduje zakoupení placeného předplatného nebo investici do její infrastruktury, kdy každá konference vyžaduje 1 fyzické jádro moderního procesoru.

Tajemství WebRTC: Jak prodejci těží z ničivé webové technologie

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

WebRTC pro trh videokonferencí

Zvýšení počtu videokonferenčních terminálů

Technologie WebRTC měla silný dopad na vývoj trhu videokonferencí. Po vydání prvních prohlížečů s podporou WebRTC v roce 2013 se potenciální počet videokonferenčních terminálů po celém světě okamžitě zvýšil o 1 miliardu zařízení. Ve skutečnosti se každý prohlížeč stal videokonferenčním terminálem, který z hlediska kvality komunikace není horší než jeho hardwarové protějšky.

Použití ve specializovaných řešeních

Použití různých knihoven JavaScriptu a rozhraní API cloudových služeb s podporou WebRTC usnadňuje přidání podpory videa do jakýchkoli webových projektů. V minulosti vyžadoval přenos dat v reálném čase, aby se vývojáři učili, jak protokoly fungují, a využívali práci jiných společností, což nejčastěji vyžadovalo dodatečné licencování, což zvyšovalo náklady. WebRTC se již aktivně používá ve službách jako „Volání z webu“, „Online chat podpory“ atd.

Bývalí uživatelé Skype pro Linux

V roce 2014 Microsoft oznámil ukončení podpory projektu Skype pro Linux, což vyvolalo mezi IT profesionály velké nevoli. Technologie WebRTC není vázána na operační systém, ale je implementována na úrovni prohlížeče, tzn. Uživatelé Linuxu budou moci vidět produkty a služby založené na WebRTC jako plnohodnotnou náhradu za Skype.

Soutěž s Flashem

WebRTC a HTML5 byly smrtelnou ranou pro technologii Flash, která už procházela svými zdaleka nejlepšími roky. Od roku 2017 přední prohlížeče oficiálně přestaly podporovat Flash a technologie konečně zmizela z trhu. Flash ale musíte dát za své, protože to byl on, kdo vytvořil trh webových konferencí a nabídl technické možnosti pro živou komunikaci v prohlížečích.

Video prezentace WebRTC

Dmitrij Odintsov, TrueConf, video+konference říjen 2017

Kodeky ve WebRTC

Audio kodeky

Pro kompresi audio provozu ve WebRTC se používají kodeky Opus a G.711.

G.711- nejstarší hlasový kodek s vysokou bitrate (64 kbps), který se nejčastěji používá v tradičních telefonních systémech. Hlavní výhodou je minimální výpočetní zátěž díky použití lehkých kompresních algoritmů. Kodek má nízkou úroveň komprese hlasových signálů a nezavádí dodatečné zpoždění zvuku během komunikace mezi uživateli.

G.711 podporuje velké množství zařízení. Systémy využívající tento kodek se používají snadněji než systémy založené na jiných zvukových kodecích (G.723, G.726, G.728 atd.). Pokud jde o kvalitu, G.711 získal v testování MOS skóre 4,2 (skóre 4-5 je nejvyšší a znamená dobrou kvalitu, podobnou kvalitě hlasového provozu v ISDN a ještě vyšší).

Opus je kodek s nízkou latencí kódování (od 2,5 ms do 60 ms), podporou proměnlivé bitové rychlosti a vysokou kompresí, který je ideální pro streamování zvuku v sítích s proměnlivou šířkou pásma. Opus je hybridní řešení, které kombinuje nejlepší vlastnosti kodeků SILK (Voice Compression, Human Speech Distortion Elimination) a CELT (Audio Data Encoding). Kodek je volně dostupný, vývojáři, kteří jej používají, nemusejí platit licenční poplatky držitelům autorských práv. Ve srovnání s jinými audio kodeky Opus jistě vítězí v mnoha směrech. Zastínil docela populární kodeky s nízkou bitovou rychlostí, jako jsou MP3, Vorbis, AAC LC. Opus obnovuje "obraz" zvuku blíže originálu než AMR-WB a Speex. Tento kodek je budoucností, a proto jej tvůrci technologie WebRTC zařadili do povinné řady podporovaných audio standardů.

Video kodeky

Problémy s výběrem video kodeku pro WebRTC trvaly vývojářům několik let, nakonec se rozhodli použít H.264 a VP8. Téměř všechny moderní prohlížeče podporují oba kodeky. Videokonferenční servery potřebují pro práci s WebRTC pouze jeden.

VP8 je bezplatný video kodek s otevřenou licencí, vyznačující se vysokou rychlostí dekódování video streamu a zvýšenou odolností proti ztrátě snímků. Kodek je univerzální, lze jej snadno implementovat do hardwarových platforem, proto jej vývojáři videokonferenčních systémů často využívají ve svých produktech.

Placený video kodek H.264 se stal známým mnohem dříve než jeho bratr. Jedná se o kodek s vysokým stupněm komprese video streamu při zachování vysoké kvality videa. Vysoká prevalence tohoto kodeku mezi hardwarovými videokonferenčními systémy naznačuje jeho použití ve standardu WebRTC.

Google a Mozilla aktivně propagují kodek VP8, zatímco Microsoft, Apple a Cisco aktivně propagují H.264 (pro zajištění kompatibility s tradičními videokonferenčními systémy). A zde nastává velmi velký problém pro vývojáře cloudových řešení WebRTC, protože pokud všichni účastníci konference používají stejný prohlížeč, pak stačí konferenci jednou smíchat s jedním kodekem, a pokud jsou prohlížeče různé a mezi nimi existuje Safari / Edge, pak bude muset být konference kódována dvakrát různými kodeky, což zdvojnásobí systémové požadavky na mediální server a v důsledku toho i náklady na předplatné služeb WebRTC.

WebRTC API

Technologie WebRTC je založena na třech hlavních API:

• (zodpovídá za to, že webový prohlížeč přijímá audio a video signály z kamer nebo plochy uživatele).
• RTCPeerConnection(zodpovědné za spojení mezi prohlížeči za účelem „výměny“ mediálních dat přijatých z kamery, mikrofonu a desktopu. Mezi „povinnosti“ tohoto API také patří zpracování signálu (vyčištění od vnějšího hluku, úprava hlasitosti mikrofonu) a ovládání přes použité audio a video kodeky) .
• Datový kanál RTC(poskytuje obousměrný přenos dat přes navázané spojení).

Před přístupem k mikrofonu a kameře uživatele prohlížeč požádá o toto oprávnění. V Google Chrome můžete předkonfigurovat přístup v sekci „Nastavení“, v Opeře a Firefoxu se výběr zařízení provádí přímo v okamžiku přístupu z rozevíracího seznamu. Požadavek na povolení se objeví vždy při použití protokolu HTTP a jednou při použití HTTPS:

RTCPeerConnection. Každý prohlížeč účastnící se konference WebRTC musí mít přístup k tomuto objektu. Díky použití RTCPeerConnection mohou mediální data z jednoho prohlížeče do druhého procházet i přes NAT a firewally. Pro úspěšný přenos mediálních proudů si účastníci musí vyměňovat následující data pomocí přenosu, jako jsou webové sokety:

• iniciující účastník zašle druhému účastníkovi Offer-SDP (datová struktura s charakteristikami mediálního toku, který bude přenášet);
• druhý účastník vygeneruje „odpověď“ - Answer-SDP a odešle ji iniciátorovi;
• poté je mezi účastníky zorganizována výměna kandidátů ICE, pokud jsou nějací nalezeni (pokud jsou účastníci za NAT nebo firewally).

Po úspěšném dokončení této výměny mezi účastníky je přímo organizován přenos mediálních streamů (audia a videa).

Datový kanál RTC. Podpora protokolu Data Channel se v prohlížečích objevila poměrně nedávno, takže o tomto API lze uvažovat pouze v případech, kdy se WebRTC používá v prohlížečích Mozilla Firefox 22+ a Google Chrome 26+. S ním si účastníci mohou vyměňovat textové zprávy v prohlížeči.

připojení WebRTC

Podporované prohlížeče pro stolní počítače

• Google Chrome (17+) a všechny prohlížeče založené na jádru Chromium;
• Mozilla Firefox (18+);
• Opera (12+);
• Safari (11+);

Podporované mobilní prohlížeče pro Android

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

WebRTC, Microsoft a Internet Explorer

Microsoft o podpoře WebRTC v Internet Exploreru a ve svém novém prohlížeči Edge velmi dlouho mlčel. Kluci z Redmondu moc neradi vkládají do rukou technologie uživatelům, které neovládají, taková je politika. Ale postupně se věci dostaly ze země, protože. WebRTC již nebylo možné ignorovat a byl oznámen projekt ORTC, odvozený od standardu WebRTC.

ORTC je podle vývojářů rozšířením standardu WebRTC o vylepšenou sadu API založených na JavaScriptu a HTML5, což v překladu do běžného jazyka znamená, že vše bude při starém, standard bude ovládat pouze Microsoft, nikoli Google a jeho vývoj. Sada kodeků byla rozšířena o podporu pro H.264 a některé zvukové kodeky řady G.7XX používané v telefonních a hardwarových videokonferenčních systémech. Možná bude vestavěná podpora RDP (pro přenos obsahu) a zasílání zpráv. Mimochodem, uživatelé Internet Exploreru mají smůlu, podpora ORTC bude pouze v Edge. A samozřejmě taková sada protokolů a kodeků se s trochou krve hodí do Skype pro firmy, což otevírá ještě více obchodních aplikací pro WebRTC.

WebRTC je rozhraní API poskytované prohlížečem, které vám umožňuje organizovat P2P připojení a přenášet data přímo mezi prohlížeči. Na internetu je poměrně dost návodů, jak napsat vlastní videochat pomocí WebRTC. Tady je například článek o Habrém. Všechny jsou však omezeny na připojení dvou klientů. V tomto článku se pokusím hovořit o tom, jak organizovat připojení a výměnu zpráv mezi třemi nebo více uživateli pomocí WebRTC.

Rozhraní RTCPeerConnection je připojení typu peer-to-peer mezi dvěma prohlížeči. Chcete-li připojit tři nebo více uživatelů, budeme muset zorganizovat síť mesh (síť, ve které je každý uzel připojen ke všem ostatním uzlům).
Použijeme následující schéma:

1. Při otevření stránky zkontrolujeme přítomnost ID místnosti v umístění.hash
2. Pokud není zadáno ID místnosti, vygenerujte nové
3. Odešleme signálnímu serveru „zprávu, že se chceme připojit k určené místnosti
4. Signalizační server odešle oznámení o novém uživateli ostatním klientům v této místnosti
5. Klienti, kteří jsou již na pokoji, zašlou nováčkovi nabídku SDP
6. Nováček reaguje na nabídku „s

0. Signalizační server

Jak víte, ačkoli WebRTC poskytuje možnost P2P spojení mezi prohlížeči, stále vyžaduje další přenos pro výměnu servisních zpráv. V tomto příkladu je přenos server WebSocket napsaný v Node.JS pomocí socket.io:

var socket_io = require("socket.io"); module.exports = funkce (server) ( var users = (); var io = socket_io(server); io.on("connection", function(socket) ( // Chcete, aby se do místnosti připojil nový uživatel socket.on( "room ", function(message) ( var json = JSON. parse(message); // Přidání soketu do seznamu uživatelů users = socket; if (socket.room !== undefined) ( // Pokud je soket již v nějaké místnosti ponechte socket.leave(socket.room); ) // Zadejte požadovanou místnost socket.room = json.room; socket.join(socket.room); socket.user_id = json.id; // Odeslat dalším klientům tato místnost obsahuje zprávu o připojení nového účastníka socket.broadcast.to(socket.room).emit("new", json.id); )); // Zpráva související s WebRTC (nabídka SDP, odpověď SDP nebo kandidát ICE) socket.on("webrtc", function(message) ( var json = JSON.parse(message); if (json.to !== undefined && users !== undefined) ( // Pokud zpráva obsahuje příjemce a tento příjemce známý serveru, pošlete zprávu pouze jemu... users.emit("webrtc", zpráva); ) else ( // ...jinak považujte zprávu za broadcast socket.broadcast.to(socket.room).emit("webrtc", zpráva); ) )); // Někdo odpojil socket.on("disconnect", function() ( // Když se klient odpojí, upozorní ostatní socket.broadcast.to(socket.room).emit("leave", socket.user_id); delete users; )); )); );

1. index.html

Zdrojový kód samotné stránky je poměrně jednoduchý. Schválně jsem nevěnoval pozornost layoutu a dalším krásným věcem, jelikož o tom tento článek není. Pokud ji někdo chce udělat krásnou, nebude to těžké.

2.main.js

2,0. Získávání odkazů na prvky stránky a rozhraní WebRTC

var chatlog = document.getElementById("chatlog"); var message = document.getElementById("message"); var connection_num = document.getElementById("číslo_připojení"); var room_link = document.getElementById("room_link");

Stále musíme používat předpony prohlížeče pro přístup k rozhraním WebRTC.

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

2.1. Určení ID místnosti

Zde potřebujeme funkci pro generování jedinečné místnosti a ID uživatele. K tomuto účelu použijeme UUID.

Funkce uuid () ( var s4 = function() ( return Math.floor(Math.random() * 0x10000).toString(16); ); return s4() + s4() + "-" + s4() + "-" + s4() + "-" + s4() + "-" + s4() + s4() + s4(); )

Nyní zkusme z adresy vytáhnout ID místnosti. Pokud toto není nastaveno, vygenerujeme nový. Na stránce zobrazíme odkaz na aktuální místnost a zároveň vygenerujeme identifikátor pro aktuálního uživatele.

VarROOM = umístění.hash.substr(1); if (!ROOM) ( ROOM = uuid(); ) room_link.innerHTML = "Odkaz na místnost"; varME = uuid();

2.2. webovou zásuvku

Ihned po otevření stránky se připojíme k našemu signalizačnímu serveru, odešleme požadavek na vstup do místnosti a specifikujeme obsluhu zpráv.

// Specifikujeme, že když je zpráva uzavřena, musíme odeslat oznámení na server o tomto var socket = io.connect("", ("synchronizace odpojení při uvolnění": true)); socket.on("webrtc", socketReceived); socket.on("new", socketNewPeer); // Okamžitě odešlete požadavek na vstup do místnosti socket.emit("room", JSON.stringify((id: ME, room: ROOM))); // Pomocná funkce pro odesílání adresních zpráv souvisejících s funkcí WebRTC sendViaSocket(type, message, to) ( socket.emit("webrtc", JSON.stringify((id: ME, to: to, type: type, data: message ) ));)

2.3. Nastavení peer připojení

Většina ISP poskytuje připojení k internetu prostřednictvím NAT. Z tohoto důvodu není přímé spojení tak triviální. Při vytváření připojení musíme zadat seznam serverů STUN a TURN, které se prohlížeč pokusí použít k obejití NAT. Uvedeme také několik dalších možností připojení.

Var server = ( iceServers: [ (url: "stun:23.21.150.121"), (url: "stun:stun.l.google.com:19302"), (url: "turn:numb.viagenie.ca", pověření: "sem je vaše heslo", uživatelské jméno: " [e-mail chráněný]") ] ); var options = ( volitelné: [ (DtlsSrtpKeyAgreement: true), // vyžadováno pro připojení mezi Chrome a Firefox (RtpDataChannels: true) // vyžadováno ve Firefoxu pro použití DataChannels API ] )

2.4. Připojování nového uživatele

Když je do místnosti přidán nový peer, server nám pošle zprávu Nový. Funkce bude volána podle výše uvedených obslužných rutin zpráv socketNewPeer.

var peers = (); function socketNewPeer(data) ( peers = (candidateCache: ); // Vytvořte nové připojení var pc = new PeerConnection(server, options); // Inicializujte jej initConnection(pc, data, "offer"); // Uložte peer v seznamu peers peers.connection = pc; // Vytvořte DataChannel, přes který se budou vyměňovat zprávy var channel = pc.createDataChannel("mychannel", ()); channel.owner = data; peers.channel = channel; // Nastavit obslužné rutiny událostí bindEvents(channel); // Vytvoření nabídky SDP pc.createOffer(function(offer) ( pc.setLocalDescription(offer); )); ) function initConnection(pc, id, sdpType) ( pc.onicecandidate = function ( event) ( if (event.candidate) ( // Když je nalezen nový kandidát ICE, přidejte jej do seznamu pro další odesílání peers.candidateCache.push(event.candidate); ) else ( // Když je objevení kandidátů dokončen, bude handler zavolán znovu, ale bez kandidáta // V tomto případě zašleme peerovi nejprve nabídku SDP, popř. Odpověď SDP (v závislosti na parametru funkce)... sendViaSocket(sdpType, pc.localDescription, id); // ...a pak všechny dříve nalezené kandidáty ICE pro (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. Nabídka SDP, odpověď SDP, kandidát ICE

Když je přijata jedna z těchto zpráv, zavoláme odpovídající obsluhu zpráv.

Funkce socketReceived(data) ( var json = JSON.parse(data); switch (json.type) ( case "candidate": remoteCandidateReceived(json.id, json.data); break; case "offer": remoteOfferReceived(json. id, json.data); break; případ "odpověď": remoteAnswerReceived(json.id, json.data); break; ) )

Nabídka 2.5.0 SDP

function remoteOfferReceived(id, data) ( createConnection(id); var pc = peers.connection; pc.setRemoteDescription(new SessionDescription(data)); pc.createAnswer(function(answer) ( pc.setLocalDescription(answer); )); ) funkce createConnection(id) ( if (peers === nedefinováno) ( peers = (candidateCache: ); var pc = nové PeerConnection(server, možnosti); initConnection(pc, id, "odpověď"); peers.connection = pc ; pc.ondatachannel = function(e) ( peers.channel = e.channel; peers.channel.owner = id; bindEvents(peers.channel); ) ) )

2.5.1 Odpovědi SDP

function remoteAnswerReceived(id, data) ( var pc = peers.connection; pc.setRemoteDescription(new SessionDescription(data)); )

2.5.2 Kandidát na ICE

function remoteCandidateReceived(id, data) ( createConnection(id); var pc = peers.connection; pc.addIceCandidate(new IceCandidate(data)); )

2.6. Odeslání zprávy

Stisknutím tlačítka poslat funkce je volána poslat zprávu. Jediné, co dělá, je projít seznam vrstevníků a pokusit se odeslat zadanou zprávu všem.