Principy moderní hlasové komunikace

Bankovní institut vysoká škola Praha Informační technologie

Principy moderní hlasové komunikace Bakalářská práce

Autor:

Milan Šereda Informační technologie

Vedoucí práce

Praha

Ing. Beneš Vladimír

Duben, 2010

Prohlášení Prohlašuji, že jsem seminární práci zpracoval samostatně a s použitím uvedené literatury.

V Praze dne 10. dubna 2010

Milan Šereda

Poděkování Chtěl bych poděkovat společnosti Siemens Enterprise Communications, s.r.o. za poskytnutí technických podkladů do této práce. Chtěl bych poděkovat vedoucímu bakalářské práce Ing. Vladimíru Benešovi Petrovickému za jeho ochotu, vedení a pomoc při tvorbě této práce.

Anotace Cílem této práce je zmapování posledního vývoje a trendů spojených s hlasovou komunikací a vyhodnocení výhod plynoucí z jejich použití v prostředí TCP/IP. Autor konkrétně zjišťuje, jak se vyvíjí hlasová komunikace, jakým způsobem dochází k propojování hlasu s dalšími multimediálními službami, jak se mění samotné produktové portfolio výrobců klasických hlasových technologií a jaké finální přínosy plynou pro uživatele při použití nejnovějších technologií. Výsledkem práce je celistvý náhled na oblast hlasové komunikace a možnosti integrace navazujících multimediálních služeb s výčtem nejvýznamnějších přínosů pro její uživatele.

Annotation The aim of this work is to assess recent developments and trends of voice communications and evaluate benefits arising from their use in the TCP/IP environment. The author specifically identifies trends in voice communications, how voice converges with other multimedia services, how vendors change their product portfolio of voice technology, and what final benefits arise when users use the latest technology. The result of this work is a complete preview of voice communication and integration capabilities related to multimedia services, listing the most important benefits for its users.

Obsah Úvod ................................................................................................................................. 9 1.

Principy a vývoj moderní hlasové komunikace .................................................. 9

1.1.

Obecné principy .................................................................................................. 9

1.2.

Počátky hlasové komunikace ............................................................................ 10

1.3.

První telefonní sítě ............................................................................................ 11

1.4.

Vývoj analogové technologie ............................................................................ 11

1.5.

Analogová faxová komunikace ......................................................................... 12

1.6.

Digitalizace veřejných telefonních ústředen ..................................................... 13

1.7.

Telefonní ústředny v organizacích a podnicích ................................................ 14

1.8.

Změny v připojení do VTS ............................................................................... 16

1.9.

Vysokorychlostní páteře poskytovatelů ............................................................ 16

1.10.

Nástup IP telefonie a Voice over IP .................................................................. 18

1.11.

Původní koncept oddělených technologických sítí ........................................... 18

1.12.

VoIP .................................................................................................................. 19

1.13.

Současnost ......................................................................................................... 19

1.13.1.

Komunikační sítě z pohledu L2 a L3 ............................................................. 20

1.13.2.

Komunikační sítě z pohledu L1 a L2 ............................................................. 20

2.

IP telefonie a Voice over IP .............................................................................. 21

2.1.

Technologická změna....................................................................................... 21

2.2.

Unified Communications .................................................................................. 22

2.3.

Mobilní technologie .......................................................................................... 24

2.4.

Protokoly VoIP.................................................................................................. 24

2.5.

Protokoly IP telefonie ....................................................................................... 25

2.6.

Signalizace H.323 ............................................................................................. 27

2.6.1.

H.323 komponenty ............................................................................................ 27

2.6.2.

Terminály .......................................................................................................... 27

2.6.3.

Brány ................................................................................................................. 28

2.6.4.

Gatekeeper......................................................................................................... 28

2.6.5.

MCU .................................................................................................................. 29

2.6.6.

Rodina protokolů H.323 .................................................................................... 29

2.7.

Signalizace SIP.................................................................................................. 29

2.7.1.

SIP komponenty ................................................................................................ 30

2.7.2.

SIP/SIMPLE ...................................................................................................... 31

2.7.3.

Rodina protokolů SIP ........................................................................................ 31

2.8.

Hlasová data ...................................................................................................... 31

2.9.

Kódování hlasu.................................................................................................. 32

2.9.1.

Problémy s kódováním ...................................................................................... 33

2.9.2.

Speciální kodeky ............................................................................................... 34

3.

Kvalita služeb .................................................................................................... 36

3.1.

Předpoklady k zavedení moderních trendů ....................................................... 36

3.2.

Kvalita služeb .................................................................................................... 37

3.2.1.

Klasifikace provozu .......................................................................................... 39

3.2.2.

Značení provozu ................................................................................................ 39

3.2.2.1.

Značení rámců L2 CoS .............................................................................................................. 39

3.2.2.2.

Značení paketů L3 DSCP .......................................................................................................... 40

3.2.3.

Upravení, omezení a zahazování provozu ........................................................ 42

3.2.4.

Začlenění provozu do front ............................................................................... 43

3.2.4.1.

Frontování v L2 prvcích ............................................................................................................ 43

3.2.4.2.

Frontování v L3 prvcích ............................................................................................................ 43

3.2.5.

Fragmentace a prokládání paketů...................................................................... 44

4.

Napájení komunikačních komponent ................................................................ 45

5.

Komponenty ve standardním řešení IP telefonie .............................................. 47

5.1.

Přehled komponent............................................................................................ 47

5.1.1.

Řešení výrobců .................................................................................................. 47

5.1.2.

Rozmístění komponent...................................................................................... 48

5.2.

Řídící server IP telefonie ................................................................................... 49

5.2.1.

IP telefony ......................................................................................................... 50

5.2.2.

Hlasové brány.................................................................................................... 50

5.3.

Podpůrné aplikace ............................................................................................. 51

5.3.1.

Média server ...................................................................................................... 51

5.3.2.

Konferenční server ............................................................................................ 51

5.3.3.

Management server ........................................................................................... 52

5.3.4.

Tarifikační server .............................................................................................. 52

5.3.5.

Integrace adresářových služeb .......................................................................... 52

5.3.5.1.

Problémy integrace adresářových služeb .................................................................................. 53

6.

Nadstavbové aplikace a jejich integrace do IP telefonie................................... 54

6.1.

Aplikace CTI ..................................................................................................... 54

6.2.

Aplikace kontaktního centra ............................................................................. 55

6.3.

Aplikace Unified Messaging ............................................................................. 56

6.4.

Aplikace automatické spojovatelky .................................................................. 57

7.

Vzorové řešení IP telefonie a Unified Communications................................... 58

7.1.

Požadavky trhu .................................................................................................. 58

7.2.

Strategie výrobců .............................................................................................. 58

7.3.

Výběr vzorového výrobce ................................................................................. 59

7.3.1.

Vzorové řešení IP telefonie ............................................................................... 60

7.3.1.1.

Siemens OpenScape Voice ........................................................................................................ 60

7.3.1.2.

Siemens Common Management Portal ..................................................................................... 61

7.3.1.3.

Siemens DLS ............................................................................................................................. 62

7.3.1.4.

IP telefony Siemens OpenStage ................................................................................................ 63

7.3.1.5.

Rozhraní pro připojení příslušenství ......................................................................................... 66

7.3.1.6.

Aplikační platforma XML ......................................................................................................... 66

7.3.1.7.

Přístup k adresáři – LDAP klient............................................................................................... 67

7.3.1.8.

Hlasová pošta OpenScape Xpressions....................................................................................... 67

7.3.1.9.

Zobrazení IP kamery/vrátníku ................................................................................................... 68

7.3.1.10. Čtení RSS kanálů přes XML ..................................................................................................... 69

7.4.

Hlasové brány.................................................................................................... 69

7.4.1.

Siemens OpenScape Unified Communications................................................. 71

7.4.1.1.

Dostupnost pod jediným telefonním číslem .............................................................................. 72

7.4.1.2.

Uživatelská prezence ................................................................................................................. 73

7.4.1.3.

Webové konference, IM ............................................................................................................ 74

7.4.1.4.

Sdílení dokumentů ..................................................................................................................... 74

7.4.2.

Siemens OpenScape Video ............................................................................... 74

7.4.2.1.

OpenScape VHD terminály ....................................................................................................... 75

7.4.2.2.

OpenScape Desktop Client ........................................................................................................ 75

7.4.2.3.

Aplikační rámec OpenScape ..................................................................................................... 76

8.

Stanovení přínosů pro uživatele ........................................................................ 77

Závěr ............................................................................................................................... 79 Použitá literatura ............................................................................................................. 80 Seznam obrázků.............................................................................................................. 82 Seznam tabulek ............................................................................................................... 83 Seznam použitých zkratek .............................................................................................. 84

Úvod Metody přenosu hlasu se stále vyvíjejí a zlepšují. Analogové hlasové technologie se nahrazují digitálními, zvyšuje se univerzálnost řešení, rozšiřuje se funkcionalita hlasových služeb, které se následně integrují do aplikací. Jedním z posledních, výrazných trendů je IP telefonie provozovaná v prostředí konvergovaných komunikačních sítí na jednotném základu TCP/IP. Konvergované komunikační sítě umožňují oproti dřívějším, jednoúčelově zaměřeným sítím sjednotit přenos dat, hlasu, videa, textu a dalších multimediálních služeb přes jednotnou přenosovou infrastrukturu. Dochází k provázání a těsné spolupráci těchto multimediálních služeb. Neméně významným aspektem komunikace je dosažení nižší režie provozu za jednotku celkových přenesených dat při zachování dobré kvality hlasu, videa a dalších kritických multimediálních služeb. To jsou přednosti, které vedou k rychlému prosazování těchto trendů a s nimi spojených technologií. Vysvětlení základních principů, mezních vývojových kroků a jejich celkové pochopení je důležitým předpokladem k podrobnému technickému rozboru hlasových technologií na bázi VoIP, IP telefonie a dalších multimediálních služeb shrnutých pod pojmem Unified Communications.

1. Principy a vývoj moderní hlasové komunikace Tato kapitola popisuje principy a důležité vývojové kroky směřující k posledním trendům.

1.1. Obecné principy Základem rozvoje naší lidské společnosti je efektivní předávání informací a to vždy tou nejsnadněji uchopitelnou formou včetně psaného textu, hlasu, hudby a obrazu, v ideálním případě vyladěnou kombinací všech těchto i dalších možných forem komunikace. O výměně informací pomocí lidského hlasu lze říci, že je to způsob nejzákladnější a lidské společnosti nejbližší. Telefonie jako metoda přenosu je interaktivní, propojí dva komunikační body vybavené patřičnou technologií a okamžitě přenáší informaci. Tento způsob komunikace je značně oblíbený, protože přenáší vedle základní informace i další lidské komunikační 9

prvky jako jsou zabarvení hlasu, jeho intenzita a emoce. Umožňuje tak s informací mixovat psychologické vjemy a generovat pocity, které mohou být v komunikaci rozhodujícím prvkem. Efektivní komunikace je o to důležitější v obchodním prostředí, kde přenos informací bez zbytečného šumu a s minimálním prodlením může zajistit konkurenční výhodu, kterou lze následně proměnit v zisk. Získané finanční prostředky touto cestou motivují k

dalším

inovacím

komunikačních

technologií,

ve

výsledku

pak

dojde

k technologickému náskoku nad konkurencí. Historicky byl přenos hlasu, hudby, obrazu a textových zpráv1 technologicky oddělen. S postupnou evolucí komunikačních technologií se tyto přenosy pomalu slučují, doplňují a rozšiřují o další nové moderní formy. Společným jmenovatelem je jednotné komunikační prostředí postavené na široce uznávaných standardech, které je schopné doručit koncovému uživateli téměř jakoukoliv užitečnou formu komunikace.

1.2. Počátky hlasové komunikace Hlasová komunikace se postupně vyvíjela od primitivních způsobů komunikace přes mechanické komunikační prostředky až po současné telefonní technologie. Ačkoliv telefonie jakožto způsob přenosu hlasové komunikace je mnohem starší, za základní mezník skutečné telefonie lze považovat až technologie postavené na elektrickém proudu. Právě elektrický proud umožnil přenos zvuku na dlouhé vzdálenosti. Za otce telefonie je obecně považován Alexander Graham Bell, který sestrojil první telefon v Bostonu ve Spojených státech v roce 1876. Využil vynálezu uhlíkového mikrofonu k převodu zvuku na elektrický signál, dále pomocí magnetu, pohyblivé membrány a výkyvů indukčního proudu převedl elektrický signál opět na zvuk. Tento okamžik umožnil povýšit komunikaci telegrafu na vyšší úroveň – na skutečnou telefonii. Objevený princip převodu zvuku na elektrický signál a zpět pomocí mikrofonu a reproduktoru se stal technologickým základem k přenosu hlasu, který je platný až do dnešních dnů moderní hlasové komunikace [17].

1

Ačkoliv tato práce je primárně zaměřena na problematiku přenosu lidského hlasu, popisuje částečně i související oblasti přenosu hudby, obrazu a textových zpráv a navazujících aplikací. 10

1.3. První telefonní sítě Na začátku byly první telefony spojeny pouze jedním metalickým vodičem, obvod byl uzavřen zemí. Signalizace k přepojení hovoru nebyla řešena. Princip spojení okruhu zemí měl řadu funkčních nedostatků. Následovala párová vedení k zajištění spolehlivějšího přenosu. Párová vedení byla prvním krokem k signalizaci, řízenému spojování hovorů a vytváření spojových uzlů manuálně ovládaných spojovatelkami. První kabelové spojení bylo drahé a to díky ceně samotného vedení. Technologie požadovala natažené metalické vodiče umístěné na sloupech telefonního vedení do nejbližšího spojovacího místa. Spojovací místo zajišťovalo manuální přepojení hovoru ke koncovému účastníku nebo do nadřazeného uzlu telefonní sítě. Navzdory vysoké ceně bylo na začátku roku 1904 ve Spojených státech už přes tři milióny uživatelů připojených přes manuálně ovládané telefonní ústředny [22]. Klíčovou roli měly telefony během 1. a následně 2. světové války. V 1. světové válce bylo telefonní spojení strategickým komunikačním nástrojem mezi velením a vojáky v zákopech a to především na kratší vzdálenosti. V 2. světové válce měl telefon roli informační a to na všech úrovních civilní a vojenské komunikace. Ačkoliv byl částečně vytěsněn rádiovým spojením, zabezpečené telefonní spojení umožňovalo spojit komunikující strany na dlouhé vzdálenosti i mezi kontinenty. Kolem roku 1960 byly vytvořeny globální telefonní sítě postavené výlučně na analogové technologii.

1.4. Vývoj analogové technologie Termín analogová technologie je odvozen od analogového přenosu, kdy akustické vlny vytvářené hlasovou komunikací jsou přenášeny ve formě analogového signálu reprezentovaného výkyvy v elektrickém proudu. S postupným vývojem analogového hlasového přenosu došlo nejen k vývoji samotné spojovací technologie, ale i koncových zařízení. Telefony původně využívané jen pro významné firmy a movité uživatele se postupně dostaly i do běžných domácností. Rovněž spojovací uzle byly měněny z manuálně obsluhovaných na automatizované. Důležitým krokem byla standardizace jak na národní, tak mezinárodní úrovni. Jednou z standardizační institucí na straně evropského kontinentu byla Comité Consultatif International Téléphonique et Télégraphique (CCIT), která se později transformovala do 11

útvaru International Telecommunication Union – Telecommunication Standardization Sector (ITU-T). ITU-T je i v současnosti jednou z nejuznávanějších organizací, které se zaměřují na oblast telekomunikací a která vydala za dobu své působnosti stovky technických doporučení2. Důležitým prvkem bylo zavedení jednotných městských, regionálních a státních číslovacích plánů. Na straně uživatele došlo k použití rotačního číselníku, který pomocí impulzů signalizoval volané číslo a následně umožnil automatické směrování hovoru přes spojovací uzle. Na straně poskytovatele spojení došlo k automatizaci spojových uzlů implementací prvních reléových ústředen. Princip rotačního číselníku a signalizace volaného čísla tzv. pulzní volbou byla i po mnoha zdokonalení běžná až do 70. let 20. století. V současnosti je běžnou signalizační metodou volby čísla tzv. tónová volba (DTMF), která při volbě čísla používá kombinaci dvojice různých tónů. Z pohledu uživatele došlo ke změně uživatelského rozhraní, kdy se místo telefonu s rotačním číselníkem začal používat telefon s tlačítky označenými čísly. DTMF generuje dvojici tónů o konkrétních frekvencích při stisku konkrétního tlačítka telefonu. DTMF je i dnes široce rozšířeno, hlasové brány do TCP/IP světa musí DTMF podporovat k mapování čísel do současných signalizačních protokolů. Kombinace tónů dle doporučení ITU-T Q.23 uvádí následující tabulka. Tabulka č. 1: Kombinace tónů v DTMF signalizaci

Skupina nízkých frekvenc í

697 Hz 770 Hz 852 Hz 941 Hz

Skupina vysokých frekvencí. 1209 Hz 1336 Hz 1477 Hz 1633 Hz 1 2 3 A 4 5 6 B 7 8 9 C * 0 # D

Zdroj: ITU-T: Recommendation Q.23, http://www.itu.int/rec/T-REC-Q.23/en/T-REC-Q.23-198811I!!PDF-E-2.pdf, 1990, str. 2

1.5. Analogová faxová komunikace Analogová technologie byla rovněž použita k přenosu faxových zpráv, kdy na základě dohody signalizačního protokolu došlo k modulaci obsahu faxové zprávy a následném přenosu přes analogové médium. 2

Domovská stránka ITU-T a struktura členění vydaných technických doporučení od A-Z jsou popsány 12

Přenos faxu se rovněž postupně vyvíjel, přenos byl standardizován pod názvy Group 1, 2, 3 a dále. Nejrozšířenější faxový přenos byl postaven na třídě Group 3 dle doporučení ITU-T T.30. Faxy podporující G3 případně G4 jsou provozovány hojně i dnes. Proto se k přenosu faxových zpráv přes TCP/IP síť používají tzv. faxová relé. Funkce faxového relé dle ITU-T T.38 umožňuje přenos faxu dávkovým způsobem v dohodnuté rychlosti přes TCP/IP prostředí. T.38 nahrazuje i starší princip faxového relé T.37, který přenášel faxovou zprávu pomocí SMTP protokolu, kdy zpráva byla kódována v grafickém formátu TIFF [3].

1.6. Digitalizace veřejných telefonních ústředen Na straně veřejných telefonních ústředen byl proveden v 80. letech 20. století revoluční krok, který znamenal náhradu analogových reléových ústředen za digitální. Původní reléové ústředny byly obrovských rozměrů s nekonečnými řadami spojových relé náchylných na mechanické poruchy. Tyto negativní vlastnosti byly nástupem nové digitální technologie odstraněny. Vedle problémů se spolehlivostí daných spojováním pomocí mechanických relé, přestaly analogové spojovací uzle poskytovat dostatečnou přenosovou kapacitu. Spojovací uzle byly původně spojeny tisíci páry fyzických vodičů. Přidávání dalších vodičů bylo složité, drahé a neefektivní. Proto byla vyvinuta nová generace telefonních ústředen, které přešly z reléového spojování na digitální. Ústředny byly postaveny na digitálním jádru tvořeného sběrnicí. Digitalizace umožnila využít technologii časového multiplexingu (TDM) k agregaci a přepínání spojů na interní sběrnici ústředny. Díky tomuto kroku začaly ústředny podporovat nejen stávající analogová, ale i nová vysokokapacitní digitální rozhraní využívající paralelní přenosy na bázi multiplexingu. Digitalizace byla daná převodem analogového signálu na digitální a naopak. Analogový signál se v daném intervalu vzorkoval, moduloval a přenášel do nul a jedniček. Standardní analogový hlasový signál jednoho telefonu je běžně kódován v 8000 analogových vzorcích za sekundu, každý v 8 bitech dává dohromady digitalizovaný tok o rychlosti 64 kbit/s. Tento základní princip modulace/demodulace je definován pod názvem Pulse Code Modulation (PCM).

na http://www.itu.int/ITU-T/publications/recs.html 13

Takto digitalizovaný výstup je obecně známý pod pojmem Digital Signal 0 neboli DS0. Jeho násobky se staly základem pro přenos dat na bázi TDM. TDM umožnilo agregovat tyto DS0 kanály do virtuálních trunků, vkládat je, vyjímat a přepínat. TDM umožnilo zavést nová komunikační rozhraní a v nich agregovat hlasová spojení na základě paralelních logických kanálů. Paralelní logické kanály byly přenášeny kombinací time-slotů a rámců. Příkladem technologie TDM je v Evropě široce rozšířené rozhraní E1, na americkém kontinentu T1 a v Japonsku J1. TDM rozhraní specifikují doporučení ITU-T G.703, G.704 a G.723, dále ANSI T1.102 a T1.107. Agregace kanálů postavených na DS0 s mapováním na fyzická rozhraní typu Tn/En uvádí následující tabulka. Tabulka č. 2: Agregace a mapování DS0 kanálů DS0 DS1 DS3

Rozhraní = T0 = T1 = T3

Kapacita (kbit/s) 1x DS0 64 24x DS0 1544 28x DS1 44736

Rozhraní E0 E1 E3

Kapacita (kbit/s) 1x E0 64 30x E0 2048 16x E1 34368

Zdroj: Dave Waren, Dennis Hartmann: Building Cisco Metro Optical Networks (METRO), Cisco Press, 2008 str. 40, 41 a 46.

1.7. Telefonní ústředny v organizacích a podnicích Pokročilá telefonie se prosadila do sektoru organizací a podniků, kdy tyto subjekty si zavedly vlastní privátní telefonní ústředny (PBX). PBX jim umožnily efektivnější interní komunikaci, poskytly rozšířenou sadu hlasových služeb, zajistily nezávislost na poskytovateli a snížily útratu finančních prostředků za pravidelné platby. S postupným vývojem se PBX začaly připojovat do veřejné telefonní sítě (VTS) přes digitální trunková rozhraní a začaly poskytovat účastnická digitální telefonní rozhranní koncovým uživatelům. Prvními digitálními rozhraními k připojení ústředny do VTS byly technologie TDM E1/T1 R2/CAS, i v současnosti stále běžnými typy jsou E1/T1 ISDN PRI a ISDN BRI. Rozhraní ISDN BRI bylo historicky využito k připojení uživatelských telefonů. Díky omezené funkční sadě se však k připojení telefonů již nepoužívá. ISDN BRI je i dnes často využito k připojení hlasových bran, faxů nebo hlasové pošty. Jelikož signalizační složka ISDN obsahuje jen omezenou sadu hlasových služeb, byla tato technologie pro vnitropodnikovou komunikaci optimalizována a rozšířena předními výrobci hlasových komunikačních systémů. Proto k připojení telefonů byla vyvinuta 14

řada proprietárních digitálních účastnických rozhraní s rozšířenou signalizací jako jsou např. Siemens U200, Siemens Up0e, Alcatel ABCD vycházejících ze standardu ISDN BRI. Příkladem podnikové telefonní ústředny může být systém Siemens HiPath 4000 [20]. Nezapojená telefonní ústředna Siemens HiPath 4000 je na následujícím obrázku. Obrázek č. 1: Nezapojená telefonní ústředna Siemens HiPath 40003

Zdroj: Siemens Enterprise Communications, popis autor

K propojení a spolupráci PBX různých výrobců v rámci organizace nebo firmy byl vyvinut standard QSIG, který rovněž vychází z ISDN. Důvodem je to, že služby ISDN jsou primárně určeny pro komunikaci s VTS, QSIG navíc obsahuje rozšířenou sadu uživatelských hlasových služeb pro vnitropodnikovou komunikaci, které nejsou v ISDN dostupné.

QSIG

Manufacturers

3

byl

prvotně

Association

specifikován

(ECMA),

dále

organizací byla

European

doporučení

Computer

transformována

Obrázek ukazuje HiPath 4000 s jednou řídící jednotkou a dvě šasi pro periferní karty. Periferní karty obyčejně obsahují 24 analogových účastnických portů, digitálních účastnických portů nebo dvojici E1 ISDN PRI/CAS trunkových portů. Maximální výstavba jediného systému až pro 12000 uživatelů, v síťové konfiguraci lze připojit až 100000 uživatelů. 15

do mezinárodních standardů ISO/IEC, ETSI. Přehled standardizovaných hlasových TDM rozhraní uvádí následující tabulka. Tabulka č. 3: Nejčastější TDM rozhraní Rozhraní E1 CAS R2 ISDN BRI (EU) E1 ISDN PRI E1 QSIG QSIG (BRI)

Evropa Kanály 30 2+1 30 + 1 30 + 1 2+1

Signalizace In-band Out-of-band Out-of-band Out-of-band Out-of-band

Rozhraní T1 CAS ISDN BRI (US) T1 ISDN PRI T1 QSIG QSIG (BRI)

Severní Amerika Kanály Signalizace 24 In-band 2+1 Out-of-band 23 + 1 Out-of-band 23 + 1 Out-of-band 2+1 Out-of-band

Zdroj: Donohue Denise; Mallory David; Salhoff Ken: Cisco Voice Gateways and Gatekeepers, Cisco Press, 2006, str. 108

Rozmach digitálních účastnických a trunkových rozhraní začal postupně vytlačovat analogová trunková rozhraní. Z důležitých vlastností digitálních rozhraní jsou spolehlivost a čistota hlasového přenosu, protože analogové vedení je obecně náchylné na rušení. Rušení signalizace způsobuje chyby, které mohou mít za následek výpadky volání. Rušení se může přenášet i do hovoru samotného, kde způsobuje negativní vlivy jako šum, praskot, echo nebo bručivý zvuk.

1.8. Změny v připojení do VTS Postupně došlo k digitalizaci přenosové páteře veřejné hlasové sítě (VTS). Změny probíhaly v 80. a 90. letech 20. století. Spojení mezi spojovými uzly tvořená tisíci páry fyzických vodičů byla postupně nahrazena logicky agregovanými spoji se strukturou virtuálních kanálů digitálních trunků. Trunky byly postaveny na rozhraních E1/T1, E3/T3, které byly dále agregované do více kapacitních rozhraní typu ATM nebo SONET/SDH. Digitalizace také znamenala přechod komunikační páteře z čistě metalického vedení na optické spoje, které poskytly vysokou odolnost vůči rušení, přenos na dlouhou vzdálenost a důležitou kapacitu. Optická spoje jsou obecně ideálním médiem pro vysokorychlostní, spolehlivé páteře propojující komunikační uzly.

1.9. Vysokorychlostní páteře poskytovatelů Hlasové páteře poskytovatelů byly postaveny primárně na technologii ATM nebo SONET/SDH bez ohledu na to, zda-li se jedná o přenášená data, hlas nebo video.

16

Technologie ATM má obyčejně topologii typu mesh nebo částečný mesh. Technologie ATM mapovala hlasové E1/T1 E3/T3 kanály na logické virtuální kanály (VC). Jednalo se o dynamicky sestavené přepínané virtuální kanály (SVC) v okamžiku iniciace telefonního volání nebo permanentní virtuální kanály (PVC), které byly permanentně sestavené a rezervované k přenosu hlasového hovoru. Ve své době byla technologie ATM značně rozšířená diky své multi-protokolové podpoře, přenosu na dlouhé vzdálenosti, rozhraními o různých kapacitách typu OC-n, garanci kvality služeb a nativní podpoře přenosu dat, hlasu a videa. Technologie ATM je dnes na ústupu, protože byly vynalezeny efektivnější multi-protokolové technologie s nižší režií přenosu. Technologie SONET/SDH se od ATM trochu liší. Technologie má topologii jednoho nebo více propojených kruhů a pracuje s násobky DS0 kanálů. V tomto prostředí se DS0 kanály se rovnají TDM timeslotu. SDH umožňuje agregaci E1/T1 nebo E3/T3 rozhraní. Hlasová spojení byla mapována na DS0 kanály, ty pak byly logicky propagovány a přenášeny přes SONET/SDH páteř. Technologie umožňuje v hraničních zařízeních optické páteře vkládat nebo vyjímat kanály (add-drop multiplexing) a ty pak mapovat do požadovaných TDM rozhraní. Náhled na vysokokapacitní rozhraní sítí poskytovatelů uvádí následující tabulka. Tabulka č. 4: Vysokokapacitní rozhraní poskytovatelů Optical Carrier OC-48 OC-96 OC-192 OC-768c

SONET/SDH STS-48/STM-16 STS-96/STM-32 STS-192/STM-64 STS-768c/STM-256c

Rychlost 2488,32 Mbit/s (2,5 Gbit/s) 4976,64 Mbit/s (5 Gbit/s) 9953,28 Mbit/s (10 Gbit/s) 39813,12 Mbit/s (40 Gbit/s)

Přenos POS, DPT POS, DPT POS, DPT POS, DPT

Zdroj: Waren Dave, Hartmann Dennis: Building Cisco Metro Optical Networks (METRO), Cisco Press, 2008, str. 54 a 56

Technologie je i dnes stále rozšířená díky multi-protokolové podpoře, přenosu na dlouhé vzdálenosti, rozhraním STM-nn o různých kapacitách a kompatibilitě s ATM. Technologie SONET/SDH pro přenos hlasu je rovněž na ústupu, protože jsou modernější a efektivnější optické technologie jako DWDM.

17

1.10. Nástup IP telefonie a Voice over IP Ačkoliv jsou analogové a digitální hlasové technologie stále hojně provozované, prosadil se nový trend hlasové komunikace, kterým je přenos hlasu přes konvergované prostředí na bázi TCP/IP. Konvergovaným prostředím se rozumí LAN/WAN infrastruktura, která umožňuje jednotné připojení koncových zařízení bez ohledu na to, jestli jsou datová, hlasová, video nebo jiná multimediální zařízení. Zařízení jsou jednotně zapojena do LAN přes standardizované rozhraní, provoz je pak transparentně přenášen přes LAN/WAN. LAN technologií je ve většině případů standard Ethernet dle IEEE 802.3 provozovaný v plně duplexním režimu.

1.11. Původní koncept oddělených technologických sítí Na konci 90. let byly v organizacích a podnicích paralelně vybudované komunikační sítě pro data, hlas, případně video. Každá technologie měla vlastní komunikační infrastrukturu. Datové sítě v té době byly postaveny na LAN technologiích Token Ring, FDDI a sdíleném Ethernetu, které vůbec nebo minimálně podporovaly kvalitu služeb (QoS) a následnou prioritizaci kritického provozu. Hlasové sítě byly tvořeny uzly ústředen propojené různými typy TDM rozhraní o kapacitě zvoleného fyzického rozhraní např. T1/E1. Propojení PBX na delší vzdálenost nebo do uzlu VTS

bylo řešeno metalickými spoji položenými v zemi

a HDSL modemy. Video sítě CATV byly tvořeny vlastní kabelovou infrastrukturou postavenou na koaxiálních nebo optických vedeních. První videokonferenční zařízení byla přímo zapojena do infrastruktury veřejného poskytovatele rozhraním ISDN BRI nebo ATM OC-3. Oddělené paralelní hlasové a video technologické sítě byly většinou proprietární, jejich údržba byla drahá a složitá. Oproti tomu dnešní konvergované komunikační sítě používají jednotný komunikační základ TCP/IP postavený na obecných standardech, které zaručují vzájemnou spolupráci.

18

Prvním krokem ke sjednocení datových, hlasových a video přenosů byly změny na straně komunikačních sítí a jejich aktivních prvků, které vyústily v podporu standardů VoATM a VoFR – tehdejších majoritních komunikačních technologií ATM a Frame Relay ve WAN. Obě dvě technologie využívaly svojí L2 transportní síť k přenosu dat a hlasu, oddělení bylo provedeno na základě virtuálních kanálů (VC). S nástupem multi-protokolových sítí typu MPLS provozovanými nad různými typy fyzických médií bylo jasné, že univerzálním přenosovým mechanizmem nezávislým na fyzické technologii transportní sítě se stane VoIP fungující na L3 úrovni IP protokolu.

1.12. VoIP Globalizace vedla k propojování telefonních ústředen a koncových hlasových zařízení prostřednictvím TCP/IP. Ve VoIP je hlasový provoz podobně jako mezi analogovým a telefonním digitálním rozhraním vzorkován a modulován do nul a jedniček. Kódován je však přímo do IP paketů, nikoli do rámců transportní technologie jak tomu bylo v případě VoFR nebo VoATM. Ve VoIP je opět použit ověřený mechanizmus PCM nebo jeho další deriváty. Hlas je kódován a následně zapouzdřen do RTP protokolu, přenášen v segmentu transportního protokolu UDP a směrován ve formě IP paketu. Požadavky na VoIP byly dány globalizací světového trhu, kdy firmy a organizace si potřebovaly vyměňovat informace transparentním, nejefektivnějším způsobem a to bez ohledu na typ použité transportní přenosové sítě. VoFR a VoATM byly účinné jen v rámci mraku své technologie, jinak muselo dojít k složitému mapování služeb na jiné technologie. Proto díky své složitosti a vysoké režii tyto technologie téměř zanikly.

1.13. Současnost Z pohledu multimediálního provozu se prosazuje termín Unified Communications, kdy sjednocená komunikace obsahuje různorodé složky provozu a uživatelských služeb. Telefonní zařízení se stávají univerzálním komunikačním prostředkem, mohou obsahovat velké barevné displeje typu QVGA/VGA, uživatel je může použít k volání webových služeb, aplikací postavených na HTTP/SOAP/XML nebo přehrávání obrázků a videa. Na druhé straně integrace hlasu a videa se prosazuje do uživatelských desktopů, kdy IP telefonie, video a přenos zpráv se stávají dalšími aplikacemi komunikační sítě. Tato integrace je směřována i na mobilní telefony. 19

1.13.1.Komunikační sítě z pohledu L2 a L3 Komunikační sítě jsou současnosti postaveny na multiprotokolových komunikačních sítích typu IP/MPLS. IP/MPLS používá k přenosu dat v rámci svého komunikačního mraku IP pakety doplněné o MPLS značku. Tyto značky se používají v celé MPLS síti k rychlému přepínání provozu, jeho logickému oddělení (MPLS VPN) a směrování k cíli tou nejvhodnější cestou (MPLS TE). Hraniční uzly MPLS sítí různých poskytovatelů jsou postaveny na výkonných MPLS-enabled směrovačích, které mapují provoz do jiných MPLS sítí nebo ho směrují do požadovaných destinací mimo MPLS oblak. Typickým směrovacím protokolem je BGP [8].

1.13.2.Komunikační sítě z pohledu L1 a L2 Přenosová jádra těchto sítí jsou postavena na optických kruhových topologiích. Základem je DWDM využívající multiplexing o různých vlnových délkách světelného spektra. Další optickou přenosovou technologií je DTP, které vytváří hierarchii přenosových kruhů na národní nebo mezinárodní úrovni. Kruhy jsou na sebe navzájem napojeny, na jejich hranicích dochází k agregaci provozu, přenosová kapacita jednotlivých kruhů je dána kapacitními požadavky na provoz odvozenými z agregace odpovídající úrovně hierarchie kruhové sítě. DWDM je hojně používáno v prostředí podnikových sítí k propojení datových center, kdy je možné díky světelným paprskům o různých vlnových délkách slučovat a paralelně přenášet různé typy fyzických médií například OC-192/STM-64 (10Gbit/s), 10GbE a 10G Fibre Channel a DS3/E3 [15]. Na straně měst a regionů vznikají účelově vytvořené metropolitní sítě MAN postavené na technologii Metro Ethernet. Díky vysokokapacitním rozhraním Ethernet a Metro Ethernet zařízením optimalizovaným pro řešení poskytovatelů, je možné připojovat koncové subjekty technologií. Jádra těchto sítí tvoří pospojované části technologií 10GbE, 40GbE nebo případně nově se prosazujícím 100GbE4.

4

Autor vychází ze svých znalostí a zkušeností. Autor vlastní řadu platných certifikátů výrobce komunikačních technologií Cisco včetně CCDP, CCNP, CCSP, CCIP a CCVP. 20

2. IP telefonie a Voice over IP IP telefonie a VoIP jsou uznávanými trendy hlasové komunikace. Ačkoliv se o IPT/VoIP mluví jako o samostatné části, jedná se pouze o jeden typ ze skupiny multimediálních služeb. Multimédia jsou jako méně či více integrovaný celek přenášeny přes konvergovanou komunikační infrastrukturu.

2.1. Technologická změna S přechodem z klasických, telefonních ústředen na čisté řešení IP telefonie dochází ke změně použitých komponent. Klasické telefonní ústředny jsou nahrazeny centrálním, řídícím serverem IP telefonie využívající signalizaci SIP případně H.323. Analogové a digitální telefony jsou nahrazeny IP telefony. K připojení analogových rozhraní faxů jsou doplněny analogové převodníky, připojení do VTS je řešeno přes dedikované brány s IP SIP / ISDN PRI rozhraními. Základní porovnání mezi řešením hlasové komunikace postavené na klasické telefonní ústředně a IP telefonii ukazuje následující obrázek. Obrázek č. 2: Porovnání mezi řešením s telefonní ústřednou a IP telefonií

Legenda: VTS – veřejná telefonní síť Mobil – síť mobilního operátora E1 PRI, E1 CAS – Digitální trunková rozhraní BRI, nebo FXO – Digitální nebo analogová trunková rozhraní E1 QSIG – Digitální vnitro-firemní trunk PBX – pobočková ústředna ÚP0E a FXS – Digitální a analogová účastnická rozhraní Brána – hlasová brána LAN – lokální síť Zdroj: Autor 21

Výše uvedený obrázek jasně ukazuje hlavní technologické rozdíly. Původní digitální trunkové technologie musely být přímo propojeny mezi ústřednami nebo vedeny do VTS přes dedikovaná rozhraní na bázi TDM. Vzdálenost byla často prodloužena optickými převodníky nebo HDSL modemy. IP telefonie na proti tomu vyžaduje pouze jednotné

připojení

do

geograficky

rozprostřené,

konvergované,

komunikační

infrastruktury. Ta však musí být nastavena k podpoře kvality služeb a definována politika CAC. Původní koncová zřízení byla postavena na digitální a analogové technologii, v řešení IP telefonie se používají výhradně IP telefony.

2.2. Unified Communications Hlas je obsažen, doplňuje nebo přímo souvisí s řadou dalších multimediálních služeb jako jsou video, textové zprávy, hudba, sdílení dokumentů stav prezence a multimediální konference. Mezi tyto služby dále patří hlasová pošta, faxová komunikace přes IP, interaktivní hlasový strom, dostupnost pod jediným číslem a výběr preferovaného zařízení. Pro tyto sjednocené typy komunikace se zavádí pojem – Unified Communications. Ve výsledku se očekává, že uživatelé budou používat Unified Communications jako celek, vybírat si z něj nejvhodnější a nejefektivnější cestu k přenosu informace k cíli, případně budou přenosové prostředky vhodně kombinovat. Vedle použití specifických komunikačních zařízení (IP telefony, videokonferenční kity, mobily) je cílem integrovat tyto služby do uživatelského prostředí osobního počítače. IP telefonie a VoIP se běžně integrují do videokonferenční zařízení, přibrat do video konference účastníka používající IP telefon je základní funkcí videokonference. Rovněž řada monitorovacích, kamerových systémů typu CATV nebo dveřních systémů obsahují integrovaný mikrofon, reproduktor a VoIP rozhraní. Následně je možné tento typ provozu propojit do hlasového komunikačního systému. Těsná integrace multimediálních složek může být provedena nejen použitím univerzálních komunikačních zařízení, univerzálního přenosového média ale i za použití univerzálních, standardizovaných, signalizačních a přenosových protokolů.

22

Náhled na rozdělení komunikačních prostředků na dedikované, hardwarové/softwarové a univerzální softwarové s univerzální aplikací ke komunikaci ukazuje následující obrázek. Obrázek č. 3: Dedikované a univerzální přenosové prostředky

Zdroj: Autor

Obrázek výše ukazuje na levé straně specializované hardwarové/softwarové komunikační prostředky a jejich rozdělení podle svého účelu. Prostředky jsou většinou hardwarově optimalizované k zajištění patřičné kvality a výkonu. Na pravé straně jsou zobrazeny univerzální komunikační prostředky tvořené standardním PC/NB nebo mobilním zařízením s podporou multimediálních aplikací. V prostředku je umístěna konvergovaná komunikační síť postavená na základech TCP/IP. Dále se tam nachází konvergovaná multimediální infrastruktura, kde je soustředěna logika multimediálních služeb.

23

2.3. Mobilní technologie IP telefonie a VoiP jsou postupně integrovány do dalších specifických oblastí komunikační infrastruktury, jako jsou mobilní technologie. Mobilita je důležitým předpokladem k rozvinutí Unified Communications. Typickým příkladem je použití mobilních technologií v prostředí firemních sítí, kde jsou vybudovány vazby na infrastrukturu Wireless IEEE 802.11. Zde byla zavedena řada standardů umožňující přenos hlasu na základě IP protokolu včetně podpory QoS (IEEE 802.11e), roamingu (IEEE 802.11r) a odpovídajícího zabezpečení (IEEE 802.11i). Hlas a další multimediální služby jsou přes bezdrátovou komunikační infrastrukturu doručeny až do koncového zařízení. Dále bylo umožněno napojení na infrastrukturu Cordless DECT/GAP, kdy nejnovější základnové stanice – BS pracující v režimu IP DECT a podporují SIP. BS umožňuje překlad IP hlasového provozu z pevného Ethernet rozhraní na bezdrátový DECT. IP síť je vedena až do základnových stanic, pro koncové bezdrátové telefony DECT se nic nemění. Typickým příkladem napojení na operátorské sítě jsou mobilní sítě GSM 3G/4G kombinující hlasové a datové přenosy, v případě datových přenosů se jedná o GPRS, UMTS, CDMA a EDGE. Moderní mobilní telefony podporují instalaci mimi-aplikace, které umožní doručit rozhraní uživatelských služeb UC až na displej mobilního telefonu. Uživatel tak může přes rozhraní mini-aplikace měnit stav prezence, volit preferované zařízení komunikace – to vše pod jediným telefonním číslem. Dále dochází k nasazování technologie WiMAX, kdy podpora rozhraní WiMAX se připravuje do nových typů notebooků [2].

2.4. Protokoly VoIP VoIP je obyčejně nazývána bod-bod interaktivní hlasová komunikace mezi dvěma hlasovými komunikačními systémy nebo mezi jejich komponentami, jakou jsou například hlasové brány tvořící hraniční bod systému. Přenos hlasu je tvořen dvěmi základními složkami. Jedná se o složku hlasové signalizace a hlasových dat. Hlasová signalizace v IP prostředí je standardizována ve dvojici široce uznávaných standardů H.323 a SIP. Hlasová data jsou přenášena ve formě RTP/RTCP. 24

Výčet protokolů a jejich použití s VoIP uvádí následující tabulka. Tabulka č. 5: Protokoly VoIP Účel Hlasová signalizace Přenos hlasových dat

Protokoly SIP, H.323, MGCP RTP/RTCP

Zdroj: Autor

Jak formát signalizace SIP/H.323, tak RTP/RTCP podporují různé typy médií včetně videa a textu. Obecně lze říci, že rozšířením hlasové signalizace a hlasových dat o řadu dalších podpůrných protokolů vznikla protokolová sada IP telefonie.

2.5. Protokoly IP telefonie IP telefonie je postavena na koncových hlasových zařízeních – IP telefonech, které jsou připojeny prostřednictvím LAN rozhraní do LAN sítě a to podobným způsobem jako běžné počítače. IP telefony jsou registrovány a řízeny prostřednictví systému IP telefonie s řídícím serverem. Tento řídící server funguje jako spojovací pole, které přepíná a spojuje koncová hlasová zařízení na základě signalizace. Komunikace mezi řídícím serverem a IP telefony je postavena na signalizačním protokolu. Komunikace mezi řídícím serverem a IP telefony může používat, jak proprietární signalizaci, tak standardizovaný signalizační protokol. Příkladem proprietárních protokolů jsou Siemens CornetIP (HFA), Alcatel ABCD nebo Cisco SCCP. K propojování různorodých hlasových komunikačních systémů přes IP rozhraní a s rozvojem standardizace se používají protokoly SIP a H.323. Dalším standardizovaným protokolem je MGCP, který je určen k ovládání a spojování multimediálních toků na speciálních zařízeních. Jedná se např. o zařízení typu média servery a hlasové brány. MGCP definuje RFC 2705. IP telefonie nepoužívá pouze protokoly RTP/RTCP a SIP/H.323, ale závisí na dalších podpůrných protokolech jako je například DHCP. Výčet běžných protokolů IP telefonie a jejich použití uvádí následující tabulka. Tabulka č. 6: Protokoly IP telefonie Účel

Protokoly 25

Hlasová signalizace Přenos hlasových dat Ovládání bran a média serveru Dynamické přidělování IP adres Jmenná rezoluce Povýšení verze firmware Časová synchronizace Vzdálená správa

SIP, H.323, proprietární RTP/RTCP MGCP DHCP DNS SSH/SCP, SFTP, FTP nebo TFTP NTP HTTP/HTTPS, SNMP, SSH

Zdroj: Autor

Speciálně DHCP je důležité pro IP telefonii, protože IP telefony obdrží dynamicky nejen IP adresu, masku sítě a výchozí bránu, ale i dodatečné informace jako jsou: 

asociace s VLAN,



IP adresa management serveru,



IP adresa úložiště konfigurace IP telefonu.

Výrobci hlasových komunikačních systémů v tomto směru využívají různé přístupy. Například Siemens tímto způsobem vnucuje IP telefonům IP adresu management serveru DLS, který následně vnutí IP telefonu všechna nastavení funkcí a zabezpečení. Siemens v tomto směru používá Vendor-specific atribut Option 43 [11]. V případě řešení Cisco je IP telefonu předána IP adresa TFTP serveru, kde jsou umístěny všechny konfigurace IP telefonů. Cisco používá pro tuto funkci DHCP Option 150 [6]. Náhled na běžné DHCP parametry v IP telefonii uvádí následující tabulka. Tabulka č. 7: DHCP parametry pro IP telefony Účel IP routing / výchozí route 1 & 2 IP adresa SNTP/NTP serveru Nastavení časové zóny IP adresa primárního a sekundárního DNS serveru DNS doménové jméno pro IP telefon IP adresa SIP Proxy a SIP Registrar serveru Vendor-specific parametry (Siemens) IP adresa TFTP serveru (Cisco)

Parametr Option 33 Option 42 Option 2 Option 6 Option 15 Option 120 Option 43 Option 150

Zdroj: Autor

Použití výše uvedených parametrů závisí na konkrétní konfiguraci hlasového komunikačního systému. DHCP Options jsou definovány v rozsahu 1-254 dle RFC 2132.

26

2.6. Signalizace H.323 H.323 vychází z rodiny protokolů H.32X. Rodina protokolů H.32X byla specifikována organizací ITU-T, která definovala standardy pro přenos, hlasu, videa i textu. Jedná se o následující standardy. Tabulka č. 8: Protokoly VoIP Typ Protokoly H.320 přenos hlasu a videa přes ISDN H.321 přenos hlasu a videa přes B-ISDN (ATM) H.322 Přenos hlasu a videa přes sítě s QoS H.323 Přenos hlasu a videa přes IP sítě H.324 Přenos hlasu a videa přes analogová rozhraní Zdroj: Donohue Denise; Mallory David; Salhoff Ken: Cisco Voice Gateways and Gatekeepers, Cisco Press, 2006, str. 37

Z pohledu VoIP je důležitý pouze typ H.323, protože VoIP je přenášen přes IP infrastrukturu. H.323 byl vytvořen v roce 1996, v současnosti je značně rozšířená verze 4, poslední verze 6 byla uvolněna v roce 2006. H.323 je robustní, složitý signalizační protokol, který zahrnuje celou řadu podprotokolů včetně nejdůležitějších H.225, H245 a H.225 RAS. H.232 vychází z ISDN signalizace, kdy signalizační příkazy ISDN Q.931 a H.225 používají stejnou syntaxi [1].

2.6.1. H.323 komponenty Z pohledu komponent využívajících H.323 je jejich členění následující: 

terminály – hlasová nebo video koncová zařízení (telefony, video konferenční zařízení),



brány – rozhraní do jiných typů sítí nebo ke konverzi protokolů (ISDN, SIP protokol),



gatekeeper – zařízení pro vnucení centrální politiky přenosu,



multipoint control unit (MCU) – zařízení pro vytváření konferencí (mixování přenosů).

2.6.2. Terminály Použití signalizace H.323 v terminálech typu IP telefon je méně obvyklé. Důvody jsou takové, že H.323 je objemný a složitý protokol, komerční telefonie potřebuje širokou skálu uživatelských hlasových služeb, standardizační organizace neumí pružně přizpůsobit signalizační protokoly posledním trendům. 27

Proto přední výrobci hlasových technologií jako Siemens, Cisco, Avaya, Alcatel-Lucent na používali v posledních letech mezi IP telefony a řídícím serverem vlastní proprietární protokoly jako Siemens CorNetIP, Cisco SCCP nebo Alcatel ABCD, kdy mohli rychle a efektivně měnit programový kód signalizace. S postupem tlaku na standardizaci však proprietární protokoly ustupují, široce uznávaným standardem se stává SIP. Všichni tito výrobci migrují nebo již migrovali své proprietární protokoly na SIP. Samozřejmě k propojení systémů různých výrobců podporují tito výrobci protokoly H.323, SIP, QSIG nebo ISDN. Jiná situace je s video zařízeními. Většina video terminálů a MCU používá signalizaci H.323. Avšak s rozmachem videotelefonie a požadavkem přenosu videa mezi hardwarovými videokonferenčními zařízeními a softwarovými videoklienty se opět prosazuje protokol SIP. Proto přední výrobci vedeokonferenčních zařízení integrovali do svých řešení SIP. Příkladem těchto řešení můžou být produkty výrobců Tandberd (akvizice Cisco), Polycom nebo LifeSize.

2.6.3. Brány Brány jsou hraničním rozhraním mezi různými typy sítí, kde jsou komunikaci obyčejně vnucena pravidla směrem ven/dovnitř. Rovněž tam může docházet ke konverzi, normalizaci a verifikaci procházejících protokolů příkladem může být přechod na rozhraní ISDN, ATM, analogové nebo IP SIP. Brána může být samostatné dedikované zařízení nebo i samotná PBX.

2.6.4. Gatekeeper Úloha gatekeeperu je centrální bod pro vnucení politiky komunikace přes konvergovanou komunikační síť. Použití gatekeeperu je v případě, že je v síti velké množství bran a kdy se stává jejich konfigurace složitá. V případě použití gatekeeperu se konfigurace bran centralizuje. Brány komunikují s gatekeeperem protokolem H.225 RAS. Gatekeeper typicky zajišťuje funkce: 

překlad čísel v E.164 formátu na IP adresy,



povolení přístupu do sítě (RAS),



kontrola přenosového pásma (CAC), 28



administrace zón.

Brány komunikují s gatekeeperem protokolem H.225 RAS. H.225 RAS je kódován v ASN.1.

2.6.5. MCU MCU primárně řídí a spojuje komunikaci mezi více účastníky. Často dále nepracuje jenom se signalizačním protokolem, ale i multimediálními daty. V případě video konferencí konvertuje a mixuje různé typy kódovaných video signálů.

2.6.6. Rodina protokolů H.323 H.323 je celý soubor protokolů. Primárně lze dělit H.323 na část: 

signalizace,



přenosu multimediálních dat .

Signalizace zahrnuje: 

kontrolu spojení H.225 Q.931,



spojení s gatekeeperem H.225.1 RAS,



signalizace k přenosu multimediálních dat H.245.

Přenos multimediálních dat je zajištěn pomocí: 

hlasových kodeků G.711, G.729, G.722, atd.,



video kodeků H.261, H.263, H264, atd.,



textového přenosu dle T.120 [3].

V současnosti se používají efektivnější metody přenosu textu než s použitím T.120.

2.7. Signalizace SIP SIP protokol byl standardizován standardizační organizací IETF v úvodním RFC 3261, které bylo následováno řadou dalších RFC definující nové vlastnosti. SIP protokol vychází z prostředí protokolů aplikační vrstvy datových sítí. Řídící kódy zpráv jsou podobné s protokoly HTTP, SMTP a dalšími. Tento princip zpráv je použit i pro signalizaci přenosu hlasu. Síla SIP je dána jednoduchými zprávami a podporou metod typu REGISTER, INVITE, ACK, BYE CANCEL, OPTIONS, REFER, SUBSCRIBE, NOTIFY, MESSAGE

29

a PUBLISH. Především poslední metody umožnily integrovat do SIP řadu dalších multimediálních služeb. Tyto metody jsou popsány v samostatných RFC. K indikaci stavů používá SIP intuitivní kódy 1xx-6xx známé u HTTP, FTP, POP3, atd. např. 200 – success message. Proto je snadné SIP protokol snadno monitorovat, sledovat důvody a příčiny potencionálních chybových stavů, volat ho z namíru vytvořených programů a aplikací [5]. SIP protokol je jednoduchý díky své ASCII podobně, proto je ho snadné implementovat do mobilních zařízení, používat ho nejen k signalizaci hlasu, videa ale i pro textové zprávy ve formě Instant Messagingu (IM). SIP protokol v poslední době zažívá obrovský rozmach protože většina předních výrobců komerčních hlasových komunikačních systémů včetně Siemens, Cisco, Avaya a Alcatel-Lucent chápou nutnost spolupráce a kompatibility při propojení systémů se zachováním maximální škály uživatelských služeb. Použití SIP umožňuje integraci nových forem komunikace, poskytuje širší nabídku služeb a možnosti k začlenění do prostředí uživatelského počítače. SIP protokol se stává univerzálním signalizačním základem pro celou multimediální skupinu služeb Unified Communication. Díky jeho univerzálnosti se napojují do řešení další výrobci včetně Microsoft a IBM a chtějí proniknout do multimediálního segmentu trhu [9].

2.7.1. SIP komponenty SIP terminologie se podstatně liší od H.323. SIP nazývá koncová zařízení jako User Agents (UA) dále členěná jako: 

User Agent Client (UAC) – komponenta iniciující SIP požadavek – typicky IP telefon nebo řídící server,



User Agent Server (UAS) – komponenta odpovídající na SIP požadavek – typicky IP telefon nebo řídící server,



Back-to-back User Agent (B2BUA) – komponenta přijímající požadavek a posílající dál vlastní požadavek – hlasová brána, session border controller nebo i řídící server.

Řídící server obyčejně obsahuje funkce SIP Proxy serveru, SIP Redirect serveru, SIP Registrar serveru a SIP Location Serveru. Funkce poskytují informace ke směrování 30

hlasových dat přes IP síť, ověřování komunikujících zařízení, informaci o způsob dosažení cílových komponent [11]. V terminologii se používá název SIP brána pro hraniční zařízení s rozhraním do sítí ISDN, QSIG, H.323 nebo SIP. Termín gatekeeper se v SIP signalizaci nepoužívá.

2.7.2. SIP/SIMPLE SIP protokol a jeho rozšíření v módu SIMPLE (Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions) se používá pro službu přenosu textových zpráv – Instant Messaging (IM) a k přenosu uživatelské prezence. Rozšíření SIP/SIMPLE bylo popsáno v řadě RFC navazujících na úvodní RFC 3261. Funkci prezence v SIP protokolu definuje RFC 3856. Funkci IM v SIP definuje RFC 3428. IM používá SIP zprávy MESSAGE. Prezence používá SIP zprávy SUBSCRIBE a NOTIFY. SIP/SIMPLE používají např. produkty Microsoft OCS a Cisco UCM. Siemens oproti tomu používá standardizovaný protokol Extensible Messaging and Presence Protocol (XMPP), který byl dříve nazýván Jabber. SIP/SIMPLE je proti XMPP jednodušší a má menší přenosovou režii, protože jsou zprávy kódovány pomocí SIP metod v SIP protokolu. Zprávy v XMPP jsou kódovány pomocí XML.

2.7.3. Rodina protokolů SIP O SIP nelze říci, že se jedná o rodinu protokolů jako v případě H.323, ačkoliv obsahuje celou řadu navazujících standardů. V sobě obsahuje například protokol SDP, v kterém dohodne parametry multimediálního přenosu a dohodnuté kodeky typu G.711, G.729, G.722, atd. SIP se používá pro služby typu Instant Messaging a prezence ve formě SIP/SIMPLE. SIP využívá bezpečnostních mechanizmů včetně TLS (SIP-TLS).

2.8. Hlasová data Hlasová data jsou kódována/dekódována pomocí kodeku – CODEC (Coder-Decoder), která

jsou

následně

zapouzdřena

do

jednotlivých

segmentů

odpovídajících

vzorkovacímu intervalu. Datům je přidána RTP hlavička, identifikující parametry hlasových dat. Vedle hlasových dat jsou posílány řídící informace ve formátu RTCP. RTP a RTCP je dále zapouzdřeno do transportního protokolu UDP. 31

Média jsou vždy zapouzdřena do protokolu UDP, protože TCP přidává zbytečnou režii. Dále přeposílání ztracených hlasových dat ze spojení nemůže být účelně využito, protože se jedná o real-time provoz a ztracený paket je přeposlán pozdě a již nebude k užitku. SIP signalizace používá většinou transportní protokol UDP. Výjimkou v použití UDP je důvod zabezpečení signalizace mechanizmem TLS, který podporuje přenos pouze ve formě transportního protokolu TCP. Některé komunikační komponenty rovněž transformují SIP do transportního protokolu TCP a to z důvodu přenosu signalizace přes prostředí nezajišťující kvalitu služeb. RFC 3261 podporuje obě transportní formy. RTP/RTPC je definováno ve standardu RFC 1889. RTP používá pouze liché UDP porty, kdežto RTCP jenom sudé. UDP porty jsou dynamicky navazované během iniciace hlasového spojení. Dohodnutí parametrů je provedeno prostřednictvím hlasové signalizace. Použité UDP porty, typ média, IP adresy komunikující stran, kodek, přenos DTMF a další parametry jsou dohodnuty například prostřednictvím protokolu SDP, který je obsažen v SIP a MGCP. V případě H.323 jsou dohodnuté komunikační porty UDP dohodnuty v H.245 [14].

2.9. Kódování hlasu Mezinárodní autority vytvořily řadu doporučení ke kódování/dekódování hlasu. Nejznámější jsou doporučení ITU-T G.711, G.729 A/B, G.723, G.726 a G.728. Kodek G.711 byl jeden z prvních standardizovaných mechanizmů kódování hlasu, který vycházel ze základu PCM. Tento kodek nepoužívá kompresi. Jeho výhodou je dobrá kvalita hlasu, široká podpora v hlasových zařízení, na druhou stranu díky zapouzdření RTP/UDP/IP má vysokou režii při přenosu, proto jeho použití je primárně určeno do prostředí LAN, kde kapacitní omezení nejsou problémem. Komprimované kodeky typu G.729A/B nebo G.723.1 obsahují řadu optimalizací včetně funkcí komprese, což je důležité pro efektivní hlasový přenos v prostředí WAN. Různě dokonalé metody komprese a jejich účinnost však snižují celkovou kvalitu hlasu a vytvářejí v komunikaci zpoždění. Náhled na seznam nejběžnějších kodeků ukazuje následující tabulka.

32

Tabulka č. 9: Seznam nejběžnějších kodeků Kodek G.711 PCM G.722 G.729 G.729 Annex A G.729 Annex B G.723.1r53 G.723.1r63 G.726 ADPCM G.728 LD-CELP iLBC AMR GSM EFR GSM FR RTAudio (Microsoft)

Tok v kbit/s 64 64 8 8 8 5,3 6,3 32 16 15,2 12,2 12,2 12,2 8,8 nebo 18

Hodnota MOS 4,1 4,5 3,92 3,7 3,7 3,65 3,9 3,8 3,6 4,14 4,14 3,8 3,5 není známo

Zdroj: Siemens Enterprise Communications: SOCP Study Guide: Open & Converged Network Consultant HiPath 8000, Siemens Enterprise Communications GMBH & CO. KG, 2008, str. 42

Hodnota přenosu v kbit/s ukazuje čistý generovaný tok kódování. Hodnota neobsahuje režii transportních protokolů RTP/UDP/IP + protokol média (např. Ethernet). MOS – Mean Opinion Score je mírou kvality generovaného hlasového signálu. MOS vychází z doporučení ITU-T P.800. Hodnocení MOS uvádí následující tabulka. Tabulka č. 10: Hodnocení MOS MOS hodnota 5 4 3 2 1

Kvalita Excelent Good Fair Poor Bad

Vliv na hlas Neslyšitelný vliv Slyšitelná vliv ale vyhovující Jemně degradovaná kvalita Hodně degradovaná kvalita Vyloženě špatná kvalita

Zdroj: ITU-T P.800 http://www.itu.int/rec/T-REC-P.800-199608-I/en/T-REC-P.800-199608-I!!PDF-E2.pdf, 1998, str.11

2.9.1. Problémy s kódováním Komprimované hlasové kodeky nelze používat k přenosu faxových zpráv, protože faxový přenos používá signalizační zprávy, které jsou přenášeny v řadě různých tónů. Komprimované hlasové kodeky degradují kvalitu těchto tónů, komunikující strany se pak spolu nedomluví a faxový přenos se neuskuteční. Přenos faxových zpráv proto musí být kódován v nekomprimovaném G.711 nebo pomocí tzv. Clear-channel kodeku případně převeden do jiné formy dat přes T.38 nebo T.37 relé. Podobná situace je s přenosem DTMF signalizace například při ovládání interaktivního hlasového stromu, kdy dojde degradaci kvality DTMF tónů a cílové zařízení nepozná DTMF tóny k provedení požadované operace. 33

Řešením je vyjmutí DTMF tónů z hlasového kanálu a jejich přenos v signalizaci. Tato funkce se nazývá DTMF relé a je podporována v radě signalizačních protokolů včetně SIP, H.323 a MGCP. Funkci DFMF relé v SIP a MGCP definuje konkrétně standard RFC 2833, podpora DFMF relé v H.245 kanálu ve formách „alfanumeric“ a „signal“ upravuje samotný standard H.323 [1]. Ze stejného důvodu je nevhodné přenášet pomocí komprimujícího hlasového kodeku hudbu. Ve výsledku budou z hudby zachovány pouze frekvenční rozsahy odpovídající lidskému hlasu. Při použití kodeků platí základní pravidlo použití přiměřeného kodeku pro daný typ multimediální komunikace s ohledem na parametry komprese, kvality, frekvenčního rozsahu a přenosového pásma. Ve výsledku to znamená, že čím je požadováno menší přenosové pásmo, tím je horší výsledná kvalita. Toto pravidlo platí i naopak.

2.9.2. Speciální kodeky Pro kvalitní přenos hlasu v IP telefonii se používá širokopásmový kodek G.722. Pro přenos kvalitní hudby a hlasu se používají kodeky vycházející ze standardu MPEG-2/4. Jejich použití je především u kvalitních videokonferencí nebo v konferenční technologii nazývané TelePresence. Cisco TelePresence např. používá kodek AAC-LD, který kombinuje nejlepší vlastnosti G.722 s MPEG-2/4. AAC-LD vzorkuje frekvenční rozsah v rozmezí 8-96 kHz. Vzorkování je prováděno 48000krát za sekundu, kdy čistý výsledný tok bez režie odpovídá 64 kbit/s v duplexním režimu 128 kbit/s. Kodeky se používají rovněž ke kódování video signálu. Typicky se používají kodeky H.261, H.263/+/++ a H.264. Přenos hlasu a videa může být řízen stejným signalizačním protokolem, ale hlasové a video data jsou přenášena v různých RTP/RTCP tocích [12]. Řada profesionálních nebo polo-profesionálních studií ke zpracování, mixování, vysílání a distribuci hudby zavádí Audio over IP a migruje z analogových a digitálních (TDM) rozhraní na IP. V tomto prostředí se typicky používá více kanálový přenos hudby (typicky 8, 16, 32) s využitím kvalitních kodeků typu MPEG AAC-LD, MPEG AAC-ELD a případně i G.722 (pro hlasové vstupy), kdy volba kodeku může odpovídat účelu a náročnosti kladených na dané kanály [4]. Níže jsou v tabulce uvedeny kodeky dedikované pro AoIP.

34

Tabulka č. 11: Kvalitní AoIP kodeky Kodek MPEG AAC-LD MPEG AAC-ELD

Pásmo vzorkování 20 kHz 20 kHz

Tok 48-64 kbit/s 32-64 kbit/s

Vzorkování 10 ms 20 ms

Popis Full-fidelity Newest

Zdroj: Church Steve, Pizzi Skip: Audio over IP – Building Pro AoIP, Focal Press, 2010, str. 157

Co je rozdílné u AoIP oproti VoIP je, že AoIP není interaktivní jako VoIP a menší zpoždění při přenosu nevadí. Tímto způsobem jsou i konstruovány audio kodeky a upraveny jitter buffery na straně přijímajících zařízení. Samozřejmě pokud spolu přímo komunikují dvě koncová zařízení, musí používat stejný kodek. Pokud se komunikující zařízení nemohou dohodnout na stejném kodeku, musí být zajištěna funkce tzv. transcodingu. Jelikož je transcoding procesorově náročný je tento proces obyčejně zajištěn hardwarovými DSP procesory v dedikovaných zařízeních typu hlasová brána, MCU nebo jiném speciálním zařízení.

35

3. Kvalita služeb Klíčovým předpokladem k provozu multimediálních služeb v prostředí konvergované komunikační sítě je nasazení kvality služeb.

3.1. Předpoklady k zavedení moderních trendů V prostředí LAN byl historicky rozšířen sdílený Ethernet a jeho princip CSMA/CD. Sdílená kolizní doména a kolize na segmentu, byly přijatelné pro aplikace používající transportní protokol TCP, který v případě kolize přeposlal ztracené pakety. V transportním protokolu UDP musela být funkce integrity přenosu provozu zajištěna na vyšších vrstvách OSI modelu. Princip CSMA/CD nebyl slučitelný pro provoz multimediálních přenosů typu hlas nebo video, které vyžadovaly minimální zpoždění a téměř nulovou ztrátovost paketů. Problém kolizí a kolizních domén byl postupně vyřešen nasazením přepínaného Ethernetu. Konkrétně muselo dojít k nahrazení LAN rozbočovačů LAN přepínači. LAN přepínače pracují v plně duplexním režimu, tedy kolize nemohou nastat. Navíc přepínaný Ethernet byl základem ke značení prioritizace provozu a značení VLAN v Ethernet rámci dle IEEE 802.1p/Q. K realizaci multimediálních přenosů musela být nahrazena i technologie Token Ring. Ačkoliv Token Ring umožňoval nastavení prioritního bitu ke komunikaci uvnitř kruhu, tato prioritizace mohla být vhodná jen pro zařízení připojené na stejné médium nikoli pro IP přenos hlasu a videa. Výjimkou byla technologie ATM, která již od začátku podporovala začlenění provozu do tříd CBR, ABR, UBR, VBR-RT, VBR-NRT. Na základě začlenění provozu do třít byly toky rozdělené do cel a přepínány v ATM síti. Třídy CBR a VBR-RT byly primárně určena k přenosu senzitivního přenosu jako je hlas a video. CBR byla určena primárně pro konstantní tok požadující minimální zpoždění a ztrátovost – např. digitalizovaný, spojovaný, hlasový okruh mezi PBX napojený přes E1 rozhraní kódované v PCM. Tento provoz měl přednost při zpracování na backplane v ATM přepínači před ostatními třídami. S příchodem technologií VoATM a následně VoIP byla hlasová data vedena jako data v odpovídajících ATM třídách. VoATM nebyl moc efektivní, protože na všech 36

hraničních bodech ATM sítě muselo dojít ke složitému mapování provozu VoATM do sítí TDM, IP, Frame Relay nebo SDH/SONET. Proto se VoATM nemohl globálně prosadit. Úplně stejný problém postihoval technologii VoFR. Je třeba si uvědomit, že ATM a Frame Relay pracují na L2 ISO OSI. Přenos hlasových dat ve formě VoIP přes ATM síť se ukázal jako značně neefektivní díky vysoké režii dané hlavičkami použitých protokolů včetně RTP/UDP/IP + ATM. Navíc ATM cely jsou malé o pevné velikosti 53 bytů. Ethernet má v porovnání velikost rámce mezi 576-1500 bytů, u WAN protokolů typu PPP, HDLC jsou velikostí rámce ještě větší. Každá ATM cela má svojí hlavičku, každá hlavička přidává další režii. ATM podporovalo kvalitu služeb CoS a mapování CoS na VC, ATM však nebylo primárně určeno k připojení běžných koncových uživatelských stanic. Jenom exponované servery měly přímé připojení přes rozhraní např. OC-3. Stanice byly připojené do LAN přes ATM LANE pomocí prvků sdíleného Ethernetu, tedy opět byl stejný problém daný kolizemi v kolizních segmentech LAN [8].

3.2. Kvalita služeb Kvalita služeb neboli QoS je základním předpokladem k přenosu multimediálního provozu přes konvergovanou komunikační infrastrukturu. Kvalita služeb odráží požadavky provozu, tak aby byla zachovaná jeho kvalita. Samozřejmě jiná kvalita je požadována od interaktivního, transakčního nebo dávkového provozu. Každý provoz má své nároky dané jeho konstrukcí a způsobem komunikace. Jiné nároky má FTP provoz, který na základě principu TCP chce využít maximální přenosové pásmo a zpomalí přenos, až když je maximální kapacita pásma vyčerpána. Na zpoždění a ztrátu IP paketů je připraven. Jiné nároky má hlasový provoz, který zabírá malou konstantní velikost přenosového pásma, pro kterého znamená zpoždění nebo ztráta souvisejících IP paketů významnou degradaci kvality hlasu. Kvalita služeb může být definována dle následujících kritérií: 

zpoždění,



variabilní zpoždění,



ztráta/ zahození IP paketu,



požadované pásmo,



požadované dostupnost. 37

Kvalita služeb může být rozdělena podle přístupů jak jí dosáhnout: 

Integrated Services – IntServ,



Differentiated Services – DiffServ.

Přístup IntServ je postaven na samostatném signalizačním protokolu, kterým je nejdříve ověřeno, že celá cesta k cíli splňuje požadované vlastnosti, pak je umožněn přenos daného provozu. IntServ je postaven na signalizačním protokolu RSVP, který definuje RFC1633. Přístup DiffServ využívá značení v přenášených datech, kdy komunikační prvky podle dané značky aplikují na procházející provoz patřičnou QoS politiku, tímto způsobem preferují kritický provoz a zamezí přetížení komunikačního prvku celkovým provozem. Mezi DiffServ patří mechanizmy využívající IP ToS byte: DSCP, předchůdce IP Precedence. Dále mechanizmy využívající značky IEEE. 802.1p a MPLS Exp [11]. QoS obecný pojem zahrnující řadu funkcí: 

klasifikaci provozu,



značení provozu,



upravení, omezení a zahazování provozu,



začlenění provozu do front,



fragmentace a prokládání paketů.

QoS se obecně rozlišuje zda-li je aplikován na L2 provoz nebo L3 provoz. Pokud se jedná o L2 provoz, je informace o prioritě umístěna v L2 rámci protokolu jako je například Ethernet. Pokud se jedná o L3 provoz je informace o prioritě umístěna přímo v IP paketu. To je důležité z pohledu zpracování, protože L2 zařízení jsou LAN přepínače, které nevidí informaci v IP paketu, protože přepínají provoz pouze na základě rámců. Informace v IP paketu je důležitá pro L3 zařízení jako jsou směrovače, kdy informace z rámce zanikne, zato informace z IP paketu je viditelná po celé délce spojení. Proto se značení rámců a IP paketů kombinuje. Specifickým příkladem je MPLS, které přidává k přenášenému provozu vlastní hlavičku. V této hlavičce je obsažena vlastní informace o prioritě.

38

3.2.1. Klasifikace provozu Pokud má být provoz přenášen jako striktně prioritní nebo zařazen do tříd odpovídající povaze provozu z pohledu zpoždění a ztráty/ zahození dat, musí být tento provoz v první řadě na nějakém vhodném základě klasifikován. Klasifikace může být řešena následujícím způsobem na základě: 

fyzického, logického rozhraní (port, VLAN, PVC),



přístupového listu L2/L3/L4 ISO OSI (ACL MAC, SAP, IP, TCP/UDP),



inspekce provozu L7 ISO OSI (NBAR),



důvěry ve značení přijatých dat (z IP telefonu) IEEE 802.1p, DSCP, z jiných typů, např. původní značení ToS nebo MPLS Exp [6].

V případě IP telefonie se obyčejně důvěřuje IP telefonu, že jeho provoz vyžaduje striktní prioritu. V současnosti se vyvíjí standardizované prostředky k automatickému přidělení provozu do tříd dle detekce připojeného zařízení. Použitím standardem je LLDP. Pokud port aktivního prvku obdrží LLDP zprávu o připojeném IP telefonů, automaticky přiřadí provoz do patřičných tříd.

3.2.2. Značení provozu Značení provozu do tříd je základním předpokladem k přenosu multimediálního provozu přes konvergovanou komunikační infrastrukturu.

3.2.2.1. Značení rámců L2 CoS Klasifikace provozu v LAN je umožněna aplikací standardu IEEE 802.1p, který umožnil na L2 ISO OSI úrovni klasifikovat zdrojová data. Standardy IEEE 802.1p/Q umožnily do Ethernet rámců vkládat značky ohledně jejich priority a příslušnosti k VLAN. Značení provádí samotné koncové zařízení jako jsou IP telefony, videokonferenční kity, řídící servery, brány a MCU. Pokud prvek značení nepodporuje, může provádět značení nejbližší L2 LAN přepínač nebo směrovač. Obecnou zásadou je značení dat přenosu co nejblíže u jejich zdroje. Standard IEEE 802.1p používá značku IEEE 802.1Q o velikosti 4 bytů vloženou do Ethernet rámce. Značka obsahuje položku tzv. Priority field o velikosti 3 bitů, která je dedikována pro IEEE 802.1p. Náhled třídy IEEE 802.1p a jejich použití uvádí následující tabulka. 39

Tabulka č. 12: Třídy CoS Priorita CoS 0 CoS 1 CoS 2 CoS 3 CoS 4 CoS 5 CoS 6 CoS 7

Bit 000 001 010 011 100 101 110 111

Specifikace dle IEEE 802.1p Best Efford Background Spare Excelent Efford Controlled Load Video Voice Network Control

Použití Normální provoz Signalizace Video Hlas Kontrola sítě Síťová signalizace


Je třeba dodat, že původní specifikace tříd ve standardu neodpovídá současnému doporučení k nastavení tříd výrobci. Je to dáno tím, že až reálný provoz ukázal vhodnost použití těchto tříd. Dalším důvodem je srovnání priorit s IP precedence. Standard IEEE 802.1p umožnil značení rámců co nejblíže u zdroje, již frontovací mechanizmy L2 LAN prvků tak mohou expresně posílat prioritní data přímo na jejich výstupní rozhraní.

3.2.2.2. Značení paketů L3 DSCP Původní standard Type of Service (ToS) dle RFC 791 byl neefektivní, protože ačkoliv používal 1 celý ToS byt, ke značení priority poskytoval jen kombinací tří bitů pro 8 prioritních tříd. Další tři byty vyhrazeny pro značení provozu s ohledem na zpoždění (Delay), propustnost (Troughput) a spolehlivost (Reliability), ty však v praxi nabyly využívány. Zbývající dva byty byly označeny jako rezerva pro budoucí použití. Standard DSCP umožnil plně využít ToS byte a vytvořit až 64 tříd k maximální podpoře různorodých typů provozu, s ohledem na citlivost přenášených paketů na zpoždění a ztrátovost během přenosu. Jedná se především o typy tříd Assurred Forwarding (AF) RFC 2597, Expedited Forwarding (EF) RFC 3246 a zpětně kompatibilní Class Selector (CS) RFC 2474. Striktně prioritní třídu DSCP 46 – Expedited Forwarding uvádí následující tabulka.

40

Tabulka č. 13: Třída EF striktní priority EF

(DSCP) 101110 (46)

Zdroj: Szigeti Tim, McMenamy Kevin, Saville Roland, Glowacky Alan: Cisco TelePresence Fundamentals, Indianapolis, Cisco Press, 2009, str. 168

Tato třída je výlučně použita pro hlasová data, která jsou nejvíce senzitivní, na straně druhé jsou tvořena konstantním tokem daným patřičným kodekem, proto je chování provozu snadno predikovatelné. Třídy Assured Forwarding kombinují nutnost priority s možností zahození paketu, tak aby třídy vyhovovaly všem typům provozu. Vyšší AF znamená vyšší prioritu. Náhled na třídy Assured Forwarding uvádí následující tabulka. Tabulka č. 14: Třídy AF Low Drop – byty (DSCP) AF 1 AF 2 AF 3 AF 4

AF11 – 0 01010 (10) AF21 – 010010 (18) AF31 – 011010 (26) AF41 – 100010 (34)

Medium Drop – bity (DSCP) AF12 – 001100 (12) AF22 – 010100 (20) AF32 – 011100 (28) AF42 – 100100 (36)

High Drop – byty (DSCP) AF13 – 001110 (14) AF23 – 010110 (22) AF33 – 011110 (30) AF43 – 100110 (38)


Ke zpětné kompatibilitě k IP Precedence byly vytvořeny třídy Class Selector. Tabulka č. 15: Třídy CS zpětné kompatibility CS bity (DSCP) CS 0 CS 1 CS 2 CS 3 CS 4 CS 5 CS 6 CS 7

IP precedence bity

000000 (0) 001000 (8) 010000 (16) 011000 (24) 100000 (32) 101000 (40) 110000 (48) 111000 (56)

000 001 010 011 100 101 110 111

Specifikace IP Precedence dle RFC 791 Normal Priority Immediate Flash Flash-Override Critical Internetwork Control Network Control


Popis specifikace IP Precedence dle RFC 791 rovněž neodpovídá doporučení výrobců. Pro signalizaci se standardně používá třída AF31 – DSCP 26 nebo CS3 – DSCP 24. Pro videokonferenční

provoz se používá AF41 – DSCP 34. Přesné rozdělení dalšího

provozu do tříd závisí na tom, jaký provoz danou sítí prochází a jaká je QoS politika daného subjektu. 41

Zdrojová zařízení jako IP telefony značí obyčejně, jak CoS, tak DSCP třídy. Pokud zařízení značí jen CoS, musí nejbližší L 3 prvek provádět mapování CoS tříd na DSCP. RFC 3662 dále specifikuje třídu Scavenger, která má být použita pro provoz, který by neměl plnit základní třídu CS 0 nazývanou jako Best Efford nebo Default Forwarding. Třída Scavenger je určena pro provoz, který má být při prvním náznaku ucpání sítě zahozen (YouTube, iTunes, atd.). Typicky se jedná o služby, které jsou nepotřebné a nesouvisí s provozem. Třída Scavenger je opak EF. Jako Scavenger se používá třída CS1 [13].

3.2.3. Upravení, omezení a zahazování provozu Provoz vstupující do aktivního prvku je začleněn do odpovídajících tříd. Pokud je přijímáno více provozu než stačí aktivní prvek pojmout nebo pokud má nějaký typ provozu tendenci utiskovat provoz v jiných specifických třídách musí být tento převažující provoz náležitě omezen. Typickými nástroji jsou: 

Traffic Policer,



Traffic Shaper.

Traffic Policer ořezává špičky provozu na definovanou mez. Provoz, který přesahuje určitou mez, např. hodnotu maximálního provozu pro danou třídu, bude zahozen. Výstupní provoz bude odpovídat požadované rychlosti přenosu. Traffic Shaper reaguje na přenosové špičky jinačím způsobem. Provoz překračující určitou mez uloží do bufferu a pošle ho na výstupní rozhraní v okamžiku poklesu provozu pod definovanou mez. Ve výsledku uhlazuje špičky a poklesy provozu do konstantního toku. Překračující provoz je v závislosti na trvání špičky zpožděn. V případě přenosu hlasu se používá funkce Traffic Policeru v rámci frontovacího mechanizmu LLQ k tomu, aby prioritní provoz nepřekročil určitou mez a nemohl v nějakém nedefinovaném stavu vytěsnit ostatní provoz. K řízenému zahazování dat se používají mechanizmy RED, WRED a další, které mají regulační funkci k přirozenému chování TCP provozu, kdy TCP spojení chtějí využít celé přenosové pásmo spoje. Tyto mechanizmy se samozřejmě neaplikují na multimediální provoz. 42

3.2.4. Začlenění provozu do front Na základě klasifikovaného provozu jsou v komunikačních prvcích použity různé frontovací mechanizmy. Provoz je rozdělen do několika výstupních front, kde čeká na odbavení a poslání na médium. Frontování se provádí jak v LAN přepínačích, tak směrovačích.

3.2.4.1. Frontování v L2 prvcích L2 LAN přepínače s podporou QoS obyčejně podporují čtyři konfigurovatelné výstupní fronty. Posílání provozu do front je postaveno na CoS třídách. Jedna z front je nastavena jako prioritní. Jakýkoliv provoz, který je nasměrován do této fronty je odbaven bez čekání. Zbývající tři fronty jsou obsluhovány způsobem Weighted RoundRobin (WRR). To znamená do kola – jeden rámec z první fronty, jeden rámec z druhé fronty, jeden rámec z třetí fronty a tak dále dokola. Frontám lze přidělovat váhy a tak lze ovlivňovat kolik rámců má být odbaveno z každé běžné fronty v každém kole. Příkladem produktů, které takto fungují jsou například LAN přepínače Enterasys nebo Cisco.

3.2.4.2. Frontování v L3 prvcích Frontování musí být zajištěno při průchodu přes L3 zařízení jako jsou směrovače. Frontování je důležité především ke směrování provozu přes prostředí nízko kapacitních WAN. Posílání provozu do front může být postaveno na řadě faktorů. Pro frontování multimediálního provozu se používá mechanizmus Low Latency Queueing. Umožňuje vytvořit celou řadu front včetně té prioritní, do front pak následně umožňuje přiřadit typy provozu dle klasifikačních kritérií včetně DSCP, CoS, MPLS Exp, ACL, NBAR, fyzického portu a dalších. Pro prioritní frontu musí být přiděleno určité přenosové pásmo, které musí odpovídat množství provozu. Nastavení funguje i jako kontrolní mechanizmus, který má zabránit vyčerpání celkového pásma výstupního rozhraní prioritním provozem. Pokud prioritní provoz z nějakého důvodu čerpá více pásma než je očekáváno, mechanizmus ořezává provoz na definovanou hodnotu. Příkladem produktu využívající výše uvedené funkce jsou směrovače Cisco, které mají v této oblasti monopolní postavení.

43

3.2.5. Fragmentace a prokládání paketů V případě společného přenosu hlasových a datových paketů na nízko kapacitních linkách WAN pod 768 kbit/s, je nutné zajistit fragmentaci velkých datových paketů a jejich prokládání s hlasovými. Typicky se jedná o FTP přenosy, které se snaží využít maximální velikost přenosového kontejneru. Tyto funkce se obecně jmenují Link Fragmentation a Interleaving. Důvodem vzniku problému je nízká rychlost média a zpoždění při odbavení provozu. Toto zpoždění se nazývá Serialization Delay a znamená čas, který trvá přenos IP paketu na médium. Díky nízké rychlosti přenos velkých datových paketů po dobu odbavení blokoval výstupní rozhraní do nízko kapacitních WAN spojů. Hlasové pakety tak musely čekat i když byly v prioritní frontě. Ve výsledku došlo výraznému variabilnímu zpoždění (jitter), které ani interní jitter-buffer v koncovém zařízení nemohl vyrovnat. Proto musely být velké datové pakety fragmentovány a vhodně prokládány s hlasovými. Jelikož řada subjektů dnes používá WAN technologie s vyšší kapacitou než je 768 kbit/s, fragmentace a prokládání paketů se postupně přestávají používat.

44

4. Napájení komunikačních komponent K provozu IP telefonie musí být zajištěno napájení koncových zařízení – IP telefonů, příp. dalších zařízení. Historicky analogové a digitální telefony byly napájeny přímo z hlasového komunikačního systému po páru přívodního kabelu. V případě IP telefonů jsou IP telefony napojeny do LAN přepínače komunikační infrastruktury přes datové Ethernet rozhraní. Ačkoliv je možné napájet IP telefony z externího napáječe, toto připojení není praktické, protože pro každý IP telefon musí být zajištěna samostatná elektrická zásuvka. Z tohoto důvodu vznikl Power over Ethernet (PoE) standard IEEE 802.3af k napájení koncových zařízení po Ethernetu. Tento standard umožnil napájet koncová zařízení po strukturované kabeláži budovy z LAN přepínačů nebo jiných dedikovaných komponent. Standard definuje napájené zařízení jako Powered Device (PC), napájecí zařízení je nazýváno Power Sourced Equipment (PSE). Třídy napájení dle IEEE 802.3af uvádí následující tabulka. Tabulka č. 16: Třídy napájení dle IEEE 803.af Třídy 0 1 2 3 4

Použití Default Optional Optional Optional Reserved

Proud (mA) 0–4 9 – 12 17 – 20 26 – 30 36 – 44

Maximální příkon (W) 0,44 – 12,94 0,44 – 3,84 3,84 – 6,49 6,49 – 12,95 12,95

Popis tříd Unknown PD – zařízení nepodporuje negociaci třídy Low-power PD – dohodnutý nízký příkon Mid-power PD – dohodnutý střední příkon High-power PD – dohodnutý vysoký příkon -


Výběr patřičné třídy závisí na detekci, která využívá Ethernet rozhraní a kabelové vedení jako smyčku mezi PSE a PD. PD obsahuje integrovaný odpor, jeho velikost umožní detekovat PSE požadovanou třídu a následně napájet koncové zařízení s detekovaným příkonem. Standard navíc umožňuje dva typy napájení PD a to po:

5



stejných pinech jako je přenášen datový provoz (piny 4,5,7 a 8),



pinech nevyužitých pro datový provoz (piny 1,2, 3 a 6)5.

Název “pin” vychází z anglického jazyka, kdy se tímto slovem označují jednotlivé metalické plošky rozhraní konektoru 45

Použití pinů se liší podle toho, zda-li je PSE power hub nebo LAN přepínač s podporou PoE. Přepínač s podporou PoE je standardní LAN přepínač s posíleným zdrojem k napájení všech Ethernet portů. Power hub je dedikované zařízení, které je předřazeno běžnému LAN přepínači a které doplňuje do vedení napájení. Typickým příkladem Power hubu jsou produkty výrobce PowerDsine. V současnosti je zaveden další nový standard IEEE 802.3at, který poskytuje větší příkon až do 15,4 W. Ten je určen především pro náročnější zařízení typu Wireless AP IEEE 802.11n nebo CATV kamerové systémy využívající Ethernet rozhraní [23].

46

5. Komponenty ve standardním řešení IP telefonie Cílem této kapitoly je vytvoření základního přehledu klíčových komponent IP telefonie, jejich popis a stanovení funkcionality v celém systému.

5.1. Přehled komponent Řešení IP telefonie se skládá z řady komponent. Jedná se o řídící server, IP telefony, hlasové brány a převodníky, podpůrné aplikace a nadstavbové aplikace. Úroveň IP telefonie u výrobců závisí na technologické vyspělosti jejich řešení a je rozdílná. Někteří tradiční výrobci pobočkových ústředen nabízí tzv. hybridní řešení postavená na technologickém základu klasických ústředen doplněných kartami s podporou VoIP a IP telefonie. Tato řešení však nelze považovat za čistou IP telefonii. Na druhou stranu čistá IP telefonie vyžaduje certifikovaný hardware PC serverů, aby bylo zajištěno předvídatelné a spolehlivé chování IPT systému. Hlavním prvkem hlasové sítě je řídící server IP telefonie. Tento řídící server je v podstatě softwarovou aplikací provozovanou ve standardním průmyslovém serveru. Operačním systémem je většinou Linux, protože nabízí vyšší výkon, otevřenost a podporu standardů v porovnání s OS Windows Server 2003/2008.

5.1.1. Řešení výrobců Vhodným příkladem řešení čisté IP telefonie může být komerční produkt Siemens OpenScape Voice V4.1, který používá certifikované servery Fujitsu a IBM jako základ pro svojí aplikaci IP telefonie. Nad hardware je provozováno jádro SUSE Linux Enterprise Server (SLES) V9, nad kterým běží v režimu clusteru samotná aplikace IP telefonie OpenScape Voice [11]. Podobným způsobem jsou postavena řešení Cisco Unified Communication Manager V6, Avaya Aura Communication Manager a dalších výrobců. Řešením IP telefonie může být i volně šířitelný produkt Asterisk vycházející z prostředí Open Source Telephony Project. Kritickým faktorem v IP telefonii je podpora standardů a otevřenost k produktům třetích stran. To je bolavým místem hlasového řešení Microsoft Office Communication Server, kdy tento produkt nepodporuje v softwarovém uživatelském vybavení standardní 47

kodeky, dále signalizační parametry se odchylují od zavedených standardů SIP. Microsoft OCS používá proprietární kodek RTAudio, komunikace směrem k produktům třetích stran proto musí vždy procházet přes aplikační bránu, která zajišťuje protokolovou konverzi. Rovněž Microsoft pojímá problematiku QoS svým způsobem, kdy zavádí tzv. Quality of Experience (QoE) [10]. Na druhé straně Microsoft je v poli ICT významným hráčem, je pravděpodobné, že stávající nedostatky řešení ve standardizaci buď dožene nebo vnutí svým dlouhodobým marketingovým tlakem.

5.1.2. Rozmístění komponent Vzorové řešení IP telefonie včetně řídících serverů v clusteru, redundantních hlasových bran, geograficky rozmístěných IP telefonů a komunikační infrastruktury ukazuje následující obrázek. Obrázek č. 4: Řešení IP telefonie v prostředí LAN/WAN

Zdroj: Autor

V řešení IP telefonie jsou na straně uživatelů provozovány IP telefony. Ty se signalizačním protokolem připojují k řídícímu serveru IP telefone. Řídící server spojuje hovory, hlasová data jsou přenášena tou nejvhodnější cestou ke svému cíli. V IP telefonech je obsaženo Ethernet rozhraní k připojení do LAN. IP telefony dále obsahují integrovaný mini-LAN přepínač k připojení uživatelského PC. LAN infrastruktura napájí IP telefony z LAN prvků dle standardu IEEE 802.3af, případně jsou použity samostatné napáječe. 48

Důležitou komponentou IP telefonie jsou hlasové brány, které převádějí VoIP na požadované TDM rozhraní nebo jiné signalizační / přenosové protokoly. Hlasové brány jsou primárně určeny k připojení do VTS a k mobilním operátorům. Analogové převodníky slouží k připojení stále využívané analogové technologie, jako jsou faxy nebo analogové telefony. Komponentou řešení je i LAN a WAN infrastruktura, která zajišťuje datový přenos, kvalitu služeb a napájení IP telefonů. V konvergované komunikační infrastruktuře lze rovněž provozovat mobilní zařízení využívající bezdrátovou infrastrukturu dle IEEE 802.11 nebo DECT. Wireless IEEE 802.11 nativně podporuje přenos hlasu přes IP infrastrukturu s podporou IEEE 802.11e/r k podpoře funkcí QoS a Fast Roaming. K napojení na DECT/GAP musí dojít ke konverzi VoIP na do protokolu DECT. Tímto konverzním bodem jsou základnové stanice IP DECT.

5.2. Řídící server IP telefonie Řídícím serverem v prostředí IP telefone je jeden server nebo více dedikovaných serverů obsahujících ucelené aplikační vybavení IP telefonie a zajišťující řadu nezbytných uživatelských služeb. Způsob nasazení hlasové technologie, rozložení na více serverů, závisí na požadavcích řešení včetně pokrytí množství koncových uživatelů, stupně dostupnosti řešení, geografického rozložení řešení a úrovně zabezpečení. Řídící server IP obsahuje typicky následující části: 

jádro signalizace SIP, spojování a přepínání hovorů,



databáze nastavení a uživatelských parametrů,



podpora běhu řídících serverů v clusteru pro HA,



média server ke generování tónů a hlášek,



management portál ke správě nastavení,



rozhraní k nadstavbovým aplikacím.

Řídící server obsahuje číslovací plán, který je obyčejně hierarchicky členěn dle lokalit a organizační struktury daného subjektu. V případě použití více číslovacích plánům mohou řídící server a hlasové brány provádět číselný překlad.

49

5.2.1. IP telefony IP telefony jsou dedikovaná, většinou hardwarová zařízení, která obsahují displej, funkční a ovládací tlačítka, sluchátko, Ethernet rozhraní k připojení do LAN a integrovaný mini-LAN přepínač k připojení uživatelského PC. IP telefony mohou podporovat řadu rozšíření včetně připojení přídavného tlačítkového modulu, náhlavní soupravy a USB zařízení. Ačkoliv řada výrobců používá pro své IP telefony standardní protokoly SIP a RTP/RTCP, kombinace řídícího serveru a IP telefonů od různých výrobců může mít svá úskalí. Jejich kombinace může znamenat omezenější sadu uživatelských služeb, protože různí výrobci mohou určité funkce zajišťovat různými standardy nebo si je vykládat odlišně. V krajním případě může být i služba IP telefonie nefunkční. Problematickým místem je centrální správa IP telefonů, protože každý výrobce používá vlastní, nekompatibilní prostředky centrální správy. Při implementaci IP telefonie pro více než 100 uživatelů se stává centrální správa IP telefonů pomocí předefinovaných profilů nutností.

5.2.2. Hlasové brány Hlasové brány slouží k připojení do VTS. Hlasové brány konvertují komunikační protokoly. Konverze může být využita mezi rozhraními a protokoly IP/SIP, IP/H.323, E1 ISDN PRI, E1 QSIG. Hlasová brána je typicky hraničním rozhraním hlasového systému. Hlasové brány zajišťují dostupnost hlasových služeb v případě nedostupnosti centrálního řídícího serveru. Hlasové brány mohou být konfigurovány do režimu Survivability – přežití služby6. V případě nedostupnosti řídícího serveru umožní hlasová brána uživatelům lokálně telefonovat do VTS s omezenou funkční sadou hlasových služeb. Hlasová brána používá k tomuto účelu integrovaný SIP Proxy server.

6

V terminologii Siemens Enterprise Communications se mluví o funkci Survivability, v terminologii Cisco se mluví o Survivable Remote Site Telephony (SRTP), jiní výrobci používají obdobné termíny 50

5.3. Podpůrné aplikace Podpůrnými aplikacemi se rozumí aplikace, které rozšiřují základní funkcionalitu řídícího serveru IP telefonie. Tyto aplikace jsou obyčejně součástí základního balíku řešení a k provozu IP telefonie jsou nezbytné.

5.3.1. Média server Nezbytnou komponentou řídících serverů bez ohledu na výrobce jsou integrované aplikace média serveru a konferenčního serveru. Média server je komponenta, která zajišťuje

přehrávání

tónů

a

hlášek.

Většina

základních,

standardizovaných

signalizačních tónů, které uživatel slyší v telefonním sluchátku je umístěna v samotném IP telefonu, hlasových branách a v média serveru. Pokud řídící systém signalizuje koncovému zařízení přehrání určitého signalizačního tónu (např. obsazeno), je tento tón přehráván ze samotného IP telefonu uživatele. V případě, že se jedná o specifické tóny nebo namluvené chybové hlášky, jsou přehrávány z média serveru. Media server může být umístěn na dedikovaném serveru nebo v hlasové bráně připojení do VTS. Přenos tónů a hlášek z média serveru je realizován protokolem RTP/RTP požadavek je signalizován protokoly MGCP nebo SIP. Pokud je řešení postaveno pro velké množství koncových uživatelů a řešení musí pracovat v HA režimu, je Media server obyčejně oddělen od řídícího serveru.

5.3.2. Konferenční server SIP protokol podporuje v základě třícestnou konferenci. K vytváření konferencí s více uživateli je nutné v řešení použit konferenční server. Konferenční server muže být dedikované hardwarové zařízení typu MCU, samostatný server nebo tato funkcionalita může být provozována v hlasových branách. Pokud se jedná o MCU nebo dedikované servery, jedná se převážně o specializované, řízené konference, často propojené s plánovacími nástroji Microsoft Office nebo IBM Lotus Notes. Konferenční zařízení vytvářejí konferenční hovory mixováním různých audio vstupů, normalizují je a překládají hlasové kódování. Přenosovým protokolem hlasu je RTP/RTCP. Požadavek na konferenci je signalizován protokoly MGCP nebo SIP. Pokud je řešení postaveno pro velké množství koncových uživatelů a řešení musí pracovat v HA režimu, je Media server obyčejně oddělen od řídícího serveru. 51

5.3.3. Management server Řídící server IP telefonie je doplněn management portálem ke správě nastavení hlasových služeb, nastavení uživatelských účtů. Management portál je obyčejně umístěn v řídícím serveru IP telefonie nebo na dedikovaném serveru.

5.3.4. Tarifikační server Ke sledování nákladů spojených s provozem hlasových služeb se používá tarifikační server. Tarifikační server sbírá tarifní věty ukládané do struktury CDR. Tarifní věty generuje samotný řídící server nebo i hlasové brány. Tarifikační server ukládá tarifní věty do vlastní databáze. Tarifní věty obsahují informace o uskutečněných telefonních spojení včetně zdrojových a cílových čísel, jmen uživatelů, času spojení a poplatků za služby poskytovatelů. Tarifikační server dále spojuje tarify poskytovatelů a generuje náhledy. Zobrazování náhledů je řešeno prostřednictvím webového rozhraní. Definovaným uživatelům je umožněno sledovat statistiky provozu a asociované náklady s rozpadem na jednotlivé organizační jednotky subjektu. Přístup k náhledem je řešen způsobem RBAC, pravidla přístupu k údajům odpovídají organizační struktuře.

5.3.5. Integrace adresářových služeb Řešení IP telefonie využívají propojení s adresářovými strukturami. Důvodem je to, že uživatelé a některé uživatelské parametry jsou již v těchto službách zavedeny, opětovné vyplňování těchto údajů do řídícího serveru je neefektivní. Adresářové služby přitom mohou sloužit jako centrální zdroj údajů a parametrů uživatelského nastavení nejen pro IP telefonii, ale i řadu dalších aplikací. Provázání adresářových služeb má následující výhody: 

propojení údajů hlasového systému s adresářovou strukturou,



použití LDAP protokolu,



použití standardních atributů v souladu s ITU-T X.500 schématem,



možnost párování uživatelských parametrů na telefonní číslo,



čísla uživatelů jsou v plném ITU-T E.164 formátu,



čísla jsou (v lepším případě) zadána v jednotné formě bez chyb,



další aplikace mohou následně tento zdroj využit. 52

Adresářové služby mohou být postaveny například na produktech OpenLDAP, Netscape Directory Server, Microsoft Active Directory, SUN One Directory Server nebo iPlanet Directory Server.

5.3.5.1. Problémy integrace adresářových služeb Ačkoliv adresářové služby využívá řada subjektů včetně firem a organizací, adresářové služby jsou často zavedeny neodborně bez logické, hierarchické, organizační struktury a dodržení standardního ITU-T X.500 schématu. Problémem je i to, že hodnoty v atributech nejsou zadány jednotně, což zabraňuje strojovému zpracování. Příkladem je různý formát telefonního čísla neodpovídající struktuře definované dle ITU-T E.164. Dochází k použití různých oddělovacích znaků včetně mezer. Často nejsou zavedeny odpovídající kontrolní mechanizmy, které by měly vkládané údaje ověřovat. Pokud nejsou telefonní čísla a další údaje zadávány do adresářových služeb jednotně, nelze smysluplně provést provázání s hlasovým komunikačním systémem.

53

6. Nadstavbové aplikace a jejich integrace do IP telefonie Konvergovaná komunikační infrastruktura a její standardizovaná rozhraní a protokoly umožnily integraci nadstavbových aplikací do IP telefonie. Z koncových zařízení, jako jsou běžné telefony nebo videokonferenční kity, se staly multi-funkční koncové terminály, které převzaly část funkcí z běžných počítačů. Příkladem jsou IP telefony s velkým grafickým displejem, který umožní uživateli zobrazovat a ovládat aplikační prostředí volané XML protokolem z aplikačního serveru. Výsledkem jsou např. aplikace k snadnému vyhledávání osob v telefonním seznamu, poskytování informací, funkce elektronického vrátného s náhledem na objekt v kameře a další. Na druhé straně integrace přinesla silné nástroje do prostředí uživatelských počítačů. Uživatel v prostředí počítače může vidět pomocí aplikace takové výstupy jako jsou žurnál volání včetně volaných, přijatých a nezodpovězených telefonních čísel, může vytočit volání pouhým klikem na kontakty v prostředí poštovního klienta, dokumentech nebo stránkách webového prohlížeče. Další významné funkce jsou informace o přítomnosti kolegů v týmu – uživatelská prezence, volba nejvhodnějšího komunikačního nástroje k jejich dosažení od pevného telefonu, mobilu, textových zpráv až po zanechání hlasové zprávy v poštovní schránce.

6.1. Aplikace CTI Jedním typem z nadstavbových aplikací jsou aplikace postavené na Computer Telephony Integration (CTI). V podstatě se jedná o propojení uživatelského počítače s řídícím serverem IP telefonie pomocí CTI serveru (3rd party CTI) přes dedikovaný signalizační protokol. Aplikace na straně uživatele je uzpůsobena k následujícím funkcím: 

žurnál volání,



vytáčení telefonního čísla,



z kontaktů Microsoft Outlook: o označením telefonního čísla a klávesovou zkratkou, o z webových stránek pomocí plug-in v prohlížeči,



historie – volaná, přijatá, nevyzvednutá čísla. 54

Signalizační CTI protokoly jsou TAPI, JTAPI a CSTA. Úloha CTI serveru je překlad protokolů a přenos signalizačních zpráv. Protokol TAPI vychází z prostředí Microsoft a je na ústupu. Protokol TAPI například podporují programy Microsoft Outlook. Protokol JTAPI je určen pro prostředí využívající softwarové vybavení JAVA. Protokol CSTA je podporován především v řídících serverech IP telefonie. CSTA byl definován ve standardech organizace ECMA následně byly transformovány do ISO/EIC. Standardy definují například syntaxi překladu zpráv s protokolem SIP nebo zapouzdření v protokolu XML (XML CSTA). Z celkového pohledu vývoje se aplikace CTI posunují do skupiny služeb Unified Communications, kde jsou integrovány se službami videa, uživatelské prezence a přenosu textových zpráv.

6.2. Aplikace kontaktního centra Aplikace kontaktního centra je speciální aplikací hlasových služeb. Aplikace slouží pro speciální uživatele – operátory, kteří zpracovávají různé multimediální typy služeb. Historicky byla kontaktní centra postavena pouze na hlasových službách, kdy operátoři využívali ke zpracovávání požadavků pouze telefony. Dnešní operátoři používají vedle telefonu i grafické prostředí, kde sledují počet volajících ve frontě, zpracovávají nejen příchozí hlasová volání ale i požadavky přijaté emailem, webovým rozhraním a SMS. Aplikace umožňuje nejen provázat různé typy médií, ale i udržovat posloupnost a perzistenci všech obhospodařovaných kontaktů. Systém kontaktního centra umí inteligentně zpracovávat, třídit a směrovat hovory na operátory dle jejich schopností a momentální vytíženosti. Systém kontaktního centra může být provozován i odchozím režimu, kdy na základě připravených kampaní systém umožňuje operátorům automaticky obvolávat definované seznamy telefonních čísel. Aplikace kontaktního centra je provázána s dalšími zdroji informačních systémů. Typicky se jedná o CRM systémy, které umožňují výstupy agregovat, vyhodnocovat, směrovat do výrobní a distribuční části firmy a vytvářet různé náhledy pro firemní, strategická rozhodnutí. Příkladem kontaktního centra mohou být produkty Genesys nebo Siemens OpenScape Contact Center [11].

55

6.3. Aplikace Unified Messaging Společně s hlasovými službami se používají různé textové služby spojené pod názvem Unified Messaging. Typicky se jedná o přenos faxových zpráv přes prostředí TCP/IP, kdy faxové zprávy jsou doručeny do email schránky společně s emaily. UM zahrnuje i integraci SMS zpráv, kdy je možné propojit mobilní zařízení, IP telefony a emailové schránky prostřednictvím dedikovaných SMS bran. Aplikace Unified Messaging se rovněž snaží zahrnout mezi své služby Instant Messaging. Výrobci proto zakoupili nebo integrovali ve formě OEM produkty IM k doplnění jejich portfolia. IM je provozován, jak pro veřejné, nekomerční prostředí, tak i pro neveřejné, komerční prostředí podniků a organizací. Výčet nejrozšířenějších, veřejných IM systémů a jejich poskytovatelů uvádí následující tabulka. Tabulka č. 17: Nejrozšířenější IM systémy IM Systém AIM ICQ Skype MSN Messenger Yahoo Messenger Jabber (XMPP)

Výrobce AoL AoL Skype Microsoft Yahoo Cisco

Odhad aktivních uživatelů 53 miliónů 15 miliónů 10 miliónů 29 miliónů 21 miliónů 13,5 miliónů

Komunikační porty 5190–3 4000 80, 443, a další 1863 5050 5222–3

Zdroj: Cisco: How Instant Messaging Is Transforming the Enterprise Network: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-2/instant_messaging.html

V případě neveřejných IM systémů je snaha začlenit IM a celkově Unified Messaging do skupiny služeb pod názvem Unified Communications. Komerční IM vnucují přístupovou politiku na perimetru v rámci komunikační infrastruktury subjektu, vnucují kontrolní mechanizmy, monitorují a šifrují provoz, povolují IM provoz přes dedikované bezpečnostní brány jen na důvěryhodné veřejné IM systémy. Důvodem začlenění Unified Messaging do Unified Communications je i to, že IM úzce spolupracuje se službou uživatelská prezence. Například protokol XMPP nativně podporuje službu prezence, která je definována v RFC 3920, 3921, a 3923. Příkladem aplikace Unified Messaging může být produkt Siemens OpenScape Xpressions, který slučuje služby hlasové pošty, faxových zpráv a SMS do jediného média. Siemens OpenScape Unified Communications využívá IM modul Openfire 56

(Open Source) s protokolem XMPP. Společnost Cisco zase koupila produkt Jabber (XMPP), aby ho integrovala do svého produktového portfolia.

6.4. Aplikace automatické spojovatelky Společně s hlasovými službami se často využívá služba automatické spojovatelky zahrnující služby interaktivního hlasového stromu (IVR), překladu textu na hlas (TTS) a rozpoznávání hlasu (ASR). Obyčejně se jedná o samostatnou aplikaci, která je dále integrována

s dalšími

produkty

jako

jsou

kontaktní

centra

nebo

Unified

Communications. Aplikace umožní přes definované rozhraní využívat poštovní služby, vyhledávat informace v databázi, ovládat uživatelské komunikační prostředky. Využití aplikace je časté s mobilními zařízeními.

57

7. Vzorové řešení IP telefonie a Unified Communications Kapitola popisuje vzorové řešení jednoho z vybraných výrobců řešení IP telefonie s nadstavbou Unified Communications.

7.1. Požadavky trhu Řada předních poradenských firem analyzuje požadavky zákazníků a produkty předních výrobců. Jako slibný segment rozvoje ICT trhu vidí oblast Unified Communications. Stejnou vizi unifikované, sjednocené komunikace vidí i řada předních zákazníků, kteří chápou tuto technologii jako možnost lepší, účinnější, vnitrofiremní komunikace, která umožní získat na trhu konkurenční výhodu. Podobný pohled mají i přední výrobci komunikačních řešení a tyto potřeby trhu podporují svými marketingovými strategiemi.

7.2. Strategie výrobců Řešení IP telefonie vychází ze skupiny více či méně provázaných produktů výrobců. Výrobci se snaží nabídnout svým zákazníkům ucelené portfolio od řídícího serveru IP telefonie, hardwarových IP telefonů, softwarových IP telefonů a různých komunikátorů, hlasových bran a analogových převodníků až po specializované aplikace. Mezi specializované aplikace patří produkty kontaktních center, centrální spojovatelky, mobility, hlasové pošty, CTI aplikace, trading aplikace a další. Těmito výrobci jsou ti, kteří byli původně zaměřeni na klasické pobočkové ústředny. Jedná se o Siemens7, Avaya, Nortel (akvizice Avaya), Alcatel-Lucent, NEC, AAstra a další. S trendem sjednotit komunikační nástroje pod názvem Unified Communications se do tohoto segmentu trhu snaží proniknout i řada dalších výrobců. Jedná se o výrobce původně videokonferenčních zařízení, kterými jsou například Tandberg (akvizice Cisco) a Polycom. Výrobcem vycházejícím z komunikačních infrastruktury je Cisco. Výrobcem operačních systémů je Microsoft. Univerzálním výrobcem hardware a aplikací je IBM. Každý z těchto výrobců se snaží uchopit maximální část tohoto tržního segmentu. Výrobci si uvědomují, že ten který ovládne všechny oblasti Unified Communications bude absolutním vítězem v oblasti multimediálních komunikací.

7

Původně se jednalo o Siemens divizi COM, z jedné části vznikla samostatná společnost Siemens Enterprise Communications, www.siemens-enterprise.com zaměřená na oblast enterprise a z další společnost Nokia Siemens Networks http://www.nokiasiemensnetworks.com zaměřená na operátory. 58

Příkladem jejich obdobné strategie je řada podobných marketingových aktivit, které prezentují oblasti Unified Communications a jejich schopnost dokonalého provázání. Následující obrázek ukazuje čtyři vzorové společnosti a jejich marketingové zaměření na oblasti Unified Communications. Obrázek č. 5: Marketingová strategie směrem k UC Siemens Enterprise Communications

Cisco

Microsoft

Polycom

Zdroje: Siemens Enterprise Communications www.siemens-enterprise.com, Cisco www.cisco.com, Microsoft www.microsoft.com, Polycom www.polycom.com

7.3. Výběr vzorového výrobce K popisu vzorového řešení a ukázání provázanosti IP telefonie s oblastí UC byl autorem této práce vybrán jeden vzorový výrobce s uceleným portfoliem multimediálních komunikačních služeb. Při výběru byly zvoleny následující kritéria: 

řešení postavené na čisté IP telefonii,



řešení určené pro oblast firemních zákazníků s více než 5000 uživateli,



široká podpora standardů,



komunikační protokoly SIP RTP/RTCP, 59



aplikační nadstavby,



moderní multimediální služby – Unified Communications: o prezence, o přenos zpráv, o sdílení dokumentů, o integrace do uživatelského desktopu, o dostupnost pod jediným číslem, o mobilita.



integrace videa a videokonference

Výběr vzorového výrobce byl proveden rovněž s ohledem na historické vazby s klasickou telefonií a jeho posun k aplikacím a integraci portfolia Unified Communications.

7.3.1. Vzorové řešení IP telefonie Jako vzorové řešení byl zvolen produkt Siemens OpenScape Voice s rozšířením o nadstavby Siemens OpenScape Unified Communications a Siemens OpenScape Video výrobce Siemens Enterprise Communications. Tento produkt splňuje všechny výše uvedené podmínky8. Cílem použití vzorového řešení je ukázat a vyhodnotit produkt s maximální provázaností komunikačních protokolů a multimediálních služeb.

7.3.1.1. Siemens OpenScape Voice Jako vzorový, hlasový, komunikační systém byl zvolen produkt Siemens OpenScape Voice V4.19. Tento produkt podporuje standardizované protokoly SIP, MGCP, RTP/RTCP a CSTA a je postaven na základech SOA [11]. OpenScape Voice poskytuje maximální dostupnost služeb, protože podporuje plně redundantní konfiguraci řídících serverů, kdy klíčová řídící technologie je rozdělena do nezávislých data center. V případě nedostupnosti jednoho z data center je provoz 8

9

Společnost Siemens je průkopníkem hlasové komunikace. Za zmínku stojí fakt, že zakladatel této společnosti Ernst Werner von Siemens již na začátku elektronické komunikace přispěl řadou patentů ke zdokonalení přenosu zpráv na dlouhé vzdálenosti pomocí telegrafu a následně i k zavedení první telefonie. Autor této práce čerpá z vlastních zkušeností. Autor práce vlastní platný certifikát Siemens Open Communication Professional (SOCP), který získá jen osoba s vynikající znalostí produktů Siemens Enterprise Communications, autor pracuje 4 roky ve stejné společnosti na pozici Solution Architect. 60

zachován bez vlivu na koncové uživatele. Řešení je určeno pro 300 až 100000 uživatelů. Koncová hlasová zařízení mohou být rozmístěna kdekoliv po konvergované komunikační infrastruktuře a to jak v národním, tak i mezinárodním měřítku. Jádro řídícího serveru OpenScape Voice je postaveno na jádru OS SLES, nad kterým je provozován software clusteru Fujitsu PrimeCluster. Nad Fujitsu PrimeCluster je provozována databáze IBM SolidTech, nad ní middleware Resilient Telco Platform (RTP). Nad RTP jsou provozovány protokolové stacky SIP, MGCP a CSTA. Vedle těchto stacků je tam umístěn webový, management portál Common Management Portal (CMP). Strukturu programového vybavení řídících serverů Siemens OpenScape Voice zapojených v clusteru ukazuje následující obrázek. Obrázek č. 6: Struktura clusteru OpenScape Voice

Zdroj: Siemens Enterprise Communications: SOCP Study Guide: Open & Converged Network Consultant HiPath 8000, Siemens Enterprise Communications GmbH & Co. KG, 2008, str. 141

7.3.1.2. Siemens Common Management Portal Řešení Siemens OpenScepe Voice používá ke správě řešení webové prostředí nazývané Common Management Portal. CMP je oddělen od řídícího serveru IP telefonie jen v případě, že je řešení navrženo pro velké množství uživatelů v HA režimu. CMP ukazuje náhledy na provozní, výkonnostní a bezpečnostní charakteristiky serverů. Přístup je řešen s ohledem na role administrátorů RBAC. Náhled na GUI rozhraní CMP ukazuje následující obrázek. Obrázek č. 7: Náhled na management rozhraní systému10 10

Produkt Siemens OpenScape Voice je rovněž nazýván jako HiPath 8000. Oficiální přejmenování produktu na OpenScape Voice bylo provedeno výrobcem ve verzi 3.1 61

Zdroj: Autor s pomocí Siemens Enterprise Communications

7.3.1.3. Siemens DLS Management řešení je také zaměřen na správu IP telefonů, kdy jejich nastavení, správa, inventarizace, vnucení konfiguračních a bezpečnostních profilů je prováděna centrálně. DLS umožňuje automatickou registraci nových IP telefonů, povyšování firmware, detekování jejich provozního stavu a porušení nastavení bezpečnostní politiky. DLS se používá k centrální distribuci, konfiguraci, inventarizaci, aktualizaci a zabezpečení IP telefonů. Nástroj umožňuje vytvořit profily, které jsou centrálně aplikovány na skupiny IP telefonů. Náhled na GUI management rozhraní DLS je uveden níže.

62

Obrázek č. 8: Náhled na management koncových přístrojů


Nastavení zahrnuje parametry QoS, SNTP, SNMP, LDAP, webového přístupu, povyšování firmware IP telefonů. Nastavení zahrnuje bezpečnostní funkce včetně oprávnění k použití služeb, přístupová hesla a práva, použití digitálních certifikátů k ověřování vzdáleného management přístupu, přístupu do LAN dle 802.1X a integraci s PKI. Management nástroje používají webové rozhraní postavené na HTTPS. Management rozhraní je zabezpečeno mechanizmem TLS. Konfigurace IP telefonů je prováděna protokolem HTTPS/SOAP/XML.

7.3.1.4. IP telefony Siemens OpenStage Řešení OpenScape Voice používá IP telefony. K náhledu na vzhled IP telefonů je níže uvedena ukázka čtyř vzorových modelů IP telefonu Siemens OpenStage.

63

Tabulka č. 18: Náhled na IP telefony Siemens OpenStage Modely IP telefonů Siemens OpenStage

OpenStage 20

OpenStage 60

OpenStage 40

OpenStage 80

Zdroj: Siemens Enterprise Communications, popsáno autorem

Dle obrázku výše je zřejmé, že se IP telefony OpenStage liší svým provedením, vybavením a mírou komfortu, což se odráží na cenové náročnosti produktů. Tento princip produktových řad je obdobný u dalších výrobců Cisco, Avaya, Alcatel-Lucent a dalších. Detailní náhled na ovládací prvky IP telefonu Siemens OpenStage 60 ukazuje následující obrázek.

64

Obrázek č. 9: Podrobný náhled na IP telefon Siemens OpenStage 60 Optická signalizace volání – modrá LED

Nastavitelný TFT barevný displej; 5,7” QVGA (320x240 Pixel); podsvícený

8 volně programovatelných dotekových tlačítek – modrá LED, 2 úrovně

Tlačítka funkcí:

  

Tlačítka funkcí:

Rozpojení



Přesměrování volání – modrá LED



Hlasová volba - modrá LED



Doteková tlačítka:

     

Reproduktor modrá LED Náhlavní souprava - modrá LED Mute - modrá LED

Telefonie Podsvícený TouchSlider pro nastavení hlasitosti

Telefonní seznam Seznam volání Schránka



Aplikace Nápověda Navigační prvek

Tlačítková číselnice

  

Přípojka pro náhlavní soupravu Bluetooth 2.0 USB (master) Polyfonní vyzváněcí tóny


Souhrn zajímavých vlastností IP telefonu OpenStage 60: 

grafický displej barevný s rozlišením QVGA,



obsluha 3 a více telefonních linek,



žurnál volání,



video hovor ve spolupráci s počítačem,



volitelně programovatelná tlačítka,



rozšíření funkčních tlačítek – přídavné moduly,



podpora rozhraní XML, aplikace,



integrace s adresářovými službami na základě LDAP,



integrovaný mini-LAN Ethernet přepínač pro připojení počítače,



podpora VLAN a QoS dle IEEE 802.1 p/Q,



podpora napájeni IEEE 802.3af (Power over Ethernet),



podpora digitálních certifikátů dle X.509, šifrování signalizace i hlasových dat dle SIP-TLS/H.235, SRTP,



ověřování přístupu do LAN dle IEEE 802.1X,



dálkový dohled, dálková správa přes webové rozhraní [21]. 65

7.3.1.5. Rozhraní pro připojení příslušenství IP telefony OpenStage disponuje širokou škálou rozhraní pro připojení rozšiřujících zařízení. Vedle konektoru pro externí napájecí zdroj a dvou rozhraní Ethernet pro připojení do LAN a připojení uživatelského PC, která jsou samozřejmostí, je k dispozici ještě konektor pro náhlavní soupravu, port USB (OpenStage 60) a bezdrátové rozhraní Bluetooth (OpenStage 60). Obrázek č. 10: Fyzické konektory IP telefonu OpenStage 60


Rozhraní Bluetooth V2.0 je možné využít pro připojení náhlavní soupravy a dalších zařízení.

7.3.1.6. Aplikační platforma XML Díky otevřenému rozhraní XML je možné na IP telefonu implementovat aplikaci dle požadavků zákazníka.

66

Příkladem XML aplikací, které lze na IP telefonech OpenStage provozovat mohou být aplikace počasí, sledování akcií, aukce nebo sledování letu letadel na letišti11.

7.3.1.7. Přístup k adresáři – LDAP klient Pomocí IP telefonu je umožněno vyhledávání ve firemním adresáři pomocí dotazů LDAP. Hledat lze rychle podle různých, pokročilých, vyhledávacích požadavků. Níže je zobrazen způsob hledání cílového uživatele přes rozhraní displeje IP telefonu s podporou protokolu LDAP. Obrázek č. 11: Přístup k adresáři a vyhledávání protokolem LDAP

Zdroj: Autor ve spolupráci se Siemens Enterprise Communications

7.3.1.8. Hlasová pošta OpenScape Xpressions Prostřednictvím XML aplikace lze přistupovat k hlasové schránce systému OpenScape Xpressions a ovládat ji, včetně odesílání nových zpráv. Níže je zobrazeno ovládání hlasové pošty a správy záznamů přes grafické rozhraní IP telefonu.

11

Dále v textu jsou umístěny ukázky zobrazení displeje IP telefonu OpenStage 80 při využití XML rozhraní IP telefonu. Obrázky byly vytvořeny v testovacím provozu demo prostředí Siemens Enterprise Communications. 67

Obrázek č. 12: Hlasová pošta a její ovládání z displeje


7.3.1.9. Zobrazení IP kamery/vrátníku Pomocí této XML aplikace je možné pomocí IP telefonu OpenStage zobrazit video signál z IP kamery/vrátníku. Tato funkce je vhodná pro všechna pracoviště vyžadující sledování dění ve vzdálené lokalitě bez instalace dalšího, speciálního zobrazovacího zařízení. Vše se odehrává na barevném displeji IP telefonu. Náhled na výstup z IP kamery, vrátníku je zobrazen na následujícím obrázku.

68

Obrázek č. 13: IP kamera, vrátník a náhled na displej


7.3.1.10. Čtení RSS kanálů přes XML Jako zdroj krátkých, aktuálních informací může být využita XML aplikace pro čtení RSS (Rich Site Summary) kanálů zpravodajských i jiných webových serverů.

7.4. Hlasové brány Příkladem řady hlasových brán můžou být produkty Siemens RG 8700, který obsahují Ethernet (IP/SIP) a několik E1 rozhraní. E1 rozhraní je možné konfigurovat do režimu ISDN PRI nebo QSIG. Obrázek níže ukazuje bránu Siemens RG 8700. Obrázek č. 14: Hlasové brány řady RG 8700


Hlasové brány Siemens RG 8700 V1.3 jsou dostupné ve třech hardwarových modelech, které se liší počtem E1 portů. Všechny tři modely mohou být zapojeny v redundantní konfiguraci.

69

Tabulka č. 19: Parametry hlasových brán Siemens RG 8700 Brána

Porty E1 PRI/QSig

RG 8702 RG 8708 RG 8716

2 8 16

Doporučený počet zařízení – Survivability 300 1000 2000

Zdroj: Siemens Enterprise Communications: SOCP Study Guide: Open & Converged Network Consultant HiPath 8000, Siemens Enterprise Communications GmbH & Co. KG, 2008, str. 138

RG 8700 podporuje audio kodeky G.711, G.723, G.726 a G.729A/B a nabízí podporu pro řadu komunikačních režimů, včetně přenosu hlasu, analogového faxu a modemu. Přenos faxové komunikace je realizován dle standardu T.38 nebo nekomprimujícím kodekem G.711. Výše zmíněná funkce Survivability je velice důležitou vlastností, neboť lokality jsou obyčejně geograficky distribuovány. RG 8700 slouží nejen jako brána s ISDN PRI rozhraním do VTS, ale též jako řídicí jednotka v okamžiku, kdy je kvůli výpadku WAN hlasový systém dočasně nedostupný. Tato dostupnost je dosažena tím, že IP telefony jsou v normálním režimu registrovány duálně, tzn. k systému OpenScape Voice a dané bráně RG 8700 nebo registrovány pomocí SIP proxy v samotné bráně. Přechod mezi normálním režimem a survivable režimem je plně automatický a pro uživatele téměř nepostřehnutelný. V důsledku nedostupnosti OpenScape Voice je však funkcionalita IP telefonů omezena na základní služby, např. hlasové zprávy nejsou k dispozici. V režimu survivability jsou záznamy o hovorech (CDR), které jsou standardně generovány a uchovávány systémem OpenScape Voice, zpracovávány lokální bránou RG 8700. Jedná se o podmnožinu CDR záznamů, které jsou ukládány v bráně v případě nedostupnosti OpenScape Voice. Stažení dat z paměťového bufferu brány je zajištěno vyčítáním tarifních vět centrální tarifikační aplikací. Dalšími branami mohou být produkty výrobce Cisco, kdy funkce hlasových bran je obsažena v Cisco směrovačích. Dalším výrobcem hlasových bran může být Mediatrix. Spolupráce komponent řešení je dána podporou široce uznávaných standardů. Výrobci obyčejně podporují certifikační program, který ověří soulad se standardy a správnou funkci v řešení.

70

7.4.1. Siemens OpenScape Unified Communications Příkladem integrace IP telefonie do prostředí uživatelského počítače a provázání s dalšími multimediálními službami je produkt Siemens OpenScape Unified Communications. Tento produkt je klient-server aplikací, která je dohromady provozována s IP telefonií. Produkt doplňuje služby jak na straně uživatelského počítače, tak i v IP telefonu. V tomto případě se nejedná o samostatný, softwarový IP telefon, ale o novou generaci rozšířeného Computer Telephony Integration (CTI) klienta, který paralelně zobrazuje stavy a ovládá pevný uživatelský IP telefon. Znamená to, že stavy signalizace telefonování a telefonního žurnálu jsou vidět jak v PC, tak pevném IP telefonu. PC s CTI klientem a IP telefonem se funkčně vzájemně doplňují. Konkrétní příklad klienta zobrazuje následující obrázek. Obrázek č. 15: Příklad aplikační integrace PC a IP telefonu

Zdroj: Autor ve spolupráci se Siemens Enterprise Communications 71

Tímto klientem je Siemens OpenScape Desktop Client, který v sobě obsahuje množství funkcí pokrývajících širokou oblast Unified Communications. Jedná se především o následující funkce: 

CTI funkcionalita, vč. integrace s MS Outlook,



řízení přítomnosti včetně integrace s MS Outlook (Presence Management),



dosažitelnost pod jediným telefonním číslem (One Number Service),



ovládání a správa konferencí včetně integrace s MS Outlook,



seznam kontaktů včetně integrace s MS Outlook,



žurnál volání – přehled příchozích, odchozích a ztracených volání,



Instant Messaging – textové zprávy,



videohovory – spojení telefonie s videem,



pravidla k použití služby telefonie.

7.4.1.1. Dostupnost pod jediným telefonním číslem V případě, že uživatel používá více komunikačních zařízení typu pevný telefon, mobilní telefon nebo PDA, může si v závislosti na jeho aktivitách volit preferované zařízení, dostupný je pak stále pod jedním telefonním číslem. Uživateli jsou příchozí hovory na jeho telefonní číslo a virtuální linku směrovány na preferované fyzické koncové zařízení dle jeho aktuální stavu dostupnosti (prezence). Pro pokročilejší nastavení může uživatel dále vytvářet pravidla pro příchozí volání, stanovovat jejich priority, kombinovat je do profilů a tyto profily pak podle situace a potřeby aktivovat. Možnosti pravidel jsou následující: Filtrace příchozích volání – uživatelská pravidla lze použít k filtraci volání v souladu se stanovanými kritérii a k následnému provedení nějaké specifické akce. K dispozici jsou níže uvedená kritéria, která lze kombinovat: 

číslo volajícího,



stav přítomnosti uživatele,



typ volání (interní/externí),



přesměrované volání,



datum/čas.

72

Akce – na základě filtračních kritérií lze volání přesměrovat na jiné číslo. Dále lze alternativně jednomu nebo více příjemcům poslat e-mail s libovolně definovatelným textem nebo zvolit Instant Messaging. Seznamy osob – je-li třeba v různých pravidlech opakovaně používat sady specifických telefonních čísel, tato čísla lze zkombinovat do seznamů, které lze následně použít v různých pravidlech při filtraci příchozích volání. Události – mají-li se v různých pravidlech opakovaně používat specifické události (týkající se např. dovolené), tato data lze kombinovat do seznamů, které lze následně použít v různých pravidlech při filtraci příchozích volání. Možnosti přesměrování volání jsou následující: Přesměrování volání pomocí pravidel – tato funkce umožňuje uživatelům přesměrovat příchozí volání na jiné číslo, když jsou na schůzce, dovolené nebo služební cestě, atd. To zaručuje, že se příchozí volání neztratí, když uživatel nebude na svém pracovišti a bude zpracováno tím nejvhodnějším způsobem. Přesměrování volání zůstává aktivní až do explicitního zrušení nebo změny. Příchozí volání se přesměrovávají na specifické číslo, jsou-li splněny tyto definované podmínky. Preferované zařízení – v závislosti na tom, co je třeba, může uživatel pomocí panelu nástrojů aktivovat jakékoli dříve zkonfigurované komunikační zařízení. Na toto zařízení se pak přesměrují všechna příchozí a odchozí volání. Odchozí volání se přesměrují, jen když bude aktivované zařízení pro ně vhodné. Bude-li to chtít, uživatel může definovat různá zařízení pro příchozí a odchozí volání. Výsledkem je vytvoření řady uživatelských profilů, které v závislosti na momentálním pracovním zatížení uživatele a jeho fyzickém umístění umožní zpracovávat hovory, příp. další typy multimediální komunikace a to vždy tou nejvhodnější cestou.

7.4.1.2. Uživatelská prezence Významnou funkcionalitou OpenScape Unified Communications je řešení uživatelské prezence. Jedná se o prezenci integrovanou, která zahrnuje jednak primární prezenci, kterou si nastavuje každý uživatel, a také media prezenci odrážející stav telefonu uživatele a též prezenci pro Instant Messaging (text chat).

73

Integrovaná prezence může čerpat též z externích zdrojů. Je obsažen konektor na kalendář aplikace MS Outlook, k dispozici je API pro integraci na další systémy. Řešení obsahuje bezpečnostní, aplikační bránu na externí IM systémy AoL, GaduGadu, ICQ, IRC, MSN, Yahoo! Messenger, Google Talk, QQ, SIP/SIMPLE a XMPP. Výběr

stavů

prezence

a

profilů

je

prováděn

automaticky

v závislosti

na

předdefinovaném nastavení a aktivitách v kalendáři. Změny lze rovněž provádět vzdáleně pomocí softwarového klienta v mobilním telefonu nebo PDA.

7.4.1.3. Webové konference, IM Součástí OpenScape Unified Communications je též softwarový modul webových konferencí Netviewer, který umožňuje rozšířit telekonferenci dvou nebo více uživatelů o sdílení aplikací a dokumentů. Lze také rozšířit probíhající telefonní hovor o video složku a vyvolat e-mail nebo Instant Messaging (text chat) s druhou stranou hovoru. Jako klienta pro aktivaci výše uvedených funkcí může uživatel využít aplikaci na svém PC, webový portál, hlasový portál (z libovolného telefonu) nebo aplikaci na pevném telefonu, lze též doplnit aplikaci na mobilním telefonu.

7.4.1.4. Sdílení dokumentů Součástí řešení OpenScape Unified Communications je též softwarový modul webových konferencí Netviewer, který zajišťuje sdílení aplikací a dokumentů v rámci telekonferenci nebo videokonferenci dvou a více uživatelů. Plánování konferencí je možné provádět přímo z aplikace MS Outlook. V případě potřeby lze NetViewer použít i samostatně mimo ostatní služby OpenScape Unified Communications.

7.4.2. Siemens OpenScape Video Dále je možné doplnit IP telefonii o použití řešení videotelefonie a videokonference postavené na produktu Siemens OpenScape Video. Produkt poskytuje řešení s vysokým rozlišením přenášeného videa (HD video) se signalizačními protokoly SIP a H.323. Jednotlivá koncová zařízení budou registrovaná k hlasovému systému OpenScape Voice pomocí signalizačního protokolu a budou součástí jediného, společného číslovacího plánu. Vytvoření video hovoru je možné pouhým vytočením čísla koncového zařízení.

74

Řešení OpenScape Video nabízí tři základní, různé, hardwarové modely. Dále je k dispozici softwarový videoklient, který je součástí klienta OpenScape Desktop Client. Vytvoření videokonference o více než dvou účastnících je možné pomocí vícebodových řídících jednotek (MCU) vestavěných v terminálech VHD nebo pomocí externích MCU, které umožní vytvoření videokonference až se 40 účastníky. Multimediální materiál a dokumenty mohou být sdíleny mezi všemi koncovými zařízeními s podporou videa, což umožňuje efektivnější spolupráci týmů, které jsou geograficky rozptýlené.

7.4.2.1. OpenScape VHD terminály Všechny OpenScape VHD terminály pracují standardně s rozlišením videa 1280 x 720 pixelů (720 p) při 30 snímcích za sekundu. Pokud je dispozici nižší přenosová rychlost než cca 1 Mbit/s, která neumožňuje využití uvedeného rozlišení, jsou dynamicky použity nejvhodnější možné parametry videa a audia. Účastnit se konference mohou i koncová zařízení, která dokáží pracovat pouze se signálem ve standardním rozlišením (SD), a co je důležité, nedegradují kvalitu komunikace mezi HD zařízeními. Zařízení OpenScape VHD používají standardizované signalizační protokoly SIP a H.323, které zajišťují interoperabilitu s odpovídajícími zařízeními. Implementovanými video kodeky jsou H.263, H.263+, H.264 a H.239, zpracování zvuku zajišťují kodeky G.711, G.722, G.729 a MPEG-4 AAC-LC.

7.4.2.2. OpenScape Desktop Client Účastníci videokonference mohou být kromě výše zmíněných hardwarovým koncových zařízení vybaveni softwarovým klientem OpenScape Desktop Client. Tento klient je registrován k OpenScape Voice jako koncové zařízení s podporou SIP a umožňuje videohovory typu bod-bod s kodekem H.263. Dále bude podporována interoperabilita se zařízeními řady VHD s kodekem H.264 a bude možné se zapojit do konference o více než dvou účastnících s využitím buď vestavěných nebo samostatných MCU.

75

Obrázek č. 16: Klienti OpenScape UC a OpenScape Video

Zdroj: Siemens Enterprise Communications

7.4.2.3. Aplikační rámec OpenScape Aplikace a hardwarové komponenty Siemens OpenScape jsou dobrým příkladem možnosti provázaní multimediální komunikace, kdy jednotlivé části tvoří modulární strukturu se standardizovanými i rovněž proprietárními rozhraními. Je jasné, že použití výše uvedených aplikací a hardwarových komponent výrobce Siemens Enterprise Communications zajišťuje vzájemnou podporu široké škály služeb, funkcí a interoperability především díky tomu, že se jedná o produkty stejného výrobce. Integrace s produkty třetích stran je samozřejmě obecně možná, je však zřejmé, že množství podporovaných služeb a funkcí bude nižší a to v závislosti na použitých, otevřených rozhraních a jednotně implementovaných standardech.

76

8. Stanovení přínosů pro uživatele Hlavní hlasovou technologií se stává IP telefonie. O proti dřívějším metodám přenosu se chová jako jedna z dalších aplikací provozovaných v komunikační infrastruktuře nad IP protokolem. To platí i pro další multimediální způsoby komunikace včetně obrazu, textu, hudby, sdílení dokumentů a stavu prezence, které se postupně integrují s hlasovým základem do univerzálních komunikačních prostředků a aplikací. Vzniká tak široce provázané, technologické zázemí postavené na obecně uznávaných standardech. Toto technologické zázemí je efektivní především v podnikovém prostředí, kde je vyžadována úzká spolupráce a součinnost k plnění pracovních úkolů a k trvalému kontaktu se zákazníky. Uživatel si volí nejvhodnější způsob komunikace a výměny informací,

který

je

v daném

okamžiku

nejúčinnější.

Rutinní

operace

jsou

minimalizovány do intuitivních kroků k ovládání komunikačních prostředků. Hlavní přínosy pro uživatele jsou: 

uživatel může volit nejvhodnější prostředek komunikace, kterým bude v dané situaci nejlépe dostupný – preferované komunikační zařízení/preferovaná komunikační služba,



uživatel může používat jediné kontaktní číslo, aby byl trvale dostupný přes toto číslo všemi jeho telefonními zařízeními – dostupnost pod jediným telefonním číslem,



uživatel může používat: o univerzální komunikační prostředky postavené na aplikaci v jeho PC, o dedikované, vysoce kvalitní, specializované, komunikační prostředky postavené na specializovaných, hardwarových zařízení,



uživatel vnímá komunikační prostředí jako transparentní unifikované přenosové médium.

Efektivita je však plně závislá na následujících faktorech: 

volba požadovaných služeb se vždy odvíjí od pracovní náplně uživatele,



potřeby podniků, organizací či jednotlivců se mohou zásadně lišit, použití takových to prostředků by mělo být vždy důkladně vyhodnoceno,

77



implementace nejnovější komunikační technologie znamená náklady a proto si mohou takovéto služby dovolit jen finančně zabezpečené subjekty,



vývoj komunikace se stále vyvíjí a v okamžiku tvorby této práce pravděpodobně vznikají nové, lépe propracované způsoby komunikace.

78

Závěr Rychlý vývoj komunikačních technologií jde ruku v ruce s požadavky na maximálně efektivní způsob komunikace. Telefonie se pomalu integruje s dalšími komunikačními technologiemi. IP telefonie se stává další aplikací ve sjednoceném komunikačním prostředí díky otevřenosti a standardizaci protokolů a rozhraní. Maximální, synergický efekt využívá primárně komerční sféra jako nástroj k posílení výhody nad konkurencí a k zajištění vyšší efektivity k zajištění podnikových procesů. Pro určité provozy dané svým zaměřením můžou být IP telefonie a navazující aplikace drahé a některé funkce dostatečně nevyužitelné. Především konzervativní subjekty mohou stále volit tradiční telefonii, která je v jejich očích vyzrálou a spolehlivou technologií. IP telefonie vyžaduje technologické předpoklady dané konvergovanou, komunikační infrastrukturou, včetně zajištění kvality služeb, napájení IP telefonů z LAN, dostupnosti podpůrných služeb, připravenosti kabelových rozvodů a aktivních prvků samotných. Volba správné technologie závisí na zaměření daného subjektu, jeho obchodních cílech a podmínkách provozu daných prostředím, konkurencí a legislativou. Důležité jsou rovněž schopnosti koncových uživatelů, jejich náplň práce a přístup k novým technologiím. Důležitá je ochota subjektu inovovat a mít zajištěné finanční a technologické prostředky nejen k implementaci, ale i k následujícímu, dlouhodobému provozu.

79

Použitá literatura Tištěné monografie: [1] DONOHUE, Denise; MALLORY, David; SALHOFF, Ken. Cisco Voice Gateways and Gatekeepers. Indianapolis : Cisco Press, 2006. 648 s. ISBN-10: 158705-258-X; [2] GRAYSON, Mark; SHATZKAMER, Kevin; WAINNER, Scott. IP Design for Mobile Networks. Indianapolis : Cisco Press, 2009. 531 s. ISBN-10: 1-58705826-X; [3] HANES, David; SALGUEIRO, Gonzalo. Fax, Modem, and Text for IP Telephony. Indianapolis : Cisco Press, 2008. 574 s. ISBN-10: 1-58705-269-5; [4] CHURCH, Steve; PIZZI, Skip. Audio over IP – Building Pro AoIP. Burlington : Focal Press, 2010, 259 s. ISBN 978-0-240-81244-1; [5] JOHNSTONE, Alan, B. SIP – Understanding the Session Initiation Protocol. Norwood : Artech House Inc., 2004. 283 s. ISBN 1-58053-655-7; [6] KAZA, Ramesh; ASADULLAH, Salman. Cisco IP Telephony: Planning, Design, Implementation, Operation, and Optimization. Indianapolis : Cisco Press, 2005. 648 s. ISBN 1-58705-157-5; [7] OLSEN, Chris. Implementing Cisco Unified Communications Manager, Part 2. Indianapolis : Cisco Press, 2008. 552 s. ISBN-10: 1-58705-561-9; [8] OSBORNE, Giles. All-in-one CCIE Study Guide. New York : McGraw-Hill Professional, 1999. 1008 s. ISBN: 0-07-135676-2; [9] PARK, Patrick. Voice over IP Security. Indianapolis : Cisco Press, 2008. 361 s. ISBN-10: 1-58705-469-8; [10] SCHURMAN Joe. Microsoft Voice and Unified Communications, New York : Addison-Wesley Professional, 2009. 269 s. ISBN-10: 0-32157-995-X; [11] SIEMENS ENTERPRISE COMMUNICATIONS. SOCP Study Guide: Open &Converged Network Consultant HiPath 8000. Munchen : Siemens Enterprise Communications GmbH & Co. KG, 2008. 260 s. Order No. A31005-PCO8-ENE1; [12] SULKIN, Allan. PBX Systems for IP Telephony. New Yourk : McGraw-Hill Professional, 2002. 487 s. ISBN-10: 0-07137-568-6; [13] SZIGETI, Tim; MCMENAMY, Kevin; SAVILLE, Roland; GLOWACKI, Alan. Cisco TelePresence Fundamentals. Indianapolis : Cisco Press, 2009. str. 592. ISBN-10: 1-58705-593-7; 80

[14] WALLACE, Kevin. Cisco Voice over IP (CVOICE). Indianapolis : Cisco Press, 2008. str. 504. ISBN-10: 1-58705-554-6; [15] WARREN, Dave; HARTMANN, Dennis. Cisco Self-Study: Building Cisco Metro Optical Networks. Indianapolis : Cisco Press, 2008. str. 483. ISBN-10: 158705-798-0; Elektronické monografie: [16] CISCO [online]. 2006 [cit. 2010-03-21]. How Instant Messaging Is Transforming the Enterprise Network. Dostupné z WWW: . [17] GOOGLE PATENTS [online]. 1876 [cit. 2010-03-21] Improvements in telegraphy – Alexander Graham Bell. Dostupné z WWW: . [18] ITU-T [online]. 1990 [cit. 2010-03-21] Recommendation Q.23, Fascicle VI.1 – Rec. Q.23. Dostupné z WWW: < http://www.itu.int/rec/T-REC-Q.23/en>. [19] ITU-T [online]. 1998 [cit. 2010-03-21] Recommendation P.800, Telephone Transmission Quality. Dostupné z WWW: < http://www.itu.int/rec/T-RECP.800-199608-I/en>. [20] SIEMENS ENTERPRISE COMMUNICATIONS [online]. 2009 [cit. 2010-03-21] HiPath 4000 verze 5.0. Dostupné z WWW: . [21] SIEMENS ENTERPRISE COMMUNICATIONS [online]. 2009, [cit. 2010-0321] IP Telefonie OpenStage SIP. Dostupné z WWW: . [22] WIKIPEDIA [online]. 2009, [cit. 2010-03-21] History of the telephone. Dostupné z WWW: . [23] WIKIPEDIA [online]. 2009, [cit. 2010-03-21] Power over Ethernet. Dostupné z WWW:.

81

Seznam obrázků Obrázek č. 1: Nezapojená telefonní ústředna Siemens HiPath 4000 ............................. 15 Obrázek č. 2: Porovnání mezi řešením s telefonní ústřednou a IP telefonií.................. 21 Obrázek č. 3: Dedikované a univerzální přenosové prostředky ..................................... 23 Obrázek č. 4: Řešení IP telefonie v prostředí LAN/WAN ............................................. 48 Obrázek č. 5: Marketingová strategie směrem k UC ..................................................... 59 Obrázek č. 6: Struktura clusteru OpenScape Voice ....................................................... 61 Obrázek č. 7: Náhled na management rozhraní systému ............................................... 61 Obrázek č. 8: Náhled na management koncových přístrojů ........................................... 63 Obrázek č. 9: Podrobný náhled na IP telefon Siemens OpenStage 60 ........................... 65 Obrázek č. 10: Fyzické konektory IP telefonu OpenStage 60........................................ 66 Obrázek č. 11: Přístup k adresáři a vyhledávání protokolem LDAP ............................ 67 Obrázek č. 12: Hlasová pošta a její ovládání z displeje ................................................. 68 Obrázek č. 13: IP kamera, vrátník a náhled na displej ................................................... 69 Obrázek č. 14: Hlasové brány řady RG 8700 ................................................................. 69 Obrázek č. 15: Příklad aplikační integrace PC a IP telefonu ......................................... 71 Obrázek č. 16: Klienti OpenScape UC a OpenScape Video .......................................... 76

82

Seznam tabulek Tabulka č. 1: Kombinace tónů v DTMF signalizaci ...................................................... 12 Tabulka č. 2: Agregace a mapování DS0 kanálů ........................................................... 14 Tabulka č. 3: Nejčastější TDM rozhraní ........................................................................ 16 Tabulka č. 4: Vysokokapacitní rozhraní poskytovatelů ................................................ 17 Tabulka č. 5: Protokoly VoIP ......................................................................................... 25 Tabulka č. 6: Protokoly IP telefonie ............................................................................... 25 Tabulka č. 7: DHCP parametry pro IP telefony ............................................................. 26 Tabulka č. 8: Protokoly VoIP ......................................................................................... 27 Tabulka č. 9: Seznam nejběžnějších kodeků .................................................................. 33 Tabulka č. 10: Hodnocení MOS ..................................................................................... 33 Tabulka č. 11: Kvalitní AoIP kodeky ............................................................................. 35 Tabulka č. 12: Třídy CoS ............................................................................................... 40 Tabulka č. 13: Třída EF striktní priority ........................................................................ 41 Tabulka č. 14: Třídy AF ................................................................................................. 41 Tabulka č. 15: Třídy CS zpětné kompatibility ............................................................... 41 Tabulka č. 16: Třídy napájení dle IEEE 803.af .............................................................. 45 Tabulka č. 17: Nejrozšířenější IM systémy .................................................................... 56 Tabulka č. 18: Náhled na IP telefony Siemens OpenStage ............................................ 64 Tabulka č. 19: Parametry hlasových brán Siemens RG 8700 ........................................ 70 Tabulka č. 20: Seznam použitých zkratek ...................................................................... 84

83

Seznam použitých zkratek Tabulka č. 20: Seznam použitých zkratek Účel 3G/4G AAC-ELD AAC-LD ABR ACL ADPCM AF AIM AMR AoIP AoL AP API ASCII ASN.1 ASR ATM BGP BIVŠ BRI BS CAC CAS CATV CCDP CCIP CCNP CCSP CCVP CBR CDMA CDR CMP CODEC CoS CRM CS CSMA/CD CSTA CTI DECT DHCP DLS DNS DS0 DSCP DSP DTMF DPT DWDM

Protokoly 3. generace/ 4. generace Advanced Audio Coding Enhanced Low Delay Advanced Audio Coding Low Delay Available Bit Rate Access List Adaptive differential pulse-code modulation Assured Forwarding Americe Online Instant Messaging Adaptive Multi-Rate audio codec Audio over IP America Online Access Point Application Programming Interface American Standard Code for Information Interchange Abstract Syntax Notation One Automatic Speech Recognition Asynchronous Transfer Mode Border Gateway Protocol Bankovní institut vysoká škola Basic Rate Interface Base Station Call Admission Control Common Associated Signaling Cable television Cisco Certified Design Professional Cisco Certified Internetwork Professional Cisco Certified Network Professional Cisco Certified Security Professional Cisco Certified Voice Professional Constant Bit Rate Code division multiple access Call Data Records Common Management Portal Coder-decoder Class of Service Customer relationship management Class Selector Carrier sense multiple access with collision detection Computer-supported telecommunications applications Computer telephony integration Digital Enhanced Cordless Telecommunications Dynamic Host Configuration Protocol Deployment Service / Server Domain Name System Digital Signal 0 Differentiated Services Code Point Digital signal processor Dual-tone Multi-frequency Dynamic packet transport Dense wavelength-division multiplexing 84

ECMA EDGE EF EFR ETST EU FDDI FR FTP FXO FXS G3/G4 GAP GbE Gbit/s GSM GUI HA HD HDLC HDSL HFA HQ HTTP HTTPS HW Hz ICT IEC IEEE iLBC IM IP IRC ISDN ISO IT ITU-T IVR J2ME JTAPI kbit/s kHz L2 L3 L7 LAN LANE LED LDAP LD-CELP LLDP LLQ mA MAC Mbit/s MCU

European Computer Manufacturers Association Enhanced Data rates for GSM Evolution Expedited Forwarding Enhanced Full Rate European Telecommunications Standards Institute Evropská Unie Fiber distributed data interface Full Rate File Transfer Protocol Foreign Exchange Office Foreign Exchange Station Group 3/Group 4 Generic access profile Gigabit Ethernet Gigabit za sekundu Global System for Mobile Communications Graphical User Interface High Availability High Definition High-Level Data Link Control High bit rate Digital Subscriber Line HiPath Feature Access High Quality Hypertext Transfer protocol HTTP Secure Hardware Hertz Information and communication technologies International Electro technical Commission Institute of Electrical and Electronics Engineers Internet Low Bitrate Codec Instant Messaging Internet Protocol Internet Relay Chat Integrated Services Digital Network International Organization for Standardization Informační technologie International Telecommunication Union for Telecommunication Interactive Voice Response Java 2 Platform Micro Edition JAVA TAPI Kilobit za sekundu kilo Hertz Layer 2 Layer 3 Layer 7 Local Area Network LAN Emulation Light Emitting Diode Lightweight Directory Access Protocol low-delay code excited linear prediction Link Layer Discovery Protocol Low Latency Queuing miliAmpér Media Access Control address Megabit za sekundu Multipoint control unit 85

MGCP MOS MPEG MPLS ms MS MSN NB NBAR NTP OC-x OC-3 OCS OEM ONS OS OSI PBX PC PCM PD PDA PoE POP3 POS PPP PRI PSE PVC QoS QSIG QVGA RAS RBAC RED RFC RSVP RSS RTP RTCP SAP SCCP SCP SD SDH SDP SFTP SIMPLE SIP SLES SNMP SNTP SMTP SOA SOAP SONET SSH

Media Gateway Control protocol Mean Opinion Score Moving Picture Experts Group Multi-protocol Label Switching milisekund Microsoft Microsoft Network Notebook Network-based Application Recognition Network Time Protocol Optical Carrier Optical Carrier – 3 Office Communications Server Original Equipment Manufacturer One-number Service Operační systém Open System Interconnection Private Branch Exchange Osobní počítač Pulse Code Modulation Powered Device Personal Digital Assistant Power over Ethernet Post Office protocol V3 Packet over SONET Point-to-Point Protocol Basic Rate Interface Power Sourced Equipment Permanent Virtual Circuit Quality of Service Q Signaling Quarter Video Graphics Array Registration, Admission and Status Role-based access control Random Early Detection Request for Comments Resource reservation protocol Really Simple Syndication Real-time Protocol Real-time Control protocol Service Access Point Skinny Client Control Protocol Secure Copy Standard Definition Synchronous Digital Hierarchy Session Description Protocol Secure FTP Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions Session Initiation Protocol SUSE Linux Enterprise Server Simple Network Management protocol Simple Network Time Protocol Simple Mail Transfer Protocol Service-oriented architecture Simple Object Access Protocol Synchronous Optical Networking Secure Shell 86

STM STS SVC TAPI TCP TDM TE TFT TFTP TIaST TLS ToS TTS UBR UC UCM UDP UMTS US USB V VBR NRT VBR RT VC VGA VLAN VoATM VoFR VoIP WAN WML WRED WRR XML XMPP

Synchronous Transport Module Synchronous Transport Signal Switched Virtual Circuit Telephone API Transmission Control Protocol Time-division Multiplexing Traffic Engineering Thin-film Transistor Trivial FTP Technická infrastruktura a síťové technologie Transport Security Layer Type of Service Text-to-Speech Unspecified Bit Rate Unified Communications Unified Communication manager User Datagram Protocol Universal Mobile Telecommunications System Spojené státy Universal Serial Bus Volt Variable Bit rate non-Real-time Variable Bit rate Real-time Virtual Circuit Video Graphics Array Virtual VLAN Voice over ATM Voice over Frame Relay Voice over IP Wide Area Network Website Meta Language Weighted Random Early Detection Weighted Round Robin Extensible Markup Language Extensible Messaging and Presence Protocol

87

Principy moderní hlasové komunikace

Recommend Documents