Rtp порты. Курс лекций по сетевым технологиям

Протокол RTP

Основным транспортным протоколом для мультимедийных приложений стал протокол реального времени RTP (Real-Time Protocol), предназначенный для организации передачи пакетов с кодированными речевыми сигналами по IP-сети. Передача пакетов RTP ведется поверх протокола UDP, работающего, в свою очередь, поверх IP (рис. 1.5.).

Рис. 1.5.

На самом деле уровень, к которому относится RTP, не определяется настолько однозначно, как это показано на рис. 1.5 и как это обычно описывается в литературе. С одной стороны, протокол действительно работает поверх UDP, реализуется прикладными программами и, по всем признакам, является прикладным протоколом. Но в то же время, как сказано в начале этого параграфа, RTP предоставляет транспортные услуги независимо от мультимедийных приложений и является, с этой точки зрения, просто транспортным протоколом. Наиболее удачное определение: RTP -- это транспортный протокол, реализованный на прикладном уровне.

Для передачи речевого (мультимедийного) трафика RTP использует пакеты, структура которых показана на рис. 1.6.

Пакет RTP состоит, как минимум, из 12 байтов. В двух первых битах RTP заголовка (поле бита версии, V) указывается версия протокола RTP (в настоящее время это версия 2).

Ясно, что при такой структуре заголовка возможна максимум еще только одна версия RTP. Следующее за ними поле содержит два бита: бит Р, который указывает, были ли добавлены в конце поля с полезной нагрузкой символы-наполнители (они обычно добавляются, если транспортный протокол или алгоритм кодирования требует использования блоков фиксированного размера), и бит X, который указывает, используется ли расширенный заголовок.

Рис. 1.6.

Если он используется, то первое слово расширенного заголовка содержит общую длину расширения. Далее, четыре бита СС определяют число CSRC-полей в конце RTP-заголовка, т.е. число источников, формирующих поток. Маркерный бит М позволяет отмечать то, что стандарт определяет как существенные события, например, начало видеокадра, начало слова в аудиоканале и т.п. За ним следует поле типа данных РТ (7 битов), где указывается код типа полезной нагрузки, определяющий содержимое поля полезной нагрузки - данные приложения {Application Data), например, несжатое 8-битовое аудио МРЗ и т.п. По этому коду приложение может узнать, что нужно делать, чтобы декодировать данные. Остальная часть заголовка фиксированной длины состоит из поля порядкового номера (Sequence Number), поля метки времени (Time Stamp) для записи момента создания первого слова пакета и поля источника синхронизации SSRC, которое идентифицирует этот источник. В последнем поле можно указывать единственное устройство, имеющее только один сетевой адрес, множественные источники, которые могут представить различные мультимедийные среды (аудио, видео и т.д.), или разные потоки одной и той же среды. Так как источники могут быть на разных устройствах, SSRC-идентификатор выбирается случайным образом, чтобы шанс получать данные сразу от двух источников во время RTP-сеанса был минимальным. Однако определен также и механизм решения конфликтов, если они возникают. За фиксированной частью RTP-заголовка могут следовать еще до 15 отдельных 32-разрядных CSRC-полей, которые идентифицируют источники данных.

RTP поддерживается протоколом управления транспортировкой в реальном времени RTCP {Real-Time Transport Control Protocol), который формирует дополнительные отчеты, содержащие информацию о сеансах связи RTP. Напомним, что ни UDP, ни RTP не занимаются обеспечением качества обслуживания QoS (Quality of Service). Протокол RTCP обеспечивает обратную связь с отправителями, а получателям потоков он предоставляет некоторые возможности повышения QoS, информацию о пакетах (потери, задержки, джиттер) и о пользователе (приложении, потоке). Для управления потоком существуют отчеты двух типов - генерируемые отправителями и генерируемые получателями. Например, информация о доле потерянных пакетов и абсолютном количестве потерь позволяет отправителю при получении отчета обнаруживать, что перегрузка канала может заставить получателей не принимать потоки пакетов, которые они ожидали. В этом случае отправитель имеет возможность понизить скорость кодирования, чтобы уменьшить перегрузку и улучшить прием. Отчет отправителя содержит информацию о том, когда был генерирован последний RTP-пакет (она включает в себя как внутреннюю метку, так и реальное время). Эта информация позволяет получателю координировать и синхронизировать множественные потоки, например, видео и аудио. Если поток направляется нескольким получателям, то организуются потоки RTCP-пакетов от каждого из них. При этом будут предприняты шаги для ограничения ширины полосы - обратно пропорционально скорости, с которой генерируются RTCP-отчеты, и числу получателей.

Следует заметить, что хотя RTCP работает отдельно от RTP, но уже и сама цепочка RTP/UDP/IP приводит к существенным накладным расходам (в виде их заголовков). Кодек G.729 генерирует пакеты размером в 10 байтов (80 битов каждые 10 мс). Один RTP-заголовок, размером в 12 байтов, больше, чем весь этот пакет. К нему, кроме того, должен быть добавлен 8-байтовый UDP-заголовок и 20-байтовый IP-заголовок (в версии IРv4), что создает заголовок, в четыре раза превосходящий по размеру передаваемые данные.

Если в один прекрасный день вам придется на скорую руку разобраться, что есть VoIP (voice over IP) и что значат все эти дикие аббревиатуры, надеюсь, эта методичка поможет. Сразу замечу, что вопросы конфигурирования дополнительных видов обслуживания телефонии (такие как перевод вызова, голосовая почта, конференц-связь и т.п.) здесь не рассматриваются.

Итак, с чем мы будем разбираться под катом:

Базовые понятия телефонии: типы аппаратов, схемы подключения
Связка SIP/SDP/RTP-протоколов: как это работает
Как передается информации о нажатых кнопках
Как происходит передача голоса и факсов
Цифровая обработка сигналов и обеспечение качества звука в IP-телефонии

1. Базовые понятия телефонии

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

На стороне провайдера (АТС) установлен телефонный модуль с портом FXS (Foreign eXchange Subscriber). Дома или в офисе установлен телефон или факс с портом FXO (Foreign eXchange Office) и модуль номеронабирателя.

По внешнему виду порты FXS и FXO никак не отличаются, это обычные 6-выводные RJ11-разъемы. Но с помощью вольтметра отличить их очень просто - на FXS-порте всегда будет какое-то напряжение: 48/60 В, когда трубка положена, или 6–15 В во время разговора. На FXO, если он не подключен к линии, напряжение всегда 0.

Для передачи данных по телефонной линии на стороне провайдера нужна дополнительная логика, которую можно реализовать на модуле SLIC (subscriber line interface circuit), а на стороне абонента - с помощью модуля DAA (Direct Access Arrangement).

Сейчас довольно популярны беспроводные DECT-телефоны (Digital European Cordless Telecommunications). По устройству они аналогичны обычным телефонным аппаратам: в них тоже есть FXO-порт и модуль номеронабирателя, но еще добавлен модуль беспроводной связи станции и трубки на частоте 1,9 ГГц.

Абоненты подключаются к PSTN-сети (Public Switched Telephone Network) - телефонной сети общего пользования, она же ТСОП, ТфОП. PSTN-сеть может быть организована с использованием разных технологий: ISDN, оптики, POTS, Ethernet. Частный случай PSTN, когда используется обычная аналоговая/медная линия - POTS (Plain Old Telephone Service) - простая старая телефонная система.

С развитием Интернета телефонная связь перешла на новый уровень. Стационарные телефонные аппараты все реже используются, в основном по служебным нуждам. DECT-телефоны немного удобнее, но ограничены периметром дома. GSM-телефоны еще удобнее, но ограничены пределами страны (роуминг - дело дорогое). А вот для IP-телефонов, они же cофтфоны (SoftPhone), никаких ограничений, кроме доступа к интернету, нет.

Skype - самый известный пример софтфона. Он может много чего, но имеет два важных недостатка: закрытая архитектура и прослушка известно какими органами. Из-за первого нет возможности создать свою телефонную микросеть. А из-за второго - не очень приятно, когда за вами подсматривают, особенно при личных и коммерческих разговорах.

К счастью есть открытые протоколы для создания своих коммуникационных сетей с плюшками - это SIP и H.323. Софтфонов на SIP-протоколе несколько больше чем на H.323, что можно объяснить его сравнительной простотой и гибкостью. Но иногда эта гибкость может вставлять большие палки в колёса. Оба протокола SIP и H.323 используют RTP-протокол для передачи медиаданных.

Рассмотрим базовые принципы протокола SIP, чтобы разобраться, как происходит соединения двух абонентов.

2. Описание связки SIP/SDP/RTP-протоколов

SIP (Session Initiation Protocol) - протокол установления сессии (не только телефонной) - это текстовый протокол поверх UDP. Также есть возможность использовать SIP поверх TCP, но это редкие случаи.

SDP (Session Description Protocol) - протокол согласования типа передаваемых данных (для звука и видео это кодеки и их форматы, для факсов - скорость передачи и коррекция ошибок) и адреса их назначения (IP и порт). Это также текстовый протокол. Параметры SDP передаются в теле SIP-пакетов.

RTP (Real-time Transport Protocol) - протокол передачи аудио/видеоданных. Это бинарный протокол поверх UDP.

Общая структура SIP-пакетов:

Start-Line: поле, указывающее SIP-метод (команду) при запросе или результат выполнения SIP-метода при ответе.
Headers: дополнительная информация к Start-Line, оформленная в виде строк, содержащих пары АТТРИБУТ: ЗНАЧЕНИЕ.
Body: бинарные или текстовые данные. Обычно используется для передачи SDP-параметров или сообщений.

Вот пример двух SIP-пакетов для одной частой процедуры - установления вызова:

Слева изображено содержимое пакета SIP INVITE, справа - ответ на него - SIP 200 OK.

Основные поля выделены рамками:

Method/Request-URI содержит SIP-метод и URI. В примере происходит установление сессии - метод INVITE, вызов абонента [email protected].
Status-Code - код ответа на предыдущую SIP-команду. В данном примере команда выполнилась успешно - код 200, т.е. абонент 555 поднял трубку.
Via - адрес, на котором абонент 777 ждет ответа. Для сообщения 200 OK это поле копируется из INVITE-сообщения.
From/To - отображаемые имя и адрес отправителя и получателя сообщения. Для сообщения 200 OK это поле копируется из INVITE-сообщения.
Cseq содержит порядковый номер команды и название метода, к которому относится данное сообщение. Для сообщения 200 OK это поле копируется из INVITE-сообщения.
Content-Type - тип данных, которые передаются в блоке Body, в данном случае - SDP-данные.
Connection Information - IP-адрес, на который второму абоненту необходимо отправлять пакеты RTP (или UDPTL пакеты в случае передачи факса по T.38).
Media Description - порт, на который второй абонент должен передавать указанные данные. В данном случае это звук (audio RTP/AVP) и список поддерживаемых типов данных - PCMU, PCMA, GSM-кодеки и DTMF-сигналы.

SDP-сообщение состоит из строк, содержащих пары ПОЛЕ=ЗНАЧЕНИЕ. Из основных полей можно отметить:

o - Origin, имя организатора сессии и идентификатор сессии.
с - Connection Information, поле описано ранее.
m - Media Description, поле описано ранее.
a - медиа-атрибуты, уточняют формат передаваемых данных. Например, указывают направление звука - прием или передача (sendrecv), для кодеков указывают частоту дискретизации и номер привязки (rtpmap).

RTP-пакеты содержат аудио/видеоданные, закодированные в определенном формате. Данный формат указывается в поле PT (payload type). Таблица соответствия значения данного поля конкретному формату приведена в https :// wikipedia org wiki RTP audio video profile .

Также в RTP-пакетах указывается уникальный SSRC-идентификатор (определяет источник RTP-потока) и метка времени (timestamp, используется для равномерного проигрывания звука или видео).

Пример взаимодействия двух SIP-абонентов через SIP-сервер (Asterisk):

Как только запускается SIP-телефон, первым делом он регистрируется на удаленном сервере (SIP Registar), отправляет ему сообщение SIP REGISTER.

При вызове абонента отправляется сообщение SIP INVITE, в теле которого вложено SDP-сообщение, в котором указываются параметры передачи звука/видео (какие кодеки поддерживаются, на какой IP и порт отправлять звук и др.).

Когда удаленный абонент поднимает трубку, нам приходит сообщение SIP 200 OK также с параметрами SDP, только удаленного абонента. Используя отправленные и полученные SDP-параметры можно устанавливать RTP-сессию передачи звука/видео или T.38-сессию передачи факсов.

Если полученные параметры SDP нас не устроили, или промежуточный SIP-сервер решил не пропускать через себя RTP-трафик, то выполняется процедура повторного согласования SDP, так называемый REINVITE. Кстати, именно из-за этой процедуры у бесплатных SIP-прокси-серверов есть один недостаток - если оба абонента находятся в одной локальной сети, а прокси-сервер находится за NAT"ом, то после перенаправления RTP-трафика ни один из абонентов не будет слышать другого.

После окончания разговора, абонент положивший трубку, отправляет сообщение SIP BYE.

3. Передача информации о нажатых кнопках

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

Так, в обычной телефонной линии есть два способа набора номера:

Импульсный - исторически первый, использовался в основном в телефонах с дисковым номеронабирателем. Набор происходит за счет последовательного замыкания и размыкания телефонной линии согласно набираемой цифре.
Тоновый - набор номера DTMF-кодами (Dual-Tone Multi-Frequency) - каждой кнопке телефона соответствует своя комбинация двух синусоидальных сигналов (тонов). Выполняя алгоритм Гёрцеля можно довольно просто определить нажатую кнопку.

Во время разговора импульсный способ неудобен для передачи нажатой кнопки. Так, на передачу «0» требуется приблизительно 1 секунда (10 импульсов по 100 мс: 60 мс - разрыв линии, 40 мс - замыкание линии) плюс 200 мс на паузу между цифрами. К тому же во время импульсного набора будут часто слышны характерные щелчки. Поэтому в обычной телефонии используется только тоновый режим доступа к ДВО.

В VoIP-телефонии информация о нажатых кнопках может передаваться тремя способами:

DTMF Inband - генерация звукового тона и передача его внутри аудиоданных (текущего RTP-канала) - это обычный тоновый набор.
RFC2833 - генерируется специальный RTP-пакет telephone-event, в котором содержится информация о нажатой клавише, громкость и длительность. Номер RTP-формата, в котором будут передаваться пакеты DTMF RFC2833, указывается в теле SDP-сообщения. Например: a=rtpmap:98 telephone-event/8000.
SIP INFO - формируется пакет SIP INFO c информацией о нажатой клавише, громкости и длительности.

Передача DTMF внутри аудиоданных(Inband) имеет несколько недостатков - это накладные ресурсы при генерации/встраивании тонов и при их детектировании, ограничения некоторых кодеков, которые могут исказить DTMF-коды, и слабая надежность при передаче (если потеряется часть пакетов, то может произойти детектирование двойного нажатия одной и той же клавиши).

Главное различие между DTMF RFC2833 и SIP INFO: если на SIP-прокси-сервере включена возможность передачи RTP непосредственно между абонентами минуя сам сервер (например, canreinvite=yes в asterisk), то сервер не заметит RFC2833-пакеты, вследствие чего становятся недоступными сервисы ДВО. Передача SIP-пакетов всегда осуществляется через SIP-прокси-серверы, поэтому ДВО всегда будут работать.

4. Передача голоса и факсов

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

Для передачи голоса существует много разнообразных кодеков, с разными соотношениями битрейт/качество/сложность, есть открытые и закрытые. В любом софтфоне обязательно есть поддержка G.711 alaw/ulaw-кодеков, их реализация очень простая, качество звука неплохое, но они требуют пропускной способности в 64 кбит/с. Например, G.729-кодек требует только 8 кбит/с, но очень сильно загружает процессор, к тому же он не бесплатный.

Для передачи факсов обычно используется либо G.711-кодек, либо T.38-протокол. Передача факсов по G.711-кодеку соответствует передаче факса по T.30-протоколу, как будто факс передается по обычной телефонной линии, но при этом аналоговый сигнал с линии оцифровывается по alaw/ulaw-закону. Это также называется передачей факса Inband T.30.

Факсы по T.30-протоколу выполняют согласование своих параметров: скорости передачи, размера дейтаграмм, тип коррекции ошибок. T.38-протокол базируется на протоколе T.30, но в отличие от Inband-передачи, происходит анализ генерируемых и принятых T.30-команд. Таким образом передаются не сырые данные, а распознанные команды управления факсом.

Для передачи команд T.38 используется UDPTL-протокол, это протокол на базе UDP, он используется только для T.38. Для передачи комманд T.38 можно ещё использовать протоколы TCP и RTP, но они используются гораздо реже.

Основные достоинства T.38 - снижение нагрузки на сеть и большая надежность по сравнению с Inband-передачей факса.

Процедура передачи факса в режиме T.38 выглядит следующим образом:

Устанавливается обычное голосовое соединение по любому кодеку.
Когда бумага загружена в отправляющий факс, он периодически шлет T.30-сигнал CNG (Calling Tone), что означает готовность к передаче факса.
На принимающей стороне генерируется T.30-сигнал CED (Called Terminal Identification) - это готовность принять факс. Данный сигнал отправляется либо после нажатия кнопки «Получить факс» либо факс делает это автоматически.
На отправляющей стороне обнаруживается CED-сигнал и происходит процедура SIP REINVITE, а в SDP-сообщении указывается T.38 тип: m=image 39164 udptl t38.

Передавать факсы по интернету желательно в T.38. Если же факс нужно передать внутри офиса или между объектами, имеющими стабильное соединение, то можно использовать передачу факса Inband T.30. При этом перед передачей факса обязательно должна быть отключена процедура эхоподавления, чтобы не вносить дополнительные искажения.

Очень подробно про передачу факсов написано в книге «Fax, Modem, and Text for IP Telephony», авторы - David Hanes и Gonzalo Salgueiro.

5. Цифровая обработка сигналов (ЦОС). Обеспечение качества звука в IP-телефонии, примеры тестирования

С протоколами установления сеанса разговора (SIP/SDP) и методе передачи звука по RTP-каналу мы разобрались. Остался один немаловажный вопрос - качество звука. С одной стороны, качество звука определяется выбранным кодеком. Но с другой, необходимы еще дополнительные процедуры DSP (ЦОС - цифровой обработки сигналов). Данные процедуры учитывают особенности работы VoIP-телефонии: не всегда используется качественная гарнитура, в интернете бывают пропадания пакетов, иногда пакеты приходят неравномерно, пропускная способность сети тоже не резиновая.

Основные процедуры, улучшающие качество звука:

VAD (Voice activity detector) - процедура определения фреймов, которые содержат голос (активный голосовой фрейм) или тишину (неактивный голосовой фрейм). Такое разделение позволяет заметно снизить загрузку сети, поскольку передача информации о тишине требует гораздо меньше данных (достаточно лишь передать уровень шума или вообще ничего не передавать).

Некоторые кодеки уже содержат внутри себя процедуры VAD (GSM, G.729), для других же (G.711, G.722, G.726) нужно их реализовывать.

Если VAD настроен на передачу информации об уровне шума, то передаются специальные SID-пакеты (Silence Insertion Descriptor) в 13м RTP-формате CN (Comfort Noise).

Стоит заметить, что SID-пакеты могут быть отброшены SIP-прокси-серверами, поэтому для проверки желательно настраивать передачу RTP-трафика мимо SIP-серверов.

CNG (сomfort noise generation) - процедура генерации комфортного шума на базе сведений из SID-пакетов. Таким образом, VAD и CNG работают в связке, но CNG-процедура гораздо менее востребована, поскольку заметить работу CNG-можно не всегда, особенно при малой громкости.

PLC (packet loss concealment) - процедура восстановления звукового потока при потере пакетов. Даже при 50% потере пакетов хороший алгоритм PLC позволяет добиться приемлемого качества речи. Искажения, конечно, будут, но слова разобрать можно.

Простейший способ эмуляции потери пакетов (в Linux) - воспользоваться утилитой tc из пакета iproute с модулем netem . Она выполняет шейпинг только исходящего трафика.

Пример запуска эмуляции сети с потерей 50% пакетов:

Tc qdisc change dev eth1 root netem loss 50%

Отключение эмуляции:

Tc qdisc del dev eth1 root

Jitter buffer - процедура избавления от jitter-эффекта, когда интервал между принятыми пакетами очень сильно меняется, и что в худшем случае ведет к неверному порядку принимаемых пакетов. Также данный эффект приводит к прерываниям речи. Для устранения jitter-эффекта необходимо на принимаемой стороне реализовать буфер пакетов с размером, достаточным для восстановления исходного порядка отправления пакетов с заданным интервалом.

Эмулировать jitter-эффект также можно с помощью утилиты tc (интервал между ожидаемым моментом прихода пакета и фактическим может достигать 500 мс):

tc qdisc add dev eth1 root netem delay 500ms reorder 99%

LEC (Line Echo Canceller) - процедура устранения локального эха, когда удаленный абонент начинает слышать собственный голос. Ее суть заключается в том, чтобы вычесть из передаваемого сигнала принимаемый сигнал с некоторым коэффициентом.

Эхо может возникать по нескольким причинам:

акустическое эхо из-за некачественного аудиотракта (звук из динамика попадает в микрофон);
электрическое эхо из-за несогласованности импедансов между телефонным аппаратом и SLIC-модулем. В большинстве случаев это происходит в цепях преобразования 4-проводной телефонной линии в 2-проводную.

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

Более подробно о VoIP и процедурах ЦОС написано в книге VoIP Voice and Fax Signal Processing. Предпросмотр доступен на Google Books .

На этом поверхностный теоретический обзор VoIP завершен. Если интересно, то пример практической реализации мини-АТС на реальной аппаратной платформе можно будет рассмотреть в следующей статье.

[!?] Вопросы и комментарии приветствуются. На них будет отвечать автор статьи Дмитрий Валенто, инженер-программист дизайн-центра электроники Promwad .

Теги:

для начинающих
для новичков

Добавить метки

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-пакета?

Из описания видно, что с точки зрения измерений качества в 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-потоки?

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

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

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

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

Остался вопрос: как Беркут-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-порта, на который уйдёт статистика. Соответственно, каждый процесс, слушающий свой порт, получает примерно одинаковое количество трафика.

Cons and pros

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

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

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

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

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

Резюме

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

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

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

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

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

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

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

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

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

9. Перечень констант протокола

Этот раздел содержит перечень констант, определенных в спецификации протокола RTP.

Константы типа трафика RTP (PT - payload type) определяются в профилях. Однако, октет заголовка RTP, который содержит бит(ы) маркера и поле типа трафика, не должен содержать зарезервированные величины 200 и 201 (десятичный вид), чтобы пакеты RTP отличались от пакетов RTCP SR и RR. Для стандартного формата с одним битом маркера и семибитовым полем типа трафика, это ограничение означает, что типы трафика 72 и 73 использоваться не должны.

Значения типов пакетов RTCP (см. табл.1) выбраны в диапазоне от 200 до 204 для лучшего контроля корректности заголовка пакетов RTCP при сравнении с пакетами RTP. Когда поле типа пакета RTCP сравнивается с соответствующим октетом заголовка RTP, этот диапазон соответствует биту маркера, равному единице (чего обычно не бывает в информационных пакетах) и старшему разряду поля стандартного типа трафика, равному единице (в то время как статически заданные типы трафика обычно имеют значения PT с нулем в старшем разряде). Этот диапазон был также выбран для большего дистанцирования от значений 0 и 255, так как поля, целиком состоящие из нулей или единиц, в основном характерны для данных.

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

Допустимые типы пунктов пакета SDES представлены в табл. 2 . Другие типы пунктов SDES назначаются Сообществом IANA. Разработчики имеют возможность регистрировать значения, которые им нужны при выполнении экспериментальных исследований, а затем аннулировать регистрацию, когда необходимость в этих значениях исчезнет.

10. Описание профиля и формата трафика

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

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

Дополнительный документ второго типа - спецификация формата трафика - определяет, как конкретный вид трафика (например, видеосигнал, кодированный согласно H.261) должен передаваться в соответствии с RTP. Один и тот же формат трафика может использоваться для множества профилей и может, следовательно, быть определен независимо от профиля. Документы профиля отвечают лишь за соответствие этого формата и значения PT.

В описании профиля могут определяться следующие пункты, но этот список не является исчерпывающим.

Заголовок пакета данных RTP. Октет в заголовке пакета данных RTP, который содержит бит маркера и поле типа трафика, может быть переопределен в соответствии с профилем для удовлетворения различным требованиям, например, для обеспечения большего или меньшего количества битов маркера (раздел 3.3).

Типы трафика. Профиль обычно определяет множество форматов трафика (например, алгоритмов кодирования мультимедийных данных) и заданное по умолчанию статическое соответствие этих форматов и значений РТ. Некоторые из форматов трафика могут быть определены ссылкой на отдельные описания формата трафика. Для каждого определенного типа трафика профиль должен задать необходимую для использования тактовую частоту временной метки RTP (раздел 3.1).

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

Расширения заголовка пакета данных RTP. Должно быть определено содержимое первых 16 битов структуры расширения заголовка пакета данных RTP, если использование этого механизма позволено профилем.

Типы пакетов RTCP. Могут быть определены (и зарегистрированы IANA) новые, зависящие от класса приложения типы пакетов RTCP.

Интервал отчетности RTCP. Профиль должен определить величины, используемые при вычислении интервала отчетности RTCP: часть полосы пропускания сеанса RTCP, минимальный интервал отчетности и разделение полосы пропускания между отправителями и получателями.

Расширение пакета SR/RR. Если имеется дополнительная информация об отправителе или получателе, которая должна регулярно передаваться, то для пакетов SR и RR протокола RTCP может быть определен раздел расширения.

Использование SDES. Профиль может определять относительные приоритеты для пунктов SDES протокола RTCP, которые будут переданы или исключены (см. раздел 4.2.2); альтернативный синтаксис или семантику для пункта CNAME (раздел 4.4.1); формат пункта LOC (раздел 4.4.5); семантику и использование пункта NOTE (раздел 4.4.7) и новые пункты SDES, которые должны регистрироваться в IANA.

Безопасность. Профиль может определять, какие услуги по обеспечению безопасности и алгоритмы нужно использовать приложениям, и может обеспечивать управление их использованием (раздел 7).

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

Протокол нижележащего уровня. Для передачи пакетов RTP может требоваться использование конкретной нижележащей сети или протокола транспортного уровня.

Транспортное соответствие. Может быть определено иное, чем указанное в разделе 8 стандартное соответствие RTP и RTCP адресам транспортного уровня, например, портам UDP.

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

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

11. Профиль RTP для аудио- и видеоконференций с минимальным управлением

В RFC 1890 приведено описание профиля для использования транспортного протокола реального времени RTP версии 2 и связанного с ним протокола управления RTCP в рамках групповой аудио- или видеоконференции, так называемого профиля RTP для аудио- и видеоконференций с минимальным управлением (RTP Profile for Audio and Video Conferences with Minimal Control). Этот профиль определяет аспекты RTP, не заданные в спецификации протокола RTP версии 2 (RFC 1889). Минимум управления означает, что не требуется никакая поддержка согласования параметров или управления принадлежностью (например, при использовании статических соответствий типов трафика и индикаций принадлежности, обеспечиваемых RTCP). Рассмотрим основные положения данного профиля.

11.1. Форматы пакетов RTP и RTCP и параметры протокола

Данный раздел содержит описание ряда пунктов, которые могут быть определены или изменены в профиле.

Заголовок информационного пакета RTP. Используется стандартный формат фиксированного заголовка информационных пакетов RTP (один бит маркера).

Типы трафика. Статические значения типов трафика определены в разделах 11.3 и 11.4.

Дополнения заголовков информационных пакетов RTP. К заголовкам информационных пакетов RTP не присоединяются никакие дополнительные фиксированные поля.

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

Типы пакетов RTCP. Никаких дополнительных типов пакетов RTCP в этой спецификации профиля не определено.

Интервал отчетности RTCP. При вычислении интервала отчетности RTCP должны использоваться константы, предложенные в RFC 1889.

Расширения пакетов SR/RR. Расширения для пакетов SR и RR протокола RTCP не определены.

Использование SDES. Приложения могут использовать любой из описанных пунктов SDES. В то время как информация о каноническом имени (CNAME) посылается в каждом отчетном интервале, другие пункты должны передаваться только в каждом пятом интервале отчетности.

Безопасность. Заданные по умолчанию службы безопасности RTP также определяются по умолчанию этим профилем.

Соответствие пароль-ключ. Вводимый пользователем пароль преобразуется с использованием алгоритма MD5 в 16-октетный дайджест. N-битовый ключ получается из дайджеста, путем использования его первых N битов. Предполагается, что пароль может включать только буквы в коде ASCII, цифры, дефисы и пробелы, чтобы уменьшить вероятность искажений при передаче паролей по телефону, факсу, телексу или электронной почте. Паролю может предшествовать спецификация алгоритма шифрования. Любые символы вплоть до первой наклонной черты вправо (код ASCII 0x2f) воспринимаются, как название алгоритма шифрования. Если наклонная черта вправо отсутствует, то по умолчанию считается, что используется алгоритм шифрования DES-CBC.

Перед применением алгоритма закрытия пароль, вводимый пользователем, преобразуется в каноническую форму. Для этого пароль преобразуется в набор символов ISO 10646 с использованием кодирования UTF-8, как определено в Приложении P к ISO/IEC 10646-1:1993 (символы ASCII не требует никакого преобразования); удаляются пробелы в начале и конце пароля; два или более пробелов заменяются на один пробел (ASCII или UTF-8 0x20); все буквы преобразуются в буквы нижнего регистра

Нижележащий протокол. Профиль определяет использование RTP над протоколом UDP в двухстороннем и групповом режиме.

Транспортное соответствие. Используется стандартное соответствие RTP и RTCP адресам транспортного уровня.

Инкапсуляция. Инкапсуляция пакетов RTP не определена.

11.2. Регистрация типов трафика

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

условное наименование типа кодирования и тактовая частота временной метки RTP (условные наименования должны иметь длину в три или четыре символа для обеспечения компактного представления, если это необходимо);
указание того, кто имеет право изменять тип кодирования (например, ISO, CCITT/ITU, другие международные организации по стандартизации, консорциум, конкретная компания или группа компаний);
любые рабочие параметры;
ссылки на доступные описания алгоритма кодирования, например (в порядке предпочтения) RFC, изданная статья, регистрация патента, технический отчет, исходный текст кодека или справочник;
для частных типов кодирований, контактная информация (почтовый адрес и адрес электронной почты);
величина для обозначения типа трафика этого профиля, в случае необходимости (см. ниже).
Заметим, что не все типы кодирования, которые нужно использовать с RTP, должны быть назначены статически. Для установления динамического соответствия между значением типа трафика (PT) в диапазоне от 96 до 127 и типом кодирования могут использоваться «не-RTP средства», не рассматриваемые в этой статье.
Доступное пространство значений типов трафика достаточно мало. Новые типы трафика назначаются статически (постоянно) только, если выполнены следующие условия:
кодирование в большой степени интересует сообщество сети Internet;
оно предлагает выгоды, сравнимые с существующими кодированиями и/или требуется для взаимодействия с существующими, широко используемыми системами конференцсвязи или мультимедийными системами;
описание достаточно для создания декодера.

11.3. Кодирование звукового сигнала

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

Тактовая частота RTP, используемая при генерации временной метки RTP, не зависит от числа каналов и типа кодирования; она равна числу периодов дискретизации в секунду. Для N-канального кодирования (стерео, квадро и т.п.) каждый период дискретизации (скажем, 1/8000 секунды) генерирует N отсчетов. Общее число отсчетов, сгенерированных за секунду, равно произведению частоты дискретизации на число каналов.

При использовании нескольких звуковых каналов они нумеруются «слева направо», начиная с первого. В звуковых пакетах RTP данные из каналов с меньшими номерами предшествуют данным из каналов с большими номерами. Для более чем двух каналов используется следующая систем обозначений:

l - левый;
r - правый;
c - центральный;
S - периферийный;
F - фронтальный;
R - тыльный.

Число каналов	Название системы	Номера каналов
Число каналов	Название системы	1	2	3	4	5	6
2	стерео	l	r
3		l	r	c
4	квадро	Fl	Fr	Rl	Rr
4		l	c	r	S
5		Fl	Fr	Fc	Sl	Sr
6		l	lc	c	r	rc	S

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

Частота дискретизации должна быть выбрана из множества: 8000, 11025, 16000, 22050, 24000, 32000, 44100 и 48000 Гц (компьютеры Macintosh Apple имеют собственные значения частоты дискретизации 22254,54 и 11127,27, которые могут быть преобразованы в 22050 и 11025 с допустимым качеством путем пропуска четырех или двух отсчетов в 20-миллисекундном кадре). Однако, большинство алгоритмов кодирования звука определено для более ограниченного множества частот дискретизации. Получатели должны быть готовы принимать многоканальный звук, но могут выбирать и монофонический режим.

Для пакетизации звукового сигнала, заданный по умолчанию интервал пакетизации должен иметь продолжительность 20 ms, если при описании кодирования не указано иное значение. Интервал пакетизации определяет минимальную задержку «из конца в конец». В более длинных пакетах под заголовок отводится относительно меньшая часть байтов, но они вызывают большую задержку и делают потери пакетов более значимыми. Для не интерактивных приложений, таких как лекции, или каналов со значительными ограничениями полосы пропускания может быть допустима более высокая задержка пакетизации. Получатель должен принимать пакеты со звуковым сигналом с задержкой от 0 до 200 ms. Это ограничение обеспечивает приемлемый размер буфера для получателя.

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

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

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

Для основанных на кадрах кодеков, порядок следования каналов определен для целого блока. То есть, для стереозвука отсчеты для левого и правого каналов кодируются независимо; при этом кадр кодирования для левого канала предшествует кадру для правого канала.

Все ориентированные на кадры звуковые кодеки должны быть способны кодировать и декодировать несколько последовательных кадров, передаваемых внутри одного пакета. Так как размер кадра для ориентированных на кадры кодеков задан, то нет никакой потребности использовать отдельное обозначение для одного и того же кодирования, но с различным числом кадров в пакете.

В табл. 3 представлены значения типов трафика (PT), определенных данным профилем для звуковых сигналов, их условные обозначения и основные технические характеристики алгоритмов кодирования.

11.4. Кодирование видеосигнала

В табл. 4 представлены значения типов кодирования (РТ), условные обозначения алгоритмов кодирования и технические характеристики алгоритмов кодирования видеосигнала, определяемых данным профилем, а также не назначенные, зарезервированные и динамически задаваемые значения РТ.

Значения типа трафика в диапазоне от 96 до 127 могут быть определены динамически через протокол управления конференции, который не рассматривается в данной статье. Например, каталог сеанса может определять, что для данного сеанса связи, тип трафика 96 обозначает кодирование PCMU, двухканальное с частотой дискретизации 8000 Гц. Диапазон значений типа трафика, отмеченный, как «зарезервировано», не используется, чтобы пакеты протоколов RTCP и RTP могли надежно различаться.

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

Звуковые приложения, использующие данный профиль, должны, как минимум, быть способны посылать и получать трафик типа 0 (PCMU) и 5 (DVI4). Это позволяет взаимодействовать без согласования формата.

11.5. Назначение портов

Как определено в описании протокола RTP, данные RTP должны передаваться через порт UDP с четным номером, а соответствующие пакеты RTCP должны передаваться через порт с номером, на единицу большим (нечетным номером).

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

Однако по умолчанию могут быть заданы номера портов 5004 и 5005. Приложения, которые используют множество профилей, могут выбирать эту пару портов, как индикатор данного профиля. Но приложения могут также требовать, чтобы пара портов была задана в явном виде.

12. Список используемых терминов и сокращений

ASCII (American Standart Code for Information Interchange) - американский стандартный код для обмена информацией. Семиразрядный код для представления текстовой информации, используемый с отдельными модификациями в большинстве вычислительных систем
CBC (cipher block chaining) - цепочка шифруемых блоков, режим стандарта шифрования данных DES
CELP (code-excited linear prediction) - тип кодирования звуковых сигналов, использующий линейное предсказание с кодовым возбуждением
CNAME (canonical name) - каноническое имя
CSRC (сontributing source) - включаемый источник. Источник потока пакетов RTP, который внес свой вклад в комбинированный поток, произведенный микшером RTP. Микшер вставляет в заголовок пакета протокола RTP список идентификаторов SSRC тех источников, которые участвовали в формировании этого пакета. Этот список называется списком CSRC. Пример: микшер передает идентификаторы говорящих в данный момент участников телеконференции, звуки голосов которых были смикшированы и использованы при создании исходящего пакета, указывая получателю на текущий источник сообщений, даже если все звуковые пакеты содержат один и тот же идентификатор SSRC (такой, как у микшера)
DES (Data Encryption Standard) - стандарт шифрования данных
IANA (Internet Assigned Numbers Authority) - Сообщество назначения номеров Internet
IMA (Interactive Multimedia Association) - Ассоциация интерактивного мультимедиа
IP (Internet Protocol) - межсетевой протокол, протокол сетевого уровня, дейтаграммный протокол. Позволяет пакетам пересекать на пути к пункту назначения множество сетей
IPM (IP Multicast) – групповая передача с использованием протокола IP
LD-CELP (low-delay code excited linear prediction) - алгоритм кодирования речи с использованием линейного предсказания с кодовым возбуждением и низкой задержкой
LPC (linear predictive encoding) - кодирование с линейным предсказанием
NTP (Network Time Protocol) - сетевой протокол времени, является отсчетом времени в секундах относительно нуля часов 1 января 1900 года. Полный формат временной метки NTP - 64-разрядное число без знака с фиксированной запятой с целой частью в первых 32 битах и дробной - в последних 32 битах. В некоторых случаях используется более компактное представление, в котором взяты из полного формата только средние 32 бита: младшие 16 битов целой части и старшие 16 битов дробной части
RPE/LTP (residual pulse excitation/long term prediction) - алгоритм кодирования речевого сигнала с разностным импульсным возбуждением и долговременным предсказанием
RTCP (Real-Time Control Protocol) - протокол управления передачей данных в реальном масштабе времени
RTP (Real-Time Transport Protocol) - транспортный протокол реального времени
SSRC (synchronization source) - источник синхронизации. Источник потока пакетов RTP, идентифицированный 32-разрядным числовым идентификатором SSRC, который передается в заголовке RTP, независимо от сетевого адреса. Все пакеты с одним источником синхронизации используют единый интервал таймирования и единое пространство порядковых номеров, так что получатель группирует пакеты для воспроизведения с помощью источника синхронизации. Пример источника синхронизации: отправитель потока пакетов, полученных из источника сигнала типа микрофона, видеокамеры или микшера RTP. Источник синхронизации может через какое-то время изменять формат данных, например, звуковое кодирование. Идентификатор SSRC - случайно выбранная величина, которая считается глобально уникальной в пределах конкретного сеанса RTP. Участнику телеконференции не требуется использовать один и тот же идентификатор SSRC для всех сеансов RTP в мультимедийном сеансе связи; объединение идентификаторов SSRC обеспечивается посредством протокола RTCP. Если участник генерирует множество потоков в одном сеансе RTP, например, от множества видеокамер, то каждый поток должен идентифицироваться отдельным SSRC
TCP (Transmission Control Protocol) - протокол транспортного уровня, используемый совместно с протоколом IP
UDP (User Datagram Protocol) - протокол транспортного уровня без установления логического соединения. UDP обеспечивает только посылку пакета одной или нескольким станциям сети. Проверка правильности и обеспечение целостности (гарантированной доставки) передачи данных осуществляется на более высоком уровне
АДИКМ - адаптивная дифференциальная импульсно-кодовая модуляция
джиттер (jitter) - дрожание, отклонения фазы или частоты сигнала; применительно к IP-телефонии - неравномерности задержки дейтаграмм в сети
ЗПД - звено передачи данных (второй уровень Эталонной модели взаимодействия открытых систем)
ИВС - информационно-вычислительные сети
микшер (mixer) - промежуточная система, которая получает пакеты RTP от одного или более источников, возможно, изменяет формат данных, объединяет пакеты в новый пакет RTP и затем передает его. Так как множество источников сигналов в общем случае не синхронизировано, микшер корректирует таймирование составляющих потоков и генерирует собственную синхронизацию для объединенного потока. Таким образом, все информационные пакеты, сформированные микшером, идентифицируются, как имеющие микшер в качестве их источника синхронизации
монитор (monitor) - приложение, которое получает пакеты RTCP, посланные участниками сеанса RTP, в частности, отчеты приема, и оценивает текущее качество обслуживания для контроля распределения, обнаружения ошибок и долговременной статистики. Обычно функции монитора лежат на приложениях, используемых в сеансе связи, но монитор может быть и отдельным приложением, которое иным образом не используется, не посылает или не получает информационные пакеты RTP. Такие приложения называются мониторами третьей стороны
МСЭ-Т - Сектор стандартизации электросвязи Международного союза электросвязи
оконечная система (еnd system) - приложение, которое генерирует содержимое, передаваемое в пакетах RTP, и/или которое потребляет содержимое полученных пакетов RTP. Оконечная система может действовать как один или более (но обычно только один) источников синхронизации в каждом сеансе RTP
пакет RTCP - управляющий пакет, состоящий из фиксированной части заголовка, подобной заголовкам информационных пакетов протокола RTP, за которой следуют структурные элементы, изменяемые в зависимости от типа пакета RTCP. Обычно, множество пакетов RTCP передается вместе, как составной пакет RTCP в одном пакете нижележащего протокола; это обеспечивается полем длины в фиксированном заголовке каждого пакета RTCP
пакет RTP - протокольный блок данных, состоящий из фиксированного заголовка RTP, возможно, пустого списка включаемых источников, расширения и трафика. Обычно в одном пакете протокола нижележащего уровня содержится один пакет RTP, но может быть и несколько
порт - абстракция, используемая протоколами транспортного уровня для различения множества адресатов в пределах одного хост-компьютера. Порт определяется своим номером. Таким образом, номер порта - это число, определяющее конкретное приложение, которому предназначены пересылаемые данные. Этот номер, вместе с информацией о том, какой протокол (например, TCP или UDP) используется на вышележащем уровне, содержится среди прочей служебной информации в пересылаемых через Internet дейтаграммах. Транспортные селекторы (TSEL - transport selector), используемые транспортным уровнем OSI, эквивалентны портам
профиль (profile) - набор параметров протоколов RTP и RTCP для класса приложений, определяющий особенности их функционирования. В профиле определяются использование полей бита маркера и типа трафика в заголовке пакета данных RTP, типы трафика, дополнения к заголовку пакета данных RTP, первые 16 битов расширения заголовка пакета данных RTP, типы пакетов RTCP, интервал отчетности RTCP, расширение пакетов SR/RR, использование пакетов SDES, услуги и алгоритмы обеспечения безопасности связи и особенности использования протокола нижележащего уровня
сеанс связи RTP (RTP session) - связь множества участников, взаимодействующих посредством протокола RTP. Для каждого участника, сеанс определяется конкретной парой транспортных адресов назначения (один сетевой адрес плюс пара портов для RTP и RTCP). Пара транспортных адресов назначения может быть общей для всех участников (как в случае IPМ) или может быть отличной для каждого (индивидуальный сетевой адрес и общая пара портов, как при двусторонней связи). В мультимедийном сеансе трафик каждого типа передается в отдельном сеансе RTP со своими собственными пакетами RTCP. Групповые сеансы RTP различаются различными номерами пар портов и/или различными групповыми адресами
средства не RTP (non-RTP means) - протоколы и механизмы, которые могут быть необходимы в дополнение к RTP, чтобы обеспечить приемлемое обслуживание. В частности, для мультимедийных конференций, приложение управления конференцией может распределять групповые адреса и ключи шифрования, согласовывать алгоритм шифрования, который нужно использовать, и определять динамические соответствия между величинами типа трафика RTP и форматами трафика, которые они представляют (форматами, которые не имеют предопределенной величины типа трафика). Для простых приложений также могут использоваться электронная почта или базы данных конференций
транслятор (translator) - промежуточная система, которая направляет пакеты RTP, не изменяя идентификатор источника синхронизации. Примеры трансляторов: приборы, которые выполняют перекодировку без микширования, многосторонние или двунаправленные репликаторы, приложения прикладного уровня в брандмауэрах
транспортный адрес (transport address) - комбинация сетевого адреса и номера порта, которая идентифицирует оконечную точку транспортного уровня, например, IP-адрес и номер порта UDP. Пакеты передаются от транспортного адреса источника до транспортного адреса назначения
трафик RTP - мультимедийные данные, передаваемые в пакете протокола RTP, например, звуковые отсчеты или сжатые видеоданные
ТСОП - телефонные сети общего пользования