40. Передача голосового трафика поверх ip, протоколы sip, rtp. Особенности алгоритмов компрессии голоса и проблемы транспортной инфраструктуры.

Из шпоргалки [2] п. 40 (см. ссылку - реальное голосовое общение)

См.также из Семёнова [4] – 4.4.9.0 Протокол IGMP и передача мультимедиа по Интернет.doc 4.4.9.2 Протокол реального времени RTP.doc и 4.4.9.8 Протокол запуска сессий SIP.doc

См. билет №41

Протокол RTP 4.4.9.2 Протокол реального времени RTP.doc

В начале 90-х годов были сделаны первые попытки использовать Интернет для передачи голоса в реальном масштабе времени (VocalTek). В настоящее время IP-телефония стала обычным видом услуг. Более того, она сыграла определяющую роль в снижении телефонных тарифов. Появились регулярные музыкальные программы. На подходе подключение к этому виду сервиса всех мобильных коммуникаций и цифрового телевидения. Этому способствовала разработка алгоритмов MPEG-1 ÷ -4 и прикладных программ, реализующих эти алгоритмы.

Специфическим для мультимедиа является использование для транспортировки протокола UDP (без установления соединения и без гарантии доставки). В случае передачи голоса или изображения повторная передача дейтограммы становится бессмысленной.

В Интернет, также как и в некоторых других сетях, возможна потеря пакетов изменение их порядка в процессе транспортировки, а также вариация времени доставки в достаточно широких пределах. Мультимедийные приложения накладывают достаточно жесткие требования на транспортную среду. Для согласования таких требований с возможностями Интернет был разработан протокол RTP. Протокол RTP (См. RFC-2205, -2209, -2210, -1990, -1889,-3550, -3551, -3989, -3952; "RTP: A Transport Protocol for Real-Time Applications" H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson) базируется на идеях, предложенных Кларком и Тенненхаузом [1], и предназначен для доставки данных в реальном масштабе времени (например, аудио- или видео). При этом определяется тип поля данных, производится нумерация посылок, присвоение временных меток и мониторирование доставки. Приложения обычно используют RTP поверх протокола UDP для того, чтобы использовать его возможности мультиплексирования и контрольного суммирования. Но RTP может использоваться и поверх любой другой сетевой транспортной среды. RTP поддерживает одновременную доставку по многим адресам, если мультикастинг поддерживается нижележащим сетевым уровнем.

Следует иметь в виду, что сам по себе RTP не обеспечивает своевременной доставки и не предоставляет каких-либо гарантий уровня сервиса (QoS. Этот протокол не может гарантировать также корректного порядка доставки данных.

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

На практике протокол RTP не отделим от протокола RTCP (RTP control protocol). Последний служит для мониторинга qos и для передачи информации об участниках обмена в ходе сессии.

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

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

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

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

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

На уровне RTP не существует какой-либо взаимосвязи между аудио- и видео сессиями. Только RTCP-пакеты несут в себе одни и те же канонические имена участников.

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

Смеситель преобразует поток аудио-пакетов в следовательность пакетов, которая соответствует возможностям узкополосного канала. Эти пакеты могут быть уникастными (адресованными одному получателю) или мультикастными. Заголовок RTP включает в себя средства, которые позволяют мультиплексорам идентифицировать источники, внесшие вклад. Так что получатель может правильно идентифицировать источник звукового сигнала.

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

Протокол SIP 4.4.9.8 Протокол запуска сессий SIP.doc

Протокол SIP (Session Initiation Protocol) описан в документе RFC 3261, и служит для запуска, модификации и завершения сессий реального времени между партнерами IP-сети. SIP может поддерживать как моно так и мультимедийные приложения, включая видеоконференции.

Протокол SIP является лишь одним из протоколов, которые обеспечивают мультимедийный обмен через Интернет. SIP представляет собой сигнальный протокол, который позволяет одному партнеру послать запрос другому и согласовать параметры мультимедиа сессии.

Собственно транспортировка мультимедиа данных обычно осуществляется с помощью протокола RTP (Real-Time Transport Protocol).

Базовым стимулом создания протокола SIP являлась необходимость реализации работы с VoIP (Voice over IP). Протокол поддерживает пять аспектов, сопряженных с установлением и завершением мультимедийных коммуникаций:

Положение пользователя: Пользователи могут менять свое положение и сохранять доступ к телефонии и другим приложениям дистанционно.

Доступность пользователя: Предполагается проверка готовности парнера-адресата участвовать в коммуникациях.

Возможности пользователя: Определяются параметры среды, которые должны быть использованы.

Формирование сессии: Создается соединение точка-точка или сессия с несколькими партнерами при заданных коммуникационных параметрах.

Управление сессией: Предполагается создание и завершение сессий, модификация параметров сессии и сервисов.

SIP базируется на модели транзакций, сходных с запросами/откликами в протоколе HTTP. Каждая транзакция состоит из запроса клиента, который включает в себя определенный метод, или функцию, для сервера и, по крайней мере, один отклик. SIP использует большинство полей заголовков, правил кодирования и коды статуса протокола HTTP. Это позволяет работать с данными легко читаемого и отображаемого формата. SIP использует протокол SDP (Session Description Protocol), который с помощью набора типов данных, используемых в MIME (Multipurpose Internet Mail Extensions), определяет содержимое сессии.