Управление мультимедийными каналами

Управление мультимедийными каналами

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

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

Уровень техники

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

Обычные телевизионные каналы передаются в широковещательном режиме множеству пользователей, и в типичном варианте пользователь может выбрать канал, чтобы принимать и смотреть его. Мобильное телевидение аналогично относится к доставке набора ("вживую") мультимедиа или мультимедийных потоков нескольким конечным пользователям. Каждый мультимедийный поток соответствует телевизионному каналу, и каждый пользователь должен иметь возможность выбирать то, какой канал смотреть. В настоящее время разрабатываются способы широковещательной/многоадресной доставки мобильного телевидения. Примерами таких усилий по стандартизации являются услуги широковещательной и многоадресной передачи (MBMS) 3GPP и цифровое видеовещание для карманных устройств (DVB-H) Европейского института телекоммуникационных стандартов (ETSI). Они аналогичны традиционному телевидению по способу широковещательного распространения.

Между тем, до тех пор, пока мобильное телевидение на основе многоадресной/широковещательной передачи не станет доступным, есть потребность в решении, которое может быть реализовано для существующих мобильных транспортных каналов. Оно также в дальнейшем должно представлять большой интерес для сот с небольшим количеством пользователей и для сетей с достаточной пропускной способностью, где одноадресная транспортировка является предпочтительным средством распространения.

Аналогичная мобильному телевидению услуга с использованием потоковой передачи по сетям на базе Интернет-протокола (IP) может быть реализована в существующих мобильных сетях. Примером является услуга потоковой передачи с коммутацией пакетов (PS) (PSS), разработанная в 3GPP. Чтобы начать такой мультимедийный или телевизионный сеанс, пользователь в типичном варианте переходит на веб-страницу или портал и щелкает либо выбирает ссылку, чтобы посмотреть канал потоковой передачи вживую.

Также существует несколько патентованных решений по потоковой передаче, которые могут быть использованы для мобильного телевидения, к примеру, RealNetworks, Apple QuickTime и Microsoft Media Player. Они, помимо этого, в типичном варианте имеют веб-страницу или портал, где щелкается ссылка для того, чтобы начать прием определенного канала.

Одна из целей услуг мобильного телевидения заключается в том, чтобы обеспечить возможность переключения между каналами, как можно сделать в обычных широковещательных телевизионных каналах. Если все каналы передаются в широковещательном режиме, приемное устройство может локально выбирать между каналами посредством выбора соответствующего транспортного канала и с помощью соответствующего демультиплексора. Это имеет место для стандартного кабельного, спутникового или наземного телевидения, а также для планируемых мобильных стандартов MBMS и DVB-H. Тем не менее, для сеансов одноадресной передачи клиент должен вместо этого выполнить действие на "сервере" или поставщике содержимого, чтобы отправить требуемый канал.

Традиционный способ выполнения мобильной потоковой передачи на основе IP состоит в том, чтобы выбрать указанное содержимое в обозревателе. Это действие начинает загрузку файла по протоколу описания сеанса (SDP) или языка синхронизированной интеграции мультимедиа (SMIL), который, в свою очередь, инициирует сеанс потоковой передачи по протоколу потоковой передачи в реальном времени (RTSP) в мультимедийном проигрывателе пользовательского терминала. Примерное время, которое проходит до того момента, пока пользователь не увидит содержимое на экране пользовательского терминала, в типичном варианте составляет порядка или чуть больше десяти секунд, из которых пять секунд может составлять установка приложения, а остальное время - передача служебных сигналов (примерно две секунды) и буферизация (примерно три или четыре секунды). Если пользователь хочет переключиться на другой "мультимедийный или телевизионный канал", он должен остановить текущий поток данных и вернуться обратно в обозреватель, где он выбирает другой канал посредством щелчка ссылки. Далее новый RTP-сеанс начинается, мультимедийный проигрыватель инициализируется и начинает буферизоваться, и возникает новая задержка порядка десяти секунд.

Что касается других способов выбора канала одноадресной передачи, помимо ссылок обозревателя, самый простой подход состоит в том, чтобы создавать приложение, которое устанавливает новый сеанс потоковой передачи для нового URI (универсального идентификатора ресурса) каждый раз, когда переключается канал. Это достаточно распространено, но весьма медленно в том, что полностью новый процесс передачи служебных сигналов RTSP должен осуществляться, как и буферизация содержимого.

Чтобы разрешить эту проблему замедления, разработано гораздо более быстрое решение [1], в котором пользователь имеет сеанс непрерывной потоковой передачи и может инициировать переключение каналов посредством отдельной передачи служебных сигналов по HTTP (протоколу передачи гипертекста) или другому протоколу.

Сущность изобретения

Ограничение процедуры, предлагаемой в документе [1], заключается в том, что все каналы должны быть закодированы аналогичным образом, чтобы создавать один непрерывный сеанс RTP (протокол управления передачей в реальном времени) для каждого мультимедийного потока.

Настоящее изобретение преодолевает эти и другие недостатки структур предшествующего уровня техники.

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

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

Эти и другие цели удовлетворяются изобретением в соответствии с тем, как задано в прилагаемой формуле изобретения.

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

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

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

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

Краткое описание чертежей

Изобретение вместе с дополнительными целями и преимуществами можно лучше всего понять посредством обращения к последующему описанию, рассматриваемому вместе с прилагаемыми чертежами, из которых:

Фиг.1A и 1B - это схемы передачи сигналов, иллюстрирующие процедуру установления канала и процедуру переключения каналов согласно предшествующему уровню техники;

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

Фиг.3 - это схема передачи сигналов, иллюстрирующая прозрачную относительно каналов процедуру установления сеанса согласно варианту осуществления настоящего изобретения;

Фиг.4 - это схема передачи сигналов, иллюстрирующая прозрачную относительно каналов процедуру установления сеанса согласно другому варианту осуществления настоящего изобретения;

Фиг.5 - это схема передачи сигналов, иллюстрирующая прозрачную относительно каналов процедуру установления сеанса согласно дополнительному варианту осуществления настоящего изобретения;

Фиг.6 - это схема передачи сигналов, иллюстрирующая процедуру запроса канала и процедуру переключения каналов согласно варианту осуществления изобретения;

Фиг.7 - это схема передачи сигналов, иллюстрирующая процедуру временной постановки на паузу и процедуру завершения основанного на одноадресной передаче мультимедийного сеанса по настоящему изобретению;

Фиг.8 - это схематичное представление части системы связи, к которой могут быть применены методики настоящего изобретения;

Фиг.9 - это схематичная блок-схема пользовательского терминала согласно настоящему изобретению;

Фиг.10 - это схематичная блок-схема менеджера установления сеанса согласно настоящему изобретению, реализуемому в пользовательском терминале по Фиг.9;

Фиг.11 - это схематичная блок-схема мультимедийного сервера согласно настоящему изобретению; и

Фиг.12 - это схематичная блок-схема менеджера установления сеанса согласно настоящему изобретению, реализуемому в мультимедийном сервере по Фиг.11.

Подробное описание изобретения

На чертежах одинаковые символы ссылок используются для соответствующих или аналогичных элементов.

Настоящее изобретение относится к управлению мультимедийными сеансами и, в частности, к управлению основанным на одноадресной передаче мультимедийным сеансом. Управление сеансами по изобретению уменьшает число передач и подтверждений приема, требуемых для переключения основанных на одноадресной передаче мультимедийных каналов или для переключения между одноадресными и многоадресными/широковещательными каналами, в сравнении с методиками предшествующего уровня техники.

Как следствие этого снижения числа передач и подтверждений приема, воспринимаемое пользователями время переключения мультимедийных каналов уменьшается, достигая "истинных" уровней переключения каналов. Следовательно, настоящее изобретение предоставляет аналогичные телевидению приемы использования, похожие на текущую обычную телевизионную систему и грядущее основанное на многоадресной/широковещательной передаче мобильное телевидение, но в основанной на одноадресной передаче системе связи. Методики настоящего изобретения могут быть применены к любой такой системе одноадресной передачи и, в частности, к системе беспроводной связи, которая использует Интернет-протокол, IP, для передачи данных. Типичным примером такой системы связи является система с коммутацией пакетов (PS), которая предоставляет мультимедийные данные подключенным пользователям посредством потоковой передачи PS (PSS). Подробные сведения о PSS приведены в документе [2].

Мультимедийный канал согласно настоящему изобретению может, к примеру, переносить мультимедиа "вживую" или состоять из заранее записанного содержимого, составленного из одного или более клипов.

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

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

Чтобы упростить понимание настоящего изобретения и его преимуществ, краткий обзор методик предшествующего уровня техники для установления основанного на одноадресной передаче мультимедийного сеанса и переключения мультимедийных каналов сначала приводится со ссылкой на Фиг.1A и 1B. Данные чертежи иллюстрируют передачу служебных сигналов, выполняемую в ходе установления и управления сеансом по протоколу потоковой передачи в реальном времени (RTSP). Как известно в данной области техники, RTSP - это протокол прикладного уровня для контроля доставки мультимедийных данных со свойствами реального времени. Сегодня доступны различные версии RTSP, в том числе RTSP 1.0 и RTSP 2.0. Настоящее изобретение может быть использовано в связи с обеими этими версиями и любой другой версией RTSP.

Сеанс RTSP может быть инициализирован посредством компиляции и передачи запроса DESCRIBE в пользовательском терминале. В ответ на запрос DESCRIBE мультимедийный сервер компилирует и возвращает ответ (сообщение 200 OK), содержащий описание запрошенного мультимедийного содержимого. Ответ в типичном варианте содержит универсальный указатель ресурса (URL) для описания мультимедиа на мультимедийном сервере. Этот ответ содержит всю информацию для инициализации мультимедиа по запрошенному мультимедийному содержимому. В типичной реализации описание дается в форме файла протокола описания сеанса (SDP). Данный файл SDP содержит, помимо прочего, название выбранного мультимедиа, транспортный адрес и доступные кодеки для мультимедиа, кроме URI информации описания.

Типичный пример ответа на DESCRIBE с помощью файла SDP следующий:

RTSP/1.0 200 OK

CSeq: "уникальный порядковый номер сеанса"

Date: "дата и время создания"

Content-Type: "тип содержимого файла, помещенного в ответ"

Content-Length: "длина файла"

Вышеприведенные четыре строки составляют заголовки в ответе RTSP. Следующие строки иллюстрируют примерное содержимое файла SDP:

v=0 "начало файла SDP"

o="автор"

s="название сеанса"

i="информация сеанса"

u="URI описания"

e="адрес электронной почты"

c="информация подключения"

t="время, пока сеанс активен"

a=control:* "контрольная строка, используемая на сеансовом уровне, * задает, что управляющий URI такой же, что и используется для DESCRIBE"

a=control:audiotrack "контрольная строка для звукового мультимедиа со связанным URI"

m=audio 3456 RTP/AVP 0

a=control:videotrack "контрольная строка для видео-мультимедиа со связанным URI"

m=video 2232 RTP/AVP 31

Типичный пример обмена данными между пользовательским терминалом (UE) и мультимедийным сервером (MS) в таком случае может быть следующим:

UE -> MS Запрос:

DESCRIBE rtsp://mediaserver.com/movie.test RTSP/1.0

CSeq: 1

MS -> UE Ответ:

RTSP/1.0 200 OK

CSeq: 1

Date: 28 Feb 2006 15:35:06 GMT

Content-Type: application/sdp

Content-Length: 435

v=0

o=- 950814089 950814089 IN IP4 144.132.134.67

s=Пример составного управления AMR-речью и H.263-видео

e=foo@bar.com

c=IN IP4 192.168.30.29

b=AS:77

t=0 0

a=range:npt=0-59.3478

a=control:*

b=AS:13

a=fmtp:97 mode-set=0,2,5,7; maxptime=200

a=control:streamID=0

m=video 0 RTP/AVP 98

b=AS:64f

a=rtpmap:98 H263-200/90000

a=fmtp:98 profile=3; level=10

a=control: streamID=1

Подробные сведения о файле SDP приведены в документе [3].

Пользовательский терминал после этого компилирует и передает запрос SETUP для универсального идентификатора ресурса (URI) требуемого мультимедийного содержимого. Типичный мультимедийный сеанс влечет за собой видео- и аудиосодержимое, передаваемое по основанному на одноадресной передаче мультимедийному каналу. В этом случае процедура SETUP выполняется пошагово для двух типов содержимого. Например, запрос SETUP на видео сначала может быть передан, содержащий URI видеосодержимого. Запрос также содержит индикатор транспортных параметров, допустимых для пользовательского терминала при передаче мультимедийных данных. Эти параметры включают в себя, в частности, клиентские входные порты, используемые для видеосодержимого. Мультимедийный сервер формирует, в ответ на запрос SETUP, идентификатор сеанса, который должен быть использован в дальнейшем в качестве идентификатора текущего мультимедийного сеанса. Этот идентификатор сеанса возвращается вместе с транспортными параметрами, выбранными посредством сервера, и портами вывода видео на сервере.

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

Сеанс RTSP теперь успешно установлен, и фактическая доставка мультимедийного содержимого может быть начата. Следовательно, пользовательский терминал компилирует запрос PLAY, сообщающий серверу начать отправку сообщенного мультимедийного содержимого через транспортный механизм, согласованный в ходе установления сеанса. Запрос PLAY может указывать диапазон, где обычное время воспроизведения должно быть начато, или параметр времени, задающий время, в которое воспроизведение или подготовка посредством рендеринга мультимедиа должна начаться. Мультимедийный сервер обрабатывает данный запрос PLAY и отвечает параметром либо диапазоном времени с подтвержденным приемом и информацией синхронизации, к примеру, относительно rtptime в поле rtp-information ответа.

Запрошенное содержимое далее может быть доставлено по основанному на одноадресной передаче мультимедийному каналу с помощью определенного транспортного механизма.

Если пользователь впоследствии захочет переключиться на второй основанный на одноадресной передаче канал, текущий сеанс RTSP сначала должен быть завершен. Это может быть реализовано посредством передачи запроса PAUSE, содержащего URI мультимедиа и идентификатор сеанса, на мультимедийный сервер. Это приводит к временному прерыванию доставляемого мультимедийного потока. Тем не менее, выделенные ресурсы для потока не высвобождаются в этот момент. Пользовательский терминал продолжает посредством передачи запроса TEARDOWN, чтобы прекратить доставку потока для данного URI, высвобождая ресурсы, ассоциативно связанные с ним. Это завершает текущий мультимедийный сеанс. Подробные сведения о RTSP приведены в документе [4].

Затем пользовательский терминал принудительно устанавливает новый сеанс RTSP, но для нового мультимедийного канала, как проиллюстрировано на Фиг.1B. Таким образом, такая же процедура что и описана ранее, проводится еще раз, но с URI нового мультимедийного содержимого и с новым идентификатором сеанса. Таким образом, переключение каналов влечет за собой объемную передачу служебных сигналов, охватывающую шесть передач и подтверждений приема, а также некоторую задержку на обработку в мультимедийном сервере и пользовательском терминале до возможности подготавливать посредством рендеринга содержимое нового мультимедийного канала.

Настоящее изобретение снижает эту объемную передачу служебных сигналов в связи с переключением каналов за счет выбора мультимедийного канала через конкретный относительно канала запрос на рендеринг (запрос RTSP PLAY) и общую прозрачную относительно каналов процедуру установления сеанса.

Фиг.2 - это блок-схема последовательности операций способа управления основанным на одноадресной передаче мультимедийным сеансом, включающим в себя пользовательский терминал (клиент) и мультимедийный сервер, предоставляющий несколько, по меньшей мере, два различных мультимедийных канала. Он начинается на этапе S1, где пользовательский терминал формирует и передает общий прозрачный относительно каналов запрос на сеанс в мультимедийный сервер. Данный запрос на сеанс тем самым не выбирает конкретное мультимедийное содержимое или мультимедийный канал. Таким образом, в этот момент мультимедийному серверу еще не сообщено о том, какое мультимедийное содержимое запрашивает пользовательский терминал. После приема общего прозрачного относительно каналов запроса на сеанс мультимедийный сервер и пользовательский терминал выполняют общую прозрачную относительно каналов процедуру установления мультимедийного сеанса на следующем этапе S2. Эта процедура установления выполняется на основе ранее сформированного и переданного запроса на сеанс. Таким образом, данный этап S2, по сути, влечет за собой установление сеанса RTSP между пользовательским терминалом и сервером. Тем не менее, в отличие от предшествующего уровня техники, данная процедура установления сеанса не влечет за собой никакой детализации мультимедийного содержимого, которое впоследствии должно быть доставлено в пользовательский терминал. Таким образом, информация обменивается между пользовательским терминалом и мультимедийным сервером, такая как согласование транспортных параметров и сообщение идентификатора сеанса. Тем не менее, этот обмен информацией выполняется без какого-либо явного или неявного выбора мультимедийного канала, чтобы использовать для мультимедийного сеанса. Это означает, что фактический выбор мультимедийного содержимого/канала откладывается до тех пор, пока не завершена процедура установления сеанса.

Оповещение по требуемому мультимедийному каналу и содержимому осуществляется первый раз после того, как общий прозрачный относительно каналов мультимедийный сеанс успешно установлен. В этот момент пользовательский терминал формирует и передает конкретный относительно канала запрос на рендеринг для требуемого канала в мультимедийный сервер на этапе S3. Только теперь сервер узнает о том, какое конкретное мультимедийное содержимое запрашивает пользовательский терминал, и поэтому начинает доставку мультимедийных данных запрошенного канала с помощью согласованного транспортного механизма. Как только терминал принимает мультимедийные данные, его мультимедийный проигрыватель начинает рендеринг или воспроизведение содержимого на терминале для своего пользователя на этапе S4. Этот рендеринг данных в типичном варианте влечет за собой отображение видеосодержимого на экране дисплея пользовательского терминала или подключенного к нему дисплея и воспроизведение содержимого на динамиках терминала или подключенных к нему динамиках.

Способ затем завершается. Далее подробнее поясняются различные сценарии, описывающие общую прозрачную относительно каналов процедуру установления сеанса в связи со схемами передачи сигналов по Фиг.3-5. На этих схемах мультимедийный сеанс выполняется как сеанс RTSP, и поэтому терминология этих запросов и ответов RTSP использована на чертежах. Тем не менее, методики настоящего изобретения могут быть применены к другим протоколам, используемым для установления и управления основанным на одноадресной передаче мультимедийным сеансом.

Фиг.3 - это схема передачи сигналов, иллюстрирующая выполнение общей прозрачной относительно каналов процедуры установления мультимедийного сеанса согласно варианту осуществления настоящего изобретения. Установление инициируется посредством передачи общего прозрачного относительно каналов сообщения запроса на сеанс в мультимедийный сервер. Это сообщение запроса может быть запросом DESCRIBE, если используется, или запросом SETUP. На этом и последующих чертежах использованы запросы и ответы DESCRIBE, но изобретение также может быть применено к процедуре без этих запросов и ответов.

Запрос DESCRIBE не указывает фактического канала, как в предшествующем уровне техники (rtsp://http://tv.com/channell.sdp на Фиг.1A и rtsp://http://tv.com/channel2.sdp на Фиг.1B). В отличие от этого, запрос является общим в отношении того, что он запрашивает описание множества, предпочтительно всех элементов мультимедийного содержимого, доступных посредством основанной на одноадресной передаче доставке из мультимедийного сервера.

Мультимедийный сервер формирует сообщение описания или извлекает заранее сформированное такое сообщение на основе принятого запроса DESCRIBE. Данный ответ DESCRIBE предпочтительно выполняется в форме файла SDP или какого-либо другого формата сообщений. Этот файл SDP содержит оповещение о доступных мультимедийных каналах и их мультимедийном содержимом. В соответствии с ранее приведенным примером файла SDP предшествующего уровня техники файл SDP, возвращаемый в ответе DESCRIBE, может быть в следующей форме:

RTSP/2.0 200 OK

CSeq: 1

Date: "дата и время создания"

Content-Type: allchannels/sdp

Content-Length: "длина файла"

v=0

o="автор"

i="информация сеанса"

u="URI описания"

t="время, пока сеанс активен"

a=control: tv.com/allchannels.sdp/channel1

a=control: tv.com/allchannels.sdp/channel2

....

a=control: tv.com/allchannels.sdp/channelN

Это означает, что описание SDP дополняется несколькими контрольными строками сеанса, причем каждая такая строка оповещает об одном из доступных мультимедийных каналов. В альтернативном подходе новый атрибут altcontrol вводится в файл SDP. Это означает, что атрибут control сохраняется для обратной совместимости.

Соответствующая мультимедийная строка в файле SDP в таком случае может выглядеть следующим образом:

a=altcontrol: list channel1

a=altcontrol: list channel2

a=altcontrol: list channelN

В обоих этих вариантах осуществления оповещения мультимедийных каналов могут быть в форме так называемых URI составного управления (AC). Такой AC URI относится и к видеосодержимому, и к ассоциативно связанному аудиосодержимому, которые должны подготавливаться посредством рендеринга вместе в пользовательском терминале. В альтернативном подходе для мультимедийного содержимого, содержащего видео и аудио, отдельные URI могут быть использованы в строках control или altcontrol для двух типов мультимедиа на каждый доступный мультимедийный канал.

В случае обратной совместимости файл SDP может быть дополнен строкой атрибута control помимо атрибута altcontrol, т.е.:

a=control: defaultchannel

a=altcontrol: list channel1

a=altcontrol: list channel2

a=altcontrol: list channel

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

Чтобы предоставить возможность восстановления для служебных сигналов, запрос на сеанс может включать в себя поддерживающий запрос в отношении того, поддерживает ли мультимедийный сервер общую прозрачную относительно каналов процедуру установления. Это может быть реализовано с помощью тега признака с заголовком Require в первом запросе DESCRIBE, переданном посредством пользовательского терминала. Данный заголовок в таком случае может включать в себя новый атрибут:

DESCRIBE rtsp://tv.com/allchannels.sdp RTSP/2.0

Require: multiple-control-uris

Если сервер не поддерживает общую процедуру установления, он может ответить сообщением об ошибке, к примеру "551 Option not supported".

После того как пользовательский терминал принял сообщение описания с предпочтительными AC URI, он формирует общее прозрачное относительно каналов сообщение запроса на транспортировку или установление. В соответствии с описанием в связи с Фиг.1A, если мультимедийный канал содержит видео- и аудиосодержимое, общий прозрачный относительно каналов запрос на установление предпочтительно компилируется и передается для обоих типов содержимого, как показано на Фиг.3. Первый такой общий прозрачный относительно каналов запрос может выполняться для видео- (аудио)- содержимого, тогда как второй запрос в таком случае предназначен для аудио- (видео-) содержимого. Запросы предпочтительно задают транспортные параметры, допустимые для пользовательского терминала при последующей передаче мультимедиа. Например, они включают в себя оповещения о входных видео- и аудиопортах для пользовательского терминала и другие транспортные параметры, требуемые для установления мультимедийного сеанса.

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

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

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

В варианте осуществления, описанном выше в связи с Фиг.3, AC URI различных доступных мультимедийных каналов сообщаются пользовательскому терминалу в сообщении описания (файле SDP ответа DESCRIBE). Тем не менее, может быть возможным то, что эти URI, т.е. идентификаторы мультимедийных каналов, неизвестны, когда файл SDP создан. Более того, доступность мультимедийных каналов может зависеть от времени дня или может быть различной в различные дни. Применение фиксированного заранее заданного файла SDP, следовательно, является слишком негибким для того, чтобы справиться с этой ситуацией. Возможным решением в данном случае может быть формировать новый файл SDP в мультимедийном сервере каждый раз, когда он принимает ответ DESCRIBE. Тем не менее, это повышает требования по обработке данных мультимедийного сервера и вводит дополнительные задержки в процедуру установления мультимедийного сеанса.

Альтернативный подход состоит в том, чтобы вместо этого использовать общие шаблоны в файле SDP и затем сообщать пользовательскому терминалу URI соответствующих мультимедийных каналов в последующий момент процедуры установления. Этот подход взят на Фиг.4 и 5.

Фиг.4 - это схема передачи сигналов, иллюстрирующая выполнение общей прозрачной относительно каналов процедуры установления мультимедийного сеанса согласно другому варианту осуществления настоящего изобретения. Установление инициируется посредством передачи общего прозрачного относительно каналов сообщения запроса на сеанс (DESCRIBE) в мультимедийный сервер. После приема этого сообщения мультимедийный сервер предоставляет файл SDP или другое сообщение описания, содержащее общее оповещение о доступных мультимедийных каналах. Данное оповещение может быть использовано в связи с атрибутом control:

a=control: tv.com/allchannels/*

или новым атрибутом altcontrol:

a=altcontrol: dynamic

Это сообщает о том, что список альтернативных AC URI является динамическим или неизвестен в конкретный момент и предоставляется посредством другого средства. В дополненной нормальной форме Бэкуса-Наура (ABNF), см. документ [5], сеансовая часть файла SDP может быть записана следующим образом:

altcontrol-line - "a=altcontrol:" control-type [sp rtsp-URI]

control-type = "list"/"dynamic"/token

rtsp-URI = "задано как в RTSP 2.0"

Фактический смысл каждой строки control также может быть предоставлен в файле SDP, но может быть более оптимально задан в полной таблице каналов, которая описывает каналы одноадресной передачи либо каналы как одноадресной, так и широковещательной передачи.

Передача оставшихся служебных сигналов запроса и ответа SETUP выполняется таким же общим прозрачным относительно каналов способом, что и описано выше в связи с Фиг.3.

Пользовательский терминал далее компилирует и передает запрос на AC URI, которые динамически/обобщенно сообщены в файле SDP. Этот запрос может быть отправлен в мультимедийный сервер либо даже другой сервер или узел в системе связи, имеющей доступ к информации текущих доступных одноадресных мультимедийных каналов в мультимедийном сервере и их соответствующим URI. Запрос может быть, к примеру, в форме обычного HTTP-запроса или запроса полной таблицы каналов. Мультимедийный сервер или другой сервер/узел отвечает на этот запрос посредством возвращения информации URI основанных на одноадресной передаче мультимедийных каналов, доступных в настоящий момент в мультимедийном сервере.

В другом подходе сообщение URI осуществляется посредством широковещательной или многоадресной передачи из мультимедийного сервера или некоторого другого сервера либо узла. Эта ситуация схематично проиллюстрирована на Фиг.5. На этой схеме передачи сигналов отдельный серверный контроллер выполняет сообщение AC URI в форме широковещательного/многоадресного описания пользовательской услуги (USD).

Мультимедийный сервер ранее сообщил серверному контроллеру о своих других основанных на одноадресной передаче каналах, их доступности и URI.

Как описано выше, общая прозрачная относительно каналов процедура установления мультимедийного сеанса согласно изобретению не обязательно должна инициироваться посредством передачи запроса DESCRIBE. Это проиллюстрировано дополнительно на текущем чертеже, поскольку пунктирные линии могут быть опущены. Как следствие, процедура установления может инициироваться непосредственно посредством передачи общего прозрачного относительно каналов сообщения запроса SETUP из пользовательского терминала. Последующая передача служебных сигналов до последнего ответа SETUP аналогична тому, что описано ранее в связи с Фиг.3.

Пользовательский терминал здесь информируется о AC URI мультимедийных каналов, доступных в данный момент в мультимедийном сервере, посредством широковещательной или многоадресной передачи USD из серверного контроллера. Сообщение USD