Materialet i artiklen er taget fra min .
Strukturen af RTP-pakke
I den forrige vi har ved hjælp af TShark udført optagelse af RTP-pakker, som vores modtager og transmitter udvekslede. I denne lektion vil vi farvelægge pakkeelementerne i forskellige farver og tale om deres funktion.
Lad os se på den samme pakke, men nu med farvelagte felter og forklarende etiketter:
I bunden af opstillingen er de bytes, der udgør RTP-pakken, farvet, og den er i øvrigt nyttelasten af UDP-pakken (dets hoved er omkranset af en sort linje). Baggrundene er farvet for at markere bytes af RTP-hovedet, og den grønne farve fremhæver datablokken, der indeholder nyttelasten af RTP-pakken. Dataene er præsenteret i hexadecimal format. I vores tilfælde er det et lydsignal komprimeret ved hjælp af u-lov (μ-lov), hvilket vil sige, at en prøve har en størrelse på 1 byte. Da vi brugte standard sampling rate (8000 Hz), skal hver RTP-pakke indeholde 160 bytes nyttelast ved en pakke frekvens på 50 Hz. Det vil vi se, når vi tæller bytes i det grønne område; der skal være 10 linjer.
Ifølge standarden skal mængden af data i nyttelasten være et multiplum af fire, eller med andre ord skal det indeholde et helt antal fire-byte ord. Hvis det skulle ske, at din nyttelast ikke overholder denne regel, skal der tilføjes bytes med nul-værdier til slutningen af nyttelasten og bit-feltet Padding (Udfyldning) skal sættes. Denne bit ligger i den første byte af RTP-hovedet, og den er farvet i turkis. Vær opmærksom på, at alle bytes i nyttelasten har værdien 0xFF — det er, hvordan stilhed ser ud i u-lov format.
RTP-pakkens header består af 12 obligatoriske bytes, men i to tilfælde kan den være længere:
Når pakken bærer et lydsignal modtaget fra blandingen af signaler fra flere kilder (RTP-strømme), så findes der efter de første 12 bytes i headeren en tabel med en liste over identifikatorer for kilderne, hvis nyttelast er blevet brugt til at skabe nyttelasten af denne pakke. Herudover er de laveste fire bits i den første byte af headeren (feltet Antal bidragende kildeidentifikatorer) angiver antallet af kilder. Størrelsen på feltet er 4 bit, således at tabellen kan indeholde op til 15 kilder. Hver af dem tager 4 byte. Denne tabel bruges ved organisering af konferenceopkald.
Når overskriften har en extension. I dette tilfælde sættes en bit i det første byte af overskriften. X. I den udvidede overskrift, efter deltagerlisten (hvis der er nogen), placeres en overskrift for extension, der har størrelsen af et ord, efterfulgt af ordene for extension. Extension er et sæt bytes, som du kan bruge til at transmittere yderligere data. Standarderne specificerer ikke formatet af disse data — det kan være hvad som helst. For eksempel kan det være nogen ekstra indstillinger for en enhed, der modtager RTP-pakker. For visse anvendelser er der dog udviklet standarder for den udvidede overskrift. Det er f.eks. gjort for kommunikationsmidler i standarden ED-137 (Interoperability Standards for VoIP ATM Components).
Lad os nu se nærmere på felterne i overskriften. Nedenfor er et kanonisk billede med strukturen af RTP-overskriften, som jeg heller ikke kunne lade være med at farve i de samme farver.
VER — versionsnummeret for protokollen (nuværende version 2);
P — en flag, der sættes i situationer, hvor RTP-pakken suppleres med tomme bytes i slutningen;
X — en flag for, at overskriften er udvidet;
CC — indeholder antallet af CSRC-identifikatorer, der følger efter den faste overskrift (efter ordene 1..3), tabellen er ikke vist på billedet;
M — markerer starten på en ramme eller tilstedeværelsen af tale i kanalen (hvis pause-detektoren anvendes). Hvis modtageren ikke har en pause-detektor, skal denne bit konstant være tændt;
PTYPE — angiver formatet for nyttelasten;
Sekvensnummer — pakkenummer, bruges til at genskabe rækkefølgen ved afspilning af pakker, da den faktiske situation kan være, at pakker når modtageren ikke i den rækkefølge, de blev sendt. Startværdien skal være tilfældig, dette gøres for at vanskeliggøre hackning, hvis RTP-strømmen krypteres. Dette felt gør det også muligt at opdage manglende pakker;
Tidsstempel — tidsstempel. Tiden måles i signalprøver, dvs. hvis pakken indeholder 160 prøver, vil tidsstemplet for den næste pakke være 160 højere. Startværdien for tidsstemplet skal være tilfældig;
SSRC — identifikatoren for pakke kilden, den skal være unik. Det er bedst at generere den tilfældigt før starten af RTP-streamen.
Hvis du udvikler din egen RTP-pakke sender eller modtager, skal du ofte overveje dine pakker for at øge effektiviteten. Jeg anbefaler at mestre brugen af pakke filtrering i TShark, da det giver mulighed for kun at fange de pakker, der er interessante for dig. I situationer hvor der arbejdes med dusinvis af RTP-enheder på netværket, er dette meget værdifuldt. I TShark's kommandolinje angives filtreringsparametre med indstillingen "-f". Vi brugte denne indstilling, da vi ønskede at fange pakker fra port 8010:
-f "udp port 8010"
Filtreringsparametre er i sin kerne et sæt kriterier, som den "fangede" pakke skal opfylde. En betingelse kan tjekke adressen, porten, værdien af et bestemt byte i pakken. Betingelserne kan kombineres med logiske operationer som "OG", "ELLER" osv. Det er et meget kraftfuldt værktøj.
Hvis du vil se dynamikken i ændringerne af felter i pakkerne, skal du duplikere outputtet TShark til en fil, som vist i den tidligere artikel, ved hjælp af at sende output TShark til indgangen tee. Derefter, når du åbner logfilen med less, vim eller et andet værktøj, der kan arbejde hurtigt med store tekstfiler og udføre søgninger, vil du kunne finde alle nuancerne i felternes adfærd i RTP-strømmen.
Hvis du har brug for at lytte til signalet sendt af RTP-strømmen, skal du bruge versionen TShark med et visuelt interface Wireshark. Gennem enkle musemanipulationer kan du lytte til det, se oscilloskopet af signalet. Men under én betingelse — hvis det er kodet i formaterne u-law eller a-law.
I næste vi vil lave et duplex samtaleapparat sammen. Sørg for at have et par headset og en samtalepartner.
Kilde: habr.com
