Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO

FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO Garant předmětu: Ing. Petr Číka, Ph.D. Autoři textu: Ing. Petr Číka, Ph.D. BRNO 2014 Vznik těchto skript byl podpořen projektem č. CZ.1.07/2.2.00/28.0062 Evropského sociálního fondu a státním rozpočtem České republiky.

Autor Ing. Petr Číka, Ph.D. Název Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO Vydavatel Vysoké učení technické v Brně Fakulta elektrotechniky a komunikačních technologií Ústav telekomunikací Technická 12, 616 00 Brno Vydání první Rok vydání 2014 Náklad elektronicky ISBN 978-80-214-5061-5 Tato publikace neprošla redakční ani jazykovou úpravou

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 3 Obsah 1 Úvod 5 2 Protokoly pro distribuci multimediálních dat v síti Internet 6 2.1 Teoretický úvod................................. 6 2.2 Laboratorní úloha Analýza multimediálních protokolů pomocí programu Wireshark.................................... 18 2.2.1 Cíle úlohy................................ 18 2.2.2 Zadání.................................. 18 2.2.3 Pokyny k vypracování......................... 18 2.3 Laboratorní úloha IP televize, streamování, video na vyžádání, protokoly RTP, RTCP, SDP, RTSP, SAP......................... 21 2.3.1 Cíl úlohy................................. 21 2.3.2 Zadání.................................. 21 2.3.3 Pokyny k vypracování......................... 21 3 Videokonference a standard H.323 25 3.1 Teoretický úvod................................. 25 3.2 Laboratorní úloha Videokonference..................... 38 3.2.1 Cíl úlohy................................. 38 3.2.2 Zadání.................................. 38 3.2.3 Pokyny k vypracování......................... 38 4 Internetová/video telefonie, protokol SIP 44 4.1 Teoretický úvod................................. 44 4.2 Laboratorní úloha Konfigurace softwarových VoIP telefonů........ 52 4.2.1 Cíl úlohy................................. 52 4.2.2 Zadání.................................. 52 4.2.3 Pokyny k vypracování......................... 52 4.3 Laboratorní úloha Konfigurace hardwarových VoIP telefonů....... 59

4 FEKT Vysokého učení technického v Brně 4.3.1 Cíl úlohy................................. 59 4.3.2 Zadání.................................. 59 4.3.3 Pokyny k vypracování......................... 59 4.4 Laboratorní úloha VoIP pobočková ústředna Asterisk a její možnosti.. 66 4.4.1 Cíl úlohy................................. 66 4.4.2 Zadání.................................. 66 4.4.3 Pokyny k vypracování......................... 67 5 Standardy pro kompresi obrazu a videa 72 5.1 Teoretický úvod................................. 72 5.2 Laboratorní úloha komprese statických obrazů a videosekvencí, JPEG, MPEG, H.26x.................................. 81 5.2.1 Cíl úlohy................................. 81 5.2.2 Zadání.................................. 81 5.2.3 Pokyny k vypracování......................... 81

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 5 1 ÚVOD Tato skripta byla vytvořena pro výuku laboratorních cvičení předmětu Multimediální služby vyučovaného v bakalářském studijním oboru Teleinformatika Fakulty elektrotechniky a komunikačních technologií Vysokého učení technického v Brně. Skripta obsahují teoretické základy k jednotlivým laboratorním úlohám, jejich zadání a pokyny k vypracování. Jsou rozdělena do pěti kapitol věnujících se protokolům využívaných při distribuci multimediálních dat, video telefonii a videokonferencím, internetové telefonii, kompresí digitálních statických obrazů a videosekvencí.

6 FEKT Vysokého učení technického v Brně 2 PROTOKOLY PRO DISTRIBUCI MULTIMEDIÁLNÍCH DAT V SÍTI INTERNET 2.1 Teoretický úvod Při distribuci multimediálních dat v síti Internet se v současné době používá řada technik, avšak pouze hrstka z nich je standardizovaných. V této kapitole se budeme zabývat pouze standardními protokoly, které jsou využívány pro distribuci multimediálního obsah. Jedná se o protokoly RTP, RTCP, SDP, RTCP, SAP.

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 7 Protokol RTP (Real time Transport Protocol) RTP (Real-time Transport Protocol) je protokol aplikační vrstvy TCP/IP modelu definovaný v RFC 3550 [15]. Využívá se pro přenos multimediálních dat v datových sítích, v současné době po Internetu. Je nezávislý na protokolech nižší vrstvy, nejčastěji využívá protokol UDP (User Datagram Protocol). Hlavička protokolu (obrázek 2.1) obsahuje: 1. Version (verze) (2b), 2. Padding (výplň) (1b), 3. Extension (rozšíření) (1b), 4. CSRC Count (počet přispívajících zdrojů) (4b), 5. Marker (1b), 6. Payload Type (typ zátěže) (7b), 7. Sequence Number (sekvenční číslo) (16b), 8. Timestamp (časové razítko) (32b), 9. Synchronization Source (SSRC) Identifier (Identifikátor zdroje), 10. Contributing Source (CSRC) Identifier (Identifikátor přispívajícího zdroje), 11. Payload Data (užitečná data), Údaje v hlavičce protokolu RTP popis 1. Version (verze) identifikuje verzi protokolu, RFC 3550 definuje verzi 2. 2. Padding (výplň) identifikuje stav, kdy byl doplněn určitý počet oktetů na konec užitečných dat. Tyto oktety nenesou žádnou informace. Poslední oktet výplně nese informaci o počtu přidaných oktetů. 3. Extension (rozšíření) identifikuje rozšíření hlavičky. Pokud je bit nastaven na 1, standardní hlavička paketu RTP je doplněna rozšířením. 4. CSRC Count (počet přispívajících zdrojů) indikuje počet zdrojů, které svými daty přispívají do aktuálního paketu. 5. Marker se používá k oznámení určité události, např. poslední paket přenášeného snímku, změna audio kodeku během VoIP hovoru apod. 6. Payload Type (typ zátěže) (7b) specifikuje typ užitečných dat přenášených RTP paketem. Přesná interpretace pole typ zátěže definuje profil RTP, který svazuje

8 FEKT Vysokého učení technického v Brně V 4b 4b 8b 16b P X CSRC count M Payload type Timestamp Sequence Number Synchronization source (SSRC) identifier Contributing source (CSRC) identifier Payload data Padding Obrázek 2.1: Standardní hlavička protokolu RTP čísla typů zátěže s různými datovými formáty. V profilech jsou definovány statické tabulky primárně provazující čísla zátěže s audio či video kodeky. Výchozí nastavení je specifikované v doporučení RFC 3551. Typy zátěže v rozsahu hodnot 0-95 jsou staticky definované, v rozsahu 96-127 jsou dynamicky přiřazeny při zahájení relace, většinou za pomoci protokolu SDP (Session Decribtion Protocol). 7. Sequence Number (sekvenční číslo) se používá k identifikaci paketů a k poskytnutí přehledu o doručených paketech. Přijímač díky němu detekuje pakety přijaté mimo pořadí či pakety ztracené. Sekvenční číslo s každým příchozím paketem inkrementuje o hodnotu 1. Pokud dosáhne své maximální hodnoty, nuluje se. Důsledkem malého počtu bitů dochází k nulování sekvenčního čísla velmi často. V typické VoIP aplikaci, kdy jsou posílány pakety obsahující hovorová data déky 20 milisekund, se sekvenční číslo nuluje přibližně každých 20 minut. Počáteční hodnota sekvenčního čísla je náhodná a z důvodu bezpečnosti by neměla začínat nulou. 8. Timestamp (časové razítko) označuje okamžik přehrávání prvního oktetu dat v paketu.

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 9 9. Synchronization Source (SSRC) Identifier (Identifikátor zdroje synchronizace) identifikuje zdroj vysílání RTP paketů. Jedná se o 32 bitové číslo náhodně generované zdrojem, které je využíváno po celou dobu trvání relace. 10. Contributing Source (CSRC) Identifier (Identifikátor přispívajícího zdroje) identifikuje účastníky relace v případě, že do jednoho RTP paketu přispívá více zdrojů. Každý přispívající zdroj je identifikován 32 bitovým číslem odpovídajícím SSRC účastníka. Počet CSRC záznamů je specifikován polem CSRC Count. 11. Payload Data (data) obsahuje užitečná data.

10 FEKT Vysokého učení technického v Brně Protokol RTCP (RTP Control Protocol) Protokol RTCP (RTP Control Protocol) slouží ke sledování kvality služeb v rámci RTP relací, identifikaci jednotlivých účastníku RTP relace a k odhadu velikosti RTP relace. Je definován společně s protokolem RTP v RFC 3550 [15]a používá stejně jako RTP pro přenos protokol UDP avšak s rozdílným číslem portu. Standardně je port o jedna vyšší než u RTP. Pakety RTCP jsou posílány periodicky. Typy paketů RTCP Doporučení RFC 3550 [15] definuje následující typy paketů RTCP: Sender Report (SR) Aktivní účastníci relace (vysílače) posílají pomocí zpráv SR statistické informace o přenosu. Receiver Report (RR) Pasivní účastníci relace (přijímače generují na základě SR statistiky příchozích paketů RTP. Informace o těchto statistikách nese RR. Source Description (SDES) Popisuje relaci, vždy obsahuje CNAME, může obsahovat i další údaje o relaci. Goodbye (BYE) Indikuje odchod účastníka z relace. Application specific (APP) Využívá se k testování nových funkcionalit. Výpočet zpoždění, kolísání zpoždění Při měření kvality služeb se využívají informace ze zpráv SR a RR. Pro výpočet průměrného zpoždění v přijímačích streamu RTP jsou potřeba následující informace, kde I značí skevenční číslo paketu: S(I) Časové razítko odchozího paketu RTP paketu. R(I) Čas příchodu RTP paketu. D(I) Rozdíl časů dvou po sobě odeslaných paketů přijatých přijímačem a odeslaných vysílačem.

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 11 J(I) Průměrné kolísání zpoždění příchozích RTP paketů. Zpoždění D(I) se získá pomocí vztahu D(I) = (R(I) R(I 1)) (S(I) S(I 1)). (2.1) Kolísání zpoždění se získá průběžně s každým příchozím datovým paketem pomocí vztahu J(I) = 15 16 J(I 1) + 1 D(I). (2.2) 16 Pakety SDES jsou využívány zdroji vysílání pro poskytnutí informací o nich samotných. Pakety jsou složeny z hlavičky a dalších informací, kde každá z nich začíná jednoznačným identifikátorem zdroje. Typy zpráv SDES podle RFC 3550 najdete v tabulce 2.1. HODNOTA NÁZEV POPIS 0 END Konec seznamu SDES 1 CNAME Kanonické jméno (Canonical Name): jednoznačné jméno v rámci jedné RTP relace 2 NAME Reálné jméno uživatele 3 EMAIL Emailová adresa 4 PHONE Telefonní číslo 5 LOC Geografická poloha 6 TOOL Název aplikace generující stream RTP 7 NOTE Zpráva popisující současný stav zdroje Tabulka 2.1: Informace v paketech SDES

12 FEKT Vysokého učení technického v Brně Protokol SDP (Session Describtion Protocol) Protokol SDP (Session Describtion Protocol) slouží k přenosu údajů o multimediální relaci potřebných při navazování spojení a je definován v doporučení RFC 4566 [5]. K přenosu využívá například protokoly SAP (Session Announcement Protocol), SIP (Session Initiation Protocol), RTSP (Real Time Streaming Protocol), e-mail použitím či HTTP (Hypertext Transport Protocol). Popis relace pomocí protokolu SDP obsahuje 1. název relace a její účel, 2. čas, po který je relace aktivní, 3. média obsažená v relaci, 4. informace potřebné k příjmu (adresy, porty, formáty, atd.), 5. informace o šířce pásma relace, 6. kontaktní informace na osobu zodpovědnou za relaci. Protokol SDP je složen z řádků, obsahujících položky < T Y P >=< HODNOT A >, kde T Y P je zastoupen malým písmenem definujícím popisovanou informaci a HODN OT A definuje parametry dané informace. Každý SPD popis je složen ze třech částí: 1. popis relace, 2. popis času, 3. popis médií. Soupis všech typů a hodnot je uveden v následujícím textu, kde typy označené * patří mezi typy volitelné. Veškeré textové popisy by měly splňovat standard ISO 10646 a kódování UTF8. Popis relace v= (protocol version) o= (owner/creator and session identifier). s= (session name) i=* (session information)

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 13 u=* (URI of description) e=* (email address) p=* (phone number) c=* (connection information) b=* (bandwidth information) z=* (time zone adjustments) k=* (encryption key) a=* (zero or more session attribute lines) Popis času t= (time the session is active) r=* (zero or more repeat times) Popis médií m= (media name and transport address) i=* (media title) c=* (connection information - optional if included at session-level) b=* (bandwidth information) k=* (encryption key) a=* (zero or more media attribute lines)

14 FEKT Vysokého učení technického v Brně Protokol RTSP (Real Time Streaming Protocol) Protokol RTSP (Real Time Streaming Protocol) je určen pro sestavení a řízení relace skládající se z jednoho nebo více multimediálních toků a je definovaný v doporučení RFC 2326 [16]. Jinými slovy se protokol RTSP využívá k ovládání multimediálních toků a je znám pod pojmem síťový dálkový ovladač. Adresace v RTSP Zprávy RTSP jsou využívány k odkazování se na multimediální toky. URL adresa RTSP má tvar rtsp://host:port/absolutní cesta. RTSP využívá transportní protokol TCP a port 554 a pracuje na bázi klient-server (žádost vs. odpověď). Metody využívané protokolem RTSP a jejich funkce jsou: 1. Metoda DESCRIBE slouží k vyžádání popisu prezentace či multimediálních dat identifikovaných požadovanou adresou URL. 2. Metoda OPTIONS se využívá ke získání dostupných metod určitého zařízení. 3. Metoda ANNOUNCE v případě vyslání klienta na server obsahuje popis prezentace nebo multimediálních dat identifikovaných dle požadované URL, v případě vysílání od serveru ke klientovi aktualizuje v reálném čase popis relace. 4. Metoda SETUP specifikuje, jakým způsobem budou multimediální data přenášena. 5. Metoda PLAY oznamuje serveru, aby začal přehrávat daný multimediální tok. 6. Metoda PAUSE oznamuje serveru, aby přerušil vysílání multimediálních dat. 7. Metoda TEARDOWN oznamuje serveru, aby ukončil vysílání multimediálních dat a rozvázal s klientem spojení. 8. Metoda GET_PARAMETERS požaduje získání zvoleného parametru. Pokud je metoda prázdná, testuje, zda opačná strana je či není k dispozici(obdoba operace ping). 9. Metoda SET_PARAMETERS požaduje nastavení určitých parametrů prezentaci specifikované pomocí URI. 10. Metoda REDIRECT oznamuje klientovi nutnost přesměrovat se na jiný server.

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 15 11. Metoda RECORD spouští záznam multimediálního vysílání.

16 FEKT Vysokého učení technického v Brně Protokol SAP (Session Announcement Protocol) Protokol SAP Session Announcement Protocol slouží k oznamování multicastových relací a je definován v RFC 2974 [6]. Vysílací server pravidelně odesílá informace o relacích na známou multicastovou adresu a port právě prostřednictvím protokolu SAP. Zpráva SAP nenese žádné informace o počtu zúčastněných stran v relaci, pouze oznamuje, že určitá relace existuje. Obsahuje popis relace, zpravidla protokolem SDP, a může obsahovat autentizační hlavičku. Zpráva SAP využívá vždy port 9875, životnost paketu (TTL) je zpravidla nastavena na 255. Bitová rychlost pro odesílání SAP zpráv je standardně nastavena na 4000 bit/s.

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 17 Adresace v IP sítích Dle využití existují celkem 3 typy IP adres (obrázek 2.2): Individuální (UNICAST) Datagramy jsou směrovány pouze na jednu stanici v síti. Všeobecné (BROADCAST) Využívají se pro vyslání jedné zprávy všem dosažitelným stanicím (většinou adresa 255.255.255.255 lokální všeobecné směrování). Nevýhodou tohoto vysílání je nadměrná zátěž sítě. Skupinové (MULTICAST) Data se směrují do skupiny, do které jsou připojeny pouze stanice, které mají o dané vysílání zájem. UNICAST MULTICAST Skupina BROADCAST Obrázek 2.2: UNICAST vs. MULTICAST vd. BROADCAST

18 FEKT Vysokého učení technického v Brně 2.2 Laboratorní úloha Analýza multimediálních protokolů pomocí programu Wireshark 2.2.1 Cíle úlohy Cílem laboratorní úlohy je seznámit se s volně dostupným softwarovým analyzátorem síťového provozu s názvem Wireshark a analyzovat základní síťové toky. 2.2.2 Zadání 1. Naučte se zachytit síťový provoz programem Wireshark. 2. Naučte se filtrovat zachycený síťový provoz dle různých kritérií. 3. Naučte se analyzovat zachycený a filtrovaný provoz a jednotlivé pakety na všech vrstvách TCP/IP modelu. 4. Na konkrétním případu analyzujte VoIP hovor. 2.2.3 Pokyny k vypracování Jak zachytit komunikaci na lokálním síťovém rozhraní? Spusťte zachytávání paketů a poté se připojte pomocí IE na adresu http://www.vutbr.cz. Jakmile se vám načte webová stránka, ukončete zachytávání a analyzujte výměnu paketů. Vzhledem k tomu, že na síťové kartě probíhá mnoho procesů, je vhodné provoz filtrovat. 1. Spusťte program Wireshark. 2. Zvolte Capture-Interfaces. Vyberte síťové rozhraní, které chcete analyzovat a stiskněte tlačítko Start Odstartuje se zachytávání provozu na síťovém rozhraní. 3. Pro ukončení zachytávání zvolte Capture-Stop. Jak filtrovat provoz? Síťový provoz můžete filtrovat dle mnoha kritérií. Nejčastěji filtrujeme dle protokolů nebo dle IP adresy. Základní filtry jsou přednastavené pod tlačítkem Filter, ostatní potom volíme pod tlačítkem Expression... Filtrace podle IP adresy:

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 19 1. Stiskněte tlačítko Filter. 2. Zvolte filtr podle IP adresy - IP address 192.168.0.1 3. Definujte IP adresu, kterou chcete analyzovat. 4. Stiskněte tlačítko OK. Vyzkoušejte filtraci i dle jiných kritérií. Analýza síťového provozu K analýze síťového provozu slouží funkce v záložce Statistics-Flow Graph. Zde vyberte all packets a TCP flow. Poté se vám zobrazí okno s grafem jednotlivých toků TCP. Při označení jednotlivých zpráv je označen příslušný paket v okně analyzátoru. Úkoly Nalezněte, v jaké části došlo k výměně zpráv Three-way handshake při navazování spojení s webovou stránkou http://www.vutbr.cz. V IP hlavičce zjistěte hodnoty následujících polí: TTL, protokol vyšší vrstvy, údaje o fragmentaci (bylo fragmentováno, jedná se o poslední fragment, popř. jaký je offset fragmentu). V TCP hlavičce zjistěte hodnoty následujících polí: zdrojový a cílový port, sekvenční číslo, příznaky. Analýza VoIP hovoru Stáhněte si z e-learningu soubor voip.pcap a otevřete jej ve Wiresharku. V tomto souboru je uložen síťový provoz jednoho hlasového VoIP hovoru prostřednictvím protokolu SIP. K analýze je vhodné využít záložku Telephony.

20 FEKT Vysokého učení technického v Brně Volba SIP Celkové statistiky SIP zpráv. Volba VoIP Calls Zobrazí seznam všech hovorů. Je možné zobrazení grafu signalizace, popřípadě přehrání jednotlivých RTP streamů. Volba RTP Vyberte show all streams. Zobrazí všechny RTP streamy. Důležitá je záložka Analyze, která zobrazuje podrobné statistiky vybraného streamu. Otázky Kolik hovorů bylo uskutečněno? Jaké IP adresy mezi sebou komunikovaly? Jaké transportní protokoly a jaké porty byly ke komunikaci využity? Jaký typ multimediálních dat byl přenášen? (Payload Type) Jaké bylo SSRC volajícího a volaného? Kolik paketů má nastaveno marker bit a k čemu tento bit slouží? Jak stanovit typ paketu? Wireshark umí analyzovat protokoly a přiřadit jim správný typ. Například v případě multimediálního toku přenášeného protokolem RTP Wireshark podle struktury protokolu pozná, že se jedná o RTP. V případě, že si není jist, označí jej jako protokol transportní vrstvy - v tomto případě UDP. Pokud však víte, že se jedná o data s RTP hlavičkou, můžete tuto skutečnost manuálně nastavit. To lze udělat tak, že označíte paket, který chcete dekódovat pravým tlačítkem - vyberete Decode as... a vyberete příslušný protokol.

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 21 2.3 Laboratorní úloha IP televize, streamování, video na vyžádání, protokoly RTP, RTCP, SDP, RTSP, SAP 2.3.1 Cíl úlohy Cílem cvičení je zprovoznit vysílání dat na multicastovou a unicastovou adresu, video na vyžádání. Zachytit průběh komunikace - protokol RTP (Real-time Transport protokol), RTCP (RTP Control Protokol), RTSP (Real-time Streaming Protocol), SDP (Session Describtion Protocol) SAP (Session Announcement Protocol). 2.3.2 Zadání 1. Zprovozněte vysílání na unicastovou adresu. 2. Zprovozněte vysílání na multicastovou adresu. 3. Zprovozněte službu video na vyžádání. 2.3.3 Pokyny k vypracování Instalace potřebného software 1. Stáhněte si na disk D do adresáře s Váším loginem (který si vytvoříte) aktuální verzi VLC přehrávače z adresy (http://www.videolan.org). 2. Do téhož adresáře si stáhněte demonstrační video z e-learningu. 3. Spusťte virtuální prostřední VMware Player Pracovat budete ve virtuálním prostředí s názvem W7 - editujte jej. 4. Nastavte sdílení disku do virtuálního prostředí. Zvolte Edit virtual machine settings- Options-Shared Folders. Zvolte Always enabled, přidejte disk D a zaškrtněte Map as network drive in Windows guests. 5. Spusťte virtuální prostředí a v případě, že se Vás program zeptá, zda jste přesunuli nebo kopírovali toto prostředí, zvolte, že jste ho zkopírovali. 6. Do virtuálního prostředí nainstalujte stažený software VLC (VideoLAN).

22 FEKT Vysokého učení technického v Brně 7. Zjistěte si IPv4 adresu Vašeho virtuálního prostředí a zapište si ji (například příkazem ipconfig v příkazovém řádku). Adresa bude mít tvar 192.168.1.x 8. Rozdělte se do dvojic. 9. Pro zajištění 100procentní funkcionality nebo v případě nefunkčnosti jakékoli služby restartujte po každé úloze aplikaci VLC. Vysílání multimediálních dat na UNICASTOVOU adresu První z dvojice 1. Spusťte přehrávač VLC seznamte s jeho základními funkcemi. 2. Zprovozněte vysílání na UNICASTOVOU adresu (vysílání na kolegův PC nikdo jiný toto vysílání nemůže přijmout): V záložce Média-Proud... vyberete zdroj pro vysílání vyberte jeden ze stažených video souborů dostupný na disku. Následně zvolte Pustit proudem a nastavte parametry přenosu: Nový cíl - RTP / MPEG Transport Stream - Přidat. Zadejte UNICASTOVOU IP adresu druhého PC + port (zvolte libovolný z dynamického rozsahu). Deaktivujte překódování. Stiskněte tlačítko Stream. Druhý z dvojice Spusťte přehrávač VLC seznamte s jeho základní funkcionalitou. Otevřete stream, který Vám kolega poslal. Média Otevřít síťový proud zadejte adresu pro příjem toku rtp rtp://vašeipadresa:port.

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 23 Nyní si vyměňte role a vysílejte z druhého počítače. Přenášený tok zachyťte ve Wiresharku a analyzujte data na síťové, transportní a aplikační vrstvě. Vysílání na MULTICASTOVOU adresu Stejným způsobem, jakým jste zprovoznili vysílání na UNICASTovou adresu lze zprovoznit i vysílání na adresu MULTICASTovou. Zopakujte si, jaký je rozsah multicastových adres a následně každý vyšlete jedno z videí na multicastovou adresu. Sdělte ostatním adresu vysílání a port. Vyzkoušejte připojit více uživatelů k jedné skupině. Zopakujte si, jak se chová multicastové vysílání a zopakujte si jeho výhody a nevýhody. Protokol SAP Session Announcement Protocol Nyní si vyzkoušíte posílání zpráv oznamujících multicastové vysílání. Ty jsou potřebné v lokálních sítích proto, aby si každý uživatel nemusel pamatovat cesty k jednotlivým vysílaným streamům. Software VLC podporuje v rámci multicastového přenosu i vysílání SAP zpráv. SAP zprávy se vysílají na smluvenou multicastovou adresu a známý port. Při vytváření multimediálního streamu viz předchozí odstavce lze u každého vysílaného obsahu zadat jeho název (Název proudu). Zadejte tedy název vysílaného obsahu a pusťte streamování. V případě, že budete vysílat více videí, bude vysílána ke každému videu jedna SAP zpráva. Na klientské straně zobrazte Seznam skladeb a zvolte Síťové proudy. Zde byste měli SAP zprávy zachytávat. Spusťte program Wireshark, kde zachyťte veškeré posílané SAP zprávy. Na jaké adrese a jaké informace jsou v SAP zprávě obsaženy? Jaký transportní protokol a port SAP zprávy využívají? Video na vyžádání (VoD Video on Demand) Video na vyžádání je takové video, kdy klient ovládá své video na vzdáleném serveru a má ho kdykoli k dispozici. Přenos ze serveru na klientskou stanicí probíhá buď přes unicastovou nebo přes multicastovou adresu. V našem případě budeme využívat unicastovou adresu. Ke vzdálenému ovládání multimediálních dat slouží protokol RTSP (Real-time Streaming Protocol).

24 FEKT Vysokého učení technického v Brně Vytvořte spojení definované obrázkem 2.3. Uživatel Koncové zařízení Webový prohlížeč HTTP žádost, odpověď, soubor popisu Webový server Soubor popisu Prohlížeč multimediálního obsahu Audio/video data Streamovací server Obrázek 2.3: Video na vyžádání - obecné schéma V případě programu VLC pod systémem Windows je nejvhodnější pracovat v záložce Nástroje-Nastavení VLM. Ve správci médií vyberte Video on Demand (VoD). Zde nastavujete pouze název a vstupní soubor. Na klientské straně se k danému vysílání přihlásíte tak, že otevřete adresu rtsp://adresa_serveru:standardní_port_pro_rtsp/název_vysílání. Spusťte vysílání. Spusťte program Wireshark a zaznamenejte, jaké zprávy se během řízení multimediálního streamu posílají. Zjistěte, jaká adresa je pro audio signál a jaká pro video, na jaké adrese můžete tyto toky řídit, jaký kodek je použit pro audio a video, atd. Zkontrolujte, zda vše odpovídá teorii. Jaký protokol se používá s protokolem RTSP pro popis médií?

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 25 3 VIDEOKONFERENCE A STANDARD H.323 3.1 Teoretický úvod Videokonference jsou v současné době používány jako moderní nástroj při komunikaci. Pod pojmem videokonference si můžeme představit klasický video hovor bod, bod, ale také vícebodové hovory, kdy je spojeno 3 a více účastníků. Standard H.323 Standard H.323 definuje možnosti multimediálních komunikací v rámci sítě Internet. Je široce rozšířený zejména u videokonferenčních spojení. Byl standardizován společností ITU-T již v roce 1996, současně (datováno k roku 2014) je využívána 7. verze tohoto standardu. Standard H.323 popisuje infrastrukturu audio-vizuálních služeb v paketově orientovaných sítích, které nemohou zajistit garantovanou kvalitu služeb. Definuje prvky sítě a protokoly, které lze v rámci komunikace použít. Základní protokoly, které standard H.323 definuje, jsou na obrázku 3.1. Prvky sítě H.323 Standard H.323 definuje 4 základní prvky sítě: 1. terminál (Terminal), 2. brána (Gateway), 3. gatekeeper (Gatekeeper), 4. vícebodová řídící jednotka (Multipoint Controller Unit). Terminál Terminál slouží k obousměrné komunikaci v reálném čase. Terminál H.323 může být osobní počítač nebo samostatné hardwarové zařízení. Podporuje vždy hlasovou komunikaci, volitelně může podporovat video i datovou komunikaci. Terminál je jedinou povinnou součástí architektury H.323. Terminály se dělí na:

26 FEKT Vysokého učení technického v Brně Audio data Video data Řídící data koncové stanice Specifikováno v H.323 Kodeky G.7xx Kodeky H.26x Hovorová signalizace H.225.0 RAS signalizace H.225.0 Signalizace pro řízení médií RTP/RTCP Transportní vrstva TCP/UDP Obrázek 3.1: Základní protokoly definované standardem H.323 1. softwarové H.323 terminály (obrázek 3.2), 2. hardwarové H.323 terminály stolní (obrázek 3.3), 3. hardwarové H.323 terminály do jednacích místností (obrázek 3.4), 4. hardwarové H.323 terminály teleprezence (obrázek 3.5),

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 27 Obrázek 3.2: Softwarový terminál Obrázek 3.3: Hardwarový terminál stolní

28 FEKT Vysokého učení technického v Brně Obrázek 3.4: Hardwarový terminál jednací místnost Obrázek 3.5: Hardwarový terminál teleprezenční místnost

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 29 Komponenty terminálu a jejich vztahy jsou zobrazeny na obrázku 3.6. Definováno v H.323 Zdroj videa Zdroj audia Kodeky videa H.261, H.263, H.264 Kodeky audia G.711, G.722, G.723, G.728, G.729 Zpoždění Zdroj aplikačních dat T.120,... Řízení systému Vrstva H.225.0 Síťové rozhraní Řízení H.245 Uživatelské rozhraní řízení systému Řízení hovoru H.225.0 Řízení RAS H.225.0 Obrázek 3.6: Obecný terminál H.323 Identifikace terminálů v síti H.323 : Sada číslic dle doporučení E.164 založeno na standardu ITU-T E.164, který popisuje číslovací plán pro mezinárodní telekomunikační síť. Maximální doporučený počet číslic je 14. H.323 ID textový alias, například konferencnimistnost. H323ID je použitelné pouze lokálně v rámci jednoho gatekeeperu. URL ID formát h323:uzivatel@nazevhostitele, například h323:cika@gk. vutbr.cz. Tento formát je vhodný například pro webově založené vytáčení. MobileUIM se využívá v bezdrátových sítích (blíže popsáno v ITU-T H.246). E-mail ID identifikuje terminál pomocí e-mailové adresy. Transportní adresa identifikuje terminál prostřednictvím adresy daného zařízení.

30 FEKT Vysokého učení technického v Brně Brána Brána v síti H.323 poskytuje propojení s ostatními komunikačními sítěmi sítěmi, například s analogovou telefonní sítí PSTN (Public Switched Telephone Network), SIP sítí, mobilními sítěmi apod. Vzájemné propojení je zajištěno překladem signalizačních protokolů, přeformátováním a překódováním médií a informací mezi sítěmi připojenými k bráně. Brána není využívána při propojení dvou či více terminálů H.323 v rámci sítě H.323. Gatekeeper Gatekeeper poskytuje služby pro správu a řízení hovorů. Gatekeeper je stejně jako brána a MCU volitelnou součástí H.323. Pokud je však zapojen v síti, potom musí všechny koncové body využít jeho služby. Oblast, kterou pokrývá jeden gatekeeper se nazývá ZÓNA. V případě výskytu více gatekeeperů existuje více zón. Komunikaci mezi zónami zajišťuje gatekeeper. V případě, že je v síti gatekeeper implementován, stará se o: Překlad adres Překládá aliasy na IP adresy. Řízení přístupu Řídí přístup koncových bodů do sítě H.323. K tomu používá zprávy RAS, Admission Request (ARQ), Confirm (ACF) a Reject (ARJ). Řízení šířky pásma Poskytuje podporu k řízení šířky pásma používáním zpráv Bandwith Request (BRQ), Confirm (BCF) a Reject (BRJ). Například pokud má síťový manažer daný možný počet současných spojení v síti H.323, potom gatekeeper zamítne jakékoli další spojení přesahující tento počet. Management zóny Poskytuje management pro registrované terminály, brány a jednotky MCU. Volitelné funkce gatekeeperu: Signalizace hovorů Gatekeeper může směrovat signalizaci hovorů mezi koncovými body H.323. V konferenci typu bod-bod může gatekeeper spravovat hovorovou signalizaci H.225, nebo může být tato signalizace směrována přímo mezi terminály. Autorizace hovorů Gatekeeper může povolit nebo zamítnout jakýkoli hovor. Rozhodnutí pro zamítnutí může být z důvodu přístupových práv nebo časové nedostupnosti k určitému terminálu nebo bráně. Management hovorů Gatekeeper smí udržovat informace o všech aktivních

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 31 hovorech. Jednotka MCU MCU (Multipoint Controller Unit) jednotka umožní přijímat a přeposílat veškeré multimediální toky od účastníků ve vícebodových konferencích. Je složená ze dvou částí: 1. Multipoint Controller (MC) je obsažena vždy pouze jednou. 2. Multipoint Processor (MP) může být obsažen více než jednou. Multipoint Controller řídí aktivní konferenci, stará se o signalizaci a výměnu zpráv s koncovými body a řídí veškeré zdroje pro hlas a video. MC nezpracovává žádné multimediální streamy. Multipoint Processor pracuje se všemi multimediálními streamy. Klasická jednotka MCU obsahuje jeden MP na zpracování hlasových signálů a jeden MP pro zpracování video signálů. MP generuje odchozí streamy a posílá je zpět k účastníkům konference. Při komunikaci 3 a více terminálů se používá MCU jednotka, ve které se vytvoří virtuální konferenční místnost. Ta se nastavuje dle svého chování do módů: 1. Voice-Activated V módu Voice-activated je jednotkou MCU posílán obraz právě hovořícího uživatele. Toho specifikuje podle hladiny hluku (podle toho, kdo právě hovoří). Výjimkou je hovořící uživatel (aktivní), ten dostává od jednotky MCU obraz předchozího hovořícího uživatele. Tato výjimka je dána tím, že každý koncový terminál umožňuje uživateli vidět sama sebe. 2. Continuous Presence Konference typu Continuous Presence (CP) mohou zobrazit dva i více účastníků současně. Multimediální procesor v tomto režimu upraví všechny vstupní video sekvence a rozdělí je do jednotlivých částí výsledného videa. Během tohoto procesu může být původnímu videu zmenšena přenosová rychlost nebo změněno rozlišení. Při rozdělení obrazovky záleží na jednotce MCU, jaké režimy povolí. 3. Lecture Mode V tomto módu je vždy hlavním hovořícím lektor, který je v hlavním okně. Připojení studenti jsou v módu Continuous Presence a v případě, že mluví, objeví se v postranních oknech.

32 FEKT Vysokého učení technického v Brně Signalizace v síti H.323 K signalizaci se využívají protokoly: H.225 call signaling poskytuje inicializaci spojení mezi účastníky H.225 RAS - (Registration, Admission, Status) poskytuje řízení šířky pásma, registraci a lokalizaci uživatelů. H.245 media control poskytuje mechanizmy pro dohodnutí typů kodeků a vlastností koncových bodů. Signalizace RAS H.225-RAS je protokol používaný mezi koncovými body (terminál, brána) a gatekeeperem. RAS je používán k registraci, ke kontrole přístupu, kontrole šířky pásma, zjištění stavu a k rozvázaní komunikace mezi koncovými body a gatekeeperem. Tento signalizační kanál je otevřen mezi koncovým bodem a gatekeeperem ještě před otevřením ostatních kanálů a využívá nespolehlivého přenosového protokolu UDP, portu 1718. H.225 RAS umožňuje: nalezení gatekeeperu, registraci koncového bodu, lokalizaci koncového bodu, zajištění přístupu, informace o stavu, informace o šířce pásma. Nalezení gatekeeperu je manuální nebo automatický proces koncových bodů používaný k nalezení gatekeeperu. V manuální metodě koncové body konfigurují IP adresu gatekeeperu. Registrace může být okamžitá, avšak pouze k předem definovanému gatekeeperu. K registraci je používán protokol UDP a port 1719. U automatické metody dochází k tomu, že koncový bod se připojí do multicastové skupiny na adresu 224.0.1.41 na port 1718 a naslouchá, zda se v síti vyskytuje nějaký gatekeeper. Pokud ano, přihlásí se k němu. K tomu jsou využívány zprávy: Gatekeeper Request (GRQ) Zpráva posílaná na multicastovou adresu pro nalezení gatekeeperu.

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 33 Gatekeeper Confirm (GCF) Odpověď na zprávu GRQ nesoucí adresu gatekeeperu. Gatekeepe Reject (GRJ) Odpověď informující koncový bod, že gatekeeper neakceptuje jeho požadavek k registraci. Registrace koncového bodu je proces umožňující připojení koncového bodu k zóně a k informování gatekeeperu o jeho IP adrese a aliasu. K tomu je možné využít celkem 6 zpráv: Registration Request (RRQ) Registration Confirm (RCF) Registration Reject (RRJ) Unregistred Request (URQ) Unregistred Confirm (UCF) Unregistred Reject (URJ) Funkce lokalizace koncového bodu je využívána koncovými body a gatekeepery ke zjískání kontaktních informací. Lokalizační zpráva je poslána ke gatekeeperu nebo na multicastovou adresu. Gatekeeper odpovídá kontaktem na užvatele dle jeho databáze. Pro lokalizaci může být využito třech zpráv: Location Request (LRQ) zpráva posílána ke gatekeeperu pro získaní kontaktních informací pro jeden nebo více aliasů. Location Confirm (LCF) zpráva posílána gatekeeperem potvrzující LRQ, obsahuje adresu koncového bodu. Location Reject (LRJ) zpráva posílána gatekeeperem zamítající LRQ, zpravidla v případě, když požadovaný koncový bod není u gatekeeperu registrován. Zajištění přístupu poskytuje základní řízení přístupu a informaci o řízení šířky pásma. Gatekeeper autorizuje přístup do sítě H.323 potvrzením nebo zamítnutím žádosti o přístup. Žádost o přístup obsahuje požadovanou šířku, kterou může gatekeeper v odpovědi redukovat. Při zajištění přístupu mohou být využity následující zprávy: Admission Request (ARQ) zpráva posílána koncovým bodem ke gatekeeperu

34 FEKT Vysokého učení technického v Brně při zahájení hovoru. Admission Confirm (ACF) zpráva posílána gatekeeperem při povolení hovoru. Admission Reject (ARJ) zpráva posílána gatekeeperem při zamítnutí hovoru. Informace o stavu slouží k monitorování stavu uživatele (Online, offline,...). Zpráva je typicky posílána každých 10 sekund. K monitorování stavu je využívání následujících zpráv: Information Request (IRQ) zprávu posílá gatekeeper ke koncovému bodu pro vyžádání stavu. Information Request Response (IRR) zpráva posílána koncovými body ke gatekeeperu jako odpověď na IRQ. V případě, že to gatekeeper požaduje, je tato zpráva posílána koncovými body periodicky. Status Enquiry zpráva posílána pro získání stavu probíhajícího hovoru. Typicky ji posílá gatekeeper k ověření, zda je hovor ještě aktivní. Informace o šířce pásma je v využívána při posílání zpráv ARQ/ACF/ARJ. Šířka pásma může být měněna i v průběhu hovoru. Využívá následující zprávy: Bandwith Request (BRQ) zpráva posílána koncovými body ke gatekeeperu při požadavku zvýšení nebo snížení šířky pásma dané relace. Bandwith Confirm (BCF) zpráva posílána gatekeeperem potvrzující BRQ. Bandwith Reject (BRJ) zpráva posílána gatekeeperem zamítající BRQ. Hovorová signalizace H.225 Hovorová signalizace H.225 je užívaná pro inicializaci a ukončení spojení dvou koncových bodů H.323. Hovorová signalizace zahrnuje výměnu zpráv H.225 přenášených přes TCP. Zprávy H.225 jsou posílány mezi koncovými body i v případě, že v síti není žádný gatekeeper. Pokud gatekeeper existuje, jsou tyto zprávy přenášeny buď přímo mezi koncovými body, nebo jsou směrovány přes gatekeeper. Signalizace H.225 využívá protokol transportní vrstvy TCP a port 1720.

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 35 Běžně užívané signalizační zprávy H.225 Zpráva Setup je používána k inicializaci hovoru. Před samotným vysláním této zprávy musí být navázáno spojení TCP. Během zpracování zprávy Setup může být během stanoveného časového intervalu hovor ukončen. Nejdůležitější informace přenášená v této zprávě je informace o typu spojení (audio, audio+video,...). Volitelně může být uvedené číslo volaného ve formátu E.164. Zpráva Call Proceeding je volitelná zpráva vysílána volanou stranou, která indikuje, že volaná strana zpracovává hovor. Zpráva Alerting je volitelná zpráva, která potvrzuje, že žádost o sestavení hovoru je na volané straně indikována (zvuková nebo grafická signalizace). Zpráva Setup ACK je potvrzovací zpráva na zprávu Setup vysílaná volanou stranou k volající straně. Zpráva Connect je vysílaná volajícím k volanému a indikuje zahájení hovoru. Od této chvíle je v případě placeného hovoru hovor účtován. Zpráva Notify umožňuje koncovým bodům výměnu informací během hovoru. Zpráva Release Complete je vyslána jak volajícím, tak i volaným, a to při požadavku na ukončení hovoru. Směrování hovorové signalizace může být zajištěno dvěma způsoby: Přímá signalizace koncových bodů zprávy hovorové signalizace jsou posílány přímo mezi dvěma koncovými body. Signalizace řízená gatekeeperem veškeré zprávy hovorové signalizace jsou posílány přes gatekeeper. Řídicí signalizace H.245 Řídící signalizace poskytuje mechanizmus pro dohodnutí typů přenášených médií a vytvoření přenosových kanálů pro RTP. Díky zprávám H.245 si koncové body mohou vyměnit informace o používaných kodecích a o jejich schopnostech. Signalizační zprávy H.245 jsou přenášeny po sestavení hovoru protokolem H.225 a používají transportní protokol TCP.

36 FEKT Vysokého učení technického v Brně Běžně užívané signalizační zprávy H.225 Zpráva Terminal Capability Set (TCS) obsahuje informace o schopnostech vysílací strany: Seznam podporovaných audio a video kodeků s jejich parametry, způsob jejich paketizace a Payload Type pro RTP. Podporovaný typ DTMF (Dual-tone multi-frequency). Informace, zda je podporován fax T.38, signalizace DTMF podle RFC 2833 a řízení vzdálené kamery (FECC - Far-End Camera Control). Zpráva Simultaneous Capability Set je volitelnou zprávou nesoucí informaci, které kodeky mohou pracovat v jeden okamžik (společně). Existují terminály, které nemohou současně použít některé z kodeků a to například z důvodu výkonnosti procesoru apod. Zpráva User Input Indications je využívána pro přenos číslic ke vzdálenému koncovému bodu (například DTMF). Zpráva Master-Slave Determination (MSD) stanovuje, který z koncových bodů bude řídit relaci. Koncové stanice si vymění zprávy MSD s náhodně vygenerovaným číslem v položce Terminal Type. Koncový bod s nejvyšším číslem se stane master, ostatní získají status slave. V případě, že je v síti použita jednotka MCU, přebírá status master ona. Zpráva Open Logical Channel (OLC) slouží k otevření logického kanálu pro přenos dat mezi koncovými body. OLC je posílána po dohodnutí parametrů pomocí zpráv MSD. Otevřený kanál je vždy pouze jednosměrný. Logický kanál je vytvořený po zaslání zprávy OLC ACK od volajícího k volanému a je určený pro přenos multimediálních dat. Zpráva Open Logical Channel Acknowledgment (OLC ACK) je posílána jako

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 37 potvrzení na zprávu OLC a potvrzuje otevření logického kanálu. Zpráva Close Logical Channel (CLC) zavírá logický kanál při ukončení spojení. Zpráva Close Logical Channel Acknowledgment (CLC ACK) potvrzuje uzavření logického kanálu při ukončení spojení. Zpráva End Session Command indikuje konec relace H.245. Po odeslání této zprávy koncový bod přestává vysílat. Tato zpráva nemá žádné potvrzení.

38 FEKT Vysokého učení technického v Brně 3.2 Laboratorní úloha Videokonference 3.2.1 Cíl úlohy Cílem laboratorní úlohy je zprovoznit dvoubodovou a vícebodovou videokonferenci, zachytit a prostudovat signalizaci H.323, seznámit se s videokonferenčním systémem AVAYA- RADVISION, jeho komponentami, administrací uživatelů, konfigurací klientů a dalšími funkčními částmi systému. Seznámit se s hardwarovými terminály AVAYA-RADVISION pasivními softwarovými terminály RADVISON a aktivními softwarovými terminály Life- Size. 3.2.2 Zadání 1. Nastavte videokonferenční systém. 2. Nastavte HW i SW terminály pro videokonference. 3. Zprovozněte dvoubodovou videokonferenci a analyzujte protokoly H.323. 4. Zprovozněte vícebodovou videokonferenci a vyzkoušejte si funkce moderování. 3.2.3 Pokyny k vypracování Videokonferenční systém, který budete v laboratoři používat, se skládá z MCU jednotky SCOPIA Elite 5110 (viz Scopia_Elite.pdf), Gatekeeperu ECS (viz Gatekeeper ECS.pdf), řídícího softwaru Scopia Management (viz Scopia_Management.pdf), softwarových terminálů Scopia Desktop (viz Scopia_Desktop.pdf) a SW a HW terminálů. Vše konfigurujte pomocí Internet Exploreru!!! Pracujte ve dvojicích 1. dvojice: login/heslo bmds1/bmds*1234 2. dvojice: login/heslo bmds2/bmds*1234 Komponenty videokonferenčního systému jsou: Jednotka MCU (Multipoint Conferencniong Unit) Gatekeeper SCOPIA Management Administration https://147.229.144.209:8445/iview

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 39 SCOPIA Desktop Server http://147.229.144.209 Scopia Management Administration V této části laboratorní úlohy se zběžně seznamte s managementem systému. Přihlaste se do SCOPIA Management Administration a prostudujte zónu VUT ECS GK (Záložka Devices). Zjistěte, na jaké IP adrese se nachází jednotka MCU. Dále zjistěte v záložce Settings, jaké služby MCU jednotka nabízí, jejich maximální bitové rychlosti a maximální podporované rozlišení. V tomto rozhraní můžete dále sledovat síťová zatížení v průběhu konference a nastavení gatekeeperu včetně přihlášených uživatelů. Zjistěte, zda je ke gatekeeperu přihlášen nějaký koncový bod. Zopakujte si, k čemu slouží gatekeeper. V záložce Meetings můžete sledovat probíhající konference. V záložce Endpoints je seznam registrovaných terminálů. Zjistěte, které terminály jsou on-line. V laboratořích budete používat terminál VC240-1 a VC240-2. Zjistěte jejich H323 ID a číslo E164 a IP adresu. Průběh registrace H.323 terminálu ke gatekeeperu Spusťte program Wireshark a spusťte monitorování síťového provozu, spusťte analýzu síťového provozu na síťové kartě, která je připojená do veřejné sítě. Spusťte SW klienta Polycom RealPresence Desktop. Přihlášení na úvodní obrazovce přeskočte. Zaregistrujte terminál ke gatekeeperu: 1. Zvolte Settings. 2. V záložce H.323 zkontrolujte zapnutí H.323 protokolu a povolte registraci ke gatekeeperu. 3. Zadejte potřebné údaje o gatekeeperu. H.323 Alias a Extension zvolte libovolně s tím, že alias je jméno, a extension je klapka.

40 FEKT Vysokého učení technického v Brně 4. Proveďte registraci. 5. Průběh registrace je zachycen v programu Wireshark (použijte filtr na IP adresu). Zjistěte, jaké zprávy se během registrace přenáší, a vyčtěte z nich, jakým způsobem se dá registrovaného uživatele zavolat (aliasy) poznamenejte si je jsou dostupné taktéž v položce Endpoints v nastavení gatekeeperu dostupné přes Scopia Management Administration. Poorovnejte Vámi získané poznatky s obrázkem 3.7. VOLAJÍCÍ A Gatekeeper VOLANÝ B REGISTRACE TERMINÁLŮ U GATEKEEPERU RRQ, E.164 číslo = 5522 RCF RRQ, E.164 číslo =6633 RCF Obrázek 3.7: Registrace terminálu u Gatekeeperu 6. Jaký transportní protokol a jaký port je při registraci využíván? 7. Jaký protokol aplikační vrstvy je při registraci využíván? Přímé volání bez gatekeeperu 1. Vyzkoušejte s kolegou přímé volání mezi klienty bez gatekeeperu. 2. Je nutné odhlásit se z gatekeeperu volání typu point to point. 3. Pro spojení využijte IP adresu kolegy. 4. Průběh hovoru zachyťte a analyzujte. Ve Wiresharku sestavte graf signálových toků a srovnejte jej s Vašimi teoretickými znalostmi. Jakým způsobem proběhla výměna zpráv H.245, klasicky (obrázek 3.8) nebo ve zkráceném mód (obrázek 3.9)?

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 41 VOLAJÍCÍ VOLANÝ TCS (G.722, H.264) MSD TCS (G.722, H.264) MSD TCS ACK TCS ACK MSD ACK OLC G.722 OLC H.264 OLC G.722 OLC H.264 OLC ACK OLC ACK Flow Control Miscellaneous Command OLC ACK OLC ACK Audio/video RTP CLC Audio CLC ACK CLC Video CLC ACK End Session Command Obrázek 3.8: H.245 klasická výměna zpráv 5. Zjistěte, jaký byl použit kodek pro přenášené audio a video, jaký byl Payload Type (PT) v RTP. 6. Najděte, v jaké zprávě se přenáší informace, kdo bude v hovoru master a kdo slave. Podle čeho se stanoví master?

42 FEKT Vysokého učení technického v Brně VOLAJÍCÍ VOLANÝ H.225 Setup (OLC/Reverse Channel Info) Alerting Connect (OLC/Reverse Channel Info) RTP Obrázek 3.9: H.245 zkrácený mód výměny zpráv Přímé volání s gatekeeperem 1. Vyzkoušejte s kolegou přímé volání mezi klienty s gatekeeperem. 2. Je nutné přihlásit se ke gatekeeperu. 3. Pro spojení využijte registrované ID kolegy. 4. Průběh hovoru zachyťte a analyzujte. Ve Wiresharku sestavte graf signálových toků a srovnejte jej s Vašimi teoretickými znalostmi. 5. Jaké zprávy se zde objevily navíc od předešlého kroku? 6. K čemu je výměna těchto zpráv? Vícebodové konference s použitím MCU 1. Vícebodové konference jsou organizovány administrátorem videokonferenčního systému tak, že se vytvoří virtuální místnost, do které vstupují uživatelé na vyzvání. Místnost je definována technickými parametry, číslem místnost, může být zabezpečena PINem, atd. 2. Virtuální místnosti se vytváří v uživatelském portálu na adrese https://147.229. 144.209:8445. Přihlaste se na tento portál stejnými údaji jako na Scopia Management. 3. Stiskněte tlačítko Schedule. 4. Do konference můžete přizvat uživatele pomocí e-mailu, nebo můžete přímo vyvolat registrovaný terminál.

Přenos a komprese audio/video dat pro integrovanou výuku VUT a VŠB-TUO 43 5. Nastavení záložky Message: V okně Schedule a Meeting zadejte do pole To: e-maily uživatelů, které chcete do konference přizvat zadejte tedy vlastní e-maily. Do pole Subject zadejte název konference. Zadejte datum a čas zahájení konference a délku konference. V záložce Where: zvolte typ konference postupně vyzkoušejte všechny typy a srovnejte je. 6. Nastavení záložky Endpoints: Vyberte hardwarové terminály, které chcete přizvat do konference. K dispozici máte terminál VC240-1 a VC240-3. 7. Záložka Availability monitoruje vytížení MCU jednotky a přizvaných terminálů. 8. Nastavení záložky Advanced: Meeting PIN číselné heslo pro vstup do místnosti. Meeting host - automaticky se přidává Váš login. Moderator PIN číselné heslo pro přístup k moderování konference. Video Layout zde můžete nastavit počáteční rozložení obrazovky. Reserved ports zde můžete rezervovat porty na MCU jednotce v případě, že víte počet účastníků a jejich kapacitu pro připojení nechejte prázdné 9. Pro vytvoření místnosti stiskněte ikonu Send. 10. Dojde k rozeslání e-mailu všem stranám a v daný čas je konference vytvořena. Pokud byly přizvány některé hardwarové terminály, jsou automaticky vytočeny v daný čas. Příchozí hovor tedy zvedněte. 11. Připojte se do konference pomocí pasivních terminálů Scopia Desktop - postupujte dle manuálu v příchozím e-mailu. 12. Vyzkoušejte si nabízené funkce terminálů, dále si vyzkoušejte moderování konference jak z pozice pasivního klienta, tak i z pozice Managera na webovém portálu.

44 FEKT Vysokého učení technického v Brně 4 INTERNETOVÁ/VIDEO TELEFONIE, PROTO- KOL SIP 4.1 Teoretický úvod Signalizační protokol SIP (Session Initiation Protocol) zajišťuje inicializaci, změnu a ukončení interaktivní multimediální relace, popřípadě posílání krátkých zpráv (Instant Messaging). Je textově založený a velmi se podobá protokolu HTTP a SMTP (Simple Mail Transfer Protocol). V současnosti je definován v doporučení RFC 3261 (červen 2002) [13]. Prvky v SIP sítích V sítích SIP jsou definovány 4 základní síťové elementy: 1. User Agent User Agent (UA) existuje ve 2 variantách: Varianta KLIENT, User Agent Client (UAC) generuje a posílá žádosti a přijímá a zpracovává odpovědi. Varianta SERVER, User Agent Server (UAS) přijímá a zpracovává žádosti a generuje odpovědi, které posílá zpět. 2. Proxy server je mezilehlá entita, která je v sítích SIP zodpovědná za přeposílání žádostí na cílový UAS nebo odpovědi na UAC. Primární funkcí PROXY serveru v SIP sítích je tedy směrování. Mimo to může také zajišťovat autentizaci a autorizaci uživatelů. 3. Redirect server je speciální typ UAS, který generuje odpovědi třídy 3xx, které v sobě nesou adresu volaného. Jeho hlavním úkolem je tedy odeslat zpět UAC adresu, na které se volaný nachází (přesměrovat). 4. Registrar server přijímá pouze žádosti o registraci SIP REGISTER od UAC a aktualizuje podle nich lokalizační databázi koncových UA, které jsou v rámci domény spravovány. Registrar udržuje v databázi SIP URI (Uniform Resource Identifier) a IP adresy. Tato databáze se nazývá Lokační služba. Lokační služba není součástí SIPu, obsahuje tabulky s AOR (veřejná identita uživatele) a s kontaktními adresami uživatelů.