Realizacja usług Voice over IP i Video over IP w sieciach operatorskich i korporacyjnych

Transkrypt

1 Zakład Sieci (Z-2) Ośrodek Informatyki (OI) Realizacja usług Voice over IP i Video over IP w sieciach operatorskich i korporacyjnych Numer pracy: Warszawa, grudzień 2006

2 Realizacja usług Voice over IP i Video over IP w sieciach operatorskich i korporacyjnych Praca nr Słowa kluczowe (maksimum 5 słów): VoIP, IP-PBX, QoS Kierownik pracy: mgr inż. Mariusz Gajewski, Z-2 Wykonawcy pracy: mgr inż. Mariusz Gajewski Z-2 mgr inż. Michał Gartkiewicz Z-2 mgr inż. Konrad Sienkiewicz Z-2 inż. Waldemar Latoszek Z-2 inż. Urszula Cackowska Z-2 mgr inż. Danuta Latoszek Z-2 mgr inż. Grzegorz Wójcik OI mgr inż. Dominik Łoniewski OI mgr inż. Piotr Jankowski OI mgr inż. Adam Cichoń OI mgr inż. Dariusz Gacoń Z-2 mgr inż. Wacław Białkowski Z-2 Kierownik Zakładu: mgr inż. Dariusz Gacoń Copyright by Instytut Łączności, Warszawa 2006

3 Spis treści Spis treści 3 1. Wprowadzenie Cel pracy Sposób realizacji Podsumowanie 6 2. Ogólne wymagania na parametry jakościowe sieci dla usług czasu rzeczywistego Wymagania jakościowe Wymagania na transmisję głosu w sieciach pakietowych Wymagania na transmisję obrazów w sieciach pakietowych Aspekty organizacyjne wdrażania telefonii VoIP w sieci korporacyjnej Testy jakości głosu oraz konfiguracja środowiska VoIP w IŁ pod kątem zapewnienia jakości głosu Zjawisko zmiennego opóźnienia pakietów (jittera) Bufor niwelujący zjawisko jittera Sposób określenia wielkości bufora dla jittera (jitterbuffer) Długookresowe monitorowanie parametrów jakościowych w tunelach Internet-VPN IŁ Testy jakości mowy Testy jakości mowy dla połączeń VoIP w internetowym kanale Internet-VPN do Wrocławia Testy jakości mowy dla połączeń VoIP w sieci LAN Podsumowanie przeprowadzonych badań Testy funkcjonalności i usług dodatkowych platformy VoIP opartej o rozwiązanie Asterisk Badania transmisji faksowej Ocena systemu poczty głosowej Testy funkcjonalności Call Center Usługa Follow Me Testy IVR Połączenia konferencyjne Połączenia video Testy funkcjonalne i użytkowe sprzętowych i programowych terminali VoIP Platforma VoIP w Instytucie Łączności Wybór platformy Rozwiązania rekomendowane do stosowania w sieci VoIP Instytutu Łączności Integracja z systemem telefonicznym Instytutu Łączności Konfiguracja systemów telefonicznych w IŁ 60 3

4 Plan numeracyjny w Instytucie Łączności Wykaz zmian w konfiguracji centrali PBX Hicom 300E w siedzibie IŁ w Warszawie System poczty głosowej Interaktywne menu głosowe IVR Założenie organizacyjne systemu VoIP Porównanie platformy Asterisk z oferowanymi komercyjnie rozwiązaniami IP-PBX Asterisk Rozwiązania firmy Cisco Rozwiązania firmy Alcatel Rozwiązania firmy 3Com Rozwiązania firmy Avaya Rozwiązania firmy Siemens 74 Bibliografia 76 Spis skrótów 77 Załącznik

5 1. Wprowadzenie 1.1. Cel pracy Głównym celem pracy było pozyskanie wiedzy i praktycznych umiejętności z zakresu rozwiązań VoIP. Wiedza ta dotyczy aspektów wdrażania, integracji z systemami TDM, usług oraz zarządzania w systemach VoIP. Cel ten został osiągnięty poprzez realizację następujących celów cząstkowych: zdefiniowanie warunków implementacji usług transmisji głosu w korporacyjnych sieciach pakietowych oraz opracowanie podręcznika przeznaczonego dla przedsiębiorstw oraz jednostek administracji, uruchomienie systemu VoIP w IŁ, łączącego oddziały terenowe, w oparciu o serwer Asterisk, analiza możliwości oferowanych na rynku platform VoIP, określenie możliwości realizacji usług na bazie uniwersalnej platformy usługowej IMS, wspólnej dla wszystkich przekazów multimedialnych Sposób realizacji Praca została zrealizowana w ramach trzech zadań: 1. Opracowanie zasad wdrażania usług VoIP w sieciach korporacyjnych. Testowanie i uruchomienie platformy VoIP w Instytucie Łączności (zadanie koordynowane przez Mariusza Gajewskiego) 2. Architektura IMS jako platforma dla realizacji usług multimedialnych w sieciach NGN umożliwiająca wdrożenie koncepcji Fixed Mobile Convergence FMC (zadanie koordynowane przez Danutę Latoszek) 3. Przygotowanie projektu realizowanego przy współpracy z krajami Europy Wschodniej, finansowanego ze środków strukturalnych (zadanie zrealizowane przez Wacława Białkowskiego) Niniejszy dokument stanowi raport z realizacji zadania 1, raporty z pozostałych dwóch zadań stanowią odrębne dokumenty. W ramach zadania 1 dokonano: 1. analizy platform VoIP dostępnych w ramach otwartej licencji, pod katem zastosowania w sieci korporacyjnej IŁ. Uwzględniono takie platformy jak Asterisk@Home, AsteriskNow, FreeSwitch, Yate, Trixbox. Etap ten uwzględniał analizę deklarowanych możliwości funkcjonalnych, ocenę możliwości uzyskania wsparcia dla produktu oraz próbną instalację produktu. W wyniku tej analizy podjęto decyzję o wyborze platformy Trixbox jako docelowego rozwiązania w IŁ. 2. instalacji platformy VoIP na serwerze wirtualnym i wykonano testy obejmujące: a. połączenia pomiędzy użytkownikami VoIP, gdzie użytkownicy korzystali z b. terminali obsługujących protokół SIP oraz IAX2), c. bram obsługujących protokół SIP oraz IAX2), 5

6 d. połączenia pomiędzy użytkownikami VoIP i użytkownikami dołączonymi do centrali Hicom za pośrednictwem bramy (Cisco 2811), przy czym użytkownicy korzystali z terminali obsługujących protokół SIP oraz IAX2. W wyniku tych testów stwierdzono, że oprogramowanie serwera VoIP zainstalowane na serwerze wirtualnym nie zapewnia wymaganej jakości głosu. Podjęto zatem decyzję o zakupie dedykowanej platformy sprzętowej dla serwera VoIP, co spowodowało konieczność wprowadzenia zmian do harmonogramu pracy. Część prac realizowanych była z wykorzystaniem testowej platformy VoIP zainstalowanej na komputerze klasy PC. 3. uruchomienia produkcyjnej platformy VoIP na dedykowanym serwerze oraz integracja z systemami telefonicznymi IŁ. Dla celów badawczych integracja z centralą Hicom w Warszawie realizowana była dwoma sposobami: z wykorzystaniem bramy VoIP w routerze Cisco 2811 oraz karty 4xE1 firmy Digium. Dla sieci VoIP w IŁ wybrano rozwiązanie z kartą Digium, dla której wykonano również testy zgodności dla implementacji protokołu DSS1. Integracja z siecią telefoniczną IŁ wymagała zmian konfiguracji centrali Hicom w Warszawie oraz dostosowania planu numeracyjnego w sposób, który zapewni zarówno łatwość korzystania, jak i nie będzie burzył dotychczasowego układu. 4. realizacji testów funkcjonalności usług dodatkowych platformy Trixbox. W ramach tego zadania sprawdzono między innymi: a. Zarządzanie systemem (konfiguracją, użytkownikami, usługami), b. Pocztę głosową; c. IVR d. Transmisję faksową e. Transmisję video f. Połączenia konferencyjne g. Implementację funkcji Call Center 5. realizacji testów jakości głosu w systemie produkcyjnym z wykorzystaniem zakupionego w tym celu oprogramowania firmy GL. 6. realizacji testów funkcjonalno-użytkowych zakupionego sprzętu VoIP i wytypowanego oprogramowania. Wynikiem tych badań jest rekomendacja dotycząca stosowania w IŁ poszczególnych rozwiązań. 7. przeglądu wybranych platform VoIP oferowanych komercyjnie na rynku Podsumowanie W wyniku realizacji niniejszej pracy w Instytucie Łączności wdrożona została platforma VoIP pozwalająca na: redukcję kosztów związanych z połączeniami telefonicznymi pomiędzy oddziałami IŁ; wdrożenie sytemu zdalnej pracy w Instytucie Łączności; wprowadzenie dodatkowych funkcjonalności systemu telekomunikacyjnego IŁ (IVR, Voic , fax2 ). Niniejsza praca badawcza z uwagi na bardzo praktyczny charakter wzbogaciła wykonawców o szereg doświadczeń i umiejętności niemożliwych do zdobycia przy pracach teoretycznych. Doświadczenia te dotyczą urządzeń końcowych, protokołów i usług VoIP oraz zasad integracji sieci VoIP z sieciami TDM. Wiedza z zakresu wdrażania systemów wykorzystujących VoIP (stosowanych m.in. w rozwiązaniach IVR i call/contact center), może być stosowana nie tylko do realizacji prac 6

7 badawczych, lecz również pozyskanych na rynku, czego dowodem są działania podjęte w roku 2006 m.in.: rozmowy prowadzone z Telekomunikacją Kolejową dotyczące wdrożenia call center opartego na platformie Asterisk, realizacja tegorocznych prac w ramach Programu Wieloletniego (propozycja rozwiązań systemu łączności dla Systemu Kierowania Bezpieczeństwem Narodowym), oraz prace planowane na rok 2007: w ramach Programu Wieloletniego (SP I.10 dotycząca retencji danych w telefonii internetowej; SP V.3 w zakresie budowy systemu systemu pilotowego dla systemu łączności dla Systemu Kierowania Bezpieczeństwem Narodowym), planowana realizacja projektu rozwojowego Kiosk multimedialny. 7

8 2. Ogólne wymagania na parametry jakościowe sieci dla usług czasu rzeczywistego 2.1. Wymagania jakościowe Wymagania na transmisję głosu w sieciach pakietowych Usługa VoIP (Voice over IP) stanowi usługę sieci teleinformatycznej umożliwiającą komunikację głosową z wykorzystaniem sieci komputerowej. Usługa ta zapewnia równoczesny transfer danych z wykorzystaniem tej samej sieci, co w przypadku tradycyjnej telefonii wymaga zajęcia dwóch różnych łączy telekomunikacyjnych. Wprowadzenie usług VoIP umożliwia, zatem uzyskanie określonych korzyści ekonomicznych poprzez obniżenie kosztów transmisji. Ideą telefonii IP jest komutacja pakietów, przy której transmisja mowy, jak i danych odbywa się z wykorzystaniem pakietów IP przesyłanych we wspólnym medium transmisyjnym. Realizacja transmisji mowy w sieciach IP wiąże się ściśle z zapewnieniem wymaganego poziomu jakości usługi. W przekazach związanych z transmisją mowy realizowanych w czasie rzeczywistym, dane muszą dotrzeć do miejsca przeznaczenia w określonym czasie (opóźnienie transmisji), co wymaga wykorzystania szybkich sieci teleinformatycznych i odpowiedniej przepustowości. Jeśli przepustowość jest zbyt mała, tracona jest część informacji, co prowadzi do pogorszenia jakości przekazu. Sieć transmisyjna musi, więc zapewnić minimalną wymaganą przepływność dla usług VoIP lub zapewnić priorytety ruchu dla tych usług (polityka QoS). W odniesieniu do aplikacji realizujących interaktywną komunikację głosową istotny jest także wpływ procesów związanych z przekształceniem sygnału mowy na postać dogodną do transmisji w sieci IP. Obejmują one konwersję sygnału do postaci analogowej, kompresję, pakietyzację i kolejkowanie w nadajniku, oraz buforowanie, depakietyzację, dekompresję i konwersję do postaci analogowej w odbiorniku. Procesy te charakteryzują się wprowadzaniem określonego opóźnienia, które wraz z opóźnieniem transmisyjnym określa opóźnienie całkowite w zbiorze parametrów QoS dla aplikacji VoIP. Sygnał mowy poddawany może być dodatkowym zabiegom związanym z eliminowaniem echa (echo cancellation) oraz eliminacją ciszy VAD (Voice Activation Detection), które służą podniesieniu jakości połączenia głosowego. W telefonii IP QoS postrzegane przez użytkownika jest, więc zależne od dwóch rzeczy: jakości odbieranego głosu i opóźnienia w dwustronnej konwersacji. Te dwa parametry są blisko ze sobą powiązane, gdyż lepsza jakość głosu wymaga większego strumienia bitów, a większy strumień bitów wprowadza większe opóźnienie. Z punktu widzenia opóźnienia transmisja winna odbywać się z wykorzystaniem pakietów o jak najmniejszym rozmiarze, co związane jest z szybkością obsługi pakietów w routerach. W przypadku połączeń fonicznych wykorzystujących eliminację echa opóźnienia sygnału mowy związane są ze stopniem interaktywności danej aplikacji. W przypadku aplikacji charakteryzujących się bardzo dużym poziomem interaktywności, zgodnie z zaleceniem ITU-T G.114 [6], opóźnienie nie powinno być większe od 100 ms. Jako graniczną wartość opóźnienia dla transmisji jednokierunkowej zgodnie z tym zaleceniem przyjmuje się wartość 150 ms, która jest wartością akceptowalną dla większości aplikacji interaktywnej komunikacji głosowej. Wartości opóźnienia w przedziale od 150 do 400 ms prowadzą do obniżenia jakości połączenia głosowego, a komunikacja przybiera charakter komunikacji naprzemiennej (half-duplex). Całkowite opóźnienie, jak już wspomniano, zależne jest od przyjętego sposobu kodowania mowy. Najczęściej wykorzystywane układy kodowania mowy wprowadzają opóźnienie przetwarzania na poziomie od kilku do kilkudziesięciu milisekund. Najmniejszym opóźnieniem charakteryzuje się kodek G.711, gdzie z uwagi na brak kompresji wprowadzane opóźnienie jest poniżej 1 ms. W przypadku kodeka G opóźnienie przetwarzania równe jest około 30 ms. 8

9 Właściwy dobór schematu kodowania może, więc skutecznie poprawić jakość realizowanego przekazu fonicznego. Wariancja opóźnienia jest kolejnym istotnym parametrem charakteryzującym jakość usług w odniesieniu do telefonii VoIP. Parametr ten charakteryzuje tę cechę sieci IP, która związana jest z możliwością kierowania pakietów należących do jednego połączenia różnymi drogami. Oczywistym jest, że w takiej sytuacji pakiety docierać mogą do odbiorcy w różnych odstępach czasu, a co więcej w różnej kolejności. Eliminacja tego niekorzystnego zjawiska wymaga zastosowania buforowania po stronie odbiorczej. Wprowadzenie bufora umożliwia przekazywanie pakietów do warstwy aplikacji we właściwej kolejności i we właściwych odstępach czasu. Wielkość bufora powinna uwzględniać zarówno charakterystyki sieci (zróżnicowany czas docierania pakietów), jak również charakterystyki aplikacji (zbyt długi czas oczekiwania wprowadza utratę interaktywności aplikacji). W zakresie pomiarów opóźnienia (a dokładnie czasu odpowiedzi) oraz jittera najczęściej stosowaną metodą pomiarową jest stosowanie polecenia PING, które wykorzystuje protokół ICMP, bezpośrednio kapsulowany w pakietach protokołu IP. Tutaj z kolei na wynik pomiaru wpływa rozmiar pakietu. Rozmiar pakietu jest tym istotniejszy, im niższa jest szybkość transmisji na testowanym łączu, gdyż do opóźnienia powodowanego: ograniczeniami propagacyjnymi, przejściem przez urządzenia sieciowe (w tym konwersją postaci sygnału, buforowaniem, (de)multipleksacją, komutacją, niekiedy też defragmentacją i powtórnym scalaniem) dochodzi również czas transmisji samej ramki testowej, który jest uzależniony od szybkości łącza. Tabela 1. Szacowany narzut związany z wielkością nagłówków poszczególnych protokołów Protokół Minimalna wielkość nagłówka wyrażona w bajtach Maksymalna wielkość nagłówka wyrażona w bajtach Przyjęta w badaniach narzędzi testowych wielkość nagłówka wyrażona w bajtach Ethernet II IPv4 TCP Dane HTTP oraz narzut związany z obsługą okna transmisyjnego RAZEM (bajtów) Nie mniej niż RAZEM (% rozmiaru pakietu) 1 5% Nie mniej niż 13% 6% Uwagi do tabeli: 1. Minimalny rozmiar ramki Ethernet II wraz z polem danych i preambułą wynosi 72 bajty 2. Maksymalny rozmiar ramki Ethernet II wraz z polem danych i preambułą wynosi 1526 bajty 3. Rozmiar nagłówków protokołu IP oraz TCP jest zależny od liczby opcjonalnych parametrów 4. Narzut na nagłówki warstwy aplikacyjnej (HTTP) jest zmienny i zależny od aplikacji 5. Narzut związany z obsługą potwierdzeń jest związana z wielkością okna transmisyjnego TCP Niestety narzędzie to nie jest precyzyjne, gdyż niektóre urządzenia sieciowe mogą filtrować pakiety protokołu ICMP (używane przez ping ) aby uniemożliwić sprawdzenie dostępności w sieci poszczególnych routerów lub serwerów. Metodę tę wykorzystano do pomiarów opóźnienia oraz 1 Przyjęto następujące założenie: maksymalna wielkość jednostki transmisyjnej, rozumianej jako pole danych ramki Ethernet, MTU=1500 bajtów 9

10 jittera w sieci IŁ oraz w kanałach VPN łączących z wykorzystaniem Internetu (Internet-VPN) oddział warszawski oraz oddziały w Gdańsku i Wrocławiu Wymagania na transmisję obrazów w sieciach pakietowych Definiując wymagania nakładane na parametry zapewniające akceptowalną pod względem jakości transmisję obrazów w sieciach pakietowych, należy rozróżnić dwa typy ruchu generowanego przez aplikacje video: ruch generowany przez aplikacje interaktywne, wykorzystywany na potrzeby wideokonferencji, ruch generowany przez aplikacje dystrybuujące sygnał wideo (zarówno w trybie unicast jak i multicast). W celu zapewnienia akceptowalnej przez użytkowników jakości usług połączeń video należy przyjąć następujące wymagania minimalne za obowiązujące: współczynnik utraty pakietów nie większy niż 1%, opóźnienie pakietów w jednym kierunku (end-to-end)150 ms, wartość parametru jitter nie większa niż 30 ms, zapewnienie pasma gwarantującego przepływność uwzględniającą przynajmniej 20% narzut związany z nagłówkami protokołów. W połączeniach video realizowanych w technologii pakietowej z wykorzystaniem protokołu IP stosowana jest typowa metoda kodowania głosu z wykorzystaniem kodeka audio, którym jest najczęściej kodek G.711. Pomimo zbieżności wymagań w zakresie parametrów jakościowych, model ruchowy charakterystyczny dla połączeń video jest znacząco inny niż model charakterystyczny dla transmisji głosowej. Różnice obejmują przede wszystkim zróżnicowaną wielkość pakietów oraz zmienność ich przepływności, co wynika ze sposobu kodowania oraz eliminowania nadmiarowej informacji (Rys. 1). Rys. 1. Wpływ kodowania sygnału wideo na wymagane pasmo (źródło [2], oznaczenia wyjaśniono w tekście) Przepływność strumienia video wynika przede wszystkim z częstotliwości próbkowania, metod kodowania obrazu jak i głosu. Najważniejsze standardy kodowania sygnałów wideo opracowane przez ITU w celu umożliwienia realizacji połączeń video przygotowano jeszcze dla sieci ISDN. Wąskie pasmo transmisyjne wymusiło utworzenie algorytmów dobrze kompresujących informacje związane z obrazem. Standardy te w późniejszym okresie zostały przeniesione do sieci LAN/WAN, 10

11 gdzie mimo swoich wad są najczęściej wykorzystywane ze względu na niewielkie wymagania i łatwość implementacji. Korzystają z nich również aplikacje internetowe. Kodowanie kanału wizyjnego dla celów transmisji obrazów w sieciach pakietowych, zgodnie ze standardami H.320/H.323, opisane zostało w zaleceniach H.261/H.263. Kodowane są trzy komponenty: luminancja i dwie składowe różnicowe koloru (Y, CB i CR). Analogowy sygnał wizyjny próbkowany jest z założeniem utraty informacji w dwóch formatach: CIF (Common Intermediate Format), w którym liczba linii obrazu wynosi 288 dla luminancji i 144 chrominancji, przy 352 punktach w linii dla luminancji i 176 dla chrominancji. QCIF (Quarter CIF), w którym liczba linii obrazu wynosi 144 dla luminancji i 72 chrominancji, przy 176 punktach w linii dla luminancji i 88 dla chrominancji. Kodek H.261 projektowany był z myślą o sieci ISDN, gdzie połączenia wykonywane są w trybie komutacji kanałów, tak że na jego wyjściu informacja przygotowana jest do transmisji o stałej przepływności binarnej (Constant Bit Rate). W skład kodera wideo H.261/H.263 wchodzą bloki predykcji, transformacji i kwantyzacji. Ogólna zasada kodowania polega na redukcji nadmiarowej przestrzennej informacji i przesyłaniu tylko różnic pomiędzy obrazami, pojawiającymi się w kolejnych ramkach. Operacja powyższa wykonywana jest w dwóch krokach: kompresja intraframe wewnątrz segmentów 8x8 z wykorzystaniem dwuwymiarowej transformacji cosinusowej DCT. Wartości wyjściowe są następnie kwantowane, z możliwością zmian współczynnika kwantowania. kompresja interframe dotyczącej różnic pomiędzy makroblokami w kolejnych ramkach obrazu. W tym trybie wykonywana jest również opcjonalna kompensacja ruchu, która polega na przesyłaniu tylko różnic przesunięć danego makrobloku w poziomie i pionie. Rozwinięciem H.261 jest schemat kodowania opisany w zaleceniu H.263. Do wad powyższych technik kodowania można zaliczyć próbkowanie w stosunku 4:1:1 (luminancja: chrominancja: chrominancja) dla składowych luminancji i chrominancji. Dodatkowo dzielenie obrazu na bloki i makrobloki, powoduje powstawanie charakterystycznych zakłóceń, które są łatwo wychwytywane przez oko ludzkie, szczególnie w przypadku powiększania obrazu. Również fakt, że obraz nie jest komprymowany w całości, lecz przy pomocy tworzonych ramek I (Intra frames), P (Predictive) i B (Bi-direction), w ramach tworzonych bloków wewnątrz obrazu, powoduje, że utrata/opóźnienie pakietów podczas transmisji lub szybka zmiana ekspozycji obrazu objawia się znacznym pogorszeniem jakości. Powyższe błędy są odbierane w postaci skwantowanego obrazu w ramach bloków (pixelization) i pogorszenia ostrości. Nie mniej jednak, kompresja sygnałów wideo z wykorzystaniem standardów H.261/H.263 pozwala uzyskać przepływność zakodowanego sygnału wideo na poziomie od 64 kb/s do 2 Mb/s. Można zatem w znaczny sposób ograniczyć wymagane przepływności, co stwarza możliwości wykorzystywania sygnałów wideo we współczesnych sieciach pakietowych do realizacji różnych usług. W kontekście ruchu generowanego przez aplikacje dystrybuujące sygnał wideo należy zdefiniować następujące minimalne warunki dla transmisji o akceptowalnej jakości: współczynnik utraty pakietów nie większy niż 5%, opóźnienie (jednokierunkowe) nie większe niż 4-5 sekund (w zależności od możliwości wykorzystywanej aplikacji w zakresie buforowania strumienia video), brak ściśle określonych wymagań na wartość jittera, 11

12 gwarantowane pasmo w zależności od formatu kodowania oraz przepływności strumienia video na wyjściu kodeka, ze względu na charakter transmisji (jednokierunkowy) wymagane jest wsparcie dla funkcji dystrybucji strumieni multimedialnych w węzłach sieci (routery), cel przekazu strumienia video (jako komercyjna usługa lub istotna funkcjonalność z punktu widzenia operatora infrastruktury informatycznej w przeciwieństwie do treści rozrywkowych przechowywanych na ogólnodostępnych serwerach) powinien determinować sposób obsługi tego ruchu przez węzły sieciowe. W tabeli przedstawiono propozycję przyporządkowania poszczególnych klas usługowych do usług multimedialnych w zależności od cech charakterystycznych usługi. Tabl. 1. Zastosowanie klas usługowych do obsługi ruchu generowanego przez aplikacje multimedialne (źródło [8]) Poziomy (levels) Poziom1 Poziom 2 Poziom 3 Poziom 4 brak, Obrazy wideo Audio Tekst Grafika/animacja Obrazy małe okna, nierównomierne dostarczanie, stratna kompresja porównywalne z jakością taśmy wideo VHS, przełączane kanały wideo zastosowanie w: a) telewizji rozsiewczej b) studia nagraniowe c) HDTV przełączane kanały wideo jakość rozmowy w PSTN jakość rozmowy w PSTN synchronizacja z sygnałem wideo 2 lub więcej kanałów ścisła synchronizacja z wideo porównywalny z jakością rozgłośni FM 3 lub więcej kanałów dźwięk typu surround porównywalny z jakością cyfrową CD zauważalne opóźnienia nierównomierne dostarczanie brak widocznych opóźnień jednostajne dostarczanie brak widocznych opóźnień jednostajne dostarczanie brak widocznych opóźnień jednostajne dostarczanie pojedyncza ramka paleta VGA zauważalne opóźnienia brak animacji dostarczanie slajdów w trybie non real time brak zauważalnych opóźnień w prezentacji grafiki animacja obrazkowa brak zauważalnych opóźnień w prezentacji grafiki animacja obrazkowa pojedynczy obraz znaczące opóźnienia pojedynczy obraz znaczące opóźnienia pojedynczy obraz dostarczanie w trybie non real time pojedynczy obraz brak zauważalnych opóźnień 12

13 3. Aspekty organizacyjne wdrażania telefonii VoIP w sieci korporacyjnej Proces wdrażania systemów VoIP w sieciach korporacyjnych jest przedsięwzięciem złożonym, ponieważ ingeruje w podstawowy system komunikacji przedsiębiorstwa (dotyczy zarówno komunikacji głosowej jak i wymiany danych). Metodyka postępowania przyjmowana w tym obszarze dotyczy zasadniczo dwóch aspektów organizacyjnego oraz technicznego. W aspekcie organizacyjnym proces migracji w kierunku systemu VoIP rozpatrywany w kategoriach organizacyjnych obejmuje następujące etapy [3]: 1. Określenie oczekiwań użytkowników Na tym etapie konieczne jest jednoznaczne zdefiniowanie celów, które mają być osiągnięte w wyniku wdrożenia systemu telefonii IP. Cele te powinny być rozpatrywane z punktu widzenia wpływu na istotne zadania realizowane przez daną organizację. Pod uwagę powinny być zatem brane nie tylko efekty ekonomiczne realizacji zadania lecz również pozytywne i negatywne skutki wdrożenia na system komunikacji w organizacji tak obecnie jak również w perspektywie 3-5 lat. 2. Analiza otoczenia projektu. Analiza istniejącej infrastruktury telekomunikacyjnej, planu numeracyjnego oraz interfejsów do sieci telekomunikacyjnej. 3. Przygotowanie planu wdrożenia Plan wdrożenia określa harmonogram prac z podziałem na etapy oraz cele przewidziane do osiągnięcia w poszczególnych etapach. Plan ten powinien być opracowany z uwzględnieniem istotnych interesów organizacji. W ramach tego planu powinny zostać zdefiniowane zakresy obowiązków członków zespołu oraz rola każdego z nich w procesie wdrażania systemu. Należy rozważyć, czy buduje się całkowicie nową infrastrukturę telefoniczną (np. podczas przeprowadzki do nowego budynku), czy też rozbudowuje się istniejący już system telefonii. Jeżeli zaczynamy od podstaw, wówczas nie musimy się martwić o współdziałanie z istniejącą infrastrukturą, co znacząco upraszcza zadanie. Należy zapewnić, aby nowo powstająca infrastruktura sieciowa była zorientowana na VoIP. Na potrzeby systemu telefonicznego najlepiej zarezerwować autonomiczną sieć. Wprawdzie dane i głos mogą współdzielić tę samą sieć (np. poprzez stworzenie oddzielnych sieci VLAN), jednak tylko dopóki nie będzie ona mocno obciążona. Przy znacznym wykorzystaniu dostępnej przepustowości na potrzeby danych pogorszy się jakość usług telefonicznych i trzeba będzie rozdzielić obydwa środowiska sieciowe. Zaleca się położenie podwójnego okablowania na samym początku budowy sieci, gdyż późniejsze przeróbki są kosztowne. Jeżeli mamy już funkcjonującą centralę PBX, trzeba rozważyć, w jaki sposób i czy faktycznie może być ona wykorzystywana z nową IP PBX. Producenci IP PBX (m.in. 3Com, Avaya i Siemens) często wykorzystują autorskie udoskonalenia protokołów H.323 lub SIP. Skutkuje to brakiem gwarancji współdziałania sprzętu pochodzącego od różnych producentów. 4. Określenie budżetu projektu i planu wydatków Realizacja zadań na tym etapie wymaga ścisłej współpracy kierownictwa projektu z komórką odpowiedzialną za finansową analizę przedsięwzięć podejmowanych przez organizację. Jest to konieczne w celu określenia wydatków, specyfikacji zamówień oraz ich terminowej realizacji. 5. Określenie struktury zespołu projektowego oraz podział kompetencji i odpowiedzialności 13

14 W ramach zadań realizowanych na tym etapie zostaje ustalona struktura zespołu projektowego, wyodrębnienie mniejszych grup, ich liderów oraz przypisanie im zadań do wykonania zgodnie z ustalonym harmonogramem. 6. Zdefiniowanie zasad komunikacji w zespole oraz przepływów informacji W tak utworzonej strukturze projektowej istotny jest właściwy przypływ informacji. Etap ten jest konieczny do wypracowania środków i kierunków przekazywania informacji tak formalnych jak i nieformalnych. Wszystkie te środki mają zapewnić odpowiednią dystrybucję informacji dotyczących: ogłaszania statusu wykonywanych zadań, poleceń do wykonania, weryfikacji poprawności wykonanych zadań i innych. 7. Wyznaczenie osoby zarządzającej nowym systemem telefonicznym. Czy ma to być administrator sieci komputerowej czy osoba zajmująca się dotychczasową centralą? Ponieważ VoIP wykorzystuje standardową sieć Ethernet oraz obecne IP PBX bardziej przypomina wyposażenie IT niż tradycyjny system telefoniczny PSTN, administrator sieci komputerowej będzie swobodniej zarządzał nowym systemem niż zarządca centrali PBX. 8. Opracowanie strategii szkolenia użytkowników Etap ten jest niezbędny, aby określić potrzeby przyszłych użytkowników systemu w zakresie szkoleń. Zakres zadań niezbędnych do wykonania na tym etapie obejmuje również podstawowy instruktaż w zakresie sposobów wybierania numerów (o ile nastąpiły tutaj modyfikacje). 9. Opracowanie zasad wsparcia dla użytkowników Implementując nowe rozwiązanie zarówno na etapie jego wdrażania, stabilizacji czy eksploatacji niezbędne jest zapewnienie wsparcia dla jego użytkowników. Opracowanie odpowiednich procedur (zgłaszanie problemów, zasady eskalacji, usuwania i powiadamiania o ich usunięciu) stanowi zbiór zadań realizowanych na tym etapie. 14

15 4. Testy jakości głosu oraz konfiguracja środowiska VoIP w IŁ pod kątem zapewnienia jakości głosu Na jakość głosu w sieciach pakietowych wpływają głównie: pasmo IP. opóźnienie pakietów, zastosowany kodek głosu, zmienność opóźnienia pakietów (jitter). Ponieważ w Instytucie Łączności telefonia IP będzie realizowana w oparciu o sieć Internet, to trzeba mieć na uwadze fakt, że z uwagi na brak mechanizmów QoS w Internecie, na większość z tych parametrów można wpływać w bardzo ograniczonym zakresie. Na przykład na opóźnienie pakietów i jego zmienność w zasadzie nie można wpływać. Zwiększenie pasma IP można uzyskać jedynie przez zwiększenie prędkości dostępowej do Internetu u każdego z użytkowników, a i to nie gwarantuje nam uzyskania większej przepływności pomiędzy dwoma punktami w sieci Internet. W związku z tym na jakość połączeń w zasadzie można wpływać na dwa sposoby. Poprzez dobór odpowiednio efektywnego kodeka głosu oraz poprzez dobór odpowiedniej wielkości bufora dla niwelacji zmienności opóźnienia. W tabeli poniżej zestawiono powszechnie stosowane kodeki głosu z określeniem zapotrzebowania na pasmo Tabl. 2 Zapotrzebowanie kodeków audio na pasmo Kodek Algorytm Bit Rate (Kbps) G.711 PCM (Pulse Code Modulation) 64 G.722 SBADPCM (Sub-Band Adaptive Differential Pulse Code Modulation 48, 56, 64 G.723 Multi-rate Coder 5.3 i 6.4 G.726 ADPCM (Adaptive Differential Pulse Code Modulation) 16, 24, 32, 40 G.727 Variable-Rate ADPCM G.728 LD-CELP (Low-Delay Code Excited Linear Prediction 16 G.729 CS-ACELP (Conjugate Structure Algebraic-Code Excited Linear Prediction 8 ILBC Internet Low Bitrate Codec i Speex CELP (Code Excited Linear Prediction) GSM - FULL RATE RPE-LTP (Regular Pulse Excitation Long-Term Prediction) 13 GSM - Enhanced Full Rate ACELP (Algebraic Code Excited Linear Prediction) 12.2 GSM - Half Rate CELP-VSELP (Code Excited Linear Prediction - Vector Sum Excited Linear Prediction) 11.4 Dla transmisji głosu w Internecie konieczne jest zastosowanie kodeka o dużej kompresji i jednocześnie zapewniającego szerokie pasmo przenoszenia dla głosu. Wydaje się, że dla takich zastosowań najodpowiedniejsze będą kodeki G.729a lub ilbc. Ustalenie wartości bufora dla jittera wymagało przeprowadzenia osobnych badań, pozwalających określić optymalna jego wartość. Dlatego w dalszej części tego rozdziału skoncentrowano się głównie na tym zagadnieniu. 15

16 4.1. Zjawisko zmiennego opóźnienia pakietów (jittera) Zjawisko nieregularnego przybywania pakietów do strony odbiorczej (jitter) jest szczególnie istotne w przypadku transmisji danych multimedialnych w pakietowych sieciach rozległych. Przykładowo, zakłada się, że typowe źródła głosu generują pakiety ze stałą szybkością. Algorytm dekompresji po stronie odbiorczej oczekuje, że pakiety głosowe będą przychodziły również ze stałą szybkością. Ze względu na wnoszone przez sieć opóźnienie, które może być różne dla różnych pakietów, pakiety nadawane w równych odstępach czasowych przez stronę nadawczą mogą przybywać do strony odbiorczej w sposób nieregularny. Ze względu na algorytm dekompresji, który wymaga stałych odstępów czasowych między pakietami, problem ten na ogół rozwiązywany jest przez zaimplementowanie po stronie odbiorczej bufora jitter. Bufor ten opóźnia przychodzące pakiety, w celu przekazania ich do części zajmującej się dekompresją w stałych odstępach czasowych. Stosowanie bufora jitter umożliwia również detekcję ewentualnych błędów poprzez kontrolę kolejności przychodzących pakietów. Wartość parametru jitter obliczana jest w pakietowych sieciach rozległych na podstawie odstępów czasowych między kolejnymi odebranymi pakietami (inter-arrival time). Najczęściej w tym celu podaje się dwie wartości: przeciętny czas inter-arrival oraz standardowe odchylenie. W najlepszym przypadku średni czas inter-arrival będzie bardzo zbliżony do odstępów czasowych między emitowanymi pakietami po stronie nadawczej, a standardowe odchylenie będzie niskie. Przy określaniu wariancji opóźnienia dla strumieni audio, ważne jest, aby wziąć pod uwagę trzy zjawiska: eliminację okresów ciszy, utratę pakietu, błędy sekwencji. Mechanizm eliminacji ciszy jest wykorzystywany przez kodeki w punktach końcowych sieci WAN w celu zredukowania liczby wysyłanych pakietów. W ten sposób można zaoszczędzić nawet do 50% dostępnego pasma. Po zaistniałym okresie ciszy w następnym pakiecie ustawia się odpowiedni bit, którego wartość uwzględniana jest podczas określania wartości parametru jitter. W przypadku utraty pakietu, czas inter-arrival między dwoma kolejnymi pakietami będzie duży, nawet jeśli w sieci nie wystąpiła wariancja opóźnienia. Zatem przy jej obliczaniu, w celu uzyskania poprawnych wyników, należy wziąć pod uwagę wymienione zjawiska, kontrolując kolejność pakietów i uwzględniając ewentualną utratę pakietów Bufor niwelujący zjawisko jittera Aby skompensować wahania warunków w sieci, wielu operatorów implementuje bufor jitter w bramach obsługujących przesyłanie danych multimedialnych. Umożliwia on oczekiwanie w pewnym przedziale czasu na spóźnione, bądź brakujące pakiety głosowe, a następnie, po skompletowaniu odpowiedniej liczby pakietów, dokonuje się ich dekompresja. Mechanizm ten służy utrzymaniu odpowiedniej jakości konwersji głosu i stwarza możliwość sterowania jakością. Zwiększa się dzięki temu odporność kodeka na utratę pakietu lub opóźnienie pakietów oraz na inne czynniki związane z transmisją. Z drugiej strony, wadą takiego rozwiązania jest to, że bufor jitter może wprowadzać znaczne opóźnienie. Rozmiar bufora jest konfigurowalny i powinien być optymalizowany dla podanych warunków sieciowych. Zazwyczaj jego wartość jest ustawiona jako wielokrotność oczekiwanego czasu między odebraniem kolejnych pakietów (ang. inter-arrival time), aby zmagazynować całkowitą liczbę pakietów. 16

17 Stosując bufory niwelujące wpływ jittera należy pamiętać, że powiększają one bilans opóźnienia pakietów na drodze pomiędzy dwoma punktami w sieci Istotnym elementem wdrożenia sieci jest więc taki wybór miejsca implementacji buforów, oraz dobranie ich rozmiarów, aby zminimalizować wnoszone opóźnienia, a jednocześnie zmaksymalizować współczynnik jakości połączeń. W przypadku implementacji VoIP w IŁ przyjęto założenie, że połączenia będą inicjowane lub zakańczane przez użytkowników dołączonych do PBX. O ile urządzenia VoIP (w postaci oprogramowania lub rozwiązań sprzętowych) posiadają zazwyczaj zaimplementowane bufory o stałej lub zmiennej wielkości (regulowanej przez użytkownika lub adaptacyjnie), o tyle urządzenia TDM pozostają wobec tego zjawiska bezbronne przenosząc wiernie strumień głosowy. Przyjęto zatem rozwiązanie, polegające na implementacji bufora na styku sieci PSTN i IP w lokalizacji centralnej, co pozwoli zapewnić odpowiedni poziom jakości dla połączeń do/z sieci PSTN w Warszawie. Jednocześnie, styk obu tych sieci w każdej z lokalizacji terenowych jest realizowany w postaci bram analogowych VoIP, które są wyposażone w bufory (jitterbuffers), co zapewnia akceptowalną jakość połączeń dla użytkowników PBX w Gdańsku oraz Wrocławiu. Na rysunku poniżej pokazane zostało rozmieszczenie jitterbufferów w sieci VoIP IŁ. Rys. 2. Zastosowanie buforów niwelujących zjawisko jittera 4.3. Sposób określenia wielkości bufora dla jittera (jitterbuffer) W sieci LAN opóźnienia wnoszone przez procesy przełączania oraz opóźnienia wynikające z granicznej wartości czasu propagacji (ok. 6us/km) nie mają znaczącego wpływu na degradację jakości strumienia głosowego. Połączenia pomiędzy użytkownikami dołączonymi do centrali PBX oraz użytkownikami systemu VoIP charakteryzują się dobrą jakością, a pomiary jakości głosu mierzonej współczynnikiem MOS były zbliżone dla średnich wartości uzyskiwanych dla połączeń głosowych, w których stosowane są typowe kodeki sygnału mowy. Znacznie większy wpływ na postrzeganą jakość głosu posiada transmisja pakietów za pośrednictwem sieci Internet. Dlatego określenie wielkości bufora dla jittera dokonane zostało pod kątem transmisji w Internecie Długookresowe monitorowanie parametrów jakościowych w tunelach Internet-VPN IŁ W celu określenia występujących opóźnień i zmienności opóźnień pakietów IP w tunelach Internet-VPN pomiędzy oddziałem warszawskim, a oddziałami gdańskim i wrocławskim w miesiącach od lutego do września 2006 stale monitorowano wielkości tych parametrów. Wyniki monitorowania 17

18 znalazły się na wykresach poniżej. Wykresy te przedstawiają uśrednione wielkości parametrów w ciągu doby za cały okres monitorowania( uwzględniają również dni wolne od pracy) czas odpowiedzi [ms] :00:01 00:50:01 01:35:01 02:30:01 03:15:01 04:00:01 04:45:01 05:30:01 06:20:01 07:05:01 07:50:01 08:35:01 09:20:01 10:10:01 10:55:01 11:40:01 12:45:01 13:30:01 14:15:01 15:00:01 15:50:02 16:35:01 17:20:01 18:05:01 18:50:01 19:35:01 20:25:01 21:10:01 21:55:01 22:40:01 23:25:01 czas [h] Rys. 3. Uśredniony czas odpowiedzi dla pomiaru pomiędzy odziałem warszawskim oraz wrocławskim jitter [ms] :00:01 00:50:01 01:35:01 02:30:01 03:15:01 04:00:01 04:45:01 05:30:01 06:20:01 07:05:01 07:50:01 08:35:01 09:20:01 10:10:01 10:55:01 11:40:01 12:45:01 13:30:01 14:15:01 15:00:01 15:50:02 16:35:01 17:20:01 18:05:01 18:50:01 19:35:01 20:25:01 21:10:01 21:55:01 22:40:01 23:25:01 czas [h] Rys. 4. Uśredniona wariancja czasu odpowiedzi (jitter) dla pomiaru pomiędzy odziałem warszawskim oraz wrocławskim 18

19 współczynnik utraty pakietów 0,018 0,016 0,014 0,012 0,01 0,008 0,006 0,004 0, :00:01 01:05:01 02:10:01 00:30:01 04:15:02 05:15:01 01:05:01 07:20:01 08:20:01 01:35:01 10:25:01 11:25:01 12:10:01 czas [h] 13:45:01 14:45:01 12:45:01 16:50:01 17:50:02 18:15:01 19:55:01 20:55:01 21:45:01 22:55:01 23:55:01 Rys. 5 Uśredniony współczynnik utraty pakietów dla pomiaru pomiędzy odziałem warszawskim oraz wrocławskim Komentarz do wyników monitorowania parametrów połączenia Internet-VPN pomiędzy oddziałami warszawskim i wrocławskim. Oddział IŁ we Wrocławiu dołączony jest do sieci Internet poprzez łącze DSL o przepływności 2 Mbit/s. Łącze to jest współdzielone z firmami wynajmującymi pomieszczenia w budynkach oddziału wrocławskiego. Przepływność 2 Mbit/s w ocenie OI jest niewystarczająca do świadczenia usługi na dobrym poziomie. Potwierdzają to też wyniki monitorowania parametrów. Obserwując powyższe wykresy można stwierdzić, że zarówno czas odpowiedzi, jak i jitter pozwalają na uruchomienie transmisji VoIP. Jednak istotnym problemem jest to, że w godzinach szczytu występują chwilowe pogorszenia warunków transmisji związane z przepełnieniem łącza do Internetu we Wrocławiu czas odpowiedzi [ms] :00:01 00:50:01 01:35:01 02:30:01 03:15:01 04:00:01 04:45:01 05:30:01 06:20:01 07:05:01 07:50:01 08:35:01 09:20:01 10:10:01 10:55:01 11:40:01 12:45:01 13:30:01 14:15:01 15:00:01 15:50:02 16:35:01 17:20:01 18:05:01 18:50:01 19:35:01 20:25:01 21:10:01 21:55:01 22:40:01 23:25:01 czas [h] Rys. 6. Uśredniony czas odpowiedzi dla pomiaru pomiędzy odziałem warszawskim oraz gdańskim 19

20 :00:01 00:50:01 01:35:01 02:30:01 03:15:01 04:00:01 04:45:01 05:30:01 06:20:01 07:05:01 07:50:01 08:35:01 09:20:01 10:10:01 10:55:01 11:40:01 12:45:01 13:30:01 14:15:01 15:00:01 15:50:02 jitter [ms] 16:35:01 17:20:01 18:05:01 18:50:01 19:35:01 20:25:01 21:10:01 21:55:01 22:40:01 23:25:01 czas [h] Rys. 7. Uśredniona wariancja czasu odpowiedzi (jitter) dla pomiaru pomiędzy odziałem warszawskim oraz gdańskim ,018 0,016 współczynnik utraty pakietów 0,014 0,012 0,01 0,008 0,006 0,004 0, :30:01 01:35:01 02:45:01 03:45:01 04:45:01 05:45:02 06:50:02 07:50:01 08:50:01 09:55:02 10:55:01 11:55:01 13:15:01 14:15:01 15:20:01 16:20:01 17:20:01 18:20:01 19:20:01 20:25:01 21:25:01 22:25:01 23:25:01 czas [h] Rys. 8 Uśredniony współczynnik utraty pakietów dla pomiaru pomiędzy odziałem warszawskim oraz gdańskim Komentarz do wyników monitorowania parametrów połączenia Internet-VPN pomiędzy oddziałami warszawskim i gdańskim. Oddział IŁ we Gdańsku dołączony jest do sieci Internet poprzez łącze TASKu o przepływności 10 Mbit/s. Biorąc pod uwagę niewielką liczbę pracowników w Gdańsku, łącze to powinno gwarantować dobrą jakość telefonii VoIP. Uśrednione czasy odpowiedzi i jittera wskazują, że łącze to ma parametry zbliżone do łącza wrocławskiego. Niemniej szczegółowa analiza wykazała, że połączenie Internet-VPN do Gdańska cechuje bardzo duża zmienność opóźnienia co jest bardzo niekorzystne z punktu widzenia VoIP. Poniżej zamieszczono 7 kolejnych pomiarów ping wykonanych na przestrzeni 1 min. Widać na nich, że są momenty czasowe, w których odpowiedzi są stałe i wynoszą około 30 ms. Ale pojawiają się wyniki pomiarów ping, w których rozrzut czasowy kolejnych pomiarów odpo- 20