Artiklens materiale er hentet fra min .
RTP-pakkestruktur
I fortiden vi bruger TShark udførte indfangningen af RTP-pakker, der blev udvekslet mellem vores modtager og sender. Nå, i denne vil vi male elementerne i pakken i forskellige farver og tale om deres formål.
Lad os tage et kig på den samme pakke, men med farvede marginer og forklarende etiketter:
Nederst på listen er de bytes, der udgør RTP-pakken, tonet, og dette er igen nyttelasten af UDP-pakken (dens overskrift er cirklet med sort). De farvede baggrunde angiver bytes af RTP-headeren, og datablokken, der indeholder RTP-pakkens nyttelast, er fremhævet med grønt. Dataene præsenteres i hexadecimalt format. I vores tilfælde er der tale om et lydsignal komprimeret efter u-loven (mu-loven), dvs. en prøve har en størrelse på 1 byte. Da vi brugte standardsamplinghastigheden (8000 Hz), ved en pakkehastighed på 50 Hz, bør hver RTP-pakke indeholde 160 bytes nyttelast. Vi vil se dette ved at tælle bytes i det grønne område, der skal være 10 linjer af dem.
Ifølge standarden skal mængden af data i nyttelasten være et multiplum af fire, eller med andre ord skal den indeholde et helt tal på fire-byte ord. Hvis det sker, at din nyttelast ikke matcher denne regel, skal du tilføje nulværdibytes til slutningen af nyttelasten og indstille Padding-bitten. Denne bit er placeret i den første byte af RTP-headeren og er farvet turkis. Bemærk, at alle nyttelastbytes er 0xFF, hvilket er, hvordan u-lov stilhed ser ud.
RTP-pakkeheaderen består af 12 obligatoriske bytes, men i to tilfælde kan den være længere:
-
Når en pakke bærer et lydsignal opnået ved at blande signaler fra flere kilder (RTP-streams), så er der efter de første 12 bytes af headeren en tabel med en liste over kildeidentifikatorer, hvis nyttelast blev brugt til at skabe nyttelasten af denne pakke. I dette tilfælde, i de nederste fire bits af den første byte i headeren (felt Medvirkende kildeidentifikatorer tæller) angiver antallet af kilder. Feltstørrelsen er 4 bit, så tabellen kan indeholde op til 15 kildeidentifikatorer. Hver af dem optager 4 bytes. Denne tabel bruges, når du opretter et konferenceopkald.
-
Når titlen har udvidelsen . I dette tilfælde sættes bit i den første byte i headeren X. I den udvidede overskrift, efter deltagertabellen (hvis nogen), er der en et-ords udvidelsesoverskrift efterfulgt af udvidelsesordene. En udvidelse er en samling af bytes, som du kan bruge til at overføre yderligere data. Standarden foreskriver ikke formatet af disse data - det kan være hvad som helst. Det kan for eksempel være nogle ekstra indstillinger for den enhed, der modtager RTP-pakker. For nogle applikationer er der dog udviklet udvidede header-standarder. Dette gøres for eksempel for kommunikation i standarden ED-137 (Interoperabilitetsstandarder for VoIP ATM-komponenter).
Lad os nu se på overskriftsfelterne mere detaljeret. Nedenfor er et kanonisk billede med strukturen af RTP-headeren, som jeg heller ikke kunne modstå og malede i de samme farver.
VER — Protokolversionsnummer (nuværende version 2);
P - et flag, der sættes i tilfælde, hvor RTP-pakken suppleres med tomme bytes i slutningen;
X - flag at overskriften er forlænget;
CC — indeholder antallet af CSRC-identifikatorer efter den konstante overskrift (efter ord 1..3), tabellen er ikke vist i figuren;
M — markør for begyndelsen af et billede eller tilstedeværelsen af tale i kanalen (hvis der bruges en talepausedetektor). Hvis modtageren ikke indeholder en talepausedetektor, skal denne bit indstilles permanent;
PTYPE - specificerer formatet på nyttelasten;
Sekvensnummer - pakkenummer, bruges til at gendanne rækkefølgen, som pakker afspilles i, da den virkelige situation er, når pakker kan nå modtageren i den forkerte rækkefølge, som de blev sendt i. Startværdien skal være tilfældig, dette gøres for at hvis RTP-strømmen er krypteret, vil det være svært at hacke den. Dette felt giver dig også mulighed for at opdage mistede pakker;
Timestamp - tidsstempel. Tid måles i signalprøver, dvs. hvis en burst indeholder 160 samples, så vil tidsstemplet for den næste burst være 160 mere. Startværdien af tidsstemplet skal være tilfældig;
SSRC — identifikator for pakkekilden, den skal være unik. Det er bedre at generere det tilfældigt, før du starter RTP-streamen.
Hvis du udvikler din egen RTP-pakkesender eller -modtager, bliver du nødt til at se på dine pakker mere end én gang for at øge produktiviteten, jeg anbefaler, at du lærer at bruge pakkefiltrering i TShark, det giver dig mulighed for kun at fange de pakker, der er af interesse for dig. I et miljø, hvor dusinvis af RTP-enheder opererer på netværket, er dette meget værdifuldt. I TShark-kommandolinjen er filtreringsindstillinger angivet med "-f"-indstillingen. Vi brugte denne mulighed, da vi ønskede at fange pakker fra port 8010:
-f "udp port 8010"
Filtreringsparametre er i bund og grund et sæt kriterier, som en "fanget" pakke skal matche. Betingelsen kan kontrollere adressen, porten, værdien af en bestemt byte i pakken. Betingelser kan kombineres med logiske operationer "AND", "OR" osv. Et meget kraftfuldt værktøj.
Hvis du vil se dynamikken i feltændringer i batches, skal du duplikere outputtet TShark til en fil, som vist i den sidste artikel, ved at sende outputtet TShark ved indgangen tee. Åbn derefter logfilen med mindre, vim eller et andet værktøj, der hurtigt kan arbejde med store tekstfiler og søge efter strenge, kan du finde ud af alle nuancerne af pakkefelters adfærd i en RTP-stream.
Hvis du skal lytte til signalet, der transmitteres af RTP-strømmen, skal du bruge versionen TShark med visuel grænseflade Wireshark. Med simple musemanipulationer kan du lytte til og se signalets bølgeform. Men på én betingelse - hvis det er kodet i u-lov eller a-low format.
Næste vi laver et duplex samtaleanlæg med dig. Lager op på et par headset og en samtalepartner.
Kilde: www.habr.com