Problémy realizace videokonferencí a skupinového multimediálního vysílání v prostředí MZLU

ZDROJE DAT52

SLOVNÍČEK POJMŮ52

1. Úvod

Tématem této diplomové práce je objasnění problematiky videokonferencí a multimediálního vysílání a možností těchto technologií pro podporu vzdělávacího procesu na MZLU.

Videokonference jsou mladé a vysoce atraktivní odvětví. Jedná se vlastně o rozšířený telefonní rozhovor, kdy kromě hlasu je přenášen i obraz a případně některé další informace. Nahlíženo s odstupem se zdá, že ve srovnání s telefonem Videokonference nenabízí mnoho navíc. Jádro přenášené informace spočívá ve zvuku, neboť záleží především na tom, co kdo řekne. Ovšem psychologický efekt obrazového přenosu je mocný. Vzniká dojem, že partneři spolu komunikují z bezprostřední blízkosti, jako by byly ve společné místnosti. Druhou výhodou je, že se může zapojit více uživatelů, kteří jsou rozptýleni po celé republice (či po celém světe) a přestože žádný z nich nevstal od svého stolu, mohou spolu plnohodnotně komunikovat. Bez použití videokonferenční technologie by mohli srovnatelná setkání pořádat daleko vzácněji.

Možné způsoby realizace videokonferencí jsou IP konference, MBone konference (MBone = Multicast Backbone – páteřní síť podporující multicast), ISDN konference a ATM konference. V následném textu je podrobněji pojednáno o MBone videokonferenci, což je vlastně virtuální síť realizovaná v rámci sítě Internet. Z dostupných variant je nejsnadněji použitelná, má nízké pořizovací i provozní náklady a přitom jsou její služby dostatečně kvalitní.

Využití videokonferencí nebo multimediálního vysílání pro podporu výuky přináší nové přístupy oproti klasickému učení. Systém, který toto umožňuje se nazývá E-Learning (elektronické učení). Jedná se o to, že daný systém ve srovnání s klasickými metodami má prakticky neomezenou kapacitu kurzu, nabízí využití multimediálních formátů (audio, video, animace apod.) a další výhody.

Struktura diplomové práce:

• První kapitolou je tento úvod, který obsahuje informace o obsahu a struktuře této diplomové práce.

• Kapitola druhá se zabývá možnými způsoby realizace videokonferencí, srovnání možností videokonferencí LAN a WAN a nakonec jsou zde rozebrány jednotlivé síťové protokoly nutné pro zajištění multimediálního vysílání. V první části se nachází srovnání videokonferencí realizovaných pomocí IP, MBone, ISDN a ATM. Další část obsahuje popis možností provozování videokonferencí v rámci LAN a nutné vybavení (směrovače) pro provoz videokonferencí přes WAN. Poslední část zahrnuje protokoly nutné pro multicast. Patří sem protokoly zajišťující přenos dat a jeho řízení (RSVP, RTP, RTCP, RTSP, IGMP) a dále routovací protokoly v  dense mode a sparse mode. Do první skupiny patří DVMRP, MOSPF a PIM-DM, do druhé potom CBT a PIM-SM.

• Ve třetí kapitole je uveden přehled potřebného vybavení pro provozování videokonferencí. Jednak sem patří vybavení (hardwarové a softwarové) počítače účastníka konference a potom také to, co leží mezi jednotlivými účastníky – přenosová cesta (routery, mroutery, tunely).

• Ve čtvrté kapitole jsou shrnuty informace o projektech, které se zabývali (zabývají) videokonferencemi, zajistily jejich rozvoj a umožnily jejich rozšíření. Patří sem série projektů prováděných v Evropě - MICE, MERCI a MECCANO. Jedná se o projekty, které na sebe navzájem navazují. Poté následují další evropské projekty Quantum a jeho pokračovatel GÉANT, americký projekt Internet2 a česká součást projektů – TEN 155 CZ. Nakonec shrnu poznatky z uspořádání dosud asi největší videokonference s názvem Global 360.

• V páté kapitole sepíši své zkušenosti s provozováním multimediálního vysílání, ke kterému jsem použil program sdr a jeho moduly (sdr je zde také popsán).

• Šestá kapitola obsahuje návrh systému, který umožňuje provozování videokonferencí na MZLU Brno. Je zde možno navázat spolupráci s jinými vysokými školami a tento systém propojit a vybudovat tak celkový integrovaný systém pro elektronickou výuku (E-Learning).

• Následuje seznam použité literatury a jiných zdrojů (většinou z Internetu).

• Na konci práce je uveden malý slovníček vysvětlující nejdůležitější a nejčastěji se vyskytující výrazy.

2. Rozbor síťových protokolů a standardů pro přenosy dat ve skupinovém režimu a přenosy dat v reálném čase

Nyní se budu zabývat způsoby realizace videokonferencí. Uvedu zde potřebné síťové protokoly a standardy, které byly pro videokonference vyvinuty nebo jim slouží. Nejprve se podívám na možnosti způsobu realizace videokonferencí podle přenosových technologií. Poté se budu zabývat tím, co je nutné pro provoz videokonferencí v rámci LAN a WAN. V poslední časti proberu funkci jednotlivých protokolů používaných při přenosu multimediálních dat.

2.1 Způsoby realizace videokonferencí

Způsobů realizace může být více než zde uvedu, ale já jsem vybral ty nejrozšířenější. Jedná se o realizace videokonferencí pomocí technologie IP, MBone, ISDN a nakonec také ATM.

IP videokonference používají jako přenosové médium síť Internet, přesněji řečeno její protokol IP. Jsou jednoduché a snadno implementovatelné a díky široce rozšířené podpoře IP mají zajištěn i značný okruh potenciálních uživatelů. Jejich největším problémem však je, že protokol IP nebyl koncipován pro zajišťování služeb tohoto charakteru. Neručí za to, že dopraví všechna data ve správném pořadí a s jistým maximálním zpožděním. Navíc současný Internet není dimenzován na podobné pokusy, jejichž spotřeba přenosové kapacity je značná. Z toho vyplývá, že čím větší je vzdálenost komunikujících partnerů, tím se zvyšuje riziko zhoršení kvality přenosu.

MBone videokonference jsou speciálním případem předchozí skupiny. Také zde se používají služby založené na IP, ovšem pro adresování se používají skupinové adresy a přenášená data jsou v rámci Internetu šířena virtuální sítí MBone. V rámci MBone je vyvíjeno potřebné programové vybavení, které je k dispozici pro řadu platforem. Díky tomu si v IP světě mohou tyto nástroje činit nárok na pozici jistého de facto standardu.

ISDN videokonference používají jako přenosové médium síť ISDN. Pro přenos signálu bývá vyhrazeno několik ISDN kanálů (nejčastěji dva), každý s kapacitou 64 kb/s. Na rozdíl od předchozích je zde přenosová trasa vyhrazena a tudíž nabízí zajištěné parametry spojení. Díky tomu může být výsledná kvalita o poznání vyšší. Koncovými body ISDN videokonferencí bývají poměrně často nepočítačová zařízení – speciální „krabičky“ s připojeným televizorem a videokamerou. V takovém případě pochopitelně odpadají veškeré doprovodné služby, jako je sdílená tabule či výměna souborů. Jednoduše je není jak realizovat.

ATM videokonference představují špičkovou technologii jak z hlediska kvality přenášeného signálu, tak z hlediska pořizovacích nákladů a nároků na přenosové kapacity. Svým charakterem se velmi podobají ISDN videokonferencím. Data se přenášejí rezervovaným ATM kanálem s definovanými parametry, takže kvalita přenosové infrastruktury je opět zaručena. Obraz a zvuk jsou zpracovávány způsobem podobným digitální televizi (používá se kódování MPEG) a také výsledná kvalita je s ní plně srovnatelná. I přenosové kapacity odpovídají digitální televizi a podle nastavení kvality se pohybují zpravidla v řádu megabitů za sekundu. Tato technologie bývá nasazena tam, kde rozhoduje především kvalita obrazu a zvuku. Jako jeden z příkladů nasazení lze jmenovat videokonferenční přenosy lékařských operací. 

V krátkosti se dá říci, že IP videokonference jsou na tom nejhůře s kvalitou, ale nejlépe s cenou, což znamená, že jejich uplatnění spočívá především při prvních pokusech uživatele s videokonferencemi. ATM naproti tomu představuje vrchol současné technologie a také kvality. Tomu bohužel odpovídá vysoká cena. Ta je dána nutností připojení k ATM a je také nezbytné pořídit speciální kódovací zařízení, které nelze použít na jiné účely (na rozdíl od počítače v případě IP a MBone). ISDN by se dala nazvat jako levnější a méně kvalitní obdoba ATM. MBone představuje rozumné řešení svou dostupností, cenou a mnohdy dostačující kvalitou. Srovnání jednotlivých způsobů realizace videokonferencí je uvedeno v tabulce 2.1.

Tabulka 2.1: Srovnání vlastností různých druhů videokonferencí ge768d9394seep

* vzhledem k tomu, že charakteru kanálu u IP a MBone je sdílený, nelze zaručit stálost přenosové rychlosti a proto také kvalita přenosu je kolísavá

** potřeba pro 2 účastníky

Výše uvedený přehled může budit dojem, že videokonference založené na technologii MBone nejsou mezi ostatními zrovna nejlepší. Tento pohled je v jistém smyslu oprávněný, ale pro běžné konference je výkon dostačující a má velmi výhodný poměr cena/výkon. Základní nevýhodou videokonferencí postavených na protokolu IP (MBone nevyjímaje) je nezaručená kvalita přenosových služeb. To může způsobovat nejrůznější výpadky, zpoždění či chyby. Tento problém však odpadne, pokud je přenosová síť dostatečně dimenzována. Mezi její největší výhody patří snadnost jejího nasazení. Postačí k tomu počítač s výkonností a cenou dnes běžně dostupný. Jedinou nadstandardní komponentou je karta pro spolupráci s videem a kamera. Není potřeba žádné speciální zařízení v ceně stovek tisíc Kč.

Druhou důležitou výhodou je kompatibilita softwaru pro provoz videokonferencí. Jelikož nástroje pro MBone videokonference jsou dostupné pro nejširší sortiment operačních systémů, představuje jejich nasazení cestu nejmenšího odporu.

Protože se ve své práci zabývám videokonferencemi realizovanými pomocí MBone, je potřeba objasnit jeho asi největší problém, kterým je neschopnost Internetu realizovat přenos pomocí multicast adres. Nyní uvedu, jak lze toto omezení vyřešit.

2.2 Srovnání možností LAN a WAN

Při videokonferencích zdroj vysílá data, která jsou určena neznámému, potenciálně velmi velkému počtu příjemců (skupině), pouze jednou a veškerá režie spojená s distribucí spočívá plně na přenosové soustavě. Ta je tvořena soustavou směrovačů, jejichž starostí je zajištění efektivního přenosu dat od zdroje k příjemcům. Efektivita spočívá v tom, že data jsou po každém spoji vysílána nejvýše jedenkrát a to pouze v případě, že v daném směru je nějaký příjemce. Na rozdíl od unicastu, kde je přenos iniciován zdrojem, je v multicastu tok paketů určován příjemci. K adresování příjemců se používá speciální typ IP adresy (třída D), která má rozsah 224.0.0.0 až 239.255.255.255. Vysílací uzel posílá data s cílovou adresou skupiny a se zdrojovou adresou vlastní. Další postup přes směrovače probíhá stejně jako v případě unicastu, ovšem směrovač může provést duplikaci paketu a jeho vyslání do více směrů.

Způsoby realizace videokonference v prostředí LAN jsou celkem jednoduché. Protokoly na 2. vrstvě síťové hierarchie totiž obsahují ve svých specifikacích podporu skupinového vysílání v podobě speciálních MAC adres. Běžné síťové karty pak mají schopnost podle svého nastavení (na základě požadavků programu) filtrovat pakety skupinového vysílání a vyšším vrstvám předávat již jen odpovídající část paketů, které se v lokální síti pohybují, tedy pouze skupiny, jež jsou předmětem zájmu dané stanice. Nedochází tedy k zatěžování stanic lokální sítě, jichž se skupinové vysílání netýká. Z toho vyplývá, že k vysílání v rámci lokální sítě může postačit běžné technické vybavení a příslušný aplikační program (případně prostředky, které program vyžaduje, např. zvuková karta, mikrofon apod.).

Snadnost implementace multicastu v rámci LAN se vytrácí, pokud je potřeba přenášet data mezi sítěmi. Přicházejí na řadu směrovače, které mají za úkol zjistit, které skupiny mají být vysílány do sítí, jež jsou ke směrovači připojeny. K tomuto účelu byl vyvinut speciální protokol IGMP (Internet Group Management Protocol). Jeho pomocí směrovač zjišťuje zájem stanic připojených sítích o jednotlivé proudy multimediálního vysílání. Směrovač vyšle do připojené sítě dotaz (paket se speciální adresou 224.0.0.1) a jednotlivé stanice odpovídají informace o adresách skupinového vysílání, o něž mají zájem. Aby nedocházelo k zahlcení sítě při současné odpovědi všech stanic, odpovídají jednotlivé stanice s náhodně zvoleným zpožděním. Odpovědi jsou rovněž vysílány na adresu 224.0.0.1 a odposlouchávány ostatními stanicemi. Tím se zamezí duplicitnímu vysílání požadavků na stejnou skupinu. Programové vybavení koncové stanice tedy musí podporovat protokol IGMP. Směrovače tak pomocí protokolu IGMP sledují zájem o příjem konkrétních skupin ve svém bezprostředním okolí.

Směrovače musejí, kromě trvalého mapování svého bezprostředního okolí, zajistit tok paketů skupinového vysílání i do vzdálených oblastí sítě, a to pokud možno optimálním způsobem. K tomu slouží tzv. směrovací protokoly. Jejich pomocí směrovače hledají minimální strom spojů, pokrývající cestu od zdroje skupinového vysílání k momentálním zájemcům o příjem (tzv. distribuční strom). Je zřejmé, že na rozdíl od běžného směrování půjde o proces velmi dynamický. Cesta od zdroje k cíli je totiž stálá, pokud nedojde k nějaké vnější události, měnící topologii sítě (např. poruše linky). Naproti tomu zájemci o příjem daného multimediálního vysílání mohou vznikat a zanikat neustále a toto musejí směrovací protokoly vhodně reflektovat. Směrovací protokoly skupinového vysílání jsou dosud předmětem intenzivního výzkumu a vývoje. V současné době se nejvíce používají protokoly DVMRP (Distance Vector Multicast Routing Protocol) a dvě varianty protokolu PIM (Protocol Independent Multicast).

Další informace o distribučním stromu jsou uvedeny v kapitole 3.2 (Přenosová cesta). Nyní se podívám na funkci jednotlivých protokolů, které se využívají při přenosu multimediálních dat.

2.3 Protokoly pro zajištění multimediálních přenosů

Mezi tyto protokoly patří RSVP (Resource ReSerVation Protocol - umožňující přijímači požadovat určitou kvalitu služeb pro své datové toky), RTP (Realtime Transport Protocol - zajišťuje přenosy dat v reálném čase), RTCP (Realtime Control Protocol - řídící protokol určený pro spolupráci s protokolem RTP), RTSP (Realtime Streaming Protocol.- navazuje a řídí audio a video stream mezi klientem a serverem) a také IGMP (Internet Group Management Protocol). Dále sem patří routovací protokoly v "dense mode" a "sparse-mode". Do první skupiny patří DVMRP (Distance Vector Multicast Routing Protocol), MOSPF (Multicast Open Shortest Path First) a PIM-DM (Protocol-Independent Multicast - Dense Mode). Do druhé potom CBT (Core Based Trees) a PIM-SM (Protocol-Independent Multicast - Sparse Mode).

2.3.1 RSVP (Resource ReSerVation Protocol)

Je to síťový protokol umožňující přijímači požadovat určitou kvalitu služeb pro své datové toky po celé datové cestě. Realtime aplikace potom mohou rezervovat potřebné zdroje na všech routerech po celé přenosové cestě tak, aby požadované pásmo bylo k dispozici ve chvíli, kdy začne vlastni přenos.

Jak RSVP pracuje?

Když aplikace v počítači, který je přijímačem, požaduje specifickou kvalitu služeb (QoS) pro její datové toky, použije RSVP pro doručení požadavku všem routerům po datové cestě. RSVP je odpovědné za sjednání požadovaných parametrů s routery a pokud dojde k nastavení rezervace také za správu vnitřních nastavení nutných k poskytnutí požadovaných parametrů.

V každém routeru po cestě běží několik procesů starajících se o jednotlivé procedury nastavení a správy rezervace (viz Obrázek 2.1a). Nutný je policy control, který zjišťuje uživatelská a administrativní práva k vytvoření rezervace. Admission control hlídá množství a rezervace systémových prostředků a kontroluje jestli je jich ještě dostatek pro přijetí požadavku. Požadavek musí samozřejmě vyhovět oběma kontrolám, jinak je navrácena informace o chybě. Pokud je požadavek přijat, RSVP daemon nastaví příslušné parametry do packet classifieru a scheduleru. Packet classifier zajišťuje klasifikaci - rozdělení paketů do jednotlivých tříd QoS podle rezervací a packet sheduler připravuje vysílaní paketů k zajištění příslušných parametrů. Tato procedura se opakuje postupně ve všech routerech po cestě v opačném směru než putují data, dokud se reservace nemůže spojit s jinou rezervací pro stejný zdroj dat (viz Obrázek 2.1b).

Obrázek 2.1: a) Rezervační mechanismy routerub) Postup rezervace

Nastavení je implementováno takto, protože velká část multimediálních dat má charakter multicastu, tedy jednoho zdroje a více přijímačů. Rezervace tedy putuje po distribučním stromě dokud nenarazí na místo, kde již takovýto datový tok - rezervace - již existuje a je tedy možné připojit množství posluchačů bez zvýšení celkového toku dat.

Rezervace vytváří v routerech soft states a RSVP démon musí vysílat periodicky zprávy k udržení rezervace. Pokud nepřijde v určitém čase žádná zpráva, je rezervace automaticky zrušena, což je nutné z hlediska Internetu jako datagramové sítě, kde pakety mohou kdykoliv změnit přenosovou cestu. Udržování rezervace se děje pomocí dvou druhů zpráv PATH a RESV. Zprávy PATH jsou periodicky posílány z vysílače po distribučním stromě, ke kterému se přijímač musí připojit, a obsahují flow spec - informace o charakteru dat a popis zdroje. Tyto informace slouží v přijímači k nalezení datové cesty a k zjištění jaké zdroje mají být rezervovány a aby nedocházelo např. ke zbytečnému přerezervování. Zprávy RESV jsou generovány přijímači k udržení rezervací, obsahují filter spec, který slouží k nastavení filtrů v packet classifieru, a flow spec s informacemi pro řízení packet scheduleru. Zprávy RESV putují v přesně obráceném směru jako zprávy PATH. V případě změny přenosové cesty pak tyto zprávy zajistí vytvoření nové rezervace v routerech na změněné cestě, samozřejmě v případě že je tato rezervace možná.

RSVP není routovacím protokolem, je spíše řídícím protokolem. RSVP pouze využívá routovací protokoly na nižších vrstvách, aby správně doručilo požadavky na rezervaci a je informováno routovacím procesem o případných změnách v cestách. Pracuje jak s unicastovými protokoly tak i s multicastovými protokoly. RSVP je také zodpovědné pouze za doručení požadovaných parametrů spojení do jednotlivých uzlů, ne však za to, jak budou tyto parametry zpracovány. Jelikož různá zařízení mohou mít různé způsoby implementace QoS, záleží na řídících procesech těchto zařízení jak zajistí splnění požadavků. Toto zjednodušuje specifikaci RSVP a umožňuje jej jednoduše aplikovat i na nové síťové technologie.

Vlastnosti RSVP

• Podporuje unicast i multicast.

• Negarantuje žádné parametry spojení, zaručuje jen to, že pro spojení budou dostupné prostředky nutné k zajištění přenosu.

• Je orientováno na přijímače a dokáže řídit síť s heterogenními přijímači, které mohou mít rozdílné nároky na jeden datový zdroj.

• Má dobrou kompatibilitu.

2.3.2 RTP (Realtime Transport Protocol)

Realtime transport protokol je IP protokol poskytující podporu pro přenos dat v reálném čase jako jsou video a audio streamy. Služby poskytované RTP zahrnují rekonstrukci času, detekci ztrát, identifikaci obsahu a bezpečnosti a je primárně navržen pro multicast, avšak je vhodný i pro unicast. Je vhodný jak pro jednosměrný přenos jako např. video-on-demand tak pro interaktivní služby jako např. internetovou telefonii. RTP spolupracuje s RTCP řídícím protokolem pro získání informací zpět o kvalitě přenosu a o účastnících přenosu.

Jak RTP pracuje?

Jak již bylo řečeno Internet je sdílená síť, kde se pakety přenáší s nepředvídatelným zpožděním a jitter (nerovnoměrnosti toku dat). RTP proto poskytuje timestamping (časové značky), sequence numbering (číslování sekvnecí) a další mechanismy k tomu aby bylo možné znovu sestavit přenášený signál.

Timestamping je velice důležitý a slouží k znovusestavení časové posloupnosti na straně přijímače, případně k synchronizaci několika datových toků jako např. audio a video streamu.Vysílač začne číslovaní v prvním zaslaném paketu a pak číslo sekvenčně zvyšuje např. každý video snímek.

Sequence numbering slouží k opětovnému seřazení paketů, protože UDP nezaručuje jejich doručení v pořadí jak byli vyslány. Samotný timestamping k tomu nestačí, protože jedno okénko videa může být odvysíláno v několika rámcích se stejnou časovou značkou.

Payload type identifier určuje formát přenášených dat např. PCM, MPEG1/MPEG2 audi a video, H.261 a slouží pro přijímač k identifikaci typu přenášených dat. Tato informace je přenášena v každém paketu, protože druh kódování se v průběhu přenosu může měnit v závislosti na požadavku přijímačů nebo možností sítě.

Source identification slouží k identifikaci odkud pocházejí data a může např. v audio konferencích určovat kdo právě mluví.

Tyto informace jsou součástí RTP hlavičky. Způsob jejího umístění je zobrazen na Obrázku 2.2.

Obrázek 2.2: Umístění RTP hlavičky

RTP se přenáší pomocí UDP a využívá jeho vlastnosti jako např. kontrolní součty. UDP sice nabízí nespojovanou datagramovou službu bez záruky doručení paketu na rozdíl od spojovaného TCP, který zaručuje doručení paketů. Byl ale vybrán UDP, protože jednak RTP je primárně navrženo pro multicast a dále přenos v reálném čase nepotřebuje spolehlivost spojení tak nutně jako včasné doručení dat. Data pokud nedojdou včas jsou již nepotřebná a aplikace s mírnou ztrátovostí může běžet v rozumné kvalitě. Opakované znovuvyslání ztracených paketů zatěžují zbytečně síť a mohou při překročení vyhrazené šířky pásma vyvolat další ztráty paketů a postupné zahlcení sítě a příp. přerušení spojení.

V praxi je RTP obvykle implementováno v aplikaci, protože většinu problémů jako zotavení ze ztráty paketu, řízení zatížení musí být implementovány až na aplikační úrovni. K sestavení RTP spojení definuje aplikace jednotlivě pár cílových adres (jedna adresa síťová a pár portů, jeden pro RTP a jeden pro RTCP). V multimediálních spojeních je obvykle přenášeno každé medium v separátním RTP spojení se svým vlastním RTCP kanálem. Takto je např. možné vysílat zvlášť audio kanál a dva video kanály v různé kvalitě a přijímač se pak rozhodne ke kterému spojení se přihlásí

Vlastnosti RTP

• Zajišťuje spojeni mezi koncovými body pro realtime data.

• Neposkytuje žádný mechanismus, který zaručí doručení dat a jejich doručení včas a pro tohle potřebuje podporu nižších vrstev.

• Neví o síti pod sebou víc než že přenáší data v rámcích - je tedy možné jej implementovat i na další protokoly jako ATM a IPv6.

• Poskytuje časová razítka a číslování, pro sestavení dat.

• RTP/RTCP poskytuje mechanismu zjišťování a řízení parametrů spojení na základě informací z vysílačů a přijímačů.

• Je pouze rámcem, který slouží pro implementace jednotlivých aplikací a je otevřený pro nové formáty dat.

2.3.3 RTCP - Real-Time Control Protocol

RTCP je řídící protokol určený pro spolupráci s protokolem RTP aby přenášel mezi účastníky spojení informace o jeho kvalitě. Je standardizován v RFC 1189 a RFC 1890. RFC 1889 definuje tyto typy RTCP paketů: