{"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 – Realtime Transport\/Control Protocol"},"content":{"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 na dokumencie IETF RFC 3550<\/a> specyfikujacym bazowy protokol RTP.<\/p>\n

RTP\/RTCP s\u0105 to protok\u00f3\u0142y przeznaczone do transmisji end2end sygna\u0142\u00f3w cyfrowych o charakterystyce ‘realtime’, 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 ‘RTP payload’. 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

RTP<\/h2>\n

Struktura pakietu<\/h3>\n
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
Pierwsze 12 oktetow wystepuje zawsze, opcjonalne pola CSRC wystepuja gdy na drodze danych jest mixer.<\/p>\n
    \n
  • version (V): 2 bity – wersja obecnie 2<\/li>\n
  • padding (P): 1 bit – wskazuje czy koniec pakietu jest uzupelniony zerami, jesli tak ostatni oktet wskazuje na liczbe oktetow do pominiecia<\/li>\n
  • extension (X): 1 bit – wskazuje ze do pakietu dolaczony jest naglowek z rozszerzeniem<\/li>\n
  • CSRC count (CC): 4 bity – wskazuje na liczbe identyfikatorw CSRC na koncu naglowka<\/li>\n
  • marker (M): 1 bit – umozliwia wskazanie ze jest znaczacy pakiet, wykorzystywane przez profile RTP<\/li>\n
  • payload type (PT): 7 bit\u00f3w – okre\u015bla format danych<\/li>\n
  • sequence number: 16 bit\u00f3w – numer sekwencyjny pakietu RTP, zwiekszany o jeden za ka\u017cdym razem<\/li>\n
  • timestamp: 32 bity – wartosc bezwgledna informujace o przedziale pomiedzy przesylanymi probkami danych<\/li>\n
  • SSRC: 32 bity – identyfikuje zrodlo synchronizacji<\/li>\n
  • CSRC list: od 0 tdo 15 , 32 bity ka\u017cde – listaidentyfikatorow CSRC ktorych dane sa mixowane<\/li>\n<\/ul>\n
    RTCP<\/h2>\n
    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
      \n
    • informowanie o jakosci dystrybucji danych oraz mozliwosciach adaptacji na poziomie kodowania<\/li>\n
    • przenosi parametr CNAME odpowiedzialny za persystentna identyfikacje sesji RTP<\/li>\n
    • ustala czestotliowsc wymiany pakietow w zaleznosci od liczby uczestnikow<\/li>\n
    • opcjonalnie pozawala przenosic minimalna ilosc informacji identyfikujaca strony<\/li>\n<\/ul>\n
      Struktura pakietu<\/h3>\n
      RFC 3550 definiuje pie\u0107 rodzaj\u00f3w pakiet\u00f3w, kt\u00f3re przenosz\u0105 r\u00f3\u017cne informacje kontrolne<\/p>\n
        \n
      • SR (Sender Report) – statystyki transmisji i odbioru danych od aktywnych uczestnikow<\/li>\n
      • RR (Receiver Report ) – statystyki odbioru dla nieaktywnych uczestnikow<\/li>\n
      • SDES (Source Description) – parametry informacyjne zr\u00f3d\u0142a np CNAME<\/li>\n
      • BYE – informuje o razlaczeniu<\/li>\n
      • APP – informacje specyficzne dla danej aplikacji<\/li>\n<\/ul>\n
        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
          \n
        • \n
          SR lub RR musza byc wysylane w kazdym pakiecie zlozonym, tak aby statystyki odbioru byly jak najbardziej dokladne<\/div>\n<\/li>\n
        • \n
          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
        • \n
          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
          Stad tez struktura pakietu zlozonego musi zawierac conajmniej dwa pakiety o nastepujacej formie:<\/p>\n
          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
            \n
          • \n
            Encryption prefix – jesli pakiet zlozony jest szyforowany jest poprzedzany 32 bitow\u0105 warto\u015bcia calkowita<\/div>\n<\/li>\n
          • \n
            SR lub RR – zawsze pierwszy pakiet w pakiecie zlozonym to SR lub RR nawet jesli zadne dane nie byly jeszcze wyslane<\/div>\n<\/li>\n
          • \n
            Dodatkowe RR – 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
          • \n
            SDES – w kazdym pakiecie zlozonym musi byc dolaczony pakiet zawierajacy parametr CNAME inne parametry sa umieszczane w zalezno\u015bci od aplikacji<\/div>\n<\/li>\n
          • \n
            BYE lub APP – 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
            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
            Czestotliwosci RTCP<\/h3>\n
            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
            Ilosc Uczestnikow<\/h3>\n
            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
            Zasady Wysylania i Odbierania pakietow RTCP<\/h3>\n
            Aby zrealizowac powyzsze zalozenia kazdy uzytkownik musi lokalnie przechowywac szereg informacji zwiazanych z realizowana sesja:<\/p>\n
              \n
            • tp – czas ostatniej transmisji<\/li>\n
            • tc- obecny czas<\/li>\n
            • tn – czas nastepnej transmisji<\/li>\n
            • pmembers – oszacowana liczba uczestnikow podczas podczas ostatniej transmisji<\/li>\n
            • members – aktualna oszacowana liczba uczestnikow<\/li>\n
            • senders – aktualna oszacowana liczba aktywnych uczestnikow<\/li>\n
            • rtcp_bw – pasmo przydzielone dla calego ruchu RTCP wszystkich uczestnikow<\/li>\n
            • we_sent – flaga informujaca czy od ostatniego raportu uczestnik wyslal dane<\/li>\n
            • avg_rtcp_size – sredni rozmiar wyslanych i odebranych pakietow przez uzytkownika<\/li>\n
            • initial – ustawiona na true gdy uzytkownik nie wyslal jeszcze zadnego pakietu RTCP<\/li>\n<\/ul>\n
              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
              Pakiety SR i RR<\/h3>\n
              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.
              \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
                      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
                \n
              • wersja (V): 2 bity – identyfikuje wersje, tak samo jak RTP 2<\/li>\n
              • padding (P): 1 bit – wskazuje czy koniec pakietu jest uzupelniony zerami, jesli tak ostatni oktet wskazuje na liczbe oktetow do pominiecia<\/li>\n
              • reception report count (RC): 5 bit\u00f3w – liczba blokow raportujacych w tym pakiecie<\/li>\n
              • packet type (PT): 8 bit\u00f3w – indentyfikuej pakiet RTCP SR (stala wartosc 200)<\/li>\n
              • length: 16 bit\u00f3w – dlugosc pakietu w 32 bitowych s\u0142owach w\u0142aczaj\u0105c nag\u0142\u00f3wek i wyr\u00f3wnanie<\/li>\n
              • SSRC: 32 bity – identyfikator SSRC zr\u00f3dla pakietu SR<\/li>\n
              • NTP timestamp: 64 bity – zegarowy czas wyslania pakietu<\/li>\n
              • RTP timestamp: 32 bity – okresowy czas wyslania pakietu<\/li>\n
              • sender’s packet count: 32 bity – calkowita liczba pakietow RTP wyslanych przez uczest<\/li>\n
              • SSRC_n (source identifier): 32 bity – identyfikator SSRC dla zrodla ktorego dotyczy raport<\/li>\n
              • fraction lost: 8 bit\u00f3w – stosunek pakietow odebranych do pakietow spodziewanych RTP<\/li>\n
              • cumulative number of packets lost: 24 bity – calkowita liczba wszystkich zg\u00f3bionych pakiet\u00f3w RTP<\/li>\n
              • xtended highest sequence number received: 32 bity – najwieszky numer sekwencyjny odebranego pakietu<\/li>\n
              • interarrival jitter: 32 bity – roznica pomiedzy odstepem w wysylaniu kolejnych pakietow<\/li>\n
              • last SR timestamp (LSR): 32 bity – srodkowe 32 bity otrzymane w SR od nadawcy<\/li>\n
              • delay since last SR (DLSR): 32 bity – czas pomiedzy odbiorem pakietu SR od nadawcy a nadaniem tego bloku raportujacego<\/li>\n<\/ul>\n
                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
                        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
                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
                Pakiety SDES<\/h3>\n
                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
                        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
                  \n
                • version (V) – wersja, padding (P) – dope\u0142nienie, length – dlugo\u015b\u0107<\/li>\n
                • packet type (PT): 8 bit\u00f3w – typ pakietu (202)<\/li>\n
                • source count (SC): 5 bit\u00f3w – liczba fragment\u00f3w w pakiecie<\/li>\n<\/ul>\n
                  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…\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":{"0":"post-6","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"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}]}}