Матэрыял артыкула ўзяты з майго .
Структура RTP-пакета
У мінулым мы з дапамогай TShark выканалі захоп RTP-пакетаў, якімі абменьваліся нашы прымач і перадатчык. Ну а ў гэтай мы расфарбуем элементы пакета ў розныя колеры і пагаворым аб іх прызначэнні.
Зірнем на той жа пакет, але ўжо з падфарбаванымі палямі і з тлумачальнымі надпісамі:
У ніжняй частцы лістынга падфарбаваны байты, якія складаюць RTP-пакет, а ён у сваю чаргу з'яўляецца карыснай нагрузкай UDP-пакета (яго загаловак абведзены чорнай лініяй). Каляровымі фонамі пазначаны байты RTP-загалоўка, а зялёным колерам выдзелены блок дадзеных, які змяшчае карысную нагрузку RTP-пакета. Дадзеныя там прадстаўлены ў шаснаццацірычным фармаце. У нашым выпадку гэта гукавы сігнал сціснуты па u-закону (мю-закону), г.зн. адзін адлік мае памер 1 байт. Паколькі мы выкарыстоўвалі сэмплінгрэйт, усталяваны па змаўчанні (8000 Гц), то пры частаце пакетаў 50 Гц кожны RTP-пакет павінен утрымоўваць 160 байт карыснай нагрузкі. Гэта мы і ўбачым, палічыўшы байты ў зялёнай вобласці, іх павінна аказацца 10 радкоў.
Па стандарце, колькасць дадзеных у карыснай нагрузцы павінна быць кратна чатыром, ці іншымі словамі павінна змяшчаць цэлую колькасць чатырохбайтных слоў. Калі здарыцца так, што ваша карысная нагрузка не будзе адпавядаць гэтаму правілу, то ў канцы карыснай нагрузкі трэба дадаць байты з нулявымі значэннямі і ўсталяваць біт Padding (Дадатак). Гэты біт размешчаны ў першым байце RTP-загалоўка, ён падфарбаваны бірузовым колерам. Звярніце ўвагу, што ўсе байты карысна нагрузкі маюць значэнне 0xFF - так выглядае цішыня ў фармаце u-law.
Загаловак RTP-пакета складаецца з 12 абавязковых байтаў, але ў двух выпадках ён можа быць даўжэй:
Калі пакет нясе гукавы сігнал атрыманы змешваннем сігналаў ад некалькіх крыніц (RTP-струменяў), то пасля першых 12 байт загалоўка размяшчаецца табліца са спісам ідэнтыфікатараў крыніц, карысныя нагрузкі якіх былі скарыстаны для стварэння карыснай нагрузкі гэтага пакета (мал. XNUMX). Contributing source identifiers count) паказваецца колькасць крыніц. Памер поля складае 4 біты, адпаведна табліца можа змяшчаць да 15 ідэнтыфікатараў крыніц. Кожны з якіх займае 4 байты. Гэтая табліца выкарыстоўваецца пры арганізацыі канферэнц-сувязі.
Калі загаловак мае пашырэнне. У гэтым выпадку ў першым байце загалоўка усталёўваецца біт X. У пашыраным загалоўку, пасля табліцы ўдзельнікаў ( калі яны ёсць), размяшчаецца загаловак пашырэння ў адно слова, а ўслед за ім словы пашырэння гэтае набор байтаў якія вы можаце выкарыстоўваць для таго каб перадаваць дадатковыя дадзеныя. загалоўка. Так зроблена напрыклад для сродкаў сувязі ў стандарце ED-137 (Interoperability Standards for VoIP ATM Components).
Цяпер разгледзім палі загалоўка больш дэталёва. Ніжэй намалявана кананічная карцінка са структурай RTP-загалоўка, якую я таксама не ўтрымаўся і расфарбаваў у тыя ж колеры.
VER - нумар версіі пратакола (бягучая версія 2);
P - сцяг, які ўсталёўваецца ў выпадках, калі RTP-пакет дапаўняецца пустымі байтамі на канцы;
X - сцяг таго, што загаловак пашыраны;
CC - змяшчае колькасць CSRC-ідэнтыфікатараў, якія ідуць за пастаянным загалоўкам (пасля слоў 1..3), на малюнку табліца не паказана;
M - маркер пачатку кадра або наяўнасці гаворкі ў канале (калі выкарыстоўваецца дэтэктар паўзаў у гаворкі). Калі прымач не ўтрымоўвае дэтэктар паўзаў у гаворкі, то гэты біт павінен быць усталяваны ўвесь час;
PTYPE - паказвае фармат карыснай нагрузкі;
Sequence number - нумар пакета, выкарыстоўваецца для аднаўлення парадку прайгравання пакетаў, бо рэальная сітуацыя калі пакеты могуць дасягнуць прымача не ў тым парадку ў якім іх адправілі. Пачатковае значэнне павінна быць выпадковым, гэта робіцца для таго, каб калі ўжываецца шыфраванне RTP-струменю абцяжарыць яго ўзлом. Таксама гэтае поле дазваляе выяўляць пропускі пакетаў;
Timestamp - пазнака часу. Час вымяраецца ў выбарках сігналу, г.зн. калі пакет утрымоўвае 160 выбарак, то пазнака часу наступнага пакета будзе больш на 160. Пачатковае значэнне часавай пазнакі павінна быць выпадковым;
SSRC - Ідэнтыфікатар крыніцы пакета, ён павінен быць унікальным. Яго лепш генераваць выпадковым чынам перад запускам RTP-струменю.
Калі вы будзеце распрацоўваць свой перадатчык або прыёмнік RTP-пакетаў, вам давядзецца не раз разглядаць вашыя пакеты, каб каб павысіць прадуктыўнасць я вам рэкамендую асвоіць выкарыстанне фільтрацыі пакетаў у TShark, яна дазваляе захопліваць толькі тыя пакеты якія ўяўляюць цікавасць для вас. Ва ўмовах, калі ў сетцы працуюць дзясяткі RTP-прылад гэта вельмі каштоўна. У камандным радку TShark параметры фільтрацыі задаюцца опцыяй "-f". Мы выкарыстоўвалі гэтую опцыю калі хацелі захапіць пакеты з порта 8010:
-f "udp port 8010"
Параметры фільтрацыі па сваёй сутнасці гэта набор крытэрыяў якім павінен адпавядаць "які адлоўліваецца" пакет. Умова можа правяраць адрас, порт, значэнне вызначанага байта ў пакеце. Умовы можна аб'ядноўваць лагічнымі аперацыямі "І", "АБО" і да т.п. Вельмі магутная прылада.
Калі вы жадаеце прагледзець дынаміку змены палёў у пакетах, вам запатрабуецца прадубліраваць выснову TShark у файл, як гэта было паказана ў мінулым артыкуле, з дапамогай перадачы высновы TShark на ўваход трайнік. Далей адкрыўшы лог-файл з дапамогай less, vim ці іншай прыладай, здольным хутка працаваць з велізарнымі тэкставымі файламі і выконваць пошук радкоў, вы зможаце высветліць усе нюансы паводзін палёў пакетаў у RTP-струмені.
Калі вам запатрабуецца праслухаць сігнал які перадаецца RTP-струменем, тое трэба скарыстацца версіяй TShark c візуальным інтэрфейсам Wireshark. Шляхам нескладаных маніпуляцый мышшу тамака можна праслухаць, убачыць асцылаграму сігналу. Але пры адной умове - калі ён будзе закадаваны ў фармаце u-law або a-low.
У наступнай мы зробім з вамі дуплексную перагаворную прыладу. Назапасьцеся парай гарнітур і адным суразмоўцам.
Крыніца: habr.com
