OCENA JAKOŚCI KODEKÓW AUDIO W USŁUDZE VOIP

Transkrypt

1 POLITECHNIKA WARSZAWSKA Wydział Elektroniki i Technik Informacyjnych Instytut Telekomunikacji PRACA DYPLOMOWA MAGISTERSKA Tomasz Kabala OCENA JAKOŚCI KODEKÓW AUDIO W USŁUDZE VOIP Kierujący pracą dyplomową: mgr inż. Marcin Golański Opiekun naukowy: prof. dr hab. inż. Andrzej Dąbrowski ocena pracy data i podpis Przewodniczącego Komisji Egzaminacyjnej Warszawa, luty 2012

2

3 Streszczenie Ocena jakości kodeków audio w usłudze VoIP Przedmiotem tej pracy jest przeprowadzenie badań wpływu parametrów sieci na jakość sygnału mowy w usłudze VoIP. Omówiono podstawowe pojęcia związane z telefonią VoIP, metodami oceny jakości sygnału mowy, a także z transmisją multimediów w sieci IP. Dokonano przeglądu narzędzi i metod do oceny jakości sygnału mowy i na jego podstawie zaproponowano stworzenie nowego narzędzia. Opisano proces implementacji omawianego narzędzia oraz wykorzystane przy tym aplikacje i biblioteki. W stworzonym środowisku testowym przeprowadzono badania jakości sygnału mowy. Następnie przedstawiono i omówiono wyniki przeprowadzonych badań.

4

5 Abstract An assessment of audio codecs quality in VoIP service The aim of this thesis is to investigate the influence of network parameters on the quality of voice signal in VoIP service. The basics of VoIP telephony, the methods of assessing voice signal quality and the methods of multimedia transmission in an IP network are described. A review of existing methods and tools for voice signal quality assessment is performed, and, based on the its conclusions, a new tool is proposed. The process of designing and implementing the tool is described, including external applications and libraries that were used. A sequence of tests has been performed using the tool. Their results are presented and discussed.

6

7 Życiorys Tomasz Kabala Kierunek: Telekomunikacja Specjalność: Systemy i sieci telekomunikacyjne Urodzony: 22. maja 1986 r. w Otwocku. Numer indeksu: W 2005 roku ukończyłem naukę w klasie o profilu matematyczno-fizycznym w liceum ogólnokształcącym im. K. I. Gałczyńskiego w Otwocku. W tym samym roku rozpocząłem studia na wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej na kierunku Telekomunikacja. W lutym 2010 roku obroniłem tytuł inżyniera z wynikiem bardzo dobrym....

8

9 Spis treści Spis treści 9 Spis rysunków 11 Spis tabel 13 Spis listingów 14 1 Wstęp Motywacja Cel pracy Układ pracy Transmisja i ocena jakości sygnału mowy Telefonia VoIP Kodeki audio Jakość transmisji w sieci IP Protokół RTP Ocena jakości mowy Miary jakości mowy Metody subiektywne Metody obiektywne Istniejące rozwiązania Sevana AQuA OPERA Pozostałe rozwiązania komercyjne Rozwiązanie akademickie - laboratorium ZST Realizacja Założenia

10 10 SPIS TREŚCI 3.2 Prace wstępne Wybór technologii Java Media Framework Projektowanie aplikacji Interfejs użytkownika Obsługa protokołu RTP Emulacja parametrów sieci Transmisja informacji o próbie Serie pomiarowe Wyznaczanie MOS Generowanie wykresów Przeprowadzone badania Środowisko testowe Zakres badań Wyniki badań Straty pakietów Uszkodzenia pakietów Zmienne opóźnienie Dostępne pasmo Podsumowanie Wnioski z badań Możliwości rozwoju aplikacji Bibliografia 67 Wykaz skrótów 70 A Zawartość płyty 73

11 Spis rysunków 2.1 Schemat działania metody zastosowanej w laboratorium ZST Model przetwarzania danych zastosowany w JMF Główne okno aplikacji VoiLa Okno ustawień Uśredniona wartość przedziałów ufności w funkcji ilości powtórzeń Ocena MOS w funkcji poziomu strat pakietów z 95% przedziałami ufności dla średniej Ocena MOS w funkcji dostępnego pasma z 95% przedziałami ufności dla średniej Ocena MOS w funkcji poziomu strat pakietów z 95% przedziałami ufności dla średniej (kodeki: G.711 µ-law, G.729, GSM FR) Ocena MOS w funkcji poziomu strat pakietów z 95% przedziałami ufności dla średniej (kodeki: Speex/8kHz, ilbc/20ms, SILK/8kHz) Ocena MOS w funkcji poziomu strat pakietów z 95% przedziałami ufności dla średniej (kodeki: Speex/16kHz, SILK/16kHz) Ocena MOS w funkcji poziomu uszkodzeń pakietów z 95% przedziałami ufności dla średniej (kodeki: G.711 µ-law, G.729, GSM FR) Ocena MOS w funkcji poziomu uszkodzeń pakietów z 95% przedziałami ufności dla średniej (kodeki: Speex/8kHz, ilbc/20ms, SILK/8kHz) Ocena MOS w funkcji poziomu uszkodzeń pakietów z 95% przedziałami ufności dla średniej (kodeki: Speex/16kHz, SILK/16kHz) Ocena MOS w funkcji jittera z 95% przedziałami ufności dla średniej (kodeki: G.711 µ-law, G.729, GSM FR) Ocena MOS w funkcji jittera z 95% przedziałami ufności dla średniej (kodeki: Speex/8kHz, ilbc/20ms, SILK/8kHz) Ocena MOS w funkcji jittera z 95% przedziałami ufności dla średniej (kodeki: Speex/16kHz, SILK/16kHz)

12 12 SPIS RYSUNKÓW 4.13 Ocena MOS w funkcji dostępnego pasma z 95% przedziałami ufności dla średniej (kodeki: G.711 µ-law, G.729, GSM FR) Ocena MOS w funkcji dostępnego pasma z 95% przedziałami ufności dla średniej (kodeki: Speex/8kHz, ilbc/20ms, SILK/8kHz) Ocena MOS w funkcji dostępnego pasma z 95% przedziałami ufności dla średniej (kodeki: Speex/16kHz, SILK/16kHz)

13 Spis tabel 2.1 Skala MOS Skala ocen zaproponowana przez ITU-T dla metody ACR Skala ocen zaproponowana przez ITU-T dla metody DCR Parametry emulatora sieci Netem Lista kodeków zaimplementowanych w aplikacji VoiLa Narzut protokołów telekomunikacyjnych wykorzystywanych w VoIP Wymagana dodatkowa przepływność dla wybranych długości ramek

14 Spis listingów 3.1 Fragment klasy Sender Metoda startlistening klasy Receiver Metoda update klasy Receiver Uproszczony kod metody uruchamiającej projekty Przykładowy skrypt programu Gnuplot

15 Rozdział 1 Wstęp 1.1 Motywacja W ciągu ostatnich kilku lat dużą popularność zdobyła usługa telefonii internetowej VoIP (ang. Voice over Internet Protocol). Wykorzystuje się w niej szereg różnych kodeków audio, które mają na celu zapewnienie jak najlepszej jakości przesyłanego sygnału mowy. Jedną z podstawowych przyczyn pogorszenia jakości odbieranego dźwięku są parametry sieci IP, takie jak straty i uszkodzenia pakietów, opóźnienie i jego zmienność (jitter) oraz ograniczona przepustowość łącza. Istnieje kilka narzędzi umożliwiających ocenę jakości sygnału mowy, jednakże żadne z nich nie daje możliwości przeprowadzenia zautomatyzowanej procedury testowej. Często też korzystanie z nich wiąże się z zakupem kosztownej licencji. Jednym z rozwiązań akademickich jest środowisko testowe stworzone w laboratorium ZST (Zakład Systemów Teletransmisyjnych Instytutu Telekomunikacji). Jednak, nawet w tym przypadku, jednym z elementów jest komercyjne oprogramowanie. Spowodowane jest to faktem, że żaden z dostępnych klientów VoIP nie umożliwia przesyłania próbek dźwiękowych w formacie WAVE. 1.2 Cel pracy Celem pracy było wykonanie oceny jakości kodeków audio stosowanych w usłudze VoIP. Po przeprowadzeniu analizy dostępnych narzędzi, została podjęta decyzja o stworzeniu własnej aplikacji pozwalającej zbadać wpływ parametrów sieci na jakość sygnału mowy. Proponowane rozwiązania powinno dawać możliwość uruchomienia długiej serii pomiarów oraz automatycznie zmieniać parametry transmisji. Dodatkowo, tak otrzymane dane powinny być poddawane analizie statystycznej i prezentowane w formie wykresu. Zało- 15

16 Układ pracy żeniem było stworzenie aplikacji, która nie będzie wymagała od użytkownika znajomości żadnego języka programowania oraz nie będzie zawierała żadnych płatnych komponentów. Aby maksymalnie obniżyć koszty wdrożenia oraz stopień skomplikowania rozwiązania, powinna istnieć możliwość uruchomienia całej procedury testowej na jednym komputerze wyposażonym w system Linux. 1.3 Układ pracy Praca została podzielona na pięć rozdziałów. Rozdział 2. zawiera charakterystykę telefonii VoIP wraz z wykorzystywanymi przez nią protokołami oraz omówienie istniejących narzędzi do oceny jakości kodeków audio. Opis implementacji proponowanego rozwiązania oraz wykorzystanych metod i narzędzi znajduję się w rozdziale 3. W rozdziale 4. zostały zamieszczone wyniki badań przeprowadzonych za pomocą stworzonego narzędzia oraz ich analiza. Podsumowanie pracy oraz opis możliwości dalszego rozwoju aplikacji znajduje się w rozdziale 5. Listę plików znajdujących się na dołączonej płycie CD zamieszczono w dodatku A.

17 Rozdział 2 Transmisja i ocena jakości sygnału mowy 2.1 Telefonia VoIP Telefonia VoIP jest szerokim pojęciem, na które składa się zbiór protokołów sieciowych dostarczających usługę transmisji głosu w czasie rzeczywistym za pośrednictwem sieci pakietowej jaką jest Internet. Przeprowadzenie rozmowy telefonicznej za pośrednictwem VoIP składa się z następujących etapów: zestawienie kanału transmisyjnego za pomocą protokołów sygnalizacyjnych; konwersja analogowo-cyfrowa sygnału mowy; kodowanie; podział na pakiety oraz ich przesłanie. Odbierając strumień z sieci wykonuje się wyżej wymienione czynności w odwrotnej kolejności, czyli: odbiór pakietu IP, dekodowanie oraz konwersja cyfrowo-analogowa celem odtworzenia oryginalnego sygnału. W zależności od zastosowania istnieje możliwość użycia różnorodnych kodeków audio, od kodeków wąskopasmowych o wysokim stopniu kompresji, aż po kodeki szerokopasmowe charakteryzujące się doskonałą jakością dźwięku. Wykorzystuje się również szereg protokołów sieciowych, taki jak na przykład protokoły sygnalizacyjne H.323 oraz SIP (ang. Session Initiation Protocol). W celu zapewnienia mechanizmu negocjacji parametrów sesji stosuje się protokół SDP (ang. Session Description Protocol). Za transport strumieni audio odpowiedzialne są protokoły RTP (ang. Real-time Transport Protocol) oraz RTCP (ang. Real-time Transport Control Protocol), które z racji wykorzystania w omawianym rozwiązaniu zostaną szerzej opisane w punkcie Rozpowszechnienie szerokopasmowego dostępu do Internetu było jedną z przyczyn zwiększenia popularności usługi VoIP. Użytkownicy mają możliwość korzystania z telefonu za pomocą usługi VoIP w dokładnie ten sam sposób jak korzystali z telefonii tradycyjnej PSTN (ang. Public switched telephone network). Mogą do tego wykorzystać bramki 17

18 Telefonia VoIP VoIP, do których podłącza się telefon analogowy albo też dedykowany aparat telefoniczny podłączany bezpośrednio do sieci lokalnej. Istnieje również możliwość korzystania z usługi VoIP poprzez instalację oprogramowania (tzw. softphone) na komputerze wyposażonym w słuchawki i mikrofon, często też tego typu aplikacje mogą zostać uruchomione na telefonie komórkowym. Telefonia VoIP ma wiele zalet w porównaniu z tradycyjną telefonią PSTN. Koszt wdrożenia jest o wiele niższy, ponieważ nie wymaga tworzenia dedykowanej sieci, a dodatkowo istnieje możliwość wykonywania wielu połączeń jednocześnie za pomocą pojedynczego łącza szerokopasmowego. Ceny połączeń krajowych jak i zagranicznych są również o wiele niższe, dostawcy często też oferują bezpłatne połączenia wewnątrzsieciowe. Użytkownicy, przy wyborze dostawcy, nie są ograniczeni tylko do tych lokalnych, a co więcej, usługa VoIP jest w pełni mobilna, czyli nie jest przypisana do konkretnej lokalizacji i może być świadczona wszędzie, gdzie istnieje połączenie z Internetem. W usłudze VoIP są dostępne mechanizmy bezpieczeństwa nie spotykane do tej pory w telefonii tradycyjnej. W tej ostatniej, szyfrowanie rozmowy telefonicznej mogło nie dojść do skutku, z powodu na przykład cyfrowej transmisji między centralami Kodeki audio Poniżej znajduje się krótka charakterystyka kilku wybranych kodeków audio wykorzystywanych w usłudze VoIP. Wszystkie poniższe kodeki zostały zbadane za pomocą narzędzia tworzonego w ramach niniejszej pracy, natomiast wyniki tych badań zostały zamieszczone w rozdziale 4. G.711 G.711 jest standardem kompresji audio stworzonym przez ITU-T (ang. International Telecommunication Union - Telecommunication Standardization Sector) w 1972 roku [1]. Często określa się go mianem PCM (ang. Pulse-Code Modulation). Stosuje się w nim częstotliwość próbkowania o wartości 8000 próbek na sekundę, kodując każdą próbkę za pomocą 8 bitów, co daje w rezultacie przepływność wyjściową o wartości 64 kb/s. Wyróżnia się dwa warianty standardu różniące się algorytmem kompresji: µ-law (wykorzystywany w Ameryce Północnej i Japonii) oraz A-law (wykorzystywany w Europie i pozostałych krajach). G.711 µ-law oferuje większą rozdzielczość dla sygnałów o wyższej wartości, natomiast G.711 A-law używa większej ilości poziomów kwantyzacji dla sygnałów o mniejszej wartości.

19 Rozdział 2. Transmisja i ocena jakości sygnału mowy 19 G.729 Najmniejszą przepływność wynoszącą zaledwie 8 kb/s, wśród standardów stworzonych przez ITU-T, oferuje opracowany w 1995 roku standard G.729 [2]. Pomimo niskiej przepływności charakteryzuje się on bardzo dobrą jakością transmisji, oraz niskimi opóźnieniami dzięki zastosowaniu ramek o długości 20 ms. Niestety, doskonała jakość okupiona jest dużą złożonością obliczeniową oraz dużymi wymaganiami sprzętowymi. Jest on oparty na kodowaniu CS-ACELP (ang. Conjugate-Structure Algebraic Code-Excited Linear Prediction), a częstotliwość próbkowania wynosi 8000 Hz. Rozwiązania zastosowane w G.729 są opatentowane, a właścicielem praw patentowych jest firma Sipro Lab Telecom [3]. Używanie tego kodeka wiąże się z uiszczeniem opłat licencyjnych, jednakże istnieją eksperymentalne implementacje do użytku niekomercyjnego. Jedną z nich jest referencyjna implementacja dołączona do rekomendacji ITU-T, która została użyta podczas tworzenia tej pracy. GSM Standard kodowania dźwięku wykorzystywany w telefonii GSM (ang. Global System for Mobile Communications) początkowo zawierał dwa kodeki: HR (ang. Half Rate) oparty na algorytmie VSELP (ang. Vector-Sum Excited Linear Prediction) [4] oraz FR (ang. Full Rate) używający algorytmu RPE-LTP (ang. Regular Pulse Excitation - Long Term Prediction) [5]. Wymagały one odpowiednio 6,5 kb/s i 13 kb/s, czyli pół lub całą szczelinę czasową GSM. W roku 1997 dodano dwa nowe kodeki: EFR (ang. Enhanced Full Rate) [6] - oferujący lepszą jakość mowy przy takiej samej przepływności jak FR; AMR (ang. Adaptive Multi Rate) - potrafiący dynamicznie zmieniać przepływność w zakresie od 4,75 do 12,2 kb/s [7]. Oba nowe rozwiązania wykorzystywały algorytm ACELP (ang. Algebraic-Code-Excited Linear Prediction). Wszystkie zastosowane w telefonii GSM kodeki są otwartymi standardami, nie wymagającymi uiszczania opłat licencyjnych. Kodeki te charakteryzują się bardzo małą złożoność obliczeniową, ponieważ wykorzystywane były w urządzeniach mobilnych nie dysponujących, przynajmniej w początkowej fazie rozwoju sieci GSM, dużą wydajnością. Dzięki temu możliwe jest wykorzystanie tych rozwiązań także poza siecią GSM, między innymi w transmisji VoIP. Zwłaszcza dlatego, że pozwalają one osiągnąć zadowalającą jakość dźwięku przy dosyć niskim zapotrzebowaniu na pasmo. Na potrzeby badań przeprowadzonych w ramach niniejszej pracy został wybrany wariant FR kodeka GSM.

20 Telefonia VoIP Speex Finalna wersja standardu Speex ukazała się w roku 2003 [8], rok po rozpoczęciu prac nad projektem, który miał na celu stworzenie otwartego standardu kompresji dźwięku na potrzeby, między innymi, transmisji VoIP. Speex jest rozwijany przez fundację Xiph. Jego użytkowanie nie jest ograniczone prawem patentowym, a dystrybucja odbywa się zgodnie z zasadami licencji BSD (w wersji opracowanej na potrzeby fundacji Xiph). Używa się w nim algorytmu CELP (ang. Code-Excited Linear Prediction) oraz częstotliwości próbkowania 8, 16 lub 32 khz. Aplikacja stworzona na potrzeby tej pracy umożliwia wykorzystanie wszystkich trzech wariantów próbkowania, ale z racji na ograniczenia algorytmu PESQ, o którym więcej można przeczytać w punkcie 2.2.3, badane są tylko dwa pierwsze. ilbc Standard ilbc (ang. Internet Low Bitrate Codec) został stworzony w 2004 roku przez firmę Global IP Solutions [9]. Zaprojektowano go z myślą o aplikacjach VoIP, a także o nadawaniu podcastów oraz archiwizacji danych głosowych. Obecnie jest własnością firmy Google i jest bezpłatnie rozpowszechniany wraz z kodem źródłowym do użytku prywatnego, jak i komercyjnego na zasadach licencji BSD. Jest to kodek wąskopasmowy o częstotliwości próbkowania 8 khz, działający w oparciu o algorytm BI-LPC (ang. Block- Independent Linear Predictive Coding). Kodek ten umożliwia przesyłania sygnału mowy w ramkach o długości 20 lub 30 ms, wykorzystując przy tym odpowiednio 15,2 i 13,3 kb/s pasma. W stworzonej aplikacji testowej można korzystać z obydwu wariantów. SILK Kodek SILK został stworzony przez firmę Skype Limited i zaprezentowany szerszemu gronu użytkowników wraz z premierą wersji 4.0 programu Skype w marcu 2009 roku [10]. Kod źródłowy kodeka został udostępniony bezpłatnie programistom i producentom sprzętu. SILK potrafi pracować aż z czterema różnymi częstotliwościami próbkowania: 8, 12, 16 lub 24 khz, co czyni go kodekiem świetnie sprawdzającym się podczas transmisji sygnału mowy jak i muzyki. Wymagane pasmo mieści się w zakresie od 6 do 40 kb/s, a długość ramki wynosi 20 ms. W niniejszej pracy zostały zbadane właściwości kodeka pracującego z częstotliwością próbkowania 8 i 16 khz Jakość transmisji w sieci IP Sieć IP, wykorzystywana w usłudze VoIP, jest nieprzystosowana do przesyłania strumieni dźwiękowych w czasie rzeczywistym. W przeciwieństwie do telefonii tradycyjnej PSTN,

21 Rozdział 2. Transmisja i ocena jakości sygnału mowy 21 nie są rezerwowane zasoby potrzebne do przeprowadzenia rozmowy. Wspierana jest tylko jedna usługa sieciowa tj. best effort, czyli przesyłania danych z najwyższą możliwą jakością bez jakichkolwiek gwarancji QoS (ang. Quality of Service). Straty pakietów Jedną z podstawowych metryk określających jakość sieci IP jest poziom strat pakietów PLR (ang. Packet Loss Ratio). Określa ona stosunek liczby pakietów straconych do liczby pakietów wysłanych w danym okresie pomiarowym z tym, że za stratę pakietu uznaje się również sytuację, gdy pakiet nie dociera do celu przed upływem ustalonego z góry czasu (time-out). Straty pakietów mogą być spowodowane na przykład chwilowymi przeciążeniami w sieci lub błędami transmisji w medium fizycznym. W sieci IP brak jest jakichkolwiek mechanizmów przeciw przeciążeniowych i sterowania ruchem. Mechanizmy te dostarcza protokół warstwy transportowej TCP (ang. Transmission Control Protocol), jednakże w przypadku transmisji w czasie rzeczywistym bardziej korzystnym rozwiązaniem jest użycie protokołu UDP (ang. User Datagram Protocol). Jednak brak kontroli dostępnego pasma i mechanizmu retransmisji obarczone jest dużym ryzykiem utraty pakietu, jednocześnie oferując najmniejszy poziom opóźnień. Z punktu widzenia użytkownika usługi VoIP straty pojedynczych pakietów mogą być niezauważalne, ponieważ większość kodeków jest wyposażona w mechanizmy, które pozwalają zamaskować tego typu braki. Natomiast poważny wpływ na jakość transmisji dźwięku mogą mieć straty pakietów sięgające kilku procent, co zostało zbadane i opisane w rozdziale 4. Opóźnienie Wspomniane wyżej opóźnienie jest również bardzo istotną metryką z punktu widzenia poziomu jakości transmisji głosowych. O ile podczas transmisji jednostronnej stały poziom opóźnienia jest nieodczuwalny, to podczas konwersacji może mieć znaczący wpływ na jej jakość, a nawet może ją uniemożliwić. Na opóźnienie w usłudze VoIP ma wpływ wiele czynników takich jak na przykład próbkowanie i kodowanie sygnału mowy w nadajniku, pakietyzacja, kolejkowanie pakietów w węzłach sieciowych oraz dekodowanie w odbiorniku. Ważnym elementem mającym wpływ na opóźnienie jest złożoność obliczeniowa algorytmu kodowania, ponieważ nie zawsze klient VoIP dysponuje odpowiednią wydajnością, szczególnie jeśli jest to urządzenie mobilne. Kolejnym elementem wprowadzającym stałe opóźnienie jest długość ramki wykorzystywanej w kodeku, czyli częstotliwość z jaką próbki składane są w pojedynczy pakiet. Jednakże największe opóźnienie wprowadza sama transmisja w sieci IP, a jego wartość może zależeć miedzy innymi od fizycznej odległości pomiędzy nadajnikiem a odbiornikiem.

22 Telefonia VoIP Jitter Na całkowite opóźnienie w transmisji, oprócz stałych elementów wymienionych powyżej, ma wpływ wiele czynników zmiennych w czasie. Parametr ten określa się jako wariancje opóźnienia (ang. delay varation, jitter). Zjawisko to wynika z bezpołączeniowego trybu transmisji w sieci IP, gdzie każdy pakiet zawiera pełna informacje adresową i przesyłany jest przez sieć niezależnie. Może nawet dojść do sytuacji, że do odbiornika w pierwszej kolejności dociera pakiet wysłany jako drugi. Aby zminimalizować to zjawisko stosuje się tzw. bufor jitter, który kolejkuje przychodzące pakiety i układa je w odpowiedniej kolejności jeśli ta została zachwiana. Niestety taki zabieg wprowadza dodatkowe, stałe opóźnienie. Przepływność Kolejną ważną metryką, określającą właściwości połączenia sieciowego i mającą wpływ na jakość transmisji VoIP, jest dostępna przepływność (ang. Available bandwidth, AvB). Jak już wcześniej wspomniano, do transmisji w czasie rzeczywistym najbardziej odpowiedni jest protokół transportowy UDP. W przeciwieństwie do protokołu TCP, który wykorzystuje algorytm slow-start, protokół UDP pozwala wykorzystać cała dostępną przepustowość już po rozpoczęciu transmisji. Na całkowitą przepływność, jaka jest wymagana do przeprowadzenia rozmowy VoIP, składa się kilka elementów. Najważniejszy składnik to przepływność strumienia danych jakie generuje sam kodek, przykładowe wartości zostały podane w punkcie Potem dodawany jest narzut w postaci nagłówków wszystkich protokołów nadrzędnych. Każda ramka jest enkapsulwowana kolejno w: pakiet protokołu RTP; segment protokołu UDP i finalnie w ramkę protokołu warstwy sieciowej, czyli na przykład Ethernet. Dodatkowo też, przesyłane co pewien czas pakiety protokołu kontrolnego RTCP również zwiększają sumaryczną przepływność. Powyższy opis dotyczy transmisji jednostronnej, więc do przeprowadzenia konwersacji za pomocą usługi VoIP koniecznie jest zapewnienie dwa razy większej przepływności. Jest to ważne w przypadku sieci dostępowych o łączach niesymetrycznych, gdzie przepływność od użytkownika w stronę sieci jest o wiele mniejsza niż prędkość pobierania danych. Wszystkie powyżej wymienione metryki mają duży wpływ na jakość transmisji dźwięku. Najlepszą metodą poprawy jakości jest dobór odpowiedniego kodeka, odpornego na negatywne parametry sieci. Dlatego też bardzo istotną kwestią jest możliwość sprawnego badania kodeków w zmiennych warunkach, o czym traktuje niniejsza praca.

23 Rozdział 2. Transmisja i ocena jakości sygnału mowy Protokół RTP Standard RTP (ang. Real-time Transport Protocol) definiuje format pakietów służących do przesyłania w czasie rzeczywistym dźwięku i obrazu przez sieć IP. Został zaproponowany przez IETF (ang. Internet Engineering Task Force) w roku 1996 w dokumencie RFC 1889 [11], jego najnowsza wersja została opublikowana w 2003 roku w dokumencie RFC 3550 [12]. Składa się on z dwóch protokołów RTP oraz RTCP (ang. Real-Time Transport Control Protocol). Pierwszy z nich przenosi dane multimedialne, natomiast drugi okresowo przesyła informacje kontrolne oraz parametry QoS. Jednym z podstawowych założeń protokołu RTP było zagwarantowanie wsparcia dla wielu kodeków multimedialnych oraz możliwość dodania nowych bez ingerencji w strukturę nagłówka pakietu. Protokół RTP umożliwia wysyłanie danych do wielu odbiorców za pomocą multicastowych adresów IP. Wprowadza on mechanizmy służące do kompensacji jittera oraz wykrywania zmiany kolejności odbieranych pakietów. Większość implementacji standardu RTP jako warstwę transportową wykorzystuje protokół UDP (ang. User Datagram Protocol), który nie posiada mechanizmu retransmisji i pozwala osiągnąć najwyższą możliwą prędkość transmisji. Dla każdego strumienia multimedialnego zestawia się pojedynczą sesję RTP, co na przykład przy przesyłaniu dwóch strumieni z obrazem i dźwiękiem daje możliwość odbiorcy zrezygnowania z jednego z nich. Na potrzeby sesji rezerwowane są dwa porty, zgodnie ze specyfikacją port RTP powinien być parzysty, natomiast port RTCP powinien być o jeden większy. Informacje przekazywane w pakietach RTP zawierają m.in.: znacznik czasowy (ang. Timestamp); numer sekwencyjny oraz pole określające format zawartości (ang. Payload Type). Znacznik czasowy informuje odbiornik w jakich odstępach czasowych powinien odtwarzać próbki. W przypadku transmisji wielu strumieni każdy z nich będzie posiadał własny niezależny znacznik czasowy. Aby zapewnić synchronizację pomiędzy strumieniami stosuje się bezwzględny znacznik czasowy (liczba sekund od północy 1 stycznia 1900 roku) przesyłany za pomocą protokołu RTCP. Numer sekwencyjny jest inicjowany losową wartością i zwiększany o jeden w każdym kolejnym pakiecie. Pomaga on odtworzyć oryginalną kolejność pakietów oraz wykrywać straty pakietów. Standard RTP nie zapewnia żadnych mechanizmów odtwarzania straconych pakietów, funkcjonalność ta powinna być realizowana przez wybrany kodek. Pole Payload Type - PT określa za pomocą jakiego kodeka zostały zakodowane dane przesyłane w pakiecie. Mapowanie pomiędzy identyfikatorami PT a odpowiadającymi im profilami ustala się podczas inicjowania sesji za pomocą protokołu SDP. Protokół RTCP zbiera statystyki dotyczące sesji takie jak ilość przesłanych i straconych pakietów, opóźnienie oraz jitter. Aplikacja może wykorzystywać te dane, aby kontro-

24 Ocena jakości mowy lować parametry QoS i odpowiednio reagować na zaistniałe sytuacje, na przykład poprzez zmianę przepływności lub typu kodeka. W celu uniknięcia przeciążenia sieci zastosowano mechanizm dynamicznego dobierania częstotliwości wysyłania pakietów RTCP, aby nie przekroczyć wartości ok. 5% pasma wykorzystywanego przez sesję. Wyróżnia się kilka typów wiadomości przesyłanych za pomocą protokołu RTCP. Statystyki na temat wysłanych pakietów oraz znacznik czasowy służący do synchronizacji strumieni przesyłany jest w wiadomości Sender Report. Informacje od pasywnych uczestników transmisji, dotyczące QoS, zawarte są w wiadomości Receiver Report. Wiadomość Source Description zawiera nazwę kanoniczną (CNAME) nadawcy oraz może również przenosić dodatkowe informacje takie jak nazwa, adres czy numer telefonu. W przypadku kiedy uczestnik sesji chce zakończyć swój udział wysyła wiadomość End of participation. 2.2 Ocena jakości mowy Istnieje wiele czynników mających wpływ na jakość mowy. Jednym z nich jest rodzaj zastosowanego toru transmisyjnego. Wyróżniamy takie jego rodzaje jak: sieć IP (opisana w punkcie 2.1.2), sieć telefonii tradycyjnej PSTN oraz sieć telefonii komórkowej GSM i UMTS. Za szczególny przypadek toru transmisyjnego należy uznać też proces zapisu sygnału mowy na nośniku jakim jest na przykład płyta winylowa, płyta CD lub plik mp3. W przypadku zapisu cyfrowego należy też wziąć pod uwagę rodzaj kodeka. Kolejnym ważnym czynnikiem jest charakterystyka percepcyjna układ słuchowego odbiorcy, jego koncentracja i stan emocjonalny. W przypadku nadawcy istotne są czynniki takie jak na przykład: płeć, język komunikatu, tempo mówienia, dykcja. Wszystkie powyżej wymienione czynniki powodują, że bardzo trudne jest jednoznaczne określenie jakości mowy. Poniżej zostaną opisane przykładowe miary jakości i metody jej pomiaru oraz kilka narzędzi, które się w tym celu wykorzystuje Miary jakości mowy Miary, jakie są wykorzystywane do określenia jakości mowy, można podzielić na dwie grupy: obiektywne i subiektywne. Do obiektywnych zaliczamy takie parametry jak na przykład stosunek sygnału do szumu (ang. Signal to Noise Ratio, SNR) lub też odległość spektralną badanego sygnału (ang. Spectral Distance). Więcej typów miar obiektywnych oraz poziom ich korelacji z wynikami badań subiektywnych można znaleźć w pracy [13]; Najpopularniejszą wśród miar obiektywnych jest skala MOS (ang. Mean Opinion Score), zaproponowana w zaleceniu ITU-T P.800 [14]. Określa ona poziom jakości sygnału

25 Rozdział 2. Transmisja i ocena jakości sygnału mowy 25 mowy za pomocą średniej po ocenach przyznanych przez słuchaczy podczas testów odsłuchowych. Oceny wybierane są z zakresu od 1 do 5 a ich dokładny opis znajduję się w tabeli 2.1. Ocena Jakość mowy 5 doskonała 4 dobra 3 zadowalająca 2 słaba 1 zła Tabela 2.1: Skala MOS Metody subiektywne Subiektywne metody pomiaru jakości dźwięku pozwalają osiągnąć najlepsze rezultaty, lecz niestety są kosztowne a ich realizacja wymaga poświęcenia dużej ilości czasu. Wymagają one przeprowadzenia testów odsłuchowych, podczas których słuchacze, opierając się na swoich wrażeniach słuchowych, oceniają jakość dźwięku w odpowiedniej skali ocen. Wymogi dotyczące przeprowadzania tego typu testów zostały zamieszczone w zaleceniu ITU-T P.800 [14]. Grupa słuchaczy powinna składać się z minimum 12 osób, przeszkolonych pod kątem testów odsłuchowych, ale ani zawodowo, ani osobiście nie związanych z badaniami jakości dźwięku. Podczas odsłuchu należy zapewnić komfortowe i powtarzalne warunki, jak najbardziej zbliżone do naturalnych. Przed rozpoczęciem testów należy przygotować nagrania zawierające fragmenty mowy, zarówno męskiej jak i żeńskiej. Najczęściej są to zdania bądź pojedyncze słowa nie powiązane semantycznie. Lektorzy powinni charakteryzować się doskonałą dykcją. Następnie dla wszystkich parametrów, które mogą mieć wpływ na jakość dźwięku, nagrania przesyłane są przez system i odtwarzane słuchaczom. Istnieje kilka metod i skal w jakich ocenia się badany sygnał, kilka z nich zostanie omówionych poniżej. Metoda ACR Ze względu na łatwość realizacji, jedną z popularniejszych metod subiektywnych jest metoda ACR (ang. Absolute Category Rating). Nagrania testowe są oceniane przez słuchaczy

26 Ocena jakości mowy w pięciostopniowej skali w trzech kategoriach: jakość mowy, wysiłek słuchowy 1, preferowana głośność (Tabela 2.2). Słuchacze nie mają możliwości odsłuchania oryginalnych nagrań. Dla każdej kategorii obliczana jest wartość MOS będąca średnią oceną słuchaczy dla wszystkich badanych parametrów, osobno dla lektorów męskich i żeńskich. Ocena ta jest równoważna ocenie MOS-LQO (ang. MOS - Listening Quality, Objective), która dokładniej zostanie omówiona w punkcie Ocena Kategoria Jakość mowy Wysiłek słuchowy Preferowana głośność 5 doskonała całkowite rozluźnienie; znacznie głośniej niż potrzeba brak wysiłku 4 dobra wymagana uwaga; głośniej niż potrzeba nieznaczny wysiłek 3 zadowalająca umiarkowany wysiłek preferowana głośność 2 słaba znaczny wysiłek ciszej niż potrzeba 1 zła zdanie niezrozumiałe; znacznie ciszej niż potrzeba maksymalny wysiłek Tabela 2.2: Skala ocen zaproponowana przez ITU-T dla metody ACR Metoda DCR Metoda DCR (ang. Degradation Category Rating) często wykorzystywana jest w przypadku kiedy metoda ACR nie daję zadowalających rezultatów. W przypadku metody DCR słuchaczom przedstawiane są pary próbek dźwiękowych: nagranie wzorcowe o wysokiej jakości oraz nagranie po przesłaniu przez badany system. Celem określenia wrażliwości słuchaczy i dokładności pomiaru stosuję się pary zerowe, czyli pary składające się z dwóch oryginalnych próbek. Oceny przyznawane są według pięciostopniowej skali degradacyjnej (Tablica 2.3). Po uśrednieniu wszystkich ocen po słuchaczach i lektorach dla każdego badanego parametru otrzymuje się ocenę DMOS (ang. Degradation Mean Opinion Score). Porównywanie nagrań oryginalnych i zdegradowanych jest podstawą działania metod obiektywnych, takich jak PESQ [15] czy POLQA [16]. Metody subiektywne są coraz rzadziej wykorzystywane ze względu na duże koszta i konieczność zorganizowania sformalizowanych testów odsłuchowych. Jednak są konieczne 1 wysiłek wymagany do zrozumienia sensu zdania

27 Rozdział 2. Transmisja i ocena jakości sygnału mowy 27 Ocena Degradacja sygnału mowy 5 degradacja niesłyszalna 4 degradacja słyszalna ale nie przeszkadzająca 3 degradacja nieznacznie przeszkadzająca 2 degradacja przeszkadzająca 1 degradacja bardzo przeszkadzająca Tabela 2.3: Skala ocen zaproponowana przez ITU-T dla metody DCR do kalibracji metod subiektywnych, celem określenia ich skuteczności. Wszystkie metody subiektywne dają w rezultacie ocenę w skali MOS bezpośrednio lub pośrednio, dzięki czemu istnieje możliwość łatwego porównywania ich Metody obiektywne Metody obiektywne w porównaniu do metod subiektywnych są o wiele prostsze w realizacji. Nie wymagają organizowania testów odsłuchowych, ani szkoleń dla uczestników. Często ich działanie opiera się na rozwiązaniach sprzętowych, bądź programowych. Metody te dzieli się na trzy kategorie: metody parametryczne, intruzyjne i nieintruzyjne. Metody parametryczne pozwalają określić jakość sygnału mowy na podstawie parametrów połączenia, za pomocą którego jest transmitowany. Wykorzystuje się takie parametry jak na przykład: zmienność opóźnienia, bitowa stopa błędów czy też zastosowany kodek. Metody nieintruzyjne pozwalają określić jakość badanego sygnału bez ingerencji w system testowy. Ocena wyznaczana jest na podstawie charakterystycznych zniekształceń sygnału, takich jak na przykład: stosunek sygnału do szumu SNR czy odległość spektralna. Działanie metod intruzyjnych polega na porównaniu sygnału wzorcowego z sygnałem zdegradowanym, powstałym w wyniku transmisji przez badany system. Dwie metody intruzyjne, w tym metoda PESQ wykorzystana w stworzonej aplikacji, zostały omówione poniżej. Metoda PESQ Metoda PESQ (ang. Perceptual Evaluation of Speech Quality) została zaproponowana przez ITU-T w roku 2001 w dokumencie P.862 [15]. Przyczyną jej powstania był brak dobrej metody obiektywnej, która w swojej ocenie uwzględniałaby wpływ zniekształceń wprowadzanych podczas transmisji w sieci IP. Tworzono ją wzorując się na już istnieją-

28 Ocena jakości mowy cych metodach PAMS (ang. Perceptual Analysis/Measurement System) oraz PSQM (ang. Perceptual Speech Quality Measure). W roku 2003 w zaleceniu P [17] wprowadzano funkcję mapującą wyniki PESQ (tzw. Raw-MOS) na skalę MOS-LQO (ang. MOS - Listening Quality, Objective). Dwa lata później rozszerzono działanie algorytmu o możliwość badania sygnałów szerokopasmowych, o częstotliwości od 50 do 7000 Hz (Zalecenie ITU-T P [18]). Do tej pory metoda wspierała tylko sygnały wąskopasmowe (częstotliwość od 300 do 3100 Hz). Jak wcześniej wspomniano metoda PESQ jest metodą intruzyjną, czyli do działania potrzebuje sygnału oryginalnego oraz zdegradowanego. Ocena MOS jest wyznaczana na podstawie różnić pomiędzy sygnałami. Poniżej zostaną opisane poszczególne etapy analizy sygnału przez algorytm PESQ. Pierwszym etapem działania algorytmu jest zrównanie poziomów głośności obu sygnałów, ponieważ w badanym systemie może wystąpić stłumienie sygnału, a nawet w niektórych przypadkach jego wzmocnienie. Najczęściej sygnał mowy jest odtwarzany i nagrywany za pomocą słuchawki telefonicznej, dlatego też, żeby uwzględnić jej wpływ, badany sygnał jest filtrowany. Używa się w tym celu filtru IRS (ang. Intermediate Reference System), którego charakterystyka częstotliwościowa została stworzona na podstawie wielu testów odsłuchowych. Kolejnym, bardzo istotnym etapem jest dopasowanie czasowe, które pozwala określić opóźnienie sygnału oraz zlokalizować brakujące fragmenty. W pierwszej kolejności wyznaczane jest opóźnienie całego sygnału, a następnie, w wyniku podziału na pojedyncze wyrażenia, opóźnienia poszczególnych fragmentów. Gwarantuje to, że w końcowym etapie działania algorytmu będą porównywane odpowiednie fragmenty sygnału. Następnie dokonuje się przekształceń sygnałów, celem zniwelowania różnic wynikających z takich zjawisk jak na przykład transmitancja badanego systemu czy też chwilowe zmiany wzmocnienia. Tak przekształcone sygnały można poddać analizie percepcyjnej, której efektem jest wyznaczenie gęstości zniekształcenia symetrycznego i asymetrycznego. Współczynniki te określają stopień zdegradowania sygnału po przesłaniu przez badany system. Wysoki współczynnik gęstości zniekształcenia może też oznaczać błąd na etapie dopasowania czasowego, dlatego ten etap jest powtarzany dla fragmentów o wysokim współczynniku. Ostatecznym efektem działania algorytmu jest średnia wartość zniekształcenia symetrycznego i asymetrycznego. Finalna wartość MOS (w zakresie od -0,5 do 4,5) jest efektem kombinacji liniowej wyżej wymienionych wartości średnich. Współczynniki tej kombinacji liniowej zostały ustalone w wyniku przeprowadzenia wielu subiektywnych testów odsłuchowych. Dzięki zmianom wprowadzonym w zaleceniu P istnieje możliwość przema-

29 Rozdział 2. Transmisja i ocena jakości sygnału mowy 29 powania tej wartości na ocenę MOS-LQO (wartości od 1,02 do 4,56). Istnieją przypadki, w których wyniki otrzymane za pomocą metody PESQ różnią się od wyników testów odsłuchowych, jednakże w większości przypadków istnieje korelacja z ocenami przyznanymi przez słuchaczy. Metoda PESQ jest obecnie najpopularniejszą metodą obiektywną pomiaru jakości sygnału mowy i często wykorzystywana jest do kalibracji metod nieintruzyjnych. Metoda POLQA Prace nad następcą PESQ trwały od 2006 roku, a jego finalna wersja ukazała się w zaleceniu ITU-T P.863 w roku 2011 pod nazwą POLQA (ang. Perceptual Objective Listening Quality Assessment) [16]. Miała ona oferować jeszcze lepsze rezultaty niż PESQ, bardziej skorelowane z wynikami testów subiektywnych, a także umożliwić badanie sygnałów mowy o większych częstotliwościach. Oprócz sygnałów wąskopasmowych i szerokopasmowych znanych z metody PESQ, obsługiwane są również sygnały super-szerokopasmowe o częstotliwości od 50 do Hz. Podobnie jak w algorytmie PESQ na początku następuje oszacowanie opóźnienia całego sygnału, jak i poszczególnych jego fragmentów. Następnie wyznacza się częstotliwość próbkowania sygnału zdegradowanego. Jeśli różnica pomiędzy częstotliwościami próbkowania jest znacząca, sygnał o większej częstotliwości jest konwertowany do częstotliwości próbkowania drugiego sygnału. Po takim zabiegu ponawia się proces dopasowania czasowego. Cała procedura jest powtarzana, aż do momentu kiedy różnica częstotliwości próbkowania będzie mniejsza niż 1%. Tak przekształcone sygnały są przekazywane do modelu percepcyjnego, o wiele bardziej rozbudowanego niż w metodzie PESQ. Jego zadanie polega na określeniu, które z zakłóceń występujących w sygnale zdegradowanym będą odczuwalne i jak bardzo będą przeszkadzać. W wypadku algorytmu POLQA efektem działania również są oceny w skali Raw-MOS i MOS-LQO. 2.3 Istniejące rozwiązania Proponowane w niniejszej pracy rozwiązanie nie jest pierwszym zintegrowanym środowiskiem do badania jakości dźwięku. Poniżej zostaną przedstawione krótkie charakterystyki istniejących rozwiązań.

30 Istniejące rozwiązania Sevana AQuA Oprogramowania AQuA (ang. Audio Codecs Quality Analyzer) fińskiej firmy Sevana jest narzędziem do porównywania jakość plików audio [19]. Najprostszym zastosowaniem aplikacji jest porównywanie dwóch plików audio, na przykład oryginalnego pliku nagranego przez lektora oraz pliku zdegradowanego po przesłaniu przez badany system. Aplikacja posiada interfejs tekstowy, dzięki czemu łatwo integruje się z większymi środowiskami testowymi. Jedną z ciekawszych funkcji programu jest wbudowany generator sygnałów testowych. Wygenerowane przez niego pliki audio mogą być wykorzystane zamiast nagrań lektorów. Dodatkowo aplikacja pozwala przetestować dowolny kodek audio, o ile będzie on dostępny w formie biblioteki (np. plik DLL w systemie Windows). AQuA wykorzystuje autorski algorytm, który według zapewnień autorów pozawala osiągnąć rezultaty bardziej zbliżone do wyników testów subiektywnych niż PESQ. Rezultatem działania programu jest procentowa wartość podobieństwa dwóch sygnałów oraz estymowana ocena MOS. Oprócz tych informacji generowany jest raport z działania algorytmu, który może zawierać wskazówki pomagające określić potencjalną przyczynę spadku jakości. Oprogramowanie AQuA występuje w trzech wariantach: AQuA Voice (8kHz, Mono); AQuA HD Voice (16kHz kHz, Mono/Stereo) AQuA WB (16kHz kHz, Mono/Stereo) Z punktu widzenia omawianego problemu, czyli oceny jakości kodeków audio, aplikacja ta mogłaby być wykorzystana do analizy plików zdegradowanych. Jednakże nie byłoby to rozwiązanie kompleksowe, ponieważ oprogramowanie AQuA nie jest wyposażone w moduł, który umożliwiałby przesyłanie próbek dźwiękowych za pomocą protokołu RTP. Najtańsza wersja AQuA Voice kosztuje 1000 za licencję, a najdroższa AQuA WB Dodatkowo za wsparcie i aktualizacje twórcy pobierają roczną opłatę od 200 do 260 rocznie. Pojedyncza licencja umożliwia uruchomienie jednocześnie tylko jednego testu. Jeśli wymagana jest praca współbieżna, konieczne jest zakupienie dodatkowych licencji. Wyżej wymienione ceny pochodzą z oferty handlowej sporządzonej w czerwcu 2011 roku.

31 Rozdział 2. Transmisja i ocena jakości sygnału mowy OPERA Producentem rodziny oprogramowania OPERA (ang. Objective Perceptual Analyzer) jest niemiecka firma Opticom [20]. Firma Opticom od lat bierze aktywny udział w procesie standaryzacji obiektywnych metod pomiaru jakości dźwięku. Metody pomiaru jakości wspierane przez to oprogramowanie to: PESQ, PSQM, PSQM+, PSQM/IP oraz PEAQ. Aplikacja umożliwia przeprowadzenie kompleksowych testów jakości (end-to-end). Rozwiązanie zaproponowane przez producenta charakteryzuje się dużą skalowalnością. W najprostszej konfiguracji jest to przenośny komputer klasy PC wyposażony w interfejsy umożliwiające podłączenie do sieci PSTN. Dodatkowo można wyposażyć takie urządzenie w interfejsy do sieci ISDN, GSM czy też VoIP. W najbardziej zaawansowanej wersji jest to grupa węzłów testowych, na przykład w formie maszyn serwerowych, rozproszonych po badanej sieci. Komunikacja między nimi odbywa się za pomocą protokołu IP. Zarządzanie siecią węzłów testowych może odbywać się z dowolnego punku za pośrednictwem programu OPERA Control Center. Istnieje też możliwość zakupu samego oprogramowania OPERA Software Suite i operowania na plikach WAVE. Pomiary mogą być wykonywane ręcznie lub ustalane według harmonogramu. Aplikacja wyposażona jest w rozbudowany język skryptowy służący to automatyzacji procesu pomiarowego. Ze wszystkich dostępnych na rynku rozwiązań, oprogramowanie OPERA prawdopodobnie byłoby najlepszym narzędziem umożliwiającym wykonanie zadania określonego w temacie niniejszej pracy. Mimo, że z założenia aplikacja ta przeznaczona jest do badania rzeczywistych warunków, możliwe byłoby zintegrowanie jej z jednym z symulatorów sieci. W czerwcu 2011 roku producent oferował oprogramowanie OPERA Software Suite (bez sprzętu) w cenie Pozostałe rozwiązania komercyjne Oprócz wyżej wymienionych aplikacji, istnieje jeszcze wiele programów i urządzeń służących do analizy jakości dźwięku. Poniżej zostaną krótko opisane rozwiązania, które były brane pod uwagę podczas poszukiwania odpowiedniego narzędzia. Jednym z tego typu narzędzi jest, działająca pod kontrolą systemu Windows, aplikacja Q-Master Voice System [21] firmy QoE Systems. Pozwala ona testować poprawność działania usług głosowych w sieci operatora, wykorzystując w tym celu algorytm PESQ. Może wysyłać i odbierać sygnały za pomocą połączenia VoIP lub też zwykłego połączenia telefonicznego. Wyposażona jest też w możliwość podłączenia bezpośrednio do słuchawki

32 Istniejące rozwiązania telefonu. Kolejnym rozwiązaniem programowym jest aplikacja Trafficlyser [22] firmy Nextragen. Jest to oprogramowanie przeznaczone do generowania i analizy ruchu w sieciach VoIP. Po dokupieniu dodatkowej licencji umożliwia również analizę zebranego materiału za pomocą algorytmu PESQ. Oprócz rozwiązań sprzętowych istnieją też tak zwane testery VoIP. Jednym z nich jest produkt firmy Trend - Unipro VoIP [23], który jest przenośnym urządzeniem służącym do weryfikacji usługi VoIP w sieciach przewodowych oraz bezprzewodowych. Umożliwia on emulowanie połączenia VoIP i obliczanie jego oceny MOS, a także zapewnia pełną obsługę protokołu SIP. Innym przykładem testera VoIP jest model 925VST [24] firmy Sage. Możliwe jest podłączenie go bezpośrednio do sieci PSTN lub, w przypadku telefonów VoIP, w miejsce słuchawki telefonicznej. Oprócz oceny MOS wyznaczanej za pomocą algorytmu PESQ, urządzenie potrafi również zmierzyć opóźnienie, jitter czy też straty pakietów. Kolejnym narzędziem wykorzystywanym przez operatorów sieci do monitorowania jakości połączeń jest seria urządzeń PowerProbe [25] firmy Tektronix. Można je wykorzystywać w sieciach VoIP jak również PSTN, GSM lub UMTS. W zależności od modelu, urządzenia te montuje się w sieciach szkieletowych, dostępowych lub bezpośrednio u abonenta. Jedną z ciekawszych możliwości jakie udostępnia to rozwiązanie, z punktu widzenia tematu pracy, jest instalacja dodatkowego pakietu PESQ Test Agent, który oprócz wyznaczania oceny w skali MOS, udostępnia wiele metryk określających jakość dźwięku Rozwiązanie akademickie - laboratorium ZST W laboratorium Zakładu Systemów Teletransmisyjnych Instytut Telekomunikacji zostało stworzone środowisko testowe służące między innymi do badania jakości sygnału mowy w usłudze VoIP za pomocą algorytmu PESQ [26]. Powstanie tego środowiskami było inspiracją do stworzenia rozwiązania prezentowanego w tej pracy. Jego schemat znajduje się na rysunku 2.1. W skład środowiska testowego wchodzą dwie stacje klienckie oraz serwer. Urządzenia połączone są za pomocą sieci LAN, a komunikację pomiędzy stacjami zapewnia serwer, na którym zainstalowane jest oprogramowanie Netem służące do modyfikacji parametrów sieci. Na obu komputerach zainstalowany jest klient VoIP - w tym przypadku jest to Ekiga. Jako, że żaden ze znanych klientów VoIP nie umożliwia transmisji plików WAVE bezpośrednio, wykorzystuje się tutaj program VAC (ang. Virtual Audio Cable). Program ten instaluje się jako wirtualna karta dźwiękowa i umożliwia przesyłanie strumieni audio po-

33 RTP Rozdział 2. Transmisja i ocena jakości sygnału mowy 33 między aplikacjami. Do odtwarzania i nagrywania plików WAVE zostały użyte programy Cool Edit Pro 2 oraz Recordpad Sound Recorder. Procedura testowa polegała na ustawieniu odpowiednich parametrów sieci na serwerze. Następnie zestawiane było połączenie pomiędzy dwoma klientami VoIP, a na jednym z nich rozpoczynało się odtwarzanie próbki dźwiękowej. Na drugiej stacji należało uruchomić nagrywanie i po skończonej transmisji otrzymywano dwie próbki, które można było bezpośrednio poddać analizie za pomocą algorytmu PESQ. Stacja kliencka 1 Serwer Cool Edit Pro odtwarzanie Virtual Audio Cable Ekiga softphone RTP Netem modyfikacja parametrów sieci Plik WAVE oryginalny Stacja kliencka 2 RecordPad nagrywanie Virtual Audio Cable Ekiga softphone PESQ Plik WAVE zdegradowany Raw-MOS MOS-LQO Rysunek 2.1: Schemat działania metody zastosowanej w laboratorium ZST

34

35 Rozdział 3 Realizacja W ramach niniejszej pracy zostało zaproponowane nowe narzędzie do pomiaru jakości sygnału mowy w usłudze VoIP. W rozdziale tym zostaną opisane etapy jego tworzenia, a także zostaną omówione wykorzystane aplikacje i biblioteki. 3.1 Założenia Celem pracy było wykonanie oceny jakości kodeków audio w usłudze VoIP, a co za tym idzie, przygotowanie środowiska testowego, które umożliwiałoby wykonanie tego zadania. Tak jak wspomniano w punkcie nie jest możliwe użycie w tym celu standardowego klienta VoIP. Koniecznym okazało się stworzenie aplikacji, która byłaby w stanie wysłać i odebrać za pomocą protokołu RTP plik WAVE zapisany na dysku. Efektem pracy byłaby para plików (oryginalny i zdegradowany), które następnie byłyby przekazywane do analizy za pomocą metody PESQ. Wynik działania tego algorytmu określałby jakość próbki zdegradowanej w skali Raw-MOS i LQO-MOS. Podstawowym wymogiem, jaki miała spełniać aplikacja, była pełna automatyzacja procedury pomiarowej, tak aby jak najmniej czynności wymagało interwencji użytkownika. Spowodowane było to faktem, iż podczas tego typu pomiarów, konieczne jest wielokrotne przesyłanie próbek dźwiękowych, co może potrwać nawet kilka godzin. Aby wynik pojedynczej próby był miarodajny, należy powtórzyć ją kilkukrotnie, a wynik uśrednić. Proces taki należy następnie powtórzyć dla wszystkich badanych parametrów sieci oraz dla wszystkich wykorzystywanych próbek dźwiękowych. Dodatkowo aplikacja powinna automatycznie zmieniać parametry sieci pomiędzy próbami. Efektem końcowym takiej procedury pomiarowej powinna być duża ilość plików WA- VE, dlatego też aplikacja powinna posiadać mechanizm pozwalający zidentyfikować te pliki, określić odpowiadający im plik oryginalny, wykorzystany kodek czy parametry sie- 35

36 Prace wstępne ci. Informacje takie powinny być przesyłane pomiędzy instancjami programu poprzez sieć IP. Zebrane w ten sposób dane powinny być poddawane analizie statystycznej, jednocześnie zapewniając dostęp do wyników pojedynczej próby. Jako nazwę projektu został wybrany skrót VoiLa, którego rozwinięciem jest VoIP Laboratory, podkreślający związek aplikacji z badaniami oraz usługą VoIP. 3.2 Prace wstępne Pracę rozpoczęto od przetestowania kilku dostępnych na rynku klientów VoIP (tzw. softphone, SP), takich jak na przykład: Ekiga [27], X-Lite [28] czy też Jitsi [29]. Celem testów było sprawdzenie, jakie kodeki są popularne wśród obecnie używanych klientów VoIP. Kolejnym krokiem była obserwacja strumienia RTP przesyłanego pomiędzy klientami, celem lepszego zapoznania się z tym protokołem. Konieczne okazało się zainstalowanie własnego serwera VoIP. Początkowo wybrany został, jeden z popularniejszych serwerów, Asterisk [30]. Umożliwiał on zestawienie połączenia pomiędzy dwoma klientami, ale tylko za pomocą kodeków, które były zainstalowane wraz z serwerem. Następnie przetestowany został serwer minisipserver [31], który już umożliwiał wykorzystanie dowolnego kodeka, o ile ten był wspierany przez używany softphone. Obserwacja ramek przesyłających pakiety protokołu RTP, jak i RTCP odbywały się za pomocą programu Wireshark [32]. Ostatnim etapem przygotowań był wybór odpowiednich narzędzi i bibliotek, które dokładniej zostały opisane poniżej. Z ich pomocą została stworzona aplikacja proof of concept, która miała za zadanie zweryfikowanie wyboru i określenie, czy możliwe jest stworzenie omawianego środowiska testowego. 3.3 Wybór technologii Projekt VoiLa został napisany w języku Java, ponieważ oferuje on możliwość znacznie szybszego tworzenia i testowania aplikacji niż na przykład C/C++. Dodatkową zaletą jest łatwe przenoszenie aplikacji pomiędzy systemami, na których jest zainstalowana wirtualna maszyna Javy. Programom uruchamianym w starszych wersjach Javy często zarzucano wolniejsze działanie w porównaniu z aplikacjami napisanymi w językach natywnie kompilowanych. Jednakże w najnowszych wersjach różnice te są już prawie niedostrzegalne. Tym bardziej przy projektach takich jak VoiLa, gdzie nie przewiduje się dużego zapotrzebowania na moc obliczeniową i pamięć operacyjną. Podstawową kwestią przy tworzeniu projektu był wybór frameworka, który zapewniłby implementację protokołu RTP oraz mechanizm kodowania strumienia audio za pomocą

37 Rozdział 3. Realizacja 37 wybranych kodeków. Istnieją dwa popularne frameworki napisane w języku Java: Java Media Framework (JMF ) [33] oraz Freedom for Media in Java (FMJ ) [34]. Ostatecznie został wybrany JMF, argumentacja tego wyboru, a także dokładny opis frameworka został zamieszczony w kolejnym punkcie. Całość aplikacji powstała w środowisku programistycznym Eclipse [35], który jest jednym z najpopularniejszych środowisk dla języka Java. Oprogramowanie to było zainstalowane na 64-bitowym systemie Ubuntu w wersji Pomimo, że tworzenie aplikacji było projektem jednoosobowym, zastosowano system kontroli wersji Subversion (SVN ) [36]. Pozwoliło to na łatwą synchronizację kodu pomiędzy komputerami oraz, w razie potrzeby, cofniecie się do wcześniejszej wersji aplikacji. Użycie serwera SVN zapewniło również cykliczne tworzenie kopii bezpieczeństwa. W projekcie został zastosowany emulator sieci Netem (Network Emulator) [37]. Jest on standardowym składnikiem jądra linuksowego w wersji 2.6. Z tego powodu, jak już wcześniej wspomniano, używanym systemem operacyjnym jest Ubuntu, które daje bezpośredni dostęp do tego narzędzia. Netem może być uruchomiony na dowolnym interfejsie sieciowym, również na interfejsie lokalnym localhost, co umożliwia uruchomienie VoiLa na pojedynczej maszynie. W przypadku środowiska testowego składającego się z dwóch maszyn, wystarczy uruchomić Netem na jednej z nich. Emulator sieci Netem umożliwia modyfikację wielu parametrów sieci, takich jak: stałe i zmienne opóźnienie (jitter); rozkład prawdopodobieństwa opóźnienia; straty pakietów; duplikacja pakietów; uszkodzenia pakietów; zmiana kolejności pakietów; dostępne pasmo. Dodatkowo możliwe jest też zdefiniowanie korelacji dla wszystkich zmiennych parametrów. Określa on stopień podobieństwa pomiędzy następującymi po sobie wartościami losowymi. Określenie oceny przesłanych próbek dźwiękowych zapewnia implementacja algorytmu PESQ, którego kod źródłowy w języku C został zamieszczony w załączniku do zalecenia ITU-T P.862 [15]. Na potrzeby pracy kod został zmodyfikowany, aby wprowadzić obsługę długich nazw plików. Następnie został skompilowany pod systemem Ubuntu w dwóch

38 Wybór technologii wersja: 32 i 64-bitowej. Obie wersje zostały dostarczone wraz z aplikacją VoiLa, która to automatycznie wybiera, z której wersji należy korzystać. Zostało ustalone, że końcowym efektem pracy programu będzie wykres, na którym będzie można porównać uśrednioną ocenę jakości przy zmiennych parametrach sieci dla dwóch lub więcej kodeków. Aby możliwe było określenie, na podstawie wykresu, który kodek oferuje lepszą jakość, konieczne było wyznaczenie przedziałów ufności dla uśrednianych ocen. W przypadku badań przeprowadzonych w ramach niniejszej pracy zdecydowano się na 95 % przedziały ufności. Oznacza to przedział, w którym z prawdopodobieństwem 95 % znajduje się wartość oczekiwana wszystkich ocen. Dopiero nienachodzące na siebie przedziały ufności pozwalają określić, który z kodeków pozwala osiągnąć lepszą jakość. W celu wykonania analizy statystycznej otrzymanych ocen, czyli obliczenia wartości średniej, wariancji oraz przedziałów ufności wykorzystano bibliotekę Colt w wersji [38]. Jest to zestaw bibliotek open-source owych, napisanych w języku Java, służących do wykonywania wysokowydajnych obliczeń naukowych. Colt został stworzony w 1999 roku przez organizację CERN, najnowsza wersja została opublikowana w sierpniu 2004 roku. Inną rozważaną opcją była własnoręczna implementacja odpowiednich wzorów statystycznych, jednakże wymagałaby ona dokładnego przetestowania pod kątem poprawności wyników oraz zapewne nie oferowałaby tak dużej wydajności obliczeniowej jak Colt. Kolejną decyzją jaką należało podjąć był wybór metody generowania wykresów. Pierwszą rozważaną opcją było użycie biblioteki JFreeChart [39], która pozwala na generowanie wielu rodzajów wykresów bezpośrednio w aplikacji, także ich eksport do plików graficznych. Takie rozwiązanie pozwalałoby w bardzo przejrzysty sposób zaprezentować wyniki działania wewnątrz aplikacji. Jednakże cały mechanizm manipulowania wykresami musiałby być zaimplementowany w samej aplikacji, co zwiększyłoby stopień skomplikowania rozwiązania, nie wnosząc nic do samej pracy. Należało wybrać narzędzie, które pozwoli zmieniać parametry wykresów poza programem. Możliwości takie oferowało linuksowe narzędzie Gnuplot [40]. Dzięki takiemu podejściu, sama aplikacja zamiast nieedytowalnego pliku graficznego generuje plik tekstowy z danymi liczbowymi, jakie mają się znaleźć na wykresie. Następnie uruchamiany jest program Gnuplot, który tworzy wykres według zdefiniowanych parametrów. W razie zaistnienia takiej potrzeby, generowanie wykresu można ponowić już niezależnie od aplikacji. Dokładny opis mechanizmu tworzenia wykresów znajduje się w punkcie

39 Rozdział 3. Realizacja Java Media Framework Framework JMF jest zbiorem bibliotek dodającym do aplikacji, napisanych w języku Java, obsługę plików audio i wideo. Pierwsza wersja ukazała się w roku 1997, natomiast wersja 2.0, wzbogacona o możliwość transmisji strumieniowej, w roku Projekt VoiLa wykorzystuje najnowszą wersję (2.1.1e), która ukazała się w maju 2003 roku. Od tamtej pory firma Sun Microsystems (obecnie Oracle Corporation) nie opublikowała żadnej aktualizacji. Fakt taki można by uznać za czynnik uniemożliwiający użycie takiej biblioteki, jednakże w protokole RTP oraz w implementacji podstawowych kodeków również nie nastąpiły żadne poważne zmiany. Dzięki mechanizmowi pluginów, w jaki wyposażony jest framework, w łatwy sposób można zwiększyć liczbę kodeków. W roku 2006 społeczność używająca JMF postanowiła stworzyć jego open-source owy odpowiednik. W ten sposób powstał projekt FMJ, który docelowo miał zastąpić JMF, wprowadzając dodatkowo wszystkie nowe rozwiązania, jakie w między czasie pojawiły się na rynku. Niestety projekt nie został ukończony, prace zostały wstrzymane w listopadzie 2007 roku. Z tego powodu framework ten, pomimo że młodszy od JMF, nie został wybrany do projektu VoiLa. Możliwości jakie oferuje framework JMF to między innymi: odtwarzanie plików multimedialnych; przechwytywanie dźwięku z mikrofonu oraz obrazu z kamery; transmisja w czasie rzeczywistym multimediów przez Internet; przetwarzanie multimediów (zmiana formatu, dodawanie efektów); zapisywanie multimediów do pliku. Oprócz podstawowej wersji JMF dostępne są również specjalne wersje (Performance Pack) przystosowane do systemów Windows, Linux oraz Solaris. Wykorzystując interfejs JNI (ang. Java Native Interface) mogą one używać natywnych bibliotek, przygotowanych dla wyżej wymienionych systemów, celem zwiększenia wydajności. W frameworku JMF wszystkie szczegóły implementacyjne ukryte są za API (ang. Application Programming Interface), które jest wspólne dla wszystkich powyższych wersji. Framework JMF wykorzystuje aspekty programowania sterowanego zdarzeniami do komunikacji pomiędzy obiektami. Łatwiejsze tworzenie nowych obiektów jest zapewnione dzięki wykorzystaniu wzorca projektowego fabryki abstrakcyjnej. Z punktu widzenia pracy, najważniejszą cechą jest pełna obsługa protokołu RTP wraz z zestawianiem i zarządzaniem sesjami. Architektura JMF jest bardzo elastyczna i intuicyjna, w ogólności wszystkie obiekty można podzielić na trzy grupy:

40 Wybór technologii Wejście Opisuje źródło multimediów, może to być urządzenie do przechwytywaniu obrazu lub dźwięku takie jak kamera czy mikrofon, plik znajdujący się na dysku bądź strumień RTP przychodzący z sieci. Proces przetwarzania Tutaj wykonywane są wszystkie działania na danych wejściowych takie jak konwertowanie czy dodawanie efektów. Sygnały mogą być multipleksowane lub demultipleksowane, jeśli jest więcej wyjść lub wejść. Procesy przetwarzania mogą być łączone w łańcuchy, gdzie wyjście jednego stanowi wejście drugiego. Wyjście Opisuje co ma się stać z multimediami po przetworzeniu. Mogą zostać one zapisanie na dysku, odtworzone bądź też przesłane do sieci za pomocą protokołu RTP. Schemat modelu wykorzystywany przez JMF został zamieszczony na rysunku 3.1. Wejście Przechwytywanie obrazu i dźwięku Odczyt pliku z dysku Odbiór transmisji z sieci Proces przetwarzania Dodawanie efektów Zmiana formatowania Multipleksacja Demultipleksacja Wyjście Odtwarzanie Zapis do pliku Transmisja do sieci Rysunek 3.1: Model przetwarzania danych zastosowany w JMF

41 Rozdział 3. Realizacja Projektowanie aplikacji Poniżej zostaną opisane zagadnienia związane z projektowaniem najważniejszych elementów aplikacji oraz zostanie krótko omówiony algorytm działania proponowanej metody Interfejs użytkownika W omawianej aplikacji wykorzystano graficzny interfejs użytkownika, zapewniając w ten sposób łatwiejszą obsługę programu w przypadku przeprowadzania pojedynczej próby pomiarowej, jak i całej serii. Przy tworzeniu projektu zastosowano model projektowy MVC (ang. Model-View-Controller), czyli oddzielono warstwę prezentacyjną od warstwy aplikacji. Główne okno aplikacji zostało przedstawione na rysunku 3.2. Składa się ono ze standardowych elementów takich jak menu główne i pasek narzędziowy. Funkcje jakie można uruchomić za pomocą tego menu to między innymi: zmienić folder wejściowy i wyjściowy; odczytać i zapisać plik projektu; przesłać pojedynczą próbkę (po wybraniu kodeka i parametrów sieci); uruchomić nasłuch na zadanym porcie; dodać wybrane pliki do projektu razem z ustawionymi parametrami sieci i kodekiem; otworzyć okno dialogowe z ustawieniami; odtworzyć wybrany plik WAVE. Centralna część aplikacji podzielona jest na cztery części (panele): Panel nadawczy Zawiera listę plików znajdujących się w folderze wejściowym. Tutaj powinny znajdować się wzorcowe pliki WAVE, które mają zostać przesłane za pomocą protokołu RTP. Na dole znajduje się lista wyboru kodeków dostępnych w aplikacji. Panel odbiorczy Zawiera listę plików znajdujących się w folderze wyjściowym, w którym zapisywane są odebrane pliki. Poniżej znajduje się przycisk uruchamiający obliczenia wartości MOS dla wszystkich plików w folderze wyjściowym oraz pole w którym wyświetla się wartość Raw-MOS i MOS-LQO dla zaznaczonego pliku.

42 Projektowanie aplikacji Panel Netem Zawiera wszystkie możliwe parametry emulatora sieci Netem. Każde z pól tekstowych może zawierać pojedynczą wartość parametru. Za pomocą odpowiedniego przycisku jedno z pól można ustawić jako pole zawierające serie parametrów. Serię taką określa się za pomocą trzech liczb, które oznaczają odpowiednio wartość początkową, wartość o jaką zwiększa się parametr oraz wartość końcową. Panel projektu Zawiera listę zadań należących do otwartego projektu. Pojedyncze zadanie składa się z listy plików jakie będą przesyłane, używanego kodeka, listy parametrów sieciowych oraz ilości powtórzeń próby. Znajdują się tam również przyciski służące do manipulowania zadaniami projektowymi. Wpisy z używanego w aplikacji systemu logowania log4j [41] znajdują się na liście w dolnej części okna. Tam trafiają tylko wpisy informacyjne, ostrzeżenia oraz błędy, natomiast wszystkie wpisy zapisywane są w pliku znajdującym się w katalogu programu. Rysunek 3.3 przedstawia okno z ustawieniami aplikacji. Rysunek 3.2: Główne okno aplikacji VoiLa Obsługa protokołu RTP Za obsługę protokołu RTP odpowiedzialne są dwie klasy: Sender oraz Receiver. Pierwsza z nich umożliwia wysłanie strumienia RTP, natomiast druga odpowiada za jego odbiór.

43 Rozdział 3. Realizacja 43 Rysunek 3.3: Okno ustawień Fragment klasy Sender odpowiedzialny za przesłanie pliku WAVE znajduje się na listingu 3.1. Dla zwiększenia czytelności kodu usunięto wszystkie fragmenty odpowiedzialne za obsługę błędów. Wartości zmiennych określających nazwy plików, kodeki oraz adresy IP zostały podane w kodzie. Za zarządzanie sesjami RTP odpowiedzialna jest klasa RTPManager, dlatego w pierwszej kolejności należy utworzyć jej nową instancję. Potrzebny też będzie obiekt MediaLocator określający lokalizację pliku, który ma być wysłany. Wszystkie metody wspomagające pracę z JMF zostały zebrane w klasie JmfUtils. Jedną z tych metod jest addcustomformats, która odpowiada za rejestrowanie nowych kodeków w klasie RTPManager. Każdy rodzaj kodowania ma swój własny numer Payload Type, część z nich stały, a część dynamiczny [42]. Podczas standardowej rozmowy VoIP numery dynamiczne ustalane są między stronami za pomocą protokołu SDP. W przypadku aplikacji VoiLa, gdzie przesyłane są tylko strumienie RTP, wszystkie numery muszą być przypisane na stałe i mieć takie same wartości we wszystkich instancjach, czemu właśnie służy metoda addcustomformats Następnie na podstawie obiektu MediaLocator tworzony jest obiekt DataSource, będący reprezentacją źródła próbki dźwiękowej. Źródło to posłuży do stworzenia obiektu Processor, który odpowiada za proces przetwarzania. Po ustaleniu parametrów przetwarzania (AudioFormat i ContentDescriptor) tworzony jest kolejny obiekt DataSource