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