{"id":6,"date":"2008-07-31T12:29:28","date_gmt":"2008-07-31T10:29:28","guid":{"rendered":"http:\/\/touk.pl\/blog\/?p=6"},"modified":"2023-03-16T14:26:45","modified_gmt":"2023-03-16T13:26:45","slug":"rtprtcp-realtime-transportcontrol-protocol","status":"publish","type":"post","link":"https:\/\/touk.pl\/blog\/2008\/07\/31\/rtprtcp-realtime-transportcontrol-protocol\/","title":{"rendered":"RTP\/RTCP &#8211; Realtime Transport\/Control Protocol"},"content":{"rendered":"<p>Poniewa\u017c ostatnio musia\u0142em od\u015bwie\u017cyc swoj\u0105 wiedz\u0119 na temat RTP ponizej powt\u00f3rka z przeszlosci. Poni\u017cszy post oparty jest bezpo\u015brednio na dokumencie <a href=\"http:\/\/tools.ietf.org\/html\/rfc3550\">IETF RFC 3550<\/a> specyfikujacym bazowy protokol RTP.<\/p>\n<p>RTP\/RTCP s\u0105 to protok\u00f3\u0142y przeznaczone do transmisji end2end sygna\u0142\u00f3w cyfrowych o charakterystyce \u2018realtime\u2019, takich jak dzwi\u0119k czy video. Zosta\u0142 zaprojektowany w celu oddzielenia mechanizm\u00f3w transmiscji danych i kontroli sesji. Z ka\u017cdym strumieniem danych skojarzony jest oddzielny kana\u0142 RTP\/RTCP zawierajaca po jednym porcie RTP i RTCP. RTP jest protoko\u0142em odpowiedzialnym za transmisje strumieni danych tak zwanych \u2018RTP payload\u2019. RTP samo w sobie nie zapewnia mechanizm\u00f3w kontorli opo\u017anie\u0144 czy stratno\u015bci ale bazuje na wykorzystywanym protokole transportowym ktorym najcze\u015bciej jest to UDP. RTCP skolei jest odpowiedzialne za kontrole jako\u015bci swiadczonych uslug poprzez RTP (informowanie o ilosci gubionych pakietow, opoznieniach czy parametrach wykorzystywanych kodekow adaptacyjnych). Opcjonalnie dostarcza mo\u017cliwo\u015b\u0107 kontroli uczestnikow sesji, ale to najcze\u015bciej jest realizowane przez skojarzony z RTP protok\u00f3\u0142 sygnalizacyjny tak jak np SIP.<\/p>\n<h2 id=\"rtp\">RTP<\/h2>\n<h3 id=\"struktura-pakietu\">Struktura pakietu<\/h3>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"generic\">0                   1                   2                   3\r\n0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n|V=2|P|X|  CC   |M|     PT      |       sequence number         |\r\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n|                           timestamp                           |\r\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n|           synchronization source (SSRC) identifier            |\r\n+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+\r\n|            contributing source (CSRC) identifiers             |\r\n|                             ....                              |\r\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<\/pre>\n<p>Pierwsze 12 oktetow wystepuje zawsze, opcjonalne pola CSRC wystepuja gdy na drodze danych jest mixer.<\/p>\n<ul>\n<li>version (V): 2 bity \u2013 wersja obecnie 2<\/li>\n<li>padding (P): 1 bit \u2013 wskazuje czy koniec pakietu jest uzupelniony zerami, jesli tak ostatni oktet wskazuje na liczbe oktetow do pominiecia<\/li>\n<li>extension (X): 1 bit \u2013 wskazuje ze do pakietu dolaczony jest naglowek z rozszerzeniem<\/li>\n<li>CSRC count (CC): 4 bity \u2013 wskazuje na liczbe identyfikatorw CSRC na koncu naglowka<\/li>\n<li>marker (M): 1 bit \u2013 umozliwia wskazanie ze jest znaczacy pakiet, wykorzystywane przez profile RTP<\/li>\n<li>payload type (PT): 7 bit\u00f3w \u2013 okre\u015bla format danych<\/li>\n<li>sequence number: 16 bit\u00f3w \u2013 numer sekwencyjny pakietu RTP, zwiekszany o jeden za ka\u017cdym razem<\/li>\n<li>timestamp: 32 bity \u2013 wartosc bezwgledna informujace o przedziale pomiedzy przesylanymi probkami danych<\/li>\n<li>SSRC: 32 bity \u2013 identyfikuje zrodlo synchronizacji<\/li>\n<li>CSRC list: od 0 tdo 15 , 32 bity ka\u017cde \u2013 listaidentyfikatorow CSRC ktorych dane sa mixowane<\/li>\n<\/ul>\n<h2 id=\"rtcp\">RTCP<\/h2>\n<div>Zasada dzialanie RTCP polega na cyklicznej wymianie wiadomosci kontrolnych w oparciu o te same mechanizmy dystrubucji co RTP np. uzywajac innego portu udp. RTCP realizuje 4 podstawowe funkcje:<\/div>\n<ul>\n<li>informowanie o jakosci dystrybucji danych oraz mozliwosciach adaptacji na poziomie kodowania<\/li>\n<li>przenosi parametr CNAME odpowiedzialny za persystentna identyfikacje sesji RTP<\/li>\n<li>ustala czestotliowsc wymiany pakietow w zaleznosci od liczby uczestnikow<\/li>\n<li>opcjonalnie pozawala przenosic minimalna ilosc informacji identyfikujaca strony<\/li>\n<\/ul>\n<h3 id=\"struktura-pakietu-2\">Struktura pakietu<\/h3>\n<p>RFC 3550 definiuje pie\u0107 rodzaj\u00f3w pakiet\u00f3w, kt\u00f3re przenosz\u0105 r\u00f3\u017cne informacje kontrolne<\/p>\n<ul>\n<li>SR (Sender Report) \u2013 statystyki transmisji i odbioru danych od aktywnych uczestnikow<\/li>\n<li>RR (Receiver Report ) \u2013 statystyki odbioru dla nieaktywnych uczestnikow<\/li>\n<li>SDES (Source Description) \u2013 parametry informacyjne zr\u00f3d\u0142a np CNAME<\/li>\n<li>BYE \u2013 informuje o razlaczeniu<\/li>\n<li>APP \u2013 informacje specyficzne dla danej aplikacji<\/li>\n<\/ul>\n<div>Kazdy pakiet RTCP sk\u0142ada sie ze sta\u0142ej cz\u0119\u015bci oraz nast\u0119puj\u0105cej po niej czesci o zmiennej d\u0142ugosci, w zale\u017cno\u015bci od typu pakietu wyr\u00f3wanej do 32 bit\u00f3w. Kilka pakiet\u00f3w mo\u017ce by\u0107 szeregowo \u0142\u0105czonych tworz\u0105c tak zwany z\u0142o\u017cony pakiet RTP, umieszczany w pakiecie warstwy ni\u017cszej. Nie ma \u017cadnego konkretnego wymogu na wielkosc pakietu z\u0142o\u017conego, gdy\u017c jest ona kontrolowana przez protok\u00f3\u0142 transportowy. Ka\u017cdy pakiet wchodz\u0105cy w sk\u0142ad pakietu z\u0142o\u017conego jest analizowany niezale\u017cnie od innych, stad kolejno\u015b\u0107 i kombinacja pakiet\u00f3w nie s\u0105 istotne. Tym niemniej aby spe\u0142ni\u0107 wymaganie realizowane przez protok\u00f3\u0142 na struktur\u0119 pakietu z\u0142o\u017conego zosta\u0142y na\u0142o\u017cone nast\u0119puj\u0105ce ograniczenia:<\/div>\n<ul>\n<li>\n<div>SR lub RR musza byc wysylane w kazdym pakiecie zlozonym, tak aby statystyki odbioru byly jak najbardziej dokladne<\/div>\n<\/li>\n<li>\n<div>SDES z parametrem CNAME musi by\u0107 wysylany w kazym pakieci zlozonym, tak aby odbiorca jak najszyciej otrzymal informacje o nadawcy<\/div>\n<\/li>\n<li>\n<div>liczba pakiet\u00f3w wyslana w pierwszym pakiecie zlozonym powinna byc jak najmniejsza (2) tak aby liczba stalych bit\u00f3w byla jak najwieksza i prawdopodobienstwo walidacji pakietu najwieksze<\/div>\n<\/li>\n<\/ul>\n<p>Stad tez struktura pakietu zlozonego musi zawierac conajmniej dwa pakiety o nastepujacej formie:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"generic\">random encryption prefix: losowy 32-bitowy integer\r\n|\r\n|[--------- packet --------][---------- packet ----------][-packet-]\r\n|\r\n|                receiver            chunk        chunk\r\nV                reports           item  item   item  item\r\n--------------------------------------------------------------------\r\nR[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why]\r\n--------------------------------------------------------------------\r\n|                                                                  |\r\n|<-----------------------  compound packet ----------------------->|\r\n|<--------------------------  UDP packet ------------------------->|\r\n\r\n#: SSRC\/CSRC identifier<\/pre>\n<ul>\n<li>\n<div>Encryption prefix \u2013 jesli pakiet zlozony jest szyforowany jest poprzedzany 32 bitow\u0105 warto\u015bcia calkowita<\/div>\n<\/li>\n<li>\n<div>SR lub RR \u2013 zawsze pierwszy pakiet w pakiecie zlozonym to SR lub RR nawet jesli zadne dane nie byly jeszcze wyslane<\/div>\n<\/li>\n<li>\n<div>Dodatkowe RR \u2013 jesli liczba zrodel dla ktorych generowane sa statystyki przewyzsza 31 i nie moga byc umieszczone w jednym RR lub SS sa one umieszczane w dodatkowych pakietach RR<\/div>\n<\/li>\n<li>\n<div>SDES \u2013 w kazdym pakiecie zlozonym musi byc dolaczony pakiet zawierajacy parametr CNAME inne parametry sa umieszczane w zalezno\u015bci od aplikacji<\/div>\n<\/li>\n<li>\n<div>BYE lub APP \u2013 pozostale pakiety moga sie pojawiac w dowolnej ilosci i kolejnosci z tym wyjatkiem ze pakiet BYE zawierajacy SSRC\/CSRC musi byc ostatni<\/div>\n<\/li>\n<\/ul>\n<div>Kazdy uczestnik powinnien wysylac tylko jeden pakiet zlozony w trakcie okresu raportowania aby oszacowanie pasma bylo precyzyjniejsze. Jesli ilosc dodatkowych pakietow RR nie miesci sie w MTU nalezy ograniczyc ich ilosc i przeslac w nastepnej turze, tak by wszystkie zrodla byly raportowane.<\/div>\n<h3 id=\"czestotliwosci-rtcp\">Czestotliwosci RTCP<\/h3>\n<div>RTP zostalo tak zaprojektowane aby umozliwiac regulowanie ruchu kontrolnego w zaleznosci o ilosci uczestnikow i przyjetej charakterystyki lacza. Z kazda sesja danych RTP zwiazane jest maksymalne dopuszczalne pasmo sesji (session bandwidth) bedace agregacja danych poszczegolnych uczestnikow. Mechanizm doboru pasma sesji moze byc praktycznie dowolny ale najczesniej przyjmuje sie jego wartosc jako nominalna sume pasm zajmowanych przez maksymalna liczbe jednoczesnie aktywnych uczestnikow. Wartosc pasma sesji najczesciej ustalana jest przez warstwe aplikacji odpowiedzialna za zarzadzanie sesja przy czym najczesciej wartosc domyslna ustalana jest jako pasmo odpowiadajace jednemu aktywnemu uzytkownikowi. Wszyscy uczestnicy sesji musza uzywac tego samego pasma tak aby okres retransmisji RTCP byl taki sam. Warto pamietac ze w trakcie obliczania utylizacji dostepnego pasma brane sa pod uwage tez protokoly transportowe (UDP i IP) ale warstwa lacza danych juz nie gdyz te sie od siebie r\u00f3\u017cnia. Ruch kontrolny jest ograniczany zar\u00f3wno z g\u00f3ry jak i z do\u0142u. Z g\u00f3ry jako czastkowa warto\u015b\u0107 calkowitego dostepnego pasma (norma 5%) lub jako warto\u015b\u0107 ilo\u015bciowa. Z dolu natomiast ustala sie minimalna warto\u015b\u0107 tak aby nie generowa\u0107 nadmiernego ruchu (norma 5s), istnieja przypadki kiedy ta wartosc moze byc jeszcze bardziej zredukowana i odwrotnie proporcjonalna do dostepnego pasma. Zaleca sie rowniez aby z posrod calego ruchu RTCP, 1\/4 byla przypisana do aktywnych uczestnikow, tak aby nowo dolaczajacy sie uzytkownicy szybko dowiadywali sie aktywnych CNAME. Algorytm oblicza czestotliowsci wysylania pakiet\u00f3w zlozonych tak aby dost\u0119pne pasmo na ruch kontrolny by\u0142o r\u00f3wnie rozdzielone pomiedzy uczestnik\u00f3w. Wyznaczona czestotliwosc skaluje sie liniowe w stosunku do liczby uczestnik\u00f3w, co zapewnia sta\u0142a warto\u015b\u0107 ruchu kontrolnego. Aby unikn\u0105c pelnej synchronizacji kazdy z uczestnikow posluguje sie lekka wariacja okresu wysylania RTCP oraz losowym opoznienieniem dla pierwszego wysylanego pakietu zlozonego. Dodatkowo obslugiwane sa mechanizmy obslugujace sytuacje wyjatkowe kiedy wielu uczestnikow jednoczesnie dolacza lub opuszcza sesje.<\/div>\n<h3 id=\"ilosc-uczestnikow\">Ilosc Uczestnikow<\/h3>\n<div>Wyznaczanie czestotliwosci RTCP bazuje na znajomosci oszacowanej liczby uczestnikow. Uczestnik okreslany jest jako nowy gdy w sesji pojawi sie ruch z nowym identyfikatorem SSRC lub CSRC. Istnieje mo\u017cliwosc przyjecia ze musi byc zarejstrowanych kilka pakietow by uznac ze pojawil sie nowy uczestnik lub ze musi zostac odebrany pakiet SDES z nowym CNAME. Uczestnika uwaza sie za usunietego gdy wysyla pakiet BYE lub przez okreslony czas nie wysyla pakietow.<\/div>\n<h3 id=\"zasady-wysylania-i-odbierania-pakietow-rtcp\">Zasady Wysylania i Odbierania pakietow RTCP<\/h3>\n<p>Aby zrealizowac powyzsze zalozenia kazdy uzytkownik musi lokalnie przechowywac szereg informacji zwiazanych z realizowana sesja:<\/p>\n<ul>\n<li>tp \u2013 czas ostatniej transmisji<\/li>\n<li>tc- obecny czas<\/li>\n<li>tn \u2013 czas nastepnej transmisji<\/li>\n<li>pmembers \u2013 oszacowana liczba uczestnikow podczas podczas ostatniej transmisji<\/li>\n<li>members \u2013 aktualna oszacowana liczba uczestnikow<\/li>\n<li>senders \u2013 aktualna oszacowana liczba aktywnych uczestnikow<\/li>\n<li>rtcp_bw \u2013 pasmo przydzielone dla calego ruchu RTCP wszystkich uczestnikow<\/li>\n<li>we_sent \u2013 flaga informujaca czy od ostatniego raportu uczestnik wyslal dane<\/li>\n<li>avg_rtcp_size \u2013 sredni rozmiar wyslanych i odebranych pakietow przez uzytkownika<\/li>\n<li>initial \u2013 ustawiona na true gdy uzytkownik nie wyslal jeszcze zadnego pakietu RTCP<\/li>\n<\/ul>\n<div>W trakcie inicjalizacji aplikacji parametry ustawiane sa na wartosci domyslne. Wartosc okresu nadawania wiadomosci kontrolnych jest obliczana na podstawie powyzej wymienionych parameterow. Procedura w efekcie daje przedzial ktory jest losowy i przydziela minimum 1\/4 calego dostepnego pasma uzytkownikom aktywnym. Jesli uzytkonik\u00f3w aktywnych jest wiecej ni\u017c 1\/4 wszystkich uzytkownikow dostepne pasmo jest dytrybuowane po rowno do wszystkich uczestnik\u00f3w. Po otrzymaniu pakietu RTP lub RTCP od uczesnika, ktorego SSRC nie jest obecne w tablicy uczestnik\u00f3w, jest on dodawany do listy i liczba uczestnikow jest aktualizowana. Kiedy pakiet RTP jest od uczestnika ktory nie znajduje sie na liscie aktywnych uczestnikow jest on do niej dodawany i ich liczba jest aktualizowana. Jak zawsze przy kazdym odebranym i wyslanym pakiecie wartosc avg_rtcp_size jest aktualizowana. Gdy uczestnik odbiera pakiet BYE sprawdza czy na liscie uczestnik\u00f3w lub aktywnych uczestnik\u00f3w znajduje nadawca pakietu, jesli tak, jest on z niej usuwany, aktualizowane sa parametry oraz czas wyslania nastepnego zlozonego pakietu RTCP. Przynajmniej raz na jeden okres przesylania pakietu kontrolnego uczestnik weryfikuje czy na kt\u00f3rej\u015b z list nie nastapil timeout dla danego SSRC. Kiedy uczestnik chce opuscic sesje moze ale nie musi wyslac pakiet BYE, jesli tego nie zrobi nastapi timeout. Jesli liczba uzytkownikow jest mala (zalecane 50) moze wyslac pakiet od razu, w przeciwnym wypadku stosuje mechanizm zapobiegajacy masowemu opuszczaniu sesji przez duza liczbe uczestnikow.<\/div>\n<h3 id=\"pakiety-sr-i-rr\">Pakiety SR i RR<\/h3>\n<div>W oparciu o pakiety RR odbiorcy informuja o jakosci odbieranych danych, je\u015bli odbiorca jest uczestnikiem aktywnym i wysy\u0142a\u0142 dane od ostatniego raportu wykorzystuje pakiet SR zawierajacy dodatkowe informacje o nadawcy. W kazdym pakiecie SR i RR znajduje sie po jednym bloku raportujacym skojarzonym z jednym \u017ar\u00f3d\u0142em synchronizacji. Je\u015bli zr\u00f3de\u0142 jest wiecej ni\u017c 31 powinny zosta\u0107 umieszczone w kolejnych pakietach RR.<br \/>\nSR sk\u0142ada sie z trzech sekcji obowiazkowych: nag\u0142\u00f3wka, informacji o nadawcy, listy blok\u00f3w raportujacych i czwartej opcjonalnej dedykowanej dla konkretnego profilu. opcjonalna cze\u015b\u0107 jest wykorzystywana gdy profil RTP wymaga przesylania dodatkowych informacji pomiedzy stronami.<\/div>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"generic\">        0                   1                   2                   3\r\n        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\nheader |V=2|P|    RC   |   PT=SR=200   |             length            |\r\n       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n       |                         SSRC of sender                        |\r\n       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+\r\nsender |              NTP timestamp, most significant word             |\r\ninfo   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n       |             NTP timestamp, least significant word             |\r\n       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n       |                         RTP timestamp                         |\r\n       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n       |                     sender's packet count                     |\r\n       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n       |                      sender's octet count                     |\r\n       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+\r\nreport |                 SSRC_1 (SSRC of first source)                 |\r\nblock  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n  1    | fraction lost |       cumulative number of packets lost       |\r\n       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n       |           extended highest sequence number received           |\r\n       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n       |                      interarrival jitter                      |\r\n       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n       |                         last SR (LSR)                         |\r\n       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n       |                   delay since last SR (DLSR)                  |\r\n       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+\r\nreport |                 SSRC_2 (SSRC of second source)                |\r\nblock  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n  2    :                               ...                             :\r\n       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+\r\n       |                  profile-specific extensions                  |\r\n       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<\/pre>\n<ul>\n<li>wersja (V): 2 bity \u2013 identyfikuje wersje, tak samo jak RTP 2<\/li>\n<li>padding (P): 1 bit \u2013 wskazuje czy koniec pakietu jest uzupelniony zerami, jesli tak ostatni oktet wskazuje na liczbe oktetow do pominiecia<\/li>\n<li>reception report count (RC): 5 bit\u00f3w \u2013 liczba blokow raportujacych w tym pakiecie<\/li>\n<li>packet type (PT): 8 bit\u00f3w \u2013 indentyfikuej pakiet RTCP SR (stala wartosc 200)<\/li>\n<li>length: 16 bit\u00f3w \u2013 dlugosc pakietu w 32 bitowych s\u0142owach w\u0142aczaj\u0105c nag\u0142\u00f3wek i wyr\u00f3wnanie<\/li>\n<li>SSRC: 32 bity \u2013 identyfikator SSRC zr\u00f3dla pakietu SR<\/li>\n<li>NTP timestamp: 64 bity \u2013 zegarowy czas wyslania pakietu<\/li>\n<li>RTP timestamp: 32 bity \u2013 okresowy czas wyslania pakietu<\/li>\n<li>sender\u2019s packet count: 32 bity \u2013 calkowita liczba pakietow RTP wyslanych przez uczest<\/li>\n<li>SSRC_n (source identifier): 32 bity \u2013 identyfikator SSRC dla zrodla ktorego dotyczy raport<\/li>\n<li>fraction lost: 8 bit\u00f3w \u2013 stosunek pakietow odebranych do pakietow spodziewanych RTP<\/li>\n<li>cumulative number of packets lost: 24 bity \u2013 calkowita liczba wszystkich zg\u00f3bionych pakiet\u00f3w RTP<\/li>\n<li>xtended highest sequence number received: 32 bity \u2013 najwieszky numer sekwencyjny odebranego pakietu<\/li>\n<li>interarrival jitter: 32 bity \u2013 roznica pomiedzy odstepem w wysylaniu kolejnych pakietow<\/li>\n<li>last SR timestamp (LSR): 32 bity \u2013 srodkowe 32 bity otrzymane w SR od nadawcy<\/li>\n<li>delay since last SR (DLSR): 32 bity \u2013 czas pomiedzy odbiorem pakietu SR od nadawcy a nadaniem tego bloku raportujacego<\/li>\n<\/ul>\n<div>Struktura pakietu RR jest taka sama jak pakietu SR, z t\u0105 r\u00f3\u017cnic\u0105 \u017ce pakiet RR nie zawiera czesci informacyjnej o nadawcy a pole typu pakietu zawiera wartosc 201:<\/div>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"generic\">        0                   1                   2                   3\r\n        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\nheader |V=2|P|    RC   |   PT=RR=201   |             length            |\r\n       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n       |                     SSRC of packet sender                     |\r\n       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+\r\nreport |                 SSRC_1 (SSRC of first source)                 |\r\nblock  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n  1    | fraction lost |       cumulative number of packets lost       |\r\n       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n       |           extended highest sequence number received           |\r\n       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n       |                      interarrival jitter                      |\r\n       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n       |                         last SR (LSR)                         |\r\n       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n       |                   delay since last SR (DLSR)                  |\r\n       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+\r\nreport |                 SSRC_2 (SSRC of second source)                |\r\nblock  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n  2    :                               ...                             :\r\n       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+\r\n       |                  profile-specific extensions                  |\r\n       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<\/pre>\n<div>Po otrzymaniu raportu w postaci pakietu SR lub RR nadawca moze zmodyfikowa\u0107 na jego podstawie charakterysytke sesji, okre\u015bli\u0107 zakres wystepuj\u0105cych problem\u00f3w, okre\u015bli\u0107 skutecznosc w dostarczaniu raportow itp. Dane raportujace moga byc rowniez agregowane przez aplikacje monitorujace nadzorujace wydajnosc sieci.<\/div>\n<h3 id=\"pakiety-sdes\">Pakiety SDES<\/h3>\n<div>Pakiet SDES posiada trzy poziomow\u0105 strukture, w kt\u00f3rej sk\u0142ad wchodzi nag\u0142\u00f3wek, zero lub wiecej fragment\u00f3w zawieraj\u0105cych atrybuty opisuj\u0105ce zr\u00f3d\u0142o identyfikowane w danym fragmencie. Ka\u017cdy fragment zawiera indentyfikator SSRC\/CSRC oraz list\u0119 atryb\u00f3t\u00f3w. Ka\u017cdy atrybut zawiera 2 8-\u015bmio bitowe pola wskazujace na jego typ oraz dlugo\u015b\u0107 oraz sam tekst, gdzie tekst nie mo\u017ce by\u0107 d\u0142u\u017cszy ni\u017c 255 oktet\u00f3w<\/div>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"generic\">        0                   1                   2                   3\r\n        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\r\n       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\nheader |V=2|P|    SC   |  PT=SDES=202  |             length            |\r\n       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+\r\nchunk  |                          SSRC\/CSRC_1                          |\r\n  1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n       |                           SDES items                          |\r\n       |                              ...                              |\r\n       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+\r\nchunk  |                          SSRC\/CSRC_2                          |\r\n  2    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n       |                           SDES items                          |\r\n       |                              ...                              |\r\n       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+<\/pre>\n<ul>\n<li>version (V) \u2013 wersja, padding (P) \u2013 dope\u0142nienie, length \u2013 dlugo\u015b\u0107<\/li>\n<li>packet type (PT): 8 bit\u00f3w \u2013 typ pakietu (202)<\/li>\n<li>source count (SC): 5 bit\u00f3w \u2013 liczba fragment\u00f3w w pakiecie<\/li>\n<\/ul>\n<p style=\"text-align: right\">autor: Tomasz Zieleniewski<\/p>\n","protected":false},"excerpt":{"rendered":"Poniewa\u017c ostatnio musia\u0142em od\u015bwie\u017cyc swoj\u0105 wiedz\u0119 na temat RTP ponizej powt\u00f3rka z przeszlosci. Poni\u017cszy post oparty jest bezpo\u015brednio&hellip;\n","protected":false},"author":7,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[],"class_list":["post-6","post","type-post","status-publish","format-standard","category-development-design"],"_links":{"self":[{"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/posts\/6","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/comments?post=6"}],"version-history":[{"count":11,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/posts\/6\/revisions"}],"predecessor-version":[{"id":15284,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/posts\/6\/revisions\/15284"}],"wp:attachment":[{"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/media?parent=6"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/categories?post=6"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/touk.pl\/blog\/wp-json\/wp\/v2\/tags?post=6"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}