Page 1

Politechnika Rzeszowska im. Ignacego Łukasiewicza

Komunikacja w sieciach mikrokomputerowych Projekt

RTCP (Real-time Transport Control Protocol) Zrealizował: Daniel Gwazdacz 4EF-ZI

Rzeszów, 28.12.2010


Czym jest RTCP ? RTCP (ang. Real-time Transport Control Protocol) został zdefiniowany w dokumencie RFC1889 w 1996 a następnie zaktualizowany w RFC3550 w 2003 roku. • RTCP jest protokołem sterującym, • przekazującym informacje kontrolne(QoS) od wszystkich uczestników sesji, • wspierającym protokół RTP (transportujący dane czasu rzeczywistego takie jak np. audio czy wideo), Oba protokoły bazują najczęściej na protokole transportowym UDP.


Duet RTCP i RTP

Protokół RTP jest skalowalnym, uniwersalnym i elastycznym rozwiązaniem dla zapewnienia transmisji strumieniowej czasu rzeczywistego, sprawdzającym się w zakresie od kbit/s do wielu Mbit/s. Oba protokoły są przystosowane do transmisji typu unicast jak i multicast. Ich cechą jest niezależność od technologii transportowej i używanego medium. Transmisje rzeczywiste zostają zazwyczaj rozbite na dwa współdziałające ze sobą kanały: • pierwszy działa w oparciu o RTP i odpowiada za dostarczanie danych, • drugi kanał obsługuje protokół kontrolny RTCP, odpowiadając za przekazywanie informacji kontrolnych i raportów dotyczących połączenia.


Zastosowanie RTP/RTCP Oba protokoły RTP/ RTCP stosowane są w: • telekonferencjach, • wideokonferencjach, • do przesyłania multimediów przez sieć Internet, metodami unicast i multicast, • IPTV, • VoIP (Voice over IP), • VOD (Video on Demand),


Kilka słów o RTP • RTP – zapewnia aplikacji podstawowe usługi wymagane do transportu strumieni czasu rzeczywistego • Zakłada zasadę „end-to-end” (niezawodność, nawet gdy sieć jest zawodna) • Sesja RTP stanowi powiązanie między komunikującymi się użytkownikami: – Dla każdego z nich sesję definiuje adres docelowy IP oraz dwie pary portów (nadawcze i odbiorcze dla RTP i RTCP) – Strumienie w ramach sesji są rozróżniane poprzez numery SSRC (multipleksacja) – W praktyce rożne media są zawsze transportowane w osobnych sesjach [10]


Podstawowe funkcje RTP • RTP zapewnia aplikacjom możliwość wyrównania wahań opóźnienia oraz zaburzeń w kolejności pakietów, wprowadzanych przez IP – numeracja pakietów (RTP nie zapobiega przychodzeniu pakietów w niewłaściwej kolejności): umożliwia detekcję strat oraz odtworzenie sekwencji pakietów – „payload type”: identyfikacja rodzaju zawartości pakietu – „timestamp”: synchronizacja strumienia danych (odbiornik może odtworzyć właściwe zależności czasowe między otrzymanymi ramkami); tzw. „dejitter” – szyfrowanie zawartości • Protokół RTP nie obsługuje mechanizmów QoS – nie zawiera żadnych mechanizmów związanych z rezerwacją zasobów – nie zapewnia transmisji strumieni danych z gwarantowaną jakością • RTP jest zazwyczaj wykorzystywany w połączeniu z protokołem UDP [10]


Założenia RTCP • Nadzoruje sesje czasu rzeczywistego pomiędzy aplikacjami wytwarzającymi ruch a odbierającymi, • Pozwala odbiorcy tworzyć raporty i kierować je do nadawcy. Jest to szczególnie przydatne w multicastingu IP, ponieważ umożliwia diagnozowanie problemów podczas dystrybucji pakietów, • Dzięki oddzieleniu strumienia głosowego i wideo, nadawca otrzymuje dokładniejsze informacje zwrotne. Daje to możliwość optymalizacji sposobu nadawania w celu poprawy dźwięku oraz obrazu, • Protokół RTCP może być pomocny w procesie synchronizacji różnych strumieni, • Wykorzystuje inny port UDP, zazwyczaj o numer większym niż port RTP, • Specyfikacja definiuje 5 standardowych typów pakietów, które nie są wysyłane pojedynczo, ale wg reguły ich grupowania w pakietach zbiorczych (compound packets)


Zadania RTCP • Monitorowanie i transport zwrotnej informacji odnośnie jakości usługi dostarczanej przez RTP (QoS), • Dopasowuje częstotliwość wysyłanych pakietów kontrolnych do liczby użytkowników sesji, • Przenosi stały identyfikator transportowy źródła protokołu RTP zwany nazwą kanoniczną – CNAME (zawsze niezmienny, w przeciwieństwie do identyfikatora SSRC (ang. Synchronization Source), który może zmienić wartość w przypadku wykrycia konfliktu lub restartu systemu), • Opcjonalnie – przenosi zminimalizowaną informację kontrolną sesji – np. wyświetlanie identyfikatora użytkownika (nadawcy) na ekranie monitora odbiorcy pakietów. [2]


Jak to działa… Dzięki protokołowi RTCP 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 też przydzielenia odpowiedniej szerokości pasma. 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. [4]


Medium dla RTCP / RTP Podstawową cechą RTCP/RTP jest niezależność od technologii transportowej i używanego medium – powszechnie stosowana implementacja działa w oparciu o UDP/IP (istnieją także inne implementacje np. dla sieci ATM). Dla poprawnej transmisji RTP/RTCP potrzebne są dodatkowe urządzenia, które niwelują różnice wynikające z różnej jakości czy przepustowości łącz. Tymi urządzeniami są: - translatory RTP - miksery RTP


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 przystosowaniu ruchu do formatu, który uwzględni ograniczenia zarówno pasma transmisyjnego sieci tranzytowej, jak też stacji w jakiej znajduje się odbiorca. [4]


Miksery RTP Mikser łączy wiele źródeł w jeden strumień - łączy sygnały w spójny format. 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, tj. nie dokonują jej z każdego źródła na różne formaty. [4]


Przechowywane informacje o sesji RTCP W ramach protokołu RTCP utrzymywane są dane o zbiorze wszystkich uczestników sesji, wraz z zebranymi o nich informacjami - każdy użytkownik musi lokalnie przechowywać szereg informacji związanych z realizowaną sesją: tp – czas ostatniej transmisji tc- obecny czas tn – czas następnej transmisji pmembers – oszacowana liczba uczestników podczas ostatniej transmisji members – aktualna oszacowana liczba uczestników senders – aktualna oszacowana liczba aktywnych uczestników rtcp_bw – pasmo przydzielone dla całego ruchu RTCP wszystkich uczestników we_sent – flaga informująca czy od ostatniego raportu uczestnik wysłał dane avg_rtcp_size – średni rozmiar wysłanych i odebranych pakietów przez użytkownika initial – ustawiona na true gdy użytkownik nie wysłał jeszcze żadnego pakietu RTCP


Nagłówek RTCP

• V (Version Number) – numer wersji (zawsze 2 dla bieżącej wersji 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) [4]


RFC 3550 definiuje pięć rodzajów pakietów, które przenoszą różne informacje kontrolne:

• komunikat nadawcy - SR (Sender Report) – statystyki transmisji i odbioru danych od aktywnych uczestników • komunikat odbiorcy - RR (Receiver Report ) – statystyki odbioru dla nieaktywnych uczestników • opis źródła - SDES (Source Description) – parametry informacyjne zródła np CNAME • zarządzanie członkostwem - BYE – informuje o rozłączeniu •zdefiniowany przez aplikację - APP – informacje specyficzne dla danej aplikacji [8]


Pakiet SR – Raport Nadawcy SR składa sie z trzech sekcji obowiązkowych: - nagłówka, - informacji o nadawcy, - listy bloków raportujących - i czwartej opcjonalnej dedykowanej dla konkretnego profilu. Opcjonalna cześć jest wykorzystywana gdy profil RTP wymaga przesyłania dodatkowych informacji pomiędzy stronami sesji. [8]


Pakiet RR – Raport Odbiorcy W oparciu o pakiety RR odbiorcy informują o jakości odbieranych danych. Jeśli odbiorca jest uczestnikiem aktywnym i wysyłał dane od otrzymania ostatniego raportu, wykorzystuje pakiet SR zawierający dodatkowe informacje o nadawcy. W każdym pakiecie SR i RR znajduje sie po jednym bloku raportującym skojarzonym z jednym źródłem synchronizacji. Jeśli źródeł jest więcej niż 31 powinny zostać umieszczone w kolejnych pakietach RR.[8]


Pakiet SDES – opisujący źródło Pakiet SDES posiada trzypoziomową strukturę, w której skład wchodzi: nagłówek, zero lub więcej fragmentów zawierających atrybuty opisujące źródło (nadawcę) identyfikowane w danym fragmencie. Pola pakietu SDES: – CNAME: Canonical NAME (“user@host” lub “host”); wykorzystywane także w synchronizacji inter-media (transport-level identifier) – NAME: User name (nazwa użytkownika) – EMAIL: E-mail – PHONE: Numer telefonu – LOC: Lokalizacja geograficzna [8]


Pakiety zbiorcze (compound RTCP) • Pakiet zbiorczy jest umieszczany w jednym pakiecie warstwy niższej – zazwyczaj UDP/IP • Pakiety zbiorcze są wysyłane okresowo – okres zależy od formatu mediów i liczby uczestników sesji – dla małych sesji jest zazwyczaj rzędu 5 sek. – dla bardzo dużych grup może być rzędu minut – dla nadawców reguły są odmienne niż dla odbiorców [10]


Ilość uczestników • Częstotliwość wysyłania pakietów RTCP bazuje na znajomości oszacowanej liczby uczestników i jakości łącza. • Uczestnik określany jest jako nowy, gdy - w sesji pojawi sie ruch z nowym identyfikatorem SSRC lub CSRC, - zostanie odebrany pakiet SDES z nowym CNAME, • Uczestnika uważa sie za usuniętego gdy wysyła pakiet BYE lub przez określony czas nie wysyła pakietów. [8]


Wykorzystanie pasma przez RTCP • RTCP stara się zająć nie więcej niż 5% pasma sesji – przykład: jeden nadawca wideo 4 Mbit/s; ruch RTCP < 200 kb/s • podział pasma RTCP: - 75% pasma dla nadawców - 25% pasma dla odbiorców • uczestnik sesji (nadawca lub odbiorca) dynamicznie określa okres transmisji pakietów zbiorczych RTCP, przez obliczenie średniego rozmiaru pakietu RTCP (w całej sesji) i jego iloraz z wielkością pasma przydzielonego dla RTCP


Poufność Jeśli jest wymagana, jej zastosowanie oznacza, że tylko ustalony odbiorca(odbiorcy) mogą odkodować otrzymane pakiety, dla innych te pakiety nie niosą żadnej istotnej informacji. Poufność zawartości jest osiągana przez szyfrowanie danych. Szyfrowanie RTP i RTCP odbywa się w ten sposób, że podczas przesyłania wszystkie oktety są kapsułowane(pakowane) w pojedynczy pakiet warstwy niższej który jest szyfrowany jak jednostka. Dla RTCP, 32-bitowa losowa liczba jest przepisywana dla każdej jednostki i musi ona być dopisana na początku, przed szyfrowaniem. Implementacja RTCP definiuje możliwość rozdzielania złożonych pakietów RTCP na 2 oddzielne. Jeden będzie zaszyfrowany a drugi będzie przesłany bez zmian(bez szyfrowania). Na rysunku widać, że informacja SDES musi być dołączona do pakietu RR(bez raportów,) żeby zaspokoić wymóg, że wszystkie złożone pakiety RTCP muszą zaczynać się pakietem RR lub SR. Pole SDES CNAME jest wymagane dla zaszyfrowanego bądź nieszyfrowanego pakietu, ale nie dla obu naraz –ta sama informacja SDES, nie powinna być przenoszona w obu pakietach. W zgodzie z poprzednią specyfikacją RTP, algorytmem szyfrowania jest Data Encryption Standard(DES) w trybie CBC.


Telefonia IP – jako przykład zastosowania H.323 - zbiór protokołów takich jak: H.255 Q.931, H.255 RAS, H.235, H.245, RTCP/RTP. Służy on do tworzenia systemów komunikacyjnych na potrzeby transmisji dźwięku, wideo oraz danych z użyciem sieci pakietowych. Protokoły te pełnią funkcje związane z sygnalizacją, rejestracją, zarządzaniem sesją, negocjowaniem parametrów oraz bezpieczeństwem. I tak: H.255 Q.931(odpowiedzialny za sygnalizacje i obsługę zgłoszeń), H.255 RAS (rejestracja), H.235(bezpieczeństwo), H.245(negocjacja parametrów) oraz RTCP/RTP(transmisja danych). Protokoły te dają możliwość łączenia ze sobą sieci zbudowanych z innych protokołów. Elementy Systemu: terminale, bramy, sterowniki bram, jednostki MCU. [3]


IPTV – jako przykład zastosowania Internet Protocol Television (IPTV) jest usługą internetową, w której cyfrowy sygnał TV jest dostarczany odbiorcom poprzez Internet Protocol (IP). IPTV zapewnia niższe koszty dla operatorów, niższe ceny dla odbiorców, oraz zapewnia znacznie wydajniejszą dystrybucję niż obecnie powszechna telewizja kablowa(po kablu koncentryczny).

Próby transmitowania multimediów przez IP mają początek w latach 70. Dla tego celu obecnie został wynaleziony RTP i współtowarzyszący RTCP.


Bibliografia [1] http://www.3cx.pl/voip-sip/rtcp.php z dnia 28.12.2010 [2] http://pl.wikipedia.org/wiki/Real_Time_Control_Protocol z dnia 28.12.2010 [3] http://www.spinet.pl/~tomczak/TelefoniaIP.doc z dnia 28.12.2010 [4] http://www.politechnika.lublin.pl/dydaktyka/pliki/wyk/SM_IMUZ/SM_IMUZ_W5_lato2007.pdf z dnia 28.12.2010 [5] http://adela.utko.feec.vutbr.cz/projects/images/pdf_files/rtcp_improvements_iptv.pdf z dnia 28.12.2010 [6] http://www.ics.agh.edu.pl/dydaktyka/mm/lato0405_inf_d/laboratoria/VoD/rn.pdf z dnia 28.12.2010 [7] http://students.mimuw.edu.pl/SR/prace-mgr/hanhatviet/HaNhatViet2008-11-20.pdf z dnia 28.12.2010 [8] http://touk.pl/blog/2008/07/ z dnia 28.12.2010 [9] http://www.ietf.org/rfc/rfc3550.txt z dnia 28.12.2010 [10] http://mion.elka.pw.edu.pl/~jkopka1/cudze/ums2/wyklady/02_transport_IP.pdf z dnia 28.12.2010 [11] http://jleszczynski.swspiz.pl/Strona_1_2/WFin/Archiwum/Tizib-05/PDF/A22_Sankowski_Mos.pdf z dnia 28.12.2010 [12] http://docs7.chomikuj.pl/245729070,0,0,R08-5.DOC z dnia 28.12.2010

RTCP  

Real time control protocol by Daniel Gw

Read more
Read more
Similar to
Popular now
Just for you