Способ для реализации функциональных возможностей ims в телевизионной приставке
Изобретение относится к телевидению по Интернет-протоколу (IPTV) и IP мультимедийным системам (IMS) и предназначено для предоставления услуг IMS телевизионным приставкам. Телевизионной приставке (50) позволяют выполнять услуги IMS посредством обеспечения приложения (40) IMS, основанного на сценарии, выполняющегося в декларативной среде (54) приложений телевизионной приставки (50) для реализации сеанса IPTV, передаваемого между шлюзом IMS (20) и системой (56) внедренной OITF телевизионной приставки (50). В результате, не только телевизионные приставки (50), предварительно сконфигурированные и имеющие установленные собственные функциональные средства IMS, могут предоставлять услуги IMS пользователям в домашней сети (1). 4 н. и 25 з.п. ф-лы, 13 ил.
ОБЛАСТЬ ТЕХНИКИ
Настоящее изобретение в целом относится к IPTV и IMS и, в частности, к обеспечению таких функциональных средств и возможностей IPTV и IMS в телевизионной приставке.
ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ
Мультимедийные услуги интернет-протокола (IP) обеспечивают динамическую комбинацию голоса, видео, передачи сообщений, данных и т.д. в пределах одного и того же сеанса. Наличие различных доступных приложений и типов медиа позволяет увеличить число услуг, предлагаемых конечным пользователям, и, таким образом, улучшить опыт межперсональной связи. Это предоставляет персонифицированные, богатые мультимедийные услуги связи.
Телевидение по Интернет-протоколу (IP) (IPTV) является развивающейся системой, в которой услуги цифрового телевидения и мультимедийные услуги поставляются к телевизионным приставкам, представленным в домашней среде, используя IP, по сетевой инфраструктуре. В настоящее время IPTV чаще всего ассоциируется с услугами передачи видеоинформации по требованию (VoD) и услугами живого TV. Однако IPTV может также предоставлять интернет-услуги, такие как web-доступ и передача голоса по протоколу IP (VoIP). Другим признаком IPTV является возможность интеграции и конвергенции с другими мультимедийными услугами. На эту возможность главным образом влияет мультимедийная подсистема IP (IMS), обеспечивающая архитектурную основу для доставки мультимедийных услуг IP в среде IPTV. Такие услуги, основанные на IMS, которые могут быть использованы телевизионными приставками, включают в себя чаты, услуги присутствия, услуги списка контактов и различные услуги передачи сообщений, такие как передача мгновенных сообщений, позволяющая пользователям IPTV связываться друг с другом.
IMS обеспечивает ключевые признаки, чтобы увеличить опыт коммуникации от человека к человеку - конечному пользователю посредством блоков, позволяющих подключение услуг стандартизированной IMS, которые облегчают предоставление новых богатых услуг связи от человека к человеку, то есть от клиента к клиенту, а также услуги от человека к контенту, то есть от клиента к серверу, по сетям, основанным на IP.
В целом, сеть, основанная на IP, предоставляющая услуги IPTV конечным пользователям, может быть в форме управляемой сети или так называемого открытого Интернета, или неуправляемой сети. Последняя форма предоставляет услуги IPTV через Интернет, не гарантируя качество обслуживания. Примерами первой формы являются сети связи, основанные на радиосвязи, управляемые оператором сети, и которые могут предоставлять услуги IPTV с гарантией качества уровней обслуживания. Терминалы пользователя, так называемые телевизионные приставки (приставки STB), представленные в домашней среде для влияния на услуги IPTV, в целом, являются отличными типами, зависящими от того, используются ли они в управляемой сети или открытом Интернете. Например, телевизионная приставка для использования в управляемой сети может быть изготовлена, чтобы содержать внедренные или собственные функциональные средства, то есть компьютерный программный код, для предоставления услуг IMS. Следовательно, телевизионная приставка содержит собственные логические блоки, установленные локально, и/или элементы аппаратного обеспечения, которые необходимы для установления и управления сеансом связи IMS, включающим в себя возможности использования интерфейса домашней сети - интерфейса шлюза IMS (HNI-IGI) между собственным или внедренным приложением IMS и удаленным шлюзом IMS (IG). Телевизионная приставка также имеет код стека реализованной IMS, определяющий, как выполняется такая связь, связанная с IMS.
Однако телевизионные приставки, телевизоры и другие терминалы IPTV являются чувствительными к затратам в том смысле, что являются весьма дорогими для покупающих пользователей, когда дело доходит до новых функциональных средств. Это означает, что для того, чтобы быть в состоянии реализовывать услуги IMS, пользователь должен заменить свою существующую телевизионную приставку той, которая предварительно сконфигурирована для включения в себя необходимых логических блоков и приложений для предоставления услуг IMS. Однако такое решение является как затратным, так и негибким для пользователя.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Таким образом, существует потребность в том, чтобы разрешить использование управляемого IPTV и услуг IMS в телевизионных приставках, которые не производятся с реализованными собственными или внедренными функциональными средствами IMS.
Общей задачей является предоставление услуг IMS телевизионным приставкам.
Конкретной задачей является обеспечение функциональных средств IMS в телевизионных приставках.
Кратко, настоящее изобретение раскрывает обеспечение функциональных средств и приложения IMS в среде браузера в телевизионной приставке и, следовательно, не должно иметь любой собственной (родной), то есть предварительно установленной и сконфигурированной, поддержки для IMS в телевизионной приставке. Приложение IMS, основанное на сценарии, запущенное в web-браузере в среде декларативного приложения, создано для принятия на себя роли приложения IMS в телевизионной приставке и выполнения необходимой обработки данных и сигнализации сеанса IPTV с помощью внешних блоков.
Более подробно, аспект вариантов осуществления относится к приложению IMS, сконфигурированному для того, чтобы быть реализованным в телевизионной приставке в домашней сети. Приложение IMS содержит генератор сигнала, сконфигурированный для генерирования сигналов сеанса IPTV, предназначенных шлюзу IMS от имени телевизионной приставки, чтобы установить и управлять сеансом IPTV. Провайдер адреса приложения IMS сконфигурирован для выдачи информации адреса в систему внедренной или собственной функции терминала открытого IPTV (OITF), реализованную в телевизионной приставке. Информация адреса ассоциируется с медиаданными, доступными от медиасервера в глобальной сети, соединенного с домашней сетью, и медиаданные должны быть визуализированы в течение сеанса IPTV в телевизионной приставке. Принятая информация адреса исходит из шлюза IMS. Приложением IMS этого аспекта является приложение IMS, основанное на сценарии, сконфигурированное для исполнения web-браузером, реализованным в телевизионной приставке, и поэтому может быть использовано в телевизионной приставке, которая не произведена или, иначе, не сконфигурирована для содержания предварительно установленных внедренных или собственных функциональных средств IMS.
Дополнительный аспект относится к телевизионной приставке, содержащей приложение IMS, основанное на сценарии, и интерфейс связи, сконфигурированный для разрешения связи со шлюзом IMS. Web-браузер обеспечивает так называемую среду декларативного приложения, в которой приложение IMS, основанное на сценарии, запускается для генерирования web-страницы, отображаемой пользователю на экране отображения телевизионной приставки или соединенном с телевизионной приставкой. Система внедренной OITF реализуется в телевизионной приставке, соединенной с интерфейсом связи, и конфигурируется для генерирования запроса медиа на основании информации адреса, выданной посредством приложения IMS, основанного на сценарии. Этот запрос медиа передается посредством интерфейса связи к медиасерверу в глобальной сети, чтобы запросить медиаданные для визуализации в телевизионной приставке в непрерывном сеансе IPTV.
Другой аспект относится к шлюзу IMS, который содержит интерфейс связи, сконфигурированный для разрешения связи с телевизионной приставкой в домашней сети и серверами в глобальной сети. Процессор регистра сконфигурирован для генерирования запроса регистра, содержащего пользовательский идентификатор пользователя телевизионной приставки и предназначен для сервера IMS в глобальной сети. Процессор подписки шлюза IMS сконфигурирован для генерирования запроса подписки, предназначенного для провайдера услуг IPTV в глобальной сети. Таким образом, шлюз IMS выполняет регистрацию, обнаружение и выбор услуг для телевизионной приставки. Процессор преобразования адреса сконфигурирован для отображения, для каждой услуги IPTV, доступной для пользователя из глобальной сети, информации адреса, принятой в ответ на запрос подписки, в преобразованную информацию адреса, ассоциированную с соответствующими услугами IPTV, но указывающей на шлюз IMS. Шлюз IMS дополнительно содержит процессор создания страницы, сконфигурированный для генерирования web-страницы, содержащей преобразованную информацию адреса и предназначенной для приложения IMS, основанного на сценарии, в телевизионной приставке для отображения посредством web-браузера на экране отображения.
Способ установления сеанса IPTV содержит, согласно аспекту, запуск приложения IMS, основанного на сценарии, в web-браузере, реализованном в телевизионной приставке. Приложение IMS, основанное на сценарии, генерирует сигналы установки сеанса IPTV на основании активации пользовательского ввода телевизионной приставки или соединенного с телевизионной приставкой. Сигналы установки сеанса IPTV передаются на шлюз IMS, который, в свою очередь, передает информацию адреса, которая принимается приложением IMS, основанным на сценарии. Информация адреса, которая ассоциируется с медиаданными, доступными от медиасервера, отправляется посредством приложения IMS, основанного на сценарии, в систему внедренной OITF телевизионной приставки для инициации генерирования запроса медиа в отношении медиаданных в сеансе IPTV.
В другом аспекте способ установления сеанса IPTV содержит передачу посредством шлюза IMS запроса регистра, содержащего пользовательский идентификатор пользователя телевизионной приставки, на сервер IMS. Шлюз IMS также передает запрос подписки, предназначенный для провайдера услуг IPTV, который отвечает посредством возвращения информации адреса в шлюз IMS. Эта информация адреса ассоциируется с доступными услугами IPTV и отображается шлюзом IMS в преобразованную информацию адреса, указывающую на шлюз IMS. Преобразованная информация адреса используется для компиляции web-страницы, которая передается на приложение IMS, основанное на сценарии, телевизионной приставки.
Поэтому протоколы и логические блоки, требуемые для проведения связи сеанса IPTV и IMS со шлюзом IMS, не должны быть предварительно установлены в телевизионной приставке, но вместо этого они могут управляться приложением IMS, основанным на сценарии, реализованным браузером. Это означает, что услуги IMS могут быть предоставлены всем телевизионным приставкам, имеющим web-браузер, реализующий среду декларативного приложения.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Изобретение, вместе с дополнительными целями и их преимуществами, может быть лучше всего понято посредством ссылки на нижеследующее описание вместе с сопроводительными чертежами, в которых:
Фиг. 1 является схематическим кратким обзором сети распределения телевидения IP (IPTV);
Фиг. 2 является схематическим кратким обзором структурной архитектуры телевизионной приставки (STB) согласно предшествующему уровню техники в домашней сети;
Фиг. 3 является схематическим кратким обзором структурной архитектуры STB согласно варианту осуществления в домашней сети;
Фиг. 4A и 4B являются диаграммами сигналов, иллюстрирующими вариант осуществления установления сеанса мультимедийной подсистемы IP (IMS);
Фиг. 5A и 5B являются диаграммами сигналов, иллюстрирующими другой вариант осуществления установления сеанса IMS;
Фиг. 6 является диаграммой сигналов, иллюстрирующей вариант осуществления установления и завершения сеанса передачи видеоинформации по требованию (VoD);
Фиг. 7 является диаграммой сигналов, иллюстрирующей вариант осуществления установления, управления и завершения сеанса IMS, включающего запланированный контент;
Фиг. 8 является диаграммой сигналов, иллюстрирующей другой вариант осуществления установления и управления сеансом IMS, включающим запланированный контент;
Фиг. 9 является схематической блок-схемой варианта осуществления приложения IMS;
Фиг. 10 является схематической блок-схемой варианта осуществления STB; и
Фиг. 11 является схематической блок-схемой варианта осуществления шлюза IMS (IG).
ПОДРОБНОЕ ОПИСАНИЕ
На всех чертежах одни и те же номера позиций используются для аналогичных или соответствующих элементов.
Варианты осуществления относятся к предоставлению услуг мультимедийной подсистемы (IMS), согласно интернет-протоколу, (IP) терминалам пользователя и телевизионным приставкам без потребности в любых предварительно сконфигурированных приложениях IMS, представленных в телевизионных приставках в качестве установленных внедренных или собственных приложений.
Фиг. 1 является схематическим кратким обзором системы телевидения IP (IPTV), в основном, содержащей две взаимосоединенные сети, - домашнюю сеть 1 и глобальную сеть 2. Глобальная сеть 2 может быть контролируемой или частной сетью, которой оперирует оператор сети. Альтернативно, глобальная сеть 2 является неконтролируемой или открытой сетью, обычно обозначаемой как Открытый Интернет в данной области техники. Иначе, глобальная сеть 2 имеет один или более контент-провайдеров или медиасерверов 70, имеющих доступ к медиаконтенту, который должен быть распределен пользовательскому оборудованию или телевизионным приставкам 50, представленным в домашней сети 1. Эти медиасерверы 70 могут быть скомпонованы в сеть, выделенными медиасерверами или, действительно, представлять генерируемые потребителем медиа (аудио-визуальные данные) в форме медиа, доступной от других пользователей в своих соответствующих домашних сетях. В целом, медиаданные являются доступными для домашней сети 1 посредством одного или более провайдеров IPTV или серверов 80 приложения IPTV, и одного или более провайдеров 90 доступа. Первое представляет объект, реализованный сетью, который предоставляет услуги IPTV пользователям системы IPTV, тогда как последний обеспечивает фактическую передачу и доступ к предоставленным услугам домашней сети 2.
Глобальная сеть 2, проиллюстрированная на Фиг. 1, должна быть просто рассмотрена как иллюстративный пример части глобальной сети системы IPTV. Другие сетевые решения, содержащие больше или меньше сетевых объектов, чем объекты, проиллюстрированные на этом чертеже, могут быть альтернативно использованы без какого-либо влияния на описания вариантов осуществления. Например, в некоторых сетях единственный оператор или сервер может выполнять функции всех или некоторых из функциональных средств: медиасервера 70, провайдера 80 IPTV и провайдера 90 доступа.
Домашняя сеть 1, иногда обозначаемая как сеть жилого здания или потребительская сеть, в некоторых вариантах осуществления может быть основана на Ethernet или одной из существующих технологий проводной домашней сети, такой как союз организации сети домашних телефонных линий (HomePNA) или стандарт G.hn сектора стандартизации в области телекоммуникации (ITU-T), который обеспечивает возможность создания высокоскоростной локальной сети, используя существующие домашние проводные средства соединения. Другие примеры включают в себя различные решения локальной сети (LAN). Это означает, что услуги, связанные с IPTV, включающие в себя услуги IMS, могут быть доставлены по IP и широкополосному соединению потребителя, такому как асимметричная цифровая абонентская линия связи (ADSL), сверхскоростная цифровая абонентская линия связи (VDSL), общественный Ethernet и т.д. Также решения беспроводной сети могут быть использованы для установления локальной сети, включающей в себя комбинации проводных и беспроводных способов.
Устройства 20-50 домашней сети 1 обычно взаимно соединены с глобальной сетью 2 через шлюз 10 (GW), обеспечивающий интерфейс между этими двумя сетями 1, 2. Этот шлюз 10 работает аналогичным способом маршрутизатору относительно отправления данных из домашней сети 1, таких как сгенерированные запросы услуг IPTV пользователя, в глобальную сеть 2 и отправления данных из глобальной сети 2, таких как услуги IPTV и ассоциированные медиа, в домашнюю сеть 1.
В варианте осуществления, проиллюстрированном на Фиг. 1, домашняя сеть 1 также содержит домашний шлюз IMS (HIGA), часто в данной области техники просто обозначаемый как шлюз 20 IMS (IG), в целом, управляющий завершением IMS и взаимодействующий в домашней сети 1. Следовательно, IG 20 может иметь проводное или беспроводное соединение с одним или более устройствами 30, 35, 50 с возможностями IMS, неограничивающим образом представленными посредством мобильного телефона 30, компьютера/ноутбука 35 и обычной телевизионной приставки (STB) на чертеже.
IG 20 может быть автономным устройством, которое соединяется с GW 10, как проиллюстрировано на чертеже. Альтернативно, функциональные средства IG 20 могут быть обеспечены в одном и том же физическом устройстве, что и GW 10, таким образом, в основном комбинируя пропускание IMS и сетевую взаимосвязь, и пропускание в единственном устройстве. Такое устройство также может быть модемом или другим шлюзовым блоком.
Хотя IG 20 иллюстрируется как формирующий часть домашней сети 1 на чертеже, он должен быть просто рассмотрен как иллюстративный вариант осуществления. Также реализованные сетью решения IG возможны и в вариантах осуществления, в которых IG 20 вместо этого полностью или по меньшей мере частично реализуется в глобальной сети 2. В таком случае IG 20 преимущественно реализуется в узле сети и может быть совместно скомпонован с другими функциональными средствами глобальной сети 2, такими как провайдер 80 IPTV и/или провайдер 90 доступа.
Домашняя сеть 1 обычно содержит одну или более телевизионных приставок 50, которые являются устройствами, способными обрабатывать и визуализировать медиа IPTV. Существует большое количество различных пользовательских оборудований, терминалов и устройств, которые могут выполнять роль телевизионной приставки 50 в домашней сети 1. Некоторые неограниченные примеры включают в себя декодер, компьютер и т.д., имеющие возможность принимать медиаданные от провайдера 80 IPTV и шлюза 10 и обрабатывать, то есть декодировать и визуализировать, медиаданные на включенном или подсоединенном экране 60 отображения. В отличие от традиционных декодеров и телевизионных приставок в цифровых системах TV, в системе IPTV телевизионная приставка 50 обеспечивает двухстороннюю связь по сети IP и учитывает декодирование потоковых медиа. Также мобильные устройства 30, 35, беспроводным образом связывающиеся со шлюзом 10 необязательно через IG 20, могут работать как телевизионные приставки согласно вариантам осуществления. Таким образом, мобильный телефон 30 и компьютер/ноутбук 35, проиллюстрированные на чертеже, могут быть расценены как телевизионные приставки. Телевизионная приставка может быть также объединена в устройстве отображения, например, TV с разрешенным IPTV.
Далее «телевизионная приставка» используется для обозначения любого пользовательского оборудования, терминала или устройства, способного быть обеспеченным в домашней сети и способного запускать приложения с целью предоставления услуг IPTV одному или более пользователям, и имеющего функциональные средства обработки медиа, связанные с IPTV, для отображения на подсоединенном экране отображения, например, для такой формы медиа, как видео, изображения, текст и т.д., и/или воспроизведения посредством подсоединенного громкоговорителя, например, для такой формы медиа, как аудио.
В данной области техники открытая функция терминала IPTV (OITF), или функция терминала IPTV (ITF), иногда используется для обозначения телевизионной приставки и функциональных средств, необходимых для установки и управления сеансом связи IPTV. Однако в данном документе телевизионная приставка последовательно используется для обозначения устройства, сконструированного для того, чтобы быть обеспеченным в домашней сети и для предоставления услуг IPTV, включающих в себя услуги IMS, пользователям. Поэтому выражение "телевизионная приставка" также охватывает эти устройства или функциональные средства, реализуемые устройством, которые обозначаются OITF и ITF в данной области техники.
IPTV должно быть широко интерпретировано, чтобы охватить мультимедийные услуги, такие как телевидение, видео, аудио, текст, графика, данные, поставляемые по сетям, основанным на IP, на пользовательское оборудование в домашней сети, где осуществляется локальная обработка, то есть визуализация и/или воспроизведение медиа.
В целом, телевизионная приставка содержит или способна выполнять различные приложения, связанные с IPTV, предоставляющие услуги IPTV пользователям. В традиционных системах IPTV эти приложения, связанные с IPTV, и, в частности, приложения IMS, главным образом, были в форме внедренных или собственных (родных) приложений. Такие внедренные приложения устанавливаются и запускаются локально в телевизионной приставке. Телевизионная приставка может быть также заранее оборудована такими установленными внедренными приложениями. Далее в описании "система внедренной OITF" обозначает те части функциональных средств OITF телевизионной приставки, которые являются внедренными и собственными по отношению к телевизионной приставке. Это означает, что эта система внедренной OITF устанавливается и запускается локально в телевизионной приставке и обычно предварительно устанавливается там после продажи. Таким образом, телевизионная приставка содержит структуры аппаратного обеспечения и/или элементы программных кодов для осуществления, будучи выполняемой обычным процессором телевизионной приставки, функциональных средств системы OITF. Поэтому система внедренной OITF имеет свое собственное непосредственное взаимодействие с пользователем, такое как удаленное управление, клавиатура, мышь и т.д., и звуковая/видеовизуализация и, необязательно, функциональные средства захвата, такие как дисплей, спикеры (громкоговорители), камеры, микрофоны, или может быть непосредственно соединена с другими звуковыми/видеоустройствами визуализации/захвата, не проходя через связь домашней сети.
Фиг. 2 схематично иллюстрирует краткий обзор телевизионной приставки 50 с реализованными функциональными средствами OITF согласно предшествующему уровню техники. Эта OITF ответственна за предоставления услуг IPTV и IMS телевизионной приставке 50, как определено форумом открытой IPTV. На чертеже связь, которая основана на домашнем сетевом интерфейсе - интерфейсе шлюза IMS (HNI-IGI), относится к сеансам IMS. Таким образом, блок, разрешающий подключение устройства воспроизведения (плеера) HNI-IGI, может быть обеспечен в качестве интерфейса между устройством воспроизведения аудио/видео (AV), приложением вещания, устройством воспроизведения медиа и IG 20. Кроме того, пользовательское управление, регистрация и обнаружение и выбор услуг (SD&S) используют передачу сообщений HNI-IGI для связи с IG 20. В целом, эти принятые сообщения HNI-IGI преобразуются посредством IG 20 в сообщения протокола инициирования сеанса связи (SIP), которые отправляются через локальную сеть (LAN) на шлюз 10 и затем дополнительно передаются в глобальную сеть 2, представленную как глобальная сеть (WAN) на чертеже. В этом контексте IG 20 может вести себя как сервер протокола передачи гипертекстовых данных (HTTP), и OITF ведет себя как клиент HTTP. Это означает, что сообщения HNI-IGI, в целом, находятся в форме запросов или ответов HTTP HNI-IGI, таких как:
HTTP POST <IG URI>/<HNI-IGI message type>
<HTTP headers>
<X-OITF extension headers> or <X-HNI-IGI extension headers>
Content-Type: <...>
Content-Length: <Number>
<Message body>
HTTP/1.1 <HTTP response>
<HTTP headers>
<X-OITF extension headers> or <X-HNI-IGI extension headers>
Content-Type: <...>
Content-Length: <Number>
<Message body>
Сообщение HNI-IGI может быть типом SIP, в котором сообщение является сообщением HNI-IGI, соответствующим сообщению SIP. IG 20 преобразует его в соответствующее сообщение SIP посредством добавления и изменения релевантных заголовков. Сообщение HNI-IGI типа AUX является сообщением HNI-IGI, которое не преобразуется в сообщение SIP. Вместо этого IG 20 обрабатывает это сообщение и отвечает соответственно. Для большей информации о передаче сообщений HNI-IGI и связи между OITF и IG делается ссылка на Open IPTV Forum (открытый форум IPTV) - спецификацию выпуска 1, Том 4 - протоколы, V1.0, 6 января 2009, описания которых тем самым явно включены здесь по ссылке и в конкретной секции 5.5, относящейся к функции инфраструктуры системы протоколов и 5.5.1, относящейся к интерфейсу OITF-IG (HNI-IGI).
Это означает, что телевизионные приставки 50, не имеющие такие локально установленные приложения IMS и логические блоки для осуществления связи с IG 20, не могут использовать преимущества большого количества доступных услуг IMS, которые в настоящее время являются доступными в системах IPTV или будут созданы в будущем. Телевизионная приставка 50 также испытывает недостаток в необходимых функциональных средствах для связи с IG 20 с целью запроса, установки и управления сеансами связи IPTV и IMS.
Раскрытые в настоящем описании варианты осуществления заменяют традиционные собственные и внедренные приложения IMS приложением IMS, основанным на сценарии и основанным на браузере. Такие приложения, основанные на сценарии, которые должны быть запущены в среде web-браузера, иногда обозначаются web-приложениями в данной области техники и, в частности, приложениями среды декларативного приложения (DAE) в области IPTV. В четком контрасте по отношению к внедренному приложению IMS к приложению IMS, основанному на сценарии, получают доступ с помощью web-браузера по сети, такой как Интернет или интранет. В целом, приложение, основанное на сценарии, является программным приложением, закодированным на 5 поддерживаемых браузером языках. Приложение, основанное на браузере, полагается на web-браузер для того, чтобы визуализировать выполняемое приложение.
Фиг. 3 является соответствующим кратким обзором телевизионной приставки 50 с системой внедренной OITF и приложением 40 IMS, основанным на сценарии, согласно варианту осуществления. В этом варианте осуществления сигнализация HNI-IGI с IG 20 для телевизионной приставки 50 и системы внедренной OITF осуществляется через приложение IMS, основанное на браузере, выполняемое в странице браузера.
Приложение 40 IMS, основанное на браузере, обеспечивается в среде DAE, то есть выполняется браузером, и предпочтительно использует интерфейс HTTP для IG 20. Это означает, что приложение 40 IMS, основанное на браузере, может использовать стандартизированный интерфейс, основанный на HTTP, то есть HNI-IGI для осуществления сигнализации с IG 20 от имени телевизионной приставки 50.
Как можно видеть посредством сравнения Фиг. 2 и 3, необходимая сигнализация HNI-IGI между системой внедренной OITF и IG 20 теперь управляется приложением IMS, основанным на сценарии, вместо того, чтобы осуществляться между различными функциональными средствами в системе внедренной OITF и IG 20, как в предшествующем уровне техники. Это означает, что в четком контрасте по отношению к предшествующему уровню техники на Фиг. 2 телевизионная приставка 50 согласно Фиг. 3 не должна иметь предварительно установленного внедренного или собственного приложения IMS и стека протоколов IMS. Следовательно, приложение 40 IMS, основанное на сценарии, работает как шлюз между системой и функциями внедренной OITF и внедренными приложениями, которые используются для обработки данных IMS, таких как устройство воспроизведения или устройства воспроизведения AV и IG 20.
В целом, функциональные средства сигнализации IMS, таким образом, перемещаются от собственного или внедренного кода или структур телевизионной приставки 50 к приложению 40 IMS, основанному на сценарии. Это означает, что функциональные средства для обнаружения услуг, подписки и регистрации преимущественно обеспечиваются в IG 20 вместо системы внедренной OITF. Однако это не является намерением вариантов осуществления ограничить то, где эти функции выполняются. В целом, все или только некоторые из них могут быть выполнены в IG 20. Это дополнительно более подробно описано в настоящем описании.
Фиг. 4A и 4B являются схематическими диаграммами сигнализации, иллюстрирующими вариант осуществления инициации OITF с целью активации телевизионной приставки таким образом, чтобы она была готова установить сеанс связи IPTV или IMS, если это желательно. На чертежах "OITF" представляет систему внедренной OITF, которая в целом обеспечивается как внедренный или собственный код и функции, обычно обеспеченные как компьютерный программный продукт, непосредственно загружаемый во внутреннюю память компьютера или блок обработки и содержащий части кода программного обеспечения для выполнения необходимых функций. Компьютер должен быть широко интерпретирован, чтобы включать в себя любое устройство или терминал, или стационарный, или портативный, содержащий функциональные средства внедренной OITF, как описано в настоящем описании. Такой компьютер может быть любым из ранее упомянутых примеров телевизионной приставки. Приложение "DAE-IMS" представляет приложение IMS, основанное на сценарии, выполняемое в web-браузере, то есть DAE, в телевизионной приставке. В обычном варианте осуществления система внедренной OITF и приложение IMS, основанное на сценарии, представлены в одном и том же физическом устройстве, но могут быть альтернативно размещены в различных устройствах, имеющих проводное или беспроводное соединение между устройствами. AS IPTV обозначает сервер приложения IPTV, который соответствует провайдеру IPTV (услуг) согласно Фиг. 1.
В целом, процедура инициации начинается посредством запуска системы внедренной OITF, если это уже не сделано. Это производится согласно процедурам предшествующего уровня техники. Соответственно, IG осуществляет обеспечение пользовательских идентификаторов и запуск, например, используя протокол динамического выбора конфигурации хост-машины (DHCP), который является протоколом приложения сети, используемым для получения информации конфигурации для работы в сети IP. Это особенно является предпочтительным, если IG может реализовывать опции DHCP 124 и 125, относящиеся к извлечению информации обнаружения услуг.
Как только система внедренной OITF была запущена, она предпочтительно автоматически выполняет запрос запуска, который является внутренним вызовом для направления приложения IMS, основанного на сценарии, или, более корректно, web-браузера на некоторый адрес, такой как http://IG.fixed.local, IG. IG предпочтительно также имеет фиксированное, полностью определенное доменное имя (FQDN), иногда называемое абсолютным доменным именем. FQDN является доменным именем, которое задает свое точное местоположение в дереве иерархии системы доменных имен (DNS). Это фиксированное FQDN указывает на IG таким образом, чтобы IG действовал как сервер DNS непосредственно, чтобы указать это FQDN на себя. FQDN предпочтительно фиксируется, подразумевая, что оно может быть закодировано или сохранено в коде или структуре системы внедренной OITF без необходимости для IG информировать систему внедренной OITF FQDN каждый раз, когда производится процедура инициирования. Альтернативно, затем система внедренной OITF должна запросить это FQDN от IG, используя приложение IMS, основанное на сценарии, или от некоторого другого блока.
Вышеупомянутый, описанный способ маршрутизации сообщений к IG имеет дополнительное значение, что, если не существует IG, то провайдер сети доступа, который отвечает за сервер DNS, может решить FQDN IG и указать это серверу сети. Этот сервер сети может, например, отображать коммерческую информацию того, как абонент может подписаться на услугу IPTV.
На основании принятого запроса запуска IG обеспечивает страницу пользовательского выбора, которая возвращается в приложение IMS, основанное на сценарии, для отображения пользователю. Эта страница пользовательского выбора может быть предварительно установлена в IG, или IG генерирует ее по требованию на основании приема запроса запуска. Страница пользовательского выбора содержит по меньшей мере один пользовательский идентификатор доступных пользователей, которые могут использовать телевизионную приставку, в которой обеспечивается система внедренной OITF. Пользовательский идентификатор(ы) может быть любым идентификатором(ами) или информацией, разрешающей идентификацию пользователя(ей). Неограничивающие примеры включают в себя имя пользователя, заданное имя и, необязательно, фамилию, пользовательский идентификатор, генерируемый компьютером, выбранный посредством IMS, и т.д.
Затем приложение IMS, основанное на сценарии, представляет принятую страницу пользовательского выбора посредством web-браузера на экране отображения телевизионной приставки или экране, соединенном с телевизионной приставкой. Затем пользователь может выбирать среди различных пользователей, которые обеспечены в IG. Например, семья, состоящая из отца, матери и двух детей, может иметь пять различных обеспеченных пользователей, включая пользовательский профиль по умолчанию, который не является персонифицированным. Пользователь кликает или, иначе, выбирает конкретный пользовательский идентификатор или имя, которое он или она хочет использовать. Активация пользовательского ввода, такого как кнопка мыши, чувствительный к касанию экран или клавиатура, генерирует команду пользовательского выбора, содержащую пользовательский идентификатор, ассоциированный с выбранным пользователем. Необязательно, инициируется процедура аутентификации, в которой пользователь вынужден ввести пароль или PIN код, чтобы получить доступ к выбранному пользовательскому профилю. Эта процедура аутентификации может быть произведена посредством генерирования и передачи сообщения HTTP: 401 UNATHORIZED (НЕАВТОРИЗОВАН) к приложению IMS, основанному на сценарии, вынуждая пользователя вводить пароль или PIN код, который возвращается в IG.
Как только выбранный пользователь был уведомлен для IG, запрос регистрации, относящийся к выбранному пользователю, составляется посредством IG. Запрос регистрации предпочтительно является сообщением SIP: REGISTER (РЕГИСТРАЦИЯ), содержащим пользовательский идентификатор выбранного пользователя. IG передает этот запрос регистрации на IMS. IMS возвращает сообщение подтверждения в форме SIP: 200 ОК. Эта сигнализация производится так, как в предшествующем уровне техники, но с существенным отличием. Она является IG, который производит пользовательскую регистрацию для IMS вместо системы внедренной OITF, как в предшествующем уровне техники.
Соответственно, выполняется процедура подписки, включающая генерирование и передачу посредством IG запроса подписки обычно в форме сообщения SIP: SUBSCRIBE (ПОДПИСКА), сопровождаемого возвратом подтверждения SIP: 200 ОК от AS IPTV. AS IPTV также передает сообщение SIP: NOTIFY, относящееся к обнаружению и выбору услуг (SD&S), на которое отвечает IG посредством передачи SIP: 200 ОК. Новый признак в настоящем описании заключается в том, что IG, а не система внедренной OITF, вовлекается в подписку и связь SD&S с AS IPTV.
Затем IG создает web-страницу, содержащую информацию услуг IPTV, включающую в себя услуги IMS, доступные для подписанного и зарегистрированного пользователя и уведомленные от провайдера услуг, то есть AS IPTV, через уведомление SD&S. IG дополнительно транслирует или преобразует информацию адреса, принятую в ответ на запрос подписки, в преобразованную информацию адреса, указывающую на IG. Например, IG преимущественно отображает каждый унифицированный указатель ресурса (URL), принятый от IPTV, чтобы вместо этого указать на IG. Это может быть произведено посредством отображения каждого уведомленного URL на локальный URL в IG или фактически посредством переименования URL.
IG может необязательно также ассоциировать выбор услуг IPTV от AS IPTV с реальным провайдером IPTV для обработки безопасности на транспортном уровне (TLS) и аутентификации в качестве прокси-сервера.
Преимущество создания и обеспечения страницы выбора провайдера услуг в IG заключается в том, что IG может добавлять выборы услуг IPTV не только от единственного провайдера услуг IPTV или AS IPTV, но и фактически от различных провайдеров услуг IPTV. Например, IG может быть установлен или соединен с традиционным ADSL-модемом. В таком случае IG может фактически связываться не только с AS IPTV, но также и, например, с провайдером кабельного телевидения, который может предоставлять медиауслуги пользователю в сеансе связи IPTV. Это означает, что IG может собирать информацию услуг, доступных от множественных различных провайдеров услуг, включающих в себя различные технологии, и скомпоновать эту информацию в единственную страницу презентации, которая отображается пользователю, используя его/ее web-браузер.
Созданная страница выбора провайдера услуг передается на приложение IMS, основанное на сценарии, которая должна быть отображена пользователю в web-браузере на экране отображения телевизионной приставки или подсоединенном с телевизионной приставкой. Отображенная web-страница представляет список выборов услуг IPTV, предоставленных посредством AS IPTV, на основании процедуры SD&S. Необязательно, TLS и/или аутентификация может также быть выполнена. Отображенная web-страница представляет список различных идентификаторов провайдеров услуг, имен или информацию, которая разрешает пользователю идентифицировать и выбирать среди доступных провайдеров услуг. Эти идентификаторы провайдеров услуг могут быть преобразованной информацией адреса, генерируемой посредством IG, или другой информацией или данными, выданными в странице выбора провайдеров услуг и выданными посредством IG на основании данных, принятых в процедуре SD&S.
Преимущество этого варианта осуществления заключается в том, что IG может представлять провайдеров услуг и информацию выбора, которая не имеет характер IPTV. Данные не-IPTV могут быть, например, кабельными, цифровыми наземными или спутниковыми TV данными. Когда пользователь телевизионной приставки выбирает эти услуги, они преобразуются из своей первоначальной природы в формат IPTV для выполнения услуг в стандартном терминале IPTV и в сеансе связи IPTV.
Затем пользователь выбирает одного из провайдеров услуг посредством активации пользовательского ввода самой телевизионной приставки или соединенного с телевизионной приставкой. Активация пользовательского ввода инициирует приложение IMS, основанное на сценарии, генерировать команду провайдера услуг, содержащую идентификатор провайдера выбранного провайдера услуг. В предпочтительном варианте осуществления команда провайдера услуг генерируется приложением IMS, основанным на сценарии, на основании преобразованных или переписанных указателей URL, обеспеченных страницей выбора провайдера услуг. Поскольку эти преобразованные указатели URL указывают назад на IG, а не на первоначальный сервер приложения IPTV, команда провайдера услуг будет предназначена для IG.
IG возвращает данные, относящиеся к выбранному провайдеру услуг, в форме сообщения выбора услуг. Сообщение выбора услуг предпочтительно содержит информацию адреса услуг IPTV, доступных в выбранном провайдере услуг. Сообщение выбора услуг передается на приложение IMS, основанное на сценарии, которое генерирует и отправляет команду загрузки описания услуг в систему внедренной OITF. Эта команда загрузки описания услуг включает в себя, например, URL провайдера услуг и информацию о типе. Система внедренной OITF предпочтительно возвращает сообщение подтверждения или ОК. Система внедренной OITF также выполняет запрос HTTP для получения данных обнаружения от AS IPTV. Эти данные обнаружения могут быть, например, в форме электронного программного гида (EPG) - представляющего список контента и медиа IPTV, доступных от провайдера услуг, разрешающего пользователю осуществлять навигацию, выбирать и обнаруживать медиа контент, например, с помощью времени, имени, канала, жанра и т.д. Также могут быть использованы другие типы описательной информации, информирующей пользователя о доступных услугах IPTV в AS IPTV. AS IPTV возвращает подтверждение с помощью данных обнаружения, например, в форме сообщения HTTP: 200 ОК.
Альтернативно, если IG добавил другого провайдера услуг к странице выбора провайдеров услуг, такого как дистрибьютор контента кабельного TV или цифрового видеовещания (DVB), HTTP получает данные обнаружения, которые передаются на IG, поскольку IG затем указывает обнаружение для себя. Затем IG вернет подтверждение с помощью данных обнаружения в систему внедренной OITF.
В варианте осуществления приложение IMS, основанное на сценарии, генерирует и передает портальное сообщение связи на IG, чтобы загрузить портальную страницу, то есть данные провайдера услуг, обеспеченную в команде провайдера услуг, посланной в IG. IG уполномочивает этот запрос и может преобразовать портальное сообщение HTTP в портальную связь безопасности HTTP (HTTP (S)), которая посылается на AS IPTV. Необязательная обычная архитектура самонастройки (GBA) может быть использована для обеспечения механизма безопасности. Затем AS IPTV возвращает сообщение HTTP (S): 401 UNAUTHORIZED (НЕАВТОРИЗОВАН) на IG, сопровождаемое возвратом информации о полномочиях, если используются механизмы безопасности GBA. AS IPTV также подтверждает прием портальной связи HTTP(S) посредством подтверждения ответа, HTTP(S): 200 ОК на IG. Это подтверждение отправляется к приложению IMS, основанному на сценарии посредством IG для уведомления, что процедура инициации была успешна.
Приложение IMS, основанное на сценарии, предпочтительно возвращает, так называемую, команду ожидания, например, в форме сообщения HNI-IGI PENDING_IG, которое является текущим запросом HTTP. Этот запрос позволяет IG отвечать, когда он должен связаться с системой внедренной OITF как результат входящего запроса от сети, например, AS IPTV.
Вышеупомянутая описанная процедура сигнала, которая иллюстрирована на Фиг. 4A и 4B, может быть проведена без использования универсальной технологии "включай и работай" (UPnP). UPnP является набором компьютерных протоколов, которые позволяют устройствам легко соединяться, и упрощает реализацию домашних сетей для совместного использования данных, связи и развлечения. Если устройства, то есть телевизионная приставка, и устройство, реализующее IG, способны связываться друг с другом, используя UPnP, может быть использована несколько отличная процедура инициации, которая проиллюстрирована на Фиг. 5A и 5B.
Процедура начинается с запуска системы внедренной OITF и обеспечения и запуска IG, как указано на Фиг. 4A. Следующие пять этапов сигнализации, проиллюстрированных на Фиг. 5A и не представленных на Фиг. 4A, относятся к сигнализации UPnP. Таким образом, в этом варианте осуществления производится другая процедура самонастройки. Принимая во внимание, что вариант осуществления на Фиг. 4A основан на фиксированном FQDN IG, Фиг. 5A использует UPnP. Поэтому система внедренной OITF компилирует и передает запрос поиска UPnP, который является частью протокола обнаружения UPnP. IG возвращает сообщение ответа, содержащее несколько существенных специфических особенностей об IG и, в частности, URL или указатель на большее количество подробной информации о IG.
После того, как система внедренной OITF обнаружила IG, она все еще совсем немного знает о IG. Чтобы узнать больше о IG и его возможности, или чтобы взаимодействовать с ним, система внедренной OITF извлекает описание IG из URL, обеспеченного в сообщении обнаружения, обычно в форме сообщения HTTP: GET (ПОЛУЧЕНИЕ). IG возвращает запрашиваемый метод, такой как поддерживаемые методы и свой URL (URL IG) в форме ответа HTTP: 200 ОК. Сообщение HTTP GET с информированным URL IG посылается в приложение IMS, основанное на сценарии, и отправляется на IG.
Следующая процедура, включающая регистрацию, подписку и процедуру SD&S, производится таким же способом, как было рассмотрено выше применительно к Фиг. 4A и 4B.
Затем IG компилирует и представляет скомпилированную страницу выбора провайдера услуг пользователю в web-браузере посредством приложения IMS, основанного на сценарии. Информация выбранного провайдера услуг возвращается на IG в команде провайдера услуг. В этом варианте осуществления IG затем компилирует и передает данные провайдера услуг, такие как в форме сообщения HTTP: REDIRECT (ПЕРЕАДРЕСАЦИЯ) на предлагающую web или предлагающую страницу, обеспеченную на основании SD&S и представленную приложением IMS, основанным на сценарии, на web-браузере. Следующая передача, согласно Фиг. 5B, является аналогичной Фиг. 4B. Механизм безопасности GBA, который является необязательным признаком, был опущен в этом варианте осуществления, проиллюстрированном на Фиг. 5B.
Таким образом, в раскрытых диаграммах сигналов IG будет выполнять управляемую поддержку, такую как процедура регистрации, и не потребуется собственной поддержки HNI-IGI. Данные SD&S, принятые для AS IPTV, анализируются посредством IG и используются для генерирования web-страницы, которая представляется пользователю посредством приложения IMS, основанного на сценарии, и web-браузера телевизионной приставки.
На Фиг. 4A-5B провайдер услуг IPTV описывался как единственный объект, то есть AS IPTV. Альтернативно, провайдер услуг IPTV может содержать выделенный (специализированный) контроллер IPTV и приложение IPTV. В таком случае связь SD&S предпочтительно производится между IG и контроллером IPTV, тогда как портальная связь вместо этого выполняется между IG и приложением IPTV.
В альтернативном подходе система внедренной OITF может выполнять обнаружение услуг. В таком случае обнаружение услуг может быть произведено с помощью DHCP и без IMS. Затем IG ответит на DHCP из системы внедренной OITF и представит информацию обнаружения провайдера услуг без IMS. В настоящее время существуют три опции в DHCP-опции 124/125: IP адрес, имя DNS или IMS, - последнее используется для управляемых сетей. Это означает, что в этом варианте осуществления не требуется IMS, но вместо этого могут быть использованы другие варианты для DHCP. Фиг. 4A и 5A иллюстрируют различные варианты осуществления самонастройки. В еще одном варианте осуществления DHCP используется для поиска IG. Такой вариант осуществления работает аналогично варианту осуществления UPnP, за исключением того, что вместо этого используется DHCP.
Фиг. 6 является примером сеанса связи IPTV в форме передачи видеоинформации по требованию (VoD). В четком контрасте по отношению к решениям предшествующего уровня техники связь, основанная на HNI-IGI, иллюстрируемая на Фиг. 6, выполняется между приложением IMS, основанным на сценарии, запускаемым в web-браузере, и IG, по сравнению с Фиг. 3. Решения предшествующего уровня техники имеют предварительно сконфигурированный собственный код в системе внедренной OITF для осуществления такой связи HNI-IGI и поэтому имеют передачу сообщений HNI-IGI между системой внедренной OITF и IG, см. Фиг. 2.
На необязательном этапе IMS, основанная на сценарии, передает сообщение HNI-IGI: REGISTER, содержащее идентификатор релевантного пользователя, если существует потребность изменить пользователя. IG преобразовывает сообщение HNI-IGI в соответствующее сообщение SIP: REGISTER, содержащее пользовательский идентификатор, и передает его на IMS. Если нет потребности изменить зарегистрированного пользователя, эта сигнализация может быть опущена.
Приложение IMS, основанное на сценарии, компилирует запрос HNI-IGI: OPTIONS (ОПЦИИ) для запроса возможностей сервера AS IPTV. Запрос OPTIONS обычно первоначально приходит из сервера сети или из локального приложения IMS, основанного на сценарии. Запрос OPTIONS предпочтительно содержит идентификатор запрошенных данных VoD, например, в форме URL или другой информации адреса. IG принимает сообщения HNI-IGI и обрабатывает их в традиционный запрос SIP: OPTIONS, и заменяет включенный идентификатор идентификатором URL2. Запрос SIP: OPTIONS передается на AS IPTV, который возвращает сообщение ответа, SIP: 200 ОК, содержащее информацию, SDP1, используемую приложением IMS, основанным на сценарии, для инициации сеанса IPTV. Присоединенная информация включает в себя описание сеанса, предпочтительно в формате протокола описания сеанса (SDP). Ответ возвращается на IG, который отображает ответ SIP в соответствующий ответ HNI-IGI и отправляет сообщение на приложение IMS, основанное на сценарии.
Приложение IMS, основанное на сценарии, запрашивает информацию видео и предпочтительно аудиопортов, которые должны быть использованы в сеансе VoD, от системы внедренной OITF с запросом порта. Система внедренной OITF возвращает сообщение ответа с запрашиваемой информацией, то есть по меньшей мере один идентификатор порта релевантных видео и аудиопортов.
Приложение IMS, основанное на сценарии, генерирует и передает сообщение HNI-IGI: INVITE (ПРИГЛАШЕНИЕ), предпочтительно с предложением SDP, включающим в себя информацию видео и аудиопортов, на которые должны быть посланы медиаданные. Это сообщение приглашения представляет запрос сеанса IPTV. IG обрабатывает сообщение приглашения и преобразует его в сообщение SIP: INVITE, которое посылается на AS IPTV. Сообщение ответа SIP: 200 ОК, содержащее предпочтительный ответ SDP, включающий в себя информацию адреса (URL2) запрашиваемых медиа, возвращается на IG. IG преобразовывает сообщение ответа в ответ HNI-IGI: 200 ОК до передачи на приложение IMS, основанное на сценарии.
Приложение IMS, основанное на сценарии, теперь имеет доступ к информации адреса, ассоциированной с медиаданными, как приняты из ответа HNI-IGI: 200 ОК. Поэтому приложение IMS, основанное на сценарии, предпочтительно генерирует запрос воспроизведения с информацией адреса, то есть URL2, и посылает его в систему внедренной OITF, чтобы вынудить ее запросить желаемый медиа поток, то есть медиапоток VoD, от медиасервера (MS). Этот запрос воспроизведения предпочтительно включает в себя индикацию, что никакая процедура установки не должна быть выполнена системой внедренной OITF, так как приложение IMS, основанное на сценарии, уже произвело такую процедуру установки с помощью IG и AS IPTV.
Запрос медиа в форме запроса воспроизведения (PLAY) протокола потоковой передачи в режиме реального времени (RTSP) затем составляется и передается посредством системы внедренной OITF на медиасервер, определенный посредством URL2. Медиасервер возвращает запрашиваемый одноадресный поток данных VoD в систему внедренной OITF, где данные декодируются и визуализируются для отображения видео на включенном или соединенном экране отображения и для воспроизведения аудио на включенном или приложенном громкоговорителе.
Если пользователь выбирает остановить сеанс VoD, он или она активизирует функцию остановки на web-странице, представленной на web-браузере посредством приложения IMS, основанного на сценарии, вызывая генерирование сообщения остановки, которое отправляется в систему внедренной OITF для остановки воспроизведения медиаданных. Запрос о завершении сеанса связи в форме сообщения HNI-IGI: BYE (ЗАВЕРШЕНИЕ) также составляется и посылается на IG, которое преобразует его в сообщение SIP: BYE, которое посылается на IPTV для завершения сеанса связи и остановки доставки медиаданных. Ответ SIP: 200 ОК возвращается на IG и транслируется в сообщение HNI-IGI: 200 ОК, которое отправляется на приложение IMS, основанное на сценарии, для указания, что сеанс связи был завершен.
Приложение IMS, основанное на сценарии, запущенное в web-браузере, таким образом, выполняет всю сигнализацию HNI-IGI с помощью IG в четком контрасте по отношению к предшествующему уровню техники. Оно также осуществляет предварительную установку порта для отправки этой информации на AS IPTV с помощью IG. Сценарий также генерирует индикацию сигнализации RTSP с предпочтительной индикацией, что процедура RTSP: SETUP (УСТАНОВКА) не должна быть инициирована системой внедренной OITF.
Фиг. 7 является диаграммой сигналов, иллюстрирующей другой вариант осуществления установки и управления сеансом IPTV. В этом примере иллюстрируется, так называемый, запланированный сеанс связи контента. Запланированный контент относится к тому, что план воспроизведения фиксируется объектом, отличным от пользователя, и этот контент поставляется пользователю для непосредственного потребления. Это может быть в форме обеспечения различных TV или медиаканалов пользователям. Многоадресное вещание обычно используется для доставки запланированных услуг контента на IPTV, но, как было упомянуто выше, источник не ограничивается IPTV, но вместо этого может быть провайдерами услуг не-IPTV, такими как кабельное, цифровое наземное или спутниковое TV, в котором IG вошел на страницу выбора провайдера услуг, как рассмотрено выше применительно к Фиг. 4B.
Процедура начинается с необязательной процедуры пользовательской регистрации, в случае необходимости.
В этом примере доступные медиаканалы заранее известны посредством приложения IMS, основанного на сценарии, или через уведомление посредством IG, сеть, то есть через AS IPTV, или локальный интерфейс DAE. Приложение IMS, основанное на сценарии, компилирует и передает сообщение HNI-IGI: INVITE с предпочтительным предложением SDP на IG, который преобразует его в соответствующее сообщение SIP: INVITE, предназначенное для AS IPTV. AS IPTV генерирует, на основании принятого сообщения, ответ SIP: 200 ОК с предпочтительным ответом SDP. Этот ответ обрабатывается в соответствующий ответ HNI-IGI посредством IG и посылается на приложение IMS, основанное на сценарии.
Сообщение описания сеанса связи, принятое от IG, используется приложением IMS, основанным на сценарии, для выдачи информации адреса, ассоциированной с медиаданными, от медиа источника. В этом варианте осуществления релевантная информация адреса является желаемым медиаканалом, предпочтительно в форме адреса интернет-протокола управления группой (IGMP) медиаканала. Релевантный адрес медиаканала связывается с системой внедренной OITF с помощью установленной команды канала. Система внедренной OITF использует эту информацию для компиляции и передачи медиа запроса, представленного в настоящем описании посредством запроса IGMP: JOIN (ПРИСОЕДИНЕНИЕ) для источника многоадресной передачи, то есть медиасервера. Таким образом, телевизионная приставка, содержащая систему внедренной OITF, подсоединяется к многоадресной передаче или каналу телевизионного вещания и начинает принимать медиаданные потока многоадресной передачи. Эти принятые данные декодируются и затем воспроизводятся для отображения и воспроизведения пользователю. Если пользователь хочет изменить канал в течение медиасеанса, пользователь просто выбирает на web-странице, представленной в web-браузере, посредством приложения IMS, основанного на сценарии, один из других доступных медиаканалов. Затем приложение IMS, основанное на сценарии, компилирует и передает новую установленную команду канала в систему внедренной OITF, содержащую адрес IGMP нового медиаканала. Объединенное сообщение IGMP: LEAVE/JOIN (ВЫХОД/ПРИСОЕДИНЕНИЕ) или отдельные сообщения IGMP: LEAVE и IGMP: JOIN затем компилируются и посылаются на источник многоадресной передачи, чтобы вынуждать источник остановить поставку медиаданных старого канала и вместо этого начать поставку медиаданных нового канала.
Если пользователь затем хочет остановить медиасеанс, он или она активирует функцию остановки на web-странице, вызывающей генерирование и передачу сообщения HNI-IGI: BYE, как описано выше на Фиг. 6. Приложение IMS, основанное на сценарии, также указывает системе внедренной OITF завершить сеанс посредством сообщения освобождения.
В вышеупомянутом описанном варианте осуществления медиаканал устанавливается на основании адреса IGMP. В таком случае необходимые данные и параметры могут быть извлечены из записи обнаружения вещания (Broadcast Discovery Record). Это может быть выполнено посредством чтения XML-документа посредством приложения IMS, основанного на сценарии.
Фиг. 8 иллюстрирует альтернативный подход, где запись обнаружения вещания включается в систему внедренной OITF. Затем приложение IMS, основанное на сценарии, запрашивает данные SDP и, в частности, адрес IGMP, который должен быть использован в HNI-IGI: INVITE от системы внедренной OITF или кода. Это означает, что желаемый адрес IGMP выбранного медиаканала запрашивается на основании включенного идентификатора медиаканала. Этот идентификатор выдается приложению IMS, основанному на сценарии, из процедуры установки, как рассмотрено выше применительно к Фиг. 4A-5B. Система внедренной OITF возвращает SDP с запрашиваемой информацией.
Приложение IMS, основанное на сценарии, может необязательно также запросить от системы внедренной OITF информацию характеристик полосы частот желаемого канала. Система внедренной OITF предпочтительно возвращает такую информацию полосы частот, как максимальная скорость передачи битов (MBR) и целевая скорость передачи данных (TTR).
Затем оставшейся процедурой является то же самое, как рассмотрено выше применительно к Фиг. 7, за исключением того, что, если изменение канала инициируется пользователем, новый необязательный запрос информации полосы предпочтительно компилируется посредством приложения IMS, основанного на сценарии, и передается в систему внедренной OITF. Вышеупомянутые описанные варианты осуществления, раскрытые в диаграммах сигналов на Фиг. 4-8, должны быть рассмотрены как иллюстративные примеры, и варианты осуществления этим не ограничиваются. Например, типы сообщения и протоколы сигнализации, описанные выше, основаны на текущей стандартной ситуации. В данной области техники существует непрерывное развитие, относящееся к стандартам. Таким образом, также другие типы передачи сообщений и стандартные протоколы, которые могут быть использованы для достижения желаемых эффектов, описанных ранее, вместо этого могут быть использованы и в рамках вариантов осуществления.
Таким образом, в общем варианте осуществления установления сеанса IPTV способ включает запуск приложения IMS, основанного на сценарии, в web-браузере, реализованном в телевизионной приставке. Приложение IMS, основанное на сценарии, генерирует установленные сигналы сеанса IPTV, основанные на активации пользовательского ввода телевизионной приставки или соединенного с телевизионной приставкой. Установленные сигналы сеанса передаются к IG, соединенному с телевизионной приставкой, присутствующей в домашней сети. Приложение IMS, основанное на сценарии, дополнительно принимает от IG информацию адреса, ассоциированную с медиаданными, доступными от медиасервера в глобальной сети, соединенной с домашней сетью. Эта информация адреса отправляется от приложения IMS, основанного на сценарии, в систему внедренной OITF телевизионной приставки, чтобы, таким образом, вызвать генерирование в сеансе IPTV запроса медиа для медиаданных и предназначенных для медиасервера.
В конкретном варианте осуществления приложение IMS, основанное на сценарии, принимает запрос запуска от системы внедренной OITF, как проиллюстрировано на Фиг. 4A, и отправляет этот запрос запуска на IG, чтобы, таким образом, вызвать генерирование страницы пользовательского выбора. Затем способ дополнительно содержит прием в приложении IMS, основанном на сценарии, страницы пользовательского выбора, содержащей по меньшей мере один пользовательский идентификатор доступных пользователей. Приложение IMS, основанное на сценарии, представляет страницу пользовательского выбора посредством web-браузера на экране отображения и передает на IG команду пользовательского выбора, содержащую пользовательский идентификатор выбранного пользователя и сгенерированную на основании активации пользовательского ввода телевизионной приставки.
Способ предпочтительно также содержит прием в приложении IMS, основанном на сценарии, и от IG, страницы выбора провайдера услуг, содержащей соответствующие идентификаторы провайдера, ассоциированные с провайдерами услуг, доступными для пользователя из глобальной сети. Однако эти идентификаторы провайдера созданы посредством IG для указания на IG вместо провайдеров услуг. Приложение IMS, основанное на сценарии, передает команду провайдера услуг, содержащую идентификатор провайдера выбранного провайдера услуг. Эта команда провайдера услуг генерируется на основании активации пользовательского ввода телевизионной приставки и передается на IG.
Способ предпочтительно дополнительно содержит прием в приложении IMS, основанном на сценарии, и от IG, сообщения выбора услуг, содержащего информацию адреса услуг IPTV, доступных в выбранном провайдере услуг. Приложение IMS, основанное на сценарии, компилирует и передает команду загрузки описания услуг, содержащую информацию адреса, в систему внедренной OITF.
Дополнительно предпочтительный этап способа включает в себя передачу ожидающей команды, содержащей ожидающий запрос HTTP от приложения IMS, основанного на сценарии, на IG, чтобы позволить IG направлять любые входящие запросы из глобальной сети в систему внедренной OITF.
Если конкретный сеанс связи IPTV включает медиа по требованию, такие как VoD, способ дополнительно содержит передачу запроса порта от приложения IMS, основанного на сценарии, в систему внедренной OITF и передачу сообщения приглашения, содержащего идентификатор порта по меньшей мере одного медиапорта телевизионной приставки, выбранному провайдеру услуг, где это сообщение приглашения было сгенерировано приложением IMS, основанным на сценарии, на основании сообщения ответа, содержащего по меньшей мере один идентификатор порта от системы внедренной OITF.
В этом случае отправление информации адреса посредством приложения IMS, основанного на сценарии, включает передачу в систему внедренной OITF запроса воспроизведения, содержащего информацию адреса, ассоциированную с запрошенными медиаданными, доступными в медиасервере. Запрос воспроизведения дополнительно содержит индикацию, что сеанс IPTV был уже установлен посредством приложения IMS, основанного на сценарии, и, следовательно, процедура установки не должна быть выполнена системой внедренной OITF.
В альтернативном варианте осуществления, направленном на сеанс IPTV, включающий запланированный контент в качестве иллюстративного примера типа медиаданных, приложение IMS, основанное на сценарии, принимает сообщение описания сеанса от IG и содержащее информацию адреса в форме информации канала многоадресной передачи или вещания. Затем отправление информации адреса в систему внедренной OITF включает передачу информации канала многоадресной передачи или вещания, чтобы инициировать систему внедренной OITF присоединиться к медиаканалу многоадресной передачи или вещания.
Этапы операции, производимые посредством IG обычным способом установки сеанса IPTV, включают передачу запроса регистрации, содержащего пользовательский идентификатор пользователя телевизионной приставки, на IMS. IG также передает запрос подписки, предназначенный провайдеру услуг IPTV, и принимает информацию адреса в ответе на него, где информация адреса относится к услугам IPTV, доступным для пользователя от глобальной сети. IG отображает информацию адреса для преобразованной информации адреса, ассоциированной с услугами, но указывающей на IG. Это означает, что генерирование и передача запроса услуг на основании преобразованной информации адреса, направят запрос услуг на IG, а не провайдеру услуг IPTV. Преобразованная информация адреса компилируется в web-страницу, которая передается посредством IG на приложение IMS, основанное на сценарии, запущенное в web-браузере в телевизионной приставке.
В конкретном варианте осуществления IG также добавляет вспомогательную информацию адреса, ассоциированную с по меньшей мере, так называемым, одним вспомогательным провайдером услуг, к информации адреса от провайдера услуг IPTV. Это позволяет IG представлять дополнительные услуги пользователю, которые могут быть выбраны и запущены в пределах текущего сеанса IPTV, как описано ранее. Вспомогательная информация адреса преобразуется или отображается в преобразованную вспомогательную информацию адреса, ассоциированную со вспомогательным провайдером(ами) услуг, но указывающую на IG. Затем преобразованная вспомогательная информация адреса объединяется с преобразованной информацией адреса при генерировании web-страницы, которая должна быть передана на приложение IMS, основанное на сценарии.
В конкретном варианте осуществления способ дополнительно включает IG, генерирующий web-страницу, содержащую пользовательские идентификаторы множественных пользователей, потенциально доступных для телевизионной приставки, в ответ на запрос пользовательского выбора от телевизионной приставки. Затем IG возвращает web-страницу, содержащую пользовательские идентификаторы, для отображения посредством приложения IMS, основанного на сценарии, используя web-браузер.
Кроме того, как только IG примет ожидающую команду, содержащую ожидающий запрос HTTP от телевизионной приставки, как описано ранее, IG передаст любые входящие запросы от глобальной сети в систему внедренной OITF телевизионной приставки.
Фиг. 9 является схематической блок-схемой приложения 40 IMS, сконфигурированного для того, чтобы быть реализованным в телевизионной приставке в домашней сети. Приложение 40 IMS является приложением 40 IMS, основанным на сценарии, сконфигурированным для управления web-браузером, реализованным в телевизионной приставке. Приложение 40 IMS, основанное на сценарии, в целом является приложением программного обеспечения, закодированным на языке, поддерживаемом браузером, таком как JavaScript, Java, ECMAscript, Flash, ActiveX и т.д. Приложение 40 IMS, основанное на сценарии, зависит от web-браузера для воспроизведения выполняемого приложения. В конкретном варианте осуществления приложение 40 IMS, основанное на сценарии, может быть обеспечено в JavaScript (JS) в странице браузера через XMLHttpRequest из загруженной страницы HTML/JS. Асинхронный JavaScript и XML (AJAX) могут быть использованы для достижения необходимых функциональных средств IMS, основанных на сценарии, через XMLHttpRequest. AJAX является способом развития сети, используемым для создания интерактивных web-приложений или интернет-приложений с богатыми возможностями. Посредством использования AJAX, web-приложения, включающие в себя приложение 40 IMS, основанное на сценарии, могут асинхронно извлекать данные из сервера в фоновом режиме, не сталкиваясь с отображением и поведением существующей страницы. Данные извлекаются, используя объект XMLHttpRequest, где XMLHttpRequest является интерфейсом прикладного программирования (API), который может быть использован в языке сценариев web-браузера, таком как JavaScript, чтобы послать запрос HTTP непосредственно на сервер сети, такой как IG, и загрузить данные ответа сервера непосредственно назад в язык сценариев.
В конкретном варианте осуществления приложение 40 IMS, основанное на сценарии, содержит функциональные средства генератора 42 сигналов, сконфигурированного для генерирования сигналов сеанса IPTV, которые предназначаются для IG для установки и управления сеансом IPTV. Генератор 42 сигналов предпочтительно сконфигурирован для выполнения такой сигнализации сеанса IPTV, используя протокол сигнала HTTP и, в частности, протокол сигнала HNI-IGI, основанный на HTTP, определенный для сеансов IPTV.
Приложение 40 IMS, основанное на сценарии, также содержит функциональные средства провайдера 44 адреса, сконфигурированного для выдачи информации адреса в систему внедренной OITF в телевизионной приставке. Эта информация адреса ассоциируется с запрошенными медиаданными, доступными от медиасервера в глобальной сети, и принятой от IG.
Фиг. 10 является схематической блок-схемой варианта осуществления телевизионной приставки 50 или другого пользовательского оборудования, терминала или устройства, подходящего для компоновки и работы в домашней сети. Телевизионная приставка 50 содержит блок или функциональные средства для связи с другими устройствами, в частности, с IG. Этот блок представлен как интерфейс 52 связи на чертеже, который служит как общий блок ввода и вывода (I/O). Практически, интерфейс 52 связи может быть общим интерфейсом ввода и вывода для проводного соединения с внешними и удаленными устройствами или в форме приемника/передатчика или приемопередатчика для беспроводного соединения.
Телевизионная приставка 50 также содержит приложение 40 IMS, основанное на сценарии, предпочтительно, как определено на Фиг. 9. Приложение 40 IMS, основанное на сценарии, сконфигурировано для управления web-браузером 54, реализованным в телевизионной приставке 50. Этот web-браузер 54 представляет DAE, как раскрыто в настоящем описании, и, в целом, обеспечивается в форме программы программного обеспечения, локально установленной и выполняемой в телевизионной приставке 50. Также решения для аппаратного обеспечения возможны и находятся в рамках вариантов осуществления. Web-браузер 54, в частности, сконфигурирован для генерирования web-страниц, отображаемых на экране отображения телевизионной приставки или соединенном, обычно через интерфейс 52 связи, с телевизионной приставкой 50. Телевизионная приставка 50 также содержит систему 56 внедренной OITF, которая может быть обеспечена в аппаратном обеспечении, программном обеспечении или их комбинации. При реализации программного обеспечения система 56 внедренной OITF содержит элементы компьютерной программы, осуществляющиеся при выполнении на компьютере или другом блоке обработки функции системы 56 внедренной OITF. Эта система 56 внедренной OITF сконфигурирована для генерирования запроса медиа на основании информации адреса, принятой от приложения 40 IMS, основанного на сценарии, и в частности, от провайдера 44 адреса (см. Фиг. 9) приложения 40 IMS, основанного на сценарии. Запрос медиа, генерируемый системой 56 внедренной OITF, предназначается для медиаданных, которые должны быть визуализированы в сеансе IPTV, и предназначается для медиасервера, представленного в глобальной сети.
Интерфейс 52 связи, в частности, сконфигурирован для осуществления связи, основанной на HTTP, с IG и предпочтительно связи HNI-IGI, основанной на HTTP, между приложением 40 IMS, основанным на сценарии, телевизионной приставкой 50 и IG.
Интерфейс 52 связи предпочтительно скомпонован для приема от IG сценария, такого как страница HTTP/JS, которая обеспечивает необходимые функциональные средства для того, чтобы разрешить сеансы IMS и IPTV, такого как приложение 40 IMS, основанное на сценарии. Принятые данные сценария отправляются на web-браузер 54 или приложение DAE, где они реализуются и выполняются в среде браузера, приводя к отображению в web-браузере 54 информации, относящейся к сеансу IPTV, пользователю.
Приложение 40 IMS, основанное на сценарии, обычно сконфигурировано для приема запроса запуска от системы 56 внедренной OITF, как только она становится активированной. Затем приложение 40 IMS, основанное на сценарии, отправляет запрос запуска, такой как фиксированное FQDN, указывающее на IG для инициации в IG генерирования страницы пользовательского выбора. Как только интерфейс 52 связи принимает эту страницу пользовательского выбора от IG, она представляется приложению IMS, основанному на сценарии, для отображения посредством web-браузера 54 на экране отображения телевизионной приставки или подсоединенном с телевизионной приставкой 50. Затем пользователь активирует пользовательский ввод, находящийся в проводном соединении или беспроводным образом соединенный с интерфейсом 52 связи, для указания предназначенных пользователей. Эта активация пользовательского ввода инициирует приложение 40 IMS, основанное на сценарии, генерировать команду пользовательского выбора, содержащую пользовательский идентификатор выбранного пользователя. Эта команда пользовательского выбора передается на IG посредством интерфейса 52 связи.
Приложение 40 IMS, основанное на сценарии, дополнительно предпочтительно принимает страницу выбора провайдера услуг от интерфейса 52 связи и исходящую из IG. Страница выбора провайдера услуг содержит соответствующие идентификаторы провайдера провайдеров услуг, представленных в глобальной сети. Эти идентификаторы провайдера ассоциируются с соответствующими провайдерами услуг, но создаются посредством IG, чтобы вместо этого указать на IG. Страница выбора провайдера услуг отображается пользователю аналогичным образом, что и страница пользовательского выбора. Активация подсоединенного пользовательского ввода инициирует генерирование посредством приложения 40 IMS, основанного на сценарии, команды провайдера услуг, предназначенной для IG и содержащей идентификатор провайдера выбранного провайдера услуг.
Приложение 40 IMS, основанное на сценарии, также предпочтительно принимает сообщение выбора услуг, содержащее информацию адреса услуг IPTV, доступных в выбранном провайдере услуг. Сообщение выбора услуг исходит из IG и используется приложением 40 IMS, основанным на сценарии, для генерирования команды загрузки описания услуг, содержащей релевантную информацию адреса услуг IPTV. Эта команда загрузки описания услуг отправляется в систему 56 внедренной OITF.
Как только сеанс IPTV был установлен, приложение 40 IMS, основанное на сценарии, предпочтительно генерирует и передает ожидающую команду, содержащую ожидающий запрос HTTP, на IG. Затем IG отправит, на основании ожидающего запроса HTTP, любые входящие запросы, исходящие из глобальной сети, в систему 56 внедренной OITF.
Приложение 40 IMS, основанное на сценарии, предпочтительно сконфигурировано для генерирования и передачи в течение непрерывного сеанса IPTV и, в частности, медиасеанса IPTV по требованию, запроса порта в систему 56 внедренной OITF. Система 56 OITF отвечает посредством сообщения ответа, содержащего запрашиваемый идентификатор(ы) порта по меньшей мере одного медиа порта телевизионной приставки 50. Затем приложение (40) IMS, основанное на сценарии, генерирует сообщение приглашения, содержащее идентификатор(ы) порта, которое передается выбранному провайдеру услуг посредством интерфейса 52 связи и IG.
Как только приложение 40 IMS, основанное на сценарии, получило доступ к информации адреса, ассоциированной с медиаданными, доступными от медиасервера, оно в течение медиасеанса IPTV по требованию генерирует и передает запрос воспроизведения в систему 56 внедренной OITF. Запрос воспроизведения содержит информацию адреса и предпочтительно индикацию, что процедура установки не должна быть выполнена сеансом связи 56 внедренной OITF, так как эта процедура установки уже была произведена между приложением (40) IMS, основанным на сценарии, и провайдером услуг IPTV.
В запланированном сеансе IPTV контента или аналогичном сеансе, включающем многоадресную передачу или вещание медиаданных, приложение 40 IMS, основанное на сценарии, сконфигурировано для приема от IG сообщения описания сеанса связи, содержащего информацию адреса медиаданных. В этом случае информация адреса находится в форме информации адреса медиаканала многоадресной передачи или вещания, доступного от медиасервера. Информация адреса передается в систему 56 внедренной OITF, чтобы инициировать систему внедренной 56 OITF присоединиться к медиаканалу многоадресной передачи или вещания. В альтернативном варианте осуществления, хотя в целом менее предпочтительно, приложение 54 web-браузера и система 56 внедренной OITF может быть реализована в различных телевизионных приставках, которые затем проводным или беспроводным образом соединяются друг с другом через интерфейс 52 связи.
Дополнительно, телевизионная приставка 50 может содержать или проводным, или беспроводным образом соединяться с медиа процессором, имеющим функциональные средства для декодирования и визуализации принятого медиа контента. Затем телевизионная приставка или медиа процессор предпочтительно содержит или соединяется с экраном отображения и предпочтительно громкоговорителем для отображения и воспроизведения медиа.
Фиг. 11 является схематическим кратким обзором варианта осуществления IG 20. IG 20 обычно реализуется в домашней сети, как иллюстрировано на Фиг. 1, чтобы, таким образом, связываться в домашней сети с телевизионной приставкой(ми), обеспеченной в ней. Также IG 20 может быть представлен в домашней сети как автономное устройство. Альтернативно, он реализуется вместе со шлюзом Фиг. 1, формирующим функциональные средства прокси-сервера между домашней сетью и глобальной сетью. Такие функциональные средства прокси-сервера могут осуществляться модемом или другим блоком прокси-сервера. Фактически, возможно иметь IG 20, реализованный в одной из телевизионных приставок домашней сети.
В существенно отличном подходе к реализации IG 20 не реализуется в домашней сети, а вместо этого - в глобальной сети, например, при соединении с провайдером доступа или провайдером IPTV, или как отдельный объект сети или сервер глобальной сети. Независимо от того, реализуется ли он в домашней сети или глобальной сети, IG 20 все еще обеспечивает функциональные средства для преобразования (трансляции) между передачами HTTP и SIP, и он способен связываться с IMS и сервером приложения IPTV. При реализации в домашней сети IG 20 завершает сигнализацию HTTP и устанавливает сигнализацию SIP, как будто он является источником. Это скрывает факт, что приложение IMS, основанное на сценарии, находится позади блока трансляции адреса сети (NAT). IG 20, реализованный в сети, работает как прокси-сервер и сохраняет информацию маршрутизации на и от приложения IMS, основанного на сценарии. Затем IMS может заниматься проблемами NAT.
IG 20 содержит блок или функциональные средства для связи с другими устройствами в домашней сети, в частности, с телевизионной приставкой, и также, предпочтительно, необязательно через шлюз, с блоками или серверами в глобальной сети. Этот блок представлен как интерфейс 21 связи, работающий как обычный блок ввода/вывода, на чертеже. Практически, интерфейс 21 связи может быть обычным интерфейсом ввода и вывода для проводного соединения с внешними и удаленными устройствами или в форме приемника/передатчика или приемопередатчика для беспроводного соединения.
IG содержит процессор 22 регистрации, сконфигурированный для генерирования запроса регистрации, содержащего пользовательский идентификатор выбранного пользователя телевизионной приставки. Этот запрос регистрации предназначается для IMS и передается на него посредством интерфейса 21 связи. Процессор 23 подписки сконфигурирован для генерирования запроса подписки, предназначенного выбранному провайдеру услуг IPTV в глобальной сети. Этот запрос подписки позволяет IG 20 принимать информацию адреса провайдера услуг IPTV предпочтительно в форме данных SD&S. Эта информация адреса используется процессором 24 преобразования адреса IG 20 для отображения принятой информации адреса в преобразованную информацию адреса, ассоциированную с провайдером услуг IPTV, но вместо этого указывающей на IG 20. Процессор 25 создания страницы использует преобразованную информацию адреса для генерирования web-страницы, то есть страницы выбора провайдера услуг, которая передается посредством интерфейса связи на телевизионную приставку и приложение IMS, основанное на сценарии, выполняемые там.
В конкретном варианте осуществления процессор 24 преобразования адреса сконфигурирован также для отображения вспомогательной информации адреса, ассоциированной с другими провайдерами услуг, которые имеют медиа услуги, которые потенциально могут управляться и обеспечиваться в сеансе IPTV. Таким образом, процессор 24 преобразования адреса генерирует преобразованную вспомогательную информацию адреса, ассоциированную с таким другим провайдером(ами) услуг, но указывающую на IG 20. Затем процессор 25 создания страницы также использует эту преобразованную вспомогательную информацию адреса при генерировании web-страницы.
Необязательный, но предпочтительный процессор 26 преобразования HTTP-SIP реализуется в IG 20 и конфигурируется для преобразования сообщения, основанного на HTTP, исходящего из телевизионной приставки, включающего в себя сообщение HNI-IGI от приложения IMS, основанного на сценарии, в соответствующее сообщение, основанное на SIP, предназначенное для IMS или провайдера услуг IPTV. Соответственно, процессор 26 преобразования HTTP-SIP сконфигурирован для преобразования входящего сообщения, основанного на SIP, исходящего из глобальной сети, в соответствующее сообщение, основанное на HTTP, предназначенное для телевизионной приставки.
Процессор 25 создания страницы предпочтительно также сконфигурирован для генерирования web-страницы или страницы пользовательского выбора, содержащей пользовательские идентификаторы множественных пользователей, потенциально доступных для телевизионной приставки в ответ на запрос пользовательского выбора, исходящего из телевизионной приставки. В таком случае IG 20 предпочтительно содержит память (не иллюстрирована), содержащую пользовательские идентификаторы ранее зарегистрированных пользователей домашней сети. Затем процессор 25 создания страницы просто извлекает эти сохраненные пользовательские идентификаторы из памяти после приема запроса пользовательского выбора. В альтернативном подходе IG извлекает пользовательские идентификаторы из другого источника, например, IMS. Затем интерфейс 21 связи отправляет запрос пользовательского выбора на IMS вместе с идентификатором домашней сети или IG 20, чтобы позволить IMS идентифицировать ранее зарегистрированных пользователей этой домашней сети или IG 20. Затем пользовательские идентификаторы возвращаются на интерфейс 21 связи и отправляются на процессор 25 создания страницы.
Интерфейс 21 связи предпочтительно сконфигурирован для приема команды ожидания, содержащей запрос ожидания HTTP, от телевизионной приставки. Эта команда ожидания инициирует интерфейс 21 связи передавать любые входящие запросы, исходящие из глобальной сети, например, IMS или сервера приложения IPTV, на телевизионную приставку.
Любые функциональные средства телевизионной приставки или IG, как проиллюстрировано на Фиг. 10 и 11, реализуются в программном обеспечении и затем обеспечиваются как компьютерный программный продукт, непосредственно загружаемый во внутреннюю память в компьютере или блоке обработки телевизионной приставки или IG, и содержащий части кодов программного обеспечения для выполнения необходимых функций. Компьютер должен широко интерпретироваться, чтобы включать в себя любое устройство, сервер, шлюз или терминал, или стационарный, или портативный, содержащий релевантные функциональные средства, как описано в настоящем описании.
Варианты осуществления, описанные выше, должны быть понятны как несколько иллюстративных примеров настоящего изобретения. Специалистам в данной области техники будет понятно, что различные модификации, комбинации и изменения могут быть сделаны для вариантов осуществления, не отступая от объема настоящего изобретения. В частности, различные частные решения в различных вариантах осуществления могут быть объединены в других конфигурациях, где это возможно технически. Однако объем настоящего изобретения определяется приложенной формулой изобретения.
1. Телевизионная приставка (50), имеющая память, в которую загружено приложение (40) IMS, основанное на сценарии, при этом телевизионная приставка содержит:
интерфейс (52) связи, сконфигурированный для разрешения связи со шлюзом (20) мультимедийной подсистемы IP, IMS;
web-браузер (54), сконфигурированный для генерирования web-страницы, отображаемой на экране (60) отображения телевизионной приставки, или соединенной с упомянутой телевизионной приставкой (50);
систему (56) внедренной открытой функции терминала IPTV, OITF, соединенной с упомянутым интерфейсом (52) связи; генератор (42) сигнала, сконфигурированный для генерирования сигналов сеанса телевидения IP, IPTV, предназначенных для упомянутого шлюза (20) IMS для установки и управления сеансом IPTV; и
провайдер (44) адреса, сконфигурированный для выдачи упомянутой системе (56) OITF информации адреса, ассоциированной с медиаданными, доступными от медиасервера (70) в глобальной сети (2), соединенной с упомянутой домашней сетью (1) и принятой от упомянутого шлюза (20) IMS, при этом упомянутая система (56) OITF сконфигурирована для генерирования на основании упомянутой информации адреса запроса медиа упомянутых медиаданных в упомянутом сеансе IPTV и предназначенных упомянутому медиасерверу (70).
2. Телевизионная приставка по п.1, в которой упомянутый интерфейс (52) связи сконфигурирован для осуществления связи, основанной на HTTP, с упомянутым шлюзом IMS (20).
3. Телевизионная приставка по п.1 или 2, дополнительно сконфигурированная для приема запроса запуска от упомянутой системы внедренной OITF (56) и отправки упомянутого запроса запуска на упомянутый шлюз (20) IMS посредством упомянутого интерфейса (52) связи для инициирования генерирования страницы пользовательского выбора.
4. Телевизионная приставка по п.3, дополнительно сконфигурированная для приема упомянутой страницы пользовательского выбора, содержащей по меньшей мере один пользовательский идентификатор доступных пользователей, от упомянутого шлюза (20) IMS, представления упомянутой страницы пользовательского выбора посредством упомянутого web-браузера (54) на упомянутом экране (60) отображения, и для передачи на упомянутый шлюз (20) IMS команды пользовательского выбора, содержащей пользовательский идентификатор выбранного пользователя и сгенерированной на основании активации пользовательского ввода телевизионной приставки или соединенной с упомянутой телевизионной приставкой (50).
5. Телевизионная приставка по п.1, дополнительно сконфигурированная для приема от упомянутого шлюза (20) IMS страницы выбора провайдера услуг, содержащей для каждого доступного провайдера (80) услуг, представленного в упомянутой глобальной сети (2), идентификатора провайдера, ассоциированного с провайдером (80) услуг, но указывающего на упомянутый шлюз (20) IMS, и для передачи на упомянутый шлюз (20) IMS команды провайдера услуг, содержащей идентификатор провайдера выбранного провайдера (80) услуг и сгенерированной на основании активации пользовательского ввода телевизионной приставки или соединенного с упомянутой телевизионной приставкой (50).
6. Телевизионная приставка по п.1, дополнительно сконфигурированная для приема от упомянутого шлюза (20) IMS сообщения выбора услуг, содержащего информацию адреса услуг IPTV, доступных в выбранном провайдере (80) услуг, представленном в упомянутой глобальной сети (2), и для передачи в упомянутую систему (56) внедренной OITF команду загрузки описания услуг, содержащую упомянутую информацию адреса упомянутых услуг IPTV.
7. Телевизионная приставка по п.1, дополнительно сконфигурированная для передачи ожидающей команды, содержащей ожидающий запрос HTTP, на упомянутый шлюз (20) IMS, чтобы позволить упомянутому шлюзу (20) IMS отправить входящий запрос, исходящий из упомянутой глобальной сети (2), в упомянутую систему (56) внедренной OITF.
8. Телевизионная приставка по п.1, дополнительно сконфигурированная для передачи запроса порта в упомянутую систему (56) внедренной OITF для приема от упомянутой системы (56) внедренной OITF сообщения ответа, содержащего идентификатор порта по меньшей мере одного медиапорта упомянутой телевизионной приставки (50), и для передачи выбранному провайдеру (80) услуг в упомянутой глобальной сети (2) и посредством упомянутого шлюза (20) IMS сообщения приглашения, содержащего упомянутый идентификатор порта.
9. Телевизионная приставка по п.1, дополнительно сконфигурированная для передачи в систему (56) внедренной OITF запроса воспроизведения, содержащего упомянутую информацию адреса, ассоциированную с медиаданными, доступными от упомянутого медиасервера (70), и индикацию, что процедура установки не должна быть выполнена упомянутой системой (56) внедренной OITF.
10. Телевизионная приставка по п.1, дополнительно сконфигурированная для приема от упомянутого шлюза (20) IMS сообщения описания сеанса, содержащего упомянутую информацию адреса в форме информации адреса медиа канала многоадресной передачи или вещания, доступного от упомянутого медиасервера (70), и для передачи упомянутой информации адреса в упомянутую систему (56) внедренной OITF для инициации упомянутой системы (56) внедренной OITF присоединиться к упомянутому медиа каналу многоадресной передачи или вещания.
11. Шлюз (20) мультимедийной подсистемы IP, IMS, содержащий:
интерфейс (21) связи, сконфигурированный для разрешения связи с телевизионной приставкой (50), представленной в домашней сети (1), и с серверами (70, 80) в глобальной сети (2), соединенной с упомянутой домашней сетью (1);
процессор (22) регистрации, сконфигурированный для генерирования запроса регистрации, содержащего пользовательский идентификатор пользователя упомянутой телевизионной приставки (50) и предназначенный серверу IMS в упомянутой глобальной сети (2);
процессор (23) подписки, сконфигурированный для генерирования запроса подписки, предназначенного для провайдера (80) услуг телевидения IP, IPTV, представленного в упомянутой глобальной сети (2);
процессор (24) преобразования адреса, сконфигурированный для отображения для каждой услуги IPTV, доступной для упомянутого пользователя из упомянутой глобальной сети (2), информации адреса, принятой в ответ на упомянутый запрос подписки, в преобразованную информацию адреса, указывающую на упомянутый шлюз (20) IMS; и
процессор (25) создания страницы, сконфигурированный для генерирования web-страницы, содержащей упомянутую преобразованную информацию адреса, указывающую на упомянутый шлюз (20) IMS и предназначенную упомянутой телевизионной приставке (50).
12. Шлюз IMS по п.11, в котором упомянутый процессор (24) преобразования адреса сконфигурирован для отображения вспомогательной информации адреса, ассоциированной со вспомогательным провайдером услуг, в преобразованную вспомогательную информацию адреса, указывающую на упомянутый шлюз (20) IMS, и упомянутый процессор (25) создания страницы сконфигурирован для генерирования web-страницы, содержащей упомянутую преобразованную информацию адреса и упомянутую преобразованную вспомогательную информацию адреса.
13. Шлюз IMS по п.11 или 12, дополнительно содержащий процессор (26) преобразования HTTP-SIP, сконфигурированный для преобразования сообщения, основанного на HTTP, исходящего из упомянутой телевизионной приставки (50), в соответствующее сообщение, основанное на SIP, предназначенное для упомянутого сервера IMS или упомянутого провайдера услуг IPTV (80), и для преобразования сообщения, основанного на SIP, исходящего из упомянутого сервера IMS или упомянутого провайдера услуг IPTV (80), в сообщение, основанное на HTTP, предназначенное для упомянутой телевизионной приставки (50).
14. Шлюз IMS по п.11, в котором упомянутый процессор (25) создания страницы сконфигурирован для генерирования web-страницы, содержащей пользовательские идентификаторы множественных пользователей, потенциально доступных для упомянутой телевизионной приставки (50), в ответ на запрос пользовательского выбора, исходящий из упомянутой телевизионной приставки (50), и упомянутый интерфейс связи (21) сконфигурирован для передачи упомянутой web-страницы, содержащей упомянутые пользовательские идентификаторы, к упомянутой телевизионной приставке (50).
15. Шлюз IMS по п.11, в котором упомянутый интерфейс (21) связи сконфигурирован для приема ожидающей команды, содержащей ожидающий запрос HTTP, от упомянутой телевизионной приставки (50), и для передачи, в ответ на упомянутую ожидающую команду, входящего запроса, исходящего из упомянутой глобальной сети (2), на упомянутую телевизионную приставку (50).
16. Шлюз IMS по п.11, в котором упомянутый интерфейс (21) связи сконфигурирован для разрешения связи с телевизионной приставкой (50), сконфигурированной для управления web-браузером (54).
17. Способ установления сеанса телевидения IP, IPTV, в телевизионной приставке, имеющей память, в которую загружено приложение (40) IMS, основанное на сценарии, содержащий этапы:
генерирование установленных сигналов сеанса IPTV на основании активации пользовательского ввода телевизионной приставки, или соединенного с упомянутой телевизионной приставкой (50);
передачи установленных сигналов упомянутого сеанса IPTV на шлюз (20) IMS, соединенный с упомянутой телевизионной приставкой (50), в домашней сети (1);
прием от упомянутого шлюза (20) IMS информации адреса, ассоциированной с медиаданными, доступными от медиасервера (70) в глобальной сети (2), соединенной с упомянутой домашней сетью (1); и
отправку упомянутой информации адреса в систему (56) внедренной открытой функции терминала IPTV, OITF, от упомянутой телевизионной приставки (50) для инициации генерирования в сеансе IPTV медиа запроса упомянутых медиаданных и предназначенных для упомянутого медиасервера (70).
18. Способ по пункту 17, дополнительно содержащий: прием запроса запуска от упомянутой системы (56) внедренной OITF; и отправку упомянутого запроса запуска на упомянутый шлюз (20) IMS для инициации генерирования страницы пользовательского выбора.
19. Способ по пункту 18, дополнительно содержащий:
прием упомянутой страницы пользовательского выбора, содержащей по меньшей мере один пользовательский идентификатор доступных пользователей от упомянутого шлюза (20) IMS;
представление упомянутой страницы пользовательского выбора посредством упомянутого web-браузера (54) на экране (60) отображения телевизионной приставки или соединенном с упомянутой телевизионной приставкой (50); и
передачу на упомянутый шлюз (20) IMS команды пользовательского выбора, содержащей пользовательский идентификатор выбранного пользователя и сгенерированной на основании активации пользовательского ввода телевизионной приставки или соединенного с упомянутой телевизионной приставкой (50).
20. Способ по любому из пп.17-19, дополнительно содержащий:
прием от упомянутого шлюза (20) IMS страницы выбора провайдера услуг, содержащей для каждого доступного провайдера (80) услуг, представленного в упомянутой глобальной сети (2), идентификатор провайдера, ассоциированный с провайдером услуг (80), но указывающий на упомянутый шлюз IMS (20); и
передачу на упомянутый шлюз (20) IMS команды провайдера услуг, содержащей идентификатор провайдера выбранного провайдера (80) услуг и сгенерированной на основании активации пользовательского ввода телевизионной приставки или соединенного с упомянутой телевизионной приставкой (50).
21. Способ по п.17, дополнительно содержащий:
прием от упомянутого шлюза (20) IMS сообщения выбора услуг, содержащего информацию адреса услуг IPTV, доступных в выбранном провайдере (80) услуг, представленном в упомянутой глобальной сети (2); и
передачу в систему (56) внедренной OITF, команду загрузки описания услуг, содержащую упомянутую информацию адреса упомянутого сеанса IPTV.
22. Способ по п.17, дополнительно содержащий передачу ожидающей команды ожидания, содержащей ожидающий запрос HTTP, на упомянутый шлюз (20) IMS, чтобы позволить упомянутому шлюзу (20) IMS отправлять входящий запрос, исходящий из упомянутой глобальной сети (2), в упомянутую систему (56), внедренной OITF.
23. Способ по п.17, дополнительно содержащий:
передачу запроса порта в упомянутую (56) систему внедренной OITF;
прием от упомянутой системы (56) внедренной OITF сообщения ответа, содержащего идентификатор порта по меньшей мере одного медиа порта упомянутой телевизионной приставки (50); и
передачу выбранному провайдеру (80) услуг в упомянутой глобальной сети (2) и посредством упомянутого шлюза IMS (20) сообщения приглашения, содержащего упомянутый идентификатор порта.
24. Способ по п.17, в котором отправление упомянутой информации адреса содержит передачу в систему (56) внедренной OITF запроса воспроизведения, содержащего упомянутую информацию адреса, ассоциированную с упомянутыми медиаданными, доступными в упомянутом медиасервере (70), и индикацию, что процедура установки не должна быть выполнена упомянутой системой (56) внедренной OITF.
25. Способ по п.17, дополнительно содержащий прием от упомянутого шлюза (20) IMS сообщения описания сеанса, содержащего упомянутую информацию адреса в форме информации адреса медиа канала многоадресной передачи или вещания, доступного от упомянутого медиасервера (70), в котором направление упомянутой информации адреса содержит передачу упомянутой информации адреса в упомянутую систему (56) внедренной OITF для инициации упомянутой системы (56) внедренной OITF присоединиться к упомянутому медиа каналу многоадресной передачи или вещания.
26. Способ установления сеанса телевидения IP, IPTV, содержащий:
передачу шлюзом (20) мультимедийной подсистемы IP (IMS-шлюзом) запроса регистрации, содержащего пользовательский идентификатор пользователя телевизионной приставки (50) в домашней сети (1), на сервер IMS в глобальной сети (2), соединенный с упомянутой домашней сетью (1);
передачу упомянутым шлюзом (20) IMS запроса подписки, предназначенного провайдеру (80) услуг IPTV, представленному в упомянутой глобальной сети (2);
отображение упомянутым шлюзом (20) IMS для каждой услуги IPTV, доступной для упомянутого пользователя от упомянутой глобальной сети (2), информации адреса, принятой в ответ на упомянутый запрос подписки, в преобразованную информацию адреса, указывающую на упомянутый шлюз IMS (20); и
генерирование упомянутым шлюзом (IMS) 20 web-страницы, содержащей упомянутую преобразованную информацию адреса, указывающую на упомянутый шлюз (20) IMS; и
передачу упомянутым шлюзом (20) IMS упомянутой web-страницы на упомянутую телевизионную приставку (50).
27. Способ по п.26, дополнительно содержащий отображение упомянутым шлюзом (20) IMS вспомогательной информации адреса, ассоциированной со вспомогательным провайдером услуг, в преобразованную вспомогательную информацию адреса, указывающую на упомянутый шлюз (20) IMS, в котором генерирование упомянутой web-страницы содержит генерирование упомянутым шлюзом (20) IMS упомянутой web-страницы, содержащей упомянутую преобразованную информацию адреса и упомянутую преобразованную вспомогательную информацию адреса.
28. Способ по п.26 или 27, дополнительно содержащий:
генерирование упомянутым шлюзом (20) IMS web-страницы, содержащей пользовательские идентификаторы множественных пользователей, потенциально доступных для упомянутой телевизионной приставки (50) в ответ на запрос пользовательского выбора, исходящий из упомянутой телевизионной приставки (50); и
передачу упомянутым шлюзом (20) IMS упомянутой web-страницы, содержащей упомянутые пользовательские идентификаторы, к упомянутой телевизионной приставке (50).
29. Способ по п.26, дополнительно содержащий:
прием упомянутым шлюзом (20) IMS ожидающей команды, содержащей ожидающий запрос HTTP от упомянутой телевизионной приставки (50); и передачу упомянутым шлюзом (20) IMS в ответ на упомянутую, ожидающую команду входящего запроса, исходящего из упомянутой глобальной сети (2), на упомянутую телевизионную приставку (50).
