Очевидно, что достаточное количество пользователей «потоковых» мультимедийных услуг желают или будут желать использовать такие стандартные для систем домашнего видео и DVD функции, как «пауза», «перемотка вперед/назад» и т.п. Как было сказано в п. 1.2.2 данной главы, реализация дополнительных протоколов позволит полностью удовлетворить запросы самого требовательного пользователя.

На момент написания книги самым широкораспространенным и быстроразвиваюшимся протоколом, на основе которого реализуются упомянутые выше функции, является «протокол для потоковых данных реального времени» RTSP (Real-Time Streaming Protocol) определенный в [RFC2326].

Главной функцией протокола RTSP является возможность управления «потоковым» приложением. Функции управления реализованы в программном продукте, осуществляющим воспроизведение аудио и/или видеоинформации, поступающей со стороны сервера, т.е. медиаплейеру. Управление осуществляется путем обмена управляющими сообщениями между сервером и клиентом. Управляющие сообщения протокола RTSP не принадлежат к информационным соединениям и потокам между сервером и клиентом - они используют отдельное соединение или поток с номером порта 544, поэтому этот протокол называется «выделенным» (out-of-band). Аналогию для управляющих сообщений RTSP можно провести с управляющим каналом в протоколе FTP. Спецификация RTSP позволяет использовать на транспортном уровне для своих лакетов как протокол TCP, так и UDP.

На рис. 1.27 приведен пример взаимодействия клиента и сервера при помощи протокола RTSP. Будем рассматривать случай, когда оконечный пользователь на стороне клиента использует стандартный браузер (browser) для просмотра гипертекстовой информации из сети и через него инициирует просмотр «потокового» видео со звуковым сопровождением. В результате процедуры инициирования (физически это может быть просто щелчок мышью на соответствующую гиперссылку) браузер посылает веб-серверу запрос о параметрах объекта (презентации), находящегося за гиперссылкой (в нашем случае это - «потоковое» видео со звуковым сопровождением), в результате чего веб-сервер присылает «файл описания презентации» (presentation description), пример которого приведен на рис. 1.26 [Schul97], Взаимодействие осуществляется через протокол HTTP [RFC 1945, RFC2616], Этот файл может содержать как ссылки на несколько «потоковых» файлов, так и директивы по их синхронизации. Каждая ссылка на «потоковый» файл должна начинаться с метода URL rtsp://.

Отметим, что физически «потоковые» файлы могут находиться на другом сервере, называемом «медиа-сервером» (media server). В рассматриваемом примере аудио и видеопотоки должны воспроизводиться параллельно на стороне клиента в режиме lip sync (синхронизация между аудио и видеопотоками), причем медиаплейер имеет возможность выбора в каком качестве должно воспроизводиться аудиосопровождение - на стороне медиа-сервера доступно два аудиопотока различного качества: высокого ni fi и низкого lofi. Отметим, что в примере предполагается использование известного формата SMIL [SMIL02] для файлов аудиопотока. Этот формат используется для обеспечения синхронизации между различными потоками многими коммерческими продуктами.

Рис. 1.26. Пример метакода «файл описания презентации» После принятия от веб-сервера «файла описания презентации» на стороне клиента браузер должен послать запрос на загрузку в оперативную память локального медиаплейера, способного воспроизводить аудио и видеопотоки заданного формата. Далее, как показано на рис. 1.27, медиаплейер на стороне клиента и медиа-сервер обмениваются рядом сообщений RTSP. Медиаплейер посылает медиа-серверу сообщение запроса установления RTSP-соединения RTSP SETUP, ответом на которое является сообщение о поддержке этого соединения RTSP ОК.

Сообщение RTSP SETUP содержит информацию о номере порта клиента, куда должны быть адресованы пакеты «потокового» файла. Затем медиаплейер посылает запрос RTSP PLAY на начало передачи «потокового» файла, пусть, в нашем случае, это аудио низкого качества lofi. После получения этого запроса, медиа-сервер начинает посылать медиаплейеру, находящемуся на стороне клиента, пакеты, содержащие требуемую аудиоинформацию.

Далее на рис. 1.27 показан пример реализации функции «пауза» - для приостановки посылки пакетов «потокового» аудио медиаплейер должен послать сообщение RTSP PAUSE, а медиа-сервер должен ответить сообщением RTSP ОК. Если пользователь решает окончить прослушивание/просмотр, должно быть инициировано разрушение RTSP-соединения, для чего медиаплейер посылает медиа-серверу сообщение RTSP TEARDOWN, а медиа-сервер должен ответить сообщением RTSP ОК.

Протокол RTSP не включает rs себя следующие функции:

• определение схем и алгоритмов компрессии для аудио и видео;

• определение каким образом аудио и видеоинформация инкапсулируется в пакеты для передачи через сеть; эта функция может быть реализована в протоколе RTP или в «корпоративном протоколе» производителя программного обеспечения приложения.

Например, в программных реализациях как медиа-сервера, так и клиента фирмы RealNetworks для обмена служебной информацией используется протокол RTSP, а аудио и видеоинформация инкапсулируется через протокол RTP;

• определение какой транспортный протокол используется для переноса пакетов «из-конца-в-конец» - может использоваться как UDP, так и TCP;

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

Самая свежая и полная информация о протоколе RTSP может быть найдена в Интернете по адресуhttp://www.cs.columbia.edu/~hgs/rtsp.

⇐Протокол rtcp | Управление трафиком и качество обслужевания в сети | Литература к главе 1⇒