Realizacja usług Voice over IP i Video over IP w

Transkrypt

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:
02.30.005.6
07.30.003.6
Warszawa, grudzień 2006
Realizacja usług Voice over IP i Video over IP w sieciach operatorskich i korporacyjnych.
Realizacja usług Voice over IP i Video over IP w sieciach operatorskich i korporacyjnych
Praca nr
02.30.005.6
07.30.003.6
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
mgr inż. Michał Gartkiewicz
mgr inż. Konrad Sienkiewicz
inż. Waldemar Latoszek
inż. Urszula Cackowska
mgr inż. Danuta Latoszek
mgr inż. Grzegorz Wójcik
mgr inż. Dominik Łoniewski
mgr inż. Piotr Jankowski
mgr inż. Adam Cichoń
mgr inż. Dariusz Gacoń
mgr inż. Wacław Białkowski
Kierownik Zakładu: mgr inż. Dariusz Gacoń
© Copyright by Instytut Łączności, Warszawa 2006
Z-2
Z-2
Z-2
Z-2
Z-2
Z-2
OI
OI
OI
OI
Z-2
Z-2
Spis treści
Spis treści
3
1. Wprowadzenie
5
1.1.
Cel pracy
5
1.2.
Sposób realizacji
5
1.3.
Podsumowanie
6
2. Ogólne wymagania na parametry jakościowe sieci dla usług czasu rzeczywistego
8
2.1.
Wymagania jakościowe
8
2.1.1.
Wymagania na transmisję głosu w sieciach pakietowych
8
2.1.2.
Wymagania na transmisję obrazów w sieciach pakietowych
10
3. Aspekty organizacyjne wdrażania telefonii VoIP w sieci korporacyjnej
13
4. Testy jakości głosu oraz konfiguracja środowiska VoIP w IŁ pod kątem zapewnienia
jakości głosu
15
4.1.
Zjawisko zmiennego opóźnienia pakietów (jittera)
16
4.2.
Bufor niwelujący zjawisko jittera
16
4.3.
Sposób określenia wielkości bufora dla jittera (jitterbuffer)
17
4.3.1.
Długookresowe monitorowanie parametrów jakościowych w tunelach Internet-VPN IŁ
17
4.3.2.
Testy jakości mowy
22
4.3.2.1. Testy jakości mowy dla połączeń VoIP w internetowym kanale Internet-VPN do Wrocławia 23
4.3.2.2. Testy jakości mowy dla połączeń VoIP w sieci LAN
28
4.4.
30
Podsumowanie przeprowadzonych badań
5. Testy funkcjonalności i usług dodatkowych platformy VoIP opartej o
rozwiązanie Asterisk
31
5.1.
Badania transmisji faksowej
31
5.2.
Ocena systemu poczty głosowej
33
5.3.
Testy funkcjonalności Call Center
35
5.4.
Usługa Follow Me
36
5.5.
Testy IVR
37
5.6.
Połączenia konferencyjne
38
5.7.
Połączenia video
40
6. Testy funkcjonalne i użytkowe sprzętowych i programowych terminali VoIP
43
7. Platforma VoIP w Instytucie Łączności
59
7.1.
Wybór platformy
59
7.2.
Rozwiązania rekomendowane do stosowania w sieci VoIP Instytutu Łączności
59
7.3.
Integracja z systemem telefonicznym Instytutu Łączności
60
7.3.1.
Konfiguracja systemów telefonicznych w IŁ
60
3
7.3.2.
Plan numeracyjny w Instytucie Łączności
61
7.3.3.
Wykaz zmian w konfiguracji centrali PBX Hicom 300E w siedzibie IŁ w Warszawie
62
7.4.
System poczty głosowej
63
7.5.
Interaktywne menu głosowe – IVR
64
7.6.
Założenie organizacyjne systemu VoIP
65
8. Porównanie platformy Asterisk z oferowanymi komercyjnie rozwiązaniami IP-PBX
66
8.1.
Asterisk
66
8.2.
Rozwiązania firmy Cisco
70
8.3.
Rozwiązania firmy Alcatel
71
8.4.
Rozwiązania firmy 3Com
73
8.5.
Rozwiązania firmy Avaya
73
8.6.
Rozwiązania firmy Siemens
74
Bibliografia
76
Spis skrótów
77
Załącznik 1
79
4
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.
1.2. 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
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.
b.
c.
d.
e.
f.
g.
Zarządzanie systemem (konfiguracją, użytkownikami, usługami),
Pocztę głosową;
IVR
Transmisję faksową
Transmisję video
Połączenia konferencyjne
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.
1.3. 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, Voicemail, fax2email).
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
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
2. Ogólne wymagania na parametry jakościowe sieci dla usług czasu rzeczywistego
2.1. Wymagania jakościowe
2.1.1. 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.723.1 opóźnienie przetwarzania równe jest około 30 ms.
8
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
Ethernet II
IPv4
TCP
Dane HTTP oraz
narzut związany z
obsługą
okna
transmisyjnego
RAZEM (bajtów)
RAZEM (% rozmiaru pakietu) 1
Maksymalna wielkość nagłówka
wyrażona w bajtach
Przyjęta w badaniach narzędzi
testowych wielkość nagłówka
wyrażona w bajtach
26
72
38
20
60
20
20
60
20
5
15
71
Nie mniej niż 192
93
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
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.
2.1.2. 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
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
•
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
Obrazy wideo
brak,
Poziom 2
małe okna,
nierównomierne
dostarczanie,
stratna kompresja
Poziom 3
porównywalne z
jakością taśmy wideo
VHS,
przełączane kanały
wideo
Poziom 4
zastosowanie w:
a) telewizji rozsiewczej
b) studia nagraniowe
c) HDTV
przełączane kanały
wideo
Audio
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
Tekst
Grafika/animacja
Obrazy
pojedyncza ramka
zauważalne
paleta VGA
opóźnienia
zauważalne opóźnierównomierne
nienia
dostarczanie
brak animacji
pojedynczy
obraz
znaczące
opóźnienia
brak widocznych opóźnień
jednostajne
dostarczanie
dostarczanie slajdów w trybie „non
real time”
pojedynczy
obraz
znaczące
opóźnienia
jednostajne
dostarczanie
brak zauważalnych
opóźnień w prezentacji grafiki
animacja obrazkowa
jednostajne
dostarczanie
brak zauważalnych
opóźnień w prezentacji grafiki
animacja obrazkowa
12
pojedynczy
obraz
dostarczanie w
trybie „non real
time”
pojedynczy
obraz
brak zauważalnych opóźnień
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
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
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
16-40
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
13.33 i 15.20
Speex
CELP (Code Excited Linear Prediction)
2.15 - 44.2
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
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.
4.2. 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
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.
4.3.1. 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
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).
172.29.10.12
250
czas odpowiedzi [ms]
200
150
100
50
23:25:01
22:40:01
21:55:01
21:10:01
20:25:01
19:35:01
18:50:01
18:05:01
17:20:01
16:35:01
15:50:02
15:00:01
14:15:01
13:30:01
12:45:01
11:40:01
10:55:01
10:10:01
09:20:01
08:35:01
07:50:01
07:05:01
06:20:01
05:30:01
04:45:01
04:00:01
03:15:01
02:30:01
01:35:01
00:50:01
00:00:01
0
czas [h]
Rys. 3. Uśredniony czas odpowiedzi dla pomiaru pomiędzy odziałem warszawskim oraz wrocławskim
172.29.10.12
70
60
jitter [ms]
50
40
30
20
10
23:25:01
22:40:01
21:55:01
21:10:01
20:25:01
19:35:01
18:50:01
18:05:01
17:20:01
16:35:01
15:50:02
15:00:01
14:15:01
13:30:01
12:45:01
11:40:01
10:55:01
10:10:01
09:20:01
08:35:01
07:50:01
07:05:01
06:20:01
05:30:01
04:45:01
04:00:01
03:15:01
02:30:01
01:35:01
00:50:01
00:00:01
0
czas [h]
Rys. 4. Uśredniona wariancja czasu odpowiedzi (jitter) dla pomiaru pomiędzy odziałem warszawskim oraz wrocławskim
18
172.29.10.12
0,018
współczynnik utraty pakietów
0,016
0,014
0,012
0,01
0,008
0,006
0,004
0,002
00
:0
0:
01 0 1
:0
5:
02 0 1
:1
0:
00 0 1
:3
0:
04 0 1
:1
5:
05 0 2
:1
5:
01 0 1
:0
5:
07 0 1
:2
0:
08 0 1
:2
0:
01 0 1
:3
5:
10 0 1
:2
5:
11 0 1
:2
5:
12 0 1
:1
0:
13 0 1
:4
5:
14 0 1
:4
5:
12 0 1
:4
5:
16 0 1
:5
0:
17 0 1
:5
0:
18 0 2
:1
5:
19 0 1
:5
5:
20 0 1
:5
5:
21 0 1
:4
5:
22 0 1
:5
5:
23 0 1
:5
5:
01
0
czas [h]
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.
172.30.10.49
180
czas odpowiedzi [ms]
160
140
120
100
80
60
40
20
czas [h]
Rys. 6. Uśredniony czas odpowiedzi dla pomiaru pomiędzy odziałem warszawskim oraz gdańskim
19
23:25:01
22:40:01
21:55:01
21:10:01
20:25:01
19:35:01
18:50:01
18:05:01
17:20:01
16:35:01
15:50:02
15:00:01
14:15:01
13:30:01
12:45:01
11:40:01
10:55:01
10:10:01
09:20:01
08:35:01
07:50:01
07:05:01
06:20:01
05:30:01
04:45:01
04:00:01
03:15:01
02:30:01
01:35:01
00:50:01
00:00:01
0
172.30.10.49
60
50
jitter [ms]
40
30
20
10
23:25:01
22:40:01
21:55:01
21:10:01
20:25:01
19:35:01
18:50:01
18:05:01
17:20:01
16:35:01
15:50:02
15:00:01
14:15:01
13:30:01
12:45:01
11:40:01
10:55:01
10:10:01
09:20:01
08:35:01
07:50:01
07:05:01
06:20:01
05:30:01
04:45:01
04:00:01
03:15:01
02:30:01
01:35:01
00:50:01
00:00:01
0
czas [h]
Rys. 7. Uśredniona wariancja czasu odpowiedzi (jitter) dla pomiaru pomiędzy odziałem warszawskim oraz gdańskim
172.30.10.49
0,018
współczynnik utraty pakietów
0,016
0,014
0,012
0,01
0,008
0,006
0,004
0,002
00
:3
0:
01 0 1
:3
5:
02 0 1
:4
5:
03 0 1
:4
5:
04 0 1
:4
5:
05 0 1
:4
5:
06 0 2
:5
0:
07 0 2
:5
0:
08 0 1
:5
0:
09 0 1
:5
5:
10 0 2
:5
5:
11 0 1
:5
5:
13 0 1
:1
5:
14 0 1
:1
5:
15 0 1
:2
0:
16 0 1
:2
0:
17 0 1
:2
0:
18 0 1
:2
0:
19 0 1
:2
0:
20 0 1
:2
5:
21 0 1
:2
5:
22 0 1
:2
5:
23 0 1
:2
5:
01
0
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 odpo20
wiedzi to ponad 2 s. Taki rozrzut w praktyce oznacza, że niemożliwe będzie uruchomienie telefonii
VoIP w oparciu o tą infrastrukturę.
Y:\>ping 172.30.10.49
Badanie 172.30.10.49 z użyciem 32 bajtów danych:
Odpowiedź z 172.30.10.49: bajtów=32 czas=31ms TTL=247
Statystyka badania ping dla 172.30.10.49:
Pakiety: Wysłane = 4, Odebrane = 4, Utracone = 0 (0% straty),
Szacunkowy czas błądzenia pakietów w millisekundach:
Minimum = 31 ms, Maksimum = 44 ms, Czas średni = 35 ms
Y:\>ping 172.30.10.49
Y:\>ping 172.30.10.49
Y:\>ping 172.30.10.49
Y:\>ping 172.30.10.49
21
Y:\>ping 172.30.10.49
Y:\>ping 172.30.10.49
Problem zmienności opóźnienia połączenie Internet-VPN do Gdańska najprawdopodobniej
wynika z niedopasowania firewalla w Gdańsku do 10Mbit/s łącza do Internetu. Tą hipotezę potwierdzają fakty, że w oddziale gdańskim występują problemy z dostępem do Intranetu i poczty korporacyjnej. Co więcej testy komendą Ping wysyłane na adres routera TASK w Gdańsku (do którego
dołączony jest oddział gdański) wykazały w zasadzie stałe opóźnienie.
W związku z potrzebą uruchomienia telefonii VoIP pomiędzy oddziałami warszawskim i gdańskim w roku 2007 planowana jest istotna modernizacja sieci komputerowej oddziału w Gdańsku, w
tym zastąpienie koncentratorów Ethernet 10 Mb/s, przełącznikami Fast Ethernet 100 Mb/, natomiast
w dalszej perspektywie rekomenduje się wymianę urządzenia firewall w Gdańsku. Do tego czasu
można korzystać z telefonii w obecnej konfiguracji, przy czym trzeba mieć na uwadze słabą jakość
rozwiązania lub można też bramę VoIP w Gdańsku umieścić poza firewallem, w sieci Internet. Te
drugie rozwiązanie związane jest z niebezpieczeństwem podsłuchu rozmów oraz próbami wykonywania połączeń telefonicznych przez osoby nieuprawnione.
4.3.2. Testy jakości mowy
W kolejnym etapie przeprowadzono szereg testów jakości mowy z wykorzystaniem oprogramowania PacketScan i VQT firmy GL. Oprogramowanie to zakupione zostało w ramach niniejszej
pracy. PacketScan umożliwia monitorowanie protokołów VoIP oraz pasywny pomiar jakości głosu, a
ponadto daje możliwość zapisania zawartości strumieni RTP do pliku audio, który może być wykorzystany do aktywnego pomiaru jakości głosu realizowanego przez oprogramowanie VQT. W niniejszym dokumencie zamieszczono jedynie wybrane wyniki, których zadaniem jest zobrazowanie występujących problemów w obszarze jakości głosu. Jednocześnie uznano za niecelowe zamieszczanie
wyników dla wszystkich przeprowadzonych pomiarów.
22
4.3.2.1. Testy jakości mowy dla połączeń VoIP w internetowym kanale Internet-VPN do Wrocławia
Warunki przeprowadzenia testu:
•
Na serwerze Asterisk w Warszawie do numerów testowych zostały przypisane odpowiednio
spreparowane pliki dźwiękowe, będącymi jednocześnie plikami referencyjnymi.
• We Wrocławiu zestawiono połączenie VoIP z wykorzystaniem protokołu SIP na numer testowy w Warszawie.
• Połączenie zarejestrowano przy pomocy oprogramowania PacketScan.
Wyniki :
Rys. 9 Odstęp pomiędzy odbieranymi pakietami (gap)
Rys. 10 Wartości jittera
Na rysunkach Rys. 9 i Rys. 10 umieszczono wykresy odstępów pomiędzy kolejnymi odebranymi pakietami oraz jittera pomierzonymi za pomocą analizatora PacketScan. Z analizy tych wykresów można stwierdzić, że występujący jitter jest zmienny i mieści się w granicach 0d 5 do30 ms.
Wartości te należy uznać za zadawalające. W przypadku odstępu pomiędzy kolejnymi pakietami to
widać, że oscyluje on w granicach 20ms, natomiast szczególnie w końcowej fazie połączenia zdarzają
się pakiety z odstępem około 100ms. Tym samym należy zakładać, że bufor niezbędny do zniwelowania zjawiska jittera powinien mieć około 80-100 ms.
W kolejnej fazie pomiarów za pomocą oprogramowania PacketScan dokonano konwersji
strumieni RTP na pliki audio, które następnie poddano aktywnym pomiarom jakości mowy. Do
pomiarów zastosowano pakiet oprogramowania VQT, który porównywał pliki audio otrzymane za
pomocą PacketScan z plikiem referencyjnym. Pomiary parametrów jakości głosu zostały wykonane
dla plików zdegradowanych odpowiadających następującym wartością bufora dla niwelacji jittera:
•
jitterbuffer = 0ms,
23
•
•
•
jitterbuffer = 40ms,
Otrzymane wyniki kształtowały się następująco:
Rys. 11 Zestawienie sygnałów referencyjnego i zdegradowanego, jitterbufer = 0ms
Ważniejsze parametry jakościowe dla pomiaru zdegradowanego pliku audio, jitterbuffer= 0ms,
względem pliku referencyjnego kształtowały się następująco:
VQT Scores
PAMS Listening Quality(P800):
1
PAMS Listening Effort(P800):
1.33
PSQM (P861):
1.53
PSQM+:
6.5
PESQ Score(P862):
1.21
PESQ Listening Quality:
1
PESQ Listening Quality Objective(P862.1): 1.22
Jitter
PAMS
Number of Utterances
16
Min Offset
-144.125
Max Offset
575
Avg. Offset
71.76563
Standard Deviation of Offsets
186.1293
Level
Reference
Degraded
Speech activity
0.63
0.3
Mean DC Level
-0.14
-0.29
Active Speech Level
-18.65
-33.35
Mean Noise Level
-54.4
-66.97
RMS Level
-20.5
-36.15
Active Level
-17.18
-30.1
Activity Level
81.31
43.12
Noise Level
-94.11
-94.11
Peak Level
1.47
-10.68
Insertion_gain: -14.7
Noise_gain:
-12.56
24
PESQ
16
-144.125
575
61.92969
194.3699
Rys. 12 Zestawienie sygnałów referencyjnego i zdegradowanego, jitterbuffer = 40ms
VQT Scores
1.51
1.33
PSQM (P861):
0.76
PSQM+:
3.95
PESQ Score(P862):
2.34
1.74
Jitter
PAMS
15
Min Offset
-323.875
Max Offset
0
Avg. Offset
-34.35833
89.29311
Level
Reference
Degraded
Speech activity
0.63
0.45
Mean DC Level
-0.14
-0.59
Active Speech Level
-18.66
-31.41
Mean Noise Level
-52.98
-65.95
RMS Level
-20.5
-34.2
Active Level
-17.18
-29.37
Activity Level
81.31
58.47
Noise Level
-94.11
-94.11
Peak Level
1.47
-10.68
Noise_gain:
-12.97
25
PESQ
15
-323.875
0
-35.61666
93.13948
VQT Scores
3.94
3.52
PSQM (P861):
0.34
PSQM+:
1.4
PESQ Score(P862):
3.35
3.27
Jitter
PAMS
15
Min Offset
-185.25
Max Offset
0
Avg. Offset
-12.89167
48.2362
Level
Reference
Degraded
Speech activity
0.63
0.49
Mean DC Level
-0.14
-0.5
Active Speech Level
-18.66
-30.89
Mean Noise Level
-53.23
-65.23
RMS Level
-20.5
-33.68
Active Level
-17.18
-29.28
Activity Level
81.31
63.49
Noise Level
-94.11
-94.11
Peak Level
1.47
-10.68
Noise_gain:
-12
26
PESQ
15
-185.25
0
-12.35
46.20947
VQT Scores
4.07
3.62
PSQM (P861):
0.3
PSQM+:
1.35
PESQ Score(P862):
3.49
3.49
Jitter
PAMS
15
Min Offset
-185.25
Max Offset
0
Avg. Offset
-12.89167
48.2362
Level
Reference
Degraded
Speech activity
0.63
0.49
Mean DC Level
-0.14
-0.55
Active Speech Level
-18.66
-30.86
Mean Noise Level
-53.23
-65.23
RMS Level
-20.5
-33.66
Active Level
-17.18
-29.25
Activity Level
81.31
63.46
Noise Level
-94.11
-94.11
Peak Level
1.47
-10.68
Noise_gain:
-12
PESQ
15
-185.25
0
-12.35
46.20947
Podsumowując wyniki pomiarów jakości głosu można stwierdzić, że przy ustawieniach jitterbufera równych 0 i 40 ms otrzymaliśmy odpowiednio wartości 1,2 i 2,3 w skali PESQ co odpowiada
słabej jakości głosu. Zatem wartości jitterbufera w zakresie od 0 do 40ms należy uznać za zbyt małe.
27
Przy ustawieniach jitterbufera równych 80 i 120 ms otrzymaliśmy odpowiednio wartości 3,3 i
3,5 w skali PESQ co odpowiada dobrej jakości głosu. Porównując oba pomiary można też stwierdzić,
że w przypadku pomiaru przy wartości jitterbufera równego 120ms, przebieg sygnału różnicowego
(różnica pomiędzy plikiem referencyjnym a zdegradowanym) w znacznym stopniu pokrywa się z
osią zerową, za wyjątkiem zakłócenia około 11s połączenia. W przebiegu sygnału różnicowego dla
pomiaru QoS przy wartości jitterbufera równego 80ms pojawiają się nieliczne piki w trakcie całego
połączenia. Stąd też wniosek, że wartość jitterbufera równa 80ms, jest wartością zbliżoną do wartości
granicznej. Natomiast mając na uwadze zmienność parametrów sieci Internet tą wartość trzeba
zwiększyć, tworząc pewien margines bezpieczeństwa, stąd rekomenduje się wartość 120ms. Wartość
ta pozwoli z jednej strony na spełnienie ogólnych wymogów stawianych telefonii, to jest różnienie w
jedną stronę nie większe niż 150-200ms, z drugiej strony zapewnia dobrą jakość przesyłanego głosu.
4.3.2.2. Testy jakości mowy dla połączeń VoIP w sieci LAN
Warunki przeprowadzenia testu:
•
Na serwerze Asterisk w Warszawie do numerów testowych zostały przypisane odpowiednio
spreparowane pliki dźwiękowe, będącymi jednocześnie plikami referencyjnymi.
• W sieci LAN z wykorzystaniem protokołu SIP zostało zestawione połaczenie numer testowy,
• Połączenie zarejestrowano przy pomocy oprogramowania PacketScan.
Wyniki :
Rys. 15 Odstęp pomiędzy odbieranymi pakietami (gap)
Rys. 16 Wartości jitera
Na rysunkach Rys. 15 i Rys. 16umieszczono wykresy odstępów pomiędzy kolejnymi odebranymi pakietami oraz jittera pomierzonymi za pomocą analizatora PacketScan. Z analizy tych wykre-
28
sów można stwierdzić, że występujący jitter jest w zasadzie stały i mieści się w granicach od 3 do5
ms. Wartości te należy uznać za bardzo dobre. W przypadku odstępu pomiędzy kolejnymi pakietami
to widać, że oscyluje on w granicach 20ms. Tym samym należy zakładać, że minimalny bufor niezbędny do zniwelowania zjawiska jittera powinien mieć około 20 ms.
W kolejnej fazie pomiarów za pomocą oprogramowania PacketScan dokonano konwersji strumienia RTP na plik audio, który następnie poddano aktywnym pomiarom jakości mowy. Do pomiarów zastosowano pakiet oprogramowania VQT, który porównywał plik audio otrzymany za pomocą
PacketScan z plikiem referencyjnym. Pomiary parametrów jakości głosu zostały wykonane dla pliku
zdegradowanego odpowiadającego wartości bufora wynoszącej 40ms.
Ważniejsze parametry jakościowe dla pomiaru zdegradowanego pliku audio, jitterbufer= 120ms,
VQT Scores
4.87
4.94
PSQM (P861):
0.02
PSQM+:
0.02
PESQ Score(P862):
4.44
4.47
Jitter
PAMS
15
Min Offset
-10
Max Offset
-10
Avg. Offset
-10
0
Level
Reference
Degraded
Speech activity
0.63
0.55
29
PESQ
15
-10
-10
-10
0
Mean DC Level
Active Speech Level
Mean Noise Level
RMS Level
Active Level
Activity Level
Noise Level
Peak Level
Insertion_gain: -12
Noise_gain:
-12
-0.14
-18.66
-53.38
-20.5
-17.18
81.31
-94.11
1.47
-0.63
-30.66
-65.38
-33.18
-29.41
70.13
-94.11
-10.68
Z zamieszczonych powyżej wyników pomiarów jakości głosu w sieci LAN wynika, że jakość
ta jest bardzo dobra (wynik PESQ =4,4) przy zastosowanym buforze 40 ms. Ponieważ w systemie nie
ma możliwości zróżnicowania wielkości jitterbuffera, to należy uznać, że przy ustalaniu wartości
jitterbuffera należy prać zjawiska występujące podczas transmisji głosu w Internecie, natomiast w
sieci LAN wartość bufora (powyżej 100ms) z dużym zapasem będzie spełniała wymagania użytkowników w zakresie jakości głosu, przy akceptowalnym opóźnieniu.
4.4. Podsumowanie przeprowadzonych badań
Na podstawie przeprowadzonej analizy zagadnienia jakości głosu w sieciach pakietowych, w
tym:
• wymagań na parametry jakościowe sieci IP dla telefonii;
• wyników monitorowania parametrów połączeń Internet-VPN do Wrocławia i Gdańska;
• wyników pomiarów jakości głosu;
przyjęto, że dla telefonii VoIP w Instytucie łączności powinien być stosowany kodek G729a lub
zamiennie iLBC, gdyż gwarantują one dobrą jakość głosu przy relatywnie niskim zapotrzebowaniu
na pasmo. Dla połączeń do sieci TDM należy stosować jitterbufer o wartości 120-150ms. Stwierdzono, że w połączeniach do/z Wrocławia mogą sporadycznie występować zaniki związane ze zbyt małą
przepływnością łącza do Internetu we Wrocławiu. W przypadku oddziału gdańskiego rekomenduje
się wymianę firewalla, gdyż obecnie stosowany nie spełnia wymagań stawianych przez telefonię
VoIP.
30
5. Testy funkcjonalności i usług dodatkowych platformy VoIP opartej o
rozwiązanie Asterisk
5.1. Badania transmisji faksowej
Zarówno migracja sieci korporacyjnych z rozwiązań TDM na platformę IP, jak i proces integracji wymusza konieczność zapewnienia obsługi połączeń faksowych. Jest to możliwe do realizacji
poprzez pozostawienie określonej liczby analogowych/cyfrowych łączy abonenckich na potrzeby
tego typu transmisji.
Inną metodą jest zastosowanie autonomicznego rozwiązania pozwalającego na wysyłkę (w
postaci elektronicznej) oraz odbiór faksów z wykorzystaniem stacji roboczej dołączonej do wspólnej
infrastruktury sieci LAN. Zazwyczaj możliwe formy wysyłania faksów obejmują wysyłkę:
a) za pomocą klienta poczty,
b) za pomocą przeglądarki internetowej, po zalogowaniu się na odpowiedniej stronie, wykorzystując formularz, do którego należy wpisać treść wiadomości lub ją skopiować z innego programu, dodatkowo dołączając dokument,
c) bezpośrednio z komputera z wykorzystaniem sterownika emulującego, po jego zainstalowaniu
w opcji wyboru drukarki pojawia się dodatkowe urządzenie - wydruk na to urządzenie uruchomi program obsługujący wysyłkę faksu.
Realizacja zadania zakładała zbadanie możliwości obsługi transmisji faksowej z wykorzystaniem funkcji zaimplementowanych na platformie Trixbox. Dodatkowo zweryfikowano poprawność
wysyłki faksów z wykorzystaniem oprogramowania Asterfax współpracującego z serwerem Asterisk
w zakresie obsługi faksów.
Celem procesu testowania było sprawdzenie poprawności wysyłania i odbierania faksów, jakości przesyłanych w ten sposób dokumentów oraz określenie możliwości udostępnienia tej funkcjonalności dla użytkowników dołączonych do centrali Hicom.
W tym celu utworzono grupę użytkowników obsługiwanych przez serwer Asterisk a jednocześnie posiadających przypisane numery katalogowe centrali Hicom (5XX). Kierowanie połączeń
do serwera Asterisk poprzez wewnętrzne łącze PRI zapewniło możliwość wykonywania połączeń
faksowych z urządzeń dołączonych do sieci PSTN.
31
Rys. 18. Schemat środowiska testowego transmisji faksowej (i docelowego dla usługi fax-to-email) oraz przepływy
informacji pomiędzy elementami systemu
Funkcja odbioru faksów
Do testów zastosowano metody wysyłania faksów oparte na:
•
aplikacji Asterfaks, wykorzystującej własny serwer pocztowy do przyjmowania dokumentów
do wysyłki od użytkowników, którzy wysyłają faks na adres e-mail przypisany do aplikacji,
podając w temacie wiadomości numer odbiorcy faksu,
•
rozwiązanie bazujące na powiązaniu mechanizmu drukowania do pliku przesyłanego na serwer FTP, w którym użytkownik drukuje dokument do pliku, który następnie jest przesyłany
na serwer FTP wraz z informacją zawierającą numer katalogowy abonenta docelowego, gdzie
cykliczny proces przeglądając zawartość serwera napotyka dokument przeznaczony do wysłania inicjuje konwersję do odpowiedniego formatu a następnie wysyłkę za pomocą serwera
VoIP.
Testy wykazały, że kompromisowym rozwiązaniem pod względem ergonomii korzystania z
usługi wysyłki faksów oraz złożoności implementacji i niezawodności jest metoda wykorzystująca
wydruk dokumentu do wirtualnej drukarki. Jej sterownik może być instalowany w każdym komputerze wyposażonym w system Windows (powyżej wersji 98SE), w sposób podobny jak sterownik
rzeczywistej drukarki. Testy transmisji faksowej inicjowanej w ten sposób wykazały jednak niedoskonałość również tej metody, objawiającą się w degradacji jakości przesyłanego dokumentu w
miejscu wstawiania nagłówka. W trakcie prób zaobserwowano również pojawiające się problemy z
32
podziałem strony. Jako źródło błędów została wskazana aplikacja obsługująca transmisję faksową w
serwerze Asterisk. Poprawienia błędów można oczekiwać w kolejnej oprogramowania serwera Asterisk (1.4), której wersja beta jest już dostępna. Skutki występowania błędów w odebranych dokumentach zostały pokazane na przykładzie porównywanych dokumentów źródłowego i wynikowego (Rys.
19i Rys. 20).
Rys. 19. Dokument źródłowy do testów transmisji
faksowej
Rys. 20. Dokument wynikowy o zdegradowanej
jakości
W związku z negatywnym wynikiem tych prób wdrożenie usługi wysyłki faksów za pośrednictwem
rozwiązania opartego na platformie Asterisk w wersji 1.2.12 nie jest rekomendowane.
5.2. Ocena systemu poczty głosowej
Obok interaktywnego menu głosowego system poczty stanowi jedną z podstawowych funkcjonalności platformy Asterisk. Integracja systemu poczty głosowej wykorzystującej zewnętrzny
serwer (często właśnie platformę Asterisk) jest pierwszym krokiem w kierunku integracji systemów
lub całkowitej migracji w kierunku telefonii IP [4].
System poczty głosowej stanowiący funkcjonalność serwera Asterisk może być wykorzystywany jako zewnętrzny w stosunku do istniejącego systemu telekomunikacyjnego system poczty
głosowej. Zasadnicza konfiguracja systemu umożliwia nie tylko dokonywanie wyboru jednej z wielu
opcji usługi, która jest oferowana użytkownikowi, lecz również dopasowanie do wymagań danej
organizacji. Wybór opcji dotyczy przede wszystkim wielkości zbioru narzędzi zarządzania oraz
uprawnień, które administrator systemu decyduje udostępnić użytkownikowi (Rys. 21).
33
Rys. 21. Dostępne opcje w konfiguracji skrzynki poczty głosowej na serwerze Asterisk
Opcje dostępne w konfiguracji indywidualnego konta poczty głosowej obejmują m.in.
•
zabezpieczenie dostępu do skrzynki (dotyczy zarówno funkcji zarządzania, np. nagrywania zapowiedzi, jak i odsłuchiwania zarejestrowanych wiadomości),
•
możliwość przesyłania zarejestrowanych wiadomości na wskazany adres poczty elektronicznej,
•
dołączanie dodatkowych informacji do nagrania znajdującego się w skrzynce głosowej
•
zarządzanie nagraniami znajdującymi się w skrzynce (usuwanie, przesyłanie do innego
użytkownika).
W najprostszym przypadku przyjętym do realizacji w procesie integracji w IŁ, użytkownik nie
posiada uprawnień do modyfikowania zapowiedzi ani zróżnicowanych metod dostępu do nagrań.
Nagraną wiadomość otrzymuje on w postaci załącznika wiadomości poczty elektronicznej (Rys. 22).
Przyjęty model nie wymaga więc od użytkownika podejmowania żadnych kroków w celu odtworzenia zarejestrowanej w skrzynce głosowej wiadomości, za wyjątkiem uprzedniego zaprogramowania
za pomocą aparatu telefonicznego funkcji przekazywania przychodzących połączeń do skrzynki
głosowej. Możliwe jest w tym przypadku wykorzystanie zarówno funkcji bezwarunkowego przekazywania połączeń, jak również przekazywania „po czasie”.
Rys. 22. Wiadomość pocztowa z załącznikiem w postaci zarejestrowanego nagrania poczty głosowej
34
5.3. Testy funkcjonalności Call Center
W ramach pracy przeprowadzono testy platformy Trixbox pod kątem zastosowania tej platformy jako rozwiązania dla Call Center. Z wymaganych funkcjonalności Call Center wynika szereg
dodatkowych usług, które realizować powinien system telekomunikacyjny. W ramach tej pracy dokonano identyfikacji tych funkcjonalności, a następnie sprawdzono ich realizację na platformie
Trixbox. Do testów tych funkcjonalności wykorzystano oprogramowanie HUDLite będące implementacją usług Call Center na platformie Trixbox. Poniżej zamieszczono panel konsoli nadzoru nad
Call Center w rozwiązaniu HUDLite.
Rys. 23 Panel konsoli nadzoru nad Call Center w w rozwiązaniu HUDLite
Podczas realizacji testów sprawdzono następujące funkcjonalności:
•
•
•
•
•
kolejkowanie połączeń,
automatyczna dystrybucja połączeń Automatic Call Distribution (ACD),
przekazywanie połączeń przez agenta,
bieżące monitorowanie agentów przez personel nadzorujący pracę agentów
o monitorowanie stanu
o podsłuch rozmowy prowadzonej przez agenta
o włączenie się nadzorcy do rozmowy w połączeniu trójstronnym,
o przechwycenie rozmowy przez nadzorcę,
o „tryb podpowiedzi”, nadzorca w trakcie rozmowy klienta z agentem udziela podpowiedzi agentowi w sposób niewidoczny dla klienta,
rejestracja połączeń,
35
•
integracja z systemami CRM,
Podsumowując wynik badań można stwierdzić, że w oparciu o rozwiązaniach wykorzystujące
IP-PBX Asterisk można z powodzeniem realizować systemy Call Center. Jednak w przypadku komercyjnych zastosowań wydaje się, że konieczne jest dostosowanie aplikacji do zarządzania Call
Center do potrzeb konkretnego klienta, tak by oferowała na przykład polskojęzyczny interfejs.
5.4. Usługa Follow Me
Jedną z nowych usług IP - PBX Asterisk jest usługa Follow Me, pozwala ona na tworzenie listy numerów, na które ma być kierowane połączenie przychodzące na dany numer wewnętrzny. W
liście może się znajdować kilka numerów zarówno wewnętrznych jak i zewnętrznych (dowolny
numer). Możliwe jest ustawienie indywidualnie dla każdego numeru jednego z trybów usługi:
•
Wywołanie kierowane jest do wszystkich numerów z listy jednocześnie, połączenie zestawiane jest do abonenta, który pierwszy się zgłosi;
• Wywołanie kierowane jest kolejno do wszystkich numerów z listy z ustalonym interwałem
czasowym;
• Wywołanie kierowane jest kolejno do wszystkich numerów z listy z ustalonym interwałem
czasowym;
• Wywołanie kierowane do pierwszego numeru z listy, następnie po ustalonym interwale czasowym wywołanie jest również kierowane do kolejnego numeru z listy, połączenie zestawiane jest do abonenta, który pierwszy się zgłosi;
Aktywacji i konfiguracji usługi dokonuje administrator systemu. Na rysunku poniżej zamieszczono
panel administratora systemu dla usługi Follow Me.
Rys. 24 Usługa Follow Me - panel administratora systemu
36
5.5. Testy IVR
Zaproponowane przez Dział Sprzedaży i Marketingu IŁ uruchomienie automatycznej obsługi
połączeń przychodzących na numer 0 22 5128 100, wymagało utworzenia schematu obsługi tych
połączeń jak również wykonanie prób na platformie testowej VoIP. Zaobserwowana liczba połączeń
przychodzących na łącze opisane tym numerem waha się w granicach 20 połączeń na dzień, więc
wynikające stąd obciążenie serwera VoIP możliwe było do zrealizowania bez konieczności angażowania generatora wywołań. Jednak rozpoczęcie rozmów z Telekomunikacją Kolejową w sprawie
organizacji call center opartego na platformie Asterisk, zachęciło wykonawców zadania do opracowania narzędzi charakteryzujących się większą wydajnością. W tym celu opracowano skrypt testowy
przeznaczony do realizacji w oparciu
Wykonano testy obciążeniowe serwera Asterisk w zakresie obsługi wywołań sterowanych za
pomocą skryptu realizującego funkcjonalność IVR. Do badań wykorzystano generator wywołań
Anritsu EF111A z dołączonymi 10 liniami analogowymi. Testy wykonano z wykorzystaniem skryptu
zawierającego scenariusze połączeń dla schematu drzewa przedstawionego na rysunku.
Połączenie przychodzące
na numer 523
Odtworzenie zapowiedzi
„1”
„9”
Powrót do
głównego
menu
„7”
Weryfikacja gałęzi za
pomocą sekwencji
DTMF (1717)
„5”
pomocą sekwencji
DTMF (1515)
„8”
pomocą sekwencji
DTMF (1818)
„2”
„6”
pomocą sekwencji
DTMF (1616)
„5”
pomocą sekwencji
DTMF (2525)
„6”
pomocą sekwencji
DTMF (2626)
„7”
pomocą sekwencji
DTMF (2727)
„8”
pomocą sekwencji
DTMF (2828)
„9”
Powrót do
głównego
menu
Rys. 25 Sekwencja drzewa dla testów IVR
Testowy skrypt umożliwia:
•
poruszanie się po poszczególnych „gałęziach” drzewa IVR,
•
osiąganie dowolnej gałęzi drzewa zgodnie z sekwencją DTMF (jest również możliwa regulacja parametrów tej sygnalizacji)
•
weryfikację osiągniętej gałęzi (sprawdzenie, czy klient dotarł do zakładanej gałęzi wybierając
zakładaną sekwencję).
Metoda testowania oraz narzędzia mogą być wykorzystane do testów obciążeniowych złożonych rozwiązań IVR. Konstrukcja generatora wywołań umożliwia inicjowanie połączeń z wykorzystaniem maksymalnie 64 łączy analogowych.
W trakcie testów w warunkach laboratoryjnych wykonano łącznie 61 670 połączeń (w tym
306 nieskutecznych). Statystyki skuteczności oraz wykrytych błędów zaprezentowano na rysunku
(Rys. 26).
37
a)
b)
Połączenia w ykonane
Przyczyny błędów
306
Brak zgłoszenia
22 24
Niew łaściw a
gałąź
61354
Nieskuteczne
260
Brak rozłączenia
Skuteczne
Rys. 26. Statystyka połączeń do IVR (a) oraz przyczyn błędów (b)
5.6. Połączenia konferencyjne
Jedną z funkcjonalności IP-PBX Asterisk są konferencje tworzone w oparciu o zasoby tzw.
mostka konferencyjnego, pozwalającego na organizację połączenia konferencyjnego dla liczby
uczestników większej od trzech. Tego typu połączenia mogą być realizowane w dwóch wariantach:
•
•
wariancie z moderatorem, który posiada uprawnienia do administrowania połączeniem konferencyjnym, m.in. w zakresie blokowania dostępu kolejnych uczestników do połączenia konferencyjnego, odbierania lub dopuszczania do głosu wybranych uczestników, usuwania z połączenia uczestników,
lub wariancie bez moderator, gdy uczestnicy nie posiadają ww. uprawnień.
Oba wymienione warianty realizacji mostka konferencyjnego mogą być skonfigurowane w taki sposób, że przed przyłączeniem użytkownika do konferencji serwer może żądać autoryzacji użytkownika za pomocą kodu DTMF. Tę samą metodę autoryzacji, lecz z wykorzystaniem innego kodu
stosuję się również w przypadku dołączenia do konferencji moderatora.
„Pokoje konferencyjne” mogą być w prosty sposób dodawane przez administratora systemu za
pomocą przeglądarki internetowej. Wydruk strony za pomocą, której tworzone są pokoje konferencyjne zamieszczony został poniżej.
38
Rys. 27 Dodawanie konfekcji w panelu administratora
Platforma Trixbox oferuje również realizację funkcji administracyjnych przypisanych do moderatora za pośrednictwem interfejsu WWW. Poprzez ten interfejs moderator może obserwować listę
aktualnych uczestników konferencji, sterować „prawem głosu” lub usunąć dowolnego uczestnika
konferencji. Na rysunku poniżej zamieszczono panel administracyjny do sterowania konferencją.
Rys. 28 Panel administracyjny do sterowania konferencją
W systemie możliwe jest również tworzenie konferencji pomiędzy trzema uczestnikami w
oparciu o możliwości funkcjonalne terminala użytkownika, który inicjuje połączenie konferencyjne.
39
5.7. Połączenia video
Testowanie aplikacji użytkownika oferujących usługi połączeń video realizowane było głównie pod kątem wykorzystania do celów połączeń konferencyjnych w ramach sieci rozległej z wykorzystaniem serwera Asterysk. Przyjęto bowiem założenie, że ten typ usługi będzie najczęściej wykorzystywana opcją połączeń wykorzystującą funkcjonalność transmisji obrazu. Przebieg testów obejmował zestawianie połączeń z wykorzystaniem różnych kodeków video (H.261, H.263). Dla każdego
połączenia ocenie podlegała subiektywna jakość obrazu oraz dźwięku, jak również łączna ocena
jakości połączenia. Ankieta służąca ocenie przewidywała punktację przedstawioną w tabeli.
Tabl. 3. Ankieta użytkownika do oceny jakości połączenia wideo
1
Jak oceniasz ogólną jakość połączenia wideo?
□ Bardzo dobrze (ocena 5)
□ Dobrze (ocena 4)
□ Dostatecznie (ocena 3)
□ Słaba (ocena 2)
□ Zła (ocena 1)
Komentarz:
2
Jak oceniasz jakość obrazu połączenia wideokonferencyjnego
Bardzo dobrze (ocena 5)
Dobrze (ocena 4)
Dostatecznie (ocena 3)
Słaba (ocena 2)
Zła (ocena 1)
Komentarz:
□
□
□
□
□
3
Jak oceniasz jakość głosu połączenia wideokonferencyjnego
Bardzo dobrze (ocena 5)
Dobrze (ocena 4)
Dostatecznie (ocena 3)
Słaba (ocena 2)
Zła (ocena 1)
Komentarz:
4
Czy w trakcie trwania wideokonferencji tracone były informacje
□
□
□
□
□
Bardzo rzadko
Rzadko
Czasami
Często
Bardzo często
Komentarz:
□
□
□
□
□
Środowisko pomiarowe
Pomiary jakości przeprowadzono w:
•
warunkach laboratoryjnych z wykorzystaniem sieci LAN z wykorzystaniem emulatora
sieci IP,
40
•
sieci Internet z wykorzystaniem zestawianych kanałów Internet-VPN.
W pierwszym przypadku zbadano jakość połączeń wideokonferencyjnych zarówno pomiędzy
dwoma terminalami dołączonymi do sieci LAN i wyposażonymi w aplikacje klienckie oraz dedykowane kamery, jak również w konfiguracji wykorzystującej emulator sieci IP włączony w łańcuch
połączeniowy.
Zainstalowany i skonfigurowany w ramach pracy emulator sieci IP wykorzystuje mechanizmy
kierowania i kształtowania ruchu na poziomie warstwy drugiej modelu OSI (pod względem funkcjonalnym uruchomione oprogramowanie realizuje funkcje mostu w sieci typu Ethernet), dając możliwość ustawiania podstawowych parametrów wydajnościowych dla ruchu pakietowego „przechodzącego” przez to urządzenie. Istnieje możliwość skonfigurowania ustawień niezależnie dla każdego z
dwóch interfejsów mostu (ruch przychodzący oraz ruch wychodzący z tego urządzenia) w odniesieniu do następujących parametrów:
•
jitter (rozkład normalny),
•
utrata pakietów,
•
opóźnienie,
•
duplikacja pakietów,
•
ograniczenie pasma.
W trakcie badań wykorzystano możliwość zmiany ustawień pierwszych trzech z przytoczonej
listy parametrów do symulacji efektów wnoszonych przez zjawiska mające miejsce w sieciach pakietowych. Ich wpływ na jakość połączeń video podobnie jak i połączeń głosowych jest uważany jest
najbardziej znaczący [5].
Testy połączeń video były realizowane z wykorzystaniem aplikacji Windows Messenger 5.1
oraz X-Lite 3.0. W trakcie testów zaobserwowano brak kompatybilności obu aplikacji, który objawiał
się brakiem przesyłania i prezentacji obrazu dla zestawionego połączenia pomiędzy aplikacjami
klienckimi.
Wyniki pomiarów jakości przeprowadzonych przy udziale 10 uczestników zostały zaprezentowane w tabeli (Tabl. 4).
Tabl. 4. Wyniki subiektywnych pomiarów jakości połaczeń video
Środowisko
Parametry
jakościowe sieci IP
Ogólna jakość
połączenia
Emulacja sieci IP
Emulacja sieci IP
Emulacja sieci IP
Emulacja sieci IP
Emulacja sieci IP
Emulacja sieci IP
J=0, D= 0, L=15%
J=20 ms, D= 30, L=0%
J=120ms, D= 30, L=0%
J=200 ms, D= 30, L=0%
J=0, D= 0, L=5%
J=0, D= 0, L= 10%
J<60ms, L=~2%
J<1ms,L=0
2,1
3,4
2,4
1,7
3,2
2,7
2,7
3,6
Sieć Internet
Sieć LAN
Objaśnienia do tabeli:
L – Packet loss
J – Jitter
D – Delay
41
Jakość Jakość głosu
obrazu
2,1
3,5
2,7
2,3
3,0
2,4
2,4
3,4
1,8
3,6
1,9
1,6
3,2
2,9
2,7
3,9
Podsumowanie:
Aplikacje Windows Messenger jak i X-Lite zapewniały poprawny przekaz strumienia wideo
w trakcie połączenia. Oprócz zaobserwowanego braku kompatybilności. Należy również podkreślić
niższą jakość obrazu w przypadku aplikacji Windows Messenger w porównaniu do X-Lite.
42
6. Testy funkcjonalne i użytkowe sprzętowych i programowych terminali
VoIP
Jednym z zadań niniejszej pracy było przeprowadzenie funkcjonalno-użytkowych testów typowego sprzętu (bram i telefonów) i terminali programowych VoIP. Celem tych testów miało być
praktyczne sprawdzenie oferowanych rozwiązań, a jednocześnie opracowanie rekomendacji dla VoIP
w IŁ. Testy terminali końcowych były przeprowadzane pod kątem współpracy z platformą Asterisk.
Najistotniejszymi kryteriami oceny były funkcjonalność oraz jakość połączeń oceniana na podstawie
subiektywnej oceny użytkowników. W ramach testów funkcjonalno-użytkowych dla każdego testowanego urządzenia i oprogramowania przeprowadzono zarówno testy opisane w tabeli Tabl. 5, jak i
minimum tygodniowe testy mające na celu określenie stopnia niezawodności. Krótki opis popularnych rozwiązań sprzętowych (bram i telefonów) będących na wyposażeniu IŁ oraz ogólne wnioski
odnośnie z testów każdego z rozwiązań zamieszczone zostały tabeli Tabl. 6. Krótki opis wybranych
aplikacji typu softphone oraz ogólne wnioski odnośnie wyników testów każdego z rozwiązań zamieszczone zostały tabeli Tabl. 7.
Tabl. 5. Testy funkcjonalne
Nr
Test
Sposób wykonania
1
Podstawowe
połączenie
Wykonanie połączenia głosowego pomiędzy użytkownikiem A i użytkownikiem B oraz
sprawdzenie skuteczności zestawienia kanału głosowego w obu kierunkach. Połączenie
powinno być zestawione dla następujących przypadków:
(A) sprzętowy telefon IP – (B) sprzętowy telefon IP
(A) software’owy telefon IP – (B) software’owy telefon IP
(A) sprzętowy telefon IP – (B) software’owy telefon IP
(A) telefon dołączony do systemu PBX – (B) software’owy telefon IP
(A) telefon dołączony do systemu PBX – (B) sprzętowy telefon IP
2
Zawieszenie
połączenia
Zestawienie połączenia pomiędzy użytkownikiem A i użytkownikiem B zgodnie z przebiegiem w teście nr 1. Połączenie zostaje zawieszone przez użytkownika A. Jeśli system
jest skonfigurowany w sposób umożliwiający wykorzystanie odtwarzania muzyki dla
zawieszonego użytkownika (Music on Hold), należy sprawdzić poprawność realizacji tej
funkcji.
3
Parkowanie
połączeń
Wykonanie połączenie zgodnie ze scenariuszem przedstawionym w punkcie 1, a następnie
zaparkowanie pod określonym numerem. W kolejnym kroku wykonać powrót do zaparkowanego połączenia.
4
Wywołanie
grupowe
Zainicjowanie połączenie pomiędzy użytkownikiem A oraz B zgodnie ze scenariuszem 1.
Użytkownik B jest w grupie numerów wywoływanych razem z użytkownikiem C. Przyjęcie połączenia następuje z terminala użytkownika C.
5
Transfer
połączenia
Zainicjowanie połączenie pomiędzy użytkownikiem A oraz B zgodnie ze scenariuszem 1.
Po odebraniu połączenia użytkownik B wykonuje jego przekazanie do użytkownika C
(sprzętowy telefon IP, software’owy telefon IP, telefon dołączony do systemu PBX).
6
Przekierowanie
połączenia
Dla użytkownika B zdefiniować kolejno typ przekierowania: bezwarunkowe (CFU), w
przypadku zajętości (CFB), w przypadku braku odpowiedzi (CFNR). Zainicjowanie
połączenia pomiędzy użytkownikiem A oraz B zgodnie ze scenariuszem 1.
7
Połączenie
konferencyjne
Zainicjowanie połączenia pomiędzy użytkownikiem A oraz B zgodnie ze scenariuszem 1.
Zawiesić połączenie od strony użytkownika A. Zestawić połączenie pomiędzy użytkownikiem A oraz C zgodnie ze scenariuszem 1. Przejść w tryb konferencji (akcja podejmowana
przez użytkownika A).
43
Tabl. 6 Porównanie bram i telefonów VoIP
Typ urządzenia
D-Link Router VoIP
DVG-1402S
DrayTek Vigor
2200V
Zdjęcie
Charakterystyka
Router DVG-1402S łączy w sobie funkcje przełącznika 10/100Mbps i
bramy VoIP pozwalającą dołączyć tradycyjny aparat telefoniczny.
Charakterystyka:
•
2 x RJ-11,
•
1 x WAN 10/100Mb,
•
4 x LAN 10/100Mb,
•
routing statyczny, RIP 1/2,
•
Comfort Noise Generation (CNG),
•
Voice Activity Detection (VAD),
•
redukcja echa (G.168),
•
wsparcie QoS (Quality of Service),
•
funkcja VPN Pass-through,
•
zarządzanie: konsola, HTTP, Telnet, SNMP;
Obsługiwane protokoły i standardy :
•
IEEE 802.3 - 10BaseT
•
IEEE 802.3u - 100BaseTX
•
Auto MDI/MDI-X
•
DHCP - Dynamic Host Configuration Protocol
•
NAT - Network Address Translation
•
PPPoE - Point-to-Point Protocol over Ethernet
•
RIPv1 - Routing Information Protocol ver. 1
•
RIPv2 - Routing Information Protocol ver. 2
•
SSL - Secure Sockets Layer
•
TLS - Transport Layer Security
•
PPTP - Point to Point Tunneling Protocol
•
IPSec - IP Security (szyfrowanie)
Vigor 2200V to router internetowy, z jednoportową bramką voip oraz
możliwością podłączenia analogowej linii telefonicznej pstn (integracja
voip i telefonii tradycyjnej oraz internetu w jednym urządzeniu).
Do bramki można podłączyć zwykłą linie telefoniczną, przez co aparat
telefoniczny zachowuje dostęp także do tradycyjnej telefonii. Telefon
może funkcjonować nieprzerwanie nawet w warunkach zaniku zasilania
routera - następuje wówczas automatyczne przejęcie zasilania z linii
abonenckiej. Wbudowane mechanizmy QoS zapewniają uprzywilejowanie dla ruchu VoIP, nadając mu wyższy priorytet w relacji do innych
Obserwacje w trakcie testów
Dobra jakość połączeń telefonicznych,
niezawodny w zakresie połączeń VoIP,
niestety jako router wielokrotnie się
zawiesza
Dobra jakość połączeń telefonicznych,
stabilna praca. W testowanym egzemplarzu stwierdzono problemy z przekazywaniem numeru poprzez FSK.
Typ urządzenia
Zdjęcie
Charakterystyka
aplikacji.
Vigor 2200V pozwala połączyć oddalone sieci LAN za pomocą tuneli
VPN, oraz zapewnić zdalny dostęp VPN dla pojedynczych stacji. Wewnątrz tuneli VPN można realizować całkowicie bezpieczną telefonię
VoIP pomiędzy lokalizacjami
Cechy urządzenia:
•
1 port WAN RJ45
•
4 porty LAN RJ45
•
1 port FXS RJ11
•
1 port LINE RJ11 dla linii PSTN
•
rozbudowany Firewall z filtrami pakietów i zawartości stron
WWW oraz ochroną przed atakami DoS
•
NAT/Multi-NAT/DMZ (niezależne mapowanie portów dla
wielu adresów publicznych)
•
obsługa dynamicznego DNS (DynDNS) dla zmiennego adresu
IP
•
synchronizacja zegara poprzez Internet (NTP)
•
obsługa UPnP (rozpoznawanie i kontrola stanu zasobów sieciowych, NAT traversal)
•
harmonogram czasowy dla niektórych funkcji komunikacyjnych
•
przyjazny Interfejs Użytkownika (Web User Interface)
•
możliwość zdalnej konfiguracji i aktualizacji oprogramowania
•
SysLog - bieżące raportowanie informacji(także na odległość)
•
rozbudowane narzędzia diagnostyczne (tabela routingu, bufor
ARP, dzierżawy DHCP, sesje NAT itd.)
•
oprogramowanie narzędziowe Router Tools wspomagające
zarządzanie
•
obsługa protokołu SIP
•
kodeki G.723.1, G.729, G.711
•
niwelacja echa
•
CNG generator szumów
•
VAD automatyczne wykrywanie głosu.
45
Typ urządzenia
Linksys PAP2T
Linksys VoIP WiFi
Router WRTP54G
Zdjęcie
Charakterystyka
•
porty głosowe FXS (RJ-11);
•
1 port FastEthernet (RJ-45);
•
protokół głosowy SIP v.2 (Session Initiation Protocol);
•
kodeki głosowe: G.711 a-law, G.711 micro-law, G.726,
G.729A, G.723.1;
•
REN (Ringer Equivalence Number) - 5 REN na każdy port RJ11;
•
ring frequency: 10-40 Hz; ring voltage: 60-90 Vrms; impedancja portu FXS: 8 ustawień (zawierają europejskie CTR21
oraz amerykańskie 600 Ohm);
•
wsparcie dla: DTMF,
•
FSK Caller ID,
•
FSK VMWI,
•
echo cancellation,
•
VAD (Voice Activity Detection);
•
możliwość podłączenia dwóch telefonów lub faksów, z dwoma
odrębnymi numerami telefonów;
•
konfiguracja za pomocą przeglądarki WWW lub klawiatury
telefonu;
Linksys WRT54G to 4-portowy router szerokopasmowy DSL (4xRJ-45)
wraz z punktem dostępowym WLAN, oraz zintegrowaną 2 portową
bramką VoIP obsługującą protokół SIP v.2.
Cechy urządzenia:
•
1 port WAN (RJ-45)
•
4 porty LAN RJ-45
•
2 porty FXS RJ-11,
•
obsługa statycznego IP, dynamicznego IP (klient DHCP),
PPPoE, PPTP,
•
punkt dostępowy WLAN 802.11g (54 Mbps),
•
bezpieczeństwo WLAN:
• WPA RADIUS (uwierzytelnianie w serwerze RADIUS),
• WPA PSK (uwierzytelnianie z użyciem Pre-Shared Key),
• WEP (64/128-bit),
• lista autoryzowanych adresów MAC,
•
moc nadajnika:
• w trybie 802.11b: 18 dBm,
46
Bramka godna polecenia w przypadku
dołączenia tylko jednego telefonu.
Stwierdzono, że w przypadku jednoczesnych połączeń na 2 portach FXS skuteczność zestawiania połączeń przez
bramkę znacznie spada
Kompletne (WiFi+router+2 bramki
VoIP) urządzenie, stabilna praca, dobra
jakość połączeń głosowych. Router
godny polecenia.
Typ urządzenia
Advanced Gateway
168
Zdjęcie
Charakterystyka
• w trybie 802.11g: 16 dBm,
•
Quality of Service - priorytety dla wybranych aplikacji i/lub
głosu,
•
firewall (SPI),
•
zasady dostępu do Internetu,
•
klonowanie adresu MAC,
•
obsługa dynamicznych DNS (DynDNS.org, TZO.com),
•
DMZ - strefa zdemilitaryzowana dla jednego IP w sieci LAN,
•
zarządzanie przez przeglądarkę WWW,
•
obsługa DTMF, FSK Caller ID, DTMF Caller ID, FSK VMWI,
•
niwelacja echa,
•
VAD automatyczne wykrywanie głosu,
•
konfiguracja za pomocą przeglądarki WWW,
•
kodeki G.711u, G.711a, G.726-40, G.726-32, G.729, G.726-24,
G.726-16,G.723,
•
impedancja portów FXS: 8 ustawień (europejskie CTR21 i
amerykańskie 600 Ohm).
•
Ring frequency: 10-40 Hz,
•
Ring voltage: 60-90 Vrms,
•
protokół głosowy SIP v.2
•
REN (Ringer Equivalence Number) - 5 REN na każdy port RJ11,
Advanced Gateway 168 to jedyna z nielicznych bramek obsługujących
protokoły Net2Phone, SIP, H323, MGCP, IAX2.
Konfiguracja urządzenia jest możliwa przy pomocy przeglądarki internetowej lub poprzez telnet, a także wstępnie przy pomocy podłączonego
telefonu.
Cechy produktu:
•
1 port WAN RJ45,
•
1 port FXS RJ11,
•
1 port line do podłączenia linii PSTN RJ11,
•
obsługa protokołów SIP, Net2Phone, H323, IAX2, MGCP,
•
obsługa DHCP, stałego IP, PPPOE,
•
obsługa VLAN
•
obsługa kodeków G.711 a/u ,G.723.1 5.3/6.3, G.729A/B/AB/
gsm610,
47
Zaletą bramki jest możliwość obsługi
większości protokołów VoIP, w tym
między innymi protokołu IAX2 oraz
szeroka gama obsługiwanych kodeków.
Wadą jest brak wbudowanego routera.
Typ urządzenia
HandyTone 486
YGW-20
Zdjęcie
Charakterystyka
•
•
CNG generator szumów tła,
•
niwelacja echa (G.168/165 16ms),
•
reguły wybierania,
HandyTone 486 to bramka VoIP obsługująca protokół SIP wyposażona
w router z opcją bridge'a a także możliwość podłączenia lini PSTN.
Dodatkowo do bramki można podłączyć analogową linie PSTN tak by
zintegrować telefonię tradycyjną i VoIP w jednym urządzeniu. Dzięki
temu można odbierać połączenia przychodzące na analogowy telefon a
także poprzez niego łączyć się, a w razie utraty zasilania bramka automatycznie przełącza nas na korzystanie z linii PSTN.
Cechy produktu:
•
1 port WAN RJ45 10mbit
•
1 port LAN RJ45 10mbit
•
1 port FXS RJ-11,
•
1 port line RJ-11 dla linii PSTN,
•
obsługa protokołu SIP 2.0,
•
obsługa DHCP, stałego IP,
•
obsługa PPPoE,
•
obsługa Nat traversal i STUN,
•
mini router (DMZ, port forwarding, klonowanie MAC),
•
możliwość pracy w trybie bridge'a,
•
kodeki G.723.1 (5.3K/6.3K), G.729A/B, G.711a/u, G.726,
G.728,
•
•
•
niwelacja echa (G.168),
•
AGC automatyczna regulacja poziomu sygnału,
•
konfiguracja przez przeglądarkę internetową, lub menu głosowe za pomocą telefonu,
YGW-20 to jedyna z nielicznych bramek obsługujących protokoły
Net2Phone, SIP, H323, MGCP, IAX2.
Konfiguracja urządzenia jest możliwa przy pomocy przeglądarki internetowej lub poprzez telnet, a także wstępnie przy pomocy podłączonego
telefonu.
Cechy produktu:
48
Bramka przez dłuższy czas testowana w
Gdańsku. Jedna z niewielu bramek z
portem FXO. Zaobserwowano problemy
z rozpoznawaniem sygnałów DTMF.
Zdarza się, że bramka zawiesza się.
Zaletą bramki jest możliwość obsługi
większości protokołów VoIP, w tym
między innymi protokołu IAX2 oraz
szeroka gama obsługiwanych kodeków.
Wadą jest brak wbudowanego routera i
duży poziom szumów.
Typ urządzenia
Linksys SPA3102
Zdjęcie
Charakterystyka
•
1 port WAN RJ45,
•
1 port FXS RJ11,
•
1 port line do podłączenia linii PSTN RJ11,
•
obsługa protokołów SIP, Net2Phone, H323, IAX2, MGCP,
•
obsługa DHCP, stałego IP, PPPOE,
•
obsługa VLAN
•
obsługa kodeków G.711 a/u ,G.723.1 5.3/6.3, G.729A/B/AB/
gsm610,
•
•
•
niwelacja echa (G.168/165 16ms),
•
reguły wybierania,
Linksys SPA3102 to router z 2 portową bramką VoIP wyposażoną w 1
port FXS i 1 port FXO. Zakres zastosowania tej bramki jest większy niż
w przypadku innych bramek, dzięki portowi FXO można bramkę podłączyć do centrali telefonicznej jako linię wewnętrzną a także umożliwić
wdzwanianie się z sieci PSTN na bramkę. Podczas gdy inna osoba może
korzystać z telefonu podłączonego do portu FXS.
Cechy urządzenia:
•
1 port WAN Internet RJ45,
•
1 port LAN ethernet RJ45,
•
router z obsługa DHCP klient/serwer,
•
obsługa PPPoE, stałego IP,
•
NAT, przekierowanie portów,
•
możliwość przypisania stałego adresu IP do podanego adresu
MAC,
•
1 port FXS RJ11,
•
1 port FXO RJ-11,
•
protokół głosowy SIP v.2,
•
kodeki G.711 a/u, G.726 (16/24/32/40 kbps), G.729A, G.723.1
(6.3 kb/s, 5.3 kbps),
•
REN (Ringer Equivalence Number) - 3 REN na każdy port RJ11,
•
Ring frequency: 10-40 Hz,
•
voltage: 40-55 Vrms,
•
impedancja portu FXS: 8 ustawień (europejskie CTR21 oraz
49
Jedna z niewielu bramek wyposażonych
w port FXO. Podczas testów charakteryzowała ją duża niezawodność i dobra
jakość głosu. Poważnym atutem bramki
jest możliwość ustawienia bufora dla
jitera. Router Linksys SPA3102 został
zastosowany jako bramka VoIP w
oddziałach w Gdańsku i Wrocławiu.
Typ urządzenia
D-Link Telefon
VoIP DPH-120S
GrandStream GXP2000
Zdjęcie
Charakterystyka
amerykańskie 600 Ohm),
•
obsługa: DTMF, FSK Caller ID, DTMF Caller ID, FSK VMWI,
•
niwelacja echa,
•
DPH-120S to telefon IP z wbudowanym jednoportowym roterem pozwwalającym na dołączenie komputera
Parametry:
•
WAN: 1 x Ethernet 100Base-TX,
•
LAN: 1 x Ethernet 100Base-TX dla PC lub LAN,
•
protokół VoIP: SIP,
•
wyświetlacz: LCD 2 x 16 znaków,
•
funkcje: Redial, Menu, Mute, Transfer, Hold, Voice mail, 3way conference, Speaker, Address book (200 wpisów), Speed
dial (10 wpisów),
•
konfiguracja: przeglądarka Web, klawiatura lokalna
Obsługiwane protokoły i standardy
•
QoS - Quality of Service (kontrola jakość usług i przepustowości)
•
IEEE 802.1Q - Virtual LANs
•
UPnP - Universal plug-and-play
•
NAT - Network Address Translation
•
DHCP Client - Dynamic Host Configuration Protocol Client
•
PPPoE - Point-to-Point Protocol over Ethernet
•
TCP/IP - Transmission Control Protocol/Internet Protocol
•
UDP - datagramowy protokół użytkownika
•
ARP - Address Resolution Protocol
•
IEEE 802.3 - 10BaseT
•
IEEE 802.3u - 100BaseTX
Telefon GXP-2000 to telefon IP umożliwiający jednoczesną rejestrację
do 4 kont VoIP. Główne cech tego aparatu to:
•
wieloliniowy wyświetlacz LCD;
•
protokół VoIP: SIP;
•
port WAN: 1x 10/100;
•
port PC: 1x 10/100;
•
obsługa 4 kont VoIP ;
50
Łatwa obsługa telefonu, dobra jakość
połączeń, w przypadku dołączenia PC
do portu LAN występują problemy z
połączeniem sieciowym
Typ urządzenia
Telefon AT-320
Telefon Linksys
SPA942
Zdjęcie
Charakterystyka
•
kodeki: ITU G.711, ITU G.722, ITU G.723, ITU G.726, ITU
G.728, ITU G.729, iLBC;
•
złącze dla zestawu słuchawkowego;
•
port rozszerzeń (w przyszłości ukażą się akcesoria, np. dodatkowa klawiatura)
AT-320 to uniwersalny telefon IP obsługujący wszystkie najbardziej
znane protokoły VoIP wyposażony w 2-portowy Hub ethernetowy.
Cechy produktu:
•
2 porty ethernet RJ-45
•
obsługa protokołów: H.323 v4, MGCP RFC2705, SIP
RFC3261, Net2phone, IAX2,
•
obsługa protokołu PPPoE,
•
obsługa stałego IP a także DHCP,
•
obsługa VLAN
•
kodeki G.723.1, G.729A/B, G.711, GSM,
•
•
CNG generator szumów,
•
AGC automatyczna regulacja poziomu sygnału
•
dynamiczny bufor głosowy (Voice Jitter),
•
redukcja echa (G.168),
•
wyświetlacz LCD 2 wiersze po 16 znaków,
•
konfiguracja przez przeglądarkę www oraz klawiaturę telefonu,
Linksys SPA942 to telefon IP obsługujący protokół SIP wyposażony w
2-portowy Hub ethernetowy.
Cechy urządzenia:
•
2 porty FastEthernet (RJ-45),
•
1 port do słuchawki telefonicznej (RJ-7),
•
1 port do słuchawek (2.5mm),
•
wbudowany zestaw głośnomówiący i mikrofon,
•
wyświetlacz monochromatyczny 128x64 pixeli
•
obsługa protokołu SIP v.2,
•
obsługa kodeków G.711a, G.711u, G.726 (16/24/32/40 kbps),
G.729A, G.723.1 (6.3 kb/s, 5.3 kbps),
•
automatyczne wykrywanie głosu VAD,
•
obsługa serwera STUN,
•
przesyłanie pakietów głosowych za pomocą szyfrowanego
51
Zaletą telefonu jest możliwość obsługi
między innymi protokołu IAX2. Do wad
telefonu należą nie najwyższa jakość
połączeń i sporadyczne zrywanie połączeń.
Prosty w obsłudze, w pełni funkcjonalny,
oferujący połączenia dobrej jakości.
Typ urządzenia
Cisco 7940
Cisco 7961G
Zdjęcie
Charakterystyka
protokołu SRTP,
•
możliwość określania wielkości ramek audio na pakiet,
•
obsługa dzwonienia przez adresy IP,
•
zabezpieczenie systemu hasłem (przed resetem, zmianą ustawień),
•
osobne panele konfiguracyjne dla użytkownika i administratora,
•
wbudowany serwer www do zarządzania telefonem,
•
zarządzanie poprzez klawiaturę telefonu,
•
system provisioningu przez HTTPS, HTTP, TFTP,
•
obsługa Syslog and Debug Server Records – dla każdego
konta,
•
możliwość podłączenia 2 kont VoIPz opcją rozszerzenia do 4
niezależnych kont (wymagany upgrade firmware),
Słuchawka ,ID Dzwoniącego ,Głosowy mail, Oczekiwanie na połączenia
, Przekazywanie połącze, Transfer połączeń, Wstrzymanie połączenia,
Menu operacyjne, Regulacja siły głosuWymiary:Szerokość 26.6 cm
Głębokość 15.2 cm Wysokość 20.3 cmCechy dźwięku:Comfort noise
generation (CNG), voice activity detection (VAD)Protokół sieciowy:TFTPIlość portów sieciowych:2 x Ethernet 10/100Base-TXProtokoły
VoIP:H.323, MGCP, SCCP, SIP. Przypisywanie adresu IP:DHCP
Parametry jak Cisco 7940 + obsługa GigabitEthernet oraz do 6 kont VIP
52
Zalety:
Dobra jakość połączeń głosowych.
Przejrzyste menu
Stabilność działania
Wady:
Znacznie utrudniona wymiana oprogramowania, a co za tym idzie przystosowanie do współpracy z serwerami
innymi niż pochodzące od producenta
Firmware dla protokołu SIP optymalizowany jest pod kątem współpracy ze
sprzętem Cisco, wskutek czego występują błędy we współpracy z pozostałym
sprzętem
Typ urządzenia
Zyxel telefon Wi-Fi Prestige 2000W v2.0
Zdjęcie
Charakterystyka
Prestige 2000W v2 - to bezprzewodowy telefon VoIP. Urządzenie
umożliwia realizację połączenia głosowego w sieci lokalnej lub poprzez
sieć Internet.
Telefon współpracuje z Access Point'ami działającymi w standardach
IEEE 802.11b/g. Urządzenia mogą również również pracować w trybie
Ad-hoc (dwa telefony połączone bezpośrednio ze sobą z pominięciem
AP). Prestige 2000W v2 to doskonałe rozwiązanie dla firm, które chcą
obniżyć koszty połączeń telefonicznych pomiędzy swoimi oddziałami.
ZyXEL Prestige 2000W v2 wyposażony jest w wyświetlacz LCD i
klawiaturę umożliwiającą wygodną konfigurację (np. dodawanie nowych
kontaktów do skrzynki adresowej). Konfiguracji można też dokonać
łącząc się z urządzeniem za pomocą przeglądarki internetowej.
Cechy Urządzenia:
•
obsługa protokołu SIP (RFC 3261) version 2,
•
obsługa SDP (RFC2327), RTP (RFC1889), RTCP (RFC1890),
•
kodeki G711, G.729a,
•
niwelacja echa G.168,
•
redukcja ciszy,
•
automatyczne wykrywanie głosu (VAD),
•
generator szumów tła(CNG),
•
obsługa STUN (RFC3489),
•
obsługa QoS (wsparcie dla TOS / DiffServ),
•
obsługa NAT Traversal dla outbound proxy,
•
możliwość skanowania dostępnych AP,
•
obsługa 64/128 bit WEP,
•
czas czuwania do 24 godzin maks,
•
maksymalny czas rozmowy do 4 godzin
•
obsługa stałego IP/DHCP, PPPoE
•
konfiguracja za pomocą www lub klawiatury,
•
obsługa provisioning'u.
53
Dobra jakość połączeń telefonicznych.
Do wad telefonu należą: krótki czas
pracy baterii, brak stacji dokującej oraz
ograniczone możliwości konfiguracji
poprzez klawiaturę (konfiguracja poprzez WWW daje większe możliwości)
Typ urządzenia
Nokia 9300i
Telefon USB AU 200
Telefon USB AU 100
Zdjęcie
Charakterystyka
Telefon komórkowy Nokia 9300i dzięki połączeniu z siecią WLAN i
pełnej klawiaturze, ekranowi o 65 536 kolorach, współpracy z wieloma
typami poczty elektronicznej push email i przeglądarką załączników,
stanowi ciekawą ofertę dla wymagających klientów. Połączenie z siecią
WLAN przyspiesza pracę Nokia 9300i, który udostępnia funkcję niezawodnego i taniego transferu danych. Dzięki temu pobieranie dużych
plików i wiadomości z załącznikami jest szybkie i ekonomiczne. Pamięć
o pojemności 80 MB (którą można zwiększyć do 2 GB za pomocą karty
MMC) gwarantuje wystarczająco dużo miejsca na przechowywanie
plików. Szeroki kolorowy ekran ułatwia wyświetlanie różnych dokumentów, arkuszy kalkulacyjnych, prezentacji i stron internetowych. Urządzenie jest wyposażone w funkcje łączności E-GPRS (EDGE) i WLAN
802.11g oraz umożliwia pięcioosobowe połączenia konferencyjne przez
wbudowany głośnik i pracę z wieloma programami poczty elektronicznej
(obsługującymi załączniki), np. Nokia Business Center, BlackBerry
Connect, IBM WebSphere, Oracle Collaboration Suite, Seven AlwaysOn Mail i Visto Mobile. Nokia 9300i umożliwia połączenia przez podczerwień i Bluetooth w celu bezprzewodowej synchronizacji urządzenia
z komputerem oraz wymiany danych z innymi urządzeniami mobilnymi.
Wygodny i prosty w obsłudze telefon USB z wyświetlaczem LCD.
Telefon nie wymaga instalacji jakichkolwiek sterowników - posiada
wbudowany sterownik (winXP/2000) i widoczny jest w systemie jako
odrębne niezależne urządzenie audio - można np. słuchać muzyki i
równocześnie prowadzić rozmowę przez telefon.
Wygodny i prosty w obsłudze telefon USB, bez wyświetlacza LCD.
Telefon nie wymaga instalacji jakichkolwiek sterowników - posiada
wbudowany sterownik (winXP/2000) i widoczny jest w systemie jako
odrębne niezależne urządzenie audio - można np. słuchać muzyki i
równocześnie prowadzić rozmowę przez telefon.
54
Nokia 9300i fabrycznie nie zapewnia
obsługi żadnego z protokołów VoIP tak
jak na przykład telefony Nokii serii E. W
związku z tym konieczne jest zainstalowanie softphonu obsługują protokołu
SIP lub IAX2. Podjęte próby uruchomienia softphona dla protokołu SIP,
skończyły się niepowodzeniem. Z uwagi,
że w IŁ do tej pory nie została uruchomiona sieć WiFi oraz brak dedykowanego dla Nokii 9300i oprogramowania dla
VoIP, wobec bardzo dynamicznego
rozwoju rynku, uznano za nie celowe
kupno oprogramowania softphonu.
Prosta obsługa.
Bardzo dobra współpraca z programami
Lite, Firefly.
Przeciętna jakość głosu.
Prosta obsługa.
Przeciętna jakość głosu.
Tabl. 7 Porównanie telefonów programowych VoIP
Nazwa softphonu
Firefly
X-Lite 3.0
Zdjęcie
Charakterystyka
Cechy softphonu:
protokoły VoIP: SIP, IAX2, Firefly
kodeki: G711, GSM, iLBC, SPEEX
przesyłanie video: NIE
ilość obsługiwanych kont: 4
IM Presence: w sieci Firefly
STUN: TAK
Dodatkowe funkcje:
•
•
•
•
•
obsługa komunikatora Firefly
Cechy softphonu:
protokoły VoIP: SIP,
kodeki: G711, GSM, iLBC, BroadVoice-32, DVI4 Wideband
przesyłanie video: TAK (H.263)
IM Presence: TAK
STUN: TAK
Dodatkowe funkcje:
•
•
•
•
•
usuwanie echa
55
Prosty w obsłudze komunikator jako
jedyny zapewniający obsługę zarówno
protokołu IAX2 jak i SIP. Niestety
najnowsze wersje tego komunikatora
obsługują jedynie wewnętrzny protokół
Firefly, dlatego nie zalecamy stosowania
tego sontphonu.
Softphone x-Lite jest jednym z telefonów programowych najczęściej polecanych przez operatorów telefonii internetowej. Cechuje go bardzo dobra jakość
głosu, szczególnie pozytywnie na tle
innych programów x-Lite realizował
funkcję usuwania echa ( echo nie było
uciążliwe nawet w przypadku korzystania z typowych głośników i mikrofonu).
Telefon ma duże możliwości funkcjonalne (video, IM Presence). Ponadto
cechuje go stabilna praca. Do zalet
należy zaliczyć pełną współpracę ze
słuchawkami USB. Jedyną stwierdzoną
jego wadą jest korzystania z niestandardowych portów.
Nazwa softphonu
SJPhone
Windows Messenger 5.1
Snom 360
Zdjęcie
Charakterystyka
Cechy softphonu:
protokoły VoIP: SIP, H.323
kodeki: G711, GSM, iLBC,
IM Presence: NIE
STUN: TAK
Dodatkowe funkcje:
•
•
•
•
Bardzo stabilny, w pełni funkcjonalny
softphone obsługujący protokoły SIP i
H.323. jedną z zalet tej aplikacji jest
możliwość ustawienia jitterbufera.
Porównując z x-Litem, wydaje się
nieznacznie bardziej skomplikowany w
obsłudze.
Cechy softphonu:
protokoły VoIP: SIP
kodeki: G711, G723, GSM, DVI4 Wideband
przesyłanie video: TAK (H261, H263)
IM Presence: TAK
STUN: NIE
Dodatkowe funkcje:
•
•
•
•
•
zdalne udostępnianie aplikacji, pulpitu i tablicy
•
przesyłanie plików
Cechy softphonu:
protokoły VoIP: SIP,
kodeki: G711, GSM
IM Presence: TAK
STUN: TAK
Dodatkowe funkcje:
•
Komunikator z obsługą SIP przeznaczony głownie do pracy w sieci MSN. W
zastosowaniu jako terminal SIP zbiór
funkcjonalności ograniczony jedynie do
podstawowych funkcji tj. połączeń
głosowych i video. Pozostałe funkcjonalności takie jak udostępnianie pulpitu
nie działają. Mało przyjazny interfejs
użytkownika (w przypadku SIP). najnowsze wersje Messenger nie obsługują
protokołu SIP.
56
Zaletą telefonu jest możliwość jednoczesnej rejestracji 12 kont oraz możliwość
szyfrowania transmisji poprzez SRTP.
Wadą jest mała liczba obsługiwanych
kodeków, słaba jakość połączeń oraz
niepraktyczny interfejs użytkownika.
Nazwa softphonu
DIAX
iaxLite
Zdjęcie
Charakterystyka
•
•
•
•
szyfrowanie transmisji SRTP
Cechy softphonu:
protokoły VoIP: IAX2
kodeki: G711, GSM, iLBC, SPEEX
IM Presencenie: NIE
STUN: Nie dotyczy
Dodatkowe funkcje:
•
•
•
•
Dynamiczny bufor głosowy (Voice Jitter),
Cechy softphonu:
protokoły VoIP: IAX2
kodeki: G711, G729, GSM, iLBC, SPEEX
IM Presencenie: NIE
STUN: Nie dotyczy
Dodatkowe funkcje:
•
•
•
•
57
Telefon do obsługi protokołu IAX2,
bardzo prosty w obsłudze, pełnej funkcjonalności i małych wymaganiach
sprzętowych, oferujący dobrą integrację
z niektórymi telefonami USB. Podczas
testów zaobserwowano sporadyczne
„zawieszanie się” telefonu.
Telefon do obsługi protokołu IAX2,
bardzo prosty w obsłudze, oferujący
podstawowe funkcje i dobrą integrację z
telefonami USB. Do głównych zalet
telefonu należy obsługa kodeka G729.
Wadą jest słabe tłumienie echa (nawet w
przypadku korzystania ze telefonów
USB)
Podsumowanie testów funkcjonalno-użytkowych.
W przypadku bramek VoIP wiele z nich oferuje podobną funkcjonalność. Wszystkie
testowane bramki współpracowały z protokołem SIP (tylko 2 z testowanych bramek współpracowały z protokołem IAX2) oraz obsługiwały do kilku kodeków. Każda z testowanych
bramek obsługiwała kodeki G711 i G729a (preferowany dla sieci IŁ). W wyniku przeprowadzonych testów do stosowania w sieci VoIP IŁ rekomenduje się:
• Bramki firmy Linksys do współpracy za pomocą protokołu SIP. W ofercie tej
firmy w zakresie bramek VoIP znalazło się wiele różnych produktów ale będących jednocześnie jednolitym produktem z punktu widzenia rozwiązania VoIP
(te same funkcje, możliwości, zarządzanie), które pozwalają wybrać bramkę
optymalną pod kątem potrzeb użytkownika. Dodatkowo za bramkami Linksys
przemawiają ich niezawodność oraz obsługa SRTP (szyfrowanie transmisji).
• Bramki YGW- 20 do współpracy za pomocą protokołu IAX2. Pomimo przeciętnych parametrów w zakresie jakości głosu jest to jedna z zaledwie 2 testowanych obsługujących protokół IAX2.
W przypadku telefonów VoIP wszystkie oferuje podobną funkcjonalność. Wszystkie
testowane bramki współpracowały z protokołem SIP (tylko 1 z testowanych tlefonów współpracował z protokołem IAX2) oraz obsługiwały do kilku kodeków. Każda z testowanych
bramek obsługiwała kodeki G711 i G729a (preferowany dla sieci IŁ). Główne różnice, to
liczba obsługiwanych kont, wielkość wyświetlacza, sposób obsługi telefonu. W wyniku przeprowadzonych testów do stosowania w sieci VoIP IŁ rekomenduje się:
• Telefony SPA942 firmy Linksys do współpracy za pomocą protokołu SIP.
• Telefony AT-320 firmy Atcom do współpracy za pomocą protokołu IAX2,
gdyż jest to jedyny telefon VoIP zapewniający współpracę z protokołem IAX2.
W obszarze telefonów programowych (softphonów) do stosowania w sieci VoIP IŁ
rekomenduje się:
• Oprogramowanie X-Lite 3.0 dla obsługi protokołu SIP. Jest to darmowy softphone o
dużych możliwościach funkcjonalnych, w tym połączenia video, charakteryzujący się
stabilną pracą i dobrym tłumieniem echa.
• Oprogramowanie DIAX lub iaxLite dla obsługi protokołu IAX2.
Dla połączeń video rekomenduje się wykorzystanie oprogramowania X-Lite 3.0 z dołączoną
kamerą.
7. Platforma VoIP w Instytucie Łączności
7.1. Wybór platformy
Do uruchomienia rozwiązania produkcyjnego wybrano zintegrowane rozwiązanie o
nazwie TrixBox. Rozwiązanie to składa się z następujących komponentów:
•
System operacyjny Linux CentOS 4.4 (http://www.centos.org),
•
Oprogramowanie serwera IP-PBX Asterisk 1.2.12 (http://www.asterisk.org),
•
freePBX – interfejs administratora systemu VoIP oparty na serwerze WWW, udostępniający zbiór narzędzi na potrzeby administrowania systemem serwerem Asterisk, składający się z następujących komponentów:
o Call Reporting – komponent oprogramowania freePBX przeznaczony do
administrowania rekordami CDR (m. in. funkcje przeglądania, archiwizacji, konwersji do typowych formatów danych),
o Flash Operator Panel, konsola operatora przeznaczona do bieżącej wizualizacji procesów w systemie IP-PBX,
•
Sugar, oprogramowanie służące do zarządzania relacjami z użytkownikiem (Customer Relationship Management),
•
A2Billing oprogramowanie wspomagające obsługę płatności w systemie pre-paid,
•
Web Meet Me Control, oprogramowanie wspomagające obsługę połączeń konferencyjnych,
•
system utrzymania wykorzystujący terminal użytkownika do realizacji czynności
utrzymaniowych.
Wyboru platfomy dokonano na podstawie doświadczeń w eksplaotacji testowej platformy VoIP opartej początkowo o rozwiązanie Asterisk@Home, będące poprzednikiem
rozwiązania Trixbox. Platforma sprzętowa wykorzystana na potrzeby tego rozwiązania to
serwer wyposażony w:
•
procesor Intel(R) Xeon(TM) CPU 3.00GHz,
•
urządzenia SCSI, RAID,
•
kartę Digium TE400P, zapewniającą możliwość dołączenia serwera do sieci
PSTN/ISDN za pośrednictwem łącza PRI (do 4 łączy), co czyni z tego rozwiązania
serwer z funkcjonalnością IP-PBX oraz bramy VoIP,
Wybór platformy sprzętowej został podyktowany koniecznością zapewniania odpowiedniego poziomu wydajności rozwiązania. Rozpatrywane wykorzystanie platformy wirtualnej zastępującej rozwiązanie sprzętowe nie zostało sfinalizowane ze względu na negatywny
wyników testów wydajności takiego rozwiązania.
7.2. Rozwiązania rekomendowane do stosowania w sieci VoIP Instytutu Łączności
Zakłada się, głównym protokołem w sieci VoIP Instytutu Łączności będzie protokół SIP.
Dodatkowo w uzasadnionych przypadkach poszczególni użytkownicy sieci VoIP mogą stosować protokół IAX2. Z uwagi na bezpieczeństwo zarówno systemu VoIP, jak i całej sieci
informatycznej IŁ wymagane jest, by wszyscy użytkownicy korzystający z dostępu do we59
wnętrznej sieci telefonicznej poprzez Internet stosowali szyfrowanie transmisji w ramach
kanałów Internet-VPN. Konsekwencją tego wymogu jest decyzja, by wszyscy użytkownicy
indywidualni korzystający z dostępu do sieci VoIP poprzez Internet korzystali z rozwiązania
typu softphone + klient VPN (na razie nie przewiduje się dostępu do systemu z wykorzystaniem bramek VoIP lub telefonów IP pomimo, że jest to technicznie realizowalne). Mając na
uwadze powyższe założenia w sieci VoIP IŁ rekomenduje się stosowanie:
• karty TE405P firmy Digium, jako główna bramę między siecią VoIP a siecią
TDM w Warszawie;
• routerów SPA3102 firmy Linksys (FXO), jako bramy między siecią VoIP a siecią
TDM w Gdańsku i Wrocławiu;
• telefonów IP SPA942, jako telefony wykorzystywane w wewnętrznej sieci Intranet;
• programowych telefonów Lite 3.0 razem z zestawem słuchawka+mikrofon lub telefon USB;
Dla celów telefonii VoIP w Instytucie łączności powinien być stosowany kodek G729a
lub zamiennie iLBC.
7.3. Integracja z systemem telefonicznym Instytutu Łączności
7.3.1. Konfiguracja systemów telefonicznych w IŁ
Zadaniem systemu VoIP w IŁ jest połączenie za pomocą Internet-VPN systemów telefonicznych w trzech oddziałach: gdańskim, warszawskim i wrocławskim i zapewnienie darmowych połączeń telefonicznych pomiędzy tymi oddziałami. Węzeł sterujący systemu VoIP
zlokalizowany został w oddziale warszawskim, a w każdej z tych lokalizacji została zainstalowana brama VoIP. Dodatkową funkcjonalnością systemu VoIP jest umożliwienie pracy
zdalnej z wykorzystaniem klienta VPN i oprogramowania typu softphone.
Konfigurację systemów telefonicznych w IŁ przedstawiono na rysunku (Rys. 29).
Rys. 29. Konfiguracja systemów telefonicznych w Instytucie Łączności
60
7.3.2. Plan numeracyjny w Instytucie Łączności
Skonstruowanie planu numeracyjnego wymagało dostosowania istniejącego planu
numeracyjnego w sposób, który zapewni zarówno łatwość korzystania, jak i nie będzie burzył
dotychczasowego jego układu. W chwili obecnej wykorzystywane są następujące schematy
numeracji:
Warszawa
• linie wewnętrzne są wykorzystywane przez pracowników IŁ i podmioty zewnętrzne
prowadzące swoją działalność na terenie IŁ Warszawa
• wykorzystywane zakresy: 1XX, 2XX, 3XX, 4XX, 6XX, 7XX, 8XX, 9XX ,
• wewnętrzni abonenci centrali są osiągani bezpośrednio po wybraniu numeru
0(prefiks)225128YXX, gdzie YXX to numer abonenta centrali,
Gdańsk
• linie wewnętrzne są wykorzystywane przez pracowników IŁ oraz podmioty zewnętrzne
• wykorzystywane zakresy wykorzystywane na potrzeby IŁ: 1XX (10 numerów wewnętrznych), 2XX (10 numerów wewnętrznych),
• abonenci wewnętrzni centrali są osiągani z wykorzystaniem łączy zewnętrznych, jednak zestawienie połączenia wymaga pośrednictwa obsługi centrali.
Wrocław
• linie wewnętrzne są wykorzystywane przez pracowników IŁ oraz podmioty zewnętrzne,
• wykorzystywane na potrzeby IŁ: 8XX (28 katalogowych, osiąganych bezpośrednio
spoza centrali PBX),
• wewnętrzni abonenci centrali są osiągani bezpośrednio po wybraniu numeru
0(prefiks)583699YXX, gdzie YXX to numer abonenta centrali,
Modyfikacja planu numeracyjnego polega na przeznaczeniu zakresów numeracji w
siedzibie warszawskiej: 5XX (aktualnie wykorzystywany przez użytkowników VoIP) oraz
8XX dla użytkowników VoIP oraz realizacji usług dodatkowych. Wykorzystywane zakresy
numeracji w lokalizacjach w Gdańsku i Wrocławiu nie ulegną zmianie. Sposób wybierania
numerów wewnętrznych oraz dostęp do funkcji oferowanych na platformie Asterisk przedstawiono w tabeli.
Tabl. 8. Schematy wybierania numerów dla połączeń i dostępu do usług
Kierunek/funkcja
Warszawa =>Gdańsk (z wykorzyst. VoIP)
Gdańsk => Warszawa (z wykorzyst. VoIP)
Warszawa => Wrocław (z wykorzyst. VoIP)
Wrocław => Warszawa (z wykorzyst. VoIP)
Schemat wybierania
555(sygnał)YXX (gdzie YXX wewnętrzny
numer abonenta w centrali PBX w Gdańsku)
200(sygnał)YXX (gdzie YXX wewnętrzny
numer abonenta w centrali PBX w Warszawie)
8XX (wewnętrzny numer abonenta w centrali PBX we Wrocławiu)
858 (sygnał) YXX (gdzie YXX wewnętrzny
numer abonenta w centrali PBX w Warszawie)
61
Przekazanie połączenia do poczty głosowej
(tylko użytkownicy w Warszawie oraz użytkownicy zdalni)
Obiór faksów (dla usługi fax-to-email, tylko
użytkownicy w Warszawie oraz użytkownicy
zdalni)
500 (jednakowy numer dla wszystkich użytkowników)
Numer z zakresu 5XX (osiągany bezpośrednio z sieci PSTN)
Aby zapewnić możliwość zestawiania połączeń z wykorzystaniem systemu VoIP, niezbędna była zmiana ustawień konfiguracyjnych centrali Hicom w IŁ Warszawa. Zestaw
dokonanych zmian w tym zakresie przedstawiono w kolejnym punkcie.
7.3.3. Wykaz zmian w konfiguracji centrali PBX Hicom 300E w siedzibie IŁ w Warszawie
W celu adaptacji konfiguracji centrali PBX w siedzibie IŁ w Warszawie zaproponowano zmiany w konfiguracji centrali Hicom, które obejmowały:
1. kierowanie na łącze wewnętrzne PRI o numerze 89 połączeń na numery z zakresu:
a)
22 51285XX (wewnętrznie 5XX)
b)
22 51288XX (wewnętrznie 8XX)
c)
22 5128111
2. określenie sposobu formowania informacji adresowej zawartej w wiadomościach protokołu DSS1 przesyłanych przez PBX według następujących zasad:
a)
dla połączeń z numerów wewnętrznych, po wybraniu 971xxxx xxx, połączenia
są kierowane na łącze wewnętrzne PRI o numerze 89. Przy czym element informacyjny Called Party Number jest wówczas równy 71xxxx xxx, (pełny
numer krajowy bez cyfry 9),
b)
dla połączeń z numerów wewnętrznych, po wybraniu 958 xxxx xxx, połączenia
są kierowane na łącze wewnętrzne PRI o numerze 89, przy czym element informacyjny Called Party Number jest wówczas równy 58 xxxx xxx (pełny
numer krajowy bez cyfry 9),
3. dla połączeń do/ z łącza wewnętrznego PRI o numerze 89:
a)
Ustalenie domyślnej nazwy dla połączeń przychodzących na VoIP
b)
zlikwidowanie logicznego podziału kanałów.
c)
zlikwidowanie ograniczeń na możliwość realizacji połączeń jedynie w strefie
warszawskiej. Wymaga się, by było możliwe zestawianie połączeń na dowolny
numer.
d)
skonfigurowanie przesyłania sygnałów DTMF, w szczególności od systemowych aparatów Optiset centrali Hicom
e)
skonfigurowanie obsługi elementu informacyjnego Display (wyświetlanie na
aparatach systemowych zawartości otrzymanej w parametrze Display oraz
wpisywanie przez Hicom w parametrze Display informacji, które wyświetlane
są na wewnętrznych aparatach systemowych). Display nie powinien być wysyłany na łącza do sieci PSTN.
f)
zapewnienie możliwości przekazywania rozmów przez abonentów dołączonych do centrali za pośrednictwem łącza PRI do użytkowników centrali Hicom
oraz przekazywania w wiadomościach DSS1 numeru użytkownika przekierowującego (element informacyjny - Redirecting Number)
62
g)
zapewnienie możliwość tworzenia grup wewnętrznych użytkowników centrali
Hicom pomiędzy użytkownikami Hicom i numerami dołączonymi za pomocą
tego łącza PRI.
W wyniku uzgodnień z przedstawicielami firmy Siemens, ustalono, że punkty 3e oraz
3g nie są możliwe do realizacji. W pierwszym przypadku przyczyną jest sposób wykorzystania elementu informacyjnego Display przez centralę Hicom, który nie przewiduje przesyłania
za jego pośrednictwem nazwy abonenta. Prowadzi to do ograniczenia funkcjonalności zintegrowanego systemu (złożonego z centrali Hicom oraz dołączonego serwera VoIP Asterisk).
Ograniczenie to polega na braku możliwości wyświetlania nazwy użytkownika (tak, jak ma to
miejsce w przypadku systemu Hicom) dla połączeń pomiędzy użytkownikami dwóch systemów, choć nadal jest wykorzystywana prezentacja numeru abonenta wywołującego. Zachowana natomiast zostaje prezentacja nazwy, jeśli połączenie wykonywane jest pomiędzy użytkownikami należącymi do tego samego systemu.
Z kolei zmiana konfiguracji centrali Hicom pozwalająca tworzyć grupy użytkowników
należących do zintegrowanego systemu nie była możliwa ze względu na brak obsługi tej
funkcjonalności w zaimplementowanej wersji oprogramowania (tj. ver 2.0).
7.4. System poczty głosowej
Aby skorzystać z usługi poczty głosowej, użytkownik posiadający własną skrzynkę
głosową na serwerze Asterisk powinien zaprogramować za pomocą aparatu telefonicznego
(systemowego lub analogowego) funkcję przekazywania połączeń na wspólny dla wszystkich
użytkowników usługi numer 500. W przypadku przekazania przychodzącego połączenia do
systemu poczty głosowej (1), rejestracja nagrania jest dokonywana w indywidualnej skrzynce
głosowej abonenta, osiąganej na podstawie informacji o numerze przekierowującym (IE
Redirecting Number), zawartej w wiadomości SETUP protokołu DSS1.
Wiadomość w skrzynce jest pozostawiana po usłyszeniu odpowiedniej zapowiedzi
głosowej oraz sygnału informującego o rozpoczęciu rejestracji (2). Zakończenie rejestracji ma
miejsce z chwilą odłożenia mikrotelefonu przez abonenta wywołującego. Po zakończeniu
rejestracji wiadomości, jest ona wysyłana pocztą elektroniczną za pomocą serwera zainstalowanego na platformie sprzętowej obsługującej serwer VoIP (3) na adres e-mail przypisany do
skrzynki głosowej użytkownika za pośrednictwem serwera Exchange (4 i 5). Schemat realizacji usługi został przedstawiony na rysunku (Rys. 30).
63
Rys. 30. Schemat realizacji usługi poczty głosowej w oddziale IŁ w Warszawie (objaśnienia w tekście)
Ze względu na zastosowanie jednoportowych bram analogowych w oddziałach w
Gdańsku i Wrocławiu usługa poczty głosowej jest dostępna jedynie dla użytkowników centrali Hicom oraz użytkowników zdalnych, korzystających z telefonii VoIP w IŁ za pomocą
dostępu do Internetu.
7.5. Interaktywne menu głosowe – IVR
Obok poczty głosowej system interaktywnego menu głosowego IVR (Interactive Voice Response) jest jedną z najczęściej implementowanych funkcjonalności w centralach IPPBX. W usługach świadczonych przez telefoniczne centra obsługi klienta funkcjonalność ta
jest podstawowym elementem kompleksowego rozwiązania - Call Center. Funkcje IVR
realizowane przez serwer Asterisk na potrzeby Instytutu Łączności zostały zdefiniowane przy
współudziale Działu Sprzedaży i Marketingu. Na tej podstawie opracowano schemat drzewa
wyboru, dostępnego po wybraniu z sieci PSTN numeru wewnętrznego 0(prefiks)22 5128 100.
Schemat został przedstawiony na rysunku.
64
Połączenie przychodzące
na numer
0(prefiks)225128100
Przekierowanie bezwarunkowe
połączenia na numer z zakresu
5XX
(system IVR)
Odtworzenie zapowiedzi:
„Witamy w Instytucie Łączności.
For English press 1”
„W celu uzyskania połączenia w
sprawie wzorcowania przyrządów
proszę wybrać tonowo cyfrę 2"
„W sprawie badań zgodności do
znaku CE proszę wybrać 3"
„W sprawie wypożyczania
przyrządów pomiarowych proszę
wybrać 4"
„Dla połączeń w sprawie szkoleń
proszę wybrać 5"
„lub 0 w celu uzyskania
połączenia z operatorem”
„5"
Przeniesienie na numer
704 lub w przypadku braku
odpowiedzi na 448
„4”
odpowiedzi na 102
„1"
Odtworzenie zapowiedzi:
„Welcome to the National Institute of
Telecommunication”
„To be connected with measurement
instruments laboratory press 2”
„...with testing laboratory press 3”
„... with instruments rental inventory
press 4”
„to be connected with telecom
training center press 5”
„...or 0 to the operator”
„2”
383 lub w przypadku
braku odpowiedzi na 102
„3"
odpowiedzi na 102
„2"
383 lub w przypadku
braku odpowiedzi na 102
„3"
odpowiedzi na 102
„0"
odpowiedzi na 448
„4"
odpowiedzi na 102
„0”
odpowiedzi na 448
„5"
odpowiedzi na 448
Rys. 31. Uzgodniona z działem DSM struktura drzewa IVR na potrzeby Instytutu Łączności
7.6. Założenie organizacyjne systemu VoIP
1.
Zakłada się, że za funkcjonowanie systemu VoIP w Instytucie Łączności odpowiada
Ośrodek Informatyki (OI). Oznacza to, że administracja użytkownikami, usługami, bezpieczeństwem, a także odpowiedzialność za działanie sprzętu spoczywa na OI.
2.
Każdy pracownik IŁ (oddział Warszawa) może złożyć wniosek o założenie konta poczty
głosowej (voicemail) powiązanego ze wskazanym numerem wewnętrznym centrali Hicom.
3.
Każdy pracownik IŁ może złożyć wniosek o przyznanie numeru VoIP w sieci IŁ (wymaga przyznania licencji klienta VPN). Zakłada się, że ze względów bezpieczeństwa
wszystkie połączenia za pośrednictwem Internetu będą realizowane z wykorzystaniem
szyfrowanej transmisji w kanałach Internet-VPN.
65
8. Porównanie platformy Asterisk z oferowanymi komercyjnie rozwiązaniami IP-PBX
W ramach niniejszej pracy podjęto próbę porównania możliwości funkcjonalnych platformy Asterisk oraz komercyjnie oferowanych rozwiązań renomowanych firm telekomunikacyjnych. Z tego porównania wynika, że platforma Asterisk w zakresie oferowanych funkcjonalności nie odbiega od rozwiązań komercyjnych. Zaletą Asterisk jest nieograniczony licencją
dostęp do pełnej funkcjonalności oraz przyszłych aktualizacji. Z kolei wadą jest to, że poszczególne składniki systemu są rozwijane osobno, co stwarza problemy z ich integracją. W
kolejnych podpunktach zamieszczono krótkie charakterystyki platformy Asterisk oraz wybranych rozwiązań VoIP oferowanych komercyjnie.
8.1. Asterisk
Asterisk stanowi platformę komunikacyjną stworzoną w ramach oprogramowania typu
Open Source. Platforma zapewnia funkcjonalność PBX oraz IVR w obsłudze połączeń w
technologii TDM, jak również połączeń realizowanych w technologii pakietowej. Obok funkcjonalności PBX i IVR, rozwiązanie to ma zapewniać spójną platformę komunikacyjną wykorzystywaną przez aparaty końcowe pochodzące od różnych producentów oraz oprogramowanie realizujące funkcje aparatów końcowych. Podstawowe funkcje platformy komunikacyjnej,
którą stanowią systemy oparte na implementacji serwera Asterisk to:
•
funkcje bramy medialnej (TDM-IP gateway) pomiędzy systemami z komutacją
kanałów oraz systemami z komutacją pakietową, realizujący translację wiadomości sygnalizacyjnych oraz kanałów użytkowych ( dla połączeń realizowanych w
oparciu o protokoły MGCP, SIP, IAX, H.323), pod warunkiem zapewniania odpowiedniego wyposażenia sprzętowego w postaci karty rozszerzenia, zapewniającej interfejs do sieci PSTN/ISDN,
•
wsparcie dla transmisji video na potrzeby wideokonferencji,
•
funkcje prywatnej centrali abonenckiej PBX (Private Branch eXchange),
•
funkcje serwera interaktywnych zapowiedzi głosowych IVR (Interactive Voice
Response),
•
funkcje rozproszonego węzła komutacyjnego typu Softswitch,
•
funkcje serwera konferencyjnego (Conferencing Server),
•
funkcje translacji numeracji (Number translation),
•
funkcje obsługi połączeń opłacanych na zasadach przedpłaty (Calling card application),
•
funkcje kolejkowania przychodzących połączeń (Call queuing with remote
agents).
Oprogramowanie to jest rozpowszechniane na warunkach licencji GNU GPL(General
Public License). Ten typ licencji pozwala na swobodną dystrybucję oprogramowania platformy Asterisk zarówno w postaci zbiorów wykonywalnych (postać binarna) jak również zbiorów w postaci źródłowej (nieskompilowanej). Redystrybucja postaci źródłowej oprogramowania jest również możliwa po dokonaniu modyfikacji w kodzie. Ten typ licencji nie obejmuje jednak sprzętu, który jest wykorzystywany do uruchomienia oprogramowania w tym kart
rozszerzeń oraz niezbędnego do ich prawidłowego funkcjonowania oprogramowania. Oznacza to również, że wykorzystywane przez użytkowników platformy oprogramowanie klienc66
kie (telefony software’owe oraz oprogramowanie telefonów hardware’owych) nie jest objęte
tą samą licencją GNU GPL. Rozwiązanie to zapewnia obsługę takich protokołów, jak: IAX2,
SIP, H.323, MGCP, oraz SCCP/Skinny.
Asterisk może być uruchamiany na wielu w oparciu o różne systemy operacyjne,
wśród których najpopularniejsze to: Linux, BSD, Windows i OS X. Architektura platformy
Asterisk została zaprojektowana w odmienny sposób, niż ma to miejsce w przypadku większości kompletnych systemów telekomunikacyjnych. Oprogramowanie platformy Asterisk
pełni w tym wypadku jedynie funkcje warstwy pośredniczącej (middleware) w architekturze
całego systemu (Rys. 32). Znaczenie funkcji middleware dotyczy w tym wypadku realizacji
funkcji niezbędnych do szeroko rozumianej obsługi połączeń VoIP, pozostawiając warstwie
systemu operacyjnego obsługę mechanizmów sieciowych, w tym związanych z poprawną
wymianą danych w sieci Internet.
Rys. 32. Ogólna architektura platformy Asterisk
Jednocześnie oprogramowanie platformy zapewnia współpracę ze sterownikami kart
rozszerzeń. Karty te umożliwiają obsługę interfejsów do sieci telefonicznych w standardach
TDM, takich jak:
•
ISDN, z obsługą zarówno dostępu pierwotnego (30B+D) jak również podstawowego (2B+D),
•
PSTN, przy czym obsługiwane mogą być dwa typy portów: FXO, wymagający zasilania i zapewniające współpracę z centralą oraz FXS, zapewniający zasilanie linii
abonenckiej i umożliwiające dołączenia do niej tradycyjnego analogowego aparatu
telefonicznego.
Fizyczna realizacja ww. interfejsów za pośrednictwem kart rozszerzeń jest realizowana
za pomocą sterowników tych urządzeń, zaś Asterisk zapewnia obsługę tzw. kanałów (ang.
channels), z którymi skojarzone są poszczególne metody transmisji głosu i obrazu w postaci
pakietowej, charakteryzujące się odmiennymi protokołami sygnalizacyjnymi. Pojęcie kanałów w przypadku tej platformy jest równoznaczne z oprogramowaniem sterowników przeznaczonych do obsługi wielu typów urządzeń wykorzystujących różne protokoły komunikacyjne.
Zbiór obsługiwanych urządzeń i aplikacji zawiera typowe rozwiązania z obszaru VoIP (telefony IP, serwery VoIP) oraz urządzenia i oprogramowanie pośredniczące w komunikacji
pomiędzy różnymi typami sieci – bramy VoIP-PST/ISDN. Tego typu wyposażenie wykorzystuje kanały obsługiwane przez platformę Asterisk zgodnie z zasadami zdefiniowanymi w
specyfikacjach poszczególnych protokołów. Oprócz obsługi połączeń kanały mogą służyć
również do realizacji procedur utrzymaniowych użytkowników VoIP. Przykładem tego typu
67
procedur jest w odniesieniu do sprzętowych/programowych telefonów IP oraz bram VoIP jest
procedura rejestracji w serwerze połączona z autoryzacją użytkowników.
Połączenia mogą być zestawiane zarówno pomiędzy urządzeniami lub oprogramowaniem komunikującym się za pomocą protokołów VoIP (SIP, IAX, MGCP, H.323, Skinny),
jak również urządzeniami wyposażonymi w standardowe dla sieci PSTN/ISDN interfejsy (np.
bramy).
W trakcie uruchomienia platformy Asterisk uruchamiany jest program (Dynamic Module Loader), który steruje ładowaniem do pamięci serwera oraz inicjowaniem sterowników,
które są wykorzystywane przez serwer do:
•
obsługi strumieni sygnalizacyjnych i użytkowych generowanych w ramach kanałów (H.323, SIP, IAX2, MGCP, Skinny),
•
obsługi plików o różnych formatach (wykorzystywanych m.in. do rejestracji nagrań skrzynek głosowych i odtwarzania zapowiedzi głosowych),
•
zapewnienia obsługi kodeków audio w zakresie kodowania i dekodowania (G.711
(w wersji A-law i µ-law), G.723.1, G.726, G.729A, Speex, iLBC, GSM, LPC 10,
ADPCM) oraz video (według standardu H.261 i H.263),
•
rejestracji zdarzeń związanych z połączeniami,
•
obsługi aplikacji sterowania połączeniami.
Architektura programowa platformy składa się z czterech typów interfejsów aplikacyjnych oraz zbioru programów obsługi do realizacji funkcji centrali PBX z obsługą VoIP.
Wszystkie programy obsługi (moduły) komunikują się ze sobą oraz zewnętrznymi aplikacjami (np. sterownikami urządzeń) za pośrednictwem interfejsów aplikacyjnych API i są sterowane przez procesy nadzorujące. Programy obsługi są niezależne od: typu kanału, w ramach
którego komunikują się końcowe aplikacje, stosowanych kodeków, typu wyposażeń sprzętowych, które są stosowane obecnie w tego typu rozwiązaniach, bądź będą wykorzystywane w
przyszłości. Umożliwia to obsługę istniejących rozwiązań sprzętowych i programowych w
zakresie wykorzystywanych protokołów i kodeków, jak również uzupełnianie platformy w
przyszłości o nowe protokoły komunikacyjne oraz nowe metody kodowania i kompresji
sygnału użytkowego. Ogólny schemat funkcjonalny oprogramowania platformy zamieszczono na rysunku.
68
Rys. 33. Architektura funkcjonalna platformy Asterisk (według „The Asterisk Handbook, Version 2)
Rola poszczególnych komponentów tym schemacie jest następująca:
•
PBX Switching Core, stanowi zbiór programów do obsługi wywołań generowanych przez użytkowników danego serwera (zarejestrowanych), jak również wywołań do nich przychodzących, zgodnie z planem obsługi połączeń (Dialplan) zawartym w pliku konfiguracyjnym extensions.conf.
•
Application Launcher jest komponentem, który kontroluje uruchamianie odpowiednich aplikacji wykorzystywanych w obsłudze połączeń (np. kierowanie wywołań do określonych użytkowników, bram, skrzynek głosowych, odtwarzanie zapowiedzi głosowych, itp.),
•
Scheduler and I/O Manager jest komponentem zapewniającym sterowanie procesami obsługi połączeń w zakresie przydziału zasobów, zarządzania priorytetami i
kolejkowania.
•
Codec Translator stanowi komponent wykorzystywany do translacji strumieni
użytkowych, zakodowanych z wykorzystaniem różnych typów kodeków.
Interfejsy aplikacyjne zastosowane w platformie wykorzystywane są z kolei do komunikacji pomiędzy poszczególnymi modułami oraz procesami odpowiedzialnymi za obsługę
poszczególnych kanałów i sterowników sprzętowych. Podstawowym zadaniem czterech
interfejsów API Asterisk jest zapewnienie niezależności programów obsługi tworzących
rdzeń platformy od wykorzystywanej implementacji kanałów oraz kodeków. Zbiór interfejsów zawiera:
•
Channel API, stanowiący interfejs do obsługi kanałów skojarzonych z typem protokołu i technologii (VoIP oraz PSTN/ISDN) stosowanej przez użytkowników
serwera Asterisk. Poszczególne moduły ładowane dynamicznie do pamięci serwera odpowiedzialne są za niskopoziomową realizację połączeń, tj. wykonanie kolejnych instrukcji kodu w danym systemie operacyjnym (np. w trakcie kodowania/dekodowania wiadomości sygnalizacyjnych).
69
•
Application API – stanowiący interfejs do aplikacji, które są uruchamiane w trakcie obsługi podstawowego połączenia oraz realizacji usług dodatkowych. Przykładowy zbiór aplikacji obejmuje m.in. obsługę połączeń konferencyjnych, skrzynek
głosowych, przeszukiwania katalogu użytkowników, obsługi funkcji sterowanych
za pomocą sygnalizacji DTMF, rejestracji informacji o połączeniach w postaci rekordów zaliczeniowych, itp.
•
Codec Translator API – odpowiedzialny za dostęp do funkcji kodowania/dekodowania strumieni użytkowych przy użyciu różnych kodeków i metod
kompresji.
•
File Format API – stanowiący interfejs do funkcji zapisu/odczytu do/z plików
różnych formatów.
Wykorzystanie ww. interfejsów aplikacyjnych zapewnia rozgraniczenie funkcji serwera PBX oraz funkcji realizacji usług VoIP za pośrednictwem różnych technologii (protokoły,
kodeki, interfejsy), zarówno tych, które są wykorzystywane obecnie, jak również tych, które
będą stosowane w przyszłości. Tym samym platforma Asterisk jest otwarta pod względem
obsługi pojawiających się rozwiązań zarówno programowych jak i sprzętowych. Jest to
szczególnie istotne, biorąc pod uwagę problemy z niekompatybilnością, pojawiające się w
trakcie dołączania do sieci nowych urządzeń VoIP, daje także możliwość doboru kodeków do
właściwości łącza transmisji danych, co z kolei wpływa na jakość transmisji głosu.
8.2. Rozwiązania firmy Cisco
Kompleksowe rozwiązanie komunikacyjne, wykorzystujące technologię VoIP proponowane przez firmę Cisco oparte jest o architekturę AVVID (Architecture for Voice, Video
and Integrated Data). Centralnym jej elementem jest serwer CCM (Cisco Call Manager) –
oprogramowanie instalowane na dedykowanym serwerze MCS firmy Cisco, na platformie
Microsoft Windows oraz serwerze z systemem operacyjnym Linux (dla CCM w wersji 5.0).
Pojemność pojedynczego serwera wynosi 7500 użytkowników, jednak większa niezawodność
i skalowalność zostaje osiągnięta poprzez budowę klastra serwerów. W tym przypadku istnieje możliwość obsługi do 30000 terminali IP przez pojedynczy klaster, składający się z pięciu
serwerów. Połączenia mogą być zestawiane zarówno pomiędzy urządzeniami lub oprogramowaniem (softphone) komunikującym się za pomocą typowych protokołów VoIP: SIP,
MGCP, H.323, SCCP (rozwiązanie Cisco), jak również z urządzeniami wyposażonymi w
standardowe dla sieci PSTN/ISDN interfejsy za pośrednictwem bram. Połączenia realizowane
przez serwer VoIP są uwierzytelniane i szyfrowane z wykorzystaniem protokołu Secure RTP
i certyfikatów X.509.
Protokół SCCP (Skinny Client Control Protocol) jest protokołem dedykowanym do
współpracy z urządzeniami pochodzącymi od jednego producenta, implementowany jest w
hardware’owych i software’owych telefonach produkowanych przez firmę Cisco. Niektóre z
nich mają zaimplementowany wyłącznie tylko ten protokół, są zatem przeznaczone do współpracy tylko z urządzeniami firmy Cisco. Do kodowania głosu w telefonach IP firmy Cisco
wykorzystywane są kodeki: G.711, G.721, G.723, G.726, G.729.
Oprócz aparatów telefonicznych serwer VoIP umożliwia dołączenie i obsługę terminali wideo, w tym dedykowanych terminali firmy Tandberg, terminali H.323 oraz specjalnego
oprogramowania komunikacyjnego.
Funkcjonalność CCM może być rozszerzana przez dołączanie zewnętrznych aplikacji
– oprogramowania znajdującego się najczęściej na osobnych serwerach. W tym celu CCM
został wyposażony w szereg standardowych interfejsów programowych: TAPI, JTAPI, XML,
70
SOAP, SQL. Aplikacje, takie jak np: poczta głosowa, rozwiązania call center, rejestratory
głosu, automatyczna recepcja dostarczane przez firmę Cisco poprzez niezależne firmy software`owe lub też mogą być tworzone przez użytkownika.
Firma Cisco jest także producentem bram VoIP, takich jak AS5350, AS5400 oraz
AS5850, które są stosowane w zależności od skalowalności rozwiązania. Przykładowo brama
AS5850 w maksymalnej konfiguracji może obsługiwać 2580 jednoczesnych połączeń, co
umożliwia obsługę nawet 25800 abonentów. Moduły wchodzące w skład tej bramy realizują
funkcję hot-swap, posiadają redundantne zasilacze pracujące z podziałem obciążenia, redundantne wentylatory ,czy karty RSC (Router Switch Controller). Bramy firmy Cisco obsługują
protokoły sygnalizacyjne QSIG, SS7, ISDN. Obsługują kodeki G.711, G.723, G.726, G.729
oraz GSM-FR.
Zarządzanie całym systemem AVVID w funkcjonalnością IP-PBX jest realizowane w
sposób scentralizowany. Dostęp administracyjny do CCM wymaga jedynie przeglądarki
WWW i protokołu SSL, co umożliwia dostę do funkcji zarządzania z dowolnego miejsca w
sieci komputerowej danej firmy. Istnieje możliwość nadzoru nad oprogramowaniem sterującym urządzeń (telefony, mostki konferencyjne), co może być szczególnie istotne przy aktualizacjach – wykonywanych z serwera CCM.
8.3. Rozwiązania firmy Alcatel
Firma Alcatel dostarcza na rynek dwa rodzaje serwerów komunikacyjnych OmniPCX
Office (OXO) oraz OmniPCX Enterprise (OXE), które różnią się pod względem możliwości
funkcjonalnych, pojemności i wyposażenia. Serwery OXO są przeznaczone do obsługi ruchu
telefonicznego w małych i średnich firmach. Natomiast serwery OXE są zintegrowanymi
platformami komunikacyjnymi przeznaczonymi do obsługi dużych firm i korporacji. Realizują zadania związane ze telefonią tradycyjną, telefonią IP oraz komunikacją multimedialną.
Serwer OXO jest rozwiązaniem przeznaczonym dla niewielkich korporacji liczących
do 236 użytkowników. Jest to przykład rozwiązania VoIP w pełni modularnego typu
„wszystko w jednym”, posiadającego zintegrowany przełącznik, firewall, serwer proxy, czy
serwer cache. System ten posiada wbudowane aplikacje bezpiecznego, współdzielonego
dostępu do Internetu, serwera VoIP, serwera pocztowego, aplikacje pozwalające zarządzać
infrastrukturą i usługami sieci LAN, konsolami CTI oraz zarządzania połączeniami.
Dla systemu OXO istnieją 3 wersje platform sprzętowych, które współdzielą pojedyncze oprogramowanie. Dzięki temu istnieje możliwość dopasowania rozwiązania do potrzeb
firmy, bowiem pojemność każdego z nich może zostać rozszerzona na drodze indywidualnych uzgodnień.
Rozwiązanie OmniPCX Office firmy Alcatel to system otwarty, w którym zastosowano jako system operacyjny – system Linux. Jest on kompatybilny z różnymi aplikacjami
opracowanymi przez firmę Alcatel i innych dostawców. W tym celu wykorzystuje się standardowe interfejsy programowe TAPI. Przykładową aplikacją jest oprogramowanie firmy
Alcatel do obsługi call centers – Alcatel OmniTouch Call Center Office, oferujące szereg
spersonalizowanych, dostosowanych dla różnych klientów usług, np: możliwość automatycznego powiadamiania w trakcie oczekiwania na połączenia, rejestrację połączeń z agentem,
przejmowanie rozmów przez nadzorcę. System ten posiada również szereg funkcji związanych z zarządzaniem call center i oceną efektywności agentów – m.in. generowanie szerokiego spektrum raportów statystycznych.
Serwer OXO współpracuje z szerokim asortymentem urządzeń do telefonii IP. Są to
zintegrowane telefony IP – IP Reflex firmy Alcatel, służąca do zarządzania spersonalizowa-
71
nym routingiem połączeń i kontaktami aplikacja telefoniczna wykorzystująca pakiety oprogramowania PIMphony w wersjach Basic, Pro i Team (różniące się zakresem posiadanych
funkcji) – zainstalowane na komputerze PC oraz standardowe aplikacje klienckie H.323 i SIP,
lub też dowolne komputery PC z odpowiednim oprogramowaniem H.323/SIP.
Do zarządzania systemem służy konsola operatorska Alcatel PIMphony, instalowana
na komputerach PC. Umożliwia ona monitoring wszystkich zainstalowanych terminali, w tym
terminali dołączanych za pośrednictwem bram: analogowych i cyfrowych, DECT lub aplikacji typu softphone. Dzięki niej istnieje, miedzy innymi, możliwość aktywacji bądź zmiany
parametrów przekierowania rozmów z danego numeru telefonu, aktualizacji bazy abonentów
w każdym z oddziałów firmy, czy też blokowania lub zdejmowania blokady z telefonu.
Zdecydowanie większą skalowalność zapewniają serwery OmniPCX Enterprise firmy
Alcatel. Zapewniają one obsługę od 10 do nawet 50000 użytkowników, przy jednoczesnej
gwarancji niezawodności 99,999%. Serwer komunikacyjny OXE jest przeznaczony do
współpracy z platformą serwerową firmy IBM lub Alcatel w oparciu o system Linux lub
Unix. Obsługuje on większość protokołów i standardów komunikacyjnych, m.in. H.323, SIP,
LDAP, XML, VxML (brak jednak wsparcia dla Megaco, MGCP). Otwarte interfejsy aplikacyjne sprawiają , że platforma OXE obsługuje szereg różnych aplikacji – m.in. terminale w
postaci oprogramowania klienckiego VoIP. Oferowana platforma OXE współpracuje nie
tylko z urządzeniami Alcatel, lecz także z klientami (oprogramowanie) SIP/H.323 innych
producentów.
Wśród produktów wchodzących w skład platformy OXE firma Alcatel oferuje bramę
VoIP, która w zależności od skalowalności rozwiązania obsługuje różną ilość użytkowników.
Maksymalnie mogą one realizować do 1500 jednoczesnych połączeń, co umożliwia obsługę
nawet 5000 użytkowników. Połączenia w ramach ruchu IP, realizowane przez platformę
OXE, są szyfrowane. Dotyczy to zarówno strumieni mediów (sRTP/AES), jako również
wiadomości sygnalizacyjnych (IPSec/AES).
Brama VoIP oferowana przez firmę Alcatel obsługuje protokoły sygnalizacyjne QSIG,
ISDN oraz DPNSS. Spośród standardów kompresji wspiera natomiast najbardziej popularne,
tj.: G.711, G.723 oraz G.729.
Do zarządzania całym systemem komunikacyjnych wykorzystującym technologię VoIP stosowane jest scentralizowana platforma zarządzająca - OmniVista 4760 firmy Alcatel.
Zapewnia ona, przy zastosowaniu redundancji sprzętu ciągłość pracy na wypadek awarii.
Dane konfiguracyjne całego systemu OXE mogą być zapisywane na dwóch różnych serwerach komunikacyjnych w różnych lokalizacjach. Uaktualnienie oprogramowania nie wymaga
przerw w pracy i jest realizowane zdalnie.
Dostęp administracyjny do systemu OmniVista jest realizowany poprzez interfejs
WWW. Jest on chroniony przed atakami nie tylko za pomocą mechanizmów uwierzytelnienia
administratora. Pomiędzy serwerami komunikacyjnymi oraz pomiędzy serwerami a platformą
zarządzania stosuje się bezpieczne protokoły (SSH, SFTP, SCP). Połączenia realizowane
między klientem a serwerem platformy OmniVista są szyfrowane za pomocą tuneli IPSec.
Firma Alcatel umożliwia integrację serwerów komunikacyjnych OXE z systemem zarządzania Alcatel OmniVista i pakietem aplikacji systemu ujednoliconej komunikacji Alcatel
OmniTouch Unified Communication. Integracja ta sprawia że system zarządzania obsługuje
węzły zarówno sieci IP, jak i TDM, a także oferuje dodatkowo funkcjonalny system bilingowy. Platforma OXE umożliwia stworzenie jednego punktu administrowania zasobami i usługami. Wśród realizowanych usług można wymienić oddzwanianie, pocztę głosową, wybór
72
rozmówcy po nazwisku, osobistą sekretarkę, automatyczną dystrybucję połączeń, czy też
możliwość pracy grupy użytkowników w czasie rzeczywistym.
8.4. Rozwiązania firmy 3Com
Firma 3Com dostarcza na rynek centralę IP PBX o symbolu VCX V7000, która umożliwia korporacjom wdrożenie telefonii IP o skalowalności i niezawodności odpowiadającej
średnim i mniejszym firmom. Centrala VCX V7000 standardowo jest instalowana na serwerach firmy IBM z rodziny eServer. Istnieje jednak możliwość zainstalowania oprogramowania
centrali także na innych serwerach z systemem Linux.
Centrala umożliwia obsługę do 1500 terminali IP przez pojedynczy serwer, podczas
gdy w całej sieci liczba ta może dojść, według deklaracji producenta, nawet do 50000. Do
połączeń realizowanych pomiędzy urządzeniami lub też oprogramowaniem wykorzystywany
jest protokół SIP. Firma 3Com oferuje telefony VoIP lub też oprogramowanie instalowane w
postaci oprogramowania na komputerze, współpracujące z omawianą platformą. Istnieje także
możliwość obsługi telefonów innych firm, które wspierają standardowy protokół SIP. System
może współpracować z telefonami oraz bramami dostępu do tradycyjnych sieci publicznych
różnych producentów. System obsługuje kodeki G.711, G.729 oraz ADPCM.
Wiele czynności administracyjnych jest realizowanych poprzez interfejs WWW (brak
jednak szyfrowania). Alternatywnie można skorzystać z interfejsu X Windows lub tez interfejsu obsługiwane za pomocą linii komend CLI. W prosty sposób można realizować wiele
czynności, takich jak wprowadzanie nowych użytkowników lub importować listę z zewnętrznego źródła. Administrator może w pełni kontrolować ustawienia telefonów i nadawać użytkownikom różne uprawnienia. Dzięki temu sami użytkownicy mogą, np. zdefiniować znaczenie konfigurowalnych klawiszy dostępnych w telefonie dotyczących szybkiego wybierania,
czy też przekierowywania połączenia.
Platforma oferowana przez firmę 3Com oprócz standardowej funkcjonalności, może
dodatkowo realizować aplikacje, takie jak: poczta głosowa, system faksowy (wysyłani/odbiór), system rozpoznawania głosu czy tez system IVR (Interactive Voice Response).
8.5. Rozwiązania firmy Avaya
Firma Avaya to jeden z większych dostawców rozwiązań telefonii IP, oferujący platformy VoIP cechujące się dużą skalowalnością. Do jej flagowych rozwiązań VoIP należy
zaliczyć serwery IP PBX S8300 oraz S8700, które można dostosować do różnych wymagań,
do obsługi średnich, a także bardzo dużych firm. Oprogramowanie central instalowane jest na
dedykowanej platformie firmy Avaya, pracującej na systemie Linux.
Centrala Avaya S8300 może obsłużyć do 450 użytkowników na jeden serwer oraz
28800 dla sieci central IP PBX. Druga z wymienionych central IP-PBX może obsłużyć do
36000 użytkowników na pojedynczy serwer, a przypadku zastosowania klastra serwerów
liczba ta może wzrosnąć nawet do 1000000. Protokoły sygnalizacyjne służącego do zestawienia połączeń i strumieni głosu są domyślnie szyfrowane (AES). Połączenia te mogą być zestawiane zarówno pomiędzy urządzeniami lub oprogramowaniem komunikującym się za
pomocą protokołów H.323 jak i SIP. W przypadku telefonów VoIP centrale umożliwiają
obsługę telefonów firm innych niż Avaya, lecz wyłącznie w postaci software’owej. Zgodnie z
deklaracją firmy Avaya centrale umożliwiają współpracę z każdym urządzeniem wyposażonym w standardowe dla sieci PSTN/ISDN interfejsy.
Obydwie platformy cechują się dużą niezawodnością i dostępnością. Centrala S8700
zawiera redundantne podzespoły, do których należą między innymi procesory oraz zasilanie.
73
Funkcjonalności obydwu central są bardzo rozbudowane. Centrala S8300 posiada zintegrowaną pocztę głosową. Centrale już w wersji podstawowej potrafią obsłużyć połączenia konferencyjne pomiędzy maksymalnie 6 użytkownikami, pozwalają też na przenoszenie rozmów z
telefonów IP na telefony komórkowe, czy zaawansowaną obsługę aplikacji na potrzeby contact center.
Oferowane przez firmę Avaya centrale IP PBX współpracują z bramami medialnymi,
takimi jak G.350, G.650 czy G.700 – stosowanymi zależnie od skalowalności rozwiązania.
Bramy te obsługują protokoły sygnalizacyjne QSIG, SS7, ISDN dla sieci PSTN/ISDN oraz
standardowe protokoły VoIP (H.323, SIP, H.248) dla obsługi strumieni w sieci IP. Obsługują
kodeki: G.711, G.729, G.168, G.165 oraz G.723.
Zarządzanie systemem jest realizowane w sposób scentralizowany. Służy do tego pakiet aplikacji z oprogramowaniem Avaya Integrated Management Suite, działającym pod
kontrolą systemu Linux. Administracja systemem może być realizowana lokalnie na serwerze
bądź zdalnie z za pośrednictwem linii komend wykorzystując połączenie modemowego, sesję
Telnet/SSH lub za pośrednictwem interfejsu WWW. Firma Avaya zapewnia graficzny interfejs do konfigurowania elementów systemu, ich modyfikowania. Istnieje możliwość obsługi
kilku serwerów komunikacyjnych. Do tego służy zestaw narzędzi administracyjnych, pozwalających m.in. na określanie uprawnień użytkowników dotyczących połączeń i dostępu do
usług, generowanie statystyk dotyczących zarządzania uszkodzeniami i wydajnością, czy
zdalnej konfiguracji elementów systemu. W celu zabezpieczenia przed awarią zastosowanie
redundantnego serwera sprawi, że w przypadku awarii funkcje administracyjne przejmie
serwer zapasowy.
8.6. Rozwiązania firmy Siemens
Firma Siemens dostarcza na rynek rozwiązanie dedykowane do obsługi średnich i dużych firm – HiPath 4000. Serwery tej serii pracują na własnym systemie operacyjnym. Posiadają one otwartą architekturę i szereg interfejsów telekomuniakcyjnych, dzięki czemu mogą
współpracować z sieciami teleinformatycznymi typu wykorzystującymi technologie ISDN,
IP, ATM przy zachowaniu przezroczystości funkcji i usług. Do tej serii serwerów należą też
rozwiązania HiPath 4300 oraz HiPath 4500, które różnią się od siebie skalowalnością rozwiązania. Pierwszy z nich jest w stanie obsłużyć 2000 użytkowników, drugi 12000. Pojemność
systemu można jednak znacznie powiększyć poprzez zastosowanie klastra serwerów. Obydwa
serwery obsługują protokół H.323 lub SIP.
W ramach platformy firma Siemens oferuje zintegrowane bramy multimedialne serii
HG 35xx. Maksymalnie może ona realizować 120 jednoczesnych połączeń, co umożliwia
obsługę 240 użytkowników. Zarówno sygnalizacja, jak i strumienie głosowe są szyfrowane,
gdy są przesyłane pomiedzy bramami a klientami IP (sRTP dla strumienia RTP, AES-128 dla
sygnalizacji). Bramy obsługują protokoły sygnalizacyjne QSIG, ISDN oraz stworzony przez
firmę Siemens CorNet NQ. Obsługują kodeki G.711, G.729, G.168 oraz G.723. Współpracują
wyłącznie z telefonami firmy Siemens, istnieje jednak możliwość zastosowania software’owych telefonów innych firm (sugerowane terminale takich producentów, jak: X10,
3Com).
Serwery oferowane przez firmę Siemens są platformami otwartymi, realizującymi wiele różnych aplikacji, takich jak poczta głosowa, telefonia DECT i GSM, czy rozwiązania
VoIP. Systemy HiPath serii 4000 umożliwiają obsługę tzw. Aplikacji dla Mobilnego Biura
(HiPath Mobile Office i HiPath Xpressions – Unified Messaging), w tym np. telepracę,
wspólne korzystanie z biurek, filtrowanie komunikacji. Oprócz tego aplikacja HiPath ProCenter może realizować multimedialną obsługę klienta (funkcie contact center i CRM).
74
Zarządzanie systemem HiPath serii 4000 może być realizowane z wykorzystaniem
przeglądarki internetowej dowolnego uprawnionego terminala lub tez zdalnie przez sieć
ISDN lub analogowy modem. System zarządzania można również zintegrować na wyższych
płaszczyznach zarządzania sieci (np. HP Open View) poprzez interfejs SNMP. Firma Siemens
do każdej jednostki HiPath serii 4000 oferuje aplikację HiPath 4000 Assistant do autonomicznego administrowania systemem. Realizuje ona funkcje monitorowania i konfigurowania, takie jak przenoszenie abonenta, zmiana numerów wywołań, czy konfigurowanie łączy.
Obsługuje także diagnozę i usuwanie występujących nieprawidłowości. W razie wystąpienia
awarii istnieje możliwość odtworzenia ustawień systemu z wcześniej wykonanej kopii zapasowej. Przy skonfigurowaniu serwera z redundantnymi komponentami i połączeniu go przez
sieć z innymi centralami HiPath w przypadku awarii istnieje możliwość przełączenia awaryjnego (fail-over).
Firma Siemens, jako dodatkową opcję, dostarcza także rozbudowę systemu zarządzania o centralną platformę administracji HiPath 4000 Manager, obsługującą zaawansowane
funkcje administracyjne. Umożliwia ona kontrolę uprawnień, autoryzacji do poziomu obiektów dla różnych grup użytkowników z ochroną z użyciem haseł i logowaniem przy dostępie.
75
Bibliografia
[1] R. Schaphorst, „Videoconferencing and Videotelephony”, Artech House, London, 1999
[2] Tim Szigeti, „End-to-End QoS Network Design”, Cisco Press, 2004
[3] Stephanie L. Carhee, “The road to IP telephony: how Cisco systems migrated from PBX
to IP telephony”, Cisco Press, 2004
[4] Theodore Wallingford, “Switching to VoIP”, O'Reilly, 2005
[5] Kun I. Park, „Qos in packet Networks”, Springer, 2005
[6] ITU-T G.114 (05-2003) One-way transmission time
[7] G.1000 (11-2001) Communications Quality of Service: A framework and definitions
[8] G.1010 (11-2001) End-user multimedia QoS categories
[9] Y.1540 (12-2002) Internet protocol data communication service – IP packet transfer and
availability performance parameters
[10] RFC 3261 „Session Initiation Protocol”, 2002
[11] RFC 3263 „SIP: Locating SIP Servers”; 2002
[12] RFC 3264 „An Offer/Answer Model with the SDP”; 2002
[13] RFC 2976 „SIP Info Method”; 2000
[14] RFC 2709 MGCP,
[15] RFC 1889 RTP: A Transport Protocol for Real-Time Applications
[16] ITU-T Recommendation H.321 (1998), Adaptation of H.320 visual telephone terminals
to B-ISDN environments.
[17] ITU-T Recommendation H.322 (1996), Visual telephone systems and terminal equipment for local area networks which provide a guaranteed quality of service.
[18] VoIPSEC. Studie zur Sicherheit von Voice over Internet Protocol, Bundesamt für Sicherheit in der Informationstechnik 2005
[19] Materiały zamieszczone w witrynie http://www.asterisk.org/
[20] Materiały zamieszczone w witrynie http://developer.berlios.de/projects/ser/
[21] Materiały zamieszczone w witrynie http://www.sipfoundry.org/
76
Spis skrótów
AGC
API
ARP
ATM
BRI
CIF
CNG
DHCP
DMZ
DNS
DSL
DSS1
DTMF
EDGE
FM
FMC
FSK
FTP
FXO
FXS
GPL
IAX2
ICMP
IEEE
IM
IP
IPSec
ISDN
ISO/OSI
ITU
IVR
LAN
MGCP
MOS
MPLS
NAT
NTP
PBX
PESQ
PPPoE
PPTP
PRI
PSK
PSTN
QCIF
QoS
REN
RIPv1
RIPv2
RTP
SCCP
SDP
SIP
-
Adaptive Gain Control
Application Programming Interface
Address Resolution Protocol
Asynchronous Transfer Mode
Basic Rate Interface
Common Intermediate Format
Comfort Noise Generation
Dynamic Host Configuration Protocol
Demilitarized Zone
Domain Name System
Digital subscriber line
Digital Subscriber Signaling No 1
Dual-Tone Multi-Frequency
Enhanced Data Rates for Global Evolution
Frequence Modulation
Fixed Mobile Convergence
Frequency-Shift Keying
File Transfer protocol
Foreign Exchange Office
Foreign Exchange Stadion
General Public License
Inter - Asterisk eXchange (ver. 2)
Internet Control Message Protocol
Institute of Electrical and Electronics Engineers
Instant Messaging
Internet Protocol
IP Security Protocol
Integrated Services Digital Network
International Standards Organization/Open Systems Interconnections
International Telecommunication Union
Interactive Voice Response
Local Area Network
Media Gateway Control Protocol
Mean Opinion Score
Multiprotocol Label Switching
Network Address Translation
Network Time Protocol
Private Branch Exchange
Perceptual Evaluation of Speech Quality
Point-to-Point Protocol over Ethernet
Point to Point Tunneling Protocol
Primary Rate Interface
Pre-Shared Key
Public Switched Telephone Network
Quarter Common Intermediate Format
Quality Of Service
Ringer Equivalence Number
Routing Information Protocol ver. 1
Routing Information Protocol ver. 2
Real Time Protocol
Skinny Client Control Protocol
Session Description Protocol
Session Initiation Protocol
77
SSL
STUN
TASK
TCP
TDM
TFTP
TLS
TTL
UDP
UDP
UPnP
VAD
VMWI
VoIP
VPN
WAN
WPA
WWW
-
Secure Sockets Layer
Simple traversal of UDP over NATs
Trójmiejska Akademicka Sieć Komputerowa
Transmission Control Protocol
Time Division Multiplexing
Trivial FTP
Transport Layer Security
Time To Live
User Datagram Protocol
User Datagram Protocol
Universal plug-and-play
Voice Activity Detection
Voicemail Waiting Indication
Voice over IP
Virtual Private Network
Wide Area Network
Wi-Fi Protected Access
World Wide Web
78
Załącznik 1
Testy zgodności implementacji protokołu DSS1 dla interfejsów PRI kart Digium TExxx
W ramach podzadania wykonano testy serwera wyposażonego w kartę PRI z obsługą sygnalizacji DSS1. Ze względu na rozważaną możliwość wykorzystania serwera VoIP również w
funkcji bramy dołączanej do sieci publicznej PSTN/ISDN z wykorzystaniem łącza PRI Przeprowadzono testy zgodności implementacji protokołu DSS1 ze standardami europejskimi
(ETS 300 402 oraz ETS 300 403). Testy wykonano w oparciu o normę TBR4 (warstwa 2 i 3
modelu OSI). Schemat konfiguracji badaniowej przedstawiono na rysunku. Wyniki w postaci
tabelarycznej zawierającej werdykty dla poszczególnych przypadków testowych zamieszczono w Załączniku 1 do niniejszego raportu.
Tester
sygnalizacji
ISDN DSS1
Bramka VoIP z portami
analogowymi (FXS i FXO)
oraz aparatem analog.
Łącze
ISDN PRI
LAN (Ethernet)
Serwer VoIP
(Asterisk)
Router z funkcjonalnością
VoIP z portami analogowymi
(FXS) oraz aparatem analog.
Komputery z aplikacjami klienckimi
VoIP (software’owe telefony IP) oraz
słuchawkami wykorzystywanymi
wraz z tymi aplikacjami
Rys. 34. Ogólny schemat konfiguracji badaniowej na potrzeby testów zgodności implementacji sygnalizacji DSS1 ze standardami europejskimi (ETS 300 402 oraz ETS 300 403)
79
Wyniki testów TBR4 L2 dla implementacji protokołu DSS1 w oprogramowaniu karty Digium.
Identyfikator testu
według TBR4 L2
TC11013
TC13008
TC13010
TC13014
TC14001
TC14002
TC14019
TC14021
TC14022
TC24004
TC24020
TC25002
TC25005
TC27003
TC27004
TC27011
TC27012
TC27015
TC27019
TC27022
TC27027
TC27028
TC27031
TC27040
TC27043
TC27046
TC27058
TC27061
TC27074
TC27075
TC27076
TC27404
TC27411
TC27412
TC27413
TC27414
TC27417
TC28005
TC28012
TC28406
TC28424
Wynik
nie dotyczy
nie dotyczy
nie dotyczy
nie dotyczy
nie dotyczy
nie dotyczy
nie dotyczy
nie dotyczy
nie dotyczy
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
nie dotyczy
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
80
Uwagi
nie dotyczy
nie dotyczy
nie dotyczy
nie dotyczy
nie dotyczy
nie dotyczy
nie dotyczy
nie dotyczy
nie dotyczy
stan 4.0
stan 4.0
stan 5.0
stan 5.0
stan 7.0
stan 7.0
stan 7.0
stan 7.0
stan 7.0
stan 7.0
stan 7.0
stan 7.0
stan 7.0
stan 7.0
stan 7.0
stan 7.0
stan 7.0
stan 7.0
stan 7.0
stan 7.0
stan 7.0
stan 7.0
stan 7.4
stan 4.7
stan 7.4
stan 7.4
stan 7.4
stan 7.4
stan 8.0
stan 8.0
stan 8.4
stan 8.4
Wyniki testów TBR4 L3 dla implementacji protokołu DSS1 w oprogramowaniu karty Digium.
Identyfikator testu
według TBR4 L3
TC10002
TC10004
TC10005
TC10006
TC10008
TC10009
TC10010
TC10011
TC10015
TC10024
TC10027
TC10028
TC10029
TC20002
TC10101
TC10102
TC10103
TC10104
TC10105
TC10107
TC10120
TC10125
TC10201
TC10202
TC10203
TC10204
TC20203
TC20204
TC10301
TC10302
Wynik
TC10303
TC20301
TC10401
TC10402
TC20401
TC10701
TC10801
TC10802
TC10901
TC11003
TC11004
TC11005
TC11007
TC11008
TC11021
TC21001
TC21003
TC21006
TC11101
TC11103
TC11105
TC11107
TC11118
TC11903
TC11904
TC11906
TC11908
TC11909
TC12501
TC12503
TC19003
Uwagi
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
81
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY
POZYTYWNY

Realizacja usług Voice over IP i Video over IP w

Transkrypt

Podobne dokumenty

innovaphone IP800

Materiał informacyjny

TP-LINK TD-VG3631Bezprzewodowy router/modem

strefy dla telefonii voip

Zetafax: Fax Over IP

Domofony IP BELL

Technologia VoIP – Podstawy i standardy