Protokoły RTP i RTCP w VoIP
RTP jest głównym protokołem transportowym w sieciach telefonii IP. RTP ( Czas rzeczywisty Protocol) to protokół czasu rzeczywistego, który został stworzony w celu przesyłania multimediów (audio, wideo), zakodowanych i spakowanych informacji przez sieci IP w ściśle określonych ramach czasowych. Segmenty RTP są transmitowane Protokół UDP i IP, odpowiednio, na różnych poziomach modelu OSI. Użycie protokołu UDP, który nie gwarantuje dostawy, wynika ze ścisłego harmonogramu transmisji multimediów w czasie rzeczywistym, a także braku możliwości działania protokołu TCP w czasie rzeczywistym. Dlatego pomimo utraty części danych, w tym przypadku ważniejsza jest terminowa dostawa.
W widok ogólny Rozkład protokołu na warstwy modelu OSI jest następujący:
Warstwa transportowa: RTP przez UDP
Sieć: IP
Kanał: Ethernet
Fizyczny: Ethernet
Podczas przesyłania informacji multimedialnych za pomocą protokołu RTP stosowana jest następująca enkapsulacja:
Minimalny rozmiar segmentu RTP to 12 bajtów. Pierwsze dwa bity określają wersję protokołu. Obecnie używany jest protokół RTPv.2. Następne pole P również ma długość 2 bitów i wskazuje obecność znaków dopełniających w polu danych w przypadku stosowania segmentów o tej samej długości. Pole X określa, czy używany jest rozszerzony nagłówek. 4-bitowe pole CC określa wówczas liczbę pól CSRC na końcu nagłówka RTP, czyli liczbę źródeł tworzących strumień. Następnie pojawia się pole M, bit znacznika używany do podświetlania ważnych danych. Następne pole PT ma rozmiar 7 bitów. Zaprojektowany do określenia rodzaju ładunku - danych wymaganych dla aplikacji. Aplikacja na podstawie podanego kodu określa rodzaj informacji multimedialnej oraz sposób dekodowania.
Pozostała część nagłówka składa się z pola SequenceNumber – numeru sekwencyjnego segmentu, który śledzi kolejność pakietów i ich utratę; Pola znacznika czasu - kod synchronizacji wskazujący czas pierwszej zakodowanej próbki w ładunku. Znacznik ten jest wykorzystywany przez bufory odzyskiwania synchronizacji w celu wyeliminowania strat jakościowych spowodowanych zmianami opóźnienia; pola źródłowe synchronizacji SSRC - dowolna liczba odróżniająca jedną sesję RTP od drugiej, w celu stworzenia możliwości multipleksowania. Po stałej, stałej części nagłówka RTP można dodać do 15 trzydziestodwubitowych pól CSRC identyfikujących źródła danych.
Opiszmy procedurę ustanawiania sesji RTP. Protokół ustala ten ruch różne typy przekazywane w oddzielnych sesjach komunikacyjnych. Aby nawiązać sesję konieczne jest określenie pary docelowych adresów transportowych tj. jeden adres sieciowy oraz dwa porty dla RTP i RTCP. Zatem w przypadku wideokonferencji konieczne jest przesyłanie dźwięku i obrazu w różnych sesjach z odpowiednio różnymi portami docelowymi. Transportowanie różnych typów ruchu przy użyciu przeplatania w tej samej sesji może powodować następujące problemy:
- przy zmianie jednego z typów ruchu nie można określić, który parametr w sesji należy zastąpić nową wartością;
- do nawiązania sesji używany jest tylko jeden interwał czasowy, a podczas przesyłania ruchu heterogenicznego każdy typ będzie miał swój własny interwał i będą się one różnić;
- mikser RTP nie może łączyć przeplatanych strumieni różnych typów ruchu w jeden strumień;
- transmisja kilku rodzajów ruchu w jednej sesji RTP jest niemożliwa z następujących powodów: wykorzystanie różnych ścieżek sieciowych lub dystrybucja zasoby sieciowe; odbieranie w razie potrzeby podzbioru danych multimedialnych, na przykład tylko dźwięku, jeśli sygnał wideo przekracza dostępną szerokość pasma; implementacje słuchaczy, które wykorzystują oddzielne procesy dla różnych typów ruchu, natomiast zastosowanie oddzielnych sesji RTP pozwala na implementacje zarówno jedno-, jak i wieloprocesowe.
Jednak protokoły RTP (protokół transportu w czasie rzeczywistym) i UDP (protokół datagramów użytkownika) nie gwarantują jakości, to znaczy nie współpracują z QoS (jakością usług). Dlatego protokół RTP jest obsługiwany przez protokół kontroli transportu w czasie rzeczywistym (RTCP), który dostarcza dodatkowych informacji o stanie sesji komunikacyjnej RTP.
Protokół RTCP spełnia cztery główne funkcje:
I. Głównym zadaniem protokołu RTCP jest przekazywanie informacji zwrotnej gwarantującej jakość transmisji danych. Sprzężenie zwrotne może być bezpośrednio przydatne w przypadku zastosowania do transmisji z kodowaniem adaptacyjnym. Ponadto w przypadku korzystania z multiemisji IP niezwykle ważne jest, aby odbiorcy diagnozowali błędy podczas przesyłania wiadomości (pakietów). Wysyłanie komunikatów wraz z raportami odbioru pozwala stronie wysyłającej ustalić przyczynę nieudanej transmisji komunikatów, jeśli taka nastąpi.
II. Protokół RTCP zawiera niezmienny identyfikator warstwy transportowej dla źródła RTP, nazywany „nazwą kanoniczną” lub „Cname”. Ponieważ identyfikator SSRC może ulec zmianie w przypadku wykrycia kolizji, odbiorca potrzebuje wartości Cname, aby śledzić każdego uczestnika. Odbiorcy używają Cname również do mapowania wielu strumieni danych od jednego uczestnika podczas ustanawiania wielu sesji jednocześnie, na przykład w celu synchronizacji kanałów audio i wideo podczas transmisji wideo z dźwiękiem.
III. Powyższe dwie funkcje zakładają, że wszyscy uczestnicy sesji wysłali pakiety RTCP, dlatego należy kontrolować szybkość transmisji, aby RTP mógł nawiązać sesje z dużą liczbą użytkowników. Kiedy każdy uczestnik przesyła swoje pakiety kontrolne do wszystkich pozostałych, każdy partner może niezależnie określić całkowitą liczbę uczestników sesji. Jest to konieczne do obliczeń szybkości transmisji komunikatów RTCP.
IV. Ta funkcja służy do przekazania minimalnej niezbędnej informacji kontrolnej, takiej jak identyfikator uczestnika, która jest wykorzystywana interfejs graficzny użytkownik. Ta funkcja jest używana w przypadku luźno kontrolowanych sesji, w których użytkownicy logują się i wylogowują bez odpowiednich negocjacji parametrów i cech. RTCP służy jako wygodny kanał kontaktu ze wszystkimi uczestnikami, ale niekoniecznie spełnia wszystkie wymagania komunikacyjne aplikacji.
W sieciach IP korzystających z multiemisji funkcje pierwsza, druga i trzecia są obowiązkowe w przypadku korzystania z sesji RTP. Zaleca się ich stosowanie także przy transmisji w innych sieciach i środowiskach. Obecnie zaleca się, aby twórcy aplikacji RTP korzystali z narzędzi, które pozwalają im pracować w trybie multicast, a nie tylko w trybie unicast.
Rozważmy format pakietów RTCP.
Standard protokołu definiuje kilka typów pakietów RTCP. RTCP przeznaczony jest do przesyłania informacji serwisowych:
sr: Raport nadawcy. Niezbędne do statystyk odbiorów i transmisji uczestników sesji będących bezpośrednio aktywnymi nadawcami;
rr: Raport odbiorcy. Wymagane w przypadku statystyk od uczestników, którzy nie są odbiorcami;
sdes: opisuje źródło, zawiera nazwę Cname;
bye: Służy do wskazania końca (wyjścia) sesji;
aplikacja: funkcje specyficzne dla aplikacji;
Każdy pakiet RTCP składa się ze stałej części, jak w przypadku protokołu RTP, który jest używany przez pakiety RTP, po której następują pola, których długość może różnić się w zależności od typu pakietu, ale są wielokrotnością 32 bitów. Aby umożliwić łączenie pakietów RTCP, wprowadzono wymagania dotyczące wyrównania i pole długości w stałej części nagłówka. Wiele pakietów RTCP można łączyć ze sobą bez wprowadzania jakichkolwiek separatorów w celu utworzenia złożonego pakietu RTCP, który jest wysyłany za pośrednictwem protokołu transportowego niskiego poziomu, takiego jak UDP. Nie ma specjalnego licznika dla poszczególnych pakietów RTCP, ponieważ protokół niskiego poziomu określi całkowitą długość i określi koniec pakietu złożonego. 
Format pakietu wiadomości nadawcy RTCP jest następujący, jak pokazano na powyższym rysunku.
Pakiety RTCP podlegają następującym kontrolom poprawności.
- Pole wersji RTP musi być równe 2.
- Pole typu danych pierwszego pakietu RTCP w pakiecie złożonym musi mieć wartość SR lub RR.
- Bit dopełnienia (P) musi wynosić zero dla pierwszego pakietu złożonego pakietu RTCP, ponieważ dopełnienie może występować tylko w ostatnim pakiecie.
- Długość pól poszczególnych pakietów RTCP musi sumować się do całkowitej długości pakietu złożonego.
Jednym z najważniejszych trendów ewolucji współczesnej telekomunikacji jest rozwój telefonii IP – szeregu nowych technologii zapewniających transmisję komunikatów multimedialnych (mowy, danych, wideo) poprzez sieci informacyjno-komputerowe (ICN), zbudowane na bazie podstawie protokołu IP (Internet Protocol), w tym lokalnego, korporacyjnego, globalnego sieci komputerowe i Internet. W pojęciu telefonii IP mieści się telefonia internetowa, która umożliwia organizowanie komunikacji telefonicznej pomiędzy abonentami Sieci internetowe, pomiędzy abonentami sieci telefoniczne sieci publicznej (PSTN) za pośrednictwem Internetu, a także komunikację telefoniczną pomiędzy PSTN a abonentami Internetu.
Telefonia IP posiada szereg niewątpliwych zalet, które zapewniają jej szybki rozwój i poszerzenie rynku telefonii komputerowej. Jest to korzystne dla użytkowników końcowych, którzy mogą korzystać z usług telefonicznych po stosunkowo niskiej stawce za minutę. W przypadku firm posiadających odległe oddziały technologia IP umożliwia organizowanie komunikacji głosowej z wykorzystaniem istniejących korporacyjnych sieci IP. Zamiast kilku sieci komunikacyjnych używana jest jedna. Niewątpliwą przewagą telefonii IP nad zwykłym telefonem jest także możliwość świadczenia dodatkowe usługi poprzez wykorzystanie komputera multimedialnego i różnorodnych aplikacji internetowych. Dzięki telefonii IP firmy i osoby prywatne mogą rozszerzyć swoje możliwości komunikacyjne o zaawansowane wideokonferencje, udostępnianie aplikacji, narzędzia typu tablica i tym podobne.
Jakie międzynarodowe standardy i protokoły regulują podstawowe parametry i algorytmy funkcjonowania sprzętu i oprogramowanie komunikacja stosowana w telefonii IP? Oczywiście, jak sama nazwa wskazuje, technologia ta opiera się na protokole IP, który jednak służy nie tylko w telefonii: pierwotnie został opracowany do przesyłania danych cyfrowych do systemów informatycznych z komutacją pakietów.
W sieciach nie zapewniających gwarantowanej jakości usług (dotyczy to także sieci zbudowanych w oparciu o protokół IP) pakiety mogą zostać utracone, może zmienić się kolejność ich nadejścia, a dane przesyłane w pakietach mogą zostać zniekształcone. Aby zapewnić niezawodne dostarczanie przesyłanych informacji w tych warunkach, stosowane są różne procedury warstwy transportowej. Przy transmisji danych cyfrowych wykorzystywany jest w tym celu protokół TCP (Transmission Control Protocol). Protokół ten zapewnia niezawodne dostarczanie danych i przywraca pierwotną kolejność pakietów. Jeśli w pakiecie zostanie wykryty błąd lub pakiet zostanie utracony, procedury TCP wysyłają żądanie retransmisji.
W zastosowaniach do konferencji audio i wideo opóźnienia pakietów mają znacznie większy wpływ na jakość sygnału niż pojedyncze uszkodzenia danych. Różnice w opóźnieniach mogą skutkować przerwami. Takie aplikacje wymagają innego protokołu warstwy transportowej, który zapewnia przywrócenie oryginalnej sekwencji pakietów, ich dostarczenie z minimalnym opóźnieniem, odtwarzanie w czasie rzeczywistym w dokładnie określonych momentach, rozpoznawanie rodzaju ruchu, komunikację grupową lub dwukierunkową. Protokół ten jest protokołem transportowym czasu rzeczywistego RTP (ang. Real-Time Transport Protocol). Protokół ten reguluje przesył danych multimedialnych w pakietach poprzez IVS na poziomie transportu i jest uzupełniony protokołem kontroli przesyłu danych w czasie rzeczywistym RTCP (Real-Time Control Protocol). Protokół RTCP z kolei zapewnia kontrolę dostarczania mediów, kontrolę jakości usług, komunikację z uczestnikami bieżącej sesji komunikacyjnej, zarządzanie i identyfikację i czasami jest uważany za część protokołu RTP.
Wiele publikacji na temat telefonii IP zwraca na to uwagę sprzęt sieciowy i specjalne oprogramowanie dla tej technologii jest rozwijany w oparciu o Zalecenie Sektora Normalizacji Telekomunikacyjnej Międzynarodowego Związku Telekomunikacyjnego (ITU-T) H.323 (w tym TAPI 3.0, NetMeeting 2.0 itp.). Jak H.323 ma się do protokołów RTP i RTCP? H.323 to szerokie ramy koncepcyjne obejmujące wiele innych standardów, z których każdy obejmuje inne aspekty przesyłania informacji. Większość tych standardów, takich jak standardy kodeków audio i wideo, ma szerokie zastosowanie
Protokół RTP działa poprzez przypisywanie znaczników czasu do każdego pakietu wychodzącego. Po stronie odbiorczej znaczniki czasu pakietów wskazują, w jakiej kolejności i z jakimi opóźnieniami mają być odtwarzane. Obsługa protokołów RTP i RTCP umożliwia hostowi odbierającemu uporządkowanie odebranych pakietów we właściwej kolejności, zmniejszenie wpływu zmian opóźnień sieci na jakość sygnału oraz przywrócenie synchronizacji między dźwiękiem i obrazem, dzięki czemu przychodzące informacje mogą być prawidłowo słyszane i oglądane przez użytkowników.
Należy zauważyć, że sama spółka RTP nie posiada żadnego mechanizmu gwarantującego terminową transmisję danych i jakość usług, lecz korzysta w tym celu z usług podstawowych. Nie zapobiega to pakietom spoza kolejności, ale nie zakłada, że sieć bazowa jest całkowicie niezawodna i przesyła pakiety we właściwej kolejności. Numery sekwencyjne zawarte w protokole RTP pozwalają odbiorcy zrekonstruować sekwencję pakietów nadawcy.
Protokół RTP obsługuje zarówno komunikację dwukierunkową, jak i przesyłanie danych do grupy odbiorców, jeśli sieć bazowa obsługuje transmisję multiemisji. RTP ma na celu dostarczanie wymaganych informacji indywidualne aplikacje i w większości przypadków jest zintegrowany z aplikacją.
Chociaż RTP jest uważany za protokół warstwy transportowej, zazwyczaj działa na bazie innego protokołu warstwy transportowej, UDP (protokołu datagramów użytkownika). Obydwa protokoły wnoszą swój udział w funkcjonalności warstwy transportowej. Należy zauważyć, że protokoły RTP i RTCP są niezależne od podstawowych warstw transportowych i sieciowych, zatem protokoły RTP/RTCP można stosować z innymi odpowiednimi protokołami transportowymi.
Jednostki danych protokołu RTP/RTCP nazywane są pakietami. Pakiety generowane zgodnie z protokołem RTP i służące do przesyłania danych multimedialnych nazywane są pakietami informacyjnymi lub pakietami danych, a pakiety generowane zgodnie z protokołem RTCP i wykorzystywane do przesyłania informacji usługowych niezbędnych do niezawodnego działania telekonferencji nazywane są pakietami kontrolnymi lub pakietami kontrolnymi. Pakiet RTP zawiera stały nagłówek, opcjonalne rozszerzenie nagłówka o zmiennej długości i pole danych. Pakiet RTCP zaczyna się od stałej części (podobnej do stałej części pakietów informacyjnych RTP), po której następują elementy strukturalne o zmiennej długości.
Aby protokół RTP był bardziej elastyczny i mógł być używany do różnych zastosowań, niektóre jego parametry są celowo niezdefiniowane, ale zapewnia koncepcję profilu. Profil to zestaw parametrów protokołów RTP i RTCP dla określonej klasy aplikacji, który określa cechy ich funkcjonowania. Profil definiuje wykorzystanie poszczególnych pól nagłówka pakietu, typy ruchu, dodatki i rozszerzenia nagłówka, typy pakietów, usługi i algorytmy bezpieczeństwa komunikacji, cechy wykorzystania podstawowego protokołu itp. (jako przykład sekcja 11 uwzględnia zaproponowane w profilu RTP RFC 1890 do konferencji audio i wideo przy minimalnej kontroli). Każda aplikacja zazwyczaj współpracuje tylko z jednym profilem, a typ profilu ustala się poprzez wybranie odpowiedniej aplikacji. Brak wyraźnego wskazania typu profilu poprzez numer portu, identyfikator protokołu itp. nie podano.
Zatem pełna specyfikacja RTP dla konkretnej aplikacji musi zawierać dodatkowe dokumenty, do których zalicza się opis profilu, a także opis formatu ruchu, który określa, w jaki sposób dany rodzaj ruchu, np. audio czy wideo, będzie przetwarzany w RTP.
Funkcje przesyłania danych multimedialnych podczas konferencji audio i wideo zostały omówione w kolejnych rozdziałach.
Grupowe konferencje audio wymagają adresu grupowego dla wielu użytkowników i dwóch portów. W tym przypadku jeden port jest wymagany do wymiany danych audio, a drugi służy do obsługi pakietów sterujących protokołem RTCP. Informacje o adresie grupy i porcie są wysyłane do docelowych uczestników telekonferencji. Jeśli wymagana jest prywatność, pakiety informacyjne i kontrolne mogą być szyfrowane zgodnie z definicją w sekcji 7.1, w którym to przypadku należy również wygenerować i rozpowszechnić klucz szyfrujący.
Aplikacja do konferencji audio używana przez każdego uczestnika konferencji wysyła dane audio w małych porcjach, np. 20 ms. Każdy fragment danych audio jest poprzedzony nagłówkiem RTP; Nagłówek i dane RTP są naprzemiennie formowane (hermetyzowane) w pakiet UDP. Nagłówek RTP wskazuje, jaki typ kodowania audio (np. PCM, ADPCM lub LPC) został użyty do wygenerowania danych w pakiecie. Dzięki temu możliwa jest zmiana rodzaju kodowania w trakcie konferencji, np. w przypadku pojawienia się nowego uczestnika korzystającego z łącza o małej przepustowości lub w przypadku przeciążenia sieci.
W Internecie, podobnie jak w innych sieciach transmisji danych z komutacją pakietów, pakiety są czasami tracone, zmieniana ich kolejność oraz opóźnienia o różny czas. Aby przeciwdziałać tym zdarzeniom, nagłówek RTP zawiera znacznik czasu i numer sekwencyjny, który umożliwia odbiorcom zresetowanie taktowania, tak aby na przykład fragmenty sygnału audio były odtwarzane w sposób ciągły przez głośnik co 20 ms. Ta rekonstrukcja taktowania jest wykonywana oddzielnie i niezależnie dla każdego źródła pakietów RTP w grupie dyskusyjnej. Odbiorca może również wykorzystać numer kolejny do oszacowania liczby utraconych pakietów.
Ponieważ uczestnicy telekonferencji mogą dołączać do konferencji i ją opuszczać w trakcie jej trwania, warto wiedzieć, kto uczestniczy w konferencji. w tej chwili i jak dobrze uczestnicy konferencji odbierają dane audio. W tym celu każda instancja aplikacji audio podczas konferencji cyklicznie wysyła komunikaty na porcie kontrolnym (port RTCP) dla aplikacji wszystkich pozostałych uczestników o odebraniu pakietów wskazujących nazwę jej użytkownika. Wiadomość odebrana wskazuje, jak dobrze słychać bieżącego mówcę i może być używana do sterowania enkoderami adaptacyjnymi. Oprócz nazwy użytkownika mogą być również zawarte inne informacje identyfikacyjne służące do kontroli przepustowości. Opuszczając konferencję, witryna wysyła pakiet RTCP BYE.
Jeżeli w telekonferencji wykorzystywane są zarówno sygnały audio, jak i wideo, są one przesyłane oddzielnie. Aby przesyłać każdy rodzaj ruchu niezależnie od drugiego, specyfikacja protokołu wprowadza koncepcję sesji komunikacyjnej RTP (zobacz listę używanych skrótów i terminów). Sesja jest definiowana przez określoną parę docelowych adresów transportowych (jeden adres sieciowy plus para portów dla protokołów RTP i RTCP). Pakiety dla każdego typu ruchu są wysyłane przy użyciu dwóch różnych par portów UDP i/lub adresów multiemisji. Nie ma bezpośredniego połączenia RTP pomiędzy sesjami audio i wideo, z tą różnicą, że użytkownik uczestniczący w obu sesjach musi używać tej samej nazwy kanonicznej w pakietach RTCP dla obu sesji, aby sesje mogły zostać połączone.
Jednym z powodów takiego rozdzielenia jest to, że niektórzy uczestnicy konferencji muszą mieć możliwość odbierania tylko jednego rodzaju ruchu, jeśli sobie tego życzą.
Nie wszystkie witryny zawsze mogą odbierać dane multimedialne w tym samym formacie. Rozważmy przypadek, w którym uczestnicy z jednej lokalizacji są połączeni za pomocą łącza o niskiej prędkości z większością innych uczestników konferencji, którzy mają szerokopasmowy dostęp do sieci. Zamiast zmuszać wszystkich do korzystania z niższej przepustowości i kodowania dźwięku o niższej jakości, narzędzie komunikacyjne warstwy RTP, zwane mikserem, można umieścić w obszarze o niskiej przepustowości. Ten mikser resynchronizuje przychodzące pakiety audio, aby przywrócić oryginalne 20-ms interwały, miksuje zrekonstruowane strumienie audio w jeden strumień i koduje sygnał dźwiękowy dla wąskiego pasma i przesyła strumień pakietów linią komunikacyjną o niskiej prędkości. W takim przypadku pakiety mogą być adresowane do jednego odbiorcy lub grupy odbiorców o różnych adresach. Aby umożliwić odbierającym punktom końcowym prawidłowe wskazanie źródła komunikatów, nagłówek RTP zawiera środki umożliwiające mikserom identyfikację źródeł, które przyczyniły się do powstania zmieszanego pakietu.
Niektórzy uczestnicy konferencji audio mogą być połączeni łączami szerokopasmowymi, ale mogą nie być dostępni za pośrednictwem konferencji grupowych IP multicast (IPM). Na przykład mogą znajdować się za zaporą sieciową warstwy aplikacji, która nie pozwala na przesyłanie żadnych pakietów IP. W takich przypadkach nie potrzebujesz mikserów, ale inny rodzaj sprzętu komunikacyjnego na poziomie RTP, zwany tłumaczami. Z dwóch przekaźników jeden jest zainstalowany poza zaporą ogniową i zewnętrznie przekazuje wszystkie pakiety multiemisji odebrane przez bezpieczne połączenie do drugiego przekaźnika zainstalowanego za zaporą. Przekaźnik za zaporą ogniową przesyła je ponownie jako pakiety multiemisji do grupy wielu użytkowników ograniczonej do wewnętrznej sieci witryny.
Miksery i tłumacze mogą być zaprojektowane do wielu celów. Przykład: Mikser wideo, który skaluje obrazy wideo poszczególnych osób w niezależnych strumieniach wideo i łączy je w pojedynczy strumień wideo, symulując scenę grupową. Przykłady translacji: połączenie grupy hostów obsługujących wyłącznie protokół IP/UDP z grupą hostów obsługujących wyłącznie ST-II lub transkodowanie pakietu wideo pakiet po pakiecie z poszczególnych źródeł bez ponownej synchronizacji i miksowania. Szczegóły działania mikserów i tłumaczy zostały omówione w rozdziale 5.
Wszystkie pola pakietów RTP/RTCP przesyłane są w sieci w bajtach (oktetach); najbardziej znaczący bajt jest przesyłany jako pierwszy. Wszystkie dane pola nagłówka są wyrównane zgodnie z ich długością . Oktety oznaczone jako opcjonalne mają wartość zero.
Czas bezwzględny (czas zegara ściennego) w protokole RTP jest reprezentowany przy użyciu formatu sygnatury czasowej protokołu Network Time Protocol (NTP), który jest odniesieniem do czasu w sekundach w odniesieniu do godzin zerowych w dniu 1 stycznia 1900 r. Pełny format znacznika czasu NTP to 64-bitowa liczba stałoprzecinkowa bez znaku, z częścią całkowitą w pierwszych 32 bitach i częścią ułamkową w ostatnich 32 bitach. Niektóre pola o bardziej zwartej reprezentacji wykorzystują tylko 32 środkowe bity – 16 dolnych bitów części całkowitej i najbardziej znaczące 16 bitów części ułamkowej.
Kolejne dwie sekcje tego artykułu (3 i 4) omawiają odpowiednio formaty pakietów i funkcje operacyjne protokołów RTP i RTCP.
Jak zauważono powyżej, pakiet RTP zawiera stały nagłówek, opcjonalne rozszerzenie nagłówka o zmiennej długości i pole danych. Stały nagłówek pakietów protokołu RTP ma następujący format: .
Pierwsze dwanaście oktetów znajduje się w każdym pakiecie RTP, natomiast pole CSRC (źródło pomocnicze) występuje tylko po wstawieniu przez mikser. Pola mają następujące cele.
Wersja (V): 2 bity. To pole identyfikuje wersję RTP. W artykule omówiono wersję 2 protokołu RTP (wartość 1 została wykorzystana w pierwszej wersji protokołu RTP).
Wypełnienie (P): 1 bit. Jeśli bit dopełniający jest ustawiony na jeden, pakiet na końcu zawiera jeden lub więcej oktetów dopełniających, które nie są częścią ruchu. Ostatni oktet dopełnienia zawiera informację o liczbie takich oktetów, które należy następnie zignorować. Dopełnianie może być wymagane w przypadku niektórych algorytmów szyfrowania o stałych rozmiarach bloków lub w celu przenoszenia wielu pakietów RTP w jednym bloku danych protokołu bazowego.
Rozszerzenie (X): 1 bit. Jeśli ustawiony jest bit rozszerzenia, po stałym nagłówku następuje rozszerzenie nagłówka w formacie zdefiniowanym w .
Licznik CSRC (CC): 4 bity. Licznik CSRC zawiera liczbę zawartych identyfikatorów źródła CSRC (zobacz listę używanych skrótów i terminów), które występują po stałym nagłówku.
Znacznik (M): 1 bit. Interpretacja znacznika zależy od profilu. Jego zadaniem jest umożliwienie oznaczania znaczących zdarzeń (takich jak granice klatek wideo) w strumieniu pakietu. Profil może wprowadzić dodatkowe bity znacznika lub określić, że nie ma bitu znacznika, zmieniając liczbę bitów w polu typu ruchu (patrz ).
Typ ruchu (PT): 7 bitów. To pole identyfikuje format ruchu RTP i określa, w jaki sposób aplikacja go interpretuje. Profil definiuje domyślne mapowanie statyczne pomiędzy wartościami PT i formatami ruchu. Dodatkowe kody typu ruchu można definiować dynamicznie za pomocą środków innych niż RTP. Nadawca pakietu RTP generuje w dowolnym momencie pojedynczą wartość typu ruchu RTP; To pole nie jest przeznaczone do multipleksowania pojedynczych strumieni multimediów (patrz ).
Numer kolejny: 16 bitów. Wartość numeru sekwencyjnego zwiększa się o jeden z każdym wysłanym pakietem informacji RTP i może zostać wykorzystana przez odbiorcę do wykrycia utraty pakietów i przywrócenia ich pierwotnej sekwencji. Początkowa wartość numeru sekwencyjnego jest wybierana losowo, aby utrudnić złamanie klucza na podstawie znanych wartości tego pola (nawet jeśli źródło nie stosuje szyfrowania, ponieważ pakiety mogą przechodzić przez tłumacz, który używa szyfrowania) . Znacznik czasu: 32 bity. Znacznik czasu odzwierciedla punkt próbkowania dla pierwszego oktetu w pakiecie informacyjnym RTP. Punkt próbkowania należy uzyskać z timera, który zwiększa swoje wartości monotonicznie i liniowo w czasie, aby zapewnić synchronizację i wykryć jitter (patrz sekcja 4.3.1). Rozdzielczość timera musi być wystarczająca dla wymaganej dokładności taktowania i pomiaru jittera przy odbiorze pakietu (jeden raport timera na klatkę wideo zwykle nie wystarcza). Częstotliwość taktowania zależy od formatu przesyłanego ruchu i jest ustawiana statycznie w profilu lub specyfikacji formatu ruchu lub może być ustawiana dynamicznie dla formatów ruchu zdefiniowanych za pomocą „środków innych niż RTP”. Jeśli pakiety RTP są generowane okresowo, należy zastosować nominalne czasy próbkowania określone przez zegar próbkowania, a nie wartości zegara systemowego. Na przykład w przypadku sygnału audio o stałej przepływności pożądane jest, aby czujnik znacznika czasu był zwiększany o jeden dla każdego okresu próbkowania. Jeżeli aplikacja audio z urządzenia wejściowego odczytuje bloki zawierające 160 próbek, wówczas znacznik czasu musi zostać zwiększony o 160 dla każdego takiego bloku, niezależnie od tego, czy blok jest przesyłany w pakiecie, czy resetowany jako pauza. Początkowa wartość znacznika czasu, podobnie jak początkowa wartość numeru kolejnego, jest zmienną losową. Wiele kolejnych pakietów RTP może mieć takie same znaczniki czasu, jeśli są logicznie generowane w tym samym czasie, na przykład jeśli należą do tej samej klatki wideo. Kolejne pakiety RTP mogą zawierać niemonotoniczne znaczniki czasu, jeśli dane nie są przesyłane w kolejności próbkowania, jak ma to miejsce w przypadku interpolowanych klatek wideo MPEG (jednak numery sekwencji pakietów będą nadal monotoniczne podczas transmisji).
SSRC: 32 bity. Pole SSRC (źródło synchronizacji) identyfikuje źródło synchronizacji (patrz lista używanych skrótów i terminów). Identyfikator ten jest wybierany losowo, tak aby żadne dwa źródła synchronizacji w ramach tej samej sesji RTP nie miały tego samego identyfikatora SSRC. Chociaż prawdopodobieństwo, że wiele źródeł wybierze ten sam identyfikator, jest niskie, wszystkie implementacje protokołu RTP muszą być przygotowane na wykrywanie i rozwiązywanie takich kolizji. W rozdziale 6 omówiono prawdopodobieństwo kolizji wraz z mechanizmem ich rozwiązywania i wykrywania pętli warstwy RTP w oparciu o unikalność identyfikatora SSRC. Jeśli źródło zmieni swój źródłowy adres transportowy, musi także wybrać nowy identyfikator SSRC, aby uniknąć interpretacji jako źródła sprzężenia zwrotnego.
Lista CSRC: od 0 do 15 elementów, każdy po 32 bity. Lista CSRC (źródło wspólne) identyfikuje uwzględnione źródła ruchu zawartego w pakiecie.
Używając różnych identyfikatorów SSRC dla każdego rodzaju ruchu, ale przesyłając je w tej samej sesji RTP, można uniknąć pierwszych trzech problemów, ale nie da się uniknąć dwóch ostatnich. Dlatego specyfikacja protokołu RTP wymaga, aby każdy typ ruchu korzystał z własnej sesji RTP.
Istniejący nagłówek pakietu informacji RTP jest kompletny pod względem zestawu funkcji wymaganych ogólnie dla wszystkich klas aplikacji, które mogą obsługiwać RTP. Jednakże, aby lepiej odpowiadał konkretnym celom, nagłówek można modyfikować poprzez modyfikacje lub uzupełnienia określone w specyfikacji profilu.
Bit znacznika i pole typu ruchu zawierają informacje specyficzne dla profilu, ale są one umieszczone w stałym nagłówku, ponieważ oczekuje się, że będzie ich potrzebować wiele aplikacji. Oktet zawierający te pola może zostać przedefiniowany przez profil w celu dostosowania go do różnych wymagań, na przykład z większą lub mniejszą liczbą bitów znacznika. Jeśli istnieją jakieś bity znacznika, należy je umieścić w najbardziej znaczących bitach oktetu, ponieważ monitory niezależne od profilu mogą być w stanie zaobserwować korelację pomiędzy wzorcami utraty pakietów a bitem znacznika.
Dodatkowe informacje wymagane dla określonego formatu ruchu (na przykład typ kodowania wideo) muszą być zawarte w polu danych pakietu. Można go umieścić w określonym miejscu na początku lub wewnątrz tablicy danych.
Jeżeli dana klasa aplikacji wymaga dodatkowej funkcjonalności, niezależnej od formatu ruchu, wówczas profil, z którym te aplikacje współpracują, musi definiować dodatkowe stałe pola znajdujące się bezpośrednio za polem SSRC istniejącego stałego nagłówka. Aplikacje te będą mogły szybko uzyskać bezpośredni dostęp do dodatkowych pól, podczas gdy niezależne od profilu monitory lub rejestratory będą nadal mogły przetwarzać pakiety RTP, interpretując tylko pierwsze dwanaście oktetów.
Jeśli uważa się, że dodatkowe funkcjonalność ogólnie konieczne dla wszystkich profili, należy je zdefiniować nowa wersja RTP, aby dokonać trwałej zmiany w stałym nagłówku.
Aby umożliwić indywidualnym implementacjom eksperymentowanie z nowymi, niezależnymi od formatu funkcjami, które wymagają przechowywania dodatkowych informacji w nagłówku pakietu danych, protokół RTP zapewnia mechanizm rozszerzania nagłówka pakietu. Mechanizm ten został zaprojektowany w taki sposób, aby rozszerzenie nagłówka mogło zostać zignorowane przez inne komunikujące się aplikacje, które go nie wymagają.
Jeżeli bit X w nagłówku RTP jest ustawiony na jeden, wówczas do stałego nagłówka RTP dołączane jest rozszerzenie nagłówka o zmiennej długości (zgodnie z listą CSRC, jeśli istnieje). Należy pamiętać, że to rozszerzenie nagłówka jest przeznaczone wyłącznie do ograniczonego użytku. Rozszerzenie nagłówka pakietu RTP ma następujący format:
Rozszerzenie zawiera pole o długości 16 bitów, które wskazuje liczbę zawartych w nim słów 32-bitowych, z wyłączeniem nagłówka rozszerzenia o czterech oktetach (stąd długość może wynosić zero). Do stałego nagłówka pakietu informacyjnego RTP można dodać tylko jedno rozszerzenie. Aby umożliwić każdej z wielu interoperacyjnych implementacji niezależne eksperymentowanie z różnymi rozszerzeniami nagłówka lub aby umożliwić konkretnej implementacji eksperymentowanie z więcej niż jednym typem rozszerzenia nagłówka, użycie pierwszych 16 bitów rozszerzenia jest nieokreślone i zarezerwowane do rozróżniania identyfikatorów lub parametry.
| 1999 | ||||||||||||
| 2000 |
Protokół RTP
Głównym protokołem transportowym dla aplikacji multimedialnych stał się protokół czasu rzeczywistego RTP (Real-Time Protocol), przeznaczony do organizowania transmisji pakietów z zakodowanymi sygnałami mowy w sieci IP. Pakiety RTP przesyłane są protokołem UDP, który z kolei działa poprzez protokół IP (ryc. 1.5.).
Ryż. 1,5. W rzeczywistości poziom, do którego odnosi się RTP, nie jest tak jasno określony, jak pokazano na ryc. 1.5 i jak jest to zwykle opisywane w literaturze. Z jednej strony protokół naprawdę działa na UDP, jest zaimplementowany programy użytkowe
i wszystko wskazuje na to, że jest protokołem aplikacyjnym. Ale jednocześnie, jak stwierdzono na początku tego akapitu, RTP świadczy usługi transportowe niezależne od aplikacji multimedialnych i jest z tego punktu widzenia po prostu protokołem transportowym. Najbardziej udana definicja: RTP to protokół transportowy zaimplementowany na poziomie aplikacji.
Do przesyłania ruchu głosowego (multimedialnego) protokół RTP wykorzystuje pakiety, których strukturę pokazano na rys. 1.6.
Pakiet RTP składa się z co najmniej 12 bajtów. Pierwsze dwa bity nagłówka RTP (pole bitowe wersji, V) wskazują wersję protokołu RTP (obecnie wersja 2).
Oczywiste jest, że przy tej strukturze nagłówka możliwa jest co najwyżej tylko jedna wersja RTP. Poniższe pole zawiera dwa bity: bit P, który wskazuje, czy na końcu pola ładunku dodano znaki wypełniające (zwykle są one dodawane, jeśli protokół transportowy lub algorytm kodowania wymaga użycia bloków o stałym rozmiarze) oraz bit Bit X, który wskazuje, czy używany jest rozszerzony nagłówek.
Jeśli jest używane, pierwsze słowo rozszerzonego nagłówka zawiera całkowitą długość rozszerzenia. Następnie cztery bity CC określają liczbę pól CSRC na końcu nagłówka RTP, tj. liczba źródeł tworzących przepływ. Bit znacznika M umożliwia oznaczenie tego, co standard definiuje jako istotne zdarzenia, takie jak początek klatki wideo, początek słowa w kanale audio itp. Po nim następuje pole typu danych PT (7 bitów), które określa kod typu ładunku, który definiuje zawartość pola ładunku – Dane aplikacji, na przykład nieskompresowany 8-bitowy dźwięk MP3 itp. Korzystając z tego kodu, aplikacja może dowiedzieć się, co zrobić, aby zdekodować dane. Pozostała część nagłówka o stałej długości składa się z pola numeru sekwencyjnego, pola sygnatury czasowej rejestrującego moment utworzenia pierwszego słowa pakietu oraz pola źródła zegara SSRC, które identyfikuje to źródło. Ostatnie pole może wskazywać pojedyncze urządzenie, które ma tylko jeden adres sieciowy, wiele źródeł mogących reprezentować różne media (audio, wideo itp.) lub różne strumienie tych samych multimediów. Ponieważ źródła mogą być włączone różne urządzenia, Identyfikator SSRC jest wybierany losowo, dzięki czemu szansa na otrzymanie danych z dwóch źródeł jednocześnie podczas sesji RTP jest minimalna. Zdefiniowano jednak także mechanizm rozwiązywania konfliktów, jeśli one powstaną. Po ustalonej części nagłówka RTP może następować maksymalnie 15 oddzielnych 32-bitowych pól CSRC identyfikujących źródła danych.
RTP obsługiwany jest przez protokół Real-Time Transport Control Protocol (RTCP), który generuje dodatkowe raporty zawierające informacje o sesjach komunikacyjnych RTP. Przypomnijmy, że ani UDP, ani RTP nie zajmują się zapewnianiem QoS (jakości usług). Protokół RTCP zapewnia informację zwrotną nadawcom, a odbiorcom strumieni zapewnia pewne ulepszenia QoS, informacje o pakietach (utrata, opóźnienie, wahania) i informacje o użytkowniku (aplikacja, strumień). W przypadku kontroli przepływu istnieją dwa typy raportów – generowane przez nadawcę i generowane przez odbiorcę. Na przykład informacja o ułamku utraconych pakietów i bezwzględnej liczbie utraconych pakietów pozwala nadawcy podczas odbierania raportu wykryć, że przeciążenie kanału może spowodować, że odbiorcy nie będą akceptować oczekiwanych strumieni pakietów. W takim przypadku nadawca ma możliwość obniżenia szybkości kodowania, aby zmniejszyć zatory i poprawić odbiór. Raport nadawcy zawiera informacje o tym, kiedy został wygenerowany ostatni pakiet RTP (obejmuje to zarówno etykietę wewnętrzną, jak i czasie rzeczywistym). Informacje te pozwalają odbiorcy koordynować i synchronizować wiele strumieni, takich jak wideo i audio. Jeśli strumień jest wysyłany do kilku odbiorców, wówczas organizowane są strumienie pakietów RTCP od każdego z nich. Zostaną podjęte kroki mające na celu ograniczenie przepustowości – odwrotnie proporcjonalne do szybkości generowania raportów RTCP i liczby odbiorców.
Należy zauważyć, że chociaż protokół RTCP działa niezależnie od protokołu RTP, sam łańcuch RTP/UDP/IP powoduje znaczne obciążenie (w postaci ich nagłówków). Kodek G.729 generuje pakiety o długości 10 bajtów (80 bitów co 10 ms). Jeden nagłówek RTP o rozmiarze 12 bajtów jest większy niż cały pakiet. Dodatkowo należy dodać 8-bajtowy nagłówek UDP i 20-bajtowy nagłówek IP (w IPv4), co tworzy nagłówek czterokrotnie większy od przesyłanych danych.
W przypadku korzystania z protokołu RTP do komunikacji otwierane są dwa porty. Jeden do przesyłania strumienia multimediów ( liczba parzysta port) i jeden do przesyłania danych sygnalizacyjnych ( informacja zwrotna do QoS i kontroli przepływu mediów) - RTCP. Wartości numerów portów nie są ogólnie ściśle powiązane; silnie zależą od używanej aplikacji.RTP — protokół transportu w czasie rzeczywistym RTCP — protokół kontroli w czasie rzeczywistym Zawiera dodatkowo informacje na temat: utraty pakietów, buforowania jittera, opóźnień, siły sygnału, metryki jakości sygnału (metryki jakości połączenia), utraty sygnału zwrotnego itp. RTCP XR - Rozszerzone raporty protokołu kontroli w czasie rzeczywistym Wszystkie pola opisane dla protokołu RTCP plus: R Factor - parametr jakości sygnału MOS - parametr jakości sygnału i inne
Pakiety zawierające przesyłany głos przesyłane są przy użyciu protokołu RTP/RTCP, który jest używany w połączeniach VOIP. Protokół RTP umożliwia przesyłanie danych multimedialnych identyfikowanych poprzez parametry zarejestrowane przez organizację: „Urząd ds. numerów przypisanych do Internetu” – IANA. Są one również używane w polach protokołu używanego w wiadomościach.
Niektóre wartości pól ładunku:
| P.T. | nazwa kodeka | audio/wideo (A/V) | częstotliwość taktowania (Hz) | liczba kanałów | Dokument | 0 | PCMU | A | 8000 | 1 | RFC3551 | 3 | GSM | A | 8000 | 1 | RFC3551 | 4 | G723 | A | 8000 | 1 | Kumar | 5 | DVI4 | A | 8000 | 1 | RFC3551 | 6 | DVI4 | A | 16000 | 1 | RFC3551 | 7 | LPC | A | 8000 | 1 | RFC3551 | 8 | PCMA | A | 8000 | 1 | RFC3551 | 9 | G722 | A | 8000 | 1 | RFC3551 | 10 | L16 | A | 44100 | 2 | RFC3551 | 11 | L16 | A | 44100 | 1 | RFC3551 | 12 | QCELP | A | 8000 | 1 | - | 13 | CN | A | 8000 | 1 | RFC3389 | 14 | MPA | A | 90000 | RFC3551,RFC2250 | 15 | G728 | A | 8000 | 1 | RFC3551 | 16 | DVI4 | A | 11025 | 1 | DiPol | 17 | DVI4 | A | 22050 | 1 | DiPol | 18 | G729 | A | 8000 | 1 | 19 | skryty | A | 20 | nie przypisany | A | 21 | nie przypisany | A | 22 | nie przypisany | A | 23 | nie przypisany | A | 24 | nie przypisany | V | 25 | CelB | V | 90000 | RFC2029 | 26 | JPG | V | 90000 | RFC2435 | 27 | nie przypisany | V | 28 | nw | V | 90000 | RFC3551 | 29 | nie przypisany | V | 30 | nie przypisany | V | 31 | H261 | V | 90000 | RFC2032 | 32 | MPV | V | 90000 | RFC2250 | 33 | MP2T | AV | 90000 | RFC2250 | 34 | H263 | V | 90000 | Zhu | 35--71 | nie przypisany | 72--76 | zarezerwowane dla RTCP, aby uniknąć konfliktów | RFC3550 | 77--95 | nie przypisany | 77--95 | dynamiczny | RFC3551 |
IANA: Zarejestrowane parametry protokołu RTP: http://www.iana.org/ przypisania/rtp-parameters
Protokół RTP i translacja adresów IP (NAT) Podczas prowadzenia sesji komunikacyjnej VOIP tworzone są dwa strumienie RTP, po jednym w każdym kierunku. Jeżeli jeden z uczestników tej sesji korzysta z adresu IP z sieci prywatnej, wówczas przepływ od abonenta znajdującego się w sieć publiczna w kierunku serwera NAT, nie będzie mógł dotrzeć do abonenta znajdującego się w sieć wewnętrzna. Aby rozwiązać ten problem, często stosuje się (symetryczny RTP). Dla dodatkowe informacje o używaniu VOIP w sieciach z NAT, zobacz: Artykuły NAT i VOIP RTCP XR mierzy wydajność VoIP Network World 17.11.03 Dokumenty RFC: IETF RFC 3550 RTP: Protokół transportowy do zastosowań w czasie rzeczywistym. IETF RFC 3611 Rozszerzone raporty protokołu kontroli RTP (RTCP XR) IETF RFC 1890 Profil RTP do konferencji audio i wideo przy minimalnej kontroli. IETF RFC 2508 Kompresja nagłówków pakietów IP/UDP/RTP dla linii komunikacyjnych o niskiej prędkości. IETF RFC 3545 Zaawansowana kompresja RTP (CRTP) dla łączy o dużych opóźnieniach, dużej utracie pakietów i częstym ponownym wysyłaniu danych.
