A cikk anyaga az én .
Az RTP-csomag struktúrája
A múltban segítségével TShark elvégeztük az RTP-csomagok rögzítését, amelyeket a vevőnk és az adónk cseréltek. Ebben a részben a csomag elemeit különböző színekkel fogjuk kiemelni, és beszélünk a funkciójukról.
Nézzük meg ugyanezt a csomagot, de már színezett mezőkkel és magyarázó feliratokkal:
A lista alján a színezett bájtok alkotják az RTP-csomagot, ami viszont az UDP-csomag hasznos terhelése (a fejlécét fekete vonal övezi). A színes háttér a RTP-fejléc bájtjait jelöli, míg a zöld szín a hasznos terhelést tartalmazó adatblokknak van fenntartva. Az adatok itt hexadecimális formátumban vannak bemutatva. Az esetünkben ez a hangjelzés u-törvény (mu-törvény) szerint tömörített, azaz egy mintavétel 1 bájt méretű. Mivel az alapértelmezett mintavételezési frekvenciát (8000 Hz) használtuk, a 50 Hz-es csomagfrekvencián minden RTP-csomagnak 160 bájt hasznos terhelést kell tartalmaznia. Ezt fogjuk látni, ha megszámoljuk a zöld területen lévő bájtokat, összesen 10 sor legyen.
A szabvány szerint a hasznos terhelésben lévő adatoknak négyzetre kell oszthatónak lenniük, vagyis egész számú négy bájtos szót kell tartalmaznia. Ha úgy alakul, hogy a hasznos terhelés nem felel meg ennek a szabályozásnak, akkor a hasznos terhelés végére nullás értékű bájtokat kell hozzáadni, és be kell állítani a Padding (Kiegészítés) bitet. Ez a bit az RTP-fejléc első bájtjában található, és türkizkék színnel van kiemelve. Figyelembe kell venni, hogy a hasznos terhely bájtjai mind 0xFF értéket vesznek fel - így néz ki a csend az u-law formátumban.
Az RTP-csomag fejezet 12 kötelező bájtból áll, de két esetben hosszabb is lehet:
Amikor a csomag hangjelet hordoz, amely több forrás (RTP-áram) jeleinek keveredéséből származik, akkor a fejléc első 12 bájtja után egy lista szerepel a források azonosítóival, amelyek hasznos terheléseit a csomag hasznos terhelésének létrehozásához használták. Itt az első bájt alsó négy bitjében található a fejléc (mező Hozzájáruló forrásazonosítók száma) meg kell adni a források számát. A mező mérete 4 bit, ennek megfelelően a táblázat legfeljebb 15 forrást azonosít be. Mindegyik 4 bájt helyet foglal el. Ezt a táblázatot a konferenciaközvetítés megszervezésére használják.
Amikor a fejlécnek van kiterjesztése. Ebben az esetben a fejléc első byte-jában beállítódik egy bit. X. A kiterjesztett fejlécben, a résztvevői táblázat után (ha van), egy szó méretű kiterjesztési fejléc található, majd ezután a kiterjesztési szavak. A kiterjesztés egy bájtokból álló halmaz, amelyet további adatok továbbítására használhat. A szabvány nem határozza meg ezeknek az adatoknak a formátumát - bármilyen lehet. Például ezek lehetnek valamilyen további beállítások az eszköz számára, amely RTP-csomagokat fogad. Néhány alkalmazáshoz azonban kifejlesztettek kiterjesztett fejléc szabványokat. Például ez megvalósult a ED-137 (A VoIP ATM Komponensek Kölcsönhatási Szabványai).
Most nézzük meg a fejléc mezőit részletesebben. Lent látható a RTP-fejléc kanonikus képe, amely színeit is a meglévő színekhez hasonlóan festettem ki.
VER — a protokoll verziószáma (jelenlegi verzió 2);
P — egy zászló, amelyet akkor állítanak be, amikor az RTP-csomagot üres bájtokkal egészítik ki az végén;
X — a kiterjesztett fejléc zászlaja;
CC — tartalmazza a folyamatos fejléc utáni CSRC-azonosítók számát (1..3 szavak után), a rajzon a táblázat nem látható;
M — a keret kezdetének vagy beszéd jelenlétének jelzője a csatornában (ha hangszünet-detektort használnak). Ha a vevő nem tartalmaz hangszünet-detektort, akkor ezt a bitet folyamatosan be kell állítani;
PTYPE — jelzi a hasznos teher formátumát;
Sorozatszám — a csomag száma, amelyet a csomagok lejátszási sorrendjének helyreállítására használunk, mivel a csomagok elérhetik a vevőt nem abban a sorrendben, ahogyan elküldték őket. A kezdeti értéknek véletlenszerűnek kell lennie, hogy ha az RTP-stream titkosítását használják, megnehezítse a feltörést. Ez a mező lehetővé teszi a csomagkihagyások észlelését is;
Időbélyeg — időbélyeg. Az idő a jelminták számában van mérve, azaz ha egy csomag 160 mintát tartalmaz, a következő csomag időbélyege 160-mal fog növekedni. Az időbélyeg kezdeti értékének véletlenszerűnek kell lennie;
SSRC — a csomagforrás azonosítója, amelynek egyedinek kell lennie. Érdemes véletlenszerűen generálni, mielőtt elindítanánk az RTP streamet.
Ha RTP-csomagok adó- vagy vevőberendezését fejleszti, többször is meg kell vizsgálnia a csomagjait a teljesítmény javítása érdekében. Javaslom, hogy ismerkedjen meg a TShark csomagszűrési használatával, amely lehetővé teszi, hogy csak azokat a csomagokat rögzítse, amelyek érdeklik Önt. Olyan környezetben, ahol tucatnyi RTP-eszköz működik, ez rendkívül értékes. A TShark parancssorában a szűrési paramétereket az "-f" opcióval adjuk meg. Ezt az opciót használtuk, amikor az 8010-es portról akartunk csomagokat rögzíteni:
-f "udp port 8010"
A szűrési paraméterek alapvetően egy halmaz kritérium, amelynek meg kell felelnie az "elfogott" csomagnak. A feltételek ellenőrizhetik a címet, a portot, a csomagban található egyes bájtok értékét. A feltételeket logikai műveletekkel, mint az "ÉS", "VAGY" stb. lehet kombinálni. Nagyon hatékony eszköz.
Ha meg szeretné nézni a mezők dinamikáját a csomagokban, akkor duplikálnia kell a kimenetet TShark egy fájlba, ahogy az az előző cikkben is bemutatásra került, a kimenet átadása TShark a bemenetre tee. Ezután a naplófájl megnyitásával less, vim vagy más olyan eszközzel, amely gyorsan képes kezelni hatalmas szöveges fájlokat és végrehajtani a sorok keresését, kiderítheti a RTP-streamben található csomagmezők viselkedésének minden részletét.
Ha meg kell hallgatnia az RTP-stream által továbbított jelet, akkor a változattal kell dolgoznia TShark grafikus felülettel Wireshark. Egyszerű egérmozdulatokkal ott hallgathatja, láthatja a jel oszcillogramját. De egy feltétellel — ha u-law vagy a-low formátumban van kódolva.
A következő egy duplex telefonkészüléket fogunk készíteni. Szerezzen be egy pár fejhallgatót és egy beszélgetőpartnert.
Forrás: habr.com
