Protokół transportu w czasie rzeczywistym

Real-Time Transport Protocol ( RTP ) to protokół do ciągłej transmisji danych audiowizualnych ( strumieni ) na IP opartych sieci . Protokół został po raz pierwszy ustandaryzowany w RFC 1889 w 1996 roku . W 2003 roku został zastąpiony przez RFC 3550 .

c. obsługuje multimedia - strumienie danych ( audio , wideo , tekst , itp.) za pośrednictwem sieci do transportu, re. H. do kodowania, pakowania i wysyłania danych. RTP jest transmisji pakietowej podstawie protokołu i zazwyczaj działa na UDP . RTP może być używany zarówno do połączeń typu unicast, jak i do komunikacji multicastowej w Internecie. RealTime Control Protocol (RTCP) współpracuje z RTP i służy do negocjowania i utrzymać jakość usług parametrów (QoS).

Znajduje zastosowanie w wielu dziedzinach, m.in.: jest używany ze standardami telefonii IP H.323 i SIP do przesyłania strumieni audio i wideo połączenia.

Główną funkcją protokołu RTP jest przesyłanie strumieni danych wymagających czasu rzeczywistego , podczas gdy protokół strumieniowania w czasie rzeczywistym (RTSP) służy do sterowania i monitorowania transmisji danych.

Datagram Congestion Control Protocol (DCCP) jest obecne podejście, aby umożliwić kontrolę przeciążenia dla mediów na podstawie strumieni RTP / UDP.

architektura

Źródło synchronizacji

Źródło danych nosi nazwę Synchronization Source (SSRC) i jest identyfikowane przez identyfikator (32 bity) w nagłówku.

Tłumacz

Tłumacz przodu przychodzące pakiety RTP pozostawiając SSRC identyfikator nienaruszone. Tłumacze mogą pozostawić dane bez zmian i są wykorzystywane np. do przełamywania zapór . Można jednak również zmienić kodowanie przesyłanych danych, należy dostosować pola Payload Type i Timestamp w nagłówku . Przekodowywanie odbywa się w sposób przejrzysty dla odbiorcy.

mikser

Miksery łączą strumienie danych z kilku źródeł w nowy strumień danych i przesyłają go dalej. Kodowanie można również zmienić. Ponieważ strumienie danych źródeł, które mają zostać połączone, niekoniecznie są zsynchronizowane, mikser musi generować własne taktowanie dla połączonego strumienia. Z tego powodu mikser wpisuje własny identyfikator SSRC w odpowiednim polu dla wszystkich wychodzących pakietów. Aby zachować tożsamość oryginalnych źródeł, ich identyfikatory SSRC są umieszczane na liście identyfikatorów CSRC.

odbiorca

Odbiorca pakietów RTP sortuje je na podstawie numerów sekwencyjnych i udostępnia odpowiedniej aplikacji.

Pakiet RTP

Pakiet RTP składa się z nagłówka z numerem wersji i sekwencji, formatem danych, identyfikatorem nadawcy i znacznikiem czasu oraz częścią danych użytkownika.

Nagłówek RTP

Wersja (V), 2 bity

Status wersji protokołu RTP

Dopełnienie (P), 1 bit

Bit wypełnienia jest ustawiany, jeśli na końcu pakietu dołączony jest jeden lub więcej bajtów wypełnienia, które nie należą do rzeczywistej zawartości danych (ładunku danych). Ostatni bajt wypełniający wskazuje liczbę dodanych bajtów wypełniających. Bajty wypełniające są wymagane tylko wtedy, gdy kolejne protokoły wymagają określonego rozmiaru bloku, np. B. Algorytmy szyfrowania.

Rozszerzenie (X), 1 bit

Bit rozszerzenia jest ustawiany, gdy do nagłówka dodawany jest dokładnie jeden nagłówek rozszerzenia.

Liczba CSRC (CC), 4 bity

Licznik CSRC wskazuje liczbę identyfikatorów CSRC.

Znacznik (M), 1 bit

Bit znacznika jest zarezerwowany do zastosowań specyficznych dla aplikacji. Służy do identyfikacji zdarzeń m.in. B. wystąpienie końca klatki sekwencji wideo.

Typ ładunku (PT), 7 bitów

To pole opisuje format przesyłanej treści RTP, tj. danych użytkownika (ładunku).

Numer sekwencyjny, 16-bitowy

Numer sekwencyjny jest zwiększany dla każdego dodatkowego pakietu danych RTP. Numer startowy jest wybierany losowo i nie można go z góry ustalić. Odbiorca może użyć numeru sekwencyjnego, aby przywrócić kolejność pakietów i rozpoznać utratę pakietów.

Znacznik czasu, 32-bitowy

Znacznik czasu wskazuje czas pierwszego bajtu pakietu danych RTP. Punkt w czasie musi być oparty na zegarze ciągłym i liniowym, aby zapewnić synchroniczność strumienia i określić różnice czasu pracy na ścieżce transmisji (jitter). Podobnie jak numer sekwencyjny, wartość początkowa powinna być wartością losową. Kolejne pakiety mogą mieć ten sam stempel czasowy, jeśli przesyłane dane to m.in. B. należą do tego samego pojedynczego obrazu ("klatki wideo"). Pakiety z kolejnymi numerami sekwencyjnymi mogą również zawierać niekolejne znaczniki czasu, jeśli takie jak B. w przypadku skompresowanego wideo kolejność transmisji i odtwarzania nie zgadza się.

SSRC, 32-bitowy

To pole służy do identyfikacji źródła synchronizacji. Wartość jest ustalana losowo, dzięki czemu dwa źródła w sesji RTP nie mają tego samego numeru identyfikacyjnego.

Lista CSRC, od 0 do 15 pól, każde 32 bity

Lista CSRC służy do identyfikacji źródeł zawartych w danych użytkownika RTP. Liczba pól listy jest określona w polu CC. Jeśli jest więcej niż 15 źródeł, identyfikuje się tylko 15. Lista jest wstawiana przez miksery, które wykorzystują zawartość pola SSRC zaangażowanych źródeł.

literatura

• Ulrich Trick, Frank Weber: SIP, TCP/IP i sieci telekomunikacyjne. Wydanie drugie, Oldenbourg, 2005, ISBN 978-3-486-57796-9 .

Normy i standardy

Magistrala:

• RFC 1889 — RTP: protokół transportowy dla aplikacji czasu rzeczywistego [1996, przestarzałe]
• RFC 3550 — RTP: protokół transportowy dla aplikacji czasu rzeczywistego [2003, obecnie]
  • Dodatek RFC 5506 — obsługa protokołu RTCP (Reduced-Size Real-Time Transport Control Protocol): możliwości i konsekwencje [2009, obecnie]
  • Dodatek RFC 5761 — Multipleksowanie pakietów danych RTP i pakietów kontrolnych na jednym porcie [2010, obecnie]
  • Dodatek RFC 6051 — Szybka synchronizacja przepływów RTP [2010, obecnie]
  • Suplement do RFC 7022 — Wytyczne dotyczące wyboru nazw kanonicznych (CNAME) protokołu RTP Control Protocol (RTCP) [2013, obecnie]
  • Dodatek RFC 7160 — obsługa wielu częstotliwości taktowania w sesji RTP [2014, aktualne]
  • Dodatek RFC 7164 - RTP i sekundy przestępne [2014, obecnie]
  • Dodatek RFC 8083 — Kontrola przeciążenia multimediów: wyłączniki dla sesji Unicast RTP [2017, obecnie]

Linia oddziału:

• RFC 1890 — profil RTP dla konferencji audio i wideo z minimalną kontrolą [1996, przestarzały]
• RFC 3551 — profil RTP dla konferencji audio i wideo z minimalną kontrolą [2003, obecnie]
  • Dodatek RFC 7007 — aktualizacja usuwająca DVI4 z zalecanych kodeków dla profilu RTP dla konferencji audio i wideo z minimalną kontrolą (RTP / AVP) [2013, obecnie]

linki internetowe

• Profil danych kontrolnych RTP (RTP / CDP) dla aplikacji maszyna-maszyna

Indywidualne dowody

1. ↑ Finley Breese: Komunikacja szeregowa przez RTP/CDP . BoD - Książki na żądanie, 2010, ISBN 9783839184608 , s.  [1] .