Väčšina materiálu v WEBRTC. Zameraný na aplikovanú úroveň písania a neprispieva k pochopeniu technológie. Pokúsme sa prehĺbiť a zistiť, ako sa spojenie sa deje, čo je rukoväť a kandidáti na to, čo potrebujete Omráčiť. a Otáčať sa Server.

WEBRTC.

Úvod

WEBRTC - prehliadač orientovaná technológia, ktorá vám umožní pripojiť dvoch klientov pre prenos dát. Hlavné vlastnosti - interná podpora prehliadačov (nepotrebujem Typové technológie tretej strany adobe Flash.) A schopnosť spojiť zákazníkov bez použitia ďalších serverov - pripojenie peer-to-peer (Ďalej, p2p.).

Vytvoriť pripojenie p2p. - pomerne zložitá úloha, keďže počítače nie vždy verejnosti Ip Adresy, ktoré sú adresy na internete. Kvôli malému množstvu IPv4. Mechanizmus (a na účely bezpečnosti) Nat.Čo vám umožňuje vytvoriť súkromné \u200b\u200bsiete, napríklad pre domáce použitie. Teraz sú podporované mnohé domáce smerovače. Nat. A vďaka tomu všetky domáce zariadenia majú prístup na internet, hoci poskytovatelia internetu zvyčajne poskytujú Ip adresa. Verejnosť Ip Adresy sú jedinečné na internete a súkromné \u200b\u200bpoznámky. Preto sa pripojte p2p. - HARD.

Aby sme to pochopili lepšie, zvážte tri situácie: Oba uzly sú na tej istej sieti (Obrázok 1)Oba uzly sú v rôznych sieťach (jedna v súkromí, ostatné na verejnosti) (Obrázok 2) a obe uzly sú v rôznych súkromných sieťach s tým istým Ip Adresy (Obrázok 3).

Obrázok 1: Oba uzly na rovnakej sieti

Obrázok 2: Uzly v rôznych sieťach (jeden v súkromí, iní na verejnosti)

Obrázok 3: Uzly v rôznych súkromných sieťach, ale s numericky rovnakými adresami

Na obrázkoch nad prvým písmenom v dvojitom symbolickej notácii znamená typ jednotky (p \u003d peer., R \u003d. router.). V prvej výkrese je situácia priaznivá: uzly v sieti sú celkom identifikované sieťami Ip a preto môžu byť priamo pripojené priamo k sebe. V druhom výkrese máme dve rôzne siete, ktoré majú podobnú číselnú číslicu uzlov. Tu sú smerovače (smerovače), ktorí majú dve sieťové rozhrania - v rámci svojej siete a mimo ich siete. Takže majú dve Ip Adresy. Konvenčné uzly majú len jedno rozhranie, prostredníctvom ktorého môžu komunikovať len vo svojej sieti. Ak prenášajú údaje niekomu mimo ich siete, potom len s Nat. vnútri routeru (router), a preto viditeľný pre ostatných Ip Adresa smerovača je ich externý Ip adresa. Takže uzol pl existuje interiér Ip = 192.168.0.200 a externý Ip = 10.50.200.5 Navyše, posledná adresa bude externá aj pre všetky ostatné uzly v sieti. Podobná situácia a pre uzol p2.. Ich spojenie je preto nemožné, ak používajú len svoje vnútorné (vlastné) Ip Adresy. Môžete použiť externé adresy, to znamená, že Router Adresy, ale, pretože všetky uzly v jednej súkromnej sieti, rovnaká externá adresa je dosť ťažká. Tento problém sa vyrieši pomocou mechanizmu Nat.

Čo sa stane, ak sa stále rozhodneme pripojiť uzly prostredníctvom svojich interných adries? Údaje neprechádzajú cez sieť. Ak chcete zvýšiť účinok, dokážete si predstaviť, že situácia zobrazená v poslednom obrázku - v oboch uzloch sa zhoduje interné adresy. Ak ich používajú na komunikáciu, každý uzol komunikuje sám.

WEBRTC. S týmito problémami sa úspešne zvládne pomocou protokolu Ľad, ktorá je pravdivá, vyžaduje použitie ďalších serverov ( Omráčiť., Otáčať sa). O tom všetko nižšie.

Dve fázy WEBRTC.

Pripojenie dvoch uzlov prostredníctvom protokolu WEBRTC. (alebo jednoducho RtcAk sú dve záväzné iPhone."A) Je potrebné vykonať niektoré predbežné opatrenia na vytvorenie spojenia. Toto je prvá fáza - nastavenie pripojenia. Druhá fáza je prenos video dát.

Ihneď stojí za to povedať aspoň technológiu WEBRTC. Vo svojej práci využíva mnoho rôznych spôsobov, ako komunikovať ( Tcp. a UDP.) a má flexibilné prepínanie medzi nimi, táto technológia nemá protokol na prenos údajov o pripojení. Nie je prekvapujúce, po tom všetkom pripojte dva uzly p2p. Nie je to tak jednoduché. Preto je potrebné mať nejaké ďalší Metóda prenosu dát, v žiadnom prípade WEBRTC.. Môže to byť prevodovka, protokol Http.Môže to byť dokonca protokolom SMTP. Alebo ruský príspevok. Tento prenosový mechanizmus primárny Údaje sa nazývajú signál. Musíte prejsť toľko informácií. Všetky údaje sa prenášajú ako text a sú rozdelené do dvoch typov - SDP. a Kandidát na ľade.. Prvý typ sa používa na vytvorenie logickej zlúčeniny a druhá pre fyzické. Podrobne o tom všetko neskôr, ale len je dôležité si uvedomiť WEBRTC. Dá nám nejaké informácie, ktoré budú musieť vyjadriť do iného uzla. Akonáhle poskytneme všetky potrebné informácie, uzly budú môcť pripojiť a už nepotrebujú našu pomoc. Teda signálny mechanizmus, ktorý musíme implementovať oddelene, bude použitý iba pri pripojenía pri prenose video údajov sa nepoužijú.

Takže, zvážte prvú fázu - fáza pripojenia spojenia. Pozostáva z niekoľkých položiek. Zvážte túto fázu najprv pre uzol, ktorý iniciuje spojenie, a potom na čakanie.

• Iniciátor (volajúci - volajúci):
  1. Ponuka Štart Video Transfer dát (CRACTAFFER)
  2. Získanie vášho SDP. SDP.)
  3. Dostať sa Kandidát na ľade. Kandidát na ľade.)
• Čakajúci hovor ( callee.):
  1. Získanie miestneho (tvojho) média prúd a nainštalujte ho na prenos (GuesermediaStream)
  2. Získanie vety na spustenie údajov o prenose videa a vytvorenie odpovede (Createandswer)
  3. Získanie vášho SDP. objekt a prenos cez signálový mechanizmus ( SDP.)
  4. Dostať sa Kandidát na ľade. a prechádzajúc ich cez signálový mechanizmus ( Kandidát na ľade.)
  5. Získanie diaľkového (cudzinec) médií a zobrazenie na obrazovke (Onadstream)

Rozdiel len v druhom odseku.

Napriek zdanlivo zmätenosti krokov tu existujú tri: Odoslanie svojho mediálneho prúdu (bod 1), Nastavenie parametrov zlúčenín (pp.2-4), získanie prúdu niekoho iného (str.5). Najkomplikovanejší je druhý krok, pretože sa skladá z dvoch častí: zriadenie fyzický a logický Spojenia. Prvá indikuje cestaCez ktoré balíky by mali ísť z jedného sieťového uzla do druhého. Druhá indikuje parametre videa / zvuku - Čo používať kvalitu na použitie kodekov.

Mentálne etapa vytvoriť. alebo kreateanswer. Mal by byť pripojený k fázam prenosu SDP. a Kandidát na ľade. objektov.

Hlavné esencie

Mediálne toky (mediáre)

Hlavnou podstatou je mediálny prúd, to znamená, že tok video a audio dát, obraz a zvuk. Médiové prúdy sú dva typy - lokálne a odstránené. Miestne prijíma údaje z vstupných zariadení (fotoaparát, mikrofón) a vzdialený cez sieť. Každý uzol má teda miestny a vzdialený prúd. Na adrese WEBRTC. Pre prúdy je rozhranie Mediátový A tiež existuje podiel MiestnyMediaream Najmä pre miestny tok. Na adrese Javascript. Najprv sa môžete stretnúť len a ak používate libjíPotom môžete čeliť druhému.

Na adrese WEBRTC. Vo vnútri prúdu je pomerne mätúca hierarchia. Každé vlákno môže pozostávať z niekoľkých mediálnych skladieb ( Mediatko), ktorý môže pozostávať z niekoľkých mediálnych kanálov ( Mediachannel.). A samotné mediálne prúdy môžu byť tiež trochu.

Zvážte všetko v poriadku. Na to budeme mať nejaký príklad. Predpokladajme, že chceme prenášať nielen video sami seba, ale aj video z nášho stola, na ktorom kus papiera ležiaci, na ktorom budeme niečo písať. Budeme potrebovať dve videá (my + tabuľka) a jeden audio (my). Je jasné, že my a stôl by sme mali byť rozdelené do rôznych potokov, pretože tieto údaje pravdepodobne závisia od seba. Takže budeme mať dve Mediátový'A je jeden pre nás a jeden pre stôl. Prvá bude obsahovať video aj zvukové údaje a druhý je len video (obrázok 4).

Obrázok 4: Dva rôzne mediálne toky. Jeden pre nás jeden pre náš stôl

Je okamžite zrejmé, že mediálny prúd by mal aspoň zahŕňať schopnosť obsahovať údaje z rôznych typov - video a zvuku. To sa berie do úvahy v technológii, a preto sa každý typ údajov realizuje prostredníctvom mediálnej skladby Mediatko. Media Track má špeciálny majetok. milý.ktorý určuje, že pred nami - video alebo audio (obrázok 5)

Obrázok 5: Mediálne toky pozostávajú z mediálnych skladieb

Ako sa to stane v programe? Vytvoríme dva mediálne toky. Potom vytvorte dve video skladby a jednu zvukovú stopu. Získame prístup k fotoaparátom a mikrofónom. Každá skladba zadáme, ktoré zariadenie používame. Pridajte video a zvukovú stopu do prvého mediálneho toku a video skladby z iného fotoaparátu v druhom toku médií.

Ako však rozlišujeme mediálne toky na druhom konci spojenia? Na tento účel má každý tok médií nehnuteľnosť. Štítok - Výtoková značka, jeho meno (obrázok 6). Rovnaká vlastnosť má mediálnu stopu. Aj keď sa na prvý pohľad zdá, že video zo zvuku možno rozlíšiť inými spôsobmi.

Obrázok 6: Médiové prúdy a skladby sú označené značkami

Tak a ak môžu byť mediálne stopy identifikované po štítku, potom by sme mali použiť dva mediálne toky pre náš príklad, namiesto jedného? Koniec koncov, môžete preniesť jeden mediálny prúd a skladby používajú rôzne cesty. Dosiahli sme dôležitú vlastnosť mediálnych prúdov - oni synchronizovať Mediálne skladby. Rôzne mediálne toky nie sú navzájom synchronizované, ale v rámci každého média prúd všetkých skladieb hrajte súčasne.

Ak by sme chceli naše slová, naše emócie na tvári a naše listy papiera sú reprodukované súčasne, stojí za to používať jeden mediálny prúd. Ak to nie je také dôležité, potom je to výhodnejšie používať rôzne prúdy - obraz bude hladší.

Ak sa počas prenosu musí odpojiť nejaká skladba, môžete využiť nehnuteľnosť. povolené. Mediálne skladby.

Na konci stojí za to premýšľať o stereo zvuku. Ako viete, stereofónny zvuk je dva rôzne zvuky. A je potrebné ich odovzdať samostatne. Na tento účel sa používajú kanály. Mediachannel.. Cesta zvuku médií môže mať mnoho kanálov (napríklad 6, ak potrebujete zvuk 5 + 1). Vnútri mediálnych kanálov, samozrejme aj synchronizovaný. Pre video sa zvyčajne používa len jeden kanál, ale niekoľko, napríklad pre reklamu.

Zhrnutie: Na prenos video a zvukových údajov používame médiový prúd. Vo vnútri každého mediálneho prúdu sú údaje synchronizované. Ak nepotrebujeme synchronizáciu, môžeme použiť niekoľko mediálnych prúdov. Vo vnútri každého média prúd je mediálna skladba dvoch typov - pre video a pre zvuk. Skladby sú zvyčajne nie viac ako dva, ale možno viac, ak potrebujete prenášať niekoľko rôznych videí (medziproduktor a jeho tabuľky). Každá dráha môže pozostávať z niekoľkých kanálov, ktorá sa zvyčajne používa len na stereofónny zvuk.

V najjednoduchšej situácii video chatu budeme mať jeden miestny mediálny prúd, ktorý bude pozostávať z dvoch skladieb - video skladieb a zvukových stôp, z ktorých každý bude pozostávať z jedného hlavného kanála. Video stopa je zodpovedná za fotoaparát, audio stopa je na mikrofón a médiový prúd je obaja obaja.

Deskriptor relácie (SDP)

Rôzne počítače budú mať vždy rôzne fotoaparáty, mikrofóny, grafické karty a iné vybavenie. Existuje mnoho parametrov, s ktorými majú. To všetko musí byť koordinované pre prenos dát médií medzi dvoma sieťovými uzlami. WEBRTC. Je to automaticky a vytvorí špeciálny objekt - deskriptor relácie SDP.. Prejdite tento objekt na iný uzol a môžete prenášať dáta médií. Až s pripojením s iným uzlom ešte nie je.

Na tento účel použite akýkoľvek signalizačný mechanizmus. SDP. Môžete sprostredkovať aspoň cez zásuvky, aspoň osoba (informovať ho s iným uzlom telefonicky), dokonca aj poštou Ruska. Všetko je veľmi jednoduché - budete mať pripravený SDP. A je potrebné odoslať. A pri prijímaní na druhej strane - prevod na oddelenie WEBRTC.. Rukoväť relácie je uložená ako text a môže byť zmenený vo svojich aplikáciách, ale spravidla nie je potrebné. Ako príklad, keď sa pripájate, je niekedy potrebný desktopofenefon, aby bol nútený zvoliť požadovaný audio kodek.

Zvyčajne, keď je pripojenie nastavené, musíte zadať určitú adresu, napríklad Url. Nie je potrebné, pretože prostredníctvom signalizačného mechanizmu odosielate cieľové údaje. Naznačovať WEBRTC.Čo chceme nainštalovať p2p. Spojenie, ktoré chcete zavolať na funkciu CrateFfer. Po volaní tejto funkcie a inštrukcií svojmu špeciálnemu zavolaj späť"A bude vytvorená SDP. objekt a prenesený do toho istého zavolaj späť. Všetko, čo sa vyžaduje od vás, je preniesť tento objekt cez sieť na iný uzol (partner). Potom, na druhom konci, budú údaje prechádzať signálovým mechanizmom, konkrétne SDP. objekt. Táto rukoväť relácie pre tento uzol je niekto iný, a preto nesie užitočné informácie. Získanie tohto objektu je signálom na začiatok spojenia. Preto sa s tým musíte dohodnúť a zavolať na funkciu Kreateandswer. Je kompletným analógom CrateFfer. Opäť vo vašom zavolaj späť Prejdite miestny deskriptor relácie a bude potrebné preniesť na signalizačný mechanizmus späť.

Stojí za zmienku, že je možné volať Createandswer funkciu len po prijatí niekoho iného SDP. objekt. Prečo? Pretože miestne SDP. Objekt, ktorý bude generovaný pri volaní Kreateanswer sa musí spoľahnúť na diaľkovom ovládaní SDP. objekt. Len v tomto prípade je možné koordinovať nastavenia videa s nastaveniami partnera. To tiež nestojí za volať kreamentswer a ccaroffer pred prijatím miestneho mediálneho prúdu - nebudú mať čo písať SDP. objekt .

Ako B. WEBRTC. Je možné upraviť SDP. Objekt po obdržaní miestneho deskriptora musí byť nainštalovaný. Môže sa zdať trochu zvláštne, že musíte prenášať WEBRTC. Skutočnosť, že nás dal, ale protokol. Keď dostanete vzdialený deskriptor, musíte byť tiež nainštalovaný. Preto musíte nainštalovať dva deskriptory na jeden uzol - svoj vlastný a niekoho iného (to znamená lokálne a vzdialené).

Po tomto handshake Uzly vedia o svojich želaniach. Napríklad, ak uzol 1 Podporuje kodeky A. a B.a uzol 2 Podporuje kodeky B. a C., Vzhľadom k tomu, každý uzol vie svojich vlastných a deskriptorov niekoho iného, \u200b\u200bobe uzly si vyberú kodek B. (Obrázok 7). Teraz je nainštalovaná logika pripojenia a môžu byť prenášané mediálne prúdy, ale existuje ďalší problém - uzly sú stále spojené so signalizačným mechanizmom.

Obrázok 7: Koordinácia kodekov

Kandidáti (kandidát na ľade)

Technológia WEBRTC. Snaží sa nás zmiasť s novou metodikou. Keď je pripojenia nainštalované, adresa tohto uzla nie je špecifikovaná, s ktorou je potrebné pripojiť. Nainštalovaný ako prvý logický a nie fyzickýHoci to bolo vždy vykonané naopak. Ale to nebude vyzerať zvláštne, ak nezabudnete, že používame signalizačný mechanizmus tretích strán.

Spojenie je už nainštalované (logické pripojenie), ale neexistuje žiadna cesta, ku ktorej môžu sieťové uzly prenášať údaje. Nie je to tak jednoduché, ale začneme s jednoduchým. Nech sú uzly v jednej súkromnej sieti. Ako už vieme, môžu sa ľahko spojiť vo svojich vnútorných Ip adresy (alebo možno pre niektoré iné, ak sa nepoužívajú TCP / IP.).

Prostredníctvom niektorých zavolaj späť'a WEBRTC. Povedz nám Kandidát na ľade. Objektov. Sú tiež prichádzajú do textového formulára a tiež, rovnako ako deskriptory relácie, musia jednoducho dopredu prostredníctvom signalizačného mechanizmu. Ak deskriptor relácie obsahoval informácie o našich inštaláciách na úrovni komory a mikrofónu, potom kandidáti obsahujú informácie o našej polohe v sieti. Preneste ich na iný uzol a bude môcť fyzicky spojiť s nami, a pretože už má deskriptor relácie, je logicky schopný pripojiť a dáta "tok". Ak nezabudne, pošlite nám a jeho predmet kandidáta, to znamená, že informácie o tom, kde je v samotnej sieti, potom sa s ním môžeme pripojiť. Všimnite si ďalší rozdiel od klasickej interakcie klient-server. Komunikácia s HTTP serverom sa vyskytuje podľa schémy reakcie dotazu, klient pošle údaje na server, spracuje ich a posiela ich adresa uvedená v balíku požiadavky. Na adrese WEBRTC. Potreba vedieť dve adresy a pripojiť ich z dvoch strán.

Rozdiel od deskriptorov relácie je, že sú potrebné len vzdialené kandidáti. Úpravy je zakázané a nemôže priniesť žiadny prospech. V niektorých implementáciách WEBRTC. Kandidáti musia byť inštalované až po inštalácii deskriptorov relácie.

A prečo bol deskriptor relácie sám, a možno môže byť veľa kandidátov? Pretože umiestnenie v sieti možno určiť nielen svojím vnútorným Ip adresa, ale aj externá adresa smerovača, a nie nevyhnutne jeden, ako aj adresy Otáčať sa Servery. Zvyšok odseku bude venovaný podrobnému posúdeniu kandidátov a ako pripojiť uzly z rôznych súkromných sietí.

Takže dva uzly sú v tej istej sieti (obrázok 8). Ako ich identifikovať? Prostredníctvom Ip adresy. Žiadny iný spôsob. TRUE, môžete stále používať rôzne dopravy ( Tcp. a UDP.) a rôzne prístavy. Toto sú informácie, ktoré sú obsiahnuté v predmete kandidáta - Ip, Port., Dopravy. A niektoré iné. Nechajte sa použiť napríklad UDP. Doprava I. 531 port.

Obrázok 8: Dve uzly sú v rovnakej sieti.

Potom, ak sme v uzle plT. WEBRTC. Dajte nám takýto predmet kandidáta - . Neexistuje žiadny presný formát, ale len systém. Ak sme v uzle p2., potom je kandidát . Prostredníctvom alarmového mechanizmu pl Získať kandidát p2. (To je umiestnenie uzla p2., menovite jeho Ip a Port.). Potom pl môže pripojiť S. p2. priamo. Správne, pl pošle údaje na adresu 10.50.150.3:531 V nádeji, že sa dostanú p2.. Bez ohľadu na to, či táto adresa patrí do uzla p2. Alebo nejaký sprostredkovateľ. Je dôležité, aby sa prostredníctvom tejto adresy odoslali a mohli dosiahnuť p2..

Zatiaľ čo uzly na tej istej sieti - všetko je jednoduché a jednoduché - každý uzol má len jeden objekt kandidáta (vždy čo znamená jeho vlastné, to znamená jeho umiestnenie v sieti). Ale kandidáti budú oveľa viac, keď uzly budú v rôzny siete.

Zamerajme sa na zložitejšiu príležitosť. Jeden uzol bude za smerovačom (presnejšie, pre NAT) a druhý uzol bude v tej istej sieti s týmto smerovačom (napríklad na internete) (obrázok 9).

Obrázok 9: Jeden uzol pre NAT, iné

Tento prípad má konkrétne riešenie problému, ktorý teraz a zvážte. Domov Router zvyčajne obsahuje tabuľku Nat.. Toto je špeciálny mechanizmus navrhnutý tak, aby zabezpečil, že uzly vo vnútri súkromnej siete smerovača môžu zvládnuť napríklad na webové stránky.

Predpokladajme, že webový server je pripojený priamo na internet, to znamená, že má verejnosť Ip* adresa. Nech je to uzol p2.. Uzol pl (webový klient) Poslať požiadavku na adresu 10.50.200.10 . Po prvé, údaje spadá na smerovač r1alebo skôr na jeho interiér rozhranie 192.168.0.1 . Po tom, smerovač si pamätá adresu zdroja (adresa pl) a vstupuje do špeciálnej tabuľky Nat., potom zmení zdrojovú adresu na jej ( pl → r1). Ďalej, vlastným spôsobom exteriérový Rozhranie smerovača odoslalo údaje priamo na webový server p2.. Spracovanie webových serverov, ktoré údaje vytvárajú odpoveď a odosiela späť. Odosiela smerovač r1Vzhľadom k tomu, že je ten, kto stojí na opačnej adrese (smerovač nahradil adresu jeho). Router dostane údaje, pozerá sa do tabuľky Nat. a postúpi tieto uzly pl. Router tu pôsobí ako sprostredkovateľ.

A čo keď sa niektoré uzly z vnútornej siete súčasne otáča do externej siete? Ako smerovač pochopí, kto poslal odpoveď späť? Tento problém je vyriešený pivo. Keď smerovač nahrádza adresu uzla na jeho, tiež nahrádza prístav. Ak dva uzly odvolávajú na internet, router nahradí ich zdrojové porty rôzny. Potom, keď sa balík z webového servera vráti do smerovača, router pochopí port, ktorý tento balík je priradený. Príklad nižšie.

Návrat na technológiu WEBRTC.alebo skôr, k jeho časti, ktorá používa Ľad Protokol (odtiaľto a Ľad Kandidátov). Uzol p2. má jedného kandidáta (jeho umiestnenie v sieti - 10.50.200.10 ) a uzol plktorý je za routerom s NAT, bude mať dvoch kandidátov - miestne ( 192.168.0.200 ) A kandidáta smerovača ( 10.50.200.5 ). Prvý nie je užitočný, ale je však vygenerovaný, pretože WEBRTC. Neviem nič o vzdialenom uzle - to môže byť v tej istej sieti a možno nie. Druhý kandidát príde šikovný a, ako už vieme, prístav bude hrať dôležitú úlohu (prejsť Nat.).

Záznam v tabuľke Nat. Vytvorí sa len vtedy, keď sa údaje vyplývajú z vnútornej siete. Preto, uzol pl Musí byť prvý, kto prevádza údaje a až po tomto uzle p2. sa bude môcť dostať do uzla pl.

V praxi oba uzly bude v Nat.. Vytvoriť záznam v tabuľke Nat. Každý router, uzly musia poslať niečo do vzdialeného uzla, ale tentoraz ani prvý sa nemôže dostať na druhý ani opak. Je to spôsobené tým, že uzly nepoznajú svoje externé Ip A odosielajú údaje na interné adresy bezvýznamné.

Ak sú však známe externé adresy, pripojenie sa ľahko nainštaluje. Ak je prvý uzol nasadený dáta na druhom routeri nódy, potom ich smerovač ignoruje, od jeho tabuľky Nat. Kým prázdny. V prvom uzolovom smerovači v tabuľke Nat. Potrebný rekord. Ak druhý uzol teraz odosiela dáta do prvého routeru uzla, router ich úspešne prenáša do prvého uzla. A stola Nat. Druhý smerovač potrebuje údaje.

Problém je, že naučiť sa vaše externé Ip Adresa, potrebujete uzol nachádzajúci sa v spoločnej sieti. Na vyriešenie takéhoto problému sa používajú ďalšie servery, ktoré sú priamo pripojené priamo k internetu. Pomocou ich pomoci sa v stole vytvárajú aj vážené záznamy. Nat..

Stun a Turn Server

Pri inicializácii WEBRTC. Musíte určiť dostupné Omráčiť. a Otáčať sa servery, ktoré budú volané v budúcnosti Ľad servery. Ak nie sú uvedené servery, na rovnakej sieti možno pripojiť iba uzly (pripojené k nemu bez Nat.). Okamžite to stojí za zmienku 3g.-set nevyhnutne použitie Otáčať sa Servery.

Omráčiť. server - Toto je len server na internete, ktorý vráti spätnú adresu, to znamená adresu zhromaždenia odosielateľa. Uzol, ktorý prichádza routerom Omráčiť. Server prejsť Nat.. Balený Omráčiť. Server obsahuje zdrojovú adresu - adresa smerovača, ktorý je, externá adresa nášho uzla. Táto adresa Omráčiť. Server a posiela sa späť. Takže uzol dostane jeho externé Ip Adresa a prístav, prostredníctvom ktorého je k dispozícii zo siete. Ďalej, WEBRTC. Pomocou tejto adresy vytvorí ďalší kandidát (externá adresa smerovača a portu). Teraz v tabuľke Nat. Router má záznam, ktorý preskočí pakety odoslané do smerovača požadovaným portom do nášho uzla.

Zvážte tento proces v príklade.

Príklad (pracovný prehrávanie)

Omráčiť. Server bude označený s1.. Smerovač, ako predtým r1a uzol pl. Bude tiež potrebné sledovať tabuľku Nat. - Označujeme to ako r1_NAT.. Okrem toho táto tabuľka zvyčajne obsahuje mnoho záznamov z rôznych uzlov podsiete - nebudú privedení.

Takže na začiatku máme prázdny stôl r1_NAT..

Tabuľka 2: Záhlavie balíka

Uzol pl Odošle tento smerovač balíka r1 (Nezáleží na tom, ako možno použiť rôzne technológie v rôznych podkladoch). Router musí byť nahradený zdrojovou adresou SRC IP.Vzhľadom k tomu, adresa uvedená v balení nie je vhodná pre externú podsiete, navyše sú adresy z tohto rozsahu vyhradené a žiadna adresa na internete nemá takúto adresu. Smerovač v balíku vytvára nahradenie a vytvorí nový záznam do jeho tabuľky r1_NAT.. Aby to urobilo, musí prísť s číslom portu. Pripomeňme, že pretože niekoľko uzlov vnútri podsiete môže pristupovať k externej sieti, potom v tabuľke Nat. Ďalšie informácie by mali byť uložené tak, aby smerovač mohol určiť, ktorý z týchto viacerých uzlov je reverzný balík zo servera. Nechajte router vynájdený port 888 .

Zmenený názov balíka:

Tabuľka 4: Nat tabuľka doplnená novým nahrávaním

Tu Ip Adresa a port pre podsieti je absolútne rovnaký ako zdrojový balík. V skutočnosti, keď je spätný chod, musíme mať spôsob, ako ich úplne obnoviť. Ip Adresa externej siete je adresa smerovača a port sa zmenil na pôvodný smerovač.

Tento port, na ktorom uzol pl spojenie - toto je, samozrejme, 35777 Ale údaje o serveri fiktívny port 888 ktorý sa zmení smerovačom do súčasnosti 35777 .

Router teda nahradil adresu a port zdroja do hlavičky paketov a pridal záznam do tabuľky Nat.. Teraz je balík odoslaný cez sieťový server, to znamená, že uzol s1.. Pri vchode s1. Má taký balík:

SRC IP.	SRC port.	Dest IP.	DEST PORT.
10.50.200.5	888	12.62.100.200	6000

Tabuľka 5: Stunn Server dostal balík

CELKOM, Omráčiť. Server vie, že má balík z adresy 10.50.200.5:888 . Teraz tento server adries pošle späť. Stojí za to zostať a znovu vidieť, že sme práve uvažovali. Tabuľky vyššie sú kusom hlavička balík vôbec obsah. Nehovorili sme o obsahu, pretože to nie je také dôležité - je to nejako popísané v protokole Omráčiť.. Teraz budeme okrem toho zvážiť aj obsah. Bude to jednoduché a obsahujú adresu routeru - 10.50.200.5:888 Aj keď sme to vzali hlavička Balíček. Toto sa nevykoná, nie často, zvyčajne protokoly nie sú dôležitými informáciami o adrese uzlov, je dôležité, aby sa balíky dodali na určený účel. Tu považujeme za protokol, ktorý nastaví cestu medzi dvoma uzlami.

Takže teraz máme druhý balík, ktorý ide opačným smerom:

Tabuľka 7: Server Stun pošle balík s takýmto obsahom

Následne sa balík cestuje cez sieť, kým sa nezobrazí na vonkajšom rozhraní smerovača r1. Smerovač chápe, že balík nie je pre neho určený. Ako to chápe? Dá sa nájsť len v prístave. Port 888 Nepoužíva sa pre svoje osobné ciele, ale používa pre mechanizmus Nat.. Preto v tejto tabuľke, router vyzerá. Pozerá na stĺpec Externý port. a hľadáte reťazec, ktorý sa zhoduje s DEST PORT. Z odoslaného balíka, to znamená 888 .

Vnútorná IP.	Vnútorný port.	Externá IP.	Externý port.
192.168.0.200	35777	10.50.200.5	888

Tabuľka 8: Nat tabuľka

Mali sme šťastie, takáto čiara existuje. Keby to nebolo šťastie, balík by jednoducho vyhodil. Teraz musíte pochopiť, kto z uzlov podsiete je potrebné poslať tento balík. Nepoužívame, zapamätáme si dôležitosť portov v tomto mechanizme. Zároveň by mohli odosielať dva uzly v podsiete žiadosti o externú sieť. Potom, ak prišiel router pre prvý uzol 888 , potom za sekundu prišiel s prístavom 889 . Predpokladajme, že sa to stalo, to znamená r1_NAT. vyzerá takto:

Tabuľka 10: Router nahrádza adresu prijímača

SRC IP.	SRC port.	Dest IP.	DEST PORT.
12.62.100.200	6000	192.168.0.200	35777

Tabuľka 11: Router nahradil adresu prijímača

Balík úspešne prichádza na uzol pl A pri pohľade na obsah balíka sa uzol učí o jeho externom Ip Adresa, ktorá je o adrese smerovača v externej sieti. Tiež pozná port, ktorý smerovač prechádza Nat..

Čo bude ďalej? Aký je prínos z toho? Použitie je záznam v tabuľke r1_NAT.. Ak teraz niekto posiela do smerovača r1 Balenie s portom 888 Potom router presmeruje tento uzol balíka pl. Bol vytvorený malý úzky priechod na skrytý uzol pl.

Z vyššie uvedeného príkladu môžete získať nejakú predstavu o práci. Nat. a podstata Omráčiť. Server. Všeobecne mechanizmus Ľad a Stun / Turn Servery sú práve zamerané na prekonanie obmedzení Nat..

Medzi uzlom a serverom nie je žiadny router, ale niekoľko. V tomto prípade sa uzol dostane adresu tohto smerovača, ktorý je prvý, kto prejde do tej istej siete ako servera. Inými slovami, dostaneme adresu smerovača pripojeného Omráčiť. Server. Pre p2p. Komunikácia Toto je presne to, čo potrebujeme, ak nezabudnete na skutočnosť, že riadok, ktorý potrebujete v každom smerovači, bude pridaný do tabuľky Nat.. Preto bude opak rovnaký ako železo.

Otáčať sa Server je vylepšený Omráčiť. server. Odtiaľ by malo byť okamžite odstránené Otáčať sa Server môže pracovať a ako Omráčiť. server. Existujú však výhody. Ak p2p. Komunikácia je nemožná (napr. 3g. Sieť), Server sa prepne do režimu opakovača ( relé), To znamená, že funguje ako sprostredkovateľ. Samozrejme, že nie p2p. potom to neprichádza, ale mimo mechanizmu Ľad Uzly si myslia, že komunikujú priamo.

V akých prípadoch sú potrebné Otáčať sa server? Prečo nie dosť Omráčiť. Servery? Faktom je, že existuje niekoľko odrôd Nat.. Sú rovnomerne nahradené Ip Adresa a prístav však niektoré z nich majú dodatočnú ochranu pred "falšovaním". Napríklad symetrický Stôl Nat. 2 Ďalšie parametre sa uložia - Ip a vzdialený uzol. Balenie z externej siete prechádza Nat. V internej sieti len vtedy, ak sa zdrojová adresa a port zhodujú s tabuľkou zaznamenanou v tabuľke. Preto sú zamerané S. Omráčiť. Server zlyhá - tabuľka Nat. Ukladá adresu a port Omráčiť. servery a keď router dostane balík WEBRTC. Hovorí, že ho hodí, ako je "falšovaný". Nepochádzal Omráčiť. Server.

Touto cestou Otáčať sa Server je potrebný v prípade, keď sú obaja intervoctors symetrický Nat. (Všetci pre svoje vlastné).

Krátke zhrnutie

Tu sú niektoré vyhlásenia o subjektoch. WEBRTC.To musí byť vždy držané vo vašej hlave. Podrobne sú opísané vyššie. Ak sa zdá, že niektorá z vyhlásení nie je úplne jasné, prečítajte si príslušné odseky.

• Médiový tok
  • Video a audio dáta sú balené v mediálnych prúdoch
  • Médiá Streams Synchronizujte mediálne skladby, z ktorých sa skladajú
  • Rôzne mediálne toky nie sú navzájom synchronizované.
  • Médiá toky môžu byť lokálne a diaľkové, fotoaparát a mikrofón sú zvyčajne pripojené k lokálnemu, odstránenému prijímaniu údajov zo siete v kódovanom formulári.
  • Mediálne skladby sú dva typy - pre video a pre zvuk
  • Mediálne skladby majú možnosť zapnúť / vypnúť
  • Mediálne skladby sa skladajú z mediálnych kanálov
  • Mediálne skladby Synchronizujte mediálne kanály, z ktorých sa skladajú
  • Mediálne toky a mediálne stopy majú štítky, pre ktoré možno rozlíšiť
• Deskriptor
  • Rukoväť relácie sa používa na logickú pripojenie dvoch sieťových uzlov.
  • Rukoväť relácie ukladá informácie o dostupných metódach kódovania videa a zvukových dát.
  • WEBRTC. používa externý signalizačný mechanizmus - úloha presmerovania deskriptorov relácie ( sDP.) Falls na žiadosť
  • Mechanizmus logickej zlúčeniny pozostáva z dvoch stupňov - návrhy ( ponuka.) A odpoveď ( odpoveď.)
  • Generovanie deskriptora relácie je nemožná bez použitia miestneho mediálneho prúdu v prípade návrhu ( ponuka.) a nemožné bez použitia deskriptora vzdialeného relácie v prípade odpovede ( odpoveď.)
  • Výsledný deskriptor musí byť dosiahnutý WEBRTC.Okrem toho nezáleží na tom, či sa tento deskriptor získava na diaľku alebo lokálne z tej istej implementácie WEBRTC.
  • Tam je malá úprava deskriptora relácie
• Kandidáti
  • Kandidát Kandidát na ľade.) - Toto je adresa uzla v sieti
  • Adresa uzla môže byť vaša, a možno adresa smerovača alebo Otáčať sa Server
  • Kandidáti sú vždy veľa
  • Kandidát pozostáva z Ip Adresy, prístav a typ dopravy ( Tcp. alebo UDP.)
  • Kandidáti sa používajú na vytvorenie fyzického spojenia dvoch uzlov v sieti.
  • Kandidáti musia byť tiež posielané prostredníctvom signálového mechanizmu
  • Kandidáti musia tiež prenášať implementáciu WEBRTC., Avšak, len vzdialené
  • V niektorých implementáciách WEBRTC. Kandidáti môžu byť prevedené len po inštalácii deskriptora relácie
• Stun / Turn / ICE / NAT
  • Nat. - Mechanizmus externého prístupu
  • Domáce smerovače podporujú špeciálnu tabuľku Nat.
  • Router nahrádza adresy v obaloch - adresa zdroja na vlastnú päsť, v prípade, že balík prejde do externej siete, a adresa prijímača na adresu uzla vo vnútornej sieti, ak balenie prišiel z externého sieť
  • Poskytovanie multikanálovej prístupu do externej siete Nat. Používa porty
  • Ľad - mechanizmus skenovania Nat.
  • Omráčiť. a Otáčať sa Servery - Pickup servery pre obchvat Nat.
  • Omráčiť. Server vám umožňuje vytvoriť potrebné položky v tabuľke. Nat.a tiež vráti externú adresu uzla
  • Otáčať sa Generuje server Omráčiť. a robí to fungovať vždy
  • V najhorších prípadoch Otáčať sa Server sa používa ako sprostredkovateľ ( relé), t.j p2p. sa zmení na komunikáciu klienta klienta.

Dnes je WEBRTC horúcou technológiou pre streamovanie zvuku a videa v prehliadačoch. Konzervatívne technológie, ako sú stránky HTTP a blesk, sú vhodnejšie na distribúciu zaznamenaného obsahu (video na požiadanie) a výrazne nižšie ako WEBRTC z hľadiska v reálnom čase a online vysielaní, t.j. Tam, kde sa vyžaduje minimálne oneskorenie videa, čo umožňuje publikum vidieť, čo sa deje "žiť".

Možnosť vysoko kvalitnej komunikácie v reálnom čase je odvodená z samotného architektúry WEBRTC, kde sa protokol UDP používa na prepravu video tokov, čo je štandardným základom pre vysielanie videa s minimálnymi oneskoreniami a široko používané v komunikačných systémoch v reálnom čase.

Oneskorenie komunikácie je dôležité v on-line vysielacích systémov, webinároch a iných aplikáciách, kde sa vyžaduje interaktívna komunikácia so zdrojom videa, koncoví používatelia sa vyžaduje a vyžaduje riešenie.

Ďalším vážnym dôvodom na vyskúšanie WEBRTC je určite trend. Každý Android Chrome Browser dnes podporuje túto technológiu, ktorá zaručuje milióny zariadení pripravených na prezeranie vysielania bez inštalácie akéhokoľvek ďalšieho softvéru a konfigurácií.

S cieľom skontrolovať technológiu WEBRTC v prípade a spustiť jednoduché online vysielanie na ňom, použili sme server na serveri FlashPhoner WeBrtc Media & Broadcasting Server. Vo funkciách, schopnosť vysielať WEBRTC Streams v jednom až do mnohých režimov "(One-to-Maany), ako aj podpora pre IP kamery a video monitorovacie systémy prostredníctvom protokolu RTSP; V tomto prehľade sa zameriavame na webové vysielania a ich funkcie.

Inštalácia servera WEBRTC Media & Broadcasting

Keďže systém verzií servera nebola pre systém Windows, nechcela sa nainštalovať VMware + Linux virtuálny typ, test online vysielanie na domácom počítači Windows nefungovali. S cieľom ušetriť čas sa rozhodol vziať inštancie na hosting cloud, ako je toto:

Bol to CentOS X86_64 verzia 6.5 bez akéhokoľvek predinštalovaného softvéru v dátovom centre Amsterdamu. Tak, všetko, čo sme dostali, je k dispozícii je server a ssh prístup k nej. Pre tých, ktorí sú oboznámení s príkazmi Console Linux, inštalácia servera WEBRTC sľubuje, že pôjde ľahko a bezbolestne. Takže to, čo sme urobili:

1. Stiahnite si archív:

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

2. Rozbaľovať

$ TAR -XZF Download-WCS5-Server.tar.gz

3. Inštalácia:

$ Cd flashfonerwebcallserver.

Počas inštalácie vstupu IP adresy servera: xxx.xxx.xxx.xxx

4. Aktivujte licenciu:

$ Cd / usr / local / flashfonerwebcallserver / bin

$. / Aktivácia

5. Spustite server WCS:

$ Service WebCallServer Začiatok

6. Skontrolujte protokol:

$ chvost - f / asr/local/flashphonerwebcallserver/logs/flashphphoner_manager.log

7. Skontrolujte, či sú zavedené dva procesy:

$ Ps aux | Grep flashfoner.

Proces inštalácie je dokončený.

Testovanie online vysielania WEBRTC

Testovacie vysielania sa ukázali byť neupravené. Okrem servera je webový klient, ktorý sa skladá z tucet Javascript, HTML a CSS súborov a bol nasadený na priečinok / var / www / html v inštalačnej fáze. Jediná vec, ktorá musela byť vykonaná, je zadať adresu IP servera na konfiguráciu flashphoner.xml, aby sa webový klient mohol pripojiť k serveru HTML5 Webscets Server. Popíšeme testovací proces.

1. Otvorte stránku Index.html Test Client Client v prehliadači Chrome:

2. Ak chcete spustiť vysielanie, musíte kliknúť na tlačidlo "Štart" v strede obrazovky.
Predtým, ako urobíte, musíte sa uistiť, že webová kamera je pripojená a pripravená na prácu. Neexistujú žiadne špeciálne požiadavky na webovú kameru, napríklad použili štandardnú kameru zabudovanú do notebooku s rozlíšením 1280 × 800.

Chrome Browser bude určite klásť prístup k fotoaparátu a mikrofónu, aby užívateľ pochopil, že jeho video bude odoslané na internetový server a umožnila ho urobiť.

3. Rozhranie je úspešným vysielaním video toku z fotoaparátu na serveri WEBRTC. V pravom hornom rohu indikátor označuje, že prietok prejde na server, v spodnom rohu tlačidla STOP prestaňte odosielať video.

Venujte pozornosť odkazu v dolnom poli. Obsahuje jedinečný identifikátor tohto vlákna, takže ktokoľvek sa môže pripojiť k sledovaniu. Stačí otvoriť tento odkaz v prehliadači. Ak chcete kopírovať do schránky, musíte kliknúť na tlačidlo "Kopírovať".

V reálnych aplikáciách, ako sú webináre, prednášky, online vysielania alebo interaktívne televízne vývojári budú musieť realizovať distribúciu tohto identifikátora do určitých skupín divákov, aby sa pripojili k požadovaným tokom, ale toto je logika aplikácie. Server WEBRTC Media & Broadcasting Server netýka sa, ale iba distribučné video.

5. Pripojenie je vytvorené a divák vidí prietok na obrazovke. Teraz môže poslať odkaz na niekoho iného, \u200b\u200bprestaňte reprodukovať prúd alebo zapnúť režim celej obrazovky pomocou ovládacích prvkov v pravom dolnom rohu.

Výsledky testov WEBRTC Online prekladový server

Počas testov vyzeralo oneskorenie dokonalé. Ping do dátového centra predstavoval asi 100 milisekúnd a oneskorenie nebolo odlíšiteľné okom. Odtiaľ sa dá predpokladať, že skutočné oneskorenie je rovnaké 100 plus mínus niekoľko desiatok milisekunds na tlmivý čas. Ak sa porovnáte s Flash Video: V takýchto testoch sa blesk správať tak dobre ako WEBRTC. Takže, ak na podobnej sieti presunúť ruku, potom pohyb na obrazovke možno vidieť len cez jednu / dve sekundy.

Pokiaľ ide o kvalitu, poznamenávame sa, že na pohybe niekedy môžete rozlišovať kocky. To zodpovedá povahe kodeku VP8 a jeho hlavnej úlohe - poskytnúť video spojenie v reálnom čase s prijateľnou kvalitou a bez oneskorenia v komunikácii.

Server je dostatočne jednoduchý na inštaláciu a konfiguráciu, nevyžaduje okrem závažných zručností okrem znalostí Linuxu na úrovni pokročilého používateľa, ktorý dokáže vykonať príkazy z konzoly cez SSH a použite textový editor. V dôsledku toho sa nám podarilo vytvoriť online vysielanie jedného medzi prehliadačmi. Pripojenie ďalších divákov na potok tiež nespôsobil problémy.

Kvalita vysielania sa ukázala byť celkom prijateľná pre webináre a online vysielania. Jediná vec, ktorá spôsobila niektoré otázky, je rozlíšenie videa. Fotoaparát podporuje 1280 × 800, ale rozlíšenie na testovacom obraze je veľmi podobné 640 × 480. Zdá sa, že vývojári musia objasniť túto otázku.

Video testovanie vysielania z webovej kamery
Cez WEBRTC Server

WEBRTC (Web Real Time Communications) je štandard, ktorý popisuje prenos streamovania audio dát, video dát a obsahu z prehliadača a do prehliadača v reálnom čase bez inštalácie plug-ins alebo iných rozšírení. Štandard umožňuje otočiť prehliadač do terminálu terminálu terminálu videokonferencie, stačí otvoriť webovú stránku, ak chcete začať komunikovať.

Čo je WEBRTC?

V tomto článku budeme zvážiť všetko, čo potrebujete vedieť o technológii WEBRTC pre bežného používateľa. Zvážte výhody a nevýhody projektu, odhaliť niektoré tajomstvá, povieme vám, ako to funguje, kde a čo sa aplikuje WEBRTC.

Čo potrebujete vedieť o WEBRTC?

Vývoj štandardov a technológií Video Communications

Sergey Yutzaytis, Cisco, video + konferencia 2016

Ako WEBRTC funguje

Na strane klienta

• Užívateľ otvorí stránku obsahujúcu HTML5 tag
• Prehliadač požiada o prístup na webovú kameru a používateľský mikrofón.
• JavaScriptový kód na stránke Užívateľská stránka ovláda parametre pripojenia (IP adries a WEBRTC Server alebo iná zákazníci WEBRTC) obísť NAT a Firewall.
• Pri prijímaní informácií o partnerstve alebo potoku s konferenciou sa prehliadač začne prispôsobiť používaným audio a video kodekmi.
• Spustí sa proces kódovania a prenosu streamovacích údajov medzi klientmi WEBRTC (v našom prípade medzi prehliadačom a serverom).

Na strane servera WEBRTC

Na výmenu údajov medzi oboma účastníkmi sa video server nevyžaduje, ale ak potrebujete kombinovať niekoľko účastníkov na jednej konferencii, server je potrebný.

Video server dostane mediálnu prevádzku z rôznych zdrojov, previesť ho a poslať ho používateľom, ktorí používajú WEBRTC ako terminál.

Aj WEBRTC Server dostane mediálnu návštevnosť z WEBRTC Peters a previesť na svojich účastníkov konferencie, ktorí používajú aplikácie pre stolové počítače alebo mobilné zariadenia, ak existujú.

Výhody štandardného

• Nevyžaduje sa žiadna inštalácia.
• Veľmi kvalitná komunikácia vďaka:
  • Použitie moderného videa (VP8, H.264) a Audio Codecs (OPUS).
  • Automatické nastavenie kvality prúdu za podmienok pripojenia.
  • Zabudovaný echo a systém redukcie hluku.
  • Automatické nastavenie citlivosti mikrofónov účastníkov (ARU).
• Vysoká bezpečnosť: Všetky pripojenia sú chránené a šifrované podľa protokolov TLS a SRTP.
• K dispozícii je vstavaný mechanizmus zachytávania obsahu, ako je desktop.
• Schopnosť implementovať akékoľvek rozhranie HTML5 a JavaScript.
• Schopnosť integrovať rozhranie s ľubovoľnými spätnými systémami pomocou weboveswets.
• Projekt otvoreného zdroja - môže byť implementovaný vo vašom produkte alebo službe.
• Skutočná platforma: Rovnaká aplikácia WEBRTC bude fungovať rovnako dobre na akomkoľvek operačnom systéme, ploche alebo mobilnom za predpokladu, že prehliadač podporuje WEBRTC. To výrazne šetrí zdroje na vývoj softvéru.

Nevýhody štandardu

• Pre organizáciu skupiny audio a videokonferencie sa vyžaduje server VKS, ktorý by premiešal video a zvuk od účastníkov, pretože Prehliadač nevie, ako synchronizovať niekoľko prichádzajúcich tokov medzi sebou.
• Všetky riešenia WEBRTC sú nekompatibilné, pretože Štandard len popisuje iba metódy prenosu videa a zvuku, takže implementácia metód adresovania účastníkov, sledovanie ich dostupnosti, správ a súborov, plánovania a iných dodávateľov.
• Inými slovami, nebudete môcť volať z aplikácie WEBRTC jedného developer v aplikácii WEBRTC iného developer.
• Miešanie skupinových konferencií si vyžaduje veľké výpočtové zdroje, takže tento typ videohovoru vyžaduje nákup plateného predplatného alebo investovania do svojej infraštruktúry, kde sa pre každú konferenciu vyžaduje 1 fyzické jadro moderného procesora.

WEBRTC Tajomstvo: Ako dodávatelia profitujú z prelomovej webovej technológie

Tsakhi Levent Levi, BlogGeek.ME, video + konferencia 2015

WEBRTC pre trh VKS

Zvýšenie počtu terminálov VKS

Technológia WEBRTC mala silný vplyv na vývoj trhu VKS. Po opustení prvého prehliadača s podporou WEBRTC v roku 2013 sa potenciálny počet videokonferenčných terminálov po celom svete okamžite zvýšil o 1 miliardu zariadení. V podstate sa každý prehliadač stal terminálom CSM, nie je horší ako jeho hardvérové \u200b\u200banalógy z hľadiska ponuky.

Použitie v špecializovaných riešeniach

Používanie rôznych knižníc Javascript a WEBRTC Cloud Service API vám umožňuje jednoducho pridať podporu video odkazu na všetky webové projekty. Predtým, na prenos údajov v reálnom čase vývojári, bolo potrebné študovať zásady protokolov a využívať vývoj iných spoločností, ktoré najčastejšie požadovali dodatočné licencie, ktoré zvýšili náklady. WEBRTC sa už aktívne používa v "Call Site", "Online Chat Support" atď.

Ex-užívatelia Skype pre Linux

V roku 2014 spoločnosť Microsoft oznámila ukončenie podpory projektu Skype pre Linux, čo spôsobilo veľké podráždenie z IT špecialistov. Technológia WEBRTC nie je viazaná na operačný systém a implementovaný na úrovni prehliadača, t.j. Používatelia Linuxu budú môcť vidieť produkty a služby založené na WEBRTC Full-Fledged Skype nahradenie.

Súťaž s bleskom.

WEBRTC a HTML5 sa stali fatálnou úderom pre technológiu Flash, ktorá a tak sa obávali o ich ďaleko z najlepších rokov. Od roku 2017, popredné prehliadače oficiálne prestali podporovať flash a technológie konečne zmizli z trhu. Ale musíte dať flash splatné, po tom všetkom to bol on, kto vytvoril webový konferenčný trh a navrhol technické príležitosti pre živú komunikáciu v prehliadačoch.

Video Prezentácia WEBRTC.

DMITRY ODINTSOV, TRUECONF, video + konferencia október 2017

Kodeky v WEBRTC.

Audio Codec

Na komprimovanie audio dopravy v WEBRTC sa používajú OPUS a G.711 CODECS.

G.711. - Najstarší hlasový kodek s vysokou bitovou rýchlosťou (64 kbps), ktorá sa najčastejšie používa v tradičných telefónnych systémoch. Hlavnou výhodou je minimálny výpočtový zaťaženie z dôvodu použitia algoritmov kompresie svetla. Kodek je charakterizovaný nízkou úrovňou kompresie hlasového signálu a počas komunikácie nerobí dodatočné audio meškanie.

G.711 je podporovaný veľkým počtom zariadení. Systémy, v ktorých sa tento kodek používa, je ľahšie použitie ako tie, ktoré sú založené na iných audio kódoch (G.723, G.726, G.728 atď.). Z hľadiska kvality G.711 sa odhadovalo 4.2 v testovaní MOS (odhad v rozsahu 4-5 je najvyšší a znamená dobrú kvalitu, podobne ako kvalita prenosu hlasovej dopravy v ISDN a ešte vyššia).

Opus. - Toto je kodek s nízkym oneskorením kódovania (2,5 ms až 60 ms), podpora pre variabilnú bitrázu a vysokú úroveň kompresie, ktorá je ideálna na prenos audio signálu streamingu v sieťach s variabilnou šírkou pásma. Opus je hybridný roztok, ktorý kombinuje najlepšie vlastnosti hodvábne kodeky (Hlasová kompresia, riešenie skreslenia ľudského reči) a Celt (Audio dátové kódovanie). Kodek je v slobodnom prístupe, vývojári, ktorí ho používajú, nemusia platiť zrážky držiteľom autorských práv. V porovnaní s inými audio kódmi, Opus, nepochybne vyhrá v mnohých ukazovateľoch. On zatienil celkom populárne kodeky s nízkym bitovým káblom, ako je MP3, Vorbis, AAC LC. OPUS obnoví najviac blízko k pôvodnému "obrazu" zvuku ako AMR-WB a Speex. Za týmto kodekom - budúcnosť, čo je dôvod, prečo to technológie WEBRRTC zahrnuli v povinnom rozsahu podporovaných Audiostandartov.

Video Codec

Výber videopódu pre WEBRTC trvalo niekoľko rokov od vývojárov, v dôsledku toho sme sa rozhodli použiť H.264 a VP8. Takmer všetky moderné prehliadače podporujú obe kodeky. Videokonferenčné servery pre prácu s WEBRTC dostatočne podporujú len jednu.

Vp8. - Bezplatné video kódované s otvorenou licenciou, sa rozlišuje vysokou rýchlosťou dekódovania video prúdu a zvýšenú odolnosť voči strate rámov. Kodek je univerzálny, je ľahké zaviesť do hardvérových platforiem, takže veľmi často ho používajú vývojári videokonferenčných systémov v ich produktoch.

Platené video kodek H.264. Stal sa o niečo skôr ako jeho kolega. Toto je kodek s vysokým stupňom kompresie video toku pri zachovaní vysokokvalitného videa. Vysoká prevalencia tohto kodeku medzi hardvérovými systémami videokonferencie zahŕňa jeho použitie v štandarde WEBRTC.

Google a Mozilla aktívne propagujú kodek VP8 a Microsoft, Apple a Cisco - H.264 (aby zabezpečili kompatibilitu s tradičnými videokonferenčnými systémami). A tu je veľmi veľkým problémom pre vývojárov Cloud WeBRTC riešenia, pretože ak v konferencii používajú všetci účastníci jeden prehliadač, konferencia je dostatočná na zmesi raz s jedným kodekom, a ak existujú rôzne prehliadače a existujú safari / hrana Prehliadače, potom bude konferencia bude musieť byť zakódovaná dvakrát rôznymi kodekmi, čo zdvojnásobí systémové požiadavky pre mediálny server a ako výsledok, náklady na predplatné služby WEBRTC.

WEBRTC API.

Technológia WEBRTC je založená na troch hlavných API:

• (Zodpovedný za prijatie zvukového a video signálu webového prehliadača z fotoaparátu alebo používateľa).
• RTCPEERCONDING. (Zodpovedný za spojenie medzi prehliadačmi pre "výmenu" prijatého z fotoaparátu, mikrofónu a desktopu, mediántov. Tiež v "clá" tohto rozhrania API vstupuje do spracovania signálu (čistenie z outsiderov, nastavenie hlasitosti mikrofónu) a kontrolu použité audio a video kódov).
• Kanál RTCDATA (Poskytuje dvojstranný prenos údajov prostredníctvom zavedeného spojenia).

Pred prístupom k mikrofónu a užívateľskej kamere sa prehliadač požaduje povolenie. V prehliadači Google Chrome môžete nastaviť vopred v časti "Nastavenia" v časti Opera a Firefox, výber zariadení sa vykonáva priamo v čase prístupu z rozbaľovacieho zoznamu. Žiadosť o uznesenie sa vždy zobrazí pri používaní protokolu HTTP a raz, ak používate HTTPS:

RTCPEERCONDING.. Každý prehliadač zúčastňujúci sa na konferencii WEBRTC musí mať prístup k tomuto objektu. Vďaka používaniu RTCpeerconnects môže byť Mediaden z jedného prehliadača použitý aj prostredníctvom obrazoviek NAT a Sieť. Na úspešné prenos mediálnych porcií by účastníci mali vymieňať tieto údaje pomocou dopravy, ako sú webové zásuvky:

• Účastník iniciátora vysiela druhý účastník ponuky-SDP (dátovej štruktúre s charakteristikami toku médií, ktorý bude prenášať);
• druhý účastník tvorí "odpoveď" - odpoveď-SDP a postúpi ju iniciátorovi;
• potom sa výmena ľadových kandidátov organizuje medzi účastníkmi, ak existuje (ak sú účastníci za NAT alebo sieťové obrazovky).

Po úspešnom ukončení tejto výmeny medzi účastníkmi sa organizuje presun výkonov médií (audio a video).

Kanál RTCDATA. Podpora protokolu dátového kanála sa objavila v prehliadačoch relatívne nedávno, preto sa toto API môže zobraziť výlučne v prípadoch používania WEBRTC v Mozilla Firefox 22+ a prehliadačoch Google 26+. Účastníci s ním môžu v prehliadači zdieľať textové správy.

Pripojenie WEBRTC.

Podporované prehliadače pracovnej plochy

• Google Chrome (17+) a všetky prehliadače na báze chrómového motora;
• Mozilla Firefox (18+);
• Opera (12+);
• Safari (11+);

Podporované mobilné prehliadače pre Android

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

WEBRTC, Microsoft a Internet Explorer

Veľmi dlho si spoločnosť Microsoft udržiaval ticho o podpore WEBRTC v Internet Explorer av jeho novom prehliadači. Chlapci z Redmondu nemajú naozaj radi poskytovať technológie užívateľom, že nekontrolujú, to je taká politika. Ale postupne sa prípad presunul z mŕtveho bodu, pretože WEBRTC ďalej nebolo možné ignorovať a bol oznámený projekt ORTC odvodený z štandardu WEBRTC.

Podľa vývojárov, ORTC je rozšírením štandardu WEBRTC so zlepšenou sadou API založeného na Javascript a HTML5, ktorá sa premieta do normálneho jazyka znamená, že všetko bude rovnaké, len na kontrolu štandardu a jeho vývoj bude Microsoft A nie Google. Sada kodekov je rozšírený o podporu pre H.264 a niektoré zvukové kódy série G.7xx používané v telefónnych a hardvérových systémoch VKS. Môže sa objaviť vstavaná podpora pre RDP (pre prenos obsahu) a odosielanie správ. Mimochodom, používatelia programu Internet Explorer nie sú šťastní, podpora ORTC bude len na okraji. No, prirodzene, takáto sada protokolov a kodekov s nízkou krvou je vložená s Skype pre podnikanie, ktorý otvára ešte viac obchodných aplikácií pre WEBRTC.

Užívatelia európskych sietí boli rozdelené do dvoch častí: podľa prieskumu Inštitútu verejnej analýzy verejnej mienky v Allenbachu (Nemecko), Skype, Chat a Instant Memory Systems sa stali neoddeliteľnou súčasťou každodenného života za 16,5 milióna dospelých a deti, 9 Milióny využívajú tieto služby z prípadu, a 28 miliónov sa netýka ich.

Situácia sa môže zmeniť, pretože teraz v integrovanej Firefoxe komunikačná technológia v reálnom čase (WEBRTC.), ako aj samotný klient. Štart Audio a video Chatujte teraz nie je ťažšie ako otvorenie stránky. Služby ako Facebook a Skype sú stávkovanie riešení pomocou samostatného klienta a vytváraním účtu.

WEBRTC sa líši nielen jednoduchosťou. Táto metóda vám umožňuje dokonca inštalovať priame spojenie medzi dvoma prehliadačmi. Audio a video dáta teda neprechádzajú serverom, kde sa môže preťaženie deje, alebo ho správca nie je obzvlášť dôrazní vo vzťahu k súkromnému sektoru alebo ochrane údajov. Vďaka priamemu spojeniu pre WEBRTC nie je potrebná registrácia ani účet v žiadnej službe.

Ak chcete začať konverzáciu, musíte len prejsť odkazom. Komunikácia zostáva súkromnáPretože dátový tok je šifrovaný. Komunikácia V reálnom čase prostredníctvom prehliadača sa spoločnosť Google začala aktívne zapojiť do roku 2011, kedy a zverejnila zdrojový kód pre jeho implementáciu WEBRTC.

Krátko potom chróm a firefox dostali svoje vlastné motory WEBRTC. Momentálne sú ich mobilné možnosti vybavené takto touto technológiou a nainštalovaný s Androidom 5.0 pomocou motora WebView 3.6, ktorý používa aplikácie.

Pre komunikáciu v reálnom čase musia byť v prehliadači WEB implementované vhodné rozhrania JavaScript. S pomocou GETUSERMEDIA softvér aktivuje zachytávanie zo zdrojov zvuku, to znamená, že z webovej kamery a mikrofónu. RTCPEERCONDING je zodpovedný za vytvorenie spojenia, ako aj samotného komunikácie.

Súbežne s integráciou do prehliadača, pracovná skupina World Wide Web Consortium (W3C) prinútil proces štandardizácie WEBRTC. Musí byť dokončený v roku 2015.

WEBRTC je spokojný s malými

Ak chcete používať službu WEBRRTC, mnohé zdroje sa nevyžaduje, pretože server spája iba interlocutors. Inštalácia zlúčeniny tiež nepredstavuje špeciálnu zložitosť. Po prvé, prehliadač slúži signálu WEBRTC na signál, ktorý plánuje začať hovor. Zo servera dostane odkaz HTTPS - pripojenie sa vykonáva v šifrovanej forme. Tento používateľ odkazuje svojmu partnerovi. Potom prehliadač požiada o prístup k webovej kamere a mikrofónu.

Ak chcete nastaviť priame streamovanie s partnerom, prehliadač prijíma svoju IP adresu a konfiguračné údaje z služby WEBRTC. Rovnakým spôsobom vstúpi webový prehliadač Interoloku.

Ak chcete streamovať funkciu pripojenia bez porúch a v dobrej kvalite, v prehliadači pracujú tri motory. Dvaja z nich optimalizujú a komprimujú a audio video údaje, tretia je zodpovedná za ich prepravu. Predkladá dáta sRTP protokol (Secure Real-Time Dopravný protokol), ktorý vám umožní vykonávať šifrované streaming v reálnom čase.

Ak nie je možné nainštalovať priame spojenie, WEBRTC hľadá ďalšiu cestu. Napríklad sa to stane, keď nastavenia siete zabraňujú utajovaniu servera Stun, aby poskytli IP adresu. Štandard WEBRTC stanovuje, že v tomto prípade sa koná konverzácia, ale s medziľahlým zapnutím otáčania servera (traversal pomocou relé okolo NAT). Takže na webovej stránke Netscan.co môžete skontrolovať, či je WEBRTC implementovaný v počítači as prístupom k sieti.

Ako sa pripojiť

Najprv musíte zaregistrovať konverzáciu (1). Služba WEBRTC poskytuje odkaz na zasielanie Partneri. Prehliadač s použitím prehrávača nájde svoju vlastnú IP adresu (2), pošle ho do služby a prijíma IP partnera na inštaláciu priamej zlúčeniny (3). Ak nemôžete použiť omračovanie, konverzácia je presmerovaná pomocou servera Turnera (4).

Komunikácia o technológii WEBRTC v prehliadači sa spustí pomocou kódu JavaScriptu. Potom sú za to, že tri motory sú zodpovedné za komunikáciu: Hlasové a video disky Zbierajú multimediálne údaje z webovej kamery a mikrofónu a dopravný motor kombinuje informácie a dopredu tok v šifrovanej forme pomocou protokolu SRTP (zabezpečený protokol v reálnom čase).

Aké prehliadače pracujú s WEBRTC

Chrome a Firefox sú vybavené motorom WEBRTC, ktorý používa takéto služby ako TalkY.io. Mozilla prehliadač môže pracovať priamo s vlastným klientom.

Google a Mozilla naďalej vyvíjajú komunikáciu v reálnom čase: Chrome môže držať konferenciu WEBRTC s niekoľkými účastníkmi a nový klient Hello v Firefoxe je navrhnutý s dcérskou spoločnosťou Telefonica telekomunikačného obrie. Apple ešte nezostal stranou, v Safari WeBRTC, aby ešte očakávala. Existuje však mnoho alternatívnych aplikácií pre iOS a plug-iny pre safari.

Microsoft je trochu inak. Ako majiteľ spoločnosti Skype konkurenčné služby, táto spoločnosť nebude tak ľahko schopná kapitálu pred WEBRTC. Namiesto toho Microsoft vyvíja technológiu s názvom ORTC (objekt Real-Time Communications) pre Internet Explorer.

Takéto rozdiely od WEBRTC, as Ďalšie kodeky a protokoly na vytvorenie kontaktu so serverom, sú zanedbateľné a časom, najpravdepodobnejšie sa zmení na dodanie štandardu WEBRTC, ktorý bude zahŕňať tieto nezrovnalosti. Na palube sa teda zostáva - ako obvykle.

Fotka:výrobcov; Goodluz / fotolia.com.