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
RTP - transport i jakość RTSP - kontrola RSVP - rezerwacja zasobów HTTP, SDP - opisy SIP - połączenia między ludźmi, sesje MULTIMEDIALNY INTERNET
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 H.323 Audio/ Video H.225 H.245 Q.931 RAS SIP MGCP RTP RTCP RTSP TCP UDP IP