rtp что это такое

Rtp что это такое

Протокол RTP (англ. Real-time Transport Protocol ) работает на транспортном уровне и используется при передаче трафика реального времени. Протокол был разработан Audio-Video Transport Working Group в IETF и впервые опубликован в 1996 году как RFC 1889, и заменён в RFC 3550 в 2003 году.

Протокол RTP переносит в своём заголовке данные, необходимые для восстановления голоса или видеоизображения в приёмном узле, а также данные о типе кодирования информации (JPEG, MPEG и т. п.). В заголовке данного протокола, в частности, передаются временная метка и номер пакета. Эти параметры позволяют при минимальных задержках определить порядок и момент декодирования каждого пакета, а также интерполировать потерянные пакеты.

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

Установление и разрыв соединения не входит в список возможностей RTP, такие действия выполняются сигнальным протоколом (например, RTSP или SIP протоколом).

Содержание

Описание протокола

RTP был разработан как протокол реального времени, из конца в конец (end-to-end), для передачи потоковых данных. В протокол заложена возможность компенсации джиттера и детектированию нарушения последовательности пакетов данных — типичных событий при передаче через IP-сети. RTP поддерживает передачу данных для нескольких адресатов через Multicast. [1] RTP рассматривается как основной стандарт для передачи голоса и видео в IP-сетях и совместно с кодеками.

Приложения, формирующие потоки реального времени, требуют своевременной доставки информации и для достижения этой цели могут допустить некоторую потерю пакетов. Например, потеря пакета в аудио-приложении может привести к доле секунды тишины, которая может быть незаметна при использовании подходящих алгоритмов скрытия ошибок. [2] Протокол TCP, хотя и стандартизирован для передачи RTP, [3] как правило не используется в RTP-приложениях, так как надежность передачи в TCP формирует временные задержки. Вместо этого, большинство реализаций RTP базируется на UDP. Кроме этого, существуют другие спецификации для транспортных протоколов SCTP и DCCP, но они мало распространены. [4] [5]

Компоненты протокола

Спецификация RTP описывает два под-протокола:

Сессии

RTP-сессия устанавливается для каждого потока мультимедиа. Сессия состоит из IP-адреса и пары портов для RTP и RTCP. Например, аудио и видео потоки будут иметь различные RTP-сессии, позволяющие приемнику для этого выделить конкретный поток. [6] Порты, которые образуют сессию, связываются друг с другом средствами других протоколов, таких как SIP (содержащий в своих сообщениях протокол SDP [7] ) и RTSP (используя SDP в методе Setup). В соответствии со спецификацией, RTP не имеет стандартного зарезервированного номера порта. Единственное ограничение состоит в том, что соединение проходит с использованием чётного номера, а следующий нечётный номер используется для связи по протоколу RTCP. RTP и RTCP обычно используют непривилегированные UDP-порты (16k-32k), но могут использовать и другие протоколы, поскольку сам протокол RTP независим от транспортного уровня.

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

Источник

Обзор и особенности протоколов передачи данных RTP/SRTP/ZRTP

RTP — (Realtime Transport Protocol) — является протоколом передачи мультимедийной информации в режиме реального времени прикладного уровня модели OSI. Данный протокол используется в системах связи, таких как телефония, видеоконференциях, IPTV и т.п. RTP использует в качестве транспорта протокол UDP, а для мониторинга статистики передачи и обеспечения качества обслуживания RTCP. Протокол RTP является одним из технических […]

RTP — (Realtime Transport Protocol) — является протоколом передачи мультимедийной информации в режиме реального времени прикладного уровня модели OSI. Данный протокол используется в системах связи, таких как телефония, видеоконференциях, IPTV и т.п.

RTP использует в качестве транспорта протокол UDP, а для мониторинга статистики передачи и обеспечения качества обслуживания RTCP. Протокол RTP является одним из технических основ в VoIP-телефонии, обеспечивая передачу голоса в таких протоколах, как SIP и IAX/IAX2.

Впервые спецификация протокола RTP была опубликована RFC в 1996 году, а в 2003 была опубликована версия спецификации, используемая по сей день.

Обзор протокола RTP

RTP изначально разрабатывался для передачи мультимедиа, поэтому он имеет следующие особенности:

К возможностям RTP стоит отнести такие функции, как компенсация джиттера, предоставление средств для отслеживания потерь среди пакетов и их неправильной доставки, контроля времени задержки. Также данный протокол позволяет проводить многоадресную доставку информации. Перечисленные элементы управления RTP, как правило выделяют в отдельный протокол RTCP (Real Time Control Protocol). Основной задачей RTCP является исправление ошибок и потерь при работе RTP, а также обеспечение обратной связи по качеству обслуживания при доставке данных.

Сеансы с использованием протокола RTP, как правило инициализируются между устройствами с помощью таких управляющих протоколов как SIP, IAX/IAX2, H.323. Они используются для создания и управления сеансом, в то время как RTP используется для передачи информации.

Взаимодействие RTP и RTCP

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

Безопасность при передаче мультимедиа данных

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

Протокол SRTP

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

Шифрование информации выполняется методом AES, что положительно отражается на криптозащите информации и скорости работы протокола.Возможности по конфигурированию шифрования в SRTP весьма широки вплоть до использования любого, описанного в RFC стандарта шифрования (с четко описанным алгоритмом) или отключения шифрования вовсе (используя NULL-шифр). Отключение шифрования может быть полезно для экономии аппаратных ресурсов в том случае, если для вас важно обеспечение целостности и правильного порядка доставки данных, но не требуется шифрование. При этом сохраняется защита от playback-атак, так как блоки передаваемой информации нумеруются и исключена возможность повторной передачи уже ранее принятого сообщения. Методы шифрования SRTP обеспечивают не только безопасную передачу, но так же и безопасное воспроизведение мультимедиа, т.е. злоумышленник не только не сможет расшифровать данные, но и также не сможет их подменить либо воспроизвести. Для аутентификации сообщений и защите его целостности используется алгоритм HMAC-SHA1, в качестве аргумента функция хеширования получает данные из заголовка пакета о полезной нагрузке им переносимой, т.е. обеспечивается высокий уровень криптозащиты. Слабым звеном в данной схеме является то, что заголовки пакетов SRTP не шифруются и по данным о передаваемой информации, злоумышленник может сделать косвенное предположение что происходит обмен мультимедиа и каким-то образом помешать передаче.
Еще одним механизмом обеспечения безопасности данных в протоколе SRTP является обновление ключей идентификации. На основе главного ключа генерируются дополнительные идентификационные ключи для каждой отдельной сессии. Таким образом, даже если злоумышленник получит ключ, передаваемый в сессии, то он не поможет ему для расшифровки других сессий, и объем полученных им данных не будет сколь-либо значительным.

Протокол ZRTP

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

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

ZRTP и Asterisk

Программная АТС Asterisk изначально не поддерживает ZRTP, так как логика работы Asterisk подразумевает что между абонентами всегда находится связующее звено в виде АТС. Логика же работы ZRTP принципиально отличается и старается исключить любую возможность промежуточных передач трафика во избежание его компрометации. Тем не менее существует набор патчей к Asterisk, разработанных в рамках проекта Zfone и описанных в библиотеке libzrtp, обеспечивающих поддержку данного протокола сервером Asterisk. Особенностью данной реализации является то, что она позволяет клиентским терминалам обмениваться RTP-трафиком непосредственно между друг другом, при этом параллельно терминалы обмениваются с АТС Asterisk SIP-трафиком. Шифруется только полезная нагрузка RTP/RTCP, заголовки пакетов передаются в незашифрованном виде.

Существует два основных режима работы реализации ZRTP в Asterisk: Passthrough и MiTM. В режиме сквозной передачи (Passthrough) АТС просто передает данные мультимедиа и сообщения ZRTP без изменений. Для поддержки данного режима, нужно внести только одно изменение — заставить Asterisk принимать и передавать сообщения протокола ZRTP. В режиме MiTM Asterisk действует как промежуточная точка и запускает протокол ZRTP для настройки безопасного соединения ZRTP между двумя конечными точками поочередно.

Процесс работы механизма реализации ZRTP для Asterisk сопровождается вызовами zrtp_event_callback () с соответствующими значениями событий. После запуска сеанса ZRTP существует три возможных стабильных состояния каждого потока: “Безопасный”, “Очистить” и “Ошибка”. Когда каждое состояние потока назначается, оно идентифицируется соответствующим обратным вызовом:

Источник

Внутренности протокола, которым браузеры передают голос и видео

WebRTC, технология голосовых и видеозвонков в браузерах (а еще realtime передачи произвольных данных, peer-to-peer пробивания NAT и захвата экрана) никогда не была простой. Долгая история, несовместимости между браузерами, запутанная документация, множество решаемых задач и используемых протоколов. Возможность позвонить и принять звонок из браузера всегда была одной из ключевых «фишек» нашей платформы Voximplant, и так как мы в этом неплохо разбираемся, то стараемся следить за интересными статьями и адаптировать их для аудитории Хабра. Под катом перевод свежей статьи от ребят из callstats.io — сервиса сбора статистики по качеству звонков для браузера. В небольшой статье они рассказывают о протоколе RTP с помощью которого, собственно, браузер и передает пакеты с голосом или видео.

WebRTC использует протокол SRTP (Secure Real-time Transport Protocol), чтобы обеспечить шифрование, аутентификацию и целостность сообщений, а также защитить RTP-данные от атак повторного воспроизведения. Это система безопасности, которая дает конфиденциальность за счет шифрования RTP-нагрузки и проверки подлинности. Эти фишки безопасности в WebRTC – ключевой момент надежности и основа для всего, что касается RTP (Real-time Transport Protocol). Но что такое RTP, как оно работает?

Что такое RTP?

RTP это сетевой протокол, спроектированный для мультимедийных коммуникаций (VoIP, видеоконференции, телепрезентации), потоковой передачи мультимедиа (видео по запросу, прямые трансляции) и широковещательное медиа. Протокол был определен организацией IETF (Internet Engineering Task Force) в стандарте RFC1889. Изначально RTP создали для поддержки видеоконференций, в которых есть географически распределенные участники, разработку вела рабочая группа IETF по аудио- и видеотранспорту. На текущий момент, версия v2 из стандарта RFC3550 используется уже 15 лет!

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

Для получения информации о качестве медиапотока внутри RTP используется «вложенный» протокол RTCP (RTP Control Protocol).

При использовании RTP отправляющая сторона упаковывает медиапоток в формат RTP пакетов и время от времени отсылает «RTCP Sender Report» для синхронизации медиапотоков между собой. Принимающая сторона организует «Jitter buffer» для сбор получаемых пакетов в правильном порядке и воспроизведения медиапотока в соответствии с информацией о таймингах, указанной в полученных пакетах. Если пакет теряется, то получающая сторона по возможности получает его еще раз или же “скрывает” проблему, интерполируя звук или разбивая видео на цветные квадратики. И, наконец, принимающая сторона передает в обратную сторону грубую или детальную статистику с помощью “RTCP Receiver Report”. Статистика позволяет отправителю выбирать битрейт, менять кодеки и выбирать объем коррекции ошибок.

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

Заголовок RTP пакета разделен на 4 части: источник синхронизации, метка времени, порядковый номер и тип полезной нагрузки.

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

2. RTP метка времени позволяет собирать из RTP пакетов медиа фреймы и воспроизводить медиапоток.

3. RTP порядковый номер: он и в африке порядковый номер, с его помощью находятся потерянные пакеты, а те что не потеряны — выстраиваются по порядку. UDP все-таки.

4. Тип полезной нагрузки определяет кодировку медиа данных в пакетах, его указывает кодек.

Отчеты RTCP

Известные в спецификации как «RTCP Reports», бывают трех типов: «Sender Reports» для отправителя, «Receiver Reports» для получателя и «Extended Reports» для всех участников процесса.

RTCP Sender Reports

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

RTCP Receiver Reports

Принимающая сторона осматривает получаемые потоки и отчитывается о происходящем с помощью пакетов «RTCP Receiver Report». В отчете указывается текущий уровень потерь пакетов, джиттер (буфер, в котором хранятся пакеты перед проигрыванием, чтобы подождать опоздавших и поменять местами запутавшихся), максимальный порядковый номер. Часть этих данных используется для расчета round trip time.

RTCP Extended Reports

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

Как выглядят форматы полезной нагрузки для RTP?

«Формат полезной нагрузки», payload format, задается такой штукой, которая в спецификации называется «кодированием», encoding. Непереводимая на русский игра слов описыват три варианта. Это может быть кодек, например H.264, H.263, H.261, MPEG-2, JPEG, G.711, G.722 или AMR. Это может быть «полезная нагрузка общего назначения», такая как «Forward Error Correction» (FEC), NACK и другие страшные акронимы. И, наконец, это могут быть мультиплексированные медиапотоки (несколько медиапотоков в рамках одного).

Спецификация жестко задает формат для кодеков и определяет два правила: агрегации и фрагментации. Правила агрегации описывают, как RTP работает с кодеками, которые производят пакеты меньше MTU — например, звуковыми кодеками. Правила фрагментации, наоборот, описывают работу с кодеками, предпочитающими большие пакеты, например пакеты с I-фреймами видеокодирования. RTP задает собственное фрагментирование, потому что IP фрагментирование для UDP как правило не работает, и NAT’ы с Firewall’ами просто молча дропают такие пакеты.

Для чего в RTP используются «Header Extensions»?

«Расширения» заголовков пакетов используются для информации, не имеющей отношения к медиапотокам. Обычно это та информация, которую нужно передавать в реальном времени — чаще, чем отсылаются RTCP отчеты.

Например, для интерактивных медиапотоков (видеочат?) RTP пакеты отправляются каждые несколько десятков миллисекунд. Расширение к RTP заголовкам может использоваться для индикации потерянных и полученных пакетов — чтобы реагировать быстрее, чем это позволяют получаемые время от времени RTCP отчеты с NACK/ACK.

Расширение заголовков обратно совместимо: если один из участников передачи данных не понимает этот формат, то он будет просто игнорировать соответствующую часть заголовка пакета. Заголовки описаны в спецификации как штука «общего назначения» и их не нужно отдельно указывать для каждого используемого кодека.

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

Что такое «отчетный интервал» для RTCP?

Использование протокола RTP выглядит как замкнутый цикл: мы отправляем RTP пакеты и получаем RTCP пакеты с обратной связью. Почти как TCP с его ACK. Обычно отчетный интервал выбирается так, чтобы объем передаваемых пакетов RTCP был гораздо меньше, чем объем передаваемых медиаданных. Выбор происходит на основании количества потоков, которые нужно синхронизировать, и ширины канала.

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

5% ширины канала выделяется для RTCP пакетов.

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

Рекомендованный минимальный интервал отправки RTCP пакетов составляет 5 секунд.

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

Расширенный профиль RTP для обратной связи с помощью RTCP

Если клиент замечает потери пакетов или проблемы с сетью, то он не может сразу отослать RTCP пакет и должен подождать окончания интервала. А там, на секундочку, 5 секунд. Для решения вопроса в спецификации есть «Extended RTP Profile for RTCP-Based Feedback» — это расширение правил RTP о таймингах.

Если оба устройства поддерживают такой профиль, то они могут договориться отсылать RTCP пакеты чаще, чем положено по спецификации. До тех пор, пока средняя скорость отправки пакетов укладывается в специфицированный интервал. Это же расширение описывает несколько дополнительных сообщений, которые клиенты могут использовать для описания происходящего с медиаданными: Negative Acknowledgement (NACK), Picture Loss Indication (PLI), Slice Loss Indication (SLI) и Reference Picture Selection Indication (RPSI).

Источник

RTP и RTCP: протоколы для IP-телефонии

Михаил Евсиков, Сергей Матвеев, Александр Осадчук

1. Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник