Fakulta elektrotechnická Katedra telekomunikační techniky
Softwarové ústředny ve vestavěných
systémech
Softswitches in embedded systems
DIPLOMOVÁ PRÁCE
Studijní program: Komunikace, multimédia a elektronika
Studijní obor: Sítě elektronických komunikací
Vedoucí práce: Ing. Bezpalec Pavel Ph.D.
Prohlašuji, že jsem svou diplomovou práci na téma Softwarové ústředny ve vesta-věných systémech vypracoval samostatně s přispěním vedoucího práce a použil jsem pouze literaturu uvedenou v přiloženém seznamu.
Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).
Rád bych poděkoval vedoucímu diplomové práce Ing. Pavlu Bezpalcovi Ph.D. za poskytnutí materiálů, cenné připomínky a odborné rady při tvorbě práce. Zároveň bych velmi rád poděkoval společnosti UPC Česká republika s.r.o. za zapůjčení přístroje Grandstream UCM 6102 pro účely testování v této diplomové práci.
Diplomová práce se zabývá problematikou nově vznikajících vestavěných systémů a jejich výkonností s ohledem na použití v konkrétní aplikaci jako softwarové ústředny. Teoretická část práce, vymezující základní pojmy diplomové práce, se zaměří na přehled aktuálně dostupných systémů na trhu a jejich využitelnost v rámci malých pobočkových ústředen. Rozebrána je také problematika volání skrze IP síť a využívané protokoly pro potřeby přenosu signalizace a hlasu. Praktická část práce spočívá v navržení komplex-ního testování vestavěných systémů s ústřednou, zjišťující maximální možné provozní zatížení jednotlivých vestavěných systémů, a to za použití testovacích softwarů SIPp, SIP Tester a iPerf. Závěr práce je věnován výslednému shrnutí získaných výsledků a následnému zhodnocení nasazení těchto systémů v praxi.
Klíčová slova
VoIP, SIP, RTP, Asterisk, SIPp, iPerf, vestavěný systém, Raspberry Pi, Orange Pi, Banana Pi
Summary
This thesis deals with emerging embedded systems and their performance with respect to use in a particular application as a software PBX. The theoretical part defining the basic concepts of the thesis will focus on an overview of the currently available systems on the market and their usefulness in small PBXs. Also discussed is the issue of the call through the IP network and used protocols for purposes of transmission of signaling and voice. The practical part consists in proposing a comprehensive testing of embed-ded systems with the exchange, detecting the maximum allowable operating load of embedded systems, using test software SIPP, SIP Tester and iperf. The conclusion is devoted resulting summary of the results obtained and the subsequent evaluation of the deployment of these systems in practice.
Index Terms
VoIP, SIP, RTP, Asterisk, SIPp, iPerf, embedded system, Raspberry Pi, Orange Pi, Banana Pi
Obsah
1 Zadání práce 8
2 Vestavěné (embedded) systémy 9
2.1 Parametry vestavěných systémů . . . 9
2.2 RaspberryPi 2 Model B . . . 10
2.3 Banana Pi . . . 11
2.3.1 Banana Pi BPI-M1+ . . . 11
2.3.2 Banana Pi BPI-M2 Quad-core . . . 12
2.3.3 Banana Pi BPI-M3 Octa-core . . . 12
2.4 Orange Pi . . . 13 2.4.1 Orange Pi PC . . . 13 2.4.2 Orange Pi One . . . 14 2.5 CubieBoard 2 . . . 14 2.6 BeagleBone Black . . . 15 2.7 UP . . . 15 2.8 Pine A64+ . . . 16 2.9 Grandstream UCM 6102 . . . 17
2.10 Přehled vestavěných systémů . . . 18
3 Voice over Internet Protocol (VoIP) 19 3.1 Session Initalization Protocol (SIP) . . . 19
3.2 Real-time Transport Protocol (RTP) . . . 21
4 Softwarové ústředny 23 4.1 Asterisk . . . 23 4.1.1 Základní konfigurace . . . 23 5 Testovací software 26 5.1 SIPp . . . 26 5.1.1 Instalace SIPp . . . 27 5.1.2 Vytvoření testovacích scénářů . . . 28 5.2 iPerf . . . 29 5.3 SIP Tester . . . 30 6 Metodika testování 32 6.1 Registrace telefonních přístrojů . . . 32
6.2 Simulace hovorů včetně přenosu hlasu . . . 33
6.3 Simulace hovorů - přenos pouze signalizace . . . 35
6.4 Sledované statistiky . . . 36 7 Testované systémy 38 8 Výsledky testů 39 8.1 Raspberry Pi 2 Model B . . . 39 8.1.1 Scénář REGISTER . . . 39 8.1.2 Scénář INVITE s RTP . . . 41
8.1.3 Scénář INVITE s přímým přenosem médií . . . 46
8.2 Orange Pi PC . . . 50
8.2.1 Scénář REGISTER . . . 50
8.2.2 Scénář INVITE s RTP . . . 54
8.2.3 Scénář INVITE s přímým přenosem médií . . . 58
8.3 Grandstream UCM 6102 . . . 62 8.3.1 Scénář REGISTER . . . 62 8.3.2 Scénář INVITE s RTP . . . 64 9 Zhodnocení 66 Seznam zkratek 68 Seznam obrázků 71 Seznam tabulek 71 Seznam ukázek kódů 72 Reference 73 Seznam příloh 74 Příloha A - Základní příkazy Asterisk konzole . . . 75
Příloha B - Testovací scénář REGISTER . . . 76
Příloha C - Testovací scénář INVITE s RTP . . . 77
Příloha D - Testovací scénář INVITE s přímý přenosem médií . . . 80
Příloha E - Konfigurační soubory CSV . . . 84
Příloha F - Nastavení ústředny Asterisk . . . 86
Příloha G - Výsledky simulace hovorů s přenosem RTP - Raspberry Pi 2 Model B . . . 88
Příloha H - Výsledky simulace hovorů s přenosem RTP - Orange Pi Pc . . . 92
Příloha I - Výsledky simulace hovorů s přenosem RTP - Grandstream UCM 6102 . . . 96
1
Zadání práce
Cíle této diplomové práce na téma Softwarové ústředny ve vestavěných systémech jsou stanoveny na základě důkladného prostudování problematiky softwarových ústředen a vestavěných systémů. Výstupem této práce bude zpracování problematiky vestavěných systémů a jejich využití v IP telefonii. Úvod práce bude zaměřen na vestavěné sys-témy, které jsou vhodné pro využití v praxi při provozování pobočkových softwarových ústředen.
Dalším cílem práce je zaměření se na jednotlivé softwarové ústředny, jejich vlast-nosti, instalaci a základní konfiguraci pro realizaci hovoru. V této dílčí části práce bude zpracována komplexní problematika konfigurace softwarových ústředen pro uskuteč-nění takzvaného internetového volání. Poznatky budou zároveň využity pro realizaci softwarové pobočkové ústředny.
Před samotným testováním se autor práce zaměří na problematiku simulačních pro-gramů pro simulaci síťového provozu. Zejména na simulační program SIPp, který umož-ňuje realizovat spojení se softwarovou ústřednou na základě komunikačního protokolu SIP. Pro zatížení testovacího systému datovým provozem je možné využít program iPerf. Tento program dokáže realizovat zatížení datovým provozem na protokolu TCP, UDP.
Na základě poznatku a možných konfigurací simulačních programů budou autorem práce stanoveny testovací scénáře pro komplexní otestování plného provozního zatížení vestavěného systému. Součástí testovacích scénářů bude snaha zaznamenat vliv počtu současných hovorů včetně přenosu hlasu skrz ústřednu. Současně bude zaznamenán vliv operačního systému na maximální možný počet uskutečněných hovorů v jeden okamžik.
S využitím testovacích scénářů budou realizovány testy na jednotlivých vestavěných systémech, které budou k dispozici. Testy budou probíhat na systému RaspberryPi 2 Model B a na systému Orange Pi PC. V případě sehnání prostředků na další konku-renční systémy budou otestovány další konkukonku-renční vestavěné systémy a zhodnoceny na základě výkonnostních parametrů.
Závěr bude tvořit srovnání získaných dat a zhodnocení, které z měřených zařízení dosáhlo nejlepších výsledků. S ohledem na důležité parametry bude sestaven přehled vestavěných systémů vhodný pro realizaci softwarové ústředny v malé firmě.
2
Vestavěné (embedded) systémy
Vestavěné systémy neboli jednodeskové počítače jsou dnes vyráběny ve velkých sériích a jsou komerčně velmi dobře dostupné. Na trhu je obrovská škála takových to zařízení, každé má jiné parametry a je primárně produkováno na určitý segment využití. Dnes již skoro každý vestavěný systém má podporu napříč mnoha operačními systémy, dokonce jsou pro ně vyvíjeny platformy přímo na míru. Většina těchto vytvořených operačních systémů je založena na Linuxovém jádře a tím přináší velké množství využití napříč technologiemi například web-server, multimediální centrum v domácnosti, ale také pro realizaci v automatizaci atd.
Vestavěné systémy jsou primárně vyvíjeny pro konkrétní aplikace a následně nasazo-vány v obtížných podmínkách, jako jsou nestálá teplota, velké výkyvy teploty, vibrace a mnoho dalších. Prakticky v každém domácím spotřebiči nalezneme pro jeho obsluhu jedinečný vestavěný systém, který byl přímo vyvíjen pro jeho funkci. V případě této diplomové práce bude využíváno vestavěných systémů, které mají univerzální uplat-nění a lze na nich realizovat testování pro konkrétní aplikace. Mezi takovéto systémy patří například RaspberryPi, BeagleBone Black, Cubieboard, UP, BananaPi, Arduino a další. Jednotlivé systémy budou popsány v dalších kapitolách.
2.1
Parametry vestavěných systémů
Každý vestavěný systém má jiné parametry. Pro účely softwarové ústředny je potřeba dostatečná síťová konektivita, výkonný procesor, dostatečně velká paměť RAM, úlo-žiště pro operační systém a softwarovou ústřednu. Konkrétní parametry záleží na tom, jak velkou provozní zátěž požadujeme od tohoto systému. Nejvíce nás bude limitovat výkon procesoru, jelikož pro jeden uskutečněný hovor je potřeba přenosová rychlost 64 kbit/s, bude dostačující 100 Mbit/s Ethernet. Některé systémy mají i Gigabitový Ethernet, ale pro tuto realizaci nebude potřeba, jelikož procesory ve vestavěných sys-témech nedosahují takového výpočetního výkonu, aby zpracovaly tak velké množství hovorů. Dále je rozhodující způsob napájení a spotřeba. Mnohá zařízení jsou schopna běžet i s velmi malou spotřebou a tím velmi ušetřit provozní náklady.
Jednotlivé systémy budou porovnávány podle následujících parametrů: • Procesor
• Síťové připojení
• Další podporované standardy (USB, HDMI, ...) • Operační paměť RAM
• Napájení, spotřeba systému
V neposlední řadě je potřeba také porovnat výkon v poměru s pořizovací cenou. Tyto řešení softwarové ústředny by měli pomoci malým firmám velmi snadno a za nízké pořizovací náklady realizovat internetové volání a hovory v rámci firmy, bez nutnosti pořizovat nákladné komerční řešení pobočkové ústředny, včetně telefonních přístrojů. Telefonní přístroje mohou být nahrazeny softwarovými klienty v pracovních počítačích, případně aplikacemi v mobilních systémech.
2.2
RaspberryPi 2 Model B
RaspberryPi 2 Model B je již druhá generace těchto vestavěných systémů, oproti první generaci přináší velmi snadnou instalaci operačního systémů, kterou zvládne i běžný uživatel, dále výkonnější procesor řady ARM Cortex – A7 s taktem 900 MHz. Disponuje operační pamětí o velikosti 1GB RAM. Součástí je 100 Mbit/s Ethernet s rozhraním RJ-45, zajišťující síťovou konektivitu. Pro obrazový výstup je zde rozhraní HDMI a následně pro připojení periférii čtyři porty USB 2.0. Na základní desce se nachází 40 GPIO pinů pro využití při programování a realizaci různorodých aplikací. Samozřejmě nechybí audio výstup. Dále vlastní rozhraní pro připojení periférii, například dotykový displej, kamera a další. Jako datové úložiště jsou využívány MicroSD karty, zařízení je vybaveno slotem na MicroSD kartu.
Obrázek 2.1: RaspberryPi 2 Model B – pohled shora.
RaspberryPi 2 patří mezi nejpopulárnější vestavěné systémy. V případě RaspberryPi existuje celá řada komunit a implementací operačních systémů. Mezi podporované OS patří vlastní vyvinutý operační systém Raspbian, dále Ubunta Mate, Snappy Ubuntu, OPNELEC a s touto verzí přichází i podpora Microsoft Windows 10 pro Internet věcí.
Obrázek 2.2: RaspberryPi 2 Model B - spodní strana.
Napájení je realizováno prostřednictvím microUSB konektoru. Zařízení je napájeno 5V a doporučený napájecí proud je minimálně 1A, pro maximální výkon je doporu-čen zdroj o velikosti napájecího proudu 2A. Nesporná výhoda RaspberryPi spočívá v možnosti napájet toto zařízení za pomoci nabíjecího adaptéru běžného mobilního telefonu.
2.3
Banana Pi
Vestavěné systémy pod názvem Banana Pi vznikaly až po RaspberryPi a do jisté míry z něho vychází. Banana Pi vzniká jako vylepšená a upravená verze oproti svému před-chůdci a rozvíjí se konkurence v open source systémech. Každý tento vestavěný systém je součástí open source hardware a je tedy volně dostupný. Mezi jeho výhody oproti RaspberryPi patří zabudovaná tlačítka na základní desce (On/Off, reset), kompatibilita s příslušenstvím pro RaspberryPi (displeje, kamery). Banana Pi je vydáváno v několika verzích podle výbavy a výkonu.
První verzí vestavěného systému byl Banana Pi BPI-M1 Classic, tato verze byla přímou konkurencí první verze systému Raspberry Pi a je již dnes příliš zastaralá, a proto zde o ní nebude zmíněno a v současné době neposkytuje dostatečný výkon. Nové generace vestavěného systému Banana Pi přináší lepší výkon, proto jsou zde uvedeny pouze nové modely.
2.3.1 Banana Pi BPI-M1+
Vylepšená verze původního Banana Pi nese označení BPI-M1+ a přichází s výkon-nějším procesorem, konkrétně řady A20 ARM Cortex A7. Jedná se o dvou jádrový procesor s taktem 1 GHz. Disponuje operační pamětí DDR3 o velikosti 1GB, Gigabi-tový Ethernet, obrazový výstup HDMI, audio Jack, GPIO porty a 2x USB. Dále má integrovaný čip pro bezdrátové připojení Wi-Fi s anténou, ovládací tlačítka systému a slot na MicroSD kartu. Napájení je zde provedeno stejně, tedy přes microUSB.
Obrázek 2.3: Banana Pi BPI-M1+.[2]
Mezi nesporné výhody patří vyšší výkon, možnost připojit zařízení k Wi-Fi, dále je možné připojit pevný disk či optickou mechaniku přes rozhraní SATA, které je inte-grováno přímo na desce. Zařízení je kompatibilní s většinou operačních systémů jako jsou Android, Raspbian, Ubuntu, OpenSUSE, Debian, Bananian a mnoho dalších.
2.3.2 Banana Pi BPI-M2 Quad-core
Nástupcem Banana Pi BPI-M1+ je vylepšená verze M2, která oproti původní verzi nabízí mnohonásobný výpočetní výkon procesoru. Deska je osazená procesorem A31S řady ARM Cortex A7, čtyř jádrový procesor s taktem 1 GHz, který je možné přetakto-vat až na 1,2 GHz. Procesor má cache paměť L1 256 KB a L2 1MB. Oproti předchůdci A20 nabízí téměř dvojnásobný výkon. Oproti M1+ má 4 USB porty a napájet lze zaří-zení opět přes microUSB, nebo napájecím adaptérem 5V DC / 2A. V této verzi chybí možnost připojení přes SATA rozhraní.
Obrázek 2.4: Banana Pi BPI-M2 Quad-core.[3]
2.3.3 Banana Pi BPI-M3 Octa-core
Nejvýkonnější deskou řady Banana Pi je deska BPi-M3 Octa-core, disponuje osmi já-drovým procesorem A83T řady ARM Cortex A7, 512 kB L1 a 1 MB L2 cache pamětí, s taktovací frekvencí až 2 GHz. Na desce je osazeno 2GB DDR3 RAM, gigabitový Ethernet, Wi-Fi modul, Bluetooth 4.0, HDMI, 2x USB, On/Off a reset tlačítko. Oproti ostatním vestavěným systémům tento má integrovaný paměťový modul eMMC o veli-kosti 8 GB, dále podporu SATA rozhraní a MicroSD karet. Napájení lze opět řešit přes microUSB nebo skrz 5V DC konektor.
Obrázek 2.5: Banana Pi BPI-M3 Octa-core.[4]
Systém má podpora většiny operačních systému Linux, včetně Microsoft Windows 10 pro Internet věcí.
2.4
Orange Pi
Po velkém úspěchu „ovocného“ konkurenta RaspberryPi vzniká řada dalších „ovocných“ vestavěných systémů. Jelikož tyto systémy vznikají až po úspěchu jejich předchůdce, odstraňují některé nedostatky původních systémů a přicházejí ve vylepšených varian-tách s větším výkonem. Ve vestavěných systémech Orange Pi je ve většině modelů k dispozici procesor ARM řady A7 od firmy AllWinner technology s typovým označením H3. Tato platforma vzniká a vyrábí se v Číně, konkrétně firmou Shenzhen Xunlong Software CO., Limited.
2.4.1 Orange Pi PC
Tato varianta nabízí čtyřjádrový procesor H3 Cortex-A7 na frekvenci 1,6 GHz, 1 GB DDR3 RAM, 100 MBit/s Ethernet, slot na MicroSD kartu, HDMI konektor a další shodné rozhraní jako má například Raspberry Pi. Nespornou výhodou oproti Raspberry Pi je větší výkon procesoru, on/off tlačítko a samozřejmě cena, která se pohybuje okolo 15-ti US dolarů. Celé zařízení je opět napájeno zdrojem o velikosti 5V/2A.
Obrázek 2.6: Popis rozhraní Orange Pi PC.[5]
Většina systémů je vyvíjena pro použití v domácnosti jako malé web servery, multi-mediální centra k televizím, řídící desky k diskům pro tvorbu NAS a mnoho dalších uplatnění. Proto se velmi často zaměřují na výkon v oblasti videa z možnosti ovládání pomocí infračerveného záření. Většina prvků je kompatibilních s malými dotykovými displeji a za pomocí vhodných softwarů lze zrealizovat téměř jakékoliv zařízení.
2.4.2 Orange Pi One
Na začátku roku 2016 byl představen nový miniaturizovaný model Orange Pi One, který nabízí velice zajímavý výkon a je k dispozici za velmi nízkou cenu. Jako většina modelů Orange Pi i tento model je osazen procesorem AllWinner H3 s architekturou ARM Cortex A7 na frekvenci 1,2 GHz a 512 MB DDR3 RAM. Deska má velmi kom-paktní rozměry, proto není osazena velkým počtem rozhraní. Je zde k dispozici 100 MBit/s Ethernet, HDMI a 1 USB port.
Obrázek 2.7: Popis rozhraní Orange Pi One.[6]
Pro operační systém je k dispozici slot na microSD kartu. Napájení je řešeno přes stan-dardní 5V zdroj. Orange Pi One má podporu napříč různými OS, jako jsou například Android, Ubuntu, Debian a dokonce je kompatibilní s Raspbianem (upravený OS pro Raspberry Pi). Cena se pohybuje okolo 10-ti US dolarů.
2.5
CubieBoard 2
Mezi méně známé vestavěné systémy patří open source platforma CubieBoard, která má již několik vývojových řad svých jednodeskových platforem. CubieBoard je jednou z mála vývojových skupin, zabývajících se možností zřetězit více těchto vestavěných systémů a vytvořit tím větší výkonovou platformu pro provozování náročnějších apli-kací, například webový cloud, webserver a další. Zařízení má procesor AllWinner A20 s frekvencí 912 MHz, 1 GB DDR3 RAM a disponuje 3,4 GB vnitřní paměti typu flash. Pro další rozšíření paměti je k dispozici slot na microSD kartu a konektor SATA pro připojení pevného disku. Síťovou konektivitu zajišťuje 100 MBit/s Ethernet a pod-pora USB Wi-Fi. Obdobně jako všechny vestavěné systémy má i CubieBoard rozhraní HDMI, USB a pro napájení lze využít USB konektor nebo standardní rozhraní pro na-pájení 5V/2A DC. Pro tuto desku je vyvíjen speciální operační systém Cubian, který má linuxové jádro a je postaven na Debianu. Podpora je napříč všemi OS, například Android, Debian, Fedora a další.
2.6
BeagleBone Black
BeagleBone Black je vestavěný systém postavený na architektuře ARM Cortex A8. Výpočetní výkon zajišťuje procesor AM3358 od firmy Texas Instruments na frekvenci 1 GHz. Na desce je paměť typu flash o velikosti 4 GB, paměť RAM o velikosti 512 MB DDR3. Konektivita je velmi podobná jako u všech ostatních desek, čili USB, HDMI, 100 MBit/s Ethernet, který má vlastní řadič. Paměť lze rozšířit pomocí microSD karet.
Obrázek 2.8: Beaglebone Black.[7]
Na zařízení BeagleBone je možné spustit řadu operačních systémů, například Debian, Android, Ubuntu a další. Napájení je realizováno opět pomocí 5V/2A DC. Udávaný odběr zařízení je 210 až 460 mA při 5V. Takto malý odběr umožňuje snížit energe-tické nároky na minimum a pro nepřetržitý provoz velmi výrazně snížit náklady na provoz tohoto systému. Cena uvedeného vestavěného systému se pohybuje okolo 70-ti US dolarů. Oproti konkurenčním systémům je cena vysoká.
2.7
UP
Asi nejzajímavějším a velmi výkonným vestavěným systémem je UP. Již z názvu vyplívá, že se jedná o velký posun v této oblasti. Celý systém vychází z koncepce RaspberryPi a je pouze jeho modifikací. Vestavěný systém UP je teprve na počátku vývoje. Jeho první generace má nespornou výhodu oproti ostatním, má plnohodnotný 64 bitový procesor Intel Atom X5-Z8300 s taktem až 1,86 GHz, cache pamětí 2MB a čtyřmi jádry. Deska je dále osazena 4 porty USB 2.0, HDMI portem, síťovou kartou Gigabit Ethernet a 40 GPIO piny. Vestavěný systém UP je navržen pro nejnáročnější aplikace a je tedy vybaven 1 nebo 2 GB DDR3 RAM na 1600 MHz a vlastní eMMC pamětí o velikosti 16 nebo 32 GB.
Obrázek 2.9: Vestavěný systém UP.[8]
Systém UP lze napájet 5V DC pomocí napájecího konektoru. Bohužel zde není mož-nost napájet prostřednictvím USB jako u předchozích systémů. Výkon a architektura procesoru nám umožní všestranné použití v jakékoliv oblasti. Je zde plná podpora Windows 10, což by mohlo být výhodné pro nasazení v domácnostech. Samozřejmě nechybí podpora operačních systémů s linuxovým jádrem a systému Android.
2.8
Pine A64+
Vestavěný systém Pine je navrhnut jako první 64 bitový systém dostupný za nízkou cenu v rozmezí 15-ti až 20-ti US dolarů podle konfigurace. Ve všech modelech je k dispozici 64 bitový procesor ARM Cortex A53 na frekvenci 1,2 GHz. Verze A64+ má oproti základní verzi lepší síťovou konektivitu, nabízí Gigabitový Ethernet port, 2 x USB, HDMI výstup pro obraz a 1 GB DDR3 RAM. Tato verze má oproti jiným mo-delům vestavěnou 3,7 V baterii, kterou lze dobíjet.
Obrázek 2.10: Pine A64+.[9]
Pine A64 lze napájet přes standardní microUSB konektor 5 V. Udávaná spotřeba vý-robce je 2,5 W. Na napájení tedy postačuje standardní nabíječka mobilního telefonu s výstupním proudem 1 A. Zařízení má prozatím podporu pro Android a Linux, ale s ohledem na stáří této desky se bude podpora různých operačních systému ještě rozvíjet.
2.9
Grandstream UCM 6102
Zařízení od firmy Grandstream není tak úplně vestavěným systémem jako předchozí uvedené systémy. Jedná se přímo o IP ústřednu, která je implementována pro jed-noznačné využití a neumožňuje žádné jiné funkce. Toto zařízení je zde uvedeno pro jeho velmi podobnou výkonnost s vestavěnými systémy jako jsou například Raspberry Pi, Orange Pi a další. Tato ústředna disponuje procesorem řady ARM A8 s frekvencí 1 GHz, 512 MB RAM, 2x Gigabitový Ethernet port a také konektivitu pro připojení analogových telefonů. Ústředna je napájena pomocí 12 V adaptéru a udávaný odběr je 1,5 A. Zařízení je vytvořené pro jednoduchou správu a instalaci, dokáže zároveň fungovat jako DHCP server, web server, na kterém je grafická nadstavba pro správu ústředny a další užitečné nástroje.
Obrázek 2.11: Grandstream UCM 6104 [10]
Na obrázku 2.11 je vyobrazen vylepšený model UCM 6104, který oproti modelu UCM 6102 nabízí větší počet portů pro připojení klasických analogových telefonů, větší výkon a tím umožňuje více současných volání. Základní model UCM 6102 by měl dle údajů výrobce zvládnou obsloužit 30 současných hovorů.
2.10
Přehled vestavěných systémů
Vestavěných systémů je mnoho a občas se liší jen nepatrně. Pro účely softwarové ústředny nejsou některé parametry až tak podstatné, a proto je potřeba vybrat pouze parametry, které jsou pro tuto aplikaci stěžejní. Mezi ně patří výkon procesoru, sí-ťová konektivita a operační paměť. Případně možnosti datového úložiště pro software ústředny, ale zde postačuje pro tyto účely rychlost SD karty. Je však nutné vzít v úvahu, že pro reálné a dlouhodobé nasazení není SD karta vhodné paměťové médium. Při tes-tování nedojde ke zkreslení výsledků, ale pro dlouhodobý běh systému je nutné zvolit spolehlivější paměťové médium než je právě SD karta. Přehled jednotlivých důležitých parametrů vestavěných systémů je uveden v tabulce 2.1.
Tabulka 2.1: Přehled vybraných parametrů vestavěných systémů.
Vestavěný
systém Procesor Frekvence RAM
Síťová konektivita Napájecí rozhraní Cena RaspberryPi 2 Model B BCM2836 0,9 GHz 1 GB DDR3 100 MBit/s Ethernet 5V/2A DC 39 $ BPI-M1+ A20 Cortex -A7 1 GHz 1 GB DDR3 1 GBit/s Ethernet, Wi-Fi 5V/2A DC 40 $ BPI-M2 A31S Cortex-A7 1 GHz 1 GB DDR3 1 GBit/s Ethernet, Wi-Fi 5V/2A DC 55 $ BPI-M3 A83T Cortex-A7 2 GHz 2 GB DDR3 1 GBit/s Ethernet, Wi-Fi 5V/2A DC 78 $ Orange Pi PC H3 Cortex-A7 1,6 GHz 1 GB DDR3 100 MBit/s Ethernet 5V/2A DC 15 $ Orange Pi One H3 Cortex-A7 1,2 GHz 512 MB DDR3 100 MBit/s Ethernet 5V/2A DC 10 $ CubieBoard 2 AM3358 ARM A8 1 GHz 512 MB DDR3 100 MBit/s Ethernet 5V/2A DC 70 $ UP Intel Atom X5-Z8300 1,86 GHz 1 GB DDR3 1 Gbit/s Ethernet 5V/2A DC 99 $ PINE A64+ 64 bit ARM A53 1,2 GHz 1 GB DDR3 1 Gbit/s Ethernet 5V/1A DC 19 $ Grandstream UCM 6102 ARM A8 1 GHz 512 MB DDR3 2x 1 Gbit/s Ethernet, 2x FXO, 2x FXS 12V/1,5A DC 399 $
3
Voice over Internet Protocol (VoIP)
V rámci rozvoje internetu a datových sítí se začali vytvářet nové možnosti přenosu telefonních hovorů prostřednictvím takto nově vznikajících sítí. Hlavním cílem bylo umožnit přechod s okruhových telefonních sítí do sítí paketově orientovaných. Tato problematika se zaměřuje na přenos hlasových dat prostřednictvím IP sítě - Voice over Internet Protocol (VoIP). Celý přenos je rozdělen do dvou částí, část signalizační a část přenosu digitalizovaného hlasu. Pro signalizaci jsou využívány nejčastěji protokoly SIP a H.323. K přenosu digitalizovaného hlasu je využíván Real-time Transport Protocol (RTP).
V této diplomové práci bude zmíněn pouze protokol SIP a RTP, které budou využity pro analýzu a testy vestavěných systémů. Protokol H.323 vznikl jako doporučení ITU-T, který definuje signalizaci telefonních hovorů přes libovolnou paketovou síť.
3.1
Session Initalization Protocol (SIP)
Protokol SIP je standardizován skupinou IETF jako RFC 3261 a mnoho dalších dopo-ručení. V doporučení RFC 3261 jsou základní popisy a definice protokolu SIP. Protokol SIP je textově orientován a je přenášen v textové formě. SIP lze přenášet pomocí UDP, TCP případně zabezpečeně pomocí TLS. SIP vychází ze standardů HTTP a využívá model komunikace klient-server.
Součástí SIP protokolu je takzvaný Session Description Protocol (SDP), který de-finuje jakými způsoby je možná komunikace jednotlivých zařízení. V praxi je pomocí tohoto protokolu popisováno s jakými kodeky je schopné zařízení, se kterým komuni-kujeme spolupracovat. Nejčastěji bývá používán kodek G.711, případně G.722.
Struktura SIP protokolu je tvořena textově a lze při zachycení paketu přímo vyčíst přenášené informace. Hlavička obsahuje:
I N V I T E sip :[ s e r v i c e ] @ [ r e m o t e _ i p ]:[ r e m o t e _ p o r t ] SIP / 2 . 0 Via : SIP / 2 . 0 / [ t r a n s p o r t ] [ l o c a l _ i p ]:[ l o c a l _ p o r t ]; b r a n c h =[ b r a n c h ] F r o m : s i p p < sip : s i p p @ [ l o c a l _ i p ]:[ l o c a l _ p o r t ] >; tag =[ c a l l _ n u m b e r ] To : sut < sip :[ s e r v i c e ] @ [ r e m o t e _ i p ]:[ r e m o t e _ p o r t ] > Call - ID : [ c a l l _ i d ] Content - T y p e : a p p l i c a t i o n / sdp Content - L e n g t h : [ len ] C S e q : 1 I N V I T E C o n t a c t : sip : s i p p @ [ l o c a l _ i p ]:[ l o c a l _ p o r t ] Max - F o r w a r d s : 70 v =0 o = u s e r 1 5 3 6 5 5 7 6 5 2 3 5 3 6 8 7 6 3 7 IN IP [ l o c a l _ i p _ t y p e ] [ l o c a l _ i p ] s = S J p h o n e c = IN IP [ l o c a l _ i p _ t y p e ] [ l o c a l _ i p ] t =0 0 m = a u d i o [ a u t o _ m e d i a _ p o r t ] RTP / AVP 0 97 8 18 a = r t p m a p :0 P C M U / 8 0 0 0 a = r t p m a p :97 S P E E X / 8 0 0 0 a = r t p m a p :8 P C M A / 8 0 0 0 a = r t p m a p :18 G 7 2 9 / 8 0 0 0
Jak je vidět na ukázce 3.1 SIP zprávy INVITE, zpráva musí obsahovat od koho je iniciováno spojení (From), komu chceme volat (To), identifikátor spojení Call-ID, následně kontakt na klienta, Via určuje kde byl vytvořen požadavek a kam má být zaslána odpověď. Následně maximální počet přesměrování. Ve spodní částí je uveden popis pomocí SDP protokolu, kde je seznam podporovaných kodeků, které jsou nabí-zeny druhé volané straně a mezi nimi se vybere jeden společný, v případě že nemají ani jeden společný kodek dojde k ukončení spojení.
V SIP protokolu se posílané zprávy rozdělují na metody a odpovědní kódy. Mezi metody patří zprávy typu REGISTER, INVITE, ACK, CANCEL, BYE a OPTIONS. Metoda REGISTER se používá pro přihlášení klienta k ústředně, INVITE slouží k zahájení signalizace hovoru, ACK pro potvrzování, CANCEL pro zrušení spojení v případě, kdy účastník na druhé straně neodpovídá. Metoda BYE ukončuje spojení, jedná se analogicky o stejný proces, kdy dojde k ukončení hovoru zavěšením sluchátka telefonního aparátu. Metodou OPTIONS můžeme přenášet informace o stavu serverů a jejich přístupnosti. V návazných doporučeních, která byla vydávána jako úpravy v protokolu SIP jsou uvedeny další metody, které ale nejsou pro účely této práce pod-statné. Druhým typem zpráv jsou odpovědní třímístné číselné kódy, které následují jako odpovědi na metody. Odpovědi začínající 1 jsou dočasné odpovědi, které mají pouze informovat protistranu o přijetí požadavku a čekají na další odpověď. Kódy zažínající 2 značí úspěšné splnění metody, odpovědi zahájené číslem 3 znamenají informaci o pře-směrování, odpovědi začínající 4 značí chybu na straně klienta například neautorizace, zakázaní přístupu a další. Odpovědi začínající od čísla 5 značí chybu serveru, například nedostupnost serveru, jako poslední jsou kódy od čísla 6 a ty značí chybu obecného charakteru.
Na obrázku 3.1 je znázorněn průběh signalizace při realizaci hovoru prostřednictvím protokolu SIP. Nejdříve je odeslána zpráva INVITE, nebo-li pozvání k hovoru. Ná-sledně ústředna odpoví dočasnou zprávou 100 Trying. Protější klient odpoví zprávou 180 Ringing. V tuto chvíli dochází k vyzvánění volaného. V okamžiku přijetí hovoru volaného dojde k potvrzení zprávou 200 OK. Volající potvrdí metodou ACK a následně je již přenos médií. Médiem může být hlas případně video. Po ukončení pošle strana, která ukončuje spojení BYE, poté již dojde pouze k odpovědi 200 OK a tím celé spojení končí.
SIP má ve své definici různé typy serverů:
• Redirect server – server pouze odpovídá zprávou 301 nebo 302 o přesměrování a odkáže na novou adresu, kde by se měl nacházet volaný
• Stateless proxy – server pouze přeposílá zprávy na základě DNS záznamů a dalších záznamů v databázích, nepamatují si co kam posílají
• Statefull proxy – sever, přeposílá zprávy, ale má vlastní paměť a udržuje si stavy spojení, může zde probíhat i směrování hovorů
• Registrar – server, který za pomocí zpráv REGISTER registruje účastníky v síti
• B2BUA – Back to Back User Agent, tento typ se chová jako ústředna na jedné straně hovor ukončuje a na druhé vytváří nové spojení, lze takto měnit kodeky mezi zařízeními, která si nerozumí navzájem.
• User Agent - koncový bod, může být v režimu Client (UAC), tedy generuje SIP zprávy (např. INVITE a další) a nebo v režimu Server (UAS) - tedy odpovídá na příchozí SIP zprávy, každý koncový bod musí podporovat oba režimy, záleží pouze na směru volání a podle toho volí konkrétní režim
Pro přenos médií je využíván protokol RTP, případně jeho šifrovaná varianta SRTP. Komunikace pomocí protokolu RTP probíhá vždy na sudém portu a na následují-cím lichém portu je protokol Real-time Transport Control Protocol (RTCP), který v pravidelných intervalech posílá informaci o kvalitě přenosu. Přenos médií může být realizován napřímo mezi koncovými zařízeními a nebo prostřednictvím RTP proxy. V případě RTP proxy dochází k zatížení SIP serveru. Zpravidla prochází stream skrz něj a je nutné počítat s větší zátěží serveru. Varianta s nepřímými médii je často využívána operátory pro možnost odposlechu hovorů. RTP nemusí vždy fungovat v každé ob-lasti, časté důvody nefunkčnosti jsou způsobeny špatně nakonfigurovaným firewallem, případně problémy s NAT.
3.2
Real-time Transport Protocol (RTP)
V paketových sítích je nejčastěji pro přenos hlasu používán Real-time Transport Pro-tocol (RTP), který umožňuje přenos médii prostřednictvím paketových sítí. Protokol je uzpůsoben tak, aby docházelo k co nejmenším zpožděním a výpadkům přenášeného audio, případně videosignálu. Tento protokol byl vydán již v roce 1996 jako RFC 1889 a později byl nahrazen RFC 3550.
Přenos médií přes paketové sítě je velmi problematický a musí brát v úvahu veš-keré možné zpoždění vzniklé zabalením paketu, zpoždění přenosu skrz IP síť a nakonec zpoždění v bufferu, který využívá RTP. RTP ve své definici využívá tzv. jitter bufferu, který shromažďuje pakety s přenášenými médii a přehrává je se zpožděním za účelem vyrovnání možného zpoždění vlivem různých přenosových cest napříč IP sítí. Do celko-vého zpoždění přenosu se započítává doba šíření sítí, zpoždění v bufferu a čas zabalení paketu. Celková doba zpoždění dle ITU by neměla přesáhnout 150 ms. V případě vel-kého zpoždění nebude pro komunikující uživatele telefonní hovor srozumitelný a bude docházet k nedorozumění uživatelů.
Pro garanci kvalitního spojení je nutné aplikovat v celé sítí parametry QoS. Pro přenos může být využívána celá řada kodeků. Mezi nejvyužívanější kodeky patří ko-dek G.711, G.729, GSM a další. Koko-dek G.711 zahrnuje vlastnosti A-zákona a µ-zákona, který definovala ITU-T. A-zákon je používán v Evropě a µ-zákon pro Ameriku a Japon-sko. Kodeky lze klasifikovat z hlediska potřebné šířky pásma pro přenos a podle kvality komprese a podle MOS, nebo-li kvality přenosu z hlediska subjektivního hodnocení uživatele.
Obrázek 3.2: Struktura RTP paketu.[13]
Paket RTP streamu je doplněn o hlavičku RTP a RTP data. V hlavičce jsou in-formace o typu dat, číslo vyslané sequence, časová stopa dat a další. Protokol RTP je vždy vysílán na sudém portu a je přenášen pomocí UDP. Součástí doporučení je Real-time Transport Control Protocol (RTCP), který vysílá na portu o 1 vyšším než RTP. Při přenosu je prostřednictvím RTCP vysílána jednou za 5 až 10 s informace o kvalitě streamu.
4
Softwarové ústředny
Softwarové ústředny nahrazují komplikované ústředny pro pevné volání v sítí a po-skytují volání skrz IP síť, zároveň umožňují propojit systémy VoIP s Public Switched Telephone Network (PSTN).Hlavním úkolem softwarové ústředny je přenášet a řídit signalizaci telefonního provozu. Spojovací pole je realizováno softwarově. Softwarová ústředna má tu výhodu, že může být provozována takřka na libovolné platformě. Tyto ústředny přináší řadu výhod oproti klasickým ústřednám. Mohou být doplněny o mnoho přídavných modulů, které pomáhají v komunikaci volajících, například IVR systém.
Většina softwarových ústředen je postavena na protokolu SIP. V případě komplex-ního VoIP systému od firmy CISCO je komunikace mezi prvky většinou řízena pomocí protokolu Skinny Call Control Protocol (SCCP) - proprietární řešení signalizace firmy CISCO, samozřejmě je zde i podpora SIP. Nejdůležitější částí ústředny je signalizace, která určuje veškerý provoz. Protokol SIP byl popsán v předcházející kapitole. Existuje mnoho typů ústředen, ale pro potřebu této diplomové práce se zaměřím pouze na open source řešení ústředny pod názvem Asterisk.
4.1
Asterisk
Asterisk je software, který dokáže implementovat veškeré funkce pobočkové ústředny na libovolném serveru a mnoho dalších funkcí. Vývoj Asterisku začal v roce 1999, kdy byl zveřejněn počáteční kód. Posléze se začal velmi rozvíjet a nyní je vyvíjen uživatelskou komunitou a sponzorován firmou Digium. Tato platforma je šířena volně pod licencí GNU General Public License (GNU). Asterisk je kompatibilní s libovolnou distribucí Linux či Unix a stačí pro jeho funkci klasický počítač nebo vestavěný systémem. Systém dokáže vytvářet několik funkcí najednou a zajistit kompatibilitu napříč technologiemi jako například PSTN, SIP a další. Jedná se o nejpoužívanější softwarovou ústřednu a existuje řada modifikací a realizací pro nasazení v reálném prostředí. Tento software nám dokáže nahradit pobočkovou ústřednu, hlasovou schránku, konference (hlasové i obrazové), interaktivního hlasového průvodce tzv. IVR a mnoho dalších. Zároveň lze připojit tuto softwarovou ústřednu i do stávající klasické telefonní sítě (PSTN). V současné době je využíván ve více než 170 zemích světa více jak tisíci uživateli.[14]
Pro účely této diplomové práce bude využita softwarová ústředna Asterisk v základ-ním režimu, kdy řídí a spojuje signalizaci protokolu SIP mezi dvěma zařízezáklad-ními v sítí. Při výkonnostních testech bude Asterisk zároveň plnit úkol media serveru pro obsluhu hlasových dat pomocí protokolu RTP.
4.1.1 Základní konfigurace
Základní konfigurace softwarové ústředny se provádí pomocí souborů uložených v ad-resáři /etc/Asterisk. Při instalaci se v tomto adad-resáři vytvoří mnoho konfiguračních souborů, které nejsou pro funkci protokolu SIP potřeba. Proto je nejdříve nutné celý adresář smazat a vytvořit jen soubory, které budou využity. Při konfiguraci je nutné za-čít v souboru asterisk.conf, kde nastavujeme pro Asterisk důležité proměnné, které ukazují v jakých adresářích se nachází konfigurační soubory, moduly, soubory se zvu-kem, databáze a prostor pro soubory logu.
[ d i r e c t o r i e s ]
a s t e t c d i r = > / etc / a s t e r i s k ; a d r e s á ř s k o n f i g u r a č n í mi s o u b o r y a s t m o d d i r = > / usr / lib / a s t e r i s k / m o d u l e s ; a d r e s á ř s m o d u l y
a s t v a r l i b d i r = > / var / lib / a s t e r i s k ; a d r e s á ř pro vyu ž í van é k n i h o v n y a s t d a t a d i r = > / var / lib / a s t e r i s k ; a d r e s á ř pro ulo ž en í z v u k o v ý ch n a h r á vek a s t d b d i r = > / var / lib / a s t e r i s k ; a d r e s á ř pro ulo ž en í v n i t ř n í d a t a b á ze A s t e r i s k u a s t r u n d i r = > / var / run / a s t e r i s k ; a d r e s á ř , kde j s o u ulo ž eny i n f o r m a c e o p r o c e s e c h a s t l o g d i r = > / var / log / a s t e r i s k ; a d r e s á ř s log s o u b o r e m
Ukázka kódu 4.1: Základní konfigurace souboru asterisk.conf
Dalším důležitým konfiguračním souborem je soubor sip.conf, ve kterém definu-jeme veškeré parametry souvisejí s protokolem SIP. Celý soubor je rozdělen do sekcí, v první sekci se nastavují parametry globálního charakteru aplikované na celý systém. V dalších částech konfigurujeme jednotlivé uživatele (telefony) a případně nakonfigu-rujeme odchozí trunk.
[ g e n e r a l ] c o n t e x t = l o c a l d t m f m o d e = r f c 2 8 3 3 d i s a l l o w = all a l l o w = a l a w t r a n s p o r t = udp e n c r y p t i o n = no nat = no d i r e c t m e d i a = n o n a t a l w a y s a u t h r e j e c t = yes [ 1 0 0 1 ] t y p e = f r i e n d h o s t = d y n a m i c u s e r n a m e = 1 0 0 1 u s e r i d = t e l e f o n 1 1 0 0 1 s e c r e t = S i l n e h e s l o 1 2 3
Ukázka kódu 4.2: Konfigurační soubor sip.conf
Na ukázce kódu 4.2 je základní podoba konfigurace SIP protokolu. Nejdříve nadefi-nujeme jakým plánem se bude konfigurace řídit, následně povolíme tónovou volbu. V případě správného nastavení kodeků nejdříve všechny zakážeme a následně povolíme pouze ty, které budou použity.Následně je nutné zvolit transportní protokol. V ukázce není používáno žádné šifrování a jelikož je uvažována pouze lokální síť podpora NAT je také vypnutá. Jednotlivé sekce jsou odděleny názvy sekcí v hranatých závorkách. V kódu 4.2 je vidět konfigurace klienta 1001, který se bude přihlašovat k ústředně protokolem SIP. V této části nastavujeme vlastnosti a možnosti přihlášení k ústředně, konkrétně možnost přihlášení z libovolné IP adresy, přihlašovací jméno, heslo, číslo účastníka a jeho jméno zobrazované protější straně.
Poslední soubor, který je nutný pro základní spuštění Asterisku s podporou SIP pro-tokolu je extension.conf. Tento soubor má za úkol definovat jednotlivé kontexty pro volání a příchozí hovory, které jsou nadefinovány v souboru sip.conf. V našem pří-padě je potřeba definovat kontext typu local, který vyplývá z konfiguračního souboru na obrázku 4.2. Na obrázku 4.3 je část konfiguračního souboru extensions.conf. V
kontextu local jsou nakonfigurované jednotlivé akce pro konkrétní telefonní čísla. Zápis jde obecně zjednodušit zástupnými znaky například v případě, kdy je potřeba specifi-kovat povolené formáty telefonních čísel pro odchozí volání.Zápis se provádí ve formátu exten =>číslo, priorita, příkaz(parametry ..). Při zadávání priority lze použít parametr n, který znamená následující prioritu. Z kódu 4.3 vyplývá, že při vytočení čísla 1001 dojde k vyzvánění na uživatele 1001, po 30 vteřinách, kdy nedojde ke spojení se pře-hraje hláška o nedostupnosti a ukončí se spojení. Naopak při volbě čísla 200 se ihned hovor spojí a přehraje do sluchátka (RTP stream) předen nahraný zvukový záznam. U čísla 100 je podobný příklad, s tím rozdílem, že se uživateli přehraje echo režim a má možnost mluvit a následně si přehrát mluvený záznam pro kontrolu správné konfigu-race. [ g e n e r a l ] [ l o c a l ] ; SIP u ž i v a t e l é e x t e n = > 1001 ,1 , D i a l ( SIP / 1 0 0 1 , 3 0 ) e x t e n = > 1001 , n , P l a y b a c k ( vm - n o b o d y a v a i l ) e x t e n = > 1001 , n , H a n g u p () e x t e n = > 200 ,1 , A n s w e r () e x t e n = > 200 , n , P l a y b a c k ( tt - monty - k n i g h t s ) e x t e n = > 200 , n , H a n g u p () e x t e n = > 100 ,1 , A n s w e r () e x t e n = > 100 , n , P l a y b a c k ( w e l c o m e ) e x t e n = > 100 , n , P l a y b a c k ( demo - e c h o t e s t ) e x t e n = > 100 , n , E c h o () e x t e n = > 100 , n , P l a y b a c k ( demo - e c h o d o n e ) e x t e n = > 100 , n , P l a y b a c k ( vm - g o o d b y e )
Ukázka kódu 4.3: Konfigurační soubor extensions.conf
Pro spuštění konzole Asterisku je zapotřebí oprávnění správce a následně použití příkazu asterisk -rvv, čím více je zadáno písmen v, tím je během správy ústředny vypisováno více detailů o chodu ústředny. Více informací ohledně využití Asterisk kon-zole je zmíněno v příloze této práce, případně v dokumentaci Asterisku. [15]
5
Testovací software
V rámci testování protokolu SIP a výkonnosti ústředny existuje celá řada programů, která se na tuto problematiku zaměřuje. Z pohledu jednoduchosti ovládání a jednodu-ché implementace bude v této práci zmíněn pouze software, který je schopen spolu-pracovat napříč platformami a zároveň lze nastavit veškeré požadované parametry pro výkonnostní testy. Výběr těchto softwarů byl na základě možnosti použití a licenčních podmínek. Pro simulaci SIP provozu bude využit analyzační nástroj SIPp, zároven při simulaci bude generován souvislý datový tok pomocí programu iPerf. Pro ověření a získání přehledu o přenosu médii bude využit pro analýzu již získaných výsledků s programu SIPp program SIP Tester od společnsoti StarTrinity.
5.1
SIPp
SIPp je výkonný testovací nástroj pro ověření SIP protokolu. V základním režimu obsahuje předpřipravené testovací scénáře pro simulaci klienta i serveru. Nástroj vytváří pomocí metod INVITE a BYE hovory a je schopen vytvořit více hovorů zároveň a umožnit i podporu přenosu médií. Testovací scénáře se dají vytvářet pomocí XML souborů, které umožňují libovolné konfigurace pro testování výkonnosti. Zároveň za pomoci CSV souboru lze vkládat doplňující data pro simulaci, jako například uživatele. Program je šířen pod licencí GNU a je podporována komunitou od firmy HP. V současné době byla vydána verze SIPp 3.5.1. Tato verze bude použita v praktické části této práce. SIPp je dostupný pro operační systémy Linux a v případě Windows, lze program spouštět v prostředí Cygwin. Program má jednoduché ovládání a přehledné konfigu-rační soubory. Při vývoji byl využit programovací jazyk C++ a tím získal velkou oblibu mezi uživatelskou komunitou a je možné si upravit a vylepšit zdrojové kódy. SIPp může být použit pro testování SIP Proxy, B2BUA, SIP media serverů, SIP gateway a SIP pobočkových ústředen. Tímto softwarem lze velmi snadno emulovat tisíce volání skrz testovaný SIP systém. SIPp umožňuje podporu TLS, PCAP play a SCTP.[16]
Na obrázku 5.1 je vidět ovládací prostředí po spuštění testovacího scénáře SIP pro-vozu. Ve výpisu v příkazové řádce jsou viděny aktuálně běžící hovory, počet usku-tečněných a aktivních hovorů, statistiky odeslaných RTP paketů a další. Zároveň je zobrazen průběh SIP zpráv dle testovacího scénáře, který je navržen pomocí XML sou-boru. Dále je možné v průběhu měnit počet souběžných hovorů a tím zvyšovat nároky na výpočetní výkon ústředny.
Výsledky simulace jsou vyobrazeny na obrázku 5.2. Obsahuje shrnutí statistických dat, čas simulace, počet vytvořených volání, počet úspěšných a neúspěšných volání, délku hovoru a další parametry.
Obrázek 5.1: Průběh testování SIPp - průběžné statistiky.
Obrázek 5.2: Výsledky simulace SIPp.
5.1.1 Instalace SIPp
Před instalací nástroje SIPp je zapotřebí nejprve nainstalovat podpůrné knihovny, které jsou potřeba pro správnou funkci a běh programu. Následující postup instalace je uve-den pro linuxovou distribuci Debian verze 8. Nejprve je potřeba doinstalovat kompilátor jazyk C, ncurses knihovnu a knihovny pro podporu médií libpcap a libnet.
# apt - get i n s t a l l b u i l d - e s s e n t i a l # apt - get i n s t a l l l i b n c u r s e s 5 - dev # apt - get i n s t a l l libpcap - dev # apt - get i n s a t l l libnet - dev
Po doinstalování potřebných knihoven již jen stačí stáhnout nejnovější stabilní verzi programu SIPp. Nyní je nutné pomocí terminálu program zkompilovat. Pro účely této diplomové práce bude postačovat podpora PCAP play, pro přehrávání předehraných nahrávek. SIPp ve výchozí konfiguraci podporuje kodek G.711 A-zákon.
# tar - x v z f sipp - 3 . 5 . 1 . tar . gz # cd sipp - 3 . 5 . 1
# ./ c o n f i g u r e - - with - p c a p # m a k e
Ukázka kódu 5.2: Instalace programu SIPp
5.1.2 Vytvoření testovacích scénářů
Testovací scénáře jsou vytvářeny pomocí XML souborů a následně volány pomocí pří-kazu programu. XML soubor má předem danou strukturu a struktura je velmi podobná struktuře SIP zpráv a tím je uživatelsky snadná na konfiguraci.Dle dokumentace pro-gramu SIPp je možné vytvořit libovolný scénář testování.
S I P p UAC R e m o t e
| ( 1 ) I N V I T E | Zah á jen í vol á n í | - - - >| | ( 2 ) 100 ( o p t i o n a l ) | O d p o v ě ď ú st ř e d n y o p ř i j e t í , v o l i t e l n á p o l o ž ka | < - - - -| | ( 3 ) 180 ( o p t i o n a l ) | Zpr á va od ú st ř e d n y o v y z v á n ě n í v o l a n é ho | < - - - -| | ( 4 ) 200 | Z v e d n u t í hovoru , zpr á va 200 | < - - - -| | ( 5 ) ACK | P o t v r z e n í p ř i j m u h o v o r u d r u h é s t r a n ě . | - - - >| | | | ( 6 ) RTP s e n d (8 s ) | P ř en á š en á m é dia , p ř ehr á n í s o u b o r u 8 s | = = = = = = = = = = = = = = = = = = > | | |
| ( 7 ) BYE | U k o n č en í s p o j e n í - zav ě š en í s l u c h á tka | - - - >|
| ( 8 ) 200 | P o t v r z e n í zav ě š en í | < - - - -|
Obrázek 5.3: Průběh signalizace scénáře SIPp UAC s médii [16]
<? xml v e r s i o n = " 1 . 0 " e n c o d i n g =" ISO - 8 8 5 9 - 1 " ? > <! D O C T Y P E s c e n a r i o S Y S T E M " s i p p . dtd " > < s c e n a r i o n a m e =" UAC w i t h m e d i a " > < s e n d r e t r a n s ="500" > <![ C D A T A [ I N V I T E sip :[ s e r v i c e ] @ [ r e m o t e _ i p ]:[ r e m o t e _ p o r t ] SIP / 2 . 0 Via : SIP / 2 . 0 / [ t r a n s p o r t ] [ l o c a l _ i p ]:[ l o c a l _ p o r t ]; b r a n c h =[ b r a n c h ] F r o m : s i p p < sip : s i p p @ [ l o c a l _ i p ]:[ l o c a l _ p o r t ] >; tag =[ c a l l _ n u m b e r ] To : sut < sip :[ s e r v i c e ] @ [ r e m o t e _ i p ]:[ r e m o t e _ p o r t ] > Call - ID : [ c a l l _ i d ] C S e q : 1 I N V I T E C o n t a c t : sip : s i p p @ [ l o c a l _ i p ]:[ l o c a l _ p o r t ] Max - F o r w a r d s : 70 S u b j e c t : P e r f o r m a n c e T e s t Content - T y p e : a p p l i c a t i o n / sdp Content - L e n g t h : [ len ] . ]] > </ send > < r e c v r e s p o n s e = " 1 0 0 " o p t i o n a l =" t r u e " > </ recv > < r e c v r e s p o n s e = " 1 8 0 " o p t i o n a l =" t r u e " > </ recv >
Na obrázku 5.3 je průběh signalizace SIP protokolu pro scénář s přenosem médií. V ukázce 5.3 konfigurace tohoto scénáře je první část SIP signalizace. Veškeré údaje, které jsou v hranatých závorkách jsou konfigurovatelné a volají se příkazem při spuštění scénáře jako je znázorněno na ukázce 5.4. Parametry, které nejsou volány při spuštění jsou automaticky doplněny výchozími hodnotami. Při vytváření scénáře se zadávají příkazy send a recv, které určují jestli půjde o vyslání zprávy nebo pouze o příjem. Na obrázku 5.4 je znázorněno spuštění scénáře uac pcap. Příkaz zároveň definuje výchozí lokální IP adresu (i), délku jednotlivých volání (d), testovací scénář (sf), číslo volaného (s), IP adresu vzdáleného hosta (ústředny) a maximální počet souběžných volání (l).
#./ s i p p - t r a c e _ e r r - i 1 9 2 . 1 6 8 . 1 . 8 - sf u a c _ p c a p . xml - d 100 - s 111 1 9 2 . 1 6 8 . 1 . 1 3 - l 1 0 0 0
Ukázka kódu 5.4: Příkaz pro spuštění SIPp
Při spuštěném scénáři lze pomocí vybraných kláves řídit aktuální vytížení a zvy-šovat případně snižovat počet hovorů. Dále je možné přepínat mezi jednotlivými ob-razovkami, které zobrazují konkrétní výsledky. Více o možné konfiguraci lze najít v dokumentaci výrobce.[16]
5.2
iPerf
iPerf je program pro analýzu síťových transportních protokolů TCP a UDP. Prostřed-nictvím tohoto programu lze analyzovat maximální možnou šířku pásma pro přenos mezi dvěma uzly v síti. Program funguje na principu klient - server a je tedy nutné aby byl spuštěn na obou koncových bodech měřené sítě. V našem případě bude zde spuštěn na ústředně v režimu server, tedy bude pouze odpovídat na příchozí poža-davky. Na jednom z notebooků bude spuštěn v módu klient a bude tedy generovat zátěž pro ústřednu. Hlavním důvodem implementace v těchto testech je vytvoření reál-ného prostředí, kdy ústředna bude vystavena okolnímu síťovému provozu a tedy bude muset reagovat i na jiné požadavky než jen požadavky protokolu SIP. iPerf podporuje většinu platforem, tedy Linux, Mac OS X, MS Windows, Android, iOS a další. Pro základní spuštění stačí pouze dva jednoduché příkazy:
# i p e r f - s // s e r v e r
# i p e r f - c a d r e s a _ s e r v e r u - i 1 - t 20 // k l i e n t
Ukázka kódu 5.5: Spuštění programu iPerf
Příkazem s parametrem c nastavíme do módu klient, zadáme adresu serveru a in-terval, jak často se budou vypisovat statistiky a dobu běhu programu, v tomto případě výpis každou vteřinu po dobu 20 vteřin. Samozřejmě je možné nastavit mnoho dalších parametrů, jako například protokol UDP, TCP, velikost TCP okna, komunikační port, parametr TTL a další.
Obrázek 5.4: Ukázka výpisu programu iPerf
5.3
SIP Tester
Testovací software od společnosti StarTrinity umožňuje komplexní sledování statistik o jednotlivých volání včetně analýzy zpoždění paketů. Oproti open-source platformě SIPp tento nástroj je schopen analyzovat veškerá zpoždění přenášených médií a tím rozpoznat kvalitu jednotlivých volání. V základním režimu lze za pomocí nástrojů ana-lyzovat REGISTER zprávy a následně vytvářet odchozí volání a odpovídat na příchozí volání. Nástroj pracuje na podobném principu jako SIPp. Je tedy zapotřebí připravit testovací scénáře v XML souborech. Výhodou oproti SIPp je možnost práce v grafic-kém režimu a zobrazování získaných výsledků v přehledných tabulkách a grafech. Tento nástroj je pro výkonnostní testy velkých systému a tvůrci uvádějí, možnost vytvářet až 8000 současných hovorů pro jeden server v konfiguraci čtyřjádrového procesoru Intel i7-3700. Software je dostupný freeware v omezené licenci pro maximálně 50 současných hovorů a maximálně 150 vygenerovaných SIP instancí. Tato omezená licence by měla být dostačující pro prokázání získaných výsledků z testů v programu SIPp. Program je dostupný pouze pro platformu MS Windows. [17]
Obrázek 5.5: Ukázka výpisu současných hovorů v programu SIP Tester - přehled RTP
Nastavení generování odchozích volání probíhá zjednodušeně za pomocí grafického prostředí znázorněném na obrázku 5.6. Volání je generováno jedním uživatelem (1002)
a volá v rozmezí 1015 až 1045. V nastavení je dále možné upravit podporované kodeky, případně zakázat média úplně, délku hovoru a také je možné nahrávat záznam hovorů.
6
Metodika testování
Testování vestavěných systémů bude realizováno v několika fázích a vyhodnocováno na základě získaných statistických dat simulací a testů při zatížení softwarové ústředny. Ústředna bude nainstalována ve stejné konfiguraci, aby byly výsledky co nejvíce porov-natelné. Jednotlivé testy budou opakovány pro dosažení přesnějších výsledků a odstra-nění náhodných veličin. Testy budou realizovány v různých scénářích, aby bylo možné komplexně porovnat výkonnostní parametry vestavěného systému. Testy proběhnou na dvou noteboocích, které budou simulovat telefonní provoz na protokolu SIP a přená-šet média pomocí protokolu RTP. Celé simulace budou vytvářeny pomocí simulačního programu SIPp. Na jedné straně bude notebook v režimu UAC, kdy bude vytvářet a generovat volání a druhý notebook v režimu UAS, který bude na volání odpovídat.
6.1
Registrace telefonních přístrojů
Prvním testovacím scénářem bude zaregistrování k telefonní ústředně. Nejdříve dojde k vygenerování zprávy REGISTER a následně ústředna odpoví metodou 401 Unau-thorized. Po obdržení se opět vygeneruje zpráva REGISTER, ale je doplněna o hash v kterém je spočtené přihlašovací jméno a heslo a autorizační kód, který byl obdržen od ústředny ve zprávě 401. |(1) REGISTER | |--->| |(2) 100 (optional) | |<---| |(3) 401 Unauthorized | |<---| |(4) REGISTER | |--->| |(5) 200 OK | |<---|
Obrázek 6.1: Průběh signalizačních zpráv registrace telefonních přístrojů k ústředně
Celý průběh scénáře je naznačen na schématu 6.1. Jak je patrné ze schématu simu-lace pro tyto testy bude postačovat jeden notebook a ústředna. Testy budou probíhat na počátečním generování 5 zpráv za vteřinu a každé 2 vteřiny dojde k navýšení o 2 zprávy za vteřinu. Test bude probíhat do té doby než dojde k zablokování ústředny a přestane odpovídat na výzvy k registraci. K ústředně se bude přihlašovat 15 uži-vatelů. Uživatele bude tvořit jedna instance scénáře SIPp a údaje budou získávány z předkonfigurovaného CSV souboru. Testovací scénář je součástí příloh této práce.
Obrázek 6.2: Schéma zapojení testu registrace telefonních přístrojů
Schéma zapojení registrace telefonních přístrojů je znázorněno na obrázku 6.2. Na notebooku, který bude generovat žádosti o registraci bude spuštěn SIPp s vlastním scénářem pro registraci k ústředně. Veškeré potřebné soubory jsou přílohou této práce. Pro spuštění testu je nutné spustit SIPp s následujícími parametry uvedených v pří-kazu 6.1. Nejdříve je nutné zadefinovat lokální IP adresu pro odesílání žádostí, následně zvolit scénář, CSV soubor s parametry uživatelů, adresu ústředny. Dle požadovaných parametrů počet volání za vteřinu, navýšení počtu volání za vteřinu a nakonec zvolit způsob výpisu statistik. Statistiky budou uloženy do souborů pod názvem testovacího scénáře a PID procesu, pod kterým jsou spuštěny.
#./ s i p p - i 1 9 2 . 1 6 8 . 1 . 8 - sf reg . xml - inf u s e r _ U A C . csv 1 9 2 . 1 6 8 . 1 . 1 3 - r 5 - r a t e _ i n c r e a s e 2 - fd 2 s - l 1 0 0 0 - t r a c e _ s t a t - t r a c e _ c o u n t s - t r a c e _ s c r e e n - t r a c e _ r t t
Ukázka kódu 6.1: Spuštění testovacího scénáře reg.xml
6.2
Simulace hovorů včetně přenosu hlasu
Simulace hovoru bude realizována za pomoci dvou instancí SIPp. Každá instance po-běží na jiném zařízení. V jednom případě se bude jednat o režim UAC, tedy generátor vyzývacích zpráv INVITE a v druhém případě bude klient v režimu UAS, tedy pouze odpovídat na příchozí výzvy. Veškerý provoz bude překládán v ústředně a bude tím za-tížena. Součástí přenosu po spojení hovoru bude přehrávání předem nahraného zvuku, který bude sloužit pro účely zatížení RTP streamem. Signalizační schéma průběhu si-mulace je znázorněno na obrázku 6.3. Nejdříve je nutné se vůči ústředně autorizovat, tedy musí se poslat zpráva INVITE dvakrát, jednou doplněná o přihlašovací údaje. Následně odpoví ústředna zprávou Trying a čeká na "zvednutí sluchátka"na protější straně. Zde dojde simulačním programem k odpovědi 200 OK a tím je vytvořeno spo-jení, poté ještě volající strana potvrdí zprávou ACK. Nyní je nastavena pauza na 90 vteřin a tím dojde k odeslání předem nahraných nahrávek a získání přenášených médií.
|(1) INVITE | |--->| |(3) 401 Unauthorized | |<---| |(4) INVITE | |--->| |(5) 180 Trying | |<---| |(6) 200 OK | |<---| |(7) ACK | |--->| |(8) RTP stream (90 s) | |<--->| |(9) BYE | |--->| |(10) 2OO OK | |<---| Obrázek 6.3: Schéma signalizace hovoru s médii
V tomto testovacím scénáři jsou média nastaveny tak, že veškeré přenosy hlasu odbavuje ústředna a posílá je koncovým uživatelům a tedy je tímto přenosem velmi za-těžována. Tato modelová situace je vhodná pro případ, že budeme požadovat nahrávání jednotlivých hovorů.
Obrázek 6.4: Schéma zapojení testu hovorů včetně přenosu hlasu
Pro realizaci simulací jsou opět vytvořeny jednotlivé scénáře a jsou přílohou této práce. Pro klienty UAC a UAS je vždy jiný scénář a využívají i jiné seznamy při-pojených uživatelů. Před samotným spuštěním celé simulace je nutné na straně UAS zaregistrovat volané pomocí scénáře uvedeného v kapitole 6.1. Aby nemuseli být puš-těné dvě instance programu SIPp je nastavena doba expirace u zprávy REGISTER na 3 600 vteřin, tedy 1 hodinu.
Spuštění simulace provedeme nejdříve zaregistrováním klientů na straně UAS po-mocí příkazu na ukázce kódu 6.2 a po skončení na straně UAS pustíme skript dle kódu 6.3. Nyní jen stačí pustit SIPp i na straně UAC dle příkazu na ukázce 6.4. Měření opět
bude navyšováno jako v případě registrace, tedy počáteční stav 0,5 hovorů za vteřinu se bude každých 50 vteřin navyšovat o 1 volání za vteřinu dokud bude ústředna schopna odbavovat hovory.
#./ s i p p i 1 9 2 . 1 6 8 . 1 . 1 4 sf reg . xml inf u s e r _ U A S . csv rsa 1 9 2 . 1 6 8 . 1 . 1 3 r 10 -r a t e _ i n c -r e a s e 5 - -r a t e _ m a x 50
Ukázka kódu 6.2: Přihlášení klientů na straně UAS pomocí reg.xml
#./ s i p p i 1 9 2 . 1 6 8 . 1 . 1 4 sf u a s _ p c a p . xml 1 9 2 . 1 6 8 . 1 . 1 3 rsa 1 9 2 . 1 6 8 . 1 . 1 3 t r a c e _ s t a t -t r a c e _ c o u n -t s - -t r a c e _ s c r e e n - -t r a c e _ r -t -t
Ukázka kódu 6.3: Spuštění režimu UAS
#./ s i p p - i 1 9 2 . 1 6 8 . 1 . 8 - sf u a c _ p c a p . xml - inf u s e r _ U A C . csv 1 9 2 . 1 6 8 . 1 . 1 3 - rsa
1 9 2 . 1 6 8 . 1 . 1 3 r 0.5 r a t e _ i n c r e a s e 1 fd 50 s l 100 t r a c e _ s t a t t r a c e _ c o u n t s -t r a c e _ s c r e e n - -t r a c e _ r -t -t
Ukázka kódu 6.4: Spuštění režimu UAC
6.3
Simulace hovorů - přenos pouze signalizace
Poslední test ústředny proběhne pouze na základě zpracovávání signalizace. Pro přenos médii bude v tomto scénáři zvolena přímá cesta mezi koncovými body a tím nebude ústředna zatěžována RTP streamem. Průběh signalizačních zpráv je znázorněn na ob-rázku 6.5. |(1) INVITE | |--->| |(3) 401 Unauthorized | |<---| |(4) INVITE | |--->| |(5) 180 Trying | |<---| |(6) 200 OK | |<---| |(7) ACK | |--->| |(8) Re-INVITE | |<---| |(9) 200 OK | |--->| |(10) Re-INVITE | |<---| |(11) 200 OK | |--->| |(12) Pause 90s | |(13) BYE | |--->| |(14) 2OO OK | |<---|
Obrázek 6.5: Signalizační schéma průběhu hovoru bez přenosu médií
V průběhu signalizace nejdříve dojde k navázání komunikace pomocí zpráv INVITE následně strana UAS potvrdí přijmutí hovoru. Média se v této konfiguraci nebudou
přenášet prostřednictvím ústředny a tedy dojde znovu k zaslání zprávy INVITE, ten-tokrát od ústředny a v následujícím kroku po zaslání poslední zprávy re-INVITE se média přepnou mezi koncové stanice.Poté dojde k pozastavení hovoru na 90 vteřin a následně se hovor ukončí. Schéma zapojení a naznačení přenosu signalizačních zpráv je znázorněno na obrázku 6.6.
Obrázek 6.6: Schéma zapojení testů s přímými médii
Z obrázku 6.6 je patrné, že ústředna bude realizovat pouze spojení pomocí signa-lizace SIP a média budou přenášena na přímo mezi koncovými zařízeními. Testovací scénář je navržen tak, aby si volající strany za pomoci ústředny domluvily přenos médií napřímo a nedocházelo tak k zatížení ústředny. Po vytvoření hovoru zrealizují přenos audia po dobu 90 vteřin a poté hovor ukončí. Testovací scénáře jsou velmi podobné jako předchozí a jsou přiloženy jako příloha této práce. Spuštění se provede stejným způsobem jako v předchozím bodě, s tím rozdílem že je nutné uvést jiné testovací scénáře XML. Spuštění je naznačeno na ukázce 6.5. Samozřejmě je nutné upravit kon-figuraci ústředny Asterisk, aby bylo možné přenášet média přímo mezi koncovými uzly.
#./ s i p p i 1 9 2 . 1 6 8 . 1 . 1 4 sf reg . xml inf u s e r _ U A S . csv rsa 1 9 2 . 1 6 8 . 1 . 1 3 r 10 -r a t e _ i n c -r e a s e 5 - -r a t e _ m a x 50
#./ s i p p i 1 9 2 . 1 6 8 . 1 . 1 4 sf uas . xml 1 9 2 . 1 6 8 . 1 . 1 3 rsa 1 9 2 . 1 6 8 . 1 . 1 3 t r a c e _ s t a t -t r a c e _ c o u n -t s - -t r a c e _ s c r e e n - -t r a c e _ r -t -t
#./ s i p p i 1 9 2 . 1 6 8 . 1 . 8 sf uac . xml inf u s e r _ U A C . csv 1 9 2 . 1 6 8 . 1 . 1 3 rsa 1 9 2 . 1 6 8 . 1 . 1 3 -r 1 - -r a t e _ i n c -r e a s e 1 - fd 90 s - t -r a c e _ s t a t - t -r a c e _ c o u n t s - t -r a c e _ s c -r e e n - t -r a c e _ -r t t - l
1 0 0 0
Ukázka kódu 6.5: Spuštění testovacího scénáře s přímým přenosem médií
6.4
Sledované statistiky
Pro jednotlivé scénáře testování ústředny jsou navrženy časové úseky po kterých bude sledována reakční doba ústředny na jednotlivé zprávy. Výsledkem těchto testů by měla být znázorněna delší reakční doba ústředny pří více požadavcích v jednom konkrét-ním časovém úseku. Následně bude zaznamenáván počet hovorů v čase a celkový počet úspěšných a neúspěšných hovorů. V podrobných statistikách bude zaznamenán jed-notlivý počet konkrétních zpráv a počet opakovaných odeslání zpráv. Při běhu testu
budou sledovány systémové statistiky ústředny, jako například vytížení procesoru a využití síťové konektivity.
Při testování bude nejdříve ústředna obsluhovat pouze provoz vzniklý hovory, tedy žádosti SIP a přenos médií prostřednictvím RTP. Poté ve stejné konfiguraci bude ústředna zároveň zatížena TCP tokem vytvářeným pomocí programu iPerf, který je popsán v kapitole 5.2. Testy proběhnou opakovaně pro zajištění přesnějších výsledků. Jedním z faktoru ovlivňující výkon by také mohl být typ operačního systému. Na testovaných zařízeních bude pro první testy nainstalován operační systém Raspbian. Raspbian vychází z distribuce Debianu a je upraven pro vestavěný systém RaspberryPi. Podporu tohoto operačního systému nabízejí i ostatní platformy vestavěných systémů. Jako druhý operační systém bude zvolena upravená linuxová distribuce Ubuntu. V pří-padě, že na vestavěném systému nebude podpora tohoto systému bude zvolena jiná distribuce pro porovnání výsledků.
7
Testované systémy
V rámci této diplomové práce budou probíhat testy na vestavěných zařízení, které se podařilo získat pro realizaci těchto testů. Mezi tyto zařízení patří Raspberry Pi 2 Model B, který je popsán v kapitole 2.2 a zařízení Orange Pi PC, které má podopné vlastnosti jako Raspberry Pi, s tím rozdílem, že je vyráběn jiným výrobcem a nabízí jiná specifika, která jsou popsána v kapitole 2.4.1.
Hlavním rozdílem těchto zařízení je typ a výkon procesoru. Raspberry Pi disponuje procesorem Broadcom BCM2836 s základním taktem 0,9 GHz, Orange Pi PC využívá procesor AllWinner H3 s taktem 1,6 GHz. Orange Pi nabízí stejnou síťovou konektivitu jako Raspberry Pi, tedy 100 Mbit/s Ethernet.
Raspberry Pi v testovacích scénářích využívá operační systém Raspbian GNU/Li-nux 8.0 (jessie) s nainstalovanou softwarovou ústřednou Asterisk verze 13.8.2. Pro účely testování a zatížení síťové komunikace je připraven program iPerf ve verzi 2.0.5. Jako druhý operační systém je připraven operační systém Ubuntu verze 14.04.2 LTS v sys-tému je nainstalována softwarová ústředna Asterisk verze 13.8.2. Jako v předchozím operačním systému i zde je k dispozici program iPerf ve verzi 2.0.5.
Orange Pi Pc podporuje OS Raspbian, ale jeho podpora není stoprocentní, a proto je využit v testech operační systém Debian GNU/Linux 8.0 (jessie) se softwarovou ústřednou Asterisk verze 13.8.2. V tomto případě se jedná o čistou instalaci systému Debian, jádro operačního systému je stejné jako v případě upraveného Raspbianu. Jako druhý operační systém je připraven OS Ubuntu verze 15.04 s ústřednou Asterisk ve stejné verzi, tedy 13.8.2. V těchto systémech již není nainstalován program iPerf, jelikož není využíván pro simulační testy.
Na závěr testování jsou simulace realizovány na podobném zařízení jako jsou vesta-věné systémy, s tím rozdílem že je toto zařízení přímo vyráběno jako malá pobočková IP ústředna. Zařízení Grandstream UCM 6102 běží na vlastní platformě(pravděpodobně linuxová distribuce). Dle odchycené komunikace se zdá, že uvnitř je použit jako ústředna software Asterisk. Tyto údaje nejsou výrobcem nikde udávané a nelze je tedy s jistotou určit. Zařízení se nastavuje pomocí vlastního webového rozhraní.
8
Výsledky testů
8.1
Raspberry Pi 2 Model B
Prvním testovaným zařízením je Raspberry Pi 2 Model B, v základní konfiguraci s taktem procesoru 0,9 MHz. Na zařízení je nainstalován operační systém Raspbian a také Ubuntu. Testy probíhaly na obou systémech a rozdíly jsou zaznamenány u jednotlivých scénářů.
8.1.1 Scénář REGISTER
Registrace telefonních přístrojů probíhala podle předem nastaveného scénáře s počá-tečním generováním 5 žádostí za vteřinu a každé 3 vteřiny se počet žádostí za vteřinu zvýšil o 2 žádosti. Test byl spuštěn s nastaveným limitem maximálně 10000 současných žádostí v systému.
Obrázek 8.1: Registrace klientů k ústředně Raspberry Pi 2 Model B - OS Raspbian
Ústředna bez problému dokáže vyhovět nejméně 150 žádostem za vteřinu. Z grafu znázorněném na obrázku 8.1 je patrné, že k zahlcení systému, kdy již nezvládá reago-vat na generované žádosti dochází v oblasti, kdy je generováno přibližně 160 žádostí za vteřinu. V tomto okamžiku je již odezva systému příliš velká a začíná docházet k výpadkům a vypršení časových limitů pro odpovědi.
Vytíženost celého systému v průběhu simulace je znázorněna v grafech na obrázku 8.2. Využití procesoru se blíží takřka ke 100 procentům v okamžiku, kdy začíná být systém přetížen a zcela zahlcen příchozími požadavky. Ve využití síťové karty jsou velmi dostatečné rezervy. Raspberry Pi 2 Model B disponuje pouze 100 Mbit/s ethernetovou kartou, ale i ta je naprosto dostačující pro zvládnutí maximální kapacity systému.
Obrázek 8.2: Využití systémových prostředků pro registraci klientů k ústředně Raspberry Pi 2 Model B - OS Raspbian
Obrázek 8.3: Odezva ústředny na registrační žádosti k ústředně Raspberry Pi 2 Model B - OS Raspbian
Na grafech na obrázku 8.3 jsou znázorněny průběhy odezvy na zprávy REGISTER. Na horním grafu je odezva na REGISTER zprávu, která již obsahuje autorizační heslo a klíč a ústředna již odpovídá úspěšnou zprávou 200 OK. Na tomto průběhu je patrné, že se zvyšujícím počtem žádostí dochází k delším prodlevám mezi odpověďmi. Po dosažení limitu 160 žádostí za vteřinu se doba odezvy velice zvyšuje a dosahuje až 27 vteřin a
