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


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.3

2.2.1

Cíle úlohy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.2

Zadání . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.3

Pokyny k vypracování . . . . . . . . . . . . . . . . . . . . . . . . . 18

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


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


4 Internetová/video telefonie, protokol SIP

44

4.1

Teoretický úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2

Laboratorní úloha – Konfigurace softwarových VoIP telefonů . . . . . . . . 52

4.3

4.2.1

Cíl úlohy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2.2

Zadání . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2.3


Laboratorní úloha – Konfigurace hardwarových VoIP telefonů . . . . . . . 59

4

FEKT Vysokého učení technického v Brně

4.4

4.3.1

Cíl úlohy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.3.2

Zadání . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.3.3


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


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



1

5

Ú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

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.


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


4b V

P X

4b CSRC count

8b M

16b

Payload type

Sequence Number

Timestamp 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.


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


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: • 𝑆(𝐼) – Časové razítko odchozího paketu RTP paketu. • 𝑅(𝐼) – Čas příchodu RTP paketu. • 𝐷(𝐼) – Rozdíl časů dvou po sobě odeslaných paketů přijatých přijímačem a odeslaných vysílačem.


11

• 𝐽(𝐼) – Průměrné kolísání zpoždění příchozích RTP paketů. Zpoždění 𝐷(𝐼) se získá pomocí vztahu 𝐷(𝐼) = (𝑅(𝐼) − 𝑅(𝐼 − 1)) − (𝑆(𝐼) − 𝑆(𝐼 − 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

𝐽(𝐼) =

1 15 𝐽(𝐼 − 1) + |𝐷(𝐼)|. 16 16

(2.2)

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

0

END

1

CNAME

POPIS Konec seznamu SDES 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

6

TOOL

Název aplikace generující stream RTP

7

NOTE

Zpráva popisující současný stav zdroje

Geografická poloha

Tabulka 2.1: Informace v paketech SDES

12


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 < 𝑇 𝑌 𝑃 >=< 𝐻𝑂𝐷𝑁 𝑂𝑇 𝐴 >, kde 𝑇 𝑌 𝑃 je zastoupen malým písmenem definujícím popisovanou informaci 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)


• 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)

13

14


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.


11. Metoda RECORD spouští záznam multimediálního vysílání.

15

16


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.


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


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:


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


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.


2.3

21

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


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 settingsOptions-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


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.


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


Vytvořte spojení definované obrázkem 2.3.

Uživatel Koncové zařízení

HTTP žádost, odpověď, soubor popisu

Webový server

Webový prohlížeč 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í?


3

25

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


Audio data

Video data

Řídící data koncové stanice

Specifikováno v H.323

Kodeky

Kodeky

G.7xx

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),


Obrázek 3.2: Softwarový terminál

Obrázek 3.3: Hardwarový terminál – stolní

27

28


Obrázek 3.4: Hardwarový terminál – jednací místnost

Obrázek 3.5: Hardwarový terminál – teleprezenční místnost


29

Komponenty terminálu a jejich vztahy jsou zobrazeny na obrázku 3.6. Definováno v H.323

Zdroj videa

Kodeky videa H.261, H.263, H.264

Zdroj audia

Kodeky audia G.711, G.722, G.723, G.728, G.729

Zdroj aplikačních dat T.120, ...

Zpoždění

Vrstva H.225.0

Síťové rozhraní

Řízení systému Ří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


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


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


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.


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


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.


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


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


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


3.2 3.2.1

Laboratorní úloha – Videokonference 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 AVAYARADVISION, 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 LifeSize.

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


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


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


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

o =663 RRQ, E.164 čísl RCF

3

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)?


VOLAJÍCÍ

41

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


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.


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


4

INTERNETOVÁ/VIDEO TELEFONIE, PROTOKOL 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ů.


45

Adresace v sítích SIP SIP adresa jednoznačně identifikuje uživatele v síti SIP a je definována prostřednictvím URI (Uniform Resource Identifier). SIP URI má tvar sip:uzivatel@domena(host):port, pole uživatel může být například jméno nebo telefonní číslo, specifikace portu je volitelná, implicitně je číslo portu nastaveno na 5060. Praktické příklady SIP URI jsou následující: • sip:[email protected], • sip:[email protected]. Další možnost je využití zabezpečeného SIPu – SIPS. Formát SIPS URI je podobný formátu SIP URI sips:uzivatel@domena(host):port. SIPS umožňuje každému zařízení zabezpečenou komunikaci se serverem s využitím SSL/TSL (Secure Socket Layer) / (Transport Layer Security). Implicitní port pro zabezpečenou komunikaci je 5061.

Signalizační zprávy SIP Signalizační zprávy SIP jsou děleny do dvou kategorií na • ŽÁDOSTI, • ODPOVĚDI, a mají následující strukturu: • startovací řádek, – pro žádosti: METODA_Požadované URI_verze SIP, – pro odpovědi: verze SIP_trojciferný kód odpovědi_textová fráze, • jeden nebo více řádků hlavičky, • prázdný řádek indikující konec hlavičky, • volitelné tělo zprávy.

46


Žádosti SIP Žádosti SIP jsou generovány klientem (UAC) a posílány na server (UAS). V doporučení RFC 3261 je definováno celkem 6 základních typů žádostí: 1. Metoda INVITE slouží k zahájení nebo modifikaci spojení. Žádost obsahuje veřejnou identitu volaného UAS. Jakmile UAS žádost přijme, generuje dočasné odpovědi, alternativně i odpovědi finální. Zpráva INVITE se může použít k výměně a dohodnutí parametrů v rámci relace. Jedná se zejména o použité kodeky (audio/video), IP adresy a porty k příjmu RTP paketů apod. K tomu se využívá protokol SDP. Zpráva INVITE se také používá pro modifikaci spojení. Říká se jí „re-INVITE“. Příkladem modifikace je například přidání videa do původní audio konference. 2. Metoda ACK potvrzuje, že UAC přijal finální odpověď na zprávu INVITE. ACK je používána pouze s žádostí INVITE. Zpráva nesoucí metodu ACK může obsahovat popis dostupných prostředků a médií iniciátora relace pouze v případě, že tyto informace nebyly přeneseny v metodě INVITE. 3. Metoda OPTIONS je používána pro dotázání se UAS na jeho schopnosti. Tím jsou získány informace o podporovaných metodách, podporovaných kodecích apod. 4. Metoda BYE slouží k ukončení probíhající relace. 5. Metoda CANCEL slouží ke zrušení nevyřízené žádosti (jako je například INVITE). Metoda CANCEL nemá vliv na předchozí metody, které již byly potvrzeny finálními odpověďmi. 6. Metoda REGISTER se využívá k registraci klientů a k identifikaci jejich současné polohy (adresy). UAC generuje žádost REGISTER, která obsahuje následující informace: • Veřejnou identitu vyjádřenou jako SIP URI. Ta je obsažena v poli To hlavičky. • Lokaci uživatele vyjádřenou jako SIP URI. Ta je obsažena v poli Contact hlavičky. Potvrzení registrace je provedeno odpovědí 200 OK. Po potvrzení je daný uživatel svázán se svou pozicí v Lokační službě. Registrace je pouze dočasná a musí být pravidelně obnovována.


47

Odpovědi SIP Odpovědi SIP indikují stav žádosti, kterou klient (UAC) poslal na server (UAS). Odpovědi SIP jsou číslovány od 100 fo 699 a jsou seskupeny do šesti kategorií 1xx, 2xx, ..., 6xx a klasifikovány jako dočasné a finální. Dočasná odpověď indikuje průběh (zpracovávání) žádosti, neindikuje však její vyřízení. Vyřízení žádosti indikuje odpověď finální.

Kategorie odpovědí • 1xx – dočasná odpověď Pokud zpráva začíná číslem jedna, je to pro agenta signál, že jeho žádost byla doručena ke druhému agentovi a ten pracuje na jejím zpracování. Zprávy 1xx nejsou konečné, což znamená, že nevypovídají nic o úspěšnosti zpracování vyslaného požadavku. • 2xx – ÚSPĚCH – finální odpověď Odpovědi začínající číslem dvě informují příjemce o tom, že jeho zpráva byla úspěšně zpracována. • 3xx – PŘESMĚROVÁNÍ – finální odpověď Tyto odpovědi posílá redirect server. Informuje tak UAC o adrese, na které se nachází požadované URI (případně požadovaná služba). Zprávu o přesměrování může posílat i UAS a to v případě, že má nastavené přesměrování hovoru. • 4xx – CHYBA NA STRANĚ KLIENTA – finální odpověď Odpovědi z této kategorie indikují, že žádost nemůže být splněna. Důvod nemožnosti zpracování žádosti je pak popsán v odeslané odpovědi. To, že se jedná o chybu na straně klienta, znamená ve většině případů, že žádost měla špatný formát (např. chybělo některé povinné pole v hlavičce apod.). V této kategorii je definováno více než třicet odpovědí. • 5xx – CHYBA NA STRANĚ SERVERU – finální odpověď Do této kategorie patří odpovědi, které značí, že žádost nemůže být zpracována z důvodu chyby na serveru. Odpověď většinou obsahuje pole Retry-After, ve kterém je zapsán časový interval, který udává, kdy je možné se opět pokusit o zaslání žádosti. • 6xx – GLOBÁLNÍ CHYBA – finální odpověď

48


Odpovědi z této skupiny může zaslat server v případě, že žádost nemůže být zpracována nikde v síti. Pokud user agent dostane takovouto odpověď, znamená to, že by neměl opakovat vysílání žádosti do té doby, než uplyne doba obsažená v poli Retry-After.

Transakce a dialog Signalizace mezi dvěma UA může být provedena jednou nebo více transakcemi. Každá transakce začíná vysláním žádosti inicializovanou UAC a končí finální odpovědí přijatou od UAS. Transakce je jednoznačně identifikován položkami Call-ID, via-branch, local tag, remote tag a CSeq. Výsledkem transakce je sestavení, modifikace nebo ukončení relace. Dialog je definován jako vztah mezi dvěma či více UA setrvávající po celou dobu relace. Dialog je jednoznačně identifikován položkami Call-ID, tag volajícího a tag volaného. Během jednoho dialogu může být vyřízeno několik transakcí. Každé transakci v rámci jednoho dialogu je inkrementována hodnota CSeq.

Rozšíření SIPu IETF definuje rozšíření základních mechanizmů v SIPu, díky kterým může být protokol SIP využíván pro zjišťování aktuálního stavu uživatele (presence), Instant Messaging (IM), a různé rozšíření při vlastním hovoru. Preference volajícího a volaného Preference UAC jsou indikovány ve zprávách INVITE nebo SUBSCRIBE přidáním řádků Accept-Contact, Reject-Contact, Request-Disposition. a detailně popsány v RFC 3841 [14]. Parametrem Request-Disposition volající specifikuje serveru, jakým způsobem by měl se zprávou zacházet. Zda jako proxy nebo redirect server. V případě proxy serveru uživatel může dále specifikovat, zda má být zpráva distribuována na všechny lokace uživatele paralelně, nebo sekvenčně. Během registrace může uživatel indikovat svoje schopnosti jako je podpora audia, videa


49

a IM. V průběhu hledání uživatele se proxy server pokouší vybrat stanici volaného podle preferencí volajícího. Příkladem je například zprává INVITE nebo SUBSCRIBE, které mohou nést v hlavičce tyto parametry: • Accept-Contact:*;video;require;explicit – indikuje, aby zpráva INVITE byla poslána na koncový bod podporující video přenos. • Accept-Contact:*;mdgserver;require;explicit – indikuje, že se uživatel chce připojit přímo do hlasové schránky volaného. • Accept-Contact:*;mobility=’mobile’ – hovor je sestaven pouze s bezdrátovým telefonem volaného. • Request-Disposition:proxy;parallel – indikuje, že by server měl žádost distribuovat na více kontaktů (forking) paralelně. • Reject-Contact:*;msgserver – indikuje, aby zpráva INVITE nebyla poslána na koncový bod, který má aktivovanou hlasovou schránku. Notifikace událostí RFC 3265 [11] popisuje rozšíření SIPu umožňující UA přihlášení k odběru oznámení jiného SIP zařízení. Příkladem síťové události je registrace nebo odregistrování se ze serveru, uložení vzkazu do hlasové schránky, změna statusu uživatele apod. Metody SUBSCRIBE a NOTIFY RFC 3265 zavádí 2 nové metody – SUBSCRIBE a NOTIFY. SIP entita se stává odběratelem oznámení jakmile pošle zprávu SUBSCRIBE pro specifický typ události. V hlavičce žádosti definuje nový řádek Event, ve kterém je uvedena třída a typ požadované události. Pole Event je pro zprávu SUBSCRIBE povinné. Příkladem jsou například Event:presence, kdy je požadavek na indikování statusu uživatele nebo například Event:reg, kdy je indikován stav registrace uživatele. UAS, který zpracovává žádost SUBSCRIBE, pracuje jako tzv. oznamovač. V případě změny stavu posílá žádosti NOTIFY zpět k odběrateli. Další novou metodou je metoda PUBLISH definovaná v RFC 3903 [9], která slouží k informování stavů uživatele.

50


Metoda REFER Metoda REFER, RFC 3515 [18], slouží k přeposlání hovoru k jinému účastníkovi. Příklad použití je následující: Lukáš volá Alešovi a rozhodne se, že by Aleš měl mluvit s Danou. Lukáš pošle instrukce k UA Alešovi pomocí zprávy s metodou REFER, díky níž Alešovu UA poskytne kontaktní informace na Danu. Aleš poté díky získaným informacím může Danu zavolat. V případě, že jeden z účastníků chce hovor přepojit k jinému, indikuje, že příjemce by měl kontaktovat třetí stranu použitím kontaktu uvedeného v žádosti. V případě, že Lukáš udělil souhlas, Aleš se pomocí získaného pokusí zavolat Daně. O stavu spojení poté informuje Lukáše. Metoda REFER může být poslána v rámci vytvořeného dialogu k zajištění přesměrování hovoru. V tomto případě je v hlavičce parametr Refer-To, který specifikuje SIP URI cílové stanice. Metoda REFER může být poslána i mimo probíhající dialog. Využití této funkce je například ve službě klikni a volej. V tomto případě uživatel klikne v online adresáři na uživatele, kterému chce volat. Aplikační server pošle na telefon uživatele zprávu REFER s adresou volané strany. Po přijetí zprávy REFER telefon volaného začne vyzvánět a poté vytvoří hovor zasláním zprávy INVITE na kontakt uvedený v hlavičce zprávy REFER v poli Refer-To. Dalším uplatněním zprávy REFER je například u konferenčních hovorů. Klient může poslat zprávu REFER k účastníkovi a požádat ho o poslání žádosti INVITE na konferenční URI. Prezence a Instant Messaging Prezence umožňuje uživatelům publikovat jejich dostupnost a zobrazovat zprávy nebo ikony u své osoby v rámci tzv. statusu. Instant Messaging (dále IM) slouží k posílání textových zpráv mezi uživateli v reálném čase. RFC 3856 popisuje rozšíření SIPu, které umožňuje sdílet informace o prezenci [12]. Pro zjištění stavu jiného uživatele může být použita metoda SUBSCRIBE. Místo přímého kontaktu uživatele se svým protějškem může být zpráva SUBSCRIBE poslána na tzv. presence server, který přijímá žádosti o zjištění stavů uživatelů a publikuje jejich stavy.


51

Prezence server je síťový server který přijímá žádosti SUBSCRIBE a na základě nich se dotazuje ostatních uživatelů na jejich aktuální stav. Uživatelé informují o změně stavu presence server zprávou NOTIFY. Pro IM byla v RFC 3428 [1] definována nová žádost MESSAGE umožňující přenos zpráv. Zpráva MESSAGE nese vlastní zprávu ve formátu MIME.

52


4.2

Laboratorní úloha – Konfigurace softwarových VoIP telefonů

4.2.1

Cíl úlohy

Seznámit se s konfigurací softwarového telefonu X-Lite, ověřit teoretické znalosti o protokolu SIP, SDP a RTP, zachytit různé SIP zprávy síťovým analyzátorem Wireshark.

4.2.2

Zadání

• Navažte dvoubodové VoIP spojení pomocí SIP URI a ověřte funkčnost služby bez použití proxy serveru. • Navažte dvoubodové VoIP spojení a ověřte funkčnost služby s použitím proxy serveru. • Zachyťte průběh spojení a ukončení spojení dvou koncových bodů (VoIP telefonů). • Přehrajte uskutečněný hovor v programu Wireshark. • Zjistěte, jaký audio kodek byl pro spojení použit.

4.2.3


Nainstalujte do virtuálního prostředí softwarový VoIP telefon X-Lite. Instalační soubory naleznete v e-learningu. Konfigurace SW telefonu X-Lite, volání bez PROXY serveru • Při spuštění programu X-Lite se Vám ve vyskakovacím okně nabídne vytvoření SIP účtu. Stiskněte tlačítko Add a vytvořte SIP účet. Pro vytvoření SIP účtu v programu X-Lite pro použití bez PROXY serveru nastavte následující hodnoty: 1. userID – zadejte čtyřmístné číslo (Vaše klapka), 2. Domain – zadejte IP adresu Vašeho PC, 3. v části Domain Proxy nechte odškrtnutý checkbox Register with domain and receive calls, 4. v záložce Advanced zaškrtněte políčko Send outgoing request directly to target, 5. v záložce Topology nastavte Range of ports used for signaling na 5060 - 5061,


53

• připojte do virtuálního prostředí VMware usb kameru kameru. Na vrchní liště zvolte Removable Device-Logitech Složené zařízení-připojit, • v programu X-lite nastavte jako mikrofon právě toto USB zařízení, • vytočte Vašeho kolegu zadejte SIP URI ve tvaru sip:username@ip-adresa:port, kde username je uživatelské jméno Vašeho kolegy, ip-adresa je IP adresa stroje Vašeho kolegy a port je port, na kterém naslouchá instalace X-Lite Vašeho kolegy. Poté stiskněte tlačítko Call. Sledování síťového provozu • Spusťte síťový analyzátor Wireshark a zapněte sledování síťového provozu. • Zaznamenejte fázi sestavení a ukončení hovoru. • V programu Wireshark vytvořte graf signálových toků a podrobně jej prostudujte srovnejte ho s teoretickým grafem signálových toků na obrázku 4.1.

Ales

Lukas

INVITE transakce

200 OK ACK

transakce dialog

relace BYE transakce

200 OK

volající

volaný

Obrázek 4.1: Základní SIP komunikace bez PROXY serveru • Specifikujte pakety, které nesou hlasová data. • Zachyťte sestavení neúspěšného hovoru – volaný hovor nepřijímá nebo volající ukončí

54


hovor ještě než volaný zvedne sluchátko. Jaká metoda SIP zprávy je v tomto případě využita? Otázky 1. Jaké zprávy musí být vyměněny pro úspěšné navázání hovoru? Jaké pro jeho ukončení? 2. Ve které metodě/ách SIP zpráv se posílají informace o schopnostech VoIP telefonů? Jaký protokol se k přenosu používá? 3. Jakou odpověď posílá klient v případě, že hovor zamítnete? 4. Jaký protokol transportní vrstvy síťového modelu TCP/IP a jaký port je standardně využíván zprávami SIP? 5. Z protokolu RTP zjistěte, jaký kodek je použit pro kódování přenášeného hlasu. 6. Pokuste se v programu Wireshark přehrát zaznamenaný hovor (Lze pouze v případě, že Wireshark zná daný kodek – například PCMU – nastavte) Testování hlasových kodeků V této části cvičení je vašim úkolem otestovat dostupné hlasové kodeky, zjistit jejich přenosové rychlosti a posoudit kvalitu přenášeného hlasu. Na typu použitého kódování se dvě stanice nejčastěji domlouvají prostřednictvím protokolu SDP. Zde platí pravidlo, že preferovaný kodek je v popisu SDP vždy uveden jako první. V programu X-Lite se na první místo vždy vloží kodek s nejvyšší kvalitou PESQ a tento fakt nelze nijak ovlivnit. Můžete však kodeky deaktivovat a nechat vždy pouze jeden na testování. To provedete v menu Softphone-Preferences-Audio Codecs a v seznamu Enabled Codecs necháte pouze jeden vybraný kodek. Poznamenejte si, jakých přenosových rychlostí jednotlivé kodeky dosahovaly a obodujte na stupnici 1-5, kdy 5 je nejvyšší skóre, jejich kvalitu. Kvalitu srovnejte s udávanou PESQ. Spuštění a nastavení REGISTRAR a PROXY serveru Nastavuje vždy jen jeden ze dvojice!!! • Stáhněte a nainstalujte JRE (Java Runtime Environment), k dispozici je v elearningu.


55

• Stáhněte a rozbalte PROXY server MjServer, dostupný v e-learningu. • Nastavení SIP serveru se provádí editací textových souborů server.cfg a aaa.db ve složce config adresáře MjServer. • V souboru server.cfg změňte: – IP adresu v poli via-addr na IP adresu Vašeho virtuálního prostředí, – pole host-port změňte např. na 5065, nebo jiný, na kterém žádná z aplikací nenaslouchá (na portu 5060 již naslouchá X-Lite). Pro výpis všech obsazených portů slouží příkaz netstat, který se zadává v příkazové řádce. Ostatní nastavení ponechte beze změny. • V souboru aaa.db (databáze uživatelů) vytvořte potřebné záznamy, abyste byli schopni na serveru zaregistrovat Vaše VoIP telefony (viz tabulka níže). Záznam Pracoviště 1

Pracoviště 2

1000/bmds

2000/bmds

1001/bmds

2001/bmds

1002/bmds

2002/bmds

1003/bmds

2003/bmds

se skládá vždy pouze z položky user a passwd. Uživatelské jméno se píše do sekce user a heslo do sekce passwd. Uživatelská jména zadávejte ve tvaru alias@IP-Adresa, kde alias je přidělené uživatelské jméno (např. 2000) a IP-adresa je IP adresa virtuáního prostředí, kde bude spuštěn MjServer. • Přejděte do adresáře MjServer a spusťte příkazový řádek (V Total Commanderu napište do řádku dole příkaz cmd). V příkazovém řádku napište příkaz proxy.bat a stiskněte Enter. • Proxy a registrar nyní běží a naslouchá na nastaveném portu a IP adrese. • Ukončit práci serveru je možné pomocí stisku kláves Ctrl+C (poté potvrďte ukončení dávkové úlohy pomocí klávesy Enter).

56


• Po ukončení práce serveru si prohlédněte logy, které se ukládají do adresáře log. • Můžete vyzkoušet změnit nastavení serveru a pozorovat změny, které nastanou. Podrobná dokumentace k jednotlivým nastavením se nachází v souboru mjsip.cfg.txt v adresáři config. Registrace softwaru X-Lite k REGISTRAR serveru • Úpravu nastavení SIP účtu můžete provést po kliknutí na Menu Softphone-Account Settings. Vyberte záložku Account. Zaškrtněte checkbox Register with domain and receive calls a z možností níže vyberte Domain. • Do polí User name a Authorization user name zadejte vaše uživatelské jméno (např. 1002) a do pole password odpovídající heslo (bmds). • Důležité upozornění: vzhledem k tomu, že server nenaslouchá na defaultním portu pro službu SIP, je nutné tento port explicitně uvést! Do pole Domain tedy napište IP adresu virtuálního prostředí PC, kde běží MjProxy server ve tvaru: IP-adresa:port, kde port je port, který jste zvolili při nastavování serveru (např. 5065). • V záložce Topology odškrtněte Range of ports used for signaling. Tím pádem bude X-Lite naslouchat na defaultním SIP portu 5060. • Pokud jste zadali všechny údaje správně, X-Lite se zaregistruje na serveru a na obrazovce se objeví vaše uživatelské jméno. • Registraci zaznamenejte v programu Wireshark a zjistěte, jaké zprávy SIP jsou během registrace mezi telefonem a proxy serverem vyměněny. Srovnejte ji s teoretickým grafem registrace s autentizací na obrázku 4.2. Konferenční hovor Tento úkol provádějte ve čtveřici!!! – během řešení si vyměňte role tak, aby všichni měli možnost tuto úlohu vyzkoušet. • Nastavuje vždy jen jeden pro všechny. • Nastavte MjServer tak, aby v databázi byly 4 různé účty (např. 1111, 2222, 3333 a 4444). • Spusťte MjServer. • Spusťte wireshark na stejném počítači, jako na kterém běží MjServer.


57

REGISTRAR SERVER

Klient

REGISTER W-Authenticate 401 Unauthorized + WW REGISTER + Authorizatio

n

200 OK

Obrázek 4.2: Registrace s autentizací • Klienty X-Lite nastavte tak, aby se zaregistrovali na MjServer. • Navažte hovor z klienta 1111 na 2222. • Po navázání hovoru zvolte na straně volajícího v rozbalovacím menu vedle ikony call Start Conference Call (původní hovoru bude On Hold). • Z linky č.2 vytočte číslo 3333 (naváže se hovor na číslo 3333, který přijměte). • Poté stiskněte v aplikaci klienta 1111 tlačítko conf. Všechny hovory budou spojeny do konference. • Ukončete všechny hovory. Vyzkoušejte různé kombinace toho, který účastník ukončuje hovor. • Ukončete zachytávání ve Wiresharku. • Analyzujte provoz. Úkoly 1. Jaké zprávy musí být vyměněny mezi klientem a serverem při procesu registrace? Jak se liší druhá zpráva, kterou posílá klient serveru od první? 2. Na základě které části zprávy server pozná, že uživatel je ten, za kterého se vydává

58


(že zná správné heslo)? 3. Jaké SSRC mají VoIP klienti? 4. Zjistěte, zda se RTP stream posílal přímo mezi klienty nebo zda byl k přenosu využit i SIP proxy server. 5. Jaké bylo průměrné a jaké maximální kolísání zpoždění, kolik procent RTP paketů bylo při přenosu ztraceno? 6. Jakou průměrnou šířku pásma VoIP hovor potřeboval. 7. Změňte používaný kodek na kodek G.711 a zjistěte, jakou šířku pásma tento kodek využívá. 8. Vypočtěte velikost užitečných dat v RTP paketu, který přenáší PCMU data, za předpokladu, že znáte počet paketů vyslaných za sekundu = 50, počet bytů v jednom vzorku PCMU = 1. Ostatní hodnoty potřebné pro výpočet najdete v SDP paketu ve zprávě SIP INVITE. Vzorec pro výpočet je

𝑣𝑒𝑙𝑖𝑘𝑜𝑠𝑡 =

𝑓𝑣𝑧 * 𝑝𝑜𝑐𝑒𝑡𝐾𝑎𝑛𝑎𝑙𝑢 * 𝑝𝑜𝑐𝑒𝑡𝐵𝑦𝑡𝑢𝑉 𝐽𝑒𝑑𝑛𝑜𝑚𝑉 𝑧𝑜𝑟𝑘𝑢 𝑝𝑜𝑐𝑒𝑡𝑃 𝑎𝑘𝑒𝑡𝑢𝑍𝑎𝑆𝑒𝑘𝑢𝑛𝑑𝑢

(4.1)


4.3

59

Laboratorní úloha – Konfigurace hardwarových VoIP telefonů

4.3.1

Cíl úlohy

Seznámit se s konfiguracemi HW telefonů Linksys, ověřit si teoretické znalosti o protokolu SIP, SDP a RTP, zachytit signalizační zprávy SIP programem Wireshark.

4.3.2

Zadání

• Nastavte HW telefony pro přímé volání bez ústředny. • Navažte mezi sebou spojení a ověřte funkčnost služby pomocí SIP URI. • Zaregistrujte telefony k ústředně. • Zjistěte, jaký je preferovaný audio kodek telefonu.

4.3.3


Instalace HW telefonů Linksys • V případě, že telefon během Vaší práce dlouho nereaguje, odpojte na 10s napájení. • Před započetím práce uveďte telefon do továrního nastavení: Setup - Factory Reset. • Konfiguraci každého VoIP telefonu je možné provádět vzdáleně přes webové rozhraní. V následujících krocích toto rozhraní budeme využívat. V internetovém prohlížeči tedy zadejte IP adresu telefonu, naleznete ji Setup - Network - Current IP. • Objeví se Vám uživatelské nastavení VoIP telefonu. Zde jsou záložky Info, System a User. Prostudujte jednotlivé záložky a jejich nastavení. • Přepněte se do Admin Login a poté do Advanced módu. To provedete v pravém horním rohu webové stránky. • Nyní zvolte záložku Ext1 (první klapka – telefon má 4). Ověřte, že tato linka je zapnutá (Line Enable). Ověřte, že signalizační port SIP je 5060 (SIP Port)

60


Nastavení telefonu pro volání bez registrace • V záložce Ext v sekci Proxy and Registration nastavte následující. Register-no, Make Call Without Reg.-yes, Ans. Call Without Reg.- yes. V případě, že chcete, aby telefon zobrazoval protistraně vaše jméno, zadejte jej do položky Subscriber Information-Display Name. • Vše potvrďte v dolní části tlačítkem Submit All Changes • Nyní můžete volat pomocí IP adresy svému kolegovi. To provedete zadáním IP adresy pomocí klávesnice. Vzhledem k tomu, že telefon je primárně nastaven na vytáčení klasických čísel, nelze zadat IP adresa. Pro zadání IP adresy je potřeba zvednout sluchátko, stisknout šipku vpravo a tlačítkem vpravo pod seznamem linek (alpha) zvolte volbu IP. Sledování síťového provozu • Spusťte síťový analyzátor Wireshark zaznamenejte síťový provoz. Nastavení telefonu pro volání přes PROXY server (ústředna) • Před registrací je nutné nastavit a spustit PROXY server – nastavte dle instrukcí v níže uvedeném odstavci s názvem Spuštění registrar a proxy serveru. • Zaregistrujte VoIP telefon k ústředně. V předchozím bodě jste si nastavili účty s hesly k proxy serveru - ty použijte. • Údaje zadejte tak, aby se telefon pomocí nich zaregistroval k ústředně. Tyto údaje se zadávají v administrátorském menu telefonu – musíte přepnout v pravém horním rohu na admin. Dostane se k němu tak, že webové rozhraní přepnete do módu admin ve kterém naleznete záložku Ext1. Podrobně prostudujte jednotlivé položky v nastavení a zadejte potřebné informace do telefonu. Důležité jsou pro Vás tyto položky: – General - Line Enable – Proxy and Registration - Register, Make Call Without Registration, Answer Call Without Registration – Subscriber Information - Display Name, User ID, Password, Use Auth ID, Auth


61

ID – Jednotlivé názvy si přeložte, zjistěte jejich význam a následně nastavte. • Po úspěšném nastavení uložte veškeré změny tlačítkem Submit All Changes. Telefon se restartuje a měl by se zaregistrovat na ústřednu. Při úspěšné registraci budou svítit led diody zeleně, na displeji bude svítit telefonní číslo (klapka), kterou jste zaregistrovali k ústředně, a vedle ní bude symbol telefonu. Pokud je symbol telefonu přepůlený, registrace neproběhla úspěšně a v některém kroku jste udělali chybu. • Po úspěšně registraci zavolejte kolegovi a analyzujte síťový provoz. Komunkaci srovnejte s teoretickým grafem signálových toků na obrázku 4.3.

TE VI IN K 0O 20 K AC

IN V PROXY server

ITE 0O K AC K

20

RTP/RTCP

Obrázek 4.3: Komunikace prostřednictvím PROXY serveru

Spuštění a nastavení REGISTRAR a PROXY serveru Nastavuje vždy jen jeden ze dvojice!!! • Stáhněte a nainstalujte JRE (Java Runtime Environment), k dispozici je v elearningu. • Stáhněte a rozbalte PROXY server MjServer, dostupný v e-learningu. • Nastavení SIP serveru se provádí editací textových souborů server.cfg a aaa.db ve složce config adresáře MjServer. • V souboru server.cfg změňte: – IP adresu v poli via-addr na IP adresu Vašeho virtuálního prostředí,

62


– pole host-port změňte např. na 5065, nebo jiný, na kterém žádná z aplikací nenaslouchá (na portu 5060 již naslouchá X-Lite). Pro výpis všech obsazených portů slouží příkaz netstat, který se zadává v příkazové řádce. Ostatní nastavení ponechte beze změny. • V souboru aaa.db (databáze uživatelů) vytvořte potřebné záznamy, abyste byli schopni na serveru zaregistrovat Vaše VoIP telefony (viz tabulka níže). Záznam Pracoviště 1

Pracoviště 2

1000/bmds

2000/bmds

1001/bmds

2001/bmds

1002/bmds

2002/bmds

1003/bmds

2003/bmds

se skládá vždy pouze z položky user a passwd. Uživatelské jméno se píše do sekce user a heslo do sekce passwd. Uživatelská jména zadávejte ve tvaru alias@IP-Adresa, kde alias je přidělené uživatelské jméno (např. 2000) a IP-adresa je IP adresa virtuáního prostředí, kde bude spuštěn MjServer. • Přejděte do adresáře MjServer a spusťte příkazový řádek (V Total Commanderu napište do řádku dole příkaz cmd). V příkazovém řádku napište příkaz proxy.bat a stiskněte Enter. • Proxy a registrar nyní běží a naslouchá na nastaveném portu a IP adrese. • Ukončit práci serveru je možné pomocí stisku kláves Ctrl+C (poté potvrďte ukončení dávkové úlohy pomocí klávesy Enter). • Po ukončení práce serveru si prohlédněte logy, které se ukládají do adresáře log. • Můžete vyzkoušet změnit nastavení serveru a pozorovat změny, které nastanou. Podrobná dokumentace k jednotlivým nastavením se nachází v souboru mjsip.cfg.txt v adresáři config.


63

Sledování síťového provozu • Zaznamenejte registraci a fázi sestavení a ukončení hovoru. • V programu Wireshark vytvořte graf signálových toků a podrobně jej prostudujte. • Zachyťte sestavení neúspěšného hovoru – volaný hovor nepřijímá nebo volající ukončí hovor ještě než volaný zvedne sluchátko. Otázky 1. Jaké zprávy musí být vyměněny pro úspěšné navázání hovoru? Jaké pro jeho ukončení? 2. Ve které metodě/ách SIP zpráv se posílají informace o schopnostech VoIP telefonů? Jaký protokol se k přenosu používá? 3. Jakou odpověď posílá klient v případě, že hovor zamítnete? 4. Jaký protokol transportní vrstvy síťového modelu TCP/IP a jaký port je standardně využíván zprávami SIP? 5. Pokuste se v programu Wireshark přehrát zaznamenaný hovor. 6. Jaké zprávy musí být vyměněny mezi klientem a serverem při procesu registrace? Jak se liší druhá zpráva, kterou posílá klient serveru od první? 7. Na základě které části zprávy server pozná, že uživatel je ten, za kterého se vydává (že zná správné heslo)? 8. Zjistěte, zda se RTP stream posílal přímo mezi klienty nebo zda byl k přenosu využit i SIP server. 9. Jaká metoda SIP zprávy použita v případě neúspěšně sestaveného hovoru? Transfer hovoru – Metoda REFER Vyzkoušejte transfer hovorů: • Nastavuje vždy jen jeden pro všechny. • Nastavte MjServer tak, aby v databázi byly 3 různé účty (např. 1111, 2222 a 3333). • Spusťte MjServer. • Spusťte wireshark na stejném počítači, jako na kterém běží MjServer. • Telefony nastavte tak, aby se zaregistrovaly na MjServer.

64


• Navažte hovor z telefonu 1111 na 2222. • Poté stiskněte na telefonu 1111 tlačítko xfer. • Vytočte číslo 3333 a zmáčkněte tlačítko dial (naváže se hovor na číslo 3333, který přijměte). • Po navázání hovoru stiskněte na telefonu 1111 opět tlačítko xfer. Provede se transfer hovoru: budou spojeni uživatelé 2222 a 3333 a hovor uživatele 1111 bude ukončen. • Ukončete všechny hovory a ukončete zachytávání ve wiresharku. • Analyzujte provoz. Konferenční hovor Vyzkoušejte konferenční hovor: • Nastavuje vždy jen jeden pro všechny. • Nastavte MjServer tak, aby v databázi byly 3 různé účty (např. 1111, 2222 a 3333) • Spusťte MjServer. • Spusťte Wireshark na stejném počítači, jako na kterém běží MjServer. • Telefony nastavte tak, aby se zaregistrovaly na MjServer. • Navažte hovor z telefonu 1111 na 2222. • Poté stiskněte na telefonu 1111 tlačítko conf. • Vytočte číslo 3333 a zmáčkněte tlačítko dial (naváže se hovor na číslo 3333, který přijměte). • Po navázání hovoru stiskněte na telefonu 1111 opět tlačítko conf. Všechny hovory budou spojeny do konference. • Ukončete všechny hovory. Vyzkoušejte různé kombinace toho, který účastník ukončuje hovor. • Ukončete zachytávání ve Wiresharku. • Analyzujte provoz. Úkoly 1. Pomocí jaké zprávy/jakých zpráv je proveden transfer hovorů? 2. Jak se uživatel 1111 dozví, že transfer byl úspěšný? 3. Jakým způsobem je řešeno vytvoření konference?


65

4. Z SDP paketů zjistěte, kolik RTP streamů se mezi účastníky konference posílá. 5. Jak probíhá ukončení konference, když ji ukončuje účastník 1111 (ten, který konferenci vytvořil)? 6. Jak probíhá ukončení konference, když ji ukončuje jiný účastník než ten, který konferenci vytvořil?

66


4.4

Laboratorní úloha – VoIP pobočková ústředna Asterisk a její možnosti

4.4.1

Cíl úlohy

Cílem úlohy je seznámit se se softwarovou pobočkovou ústřednou Asterisk-Trixbox (distribuce CentOS). Ta je v tomto případě reprezentována řešením Trixbox, které přidává přehledné webové rozhraní. V úloze se seznámíte s ovládáním ústředny, vytvoříte uživatelské účty, provedete registraci IP telefonů a realizujete mezi nimi hovor. Po úvodní konfiguraci ústředny se seznámíte s funkcí volacích skupin a vytvářením hlasového menu. Dále připravíte podklady pro jeho tvorbu. Využijte poznatků a vytvořte jednoduché hlasové menu (aplikace – IVR).

4.4.2

Zadání

Pracujte jednotlivě ve virtuálním prostředí VMWare!!! • Pomocí přiložené literatury Trixbox without Tears.pdf se seznamte s možnostmi a funkcemi pobočkové ústředny. • Pomocí internetového prohlížeče se připojte k ústředně Trixbox. IP adresu ústředny získáte od vyučujícího. • Vytvořte v ústředně vlastní uživatelské účty (klapky) a zaregistrujte se k nim jak softwarovým IP telefonem, tak i hardwarovým IP telefonem. • Realizujte testovací hovor mezi oběma telefony. • Seznamte se s vytvářením vlastních hlasových záznamů a nahrajte hlasový záznam. • Seznamte se s vytvářením oznámení a vytvořte vlastní oznámení. • Seznamte s vytvářením volacích skupin. • Vytvořte takovou volací skupinu, která obsahuje pouze jedno telefonní číslo a při jeho nedostupnosti přehraje vámi definované oznámení a poté, co oznámení přehraje, zavěsí. • Seznamte se s vytvářením konferencí.


4.4.3

67


Připojení k ústředně Trixbox • BUĎTE PROSÍM TRPĚLIVÍ VZHLEDEM K DOBĚ ODEZVY ÚSTŘEDNY!!! • Do internetového prohlížeče napište IP adresu ústředny, kterou dostanete zadánu od vyučujícího. • Vpravo nahoře klikněte na odkaz switch – ústředna se přepne do administrátorského módu. • Zadejte přihlašovací údaje - jméno maint heslo password. Nastavení uživatelských účtů na PBX • Při nastavení uživatelských účtů (klapek) pracujte dle přiložené dokumentace. Nastavení se provádí v sekci Asterisk - freePBX Settings - Setup - Extensions. • Nastavte zařízení typu Generic SIP Device. • Zadáváte údaje User Extension - klapka - zadejte minimálně 4místné číslo, Display name - jméno stanice a secret- heslo. • Podrobné možnosti nastavení Extensions vyhledejte v dokumentaci. • Po nastavení klapek nezapomeňte stisknout červené tlačítko Apply Configuration Changes!!! • Zaregistrujte 4 klapky. Registrace SW a HW telefonu k PBX • Spusťte SW klienta X-lite a zaregistrujte ho k PBX na vybranou klapku. • SW telefon X-Lite 1. Spusťte program X-Lite. 2. Zvolte Softphone-Account Settings. 3. Vyplňte políčka UserID, Domain a Password. 4. Ostatní nastavení nechte defaultní. • Zaregistrujte HW telefon na vybranou klapku. • HW telefon INTERBELL 1. IP adresu telefonu zjistíte pomocí tlačítka SYSINFO.

68


2. Přihlaste se do telefonu pomocí webového prohlížeče. K telefon je /heslo admin/admin. 3. Zvolte záložku VOIP/SIP Config. 4. Vyplňte položky Register Server Addr, Register Username, Register Password, Phone Number. Pro použití DTMF tónů zbvolte standard RFC 2833. Zatrhněte Enable Register, Enable Pub Outbound Proxy a SIP. 5. Úspěšně registrovaný telefon poznáte tak, že na displeji trvale svítí SIP. • HW telefon GRANDSTREAM 1. IP adresa telefonu je na úvodní obrazovce. 2. Přihlaste se do telefonu pomocí webového prohlížeče. Heslo k telefon je admin. 3. Zvolte záložku ACCOUNT 1. 4. Vyplňte pole Account Name, SIP Server. SIP User ID, Authenticate ID, Authenticate Password. 5. Ostatní nechte v defaultním nastavení. 6. Úspěšně registrovaný telefon poznáte tak, že na displeji vlevo nahoře trvale svítí bílý symbol UTP zásuvky Seznamte se s vytvářením vlastních hlasových záznamů a nahrajte hlasový záznam • Do ústředny nainstalujte možnost vytváření hlasových záznamů (Tools-Module Admin-Recordings). • Hlasový záznam vytvoříte pomocí pole System Recordings po vyvolání menu Asterisk - freePBX Settings - Setup. • Pro nahrání uživatelských hlášení využijete externí telefon. Do prvního pole je nutné napsat jeho klapku (extension). • Po vložení klapky telefonu postupujte podle pokynů systému. Seznamte s vytvářením volacích skupin • Do ústředny nainstalujte možnost vytváření volacích skupin (Tools-Module Admin-Ring Groups) • Volací skupiny vytvoříte pomocí položky menu Ring Groups.


69

• Prostudujte strategie volání (Zejména RingAll a Hunt) - k čemu slouží? • Vytvořte takovou volací skupinu, která obsahuje pouze jedno telefonní číslo a při jeho nedostupnosti přehraje vámi definované oznámení a poté, co oznámení přehraje, zavěsí. • V menu Ring Groups přidejte do volací skupiny jedno z telefonních čísel, které máte k dispozici. V poli Destination if no answer vyberte vámi vytvořené oznámení. • Ověřte, že vše funguje dle zadání. Seznamte se s možnostmi vytváření hlasového menu v ústředně Trixbox • Do ústředny nainstalujte možnost vytváření hlasových menu (Tools-Module Admin-IVR) • Hlasové menu vytvoříte pomocí pole IVR (Interactive Voice Response) po vyvolání menu Asterisk - freePBX Settings - Setup • Nové hlasové menu vytvoříte pomocí tlačítka Add IVR napravo. • Je důležité, abyste hlasové menu srozumitelně pojmenovali v poli Change name. K nové nabídce přiřadíte uvítání pomocí pole Announcement. • V sekci s možnostmi je nalevo malé pole, do kterého píšete tlačítko na telefonu, kterým se položka vyvolává. Počet položek menu snížíte nebo zvýšíte pomocí tlačítek Increase Options a Decrease Options. • Vytvořte IVR dle přiloženého grafu. • Do IVR se lze dovolat například správným nastavením volby Destination if no answer v nastavení Ring Groups. Vytvořte nový automat DISA (Direct Inward System Access) • DISA vytvoříte pomocí pole DISA po vyvolání menu PBX - PBX Settings, záložky Setup. • Nový automat DISA vytvoříte pomocí tlačítka Add DISA napravo. • Pojmenujte automat a nastavte heslo, kontext ponechte. Vytvořte novou funkci Callback • Callback vytvoříte pomocí pole Callback po vyvolání menu PBX - PBX Settings, záložky.

70


541225869

Hláška - vítejte v našem internetovém obchodě

Hláška: pro přepojení na obchodní oddělení stiskněte 1, pro přepojení na technické oddělení stiskněte 2, pro ostatní informace stiskněte 3.

1

Zvoní na čísle 1

3

2

Zvoní na čísle 2

Zvoní na čísle 3 10 s

Momentálně jsou všichni naši operátoři zaneprázdněni, zavolejte později

Hláška Technické oddělení není dostupné, přepojuji vás na obchodníka

Ukončení hovoru

Obrázek 4.4: Schéma IVR • Nastavte jméno Callback a také zpoždění před jejím vyvoláním. Callback number ponechte prázdné, protože jinak bude automat volat zpět vždy na něj. • V poli destination after callback zadejte vámi vytvořené DISA. Vytvořte novou volací skupinu a navažte ji na funkci Callback • Vytvořte novou volací skupinu a navažte ji na prázdné telefonní číslo, na které se nebude nikdy nikdo registrovat. • Nastavte volací skupinu tak, aby byla při nevyzvednutí hovoru nasměrována na předtím vytvořenou funkci Callback. • Zodpovězte si, k čemu je funkce DISA a Callback dobrá?


71

Seznamte se s možnostmi vytváření konference v ústředně Trixbox • Konferenci vytvoříte pomocí pole Conferences po vyvolání menu Asterisk - freePBX Settings - Setup.

72


5

STANDARDY PRO KOMPRESI OBRAZU A VIDEA

5.1

Teoretický úvod

Standard JPEG Standard JPEG je standardem pro kompresi bitmapových obrazů a byl vyvinut skupinou Joint Photographic Experts Group, která vznikla pod záštitou ISO (International Standards Organisation) a ITU-T (International Telecommunication Union) v roce 1986. V současné době existují 4 módy komprese: • Sekvenční mód kódování – Bitmapový obraz se kóduje řádek po řádku (ztrátové kódování ). • Progresivní mód kódování – Bitmapový obraz se kóduje ve více iteracích (ztrátové kódování ). • Bezeztrátový mód kódování – Bitmapový obraz se kóduje beze ztráty irelevantních dat (bezeztrátové kódování ). • Hierarchický mód kódování – Bitmapový obraz se kóduje ve více průchodech s odlišným prostorovým rozlišením (ztrátové kódování ). Ztrátové sekvenční kódování založené na DCT Komprese JPEG lze shrnout do několika bodů: 1. Převod bitmapového obrazu z prostoru RGB do prostoru YCbCr. 2. Podvzorkování barvonosných složek Cb a Cr dle modelu 4:2:0. 3. Rozdělení matic Y, Cb, Cr na bloky o velikosti 8x8 pixelů. 4. Transformace každého bloku z prostorové oblasti do oblasti frekvenční pomocí dvourozměrné diskrétní kosinové transformace (2D-DCT). V transformovaném bloku platí, že v levém horním rohu je koeficient představující stejnosměrnou složku (DC koeficient) a ostatní koeficienty představují střídavé složky (AC koeficienty). 5. Kvantizace – Transformované bloky ve frekvenční oblasti jsou podrobeny kvantizaci. Ve standardu JPEG jsou uvedeny doporučené kvantizační tabulky, ze kterých


73

je patrná vzrůstající hodnota směrem k pravému dolnímu rohu. To znamená, že koeficienty zastupující vyšší frekvence jsou kvantovány do menšího počtu kvantovacích hladin než je tomu u koeficientů zastupující nízké frekvence. Odlišnost kvantovacích tabulek pro jasové a barvonosné bloky je dána citlivostí lidského oka (na jas je více citlivé než na barvu). Kvantování probíhá dle vztahu 𝑆𝑞𝑢𝑣 =

𝑆𝑢𝑣 , 𝑄𝑢𝑣

(5.1)

kde 𝑆𝑞𝑢𝑣 je hodnota DCT koeficientu po kvantizaci, 𝑆𝑢𝑣 je hodnota DCT koeficientu před kvantizaci a 𝑄𝑢𝑣 je kvantizační krok získaný z tabulky 5.1 pro jasovou složku a z tabulky 5.2 pro barvonosnou složku. Tabulka 5.1: Kvantizační tabulka pro jasovou složku 16

11

10

16

24

40

51

61

12

12

14

19

26

58

60

55

14

13

16

24

40

57

69

56

14

17

22

29

51

87

80

62

18

22

37

56

68

109

103

77

24

35

55

64

81

104

113

92

49

64

78

87

103

121

120

101

72

92

95

98

112

100

103

99

Kvantovací tabulky jsou předem upraveny dle nastavení faktoru kvality 𝑞, jehož hodnota se může pohybovat v rozmezí 1–100, kdy 1 znamená největší kompresi. Každá kvantizační tabulka je vždy definovaná pro hodnotu kvalitativního faktoru 𝑞 = 50. V případě její úpravy je použit vztah 𝑄𝑞𝑢𝑣 = 𝛼𝑄𝑢𝑣 , kde

(5.2)

74


Tabulka 5.2: Kvantizační tabulka pro barvonosné složky 17

18

24

47

99

99

99

99

18

21

26

66

99

99

99

99

24

26

56

99

99

99

99

99

47

66

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

99

𝛼=

50 𝑞

𝛼=2−

v případě, že platí 1 ≤ 𝑞 ≤ 50,

2𝑞 100

v případě, že platí 50 ≤ 𝑞 ≤ 99.

V případě, že 𝑞 = 100, hodnoty kvantizačních tabulkách jsou rovny 1. 6. Kódování DC a AC koeficientů Kódovaná hodnota DC koeficientu je stanovena jako rozdíl DC koeficientu současného a předešlého bloku. Pro výpočet rozdílu je použit vzorec 𝐷𝐼𝐹 𝐹 = 𝑆𝑞00 − 𝑃 𝑅𝐸𝐷,

(5.3)

kde 𝑆𝑞00 je hodnota aktuálně kódovaného DC koeficientu a 𝑃 𝑅𝐸𝐷 je hodnota DC koeficientu předchozího bloku. Výsledek je entropicky kódován Huffmanovým kódem. Střídavé koeficienty AC jsou vyčítány v pořadí cik-cak (obrázek 5.1) – se vzrůstající frekvencí. Koeficienty po cik-cak čtení jsou seřazeny vzestupně od nejnižší frekvence. U klasických obrazů bývají koeficienty vyšších frekvencí nulové. Po cik-cak čtení následuje entropické kódování pomocí předem daných tabulek Huffmanových kódů. Schéma kodéru i dekodéru standardu JPEG je na obrázku 5.2.


75

Obrázek 5.1: Vyčítání koeficientů cik–cak RGB

YCbCr Kvantizační tabulky

4:2:0

Bloky 8x8

2D-DCT

Kvantizace

Huffmanovy tabulky

Čtení cik-cak

C(0) . . .

DPCM

RLE

Huffmanovo /aritmetické/ kódování

DATA

C(63) Přenosový kanál

Bloky 8x8

Inverzní 2D-DCT

Inverzní kvantizace

C(0) . . .

IDPCM

IRLE

Huffmanovo /aritmetické/ dekódování

C(63) 4:4:4

YCbCr

Kvantizační tabulky

RGB

Obrázek 5.2: Kodér a dekodér standardu JPEG

Huffmanovy tabulky

DATA

76


Standardy pro kompresi videa MPEG Standardy MPEG jsou využívány ke ztrátové kompresi videa. Základní princip kodéru je podrobně popsán pro MPEG-1, ostatní novější kodeky (MPEG-2, MPEG-4, H.264, H.265) na tomto principu dále staví a vylepšují ho.

Standard MPEG-1 Standard MPEG-1 (ISO/IEC 11172) byl primárně určen k ukládání videosekvencí na digitální médium v kvalitě srovnatelné s kvalitou videa uložených na analogových VHS (Video Home System) kazetách. Hierarchie a terminologie Nejvyšší definovanou úrovní v hierarchii MPEG-1 je sekvence snímků určité délky (videoklip). Ta se skládá z částí nazývaných skupiny snímků GOP (Group of Pictures). Skupina snímku GOP je série jednoho nebo více snímků. Typická sekvence MPEG-1 se skládá s opakujících se struktur GOP. GOP se může skládat ze 3 typů snímků, jejichž vlastnosti budou uvedeny níže. Dalším stupněm hierarchie je zmiňovaný snímek. Každý snímek se skládá z tzv. slice, které obsahují makrobloky. Makroblok obsahuje veškeré informace o oblasti o velikosti 16x16 pixelů. Slice obsahuje libovolný počet makrobloků kódovaných bez jakýchkoliv odkazů na makrobloky v jiném slice (pokud jsou data ze slice znehodnocena, nemá to žádný vliv na ostatní data v dalších slice). Maximální velikost slice u MPEG-1je omezena velikostí jednoho snímku. Typy snímků 1. Snímek I je kódovaný bez jakékoli reference na předchozí nebo budoucí snímek. Snímky I tvoří tzv. přístupové body kódovaného videa pro dekodér. Snímky jsou kódovány obdobným způsobem jako snímky kódované standardem JPEG. 2. Snímek P je prediktivně kódován z předchozího referenčního I nebo P snímku. Sám může být použit jako referenční pro kódování následujícího snímku. 3. Snímek B je obousměrně predikovaný. K predikci může využít předchozí, následující nebo oba snímky dohromady. To zvyšuje efektivitu pohybové kompenzace. B snímky


77

však nikdy nemohou být použity jako referenční. Důsledky použití B snímků jsou: (a) Vzhledem k tomu, že B snímek není užívaný jako referenční, může být kódování provedeno s nejvyšší možnou kompresí bez jakýchkoliv dalších vedlejších účinků. (b) Při přenosu videa sítí mohou být, např. při náhlém přetečení bufferu, B snímky vypuštěny bez jakýchkoliv následků na dekódování následujících snímků. 4. Snímek D kódovaný intra-frame, kóduje se však pouze DC koeficient. D snímky nemají v současnosti uplatnění. Skupina snímků GOP Skupina snímků je kombinace I, P a B snímků. Může se však skládat pouze z I snímků nebo například z kombinace I a P snímků. Každá GOP začíná I snímkem, z čehož plyne, že není potřebná žádná předchozí reference k dekódování. Po I snímku může následovat jeden či více B snímků. První P snímek v GOP je kódován z odkazu na I snímek. Pro další P snímky v GOP je referenčním snímkem předchozí P. Z toho plyne nepříjemná vlastnost. Pokud bude chyba v některém P snímku, potom se bude šířit dále až nakonec GOP. Pro B snímky je referenční předchozí I nebo P snímek - dopředná predikce, nebo následující I nebo P snímek - zpětná predikce, nebo oba - obousměrný predikce. B snímek nikdy nemůže být referenčním. Skladba GOP není nikde definovaná, může se proto skládat z libovolně uspořádaných snímků zmíněných typů. Délka GOP je definována jako vzdálenost dvou I snímků, která je reprezentovaná parametrem 𝑁 . GOP může obsahovat libovolný počet snímků, alespoň jeden musí být I. Aplikace vyžadující náhodný přístup, rychlé převíjení vpřed i vzad, by měly využívat kratší GOP. Pro většinu aplikací u formátu MPEG-1 má 𝑁 = 12 a 𝑀 = 3. Pořadí kódování snímků se liší od pořadí zobrazených snímků. Makrobloky Standard MPEG-1 při kódování používá barevný prostor YCbCr se vzorkováním 4:2:0. Obraz je rozdělen na makrobloky o velikosti 16x16 pixelů. Po vzorkování zahrnuje jeden makroblok 4 jasové bloky Y o rozměrech 8x8 pixelů a jeden blok o rozměrech 8x8 pixelů od každé barvonosné složky Cb a Cr. Existují 2 možnosti kódování makrobloků:

78


1. Kódování uvnitř makrobloku (INTRA kódování) probíhá téměř shodně s JPEG kódováním. Jediným rozdílem je definice kvantizačních tabulek. MPEG-1 definuje kvantizační tabulky, jednu pro INTRA kódování, ostatní pro mezisnímkové INTER kódování. Každá z těchto tabulek však může být změněna specifikací v hlavičce sekvence. Pokud změněny nejsou, dekodér vychází ze standardních. Kvantizace se nastavuje pomocí parametru MQuant. Tato hodnota je primárně nastavena pro každý slice, může být nastavena i pro každý makroblok samostatně. 2. Mezisnímkové kódování makrobloků (INTER kódování) probíhá u snímků P a B. Ty jsou nejprve INTRA kódovány stejně jako I snímky bez predikčního kódování. V bloku pro odhad pohybu se dekódují a proběhne mechanizmus, který má za cíl najít určitou shodu mezi právě kódovaným snímkem a snímkem referenčním (predikce). V případě, že rozdíl mezi predikčním a skutečně kódovaným snímkem přesahuje určitou definovanou hranici, snímek se kóduje v INTRA módu. V ostatních případech se kóduje rozdíl mezi skutečně kódovaným snímkem a jeho predikcí. K nalezení nejlepší shody makrobloků se používá blok pro odhad pohybu. V MPEG standardech je pro odhad pohybu využívána pouze jasová složka obrazu Y. Blok pro odhad pohybu určí vektory pohybu, které jsou použity jak pro jasové, tak i pro barvonosné složky. Výstupem INTER kódování je tedy kódovaný predikovaný snímek společně s vektory pohybu. Po nalezení vektorů pohybu je s každým predikovaným blokem v makrobloku nakládáno samostatně. Každý predikovaný blok je pixel po pixelu odečten od vybraného bloku v referenčním makrobloku. Tím vznikne rozdílový snímek (chyba odhadu), který je následně transformován pomocí DCT, kvantován a entropicky kódován. Neplatí zde však pravidlo, že DC koeficient je kódován rozdílově jako u INTRA či JPEG kódování. Zmíněný postup se provádí pro všechny bloky jednoho makrobloku. Pokud je odhad pohybu dobrý, mají koeficienty rozdílových bloků malé hodnoty a po kvantizaci jsou tedy nulové. Tyto bloky pak není potřeba kódovat a jsou přeskakovány, čímž se značně ušetří šířka pásma. Vektory pohybu jsou taktéž kódovány. Pro první makroblok ve slice musí být vektory pohybu kódovány a poslány úplné. Pro následné makrobloky jsou vektory pohybu prediktivně kódovány z předchozích.


79

Kódování a dekódování videa dle standardu MPEG-1 Vstupem do kodéru je nekomprimované video, u kodéru MPEG-1 v rozlišení maximálně CIF. Před samotným kódováním je stanovena velikost a struktura GOP. V níže popsaném příkladě bude GOP složena ze čtyřech snímků IBBP. Jak bylo popsané výše, pořadí kódování může být odlišné od pořadí přehrávání. V tomto případě je jasné, že pro případ kódování B snímků je zapotřebí I a P snímek, což je v tomto případě snímek 1 a 4. V první fázi kódování tedy dochází k přeuspořádání snímků. Vstupní posloupnost 1,2,3,4 je přeuspořádána na posloupnost 1,4,2,3. Řízení

vstup

Přeuspořádání snímků

-

Q

DCT

VLC

Buffer

výstup

IQ

IDCT

+

Kompenzace pohybu Snímková paměť Odhad pohybu Vektory pohybu

Obrázek 5.3: Obecný kodér standardu MPEG

Dle GOP následuje kódování snímku 1, který bude kódován jako I snímek. Se snímkem je zacházeno obdobně jako v případě kódování standardem JPEG. Odlišuje se pouze v použitých kvantizačních tabulkách. Po kvantizaci probíhá kódování proměnné délky VLC opět shodné se standardem JPEG. Výstupem je zakódovaný snímek I. Ještě před VLC kódování

80


je tentýž snímek inverzně kvantován a transformován, čímž vznikne dekódovaný snímek, který je uložen do snímkové paměti pro další zpracování. Do kodéru vstupuje snímek 4, který dle GOP bude kódovaný jako P snímek (predikovaný z předchozího snímku). Při predikci jsou oba spínače sepnuty. Snímek 4 nejprve vstupuje do bloku pro odhad pohybu. Zde se stává referenčním snímkem pro snímek 1 uložený ve snímkové paměti. Jednotlivé makrobloky snímku 1 jsou přeskládány tak, aby co nejlépe odpovídaly blokům snímku 4. Zde vznikají vektory pohybu, které určují pozice, kam se který makroblok posunul. Tyto vektory jsou poté aplikovány na snímek 1, čímž se vytvoří predikovaný snímek ke snímku 4. Tento predikovaný snímek odečten od původního snímku 4, čímž je zajištěno, že na vstup bloku DCT přichází pouze chyba predikce. Ta obsahuje podstatně méně informace než původní snímek. Tato chyba predikce je dále kódována ve stejném znění jako předchozí snímek. Po její zpětné rekonstrukci je přičtena k predikovanému snímku a výsledek, dekódovaný snímek 4 je uložen do snímkové paměti. Tento postup je ve stejném znění opakován pro další příchozí snímky. U B snímků jsou do snímkové paměti ukládány 2 referenční snímky. Proces dekódování je opačný k procesu kódování. Dekodér je však méně výpočetně náročný, neboť odpadá výpočet odhadovaného snímku. Schéma pro obecný MPEG dekodér je na obrázku 5.4.

vstup

Buffer

VLD

IQ

IDCT

Přeuspořádání snímků

+

Snímková paměť

Kompenzace pohybu

Obrázek 5.4: Obecný dekodér standardu MPEG

výstup


5.2

81

Laboratorní úloha – komprese statických obrazů a videosekvencí, JPEG, MPEG, H.26x

5.2.1

Cíl úlohy

Seznámit se s principy činnosti a možnostmi kompresních algoritmů JPEG pro statické obrazy, MPEG-1, MPEG-2 a H.264 užívané pro pohyblivé obrazy (video). Uvědomit si vznik různých artefaktů (zkreslení), které doprovázejí kompresi videa s těmito metodami.

5.2.2

Zadání

• Seznamte se s kodeky obrazu a videa JPEG a MPEG. • Vyzkoušejte si různá nastavení ovlivňující kompresi a videa.

5.2.3


• Z e-learnigu si stáhněte VCDemo a nainstalujte jej ve virtuálním prostředí. • Spusťte program VCDemo, otevřete libovolný obrázek pomocí File/Open Image. Klikněte na tlačítko JPEG. • Vyzkoušejte, u jakého faktoru kvality poznáte, že komprimovaný obrázek nevypadá shodně s originálem? Jakou má hodnotu PSNR? Co je to PSNR? Kolik bitů na jeden pixel tento obrázek má před a po kompresi? • Vyzkoušejte nabízené kvantizační tabulky. Jaké vidíte výhody a nevýhody jednotlivých z nich? • Zaveďte do souboru různé procento chyb a zjistěte, jakým způsobem to ovlivní výsledný obraz. • Spusťte program VCDemo, otevřete soubor videosekvence pomocí File/Open Sequence. Klikněte na tlačítko MEnc. • Základní nastavení. Na záložce File vyberte, kam se komprimovaný MPEG soubor uloží pomocí Save as.., typ komprese zvolte MPEG-1. Na záložce Rate zvolte Set Bit Rate na 0,384 Mbit/sec. Na záložce Gop zvolte pořadí snímků IBBPBB, tj, jeden intra kódovaný a pět inter kódovaných snímků, a pak zvolte Apply. Sekvence se zkomprimovala do předem určeného adresáře. Prohlédnout si ji můžeme přes menu

82


File/Open Mpeg Stream. Vyberte modul MDec - Záložka Operation - Set decoder output - Decoded frames, tím jsme zvolili, aby se nám při přehrávání zobrazoval dekomprimovaný obraz. Pomocí Apply si prohlédneme komprimované video. Při tomto relativně nízkém datovém toku jsou jasně patrné kompresní artefakty: blokové, tzv. "ringing", který se projevuje kolem ostrých přechodů a celkové rozmazání obrazu. • Přenos chybovým kanálem. Záložka Wireless Channel v modulu MDec. Dejte Simulate Wireless Channel. Zvolte HiperLAN (v podstatě jiná verze Wi-Fi) a pravděpodobnost chyby P(error) (BER) nastavte na 1e-3, a počet přihlášených uživatelů Number of users dejte na 1, dejte Apply. Potom z tohoto dialogu vyskočte a otevřete si právě vytvořený soubor *-WRLS.mpg. Prozkoumejte vliv náhodných chyb na kvalitu videa. Zkuste vytvořit nové video s chybovým kanálem, ale také s více uživateli. Při překročení dostupných síťových prostředků (20Mbit/s / počet uživ. * datový tok videa) začne mechanizmus sítě zahazovat celé pakety, čímž vznikají shluky chyb v přenosu - ověřte. • Vyzkoušejte rovněž simulaci přenosu přes GPRS. CS-1: 25 kbit/s, CS-2: 60 kbit/s, CS-3: 80 kbit/s, nebo CS-4: 150 kbit/s. Čím vyšší je zvolená přenosová rychlost, tím slabší je protichybové zabezpečení přenášených paketů - vyzkoušejte. • Vyzkoušejte kompresi videa MPEG, při kterém budou použity pouze snímky I (GOP I only). Prověřte vliv tohoto nastavení a pokuste se zodpovědět jeho výhody a nevýhody. • Spusťte program VCDemo, otevřete soubor videosekvence pomocí File/Open Sequence. Klikněte na tlačítko HEnc. • Základní nastavení. Na záložce File vyberte, kam se komprimovaný soubor uloží pomocí Save as... Na záložce IntraFrame zvolte periodu snímků komprimovaných v Intra módu Set Period of I-Frames. 0 znamená je první snímek v sekvenci. Ponechte ji nastavenou na 0. Dále můžete nastavit kvantizační parametr (QP) prvního a dalších I-snímků, zatím ponechte na hodnotě 28. Na záložce Inter Search Modes lze nastavit možnost dělení makrobloků 16x16 na menší bloky, což ovlivňuje efektivitu komprese. Zvolte všechny možnosti dělení bloků. A nakonec na záložce Entropy Coding zvolte kódování s proměnnou délkou slova UVLC. A dejte Apply. Po skončení komprimace si můžeme v okně textového výstupu přečíst charakteristiku kódování.


83

V položce Bit rate nalezneme datový tok při určité snímkové frekvenci. Dále můžeme u jednotlivých snímků vidět, kolik bitů je potřeba na komprimaci I, P a B snímků. • Přes menu File/Open H.264 Stream vyberte zkomprimovaný soubor a klikněte na modul HDec. Záložka Decoder Step - Frame by frame, dále Input Stream - Input Stream Shown, Motion Vectors - Shown, včetně Picture in the background, Intra prediction - Shown, včetně Colored, Block Division - Shown, včetně Picture in the background. Dejte Apply. • Při práci s H.264 kodérem se nenastavuje přenosová rychlost (datový tok) videosouboru jako u MPEG-1 kodéru, ale nastavují se zde parametry kvantizace (QP parametr). To v praxi znamená, že 2 obsahově různé sekvence se stejným nastavením QP budou mít různou velikost. Vyzkoušejte nastavit QP parametr jak pro I-snímky, tak pro B-snímky na záložce B-Frames - QP. • Jaký je vztah mezi kvantizačním parametrem (QP) a datovým tokem videa? • Které ze snímků I, P nebo B nesou nejméně informace?

84


Reference [1] Campbell, B.; Rosenberg, J.; Schulzrinne, H.; aj.: RFC 3428 - Session Initiation Protocol (SIP) Extension for Instant Messaging. Technická zpráva, Internet Engineering Task Force, 2002. [2] Davidson, J.; Peters, J.; Bhatia, M.; aj.: Voice over IP Fundamentals. Indianopolis: Cisco Press, 2007, ISBN 978-1-58705-257-6, 394 s. [3] Firestone, S.; Ramalingam, T.; Fry, S.: Voice and Video Conferencing Fundamentals. Indianopolis: Cisco Press, 2007, ISBN 978-1587052682, 376 s. [4] Handley, M.; ; Schulzrinne, H.; aj.: RFC 2543 - SIP: Session Initiation Protocol. Technická zpráva, Internet Engineering Task Force, 1999. [5] Handley, M.; Jacobson, V.; Perkins, C.: RFC 4566 - SDP: Session Describtion Protocol. Technická zpráva, Internet Engineering Task Force, 2006. [6] Handley, M.; Perkins, C.; Whelan, E.: RFC 2974 - Session Announcement Protocol. Technická zpráva, Internet Engineering Task Force, 2000. [7] Kolář, J.: Teoretická informatika. Praha: Česká informatická společnost, 2004, ISBN 80-900853-8-5, 205 s. [8] Levický, D.: Multimediálne komunikácie. Košice-Elfa, 2002, ISBN 80-89066-58-5. [9] Niemi, A.: RFC 3903 - Session Initiation Protocol (SIP) Extension for Event State Publication. Technická zpráva, Internet Engineering Task Force, 2004. [10] Richardson, I. E. G.: H.264 and MPEG-4 Video Cmpression. John Wiley & Sons Ltd., 2002, ISBN 0-470-84837-5. [11] Roach, A. B.: RFC 3265 - Session Initiation Protocol (SIP)-Specific Event Notification. Technická zpráva, Internet Engineering Task Force, 2002. [12] Rosenberg, J.: RFC 3856 - A Presence Event Package for the Session Initiation Protocol (SIP). Technická zpráva, Internet Engineering Task Force, 2004.


85

[13] Rosenberg, J.; Schulzrinne, H.; Camarillo, G.; aj.: RFC 3261 - SIP: Session Initiation Protocol. Technická zpráva, Internet Engineering Task Force, 2002. [14] Rosenberg, J.; Schulzrinne, H.; Kyzivat, P.: RFC 3841 - Caller Preferences for the Session Initiation Protocol (SIP). Technická zpráva, Internet Engineering Task Force, 2004. [15] Schulzrinne, H.; Casner, S.; Frederick, R.; aj.: RFC 3550 - RTP: A Transport Protocol for Real-Time Applications. Technická zpráva, Internet Engineering Task Force, 2003. [16] Schulzrinne, H.; Columbia, U.; Rao, A.; aj.: RFC 2326 - Real Time Streaming Protocol (RTSP). Technická zpráva, Internet Engineering Task Force, 1998. [17] Shi, Y. Q.; Sun, H.: Image and Video Compression for Multimedia Engineering. Boca Raton, FL, USA: CRC Press, Inc., první vydání, 1999, ISBN 0849334918. [18] Sparks, R.: RFC 3515 - The Session Initiation Protocol (SIP) Refer Method. Technická zpráva, Internet Engineering Task Force, 2003.

video dat pro integrovanou výuku VUT a VŠB-TUO

Recommend Documents