Badamy silnik VoIP Mediastreamer2. Część 8

Materiał artykułu pochodzi z mojego kanału Zen.

Badamy silnik VoIP Mediastreamer2. Część 8

Struktura pakietu RTP

W poprzedniej artykuł my za pomocą TShark przeprowadziliśmy przechwytywanie pakietów RTP, którymi wymieniały się nasze urządzenia odbiorcze i nadawcze. A w tym artykule pokolorujemy elementy pakietu w różne kolory i omówimy ich przeznaczenie.

Przyjrzyjmy się temu samemu pakietowi, ale już z pokolorowanymi polami i z wyjaśniającymi podpisami:
Badamy silnik VoIP Mediastreamer2. Część 8

W dolnej części listingu pokolorowane są bajty, które tworzą pakiet RTP, a on sam jest ładunkiem użytecznym pakietu UDP (jego nagłówek jest otoczony czarną linią). Kolorowe tła oznaczają bajty nagłówka RTP, a zielonym kolorem wyróżniono blok danych, który zawiera ładunek użyteczny pakietu RTP. Dane są przedstawione w formacie szesnastkowym. W naszym przypadku jest to sygnał dźwiękowy skompresowany zgodnie z prawem u (μ-law), tzn. jeden próbka ma rozmiar 1 bajta. Ponieważ użyliśmy domyślnego częstotliwości próbkowania (8000 Hz), przy częstotliwości pakietów 50 Hz każdy pakiet RTP powinien zawierać 160 bajtów ładunku użytecznego. To właśnie zobaczymy, licząc bajty w zielonym obszarze, powinno ich być 10 linii.

Zgodnie z normą, ilość danych w ładunku użytecznym powinna być wielokrotnością czterech, czyli powinna zawierać całkowitą liczbę czterobajtowych słów. Jeśli zdarzy się, że twój ładunek użyteczny nie będzie odpowiadał tej regule, należy dodać bajty o zerowych wartościach na końcu ładunku użytecznego i ustawić bit Padding (uzupełnienie). Ten bit znajduje się w pierwszym bajcie nagłówka RTP i jest pokolorowany turkusowym kolorem. Zauważ, że wszystkie bajty ładunku użytecznego mają wartość 0xFF — tak wygląda cisza w formacie u-law.

Nagłówek pakietu RTP składa się z 12 obowiązkowych bajtów, ale w dwóch przypadkach może być dłuższy:

  • Gdy pakiet niesie sygnał dźwiękowy uzyskany przez miksowanie sygnałów z kilku źródeł (strumieni RTP), wtedy po pierwszych 12 bajtach nagłówka znajduje się tabela ze listą identyfikatorów źródeł, których ładunki użyteczne zostały wykorzystane do stworzenia ładunku tego pakietu. W tym samym czasie w czterech niższych bitach pierwszego bajtu nagłówka (pole Liczba identyfikatorów źródeł przyczynowych) wskazuje liczbę źródeł. Rozmiar pola wynosi 4 bity, w związku z czym tabela może zawierać do 15 identyfikatorów źródeł. Każdy z nich zajmuje 4 bajty. Tabela ta jest używana do organizacji konferencyjnych rozmów.

  • Gdy nagłówek ma rozszerzenie. W takim przypadku w pierwszym bajcie nagłówka ustawiany jest bit X. W rozszerzonym nagłówku, po tabeli uczestników (jeśli są), znajduje się nagłówek rozszerzenia o rozmiarze jednego słowa, a po nim słowa rozszerzenia. Rozszerzenie to zestaw bajtów, które można wykorzystać do przesyłania dodatkowych danych. Standard nie określa formatu tych danych — może być on dowolny. Na przykład mogą to być dodatkowe ustawienia dla urządzenia, które odbiera pakiety RTP. Dla niektórych zastosowań jednak opracowano standardy rozszerzonego nagłówka. Zrobiono tak na przykład dla środków łączności w standardzie ED-137 (Standardy interoperacyjności dla komponentów VoIP ATM).

Teraz przyjrzyjmy się polom nagłówka bardziej szczegółowo. Poniżej znajduje się kanoniczny obrazek ze strukturą nagłówka RTP, który również pomalowałem w te same kolory.

Badamy silnik VoIP Mediastreamer2. Część 8
VER — numer wersji protokołu (aktualna wersja to 2);

P — flaga, która jest ustawiana w przypadkach, gdy pakiet RTP jest uzupełniany pustymi bajtami na końcu;

X — flaga, że nagłówek jest rozszerzony;

CC — zawiera liczbę identyfikatorów CSRC, które następują po stałym nagłówku (po słowach 1..3), tabela na rysunku nie jest pokazana;

M — znacznik początku ramki lub obecności mowy w kanale (jeśli używany jest detektor pauzy w mowie). Jeśli odbiornik nie zawiera detektora pauzy w mowie, ten bit powinien być ustawiony permanentnie;

PTYPE — wskazuje format ładunku użytkowego;

Numer sekwencyjny — numer pakietu, używany do odbudowy porządku odtwarzania pakietów, ponieważ w rzeczywistości pakiety mogą dotrzeć do odbiornika w innym porządku niż zostały wysłane. Wartość początkowa powinna być losowa, aby w przypadku szyfrowania strumienia RTP utrudnić jego złamanie. Pole to pozwala również wykrywać zagubione pakiety;

Znacznik czasu — znacznik czasu. Czas jest mierzony w próbkach sygnału, tzn. jeśli pakiet zawiera 160 próbek, znacznik czasu następnego pakietu będzie większy o 160. Początkowa wartość znacznika czasu powinna być losowa;

SSRC — identyfikator źródła pakietu, który musi być unikalny. Lepiej go generować losowo przed uruchomieniem strumienia RTP.

Jeśli zamierzasz rozwijać swój nadajnik lub odbiornik pakietów RTP, będziesz musiał wielokrotnie analizować swoje pakiety, aby zwiększyć wydajność. Polecam opanować użycie filtracji pakietów w TShark, która pozwala na przechwytywanie tylko tych pakietów, które są dla Ciebie interesujące. W warunkach, gdy w sieci działa dziesiątki urządzeń RTP, jest to bardzo cenne. W wierszu poleceń TShark parametry filtracji określa się opcją "-f". Użyliśmy tej opcji, gdy chcieliśmy przechwycić pakiety z portu 8010:
-f "udp port 8010"
Parametry filtracji to w istocie zbiór kryteriów, które musi spełnić "przechwytywany" pakiet. Warunek może sprawdzać adres, port, wartość określonego bajtu w pakiecie. Warunki można łączyć operacjami logicznymi "AND", "OR" itp. Bardzo potężne narzędzie.

Jeśli chcesz zobaczyć dynamikę zmian pól w pakietach, musisz podwoić wyjście TShark do pliku, jak pokazano w poprzednim artykule, za pomocą przekazywania wyjścia TShark na wejście tee. Następnie otwierając plik logu za pomocą less, vim lub innego narzędzia, które może szybko pracować z ogromnymi plikami tekstowymi i wykonywać wyszukiwanie wierszy, będziesz mógł ustalić wszystkie niuanse zachowania pól pakietów w strumieniu RTP.

Jeśli będziesz potrzebował nasłuchiwać sygnał przesyłany przez strumień RTP, musisz skorzystać z wersji TShark z interfejsem graficznym Wireshark. Dzięki prostym manipulacjom myszą możesz tam wysłuchać, a także zobaczyć oscylogram sygnału. Ale pod jednym warunkiem — jeśli będzie on zakodowany w formacie u-law lub a-low.

W następnej artykuł stworzymy z Tobą duplexowe urządzenie do rozmów. Zaopatrz się w parę zestawów słuchawkowych i jednego rozmówcę.

Źródło: habr.com

Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS 🔥 Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS | ProHoster