Stoffet til artikkelen er hentet fra min .
RTP-pakkestruktur
I den siste vi bruker TShark utførte fangst av RTP-pakker som ble utvekslet mellom vår mottaker og sender. Vel, i denne vil vi male elementene i pakken i forskjellige farger og snakke om formålet deres.
La oss ta en titt på den samme pakken, men med fargede marger og forklarende etiketter:
Nederst på listen er bytene som utgjør RTP-pakken farget, og dette er igjen nyttelasten til UDP-pakken (overskriften er ringt inn i svart). De fargede bakgrunnene indikerer bytene til RTP-overskriften, og datablokken som inneholder nyttelasten til RTP-pakken er uthevet i grønt. Dataene presenteres i heksadesimalt format. I vårt tilfelle er dette et lydsignal komprimert etter u-loven (mu-loven), dvs. en prøve har en størrelse på 1 byte. Siden vi brukte standard samplingsfrekvens (8000 Hz), med en pakkehastighet på 50 Hz, bør hver RTP-pakke inneholde 160 byte nyttelast. Vi vil se dette ved å telle byte i det grønne området, det skal være 10 linjer av dem.
I henhold til standarden må datamengden i nyttelasten være et multiplum av fire, eller med andre ord, den må inneholde et heltall på fire-byte ord. Hvis det skjer at nyttelasten din ikke samsvarer med denne regelen, må du legge til nullverdibyte på slutten av nyttelasten og angi Padding-biten. Denne biten er plassert i den første byten i RTP-headeren og er farget turkis. Merk at alle nyttelastbyte er 0xFF, som er hvordan u-lov-stillhet ser ut.
RTP-pakkehodet består av 12 obligatoriske byte, men i to tilfeller kan den være lengre:
-
Når en pakke bærer et lydsignal oppnådd ved å blande signaler fra flere kilder (RTP-strømmer), er det etter de første 12 bytene i overskriften en tabell med en liste over kildeidentifikatorer hvis nyttelast ble brukt til å lage nyttelasten til denne pakken. I dette tilfellet, i de fire nedre bitene av den første byten i overskriften (felt Medvirkende kildeidentifikatorer teller) angir antall kilder. Feltstørrelsen er 4 biter, så tabellen kan inneholde opptil 15 kildeidentifikatorer. Hver av dem opptar 4 byte. Denne tabellen brukes når du setter opp en konferansesamtale.
-
Når tittelen har utvidelsen . I dette tilfellet settes biten i den første byten i overskriften X. I den utvidede overskriften, etter deltakertabellen (hvis noen), er det en utvidelsesoverskrift på ett ord, etterfulgt av utvidelsesordene. En utvidelse er en samling byte som du kan bruke til å overføre tilleggsdata. Standarden angir ikke formatet på disse dataene - det kan være hva som helst. Det kan for eksempel være noen tilleggsinnstillinger for enheten som mottar RTP-pakker. For noen applikasjoner er det imidlertid utviklet utvidede topptekststandarder. Dette gjøres for eksempel for kommunikasjon i standarden ED-137 (Interoperabilitetsstandarder for VoIP ATM-komponenter).
La oss nå se på overskriftsfeltene mer detaljert. Nedenfor er et kanonisk bilde med strukturen til RTP-headeren, som jeg heller ikke kunne motstå og malte i de samme fargene.
VER — protokollversjonsnummer (gjeldende versjon 2);
P - et flagg som settes i tilfeller der RTP-pakken er supplert med tomme byte på slutten;
X - flagg at overskriften er utvidet;
CC — inneholder antall CSRC-identifikatorer etter den konstante overskriften (etter ord 1..3), tabellen er ikke vist i figuren;
M — markør for begynnelsen av en ramme eller tilstedeværelsen av tale i kanalen (hvis en talepausedetektor brukes). Hvis mottakeren ikke inneholder en talepausedetektor, skal denne biten settes permanent;
PTYPE - spesifiserer formatet på nyttelasten;
Sekvensnummer - pakkenummer, brukes til å gjenopprette rekkefølgen pakker spilles i, siden den virkelige situasjonen er når pakker kan nå mottakeren i feil rekkefølge de ble sendt i. Startverdien må være tilfeldig, dette gjøres slik at hvis RTP-strømmen er kryptert, vil det være vanskelig å hacke den. Dessuten lar dette feltet deg oppdage tapte pakker;
Tidsstempel - tidsstempel. Tid måles i signalprøver, dvs. hvis en serie inneholder 160 sampler, vil tidsstemplet til neste serie være 160. Startverdien til tidsstemplet må være tilfeldig;
SSRC — identifikator for pakkekilden, den må være unik. Det er bedre å generere det tilfeldig før du starter RTP-strømmen.
Hvis du utvikler din egen RTP-sender eller -mottaker, må du gjennomgå pakkene dine mer enn en gang for å øke produktiviteten, jeg anbefaler at du lærer deg hvordan du bruker pakkefiltrering i TShark, det lar deg fange bare de pakkene som er av interesse for deg. I et miljø der dusinvis av RTP-enheter opererer på nettverket, er dette svært verdifullt. I TShark-kommandolinjen er filtreringsalternativer spesifisert med alternativet "-f". Vi brukte dette alternativet når vi ønsket å fange pakker fra port 8010:
-f "udp port 8010"
Filtreringsparametere er i hovedsak et sett med kriterier som en "fanget" pakke må oppfylle. Tilstanden kan sjekke adressen, porten, verdien til en bestemt byte i pakken. Betingelser kan kombineres med logiske operasjoner "AND", "OR", etc. Et veldig kraftig verktøy.
Hvis du vil se dynamikken til feltendringer i batcher, må du duplisere utdataene TShark til en fil, som vist i forrige artikkel, ved å sende utdataene TShark ved inngangen tee. Deretter åpner du loggfilen med mindre, vim eller et annet verktøy som raskt kan jobbe med store tekstfiler og søke etter strenger, kan du finne ut alle nyansene til oppførselen til pakkefelt i en RTP-strøm.
Hvis du trenger å lytte til signalet som sendes av RTP-strømmen, må du bruke versjonen TShark med visuelt grensesnitt Wireshark. Med enkle musemanipulasjoner kan du lytte til og se bølgeformen til signalet. Men på en betingelse - hvis den er kodet i u-lov eller a-low-format.
Neste vi vil lage en duplex intercom med deg. Lager opp et par hodesett og en samtalepartner.
Kilde: www.habr.com