Co je Web Real Time Communications?

WebRTC (Web Real Time Communications) je standard, který popisuje přenos streamovaných zvukových dat, videodat a obsahu mezi prohlížeči (bez instalace zásuvných modulů nebo jiných rozšíření) nebo jinými aplikacemi, které jej podporují, v reálném čase. Tato technologie umožňuje proměnit prohlížeč ve videokonferenční terminál. Chcete-li zahájit komunikaci, stačí otevřít webovou stránku konference.

‍

Jak WebRTC funguje

Uvažujte o fungování technologie na příkladu hovoru mezi dvěma účastníky prostřednictvím prohlížeče:

‍

‍

1. Uživatel otevře stránku obsahující obsah WebRTC.
2. Prohlížeč si vyžádá přístup k webové kameře a mikrofonu, je-li to nutné. Dokud uživatel nepovolí přístup k zařízení, nebude se používat. V případech, kdy je to nepovinné (například při sledování vysílání), nejsou vyžadována žádná další oprávnění.

‍

‍

Výhody standardu WebRTC.

• Není nutná instalace softwaru.
• Vysoce kvalitní komunikace díky:
  • Díky použití moderních video a audio kodeků;
  • automatickému přizpůsobení kvality datového toku podmínkám připojení;
  • vestavěný systém redukce ozvěny a šumu;
  • automatické řízení úrovně mikrofonů účastníků (AGC).
• Vysoká úroveň zabezpečení: všechna spojení jsou zabezpečená a šifrovaná podle protokolů DTLS a SRTP. WebRTC zároveň funguje pouze přes protokol HTTPS a web využívající tuto technologii musí být podepsán certifikátem.
• V rámci implementace kodeků VP9 a AV1 byla přidána podpora technologie SVC. Přestože v současné době ještě neexistuje implementace v samotných prohlížečích, softwarová řešení TrueConf umožňují použití SVC v klientech prohlížeče.
• K dispozici je vestavěný mechanismus pro zachycení obsahu, jako je např. plocha.
• Možnost implementovat libovolné ovládací rozhraní založené na HTML5 a JavaScriptu.
• Projekt s otevřeným zdrojovým kódem - můžete jej vložit do svého produktu nebo služby.
• Skutečná multiplatformnost: stejná aplikace WebRTC bude fungovat stejně dobře v jakémkoli operačním systému, na počítači nebo mobilním zařízení, pokud prohlížeč podporuje WebRTC. Tím se ušetří spousta prostředků na vývoj softwaru.

‍

Nevýhody normy

• Všechna řešení WebRTC jsou vzájemně nekompatibilní, protože standard popisuje pouze způsoby přenosu obrazu a zvuku a implementaci metod pro oslovování účastníků, sledování jejich dostupnosti, výměnu zpráv a souborů, plánování a další věci ponechává na vývojáři. Jinými slovy, nebude možné volat z jedné aplikace WebRTC do druhé.
• Pro uživatele, kteří mají obavy o své soukromí, bude nepříjemným zjištěním, že WebRTC zjišťuje jejich skutečné IP adresy. Současně ani proxy server, ani použití sítě Tor nepomůže zachovat anonymitu. IP adresu můžete skrýt pomocí různých služeb VPN a také při použití serveru TURN. V případě potřeby lze používání WebRTC zakázat.
• WebRTC nepodporuje vzdálenou správu plochy. Ano, můžete vysílat, co se děje na obrazovce zařízení, ale bude to stejný jednosměrný videostream jako obraz přenášený z kamery a neexistuje žádný způsob interakce se zdrojem streamu. To je provedeno z bezpečnostních důvodů: Kód Javascript nemůže ovládat nic mimo aktuální okno prohlížeče. Další funkce, včetně ovládání vzdálené plochy, lze získat pomocí speciálně vyvinutých klientských aplikací dodavatelů videokonferencí.

‍

Kodeky ve WebRTC

Kodeky WebRTC lze rozdělit na povinné (prohlížeče, které tuto technologii implementují, je musí podporovat) a volitelné (nejsou součástí standardu, ale některé prohlížeče je přidávají).

Zvukové kodeky

Ke kompresi zvukového provozu ve WebRTC se používají povinné kodeky (Opus a G.711) a doplňkové kodeky (G.722, iLBC, iSAC).

Opus

• Opus je zvukový kodek s nízkou latencí kódování (od 2,5 ms do 60 ms), podporou variabilního datového toku a vysokou kompresí, který je ideální pro přenos zvuku v sítích s proměnlivou šířkou pásma. Je to hlavní zvukový kodek pro WebRTC. Opus je hybridní řešení, které kombinuje nejlepší vlastnosti kodeků SILK (Voice Compression, Human Speech Distortion Elimination) a CELT (Audio Data Encoding). Kodek je volně dostupný, vývojáři, kteří jej používají, nemusí platit licenční poplatky držitelům autorských práv. Ve srovnání s jinými zvukovými kodeky Opus rozhodně vítězí v mnoha ohledech. V řadě parametrů překonává poměrně populární kodeky s nízkým datovým tokem, jako jsou MP3, Vorbis, AAC LC. Opus obnovuje "obraz" zvuku blíže originálu než AMR-WB a Speex.

G.711

• G.711 je zastaralý hlasový kodek s vysokou přenosovou rychlostí (64 kb/s), který se nejčastěji používá v tradičních telefonních systémech. Hlavní výhodou je minimální výpočetní zátěž díky použití lehkých kompresních algoritmů. Kodek má nízkou úroveň komprese hlasových signálů a nezavádí dodatečné zpoždění zvuku při komunikaci mezi uživateli.
• G.711 je podporován velkým počtem zařízení. Systémy využívající tento kodek se používají snadněji než systémy založené na jiných zvukových kodecích (G.723, G.726, G.728 atd.). Z hlediska kvality získal kodek G.711 při testování MOS skóre 4,2 (skóre 4-5 je nejvyšší a znamená dobrou kvalitu, podobnou kvalitě hlasového provozu v ISDN a dokonce vyšší).

G.722

• G.722 je standard ITU-T přijatý v roce 1988 a v současné době je volný. Může pracovat při rychlostech 48, 56 a 64 kb/s a poskytuje kvalitu zvuku na úrovni standardu G.711. Stejně tak je G.711 zastaralý. Je podporován v prohlížečích Chrome, Safari a Firefox.

iLBC

• iLBC (internet Low Bitrate Codec) je úzkopásmový řečový kodek s otevřeným zdrojovým kódem. K dispozici v prohlížečích Chrome a Safari. Vzhledem k vysoké kompresi datového toku se při použití tohoto kodeku zvyšuje zatížení procesoru.

iSAC

• iSAC (internet Speech Audio Codec) je širokopásmový řečový kodek, dříve proprietární, který je v současné době součástí projektu WebRTC, ale jeho použití není povinné. Podporován v prohlížečích Chrome a Safari. Implementace pro WebRTC používá adaptivní datový tok od 10 do 52 kb/s se vzorkovací frekvencí 32 kHz.

‍

Video kodeky

Problematika výběru videokodeku pro WebRTC zabrala vývojářům několik let, výsledkem bylo zařazení kodeků VP8 a H.264 do standardu. Existují také implementace volitelných videokodeků (H.265, VP9, AV1).

VP8

• VP8 je bezplatný videokodek s otevřenou licencí, který se vyznačuje vysokou rychlostí dekódování videostreamu a zvýšenou odolností proti ztrátě snímků. Kodek je univerzální, lze jej snadno implementovat do hardwarových platforem, proto jej vývojáři videokonferenčních systémů často používají ve svých produktech. Kompatibilní s prohlížeči Chrome, Edge, Firefox a Safari (12.1+).
• Placený videokodek H.264 se stal známým mnohem dříve než jeho protějšek. Jedná se o kodek s vysokým stupněm komprese videoproudu při zachování vysoké kvality videa. Rozšířené použití tohoto kodeku mezi hardwarovými videokonferenčními systémy naznačuje jeho použití ve standardu WebRTC. Kompatibilní s prohlížeči Chrome (52+), Edge, Firefox (zastaralý pro Android 68+) a Safari.

VP9

• VP9 je otevřený a bezplatný standard pro kompresi videa, který v roce 2012 vyvinula společnost Google. Jedná se o vývoj myšlenek obsažených v standardu VP8 a následně byl rozšířen v rámci standardu AV1. Kompatibilní s prohlížeči Chrome (48+) a Firefox.

H.265

• H.265 je placený video kodek, který je nástupcem H.264 a poskytuje stejnou vizuální kvalitu při polovičním datovém toku. Toho je dosaženo díky účinnějším kompresním algoritmům. Tento kodek v současné době konkuruje bezplatnému kodeku AV1.

AV1

• AV1 je kodek s otevřeným zdrojovým kódem pro kompresi videa určený speciálně pro přenos videa přes internet. Podporován v prohlížečích Chrome (70+) a Firefox (67+).

‍

Triky při práci s WebRTC

Signalizační server

WebRTC neposkytuje prohlížečům způsob, jak se navzájem vyhledat. Můžeme si vygenerovat všechny potřebné metainformace o svých blízkých, ale jak se jeden prohlížeč dozví o existenci druhého? Jak je propojit?

Signalizační server WebRTC je server, který spravuje spojení mezi vrstevníky. Slouží právě k signalizaci. Pomáhá s tím, aby jeden peer našel v síti druhého, vyjednává samotné spojení, v případě potřeby resetuje spojení a ukončuje ho.

WebRTC nespecifikuje signalizační protokol, je třeba jej vyvinout sám nebo použít hotová řešení. Rovněž není specifikován transport pro signalizační protokol. Můžete použít HTTP, WebSocket nebo datový kanál. Běžně se používá WebSocket v případě, že je založen na trvalém spojení a může přenášet data téměř v reálném čase.

Práce s hardwarovými zařízeními

Názvy a charakteristiky kamer nemůžeme získat, dokud není navázáno spojení. Pokud je v klientském systému nainstalována více než jedna kamera. Například mobilní zařízení. Můžeme uživateli nabídnout pouze volbu Kamera 1 nebo Kamera 2, ale nepojmenováváme tyto kamery (například "Logitech", "Přední kamera", "FullHD kamera").

Pokud klient během relace připojí nové zařízení, webová aplikace o tom nebude informována, dokud uživatel neobnoví stránku. To znamená, že pokud jste již otevřeli stránku konference a poté připojili novou kameru USB, aplikace se o tom nedozví.

Zachycení médií

Z bezpečnostních důvodů prohlížeč neposkytuje přímý přístup k ovladačům kamery. Proto nemůžeme na kameře trvat, zvolit rozlišení, snímkovou frekvenci apod.

Také nemůžeme provádět následné zpracování videa, nastavovat jas, zrcadlit video a další věci, které jsou obvykle součástí nastavení ovladače kamery.

Neexistuje také žádné jednotné standardní řešení pro sdílení pracovní plochy. Možná jste se v aplikacích pro videokonference setkali s tím, že po spuštění sdílení plochy se často vytvoří další účastník konference, který streamuje vybranou plochu nebo okno aplikace. Problémy, se kterými se potýkáme při práci s kamerami (nemožnost zadat název kamery a nemožnost získat charakteristiku zařízení), platí i pro práci s monitory při vysílání plochy.

P2P připojení (protokol popisu relace SDP)

Rozhraní API pro generování protokolu SDP je asynchronní, takže mohou nastat situace, kdy parametry mediálního toku popsané v příchozím paketu SDP neodpovídají tomu, co klient skutečně odesílá.

Existují dva formáty SDP: Plán B používaný prohlížeči založenými na Chromiu a Unified Plan používaný prohlížečem Firefox.

Plán B má všechny mediální toky ve stejném formátu. Pokud nepoužijeme externí mediální server, existuje možnost, že někteří účastníci konference nebudou rozumět formátu našeho mediálního toku a nebudou jej moci zobrazit.

Jednotný plán umožňuje vybrat kodek pro každý mediální proud.

Například kódovat vysílání z pracovní plochy jedním kodekem a vysílání z kamery jiným kodekem. Můžete naučit signálový server překládat jeden SDP na jiný, ale jeho zatížení zvyšuje zátěž serveru.

Translated with DeepL.com (free version)

RTP a SRTP(ssl) streamování médií

Jak žít, když je NAT, když počítače vystupují pod jednou IP adresou, ale uvnitř o sobě vědí jiné? Na pomoc přichází rámec ICE - Internet Connectivity Establishment. Popisuje, jak obejít NAT a jak navázat spojení, pokud máme NAT.

Tento rámec využívá server STUN. Jedná se o takový speciální server, s odkazem na který můžete zjistit svou vnější IP adresu. V procesu navazování spojení P2P tedy musí každý z klientů vznést požadavek na tento server STUN, aby zjistil svou IP adresu, vygeneroval další informace, IceCandidate, a vyměnil si tento IceCandidate pomocí signalizačního mechanismu. Poté se klienti dozvědí o sobě navzájem správné IP adresy a budou moci navázat spojení P2P. Existují však i složitější případy. Například když je počítač skryt za dvojitým NAT. V takovém případě rámec ICE nařizuje použití serveru TURN.

Jedná se o takový speciální server, který mění spojení klient-klient, P2P, na spojení klient-server-klient, tj. funguje jako relay. Dobrou zprávou pro vývojáře je, že bez ohledu na to, podle kterého ze tří scénářů bylo spojení navázáno, zda jsme v místní síti, nebo zda potřebujeme kontaktovat server STUN nebo TURN, bude pro nás technologie API totožná. Jednoduše na začátku zadáme konfiguraci serverů ICE a TURN, uvedeme, jak k nim máme přistupovat, a poté už za nás technologie udělá vše pod kapotou.

Zde se setkáváme s dalšími obtížemi. První z nich je nutnost mít servery STUN a TURN, respektive náklady na jejich podporu a údržbu. Server TURN, přestože se jedná o jednoduchý proxy server a nezpracovává video, musí mít vysokorychlostní připojení k internetu, aby mohl distribuovat mediální proud v reálném čase všem účastníkům konference.

‍

WebRTC for the video conferencing market

Popularita technologie

K dnešnímu dni je WebRTC druhým nejoblíbenějším protokolem pro videokomunikaci po proprietárním protokolu Zoom a předstihuje všechny ostatní standardy (H.323 a SIP) a proprietární protokoly (Microsoft Teams a Cisco Webex).

Nárůst počtu zákazníků

Technologie WebRTC má silný vliv na rozvoj trhu videokonferencí. Po vydání prvních prohlížečů s podporou WebRTC v roce 2013 se potenciální počet videokonferenčních terminálů na celém světě okamžitě zvýšil o 1 miliardu zařízení. Ve skutečnosti se každý prohlížeč stal videokonferenčním terminálem se základními možnostmi pro účast na videokonferenci. Použití ve specializovaných řešeních

Použití různých knihoven JavaScriptu a rozhraní API cloudových služeb s podporou WebRTC umožňuje snadno přidat podporu videa do libovolných webových projektů. V minulosti přenos dat v reálném čase vyžadoval, aby se vývojáři naučili, jak protokoly fungují, a využívali práce jiných společností, což většinou vyžadovalo další licence, které zvyšovaly náklady. Již nyní se WebRTC aktivně využívá pro organizování videokontaktických center, pořádání webinářů apod.

Konkurence s Flashem

WebRTC a HTML5 znamenaly smrtelnou ránu pro technologii Flash, která už tehdy prožívala svá zdaleka ne nejlepší léta. Od roku 2017 přestaly přední prohlížeče oficiálně podporovat Flash a tato technologie definitivně zmizela z trhu.

‍

Příklady služeb využívajících WebRTC

Google Meet

Google Meet je služba pro okamžité zasílání zpráv a také pro videohovory a audiohovory, kterou společnost Google uvedla na trh v roce 2017. Prohlížeče založené na platformě Chromium (Google Chrome atd.) využívají mnoho skrytých funkcí WebRTC, které nejsou zdokumentovány a pravidelně se objevují jako první v jeho řešení Meet (stejně jako v předchůdci Hangouts). Tak tomu bylo u snímání obrazovky, rozostření pozadí, podpory hardwarového kódování na některých platformách.

Jitsi Meet

Jitsi Meet je open source aplikace vydaná společností 8x8. Technologie Jitsi je založena na architektuře Simulcast, což znamená nestabilní provoz na slabých komunikačních kanálech a vysoké nároky na rychlost připojení na straně serveru. Umožňuje vést webové konference pouze v prohlížeči a nemá plnohodnotné klientské aplikace pro spolupráci, podporovány jsou konference s maximálně 75 účastníky (až 35 s vysokou kvalitou hovoru). Pro plnohodnotné využití Jitsi ve firemním prostředí je třeba samostatně vyvinout a nainstalovat další software.

BigBlueButton

BigBlueButton je bezplatný software pro videokonference. Vývojáři kladou zvláštní důraz na vzdělávání na dálku (k dispozici jsou funkce jako interaktivní tabule, zobrazování obsahu, podpora průzkumů atd.). Podporuje webové konference až pro 100 účastníků.

Co třeba Zoom?

Navzdory všeobecnému přesvědčení nepoužívá Zoom k přenosu a dekódování mediálních dat technologii WebRTC. Bylo tak učiněno z důvodu úspory serverových zdrojů. Na straně prohlížeče jsou zapojeny jiné webové technologie - nízkoúrovňové WebAssembly a WebSocket. Při použití těchto nestandardních přístupů k přenosu videostreamu mohou mít někteří účastníci problémy s kvalitou obrazu.

‍