Het materiaal van dit artikel is afkomstig van mijn .
Structuur van het RTP-pakket
In het verleden wij hebben met behulp van TShark de RTP-pakketten vastgelegd die werden uitgewisseld tussen onze ontvanger en zender. In deze zullen we de elementen van het pakket in verschillende kleuren kleuren en spreken over hun functies.
Laten we naar hetzelfde pakket kijken, maar nu met gekleurde velden en verklarende teksten:
In de onderste helft van de listing zijn de bytes gekleurd die het RTP-pakket vormen, dat op zijn beurt de nuttige lading van het UDP-pakket is (de header is omcirkeld met een zwarte lijn). De gekleurde achtergronden geven de bytes van de RTP-header aan, terwijl het groene gedeelte het datablok markeert dat de nuttige lading van het RTP-pakket bevat. De gegevens worden gepresenteerd in hexadecimale indeling. In ons geval is dit een geluidssignaal dat is gecomprimeerd volgens de u-wet (mu-wet), dat wil zeggen dat één monster 1 byte groot is. Aangezien we de standaard samplingfrequentie (8000 Hz) hebben gebruikt, moet elk RTP-pakket bij een frequentie van 50 Hz 160 bytes nuttige lading bevatten. Dit zullen we zien door de bytes in het groene gebied te tellen, er zouden 10 regels moeten zijn.
Volgens de standaard moet de hoeveelheid gegevens in de nuttige lading een veelvoud van vier zijn, of met andere woorden, het moet een geheel aantal vierbytewoorden bevatten. Als het gebeurt dat uw nuttige lading niet aan deze regel voldoet, moeten aan het einde van de nuttige lading bytes met nulwaarden worden toegevoegd en moet de Padding-bit worden ingesteld. Deze bit bevindt zich in de eerste byte van de RTP-header, die in turquoise kleur is gemarkeerd. Houd er rekening mee dat alle bytes in de nuttige lading de waarde 0xFF hebben – zo ziet stilte eruit in het u-law formaat.
De RTP-header bestaat uit 12 verplichte bytes, maar in twee gevallen kan deze langer zijn:
Wanneer het pakket een geluidssignaal bevat dat is verkregen door het mengen van signalen van verschillende bronnen (RTP-stromen), dan komt na de eerste 12 bytes van de header een tabel met een lijst van de identificatoren van de bronnen waarvan de nuttige ladingen zijn gebruikt voor het maken van de nuttige lading van dit pakket. Hierbij bevinden zich in de laagste vier bits van de eerste byte van de header (veld Aantal bijdragende bronidentificaties) geeft het aantal bronnen aan. Het veld is 4 bits groot, dus de tabel kan tot 15 bronidentificatoren bevatten, die elk 4 bytes innemen. Deze tabel wordt gebruikt bij het organiseren van conferentiecommunicatie.
Wanneer de header een extensie heeft. In dit geval wordt in de eerste byte van de header een bit ingesteld. X. In de uitgebreide header, na de deelnemerslijst (indien van toepassing), bevindt zich de extensieheader van één woord, gevolgd door de extensiewoorden. De extensie is een set bytes die je kunt gebruiken om extra gegevens door te geven. De standaard specificeert het format van deze gegevens niet — het kan van alles zijn. Bijvoorbeeld, dit kunnen extra instellingen zijn voor het apparaat dat RTP-pakketten ontvangt. Voor sommige toepassingen zijn echter standaarden voor de uitgebreide header ontwikkeld. Dit is bijvoorbeeld zo gedaan voor communicatiemiddelen in de standaard ED-137 (Interoperabiliteitsstandaarden voor VoIP-ATM-componenten).
Laten we nu de headervelden in meer detail bekijken. Hieronder is een canonieke afbeelding met de structuur van de RTP-header, die ik ook in dezelfde kleuren heb gekleurd.
VER — het versie nummer van het protocol (huidige versie 2);
P — een vlag die wordt ingesteld in gevallen waarin het RTP-pakket wordt aangevuld met lege bytes aan het einde;
X — een vlag die aangeeft dat de header uitgebreid is;
CC — bevat het aantal CSRC-identificatoren dat volgt na de vaste header (na de woorden 1..3), de tabel is in de afbeelding niet getoond;
M — marker voor het begin van een frame of aanwezigheid van spraak in de kanalen (indien er een spraakpauzedetector wordt gebruikt). Als de ontvanger geen spraakpauzedetector bevat, moet deze bit altijd zijn ingesteld;
PTYPE — geeft het formaat van de nuttige lading aan;
Volgnummer — pakketnummer, wordt gebruikt om de volgorde van de afspelen van de pakketten te herstellen, aangezien het in werkelijkheid kan voorkomen dat pakketten in een andere volgorde bij de ontvanger aankomen dan waarvoor ze zijn verzonden. De beginwaarde moet willekeurig zijn, dit is om het moeilijker te maken om de RTP-stroom te kraken als encryptie wordt toegepast. Dit veld maakt ook het detecteren van gemiste pakketten mogelijk;
Timestamp — tijdstempel. De tijd wordt gemeten in signal samples, dat wil zeggen, als een pakket 160 samples bevat, zal de tijdstempel van het volgende pakket met 160 toenemen. De initiële waarde van de tijdstempel moet willekeurig zijn;
SSRC — de identifier van de pakketbron, deze moet uniek zijn. Het is beter om deze willekeurig te genereren vóór de start van de RTP-stroom.
Als je je eigen zender of ontvanger van RTP-pakketten ontwikkelt, moet je je pakketten vaak bekijken om de prestaties te verbeteren. Ik raad je aan om de mogelijkheden van pakketfiltering in TShark te leren, dit stelt je in staat om alleen de pakketten te vangen die relevant voor je zijn. In situaties waarin tientallen RTP-apparaten op het netwerk werken, is dit zeer waardevol. In de TShark-opdrachtregel worden de filterparameters ingesteld met de optie "-f". We hebben deze optie gebruikt toen we pakketten van poort 8010 wilden vastleggen:
-f "udp port 8010"
Filterparameters zijn in wezen een set criteria waaraan het "gecaptureerde" pakket moet voldoen. Een voorwaarde kan het adres, de poort, of de waarde van een bepaalde byte in het pakket controleren. Voorwaarden kunnen worden gecombineerd met logische operatoren zoals "EN", "OF", enz. Een zeer krachtig hulpmiddel.
Als je de dynamiek van de veranderingen in de velden binnen de pakketten wilt bekijken, moet je de uitvoer dupliceren TShark naar een bestand, zoals eerder in het artikel is getoond, met behulp van het doorgeven van de uitvoer TShark aan de invoer tee. Vervolgens kun je het logbestand openen met less, vim of een ander hulpmiddel dat snel met enorme tekstbestanden kan werken en stringsearching kan uitvoeren, om alle nuances van het gedrag van de velden in de RTP-stroom te begrijpen.
Als je het signaal dat via de RTP-stroom wordt verzonden wilt beluisteren, moet je de versie gebruiken TShark met een grafische interface Wireshark. Met een paar muisklikken kun je daar luisteren en de oscilloscoop van het signaal zien. Maar slechts onder één voorwaarde — als het gecodeerd is in het formaat u-law of a-law.
In de volgende we gaan samen een duplex communicatiesysteem maken. Zorg voor een paar headsets en één gesprekspartner.
Bron: habr.com
