Principy moderní hlasové komunikace

Transkript

1 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 Ing. Beneš Vladimír Praha Duben, 2010

2 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

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

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

5 Obsah Úvod Principy a vývoj moderní hlasové komunikace Obecné principy Počátky hlasové komunikace První telefonní sítě Vývoj analogové technologie Analogová faxová komunikace Digitalizace veřejných telefonních ústředen Telefonní ústředny v organizacích a podnicích Změny v připojení do VTS Vysokorychlostní páteře poskytovatelů Nástup IP telefonie a Voice over IP Původní koncept oddělených technologických sítí VoIP Současnost Komunikační sítě z pohledu L2 a L Komunikační sítě z pohledu L1 a L IP telefonie a Voice over IP Technologická změna Unified Communications Mobilní technologie Protokoly VoIP Protokoly IP telefonie Signalizace H H.323 komponenty Terminály Brány Gatekeeper MCU Rodina protokolů H Signalizace SIP SIP komponenty SIP/SIMPLE... 31

6 Rodina protokolů SIP Hlasová data Kódování hlasu Problémy s kódováním Speciální kodeky Kvalita služeb Předpoklady k zavedení moderních trendů Kvalita služeb Klasifikace provozu Značení provozu Značení rámců L2 CoS Značení paketů L3 DSCP Upravení, omezení a zahazování provozu Začlenění provozu do front Frontování v L2 prvcích Frontování v L3 prvcích Fragmentace a prokládání paketů Napájení komunikačních komponent Komponenty ve standardním řešení IP telefonie Přehled komponent Řešení výrobců Rozmístění komponent Řídící server IP telefonie IP telefony Hlasové brány Podpůrné aplikace Média server Konferenční server Management server Tarifikační server Integrace adresářových služeb Problémy integrace adresářových služeb Nadstavbové aplikace a jejich integrace do IP telefonie Aplikace CTI Aplikace kontaktního centra... 55

7 6.3. Aplikace Unified Messaging Aplikace automatické spojovatelky Vzorové řešení IP telefonie a Unified Communications Požadavky trhu Strategie výrobců Výběr vzorového výrobce Vzorové řešení IP telefonie Siemens OpenScape Voice Siemens Common Management Portal Siemens DLS IP telefony Siemens OpenStage Rozhraní pro připojení příslušenství Aplikační platforma XML Přístup k adresáři LDAP klient Hlasová pošta OpenScape Xpressions Zobrazení IP kamery/vrátníku Čtení RSS kanálů přes XML Hlasové brány Siemens OpenScape Unified Communications Dostupnost pod jediným telefonním číslem Uživatelská prezence Webové konference, IM Sdílení dokumentů Siemens OpenScape Video OpenScape VHD terminály OpenScape Desktop Client Aplikační rámec OpenScape Stanovení přínosů pro uživatele Závěr Použitá literatura Seznam obrázků Seznam tabulek Seznam použitých zkratek... 84

8 Ú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 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

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áv 1 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 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 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

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

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. Skupina nízkých frekvenc í Tabulka č. 1: Kombinace tónů v DTMF signalizaci Skupina vysokých frekvencí Hz 1336 Hz 1477 Hz 1633 Hz 697 Hz A 770 Hz B 852 Hz C 941 Hz * 0 # D Zdroj: ITU-T: Recommendation Q.23, I!!PDF-E-2.pdf, 1990, str 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

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] 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 13

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 T 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ů Rozhraní Kapacita (kbit/s) Rozhraní Kapacita (kbit/s) DS0 = T0 1x DS0 64 E0 1x E0 64 DS1 = T1 24x DS E1 30x E DS3 = T3 28x DS E3 16x E Zdroj: Dave Waren, Dennis Hartmann: Building Cisco Metro Optical Networks (METRO), Cisco Press, 2008 str. 40, 41 a 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

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 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 byl prvotně specifikován organizací European Computer Manufacturers Association (ECMA), dále byla doporučení transformována 3 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 uživatelů, v síťové konfiguraci lze připojit až uživatelů. 15

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í Evropa Severní Amerika Rozhraní Kanály Signalizace Rozhraní Kanály Signalizace E1 CAS R2 30 In-band T1 CAS 24 In-band ISDN BRI (EU) Out-of-band ISDN BRI (US) Out-of-band E1 ISDN PRI Out-of-band T1 ISDN PRI Out-of-band E1 QSIG Out-of-band T1 QSIG Out-of-band QSIG (BRI) Out-of-band QSIG (BRI) 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 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 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

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 SONET/SDH Rychlost Přenos OC-48 STS-48/STM ,32 Mbit/s (2,5 Gbit/s) POS, DPT OC-96 STS-96/STM ,64 Mbit/s (5 Gbit/s) POS, DPT OC-192 STS-192/STM ,28 Mbit/s (10 Gbit/s) POS, DPT OC-768c STS-768c/STM-256c 39813,12 Mbit/s (40 Gbit/s) 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

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 provozovaný v plně duplexním režimu 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

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

19 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] 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 100GbE 4. 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

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

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

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

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 Zde byla zavedena řada standardů umožňující přenos hlasu na základě IP protokolu včetně podpory QoS (IEEE e), roamingu (IEEE r) a odpovídajícího zabezpečení (IEEE i). 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] 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

24 Výčet protokolů a jejich použití s VoIP uvádí následující tabulka. Tabulka č. 5: Protokoly VoIP Zdroj: Autor Účel Hlasová signalizace Přenos hlasových dat Protokoly SIP, H.323, MGCP RTP/RTCP 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 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 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

25 Zdroj: Autor 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 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. Zdroj: Autor Tabulka č. 7: DHCP parametry pro IP telefony Účel Parametr IP routing / výchozí route 1 & 2 Option 33 IP adresa SNTP/NTP serveru Option 42 Nastavení časové zóny Option 2 IP adresa primárního a sekundárního DNS serveru Option 6 DNS doménové jméno pro IP telefon Option 15 IP adresa SIP Proxy a SIP Registrar serveru Option 120 Vendor-specific parametry (Siemens) Option 43 IP adresa TFTP serveru (Cisco) Option 150 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 dle RFC

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 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] 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ů) 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

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

28 administrace zón. Brány komunikují s gatekeeperem protokolem H.225 RAS. H.225 RAS je kódován v ASN 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ů 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 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 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

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

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á 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 Funkci prezence v SIP protokolu definuje RFC Funkci IM v SIP definuje RFC 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 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) 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

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

32 Tabulka č. 9: Seznam nejběžnějších kodeků Kodek Tok v kbit/s Hodnota MOS G.711 PCM 64 4,1 G ,5 G ,92 G.729 Annex A 8 3,7 G.729 Annex B 8 3,7 G.723.1r53 5,3 3,65 G.723.1r63 6,3 3,9 G.726 ADPCM 32 3,8 G.728 LD-CELP 16 3,6 ilbc 15,2 4,14 AMR 12,2 4,14 GSM EFR 12,2 3,8 GSM FR 12,2 3,5 RTAudio (Microsoft) 8,8 nebo 18 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 Kvalita Vliv na hlas 5 Excelent Neslyšitelný vliv 4 Good Slyšitelná vliv ale vyhovující 3 Fair Jemně degradovaná kvalita 2 Poor Hodně degradovaná kvalita 1 Bad Vyloženě špatná kvalita Zdroj: ITU-T P pdf, 1998, str 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

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

34 Tabulka č. 11: Kvalitní AoIP kodeky Kodek Pásmo vzorkování Tok Vzorkování Popis MPEG AAC-LD 20 khz kbit/s 10 ms Full-fidelity MPEG AAC-ELD 20 khz kbit/s 20 ms 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

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

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

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

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

39 Tabulka č. 12: Třídy CoS Priorita Bit Specifikace dle IEEE 802.1p Použití CoS Best Efford Normální provoz CoS Background - CoS Spare - CoS Excelent Efford Signalizace CoS Controlled Load Video CoS Video Hlas CoS Voice Kontrola sítě CoS Network Control Síťová signalizace Zdroj: Siemens Enterprise Communications: SOCP Study Guide: Open & Converged Network Consultant HiPath 8000, Siemens Enterprise Communications GMBH & CO. KG, 2008, str. 42 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í 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 Striktně prioritní třídu DSCP 46 Expedited Forwarding uvádí následující tabulka. 40

40 Tabulka č. 13: Třída EF striktní priority (DSCP) EF (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) Medium Drop bity (DSCP) High Drop byty (DSCP) AF 1 AF (10) AF (12) AF (14) AF 2 AF (18) AF (20) AF (22) AF 3 AF (26) AF (28) AF (30) AF 4 AF (34) AF (36) AF (38) Zdroj: Szigeti Tim, McMenamy Kevin, Saville Roland, Glowacky Alan: Cisco TelePresence Fundamentals, Indianapolis, Cisco Press, 2009, str. 170 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) IP precedence bity Specifikace IP Precedence dle RFC 791 CS (0) 000 Normal CS (8) 001 Priority CS (16) 010 Immediate CS (24) 011 Flash CS (32) 100 Flash-Override CS (40) 101 Critical CS (48) 110 Internetwork Control CS (56) 111 Network Control Zdroj: Szigeti Tim, McMenamy Kevin, Saville Roland, Glowacky Alan: Cisco TelePresence Fundamentals, Indianapolis, Cisco Press, 2009, str. 171 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

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

42 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 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 Round- Robin (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 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

43 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

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 Použití Proud Maximální (ma) příkon (W) Popis tříd 0 Default 0 4 0,44 12,94 Unknown PD zařízení nepodporuje negociaci třídy 1 Optional ,44 3,84 Low-power PD dohodnutý nízký příkon 2 Optional ,84 6,49 Mid-power PD dohodnutý střední příkon 3 Optional ,49 12,95 High-power PD dohodnutý vysoký příkon 4 Reserved ,95 - Zdroj: Siemens Enterprise Communications: SOCP Study Guide: Open & Converged Network Consultant HiPath 8000, Siemens Enterprise Communications GMBH & CO. KG, 2008, str. 42 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: 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. 5 Název pin vychází z anglického jazyka, kdy se tímto slovem označují jednotlivé metalické plošky rozhraní konektoru 45

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 n nebo CATV kamerové systémy využívající Ethernet rozhraní [23]. 46

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 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/ Ř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

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

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 nebo DECT. Wireless IEEE nativně podporuje přenos hlasu přes IP infrastrukturu s podporou IEEE e/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 Ří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

49 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í 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žby 6. 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

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

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

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

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

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 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é em, 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

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 schránky společně s y. UM zahrnuje i integraci SMS zpráv, kdy je možné propojit mobilní zařízení, IP telefony a ové 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 Výrobce Odhad aktivních uživatelů Komunikační porty AIM AoL 53 miliónů ICQ AoL 15 miliónů 4000 Skype Skype 10 miliónů 80, 443, a další MSN Messenger Microsoft 29 miliónů 1863 Yahoo Messenger Yahoo 21 miliónů 5050 Jabber (XMPP) Cisco 13,5 miliónů Zdroj: Cisco: How Instant Messaging Is Transforming the Enterprise Network: 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 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

56 (Open Source) s protokolem XMPP. Společnost Cisco zase koupila produkt Jabber (XMPP), aby ho integrovala do svého produktového portfolia 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

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 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 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 Siemens 7, 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, zaměřená na oblast enterprise a z další společnost Nokia Siemens Networks zaměřená na operátory. 58

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 59 Polycom Zdroje: Siemens Enterprise Communications Cisco Microsoft Polycom 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 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ínky 8. 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 Siemens OpenScape Voice Jako vzorový, hlasový, komunikační systém byl zvolen produkt Siemens OpenScape Voice V 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

60 zachován bez vlivu na koncové uživatele. Řešení je určeno pro 300 až 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 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ému Produkt Siemens OpenScape Voice je rovněž nazýván jako HiPath Oficiální přejmenování produktu na OpenScape Voice bylo provedeno výrobcem ve verzi

61 Zdroj: Autor s pomocí Siemens Enterprise Communications 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

62 Obrázek č. 8: Náhled na management koncových přístrojů Zdroj: Autor s pomocí Siemens Enterprise Communications 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 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

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

64 Obrázek č. 9: Podrobný náhled na IP telefon Siemens OpenStage 60 Nastavitelný TFT barevný displej; 5,7 QVGA (320x240 Pixel); podsvícený Tlačítka funkcí: Rozpojení Přesměrování volání modrá LED Hlasová volba - modrá LED Doteková tlačítka: Telefonie Telefonní seznam Seznam volání Schránka Aplikace Nápověda Navigační prvek Tlačítková číselnice Optická signalizace volání modrá LED 8 volně programovatelných dotekových tlačítek modrá LED, 2 úrovně Tlačítka funkcí: Reproduktor - modrá LED Náhlavní souprava - modrá LED Mute - modrá LED Podsvícený TouchSlider pro nastavení hlasitosti Přípojka pro náhlavní soupravu Bluetooth 2.0 USB (master) Polyfonní vyzváněcí tóny Zdroj: Siemens Enterprise Communications, popsáno autorem 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 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

65 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 Zdroj: Siemens Enterprise Communications, popsáno autorem Rozhraní Bluetooth V2.0 je možné využít pro připojení náhlavní soupravy a dalších zařízení 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

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šti 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 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