Protokół RTP, określony w specyfikacji RFC 1889, zapewnia usługi dostawcze typu end-to-end, aby zapewnić obsługę aplikacji, które transmitują dane czasu rzeczywistego. Dokument RFC 1890 określa profil przenoszenia ruchu audio oraz wideo poprzez RTP. Microsoft Netmeeting jest przykładem aplikacji opartej na RTP.
W skład usług RTP wchodzi rozpoznawanie typu ładunku, numerowanie sekwencji oraz nadawanie znaczników czasu. Protokół zapewnia usługi dostawcze typu end-to-end, ale nie zapewnia zestawu wszystkich funkcji protokołu transportowego. Zazwyczaj RTP działa na wierzchu protokołu UDP i wykorzystuje jego usługi multipleksowania i sumy kontrolnej.
Nagłówek RTP dostarcza informacji dotyczących synchronizacji, które są wykorzystywane do synchronizacji i wyświetlania danych audio i wideo. Informacje te mogą również określać czy pakiety uległy utracie, czy też doszły w niewłaściwej kolejności. Nagłówek określa również typ ładunku, przy czym dozwolonych jest wiele typów danych i kompresji. Specyfikacje profilu pomocniczego oraz formatu ładunku konfigurują RTP do określonej aplikacji — na przykład format ładunku może określać typ kodowania audio lub wideo przenoszony w pakiecie RTP. Dane zakodowane mogą być poddawane kompresji przed dostarczeniem.
Aby ustanowić sesję RTP, aplikacja określa parę adresów docelowych transportu (jeden adres sieciowy plus porty dla RTP oraz RTCP). Każde medium w transmisji multimedialnej przenoszone jest w oddzielnej sesji RTP, co daje odbiorcy wybór czy odbierać, czy nie odbierać określonego medium. Specyfikacja RFC 1889 przedstawia wykorzystanie RTP w scenariuszu audio-konferencji Więcej informacji można uzyskać z tej specyfikacji RFC.
RTP nie zawiera żadnych mechanizmów gwarantujących dostawę na czas, czy też dających gwarancje jakości usługi. Nie gwarantuje on dostawy, ani nie sprawdza, czy pakiety są odbierane w kolejności transmitowania. Nie zakłada też, że wykorzystywana sieć jest niezawodna. Niektóre aplikacje adaptacyjne nie wymagają takich gwarancji, ale w przypadku tych, które ich wymagają, RTP musi być wspomagany przez mechanizmy zapewniające rezerwację zasobów, jak kontrola wpływu danych Jakości usługi.
Nagłówek RTP zawiera następujące pola:
· Wersja — to 2-bitowe pole identyfikuje wersję RTP, aktualnie 2.
· Wypełnienie — to 1-bitowe pole wskazuje czy pakiet RTP zawiera jeden, czy więcej oktetów wypełniających, nie będących częścią ładunku. Wypełnienie może być wymagane w przypadku algorytmów szyfrowania, mających stałe rozmiary bloków, lub w przypadku przenoszenia kilku pakietów RTP w jednostce danych protokołu niższego poziomu.
· Rozszerzenie — to 1-bitowe pole wskazuje, czy po stałym nagłówku RTP następuje rozszerzenie nagłówka.
· Liczba CSRC (CC) — to 4-bitowe pole określa liczbę identyfikatorów źródeł zasilających (CSRC), które następują po stałym nagłówku.
· Znacznik (M) — to 1-bitowe pole umożliwia zaznaczanie w strumieniu danych istotnych zdarzeń, takich jak granice ramek.
· Typ ładunku — to 7-bitowe pole identyfikuje format ładunku RTP i określa sposób jego interpretacji przez aplikację.
· Numer sekwencji — to 16-bitowe pole zawiera numer sekwencji, który wzrasta o jeden z każdym wysłanym pakietem danych RTP i może być wykorzystywany przez odbiorcę do wykrywania utraty danych oraz do przywracania sekwencji pakietów.
· Znacznik czasu — to 32-bitowe pole zawiera znacznik czasu, który odzwierciedla moment próbkowania pierwszego oktetu w pakiecie danych RTP. Znacznik czasu wykorzystywany jest przy obliczeniach synchronizacji i rozsynchronizowania. Obliczanie i stosowanie znaczników jest skomplikowane. Aby uzyskać szczegóły, odwołaj się do specyfikacji RFC 1889.
· SSRC — to 32-bitowe pole identyfikuje źródło synchronizacji (SSRC). Identyfikator ten wybierany jest losowo, aby dwa źródła synchronizacji w obrębie tej samej sesji RTP nie miały tego samego identyfikatora SSRC.
· Lista SSRC — to pole może zawierać od 0 do 15 pozycji, każda o długości 32 bitów. Lista CSRC identyfikuje źródła zasilające dla ładunku zawartego w pakiecie. Liczba identyfikatorów określona jest w polu CC.