Протоколы RTP и RTCP в VoIP

Протоколы 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-пакетов должна в сумме равняться полной длине составного пакета.