Sem vložte zadání Vaší práce.
České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství
Diplomová práce
Webová aplikace pro pořádání audiokonferencí na platformě Asterisk Bc. Michal Filip
Vedoucí práce: Ing. Jiří Dostál
9. května 2013
Poděkování Rád bych na tomto místě poděkoval všem, kteří pozitivní měrou přispěli k dokončení této práce. Největší roli samozřejmě sehráli lidé v mém okolí. Rodině i příbuzným bych rád poděkoval za plnou podporu po celou dobu studia, přítelkyni Evě pak za pomoc při jazykové korektuře práce i trpělivost v době, kdy jsem převážnou část dne věnoval psaní. Velký dík také patří kolegům, zejména pak Tomáši Ficovi a Lukáši Jandovi, a to jak za konzultace k ryze implementačním detailům, tak za schovívavost vůči neustálému vyzvánění telefonů používaných při vývoji. Tato práce by také nevznikla bez mého vedoucího, Ing. Jiřího Dostála, jehož komentáře zejména k formální stránce práce bezpochyby přispěly k tomu, aby byla nejen čitelná, ale splňovala i nezbytné standardy publikací.
Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů. Dále prohlašuji, že jsem s Českým vysokým učením technickým v Praze uzavřel dohodu, na základě níž se ČVUT vzdalo práva na uzavření licenční smlouvy o užití této práce jako školního díla podle § 60 odst. 1 autorského zákona. Tato skutečnost nemá vliv na ust. § 47b zákona č. 111/1998 Sb., o vysokých školách, ve znění pozdějších předpisů.
V Praze dne 9. května 2013
.....................
České vysoké učení technické v Praze Fakulta informačních technologií c 2013 Michal Filip. Všechna práva vyhrazena.
Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.
Odkaz na tuto práci Filip, Michal. Webová aplikace pro pořádání audiokonferencí na platformě Asterisk. Diplomová práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2013.
Abstract The purpose of this thesis is to design and implement a web application for creating and management of audio conferences hosted on Asterisk call manager. The resulting application is to be integrated with phone system and other parts of customer’s ICT infrastructure. Parts of this thesis are the complete source code, documentation, table values measured during the testing and compiled version of the application. Keywords Asterisk, audio conferencing, web application, Grails
Abstrakt Cílem této diplomové práce je navrhnout a implementovat aplikaci sloužící pro vytváření a správu audiokonferencí provozovaných na telefonní ústředně Asterisk. Výsledkem je webová aplikace, určená k integraci s ústřednou a dalšími prvky ICT infrastruktury zákazníka zadavatele. Součástí práce jsou kompletní zdrojový kód, dokumentace, tabulkové hodnoty naměřené při testování a kompilovaná funkční verze aplikace. Klíčová slova Asterisk, audiokonference, webová aplikace, Grails ix
Obsah Úvod
1
1 Cíle práce 1.1 Metodika testování . . . . . . . . . . . . . . . . . . . . . . .
3 4
2 Analýza a návrh řešení 2.1 Popis digitální telefonní ústředny Asterisk 2.2 Požadavky na aplikaci . . . . . . . . . . . 2.3 Rešerše existujících řešení . . . . . . . . . 2.4 Případy užití . . . . . . . . . . . . . . . . 2.5 Návrh analytických tříd . . . . . . . . . . 2.6 Návrh uživatelského rozhraní . . . . . . . . 2.7 Plánované způsoby nasazení . . . . . . . . 3 Realizace 3.1 Volba použitých technologií . . . . . . 3.2 Nastavení telefonní ústředny Asterisk . 3.3 Integrace aplikace s telefonní ústřednou 3.4 Umožnění sdílení materiálů . . . . . . 3.5 Implementace tarifikace . . . . . . . .
. . . . .
. . . . .
. . . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . . . .
. . . . .
. . . . . . .
7 7 10 13 18 21 23 26
. . . . .
29 29 33 38 47 48
4 Integrace se stávající infrastrukturou 53 4.1 Integrace telefonní sítě . . . . . . . . . . . . . . . . . . . . . 53 4.2 Integrace autentizačních zdrojů . . . . . . . . . . . . . . . . 55 5 Testování 59 5.1 Automatické testování uživatelského rozhraní . . . . . . . . . 59 xi
5.2 5.3
Uživatelské testování . . . . . . . . . . . . . . . . . . . . . . Testování výkonu . . . . . . . . . . . . . . . . . . . . . . . .
60 62
Závěr 65 Náměty pro pokračování projektu . . . . . . . . . . . . . . . . . . 65 Literatura
67
A Seznam použitých zkratek
71
B Obsah přiloženého CD
73
xii
Seznam obrázků 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 3.1 3.2 3.3 5.1 5.2 5.3
Architektura ústředny Asterisk . . . . . . . . . . . . . . . . . . Ukázka rozhraní aplikace Web-MeetMe - správa konferencí . . . Ukázka rozhraní aplikace AppKonference - detail průběhu konference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ukázka rozhraní aplikace BigBlueButton - plánování konference Ukázka rozhraní aplikace BigBlueButton - detail průběhu konference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Model případů užití aplikace - manažer . . . . . . . . . . . . . . Model případů užití aplikace - běžný uživatel . . . . . . . . . . Model tříd aplikace - balíček core (cz.improvisio.visioCore) . . . Model tříd aplikace - balíček conference (cz.improvisio.conference) Graf navigace v aplikaci . . . . . . . . . . . . . . . . . . . . . . Vícestránkový formulář, nastavení zabezpečení konference . . . Detaily konference a její průběh . . . . . . . . . . . . . . . . . . Plánované nasazení pro účely testování . . . . . . . . . . . . . . Diagram nasazení v infrastruktuře zákazníka . . . . . . . . . . . Porovnání vzhledů softwarových SIP klientů (zleva 3CX, X-Lite, Jitsi) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vytvoření obrazovky sdílení . . . . . . . . . . . . . . . . . . . . Správa obsahu v jednotlivých zónách . . . . . . . . . . . . . . . Předpis pro automatické testování grafického rozhraní . . . . . . Průměrný čas strávený prováděním testovacího scénáře dle zkušenosti uživatele a opakování . . . . . . . . . . . . . . . . . . . . Graf testování zátěže - 1 x Xeon @ 2,16 GHz; 1 GB RAM - prům. odezva modře, median fialově, propustnost zeleně . . . . . . . . xiii
8 15 16 17 17 19 20 21 22 24 25 26 27 28 36 47 48 60 61 63
5.4
Graf testování zátěže - 4 x Xeon @ 2,16 GHz; 16 GB RAM prům. odezva modře, median fialově, propustnost zeleně . . . .
xiv
63
Seznam tabulek 2.1
Porovnání funkcí existujících řešení . . . . . . . . . . . . . . . .
18
5.1
Tabulka výsledků naměřených při testování výkonu . . . . . . .
63
xv
Úvod Komunikace a dorozumívání je jednou ze základních potřeb člověka. Nejen pro jednotlivce, ale zejména pro střední a větší společnosti je rychlá a efektivní komunikace nezbytná pro dosažení potřebné efektivity a schopnosti rychle reagovat na každodenní problémy a výzvy. Přes výrazný rozvoj emailové komunikace a možnost jednoduchým způsobem předávat zprávy mnoha adresátům je tato forma v mnoha případech velice neefektivní a zejména v případě, kdy zaslaná zpráva vede ke vzniku diskuze, se stává její moderování nemožným. Logicky vhodnější pro rychlé dorozumívání je použití hlasových přenosů. Až donedávna byla možnost spojení více účastníků v rámci jednoho konferenčního hovoru převážně doménou větších firem a vyžadovala vlastnictví speciálního a často finančně nákladného hardware sloužícího pro mixování analogových hovorů. Nyní, s rozvojem digitálních pobočkových ústředen tzv. PBX (private branch exchange) - se tato možnost stává výrazně dostupnější a firmy ji často preferují oproti pořádání klasických jednání. Ta jsou náročná jak na čas a dopravu jednotlivých pracovníků, tak na organizaci vhodné konferenční místnosti. Problémem, který při organizování audiokonferencí řeší většina manažerů, je náročný postup zahájení konference. Obvykle je třeba nejprve rozeslat plánovaným účastníkům pozvánku ke konferenci. Součástí pozvánky, která je často ručně psaná, mohou být kromě data, času a tématu konference také přílohy (prezentace či dokumenty, jejichž obsah se bude projednávat). Po potvrzení nebo zamítnutí účasti jedotlivými účastníky může či nemusí vedoucí rozeslat finální seznam účastníků, podle kterého se obvykle odvíjí agenda. Před termínem zahájení konference svolavatel kontaktuje technic1
Úvod kého pracovníka zodpovědného za správu audiokonferencí a ten na jeho žádost vytvoří virtuální konferenční místnost a přidělí potřebné přihlašovací údaje. Ty je opět třeba zaslat jednotlivým účastníkům. Tato práce vznikla s cílem vytvořit aplikaci umožňující zakládání a správu audiokonferencí samotnými manažery, usnadňující komunikaci a sdílení informací a dokumentů v rámci středních a větších firem. Z důvodu, že jejími hlavními uživateli jsou pracovníci vedení a manažeři, musí být aplikace dostatečně intuitivní a snadno a rychle použitelná tak, aby nevyžadovala předchozí zaškolení. Velký důraz je kladen také na možnost integrace do stávající telefonní infrastruktury firmy.
2
Kapitola
Cíle práce Cílem projektu je vytvořit kompletní řešení zajišťující audiokonferenční funkcionalitu pro použití v prostředí středních a velkých firem. Základem tohoto řešení je zvolená telefonní ústředna poskytující samotnou audiokonferenční službu (tj. spojování hovorů a mixování zvukových proudů) a webová aplikace umožňující komplexní správu konferenčních místností, uživatelů, kontaktů a pozvánek ke konferencím, nahrávek hovorů a dalších souvisejících údajů. Předem bylo specifikováno, že stávající interní telefonní systém zákazníka je provozován na digitální telefonní ústředně Cisco Unified Communications Manager (CUCM) a dalších přidružených produktech opět od firmy Cisco (kontaktní centrum, automatický recepční – IVR a další). Zejména vzhledem k ceně licencí za konferenční funkcionalitu nabízenou přímo firmou Cisco prostřednictvím jejích produktů byl zadavatel osloven s žádostí o vytvoření konkurenční nabídky s využitím jiných technologií. Platformou, kterou jsme po konzultaci se zadavatelem zvolili jako výchozí pro tento projekt, se stala digitální ústředna Asterisk. Ta je zdarma dostupnou open-source ústřednou, bez těsných vazeb na hardware, na kterém je provozována. Poskytuje navíc prostřednictvím jednoho ze svých modulů také funkcionalitu audiokonferencí, přičemž role systému spočívá v samotném spojení hovorů, ověřování oprávnění účastníka k připojení, mixování zvukových stop a nahrávání záznamu konference. Předmětem této práce je pak vytvoření nadstavbové webové aplikace umožňující: správu konferenčních místností a účastníků, plánování konferencí s rozesíláním pozvánek a sdílením materiálů a také vytvoření přehledné obrazovky pro sledování průběhu konference a pokročilou spolupráci účastníků. 3
1
1. Cíle práce
Zatímco samotná telefonní ústředna Asterisk byla zvolena jako hotové řešení, které bude dále integrováno bez plánovaného zásahu do jejího interního fungování, webová aplikace sloužící pro správu je komponentou vyvíjenou zcela od základu. Hlavní úkoly, které ve své práci budu řešit, se dají shrnout do následujících bodů: • Rešerše existujících řešení, průzkum jejich kladů a záporů, možnosti využití • Implementace webového rozhraní sloužícího pro správu konferencí • Integrace řešení se stávajícími podnikovými ústřednami • Nastavení licenční a tarifikační politiky, příprava pro provoz ve formě cloudové služby
1.1 1.1.1
Metodika testování Předprodukční testování
Aby byla ověřena schopnost aplikace plnit svou funkci s dostatečnou uživatelskou přívětivostí, nabídkou funkcí a spolehlivostí, bude aplikace nejprve nasazena do testovacího provozu v mé společnosti, přičemž zde bude také podrobena jednoduchým zátěžovým testům. První test bude spočívat v definování úkolů, které by měl testující uživatel provést. Pro každý z úkolů se bude definovat míra splnění (0 - 100 %) a také čas potřebný k jeho splnění. Celý test se bude opakovat 2x, aby byla ověřena schopnost používat aplikaci efektivněji při opakovaném použití. U každého uživatele bude zaznamenána jeho vlastní subjektivní kategorizace dle zkušenosti s používáním webových aplikací tohoto druhu. Dalším sledovaným parametrem je odezva webové aplikace v závislosti na počtu paralelně připojených uživatelů. Jelikož zobrazení detailu konference bude obsahovat také seznam aktuálně připojených účastníků, který musí být v zájmu uživatelského komfortu pravidelně aktualizován s pokud možno co nejnižším intervalem, lze očekávat, že tato aktualizace výpisu bude tvořit hlavní zátěž aplikace. Parametr průměrné odezvy bude sledován u všech připojených klientů a bude zaznamenáván jeho vývoj v závislosti na počtu paralelně připojených uživatelů. 4
1.1. Metodika testování
1.1.2
Produkční testování
Následně bude aplikace nainstalována do síťového prostředí zákazníka, kde bude po předvedení po omezenou dobu zdarma testována v reálném provozu. Po tuto dobu budou zaznamenávány a se zákazníkem diskutovány kromě chyb také praktické poznámky vedoucí ke změnám zejména v uživatelském rozhraní aplikace.
5
Kapitola
Analýza a návrh řešení 2.1
Popis digitální telefonní ústředny Asterisk
Digitální pobočková audioústředna Asterisk je Open-Source projektem, za jehož počátek se považuje rok 1999, kdy vývojář Mark Spencer uvolnil původní zdrojový kód pod licencí GPL[16]. Asterisk se za tuto dobu stal komunitním projektem s více než 86 000 členy a více než 2 000 000 staženími ročně [17]. Asterisk nyní rovněž není považován pouze za telefonní ústřednu, ale také za kompletní platformu sloužící pro vývoj vlastních specializovaných aplikací využívajících jádro systému pro zpracování přenosů zvuku a videa v reálném čase. Důvodů pro volbu této ústředny bylo v počátku projektu několik. Kromě absence pořizovacích nákladů na samotný softwarový produkt, možnosti instalace na téměř jakýkoli hardware a živé komunity vývojářů i uživatelů byly stěžejními důvody také otevřené možnosti integrace za pomoci dostupných komunikačních rozhraní, existence plně postačující fukcionality mixování audiokonferenčních hovorů a velkého počtu dalších modulů, které do budoucna mohou umožnit rozšíření projektu o další komplexní funkcionalitu.
2.1.1
Historický vývoj platformy
Pro účely této práce jsem zvolil verzi Asterisk 1.8 LTS, jelikož v době počátku vývoje byla tato verze nejaktuálnější dostupnou stabilní verzí. Navíc tato verze má prodlouženou podporu (Long-Term-Support) po dobu min. 3 let od vydání. 7
2
2. Analýza a návrh řešení
2.1.2
Architektura platformy Asterisk
Platforma Asterisk je skládá z mnoha logicky oddělených částí, jejichž důkladný rozbor není pro tuto práci zcela stěžejní. Pro získání obecného přehledu je však vhodné jmenovat alespoň základní strukturu. Přehled propojení základních komponent znázorňuje obrázek 2.1.
Obrázek 2.1: Architektura ústředny Asterisk
2.1.2.1
Jádro – PBX Core
Jádro je srdcem celé platformy a je nezbytnou komponentou zajišťující spojování hovorů [18]. Jeho zodpovědností je rovněž načítání konfiguračních souborů a nahrávání rozšiřujících modulů systému. Jádro také obsahuje zpracování tzv. dialplanu, komplexní logiky zajišťující spojování hovorů na základě sekvenční struktury rozhodovacích pravidel (tato pravidla berou v potaz zejména identifikátory volajícího a volaného, ale mohou obsahovat i složitější definice směrující hovor na např. základě denní doby, existence záznamů o historii hovorů apod.). 2.1.2.2
Moduly
Naprostá většina dalších funkcí je v platformě Asterisk dělena do modulů. Modulem v tomto kontextu mohou být mimo jiné tyto prvky: • Aplikace - definují různé akce, které mohou být použity v rámci dialplanu pro zpracování hovoru (stovky dostupných modulů zahrnují audiokonferenční aplikace app_meetme a app_confbridge, osobní pře8
2.1. Popis digitální telefonní ústředny Asterisk směrování app_followme, přehrávání zvuků app_playback či vytáčení nových hovorů app_originate) • Moduly CDR - zajišťují ukládání informací o probíhajících hovorech – tzv. Call Details Records - do souborů, databáze či systémových protokolů • Channel Drivers - ovladače pro spojování hovorů specifické pro komunikační kanály (SIP, ISDN, H323) • Kodeky - kodeky pro konvertování audio a videoformátů (G.711, G.729, A-law a další) • Funkce dialplanu - funkce poskytují rozšíření dialplanu o další užitečné schopnosti: komunikace s databází, webovými službami prostřednictvím CURL, kryptografické výpočty apod. • Moduly PBX - poskytují rozšířené kontrolní a konfigurační funkce, mimo jiné možnost externalizace konfigurace do relační databáze • Moduly zdrojů - umožňují integraci Asterisku s externími zdroji (databázemi ODBC, MySQL, službami pro rozpoznávání hlasu apod.) • Rozšiřující moduly - další rozšiřující moduly jako podpora přehrávání formátu MP3
2.1.3
Funkce poskytované platformou
Platforma Asterisk poskytuje zdarma velmi širokou škálu dostupných služeb sloužících nejen pro základní spojování hovorů, ale také pro tvorbu komplexních rozhodovacích stromů (IVR, časové skupiny a pravidla). Na rozdíl od konkurenčních řešení firem Cisco či Avaya, u kterých nadstavbové funkce jako je právě IVR vyžadují dokoupení odpovídajícího hardware či licencí, ústředna Asterisk tuto funkcionalitu nabízí formou modulu, který lze do ústředny snadno doinstalovat (přičemž většina běžně požadovaných funkcí je dostupná i při výchozí instalaci). Dále jsou dostupné moduly umožňující tvorbu call-center (fronty hovorů, vyzváněcí skupiny, nahrávání hovorů, zpětné volání) a také již zmiňovaná funkcionalita audiokonferencí. 2.1.3.1
Aplikace MeetMe - app_meetme
Aplikace MeetMe je podporovanou součástí platformy Asterisk od verze 1.0.9. Tato aplikace umožňuje vytváření konferenčních místností, do kterých se následně mohou připojovat účastníci. Každá konferenční místnost 9
2. Analýza a návrh řešení je identifikována svým číslem a má mnoho konfiguračních nastavení. Režim konference může určit, zda se každý z účastníků může konference aktivně účastnit či zda je část účastníků pouze posluchači. Každé konferenční místnosti lze definovat způsob čekání na účastníky a ohlašování jejich vstupů / odchodů z konference, role účastníků, dále nastavovat její nahrávání nebo např. volit hudbu hrající před začátkem konference. Každému účastníkovi konference lze při připojování nastavit další parametry – zejména pak uživatelskou roli. V případě, že je konferenční místnost chráněna PIN kódem, účastník musí tento kód zadat před svým připojením. Aplikace MeetMe dále umožňuje od verze Asterisk 1.8 časové plánování konferencí tj. určení časů, kdy se konferenční místnost otevře, kdy konference započne a kdy bude místnost opět uzavřena. Tyto časy nejsou zcela striktní a na globální úrovni lze definovat povolené přesahy - více o tomto v kapitole 3.2.3. 2.1.3.2
Aplikace ConfBridge – app_confbridge
Aplikace ConfBridge byla vytvořena jako alternativa k aplikaci MeetMe a poprvé byla k dispozici ve verzi Asterisk 1.6.2. Funkcionalita tohoto modulu je velmi podobná a přes svou podobnost a to, že je vývojově mladší, údajně nebyl vytvářen s ambicemi nahrazení modulu MeetMe. Hlavním rozdílem je způsob mixování audio proudů (MeetMe využívá DAHDI, zatímco ConfBridge provádí mixování interně v Asterisku). Dále nemá ConfBridge funkcionalitu autorizace PIN kódem a ta musí být prováděna jiným modulem a v dialplanu předcházet samotnému připojení do ConfBridge1 .
2.2
Požadavky na aplikaci
Aplikace je tvořena jako nástroj sloužící pro střední a velké společnosti zejména pro podporu spolupráce zaměstnanců a externích spolupracovníků prostřednictvím komunikačního uzlu poskytujícího přehledné a intuitivní, avšak prakticky dobře využitelné rozhraní. Toto rozhraní musí poskytovat nejenom funkce komunikační v reálném čase, ale také možnost plánování konferencí a zpětného procházení souvisejícího obsahu (prohlížení projednávaných dokumentů, stahování a poslech záznamů konferencí). 1
Ve verzi Asterisk 10 byl konferenční modul ConfBridge kompletně přepracován. Jelikož však na počátku vývoje nebyla tato verze k dispozici, nebyla přidaná funkcionalita při rozhodování brána v potaz.
10
2.2. Požadavky na aplikaci Při tvorbě řešení jsem byl do určité míry limitován požadavky, které byly na funkcionalitu aplikace kladeny zákazníkem, který o aplikaci tohoto druhu projevil zájem krátce po zahájení analytických prací. Se zákazníkem byly rovněž konzultovány jednotlivé vývojové fáze a v jeho síťovém je nyní nasazena jedna z vývojových verzí aplikace. Po sestavení neformálního zadání byly stanoveny požadavky, popsané v následujících kapitolách.
2.2.1
Funkční požadavky
2.2.1.1
Požadavky uživatele
Uživatel se základním oprávněním pro přístup k systému má k dispozici následující funkce: • Může procházet seznam konferencí, ve kterém se zobrazují pouze konference, které jsou označeny jako veřejné či ty, ke kterým dostal pozvánku resp. je uveden mezi účastníky, bez ohledu na to, jaký je stav jeho účasti • Může zobrazit detail konference, přičemž jsou mu zobrazeny podrobné údaje o konferenci, zejména pak datum a čas jejího začátku a doba trvání, dále pak hlavní téma a popis obsahu konference, přístupové údaje (číslo konference a PIN kód sloužící k přihlášení) a seznam účastníků konference spolu s jejich oznámenými stavy účasti (učastní se / neví / neúčastní se / bez reakce) • Má k dispozici zobrazení QR kódu obsahující telefonní číslo určené pro připojení ke konferenci • U plánovaných konferencí může měnit stav své očekávané účasti • Je mu umožněno stáhnout a zobrazit přílohy konference – tj. soubory vložené ke konferenci (např. projednávané dokumenty, prezentace) • Může v průběhu konference sledovat automaticky aktualizovaný seznam připojených účastníků, jakožto i dobu jejich připojení. Pro usnadnění orientace jsou mezi těmito účastníky automaticky zvýrazněni ti, kteří momentálně hovoří. • V průběhu konference mu může být zobrazena tzv. kolaborační plocha s dalšími sdílenými materiály, prezentacemi či webovými stránkami. 11
2. Analýza a návrh řešení 2.2.1.2
Požadavky vedoucího uživatele
Vedoucí uživatel je uživatelem přímo nadřazeným běžnému uživateli, má tak všechna jeho oprávnění. Navíc je mu však umožněno zakládání nových konferencí a jejich pokročilá administrace. To zahrnuje zejména následující aktivity: • Přizvání účastníků, rozesílání pozvánek • Vkládání a správa příloh konference • Moderování konference – Možnost odpojit účastníka od konference – Možnost ztlumit účastníka konference – Možnost uzamknout resp. odemknout konferenční místnost – Možnost aktivně vytočit účastníka, který není momentálně připojen • Možnost konferenci odvolat a odeslat automatickou notifikaci • Možnost spravovat kolaborační plochu – Možnost sdílet dokumenty či webové odkazy – Možnost promítat prezentaci pomocí nástroje PowerPoint 2010 2.2.1.3
Požadavky správce systému
Správce konferenčního systému je opět uživatelem nadřazeným předchozím dvěma rolím. Oproti těm má ale další dostupné funkce: • Může spravovat veškeré konference, nejen ty, které sám vytvořil • Spravuje role uživatelů v rámci systému • Nastavuje globální proměnné systému (parametry bezpečnostní, provozní i týkající se pouze uživatelského komfortu při používání aplikace), za tímto účelem má dostupný intuitivní konfigurační panel • Nastavuje potřebné parametry týkající se integrace s telefonní infrastrukturou 12
2.3. Rešerše existujících řešení 2.2.1.4
Požadavky majitele systému
Aplikace dále obsahuje roli vývojáře, který je v tomto kontextu využíván zároveň jako majitel systému. Kromě ryze vývojářských funkcí je mu, oproti správi systému, navíc umožněna změna tarifikačních pravidel a licenčních omezení systému.
2.2.2
Nefunkční požadavky
• Aplikace musí, v zájmu uživatelské přívětivosti, umožňovat živou aktualizaci údajů o probíhající konferenci bez nutnosti obnovování webové stránky uživatelem. Za tímto účelem je třeba provádět automatickou obnovu obsahu stránek s maximálním intervalem 5 sekund, optimálním pak 1 sekunda. V tomto režimu musí aplikace pojmout 50 paralelně připojených a hovořících uživatelů (celkem tedy minimálně 10 požadavků za vteřinu, optimálně 50 požadavků za vteřinu). • Aplikaci musí být možné provozovat ve virtualizovaném prostředí VM Ware – vSphere v privátní síti zákazníka. • Aplikaci musí být možné integrovat se stávající telefonní infrastrukturou provozovanou na ústředně Cisco Unified Communications Manager.
2.3
Rešerše existujících řešení
Při hledání existujících řešení jsem se soustředil na bezplatné Open-Source aplikace s odpovídající licencí, jejichž úprava a rozšíření by umožnily splnit stanovené požadavky. Z placených variant jsem, zejména pro vlastní inspiraci, zkoušel integrované rozhraní pro správu ústředny Asterisk a konferenčního modulu od firmy VoIP Business Solutions. Nejlepší alternativou k vytvářené aplikaci se pak zdá být řešení Switchvox pocházející přímo od firmy Digium. Jedná se však v obou případech o neupravitelná placená řešení. Při hodnocení jednotlivých porovnávaných aplikací jsem vycházel ze splnění těchto požadavků: 1. Možnost vytvářet a spravovat konferenční místnosti 2. Možnost v reálném čase sledovat průběh konference, spravovat připojené účastníky 13
2. Analýza a návrh řešení 3. Možnost odesílat pozvánky a spravovat očekávaný stav účasti (RSVP) 4. Možnost sdílet dokumenty a další materiály, promítat účastníkům prezentace
2.3.1
FreePBX
FreePBX je jedním z nejčastěji používaných administračních nástrojů pro platformu Asterisk. Jde o komplexní webové rozhraní programované v jazyce PHP, které svou modulární architekturou nabízí sjednocenou správu širokého portfolia funkcí, které Asterisk nabízí. Konkrétně modul pro správu konferencí však i v nejnovější verzi, dostupné v době psaní tohoto textu, nabízí pouze základní funkce založení či zrušení konferenční místnosti [20]. Konferenční místnost má mnoho volitelných parametrů, avšak nelze definovat datum a čas jejího otevření ani uzavření a rovněž nelze v uživatelském rozhraní žádným způsobem sledovat ani ovlivňovat průběh konference, poslouchat její záznam či zasílat pozvánky a upozornění. Výhody • Centralizovaná správa spolu s dalšími funkcemi telefonní ústředny • Dostupný v rámci instalačních “Live CD” (AsteriskNOW) • Poskytuje možnost nastavit většinu parametrů konference Nevýhody • Nemožnost oddělení přístupu dle uživatelských rolí • Nemožnost plánovat konference na konkrétní čas • Nemožnost spravovat průběh konference v reálném čase
2.3.2
Web-MeetMe
Web-MeetMe je oproti FreePBX již specificky vymezená webová aplikace sloužící pouze pro vytváření a správu konferencí. Je vytvořena v programovacím jazyku PHP a poskytuje snadno použitelné rozhraní pro vytváření konferencí, nastavení jejich parametrů a jednoduchou správu připojených účastníků. První veřejně dostupná verze 2.0.0 byla zveřejněna v roce 2006 a jejími autory jsou Arezqui Belaid, Dan Austin a Michael Clark [21].
14
2.3. Rešerše existujících řešení Aplikace, která byla vytvořena již pro Asterisk verze nižší než 1.8, jejíž integovaný konferenční modul neumožňoval ohraničení času konference, tuto funkci emulovala pomocí přepisování sdílené konfigurace v čase, kdy konference začala resp. skončila. V jednoduchém rozhraní lze spravovat registrované uživatele a těmto uživatelům lze následně udělovat oprávnění k zakládání a správě konferencí. Registrované uživatele lze přizvat k již existujícím konferencím a lze jim snadno odeslat notifikační e-mailovou zprávu obsahující nezbytné informace o začátku a době trvání konference a jejím názvu. Během konference aplikace zobrazuje seznam připojených uživatelů a umožňujě u nich individuálně provádět akce ztlumení, zesílení příp. odpojení. Instalace aplikace je poměrně snadná. Je vyžadováno několik ne zcela standartních nastavení PHP serveru (short_open_tags) a dále rozšíření PERL::DB, avšak následné zprovoznění je otázkou maximálně desítek minut. Zatímco hlavním kladem tohoto řešení jsou bezesporu snadná instalace a jednoduché, intuitivní ovládání, nevýhodou je jednoznačně absence jakýchkoli kolaboračních funkcí (diskuze, sdílení souborů apod.).
2.3.3
App-Konference
App-Konference je webovou aplikací vytvořenou v jazyce PHP, která navazuje svou funkcionalitou na projekt Web-Meetme. Ačkoli neumožňuje vytvá-
Obrázek 2.2: Ukázka rozhraní aplikace Web-MeetMe - správa konferencí 15
2. Analýza a návrh řešení ření, úpravu či správu parametrů konferencí, ani odesílání pozvánek, má naopak propracovanější a graficky přívětivější zobrazení průběhu konference. Při výběru konkrétní probíhající konference ze seznamu je zobrazen její detail se všemi připojenými účastníky. Opět jsou k dispozici volby ztlumení či odpojení účastníka. Dále je možnost měnit hlasitost vstupu jednotlivých účastníků. Zcela zásadní výhodou je však detekce mluvčího, kdy je na základě hlasitosti vstupu konkrétního účastníka tento označen jako mluvící. Tato funkce pak výrazně zpřehledňuje průběh celé konference a orientaci v ní, zejména pokud je vyšší počet členů.
Obrázek 2.3: Ukázka rozhraní aplikace AppKonference - detail průběhu konference
2.3.4
BigBlueButton
BigBlueButton je dalším z Open-Source nástrojů, který využívá ústředny Asterisk pro konferenční funkcionalitu. Jeho hlavním cílem je umožnění výuky a spolupráce student-učitel. Webová aplikace se skládá ze serverové části psané v jazycích Java a Ruby a z klientské části vytvořené v jazyce Adobe Flex/Flash. Ačkoli tato aplikace skvělým způsobem umožňuje správu konference v reálném čase, přičemž poskytuje i pokročilé funkce jako sdílení prezentací, kreslení a také sdílení videa, naopak zaostává v plánování konferencí. Modul, který tuto funkcionalitu zajišťuje již delší dobu není aktualizován a kromě absence jakéhokoli vizuálního stylu nemá možnost přímé lokalizace. Ukázka tohoto rozhraní je na obrázku 2.4. Oproti naprosto základní funkcionalitě plánování je část správy průběhu konference zpracována velice precizně. Obrazovka je rozdělena na tři sloupce (její rozvržení však lze upravovat), přičemž obsahuje několik bloků sloužících k přehledu připojených uživatelů, další pro posílání zpráv a nej16
2.3. Rešerše existujících řešení
Obrázek 2.4: Ukázka rozhraní aplikace BigBlueButton - plánování konference
větší část obrazovky slouží pro promítání prezentace a spolupráce uživatelů. Vždy je pouze jeden z účastníků určen jako prezentující a ostatní pasivně sledují promítaný obsah. Na rozdíl od ostatních porovnávaných aplikací je tuto možné použít i pro vytváření konferencí bez hlasových přenosů. Rozhraní obrazovky spolupráce znázorňuje obrázek 2.5.
Obrázek 2.5: Ukázka rozhraní aplikace BigBlueButton - detail průběhu konference
17
2. Analýza a návrh řešení
2.3.5
Porovnání
Ačkoli každá z výše uvedených aplikací si jistě najde své uživatele a reálné nasazení, žádná neposkytuje veškerou funkcionalitu vyžadovanou od tohoto projektu. Porovnání jednotlivých aplikací dle hlavních rozhodovacích bodů znázorňuje tabulka 2.1. Nejblíže se nabízenou funkcionalitou dostal poslední popisovaný, projekt BigBlueButton. Jednoznačnou výhodou bylo kvalitní zpracování služeb správy konference v reálném čase. Naopak velmi nedostačující bylo řešení plánování konferencí. Přestože by pravděpodobně bylo možné správu plánovaných konferencí zcela přepracovat a použít pouze část původní aplikace, na základě dohody se zadavatelem bylo jako preferované řešení zvoleno kompletní nové zpracování. Důvodem pak byla především snaha o zachování jednotného vzhledu všech částí aplikace a také zájem na tom, nebýt vázán licencí LGPL (pod kterou je licencován BigBlueButton).
lu eB B
ig B
A
částečně ne ne ne PHP částečně
ano ne ne ne PHP ne
ne ano ne ne PHP ne
částečně ano ne ano Java částečně
pp
W eb
-K on
ut t
fe re n
tM e -M ee
X B eP
2.4
Fr e
1. Správa místností 2. Real-time přehled 3. Správa pozvánek, RSVP 4. Sdílení materiálů - Programovací jazyk - Možnost lokalizace
on
ce
Tabulka 2.1: Porovnání funkcí existujících řešení
Případy užití
Uživatelé aplikace se dle svých rolí rozdělují do dvou skupin, běžné uživatele a manažery. Zatímco manažeři se mohou konferencí jak účastnit, tak je pořádat, běžní uživatelé se mohou pouze účastnit již vytvořených konferencí.
2.4.1
Manažer
Zjednodušený model případů užití manažera znázorňuje obrázek 2.6. Manažer dle tohoto diagramu může konferenci vytvořit a pozvat jednotlivé účastníky. Dále může plně spravovat přílohy v rámci své konference. Je mu dále přidělen správcovský PIN kód, pomocí kterého se autorizuje při připojování ke konferenci. Po této autorizaci může nejen pomocí webového rozhraní, ale 18
2.4. Případy užití také pomocí klávesnice telefonu spravovat konferenci, odpojovat či ztišovat účastníky a provádět další úpravy. Stejné operace může provádět zároveň i pomocí webového rozhraní. V případě potřeby může také konferenci zrušit. Manažerský uživatel dále přejímá všechny povolené akce běžného uživatele, popsané v následující kapitole.
Obrázek 2.6: Model případů užití aplikace - manažer
2.4.2
Běžný uživatel
Případy užití běžného uživatele jsou oproti manažerovi omezeny pouze na konference, v nichž je uveden jako účastník. U těchto konferencí je uživateli také zobrazen PIN kód, který může použít pro připojení ke audiokonferenci. Každý účastník může dále nastavit svůj status účasti v konferenci, 19
2. Analýza a návrh řešení stahovat přílohy a také ztlumit sám sebe. Pro usnadnění připojení z mobilního telefonu může uživatel ke každé ze svých konferencí zobrazit QR kód obsahující její vnější telefonní číslo. Zjednodušený model případů užití znázorňuje obrázek 2.7.
Obrázek 2.7: Model případů užití aplikace - běžný uživatel
2.4.3
Ostatní uživatelské role a oprávnění
Pro usnadnění správy aplikace existuje ještě třetí uživatelská role - vývojář. Ten má dle svých oprávnění přístup ke konfiguraci aplikace a může upravovat takové parametry, jako jsou přístupové údaje k rozhraním telefonní ústředny, požadované bezpečnostní parametry jako délka PIN kódu či přihlašovací údaje k platební bráně. Oprávnění role vývojáře nejsou žádným způsobem omezena. Po jednání s prvním zákazníkem vzešel na aplikaci ještě dodatečný požadavek na umožnění pověření náhradního správce konference v případě, že 20
2.5. Návrh analytických tříd se například její původní organizátor (manažer) nemůže dostavit či se musí před skončením konference odpojit. Každý z účastníků konference tak má navíc přidělenou roli i v rámci dané konference. Běžnému uživateli tak může být umožněna správa konkrétní konference (a tím pádem také odpojování účastníků, jejich ztlumování či zamykání konference) bez toho, aby mu bylo umožněno vytvářet konference nové.
2.5
Návrh analytických tříd
Na základě analýzy požadavků na funkcionalitu byl vytvořen návrh modelu tříd, který je spolu s jejich atributy zobrazen na obrázcích 2.8 a 2.9.
Obrázek 2.8: Model tříd aplikace - balíček core (cz.improvisio.visioCore) První obrázek zobrazuje návrh balíčku „core“, obsahujícího základní jádro budoucí aplikace. Tím jsou hlavně třídy „uživatel“ a „uživatelská role“. Dále byla pro účely konfigurace navržena dvojice tříd „nastavení“ a „kategorie nastavení“. Tyto třídy v důsledku umožňují snadné vytvoření uživatelsky spravovatelné konfigurační sekce, ve které jsou změny jednotlivých konfiguračních hodnot umožněny pouze zástupcům konkrétních uživatelských rolí. Jelikož se v cílové aplikaci počítá s několika výpisy dat, ve kterých by mělo být umožněno filtrování dat, bude vhodné uživatelům 21
2. Analýza a návrh řešení
Obrázek 2.9: Model (cz.improvisio.conference)
tříd
aplikace
-
balíček
conference
umožnit uložení jimi často používaných filtrů. K tomuto slouží dvojice tříd „filtr“ a „hodnota filtru“. Druhý obrázek 2.9 pak zobrazuje návrh balíčku „conference“. Ten obsahuje samozřejmě zejména samotnou třídu „konference“. Dále obsahuje třídu „účastník konference“ obsahující referenci na uživatele, roli uživatele v rámci dané konference a také stav účasti uživatele. Toto druhotné přidělení role uživateli by mělo v budoucnu sloužit k tomu, aby bylo možné pověřit běžného uživatele vedením konference (např. z důvodu absence vedoucího či nutnosti jeho brzkého odpojení). Třída „příloha“ umožňuje pojmenování přílohy a také obsahuje vztah se třídou „role“, sloužící k určení potřebného oprávnění k zobrazení souboru. Důležitou částí je pak skupina tříd určených pro spolupráci v reálném čase. Návrh počítá s možností vytvoření sdílené pracovní plochy (tato pracovní plocha existuje pouze v rámci webové aplikace a nemá žádnou spojitost s plochou operačního systému). Pracovní plocha má volitelné rozložení, určijící počet a rozměry pozic pro sdílený obsah. Každá z pozic pak může obsahovat náhled nahrané přílohy ke konferenci, webovou stránku zobrazenou formou vnořeného rámce (tzv. iframe) nebo živě sdílenou prezentaci nástroje PowerPoint 2010 či jeho novějších verzí. Více o návrhu této části aplikace je uvedeno v následující kapitole. 22
2.6. Návrh uživatelského rozhraní
2.6
Návrh uživatelského rozhraní
Při návrhu uživatelského rozhraní bylo postupováno metodami, jež byly mimo jiné diskutovány v rámci předmětu MI-NUR (návrh uživatelského rozhraní) a během jehož cvičení byl rovněž prezentován prvotní koncept rozhraní aplikace. Pro účely tohoto předmětu byly detailně analyzovány pouze scénáře základního vytvoření a správy konference. Další nadstavbová funkcionalita, včetně správy dobíjení a čerpání kreditu nebyla v tomto návrhu obsažena. Návrh probíhal v následujících krocích: 1. Analýza požadavků na funkcionalitu 2. Sestavení scénářů obvyklého použití aplikace 3. Rozdělení činností do skupin dle oblasti použití (příprava konference, realtime správa konference, správa kontaktů) 4. Sestavení grafu navigace v aplikaci 5. Vytvoření lo-fi prototypu (wireframe modelů aplikace) 6. Vytvoření hi-fi prototypu (klikatelného webového rozhraní a formulářů) Kompletní dokumentace provedené analýzy, včetně komentářů cvičícího Ing. Jiřího Hunky je přílohou této práce a je umístěna na CD.
2.6.1
Navigace v aplikaci
Při vytváření navigačního grafu bylo nutné se orientovat zejména nejčastěji užívanými uživatelskými scénáři. Těmi jsou vytvoření nové konference, vyhledání plánované konference, vyhledání proběhlé konference a zobrazení konference právě probíhající. Aby právě tyto akce byly snadno a rychle dostupné, byly zpřístupněny skrze navigaci na hlavní stránce aplikace. Obrázek 2.10 zobrazuje navržené schéma.
2.6.2
Vytváření a úprava konference
Jelikož vytváření a úprava konference jsou aktivitou, která je v rámci aplikace nejkomplexnější a přesto musí být využívána uživateli bez dlouhého zaškolení, bylo nutné tento proces co nejvíce zjednodušit a eliminovat tak možné chyby.
23
2. Analýza a návrh řešení
Obrázek 2.10: Graf navigace v aplikaci
Formulář sloužící k zadání údajů konference byl navržen jako vícestránkový (také nazývaný jako typ wizard) a každý z prvků formuláře byl opatřen krátkým popisem a ikonou otazníku poskytující podrobné informace o konkrétním nastavení. Toto umožňuje snadné seznámení se s formulářem, ve kterém je uživatel detailně veden ke správnému vyplnění hodnot. Zároveň však neobtěžuje nadbytkem textu při opakovaném vyplňování formuláře. Jednotlivé zóny formuláře, sloužící k vyplnění, mohou být ve výchozím zobrazení minimalizované. To se týká zejména zřídka využívaných či pokročilých nastavení. Tento model tak poskytuje výhodu jak začínajícím uživatelům, pro které je vyplnění rychlé a intuitivní, tak uživatelům pokročilým, kteří mohou získat informace o dalších možnostech konference (např. nastavení režimů poslechu, nahrávání koneference či režim čekání na správce). Navržený formulář znázorňuje obrázek 2.11. 24
2.6. Návrh uživatelského rozhraní
2.6.3
Zobrazení detailu a průběhu konference
Zobrazení detailu konference je obrazovkou, obsahující nejvíce informací a ovládacích prvků. Je proto nutné tuto obrazovku vytvořit nejen přehlednou, ale také ergonomicky navrženou tak, aby uživatelé nebyli nuceni nadbytečně posouvat oknem prohlížeče. Vzhledem k objemu informací je úplné zamezení posouvání bohužel nemožné. Proto je stránka rozdělena do tří sekcí, které lze individuálně minimalizovat a zobrazovat tak vždy pouze ty údaje, které jsou v danou chvíli relevantní. Vše znázorňuje obrázek 2.12. První sekce obsahuje obecné informace o konferenci. Těmi jsou popis, číslo místnosti, datum konání či přístupový kód, který je nutné po vytočení čísla konference zadat na klávesnici telefonu. Rovněž jsou zde k dispozici nahrané přílohy a odkaz na zobrazení QR kódu, sloužícího k načtení telefonního čísla konference do chytrých telefonů. Druhá sekce obsahuje seznam pozvaných účastníků konference, spolu s jejich plánovaným stavem účasti na konferenci. Každému z účastníků zde lze nastavit individuální oprávnění v rámci konference a také provést jeho vytočení v případě, že není momentálně připojen ke konferenci. Poslední sekce je realtimové zobrazení účastníků konference. To uka-
Obrázek 2.11: Vícestránkový formulář, nastavení zabezpečení konference 25
2. Analýza a návrh řešení zuje seznam připojených účastníků, jejich dobu připojení a kromě možnosti jednotlivé účastníky ztlumit či odpojit zobrazuje také zvýraznění aktuálně hovořícího klienta (realizováno podbarvením).
Obrázek 2.12: Detaily konference a její průběh
2.7
Plánované způsoby nasazení
Nasazení vytvářené aplikace by mělo být možné co nejvíce upravovat dle konkrétních požadavků zákazníka. Přímo či s minimálními úpravami by však mělo by být možné v následujících modelových situacích: • Zákazník nevlastní žádnou telefonní infrastrukturu a přeje si použít server Asterisk, který je součástí řešení, jako základ budoucí telefonní sítě • Zákazník vlastní existující telefonní infrastrukturu a přeje si nasadit řešení ve vlastním prostředí a integrovat jej se stávající telefonní sítí První ze schémat nasazení, které znázorňuje obrázek 2.13, počítá s existencí jednoho serverového stroje, na kterém je provozován telefonní systém Asterisk, aplikační server Apache Tomcat a sdílená databáze. Kromě 26
2.7. Plánované způsoby nasazení vazeb prvních dvou komponent na databázi existuje také připojení mezi konferenční aplikací a platformou Asterisk, využívající protokolu telnet pro komunikaci s rozhraním AMI (Asterisk manager interface – více je toto rozhraní popsáno v kapitole 3.3). Toto schéma počítá s existencí databáze uživatelů v rámci MySQL databáze, eventuelně s existencí LDAP autentizačního zdroje umístěného uvnitř či vně sítě zákazníka. V síti zákazníka se dále mohou nacházet digitální telefony komunikující s ústřednou pomocí protokolu SIP, přičemž se jedná buďto o samostatná zařízení (stolní telefony) či softwarové klienty (aplikace běžící na PC hostitele). Ústředna Asterisk dále může, ale nemusí být připojena do veřejné telefonní sítě (PTSN).
Obrázek 2.13: Plánované nasazení pro účely testování
Následující diagram - obrázek 2.14 – zobrazuje pokročilé schéma nasazení v existující síťové infrastruktuře zákazníka, obsahující telefonní ústřednu Asterisk PBX či Cisco Unified Communications Manager (CUCM). K této ústředně jsou připojeny VoIP telefony jednotlivých klientů a tato je rovněž připojena do veřejné telefonní sítě. Hlavní odlišnost tohoto nasazení spočívá v existenci komunikačního tunelu mezi oběma digitálními ústřednami a směrování hovorů mezi nimi na bázi pravidel definovaných číselnými prefixy vytáčených čísel.
27
2. Analýza a návrh řešení
Obrázek 2.14: Diagram nasazení v infrastruktuře zákazníka
Toto nasazení již také předpokládá existenci LDAP autentizačního zdroje v síti zákazníka či existenci Windows domény s databází uživatelů Active Directory a vlastního SMTP serveru pro odesílání informačních e-mailů.
28
Kapitola
Realizace V této kapitole popisuji návrh aplikace, vycházející z rešerše existujících řešení a požadavků kladených na aplikaci. Vzhledem ke komplexnosti některých požadavků jsem se rozhodl se do velké míry opírat o existující technologie a vytvořit jakýsi můstek integrující jejich vlastnosti. Volba telefonní ústředny Asterisk jakožto hotové části systému, do které je dále nutné zasahovat pouze formou konfigurace, umožnila se více soustředit na seznámení se s frameworkem Grails a jím používaným jazykem Groovy. Stejně tak zvolení frameworku Bootstrap jako základu pro tvorbu individuálních obrazovek aplikace sloužilo k usnadnění zejména grafických prací, které jinak nesouvisí s hlavním předmětem práce. Výsledkem tak dle mého názoru je nejen funkční, ale také graficky atraktivní nástroj, což usnadňuje jeho pronikání mezi uživatele.
3.1 3.1.1
Volba použitých technologií Programovací jazyk
Pro implementaci jsem volil primárně mezi jazyky PHP a Java, jelikož s těmito jazyky mám dlouholeté praktické zkušenosti a oba poskytují potřebné množství nástrojů pro vývoj webové aplikace potřebného rozsahu a funkcionality. Konečná volba padla na jazyk Java a to zejména z důvodu nutnosti odchytávání událostí telefonní ústředny v reálném čase, přičemž toto je v případě jazyku PHP komplikovaně realizovatelné. 29
3
3. Realizace
3.1.2
Aplikační framework
Jako aplikační framework jsem zvolil Grails verze 1.3.9. Tento, ačkoli nebyl v době počátku vývoje nejaktuálnější dostupnou verzí, nabízel největší počet podporovaných doplňků (pluginů) a zároveň měl plnou podporu vývojových prostředí. V tomto případě jsem pro vývoj použil IntelliJ Idea 10.5 ve verzi Ultimate, což je sice nástroj placený, ale nabízející celou řadu nástrojů a usnadnění umožňujících mimo jiné nasazování změn za běhu aplikace, pokročilé doplňování kódu, snadné generování šablon tříd a poskytující přehledné znázornění struktury kódu aplikace. 3.1.2.1
Nástroje nabízené frameworkem
Grails je plně vybaveným frameworkem inspirujícím se Ruby on Rails, obsahujícím hotová řešení pro správu hlavních aspektů webových aplikací. Skládá se z MVC frameworku, jednoduchého šablonovacího nástroje, databázové ORM řešení podobného JPA zvaného GORM (Grails’ object relational mapping), jednoduché správy překladů a nástrojů pro testování, dokumentaci a zajištění kompilace za dodržení předepsaných závislostí (build fáze). Grails navíc obsahuje aplikační server Tomcat určený pro použití během vývoje, umožňující nasazení změn během chodu aplikace a za potřebné podpory vývojového prostředí také debugging. 3.1.2.2
Dostupná rozšíření frameworku
Framework Grails, jakožto komunitně otevřený projekt spoléhá především na uživateli vytvářená rozšíření, zde nazývané pluginy, která doplňují základní funkcionalitu o další různě komplexní funkce. Dostupných rozšíření je v době psaní tohoto textu přes 900, přičemž tento počet tvoří pouze rozšíření publikovaná na hlavním webu grails.org a velký počet rozšíření lze za cenu nekompletní dokumentace či nižší stability získat z dalších zdrojů. Mezi nejoblíbenější podporovaná rozšíření patří ORM framework Hibernate, plugin Resources sloužící pro kompresi a optimalizaci zdrojových souborů zasílaných webovému prohlížeči, dále pak sada nástrojů Spring Security zajišťující autentizaci vůči různým zdrojům (lokální databáze, LDAP resp. Active Directory, OAuth a další), nástroj pro snadné odesílání e-mailů či pluginy pro migraci databáze a vyrovnávací pamět cache. Struktura pluginu je analogická vůči struktuře aplikace, což dále motivuje vývojáře ke zveřejnění částí vlastních aplikací veřejnosti. Pro vyvíjené řešení jsem mimo výše zmíněné dále použil pluginy pro generování QR kódů, kalendářových ICal pozvánek a konverzi souborů s definicí stylu stránky z formátu LESS do formátu CSS. 30
3.1. Volba použitých technologií 3.1.2.3
Generátor administračního rozhraní
Jednou z funcionalit, která umožňuje výrazné zrychlení vývoje je také existence vestavěného generátoru administračního rozhraní aplikace, jež je zde nazýván „scaffolding“. Ten nabízí dobrý základ pro úpravy a rozšíření, avšak nedosahuje v základu zdaleka kvalit svých konkurentů, jimiž jsou například Django pro jazyk Python či Symfony verze 1.x pro jazyk PHP. Naproti tomu však je vytvoření základního rozhraní otázkou několika minut, jelikož nevyžaduje téměř žádnou konfiguraci a funguje na principu reflexe, kterou používá pro vytvoření odpovídajících zobrazení pro každou z doménových tříd datového modelu. Pomocí té vygeneruje 4 základní zobrazení – tabulkový výpis záznamů, zobrazení detailu záznamu a dvojici analogických formulářů pro vytvoření a úpravu záznamu. Velice praktickou funkcí je možnost ve vygenerovaných formulářích ihned definovat vztahy mezi jednotlivými perzistentními objekty a to po drobné úpravě jak u vztahů one-to-one (1:1) a one-to-many (1:N) resp. many-toone (N:1), tak také many-to-many (N:N) , což je například u frameworku Symfony obtížněji realizovatelné. Oproti němu však naopak schází především možnost filtrovat seznam záznamů, upravovat zobrazení seznamu i jednotlivých polí či definovat uživatelské akce ke každému z objektů.
3.1.3
Databázový stroj
Ačkoli platforma Asterisk jako své interní úložiště používá do verze 1.8 databázi Berkeley DB (resp. SQLite3 ve verzi 10), lze ji konfigurovat rovněž pro používání jakékoli externí databáze podporující standard ODBC [22]. Zároveň však v rámci balíku rozšíření asterisk-addons (který byl později integrován přímo do základního balíku) nabízí přímou podporu databáze MySQL. Právě pro tuto databázi jsem se v rámci vytvářené aplikace přiklonil a to zejména z důvodu, že se jedná o rozšířené komunitní řešení, podporované širokou řadou nástrojů včetně pro tento projekt stěžejního ORM frameworku Hibernate, který je sice volitelnou, avšak předinstalovanou a plně kompatibilní součástí Grails.
3.1.4
Komponenty grafického uživatelského rozhraní
Aby aplikace působila uživatelsky atraktivním dojmem, byla uživatelsky snadno použitelná a nebylo nutné se při její tvorbě obracet na zkušené grafiky či designéry, rozhodl jsem se použít prověřený webový framework Bootstrap [23]. Ten je zdarma dostupnou sadou nástrojů urychlujících a 31
3. Realizace usnadňujících tvorbu webových aplikací. Balík těchto nástrojů, skládající se ze souboru obsahujícího CSS styly, nepovinných souborů obsahujících javascriptové knihovny a ukázek kódu ve formátu HTML5, má velikost pouze přibližně 80 kB a je tak vhodným kandidátem na pozici webového frameworku. První verze byla zveřejněna zaměstnanci firmy Twitter v srpnu 2011 a od té doby se projekt stal nejaktivnějším z projektů hostovaných na portále GitHub [24]. Početná komunita nadšenců od té doby vyvíjí nejen aktualizace a nástroje podporující kompatibilitu, ale také samostatně dostupná rozšíření. Způsob použití frameworku a jeho hlavní idea spočívají v použití předem připravených šablon kódu, sloužících jako snadno použitelné stavební prvky webových aplikací. Prvky, pro které jsou k dispozici šablony jsou mimo jiné následující: • Rozvržení stránky • Formuláře • Tabulky • Bloky textu či zdrojového kódu • Tlačítka • Obrázky • Ikony Kromě základních komponent jsou rovněž k dispozici komplexní prvky, při jejichž použití je tvorba stránky otázkou několika minut. Jsou jimi navigační a nástrojové lišty, vyjížděcí seznamy, drobková navigace, stránkovací rozcestníky, upozorňující bloky a okna, ukazatele průběhu akcí a další. Aby byl výčet dostupných funkcí frameworku kompletní, nelze zapomenout na podporu tzv. responsivního designu, při jehož použití se rozvržení stránek automaticky upravuje dle šířky obrazovky prohlížečového okna či zařízení, na kterém je výsledná stránka zobrazována. Použité komponenty: • jQuery • jQuery UI 32
3.2. Nastavení telefonní ústředny Asterisk • jQuery – Chosen • Boostrap Datepicker • Bootstrap File Upload
3.2
Nastavení telefonní ústředny Asterisk
Jelikož jádro samotné funkcionality, tedy konferenční server umožňující vytvoření konferenční místnosti a následné spojení účastníků, je možné již bez existence vyvíjené webové aplikace, bylo zprovoznění tímto způsobem ideálním výchozím bodem pro následnou integraci. Prvotním cílem tedy bylo zprovoznit fungující schéma sestávající se z ústředny Asterisk, nasazené na libovolné kompatibilní linuxové distribuci a dvou telefonů připojených k ústředně pomocí protokolu SIP. Dále bylo třeba vytvořit pro účely testování jednu konferenční místnost a také připojit ústřednu do veřejné telefonní sítě (PTSN).
3.2.1
Instalace telefonní ústředny
Při instalaci ústředny si lze vybrat z mnoha způsobů instalace. Přímo na oficiálních stránkách asterisk.org lze stáhnout kromě zdrojového kódu také předem připravené distribuce AsteriskNOW, ve formě obrazu disku obsahujícího jednoduchý instalátor. I uživatel bez hlubších znalostí instalačních procesů cílové linuxové platformy tak zvládne provést základní instalaci a zvolit si jedno z dostupných webových GUI. Těmi jsou FreePBX a Asterisk GUI, přičemž se zprovozněním druhé z možností byla na mém PC spojena řada komplikací způsobených nekompatibilitou javascriptu s některými moderními prohlížeči. Takto nainstalovaná ústředna běží na linuxové distribuci Centos. Kromě balíku AsteriskNOW lze řešení zkompilovat ze zdrojového kódu, což je varianta, pro kterou jsem se při vývoji přiklonil z důvodů lepší kontroly nad instalačním procesem a možností ponechat pouze skutečně používané komponenty systému. Instalace Asterisk verze 1.8 má pro svůj běh jen minimum povinných závislostí. Pokud však potřebujeme aktivovat rozšiřující modul MeetMe stěžejní pro konference, musíme dále nainstalovat také balík DAHDI (Digium Asterisk Hardware Device Interface), sloužící k mixování zvukových proudů. Samotná volba funkcionalit se provádí pomocí nástroje menuselect, který u každého z volitelných rozšíření umožňuje jeho 33
3. Realizace přidání či odebrání, případně upozorní na další rozšíření či balíky, na kterých je funkce závislá [10]. Z dostupných rozšíření pro tuto implementaci byly stěžejní následující: • res_config_mysql, app_mysql, func_realtime, pbx_realtime, res_realtime - tyto moduly umožňují změnu konfigurace ústředny v reálném čase prostřednictvím relační databáze MySQL • app_meetme, app_talkdetect - tyto moduly přidávají samotnou funkcionalitu konferenčního serveru a detekci mluvčího • chan_sip - tento modul se závislostí na balíku openssh umožňuje komunikaci s telefony a ostatními ústřednami prostřednictvím standartního protokolu SIP • extra-sounds-en-wav / extra-sounds-en-gsm / extra-sounds-... - libovolný z těchto balíků je nezbytný pro instalaci hlášek, které doprovázejí připojování a další procesy v konferenčním systému („zadejte PIN“, „nyní budete připojen do konference“ apod.) Ačkoli ve výchozí instalaci jsou dostupné pouze anglické hlášky, lze do systému snadno doplnit vlastní namluvené či stáhnout již hotový profesionálně namluvený balík, který při splnění několika podmínek (mj. nekomerční použití) nabízí ke stažení firma IPEX a.s. Po nainstalování ústředny tímto způsobem je nutné pro její konfiguraci použít ruční úpravu souborů, nacházejících se ve výchozím nastavení v adresáři /etc/asterisk. Tento adresář obsahuje velký počet konfiguračních souborů, pojmenovaných z důvodů historického vývoje ne vždy zcela intuitivním způsobem. Mezi nejdůležitější soubory pro prvotní nastavení patří: • asterisk.conf - soubor obsahuje základní nastavení ústředny, obsahující cesty k jednotlivým pracovním adresářům ústředny, dále obsahuje nastavení protokolování, výchozího jazyka a limitů zátěže systému, po jejichž překročení přestane ústředna přijímat nové hovory • cdr.conf, cdr_*.conf - obsahuje nastavení protokolování hovorů (např. za účelem tarifikace) • extensions.conf - obsahuje předpisy pro směrování hovorů (tzv. dialplán), přičemž 34
3.2. Nastavení telefonní ústředny Asterisk pravidla směrování pro jednotlivá čísla se dále dělí dle kontextů, ve kterých je číslo použito • manager.conf - obsahuje nastavení komunikačních rozhraní potřebných pro komunikaci s ostatními systémy a aplikacemi (AMI, CLI) • meetme.conf - obsahuje nastavení konferenčních místností, případně definici statických (vždy existujících) místností • sip.conf - obsahuje nastavení komunikujících SIP uzlů (VoIP poskytovatelů, koncových telefonů) • users.conf - obsahuje analogická nastavení jako soubor sip.conf (či další jako iax.conf, h323.conf, ...), avšak nezávisle na použitém komunikačním protokolu
3.2.2
Nastavení lokálních telefonů komunikujících protokolem SIP
3.2.2.1
Volba a připojení testovacích telefonů
Přestože jsem po celou dobu vývoje měl k dispozici několik stolních telefonů značek Cisco a Gigaset, až do předprodukčních testů bylo vhodnější využití softwarových telefonních klientů a to zejména z důvodů snadného střídání připojených linek a možnosti vývoje i kdekoli na cestách. Dobře se osvědčily zdarma dostupní klienti pro OS Windows: 3CX, Jitsi a X-Lite, přičemž všechny tyto nástroje mají podporu požadovaného protokolu SIP. Nevýhodou pak je nemožnost provozovat na jednom počítači více než jednu instanci jakékoli z těchto aplikací. Řešením je pak instalace a spuštění více aplikací současně, přičemž sdílení jedné zvukové karty již naštěstí není komplikací. Ukázku rozhraní těchto klientů znázorňuje obrázek 3.1. Identifikace a přihlášení telefonů k ústředně se při výchozím nastavení provádí zadáním tří údajů: IP adresy ústředny, účastnického čísla a hesla. Účastnická čísla a hesla musí korespondovat s nastavením provedeným ve výše zmíněném souboru sip.conf. Jelikož nastavení jednotlivých telefonů se ve většině případů liší pouze minimálně (tj. pokud se používají softwarové telefony nebo telefony od stejného výrobce), je vhodné používat při konfiguraci šablony. Ukázku použití takové šablony znázorňuje ukázka kódu 3.1. 35
3. Realizace
Obrázek 3.1: Porovnání vzhledů softwarových SIP klientů (zleva 3CX, XLite, Jitsi)
1 2 3 4 5 6 7 8 9 10 11 12 13
[ base ] ( ! ) dtmfmode=r f c 2 8 3 3 c o n t e x t=d e f a u l t type=f r i e n d [ natted ] ( ! , base ) d i r e c t m e d i a=no h o s t=dynamic [ 9 1 ] ( natted ) s e c r e t =91 [ 9 2 ] ( natted ) s e c r e t =92
Výpis kódu 3.1: Nastavení SIP účtů v souboru sip.conf za použití šablon
Zde je definována základní šablona base, dále rozšiřující šablona natted a nakonec dva telefony s účastnickými čísly 91 a 92 a individuálně definovanými hesly, dědící všechny vlastnosti definovaných šablon. 36
3.2. Nastavení telefonní ústředny Asterisk
3.2.3
Nastavení konferenční místnosti
Ačkoli velká část parametrů konferenční místnosti se nastavuje až v okamžiku jejího vytváření, existují globální parametry, které lze definovat v souboru meetme.conf a mají následně vliv na všechny konference. Kromě nastavení vyrovnávací paměti sloužící k odstraňování šumu (jejíž vysoká hodnota má však za následek opoždění přenášeného zvuku na straně serveru) může obsahovat soubor také tato nastavení: • schedule (ano / ne resp. yes / no) – povolení nastavení konferencí z externího zdroje v reálném čase (v našem případě MySQL databáze) • fuzzystart (číselná hodnota větší nebo rovna nule) – umožnění připojení účastníků před začátkem konference (číslo udává čas v sekundách, o který se mohou účastníci dříve připojit) • earlyalert (číselná hodnota větší nebo rovna nule) – ohlášení předčasného připojení ke konferenci (číslo udává čas v sekundách, o kolik dříve se mohou účastníci připojit, přičemž je jim namísto varování o „neexistující konferenci“ sděleno, že konference ještě nezačala) • endalert (čísledná hodnota větší nebo rovna nule) – udává zbývající čas v sekundách, při kterém je účastníkům konference přehráno oznámení signalizující brzké ukončení konference. Nastavení výše uvedených hodnot je ponecháno na požadavcích konkrétního nasazení, pouze povolení externího zdroje dat (MySQL) je pro funkčnost řešení nutné mít nastaveno na „ano“ resp. „yes“.
3.2.4
Připojení na veřejnou telefonní síť
Připojení telefonní ústředny na veřejnou telefonní síť je opět možné provést několika způsoby. V zásadě však lze buďto využít specifického hardwaru sloužícího pro připojení do analogové telefonní sítě, nebo propojit ústřednu s další, nadřazenou, prostřednictvím kteréhokoli z dostupných protokolů. Nejrozšířenějším je ve druhém případě protokol SIP, nabízený pro komunikaci naprostou většinou tuzemských VoIP operátorů. Pro tento projekt jsem testoval připojení prostřednictvím firem Mikrotech a Xphone. Po volbě operátorů (a podpisu smlouvy) mi byly v obou případech vygenerovány přístupové údaje (uživatelské jméno a heslo) a tyto jsem spolu s IP adresou nadřazené ústředny využil k definování tzv. trunku – komunikačního tunelu umožňujícího obousměrné přenášení hovorů. 37
3. Realizace
1 2 3 4 5 6 7 8 9 10 11 12
[222764661] d i s a l l o w=a l l username =222764661 type=p e e r s e c r e t=
host =81.91.216.18 c o n t e x t=ext−d i d i n s e c u r e=port , i n v i t e f r o m u s e r =222764661 dtmfmode=r f c 2 8 3 3 a l l o w=ulaw a l l o w=alaw
Výpis kódu 3.2: Nastavení SIP trunku v souboru sip.conf Nastavení tohoto trunku se opět provádí v souboru sip.conf, přičemž náhled funkčního nastavení je předmětem ukázky kódu 3.2. Blok konfigurace je uvozený název trunku a obsahuje mimo jiné tyto parametry:
• Allow / disallow: Definice povolených či zakázaných kodeků • Username, secret: Dvojice autentifikačních údajů • Host: IP adresa druhého uzlu • Type: nabývá hodnot peer, user či friend, přičemž toto ovlivňuje způsob navazování připojení mezi ústřednami či telefonem a ústřednou (v praxi se pro telefony využívá nejčastěji hodnota „friend“, pro připojení mezi ústřednami pak hodnota „peer“ [8]) • DTMF mode: Určuje způsob předávání tónové volby (Dual-tone multifrequency signalling) – možnostmi jsou „auto“, „inband“, „rfc2833“ a „sip-info“ přičemž volba závisí opět především na schopnostech a nastavení komunikující protistrany
3.3
Integrace aplikace s telefonní ústřednou
Abychom byli schopni v rámci aplikace sledovat průběh konferencí jakožto i zakládat konference nové a nastavovat jejich parametry, potřeboval jsem najít způsob, jak s ústřednou komunikovat a předávat potřebné informace a příkazy. Asterisk naštěstí v tomto směru nabízí hned několik možností: 38
3.3. Integrace aplikace s telefonní ústřednou • AGI (Asterisk Gateway Interface) Komunikační rozhraní AGI umožňuje přidání funkcionality prostřednictvím skriptů v prakticky libovolném programovacím jazyce. AGI skript je spuštěn v předem definovaném kontrolním bodě ústředny (obvykle v rámci vytáčecího plánu) a komunikace probíhá synchronně prostřednictvím standardního vstupu a výstupu skriptu, přičemž skript vždy volá příkaz a ústředna následně na tento příkaz zašle odpověď. Teprve po přečtení odpovědi lze volat další příkaz. • AMI (Asterisk Manager Interface) Toto rozhraní umožňuje jednoduchou komunikaci prostřednictvím protokolu telnet. Komunikaci zahajuje vždy klient zasláním autentizačních údajů, teprve po jejich ověření je oprávněn volat dostupné příkazy. Každý z příkazů se skládá z názvu a parametrů, z nichž některé mohou být volitelné. Jak název, tak parametry jsou uvedeny na samostatných řádcích, přičemž odeslání dvou ukončení řádků za sebou považuje serverová strana za spuštění zadaného příkazu. Příklad komunikace znázorňuje ukázka kódu 3.3. V této ukázce je znázorněna jednoduchá autentifikace, přičemž data jsou přenášena nezabezpečeně. V případě, že hrozí odposlechnutí hesla, je mnohem vhodnější využít challenge-response autentifikaci, kterou rozhraní AMI také nabízí. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
[ r o o t @ i s −a s t e ~]# t e l n e t 1 2 7 . 0 . 0 . 1 5038 Trying 1 2 7 . 0 . 0 . 1 . . . Connected t o l o c a l h o s t . l o c a l d o m a i n ( 1 2 7 . 0 . 0 . 1 ) . Escape c h a r a c t e r i s ’ ^ ] ’ . A s t e r i s k C a l l Manager / 1 . 1 Action : Login Username : admin S e c r e t : Response : S u c c e s s Message : A u t h e n t i c a t i o n a c c e p t e d Event : F u l l y B o o t e d P r i v i l e g e : system , a l l S t a t u s : F u l l y Booted Action : ListCommands Response : S u c c e s s WaitEvent : Wait f o r an e v e n t t o o c c u r .
( P r i v : <none >)
Výpis kódu 3.3: Běžné přihlášení k rozhraní Asterisk Manager Interface
39
3. Realizace • CLI (Asterisk Command-line Interface) Rozhraní CLI je nejčastěji používané při prvotní konfiguraci ústředny spravujícím uživatelem a to hlavně proto, že oproti výše uvedeným poskytuje přívětivé funkce jako je automatické doplňování a napovídání dostupných příkazů během jejich zadávání a nevyžaduje při odpovídajícím oprávnění v rámci systému již další autentizaci či autorizaci. Příkazy jsou zadávány vždy do jednoho řádků, přičemž jako oddělovač jednotlivých parametrů slouží mezera. • Call files Call files se nazývají soubory, které slouží jako další způsob ovlivnění chování ústředny. Soubor který má sloužit jako „call file“ musí dodržovat danou syntaxi, k jeho provedení však stačí nastavení odpovídajících oprávnění a přesunutí souboru do předem existující složky, odkud jej ústředna načte, provede a následně je soubor smazán. Doba od vložení souboru do složky do začátku provádění skriptu je řádově zlomky sekund. Ukázka kódu 3.4 znázorňuje možnou podobu zmiňovaného souboru. 1 2 3 4 5 6 7
Channel : SIP /6001 MaxRetries : 2 RetryTime : 20 WaitTime : 10 Context : d e f a u l t E x t e n s i o n : 123 Priority : 1
Výpis kódu 3.4: Příklad formátu souboru „call file" Kromě příkazů dostupných prostřednictvím těchto rozhraní zůstává hlavním způsobem, kterým lze ovlivnit chování ústředny, změna jejích konfiguračních souborů. Ačkoli konfugrační soubory jsou ústřednou zpracovávány již při startu a nadále se již načítají pouze z operační paměti, je možné po provedení externí změny vyzvat ústřednu k jejich opětovnému načtení. To je možné prostřednictvím příkazů „sip reload“, „dialplan reload“, resp. „<jmeno modulu> reload“, které lze volat pomocí které lze volat prostřednictvím libovolného z výše uvedených rozhraní .
3.3.1
Nastavení real-time zdroje dat
Ačkoli je použití konfiguračních souborů všeobecně preferovanou variantou a to jak z hlediska obtížnosti nastavení tak z hlediska výkonu, při integraci s dalšími aplikacemi je možné použít tzv. real-time konfigurační zdroj. Tím mohou být například databáze podporující standard ODBC či databáze 40
3.3. Integrace aplikace s telefonní ústřednou MySQL. Kromě základních souborů jako je asterisk.conf lze držet veškerou konfiguraci uvnitř databázových tabulek, jejichž schéma vždy věrně kopíruje parametry dostupné v konfiguraci klasické, souborové. Pro účely implementace konferenčního systému bylo potřeba umožnit nově vytvářené aplikaci přistupovat do seznamu plánovaných konferencí a provádět zde potřebné úpravy. Ve sdílené databázi tak bylo nejprve třeba vytvořit tabulku, pojmenovanou pro usnadnění orientace stejně jako příslušný konfigurační soubor – meetme. Tuto tabulku, jejíž schéma lze vidět v ukázce kódu 3.5, bylo následně třeba nastavit jako real-time konfigurační zdroj pro konference. Ačkoli pro základní fungování jsou v tabulce nezbytné pouze sloupce obsahující číslo konference (confno) a v režimu plánování také sloupce ohraničující dobu trvání konference (starttime, endtime), připravil jsem také další sloupce umožňující podrobnější nastavení vlastností konference a parametrů autentizace (sloupce opts, adminopts, pin, adminpin, members, maxusers). Ostatní sloupce, které jsou ve zmiňované ukázce vypsány jsou používány pouze vytvářenou konferenční aplikací a ústředna Asterisk je nijak neregistruje. mysql> show columns i n meetme ; +−−−−−−−−−−−−−−−+−−−−−−−−−−−−−−+−−−−−−+−−−−−+−−−−−−−−−+−−−−−+ | Field | Type | N u l l | Key | D e f a u l t | Extra | +−−−−−−−−−−−−−−−+−−−−−−−−−−−−−−+−−−−−−+−−−−−+−−−−−−−−−+−−−−−+ | id | bigint (20) | NO | PRI | NULL | AI | | version | bigint (20) | NO | | NULL | | | adminopts | v a r c h a r ( 3 2 ) | NO | | NULL | | | adminpin | v a r c h a r ( 1 0 ) | NO | | NULL | | | agenda | longtext | NO | | NULL | | | created_by_id | b i g i n t ( 2 0 ) | NO | MUL | NULL | | | endtime | datetime | NO | | NULL | | | event_uid | v a r c h a r ( 2 5 5 ) | YES | | NULL | | | maxusers | int (11) | NO | | NULL | | | members | int (11) | NO | | NULL | | | confno | v a r c h a r ( 1 0 ) | NO | | NULL | | | opts | v a r c h a r ( 3 2 ) | NO | | NULL | | | pin | v a r c h a r ( 1 0 ) | NO | | NULL | | | scheduled | bit (1) | NO | | NULL | | | starttime | datetime | NO | | NULL | | | status | v a r c h a r ( 3 2 ) | NO | | NULL | | | topic | v a r c h a r ( 1 2 7 ) | NO | | NULL | | +−−−−−−−−−−−−−−−+−−−−−−−−−−−−−−+−−−−−−+−−−−−+−−−−−−−−−+−−−−−+ 17 rows i n s e t ( 0 . 0 1 s e c )
Výpis kódu 3.5: Schéma databázové tabulky se seznamem konferencí Ačkoli by takto vytvořená tabulka již fungovala jako sdílený seznam plá41
3. Realizace novaných konferencí, provedl jsem ještě jednu změnu spočívající ve využití sloupce scheduled, obsahujícího binární příznak, zda je konference skutečně plánována či ne. Pokud je tedy v rámci aplikace konference pouze ve stádiu konceptu (její správce teprve nastavuje potřebné parametry a doposud např. neví přesné určení času), je tento příznak nastaven na nulovou hodnotu. Aby se tento, ústřednou nepodporovaný parametr, správně projevil na jejím chování, je třeba vytvořit pohled nad tabulkou (view) a teprve tento pohled zvolit jako skutečný zdroj real-time dat. Vytvoření odpovídajícího pohledu je možné následujícím příkazem: CREATE VIEW ‘ meetme_active ‘ AS SELECT ∗ FROM ‘ meetme ‘ WHERE ‘ scheduled ‘ = ’1 ’ ;
Nyní ústředna eviduje pouze skutečně plánované konference a v daný čas umožní připojení. Aby s vytvořenou tabulkou byla možná snadná manipulace i v rámci aplikace, bylo nutné provést odpovídající konfiguraci doménové třídy za pomoci ORM notace GORM. Kromě volby odpovídajících datových typů bylo třeba využít také nepovinného statického atributu doménové třidy – mapping, který umožnil nastavit požadovaný název databázové tabulky i přesnější definice názvů sloupců. Náhled výsledné doménové třídy je znázorněn v ukázce kódu 3.6. 1 class Conference { 2 3 /∗ A s t e r i s k f i e l d s ∗/ 4 S t r i n g number 5 String pin 6 S t r i n g adminPin 7 // @Temporal ( TemporalType .TIMESTAMP) 8 Date s t a r t T i m e 9 Date endTime 10 int members 11 int maxUsers 12 String status 13 String options = " " 14 S t r i n g adminOptions = " " 15 16 /∗ Custom f i e l d s ∗/ 17 String topic 18 S t r i n g agenda 19 User cr ea ted By 20 S t r i n g eventUid 21 22 boolean s c h e d u l e d = true 23
42
3.3. Integrace aplikace s telefonní ústřednou /∗ Custom r e l a t i o n s ∗/ L i s t attachments s t a t i c hasMany = [ participants : Participant , a t t a c h m e n t s : Attachment , collaborationScreens : CollaborationScreen ]
24 25 26 27 28 29 30 31 32
// ( . . . ) v a l i d a t i o n c o n s t r a i n t s , custom g e t t e r s and s e t t e r s (...)
33 34 35 36 37 38 39 40 41 42 43 44 45
s t a t i c mapping = { t a b l e ’meetme ’ number column : ’ confno ’ , type : ’ s t r i n g ’ p i n column : ’ pin ’ , type : ’ s t r i n g ’ , l e n g t h : 10 adminPin column : ’ adminpin ’ , type : ’ s t r i n g ’ , l e n g t h : 10 s t a r t T i m e column : ’ starttime ’ , type : ’ timestamp ’ endTime column : ’ endtime ’ , type : ’ timestamp ’ members column : ’members ’ , type : ’ i n t e g e r ’ , l e n g t h : 4 maxUsers column : ’ maxusers ’ , type : ’ i n t e g e r ’ , l e n g t h : 4 s t a t u s column : ’ status ’ , type : ’ s t r i n g ’ , l e n g t h : 32 o p t i o n s column : ’ opts ’ , type : ’ s t r i n g ’ , l e n g t h : 32 adminOptions column : ’ adminopts ’ , type : ’ s t r i n g ’ , l e n g t h : 32
46 47 48 49 50 51 52 53 54 }
t o p i c type : ’ s t r i n g ’ , l e n g t h : 127 agenda type : ’ text ’ , l e n g t h : 65535 p a r t i c i p a n t s ( column : ’ conference ’ , c a s c a d e : ’ a l l ’ ) attachments ( cascade : ’ a l l ’ ) cre at edB y : column : ’ created_by ’ eventUid : column : ’ event_uid ’ }
Výpis kódu 3.6: Doménová třída konference frameworku Grails v notaci GORM
3.3.2
Nastavení komunikačního rozhraní AMI
Jelikož kromě samotného zakládání a správy konferencí je cílem aplikace nabídnout také pohled na průběh konference v reálném čase, je nutné umožnit jí přístup k dalším informacím. Zejména pak k počtu účastníků aktuálně připojených ke konferenci včetně jejich detailů (účastnického čísla, doby připojení). Dále aplikace potřebuje znát seznam aktuálně hovořicích účastníků, jelikož jejich zvýraznění na stránce konference může výrazně pomoci v orientaci v rámci konference, zejména pokud je počet hovořících účast43
3. Realizace níků vyšší či pokud se ve výkladu nepravidelně střídají. Nakonec musí být aplikace schopna skrze rozhraní vytvořit nové spojení mezi probíhající konferencí a libovolným, nepřipojeným účastníkem. Zjištění všech těchto informací umožňuje právě rozhraní AMI. Nastavení parametrů tohoto rozhraní se provádí prostřednictvím souboru manager.conf. Ukázku tohoto nastavení pak lze vidět v ukázce kódu 3.7. Zde je pro správné fungování nutné nastavit v oddílu general hodnotu enabled na yes a tím rozhraní aktivovat. Dále je nutné definovat uživatele, který bude sloužit pro přístup (výchozího uživatele je vhodné odstranit, případně alespoň změnit jeho heslo na jiné než výchozí „amp111“). Každý z uživatelů má definovanou sadu oprávnění pro čtení a zápis a také mu lze omezit přístup pouze na určité IP adresy (v ukázce je povolen pouze lokální přístup). 1 2 3 4 5 6 7 8 9 10 11 12 13 14
[ general ] enabled = yes ; webenabled = y e s ; e n a b l e s t a t i c = yes p o r t = 5038 bindaddr = 0 . 0 . 0 . 0 d i s p l a y c o n n e c t s=no ; o n l y e f f e c t s 1.6+
[ admin ] writetimeout = s e c r e t = deny = 0 . 0 . 0 . 0 / 0 . 0 . 0 . 0 permit = 1 2 7 . 0 . 0 . 1 / 2 5 5 . 2 5 5 . 2 5 5 . 0 r e a d = system , c a l l , l o g , v e r b o s e , command , agent , u s e r , c o n f i g , command , dtmf , 15 r e p o r t i n g , cdr , d i a l p l a n , o r i g i n a t e 16 w r i t e = system , c a l l , l o g , v e r b o s e , command , agent , u s e r , c o n f i g , command , dtmf , 17 r e p o r t i n g , cdr , d i a l p l a n , o r i g i n a t e
Výpis kódu 3.7: Nastavení rozhraní AMI v souboru manager.conf Zatímco zjištění aktuálně připojených účastníků je operace, kterou lze provádět s větším itervalem řádově až kolem deseti sekund, detekce hovořícího účastníka je informací, jejíž aktualizace by měla být co nejčastější, s maximálním intervalem kolem dvou sekund. I s tímto rozhraní AMI počítá a automaticky po navázání spojení zasílá klientovi všechny události, ke kterým má dle nastavených oprávnění nárok. Vzhledem k tomu, že množství těchto událostí může být u vytížené ústředny enormní, lze se z jejich odběru odhlásit a to při přihlášení přidáním parametru Events s hodnotou off.
44
3.3. Integrace aplikace s telefonní ústřednou
1 2 3 4 5 6 7 8 9
Event : F u l l y B o o t e d P r i v i l e g e : system , a l l S t a t u s : F u l l y Booted Event : R e g i s t r y P r i v i l e g e : system , a l l ChannelType : SIP Domain : 8 1 . 9 1 . 2 1 6 . 1 8 Status : Registered
Výpis kódu 3.8: Náhled událostí zasílaných prostřednictvím rozhraní AMI
3.3.3
Použití knihovny Asterisk-Java
Ačkoli komunikace s rozhraním AMI prostřednictvím protokolu telnet není technicky složitá, jedná se o často řešený problém a tak jsem se namísto vlastní implementace rozhodl pro integraci již hotového řešení. Tímto řešením je zdarma nabízená knihovna Asterisk-Java distribuovaná pod licencí Apache 2.0 [25]. Tato knihovna umožňuje snadnou interakci s rozhraním AMI a to jak formou volání příkazů, tak formou poslechu zpráv a reakcí na ně. Také obsahuje logiku zajišťující opětovné připojení při krátkodobé ztrátě konektivity se serverem Asterisk. Pro zpřístupnění knihovny aplikaci prostřednictvím mechanismu automatického řešení závislostí Maven bylo třeba doplnit do konfiguračního souboru BuildConfig.groovy projektu následující řetězec: 1 g r a i l s . p r o j e c t . dependency . r e s o l u t i o n = { 2 dependencies { 3 // ( . . . ) 4 c o m p i l e ’ o r g . a s t e r i s k j a v a : a s t e r i s k −j a v a : 1 . 0 . 0 −m2’ 5 } 6 }
Výpis kódu 3.9: Vložení závislosti na knihovnu Asterisk-Java do projektu Samotné použití knihovny je následně triviální. V rámci projektu je vhodné komunikaci separovat do služby, kterou je následně možné pomocí mechanismu dependency injection (automatického řešení závislostí) použít uvnitř libovolného controlleru aplikace. Tuto třídu jsem nazval AsteriskInfoService a tato služba, existující pouze v jedné instanci (dle návrhového vzoru Singleton) při svém vytvoření naváže připojení k ústředně, které je následně využíváno pro veškeré volání příkazů a zjišťování stavů. Ukázku implementace servisní třídy a jejího použití uvnitř controlleru znázorňují ukázka kódu 3.10 a ukázka kódu 3.11. 45
3. Realizace
1 c l a s s A s t e r i s k I n f o S e r v i c e implements A s t e r i s k S e r v e r L i s t e n e r { 2 static scope = ’ singleton ’ 3 s t a t i c t r a n s a c t i o n a l = true 4 5 private A s t e r i s k S e r v e r s e r v e r ; 6 7 public A s t e r i s k I n f o S e r v i c e ( ) { 8 ManagerConnection conn = 9 AsteriskAPI . g e t I n s t a n c e ( ) . createConnection ( false ) 10 s e r v e r = new D e f a u l t A s t e r i s k S e r v e r ( conn ) ; 11 s e r v e r . addAsteriskServerListener ( this ) ; 12 } 13 14 public C o l l e c t i o n <MeetMeRoom> g e t A c t i v e C o n f e r e n c e L i s t ( ) { 15 return s e r v e r . getMeetMeRooms ( ) 16 } 17 // ( . . . ) 18 }
Výpis kódu 3.10: Definice služby využívající knihovny Asterisk-Java pro připojení k rozhraní AMI 1 class ConferenceController { 2 def securityService 3 def springSecurityService 4 def a s t e r i s k I n f o S e r v i c e 5 // ( . . . ) 6 7 def l i v e P a r t i c i p a n t L i s t = { 8 C o n f e r e n c e c o n f e r e n c e = C o n f e r e n c e . f i n d B y I d ( params ? . conf_id ) 9 i f ( c o n f e r e n c e && s e c u r i t y S e r v i c e . c h e c k A c c e s s ( ’show ’ , conference ) ){ 10 L i s t <MeetMeUser> a c t i v e U s e r s L i s t = 11 as t er is k In fo Se r vi ce . getConferenceUserList ( conference ) 12 r e n d e r ( view : ’ l i v e P a r t i c i p a n t L i s t ’ , model : [ 13 conference : conference , 14 activeUsers : activeUsersList 15 ]) 16 } else { 17 render ( ’ error ’ ) 18 } 19 } 20 }
Výpis kódu 3.11: Využití služby komunikující s ústřednou v controlleru aplikace 46
3.4. Umožnění sdílení materiálů
3.4
Umožnění sdílení materiálů
Ačkoli navržená webová aplikace zcela jistě může plnit svou roli při vytváření a správě konferenčních místností, další přidaná hodnota spočívá v usnadnění spolupráce uživatelů. Ta obvykle spočívá ve sdílení pracovních materiálů a diskuzi nad nimi. V tomto směru jsem se rozhodl inspirovat aplikací BigBlueButton, která tuto část má zpracovanou zcela bezkonkurenčním způsobem. Ke každé konferenci tak existuje jedna nebo více obrazovek sdílení, které slouží ke zobrazování sdílených dokumentů. Protože největší prioritou bylo umožnění zobrazování prezentací, rozhodl jsem se pro zjednodušení problému namísto serverové konverze PPT dokumentů na obrázky (tj. způsobu, který využívá aplikace BigBlueButton) využít funkcionality aplikace PowerPoint 2010 a totiž sdílení prezentace prostřednictvím URL. Problém se tak redukuje na umožnění zobrazení libovolné URL adresy uvnitř rámce vnořeného do obrazovky sledování průběhu konference.
Obrázek 3.2: Vytvoření obrazovky sdílení Tato obrazovka má k tomuto účelu předem vyčleněnou převážnou část plochy. Uživatel, který v dané konferenci prezentuje (a má k tomu potřebné oprávnění) tak nejprve otevře na svém počítači aplikaci PowerPoint a spustí funkci „Broadcast Presentation“2 . Následně v rámci webové aplikace vytvoří novou plochu pro sdílení s požadovaným rozvržením (znázorněno na 2
Pro použití této funkce je vyžadováno přihlášení pomocí Live ID
47
3. Realizace obrázku 3.2). Zvolené rozvržení definuje počet zón pro vložení obsahu a jejich pozice, dostupných je celkem 8 variant rozvržení. Do každé zóny pak lze umístit jeden z předdefinovaných typů obsahu (obrázek 3.3). Nyní jsou jimi pouze prezentace a webová stránka. V budoucnu by bylo vhodné umožnit vkládání jednoduchých textových poznámek a to jak privátních, tak sdílených. Dále by pak mělo být snadné umožnit zobrazit náhled PDF dokumentů, prezentací či jiných dokumentů prostřednictvím služby Google Docs Viewer [7]. Aby byla sdílená plocha dostačující i na menších obrazovkách3 , je umožněna minimalizace postranní navigační lišty a zvětšení stránky na celou obrazovku (u prohlížečů, které toto podporují).
Obrázek 3.3: Správa obsahu v jednotlivých zónách
3.5
Implementace tarifikace
Ačkoli tato funkcionalita nebyla z hlediska prvního zákazníka potřebná ani požadovaná, byla jedním z úkolů stanovených zadavatelem i příprava takového technického řešení, které by umožňovalo nasazení mimo síť koncového zákazníka, s žádnou či pouze s částečnou integrací do stávající infrastruktury. V tomto případě je možnost odchozího vytáčení (z hlediska audiokon3
Aplikaci lze používat při šířce zobrazení vyšší než 400px, optimální pro zobrazení obrazovky průběhu konference je šířka 800px a vyšší
48
3.5. Implementace tarifikace ferenční ústředny) nutno poskytovat jako součást služby a náklady za ni dodatečně přenášet na uživatele (resp. opět zákazníka). Aby toto bylo možné, bylo nutné rozšířit takový model aplikace o domény týkající se objednávky, platby a čerpání kreditu. Dále bylo třeba umožnit definovat pravidla týkající se právě odchozích hovorů a jejich pravidel. Zejména pak omezení čísel, na které lze provádět odchozí vytáčení, na základě mezinárodních předvoleb a formátů čísel je v tomto případě nezbytné.
3.5.1
Volba platební brány
Při volbě platební brány jsem se soustředil především na ta řešení, která jsou v tuzemsku často používanými a ověřenými. Paralelně s tímto projektem jsem měl možnost otestovat a v několika případech také implementovat některé z těchto platebních bran v samostatných projektech, programovaných vždy ve skriptovacím jazyce PHP. V dlouhé řadě nabízejících se možností jsem se v analýze pro tento projekt zaměřil na platební brány GP WebPay (MUZO), GoPay, PayU a PayPal. 3.5.1.1
Platební brána GP WebPay
Tato platební brána, provozována firmou Global Payments Europe a.s. (dříve nazývaná rovněž MUZO) je v tuzemsku nejčastěji nabízena samotnými bankovními institucemi (Komerční Banka, ČSOB, Raiffeisen Bank, Unicredit Bank [5]). Narozdíl od ostatních popisovaných řešení vyžaduje zřízení platební brány složení jednorázového poplatku ve výši cca 400015000 Kč . Dále je z každé dokončené transakce účtována provize ve výši cca 1-3%. Jedinou dostupnou metodou platby je on-line platba platební kartou. Implementační postup spočívá nejprve ve vygenerování certifikátu, sloužícího k autorizaci budoucích platebních příkazů. Klient rovněž obdrží unikátní číslo obchodníka (merchant number). V okamžiku vytváření platební transakce ze strany aplikace se pak tato prokáže za pomoci čísla obchodníka a certifikátu a rozhraní platební brány ve své návratové informaci odešle URL, na které má být následně přesměrován plátce pro zadání informací o své platební kartě. Po dokončení platby (úspěšném či neúspěšném) je plátce prostřednictvím svého prohlížeče přesměrován zpět na stránky naší aplikace. Té jsou předány parametry PRCODE a SRCODE obsahující návratový kód transakce, případně upřesňující kód chyby, ke které došlo (tou může být nejčastěji zrušení transakce uživatelem, zadání nesprávných 49
3. Realizace platebních údajů nebo chyby týkající se chybné implementace – nesprávné formátování předávaných údajů apod.).
3.5.1.2
Integrované platební řešení GoPay
Platební řešení GoPay, úspěšný český projekt prezentovaný také v pořadu „Den D“ České Televize, je platebním řešením integrujícím v době tvorby této práce 15 platebních metod. Těmito metodami jsou, stejně jako u řešení GP WebPay, platby kartou, navíc jsou dostupné on-line převody prostřednictvím internetových bankovnictví většiny tuzemských bank, mobilní platby pomocí Premium SMS a metody mPlatba, dále pak off-line bankovní převod a další, méně používané platební metody (kupony SuperCASH společnosti Sazka a.s., PaySafe Card, GoPay peněženka) [4]. Hlavní výhodou integrovaného řešení je potřeba pouze jedné implementace s minimálními odlišnostmi průběhu platby mezi jednotlivými platebními metodami. Zřízení obchodního účtu GoPay není zatíženo žádným poplatkem. Výše provize za jednotlivé transakce se liší dle použité platební metody a je určena buďto fixní částkou (3 Kč v případě off-line bankovních převodů), procentuální provizí (1-3,5% u karetních plateb) příp. kombinací obojího (3 Kč + 1,5% v případě on-line bankovních převodů). Obchodníkovi je u GoPay automaticky zřízen virtuální účet, jehož zůstatek lze volitelně a za fixní cenu 10 Kč bez DPH převést na libovolný tuzemský bankovní účet. Toto lze provádět i automatizovaně po dosažení určitého zůstatku na virtuálním účtu příp. periodicky např. 1x týdně. Nevýhodou integrace služby GoPay je především delší platební proces, který je prodloužený o jeden krok: Zákazník je nejprve přesměrován do platební brány GoPay, kde vybere požadovanou platební metodu a vyplní svou e-mailovou adresu a teprve poté je přesměrován do internetového bankovnictví či platební brány akceptující karty Visa, MasterCard a další. Akceptaci karet, která byla dříve realizována prostřednictvím služby Moneybookers, nyní pro GoPay zajišťuje opět služba GP WebPay. K samotné integraci obdrží vývojář dvojici údajů: GoID (identifikátor prodejce) a secret (heslo sloužící k šifrování dat přenášených mezi platební branou a klientem). Zatímco přesměrování na platební bránu probíhá stejně jako u GP WebPay, je nutné pro GoPay navíc zveřejnit tzv. notifikační URL. Jeho adresu je třeba nahlásit během integrace a toto následně slouží pro oznamování dokončení off-line plateb (u bankovních převodů může být prodleva notifikace od zahájení platby až 14 dní). 50
3.5. Implementace tarifikace 3.5.1.3
Platební brána PayU
Platební brána PayU společnosti Aukro je produktem, který vznikl rovněž v roce 2010 a stal se rovněž velmi oblíbeným zejména v segmentu slevových portálů. Myšlenka spojení více platebních metod pod jednu integraci je zde shodná a přestože počet nabízených platebních metod je nižší než u GoPay, jejich výběr je mírně odlišný a tak může být pro některá nasazení vhodnější (brána podporuje navíc např. platby Mobito, Sberbank či platby poštovní poukázkou). Z osobních zkušeností z doby zahájení provozu PayU, kdy byla veškerá komunikace zdlouhavá a proces přidělení údajů pro integraci byl několikrát poskytovatelem oddálen, jsem však toto řešení nepreferoval. 3.5.1.4
Platební brána PayPal
PayPal je oblíbenou platební metodou zejména v USA, avšak je celosvětově rozšířeným platebním řešením. V době psaní této práce PayPal nabízel platby ve 24 měnách ve 190 zemích světa. Stejně jako GoPay a PayU, i PayPal nabízí založení elektronické peněženky spolu s platební branou zdarma. Oproti předchozím platebním metodám však je celý proces automatizován a nasazení nového systému integrujícího tuto platební bránu je tak otázkou maximálně hodin. Nevýhodou oproti konkurenci jsou jednoznačně výše poplatků a nemožnost přepnout zobrazení platební brány do českého jazyka, což může především pro občasné platiče působit nedůvěryhodně. Výše poplatků, které jsou v případě všech platebních bran účtovány pouze straně obchodníka, je u PayPalu součtem fixní částky 10 Kč za transakci a podílu 3,9% (při měsíčním obratu méně než 70 000 Kč) [3].
3.5.2
Integrace platební brány
Na základě výše popsaného rozboru jsem se rozhodl pro integrace platební brány GoPay. Vzhledem k existenci připravené Java knihovny a předchozím zkušenostem s integrací brány do aplikace v jazyce PHP mělo být největší výzvou navržení odpovídajícího datového modelu a obslužného rozhraní. Oproti očekávání však správné použití knihovny vyžadovalo vytvoření délkou kódu poměrně obsáhlou obslužnout třídu „GoPayService“. Navíc příklad použití knihovny, který je součástí balíku materiálů poskytovaných GoPay, je dle mého názoru vytvořen poměrně nevhodně a i kvůli nedostatku dokumentace může velmi snadno způsobit nepochopení, které vyústí v nesprávnou kontrolu dokončení platby a z toho vyplývající riziko podvržení 51
3. Realizace platby a neoprávněného čerpání služeb. Pro usnadnění přechodu z testovacího do produkčního provozu je v konfiguraci aplikace umožněno vyplnění jak produkčních, tak testovacích údajů a jedním kliknutím přepínat, která sada údajů je aktuálně používána.
3.5.3
Nastavení čerpání kreditu
Další součástí potřebnou pro nasazení aplikace jako služby je systém pro tarifikaci. Implementaci této součásti lze pojmout mnoha způsoby a konkrétní zpracování již je mimo rozsah této práce. Přesto se pokusím alespoň nastínit některé koncepty, které by mohly být při dalším vývoji využity. Možností, kterými lze provádět tarifikaci a čerpání kreditu zákazníka, je několik. Vzhledem k tomu, že ceny odchozích hovorů se mohou pohybovat v rozsahu od bezplatných po placené několika desítkami Kč za minutu, je třeba tyto mezi sebou odlišit a zpracovávat rozdílně. Buďto lze omezit hovory pouze na lokální či několik předem definovaných formátů čísel se známými poplatky. V tomto případě lze ihned po dokončení hovoru či již v jeho průběhu odečítat odpovídající výši kreditu, případně probíhající hovor ukončit v případě jeho vyčerpání. Také by bylo vhodné do probíhajícího hovoru přehrát před jeho ukončením vysvětlující oznámení. Formáty čísel je třeba definovat formou regulárních výrazů, aby např. v rámci národních linek bylo možné odlišit tzv. žluté či jiné linky s odlišnou tarifikací. Další možností, jak k řešení problému přistupovat, je provádění zpětného čerpání kreditu např. v týdenních či měsíčních intervalech. V tomto případě je nutné buďto s koncovým zákazníkem mít uzavřenou smlouvu, na základě které je možné dodatečně fakturovat částku nad rámec dostupného kreditu, nebo stanovit minimální výši stavu kreditového účtu, která slouží jako volací jistina. V případě, že zbývající kredit klesne pod limitní částku volací jistiny, není dále možné vytvářet odchozí hovory.
52
Kapitola
Integrace se stávající infrastrukturou Protože naprostá většina firem, které by zadavatel touto aplikací rád oslovil, má již interní telefonní a aplikační infrastrukturu implementovanou, je nutné aby bylo možné aplikaci snadno integrovat. Integraci je třeba provést jak na úrovni telefonní sítě, tak na úrovni autentizace uživatelů.
4.1
Integrace telefonní sítě
Integrace telefonní sítě vyžaduje dva kroky. Jednak umožnit stávajícím uživatelům telefonní sítě připojit se ke konferenci, dále pak umožnit, aby odchozí volání z ústředny byla směrována odpovídajícím způsobem jak v rámci vnitřní sítě, tak do vnější telefonní sítě. Toto se obvykle provádí přidělením unikátního předčíslí všem hovorům směřujícím do či vně konferenční ústředny. Toto předčíslí je na straně příjemce hovoru odstraněno a hovor je dále směrován dle běžného číslovacího plánu (na straně ústředny Asterisk se toto definuje v souboru extensions.conf, na straně Cisco Call manageru pak v nastavení „route patterns“ a „translation patterns“).
4.1.1
Integrace s existující ústřednou Asterisk
Pro umožnění komunikace mezi dvojicí ústředen Asterisk je třeba na obou stranách vytvořit trunk typu peer či friend s analogickou konfigurací. To umožní oběma stranám vzájemně předávat hovory. Maximální počet paralelně směrovaných hovorů lze upravit nastavením hodnoty maximum channels [9]. Nabízí se použití dvou způsobů připojení - pomocí dvojice trunků 53
4
4. Integrace se stávající infrastrukturou SIP a pomocí tunelu IAX - „Inter-Asterisk eXchange“. Nastavení obou metod je v naprosté většině parametrů shodné, avšak rozdíl je ve zpracování hovorů, které jsou předávány. Zatímco u SIP komunikace je každý hovor předáván separátně a jeho SIP i RTP pakety jsou zasílány jednotlivě, při použití IAX tunelu lze uplatnit tzv. „trunking“. Ten spočívá ve spojení dat více hlasových hovorů do jednoho paketu, což sice nepatrně zvyšuje latenci, avšak výrazně snižuje objem přenášených dat, zejména při vysokém počtu současných hovorů, což je případ právě audiokonferencí.
4.1.2
Integrace s ústřednou Cisco Unified Communications Manager
Ústředna Cisco Unified Communications Manager (dále jen CUCM) je, stejně jako Asterisk, softwarovou telefonní ústřednou. Její první verze byla v roce 1997 nabízena pod názvem Selsius-CallManager 1.0. V roce 1998, kdy byla také vydána verze 2.0 byla firma Selsius Systems zakoupena společností Cisco Systems a produkt byl přejmenován na Cisco CallManager, jehož verze 3.0 byla vydána v roce 2000. Zatímco až do verze 4.x byl jádrem operační systém Microsoft Windows (Windows NT 3.51, Windows 2000 a Windows 2003), od verze 5.0 bylo jádro systému linuxové. Zároveň byla přidána podpora protokolu SIP. Dostupná je také možnost propojení prostřednictvím protokolu H323 pro audiovizuální relace. Jelikož jak v testovacím prostředí, tak v prostředí prvního zákazníka byla instalována ústředna CUCM verze 8.x, byly dostupné obě z možností. Zatímco při integraci dvou ústředen Asterisk je plná kompatibilita všech parametrů zajištěna, v případě integrace s ústřednami CUCM jsme nuceni některé parametry nastavit odpovídajícím způsobem tak, aby druhá strana komunikace byla schopna hovor přijmout a správně zpracovávat. Ačkoli dle dokumentace by mělo být možné použít pro přenášení tónové volby specifikaci RFC2833, v praxi přijímající strana při tomto nastavení nedetekovala žádné příchozí DTMF signály. Toto je známý problém právě při použití protokolu H323 [13], avšak stejné chování vykazovalo nastavení RFC2833 i při propojení prostřednictvím protokolu SIP. Jako kompatibilní se v tomto směru ukázalo nastavení „inband“ - tedy zasílání tónové volby v rámci samotného hovoru. Stěžejní pro funkcionalitu SIP integrace je nastavení parametru „qualify“ na hodnotu „yes“ na straně ústředny Asterisk, což je parametr sloužící k ověření dostupnosti vzdáleného CUCM serveru. Vzhledem k tomu, že CUCM server neumožňuje provádění registrace, je toto nastavení nezbytné. Další nastavení spočívá pouze v definování odpovída54
4.2. Integrace autentizačních zdrojů jících směrování hovorů prostřednictvím výše zmiňovaných route patterns, avšak poté integrace již fungovala spolehlivě.
4.2
Integrace autentizačních zdrojů
Aby byla aplikace připravena pro nasazení v podnikových prostředích, je nutné umožnit její integraci se stávajícími autorizačními zdroji. Existence oddělené databáze uživatelů, sloužící pouze pro správu konferencí by v případě nasazení mezi uživatele přinesla nutnost vytvořit novou sadu uživatelských jmen a hesel a tyto mezi uživatelům rozeslat. Lepším, avšak stále nepříliš vhodným řešením je jednorázový import uživatelů z jiného systému, který je uživateli používán (např. doménového účtu v počítačové síti spravované systémem Windows Server či Samba). Komplikací zde je nutnost uživatelům přidělit nové heslo (příp. jiným způsobem vynutit nastavení nového hesla), které je následně od ostatních systémů oddělené. Stejně tak samotný uživatelský účet je spravován samostatně a tak při příchodu či odchodu zaměstnance firmy je třeba založit či zablokovat uživatelský účet v aplikaci. Nejlepší možností je v tomto směru implementace tzv. IAM systémů (Identity and Access Management), které slouží jako externí autentizační (a volitelně také autorizační) zdroje. Motivací k přechodu z jednoduchého modelu autentizace vůči interní databázi je několik. Především jsou to následující [14]: • Snížení počtu identifikátorů a hesel, která si musí uživatel pamatovat • Posílení stávajících autentikačních metod • Snížení nákladů na reset hesla pracovníky help-desku • Vynucení bezpečnostních standardů napříč organizací • Odstranění zodpovědnosti vývojářů nových aplikací definovat bezpečnostní politiku Příkladem IAM systémů jsou adresářová služba LDAP či centrální autentizační zdroj Jasig CAS. Zatímco druhý jmenovaný je vlastnostmi pokročilejší a flexibilnější variantou, rozhodl jsem se pro umožnění integrace s adresářovou službou LDAP a to zejména z důvodů její vyšší rozšířenosti a podpory ostatními aplikacemi a operačnímy systémy. 55
4. Integrace se stávající infrastrukturou
4.2.1
LDAP
LDAP (Lightweight Directory Access Protocol) je protokolem sloužícím pro čtení a zápis v rámci adresářových služeb odpovídajících mezinárodnímu standardu X.500. Protokol je zjednodušenou variantou protokolu DAP, který byl definován právě standardem X.500 v osmdesátých letech 20. století. Mezi nejznámější implementace adresářových službeb, se kterými lze prostřednictvím protokolu LDAP komunikovat, jsou databáze Active Directory využívané v rámci domény operačních systému Microsoft Windows či OpenLDAP používaný v UNIXových operačních systémech. Tyto adresáře obsahují záznamy umístěné v hierarchické struktuře členěné dle organizačních jednotek. Každý ze záznamů pak má dle svého typu volitelný počet atributů. Všechny informace umístěné v databázi musí odpovídat definovanému schématu. Adresářová služba LDAP může obsahovat širokou škálu informací, v našem případě však její využití spočívá v poskytnutí autentizační informace, tedy uživatelského identifikátoru a dalších souvisejících údajů (hesla resp. jeho kryptografického otisku či dalších parametrů sloužících k ověření). Ačkoli lze ověření hesla provést kompletně na straně klienta (toto vyžaduje znalost šifry použité při generování otisku hesla umístěného v adresáři), je možné a obvykle vhodnější tento úkol přenechat databázi a zpracovat pouze návratovou hodnotu tj. potvrzení či zamítnutí autenticity přihlašovaného klienta.
4.2.2
Implementace ve frameworku Grails
Zabezpečení aplikací vytvářených ve frameworku Grails lze řešit pomocí dostupných rozšíření (pluginů) implementujících knihovny Spring Security. Základním rozšířením je plugin spring-security-core, umožňující jednoduchou autentizaci vůči vestavěné databázi. Datový model v tomto případě musí obsahovat domény reprezentující uživatele a jeho role v rámci aplikace. Dalšími rozšířeními, které lze snadno doinstalovat z veřejného repozitáře a rozšířit tak dostupné autentizační zdroje, jsou pluginy spring-security-kerberos, spring-security-radius, spring-security-cas, spring-security-saml, spring-security-twitter, spring-security-openid a další reprezentující stejnojmenné metody autentizace, ale také spring-security-ldap, který jsem se rozhodl využít v tomto projektu. 56
4.2. Integrace autentizačních zdrojů 4.2.2.1
OpenLDAP
Integrace přihlášení s existující databází OpenLDAP je po instalaci odpovídajícího rozšíření čistě záležitostí konfigurace. Ta se provádí standardní notací uvnitř souboru grails-app/conf/Config.groovy a její ukázkou je výpis kódu 4.1. Nejprve je třeba povolit autentizaci uživatelů vůči databázi LDAP, přidáním poskytovatele ldapAuthProvider. Následně je třeba nastavit přihlašovací údaje správce databáze a kontextovou cestu pro vyhledání uživatelů, jež je zde definována řetězcem dc=dev,dc=improvisio,dc=cz. 1 g r a i l s . p l u g i n s . s p r i n g s e c u r i t y . providerNames = [ ’ ldapAuthProvider ’ , ’ rememberMeAuthenticationProvider ’ ] 2 g r a i l s . p l u g i n s . s p r i n g s e c u r i t y . l d a p . c o n t e x t . managerDn = ’ cn= admin , dc=dev , dc=i m p r o v i s i o , dc=cz ’ 3 g r a i l s . p l u g i n s . s p r i n g s e c u r i t y . l d a p . c o n t e x t . managerPassword = ’< h e s l o >’ 4 g r a i l s . p l u g i n s . s p r i n g s e c u r i t y . ldap . context . s e r v e r = ’ ldap :// edmonton . i m p r o v i s i o . c z : 3 8 9 ’ 5 6 g r a i l s . p l u g i n s . s p r i n g s e c u r i t y . ldap . a u t h o r i t i e s . retrieveGroupRoles = f a l s e 7 g r a i l s . p l u g i n s . s p r i n g s e c u r i t y . ldap . a u t h o r i t i e s . retrieveDatabaseRoles = true 8 g r a i l s . p l u g i n s . s p r i n g s e c u r i t y . l d a p . s e a r c h . b a s e = ’ dc=dev , dc= i m p r o v i s i o , dc=cz ’ 9 g r a i l s . p l u g i n s . s p r i n g s e c u r i t y . password . a l g o r i t h m = ’MD5’ 10 g r a i l s . p l u g i n s . s p r i n g s e c u r i t y . l d a p . mapper . u s e r D e t a i l s C l a s s = ’ i n et O r g Pe r s on ’ 11 g r a i l s . p l u g i n s . s p r i n g s e c u r i t y . l d a p . auth . hideUserNotFoundExceptions = f a l s e 12 g r a i l s . p l u g i n s . s p r i n g s e c u r i t y . l d a p . useRememberMe = t r u e
Výpis kódu 4.1: Nastavení autentizace prostřednictvím databáze LDAP 4.2.2.2
Active Directory
Přestože jak OpenLDAP, tak Active Directory umožňuje pro komunikaci použít protokol LDAP [6], vyžaduje každá z databází nepatrně odlišné nastavení. Především je třeba nastavit filtr vyhledávání (klíč .search.filter) na hodnotu „sAMAccountName={0}“, čímž specifikujeme, které pole z Active Directory má být použito jako uživatelské jméno. Nastavení klíče .authorities.groupSearchFilter pak slouží k nastavení mapování uživatelských skupin na uživatelské role v aplikaci. Role jsou dále využity pro určení oprávnění uživatele. V praxi tak nastavení oprávnění může být tímto způsobem plně externalizováno.
57
4. Integrace se stávající infrastrukturou
1 g r a i l s . p l u g i n s . s p r i n g s e c u r i t y . ldap . a u t h o r i t i e s . ignorePartialResultException = true 2 g r a i l s . p l u g i n s . s p r i n g s e c u r i t y . l d a p . s e a r c h . f i l t e r =" sAMAccountName={0}" 3 g r a i l s . p l u g i n s . s p r i n g s e c u r i t y . ldap . a u t h o r i t i e s . g r o u p S e a r c h F i l t e r = ’ member={0} ’ 4 g r a i l s . p l u g i n s . s p r i n g s e c u r i t y . ldap . a u t h o r i t i e s . g r o u p S e a r c h F i l t e r = ’ ( member : 1 . 2 . 8 4 0 . 1 1 3 5 5 6 . 1 . 4 . 1 9 4 1 : = { 0 } ) ’
Výpis kódu 4.2: Nastavení autentizace pro prostředí Active Directory
58
Kapitola
Testování V rámci této kapitoly podrobněji popíši, jaký průběh mělo samotné testování aplikace. Jelikož byl důraz kladen na snadné používání aplikace, také testování se soustředilo především na uživatelské zkušenosti získané v průběhu práce s aplikací. Kromě toho bylo vytvořeno několik automatizovaných testů uživatelského rozhraní, které slouží k prověření funkcionality základních uživatelských scénářů.
5.1
Automatické testování uživatelského rozhraní
Aby bylo možné již v průběhu vývoje provádět jinak časově velmi náročné testování frontendu aplikace, použil jsem v projektu nástroj Selenium [26] sloužící k automatizaci této činnosti. Základem je definování exaktního postupu, skládajícího se z velkého množství atomických operací, které se následně již bez přičinění uživatele opakovaně provádějí. Operacemi jsou jednotlivá kliknutí na tlačítka, přesouvání kurzoru, čekání na odezvy serveru, ověřování zobrazených textů a další. Jelikož ruční psaní předpisu je rovněž časově náročné, je vhodné nejprve využít pluginu pro prohlížeč Mozilla Firefox, který umožňuje sledování operací uživatele a jejich nahrávání a překlad právě do předpisu pro testování. Ukázka části výsledného předpisu je předmětem obrázku 5.1. Díky integraci s projektem frameworku Grails prostřednictvím pluginu „Grails-Selenium“ je spuštění jednotlivých testů možné pomocí příkazu run-selenium zadaného do interaktivní konzole. 59
5
5. Testování
Obrázek 5.1: Předpis pro automatické testování grafického rozhraní
5.2
Uživatelské testování
Uživatelské testování, které probíhalo dle předem stanovené metodiky, sloužilo především k ověření použitelnosti a detekování chyb, které by po nasazení ovlivňovaly velkou část uživatelů aplikace. I vzhledem k časové náročnosti testů byly tyto prováděny pouze šesti osobami. Byli vybráni dva zástupci uživatelů, kteří sami sebe ohodnotili jako začátečníky co se práce s webovými aplikacemi tohoto typu týče. Dále byli vybráni dva uživatele středně pokročilí a dva uživatelé z řad vývojářů. Žádný z těchto uživatelů však neměl předchozí zkušenost s používáním této konkrétní aplikace ani nebyl podrobněji seznámen s architekturou řešení. Každý z uživatelů dostal seznam deseti úloh s podrobnějším popisem, avšak bez instrukcí, jak určeného cíle dosáhnout. Jednalo se o tyto uživatelské scénáře: 1. Přihlášení 2. Odhlášení 3. Vytvoření konference 4. Přidání účastníka do konference 5. Připojení se ke konferenci 6. Ztlumení účastníka připojeného ke konferenci 7. Sdílení PowerPoint 2010 prezentace 8. Změna termínu konference 60
5.2. Uživatelské testování 9. Nahrání přílohy ke konferenci 10. Uzamčení konferenční místnosti Přestože naprostá většina testů proběhla v souladu s očekáváním a bez významných odchylek, podařilo se díky nim odhalit několik nedostatků. Konkrétně šlo o problém s nepříliš intuitivním zobrazením PIN kódu a dalších informací o konferenci. Rovněž byla identifikována chyba způsobující, že některá tlačítka ovládání konference mohou reagovat nespolehlivě (vyžadují opakované kliknutí). Poslední chybou, která způsobila nepříjemnosti jednomu z testujících, bylo chybějící potvrzení akce odpojení uživatele z konference. Při nepřesném kliknutí na ztlumení účastníka tak namísto toho došlo k jeho odpojení. Část těchto identifikovaných problémů byla ihned opravena, některé (jako nutnost opakovaného kliknutí na tlačítko) vyžadují hlubší přepracování a jejich zapracování je plánováno v následující verzi. Příjemným zjištěním bylo, že se naprostou většinu úkolů podařilo uživatelům splnit bez chyby a nutnosti vyžádat si pomoc. Průměrné časy plnění úkolů hrubě odpovídaly zkušenosti uživatelů a rovněž při opakovaném použití aplikace4 již byly časy plnění úkolů až na výjimky nižší, v průměru o 34%.
Obrázek 5.2: Průměrný čas strávený prováděním testovacího scénáře dle zkušenosti uživatele a opakování
4
Prodleva obou testování byla vždy cca 7 hodin
61
5. Testování
5.3
Testování výkonu
Vyvíjená aplikace je typem aplikace, která je za svého provozu zatěžována velmi nerovnoměrně. Mimo pracovní dobu firmy a často i během ní může být zátěž aplikace prakticky nulová. Naproti tomu v době konání konference, zejména takové, jejíž součástí je sdílení prezentace, vyžadující připojení účastníků k rozhraní aplikace, je zátěž úměrná počtu účastníků připojených ke konferencím. Abych otestovali toto limitní zatížení, rozhodl jsem se využít nástroje JMeter [27], sloužícího pro zasílání simulovaných požadavků na webový server. V aplikaci JMeter jsem definoval skupinu 50 uživatelů, kteří se postupně připojují k aplikaci. Cílovým testovaným stavem je stav, kdy mají všichni uživatelé otevřenou stránku průběhu konference, cesty jednotlivých uživatelů na tuto stránku nejsou nijak simulovány. Každý z uživatelů se nejprve musí přihlásit, aby obdržel cookie, pomocí které se následně autorizuje ke konkrétní konferenci. Následně každou vteřinu odesílá na server požadavek, přičemž doba jeho zpracování je hlavním sledovaným parametrem. Jelikož testovací server byl provozován ve virtualizovaném prostředí VMware ESXi, měl jsem možnost upravovat výši jeho přidělených prostředků. Nejprve byl provedený test na konfiguraci, jež byla použita při vývoji. Tou bylo přidělené 1 jádro procesoru Intel Xeon taktovaného na frekvenci 2,16 GHz a 1 GB operační paměti. Při této konfiguraci, podle očekávání, nebylo možné dosádnout požadovaných hodnot odezvy. Graf vývoje odezvy od počátečního zatížení přihlašováním uživatelů až do téměř limitního stavu znázorňuje obrázek 5.3. Naměřená průměrná doba odezvy v tomto případě byla 5582 ms, tedy více než by umožňovalo snadnou orientaci v průběhu konference díky zvýraznění aktuálně hovořícího účastníka. Aby bylo dosaženo požadovaných parametrů a byly blíže simulovány prostředky produkčního serveru, byla konfigurace serveru navýšena přidělením 4 jader procesoru a 16 GB operační paměti. Po tomto navýšení bez dalších změn byl provedený test zátěže se stejným průběhem. Jeho výsledky jsou znázorněny v obrázku 5.4. Naměřené hodnoty pak shrnuje tabulka 5.1. Průměrná odezva v tomto případě byla pouze 734 ms, tedy pod hranicí, jež byla v rámci nefunkčních požadavků na aplikaci stanovena jako optimální.
62
5.3. Testování výkonu
Obrázek 5.3: Graf testování zátěže - 1 x Xeon @ 2,16 GHz; 1 GB RAM prům. odezva modře, median fialově, propustnost zeleně
Obrázek 5.4: Graf testování zátěže - 4 x Xeon @ 2,16 GHz; 16 GB RAM prům. odezva modře, median fialově, propustnost zeleně
Tabulka 5.1: Tabulka výsledků naměřených při testování výkonu Konfigurace 1 x Xeon @ 2,16 GHz; 1 GB RAM 4 x Xeon @ 2,16 GHz; 16 GB RAM
Prům. odezva 5581 ms 734 ms
Median 6602 ms 660 ms
Propustnost 292,27 / min. 1306,24 / min.
63
Závěr Práce na tomto projektu přinesla mnoho nedocenitelných zkušeností zejména v oblastech VoIP technologií a aplikačního frameworku Grails. Přes mnoho počátečních nezdarů při konfiguraci ústředny Asterisk a zdlouhavé úpravy generátoru administračního rozhraní se podařilo vytvořit nástroj, který splňuje zadání zákazníka a v mnoha ohledech ho také rozšiřuje. Jako vedlejší produkt práce byl také vytvořen opětovně použitelný základ webové aplikace na frameworku Grails, poskytující mnoho nástrojů vyžadovaných ve většině projektů. Tento základ je nyní použitý při vývoji aplikace sloužící pro správu marketingových materiálů na pobočkách. Vytvořená aplikace splňuje veškeré požadavky, které jsou na moderní aplikace uživateli kladeny a to zejména co se týká rychlosti odezvy, grafické atraktivity a intuitivního používání. Také implementace asynchronních požadavků prostřednictvím technologie AJAX přináší výhody v těchto oblastech. I díky tomu byla při jednáních u zákazníka aplikace snadno přijata a po úspěšném předvedení byla nasazena do fáze testovacího provozu u zákazníka zadavatele. Soudě podle tohoto a splnění všech funkčních i nefunkčních požadavků daných zadavatelem i prvním zákazníkem lze dosavadní průběh projektu hodnotit jako úspěšný.
Náměty pro pokračování projektu Přestože stanovené cíle projektu byly splněny, nabízí se několik rozšíření a úprav, které mohou být realizovány v následujících vývojových fázích. Kromě kompletní implementace tarifikace, jež byla zmiňována v rámci kapitoly 3.5.3, by se další vývoj mohl zabývat optimalizací zobrazení aplikace 65
Závěr na mobilních zařízeních, rozšířením dostupných formátů sdílených materiálů či nabízením sdílení plochy počítače. Také by bylo vhodné otestovat kompatibilitu s novými verzemi ústředny Asterisk (10 a 11), které byly vydané až během vývoje aplikace. Aplikace by také, pro snadnější nasazení, mohla v budoucnu obsahovat instalační proces, který by automaticky odpovídajícím způsobem konfiguroval připojenou ústřednu.
66
Literatura [1] SPELL, Brett. Java Programujeme profesionálně. Computer Press, 2002. 1022 s. Přel. z Professional Java Programming. Wrox Press, 2000. 80-7226-667-5 [2] Hibernate ORM Framework Dostupné z WWW: http://www.hibernate.org [3] PayPal CZ - Poplatky za platby [online]. [cit. 4. května 2013]. Dostupné z WWW: http://www.paypalcz.cz/poplatky-za-platby [4] GoPay Podmínky - sazebník poplatků [online]. [cit. 28. dubna 2013] Dostupné z WWW: https://www.gopay.cz/podminky/sazebnik [5] Global Payments Europe GP webpay - moderní a bezpečná internetová platební brána [online]. [cit. 28. dubna 2013] Dostupné z WWW: http: //www.gpwebpay.cz/ [6] Symas Corporation. Assessment of Microsoft’sActive DirectoryApplication Mode (ADAM) as a Potential Enterprise Directory Technology versus OpenLDAP and Other LDAP Offering. 2007 [online]. [cit. 12. dubna 2013] Dostupné z WWW: ftp://ftp.uni-duisburg.de/LDAP/ Adam-Eval1-0.pdf [7] Google Dokumenty Google - prohlížeč [online]. [cit. 6. dubna 2013] Dostupné z WWW: https://docs.google.com/viewer [8] HRUŠKA, Petr. Konfigurace Asterisku - User, peer a friend 2009 [online]. [cit. 21. dubna 2013] Dostupné z WWW: http://www.telegro.cz/2009/05/23/konfigurace-asterisku7-user-peer-friend 67
Literatura [9] van MEGGELEN, Jim, SMITH, Jared, MADSEN, Leif. Connecting Two Asterisk Boxes Together via IAX [online]. Dostupné z WWW: http://www.asteriskdocs.org/en/2nd_Edition/asteriskbook-html-chunk/I_sect14_tt670.html [10] DAVENPORT, Malcolm. Using Menuselect to Select Asterisk Options [online]. [cit. 28. února 2013] Dostupné z WWW: https: //wiki.asterisk.org/wiki/display/AST/Using+Menuselect+to+ Select+Asterisk+Options [11] Asterisk Cisco CallManager Integration [online]. [cit. 1. května 2013] Dostupné z WWW: http://www.voip-info.org/wiki/view/ Asterisk+Cisco+CallManager+Integration [12] SAMINI, Reza, Asterisk H323 Trunk to Cisco call manager [online]. [cit. 28. dubna 2013] Dostupné z WWW: http://www.mehrdust.com/ archives/asterisk-h323-trunk-to-cisco-call-manager [13] Cisco Systems, Inc. Cisco Unified Communications System 8.x SRND [online]. [cit. 25. dubna 2013] Dostupné z WWW: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/ media.html#wp1056938 [14] The Business Of Authentication [online]. [cit. 24. dubna 2013] Dostupné z WWW: http://www.authenticationworld.com/ [15] The Apache Software Foundation. Apache HTTP server benchmarking tool [online]. [cit. 7. dubna 2013] Dostupné z WWW: http: //httpd.apache.org/docs/2.2/programs/ab.html [16] Get Started - Learn Open-Source Asterisk [online]. [cit. 1. března 2013] Dostupné z WWW: http://www.asterisk.org/get-started [17] Community - Join the Asterisk Project [online]. [cit. 30. dubna 2013] Dostupné z WWW: http://www.asterisk.org/community [18] Asterisk Architecture, The Big Picture [online]. [cit. 9. dubna 2013] Dostupné z WWW: https://wiki.asterisk.org/wiki/display/AST/ Asterisk+Architecture%2C+The+Big+Picture [19] Converting WAV files into MP3’s automatically for asterisk recordings [online]. [cit. 1. dubna 2013] Dostupné z WWW: http: //community.spiceworks.com/how_to/show/890-converting-wavfiles-into-mp3-s-automatically-for-asterisk-recordings 68
Literatura [20] Conferences - FreePBX Modules - FreePBX Documentation [online]. [cit. 26. dubna 2013] Dostupné z WWW: http://wiki.freepbx.org/ display/F2/Conferences [21] Web-MeetMe - SourceForge.net [online]. [cit. 26. dubna 2013] Dostupné z WWW: http://sourceforge.net/projects/web-meetme/ [22] Installing and configuring ODBC [online]. [cit. 12. dubna 2013] Dostupné z WWW: http://www.asteriskdocs.org/en/2nd_Edition/ asterisk-book-html-chunk/installing_configuring_odbc.html [23] Bootstrap [online]. [cit. 4. dubna 2013] Dostupné z WWW: http:// twitter.github.io/bootstrap/index.html [24] Popular Starred Repositories [online]. [cit. 16. dubna 2013] Dostupné z WWW: https://github.com/popular/starred [25] Asterisk-Java Project License [online]. [cit. 17. dubna 2013] Dostupné z WWW: http://www.asterisk-java.org/development/ license.html [26] Selenium - Web Browser Automation [online]. [cit. 3. dubna 2013] Dostupné z WWW: http://docs.seleniumhq.org/ [27] Apache JMeter [online]. [cit. 24. dubna 2013] Dostupné z WWW: http: //apache.jmeter.org
69
Příloha
Seznam použitých zkratek PBX Private Branch Exchange CUCM Cisco Unified Communications Manager IVR Interactive Voice Response LDAP Lightweight Directory Access Protocol ODBC Open Database Connectivity IAX Inter-Asterisk Exchange AMI Asterisk Manager Interface CLI Asterisk Command-line Interface PTSN Public Switched Telephone Network
71
A
Příloha
Obsah přiloženého CD
readme.txt ................................ stručný popis obsahu CD docs. ........................................ dokumentace projektu installation.pdf ............................. instalační manuál getting-started.pdf................stručné seznámení s aplikací user-manual.pdf.............................uživatelský manuál presentation.pptx...................prezentace přínosů aplikace project.................................adresář s modelem aplikace project.eap .. UML návrh aplikace z nástroje Enterprise Architect src impl.................................zdrojové kódy implementace thesis....................zdrojová forma práce ve formátu LATEX target.................adresář s kompilovanou formou implementace conference.war ...... archiv určený k nasazení na aplikační server test......................................adresář s testovacími daty gui concept.pdf ....... rozvaha nad tvorbou uživatelského rozhraní h-analysis.pdf....heuristická analýza vývojové verze rozhraní perf data.csv..................data naměřená při testování výkonu text.....................................................text práce thesis.pdf...........................text práce ve formátu PDF 73
B
