Информация для заказа:
Санкт-Петербург - +7 (812) 319-33-79
Москва - +7 (495) 797-56-95
e-mail: info@dianetpro.ru
Название:
Производитель:
Статьи
Как спланировать работу операторов контакт-центра с навыками общения в разных каналахКак спланировать работу операторов контакт-центра с навыками общения в разных каналах 21.06.2017
Как спланировать работу операторов контакт-центра с навыками общения в разных каналах
Речевой анализ: новая точка роста в сегменте контакт-центровРечевой анализ: новая точка роста в сегменте контакт-центров 21.06.2017
Речевой анализ: новая точка роста в сегменте контакт-центров
Тестирование категории 8: чем и зачем?Тестирование категории 8: чем и зачем? 16.02.2017
Тестирование категории 8: чем и зачем?
Компания FLUKE прекращает выпуск первоначальных моделей тепловизоровКомпания FLUKE прекращает выпуск первоначальных моделей тепловизоров 30.01.2017
Компания FLUKE прекращает выпуск первоначальных моделей тепловизоров
Как обращаться с кабельными катушками? Советы от General CableКак обращаться с кабельными катушками? Советы от General Cable 21.09.2016
Как обращаться с кабельными катушками? Советы от General Cable
все статьи »
  • Статьи
    • На что способен RTCP (RTP) протокол?

 Что такое протокол RTCP? Это компаньон протокола RTP, который сегодня используется для отправки и получения большинства медиаданных по IP. Благодаря такому подходу получаем облегченный механизм управления, который обеспечивает обратную связь с отправителем относительно качества отправляемых данных (сколько пакетов удаленной стороной получено, сколько потеряно и другой подобной информации).
Кроме того, при сбое сеанса связи использование RTCP позволяет узнать причину разрыва. Например, в SIP управления вызовами может производиться поверх UDP, где нет возможности узнать, почему один из пользовательских агентов сломался или вывалился из сети из-за некоторых посторонних причин - особенно, в том случае, когда агенты пользователей обмениваются между собой только медиаданными. В таком случае, просмотрев RTCP-отчеты, можно будет определить время обрыва.
Сегодня, у RTCP появилось гораздо больше возможностей. Более подробно хотелось бы остановиться на двух стандартах IETF RFC, которые являются расширением RTCP и довольно важной составляющей визуальных коммуникаций в реальном времени: RFC 3611 и RFC 4585.

Протокол RFC 3611: RTCP-XR (Extended Reports)

RTCP является своего рода отчетным протоколом: он собирает информацию, а затем выдает ее в определенное время. Проблема в том, что он предоставляет очень мало информации. Это значит, что RTCP бесполезен в большинстве случаев устранения заторов в сети.
Спецификация RTCP-XR (RFC 3611) была разработана для того, чтобы улучшить возможности стандартного RTCP. RTCP-XR просто добавляет кучу дополнительной информации, которая может быть собрана:
  •     Можно узнать не только, сколько пакетов было потеряно, но и их порядковые номера, что позволит при необходимости ретранслировать только необходимую часть информации.
  •     Теперь можно узнать информацию о джиттере принимающей стороны. Или значение MOS для вашего голоса (это измерение качества).
  •     А также кучу других вещей, которые могут пригодиться при необходимости улучшить общее качество медиаданных.
Какие основные улучшения по сравнению со стандартным отчетом?
  1.     Порядковые номера потерянных пакетов.
  2.     Порядковые номера повторяющихся пакетов.
  3.     Время получения пакета.
  4.     Ожидаемое время доставки.
  5.     Задержка с момента приема последнего отчета RTCP Receiver Report.
  6.     Общая статистика.
  7.     Оценивание VoIP.
Точное использование каждого дополнения зарезервировано для самих приложений, но в целом дополнительная информация существенно расширить возможности для оптимизации решений в рамках стандарта и, таким образом, обеспечить совместимость.

Кроме того, для RTCP-XR требуется реализация спецификации IMS (IP Multimedia Subsystem).

Протокол RFC 4585: RTCP-FB (AVPF/Обратная связь)

RTP использует SIP, H.323 и даже XMPP для пересылки актуальных медиаданных через сеть. После чего, все управление медиаданными выполняется самостоятельно – изменение битрейта, запрос I-кадров и прочее, как правило, осуществляется с помощью протоколов сигнализации: H.245, когда дело доходит до H.323, INFO и SDP когда дело доходит до SIP. На данном этапе могут проявиться проблемы с отображением протоколов и шлюзованием между ними, а также есть еще большие последствия. Желательно было бы собрать все необходимые медиаданные и служебную информацию в одном месте и передавать по одному маршруту, чтобы уменьшить время ожидания и повысить качество, но сигнализация часто отделена от медиаданных и передается по другому маршруту через другой набор объектов сети.

Для решения этих проблем был разработан протокол RTCP-FB, который также известен как RTP/AVPF. Он определяет способ взаимодействия приложений для передачи команд по RTCP от приемника медиа к отправителю.

Большая часть этого стандарта касается отправки сервисных сообщений с минимальными задержками внутри RTCP. Но основная модель использования проявилась в другой RFC-спецификации, которая "сидит" прямо на вершине этой: RTC 5104. Несмотря на то, что доступно множество типов управляющих сообщений, самым полезным дополнением является FIR (Full Intra Request), которое очень похоже на сообщение Video Fast Update в H.323.

Вместе с RFC 4585, RTCP становится протоколом, который можно использовать для некоторых интеллектуальных коммуникаций, а не только для простой пересылки медиаданных по IP-сети. Кроме того, например, в  IMTC SIP Parity AG использование этого RFC является неотъемлемая частью развития SIP Video Profile.

Итак, можно убедиться в том, что RTCP намного больше, чем просто прибавка к RTP - это полноценный протокол, который обязательно будет использоваться по мере того как видеозвонок (подробнее о видеосвязи) будет становиться обычным явлением. Поэтому нужно не забывать о нем при разработке новых продуктов для VoIP (VoIP телефоны, VoIP АТС и др.).