Протоколы RTP и RTCP в VoIP
RTP является основным транспортным протоколом в сетях IP-телефонии.
RTP (Real Time Protocol) - протокол реального времени, был создан для
передачи мультимедийной (ауди, видео), закодированной и упакованной в
пакеты, информации по IP сетям в строгих временных рамках. Передача
сегментов RTP происходит поверх протокола UDP и IP, соответственно на
разных уровнях модели OSI. Использования протокола UDP, не
гарантирующего доставку, связано со строгими временными рамками передачи
мультимедийной информации в реальном времени, а также неспособностью
протокола TCP работать в режиме реального времени. Поэтому не смотря на
потерю части данных своевременность доставки более важна в данном
случае.
В общем виде распределение протоколом по уровням модели OSI выглядит следующим образом:
Транспортный уровень: RTP поверх UDP
Сетевой: IP
Канальный: Ethernet
Физический: Ethernet
При передачи мультимедийной информации с использованием протокола RTP используется инкапсуляция следующего вида:
Минимальным размером RTP сегмента является 12 байт. Первые два бита
определяют версию протокола. На сегодняшний день используется RTPv.2 .
Следующее поле Р также имеет размер 2 бита и указывает на наличие
символов заполнителей в поле данных, при использовании сегментов
одинаковой длинны. Поле X определяет используется ли расширенный
заголовок. Затем поле СС, состоящее из 4 бит, определяет число
CSRC-полей в конце RTP заголовка, т. е. число источников, формирующих
поток. Затем идет поле М - маркерный бит, использующийся для выделения
важных данных. Следующее поле РТ имеет размер 7 бит. Предназначено для
определения типа полезной нагрузки - данные необходимые для приложения.
По указанному коду приложение определяет тип мультимедийной информации и
способ декодирования.
Остальная часть заголовка состоит из поля порядкового номера
(SequenceNumber) - последовательный номер сегмента, который отслеживает
порядок пакетов и их потерю; поля метки времени (Time Stamp) - код
синхронизации, указывающий на момент времени первой кодированной выборки
в полезной нагрузке, данная отметка используется буферами
восстановления синхронизации для ликвидации потерь качества, вызванного
вариацией задержки; поля источника синхронизации SSRC - произвольное
число, отличающее один RTP-сеанс от другого, для создания возможности
мультиплексирования. После постоянной фиксированной части
RTP-заголовка могут добавляться до 15 тридцати двух разрядных
CSRC-полей, которые идентифицируют источники данных.
Опишем процедуру установления RTP сеанса. Протоколом установлено, что
трафик разного типа передается в отдельных сеансах связи. Для
установления сеанса необходимо определить пару транспортных адресов
назначения т.е. один сетевой адрес и два порта для RTP и RTCP. Так для
видеоконференции необходимо аудио и видео передавать в разных сеансах с
соответственно разными портами назначения. Передача разных типов
трафика с использованием перемежения в одном сеансе могло бы вызвать
следующие проблемы:
- при изменении одного из типов трафика невозможно определить какой параметр в сеансе необходимо заменить на новое значение;
- для установления сеанса используется только один интервал тайминга, а
при передачи разнородного трафика у каждого типа будет свой интервал, и
они будут различаться;
- микшер RTP не может объединять перемеженные потоки различных типов трафика в один поток;
- передаче нескольких типов трафика в одном сеансе RTP невозможно по
следующим причинам: применение различных сетевых путей или распределение
сетевых ресурсов; прием подмножества мультимедийных данных, когда это
требуется, например, только звука, если видеосигнал превысил доступную
полосу пропускания; реализации приемника, которые используют отдельные
процессы для различных типов трафика, в то время как использование
отдельных сеансов RTP допускает реализации как с одним, так и с
множеством процессов.
Однако протокол RTP (Real-time Transport Protocol) и UDP (User
Datagram Protocol) не гарантируют качество, т.е не работают с QoS
(Quality of Service). Поэтому протокол RTP поддерживается протоколом
RTCP (Real-Time Transport Control Protocol), который предоставляет
дополнительную информацию о состоянии сеанса связи RTP.
Протокол RTCP выполняет четыре основные функции:
I. Основная задача протокола RTCP - это обеспечение обратной связи для
гарантирования качества при передаче данных. Обратная связь может быть
непосредственно полезна при применении при передаче адаптивного
кодирования. Также при использовании IP мультикастинга для получателей
крайне важно диагностировать ошибки при передаче сообщений(пакетов).
Посылка сообщений с отчетами о приеме позволяют передающей стороне
определить причину неудачной передачи сообщений, в случаи возникновении
таковой.
II. RTCP содержит неизменяемый идентификатор транспортного уровня для
RTP источника, который имеет название «каноническое имя» или «Сname»
(Canonical Name). Так как SSRC-идентификатор может быть изменятся, в
случае нахождения коллизий (столкновений) , для получателя необходимо
значение Сname, для того чтобы отслеживать каждого из участников.
Получателям также использует Cname, чтобы установить соответствие между
многими потоками данных от одного участника при установлении нескольких
сессий одновременно, например, чтобы синхронизовать аудио и видео каналы
при передаче видео со звуком.
III. Перечисленные выше две функции подразумевают, что все участники
сеансов посылали RTCP-пакеты, поэтому скорость передачи должна
контролироваться для того, чтобы RTP мог устанвливать сеансы с большим
числом пользователей. При передаче каждым участником своих управляющих
пакетов всем остальным любой партнер может независимо определить полное
число участников сессии. Это необходимо для расчетов частоты передачи
сообщений RTCP.
IV. Данная функция служит для передачи минимально необходимой
управляющей информации, такой как идентификатор участников, которая
используется графическим интерфейсом пользователя. Эта функция
используется для слабо контролируемых сессий, когда пользователи входят и
выходят без должного согласование параметров и характеристик. RTCP
выполняет функции удобного канала для контакта со всеми участниками, но
он необязательно поддерживает все коммуникационные требования
приложения.
В IP сетях с использованием мультикастинга функции один, два и три
являются обязательными при использовании RTP сессий. Также рекомендуется
их использование и при передаче в прочих сетях и средах. На сегодняшний
день рекомендуется разработчикам приложений RTP использовать средства
позволяющие работать в мультикастном режиме, а не только в уникастном.
Рассмотрим формат пакетов RTCP.
Стандартом протокола определено несколько типов пакетов RTCP. RTCP предназначен для передачи служебной информации:
sr: Отчет отправителя. Необходим для статистики приема и передачи
участников сеанса, которые непосредственно являются активными
отправителями;
rr: Отчет получателя. Необходим для статистики от участников, которые не являются получателями;
sdes: Описывает источник, включает Cname;
bye: Служит для индикации завершения (выхода) сеанса;
app: Специфические функции приложений;
Каждый RTCP пакет состоит из постоянной части, как и для протокола RTP,
которая используется RTP-пакетами, за ней следуют поля, которые могут
изменяться по длинне в зависимости от типа пакета, но кратную 32 бит.
Требования выравнивания и поле длины в фиксированной части заголовка
введены для того, чтобы сделать RTCP-пакеты объединяемыми. Несколько
RTCP-пакетов могут быть соединены друг с другом без введения каких-либо
сепараторов, для того чтобы получить составной RTCP-пакет, который
посылается в рамках транспортного протокола низкого уровня, например
UDP. Не существует специального счетчика индивидуальных RTCP-пакетов,
так как протокол низкого уровня задаст общую длину и определит конец
составного пакета.
Формат RTCP пакета сообщения отправителя выглядит следующим образом, как показано на рисунке выше.
Пакеты RTCP подвергаются следующим проверкам на корректность.
- RTP поле версии должно быть равно 2.
- Поле типа данных первого RTCP пакета в составном пакете должно быть SR или RR.
- Бит заполнителя (P) должен быть равен нулю для первого пакета
составного RTCP пакета, так как заполнитель может присутствовать только в
последнем.
- Длина полей индивидуальных RTCP-пакетов должна в сумме равняться полной длине составного пакета.
Одной из важнейших тенденций в эволюции современных телекоммуникаций является развитие средств IP-телефонии - множества новых технологий, обеспечивающих передачу мультимедийных сообщений (речи, данных, видео) через информационно-вычислительные сети (ИВС), построенные на базе протокола IP (Internet Protocol), в том числе локальные, корпоративные, глобальные вычислительные сети и сеть Internet. Понятие IP-телефонии включает в себя Internet-телефонию, позволяющую организовать телефонную связь между абонентами сети Internet, между абонентами телефонных сетей общего пользование (ТСОП) через Internet, а также телефонную связь абонентов ТСОП и Internet друг с другом.
IP-телефония обладает рядом несомненных достоинств, обеспечивающих ее быстрое развитие и расширение рынка компьютерной телефонии. Она выгодна конечным пользователям, которые обеспечиваются телефонной связью при довольно низкой поминутной оплате. Компаниям, имеющим удаленные филиалы, IP-технология позволяет организовать речевую связь при помощи уже существующих корпоративных IP-сетей. Вместо нескольких сетей связи при этом используется одна. Безусловным преимуществом IP-телефонии перед обычным телефоном является также возможность предоставления дополнительных услуг за счет использования мультимедийного компьютера и различных Internet-приложений. Таким образом, благодаря IP-телефонии предприятия и частные лица могут расширить возможности организации связи путем включения в них современной видеоконференцсвязи, совместного использования приложений, средств типа электронной чертежной доски (whiteboard) и т.п.
Какие международные стандарты и протоколы регламентируют основные параметры и алгоритмы функционирования аппаратных и программных средств связи, используемых в IP-телефонии? Очевидно, как следует из названия, данная технология построена на базе протокола IP, который, впрочем, используется не только для телефонии: первоначально он был разработан для передачи цифровых данных в ИВС с коммутацией пакетов.
В сетях, не обеспечивающих гарантированное качество обслуживания (к ним относятся сети, построенные на основе протокола IP), пакеты могут теряться, может изменяться порядок их поступления, данные, передаваемые в пакетах, могут искажаться. Для обеспечения надежной доставки передаваемой информации в этих условиях используются различные процедуры транспортного уровня. При передаче цифровых данных для этой цели применяется протокол ТСР (Transmission Control Protocol). Данный протокол обеспечивает надежную доставку данных и восстанавливает исходный порядок следования пакетов. Если в пакете обнаружена ошибка, или пакет теряется, процедуры TCP посылают запрос на повторную передачу.
Для приложений аудио- и видеоконференцсвязи задержки пакетов гораздо в большей степени влияют на качество сигнала, чем отдельные искажения данных. Различия в задержках могут приводить к появлению пауз. Для таких приложений необходим другой протокол транспортного уровня, обеспечивающий восстановление исходной последовательности пакетов, их доставку с минимальной задержкой, воспроизведение в реальном масштабе времени в точно заданные моменты, распознавание типа трафика, групповую или двухстороннюю связь. Таким протоколом является транспортный протокол реального времени RTP (Real-Time Transport Protocol). Данный протокол регламентирует передачу мультимедийных данных в пакетах через ИВС на транспортном уровне и дополняется протоколом управления передачей данных в реальном масштабе времени RTCP (Real-Time Control Protocol). Протокол RTCP, в свою очередь, обеспечивает контроль доставки мультимедийных данных, контроль качества обслуживания, передачу информации об участниках текущего сеанса связи, управление и идентификацию, и иногда считается частью протокола RTP.
Во многих публикациях, посвященных IP-телефонии, отмечается, что большая часть сетевого оборудования и специального программного обеспечения для данной технологии разрабатывается на базе Рекомендации Сектора стандартизации электросвязи Международного союза электросвязи (МСЭ-Т) Н.323 (в том числе, TAPI 3.0, NetMeeting 2.0 и т.д.). Как соотносится Н.323 с протоколами RTP и RTCP? Н.323 - это широкий концептуальный каркас, включающий множество других стандартов, каждый из которых отвечает за различные аспекты передачи информации. Большинство из этих стандартов, например, стандарты аудио- и видеокодеков, имеют широкое применение не только в IP-телефонии. Что касается протоколов RTP/RTCP, то они составляют основу стандарта H.323, ориентированы на обеспечение именно IP-технологии, лежат в основе организации IP-телефонии. Рассмотрению данных протоколов и посвящена эта статья.
Транспортный протокол реального времени RTP обеспечивает сквозную передачу в реальном времени мультимедийных данных, таких как интерактивное аудио и видео. Этот протокол реализует распознавание типа трафика, нумерацию последовательности пакетов, работу с метками времени и контроль передачи.
Действие протокола RTP сводится к присваиванию каждому исходящему пакету временных меток. На приемной стороне временные метки пакетов указывают на то, в какой последовательности и с какими задержками их необходимо воспроизводить. Поддержка RTP и RTCP позволяет принимающему узлу располагать принимаемые пакеты в надлежащем порядке, снижать влияние неравномерности времени задержки пакетов в сети на качество сигнала и восстанавливать синхронизацию между аудио и видео, чтобы поступающая информация могла правильно прослушиваться и просматриваться пользователями.
Заметим, что RTP сам по себе не имеет никакого механизма, гарантирующего своевременную передачу данных и качество обслуживания, но для обеспечения этого использует службы нижележащего уровня. Он не предотвращает нарушения порядка следования пакетов, но при этом и не предполагает, что основная сеть абсолютно надежна и передает пакеты в нужной последовательности. Порядковые номера, включенные в RTP, позволяют получателю восстанавливать последовательность пакетов отправителя.
Протокол RTP поддерживает как двустороннюю связь, так и передачу данных группе адресатов, если групповая передача поддерживается нижележащей сетью. RTP предназначен для обеспечения информации, требуемой отдельным приложениям, и в большинстве случаев интегрируется в работу приложения.
Хотя протокол RTP считается протоколом транспортного уровня, он функционирует обычно поверх другого протокола транспортного уровня UDP (User Datagram Protocol). Оба протокола вносят свои доли в функциональность транспортного уровня. Следует отметить, что RTP и RTCP являются независимыми от нижележащих уровней - транспортного и сетевого, поэтому протоколы RTP/RTCP могут использоваться с другими подходящими транспортными протоколами.
Протокольные блоки данных RTP/RTCP называются пакетами. Пакеты, формируемые в соответствии с протоколом RTP и служащие для передачи мультимедийных данных, называются информационными пакетами или пакетами данных (data packets), а пакеты, генерируемые в соответствии с протоколом RTCP и служащие для передачи служебной информации, требуемой для надежной работы телеконференции, называют пакетами управления или служебными пакетами (control packets). Пакет RTP включает в свой состав фиксированный заголовок, необязательное расширение заголовка переменной длины и поле данных. Пакет RTCP начинается с фиксированной части (подобной фиксированной части информационных пакетов RTP), за которой следуют структурные элементы, имеющие переменную длину.
Для того, чтобы протокол RTP был более гибким и мог применяться для различных приложений, некоторые его параметры сделаны преднамеренно не определенными, но зато в нем предусмотрено понятие профиля. Профиль (profile) - это набор параметров протоколов RTP и RTCP для конкретного класса приложений, определяющий особенности их функционирования. В профиле определяются использование отдельных полей заголовков пакетов, типы трафика, дополнения к заголовкам и расширения заголовков, типы пакетов, услуги и алгоритмы обеспечения безопасности связи, особенности использования протокола нижележащего уровня и т.д (в качестве примере в разделе 11 рассмотрен предложенный в RFC 1890 профиль RTP для аудио- и видеоконференций с минимальным управлением). Каждое приложение обычно работает только с одним профилем, и задание типа профиля происходит путем выбора соответствующего приложения. Никакой явной индикации типа профиля номером порта, идентификатором протокола и т.п. не предусмотрено.
Таким образом, полная спецификация RTP для конкретного приложения должна включать дополнительные документы, к которым относятся описание профиля, а также описание формата трафика, определяющее, как трафик конкретного типа, такой как аудио или видео, будет обрабатываться в RTP.
Особенности передачи мультимедийных данных при проведении аудио- и видеоконференций рассмотрены в следующих разделах.
Для организации групповой аудиоконференцсвязи требуется многопользовательский групповой адрес и два порта. При этом один порт необходим для обмена звуковыми данными, а другой используется для пакетов управления протокола RTCP. Информация о групповом адресе и портах передается предполагаемым участникам телеконференции. Если требуется секретность, то информационные и управляющие пакеты могут быть зашифрованы, как определено в разделе 7.1, в этом случае также должен быть сгенерирован и распределен ключ шифрования.
Приложение аудиоконференцсвязи, используемое каждым участником конференции, посылает звуковые данные малыми порциями, например, продолжительностью 20 мс. Каждой порции звуковых данных предшествует заголовок RTP; заголовок RTP и данные поочередно формируются (инкапсулируются) в пакет UDP. Заголовок RTP показывает, какой тип кодирования звука (например, ИКМ, АДИКМ или LPC) использовался при формировании данных в пакете. Это дает возможность изменять тип кодирования в процессе конференции, например, при появлении нового участника, который использует линию связи с низкой полосой пропускания, или при перегрузках сети.
В сети Internet, как и в других сетях передачи данных с коммутацией пакетов, пакеты иногда теряются и переупорядочиваются, а также задерживаются на различное время. Для противодействия этим событиям заголовок RTP содержит временную метку и порядковый номер, которые позволяют получателям восстановить синхронизацию в исходном виде так, чтобы, например, участки звукового сигнала воспроизводились динамиком непрерывно каждые 20 мс. Эта реконструкция синхронизации выполняется отдельно и независимо для каждого источника пакетов RTP в телеконференции. Порядковый номер может также использоваться получателем для оценки количества потерянных пакетов.
Так как участники телеконференции могут вступать и выходить из нее во время ее проведения, то полезно знать, кто участвует в ней в данный момент, и как хорошо участники конференции получают звуковые данные. Для этой цели каждый экземпляр звукового приложения во время конференции периодически выдает на порт управления (порт RTCP) для приложений всех остальных участников сообщения о приеме пакетов с указанием имени своего пользователя. Сообщение о приеме указывает, как хорошо слышим текущий оратор, и может использоваться для управления адаптивными кодерами. В дополнение к имени пользователя, может быть включена также другая информация идентификации для контроля полосы пропускания. При выходе из конференции сайт посылает пакет BYE протокола RTCP.
Если в телеконференции используются и звуковые, и видеосигналы, то они передаются отдельно. Для передачи каждого типа трафика независимо от другого спецификацией протокола вводится понятие сеанса связи RTP (см. список используемых сокращений и терминов). Сеанс определяется конкретной парой транспортных адресов назначения (один сетевой адрес плюс пара портов для RTP и RTCP). Пакеты для каждого типа трафика передаются с использованием двух различных пар портов UDP и/или групповых адресов. Никакого непосредственного соединения на уровне RTP между аудио- и видеосеансами связи не имеется, за исключением того, что пользователь, участвующий в обоих сеансах, должен использовать одно и то же каноническое имя в RTCP-пакетах для обоих сеансов так, чтобы сеансы могли быть связаны.
Одна из причин такого разделения состоит в том, что некоторым участникам конференции необходимо позволить получать только один тип трафика, если они этого желают. Несмотря на разделение, синхронное воспроизведение мультимедийных данных источника (звука и видео) может быть достигнуто при использовании информации таймирования, которая переносится в пакетах RTCP для обоих сеансов.
Не всегда все сайты имеют возможность получать мультимедийные данные в одинаковом формате. Рассмотрим случай, когда участники из одной местности соединены через низкоскоростную линию связи с большинством других участников конференции, которые обладают широкополосным доступом к сети. Вместо того, чтобы вынуждать каждого использовать более узкую полосу пропускания и звуковое кодирование с пониженным качеством, средство связи уровня RTP, называемое микшером, может быть размещено в области с узкой полосой пропускания. Этот микшер повторно синхронизирует входящие звуковые пакеты для восстановления исходных 20-миллисекундных интервалов, микширует эти восстановленные звуковые потоки в один поток, производит кодирование звукового сигнала для узкой полосы пропускания и передает поток пакетов через низкоскоростную линию связи. При этом пакеты могут быть адресованы одному получателю или группе получателей с различными адресами. Чтобы в приемных оконечных точках можно было обеспечивать правильную индикацию источника сообщений, заголовок RTP включает для микшеров средства опознавания источников, участвовавших в формировании смешанного пакета.
Некоторые из участников аудиоконференции могут быть соединены широкополосными линиями связи, но могут быть недостижимы посредством групповой конференцсвязи с использованием протокола IP (IPM - IP multicast). Например, они могут находиться за брандмауэром прикладного уровня, который не будет допускать никакой передачи IP-пакетов. Для таких случаев нужны не микшеры, а средства связи уровня RTP другого типа, называемые трансляторами. Из двух трансляторов один устанавливается вне брандмауэра и снаружи передает все групповые пакеты, полученные через безопасное соединение, другому транслятору, установленному за брандмауэром. Транслятор за брандмауэром передает их снова как мультивещательные пакеты многопользовательской группе, ограниченной внутренней сетью сайта.
Микшеры и трансляторы могут быть разработаны для ряда целей. Пример: микшер видеосигнала, который масштабирует видеоизображения отдельных людей в независимых потоках видеосигнала и выполняет их композицию в один поток видеосигнала, моделируя групповую сцену. Примеры трансляции: соединение группы хостов, использующих только протоколы IP/UDP с группой хостов, которые воспринимают только ST-II, или перекодирование видеосигнала пакет за пакетом из индивидуальных источников без пересинхронизации или микширования. Детали работы микшеров и трансляторов рассмотрены в разделе 5.
Все поля пакетов RTP/RTCP передаются по сети байтами (октетами); при этом наиболее значащий байт передается первым. Все данные полей заголовка выравниваются в соответствии с их длиной. Октеты, обозначенные как дополнительные, имеют нулевое значение.
Абсолютное время (время Wallclock) в RTP представлено с использованием формата временной метки сетевого протокола времени NTP (Network Time Protocol), который является отсчетом времени в секундах относительно нуля часов 1 января 1900 года. Полный формат временной метки NTP - 64-разрядное число без знака с фиксированной запятой с целой частью в первых 32 битах и дробной - в последних 32 битах. В некоторых полях с более компактным представлением используются только средние 32 бита - младшие 16 битов целой части и старшие 16 битов дробной части.
В следующих двух разделах данной статьи (3 и 4) рассматриваются форматы пакетов и особенности функционирования протоколов RTP и RTCP соответственно.
Как было отмечено выше, пакет RTP включает в свой состав фиксированный заголовок, необязательное расширение заголовка с переменной длиной и поле данных. Фиксированный заголовок пакетов протокола RTP имеет следующий формат: .
Первые двенадцать октетов присутствуют в каждом пакете RTP, в то время как поле идентификаторов включаемых источников CSRC (сontributing source) присутствует только тогда, когда оно вставлено микшером. Поля имеют следующие назначения.
Версия (V): 2 бита. Это поле идентифицирует версию RTP. В данной статье рассматривается версия 2 протокола RTP (величина 1 использовалась в первой черновой версии RTP).
Дополнение (P): 1 бит. Если бит дополнения установлен в единицу, то пакет в конце содержит один или более октетов дополнения, которые не являются частью трафика. Последний октет дополнения содержит указание на число таких октетов, которые должны впоследствии игнорироваться. Дополнение может требоваться некоторым алгоритмам шифрования с фиксированными размерами блока или для переноса нескольких пакетов RTP в одном блоке данных протокола нижележащего уровня.
Расширение (X): 1 бит. Если бит расширения установлен, то за фиксированным заголовком следует расширение заголовка с форматом, определенным в .
Счетчик CSRC (CC): 4 бита. Счетчик CSRC содержит число идентификаторов включаемых источников CSRC (см. список используемых сокращений и терминов), которые следуют за фиксированным заголовком.
Маркер (M): 1 бит. Интерпретация маркера определяется профилем. Он предназначен для того, чтобы позволить маркировать в потоке пакетов значительные события (например, границы видеокадра). Профиль может вводить дополнительные биты маркера или определять, что никакого бита маркера не имеется, изменяя число битов в поле типа трафика (см. ).
Тип трафика (PT): 7 бит. Это поле идентифицирует формат трафика RTP и определяет его интерпретацию приложением. Профиль определяет заданное по умолчанию статическое соответствие значений РТ и форматов трафика. Дополнительные коды типа трафика могут быть определены динамически через не-RTP средства. Отправитель пакета RTP в любой момент времени выдает единственное значение типа трафика RTP; это поле не предназначено для мультиплексирования отдельных мультимедийных потоков (см. ).
Порядковый номер: 16 бит. Значение порядкового номера увеличивается на единицу с каждым посланным информационным пакетом RTP и может использоваться получателем для обнаружения потерь пакетов и восстановления их исходной последовательности. Начальная величина порядкового номера выбирается случайным образом, чтобы усложнить попытки взлома ключа с опорой на известные значения данного поля (даже если шифрование не используется источником, так как пакеты могут проходить через транслятор, который применяет шифрование). Временная метка: 32 бита. Временная метка отражает момент дискретизации для первого октета в информационном пакете RTP. Момент дискретизации должен быть получен от таймера, который увеличивает свои значения монотонно и линейно во времени, для обеспечения синхронизации и определения джиттера (см. раздел 4.3.1). Разрешение таймера должно быть достаточным для желательной точности синхронизации и измерения джиттера поступления пакетов (одного отчета таймера на видеокадр обычно бывает недостаточно). Частота таймирования зависит от формата передаваемого трафика и задается статически в профиле или спецификации формата трафика или может задаваться динамически для форматов трафика, определенных через «не-RTP средства». Если пакеты RTP генерируются периодически, то должны использоваться номинальные моменты дискретизации, определяемые таймером дискретизации, а не значения системного таймера. Например, для звукового сигнала с фиксированной скоростью желательно, чтобы датчик временной метки увеличивался на единицу для каждого периода дискретизации. Если звуковое приложение из устройства ввода читает блоки, содержащие 160 отсчетов, то временная метка при этом должна увеличиваться на 160 для каждого такого блока, независимо от того, передан ли блок в пакете или сброшен, как пауза. Начальное значение временной метки, так же, как и начальное значение порядкового номера, является случайной величиной. Несколько последовательных пакетов RTP могут иметь равные временные метки, если они логически генерируются одновременно, например, принадлежат одному и тому же видеокадру. Последовательные пакеты RTP могут содержать немонотонные временные метки, если данные не передаются в порядке дискретизации, как в случае интерполируемых видеокадров MPEG (однако порядковые номера пакетов при передаче все же будут монотонными).
SSRC: 32 бита. Поле SSRC (synchronization source) идентифицирует источник синхронизации (см. список используемых сокращений и терминов). Этот идентификатор выбирается случайным образом так, чтобы никакие два источника синхронизации в рамках одного и того же сеанса связи RTP не имели одинаковых идентификаторов SSRC. Хотя вероятность того, что несколько источников выберут один и тот же идентификатор, низка, все же все реализации RTP должны быть готовы обнаруживать и разрешать подобные коллизии. В разделе 6 рассмотрена вероятность коллизий вместе с механизмом для их разрешения и обнаружения зацикливаний уровня RTP, основанным на уникальности идентификатора SSRC. Если источник изменяет свой исходный транспортный адрес, то он должен также выбрать новый идентификатор SSRC, чтобы его не интерпретировали как зацикленный источник.
Список CSRC: от 0 до 15 пунктов, 32 бита каждый. Список CSRC (сontributing source) идентифицирует включаемые источники трафика, содержащегося в пакете. Число идентификаторов задается полем CC. Если имеется более пятнадцати включаемых источников, то только 15 из них могут быть идентифицированы. Идентификаторы CSRC вставляются микшерами при использовании идентификаторов SSRC для включаемых источников. Например, для звуковых пакетов идентификаторы SSRC всех источников, которые были смешаны при создании пакета, перечисляются в списке CSRC, обеспечивая корректную индикацию источников сообщений для получателя.
Как было упомянуто выше, в соответствии с протоколом RTP трафик различных типов должен передаваться отдельно, в разных сеансах связи RTP. Сеанс определяется конкретной парой транспортных адресов назначения (один сетевой адрес плюс пара портов для RTP и RTCP). Например, в телеконференции, составленной из звукового и видеосигнала, кодированных отдельно, трафик каждого типа нужно передавать в отдельном сеансе RTP со своим собственным транспортным адресом назначения. Не предполагается, что звуковой и видеосигнал будут передаваться в одном сеансе RTP и разделяться на основе типа трафика или полей SSRC. Перемежение пакетов, имеющих различные типы трафика, но использующих один и тот же SSRC, вызвало бы некоторые проблемы:
При использовании для каждого типа трафика различных SSRC, но при передаче их в одном и том же сеансе RTP, можно избежать первых трех проблем, но двух последних избежать не удастся. Поэтому спецификация протокола RTP предписывает для каждого типа трафика использовать свой сеанс RTP.
Существующий заголовок информационного пакета RTP является полным для набора функций, требуемых в общем случае для всех классов приложений, которые могли бы поддерживать RTP. Однако, для лучшего приспособления к конкретным задачам заголовок может быть видоизменен посредством модификаций или дополнений, определенных в спецификации профиля.
Бит маркера и поле типа трафика несут информацию, зависящую от профиля, но они расположены в фиксированном заголовке, так как ожидается, что в них будут нуждаться много приложений. Октет, содержащий эти поля, может быть переопределен профилем для удовлетворения различным требованиям, например, с большим или меньшим количеством битов маркера. Если имеются какие-либо биты маркера, они должны размещаться в старших битах октета, так как независимые от профиля мониторы могут быть способны наблюдать корреляцию между характером потерь пакетов и битом маркера.
Дополнительная информация, которая требуется для конкретного формата трафика (например, тип кодирования видеосигнала), должна передаваться в поле данных пакета. Она может размещаться на определенном месте в начале или внутри массива данных.
Если конкретный класс приложений нуждается в дополнительных функциональных возможностях, не зависящих от формата трафика, то профиль, с которым функционируют эти приложения, должен определить дополнительные фиксированные поля, располагаемые сразу после поля SSRC существующего фиксированного заголовка. Эти приложения будут способны быстро напрямую обращаться к дополнительным полям, в то время как профиль-независимые мониторы или регистраторы все еще будут способны обрабатывать пакеты RTP, интерпретируя только первые двенадцать октетов.
Если считается, что дополнительные функциональные возможности необходимы в общем для всех профилей, то должна быть определена новая версия RTP, чтобы сделать постоянное изменение фиксированного заголовка.
Для обеспечения возможности отдельным реализациям экспериментировать с новыми функциями, независимыми от формата трафика, которые требуют, чтобы в заголовке информационного пакета передавалась дополнительная информация, протоколом RTP предусмотрен механизм расширения заголовка пакета. Этот механизм разработан так, чтобы расширение заголовка могло игнорироваться другими взаимодействующими приложениями, которым оно не требуется.
Если бит X в заголовке RTP установлен в единицу, то к фиксированному заголовку RTP (вслед за списком CSRC, если он есть) присоединяется расширение заголовка с переменной длиной. Заметим, что это расширение заголовка предназначено только для ограниченного использования. Расширение заголовка пакета RTP имеет следующий формат:
Расширение содержит 16-разрядное поле длины, которое показывает количество 32-разрядных слов в нем, исключая четырехоктетный заголовок расширения (следовательно, длина может иметь нулевое значение). Только одно расширение может быть добавлено к фиксированному заголовку информационного пакета RTP. Чтобы позволить каждому из множества взаимодействующих реализаций экспериментировать независимо с различными расширениями заголовка или позволять конкретной реализации экспериментировать более чем с одним типом расширения заголовка, использование первых 16 битов расширения не определено, оставлено для различающих идентификаторов или параметров. Формат из этих 16 битов должен быть определен спецификацией профиля, с которым работают приложения.
| 1999 | ||||||||||||
| 2000 |
Основным транспортным протоколом для мультимедийных приложений стал протокол реального времени RTP (Real-Time Protocol), предназначенный для организации передачи пакетов с кодированными речевыми сигналами по IP-сети. Передача пакетов RTP ведется поверх протокола UDP, работающего, в свою очередь, поверх IP (рис. 1.5.).
Рис. 1.5.
На самом деле уровень, к которому относится RTP, не определяется настолько однозначно, как это показано на рис. 1.5 и как это обычно описывается в литературе. С одной стороны, протокол действительно работает поверх UDP, реализуется прикладными программами и, по всем признакам, является прикладным протоколом. Но в то же время, как сказано в начале этого параграфа, RTP предоставляет транспортные услуги независимо от мультимедийных приложений и является, с этой точки зрения, просто транспортным протоколом. Наиболее удачное определение: RTP -- это транспортный протокол, реализованный на прикладном уровне.
Для передачи речевого (мультимедийного) трафика RTP использует пакеты, структура которых показана на рис. 1.6.
Пакет RTP состоит, как минимум, из 12 байтов. В двух первых битах RTP заголовка (поле бита версии, V) указывается версия протокола RTP (в настоящее время это версия 2).
Ясно, что при такой структуре заголовка возможна максимум еще только одна версия RTP. Следующее за ними поле содержит два бита: бит Р, который указывает, были ли добавлены в конце поля с полезной нагрузкой символы-наполнители (они обычно добавляются, если транспортный протокол или алгоритм кодирования требует использования блоков фиксированного размера), и бит X, который указывает, используется ли расширенный заголовок.
Рис. 1.6.
Если он используется, то первое слово расширенного заголовка содержит общую длину расширения. Далее, четыре бита СС определяют число CSRC-полей в конце RTP-заголовка, т.е. число источников, формирующих поток. Маркерный бит М позволяет отмечать то, что стандарт определяет как существенные события, например, начало видеокадра, начало слова в аудиоканале и т.п. За ним следует поле типа данных РТ (7 битов), где указывается код типа полезной нагрузки, определяющий содержимое поля полезной нагрузки - данные приложения {Application Data), например, несжатое 8-битовое аудио МРЗ и т.п. По этому коду приложение может узнать, что нужно делать, чтобы декодировать данные. Остальная часть заголовка фиксированной длины состоит из поля порядкового номера (Sequence Number), поля метки времени (Time Stamp) для записи момента создания первого слова пакета и поля источника синхронизации SSRC, которое идентифицирует этот источник. В последнем поле можно указывать единственное устройство, имеющее только один сетевой адрес, множественные источники, которые могут представить различные мультимедийные среды (аудио, видео и т.д.), или разные потоки одной и той же среды. Так как источники могут быть на разных устройствах, SSRC-идентификатор выбирается случайным образом, чтобы шанс получать данные сразу от двух источников во время RTP-сеанса был минимальным. Однако определен также и механизм решения конфликтов, если они возникают. За фиксированной частью RTP-заголовка могут следовать еще до 15 отдельных 32-разрядных CSRC-полей, которые идентифицируют источники данных.
RTP поддерживается протоколом управления транспортировкой в реальном времени RTCP {Real-Time Transport Control Protocol), который формирует дополнительные отчеты, содержащие информацию о сеансах связи RTP. Напомним, что ни UDP, ни RTP не занимаются обеспечением качества обслуживания QoS (Quality of Service). Протокол RTCP обеспечивает обратную связь с отправителями, а получателям потоков он предоставляет некоторые возможности повышения QoS, информацию о пакетах (потери, задержки, джиттер) и о пользователе (приложении, потоке). Для управления потоком существуют отчеты двух типов - генерируемые отправителями и генерируемые получателями. Например, информация о доле потерянных пакетов и абсолютном количестве потерь позволяет отправителю при получении отчета обнаруживать, что перегрузка канала может заставить получателей не принимать потоки пакетов, которые они ожидали. В этом случае отправитель имеет возможность понизить скорость кодирования, чтобы уменьшить перегрузку и улучшить прием. Отчет отправителя содержит информацию о том, когда был генерирован последний RTP-пакет (она включает в себя как внутреннюю метку, так и реальное время). Эта информация позволяет получателю координировать и синхронизировать множественные потоки, например, видео и аудио. Если поток направляется нескольким получателям, то организуются потоки RTCP-пакетов от каждого из них. При этом будут предприняты шаги для ограничения ширины полосы - обратно пропорционально скорости, с которой генерируются RTCP-отчеты, и числу получателей.
Следует заметить, что хотя RTCP работает отдельно от RTP, но уже и сама цепочка RTP/UDP/IP приводит к существенным накладным расходам (в виде их заголовков). Кодек G.729 генерирует пакеты размером в 10 байтов (80 битов каждые 10 мс). Один RTP-заголовок, размером в 12 байтов, больше, чем весь этот пакет. К нему, кроме того, должен быть добавлен 8-байтовый UDP-заголовок и 20-байтовый IP-заголовок (в версии IРv4), что создает заголовок, в четыре раза превосходящий по размеру передаваемые данные.
При использовании протокола RTP открываются два порта для коммуникации. Один для передачи потока медиаданных (четный номер порта), и один для передачи данных сигнализации (обратная связь для QoS и контроль медиапотока) - RTCP. Значения номеров портов жестко не привязаны, в основном, они сильно зависят от используемого приложения.RTP - Протокол передачи медиаданных в реальном времени (Real-time Transport Protocol) RTCP - Протокол передачи управляющих данных в реальном времени (Real-time Control Protocol)
Дополнительно включает в себя информацию о: Потерях пакетов Буферизация "Jitter" Задержки Уровень сигнала Метрика качества сигнала (Call Quality Metrics) Echo Return Loss и т.д. RTCP XR -Расширенный Протокол передачи управляющих данных в реальном времени (Real-time Control Protocol Extended Reports)
Все поля, описанные для протокола RTCP, плюс: R Factor - Параметр качества сигнала MOS - Параметр качества сигнала и другие
Пакеты, содержащие передаваемый голос, передаются с использованием RTP/RTCP для протокола , который используется для VOIP вызовов. Протокол RTP может передавать медиаданные, идентифицируемые параметрами, которые зарегистрированы организацией: "Internet assigned numbers authority" - IANA. Они так же используются для полей в протоколе , который используется в и сообщениях.
Некоторые значения поля payload:
| PT | название кодека | audio/video (A/V) | clock rate (Hz) | кол-во каналов | Документ | 0 | PCMU | A | 8000 | 1 | RFC3551 | 3 | GSM | A | 8000 | 1 | RFC3551 | 4 | G723 | A | 8000 | 1 | Kumar | 5 | DVI4 | A | 8000 | 1 | RFC3551 | 6 | DVI4 | A | 16000 | 1 | RFC3551 | 7 | LPC | A | 8000 | 1 | RFC3551 | 8 | PCMA | A | 8000 | 1 | RFC3551 | 9 | G722 | A | 8000 | 1 | RFC3551 | 10 | L16 | A | 44100 | 2 | RFC3551 | 11 | L16 | A | 44100 | 1 | RFC3551 | 12 | QCELP | A | 8000 | 1 | - | 13 | CN | A | 8000 | 1 | RFC3389 | 14 | MPA | A | 90000 | RFC3551,RFC2250 | 15 | G728 | A | 8000 | 1 | RFC3551 | 16 | DVI4 | A | 11025 | 1 | DiPol | 17 | DVI4 | A | 22050 | 1 | DiPol | 18 | G729 | A | 8000 | 1 | 19 | зарезервировано | A | 20 | не назначено | A | 21 | не назначено | A | 22 | не назначено | A | 23 | не назначено | A | 24 | не назначено | V | 25 | CelB | V | 90000 | RFC2029 | 26 | JPEG | V | 90000 | RFC2435 | 27 | не назначено | V | 28 | nv | V | 90000 | RFC3551 | 29 | не назначено | V | 30 | не назначено | V | 31 | H261 | V | 90000 | RFC2032 | 32 | MPV | V | 90000 | RFC2250 | 33 | MP2T | AV | 90000 | RFC2250 | 34 | H263 | V | 90000 | Zhu | 35--71 | не назначено | 72--76 | зарезервировано для RTCP во избежание конфликтов | RFC3550 | 77--95 | не назначено | 77--95 | dynamic | RFC3551 |
IANA: Зарегистрированные параметры протокола RTP: http://www.iana.org/assignments/rtp-parameters
Протокол RTP и трансляция IP адресов (NAT) При проведении VOIP сеанса связи, образуются два RTP потока, по одному в каждом направлении. Если один из участников, участвующий в этом сеансе, использует IP адрес из приватной сети, тогда поток от абонента, находящегося в публичной сети в сторону NAT сервера, не сможет достичь абонента, находящегося во внутренней сети. Для решения этой проблемы часто используется (симметричный RTP). Для дополнительной информации об использовании VOIP в сетях с NAT, смотри: NAT and VOIP.Статьи RTCP XR measures VoIP performance Network World 11/17/03Документы RFC: IETF RFC 3550 RTP: Транспортный протокол для приложений, работающих в реальном времени. IETF RFC 3611 RTP Control Protocol Extended Reports (RTCP XR) IETF RFC 1890 RTP профиль для звуковых и видео конференций с Минимальным управлением. IETF RFC 2508 Сжатие заголовков IP/UDP/RTP пакетов для низкоскоростных линий связи. IETF RFC 3545 Расширенная компрессия RTP (CRTP) для линий связи с высокими задержками, большими потерями пакетов и частой повторной отправкой данных.
