Materialet i artikeln är hämtat från min .
RTP-paketstruktur
Förr vi använder TShark utförde fångst av RTP-paket som utbyttes mellan vår mottagare och sändare. Tja, i den här kommer vi att måla elementen i paketet i olika färger och prata om deras syfte.
Låt oss ta en titt på samma förpackning, men med färgade marginaler och förklarande etiketter:
Längst ner i listan är byten som utgör RTP-paketet tonade, och detta är i sin tur nyttolasten för UDP-paketet (dess rubrik är inringad i svart). De färgade bakgrunderna indikerar byten för RTP-huvudet, och datablocket som innehåller nyttolasten för RTP-paketet är markerat i grönt. Uppgifterna presenteras i hexadecimalt format. I vårt fall är detta en ljudsignal komprimerad enligt u-lagen (mu-lagen), d.v.s. ett prov har en storlek på 1 byte. Eftersom vi använde standardsamplingshastigheten (8000 Hz), vid en pakethastighet på 50 Hz, bör varje RTP-paket innehålla 160 byte nyttolast. Vi kommer att se detta genom att räkna byte i det gröna området, det bör finnas 10 rader av dem.
Enligt standarden måste mängden data i nyttolasten vara en multipel av fyra, eller med andra ord måste den innehålla ett heltal av fyra-byte ord. Om det händer att din nyttolast inte matchar den här regeln, måste du lägga till nollvärdena byte i slutet av nyttolasten och ställa in Padding-biten. Denna bit finns i den första byten i RTP-huvudet och är färgad turkos. Observera att alla nyttolastbytes är 0xFF, vilket är hur u-lags tystnad ser ut.
RTP-pakethuvudet består av 12 obligatoriska byte, men i två fall kan det vara längre:
-
När ett paket bär en ljudsignal som erhålls genom att blanda signaler från flera källor (RTP-strömmar), så finns det efter de första 12 byten i rubriken en tabell med en lista över källidentifierare vars nyttolaster användes för att skapa nyttolasten för detta paket. I det här fallet, i de nedre fyra bitarna av den första byten i rubriken (fält Bidragande källidentifierare räknas) anger antalet källor. Fältstorleken är 4 bitar, så tabellen kan innehålla upp till 15 källidentifierare. Var och en upptar 4 byte. Denna tabell används när du ställer upp ett konferenssamtal.
-
När titeln har tillägget . I det här fallet sätts biten i den första byten i rubriken X. I den utökade rubriken, efter deltagartabellen (om någon), finns en ettordsförlängningshuvud, följt av förlängningsorden. En tillägg är en samling byte som du kan använda för att överföra ytterligare data. Standarden anger inte formatet för dessa data - det kan vara vad som helst. Det kan till exempel vara några ytterligare inställningar för enheten som tar emot RTP-paket. För vissa applikationer har dock utökade rubrikstandarder utvecklats. Detta görs till exempel för kommunikationer i standarden ED-137 (Interoperability Standards for VoIP ATM Components).
Låt oss nu titta på rubrikfälten mer detaljerat. Nedan är en kanonisk bild med strukturen på RTP-huvudet, som jag inte heller kunde motstå och målade i samma färger.
VER — Protokollets versionsnummer (nuvarande version 2).
P - en flagga som sätts i fall där RTP-paketet kompletteras med tomma bytes i slutet;
X - flagga att rubriken är förlängd;
CC — innehåller antalet CSRC-identifierare efter den konstanta rubriken (efter ord 1..3), tabellen visas inte i figuren;
M — markör för början av en bildruta eller närvaron av tal i kanalen (om en talpausdetektor används). Om mottagaren inte innehåller en talpausdetektor, ska denna bit ställas in permanent;
PTYPE - anger formatet på nyttolasten;
Sekvensnummer - Paketnummer, som används för att återställa ordningen i vilken paket spelas, eftersom den verkliga situationen är när paket kan nå mottagaren i fel ordning som de skickades. Initialvärdet måste vara slumpmässigt, detta görs för att om RTP-strömmen är krypterad blir det svårt att hacka den. Det här fältet låter dig också upptäcka missade paket;
Tidsstämpel - tidsstämpel. Tid mäts i signalsampel, d.v.s. om en skur innehåller 160 sampel, kommer tidsstämpeln för nästa skur att vara ytterligare 160. Det initiala värdet för tidsstämpeln måste vara slumpmässigt;
SSRC — identifierare för paketkällan, den måste vara unik. Det är bättre att generera det slumpmässigt innan du startar RTP-strömmen.
Om du utvecklar din egen RTP-paketsändare eller -mottagare måste du titta på dina paket mer än en gång för att öka produktiviteten, jag rekommenderar att du lär dig hur du använder paketfiltrering i TShark, det låter dig fånga endast de paket som är av intresse för dig. I en miljö där dussintals RTP-enheter fungerar på nätverket är detta mycket värdefullt. I TShark-kommandoraden anges filtreringsalternativ med alternativet "-f". Vi använde det här alternativet när vi ville fånga paket från port 8010:
-f "udp port 8010"
Filtreringsparametrar är i huvudsak en uppsättning kriterier som ett "fångat" paket måste matcha. Villkoret kan kontrollera adressen, porten, värdet för en viss byte i paketet. Villkor kan kombineras med logiska operationer "AND", "ELLER" etc. Ett mycket kraftfullt verktyg.
Om du vill se dynamiken för fältändringar i batcher måste du duplicera utdata TShark till en fil, som visas i den senaste artikeln, genom att skicka utdata TShark vid ingången tee. Öppna sedan loggfilen med mindre, vim eller ett annat verktyg som snabbt kan arbeta med stora textfiler och söka efter strängar, kan du ta reda på alla nyanser av beteendet hos paketfält i en RTP-ström.
Om du behöver lyssna på signalen som sänds av RTP-strömmen, måste du använda versionen TShark med visuellt gränssnitt Wireshark. Med enkla musmanipulationer kan du lyssna på och se signalens vågform. Men på ett villkor - om det är kodat i u-lag eller a-låg format.
Nästa vi kommer att göra en duplex intercom med dig. Fyll på ett par headset och en samtalspartner.
Källa: will.com