В данном разделе рассмотрены некоторые аспекты переноса пакетов 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, например, звуковые отсчеты или сжатые видеоданные
• ТСОП - телефонные сети общего пользования

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 сможет корректировать ошибки и сбои, возникающие при передаче данных.

Требование поддержки нескольких типов трафика с различными требованиями к качеству обслуживания на базе стека протоколов TCP/IP сейчас весьма акту­ально. Эту задачу призван решить транспортный протокол реального времени (Real-Time Transport Protocol, RTP), который является стандартом IETF для передачи таких данных, как голос или видео, в реальном времени по сети, не гарантирующей качества обслуживания.

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

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

Адресная схема протокола IP

Межсетевая схема адресации, применяемая в протоколе IP, описана в докумен­тах RFC 990 и RFC 997. В ее основе лежит разделение адресации сетей от адре­сации устройств в этих сетях. Такая схема облегчает маршрутизацию. При этом адреса должны назначаться упорядоченно (последовательно), для того чтобы сделать маршрутизацию более эффективной.

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

Итак, для каждого устройства в сетях IP можно говорить об адресах трех уровней:

q Физический адрес устройства (точнее - определенного интерфейса). Для устройств в сетях Ethernet - это МАК - адрес сетевой карты или порта маршрутизатора. Эти адреса назначаются производителями оборудования. Физический адрес имеет шесть байтов: старшие три байта - идентифика­тор фирмы-производителя, младшие три байта назначаются самим произ­водителем;

q IP-адрес, состоящий из четырех байт. Этот адрес используется на сетевом уровне эталонной модели OSI;

q Символьный идентификатор - имя. Этот идентификатор может назна­чаться администратором произвольно.

Когда протокол IP был стандартизован в сентябре 1981 года, его специфика­ция требовала, чтобы каждое устройство, подключенное к сети, имело уникаль­ный 32-битный адрес. Этот адрес разбивается на две части. Первая часть адреса идентифицирует сеть, в которой располагается устройство. Вторая часть одноз­начно идентифицирует само устройство в рамках сети. Такая схема приводит к двухуровневой адресной иерархии (рис. 6.23).

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

Для обеспечения гибкости в присвоении адресов компьютерным сетям разра­ботчики протокола определили, что адресное пространство IP должно быть раз­делено на три различных класса - А, В и С. Зная класс, вы знаете, где в 32-битном адресе проходит граница между сетевым префиксом и номером устройства. На рис. 6.24 показаны форматы адресов этих основных классов.

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

Недостатком такого метода является необходимость изменения сетевого ад­реса при подключении дополнительных устройств. Например, если общее число устройств в сети класса С будет превышать 255, то потребуется заменить ее адреса на адреса класса В. Изменение сетевых адресов потребует от админист­ратора дополнительных усилий по отладке сети. Администраторы сетей не могут осуществить плавный переход к новому классу адресов, так как классы четко разделены. Приходится запрещать использовать целую группу сетевых адресов, производить одновременное изменение всех адресов устройств в этой группе, и только затем вновь разрешать их использование в сети. Кроме того, введение классов адресов значительно уменьшает теоретически возможное число индивидуальных адресов. В текущей версии протокола IP (версия 4) общее число адресов могло составлять 2 32 (4 294 967 296), так как протокол преду­сматривает использование 32 бит для задания адреса. Естественно, использование части бит в служебных целях уменьшает доступное количество индивидуальных адресов.

Класс А предназначен для больших сетей. Каждый адрес класса А имеет 8-битовый префикс сети, в котором старший бит установлен в 1, а следующие семь бит используются для номера сети. Для номера устройства задействуются оставшиеся 24 бита. В настоящий момент все адреса класса А уже выделены. Сети класса А также обозначаются как «/8», поскольку адреса этого класса имеют 8-битовый сетевой префикс.

Максимальное число сетей класса А составляет 126 (2 7 -2 - вычитаются два адреса, состоящие из одних нулей и единиц). Каждая сеть этого класса поддер­живает до 16 777 214 (2 24 -2) устройств. Так как адресный блок класса А может содержать максимум до 2 31 (2 147483648) индивидуальных адресов, а в прото­коле IP версии 4 может поддерживаться максимум до 2 32 (4 294 967 296) адре­сов, то класс А занимает 50 % общего адресного пространства протокола IP.

Класс В предназначен для сетей среднего размера. Каждый адрес класса В имеет 16-битовый сетевой префикс, в котором два старших бита равны 10, а следующие 14 бит используются для номера сети. Для номера устройства выде­лены 16 бит. Сети класса В также обозначаются как «/16», поскольку адреса этого класса имеют 16-битный сетевой префикс.

Максимальное число сетей класса В равно 16 382 (2 14 -2). Каждая сеть этого класса поддерживает до 65 534 (2 16 -2) устройств. Так как весь адресный блок класса В может содержать максимум до 2 30 (1 073 741 824) индивидуальных ад­ресов, он занимает 25 % общего адресного пространства протокола IP.

Адреса класса С используются в сетях с небольшим числом устройств. Каж­дая сеть класса С имеет 24-битный сетевой префикс, в котором три старших бита равны 110, а следующие 21 бит используются для номера сети. Под номера устройства выделены оставшиеся 8 бит. Сети класса С также обозначаются как «/24», поскольку адреса этого класса имеют 24-битный сетевой префикс.

Максимальное число сетей класса С составляет 2 097 152 (2 21). Каждая сеть этого класса поддерживает до 254 (2 8 -2) устройств. Класс С занимает 12.5 % общего адресного пространства протокола IP.

В табл. 6.9 подводится итог нашему анализу классов сетей.

Таблица 6.9. Классы сетей

В дополнение к этим трем классам адресов выделяют еще два класса. В клас­се D старшие четыре бита равны 1110. Этот класс используется для групповой передачи данных. В классе Е старшие четыре бита - 1111. Он зарезервирован для проведения экспериментов.

Для удобства чтения адресов в технической литературе, прикладных про­граммах и т. д. IP-адреса представляются в виде четырех десятичных чисел, раз­деленных точками. Каждое из этих чисел соответствует одному октету (8 битам) IP-адреса. Этот формат называют точечно-десятичным (Decimal-Point Notation) или точечно-десятичной нотацией (рис. 6.25).

В табл. 6.10 перечислены диапазоны десятичных значений трех классов адре­сов. В табл. 6.10 запись XXX означает произвольное поле.

Таблица 6.10. Диапазоны значений адресов

Некоторые IP-адреса не могут присваиваться устройствам в сети (табл. 6.11).

Как показано в этой таблице, в зарезервированных IP-адресах все биты, установленные в ноль, соответствуют либо данному устройству, либо данной сети, а IP-адреса, все биты которых установлены в 1, используются при ши­роковещательной передаче информации. Для ссылки на всю IP-сеть в целом используется адрес с номером устройства, у которого все биты установлены в «0». Сетевой адрес класса А - 127.0.0.0 зарезервирован для обратной связи и введен для проверки взаимодействия между процессами на одной машине. Ког­да приложение использует адрес обратной связи (loopback), стек протоколов TCP/IP возвращает эти данные приложению, ничего не посылая в сеть. Кроме того, данный адрес можно использовать для взаимодействия отдельных процес­сов в пределах одной машины. Поэтому в сетях IP запрещается присваивать устройствам IP-адреса, начинающиеся со 127.

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

Направленное широковещание позволяет устройству из удаленной сети по­слать дейтаграмму всем устройствам в текущей сети. Дейтаграмма с направлен­ным широковещательным адресом может проходить через маршрутизаторы, но доставлена она будет только всем устройствам в указанной сети, а не вообще всем устройствам. При направленном широковещании адрес получателя состоит из номера конкретной сети и номера устройства, все биты которого равны 0 или 1. Например, адреса 185.100.255.255 и 185.100.0.0 будут рассматриваться как адреса направленного широковещания для сети 185.100.xxx.xxx класса В. С точки зрения адресации, главным недостатком направленного широковеща­ния является то, что требуется знание номера целевой сети.

Вторая форма широковещания, называемая ограниченным широковещанием, обеспечивает широковещательную передачу в рамках текущей сети (сети, где находится устройство-отправитель). Дейтаграмма с ограниченным широкове­щательным адресом никогда не будет пропущена через маршрутизатор. При ограниченном широковещании биты номера сети и номера устройства состоят из всех нулей или единиц. Таким образом дейтаграмма с адресом получате­ля 255.255.255.255 или 0.0.0.0 будет доставлена всем устройствам в сети. На рис. 6.26 показаны сети, связанные маршрутизаторами. В табл. 6.12 перечис­лены получатели широковещательных дейтаграмм, отправляемых рабочей стан­цией А.

Протокол IP поддерживает три способа адресации: единичную (unicast), ши­роковещательную (broadcast) и групповую (multicast).

Таблица 6.12. Получатели широковещательных дейтаграмм

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

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

При групповой адресации дейтаграммы доставляются определенной группе устройств. При этом (что очень важно при работе в распределенных сетях) не генерируется избыточный трафик. Дейтаграммы с групповым и единичным ад­ресом различаются адресом. В заголовке IP-дейтаграммы с групповой адреса­цией вместо IP-адресов классов А, В, С содержится адрес класса D, то есть групповой адрес.

Групповой адрес присваивается некоторым устройствам-получателям или, иными словами, группе. Отправитель записывает данный групповой адрес в за­головок IP-дейтаграммы. Дейтаграмма будет доставлена всем членам группы. Первые четыре бита адреса класса D равны 1110. Остальную часть адреса (28 бит) занимает идентификатор группы (рис. 6.27).

В точечно-десятичном формате групповые адреса лежат в диапазоне от 224.0.0.0 до 239.255.255.255. В табл. 6.13 показана схема распределения адресов класса D.

Таблица 6.13. Распределение адресов класса D

Как видно из табл. 6.13, первые 256 адресов зарезервированы. В частности, этот диапазон отведен протоколам маршрутизации и другим низкоуровневым протоколам. В табл. 6.14 содержатся некоторые зарезервированные IP-адреса класса D.

Выше этого диапазона находится большая группа адресов, выделенных для приложений, работающих в сети Internet. Самый верхний диапазон адресов (примерно 16 миллионов адресов) предназначен для административных целей в локальных сетях. Централизованным управлением и регистрацией групповых адресов класса D занимается специальная организация IANA.

Групповая адресация может быть реализована на двух уровнях модели OSI - канальном (Data-Link Layer) и сетевом (Network Layer). Протоколы пе­редачи канального уровня, например, Ethernet и FDDI, могут поддерживать еди­ничную, широковещательную и групповую адресацию. Групповая адресация на канальном уровне особенно эффективна, если она поддерживается сетевой пла­той аппаратно.

Для поддержки групповой адресации IANA выделен блок групповых Ether­net-адресов, начиная с 01-00-5Е (в шестнадцатеричном представлении). Груп­повой IP-адрес может транслироваться в адрес из этого блока. Принцип трансляции достаточно прост: младшие 23 бита идентификатора IP-группы ко­пируются в младшие 23 бита Ethernet-адреса. При этом необходимо учитывать, что данная схема ассоциирует до 32 различных IP-групп с одним и тем же Ethernet-ад­ресом, так как следующие 5 бит идентификатора IP-группы игнорируются.

Таблица 6.14. Зарезервированные адреса класса D

Адрес	Назначение
224.0.0.1	Все устройства подсети
224.0.0.2	Все маршрутизаторы подсети
224.0.0.4	Все DVMRP-маршрутизаторы
224.0.0.5	Все MOSPF-маршрутизаторы
224.0.0.9	RIP IP версии II
224.0.1.7	Аудионовости
224.0.1.11	IEFT аудио
224.0.1.12	IEFT видео

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

Если отправитель и получатель находятся в разных подсетях, связанных мар­шрутизаторами, доставка дейтаграмм затруднена. В этом случае маршрутизато­ры должны поддерживать один из групповых протоколов маршрутизации (DVMRP, MOSPF, PIM - см. ниже). Согласно этим протоколам маршрутиза­тор построит дерево доставки и правильно передаст групповой трафик. Кроме того, каждый маршрутизатор должен поддерживать протокол управления груп­пами (IGMP) для определения наличия членов группы в непосредственно под­ключенных подсетях (рис. 6.28).

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

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

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

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

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

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 выполняет несколько функций:

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

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

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

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

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

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

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

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

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

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

0

2

3

4

8

16

31

Synchronization Source (SSRC) Identifier
Contributing Source (CSRC) Identifiers

Рис. 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

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

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

Литература

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

Добрый день!

Итого: система мониторинга представляет собой комплекс, подключаемый в неинтрузивном режиме к 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 следующее:

1. получаем пакет, разбираем на поля;
2. если версия равна 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’овых подсистем (распределение очередей по прерываниям, увеличение приёмных буферов, директивное выделение ядер на конкретные процессы и т.п.) я оставил за рамками статьи, т.к. эта тема и так уже очень хорошо освещена.

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

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