Der Inhalt dieses Artikels stammt von meinem .
Struktur des RTP-Pakets
Im letzten haben wir mithilfe von TShark die RTP-Pakete erfasst, die zwischen unserem Empfänger und Sender ausgetauscht wurden. In diesem Abschnitt färben wir die Elemente des Pakets in verschiedene Farben und sprechen über deren Zweck.
Schauen wir uns dasselbe Paket an, aber jetzt mit eingefärbten Feldern und erläuternden Beschriftungen:
Im unteren Bereich der Auflistung sind die Bytes hervorgehoben, die das RTP-Paket bilden, welches wiederum die Nutzlast des UDP-Pakets darstellt (der Header ist mit einer schwarzen Linie umrandet). Die farbigen Hintergründe kennzeichnen die Bytes des RTP-Headers, während der grüne Bereich den Datenblock hervorhebt, der die Nutzlast des RTP-Pakets enthält. Die Daten sind im Hexadezimalformat dargestellt. In unserem Fall handelt es sich um ein komprimiertes Audiosignal gemäß dem u-Gesetz (Mü-Gesetz), d.h. ein Sample hat eine Größe von 1 Byte. Da wir die standardmäßige Abtastrate von 8000 Hz verwendet haben, sollte jedes RTP-Paket bei einer Paketfrequenz von 50 Hz 160 Bytes Nutzlast enthalten. Das werden wir sehen, wenn wir die Bytes im grünen Bereich zählen; es sollten 10 Zeilen sein.
Nach den Standards muss die Größe der Nutzdaten ein Vielfaches von vier sein, oder anders ausgedrückt, sie muss eine ganze Anzahl an vier-Byte-Wörtern enthalten. Sollte es vorkommen, dass Ihre Nutzdaten dieser Regel nicht entsprechen, müssen Sie Nullen am Ende der Nutzdaten hinzufügen und das Padding-Bit setzen. Dieses Bit befindet sich im ersten Byte des RTP-Headers, das türkisfarben ist. Beachten Sie, dass alle Bytes der Nutzdaten den Wert 0xFF haben – so sieht Stille im u-law-Format aus.
Der RTP-Paketheader besteht aus 12 obligatorischen Bytes, kann jedoch in zwei Fällen länger sein:
Wenn das Paket ein Audiosignal trägt, das aus der Mischung von Signalen mehrere Quellen (RTP-Streams) stammt, folgt auf die ersten 12 Bytes des Headers eine Tabelle mit einer Liste der Quellidentifikatoren, deren Nutzdaten zur Erstellung der Nutzdaten dieses Pakets verwendet wurden. Dabei stehen in den unteren vier Bits des ersten Bytes des Headers (Feld Anzahl der beitragenden Quellidentifikatoren) die Anzahl der Quellen an. Die Feldgröße beträgt 4 Bit, entsprechend kann die Tabelle bis zu 15 Quellidentifikatoren enthalten. Jeder davon belegt 4 Byte. Diese Tabelle wird zur Organisation von Konferenzverbindungen genutzt.
Wenn der Header eine Erweiterung hat. In diesem Fall wird im ersten Byte des Headers ein Bit gesetzt X. Im erweiterten Header, nach der Teilnehmerliste (sofern vorhanden), befindet sich der Erweiterungsheader mit einer Größe von einem Wort, gefolgt von Erweiterungswörtern. Eine Erweiterung ist eine Reihe von Bytes, die Sie verwenden können, um zusätzliche Daten zu übertragen. Der Standard legt das Format dieser Daten nicht fest – es kann beliebig sein. Zum Beispiel könnten dies zusätzliche Einstellungen für ein Gerät sein, das RTP-Pakete empfängt. Für bestimmte Anwendungen wurden jedoch Standards für den erweiterten Header entwickelt, wie beispielsweise für Kommunikationsmittel im Standard ED-137 (Interoperabilitätsstandards für VoIP-ATM-Komponenten).
Schauen wir uns die Headerfelder genauer an. Unten sehen Sie ein kanonisches Bild mit der Struktur des RTP-Headers, das ich ebenfalls in denselben Farben gestaltet habe.
VER — Versionsnummer des Protokolls (aktuelle Version 2);
P — Flag, das gesetzt wird, wenn das RTP-Paket mit leeren Bytes am Ende ergänzt wird;
X — Flag, dass der Header erweitert ist;
CC — enthält die Anzahl der CSRC-Identifikatoren, die dem festen Header folgen (nach den Worten 1..3), in der Abbildung ist die Tabelle nicht dargestellt;
M — Marker für den Beginn eines Frames oder das Vorhandensein von Sprache im Kanal (wenn ein Sprachpausendetektor verwendet wird). Wenn der Empfänger keinen Sprachpausendetektor enthält, sollte dieses Bit konstant gesetzt sein;
PTYPE — gibt das Format der Nutzlast an;
Sequenznummer — Paketnummer, die zur Wiederherstellung der Wiedergabereihenfolge der Pakete verwendet wird, da Pakete möglicherweise nicht in der Reihenfolge beim Empfänger ankommen, in der sie gesendet wurden. Der Anfangswert sollte zufällig sein, um es zu erschweren, den RTP-Stream bei Verwendung von Verschlüsselung zu knacken. Dieses Feld ermöglicht auch die Erkennung von Paketverlusten;
Zeitstempel — der Zeitstempel. Die Zeit wird in Signalproben gemessen, d.h. wenn ein Paket 160 Proben enthält, wird der Zeitstempel des nächsten Pakets um 160 erhöht. Der anfängliche Zeitstempel sollte zufällig sein;
SSRC — die Identifikation des Paketquell, die einzigartig sein muss. Es ist am besten, ihn zufällig vor dem Start des RTP-Streams zu generieren.
Wenn Sie Ihren eigenen RTP-Paketsender oder -empfänger entwickeln, müssen Sie Ihre Pakete häufig betrachten, um die Produktivität zu steigern. Ich empfehle Ihnen, den Umgang mit der Paketfilterung in TShark zu erlernen; es ermöglicht das Erfassen nur der Pakete, die für Sie von Interesse sind. In einer Umgebung, in der Dutzende von RTP-Geräten im Netzwerk aktiv sind, ist das von großem Wert. In der TShark-Befehlszeile werden die Filterparameter mit der Option "-f" festgelegt. Wir haben diese Option verwendet, als wir Pakete von Port 8010 erfassen wollten:
-f "udp port 8010"
Die Filterparameter sind im Wesentlichen eine Reihe von Kriterien, die das "erfasste" Paket erfüllen muss. Die Bedingungen können die Adresse, den Port oder den Wert eines bestimmten Bytes im Paket überprüfen. Die Bedingungen lassen sich durch logische Operationen wie "UND", "ODER" usw. kombinieren. Ein äußerst leistungsfähiges Werkzeug.
Wenn Sie die Dynamik der Änderungen in den Paketfeldern beobachten möchten, müssen Sie die Ausgabe wiederholen TShark in eine Datei, wie es im vorherigen Artikel gezeigt wurde, indem Sie die Ausgabe übergeben TShark an den Eingang tee. Öffnen Sie anschließend die Log-Datei mit less, vim oder einem anderen Werkzeug, das in der Lage ist, schnell mit großen Textdateien zu arbeiten und Zeilen zu durchsuchen, damit Sie alle Nuancen des Verhaltens der Paketfelder im RTP-Stream herausfinden können.
Sollten Sie das Signal, das über den RTP-Stream gesendet wird, abhören müssen, verwenden Sie die Version TShark mit grafischer Benutzeroberfläche Wireshark. Durch einfache Mausklicks können Sie dort das Signal abhören und das Oszillogramm des Signals sehen. Aber unter der Voraussetzung, dass es im Format u-law oder a-low kodiert ist.
Im nächsten Wir werden zusammen ein Duplex-Gesprächsgerät erstellen. Besorgen Sie sich ein paar Headsets und einen Gesprächspartner.
Quelle: habr.com
