Протоколы RTSP, RTP, UDP и TCP в системах видеонаблюдения. IP-телефония: от медных проводов до цифровой обработки сигнала

2. Основные понятия

3. Протокол передачи данных RTP

Принципы построения протокола RTP

Методы контроля работы

Формат заголовка протокола RTP

Протокол резервирования ресурсов - RSVP

Литература

2.1. Групповая аудиоконференцсвязь

2.2. Видеоконференцсвязь

2.3. Понятие о микшерах и трансляторах

2.4. Порядок байтов, выравнивание и формат меток времени

3.1. Поля фиксированного заголовка RTP

3.2. Сеансы связи RTP

3.3. Определяемые профилем изменения заголовка RTP

3.4. Расширение заголовка RTP

И что тут сложного?

Ищем подходящее решение…

Что можно измерить по полям RTP-пакета?

Как идентифицировать RTP-потоки?

Как отделить RTP-пакеты от остального трафика?

Двигаемся дальше…

Чем в итоге занят сервер?

Cons and pros

Резюме

17.09.2020

Стремительный рост Internet предъявляет новые требования к скорости и объемам передачи данных. И для того чтобы удовлетворить все эти запросы, одного увеличения емкости сети недостаточно, необходимы разумные и эффективные методы управления трафиком и загруженностью линий передачи.

В приложениях реального времени отправитель генерирует поток данных с постоянной скоростью, а получатель (или получатели) должен предоставлять эти данные приложению с той же самой скоростью. Такие приложения включают, например, аудио- и видеоконференции, живое видео, удаленную диагностику в медицине, компьютерную телефонию, распределенное интерактивное моделирование, игры, мониторинг в реальном времени и др.

Наиболее широко используемый протокол транспортного уровня - это TCP. Несмотря на то что TCP позволяет поддерживать множество разнообразных распределенных приложений, он не подходит для приложений реального времени.

Эту задачу и призван решить новый транспортный протокол реального времени - RTP (Real-Time Transport Protocol), который гарантирует доставку данных одному или более адресатам с задержкой в заданных пределах, т. е. данные могут быть воспроизведены в реальном времени.

RTP не поддерживает каких-либо механизмов доставки пакетов, обеспечения достоверности передачи или надежности соединения. Эти все функции возлагаются на транспортный протокол. RTP работает поверх UDP и может поддерживать передачу данных в реальном времени между несколькими участниками RTP-сеанса.

Примечание

Для каждого участника RTP сеанс определяется парой транспортных адресов назначения пакетов (один сетевой адрес - IP и пара портов: RTP и RTCP).

Пакеты RTP содержат следующие поля: идентификатор отправителя, указывающий, кто из участников генерирует данные, отметки о времени генерирования пакета, чтобы данные могли быть воспроизведены принимающей стороной с правильными интервалами, информация о порядке передачи, а также информация о характере содержимого пакета, например, о типе кодировки видеоданных (MPEG, Indeo и др.). Наличие такой информации позволяет оценить величину начальной задержки и объема буфера передачи.

Примечание

В типичной среде реального времени отправитель генерирует пакеты с постоянной скоростью. Они отправляются через одинаковые интервалы времени, проходят через сеть и принимаются получателем, воспроизводящим данные в реальном времени по их получении. Однако ввиду изменения времени задержки при передаче пакетов по сети, они могут прибывать через нерегулярные интервалы времени. Для компенсации этого эффекта поступающие пакеты буферизуются, придерживаются на некоторое время и затем предоставляются с постоянной скоростью программному обеспечению, генерирующему вывод. Поэтому для функционирования протокола реального времени необходимо, чтобы каждый пакет содержал временную метку- таким образом получатель может воспроизвести поступающие данные с той же скоростью, что и отправитель.

Поскольку RTP определяет (и регулирует) формат полезной нагрузки передаваемых данных, с этим напрямую связана концепция синхронизации, за которую частично отвечает механизм трансляции RTP - микшер. Принимая потоки пакетов RTP от одного или более источников, микшер, комбинирует их и посылает новый поток пакетов RTP одному или более получателям. Микшер может просто комбинировать данные, а также изменять их формат, например, при комбинировании нескольких источников звука. Предположим, что новая система хочет принять участие в сеансе, но ее канал до сети не имеет достаточной емкости для поддержки всех потоков RTP, тогда микшер получает все эти потоки, объединяет их в один и передает последний новому члену сеанса. При получении нескольких потоков микшер просто складывает значения импульсно-кодовой модуляции. Заголовок RTP, генерируемый микшером, включает идентификатор отправителя, чьи данные присутствуют в пакете.

Более простое устройство - транслятор, создает один исходящий пакет RTP для каждого поступающего пакета RTP. Этот механизм может изменить формат данных в пакете или использовать иной комплект низкоуровневых протоколов для передачи данных из одного домена в другой. Например, потенциальный получатель может оказаться не в состоянии обрабатывать высокоскоростной видеосигнал, используемый другими участниками сеанса. Транслятор конвертирует видео в формат более низкого качества, требующий не такой высокой скорости передачи данных.

Протокол RTP используется только для передачи пользовательских данных - обычно многоадресной - всем участникам сеанса. Совместно с RTP работает протокол RTCP (Real-time Transport Control Protocol), основная задача которого состоит в обеспечении управления передачей RTP. RTCP использует тот же самый базовый транспортный протокол, что и RTP (обычно UDP), но другой номер порта.

RTCP выполняет несколько функций:

Обеспечение и контроль качества услуг и обратная связь в случае перегрузки. Так как RTCP-пакеты являются многоадресными, все участники сеанса могут оценить, насколько хороши работа и прием других участников. Сообщения отправителя позволяют получателям оценить скорость данных и качество передачи. Сообщения получателей содержат информацию о проблемах, с которыми они сталкиваются, включая утерю пакетов и избыточную неравномерность передачи. Обратная связь с получателями важна также для диагностирования ошибок при распространении. Анализируя сообщения всех участников сеанса, администратор сети может определить, касается данная проблема одного участника или носит общий характер. Если приложение-отправитель приходит к выводу, что проблема характерна для системы в целом, например, по причине отказа одного из каналов связи, то оно может увеличить степень сжатия данных за счет снижения качества или вообще отказаться от передачи видео - это позволяет передавать данные по соединению низкой емкости.
Идентификация отправителя. Пакеты RTCP содержат стандартное текстовое описание отправителя. Они предоставляют больше информации об отправителе пакетов данных, чем случайным образом выбранный идентификатор источника синхронизации. Кроме того, они помогают пользователю идентифицировать потоки, относящиеся к различным сеансам.
Оценка размеров сеанса и масштабирование. Для обеспечения качества услуг и обратной связи с целью управления загруженностью, а также с целью идентификации отправителя, все участники периодически посылают пакеты RTCP. Частота передачи этих пакетов снижается с ростом числа участников. При небольшом числе участников один пакет RTCP посылается максимум каждые 5 секунд. RFC-1889 описывает алгоритм, согласно которому участники ограничивают частоту RTCP-пакетов в зависимости от общего числа участников. Цель состоит в том, чтобы трафик RTCP не превышал 5% от общего трафика сеанса.

RTP - потоко -ориентированный протокол. Заголовок RTP-пакета создавался с учетом потребностей передачи в реальном времени. Он содержит информацию о порядке следования пакетов, чтобы поток данных был правильно собран на принимающем конце, и временную метку для правильного чередования кадров при воспроизведении и для синхронизации нескольких потоков данных, например, видео и аудио.

Каждый пакет RTP имеет основной заголовок, а также, возможно, дополнительные поля, специфичные для приложения.

Использование TCP в качестве транспортного протокола для этих приложений невозможно по нескольким причинам:

Этот протокол позволяет установить соединение только между двумя конечными точками, следовательно, он не подходит для многоадресной передачи.
TCP предусматривает повторную передачу потерянных сегментов, прибывающих, когда приложение реального времени уже их не ждет.
TCP не имеет удобного механизма привязки информации о синхронизации к сегментам - дополнительное требование приложений реального времени.

Другой широко используемый протокол транспортного уровня - LJDP не имеет части ограничений TCP, но и он не предоставляет критической информации о синхронизации.

Несмотря на то, что каждое приложение реального времени может иметь свои собственные механизмы для поддержки передачи в реальном времени, они имеют много общих черт, а это делает определение единого протокола весьма желательным.

Эту задачу и призван решить новый транспортный протокол реального времени - RTP (Real-time Transport Protocol), который гарантирует доставку данных одному или более адресатам с задержкой в заданных пределах, т. е. данные могут быть воспроизведены в реальном времени.

На рис. 1 представлен фиксированный RTP-заголовок, который содержит ряд полей, идентифицирующих такие элементы, как формат пакета, порядковый номер, источники, границы и тип полезной нагрузки. За фиксированным заголовком могут следовать другие поля, содержащие дополнительную информацию о данных.

Рис. 1. Фиксированный RTP-заголовок.

V (2 бита). Поле версии. Текущая версия - вторая.
Р (1 бит). Поле заполнения. Это поле сигнализирует о наличии заполняющих октетов в конце полезной нагрузки. Заполнение применяется, когда приложение требует, чтобы размер полезной нагрузки был кратен, например, 32 битам. В этом случае последний октет указывает число заполняющих октетов.
Х (1 бит). Поле расширения заголовка. Когда это поле задано, то за основным заголовком следует еще один дополнительный, используемый в экспериментальных расширениях RTP.
СС (4 бита). Поле числа отправителей. Это поле содержит число идентификаторов отправителей, чьи данные находятся в пакете, причем сами идентификаторы следуют за основным заголовком.
М (1 бит). Поле маркера. Смысл бита маркера зависит от типа полезной нагрузки. Бит маркера используется обычно для указания границ потока данных. В случае видео он задает конец кадра. В случае голоса он задает начало речи после периода молчания.
РТ (7 бит). Поле типа полезной нагрузки. Это поле идентифицирует тип полезной нагрузки и формат данных, включая сжатие и шифрование. В стационарном состоянии отправитель использует только один тип полезной нагрузки в течение сеанса, но он может его изменить в ответ на изменение условий, если об этом сигнализирует протокол управления передачей в реальном времени (Real-Time Transport Control Protocol).
Sequence Number (16 бит). Поле порядкового номера. Каждый источник начинает нумеровать пакеты с произвольного номера, увеличиваемого затем на единицу с каждым посланным пакетом данных RTP. Это позволяет обнаружить потерю пакетов и определить порядок пакетов с одинаковой отметкой о времени. Несколько последовательных пакетов могут иметь одну и ту же отметку о времени, если логически они порождены в один и тот же момент, как, например, пакеты, принадлежащие к одному и тому же видеокадру.
Timestamp (32 бита). Поле отметки о времени. Это поле содержит момент времени, в который первый октет данных полезной нагрузки был создан. Единицы, в которых время указывается в этом поле, зависят от типа полезной нагрузки. Значение определяется по локальным часам отправителя.
Synchronization Source (SSRC) Identifier (32 бита). Поле идентификатора источника синхронизации: генерируемое случайным образом число, уникальным образом идентифицирующее источник в течение сеанса и независимое от сетевого адреса. Это число играет важную роль при обработке поступившей порции данных от одного источника.
Contributing source (CSRC) Identifier (32 бита). Список полей идентификаторов источника, "подмешанных" в основной поток, например, с помощью микшера. Микшер вставляет целый список SSRC идентификаторов источников, которые участвовали в построении данного RTP-пакета. Этот список и называется CSRC. Количество элементов в списке: от 0 до 15. Если число участников более 15 - выбираются первые 15. Примером может служить аудио-конференция, в RTP-пакеты которой собраны речи всех участников, каждый со своим SSRC - они-то и образуют список CSRC. При этом вся конференция имеет общий SSRC.

Протокол RTCP, как и всякий управляющий протокол, значительно сложнее и по структуре, и по выполняемым функциям (сравните, например, протоколы IP и TCP). Хотя основу протокола RTCP составляет RTP, он содержит множество дополнительных полей, с помощью которых он реализует свои функции.

Решить проблему приоритетности для чувствительных к задержкам данных, в противовес традиционным данным, для которых задержки не столь критичны, призван протокол резервирования ресурсов - RSVP, находящийся в настоящее время на рассмотрении в группе инженерной поддержки Internet (IETF). RSVP позволяет конечным системам резервировать сетевые ресурсы для получения необходимого качества услуг, в особенности ресурсы для графика реального времени по протоколу RTP. RSVP касается прежде всего маршрутизаторов, хотя приложения в конечных узлах также должны знать, как использовать RSVP в целях резервирования необходимой полосы пропускания для данного класса услуг или уровня приоритета.

RTP вместе с другими описанными стандартами позволяет с успехом передавать видео и аудио по обычным IP-сетям. RTP/RTCP/RSVP - стандартизованное решение для сетей с передачей данных в реальном времени. Единственным его недостатком является то, что оно предназначено только для IP-сетей. Однако это ограничение временное: сети так или иначе будут развиваться в этом направлении. Данное решение обещает решить проблему передачи чувствительных к задержкам данных по Internet.

Описание протокола RTP можно найти в RFC-1889.

Одной из важнейших тенденций в эволюции современных телекоммуникаций является развитие средств IP-телефонии - множества новых технологий, обеспечивающих передачу мультимедийных сообщений (речи, данных, видео) через информационно-вычислительные сети (ИВС), построенные на базе протокола IP (Internet Protocol), в том числе локальные, корпоративные, глобальные вычислительные сети и сеть Internet. Понятие IP-телефонии включает в себя Internet-телефонию, позволяющую организовать телефонную связь между абонентами сети Internet, между абонентами телефонных сетей общего пользование (ТСОП) через Internet, а также телефонную связь абонентов ТСОП и Internet друг с другом.

IP-телефония обладает рядом несомненных достоинств, обеспечивающих ее быстрое развитие и расширение рынка компьютерной телефонии. Она выгодна конечным пользователям, которые обеспечиваются телефонной связью при довольно низкой поминутной оплате. Компаниям, имеющим удаленные филиалы, IP-технология позволяет организовать речевую связь при помощи уже существующих корпоративных IP-сетей. Вместо нескольких сетей связи при этом используется одна. Безусловным преимуществом IP-телефонии перед обычным телефоном является также возможность предоставления дополнительных услуг за счет использования мультимедийного компьютера и различных Internet-приложений. Таким образом, благодаря IP-телефонии предприятия и частные лица могут расширить возможности организации связи путем включения в них современной видеоконференцсвязи, совместного использования приложений, средств типа электронной чертежной доски (whiteboard) и т.п.

Какие международные стандарты и протоколы регламентируют основные параметры и алгоритмы функционирования аппаратных и программных средств связи, используемых в IP-телефонии? Очевидно, как следует из названия, данная технология построена на базе протокола IP, который, впрочем, используется не только для телефонии: первоначально он был разработан для передачи цифровых данных в ИВС с коммутацией пакетов.

В сетях, не обеспечивающих гарантированное качество обслуживания (к ним относятся сети, построенные на основе протокола IP), пакеты могут теряться, может изменяться порядок их поступления, данные, передаваемые в пакетах, могут искажаться. Для обеспечения надежной доставки передаваемой информации в этих условиях используются различные процедуры транспортного уровня. При передаче цифровых данных для этой цели применяется протокол ТСР (Transmission Control Protocol). Данный протокол обеспечивает надежную доставку данных и восстанавливает исходный порядок следования пакетов. Если в пакете обнаружена ошибка, или пакет теряется, процедуры TCP посылают запрос на повторную передачу.

Для приложений аудио- и видеоконференцсвязи задержки пакетов гораздо в большей степени влияют на качество сигнала, чем отдельные искажения данных. Различия в задержках могут приводить к появлению пауз. Для таких приложений необходим другой протокол транспортного уровня, обеспечивающий восстановление исходной последовательности пакетов, их доставку с минимальной задержкой, воспроизведение в реальном масштабе времени в точно заданные моменты, распознавание типа трафика, групповую или двухстороннюю связь. Таким протоколом является транспортный протокол реального времени RTP (Real-Time Transport Protocol). Данный протокол регламентирует передачу мультимедийных данных в пакетах через ИВС на транспортном уровне и дополняется протоколом управления передачей данных в реальном масштабе времени RTCP (Real-Time Control Protocol). Протокол RTCP, в свою очередь, обеспечивает контроль доставки мультимедийных данных, контроль качества обслуживания, передачу информации об участниках текущего сеанса связи, управление и идентификацию, и иногда считается частью протокола RTP.

Во многих публикациях, посвященных IP-телефонии, отмечается, что большая часть сетевого оборудования и специального программного обеспечения для данной технологии разрабатывается на базе Рекомендации Сектора стандартизации электросвязи Международного союза электросвязи (МСЭ-Т) Н.323 (в том числе, TAPI 3.0, NetMeeting 2.0 и т.д.). Как соотносится Н.323 с протоколами RTP и RTCP? Н.323 - это широкий концептуальный каркас, включающий множество других стандартов, каждый из которых отвечает за различные аспекты передачи информации. Большинство из этих стандартов, например, стандарты аудио- и видеокодеков, имеют широкое применение не только в IP-телефонии. Что касается протоколов RTP/RTCP, то они составляют основу стандарта H.323, ориентированы на обеспечение именно IP-технологии, лежат в основе организации IP-телефонии. Рассмотрению данных протоколов и посвящена эта статья.

Транспортный протокол реального времени RTP обеспечивает сквозную передачу в реальном времени мультимедийных данных, таких как интерактивное аудио и видео. Этот протокол реализует распознавание типа трафика, нумерацию последовательности пакетов, работу с метками времени и контроль передачи.

Действие протокола RTP сводится к присваиванию каждому исходящему пакету временных меток. На приемной стороне временные метки пакетов указывают на то, в какой последовательности и с какими задержками их необходимо воспроизводить. Поддержка RTP и RTCP позволяет принимающему узлу располагать принимаемые пакеты в надлежащем порядке, снижать влияние неравномерности времени задержки пакетов в сети на качество сигнала и восстанавливать синхронизацию между аудио и видео, чтобы поступающая информация могла правильно прослушиваться и просматриваться пользователями.

Заметим, что RTP сам по себе не имеет никакого механизма, гарантирующего своевременную передачу данных и качество обслуживания, но для обеспечения этого использует службы нижележащего уровня. Он не предотвращает нарушения порядка следования пакетов, но при этом и не предполагает, что основная сеть абсолютно надежна и передает пакеты в нужной последовательности. Порядковые номера, включенные в RTP, позволяют получателю восстанавливать последовательность пакетов отправителя.

Протокол RTP поддерживает как двустороннюю связь, так и передачу данных группе адресатов, если групповая передача поддерживается нижележащей сетью. RTP предназначен для обеспечения информации, требуемой отдельным приложениям, и в большинстве случаев интегрируется в работу приложения.

Хотя протокол RTP считается протоколом транспортного уровня, он функционирует обычно поверх другого протокола транспортного уровня UDP (User Datagram Protocol). Оба протокола вносят свои доли в функциональность транспортного уровня. Следует отметить, что RTP и RTCP являются независимыми от нижележащих уровней - транспортного и сетевого, поэтому протоколы RTP/RTCP могут использоваться с другими подходящими транспортными протоколами.

Протокольные блоки данных RTP/RTCP называются пакетами. Пакеты, формируемые в соответствии с протоколом RTP и служащие для передачи мультимедийных данных, называются информационными пакетами или пакетами данных (data packets), а пакеты, генерируемые в соответствии с протоколом RTCP и служащие для передачи служебной информации, требуемой для надежной работы телеконференции, называют пакетами управления или служебными пакетами (control packets). Пакет RTP включает в свой состав фиксированный заголовок, необязательное расширение заголовка переменной длины и поле данных. Пакет RTCP начинается с фиксированной части (подобной фиксированной части информационных пакетов RTP), за которой следуют структурные элементы, имеющие переменную длину.

Для того, чтобы протокол RTP был более гибким и мог применяться для различных приложений, некоторые его параметры сделаны преднамеренно не определенными, но зато в нем предусмотрено понятие профиля. Профиль (profile) - это набор параметров протоколов RTP и RTCP для конкретного класса приложений, определяющий особенности их функционирования. В профиле определяются использование отдельных полей заголовков пакетов, типы трафика, дополнения к заголовкам и расширения заголовков, типы пакетов, услуги и алгоритмы обеспечения безопасности связи, особенности использования протокола нижележащего уровня и т.д (в качестве примере в разделе 11 рассмотрен предложенный в RFC 1890 профиль RTP для аудио- и видеоконференций с минимальным управлением). Каждое приложение обычно работает только с одним профилем, и задание типа профиля происходит путем выбора соответствующего приложения. Никакой явной индикации типа профиля номером порта, идентификатором протокола и т.п. не предусмотрено.

Таким образом, полная спецификация RTP для конкретного приложения должна включать дополнительные документы, к которым относятся описание профиля, а также описание формата трафика, определяющее, как трафик конкретного типа, такой как аудио или видео, будет обрабатываться в RTP.

Особенности передачи мультимедийных данных при проведении аудио- и видеоконференций рассмотрены в следующих разделах.

Для организации групповой аудиоконференцсвязи требуется многопользовательский групповой адрес и два порта. При этом один порт необходим для обмена звуковыми данными, а другой используется для пакетов управления протокола RTCP. Информация о групповом адресе и портах передается предполагаемым участникам телеконференции. Если требуется секретность, то информационные и управляющие пакеты могут быть зашифрованы, как определено в разделе 7.1, в этом случае также должен быть сгенерирован и распределен ключ шифрования.

Приложение аудиоконференцсвязи, используемое каждым участником конференции, посылает звуковые данные малыми порциями, например, продолжительностью 20 мс. Каждой порции звуковых данных предшествует заголовок RTP; заголовок RTP и данные поочередно формируются (инкапсулируются) в пакет UDP. Заголовок RTP показывает, какой тип кодирования звука (например, ИКМ, АДИКМ или LPC) использовался при формировании данных в пакете. Это дает возможность изменять тип кодирования в процессе конференции, например, при появлении нового участника, который использует линию связи с низкой полосой пропускания, или при перегрузках сети.

В сети Internet, как и в других сетях передачи данных с коммутацией пакетов, пакеты иногда теряются и переупорядочиваются, а также задерживаются на различное время. Для противодействия этим событиям заголовок RTP содержит временную метку и порядковый номер, которые позволяют получателям восстановить синхронизацию в исходном виде так, чтобы, например, участки звукового сигнала воспроизводились динамиком непрерывно каждые 20 мс. Эта реконструкция синхронизации выполняется отдельно и независимо для каждого источника пакетов RTP в телеконференции. Порядковый номер может также использоваться получателем для оценки количества потерянных пакетов.

Так как участники телеконференции могут вступать и выходить из нее во время ее проведения, то полезно знать, кто участвует в ней в данный момент, и как хорошо участники конференции получают звуковые данные. Для этой цели каждый экземпляр звукового приложения во время конференции периодически выдает на порт управления (порт RTCP) для приложений всех остальных участников сообщения о приеме пакетов с указанием имени своего пользователя. Сообщение о приеме указывает, как хорошо слышим текущий оратор, и может использоваться для управления адаптивными кодерами. В дополнение к имени пользователя, может быть включена также другая информация идентификации для контроля полосы пропускания. При выходе из конференции сайт посылает пакет BYE протокола RTCP.

Если в телеконференции используются и звуковые, и видеосигналы, то они передаются отдельно. Для передачи каждого типа трафика независимо от другого спецификацией протокола вводится понятие сеанса связи RTP (см. список используемых сокращений и терминов). Сеанс определяется конкретной парой транспортных адресов назначения (один сетевой адрес плюс пара портов для RTP и RTCP). Пакеты для каждого типа трафика передаются с использованием двух различных пар портов UDP и/или групповых адресов. Никакого непосредственного соединения на уровне RTP между аудио- и видеосеансами связи не имеется, за исключением того, что пользователь, участвующий в обоих сеансах, должен использовать одно и то же каноническое имя в RTCP-пакетах для обоих сеансов так, чтобы сеансы могли быть связаны.

Одна из причин такого разделения состоит в том, что некоторым участникам конференции необходимо позволить получать только один тип трафика, если они этого желают. Несмотря на разделение, синхронное воспроизведение мультимедийных данных источника (звука и видео) может быть достигнуто при использовании информации таймирования, которая переносится в пакетах RTCP для обоих сеансов.

Не всегда все сайты имеют возможность получать мультимедийные данные в одинаковом формате. Рассмотрим случай, когда участники из одной местности соединены через низкоскоростную линию связи с большинством других участников конференции, которые обладают широкополосным доступом к сети. Вместо того, чтобы вынуждать каждого использовать более узкую полосу пропускания и звуковое кодирование с пониженным качеством, средство связи уровня RTP, называемое микшером, может быть размещено в области с узкой полосой пропускания. Этот микшер повторно синхронизирует входящие звуковые пакеты для восстановления исходных 20-миллисекундных интервалов, микширует эти восстановленные звуковые потоки в один поток, производит кодирование звукового сигнала для узкой полосы пропускания и передает поток пакетов через низкоскоростную линию связи. При этом пакеты могут быть адресованы одному получателю или группе получателей с различными адресами. Чтобы в приемных оконечных точках можно было обеспечивать правильную индикацию источника сообщений, заголовок RTP включает для микшеров средства опознавания источников, участвовавших в формировании смешанного пакета.

Некоторые из участников аудиоконференции могут быть соединены широкополосными линиями связи, но могут быть недостижимы посредством групповой конференцсвязи с использованием протокола IP (IPM - IP multicast). Например, они могут находиться за брандмауэром прикладного уровня, который не будет допускать никакой передачи IP-пакетов. Для таких случаев нужны не микшеры, а средства связи уровня RTP другого типа, называемые трансляторами. Из двух трансляторов один устанавливается вне брандмауэра и снаружи передает все групповые пакеты, полученные через безопасное соединение, другому транслятору, установленному за брандмауэром. Транслятор за брандмауэром передает их снова как мультивещательные пакеты многопользовательской группе, ограниченной внутренней сетью сайта.

Микшеры и трансляторы могут быть разработаны для ряда целей. Пример: микшер видеосигнала, который масштабирует видеоизображения отдельных людей в независимых потоках видеосигнала и выполняет их композицию в один поток видеосигнала, моделируя групповую сцену. Примеры трансляции: соединение группы хостов, использующих только протоколы IP/UDP с группой хостов, которые воспринимают только ST-II, или перекодирование видеосигнала пакет за пакетом из индивидуальных источников без пересинхронизации или микширования. Детали работы микшеров и трансляторов рассмотрены в разделе 5.

Все поля пакетов RTP/RTCP передаются по сети байтами (октетами); при этом наиболее значащий байт передается первым. Все данные полей заголовка выравниваются в соответствии с их длиной. Октеты, обозначенные как дополнительные, имеют нулевое значение.

Абсолютное время (время Wallclock) в RTP представлено с использованием формата временной метки сетевого протокола времени NTP (Network Time Protocol), который является отсчетом времени в секундах относительно нуля часов 1 января 1900 года. Полный формат временной метки NTP - 64-разрядное число без знака с фиксированной запятой с целой частью в первых 32 битах и дробной - в последних 32 битах. В некоторых полях с более компактным представлением используются только средние 32 бита - младшие 16 битов целой части и старшие 16 битов дробной части.

В следующих двух разделах данной статьи (3 и 4) рассматриваются форматы пакетов и особенности функционирования протоколов RTP и RTCP соответственно.

Как было отмечено выше, пакет RTP включает в свой состав фиксированный заголовок, необязательное расширение заголовка с переменной длиной и поле данных. Фиксированный заголовок пакетов протокола RTP имеет следующий формат: .

Первые двенадцать октетов присутствуют в каждом пакете RTP, в то время как поле идентификаторов включаемых источников CSRC (сontributing source) присутствует только тогда, когда оно вставлено микшером. Поля имеют следующие назначения.

Версия (V): 2 бита. Это поле идентифицирует версию RTP. В данной статье рассматривается версия 2 протокола RTP (величина 1 использовалась в первой черновой версии RTP).

Дополнение (P): 1 бит. Если бит дополнения установлен в единицу, то пакет в конце содержит один или более октетов дополнения, которые не являются частью трафика. Последний октет дополнения содержит указание на число таких октетов, которые должны впоследствии игнорироваться. Дополнение может требоваться некоторым алгоритмам шифрования с фиксированными размерами блока или для переноса нескольких пакетов RTP в одном блоке данных протокола нижележащего уровня.

Расширение (X): 1 бит. Если бит расширения установлен, то за фиксированным заголовком следует расширение заголовка с форматом, определенным в .

Счетчик CSRC (CC): 4 бита. Счетчик CSRC содержит число идентификаторов включаемых источников CSRC (см. список используемых сокращений и терминов), которые следуют за фиксированным заголовком.

Маркер (M): 1 бит. Интерпретация маркера определяется профилем. Он предназначен для того, чтобы позволить маркировать в потоке пакетов значительные события (например, границы видеокадра). Профиль может вводить дополнительные биты маркера или определять, что никакого бита маркера не имеется, изменяя число битов в поле типа трафика (см. ).

Тип трафика (PT): 7 бит. Это поле идентифицирует формат трафика RTP и определяет его интерпретацию приложением. Профиль определяет заданное по умолчанию статическое соответствие значений РТ и форматов трафика. Дополнительные коды типа трафика могут быть определены динамически через не-RTP средства. Отправитель пакета RTP в любой момент времени выдает единственное значение типа трафика RTP; это поле не предназначено для мультиплексирования отдельных мультимедийных потоков (см. ).

Порядковый номер: 16 бит. Значение порядкового номера увеличивается на единицу с каждым посланным информационным пакетом RTP и может использоваться получателем для обнаружения потерь пакетов и восстановления их исходной последовательности. Начальная величина порядкового номера выбирается случайным образом, чтобы усложнить попытки взлома ключа с опорой на известные значения данного поля (даже если шифрование не используется источником, так как пакеты могут проходить через транслятор, который применяет шифрование). Временная метка: 32 бита. Временная метка отражает момент дискретизации для первого октета в информационном пакете RTP. Момент дискретизации должен быть получен от таймера, который увеличивает свои значения монотонно и линейно во времени, для обеспечения синхронизации и определения джиттера (см. раздел 4.3.1). Разрешение таймера должно быть достаточным для желательной точности синхронизации и измерения джиттера поступления пакетов (одного отчета таймера на видеокадр обычно бывает недостаточно). Частота таймирования зависит от формата передаваемого трафика и задается статически в профиле или спецификации формата трафика или может задаваться динамически для форматов трафика, определенных через «не-RTP средства». Если пакеты RTP генерируются периодически, то должны использоваться номинальные моменты дискретизации, определяемые таймером дискретизации, а не значения системного таймера. Например, для звукового сигнала с фиксированной скоростью желательно, чтобы датчик временной метки увеличивался на единицу для каждого периода дискретизации. Если звуковое приложение из устройства ввода читает блоки, содержащие 160 отсчетов, то временная метка при этом должна увеличиваться на 160 для каждого такого блока, независимо от того, передан ли блок в пакете или сброшен, как пауза. Начальное значение временной метки, так же, как и начальное значение порядкового номера, является случайной величиной. Несколько последовательных пакетов RTP могут иметь равные временные метки, если они логически генерируются одновременно, например, принадлежат одному и тому же видеокадру. Последовательные пакеты RTP могут содержать немонотонные временные метки, если данные не передаются в порядке дискретизации, как в случае интерполируемых видеокадров MPEG (однако порядковые номера пакетов при передаче все же будут монотонными).

SSRC: 32 бита. Поле SSRC (synchronization source) идентифицирует источник синхронизации (см. список используемых сокращений и терминов). Этот идентификатор выбирается случайным образом так, чтобы никакие два источника синхронизации в рамках одного и того же сеанса связи RTP не имели одинаковых идентификаторов SSRC. Хотя вероятность того, что несколько источников выберут один и тот же идентификатор, низка, все же все реализации RTP должны быть готовы обнаруживать и разрешать подобные коллизии. В разделе 6 рассмотрена вероятность коллизий вместе с механизмом для их разрешения и обнаружения зацикливаний уровня RTP, основанным на уникальности идентификатора SSRC. Если источник изменяет свой исходный транспортный адрес, то он должен также выбрать новый идентификатор SSRC, чтобы его не интерпретировали как зацикленный источник.

Список CSRC: от 0 до 15 пунктов, 32 бита каждый. Список CSRC (сontributing source) идентифицирует включаемые источники трафика, содержащегося в пакете. Число идентификаторов задается полем CC. Если имеется более пятнадцати включаемых источников, то только 15 из них могут быть идентифицированы. Идентификаторы CSRC вставляются микшерами при использовании идентификаторов SSRC для включаемых источников. Например, для звуковых пакетов идентификаторы SSRC всех источников, которые были смешаны при создании пакета, перечисляются в списке CSRC, обеспечивая корректную индикацию источников сообщений для получателя.

Как было упомянуто выше, в соответствии с протоколом RTP трафик различных типов должен передаваться отдельно, в разных сеансах связи RTP. Сеанс определяется конкретной парой транспортных адресов назначения (один сетевой адрес плюс пара портов для RTP и RTCP). Например, в телеконференции, составленной из звукового и видеосигнала, кодированных отдельно, трафик каждого типа нужно передавать в отдельном сеансе RTP со своим собственным транспортным адресом назначения. Не предполагается, что звуковой и видеосигнал будут передаваться в одном сеансе RTP и разделяться на основе типа трафика или полей SSRC. Перемежение пакетов, имеющих различные типы трафика, но использующих один и тот же SSRC, вызвало бы некоторые проблемы:

Если в течение сеанса один из типов трафика изменится, то не будет никаких общих средств, чтобы определить, какая из старых величин была заменена новой.
SSRC идентифицирует единственное значение интервала таймирования и пространство порядкового номера. Перемежение множества типов трафика потребовало бы различных интервалов синхронизации, если тактовые частоты разных потоков различаются, и различных пространств порядковых номеров для индикации типа трафика, к которому относится потеря пакета.
Сообщения отправителя и получателя протокола RTCP (см. раздел 4.3) описывают только одно значение интервала таймирования и пространство порядковых номеров для SSRC и не передают поле типа трафика.
Микшер RTP не способен объединять перемеженные потоки различных типов трафика в один поток.
Передаче множества типов трафика в одном сеансе RTP препятствуют следующие факторы: использование различных сетевых путей или распределение сетевых ресурсов; прием подмножества мультимедийных данных, когда это требуется, например, только звука, если видеосигнал превысил доступную полосу пропускания; реализации приемника, которые используют отдельные процессы для различных типов трафика, в то время как использование отдельных сеансов RTP допускает реализации как с одним, так и со множеством процессов.

При использовании для каждого типа трафика различных SSRC, но при передаче их в одном и том же сеансе RTP, можно избежать первых трех проблем, но двух последних избежать не удастся. Поэтому спецификация протокола RTP предписывает для каждого типа трафика использовать свой сеанс RTP.

Существующий заголовок информационного пакета RTP является полным для набора функций, требуемых в общем случае для всех классов приложений, которые могли бы поддерживать RTP. Однако, для лучшего приспособления к конкретным задачам заголовок может быть видоизменен посредством модификаций или дополнений, определенных в спецификации профиля.

Бит маркера и поле типа трафика несут информацию, зависящую от профиля, но они расположены в фиксированном заголовке, так как ожидается, что в них будут нуждаться много приложений. Октет, содержащий эти поля, может быть переопределен профилем для удовлетворения различным требованиям, например, с большим или меньшим количеством битов маркера. Если имеются какие-либо биты маркера, они должны размещаться в старших битах октета, так как независимые от профиля мониторы могут быть способны наблюдать корреляцию между характером потерь пакетов и битом маркера.

Дополнительная информация, которая требуется для конкретного формата трафика (например, тип кодирования видеосигнала), должна передаваться в поле данных пакета. Она может размещаться на определенном месте в начале или внутри массива данных.

Если конкретный класс приложений нуждается в дополнительных функциональных возможностях, не зависящих от формата трафика, то профиль, с которым функционируют эти приложения, должен определить дополнительные фиксированные поля, располагаемые сразу после поля SSRC существующего фиксированного заголовка. Эти приложения будут способны быстро напрямую обращаться к дополнительным полям, в то время как профиль-независимые мониторы или регистраторы все еще будут способны обрабатывать пакеты RTP, интерпретируя только первые двенадцать октетов.

Если считается, что дополнительные функциональные возможности необходимы в общем для всех профилей, то должна быть определена новая версия RTP, чтобы сделать постоянное изменение фиксированного заголовка.

Для обеспечения возможности отдельным реализациям экспериментировать с новыми функциями, независимыми от формата трафика, которые требуют, чтобы в заголовке информационного пакета передавалась дополнительная информация, протоколом RTP предусмотрен механизм расширения заголовка пакета. Этот механизм разработан так, чтобы расширение заголовка могло игнорироваться другими взаимодействующими приложениями, которым оно не требуется.

Если бит X в заголовке RTP установлен в единицу, то к фиксированному заголовку RTP (вслед за списком CSRC, если он есть) присоединяется расширение заголовка с переменной длиной. Заметим, что это расширение заголовка предназначено только для ограниченного использования. Расширение заголовка пакета RTP имеет следующий формат:

Расширение содержит 16-разрядное поле длины, которое показывает количество 32-разрядных слов в нем, исключая четырехоктетный заголовок расширения (следовательно, длина может иметь нулевое значение). Только одно расширение может быть добавлено к фиксированному заголовку информационного пакета RTP. Чтобы позволить каждому из множества взаимодействующих реализаций экспериментировать независимо с различными расширениями заголовка или позволять конкретной реализации экспериментировать более чем с одним типом расширения заголовка, использование первых 16 битов расширения не определено, оставлено для различающих идентификаторов или параметров. Формат из этих 16 битов должен быть определен спецификацией профиля, с которым работают приложения.

1999
2000

RTSP (Real Time Streaming Protocol, или, по-русски, потоковый протокол реального времени) – это прикладной протокол, в котором описаны команды для управления видеопотоком. С помощью этих команд мы можем «приказать» камере или серверу, например, начать трансляцию видеопотока. Пример запроса на начало воспроизведения выглядит так: PLAY rtsp://192.168.0.200/h264 RTSP/1.0

То есть RTSP – это просто набор команд для управления видеопотоком. Проведем эксперимент. Для этого нам понадобится IP-камера с поддержкой RTSP протокола и ее RTSP адрес. Этот адрес выглядит примерно так rtsp:///mpeg. Его можно узнать из руководства по эксплуатации камеры либо из описания API. Для удобства мы приведем RTSP адреса для ряда популярных камер в таблице. После того, как мы узнали RTSP-адрес камеры, открываем стандартный проигрыватель, поддерживающий RTSP. Это может быть одна из следующих программ: Windows Media Player, QuickTime, Media Player Classic, VLC media player, RealPlayer, MPlayer. Мы выбрали QuickTime. Открываем меню «Файл > Открыть URL» и вводим наш RTSP адрес. После чего QuickTime подключится к камере и воспроизведет «живое видео». Устройства записи, работающие в системах IP-видеонаблюдения, получают видео от камер либо с помощью протокола HTTP – то есть также, как мы скачиваем JPEG-картинки с сайтов, либо в виде потока через RTSP – то есть также как мы получили его с помощью стандартного проигрывателя в последнем примере. В настройках IP-камер потоковый вариант передачи данных может обозначаться как RTSP over , RTSP over либо просто . Итак, RTSP – это набор команд для управления потоком. Но что означают остальные аббревиатуры: TCP, RTP? TCP, и RTP — это транспортные механизмы (протоколы), которые собственно и передают видео.

Протокол TCP

Допустим, мы выбрали метод RSTP over TCP и хотим начать передачу видеопотока. Что будет происходить на уровне транспортных механизмов? Предварительно с помощью нескольких команд будет установлено соединение между отправителем и получателем. После этого начнется передача видеоданных. При этом механизмы TCP
будут следить за тем, чтобы все данные дошли до адресата без изменений и в нужной последовательности. Также TCP будет регулировать скорость передачи, чтобы передатчик не посылал данные интенсивнее, чем их может обработать приемник.

UDP – это альтернатива транспортному протоколу TCP. В отличие от TCP, UDP не устанавливает предварительного соединения, а вместо этого просто начинает передавать данные. UDP не следит за тем, чтобы данные были получены и не дублирует их, если отдельные части пропали или пришли с ошибками. UDP менее надежен, чем TCP. Но с другой стороны, он обеспечивает более быструю передачу потоков благодаря отсутствию механизма повторения передачи потерянных пакетов.

Можно увидеть различие в протоколах, поставив следующий эксперимент: попробуйте перевести камеру в режим RTSP over TCP и помашите рукой перед объективом — на экране монитора вы увидите задержку. А теперь проведите этот же тест в режиме RTSP over UDP. Задержка будет меньше. На время задержки влияют несколько факторов: формат сжатия, мощность компьютера, протокол передачи и особенности программного обеспечения, участвующего в декодировании видео.

RTP (Real-time Transport Protocol), или по-русски транспортный протокол реального времени. Этот протокол специально создан для передачи реалтайм трафика. Он позволяет следить за синхронизацией передаваемых данных, корректировать последовательность доставки пакетов и потому более других подходит для передачи видео- и аудиоданных. В общем случае для передачи видеопотока предпочтительнее использовать либо RTP либо UDP. Работа через TCP оправдана лишь если нам приходится работать с проблемными сетями, так как протокол TCP сможет корректировать ошибки и сбои, возникающие при передаче данных.

Добрый день!

Итого: система мониторинга представляет собой комплекс, подключаемый в неинтрузивном режиме к n-ному количеству 10-гигабитных линков Ethernet, который непрерывно “наблюдает” за передачей всех присутствующих в трафике видео-потоков RTP и проводит измерения с определённым интервалом времени, чтобы потом сохранить их в базу. По данным из базы регулярно строятся отчёты для всех камер.

В процессе поиска решения сразу зафиксировали несколько проблем:

Неинтрузивное подключение. Система мониторинга подключается к уже работающим каналам, в которых большинство соединений (по RTSP) уже установлены, сервер и клиент уже знают, по каким портам происходит обмен, но нам это заранее неизвестно. Well-known порт есть только для протокола RTSP, а вот UDP-потоки могут идти по произвольным портам (к тому же, оказалось, что нередко они нарушают требование SHOULD чётности/нечётности портов, см. rfc3550). Как определить, что тот или иной пакет от какого-то IP-адреса принадлежит к видео-потоку? Например, протокол BitTorrent ведёт себя аналогично - на этапе установки соединения клиент и сервер договариваются о портах, а потом весь UDP-трафик выглядит как “просто битовый поток”.
В подключенных линках могут быть не только видео-потоки. Могут быть и HTTP, и BitTorrent, и SSH, и любые другие протоколы, которыми мы сегодня пользуемся. Следовательно, система должна правильно идентифицировать видео-потоки, чтобы отделить их от остального трафика. Как это проделать в реальном времени с 8-ю десяти-гигабитными линками? Они, конечно, обычно не заполняются на 100%, поэтому суммарно трафика будет не 80 гигабит/с, а примерно 50-60, но и это не так уж мало.
Масштабируемость. Там, где уже много видео-потоков, их может стать ещё больше, поскольку видео-наблюдение уже давно оправдало себя как эффективный инструмент. Это говорит о том, что должен быть запас по производительности и резерв по линкам.

Мы, естественно, стремились максимально использовать собственный опыт. К моменту принятия решения у нас уже была реализация обработки ethernet-пакетов на FPGA-powered девайсе Беркут-МХ (проще - MX). С помощью Беркут-MX мы умели получать из заголовков Ethernet-пакетов нужные поля для анализа. Опыта обработки такого объёма трафика средствами “обычных” серверов у нас не было, увы, поэтому на подобное решение смотрели с некоторой опаской…

Казалось бы, оставалось просто применить метод к RTP-пакетам и золотой ключик был бы у нас в кармане, но MX умеет только обрабатывать трафик, в него не заложены возможности учёта и хранения статистики. Для хранения найденных соединений (комбинаций IP-IP-порт-порт) в ПЛИС не хватит памяти, ведь в 2x10-гигабитном линке, заходящем на вход, может быть около 15 тысяч видео-потоков, и по каждому нужно “помнить” количество принятых пакетов, количество потерянных пакетов и так далее… Более того, поиск на такой скорости и по такому количеству данных при условии обработки без потерь становится нетривиальной задачей.

Чтобы найти решение, пришлось “копнуть глубже” и разобраться в том, по каким алгоритмам мы будем измерять качество и идентифицировать видео-потоки.

Из описания видно, что с точки зрения измерений качества в RTP-пакете нас интересуют следующие поля:

sequence number - 16-ти разрядный счётчик, увеличивающийся с каждым отправленным пакетом;
timestamp - временная метка, для h.264 величина дискрета составляет 1/90000 c (т.е. соответствует частоте 90 КГц);
Marker-бит. В rfc3550 в общем виде описано, что этот бит предназначен для обозначения “значимых” событий , а по факту этим битом чаще всего камеры маркируют начало видео-кадра и специализированные пакеты с SPS/PPS-информацией.

Вполне очевидно, что sequence number позволяет определить следующие параметры потока:

потери пакетов (frame loss);
повторную посылку пакета (duplicate);
изменение порядка прихода (reordering);
перезагрузку камеры, при большом «разрыве» в последовательности.

Timestamp позволяет измерить:

вариацию задержки (ещё называют джиттером). При этом на приёмной стороне должен работать 90 КГц счётчик;
в принципе, задержку прохождения пакета. Но для этого нужно синхронизировать время камеры с timestamp’ом, а это возможно, если камера передаёт sender reports (RTCP SR), что в общем случае неверно, т.к. в реальной жизни многие камеры игнорируют посылку RTCP SR (примерно половина камер, с которыми нам довелось поработать).

Ну а M-бит позволяет измерить частоту кадров. Правда, SPS/PPS-кадры протокола h.264 вносят погрешность, т.к. видео-кадрами не являются. Но её можно нивелировать, использовав информацию из заголовка NAL-unit’а, который всегда идёт следом за RTP-заголовком.

Подробные алгоритмы измерения параметров выходят за рамки статьи, не буду заглубляться. Если интересно, то в rfc3550 есть пример кода вычисления потерь и формулы для вычисления джиттера . Главный же вывод заключается в том, что для измерений базовых характеристик транспортного потока достаточно всего лишь нескольких полей из RTP-пакетов и NAL-юнитов. А остальная информация в измерениях не участвует и её можно и нужно отбросить!

Для ведения статистики информацию, полученную из RTP-заголовка, необходимо “привязать” к некоторому идентификатору камеры (видео-потока). Камеру можно однозначно идентифицировать по следующим параметрам:

IP-адреса источника и получателя
Порты источника и получателя
SSRC. Имеет особое значение тогда, когда с одного IP вещается несколько потоков, т.е. в случае с многопортовым энкодером.

Что интересно, мы сначала сделали идентификацию камер только по IP источника и SSRC, полагаясь на то, что SSRC должен быть случайным, но на практике оказалось, что многие камеры устанавливают SSRC в фиксированное значение (скажем, 256). Видимо, это связано с экономией ресурсов. В итоге нам пришлось к идентификатору камеры добавить ещё и порты. Это решило проблему уникальности полностью.

Остался вопрос: как Беркут-MX, приняв пакет, поймёт, что это RTP? RTP-заголовок не имеет такой явной идентификации, как IP, у него нет контрольной суммы, передаваться он может по UDP с номерами портов, которые выбираются динамически при установке соединения. А в нашем случае большинство соединений уже давно установлены и ждать переустановки можно очень долго.

Для решения этой задачи в rfc3550 (Appendix A.1) рекомендуется проверять биты версии RTP - это два бита, и поле Payload Type (PT) - семь бит, которое в случае с динамическим типом принимает небольшой диапазон. Мы на практике выяснили, что для того множества камер, c которым мы работаем, PT укладывается в диапазон от 96 до 100.

Есть ещё один фактор - чётность порта, но как показала практика, не всегда соблюдается, поэтому от него пришлось отказаться.

Таким образом, поведение Беркут-MX следующее:

получаем пакет, разбираем на поля;
если версия равна 2 и payload type находится в заданных пределах, то отправляем заголовки серверу.

Очевидно, что при таком подходе есть ложноположительные срабатывания, т.к. под такие простые критерии могут попадать не только RTP-пакеты. Но для нас важно, что RTP-пакет мы точно не пропустим, а «неправильные» пакеты отфильтрует уже сервер.

Для фильтрации ложных случаев сервер использует механизм, который регистрирует источник видео-трафика по нескольким последовательно принятым пакетам (в пакете же есть sequence number!). Если несколько пакетов пришло с последовательными номерами, то это не случайное совпадение и начинаем работать с этим потоком. Этот алгоритм оказался весьма надёжным.

Поняв, что вся информация, идущая в пакетах, для измерения качества и идентификации потоков не нужна, мы решили всю highload & time-critical работу по приёму и вычленению полей RTP-пакетов взвалить на Беркут-MX, то бишь на FPGA. Он “находит” видео-поток, разбирает пакет, оставляет только нужные поля и в UDP-туннеле отправляет на обычный сервер. Сервер проводит измерения по каждой камере и сохраняет результаты в базу данных.

В итоге сервер работает не с 50-60 Гигабит/с, а максимум с 5% (именно такая получилась пропорция отсылаемых данных к среднему размеру пакета). То есть на входе всей системы 55 Гигабит/с, а на сервер попадает всего-то не более 3 Гигабит/с!

В итоге у нас получилась такая архитектура:

И первый результат в такой конфигурации мы получили через две недели после постановки начального ТЗ!

Итак, что же делает сервер в нашей архитектуре? Его задачи:

слушать UDP-сокет и вычитывать из него поля с упакованными заголовками;
разбирать приходящие пакеты и доставать оттуда поля RTP заголовков вместе с идентификаторами камеры;
соотносить полученные поля с теми, что были получены прежде, и понимать, потерялись ли пакеты, посылались ли пакеты повторно, менялся ли порядок прихода, какая была вариация задержки прохождения пакета (джиттер) и т.д.;
фиксировать измеренное в базе с привязкой ко времени;
анализировать базу и генерировать отчёты, посылать трапы о критических событиях (высокие потери пакетов, пропадание пакетов от какой-то камеры и т.п.).

При том, что суммарный трафик на входе сервера составляет около 3 Гигабит/с, сервер справляется даже при условии, что мы не используем никаких DPDK, а работаем просто через linux’овый сокет (предварительно увеличив размер буфера для сокета, конечно). Более того, можно будет подключать новые линки и MX"ы, потому что запас по производительности остаётся.

Вот как выглядит top сервера (это top только одного lxc-контейнера, отчёты генерируются в другом):

Из него видно, что вся нагрузка по расчёту параметров качества и учёту статистики распределена по четырём процессам равномерно. Нам удалось добиться такого распределения за счёт применения хеширования в FPGA: по IP считается хеш-функция, а младшие биты полученного хеша определяют номер UDP-порта, на который уйдёт статистика. Соответственно, каждый процесс, слушающий свой порт, получает примерно одинаковое количество трафика.

Настало время похвастаться и признаться в недостатках полученного решения.

Начну с плюсов:

отсутствие потерь на стыке с 10G-линками. Поскольку весь “удар” на себя берёт ПЛИС, мы можем не сомневаться в том, что будет проанализирован каждый пакет;
для мониторинга 55000 камер (и более) требуется всего один сервер с одной 10G карточкой. Мы пока используем сервера на базе 2х Xeon c 4мя ядрами по 2400 МГц каждое. Хватает с запасом: параллельно со сбором информации генерируются отчёты;
мониторинг 8-ми “десяток” (10G линков) укладывается всего в 2-3 юнита: не всегда под систему мониторинга есть много места и питания в стойке;
при подключении линков от MX’ов через коммутатор можно добавлять новые линки без остановки мониторинга, т.к. никакие платы в сервер вставлять не надо и для этого не требуется его выключать;
сервер не перегружен данными, он получает только то, что необходимо;
заголовки с MX’а приходят в jumbo Ethernet-пакете, значит процессор не захлебнётся прерываниями (к тому же мы не забываем и про interrupt coalescing).

Справедливости ради рассмотрю и недостатки:

из-за жёсткой оптимизации под конкретную задачу добавление поддержки новых полей или протоколов требует изменений в коде ПЛИС. Это приводит к бОльшим затратам времени, чем если бы мы делали это же на процессоре. Как в разработке и тестировании, так и при деплое;
видео-информация не анализируется вообще. Камера может снимать сосульку, висящую перед ней, или быть повёрнутой не в ту сторону. Этот факт останется незамеченным. Мы, конечно, предоставили возможность записи видео с выбранной камеры, но не перебирать же оператору все 55000 камер!
сервер и FPGA-powered девайсы - это дороже, чем просто один-два сервера;)

Synchronization Source (SSRC) Identifier

Contributing Source (CSRC) Identifiers

В конечном итоге у нас получился программно-аппаратный комплекс, в котором мы можем контролировать и ту часть, которая парсит пакеты на интерфейсах, и ту, которая ведёт статистику. Полный контроль над всеми узлами системы буквально спас нас, когда камеры начали переводить на RTSP/TCP interleaved mode. Потому что в этом случае заголовок RTP перестал располагаться в пакете по фиксированному смещению: он может находиться где угодно, даже на границе двух пакетов (первая половина в одном, вторая - в другом). Соответственно, алгоритм получения RTP-заголовка и его полей претерпел кардинальные изменения. Нам пришлось сделать TCP reassembling на сервере для всех 50000 соединений - отсюда и довольно высокая нагрузка в top’е.

Мы никогда до этого не работали в сфере высоконагруженных приложений, но нам удалось решить задачу за счёт наших скилов в FPGA и получилось довольно-таки неплохо. Даже остался запас - например, к системе с 55000 камерами можно подключить ещё 20-30 тысяч потоков.

Тюнинг linux’овых подсистем (распределение очередей по прерываниям, увеличение приёмных буферов, директивное выделение ядер на конкретные процессы и т.п.) я оставил за рамками статьи, т.к. эта тема и так уже очень хорошо освещена.

Я описал далеко не всё, граблей было собрано немало, поэтому не стесняйтесь задавать вопросы:)

Большое спасибо всем, кто дочитал до конца!