Přenos a komprese audio/video dat pro integrovanou výuku

Transkript

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:
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
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.
• 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
• 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ů:
• Nastavte MjServer tak, aby v databázi byly 3 různé účty (např. 1111, 2222 a 3333).
• 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.
Konferenční hovor
Vyzkoušejte konferenční hovor:
• Nastavte MjServer tak, aby v databázi byly 3 různé účty (např. 1111, 2222 a 3333)
• 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.
Ú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.

Přenos a komprese audio/video dat pro integrovanou výuku

Transkript

Podobné dokumenty

Zpracování multimediálních dat pro integrovanou výuku VUT a

nanotechnologie

Untitled - Kodak Alaris

Kazetové jednotky Optimální klimatizace pro Váš prostor GEA

it produkt roku 2010

2135XP_data

2135QTi-2MAX

2130XP_data

CVIČENÍ