 |
Обеспечение качества на базе протокола RTSP
|
|
|
|
Потоковый протокол реального времени (Real Time Streaming Protocol, RTSP), разработанный IETF в 1998 году и описанный в RFC 2326, является прикладным протоколом, предназначенным для использования в системах, работающих смультимедиа данными, и позволяющий клиенту удалённо управлять потоком данных с сервера, предоставляя возможность выполнения команд, таких как «Старт», «Стоп», а также доступа по времени к файлам, расположенным на сервере.
RTSP не выполняет сжатие, а также не определяет метод инкапсуляции мультимедийных данных и транспортные протоколы. Передача потоковых данных сама по себе не является частью протокола RTSP. Большинство серверов RTSP используют для этого стандартный транспортный протокол реального времени, осуществляющий передачу аудио- и видеоданных.
Клиенты
· RealPlayer
· MPlayer
· Windows Media Player
· QuickTime
· MPEG4IP
· Media Player Classic
· Skype
· VLC media player
· Winamp (только некоторые версии протокола)
Команды RTSP
По синтаксису и операциям протокол RTSP похож на HTTP. Однако между протоколами RTSP и HTTP есть ряд существенных различий. Одно из основных заключается в том, что в первом и сервер, и клиент способны генерировать запросы. Например, видеосервер может послать запрос для установки параметров воспроизведения определенного видеопотока. Далее, протоколом RTSP предусматривается, что управление состоянием или связью должен осуществлять сервер, тогда как HTTP вообще никакого отношения к этому не имеет. Наконец, в RTSP данные могут передаваться вне основной полосы (out-of-band) другими протоколами, например RTP, что невозможно в случае HTTP. RTSP-сообщения посылаются отдельно от мультимедийного потока. Для них используется специальный порт с номером 554. Формат запроса
|
|
|
Запрос на сервер посылается в текстовом виде в формате: " метод абсолютный_адрес_контента версия_протокола ". Вместе с запросом могут быть переданы дополнительные служебные поля (на новых строчках запроса).
Использование протокола RTSP упрощает создание и поддержку виртуальных серверов, где один хост с одним адресом IP обслуживает несколько структур, деревьев, документов.
Обеспечение качества на базе протокола RSVP Одним из средств обеспечения качества IP-телефонии является использование протокола резервирования ресурсов (Resourse Reservation Protocol, RSVP), рекомендованного комитетом IETF. С помощью RSVP мультимедиа программы могут потребовать специального качества обслуживания (QoS) посредством любого из сетевых протоколов IP, а также UDP, чтобы обеспечить качественную передачу видео и аудиосигналов. Протокол RSVP предусматривает гарантированное QoS благодаря тому, что через каждый компьютер, или узел, может передаваться определённое количество данных. Протокол RSVP предназначен только для резервирования части пропускной способности. Используя RSVP, отправитель периодически информирует получателя о свободном количестве ресурсов сообщением RSVP Path (см. рисунок 17). Транзитные маршрутизаторы по мере прохождения этого сообщения также анализируют имеющееся у них количество свободных ресурсов и подтверждают его соответствующим сообщением RSVP Resv, передаваемых в обратном направлении. Если ресурсов достаточно, то отправитель начинает передачу. Если ресурсов недостаточно, получатель должен снизить требования или прекратить передачу информации.
Рисунок 17 – Применение протокола RSVP
В виду зависимости RSVP от совместимости предела своих возможностей, когда он не может гарантировать запрошенный уровень QoS, все последующие запросы будут игнорироваться и удаляться. При отказе только одного узла обслуживать запрос вся стройная система RSVP распадается на части. RSVP имеет весьма хорошие перспективы на корпоративном уровне, где администратор имеет возможность определить, какие параметры будет использовать маршрутизатор для обслуживания запросов о предоставлении QoS. В глобальных сетях маршрутизаторы вовсе необязательно находятся под той же юрисдикцией, что и хосты и приложения, производящие запросы, что осложняет гарантированное QoS. Для уменьшения значений джиттера и задержек на сетевом уровне применяются гарантирующие пользователю заданный уровень качества механизмы RSVP, MPLS, ATM и другие. Они улучшают качество услуг, предоставляемых сетью, но не могут полностью устранить образование очередей в сетевых устройствах, а, следовательно, и совсем убрать джиттер. Компенсировать его негативное влияние позволяет разработанный IETF протокол прикладного уровня RTP (Realtime Transport Protocol), который используется технологией H.323.
|
|
|
Обеспечение качества на базе протокола RTP Протокол прикладного уровня RTP (Real-time Transport Protocol), предназначен для доставки чувствительной к задержкам информации с использованием сетевых служб одноадресной и групповой рассылки. Он не имеет собственных механизмов, гарантирующих своевременную доставку пакетов или другие параметры качества услуг - это осуществляют нижележащие протоколы. Обычно RTP работает поверх UDP и использует его службы, но может функционировать и поверх других транспортных протоколов (рисунок 3.5.2)
|
Рисунок 3.5.2 Стек протоколов Н.323
Служба RTP предусматривает указание типа полезной нагрузки и последовательного номера пакета в потоке, а также применение временных меток. Отправитель помечает каждый RTP-пакет временной меткой, а получатель извлекает ее и вычисляет суммарную задержку. Разница в задержке пакетов позволяет определить джиттер и смягчить его влияние - все пакеты будут выдаваться приложению с одинаковой задержкой.
Таким образом, главная особенность RTP - это вычисление средней задержки некоторого набора принятых пакетов и выдача их пользовательскому приложению с постоянной задержкой, равной этому среднему значению. Временная метка RTP соответствует моменту кодирования первого дискретного сигнала пакета. Поэтому, если RTP пакет, например, с видеоинформацией, разбивается на несколько пакетов нижележащего уровня, то временная метка уже не будет соотвествовать истинному времени их передачи, поскольку они перед передачей могут быть организованы в очередь. Еще одно преимущество RTP состоит в том, что его можно использовать с RSVP для передачи синхронизированной мультимедиаинформации с определенным уровнем качества обслуживания. Кроме того, разговоры передаются по сети Интернет в незашифрованном виде. Поэтому любой узел, находящийся на пути следования данных, может подключиться к этой линии и прослушать ваш разговор. Чтобы решить эту проблему, в RTP предлагается механизм, до некоторой степени обеспечивающий защиту от несанкционированного доступа и конфиденциальность. Эти средства довольно ненадежны и могут рассматриваться лишь как временное решение проблемы пока протоколы, поверх которых работает RTP, не будут располагать развитыми механизмами безопасности данных.
|
|
|
|
|
|
