Изучаем VoIP-движок Mediastreamer2. Часть 8

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Материал статьи взят с моего дзен-канала.


Структура RTP-пакета


В прошлой статье мы с помощью TShark выполнили захват 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-заголовка, которую я тоже не удержался и раскрасил в те же цвета.



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 на вход tee. Далее открыв лог-файл с помощью less, vim или другим инструментом, способным быстро работать с огромными текстовыми файлами и выполнять поиск строк, вы сможете выяснить все нюансы поведения полей пакетов в RTP-потоке.


Если вам потребуется прослушать сигнал передаваемый RTP-потоком, то нужно воспользоваться версией TShark c визуальным интерфейсом Wireshark. Путем несложных манипуляций мышью там можно прослушать, увидеть осциллограмму сигнала. Но при одном условии — если он будет закодирован в формате u-law или a-low.


В следующей статье мы сделаем с вами дуплексное переговорное устройство. Запаситесь парой гарнитур и одним собеседником.

Источник: https://habr.com/ru/post/496666/


Интересные статьи

Интересные статьи

Как стать DevOps инженером за полгода или даже быстрее. Часть 1. Введение Как стать DevOps инженером за полгода или даже быстрее. Часть 2. Конфигурирование Как стать DevOps инженер...
Пока за окном творился греческий и бумажный апокалипсис, а макаронный монстр пожирал вермишель на полках мегамаркетов, в стенах НИИ плодотворно кипела работа над измерениями тепловых потерь о...
В данной статье будет проведено сравнение средств резервного копирования, но сначала стоит узнать, как они быстро и хорошо справляются с восстановлением данных из резервных копий. Для простоты...
Есть такие области знания, которые «аршином общим не измерить...». В принципе, в моей «домашней» области, коллоидной химии, под такое направление можно спокойно помещать любое фундаментальное пон...
Это вторая статья из цикла про то, как мы в Citymobil увеличивали стабильность сервиса (первую можете почитать здесь). В этой статье я углублюсь в конкретику разбора аварий. Но перед этим я о...