nagłówek rtp

ZAŁOŻENIA PROTOKOŁU RTP
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.
PROTOKOŁY STREAMINGU
MULTIMEDIALNY INTERNET
RTP - transport i jakość
RTSP - kontrola
RSVP - rezerwacja zasobów
HTTP, SDP - opisy
SIP - połączenia między ludźmi, sesje
NAGŁÓWEK RTP
V – wersja protokołu RTP (obecnie V=2)
P – gdy ten bit jest ustawiony oznacza to, iż pakiet RTP zawiera jeden lub
więcej błędnych oktetów, które nie są częścią strumienia użytecznego.
Przy czym ostatnio oktet w tym pakiecie zawiera liczbę oktetów, które
powinny być zignorowane - włącznie z nim samym.
NAGŁÓWEK RTP - CD
X - eXtension - wskazuje na następnY nagłówek po RTP, ale nie jest jeszcze używany.
CC (CSRS Count) przenosi liczbę identyfikatorów CSRS.
M (Marker) jest znacznikiem, którego interpretacja została zdefiniowana
przez profil. Znacznik zwraca uwagę na pewne ważne zdarzenia, np.
zaznaczanie w strumieniu ramek brzegowych.
NAGŁÓWEK RTP - CD
Typ ruchu - typ przenoszonej informacji. Identyfikuje format ładunku RTP i określa
sposób jego interpretacji przez aplikację. Wyszczególnia typ i sposób kodowania
informacji.
Stempel czasowy - znacznik czasu. Wprowadza próbki zegara dla pierwszego oktetu
pakietu RTP. Zegar musi być liniowy, by pozwalał synchronizować i obliczać
wahania przybywających pakietów. Musi być także wystarczająco dokładny by było
można mierzyć wahania przybycia paczek (np. jeden takt na ramkę wideo nie jest
wystarczający).
NAGŁÓWEK RTP - CD
SSRC – 32 bitowy identyfikator źródła synchronizacji (źródła strumienia
pakietów RTP). Przykłady takich źródeł: nadawcy strumieni pakietów
wywodzących się z sygnałów źródłowych, jak mikrofon, kamera lub mikser.
Źródło synchronizacji może zmieniać format danych, na przykład przez
kodowanie audio. Jeśli uczestnik generuje wiele strumieni w jednej sesji RTCP
(z oddzielnych kamer wideo itp.), to każdy strumień musi mieć inny SSRC.
TRANSLATORY RTP
załóżmy, że urządzenia po lewej stronie są przystosowane do przepływności 512
kb/s, a po prawej 384 kb/s (jak pokazano na rysunku). Dodatkowo już sama sieć
transportowa może nie być w stanie przesłać strumienia 512 kb/s. W sytuacji
zaistnienia takich ograniczeń komunikacja multimedialna między urządzeniami z lewej
i prawej strony (rysunku) nie będzie możliwa. Jednakże translator RTP, który
faktycznie jest podsystemem przesyłającym pakiety RTP z nienaruszonym
identyfikatorem synchronizacji źródła, umożliwi wzajemną interakcję. Jego praca
polega w głównej mierze na przekształceniu jednej składni na inną, czyli - innymi
słowy - na przystosowaniu ruchu do formatu, który uwzględni ograniczenia zarówno
pasma transmisyjnego sieci tranzytowej, jak też stacji w jakiej znajduje się odbiorca.
MIKSERY RTP
Mikser łączy wiele źródeł w jeden strumień - po prostu łączy sygnały w spójny
format (patrz rys.3.2.). Zazwyczaj miksery uczestniczą w operacjach audio i nie
pogarszają jakości sygnału. Operacje miksowania RTP są szczególnie polecane
w audiokonferencjach, natomiast niezbyt dobrze radzą sobie z
wideokonferencjami. Miksery RTP nie dokonują translacji każdego rodzaju, np.
nie dokonują jej z każdego źródła na różne formaty.
PODSTAWY RTCP
Protokół, używany do przekazywania informacji w sesji kontrolnej,
nazywa się Real-Time Control Protocol - RTCP.
Jest on odpowiedzialny za nadzorowanie sesji czasu rzeczywistego
pomiędzy aplikacjami wytwarzającymi ruch a odbierającymi.
Protokół ten umożliwia nadawcy informowanie odbiorcy o skierowaniu w
jego stronę ruchu RTP.
Pozwala też odbiorcy tworzyć raporty i kierować je do nadawcy. Jest to
użyteczne zwłaszcza w multicastingu IP, ponieważ umożliwia diagnozowanie
błędów podczas dystrybucji pakietów.
Dzięki separacji strumienia głosowego i wideo, nadawca otrzymuje
dokładniejsze informacje zwrotne. Daje to możliwość optymalizacji: sposobu
nadawania oraz samej architektury sieci, pod kątem polepszenia jakości
zarówno dźwięku, jak i obrazu.
WŁASNOŚCI RTP
Protokół RTCP zapewnia sprzężenie zwrotne, synchronizację oraz interfejs użytkownika,
lecz nie umożliwia przesyłania żadnych danych. Mechanizm sprzężenia zwrotnego może
być wykorzystany do reagowania na opóźnienia, zmianę szerokości pasma, przeciążenia,
utratę pakietów i wszelkie inne konsekwencje błędów sieci związanej ze źródłem.
Protokół RTCP może być także pomocny w procesie synchronizacji różnych strumieni.
Znakowanie czasowe pakietów RTP może okazać się niewystarczające, jeżeli różne
strumienie używać będą różnych zegarów. o zróżnicowanej granulacji i różnym stopniu
odchyłki od wskazania normatywnego; RTCP umożliwia uporanie się z tym problemem.
RTCP daje możliwość opatrywania poszczególnych źródeł opisami (na przykład w
postaci tekstu ASCII).
Każda sesja RTP jest identyfikowana przez adresy sieciowe
i parę portów: jednego dla danych RTP i jednego dla danych
RTCP. Port danych RTP powinien być parzysty a port RTCP
o jeden numer wyższy niż RTP.
PAKIETY RTCP
W specyfikacji RTP zdefiniowanych jest pięć rodzajów pakietów RTCP:
komunikat odbiorcy (RR – receiver report),
komunikat nadawcy (SR – sender report),
opis źródła (SDES – source description),
zarządzanie członkostwem (BYE – membership management)
zdefiniowany przez aplikację (APP- application defined).
Każdy z nich jest zbudowany zgodnie z podstawową strukturą, ale
posiada odmienne pola w miejscu oznaczonym jako „Format-specific
information” w zależności od typu pakietu zdefiniowanego w polu PT.
NAGŁÓWEK RTCP
V (Version Number) – numer wersji (zawsze 2 dla bieżącej ersji RTP
P (Padding) – bit sygnalizujący obecność dopełnienia. Jeśli jest ustawiony na
1, to oznacza, że ten pakiet RTCP zawiera dodatkowe oktety.
IC (Item Count) – pole określa liczbę elementów charakterystycznych dla
danego typu pakietu (np. liczba bloków zawartych w pakiecie). Pole może mieć
różne nazwy w poszczególnych typach pakietów, w zależności od ich
zastosowania.
PT (Packet Type) – identyfikuje typ informacji przenoszonej przez pakiet
(jeden z pięciu wymienionych wcześniej)
PROTOKOŁY VoIP
Sygnalizacja
Kontrola bramy
Media
Audio/
Video
H.323
H.225
H.245
Q.931
RAS
SIP
MGCP
TCP
UDP
IP
RTP
RTCP
RTSP