Protokół RTP ma kilka nazw, jak
Real Time Protocol,
Real-time Transport Protocol
Nazwa zgodna z RFC 1889 ma postać:
A Transport Protocol for Real-Time Applications Internet
.
Jego zadaniem jest dostarczanie w czasie rzeczywistym pakietów z takimi danymi,
jak audio i wideo.
Pakiety kontrolowane są od momentu wejścia do sieci do momentu wyjścia z niej.
Protokół ten może obsługiwać aplikacje zarówno unicastowe, jak i multicastowe.
IDEA TRANSMISJI CZASU RZECZYWISTEGO
Wyobraźmy sobie, że spotyka się grupa, która chce omówić ważną sprawę.
Wykorzystają do tego mulitemisję dźwięku w sieci IP.
Zakładamy, że otrzymali
oni adres multicastowy i ustaliły dwa porty. Jeden wykorzystany jest do
transmisji audio a drugi przeznaczony jest dla kontrolnego protokołu RTCP.
Wiadomość o adresie i portach została rozesłana do wszystkich uczestników
konferencji. Oprócz tego rozesłane zostały informacje o kluczu szyfrującym. Tak
przygotowana sieć nadaję się już do transmisji RTP. Wtedy uczestnicy
konferencji mogą rozpocząć pracę.
Zakładamy, ze każdy uczestników konferencji wysyłka dane audio w małych
paczkach powiedzmy co 20 ms.
Każda taka paczka jest zabezpieczona przez
nagłówek RTP. Ten nagłówek i dane zawarte są w pakiecie UDP.
Nagłówek
RTP zawiera informacje np. o sposobie kodowania. Dzięki czemu istniej
możliwość dynamicznej zmiany kodeka gdyby np. do konferencji włączyła się
osoba korzystająca z wąsko pasmowego łącza.
IDEA TRANSMISJI CZASU RZECZYWISTEGO-CD
Uczestnicy konferencji korzystają z sieci pakietowej więc nieuniknione jest to że
pakiety czasem się zgubią lub dotrą z różnymi opóźnieniami.
Nagłówek RTP
zawiera informacje dotyczące synchronizacji i numerów sekwencji dzięki czemu
odbiornik może zrekonstruować nadawany sygnał.
Ku temu służy synchronizacja
czasowa czyli nadawanie małych porcji sygnału co 20 ms. Ta czynność
rekonstrukcji sygnału jest przeprowadzana oddzielnie przez każdy odbiornik.
Oprócz samej rekonstrukcji na podstawie informacji przenoszonych przez
nagłówek RTP (ponumerowane sekwencje) odbiornik może określi ile pakietów
zostało zgubionych a ile dotarło bez strat.
Ważnym elementem naszej przykładowej konferencji jest to, że dzięki protokołowi
RTP aplikacje poszczególnych użytkowników wiedzą kto akurat uczestniczy w
konferencji, kto odszedł, a kto przed chwila się dołączył.
Komunikacja między
aplikacjami odbywa się okresowo na porcie wykorzystywanym przez RTCP.
Przesyłane są wtedy raporty zawierające informacje o nazwie użytkownika i
jakości odbieranego przez niego sygnału. Informacje te służą do identyfikacji
użytkowania, do dobrania odpowiedniego kodeka czy tez przydzielenia
odpowiedniej szerokości pasma.
IDEA TRANSMISJI CZASU RZECZYWISTEGO-CD
Wyobraźmy sobie teraz, że oprócz dźwięku uczestnicy konferencji przesyłają
także obraz wideo. Transmisja ta niczym się nie różni od transmisji audio. W
nowym przypadku obraz przekazywany jest podobnie jak dźwięk.
Wykorzystuje on transmisje UDP.
Protokół kontrolny RTCP razem z transmisją
wideo wykorzystuje nową, oddzielną parę portów.
Ważne jest to aby nagłówki użytkownika nadającego audio i wideo miały te
sama nazwę – sesje muszą być ze sobą powiązane. Dzięki temu pozostali
użytkownicy mogą sami decydować czy chcą odbierać tylko dane audio lub
wideo czy całą transmisję.
Synchronizacja czasowa obu przekazów odbywa się
za pomocą oznaczeń czasowych przenoszonych w nagłówkach RTCP.
IDEA TRANSMISJI CZASU RZECZYWISTEGO-CD
Kolejną ważną sprawą, której nie można pominąć jest to, że poszczególni
uczestnicy konferencji mogą korzystać z łącz o różnej szerokości pasma lub
nawet mogą być nieosiągalni bezpośrednio poprzez multicastowy adres
grupy.
Wtedy z pomocą przychodzą takie usługi oferowane przez RTP jak
miksery i translatory.