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

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

 

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

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

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

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

Обычные телевизионные каналы передаются в широковещательном режиме множеству пользователей, и в типичном варианте пользователь может выбрать канал, чтобы принимать и смотреть его. Мобильное телевидение аналогично относится к доставке набора ("вживую") мультимедиа или мультимедийных потоков нескольким конечным пользователям. Каждый мультимедийный поток соответствует телевизионному каналу, и каждый пользователь должен иметь возможность выбирать то, какой канал смотреть. В настоящее время разрабатываются способы широковещательной/многоадресной доставки мобильного телевидения. Примерами таких усилий по стандартизации являются услуги широковещательной и многоадресной передачи (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=[e-mail]

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 необязательно должно отправляться после завершения прозрачной относительно каналов процедуры установления. Это значит, что пользовательский терминал вместо этого мог принять USD (незадолго) до инициирования процедуры установления или в определенное время в ходе процедуры установления. В этом случае серверный контроллер может быть выполнен с возможностью периодической передачи в широковещательном или многоадресном режиме USD с надлежащими временными интервалами.

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

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

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

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

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

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

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

В предпочтительной реализации новые значения синхронизации (SSRC) отправляются для всех мультимедийных потоков и каналов. Ответ PLAY от мультимедийного сервера в таком случае может иметь следующий формат:

RTSP/2.0 200 OK

RTSP-Info: URI="rtsp://tv.com/allchannels.sdp/audiotrack"

ssrc=0D12F123:seq=5712; rtptime=93407921,

URI="rtsp://tv.com/allchannels.sdp/videotrack"

ssrc=789DAF12 : seq=57654; rtptime=2792482193

Быстрое переключение каналов по настоящему изобретению, таким образом, использует запрос на рендеринг, такой как запрос RTSP PLAY, внутрь текущего мультимедийного сеанса, такого как сеанс RTSP, чтобы запросить новый канал. Как следствие, все эти параметры, согласованные и определенные в ходе общего прозрачного относительно каналов установления по изобретению, могут быть сохранены также для доставки нового мультимедийного содержимого. Это должно быть сравнено с переключением по предшествующему уровню техники, в котором текущий сеанс RTSP сначала должен быть остановлен и разорван, и полностью новый конкретный относительно канала запрос RTSP должен быть установлен, прежде чем мультимедийное содержимое нового канала сможет быть доставлено и подготовлено посредством рендеринга на пользовательском терминале. Посредством сравнения Фиг.6 с ситуацией на Фиг.1A и 1B очевидно, что примерно шесть передач и подтверждений приема и обработка в связи с передачей служебных сигналов более не требуется для переключения мультимедийных каналов. Как следствие, переключение каналов по изобретению становится гораздо быстрее, чем переключение в предшествующем уровне техники.

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

PLAY rtsp://tv.com/allchannels.sdp/channel2 RTSP/2.0,

где "tv.com/allchannels.sdp/channel2" - это AC URI мультимедийного канала номер 2.

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

PLAY rtsp://tv.com/allchannels.sdp?channel=2 RTSP/2.0,

где часть запроса используется для базового URI "http://tv.com/allchannels.sdp", а "2" - это идентификатор запрошенного канала.

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

PLAY rtsp:// RTSP/2.0 x-channel: "идентификатор запрошенного канала".

Идентификатор может быть просто цифровым числом, 1, 2, 3 и т.п., или каким-либо другим названием или идентификатором, в том числе идентификатор пользовательской услуги MBMS.

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

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

После того как пользовательский терминал принимает пользовательский ввод, чтобы переключиться на широковещательный канал, терминал компилирует запрос на паузу рендеринга, такой как запрос RTSP PAUSE. Этот запрос является традиционным запросом PAUSE, как описано в связи с Фиг.1A. Мультимедийный сервер отвечает приостановкой передачи мультимедийных данных текущего основанного на одноадресной передаче канала и предпочтительно отвечает с помощью отклика иди ответа PAUSE.

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

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

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

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

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

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

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

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

Если пользовательский терминал затем захочет завершить текущий мультимедийный сеанс, ранее описанная процедура с запросами и ответами PAUSE и TEARDOWN выполняется.₀

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

Общая прозрачная относительно каналов процедура установления сеанса согласно изобретению не обязательно должна следовать передаче служебных сигналов, описанной в связи с Фиг.3-6. В альтернативном подходе конвейерная обработка запросов и откликов RTSP может быть возможна. В этом случае пользовательский терминал компилирует и передает прозрачные относительно каналов запросы SETUP для видео и аудио, после которых следует конкретный относительно канала запрос PLAY. Это означает, что терминал не ждет каких-либо откликов на ранее переданный запрос перед передачей следующего. Мультимедийный сервер отвечает посредством отправки ответа SETUP для видео, ответа SETUP для аудио и ответа PLAY один за другим или фактически вместе. Мультимедийные данные мультимедийного канала, запрошенного сначала в запросе PLAY, затем доставляются в пользовательский терминал.

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

Фиг.8 - это схематичное представление основанной на одноадресной передаче системы 1 беспроводной связи согласно варианту осуществления настоящего изобретения. Система 1 связи содержит базовую станцию или сетевой узел 20, передающий мультимедийное содержимое в подключенные пользовательские терминалы 10, 100. Базовая станция 20 содержит или подключена к мультимедийному серверу 200 согласно изобретению, имеющему несколько доступных основанных на одноадресной передаче мультимедийных каналов. На чертеже первый пользовательский терминал 100 прослушивает один из этих основанных на одноадресной передаче мультимедийных каналов. Два других пользовательских терминала 10, тем не менее, прослушивают широковещательный канал, также доступный в мультимедийном сервере 200.

Фиг.9 - это схематичная блок-схема пользовательского терминала 100 согласно варианту осуществления настоящего изобретения. Этот пользовательский терминал 100 содержит передающее устройство и приемное устройство или приемопередающее устройство 110, схематично проиллюстрированное как один блок на чертеже. Блок 110 включает в себя традиционную функциональность передающего/приемного устройства, такую как модулятор/демодулятор, кодер/декодер и т.д.

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

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

Формирователь 135 запросов на рендеринг или воспроизведение реализован в пользовательском терминале, чтобы компилировать конкретный относительно канала запрос на рендеринг, после того как менеджер 140 установления выполнил прозрачную относительно каналов процедуру установления с мультимедийным сервером. Это сообщение запроса содержит идентификатор выбранного мультимедийного канала, такой как AC URI или другой идентификатор канала. Скомпилированный запрос на рендеринг перенаправляется в передающее устройство 110, которое перенаправляет его мультимедийному серверу для начала доставки мультимедиа.

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

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

Формирователь 135 запросов может быть реализован в мультимедийном или медийном проигрывателе 130 пользовательского терминала 100. Этот мультимедийный проигрыватель 130 предпочтительно соединен с экраном 120 дисплея и динамиками 160 терминала 100 для отображения и воспроизведения мультимедиа на них.

Необязательный мультимедийный буфер 150 может быть реализован в пользовательском терминале 100 для временного сохранения принимаемых мультимедийных данных, прежде чем они подготавливаются посредством рендеринга 130 на экране 120 и/или динамиках 160. Этот буфер 150 полезен в случае переключения каналов и, в частности, для переключения от одноадресной к широковещательной передаче или от широковещательной к одноадресной передаче, поскольку два мультимедийных потока могут приниматься параллельно и сохраняться в буфере 150 для предоставления возможности органичного перехода между каналами.

Блоки 110, 130, 135 и 140 пользовательского терминала 100 могут быть предоставлены как программное обеспечение, аппаратные средства или их комбинация. Формирователь 135 запросов на воспроизведения может быть реализован в мультимедийном проигрывателе 130, как проиллюстрировано на чертеже, или в другом месте в терминале 100.

Фиг.10 - это схематичная блок-схема варианта осуществления менеджера 140 установления сеанса пользовательского терминала на Фиг.9. Менеджер 140 установления необязательно, но предпочтительно, содержит блок 141 для формирования прозрачного относительно каналов запроса на описание. Этот формирователь 141 запросов DESCRIBE компилирует ранее описанный прозрачный относительно каналов запрос DESCRIBE, который может составлять общее прозрачное относительно каналов сообщение запроса на сеанс по изобретению.

Результирующий ответ DESCRIBE обрабатывается посредством необязательного, но предпочтительного процессора 142 сообщений описания. Этот процессор 142, в частности, извлекает оповещение о нескольких мультимедийных каналах, доступных на мультимедийном сервере. В этом случае URI или другие идентификаторы каналов включаются в сообщение описания, процессор 142 извлекает эти идентификаторы и перенаправляет их в формирователь запросов на рендеринг пользовательского терминала.

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

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

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

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

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

В случае, если идентификаторы каналов не включены в сообщение описания, обрабатываемое посредством процессора 142 отклика с описанием, либо этот ответ с описанием не принят, менеджер 140 установления предпочтительно использует необязательный, но предпочтительный формирователь 147 запросов идентификатора. Этот формирователь 147 составляет сообщение запроса для идентификаторов доступных основанных на одноадресной передаче каналов в мультимедийном сервере. Сформированное сообщение в типичном варианте передается на сервер, но альтернативно может передаваться в какой-либо сетевой узел, имеющий доступ к этой информации.

Сообщение ответа от мультимедийного сервера или другого узла перенаправляется из приемного устройства терминала в процессор 148 ответов идентификатора менеджера 140 установления. Этот процессор 148 извлекает информацию мультимедийных каналов, в типичном варианте в форме URI и предпочтительно в форме AC URI, включенных в отклик. Информация идентификатора затем перенаправляется в формирователь запросов на рендеринг и используется посредством формирователя при составлении конкретного относительно канала запроса на рендеринг.

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

Блоки 141-148 менеджера 140 установления сеанса могут быть предоставлены как программное обеспечение, аппаратные средства или их комбинация. Блоки 141-148 могут быть реализованы вместе в менеджере 140 установления. Так же, распределенная реализация возможна с некоторыми из блоков, предусмотренными в другом месте пользовательского терминала.

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

Мультимедийный сервер 200 содержит или имеет доступ к нескольким мультимедийным каналам 400, 410. Это означает, что сервер 200 может содержать или быть подключенным к банку данных, сохраняющему заранее записанное мультимедийное содержимое. Альтернативно или помимо этого, мультимедийный источник может быть в форме "живого" мультимедийного содержимого, принимаемого в мультимедийном сервере 200 для дальнейшей передачи в запрашивающие терминалы. Мультимедийный менеджер 230 сервера 200 реализован для осуществления корректной обработки мультимедиа, к примеру, выбора корректного мультимедийного содержимого для различных терминалов, формирования пакетов данных с мультимедийным содержимым.

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

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

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

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

Фиг.5 схематично проиллюстрировала использование отдельного серверного контроллера 300, который может быть использован в беспроводной системе радиосвязи для передачи идентификатора одноадресного (и широковещательного канала), доступного из мультимедийного сервера 200. Этот контроллер 300 показан на Фиг.11. В этом случае данный контроллер 300 предпочтительно содержит менеджер 320 идентификаторов для формирования сообщений, содержащих эту информацию идентификаторов. Передающее устройство 310 контроллера 300 затем передает сообщение, в типичном варианте в форме многоадресной или широковещательной передачи, в соответствующие терминалы.

Менеджер 320 идентификаторов также может посредством передающего устройства 310 опросить мультимедийный сервер 200 на предмет информации мультимедийных каналов, в том числе их идентификаторов и доступности.

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

Блоки 210-230 мультимедийного сервера 200 могут быть предоставлены как программное обеспечение, аппаратные средства или их комбинация. Блоки 210-230 могут быть реализованы вместе в сервере 200 в одном сетевом узле. Так же, распределенная реализация возможна с некоторыми из блоков, предусмотренными в других узлах сети. То же пояснение, касающееся программной/аппаратной реализации, также применяется к блокам 310 и 320 серверного контроллера 300.

Фиг.12 - это схематичная блок-схема менеджера 220 установления сеанса мультимедийного сервера по Фиг.11. Менеджер 220 установления необязательно, но предпочтительно содержит процессор 221 запросов на описание для обработки прозрачного относительно каналов запроса из пользовательского терминала. Процессор 221 в типичном варианте идентифицирует терминал, из которого исходит запрос, и передает необязательный, но предпочтительный формирователь 222 сообщений или ответов описания. Формирователь компилирует ранее поясненный ответ DESCRIBE, который содержит оповещение о мультимедийных каналах, доступных в мультимедийном сервере. Это оповещение может быть фактическими идентификаторами или URI каналов или оповещением того, что несколько каналов может быть выбрано посредством терминала, и при этом их идентификаторы сообщаются отдельно.

Процессор 223 запросов на установление видео и процессор 225 запросов на установление аудио обрабатывает принимаемые запросы SETUP для видео и аудио. Процессоры 223, 225 выбирают транспортные параметры, включающие в себя выходные видео- и аудиопорты, чтобы использовать для сеанса. Эта информация перенаправляется в передающее устройство мультимедийного сервера для использования в предстоящей доставке мультимедиа и в соответствующий формирователь 224 ответов по установлению видео и формирователь 226 ответов по установлению аудио. Формирователь 224 компилирует соответствующие ответы SETUP для аудио и видео, содержащие входные транспортные параметры для передачи в терминал. Формирователь 224 ответов SETUP для видео предпочтительно также включает в себя идентификатор сеанса, сформированный в мультимедийном сервере и включенный во все последующие ответы и запросы, обмениваемые между сервером и пользовательским терминалом.

В случае если формирователь 222 ответов с описанием не включает идентификаторы мультимедийных каналов в ответ с описанием, менеджер 220 установления может использовать необязательный формирователь 228 сообщений идентификаторов. Этот формирователь 228 составляет сообщение, содержащее идентификаторы, такие как AC URI, основанные на одноадресной передаче мультимедийных каналов, доступных в данный момент на сервере. Формирователь 228 может работать при приеме явного запроса от пользовательского терминала. Альтернативно, сформированное сообщение может передаваться в широковещательном или многоадресном режиме посредством сервера в несколько терминалов.

Блоки 221-228 менеджера 220 установления сеанса могут быть предоставлены как программное обеспечение, аппаратные средства или их комбинация. Блоки 221-228 могут быть реализованы вместе в менеджере 220 установления. Так же, распределенная реализация возможна с некоторыми из блоков, предусмотренными в другом месте мультимедийного сервера.

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

ССЫЛКИ

[1] WO 2006/096104.

[2] 3GPP TS 26.234 v7.1.0; 3^rd Generation Partnership Project; Technical Specification group Services and System Aspects; Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs, декабрь 2006 года.

[3] Network Working Group, Request for Comments: 2327, апрель 1998 года, SDP: Session Description Protocol.

[4] Network Working Group, Request for Comments: 2326, апрель 1998 года, Real Time Streaming Protocol (RTSP).

[5] Network Working Group, Request for Comments: 4234, октябрь 2005 года, Augmented BNF for Syntax Specifications: ABNF.

1. Способ управления основанным на одноадресной передаче мультимедийным сеансом с привлечением пользовательского терминала (100) и мультимедийного сервера (200), предоставляющего несколько мультимедийных каналов, осуществляемый в пользовательском терминале (100), при этом каждый мультимедийный канал переносит соответствующее мультимедийное содержимое, причем упомянутый способ содержит этапы, на которых:
передают посредством упомянутого пользовательского терминала (100) в упомянутый мультимедийный сервер (200) общий запрос на сеанс, не содержащий конкретных относительно содержимого идентификаторов; и
выполняют посредством упомянутого пользовательского терминала (100) с упомянутым мультимедийным сервером (200) на основе упомянутого запроса на сеанс общую процедуру установления основанного на одноадресной передаче мультимедийного сеанса; и
передают посредством упомянутого пользовательского терминала (100) в упомянутый мультимедийный сервер (200) конкретный относительно содержимого запрос на рендеринг в форме запроса PLAY протокола потоковой передачи в реальном времени (RTSP) для первого мультимедийного содержимого первого мультимедийного канала из упомянутых нескольких мультимедийных каналов после того, как упомянутая общая процедура установления основанного на одноадресной передаче мультимедийного сеанса выполнена, при этом упомянутый запрос PLAY RTSP содержит уникальный идентификатор ресурсов мультимедийного содержимого, ассоциативно связанный с упомянутым первым мультимедийным содержимым.

2. Способ по п.1, дополнительно содержащий этап, на котором:
передают посредством упомянутого пользовательского терминала (100) в упомянутый мультимедийный сервер (200) запрос PLAY RTSP для второго мультимедийного содержимого второго мультимедийного канала из упомянутых нескольких мультимедийных каналов, чтобы переключиться с упомянутого первого мультимедийного канала на упомянутый второй мультимедийный канал в ходе упомянутого мультимедийного сеанса.

3. Способ по п.1 или 2, дополнительно содержащий этапы, на которых:
передают посредством упомянутого пользовательского терминала (100) в упомянутый мультимедийный сервер (200) запрос на паузу рендеринга, чтобы временно приостанавливать прием мультимедийного содержимого упомянутого первого мультимедийного канала из упомянутого мультимедийного сервера; и
передают посредством упомянутого пользовательского терминала (100) в упомянутый мультимедийный сервер (200) запрос PLAY RTSP для мультимедийного содержимого мультимедийного канала из упомянутых нескольких мультимедийных каналов, чтобы возобновить прием мультимедийного содержимого в ходе упомянутого мультимедийного сеанса, при этом упомянутый запрос PLAY RTSP содержит уникальный идентификатор ресурсов мультимедийного содержимого, ассоциативно связанный с упомянутым мультимедийным содержимым.

4. Способ управления основанным на одноадресной передаче мультимедийным сеансом с привлечением пользовательского терминала (100) и мультимедийного сервера (200), предоставляющего несколько мультимедийных каналов, осуществляемый в мультимедийном сервере (200), при этом каждый мультимедийный канал переносит соответствующее мультимедийное содержимое, причем упомянутый способ содержит этапы, на которых:
принимают посредством упомянутого мультимедийного сервера (200) из упомянутого пользовательского терминала (100) общий запрос на сеанс, не содержащий конкретных относительно содержимого идентификаторов;
выполняют посредством упомянутого мультимедийного сервера (200) с упомянутым пользовательским терминалом (100) на основе упомянутого запроса на сеанс общую процедуру установления основанного на одноадресной передаче мультимедийного сеанса; и
передают посредством упомянутого мультимедийного сервера (200) в упомянутый пользовательский терминал (100) и на основе конкретного относительно содержимого запроса на рендеринг в форме запроса PLAY протокола потоковой передачи в реальном времени (RTSP) для упомянутого первого мультимедийного содержимого первого мультимедийного канала из упомянутых нескольких мультимедийных каналов, исходящего из упомянутого пользовательского терминала (100) и принятого после того, как упомянутая общая процедура установления основанного на одноадресной передаче мультимедийного сеанса выполнена, мультимедийное содержимое упомянутого первого мультимедийного канала, при этом упомянутый запрос PLAY RTSP содержит уникальный идентификатор ресурсов мультимедийного содержимого, ассоциативно связанный с упомянутым первым мультимедийным содержимым.

5. Способ по п.4, дополнительно содержащий этап, на котором:
передают посредством упомянутого мультимедийного сервера (200) в упомянутый пользовательский терминал (100) и на основе запроса PLAY RTSP для второго мультимедийного содержимого второго мультимедийного канала из упомянутых нескольких мультимедийных каналов, исходящего из упомянутого пользовательского терминала (100), мультимедийное содержимое упомянутого второго мультимедийного канала в ходе упомянутого мультимедийного сеанса.

6. Способ по п.4 или 5, дополнительно содержащий этапы, на которых:
временно приостанавливают посредством упомянутого мультимедийного сервера (200) на основе запроса на паузу рендеринга из упомянутого пользовательского терминала (100) передачу упомянутого мультимедийного содержимого упомянутого первого мультимедийного канала в упомянутый пользовательский терминал (100); и
передают посредством упомянутого мультимедийного сервера (200) в упомянутый пользовательский терминал (100) на основе запроса PLAY RTSP для мультимедийного содержимого мультимедийного канала из упомянутых нескольких мультимедийных каналов, исходящего из упомянутого пользовательского терминала (100), мультимедийное содержимое упомянутого запрошенного мультимедийного канала, при этом упомянутый запрос PLAY RTSP содержит уникальный идентификатор ресурсов мультимедийного содержимого, ассоциативно связанный с упомянутым мультимедийным содержимым.

7. Пользовательский терминал (100), содержащий:
передающее устройство (110) для передачи общего запроса на сеанс в мультимедийный сервер (200), предоставляющий несколько мультимедийных каналов, причем каждый мультимедийный канал переносит соответствующее содержимое, упомянутый общий запрос на сеанс не содержит конкретных относительно содержимого идентификаторов; и
средство (140) для выполнения с помощью упомянутого мультимедийного сервера (200) и на основе упомянутого запроса на сеанс общей основанной на одноадресной передаче процедуры установления основанного на одноадресной передаче мультимедийного сеанса, при этом упомянутое передающее устройство (110) выполнено с возможностью передачи в упомянутый мультимедийный сервер (200) конкретного относительно содержимого запроса на рендеринг в форме запроса PLAY протокола потоковой передачи в реальном времени (RTSP) для первого мультимедийного содержимого первого мультимедийного канала из упомянутых нескольких мультимедийных каналов, после того как упомянутое средство выполнения завершило упомянутую общую процедуру установления основанного на одноадресной передаче мультимедийного сеанса, при этом упомянутый запрос PLAY RTSP содержит уникальный идентификатор ресурсов мультимедийного содержимого, ассоциативно связанный с упомянутым первым мультимедийным содержимым.

8. Пользовательский терминал по п.7, в котором упомянутое средство (140) выполнения содержит:
формирователь (143; 145) запросов на установление для формирования общего запроса на установление, предназначенного для упомянутого мультимедийного сервера (200); и
процессор (144; 146) сообщений установления для обработки общего сообщения установления, исходящего из упомянутого мультимедийного сервера (200) и сформированного на основе упомянутого запроса на установление, причем упомянутое общее сообщение установления содержит информацию, по меньшей мере, по одному порту связи для использования приемным устройством (110) упомянутого пользовательского терминала (100) в ходе упомянутого мультимедийного сеанса.

9. Пользовательский терминал по п.7 или 8, в котором упомянутое средство (140) выполнения содержит:
процессор (148) сообщений идентификатора для извлечения из сообщения идентификатора уникального идентификатора мультимедийного содержимого для каждого мультимедийного содержимого из упомянутых нескольких мультимедийных каналов, причем упомянутый пользовательский терминал (100) дополнительно содержит:
формирователь (135) запросов на рендеринг для формирования упомянутого запроса на рендеринг на основе уникального идентификатора мультимедийного содержимого, ассоциативно связанного с упомянутым первым мультимедийным содержимым.

10. Пользовательский терминал по п.7, в котором упомянутое передающее устройство (110) выполнено с возможностью передачи в упомянутый мультимедийный сервер (200) запроса PLAY RTSP для второго мультимедийного содержимого второго мультимедийного канала из упомянутых нескольких мультимедийных каналов, чтобы переключиться с упомянутого первого мультимедийного канала на упомянутый второй мультимедийный канал в ходе упомянутого мультимедийного сеанса.

11. Пользовательский терминал по п.7, в котором упомянутое передающее устройство (110) выполнено с возможностью i) передачи в упомянутый мультимедийный сервер (200) запроса на паузу рендеринга, чтобы временно приостанавливать прием мультимедийных данных упомянутого первого мультимедийного канала из упомянутого мультимедийного сервера (200), и ii) передачи в упомянутый мультимедийный сервер (200) запроса PLAY RTSP для мультимедийного содержимого мультимедийного канала из упомянутых нескольких мультимедийных каналов, чтобы возобновить прием мультимедийных данных в ходе упомянутого мультимедийного сеанса.

12. Мультимедийный сервер (200), предоставляющий несколько мультимедийных каналов, при этом каждый мультимедийный канал переносит соответствующее содержимое, причем упомянутый мультимедийный сервер (200) содержит:
приемное устройство (210) для приема от пользовательского терминала (100) общего запроса на сеанс, не содержащего конкретных относительно содержимого идентификаторов;
средство (220) для выполнения с упомянутым пользовательским терминалом (100) на основе упомянутого запроса на сеанс общей основанной на одноадресной передаче процедуры установления основанного на одноадресной передаче мультимедийного сеанса;
передающее устройство (210) для передачи в упомянутый пользовательский терминал (100) на основе конкретного относительно содержимого запроса на рендеринг в форме запроса PLAY протокола потоковой передачи в реальном времени (RTSP) для первого мультимедийного содержимого первого мультимедийного канала из упомянутых нескольких мультимедийных каналов, исходящего из упомянутого пользовательского терминала (100) и принятого посредством упомянутого приемного устройства (210), после того как упомянутое средство (220) выполнения завершило упомянутую общую процедуру установления основанного на одноадресной передаче мультимедийного сеанса, мультимедийных данных упомянутого первого мультимедийного канала, при этом упомянутый запрос PLAY RTSP содержит уникальный идентификатор ресурсов мультимедийного содержимого, ассоциативно связанный с упомянутым первым мультимедийным содержимым.

13. Мультимедийный сервер по п.12, в котором упомянутое средство (220) выполнения содержит:
формирователь (222) сообщений описания сеанса для формирования на основе упомянутого запроса на сеанс общего сообщения описания сеанса, содержащего оповещение об упомянутых нескольких мультимедийных каналах, при этом упомянутое передающее устройство (210) выполнено с возможностью передачи упомянутого общего сообщения описания сеанса в упомянутый пользовательский терминал (100).

14. Мультимедийный сервер по п.12 или 13, в котором упомянутое средство (220) выполнения содержит:
формирователь (224; 226) сообщений установления для формирования на основе общего сообщения описания сеанса, принятого от упомянутого пользовательского терминала (100), общего сообщения запроса на установление, содержащего информацию, по меньшей мере, об одном порте связи для использования для упомянутого мультимедийного сеанса, при этом упомянутое передающее устройство (210) выполнено с возможностью передачи упомянутого общего сообщения установления в упомянутый пользовательский терминал (100).

15. Мультимедийный сервер по п.12, в котором упомянутое передающее устройство (210) выполнено с возможностью передачи в упомянутый пользовательский терминал (100) и на основе запроса PLAY RTSP для второго мультимедийного содержимого второго мультимедийного канала из упомянутых нескольких мультимедийных каналов, исходящего из упомянутого пользовательского терминала (100), мультимедийных данных упомянутого второго мультимедийного канала в ходе упомянутого мультимедийного сеанса.

16. Мультимедийный сервер по п.12, в котором упомянутое передающее устройство (210) выполнено с возможностью i) временного приостановления на основе запроса на паузу рендеринга, исходящего из упомянутого пользовательского терминала (100), передачи упомянутых мультимедийных данных упомянутого первого мультимедийного канала в упомянутый пользовательский терминал (100), и ii) передачи в упомянутый пользовательский терминал (100) на основе запроса PLAY RTSP для мультимедийного содержимого мультимедийного канала из упомянутых нескольких мультимедийных каналов, исходящего из упомянутого пользовательского терминала (100), мультимедийных данных упомянутого запрошенного мультимедийного канала.