Wprowadzenie do protokołów VoIP

0

W komunikacji VoIP duże znaczenie mają wymagania dotyczące wydajności, których spełnienie jest poważnym wyzwaniem w sieciach przystosowanych do przenoszenia danych. Dlatego poznanie działania protokołów VoIP to pierwszy krok w kierunku zrozumienia, jak przystosować sieć firmową do wydajnej transmisji dźwięku.

Połączenie VoIP składa się z dwóch faz:

  • Nawiązania połączenia. W tej fazie mają miejsce operacje potrzebne do nawiązania połączenia pomiędzy nawiązującym połączenie (dzwoniącym) i rozmówcą.
  • Właściwego połączenia (rozmowa). Dźwięk jest kodowany i przesyłany przez sieć.

Nawiązanie połączenia
W tej fazie połączenia wykorzystywane są protokoły obsługujące wybieranie numeru (impulsowe lub tonowe), wyszukiwanie odbiorcy rozmowy, dzwonienie, sygnał zajętości, itd. Dodatkowo, protokoły nawiązywania połączenia obsługują operacje następujące po zakończeniu rozmowy, np. zwalnianie zasobów czy dostarczanie informacji do raportów.

Protokoły nawiązywania połączenia używają protokołów transportowych TCP lub UDP do przesyłania danych. Każdy protokół używa określonych portów do komunikacji z serwerem połączeń (call server), który służy, podobnie jak PBX, do zestawiania połączeń. Pakiety konfiguracyjne są przesyłane za pośrednictwem serwera połączeń pomiędzy dzwoniącym a odbiorcą połączenia. W przypadku połączeń pomiędzy siecią IP a siecią PSTN (Public Switched Telephone Network), serwer połączeń komunikuje się z bramką VoIP, wykorzystując te same protokoły nawiązywania połączeń.

Komunikaty konfiguracyjne, których liczba i rozmiar są różne, realizują takie funkcje, jak mapowanie numerów telefonów na adresy IP, generowanie sygnałów wybierania numeru, sygnałów zajętości, itd. We wdrożeniach VoIP stosuje się wiele protokołów nawiązywania połączenia. Niektóre z nich to standardowe protokoły, a część to protokoły zamknięte, opracowane przez producentów. Obecnie nie ma jednego, dominującego protokołu. Powszechnie spotyka się wszystkie z opisanych poniżej protokołów (H.323, MGCP, SIP oraz SCCP), ale jest widoczny trend coraz częstszego wybierania protokołu SIP.

H.323

Ten protokół opiera się na standardzie przygotowanym przez International Telecommunications Union (ITU). H.323 jest powszechnie stosowany, a wśród protokołów nawiązywania połączeń ma najdłuższą historię. We wdrożeniach VoIP często jest stosowany w bramkach VoIP do nawiązywania połączeń z siecią PSTN. H.323 wymaga dodatkowej konfiguracji bramki VoIP odnośnie tego, jak połączenia mają być routowane.

H.323 to także zbiór standardów do obsługi multimediów, np. transmisji głosu czy wideokonferencji. Te powiązane ze sobą standardy są rozwijane od lat, w efekcie czego stały się bardzo rozbudowane i elastyczne. Jednak wadą tego jest duży narzut – faza nawiązywania połączenia składa się ze stosunkowo dużej liczby komunikatów i ilości danych wymienianych w celu obsługi poszczególnych funkcji. Ponieważ H.323 używa do komunikacji protokołu TCP, nawiązanie połączenia może wymagać przesłania wielu komunikatów TCP potwierdzających odbiór danych. Należy o tym pamiętać, jeśli w sieci pojawią się problemy z wydajnością utrudniające nawiązywanie połączeń.

MGCP

Media Gateway Control Protocol (MGCP) został opisany w dokumencie RFC 2705 i również jest dość powszechnie stosowany. MGCP różni się tym od większości protokołów nawiązywania połączenia, że urządzenia końcowe nie używają go do kontrolowania połączenia. Częściej MGCP jest używany przez call server do kontrolowania połączeń z sieciami PSTN.

MGCP przesyła komunikaty między bramką VoIP a serwerem połączeń na porcie UDP 2427. Ponieważ serwer połączeń kontroluję bramkę, w nim znajduje się większość „inteligencji” kontrolującej połączenia. Podobnie, konfiguracja routingu połączeń również jest przechowywana w serwerze, a nie w bramce VoIP.

SIP

SIP (Session Initiation Protocol) to protokół opracowany przez IETF i opisany w dokumencie RFC 3261. Wyróżnia się niewielkim narzutem, a jednocześnie w większości wypadków potrafi wykonać te same zadania, co bardzo rozbudowany H.323. SIP cieszy się rosnącą popularnością i w przyszłości będzie najczęściej używanym protokołem nawiązywania połączeń. Już teraz w swoich rozwiązaniach stosują go takie firmy, jak Cisco i Avaya. Dodatkowo, Microsoft zaimplementował SIP w oprogramowaniu Office Communications Server.

SIP potrafi wykorzystywać do komunikacji protokoły TCP i UDP, ale w większości przypadków stosuje się protokół TCP i port 5060. Komunikaty SIP są podobne do HTTP – są to komunikaty tekstowe i najczęściej mają strukturę żądanie-odpowiedź.

Protokoły zamknięte
Oprócz standardowych protokołów, opisanych powyżej, niektórzy producenci stosują własne protokoły. Popularnym przykładem jest Cisco Skinny Client Control Protocol (SCCP). SCCP lub Skinny to prosty protokół, ale charakteryzujący się małym narzutem. Do komunikacji wykorzystuje port TCP 2000.

Rozmowa VoIP
Faza rozmowy wymaga konwersji dźwięku z postaci analogowej do cyfrowej, następnie upakowania go w pakietach i przesłania przez sieć, a na koniec powtórnej konwersji do postaci analogowej. Do tego, żeby przesyłać głos przez sieci IP, potrzeba szereg komponentów, standardów i protokołów.

Kodeki
Kodeki służą do kodowania i dekodowania dźwięku w obu urządzeniach końcowych biorących udział w połączeniu. Poszczególne kodeki mają różne wymagania dotyczące przepustowości oraz w różny sposób wpływają na wydajność sieci.

Niektóre z powszechnie używanych kodeków to standardy opracowane przez ITU, np. G.711 oraz G.729. Zadaniem kodeków jest konwersja dźwięku na pakiety danych, które można transmitować przez sieć. Niektóre kodeki, np. G.711, nie kompresują dźwięku. Brak kompresji oznacza, że jakość dźwięku nie ulega pogorszeniu, ale ceną za to jest większa wymagana przepustowość sieci. Inne kodeki, jak G.729, kompresują dane, dzięki czemu mniej obciążają sieć. To jednak wiąże się z pewnym pogorszeniem dźwięku.

Gdy kodek przygotuje dane do wysłania, zadaniem kolejnego protokołu, RTP (Real-time Transport Protocol), jest ich przesłanie do odbiorcy.

RTP
RTP praktycznie nie ma konkurencji, jeśli chodzi o protokoły przesyłania rozmów w rozwiązaniach VoIP (w tym artykule nie omawiamy Skype’a, ale należy pamiętać, że jest to zamknięty protokół). RTP został opisany najpierw w dokumencie RFC 1889, a następnie w RFC 3550 (ma status Internet Standard). Powszechnie używany do strumieniowania dźwięku i wideo, RTP został zaprojektowany z myślą o aplikacjach wymagających przesyłania danych w czasie rzeczywistym w jedną stronę i nie wymagających potwierdzeń odbioru.

Ponieważ rozmowy VoIP są dwukierunkowe, podczas połączenia przesyłane są dwa strumienie RTP, po jednym w każdym kierunku. Trasa, którą pokonują strumienie RTP przez sieć oraz występujące po drodze utrudnienia (np. opóźnienia), mają wpływ na jakość przesyłanego dźwięku.

RTP jest protokołem warstwy aplikacji i wykorzystuje protokół transportowy UDP. Wszystkie pola dotyczące RTP są zawarte w polu danych datagramu UDP. Podobnie, jak UDP, RTP jest protokołem bezpołączeniowym. Aplikacja, która tworzy datagramy RTP, najczęściej nie jest częścią stosu TCP/IP, więc stosuje się dodatkowe oprogramowanie, które dodaje i rozpoznaje dodatkowy, dwunastobajtowy nagłówek w każdym datagramie UDP. Nadawca wypełnia nagłówek RTP, który zawiera cztery ważne pola:

  • RTP Payload Type – informuje odbiorcę, który kodek został użyty do zakodowania dźwięku, co pozwala użyć właściwego kodek do odkodowania.
  • Sequence Number – umożliwia odbiorcy wykrycie datagramów: utraconych, odebranych poza kolejnością lub zduplikowanych.
  • Time Stamp – umożliwia zgodne z oryginałem odtworzenie rozmowy w czasie. Parametr wykorzystywany także do wykrywania zmieniających się opóźnień w odbieraniu pakietów (tzw. jitter). Znacznik czasu to największa wartość protokołu RTP. Nadawca umieszcza znacznik czasu w każdym datagramie RTP. Ich odbiorca oblicza różnicę między czasem nadejścia datagramu a czasem wysłania. Idealną sytuacją jest, gdy w przypadku kolejnych datagramów ta różnica nie zmienia się. W przeciwnym razie występuje tzw. jitter, zjawisko negatywnie wpływające na jakość odtwarzanego dźwięku. Jeśli odbiorca otrzymuje znacznik czasu, może zniwelować efekt tego zjawiska.
  • Source ID – każdy nadawca generuje unikalnych identyfikator i umieszcza go w nagłówku RTP. Ten identyfikator pomaga aplikacji odbiorcy w sytuacji, gdy odbiera on kilka strumieni.

RTP a przepustowość
Nagłówek RTP jest ważny z punktu widzenia wymagań transmisji w czasie rzeczywistym, ale nagromadzenie nagłówków prowadzi do powstania dużego narzutu, szczególnie w odniesieniu do rozmiarów danych przygotowanych przez kodeki VoIP. Przykładowo, jeśli używa się kodeka G.729, pole danych zawiera z reguły 20 bajtów, co oznacza, że kodek generuje 20-bajtowe paczki dźwięku z określoną częstotliwości, z reguły co 20 milisekund. Używając RTP, dwie trzecie datagramu stanowi nagłówek, ponieważ cały nagłówek składa się z: RTP (12 bajtów), UDP (8 bajtów), IP (20 bajtów), co daje w sumie 40 bajtów.

Faktyczne wykorzystanie przepustowości przez VoIP jest większe, niż to się początkowo wydaje. Przykładowo, kodek G.729 generuje 8 Kbit/s danych, ale wykorzystanie łącza jest większe. Wysyłając co 20 milisekund datagramy zawierające 20 bajtów danych, trzeba wraz z nimi wysłać 40 bajtów nagłówka RTP i nagłówki dwóch dodatkowych warstw. Przykładowo, nagłówek protokołu Ethernet ma z reguły 18 bajtów. Tabela pierwsza pokazuje, jaka jest faktyczna wymagana przepustowość dla różnych kodeków w sieciach Ethernet.

Tabela 1 Realnie wymagana przepustowość w sieciach Ethernet

Kodek Szybkość kodeka (próbkowanie) Typowa częstotliwość wysyłania pakietów z dźwiękiem Wymagana przepustowość
G.711u 64.0 Kbit/s 20 ms 87.2 Kbit/s
G.711a 64.0 Kbit/s 20 ms 87.2 Kbit/s
G.726-32 32.0 Kbit/s 20 ms 55.2 Kbit/s
G.729 8.0 Kbit/s 20 ms 31.2 Kbit/s
G.723.1 MPMLQ 6.3 Kbit/s 30 ms 21.9 Kbit/s
G.723.1 ACELP 5.3 Kbit/s 30 ms 20.8 Kbit/s

Niektóre telefony umożliwiają ustawienie opóźnienia między pakietami lub wielkości pakietów z dźwiękiem, co przekłada się na częstotliwość wysyłania pakietów przez nadawcę. Przykładowo, ustawienie próbkowania 64 Kbit/s oznacza, że wysyłane co 20 milisekund datagramy będą zawierały 160 bajtów danych.

Proste równanie pozwala obliczyć szybkość kodeka (próbkowanie), częstotliwość wysyłania oraz rozmiar pola danych datagramu:

rozmiar pola danych (w bajtach) = szybkość kodeka (w bitach na sekundę) * częstotliwość wysyłania pakietów (w sekundach)

W naszym przykładzie jest to 160 bajtów= (64000 b/s * 0,02 s)/8

Przy określonej szybkości kodeka zmniejszenie częstotliwości wysyłania pakietów również spowoduje zwiększenie rozmiaru datagramów, ponieważ będą one rzadziej wysyłane. Dlaczego więc wszystkie kodeki nie generują większych pakietów z dźwiękiem i nie wysyłają ich z mniejszą częstotliwością, żeby zmniejszyć narzut spowodowany nagłówkiem? Jest to uzasadnione dłuższymi opóźnieniami, jakie powstają przy przesyłaniu większych pakietów, co odbija się negatywnie na jakości dźwięku. Poza tym, w przypadku utracenia dużego datagramu również mogą wystąpić słyszalne zakłócenia.

PODZIEL SIĘ

BRAK KOMENTARZY

ZOSTAW ODPOWIEDŹ