Európski používatelia internetu sa delia na dve časti: podľa prieskumu Inštitútu pre analýzu verejnej mienky v Allenbachu (Nemecko) sa Skype, chat a systémy okamžitých správ stali neoddeliteľnou súčasťou každodenného života pre 16,5 milióna dospelých a detí, 9 miliónov využívať tieto služby od prípadu k prípadu a 28 miliónov sa ich nedotkne.

Situácia sa môže zmeniť, pretože Firefox je teraz integrovaný komunikačná technológia v reálnom čase (WebRTC), ako aj samotný klient. Spustenie audio a video chatu teraz nie je o nič ťažšie ako otvorenie webovej stránky. Služby ako Facebook a Skype sa na druhej strane spoliehajú na riešenia využívajúce samostatného klienta a vytvorenie účtu.

WebRTC sa nielen ľahko používa. Táto metóda vám dokonca umožňuje nastaviť priame spojenie medzi dvoma prehliadačmi. Týmto spôsobom zvukové a obrazové údaje neprechádzajú cez server, kde môže dôjsť k preťaženiu alebo kde správca nie je obzvlášť citlivý na ochranu súkromia alebo údajov. Vďaka priamemu pripojeniu WebRTC nevyžaduje žiadnu registráciu resp účtu v akejkoľvek službe.

Ak chcete začať konverzáciu, stačí kliknúť na odkaz. Komunikácia zostáva súkromná pretože dátový tok je šifrovaný. Komunikácii v reálnom čase cez prehliadač sa Google začal aktívne venovať už v roku 2011, keď zverejnil zdrojový kód svojej implementácie WebRTC.

Krátko na to dostali Chrome a Firefox svoje vlastné motory WebRTC. V súčasnosti sú mobilné možnosti vybavený touto technológiou aj motorom WebView 3.6 nainštalovaným s Androidom 5.0, ktorý používajú aplikácie.

Pre komunikáciu v reálnom čase musia byť vo webovom prehliadači implementované príslušné JavaScriptové rozhrania. Pomocou GetUserMedia softvér aktivuje snímanie zo zdrojov zvuku a videa, t. j. z webovej kamery a mikrofónu. RTCPeerConnection je zodpovedný za nadviazanie spojenia, ako aj za samotnú komunikáciu.

Súbežne s integráciou prehliadača pracovná skupina World Wide Web Consortium (W3C) presadzuje proces štandardizácie WebRTC. Dokončený by mal byť v roku 2015.

WebRTC sa uspokojí s málom

Používanie služby WebRTC nevyžaduje veľa zdrojov, pretože server spája iba kamarátov. Nadviazanie spojenia tiež nie je obzvlášť ťažké. Po prvé, prehliadač signalizuje serveru WebRTC, že plánuje iniciovať hovor. Prijíma HTTPS odkaz zo servera - spojenie je šifrované. Používateľ pošle tento odkaz svojmu partnerovi. Prehliadač potom požiada používateľa o povolenie prístupu k webovej kamere a mikrofónu.

Na vytvorenie priameho streamingového spojenia s druhou stranou dostane prehliadač svoju IP adresu a konfiguračné údaje zo služby WebRTC. Kamarátov webový prehliadač robí to isté.

Aby streamingové pripojenie fungovalo hladko a in dobrá kvalita, v prehliadači fungujú tri motory. Dva z nich optimalizujú a komprimujú audio a video dáta, tretí je zodpovedný za ich transport. Údaje odosiela cez protokol SRTP(Secure Real-time Transport Protocol), ktorý umožňuje šifrované streamovanie v reálnom čase.

Ak priame pripojenie zlyhá, WebRTC hľadá inú cestu. Napríklad sa to stane, keď nastavenia siete zabrániť serveru STUN, aby mohol nahlásiť IP adresu. Štandard WebRTC stanovuje, že v tomto prípade sa konverzácia uskutoční, ale s prechodným zahrnutím servera TURN (Traversal Using Relays around NAT). Takže na webovej stránke netscan.co môžete skontrolovať, či je WebRTC implementovaný vo vašom počítači a s vaším prístupom na web.

Ako sa vytvorí spojenie

Najprv musíte zaregistrovať konverzáciu (1). Služba WebRTC poskytuje odkaz, ktorý je potrebné odoslať účastníkovi rozhovoru. Prehliadač pomocou STUNserveru zistí svoju vlastnú IP adresu (2), odošle ju službe a prijme IP partnera na vytvorenie priameho spojenia (3). Ak STUN zlyhá, konverzácia je presmerovaná pomocou TURNservera (4).

Komunikácia prostredníctvom technológie WebRTC v prehliadači sa spúšťa pomocou kódu JavaScript. Potom sú za komunikáciu zodpovedné tri motory: hlasové a obrazové motory zbierajú multimediálne údaje z webovej kamery a mikrofónu a transportný mechanizmus kombinuje informácie a odosiela tok v zašifrovanej forme pomocou protokolu SRTP (Secure Real-time Protocol).

Ktoré prehliadače pracujú s WebRTC

Chrome a Firefox sú vybavené jadrom WebRTC, ktoré využíva služby ako talky.io. Prehliadač Mozilla môže pracovať priamo s vlastným klientom.

Google a Mozilla pokračujú v rozvíjaní myšlienky komunikácie v reálnom čase: Chrome môže hostiť WebRTC konferenciu s viacerými účastníkmi a nový klient Hello vo Firefoxe je vyvinutý s pomocou dcérskej spoločnosti telekomunikačného giganta Telefonica. Apple zatiaľ ostáva bokom, WebRTC v Safari zatiaľ nečakajte. Existuje však množstvo alternatívnych aplikácií a doplnkov pre iOS pre Safari.

Microsoft ide trochu iným smerom. Ako vlastník konkurenčnej služby Skype sa táto spoločnosť pred WebRTC len tak ľahko nechystá kapitulovať. Namiesto toho Microsoft vyvíja technológiu s názvom ORTC (Object Real-Time Communications). internet Explorer.

Rozdiely od WebRTC, ako sú rôzne kodeky a protokoly na nadviazanie kontaktu so serverom, sú nepatrné a časom s najväčšou pravdepodobnosťou pribudnú k štandardu WebRTC, ktorý bude tieto rozdiely zahŕňať. Pozadu tak ostáva už len Apple – ako inak.

Fotka: výrobné spoločnosti; goodluz/Photolia.com

Ahojte priatelia, ako už viete, pravidelne vás aktualizujeme o nové technológie, dnes vám predstavím WebRTC, technológiu vyvinutú spoločnosťou Google, ktorý umožňuje používateľom hovoriť priamo vo videu a zvuku prehliadača bez toho, aby bolo potrebné použiť doplnok – Webové stránky alebo aplikácie. Priame video a audio prepojenie medzi používateľmi prebieha priamo v prehliadači.
Technológia WebRTC podporovaná Mozillou Prehliadače Firefox Google Chrome a pre akékoľvek operačný systém, Opera sa čoskoro pripojí.
Čo je WebRTC a čo?
WebRTC je skratka pre Web Real Time Communication, táto technológia vám umožňuje otvárať audio a video chaty priamo v prehliadači bez toho, aby ste na to potrebovali ďalšie plug-iny, aplikácie alebo služby na internete. Pripojenie sa uskutočňuje priamo z prehliadača do prehliadača.
Kde známe služby (Skype, Yahoo Messenger, Apple FaceTime, Google Hago atď.) vyžadujú server, ktorý spája používateľov s cieľom iniciovať a spravovať prenos. Pomocou týchto služieb sa musíme zaregistrovať a nastaviť zoznam klientov a kontaktov.
S WebRTC nepotrebujeme servery, aplikácie alebo servery, ktoré sa pripájajú, aby zasiahli.
Výhody WebRTC:
1. Už žiadne aplikácie spotrebúvajú zdroje a spotrebu batérie.
2. Chaty sú viac súkromné ​​(relatívne).
3. Kontakt sa môže uskutočniť lokálne, nie na serveroch Flos US pre lokálne pripojenia.
4. Jednoduchosť, jednoduchosť použitia.
5. Príležitosť ďalší vývoj a v iných smeroch.
6. Komunikácia je stabilná a nezávislá od vonkajšie pripojenia ktoré sú niekedy mimoriadne nestabilné.
V tutoriále som použil demo, ktoré vyvinuli ľudia v Google, toto demo je celkom jednoduché, pokročilejšie funkcie a rýchlejšie pripojenia môžu využiť niektorú z aplikácií, ktoré podporujú WebRTC, sú jednoduchšie na používanie. Čoskoro pripravíme aj tutoriál o aplikáciách WebRTC.
Ako používať ukážku WebRTC?
Veľmi jednoducho kliknite na odkaz nižšie, automaticky sa vygeneruje chat. Ak chcete prepojiť túto miestnosť, musíte poslať priateľovi/priateľke, s ktorou sa chcete spojiť.
Priateľ / priateľka a tvoja, ale mali by ste použiť len najviac najnovšie verzie Mozilla Firefox alebo Google Chrome.

Ukážka WebRTC(zvuk - video úvodného rozhovoru)

Pozor:
Demo nie je príliš stabilné, je robené len na demonštračné účely. Môže sa používať na obmedzený čas, počas ktorého sa môžu vyskytnúť malé chyby pripojenia.
Ak máte problémy s pripojením, skúste vytvoriť iný čet.

Dnes je WebRTC „horúcou“ technológiou na streamovanie zvuku a videa v prehliadačoch. Konzervatívne technológie ako napr Streamovanie HTTP a Flash sú vhodnejšie na distribúciu nahratého obsahu (video na požiadanie) a sú výrazne horšie ako WebRTC z hľadiska vysielania v reálnom čase a online, t.j. kde sa vyžaduje minimálna latencia videa, čo umožňuje divákom vidieť, čo sa deje „naživo“.

Možnosť kvalitnej komunikácie v reálnom čase pochádza zo samotnej architektúry WebRTC, kde sa na prenos video streamov používa protokol UDP, ktorý je štandardným základom pre prenos videa s minimálnym oneskorením a je široko používaný v systémoch komunikácie v reálnom čase.

Komunikačná latencia je dôležitá v systémoch živého vysielania, webinároch a iných aplikáciách, kde sa vyžaduje interaktívna komunikácia so zdrojom videa, koncovými používateľmi a riešením.

Ďalším dobrým dôvodom na vyskúšanie WebRTC je určite trend. Každý Android dnes Prehliadač Chrome podporuje túto technológiu, ktorá zaisťuje, že milióny zariadení sú pripravené sledovať vysielanie bez inštalácie akéhokoľvek dodatočného softvéru a konfigurácií.

Aby sme otestovali technológiu WebRTC v praxi a spustili na nej jednoduché online vysielanie, použili sme serverový softvér Flashphoner WebRTC Media & Broadcasting Server. Funkcie deklarujú schopnosť vysielať WebRTC streamy v režime one-to-many, ako aj podporu IP kamier a video monitorovacích systémov cez protokol RTSP; v tejto recenzii sa zameriame na web-webové vysielania a ich funkcie.

Inštalácia WebRTC Media & Broadcasting Server

Pretože pre systémy Windows neexistovala žiadna verzia servera a nechcel som inštalovať virtuálny stroj ako VMWare + Linux, testovať online vysielanie doma Počítač so systémom Windows Nevyšlo to. Aby sme ušetrili čas, rozhodli sme sa použiť príklad cloudového hostingu, ako je tento:

Bol to Centos x86_64 verzie 6.5 bez akéhokoľvek predinštalovaného softvéru v amsterdamskom dátovom centre. Takže všetko, čo máme k dispozícii, je server a ssh prístup k nemu. Pre tých, ktorí sú oboznámení s príkazy konzoly Linux, inštalácia servera WebRTC sľubuje, že bude jednoduchá a bezbolestná. Čo sme teda urobili:

1. Stiahnite si archív:

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

2. Rozbaliť:

$tar -xzf download-wcs5-server.tar.gz

3. Inštalácia:

$cd FlashphonerWebCallServer

Počas inštalácie zadajte IP adresu servera: XXX.XXX.XXX.XXX

4. Aktivovať licenciu:

$cd /usr/local/FlashphonerWebCallServer/bin

$./activation.sh

5. Spustite server WCS:

$service webcallserver štart

6. Skontrolujte denník:

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

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

$ps aux | grep Flashphoner

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

Testovanie živých prenosov WebRTC

Testovanie vysielania sa ukázalo ako jednoduchá záležitosť. Okrem servera existuje webový klient, ktorý pozostáva z tucta súborov Javascript, HTML a CSS a bol nami nasadený do priečinka /var/www/html počas fázy inštalácie. Jediné, čo bolo treba urobiť, bolo zadať IP adresu servera do konfigurácie flashphoner.xml, aby webový klient mohol nadviazať spojenie so serverom cez HTML5 Websockets. Poďme si popísať proces testovania.

1. Otvorte stránku index.html testovacieho klienta v prehliadači Chrome:

2. Ak chcete spustiť vysielanie, musíte kliknúť na tlačidlo „Štart“ v strede obrazovky.
Predtým, ako to urobíte, sa musíte uistiť, že je webová kamera pripojená a pripravená na použitie. Na webovú kameru nie sú kladené žiadne špeciálne požiadavky, napríklad sme použili štandardnú vstavanú notebookovú kameru s rozlíšením 1280 × 800.

Prehliadač Chrome určite požiada o prístup ku kamere a mikrofónu, aby používateľ pochopil, že jeho video bude odoslané na internetový server, a umožní mu to.

3. Rozhranie predstavuje úspešné vysielanie toku videa z kamery na server WebRTC. V pravom hornom rohu indikátor indikuje, že stream smeruje na server, v dolnom rohu je tlačidlo „Stop“ na zastavenie odosielania videa.

Pozrite si odkaz nižšie. Obsahuje jedinečný identifikátor pre tento stream, takže k zobrazeniu sa môže pripojiť ktokoľvek. Stačí otvoriť tento odkaz v prehliadači. Ak ho chcete skopí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 video vysielanie alebo interaktívna televízia, budú musieť vývojári implementovať distribúciu tohto identifikátora určitým skupinám divákov, aby sa mohli pripojiť k požadovaným streamom, ale to je logika aplikácie. WebRTC Media & Broadcasting Server neovplyvňuje, ale zaoberá sa iba distribúciou videa.

5. Spojenie sa vytvorí a divák vidí stream na obrazovke. Teraz môže poslať odkaz niekomu inému, zastaviť prehrávanie streamu alebo povoliť režim celej obrazovky pomocou ovládacích prvkov v pravom dolnom rohu.

Výsledky testovania servera WebRTC pre online vysielania

Počas testov sa latencia zdala byť dokonalá. Ping do dátového centra bol asi 100 milisekúnd a oneskorenie nebolo okom viditeľné. Odtiaľ môžeme predpokladať, že skutočné oneskorenie je rovnakých 100 plus alebo mínus niekoľko desiatok milisekúnd pre čas ukladania do vyrovnávacej pamäte. V porovnaní s videom Flash si Flash v týchto testoch nevedie tak dobre ako WebRTC. Ak teda pohnete rukou na podobnej sieti, pohyb na obrazovke bude vidieť až po jednej/dvoch sekundách.

Pokiaľ ide o kvalitu, poznamenávame, že niekedy môžete rozlíšiť kocky na pohyboch. To je v súlade s charakterom kodeku VP8 a jeho hlavným cieľom je poskytnúť video komunikáciu v reálnom čase s prijateľnou kvalitou a bez komunikačných oneskorení.

Server sa inštaluje a konfiguruje pomerne jednoducho, jeho spustenie nevyžaduje žiadne vážne zručnosti, okrem znalosti Linuxu na úrovni pokročilého používateľa, ktorý dokáže spúšťať príkazy z konzoly cez ssh a používať textový editor. Výsledkom bolo, že sa nám podarilo nastaviť online vysielanie typu one-to-many medzi prehliadačmi. Problémy nespôsobilo ani pripojenie ďalších divákov k streamu.

Kvalita vysielania sa ukázala byť celkom prijateľná pre webináre a online prenosy. Jediné, čo vyvolalo nejaké otázky, bolo rozlíšenie videa. Kamera podporuje rozlíšenie 1280 x 800, ale rozlíšenie na testovacom obrázku je veľmi podobné 640 x 480. Zdá sa, že tento problém je potrebné objasniť s vývojármi.

Video o testovaní vysielania z webovej kamery
cez WebRTC server

Väčšina materiálu na WebRTC sa zameriava na aplikačnú úroveň písania kódu a neprispieva k pochopeniu technológie. Pokúsme sa ísť hlbšie a zistiť, ako sa spojenie vyskytuje, aký je deskriptor relácie a kandidáti, čo sú STUN a OTOČIŤ server.

WebRTC

Úvod

WebRTC je technológia založená na prehliadači, ktorá umožňuje prepojiť dvoch klientov na prenos video dát. Hlavnými funkciami sú interná podpora prehliadača (nie sú potrebné vstavané technológie tretích strán ako napr Adobe Flash ) a možnosť pripojenia klientov bez použitia ďalších serverov - pripojenie peer-to-peer(Ďalej, p2p).

Vytvorte spojenie p2p- pomerne náročná úloha, pretože počítače nie sú vždy verejné IP adresy, teda adresy na internete. Vzhľadom na malé množstvo IPv4 adries (a na bezpečnostné účely) bol vyvinutý mechanizmus NAT, ktorá umožňuje vytvárať privátne siete napríklad pre domáce použitie. Mnoho domácich smerovačov teraz podporuje NAT a vďaka tomu majú všetky domáce zariadenia prístup na internet, hoci poskytovatelia internetu ho väčšinou poskytujú IP adresu. verejnosti IP Adresy sú na internete jedinečné, ale súkromné ​​adresy nie. Tak sa pripojte p2p- ťažké.

Aby ste tomu lepšie porozumeli, zvážte tri situácie: oba uzly sú v rovnakej sieti (Obrázok 1), oba uzly sú v rôznych sieťach (jeden v súkromnej, druhý vo verejnej) (Obrázok 2) a oba uzly sú v rôznych súkromných sieťach s rovnakým IP adresy (Obrázok 3).

Obrázok 1: Oba uzly v rovnakej sieti

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

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

Na obrázkoch vyššie prvé písmeno v dvojznakovom zápise označuje typ uzla (p = peer, r = router). Na prvom obrázku je situácia priaznivá: uzly v ich sieti sú úplne identifikované sieťou IP adresy, a preto sa môžu navzájom priamo spájať. Na druhom obrázku máme dve rôzne siete, ktoré majú podobné čísla uzlov. Objavujú sa tu smerovače (smerovače), ktoré majú dva sieťové rozhranie- vo vašej sieti a mimo vašej siete. Preto majú dve IP adresy. Bežné uzly majú len jedno rozhranie, cez ktoré môžu komunikovať len vo vlastnej sieti. Ak prenášajú dáta niekomu mimo ich siete, tak jedine s pomocou NAT vnútri smerovača (smerovača), a teda viditeľné pre ostatných pod IP adresa smerovača je ich externé IP adresu. Teda uzol p1 existuje interiéru IP = 192.168.0.200 a externé IP = 10.50.200.5 , pričom posledná adresa je externá aj pre všetkých ostatných hostiteľov v jeho sieti. Situácia je podobná pre uzol p2. Preto je ich spojenie nemožné, ak iba ich vnútorné (vlastné) IP adresy. Môžete použiť externé adresy, teda adresy smerovačov, ale keďže všetky uzly v tej istej súkromnej sieti majú rovnakú externú adresu, je to dosť ťažké. Tento problém je vyriešený mechanizmom NAT

Čo sa stane, ak sa predsa len rozhodneme prepojiť uzly cez ich interné adresy? Dáta neopustia sieť. Pre zvýšenie efektu si môžete predstaviť situáciu znázornenú na poslednom obrázku – oba uzly majú rovnaké interné adresy. Ak ich použijú na komunikáciu, potom každý uzol bude komunikovať sám so sebou.

WebRTC sa s takýmito problémami úspešne vyrovná pomocou protokolu ICE, čo si však vyžaduje použitie ďalších serverov ( STUN, OTOČIŤ). To všetko nižšie.

Dve fázy WebRTC

Na prepojenie dvoch uzlov cez protokol WebRTC(alebo jednoducho RTC ak sú dve spojené iPhone„a) je potrebné vykonať nejaké predbežné opatrenia nadviazať spojenie. Toto je prvá fáza - nadviazanie spojenia. Druhou fázou je prenos video dát.

Hneď by sa malo povedať, že aj keď technológia WebRTC vo svojej práci využíva mnohé rôznymi spôsobmi komunikácia ( TCP a UDP) a má medzi nimi flexibilné prepínanie, túto technológiu nemá protokol na odovzdávanie údajov o pripojení. Nie je prekvapujúce, pretože spojte dva uzly p2p nie také ľahké. Preto je potrebné mať nejaké dodatočné spôsob prenosu údajov, nesúvisiaci s WebRTC. Môže to byť soketový prenos, protokol HTTP, môže to byť aj protokol SMTP alebo ruskej pošty. Tento prevodový mechanizmus primárny dáta sa nazývajú signál. Nie je potrebné prenášať veľa informácií. Všetky údaje sa prenášajú ako text a sú rozdelené do dvoch typov − SDP a Ľadový kandidát. Prvý typ sa používa na vytvorenie logického spojenia a druhý na fyzické. Viac o tom neskôr, ale zatiaľ je dôležité si to zapamätať WebRTC nám poskytne nejaké informácie, ktoré bude potrebné preniesť do iného uzla. Keď prenesieme všetky potrebné informácie, uzly sa budú môcť spojiť a naša pomoc už nebude potrebná. Takže signálny mechanizmus, ktorý musíme implementovať oddelene, bude použitý iba pri pripojení, a nepoužije sa pri prenose video údajov.

Pozrime sa teda na prvú fázu, fázu nastavenia pripojenia. Skladá sa z niekoľkých položiek. Zvážte túto fázu najskôr pre uzol, ktorý iniciuje spojenie, a potom pre čakajúci uzol.

• Iniciátor (volajúci - volajúceho):
  1. Ponuka na spustenie prenosu video dát (createOffer)
  2. Získanie vášho SDP SDP)
  3. Získanie vášho Ľadový kandidát Ľadový kandidát)
• Čakajúci hovor ( volaný):
  1. Získanie lokálneho (vlastného) mediálneho streamu a jeho nastavenie na prenos (getUserMediaStream)
  2. Prijať ponuku na spustenie prenosu video dát a vytvoriť odpoveď (createAnswer)
  3. Získanie vášho SDP objekt a jeho prechod cez signalizačný mechanizmus ( SDP)
  4. Získanie vášho Ľadový kandidát predmety a ich prenos cez signalizačný mechanizmus ( Ľadový kandidát)
  5. Príjem vzdialeného (cudzieho) mediálneho streamu a jeho zobrazenie na obrazovke (onAddStream)

Jediný rozdiel je v druhom odseku.

Napriek zjavnej zložitosti krokov sú v skutočnosti tri: odoslanie vlastného mediálneho toku (s. 1), nastavenie parametrov pripojenia (s. 2-4), príjem mediálneho toku niekoho iného (s. 5). Najťažší je druhý krok, pretože pozostáva z dvoch častí: založenie fyzické a logické spojenia. Prvý naznačuje cesta, pozdĺž ktorého musia ísť pakety, aby sa dostali z jedného sieťového uzla do druhého. Druhý naznačuje video/audio parametre- akú kvalitu použiť, aké kodeky použiť.

Mentálne štádium vytvoriťPonuku alebo vytvoriťOdpoveď by mali byť spojené s prestupovými stupňami SDP a Ľadový kandidát predmety.

Základné entity

Mediálne streamy (MediaStream)

Hlavnou entitou je mediálny tok, to znamená tok obrazových a zvukových údajov, obrazu a zvuku. Existujú dva typy mediálnych tokov – lokálne a vzdialené. Lokálne prijíma dáta zo vstupných zariadení (kamera, mikrofón) a vzdialené cez sieť. Každý uzol má teda lokálne aj vzdialené vlákno. AT WebRTC existuje rozhranie pre streamy mediálny prúd a existuje aj podrozhranie LocalMediaStreamšpeciálne pre lokálne vlákno. AT JavaScript môžete sa stretnúť iba s prvým, a ak použijete lib znelka, potom sa možno stretnúť aj s druhým.

AT WebRTC vo vlákne je dosť mätúca hierarchia. Každý stream môže pozostávať z niekoľkých mediálnych stôp ( mediálna stopa), ktoré zase môžu pozostávať z niekoľkých mediálnych kanálov ( MediaChannel). A samotných mediálnych streamov môže byť aj niekoľko.

Zvážme všetko v poriadku. Aby sme to dosiahli, spomeňme si na nejaký príklad. Povedzme, že chceme odovzdať nielen video seba, ale aj video nášho stola, na ktorom leží papier, na ktorý ideme niečo písať. Budeme potrebovať dve videá (my + stôl) a jedno audio (my). Je jasné, že my a tabuľku by sme mali rozdeliť do rôznych vlákien, pretože tieto údaje sú na sebe pravdepodobne slabo závislé. Preto budeme mať dve mediálny prúd„a – jeden pre nás a jeden pre stôl. Prvý bude obsahovať obrazové aj zvukové údaje a druhý bude obsahovať iba video (obrázok 4).

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

Okamžite je jasné, že mediálny prúd musí obsahovať aspoň schopnosť obsahovať dáta odlišné typy- video a audio. Toto je zohľadnené v technológii, a preto je každý typ údajov implementovaný prostredníctvom mediálnej stopy. mediálna stopa. Mediálna stopa má špeciálnu vlastnosť milý, ktorý určuje, čo je pred nami - video alebo zvuk (obrázok 5)

Obrázok 5: Mediálne toky sú tvorené mediálnymi stopami

Ako bude všetko prebiehať v programe? Vytvoríme dva mediálne prúdy. Potom vytvoríme dve video stopy a jednu zvukovú stopu. Získajte prístup ku kamerám a mikrofónu. Povedzme každej skladbe, ktoré zariadenie použiť. Pridajme video a audio stopu do prvého mediálneho prúdu a video stopu z inej kamery do druhého mediálneho prúdu.

Ako však rozlíšime mediálne toky na druhom konci pripojenia? Na tento účel má každý mediálny prúd vlastnosť štítok– označenie prúdu, jeho názov (obrázok 6). Mediálne stopy majú rovnakú vlastnosť. Aj keď sa na prvý pohľad zdá, že video sa dá od zvuku odlíšiť aj inak.

Obrázok 6: Toky médií a stopy sú označené štítkami

Takže, a ak je možné mediálne stopy identifikovať pomocou označenia, prečo potom potrebujeme pre náš príklad použiť dva mediálne prúdy namiesto jedného? Koniec koncov, môžete preniesť jeden mediálny tok a použiť v ňom rôzne stopy. Dosiahli sme dôležitý majetok mediálne prúdy – oni synchronizovať mediálne stopy. Rôzne mediálne toky nie sú synchronizované navzájom, ale v rámci každého mediálneho toku sú všetky stopy hral v rovnakom čase.

Ak teda chceme, aby sa súčasne prehrávali naše slová, emócie na tvári a kus papiera, potom sa oplatí použiť jeden mediálny prúd. Ak to nie je také dôležité, potom je výhodnejšie použiť rôzne prúdy - obraz bude hladší.

Ak je potrebné stopu počas prenosu deaktivovať, môžete túto vlastnosť použiť povolené mediálne stopy.

Nakoniec by ste mali myslieť na stereo zvuk. Ako viete, stereo zvuk sú dva iný zvuk. A tiež ich treba poslať samostatne. Na to slúžia kanály. MediaChannel. Zvuková mediálna stopa môže mať veľa kanálov (napríklad 6, ak potrebujete zvuk 5+1). Vo vnútri mediálnej stopy, kanály, samozrejme, tiež synchronizované. Pre video sa zvyčajne používa iba jeden kanál, ale niekoľko sa môže použiť napríklad na prekrytie reklamy.

Zhrnúť: na prenos obrazových a zvukových údajov používame mediálny tok. V rámci každého mediálneho toku sa údaje synchronizujú. Ak nepotrebujeme synchronizáciu, môžeme použiť viacero mediálnych streamov. V rámci každého mediálneho toku existujú dva typy mediálnych stôp – pre video a pre zvuk. Zvyčajne nie sú viac ako dve stopy, ale môže ich byť viac, ak potrebujete preniesť niekoľko rôznych videí (hovoriaceho a jeho stola). Každá stopa môže pozostávať z niekoľkých kanálov, čo sa zvyčajne používa iba pre stereo zvuk.

V najjednoduchšej situácii videorozhovoru budeme mať jeden lokálny mediálny stream, ktorý bude pozostávať z dvoch stôp - video stopy a zvukovej stopy, z ktorých každá bude pozostávať z jedného hlavného kanála. Video stopa je zodpovedná za kameru, zvuková stopa je za mikrofón a mediálny tok je kontajnerom oboch.

Deskriptor relácie (SDP)

O rôzne počítače vždy budú rôzne kamery, mikrofóny, grafické karty a ďalšie vybavenie. Existuje veľa možností, ktoré majú. Toto všetko musí byť koordinované pre prenos mediálnych dát medzi dvoma sieťovými uzlami. WebRTC urobí to automaticky a vytvorí špeciálny objekt - handle relácie SDP. Odovzdajte tento objekt inému uzlu a môžete posielať mediálne dáta. Len ešte nie je spojenie s iným uzlom.

Na tento účel sa používa akýkoľvek signalizačný mechanizmus. SDP môže byť prenášaný aj cez zásuvky, dokonca aj osobou (povedzte to inému uzlu telefonicky), dokonca aj ruskou poštou. Všetko je veľmi jednoduché - dostanete hotové SDP a treba to poslať. A po prijatí na druhej strane - presun na oddelenie WebRTC. Popisovač relácie je uložený ako text a môžete ho zmeniť vo svojich aplikáciách, ale zvyčajne to nie je potrebné. Napríklad pri pripájaní stolného↔telefónu niekedy musíte vynútiť výber požadovaného zvukového kodeku.

Väčšinou pri nadväzovaní spojenia musíte zadať nejakú adresu, napr URL. Tu to nie je potrebné, pretože vy sami pošlete údaje do cieľa prostredníctvom signalizačného mechanizmu. Naznačovať WebRTCčo chceme nainštalovať p2p pripojenie musíte zavolať funkciu createOffer. Po zavolaní tejto funkcie a udelení špeciálnej funkcie zavolaj späť„vytvorí sa SDP predmetu a odovzdaný tomu istému zavolaj späť. Všetko, čo sa od vás vyžaduje, je preniesť tento objekt cez sieť do iného uzla (partnera). Potom na druhom konci budú dáta prichádzať cez signalizačný mechanizmus, a to tento SDP objekt. Tento deskriptor relácie pre tento uzol je cudzí a preto prenáša užitočná informácia. Príjem tohto objektu je signálom na spustenie spojenia. Preto s tým musíte súhlasiť a zavolať funkciu createAnswer. Je to úplný analóg createOffer . Späť k vášmu zavolaj späť prejde lokálnym deskriptorom relácie a bude musieť prejsť späť cez signalizačný mechanizmus.

Stojí za zmienku, že funkciu createAnswer môžete zavolať až po prijatí niekoho iného SDP objekt. prečo? Pretože miestne SDP objekt, ktorý sa vygeneruje pri volaní createAnswer, sa musí spoliehať na diaľkové ovládanie SDP objekt. Iba v tomto prípade je možné koordinovať nastavenia videa s nastaveniami partnera. Taktiež nevolajte createAnswer a createOffer, kým nedostanete miestny mediálny stream – nebudú mať do čoho písať SDP objekt .

Keďže v r WebRTC je možné upraviť SDP objekt, potom po získaní lokálneho úchytu ho treba nastaviť. Môže sa zdať trochu zvláštne prejsť WebRTCčo nám sama dala, ale taký je protokol. Keď dostanete diaľkovú rukoväť, musíte ju tiež nastaviť. Preto musíte na jeden uzol nainštalovať dva deskriptory – svoj vlastný a cudzí (teda lokálny a vzdialený).

Po takomto podania rúk uzly vedia o svojich prianiach. Napríklad, ak uzol 1 podporuje kodeky A a B a uzol 2 podporuje kodeky B a C, potom, keďže každý uzol pozná svoje vlastné a cudzie deskriptory, oba uzly si vyberú kodek B(Obrázok 7). Logika spojenia je teraz vytvorená a mediálne streamy môžu byť prenášané, ale je tu ďalší problém - uzly sú stále spojené iba signalizačným mechanizmom.

Obrázok 7: Vyjednávanie kodeku

Kandidáti (kandidát na ľad)

Technológia WebRTC snaží sa nás zmiasť svojou novou metodikou. Pri vytváraní spojenia nie je zadaná adresa uzla, s ktorým sa chcete spojiť. Nainštalované ako prvé logické spojenie, nie fyzické, aj keď sa vždy robil opak. Ale to sa nebude zdať zvláštne, ak nezabudneme, že používame signalizačný mechanizmus tretej strany.

Takže spojenie už bolo vytvorené (logické spojenie), ale zatiaľ neexistuje spôsob, ako by sieťové uzly mohli prenášať dáta. Nie je to všetko také jednoduché, ale začnime jednoducho. Nech sú uzly v rovnakej súkromnej sieti. Ako už vieme, môžu sa navzájom ľahko spojiť cez svoje vnútorné IP adresy (alebo možno nejaké iné, ak sa nepoužívajú TCP/IP).

Prostredníctvom niektorých zavolaj späť a WebRTC hovorí nám Ľadový kandidát predmety. Prichádzajú tiež v textovej forme a rovnako ako v prípade deskriptorov relácií, musia byť odoslané prostredníctvom signalizačného mechanizmu. Ak deskriptor relácie obsahoval informácie o našich nastaveniach na úrovni kamery a mikrofónu, potom kandidáti obsahujú informácie o našej polohe v sieti. Odovzdajte ich inému uzlu a ten sa k nám bude môcť fyzicky pripojiť a keďže už má deskriptor relácie, môže sa logicky pripojiť a dáta budú „plynúť“. Ak nám nezabudne poslať svoj kandidátsky objekt, teda informáciu o tom, kde sa v sieti nachádza, tak sa s ním budeme vedieť spojiť. Všimli sme si tu ešte jeden rozdiel oproti klasickej interakcii klient-server. Komunikácia s HTTP server prebieha podľa schémy požiadavka-odpoveď, klient odošle dáta na server, ktorý ich spracuje a odošle cez adresa uvedená v balíku žiadosti. AT WebRTC potreba vedieť dve adresy a spojte ich na oboch stranách.

Rozdiel od úchytov relácie je v tom, že je potrebné nastaviť iba vzdialených kandidátov. Úpravy sú tu zakázané a nemôžu priniesť žiadne výhody. V niektorých implementáciách WebRTC kandidátov je potrebné nastaviť až po nastavení rukovätí relácie.

A prečo bol iba jeden deskriptor relácie, ale kandidátov môže byť veľa? Pretože umiestnenie v sieti môže byť určené nielen jej interným IP adresu, ale aj externu adresu routera, a nie nutne jednu, ako aj adresy OTOČIŤ serverov. Zvyšok odseku bude venovaný podrobnej diskusii o kandidátoch a spôsobe pripojenia uzlov z rôznych súkromných sietí.

Takže dva uzly sú v rovnakej sieti (obrázok 8). Ako ich identifikovať? Používaním IP adresy. Žiadna iná cesta. Je pravda, že stále môžete použiť rôzne prepravy ( TCP a UDP) a rôzne porty. Toto sú informácie, ktoré obsahuje kandidátsky objekt - IP, PORT, DOPRAVA a niektoré ďalšie. Využime napr UDP doprava a 531 prístav.

Obrázok 8: Dva uzly sú v rovnakej sieti

Potom, ak sme v uzle p1, potom WebRTC nám dá takýto kandidátsky predmet - . Toto nie je presný formát, ale iba diagram. Ak sme v uzle p2, potom je kandidátom . Cez signalizačný mechanizmus p1 dostane kandidáta p2(t. j. umiestnenie uzla p2, a to jeho IP a PORT). Potom p1 môže sa spojiť s p2 priamo. správnejšie, p1 odošle údaje na adresu 10.50.150.3:531 v nádeji, že dosiahnu p2. Nezáleží na tom, či táto adresa patrí uzlu p2 alebo nejakého sprostredkovateľa. Dôležité je len to, že cez túto adresu sa budú odosielať údaje a môžu sa dostať p2.

Pokiaľ sú uzly v rovnakej sieti – všetko je jednoduché a ľahké – každý uzol má len jeden kandidátsky objekt (vždy to znamená jeho vlastný, teda jeho umiestnenie v sieti). Ale keď budú uzly, bude oveľa viac kandidátov rôzne siete.

Prejdime k zložitejšiemu prípadu. Jeden uzol bude za smerovačom (presnejšie za NAT) a druhý uzol bude v rovnakej sieti s týmto smerovačom (napríklad na internete) (obrázok 9).

Obrázok 9: Jeden hostiteľ za NAT, druhý nie

Tento prípad má konkrétne riešenie problému, ktoré teraz zvážime. Domáci router zvyčajne obsahuje tabuľku NAT. Ide o špeciálny mechanizmus navrhnutý tak, aby umožnil uzlom v súkromnej sieti smerovača prístup napríklad k webovým stránkam.

Predpokladajme, že webový server je priamo pripojený k internetu, to znamená, že má verejný IP* adresa. Nech je to uzol p2. Uzol p1(webový klient) odošle požiadavku na adresu 10.50.200.10 . Po prvé, údaje idú do smerovača r1, alebo skôr na jeho interiéru rozhranie 192.168.0.1 . Potom si router zapamätá zdrojovú adresu (adresu p1) a zapíše ho do špeciálnej tabuľky NAT, potom zmení zdrojovú adresu na svoju vlastnú ( p1 → r1). Ďalej podľa externé rozhranie, router posiela dáta priamo na webový server p2. Webový server spracuje údaje, vygeneruje odpoveď a odošle ju späť. Odošle do smerovača r1, keďže je to on, kto je v návratovej adrese (smerovač zmenil adresu na svoju). Router prijíma dáta, pozerá sa na tabuľku NAT a odošle údaje do uzla p1. Router tu funguje ako sprostredkovateľ.

Ale čo ak niekoľko uzlov z internej siete pristupuje k externej sieti súčasne? Ako router pochopí, komu má poslať odpoveď späť? Tento problém je vyriešený pomocou prístavov. Keď router nahradí hostiteľskú adresu svojou vlastnou, nahradí aj port. Ak dva uzly pristupujú na internet, router nahradí ich zdrojové porty rôzne. Potom, keď sa paket z webového servera vráti späť do smerovača, smerovač bude rozumieť portu, ktorému je tento paket priradený. Príklad je uvedený nižšie.

Späť k Technológii WebRTC, alebo skôr jeho časti, ktorá používa ICE protokol (teda Ľad kandidáti). Uzol p2 má jedného kandidáta (jeho umiestnenie v sieti - 10.50.200.10 ) a uzol p1, ktorý sa nachádza za smerovačom s NAT, bude mať dvoch kandidátov – lokálny ( 192.168.0.200 ) a kandidát na smerovač ( 10.50.200.5 ). Prvý z nich nie je užitočný, ale napriek tomu sa generuje, pretože WebRTC zatiaľ nevie nič o vzdialenom hostiteľovi – môže a nemusí byť v rovnakej sieti. Druhý kandidát príde vhod a ako už vieme, dôležitú úlohu bude hrať prístav (prejsť NAT).

Zápis do tabuľky NAT generované iba vtedy, keď dáta opúšťajú internú sieť. Preto uzol p1 musí najprv preniesť dáta a až potom dáta uzla p2 môže dostať do uzla p1.

Na praxi oba uzly bude pozadu NAT. Na vytvorenie záznamu v tabuľke NAT každý smerovač, uzly musia niečo poslať vzdialenému uzlu, ale tentoraz ani prvý nemôže dosiahnuť druhý a ani naopak. Je to spôsobené tým, že uzly nepoznajú svoje vonkajšie IP adresy a posielanie údajov na interné adresy nemá zmysel.

Ak sú však známe externé adresy, spojenie sa ľahko vytvorí. Ak prvý uzol odošle údaje do smerovača druhého uzla, smerovač ich bude ignorovať, pretože jeho tabuľka NAT kým je prázdny. Avšak v smerovači prvého uzla v tabuľke NAT bol potrebný záznam. Ak teraz druhý uzol posiela údaje do smerovača prvého uzla, smerovač ich úspešne prenesie do prvého uzla. Teraz stôl NAT druhý router má dáta, ktoré potrebuješ.

Problém je v tom, aby ste poznali svoje vonkajšie IP adresu, potrebujete uzol umiestnený v spoločná sieť. Na vyriešenie tohto problému sa používajú ďalšie servery, ktoré sú priamo pripojené k internetu. S ich pomocou sa vytvárajú aj cenné záznamy v tabuľke. NAT.

Servery STUN a TURN

Pri inicializácii WebRTC k dispozícii STUN a OTOČIŤ servery, ktoré budeme označovať ako ICE serverov. Ak nie sú špecifikované servery, potom iba uzly v rovnakej sieti (k nej sú pripojené bez NAT). Hneď treba poznamenať, že pre 3 g- musia sa používať siete OTOČIŤ serverov.

STUN server je len server na internete, ktorý sa vracia spiatočná adresa, čo je adresa hostiteľa odosielateľa. Uzol za smerovačom pristupuje STUN server prejsť NAT. Balík, ktorý prišiel STUN server, obsahuje zdrojovú adresu - adresu smerovača, teda externú adresu nášho uzla. Táto adresa STUN server a odošle späť. Takto uzol dostane svoj vonkajší IP adresu a port, cez ktorý je prístupný zo siete. ďalej WebRTC použitím tejto adresy sa vytvorí ďalší kandidát (adresa a port externého smerovača). Teraz v tabuľke NAT smerovač má záznam, ktorý posiela pakety odoslané smerovaču na požadovanom porte do nášho uzla.

Pozrime sa na tento proces na príklade.

Príklad (prevádzka servera STUN)

STUN server bude označený s1. Router, ako predtým, cez r1 a cez uzol p1. Budete sa tiež musieť riadiť tabuľkou NAT- označme to ako r1_nat. Okrem toho táto tabuľka zvyčajne obsahuje veľa položiek z rôznych uzlov podsiete - nebudú uvedené.

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

Tabuľka 2: Hlavička paketu

Uzol p1 odošle tento paket do smerovača r1(bez ohľadu na to, ako sa dajú použiť rôzne technológie v rôznych podsieťach). Router musí nahradiť zdrojovú adresu src IP, keďže adresa uvedená v pakete určite nie je vhodná pre externú podsieť, navyše adresy z tohto rozsahu sú rezervované a ani jedna adresa na internete takúto adresu nemá. Smerovač vykoná náhradu v pakete a vytvorí nový záznam vo vašej tabuľke r1_nat. Aby to urobil, musí prísť s číslom portu. Pripomeňme, že keďže niekoľko uzlov v rámci podsiete má prístup k externej sieti, potom v tabuľke NAT by mali byť zachované Ďalšie informácie takže smerovač môže určiť, ktorému z týchto niekoľkých hostiteľov je určený návratový paket zo servera. Nechajte router prísť s portom 888 .

Zmenená hlavička balíka:

Tabuľka 4: Tabuľka NAT aktualizovaná novou položkou

Tu IP adresa a port pre podsieť sú presne rovnaké ako pôvodný paket. Pri postbacku musíme mať spôsob, ako ich úplne obnoviť. IP adresa pre externú sieť je adresa smerovača a port sa zmenil na port, ktorý vymyslel smerovač.

Skutočný port, na ktorý je uzol p1 akceptuje spojenie - toto, samozrejme, 35777 , ale server odosiela údaje do fiktívne prístav 888 , ktorý router zmení na skutočný 35777 .

Router teda zmenil zdrojovú adresu a port v hlavičke paketu a pridal záznam do tabuľky NAT. Teraz je paket odoslaný cez sieť na server, teda uzol s1. pri vstupe, s1 má tento balík:

src IP	Src PORT	Cieľová IP	DEST PORT
10.50.200.5	888	12.62.100.200	6000

Tabuľka 5: Server STUN prijal paket

Celkom STUN server vie, že prijal paket z adresy 10.50.200.5:888 . Teraz server pošle túto adresu späť. Stojí za to zastaviť sa tu a vrátiť sa k tomu, o čom sme práve uvažovali. Vyššie uvedené tabuľky sú súčasťou hlavička balík, vôbec nie z neho obsahu. O obsahu sme sa nebavili, keďže ten nie je taký dôležitý – je to nejako popísané v protokole STUN. Teraz zvážime okrem názvu aj obsah. Bude to jednoduché a bude obsahovať adresu smerovača - 10.50.200.5:888 hoci sme to zobrali z hlavička balík. Toto sa často nerobí, protokoly sa väčšinou nestarajú o informácie o adresách uzlov, dôležité je len to, aby boli pakety doručené na miesto určenia. Tu uvažujeme o protokole, ktorý vytvára cestu medzi dvoma uzlami.

Takže teraz máme druhú várku, ktorá ide opačným smerom:

Tabuľka 7: Server STUN odošle paket s týmto obsahom

Potom paket prechádza sieťou, kým nedosiahne externé rozhranie smerovača r1. Router chápe, že balík nie je určený pre neho. Ako tomu rozumie? To sa dá nájsť iba podľa prístavu. Port 888 nepoužíva na svoje osobné účely, ale používa na mechanizmus NAT. Preto sa router pozrie do tejto tabuľky. Pozerá na stĺpec Externý PORT a hľadá reťazec, ktorý sa zhoduje DEST PORT z prichádzajúceho balíka, tzn 888 .

interná IP	Vnútorný PORT	externá IP	Externý PORT
192.168.0.200	35777	10.50.200.5	888

Tabuľka 8: Tabuľka NAT

Máme šťastie, že takáto linka existuje. Ak by to nemalo šťastie, paket by sa jednoducho zahodil. Teraz musíte pochopiť, ktorý z uzlov podsiete by mal odoslať tento paket. Neponáhľajme sa, zopakujme si dôležitosť portov v tomto mechanizme. Súčasne dva uzly v podsieti mohli odosielať požiadavky do externej siete. Potom, ak pre prvý uzol smerovač prišiel s portom 888 , potom by na druhý prišiel s prístavom 889 . Predpokladajme, že sa to stalo, teda stôl r1_nat vyzerá takto:

Tabuľka 10: Adresa prijímača spoofingu smerovača

src IP	Src PORT	Cieľová IP	DEST PORT
12.62.100.200	6000	192.168.0.200	35777

Tabuľka 11: Smerovač zmenil adresu prijímača

Paket úspešne dorazí do uzla p1 a pohľadom na obsah paketu sa uzol dozvie o jeho vonkajšku IP adresu, teda adresu smerovača vo vonkajšej sieti. Pozná aj port, cez ktorý router prechádza NAT.

Čo bude ďalej? Načo je toto všetko? Prínosom je záznam v tabuľke r1_nat. Ak teraz niekto pošle na router r1 portový balík 888 , potom smerovač prepošle tento paket hostiteľovi p1. Tak vznikol malý úzky priechod do skrytého uzla p1.

Z vyššie uvedeného príkladu môžete získať určitú predstavu o tom, ako to funguje. NAT a podstatou STUN server. Vo všeobecnosti mechanizmus ICE a OMRÁČIŤ/OTÁČIŤ servery sú zamerané len na prekonanie obmedzení NAT.

Medzi uzlom a serverom môže byť viac ako jeden smerovač, ale niekoľko. V tomto prípade uzol dostane adresu smerovača, ktorý ako prvý vstúpi do rovnakej siete ako server. Inými slovami, dostaneme adresu smerovača, ku ktorému je pripojený STUN server. Pre p2p komunikácia je presne to, čo potrebujeme, ak nezabudneme na to, že v každom routeri sa do tabuľky pridá linka, ktorú potrebujeme NAT. Takže cesta späť bude opäť rovnako hladká.

OTOČIŤ server je vylepšený STUN server. Z toho hneď vyplýva, že akékoľvek OTOČIŤ server môže fungovať a ako STUN server. Existujú však aj výhody. Ak p2p komunikácia nie je možná (ako napr 3 g siete), potom sa server prepne do režimu opakovača ( relé), teda funguje ako sprostredkovateľ. Samozrejme, o akomkoľvek p2p potom to nie je otázka, ale mimo rámca mechanizmu ICE uzly si myslia, že komunikujú priamo.

V akých prípadoch je to potrebné OTOČIŤ server? Prečo nestačí STUN servery? Faktom je, že existuje niekoľko typov NAT. Nahrádzajú to isté IP adresu a port, ale niektoré z nich majú vstavané dodatočná ochrana z „falšovania“. Napríklad v symetrické tabuľky NAT Uložia sa ďalšie 2 parametre - IP a port vzdialeného hostiteľa. Prejde paket z externej siete NAT do internej siete len vtedy, ak sa zdrojová adresa a port zhodujú s tými, ktoré sú zaznamenané v tabuľke. Preto zameranie STUN server zlyhá - tabuľka NAT ukladá adresu a port STUN server a keď smerovač prijme paket od WebRTC partnera, odhodí ho, keďže je „sfalšovaný“. Nepochádzal z STUN server.

Touto cestou OTOČIŤ server je potrebný, keď sú obaja partneri pozadu symetrické NAT(každý za svoje).

Krátke zhrnutie

Tu je niekoľko vyhlásení o subjektoch WebRTC ktoré treba mať stále na pamäti. Sú podrobne opísané vyššie. Ak sa vám niektorý z výrokov nezdá úplne jasný, prečítajte si znova príslušné odseky.

• mediálny prúd
  • Video a audio dáta sú zabalené do mediálnych tokov
  • Toky médií synchronizujú mediálne stopy, ktoré tvoria
  • Rôzne mediálne toky nie sú synchronizované
  • Mediálne streamy môžu byť lokálne a vzdialené, kamera a mikrofón sú zvyčajne pripojené k lokálnemu, vzdialené prijímajú dáta zo siete v šifrovanej podobe
  • Existujú dva typy mediálnych stôp – pre video a pre zvuk.
  • Mediálne stopy majú možnosť zapnúť/vypnúť
  • Mediálne stopy sa skladajú z mediálnych kanálov
  • Mediálne stopy synchronizujú mediálne kanály, ktoré tvoria
  • Mediálne toky a mediálne stopy majú štítky, podľa ktorých ich možno rozlíšiť
• Rukoväť relácie
  • Deskriptor relácie sa používa na logické prepojenie dvoch sieťových uzlov
  • Deskriptor relácie ukladá informácie o dostupné spôsoby kódovanie obrazových a zvukových dát
  • WebRTC používa externý signalizačný mechanizmus – úlohu preposielať deskriptory relácie ( sdp) pripadá na aplikáciu
  • Mechanizmus logického spojenia pozostáva z dvoch etáp - návrh ( ponúknuť) a odpoveď ( odpoveď)
  • Generovanie deskriptora relácie nie je možné bez použitia lokálneho mediálneho streamu v prípade ponuky ( ponúknuť) a nie je možné bez použitia deskriptora vzdialenej relácie v prípade odpovede ( odpoveď)
  • Výsledný deskriptor musí byť daný implementácii WebRTC a nezáleží na tom, či je tento handle získaný vzdialene alebo lokálne z rovnakej implementácie WebRTC
  • Je možné mierne upraviť deskriptor relácie
• Kandidáti
  • Kandidát ( Ľadový kandidát) je adresa uzla v sieti
  • Adresa uzla môže byť vaša vlastná, alebo to môže byť adresa smerovača resp OTOČIŤ serverov
  • Kandidátov je vždy veľa
  • Kandidát sa skladá z IP adresa, prístav a druh dopravy ( TCP alebo UDP)
  • Kandidáti sa používajú na vytvorenie fyzického spojenia medzi dvoma uzlami v sieti
  • Kandidátov je tiež potrebné poslať cez signalizačný mechanizmus
  • Kandidáti musia prejsť aj implementáciami WebRTC, ale len na diaľku
  • V niektorých implementáciách WebRTC Kandidátov možno odovzdať až po nastavení deskriptora relácie
• STUN/TURN/ICE/NAT
  • NAT– mechanizmus na poskytovanie prístupu do vonkajšej siete
  • Domáce smerovače podporujú špeciálnu tabuľku NAT
  • Router nahrádza adresy v paketoch – zdrojovú adresu svojou vlastnou, ak paket smeruje do vonkajšej siete, a cieľovú adresu hostiteľskou adresou vo vnútornej sieti, ak paket prišiel z externej siete
  • Na poskytovanie viackanálového prístupu k externej sieti NAT používa porty
  • ICE- obtokový mechanizmus NAT
  • STUN a OTOČIŤ servery - pomocné servery na obchádzanie NAT
  • STUN server vám umožňuje vytvárať potrebné položky v tabuľke NAT a tiež vráti externú adresu uzla
  • OTOČIŤ server zovšeobecňuje STUN mechanizmus a vždy funguje
  • V najhorších prípadoch OTOČIŤ server sa používa ako sprostredkovateľ ( relé), tj p2p sa zmení na spojenie klient-server-klient.