A cikk anyaga az én .
RTP csomagstruktúra
Az utolsóban használunk TShark rögzített RTP-csomagokat cserélünk a vevőnk és az adónk között. Nos, ebben a csomag elemeit különböző színekre festjük, és beszélünk a céljukról.
Nézzük meg ugyanazt a csomagot, de színezett mezőkkel és magyarázó megjegyzésekkel:
A lista alján találhatók az RTP-csomagot alkotó bájtok, amelyek viszont az UDP-csomag hasznos terhelése (a fejléce feketével van körvonalazva). A színes hátterek az RTP fejléc bájtjait jelzik, a zöld pedig azt az adatblokkot, amely az RTP-csomag hasznos terhét tartalmazza. Az ott található adatok hexadecimális formátumban jelennek meg. Esetünkben ez az u-törvény (mu-törvény) szerint tömörített hangjel, azaz. egy minta 1 bájt méretű. Mivel az alapértelmezett mintavételezési frekvenciát (8000 Hz) használtuk, 50 Hz-es csomagsebességgel, minden RTP-csomagnak 160 bájt hasznos terhelést kell tartalmaznia. Ezt úgy fogjuk látni, hogy megszámoljuk a zöldterület bájtjait, 10 sornak kell lennie.
A szabvány szerint a hasznos adatmennyiségnek négy többszörösének kell lennie, vagyis egész számú négybájtos szavakat kell tartalmaznia. Ha előfordul, hogy a rakomány nem követi ezt a szabályt, akkor nulla értékű bájtokat kell hozzáadnia a rakomány végéhez, és be kell állítania a Padding bitet. Ez a bit az RTP fejléc első bájtjában található, és türkiz színű. Ne feledje, hogy minden hasznos adatbájt 0xFF értékű – így néz ki a csend az u-law formátumban.
Az RTP csomag fejléce 12 szükséges bájtból áll, de két esetben hosszabb is lehet:
-
Ha egy csomag több forrásból származó jelek (RTP folyamok) keverésével kapott audiojelet hordoz, akkor a fejléc első 12 bájtja után egy táblázat található azon forrásazonosítók listájával, amelyek hasznos adatait felhasználták a csomag hasznos adatának létrehozásához. Ebben az esetben a fejléc első bájtjának alsó négy bitjében (mező A közreműködő forrásazonosítók számítanak) fel van tüntetve a források száma. A mező mérete 4 bites, így a táblázat legfeljebb 15 forrásazonosítót tartalmazhat. Mindegyik 4 bájtot vesz igénybe. Ez a táblázat konferenciahívás szervezésekor használatos.
-
Amikor a címnek van kiterjesztése. Ebben az esetben a fejléc első bájtjában lévő bit be van állítva X. A kiterjesztett fejlécben a résztvevők táblázata után (ha van) egy egyszavas kiterjesztésű fejléc található, amelyet a kiterjesztés szavai követnek. A kiterjesztés bájtok halmaza, amelyet további adatok átvitelére használhat. A szabvány nem határozza meg ezen adatok formátumát – bármi lehet. Például ezek lehetnek további beállítások az RTP-csomagokat fogadó eszközhöz. Egyes alkalmazásokhoz azonban kiterjesztett fejléc-szabványokat fejlesztettek ki. Ez történik például a szabványban szereplő kommunikációs berendezések esetében ED-137 (VoIP ATM komponensek interoperabilitási szabványai).
Most nézzük meg részletesebben a fejlécmezőket. Alább egy kanonikus kép egy RTP fejléc szerkezetével, aminek szintén nem tudtam ellenállni, és ugyanolyan színekre festettem.
VER — protokoll verziószáma (jelenlegi verzió 2);
P — egy zászló, amely olyan esetekben kerül beállításra, amikor egy RTP-csomag a végén üres bájtokkal van kiegészítve;
X — jelölje meg, hogy a fejléc ki van terjesztve;
CC — a konstans fejlécet követő CSRC azonosítók számát tartalmazza (1..3 szavak után), a táblázat nem látható az ábrán;
M — a keret kezdetének jelzője vagy a beszéd jelenléte a csatornában (ha beszédszünet-érzékelőt használnak). Ha a vevő nem tartalmaz beszédszünet érzékelőt, akkor ezt a bitet állandóan be kell állítani;
PTYPE — jelzi a hasznos teher formátumát;
Sorszám — csomagszám, a csomaglejátszás sorrendjének visszaállítására szolgál, mivel a valós helyzet az, amikor a csomagok a küldésük sorrendjétől eltérő sorrendben juthatnak el a vevőhöz. A kezdeti értéknek véletlenszerűnek kell lennie; ez azért történik, hogy RTP adatfolyam titkosítás használata esetén nehéz legyen feltörni. Ez a mező lehetővé teszi a csomagkiesések észlelését is;
Timestamp - időbélyeg. Az időt jelmintákban mérjük, azaz. ha egy csomag 160 mintát tartalmaz, akkor a következő csomag időbélyege 160-al nagyobb lesz. Az időbélyeg kezdeti értékének véletlenszerűnek kell lennie;
SSRC — a csomag forrásazonosítója, annak egyedinek kell lennie. Jobb véletlenszerűen generálni az RTP folyam elindítása előtt.
Ha saját RTP-csomagok adóját vagy vevőjét fejleszti, akkor többször meg kell néznie a csomagjait, ezért a termelékenység növelése érdekében azt javaslom, hogy sajátítsa el a csomagszűrést a TSharkban, amely lehetővé teszi, hogy csak azokat a csomagokat rögzítse. amelyek érdekelnek téged. Olyan körülmények között, amikor több tucat RTP-eszköz működik a hálózaton, ez nagyon értékes. A TShark parancssorban a szűrési paraméterek a "-f" kapcsolóval vannak megadva. Ezt az opciót használtuk, amikor csomagokat akartunk rögzíteni a 8010-es portról:
-f "udp port 8010"
A szűrési paraméterek lényegében olyan kritériumok összessége, amelyeknek a „fogott” csomagnak meg kell felelnie. A feltétel ellenőrizheti a csomagban lévő adott bájt címét, portját vagy értékét. A feltételek "ÉS", "VAGY" stb. logikai műveletekkel kombinálhatók. Nagyon erős eszköz.
Ha kötegekben szeretné megtekinteni a mezőváltozások dinamikáját, akkor meg kell másolnia a kimenetet TShark fájlba, ahogy az előző cikkben is látható volt, kimeneti átvitel segítségével TShark a bejáratnál tee. Ezután nyissa meg a naplófájlt a segítségével kevesebb, vim vagy egy másik eszköz, amely gyorsan tud dolgozni hatalmas szöveges fájlokkal és keresni sztringeket, megtudhatja az RTP-folyamban lévő csomagmezők viselkedésének minden árnyalatát.
Ha meg kell hallgatnia az RTP adatfolyam által továbbított jelet, akkor a verziót kell használnia TShark vizuális felülettel Wireshark. Az egérrel végzett egyszerű manipulációk segítségével meghallgathatja és láthatja a jel oszcillogramját. De egy feltétellel - ha u-law vagy a-low formátumban van kódolva.
Következő Duplex kaputelefont készítünk Önnel. Készítsen néhány headsetet és egy beszélgetőpartnert.
Forrás: will.com