Vi studerar VoIP-motorn Mediastreamer2. Del 8

Artikelmaterialet är hämtat från min Zen-kanal.

Strukturen av RTP-paketet

Tidigare artikeln Vi har med hjälp av TShark genomfört en fångst av RTP-paket som utbyttes mellan vår mottagare och sändare. I denna kommer vi att färglägga paketets element i olika färger och diskutera deras syften.

Låt oss titta på samma paket, men nu med färgade fält och förklarande texter:

I den nedre delen av listningen är de bytes som utgör RTP-paketet färgade, och det är i sin tur nyttolasten i UDP-paketet (dess huvud är inringat med en svart linje). Färgfonderna markerar bytes av RTP-huvudet, medan den gröna färgen framhäver datablocket som innehåller RTP-paketets nyttolast. Data presenteras i hexadecimalt format. I vårt fall är detta ett ljudsignal komprimerat enligt u-law (my-law), det vill säga en sampling har storleken 1 byte. Eftersom vi använde standard samplingfrekvens (8000 Hz), ska varje RTP-paket innehålla 160 bytes nyttolast vid en paketfrekvens på 50 Hz. Detta ser vi när vi räknar bytes i det gröna området; de borde vara 10 rader.

Enligt standarden ska mängden data i nyttolasten vara ett multipel av fyra, eller med andra ord innehålla ett helt antal fyrabyte ord. Om det skulle hända att din nyttolast inte uppfyller denna regel, måste du lägga till nollbytes i slutet av nyttolasten och sätta biten Padding. Denna bit finns i den första byte av RTP-huvudet, och den är färgad turkos. Observera att alla bytes i nyttolasten har värdet 0xFF – så ser tystnad ut i u-law format.

RTP-paketets huvud består av 12 obligatoriska bytes, men i två fall kan den vara längre:

• När paketet bär en ljudsignal som mottagits genom att blanda signaler från flera källor (RTP-strömmar), placeras en lista med identifikationsnummer för källor, vars nyttolaster har använts för att skapa nyttolasten av detta paket, efter de första 12 bytes av huvudet. I de lägre fyra bitarna av den första byte av huvudet (fältet Antal identifierare för bidragande källor) anger antalet källor. Storleken på fältet är 4 bitar, vilket innebär att tabellen kan innehålla upp till 15 källidentifierare. Var och en tar upp 4 byte. Denna tabell används vid organiseringen av konferenskommunikation.

• När rubriken har en förlängning. I detta fall sätts en bit i den första byte av rubriken. X. I den utvidgade rubriken, efter deltagartabellen (om de finns), finns en utvidgad rubrik med storlek av ett ord, följt av utvidgade ord. En utvidgning är en uppsättning byte som du kan använda för att överföra ytterligare data. Standarden specificerar inte formatet för dessa data — det kan vara vilket som helst. Till exempel kan det vara några ytterligare inställningar för en enhet som tar emot RTP-paket. För vissa tillämpningar har standarder för den utvidgade rubriken utvecklats. Det är så gjort exempelvis för kommunikationsmedel i standarden ED-137 ( Interoperability Standards for VoIP ATM Components ).

Låt oss nu titta mer i detalj på rubrikfälten. Nedan visas en kanonisk bild med strukturen för RTP-rubriken, som jag också inte kunde låta bli att färga i samma färger.

VER — versionsnumret för protokollet (nuvarande version 2);

P — en flagga som sätts i de fall där RTP-paketet kompletteras med tomma byte i slutet;

X — en flagga för att indikera att rubriken är utvidgad;

CC — innehåller antalet CSRC-identifikatorer som följer efter den fasta rubriken (efter orden 1..3), i bilden visas inte tabellen;

M — en markör för början av ett paket eller närvaro av tal i kanalen (om tystnadsdetektor används). Om mottagaren inte har en tystnadsdetektor, ska denna bit alltid sättas;

PTYPE — indikerar formatet för nyttolasten;

Sekvensnummer — paketnumret, används för att återställa ordningen på uppspelningen av paketen, eftersom det i verkligheten kan hända att paketen når mottagaren i en annan ordning än den som de skickades. Startvärdet ska vara slumpmässigt, detta görs för att om RTP-strömmen krypteras ska det bli svårare att bryta den. Detta fält möjliggör även att upptäcka bortfall av paket;

Tidsstämpel — tidsstämpel. Tiden mäts i signalprov, det vill säga om paketet innehåller 160 prov, kommer tidsstämpeln för nästa paket att öka med 160. Startvärdet för tidsstämpeln bör vara slumpmässigt;

SSRC — identifierare för paketkällan, den måste vara unik. Det är bäst att generera den slumpmässigt innan du startar RTP-flödet.

Om du utvecklar din egen sändare eller mottagare för RTP-paket, kommer du att behöva titta på dina paket flera gånger för att öka produktiviteten; jag rekommenderar att du bemästrar användningen av paketfiltrering i TShark, eftersom det tillåter dig att fånga endast de paket som är av intresse för dig. Under förhållanden där dussintals RTP-enheter fungerar på nätverket är detta mycket värdefullt. I kommandoraden ställs filtreringsparametrarna in med alternativet "-f". Vi använde detta alternativ när vi ville fånga paket från port 8010:
-f "udp port 8010"
Filtreringsparametrar är i grunden en uppsättning kriterier som det "fångade" paketet måste uppfylla. Villkoret kan kontrollera adress, port, värdet av en viss byte i paketet. Villkor kan kombineras med logiska operationer "OCH", "ELLER" och så vidare. Ett mycket kraftfullt verktyg.

Om du vill se dynamiken i fältsändningar i paketen, måste du duplicera utdata TShark till en fil, som visat i den tidigare artikeln, med hjälp av att överföra utdata TShark till ingången tee. Du öppnar sedan loggfilen med less, vim eller något annat verktyg som snabbt kan hantera stora textfiler och utföra sökningar, så kan du ta reda på alla nyanser i fältena för RTP-flödet.

Om du behöver lyssna på signalen som överförs av RTP-flödet, bör du använda versionen TShark med grafiskt gränssnitt Wireshark. Genom enkla musmanipulationer kan du där lyssna, se signalens oscilloskop. Men under ett villkor — om den kodas i formatet u-law eller a-law.

I nästa artikeln kommer vi att skapa ett duplexkommunikationssystem tillsammans. Se till att ha ett par hörlurar och en kompis.

Källa: habr.com