СПОСОБ И СИСТЕМА ДОСТАВКИ АУДИОВИЗУАЛЬНОГО КОНТЕНТА В РЕЖИМЕ РЕАЛЬНОГО ВРЕМЕНИ Российский патент 2023 года по МПК H04N21/6405 H04L65/611 H04N21/2187 

ОБЛАСТЬ ТЕХНИКИ

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

УРОВЕНЬ ТЕХНИКИ

В прошлом большинство технологий потоковой передачи видео в режиме реального времени основывалось на таких протоколах потоковой передачи, как RTP (Real-time Transport Protocol, транспортный протокол в режиме реального времени, определенный в нормативном документе RFC 3550) или RTSP (Real-Time Streaming Protocol, протокол потоковой передачи данных в режиме реального времени, определенный в нормативном документе RFC 2326). Современные технологии потоковой передачи в режиме реального времени почти исключительно основаны на протоколе HTTP (HyperText Transfer Protocol, протокол передачи гипертекста, определенном в нормативном документе RFC 2616) и выполнены с возможностью обеспечения эффективной работы в больших и распределенных сетях HTTP, таких как Интернет.

Адаптивная передача битового потока (Adaptive Bitrate Streaming, ABS) представляет собой одну из популярных технологий потоковой передачи HTTP, используемых при потоковой передаче контента по компьютерным сетям, а HLS (HTTP Live Streaming, потоковая передача HTTP в режиме реального времени), которая представляет собой протокол потоковой передачи данных в режиме реального времени, основанный на HTTP и разработанный компанией Apple Inc., представляет собой один из конкретных вариантов реализации. При использовании HLS обеспечивает разделение общего AV (Audio-Visual, аудиовизуального) потока на последовательность небольших загруженных файлов на основе HTTP, каждый из которых содержит один фрагмент общего потенциально неограниченного транспортного потока. Аудиовизуальный контент доступен в различных разрешениях и разделен на фрагменты, причем фрагмент представляет собой часть аудиовизуального контента, независимо от фактического разрешения, которое соответствует временному сегменту аудиовизуального контента. При воспроизведении аудиовизуального потока клиентское устройство, декодирующее аудиовизуальный контент, может осуществлять выбор из разных альтернативных версий (также называемых уровнями или представлениями), содержащих один и тот же материал, закодированный с различными соответствующими разрешениями (различными соответствующими скоростями передачи данных в битах), что позволяет в ходе сеанса потоковой передачи адаптироваться к доступным ресурсам передачи сети и/или доступным ресурсам обработки клиентского устройства. В начале сеанса потоковой передачи клиентское устройство обычно загружает список воспроизведения в виде текстового файла с расширением файла «M3U» или «m3u8». Этот текстовый файл содержит метаданные для различных альтернативных версий, которые доступны для соответствующего аудиовизуального контента.

Аналогичный подход адаптивной передачи битового потока (ABS) реализуют с применением технологии равномерной потоковой передачи (Smooth Streaming), которая представляет собой функцию мультимедийных служб информационных служб Интернета (Internet Information Services, IIS), интегрированной платформы доставки мультимедийных данных на основе HTTP, предоставляемой Microsoft Corp. В отличие от потоковой передачи HTTP в режиме реального времени (HLS), при которой аудиовизуальный поток разделяют на множество файлов, содержащих фрагменты, дополненных файлами списков воспроизведения, при равномерной потоковой передаче используют один аудиовизуальный файл, разделенный на блоки, причем каждый блок файла содержит дескриптор, указывающий на соответствующий уровень и эталонное время в аудиовизуальном контенте. Однако основа протокола и его преимущества эквивалентны.

Аналогичным образом можно рассмотреть динамическую потоковую передачу HTTP (HTTP Dynamic Streaming, HDS) и динамическую адаптивную потоковую передачу с применением HTTP от Adobe Systems, технологию потоковой передачи мультимедиа, разработанную группой экспертов по движущимся изображениям и называемую MPEG DASH, которая связана с HDS, потоковой передачей HTTP в режиме реального времени (HLS) и плавной потоковой передачей (Smooth Streaming). При этом используют файлы с расширением «mpd».

Технологии потоковой передачи на основе HTTP очень удобны, поскольку HTTP позволяет передавать информацию через межсетевые экраны и гарантирует целостность данных, обеспечиваемую TCP (Transmission Control Protocol протоколом управления передачей, определенном в нормативном документе RFC 793). Однако одноадресная природа HTTP в контексте адаптивной передачи битового потока (ABS) создает большие проблемы с масштабируемостью для операторов CDN (Content Delivery Network, сети доставки контента), что не позволяет им использовать основанные на ABS механизмы для потоковой передачи в режиме реального времени. В действительности технологии потоковой передачи на основе HTTP основаны на одноадресных передачах, поэтому могут быть неустойчивыми с точки зрения внутренней инфраструктуры, поскольку многочисленные пользователи могут одновременно запрашивать просмотр аудиовизуального контента в режиме реального времени.

Ввиду таких недостатков технологий потоковой передачи на основе HTTP для доставки аудиовизуального контента в режиме реального времени многие операторы используют технологии потоковой передачи в режиме реального времени на основе многоадресной передачи. Это позволяет более эффективно оценить размер внутренней инфраструктуры с точки зрения расходов. В результате появилось усовершенствование Multicast-ABR, также упоминаемое как M-ABR, раскрытое в патентном документе EP 2 704 391 A1. Оно заключается в отправке файла манифеста, а также различных представлений аудиовизуального контента в режиме реального времени в виде многоадресных IP (Internet Protocol, Интернет-протокол, как определено в нормативном документе RFC 791) пакетов посредством многоадресной или широковещательной среды, что, таким образом, позволяет обеспечить значительное сокращение потребления сетевых ресурсов. На сетевой стороне существует так называемый сервер многоадресной передачи (также называемый мультикастером), который главным образом получает манифест, а затем соответствующие сегменты от сервера-источника. Мультикастер инкапсулирует сегменты в многоадресных IP-пакетах, используя некоторую схему инкапсуляции промежуточного транспортного протокола. На стороне шлюза имеется так называемый демультикастер, который принимает многоадресные IP-пакеты путем реализации указанного промежуточного транспортного протокола и извлекает полезную нагрузку в виде сегмента мультимедийных данных, готового для подачи на устройство воспроизведения клиентского устройства с использованием одноадресных передач. Устройство воспроизведения запрашивает сегменты у демультикастера, который функционирует как HTTP-сервер с позиции клиентского устройства, обычным одноадресным способом (например, MPEG DASH), основанным на периоде продолжительности сегмента и оцененном качестве/скорости передачи данных в битах.

Чтобы клиентское устройство гарантировано использовало демультикастер в качестве прокси, применяют раскрытый в патентном документе EP 2 704 391 A1 механизм перенаправления, согласно которому контроллер CDN, на котором клиентское устройство запрашивает доставку аудиовизуального контента в режиме реального времени, перенаправляет клиентское устройство на демультикастер в шлюзе, соединяющем локальную сеть (LAN), в которой находится клиентское устройство, и сеть поставщика услуг, в которой расположены контроллер CDN и мультикастер.

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

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

Также, в частности, желательно предоставить решение, которое было бы простым и эффективным с точки зрения расходов.

РАСКРЫТИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ

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

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

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

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

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

Способ включает:

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

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

- отправку клиентом контроллеру запроса на получение целевого аудиовизуального контента в режиме реального времени, который обеспечивает указание того, присутствует ли и доступен ли демультикастер или нет;

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

- на фиг. 1 схематически изображена система доставки аудиовизуального контента в режиме реального времени согласно настоящему изобретению;

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

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

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

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

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

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

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

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

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

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

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

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

Система доставки аудиовизуального контента в режиме реального времени содержит шлюз GW 140, соединяющий локальную сеть LAN 101 и сеть PN 102 поставщика услуг. Сеть PN 102 поставщика услуг представляет собой, например, сеть ISP (Internet Service Provider, поставщика услуг сети Интернет). Сеть PN 102 поставщика услуг представляет собой, например, сеть кабельного или спутникового вещания. Таким образом, сеть PN 102 поставщика услуг может позволять выполнять передачи по нисходящей и восходящей линиям связи или позволять выполнять передачи только по нисходящей линии связи, как подробно описано ниже. В предпочтительном варианте осуществления локальная сеть LAN 101 и сеть PN 102 поставщика услуг поддерживают протокол IP. Шлюз GW 140 предпочтительно является абонентским шлюзом.

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

В системе доставки аудиовизуального контента в режиме реального времени по меньшей мере один клиент содержит устройство PL 110 воспроизведения или подключен к нему. Клиент обычно подключен к локальной сети LAN 101. Устройство PL 110 воспроизведения выполнено с возможностью использования (например, воспроизведения, записи) аудиовизуального контента в режиме реального времени, принятого клиентом в форме, пригодной для одноадресной передачи. Предпочтительно, клиент выполнен с возможностью осуществления связи и приема аудиовизуального контента в режиме реального времени с использованием HTTP, и, например, выполнен с возможностью использования аудиовизуального контента в режиме реального времени, соответствующего схеме HAS (HTTP Adaptive Streaming, адаптивной потоковой передачи HTTP). Таким образом, клиент не может принимать аудиовизуальный контент в режиме реального времени ни в форме, пригодной для многоадресной передачи, ни в форме, пригодной для широковещательной передачи. Как подробно описано ниже, устройство PL 110 воспроизведения не зависит от инфраструктуры системы доставки аудиовизуального контента в режиме реального времени. Клиент обрабатывает принятые данные аудиовизуального контента в режиме реального времени, выполненные с возможностью использования в устройстве PL 110 воспроизведения, так что данные аудиовизуального контента в режиме реального времени имеют форму, подходящую для устройства PL 110 воспроизведения. Клиент выполняет обмен протоколами, чтобы обеспечить возможность для устройства PL 110 воспроизведения принимать указанные данные аудиовизуального контента в режиме реального времени. В дальнейшем для упрощения считается, что клиент и устройство PL 110 воспроизведения являются единым целым.

В системе доставки аудиовизуального контента в режиме реального времени оборудование CDE 120 для доставки контента непосредственно или опосредованно подключено к сети PN 102 поставщика услуг. Оборудование CDE 120 для доставки контента включает один или более серверов. Оборудование CDE 120 для доставки контента содержит по меньшей мере мультикастер (устройство для многоадресной передачи). Мультикастер обеспечивает предоставление по сети PN 102 поставщика услуг аудиовизуального контента в режиме реального времени в форме, пригодной для многоадресной передачи. Например, мультикастер обеспечивает различные представления аудиовизуального контента в режиме реального времени в форме потоков многоадресной передачи с использованием транспортного протокола в режиме реального времени (RTP) поверх UDP (User Datagram Protocol, протокола датаграмм пользователя, определенного в нормативном документе RFC 768). Использование многоадресных передач посредством сети PN 102 поставщика услуг позволяет уменьшить размеры внутренней инфраструктуры (т.е. ресурсов обработки и ширины полосы, требуемых оборудованию CDE 120 для доставки контента для выполнения доставки аудиовизуального контента в режиме реального времени) по сравнению с доставкой аудиовизуального контента в режиме реального времени одноадресным способом.

Перед мультикастером может присутствовать сервер-источник, также называемый источником-упаковщиком, обеспечивающий упаковку различных представлений аудиовизуального контента в режиме реального времени в сегменты, все из которых согласованы (имеют одинаковую длительность, одинаковые изображения) в виде набора мультимедийных файлов, например, соответствующих схеме адаптивной потоковой передачи HTTP (HAS). Перед источником-упаковщиком может присутствовать кодер OTT (Over-The-Top), доставляющий различные представления аудиовизуального контента в режиме реального времени (например, телевизионный канал) источнику-упаковщику, причем каждое представление кодируется кодером OTT с конкретной скоростью передачи данных в битах/качеством.

Шлюз GW 140 или другое устройство в локальной сети LAN 101 (включая клиента) содержит демультикастер DM 150. Демультикастер DM 150 выполнен с возможностью приема многоадресных IP-пакетов, передаваемых с применением многоадресной передачи и которые могут проходить через шлюз GW 140, если демультикастер DM 150 находится в другом устройстве в локальной сети LAN 101.

Демультикастер DM 150 выполнен с возможностью получения сегментов аудиовизуального контента в режиме реального времени, готовых к подаче в устройство PL 110 воспроизведения, с использованием одноадресных передач. Когда устройство PL 110 воспроизведения принимает аудиовизуальный контент в режиме реального времени, оно выполнено с возможностью отслеживания ширины полосы, доступной для приема аудиовизуального контента в режиме реального времени и, кроме того, выбора представления аудиовизуального контента в режиме реального времени, соответствующего доступной ширине полосы и предпочтительно доступным внутренним ресурсам обработки. Таким образом, демультикастер DM 150 выполнен с возможностью осуществления преобразования из формы для многоадресной передачи в форму для одноадресной передачи. Для этого демультикастер DM 150 выполнен с возможностью управления регистрациями потока многоадресной передачи, например, путем реализации протокола IGMP (Internet Group Management Protocol, протокола управления группами в сети Интернет, определенного в нормативном документе RFC 3376). Кроме того, демультикастер DM 150 на основании предварительной конфигурации определяет, какой аудиовизуальный контент в режиме реального времени может быть принят с применением многоадресных передач, например, с использованием заданного выделенного потока или канала многоадресной передачи, обеспечиваемого оборудованием CDE 120 для доставки контента, или путем обмена данными с сервером с заданной выделенной конфигурацией оборудования CDE 120 для доставки контента.

Демультикастер DM 150 также может быть выполнен с возможностью выполнения запроса и приема в ответ сегментов аудиовизуального контента в режиме реального времени в форме, пригодной для одноадресной передачи, на восстановительный сервер RUS одноадресной передачи оборудования CDE 120 для доставки контента, чтобы демультикастер DM 150 мог получить сегменты аудиовизуального контента в режиме реального времени, потерянные в ходе многоадресных передач. Этот аспект рассматривается ниже.

Шлюзы и локальные сети, подключенные к сети PN 102 поставщика услуг, такие как шлюз GW 140 и локальная сеть LAN 101, могут включать в себя такой демультикастер, в то время как другие шлюзы или другие локальные сети, подключенные к сети PN 102 поставщика услуг, могут не включать в себя такой демультикастер. Кроме того, в шлюзах или локальных сетях, которые включают в себя такой демультикастер, некоторые демультикастеры могут присутствовать, но быть неактивными, а у некоторых демультикастеров уже может не хватать объема запоминающего устройства и/или ресурсов обработки. Этот аспект подробно рассматривается ниже.

В системе доставки аудиовизуального контента в режиме реального времени контроллер CTRL 130 управляет доставкой аудиовизуального контента в режиме реального времени, т.е. управляет маршрутизацией запросов на получение аудиовизуального контента в режиме реального времени. В зависимости от инфраструктуры системы доставки аудиовизуального контента в режиме реального времени контроллер CTRL 130 может быть расположен в сети PN 102 поставщика услуг, или подключен к ней, либо он может быть расположен в шлюзе GW 140 или в локальной сети LAN 101. Если ожидается, что устройство PL 110 воспроизведения будет использовать аудиовизуальный контент в режиме реального времени (например, согласно команде пользователя), устройство PL 110 воспроизведения обращается к контроллеру CTRL 130, запрашивая доставку рассматриваемого аудиовизуального контента в режиме реального времени. Устройство PL 110 воспроизведения обращается к контроллеру CTRL 130, как если бы контроллер CTRL 130 был сервером, с которого может быть доставлен аудиовизуальный контент в режиме реального времени. Тот факт, что сам контроллер CTRL 130 не способен доставлять аудиовизуальный контент в режиме реального времени, очевиден для устройства PL 110 воспроизведения. Устройство PL 110 воспроизведения определяет способ обращения к контроллеру CTRL 130 - с использованием преобразования DNS (Domain Name System, системы доменных имен) или путем определения адреса в ходе процедуры обнаружения, предназначенной для обнаружения доступности демультикастера DM 150 в шлюзе GW 140 или в другом устройстве в локальной сети LAN 101. Этот аспект подробно рассматривается ниже. Чтобы выполнить запрос на доставку аудиовизуального контента в режиме реального времени, контроллер CTRL 130 перенаправляет устройство PL 110 воспроизведения на соответствующий сервер одноадресной передачи (например, оборудования CDE 120 для доставки контента) или на демультикастер DM 150, в зависимости от того, что из указанного выполнимо, с учетом инфраструктуры системы доставки аудиовизуального контента в режиме реального времени и фактического рабочего состояния с целью оптимизации потребления ресурсов в сети PN 102 поставщика услуг. Другими словами, контроллер решает, куда перенаправить клиент для выполнения запросов на получение целевого аудиовизуального контента в режиме реального времени, по меньшей мере в соответствии с указанием того, присутствует ли и доступен ли такой демультикастер, выполненный с возможностью обеспечения преобразования из формы для многоадресной передачи в форму для одноадресной передачи для клиента, или нет. Этот аспект также подробно рассматривается ниже.

В конкретном варианте осуществления демультикастер DM 150 установлен в шлюзе GW 140. В другом конкретном варианте осуществления демультикастер DM 150 установлен в декодере каналов, подключенном к шлюзу GW 140. Такой декодер каналов подключен к локальной сети LAN 101 и может быть дополнительно подключен к шлюзу GW 140 через локальную сеть LAN 101 или по выделенной линии связи.

В конкретном варианте осуществления клиент и устройство PL 110 воспроизведения установлены в шлюзе GW 140 или в подключенном к нему декодере каналов. Если демультикастер DM 150 также присутствует в шлюзе GW 140 или в подключенном к нему декодере каналов, клиент и устройство PL 110 воспроизведения устанавливают изолировано по отношению к демультикастеру DM 150 и, если он присутствует, к контроллеру CTRL 130. Это означает, что до выполнения процедуры обнаружения клиент и устройство PL 110 воспроизведения не имеют данных о том, находятся ли они в одном и том же устройстве с демультикастером DM 150, или нет.

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

На этапе 200 по фиг. 2A и на этапе 210 по фиг. 2B устройство PL 110 воспроизведения инициирует процедуру обнаружения, в ходе выполнения которой шлюз GW 140 и любое другое устройство в локальной сети LAN 101 должны уведомить устройство PL 110 воспроизведения о том, включает ли указанный шлюз GW 140 или указанное другое устройство в локальной сети LAN 101 доступный демультикастер, или нет. Если устройство PL 110 воспроизведения встроено в устройство, отличное от шлюза GW 140, процедура обнаружения выполняется в локальной сети LAN 101. Если устройство PL 110 воспроизведения размещается в устройстве, способном содержать такой демультикастер (например, шлюз GW 140), процедура обнаружения дополнительно выполняется посредством API (Application Programming Interface, интерфейса прикладного программирования) устройства, в котором размещено устройство PL 110 воспроизведения.

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

Далее для иллюстрации будем считать, что устройство PL 110 воспроизведения встроено в устройство, отличное от шлюза GW 140, и что процедура обнаружения выполняется исключительно в локальной сети LAN 101. Принципы процедуры обнаружения, описанные в данном документе в контексте локальной сети LAN 101, будут применяться mutatis mutandis в контексте вышеупомянутого интерфейса прикладного программирования (API).

В процедуре обнаружения, например, используется протокол SDP (Service Discovery Protocol, протокол обнаружения услуг), такой как протокол SSDP (Simple Service Discovery Protocol, протокол обнаружения простых услуг), который также используется в UPnP (Universal Plug n’ Play, универсальный протокол Plug n’ Play, который определен в нормативном документе ISO/IEC 29341), или технология Zeroconf, такая как Apple’s Bonjour или подходы к обнаружению услуг на основе DNS. Локальный сервер DNS, расположенный, например, в шлюзе GW 140, и заранее сконфигурированный, возможно, с помощью демультикастера DM 150, если он присутствует, позволяет осуществлять преобразование заданного доменного имени, связанного с указанным демультикастером DM 150.

В ходе процедуры обнаружения устройство PL 110 воспроизведения зондирует локальную сеть LAN 101, чтобы определить, присутствует ли демультикастер в шлюзе GW 140 или, в более общем случае, в локальной сети LAN 101, и, предпочтительно, активен ли демультикастер, если он имеется, или нет. Если на устройстве имеется такой демультикастер, указанное устройство передает в ответ дескриптор, идентифицирующий рассматриваемый демультикастер DM 150. Если принять, что шлюз GW 140 содержит демультикастер DM 150, шлюз GW 140, таким образом, передает в ответ дескриптор, идентифицирующий демультикастер DM 150. Таким образом, дескриптор по существу указывает на наличие демультикастера DM 150. Дескриптор также указывает адрес для обращения к демультикастеру DM 150 и, возможно, локальное имя демультикастера DM 150, которое определяется конфигурацией при установке демультикастера DM 150.

Следует отметить, что используемый в данном документе термин «адрес» следует понимать в его широком значении, включая, в частности, конкатенацию IP-адреса и номера порта.

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

В предпочтительном альтернативном варианте осуществления дескриптор указывает только наличие демультикастера DM 150 и адрес, такой как IP-адрес и номер порта, для обращения к демультикастеру DM 150. Затем устройство PL 110 воспроизведения передает специальный запрос на демультикастер DM 150, чтобы определить, активен ли демультикастер DM 150, или нет, используя адрес, указанный в дескрипторе. Если демультикастер DM 150 отвечает на указанный специальный запрос, устройство PL 110 воспроизведения заключает, что демультикастер DM 150 активен. При ответе демультикастер DM 150 может указывать, имеет ли демультикастер DM 150 достаточный объем запоминающего устройства и/или ресурсов обработки для приема еще одной порции аудиовизуального контента в режиме реального времени. Если в течение заданного времени задержки ответ на специальный запрос не принят, устройство PL 110 воспроизведения заключает, что демультикастер DM 150 неактивен.

На этапе 201 по фиг. 2A и на этапе 211 на фиг. 2B устройство PL 110 воспроизведения получает адрес для обращения к контроллеру CTRL 130 и передает на контроллер CTRL 130 запрос REQ1, запрашивающий доставку одного конкретного аудиовизуального контента в режиме реального времени. Таким образом, запрос REQ1 представляет собой одноадресное сообщение, которое идентифицирует рассматриваемый аудиовизуальный контент в режиме реального времени. Например, запрос REQ1 представляет собой сообщение HTTP GET, содержащее URL (Uniform Resource Locator, унифицированный указатель ресурса), состоящий из FQDN (Fully Qualified Domain Name, полного доменного имени), за которым следует путь к текстовому файлу с соответствующим расширением файла (основанным на формате, в котором упакован аудиовизуальный контент в режиме реального времени), например:

HTTP GET tv.myISP.com/SportsChannel1.mpd

Запрос REQ1 также содержит информацию, указывающую после обнаружения, содержит ли шлюз, через который устройство PL 110 воспроизведения осуществляет доступ к сети PN 102 поставщика услуг, демультикастер, выполненный с возможностью обеспечения доставки аудиовизуального контента в режиме реального времени для устройства PL 110 воспроизведения, или нет. Например, при повторном осуществлении приведенного выше примера запрос REQ1 включает внутренний параметр, в котором явным образом указана информация, показанная ниже при указании доступности демультикастера:

HTTP GET tv.myISP.com/SportsChannel1.mpd?de-multicaster=ON

и следующим образом при указании недоступности демультикастера:

HTTP GET tv.myISP.com/SportsChannel1.mpd?de-multicaster=OFF

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

HTTP GET tv.myISP.com/SportsChannel1.mpd

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

HTTP GET tv.myISP.com/SportsChannel1.mpd?

de-multicaster=192.168.1.100:8000

причем в этом примере 192.168.1.100:8000 - это комбинация IP-адреса и номера порта демультикастер DM 150.

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

Запрос REQ1 также может включать в качестве дополнительного внутреннего параметра, в случае наличия демультикастера, представленную ниже информацию о полном доменном имени (FQDN) (tv.myISP.com в этом примере).

HTTP GET tv.myISP.com/SportsChannel1.mpd?

de-multicaster=192.168.1.100:8000&FQDN_orig= tv.myISP.com

Это может быть применено позже для демультикастера DM 150, например, с целью управления доступом и для дополнительного аспекта, описанного ниже в подробном описании варианта осуществления. Следует отметить, что указанный внутренний параметр не является обязательным. Если он отсутствует, то может быть добавлен контроллером CTRL 130 при перенаправлении устройства PL 110 воспроизведения на демультикастер DM 150. Если он присутствует, то «виден» для контроллера CTRL 130, который лишь должен скопировать внутренние параметры запроса REQ1, когда необходимо перенаправить устройство PL 110 воспроизведения на демультикастер DM 150.

На этапе 201 по фиг. 2A считается, что запрос REQ1 содержит информацию, указывающую на то, что демультикастер, выполненный с возможностью обеспечения доставки аудиовизуального контента в режиме реального времени для устройства PL 110 воспроизведения, присутствует локально. На этапе 211 по фиг. 2B дополнительно считается, что запрос REQ1 содержит информацию, указывающую на то, что демультикастер, выполненный с возможностью обеспечения доставки аудиовизуального контента в режиме реального времени для устройства PL 110 воспроизведения, не присутствует локально.

На этапе 202 по фиг. 2A и на этапе 212 по фиг. 2B контроллер CTRL 130 проверяет, доступен ли рассматриваемый аудиовизуальный контент в режиме реального времени в какой-либо форме, или нет. Если контроллер CTRL 130 определяет, что рассматриваемый аудиовизуальный контент в режиме реального времени не доступен в какой-либо форме, контроллер CTRL 130 отклоняет запрос REQ1, например, возвращая сообщение HTTP ERROR 404.

На этапе 202 по фиг. 2A контроллер CTRL 130 проверяет, доступен ли рассматриваемый аудиовизуальный контент в режиме реального времени в форме, пригодной для многоадресной передачи, или нет. Контроллер CTRL 130 обращается, например, к файлу, содержащему список аудиовизуального контента в режиме реального времени, доступного в форме, пригодной для многоадресной передачи. Если контроллер CTRL 130 определяет, что рассматриваемый аудиовизуальный контент в режиме реального времени доступен в форме, пригодной для многоадресной передачи, контроллер CTRL 130 перенаправляет устройство PL 110 воспроизведения на демультикастер DM 150, как изображено на фиг. 2A. Для этого контроллер CTRL 130 предпочтительно включает в сообщение REDIR1 о перенаправлении, передаваемое в ответ на запрос REQ1, адрес или локальное имя демультикастера DM 150, которое предусмотрено в качестве внутреннего параметра запроса REQ1.

Кроме того, когда сеть PN 102 поставщика услуг разрешает осуществление связи по восходящей линии связи, контроллер CTRL 130 может включать в сообщение REDIR1 о перенаправлении в качестве внутреннего параметра адрес (или URL-адрес) сервера одноадресной доставки аудиовизуального контента в режиме реального времени в сети PN 102 поставщика услуг (например, оборудования CDE 120 для доставки контента). Такой сервер одноадресной доставки аудиовизуального контента в режиме реального времени может быть использован позже демультикастером DM 150 для дополнения сегментов аудиовизуального контента в режиме реального времени, полученных в форме, пригодной для многоадресной передачи, сегментами в форме, пригодной для одноадресной передачи, в частности, когда демультикастер DM 150 обнаруживает, что среди сегментов, принятых в форме, пригодной для многоадресной передачи, есть по меньшей мере один пропущенный аудиовизуальный контент в режиме реального времени.

Таким образом, в приведенном выше примере сообщение REDIR1 о перенаправлении выглядит, например, следующим образом:

HTTP REDIRECT 192.168.1.100:8000/SportsChannel1.mpd? FQDN_orig= tv.myISP.com &CDN_unicastServer=<адрес сервера>

Если контроллер CTRL 130 определяет, что рассматриваемый аудиовизуальный контент в режиме реального времени недоступен в форме, пригодной для многоадресной передачи, контроллер CTRL 130 перенаправляет устройство PL 110 воспроизведения на сервер одноадресной доставки аудиовизуального контента в режиме реального времени в сети PN 102 поставщика услуг (например, относящийся к оборудованию CDE 120 для доставки контента), если инфраструктура системы доставки аудиовизуального контента в режиме реального времени позволяет осуществлять связь по восходящей линии связи от шлюза GW 140 и локальной сети LAN 101 к оборудованию CDE 120 для доставки контента, и если такой сервер одноадресной доставки аудиовизуального контента в режиме реального времени существует в сети PN 102 поставщика услуг (например, в оборудовании CDE 120 для доставки контента). Таким образом, устройство PL 110 воспроизведения перенаправляется таким же образом, как если бы демультикастер отсутствовал в шлюзе GW 140 или любом другом устройстве в локальной сети LAN 101, как изображено на фиг. 2B.

Если контроллер CTRL 130 не способен определить, доступен ли рассматриваемый аудиовизуальный контент в режиме реального времени в форме, пригодной для многоадресной передачи, или нет, контроллер CTRL 130 позволяет демультикастеру DM 150 выполнить такую проверку со своей стороны. В этом случае контроллер CTRL 130 предпочтительно указывает в качестве внутреннего параметра в сообщении REDIR1 о перенаправлении адрес (или URL-адрес) рассматриваемого сервера одноадресной доставки аудиовизуального контента в режиме реального времени.

Каждый внутренний параметр сообщения REDIR1 о перенаправлении затем предоставляется устройством PL 110 воспроизведения на демультикастер DM 150 во время перенаправления, что, таким образом, позволяет демультикастеру DM 150 идентифицировать адрес сервера одноадресной доставки аудиовизуального контента в режиме реального времени, когда это необходимо. Этот аспект рассматривается на фиг. 9A и 9B в контексте конкретного варианта осуществления инфраструктуры, показанного на фиг. 8, но тот же принцип также применяется и в контексте конкретного варианта осуществления инфраструктуры, показанного на фиг. 4 (т.е. если сеть PN 102 поставщика услуг разрешает связь по восходящей линии связи).

В конкретном варианте осуществления сообщение REDIR1 о перенаправлении, перенаправляющее устройство PL 110 воспроизведения на демультикастер DM 150, дополнительно содержит другие внутренние параметры, такие как, например, адрес восстановительного сервера одноадресной передачи, если он имеется, и/или адреса многоадресной передачи различных представлений рассматриваемого аудиовизуального контента в режиме реального времени, если они известны контроллеру CTRL 130. В приведенном выше примере сообщение REDIR1 о перенаправлении выглядит, например, следующим образом:

HTTP REDIRECT 192.168.1.100:8000/SportsChannel1.mpd? FQDN_orig=tv.myISP.com&CDN_unicastServer=<адрес сервера>

&repair=172.16.254.1:80

где 172.16.254.1:80 - это комбинация IP-адреса и номера порта, выделенного для рассматриваемого восстановительного сервера одноадресной передачи.

Затем, на этапе 212 по фиг. 2B контроллер CTRL 130 проверяет, доступен ли рассматриваемый аудиовизуальный контент в режиме реального времени в форме, пригодной для одноадресной передачи, или нет. Контроллер CTRL 130 обращается, например, к файлу, содержащему список аудиовизуального контента в режиме реального времени, доступного в форме, пригодной для одноадресной передачи. Если контроллер CTRL 130 определяет, что рассматриваемый аудиовизуальный контент в режиме реального времени доступен в форме, пригодной для одноадресной передачи, контроллер CTRL 130 перенаправляет устройство PL 110 воспроизведения на сервер одноадресной доставки аудиовизуального контента в режиме реального времени в сети PN 102 поставщика услуг (например, относящийся к оборудованию CDE 120 для доставки контента), если инфраструктура системы доставки аудиовизуального контента в режиме реального времени позволяет осуществлять связь по восходящей линии связи от локальной сети LAN 101 к оборудованию CDE 120 для доставки контента, и если такой сервер одноадресной доставки аудиовизуального контента в режиме реального времени существует в сети PN 102 поставщика услуг (например, в оборудовании CDE 120 для доставки контента). Для этого контроллер CTRL 130 предпочтительно включает в сообщение REDIR1 о перенаправлении, передаваемое в ответ на запрос REQ1, адрес рассматриваемого сервера одноадресной доставки аудиовизуального контента в режиме реального времени. В приведенном выше примере сообщение REDIR1 о перенаправлении выглядит, например, следующим образом:

HTTP REDIRECT 172.16.248.3:80/SportsChannel1.mpd

где 172.16.248.3:80 - это комбинация IP-адреса и номера порта рассматриваемого сервера одноадресной доставки аудиовизуального контента в режиме реального времени.

В противном случае контроллер CTRL 130 отклоняет запрос REQ1, например, возвращая сообщение HTTP ERROR 404.

На этапе 203 по фиг. 2A и на этапе 213 по фиг. 2B устройство PL 110 воспроизведения передает еще один запрос REQ2 согласно командам, содержащимся в сообщении REDIR1 о перенаправлении. Таким образом, в запросе REQ2 запрашивается доставка рассматриваемого аудиовизуального контента в режиме реального времени с сервера, отличного от изначально запрошенного контроллером CTRL 130. На этапе 203 по фиг. 2A устройство PL 110 воспроизведения передает запрос REQ2 на демультикастер DM 150.

На этапе 213 по фиг. 2B устройство PL 110 воспроизведения передает запрос REQ2 на сервер одноадресной доставки аудиовизуального контента в режиме реального времени.

Следовательно, устройство PL 110 воспроизведения принимает рассматриваемый аудиовизуальный контент в режиме реального времени. Либо аудиовизуальный контент в режиме реального времени принимается на этапе 205 по фиг. 2A в форме, пригодной для одноадресной передачи, от демультикастера DM 150, выполняющего функцию ретранслятора передач, принятых от оборудования CDE 120 для доставки контента на этапе 204; либо аудиовизуальный контент в режиме реального времени принимается в форме, пригодной для одноадресной передачи, от сервера одноадресной доставки аудиовизуального контента в режиме реального времени (например, относящегося к оборудованию CDE 120 для доставки контента), т.е. без прохождения через демультикастер DM 150, на этапе 214 по фиг. 2B.

На этапах 204 и 205, когда сеть 102 поставщика услуг разрешает осуществление связи по восходящей линии связи, запрошенные сегменты аудиовизуального контента в режиме реального времени либо присутствуют в демультикастере DM 150, принятые ранее в форме, пригодной для многоадресной передачи, от мультикастера оборудования CDE 120 для доставки контента, а демультикастер DM 150 может вернуть запрошенные сегменты аудиовизуального контента в режиме реального времени на устройство PL 110 воспроизведения, либо, если сегменты потеряны, демультикастер DM 150 может запросить контент на сервере одноадресной доставки аудиовизуального контента в режиме реального времени.

Благодаря подходу, описанному выше, контроллер CTRL 130 динамически определяет, содержит ли шлюз GW 140 или любое другое устройство в локальной сети LAN 101 такой демультикастер, и, если он имеется, способен ли этот демультикастер выполнить за устройство PL 110 воспроизведения запрос на доставку аудиовизуального контента в режиме реального времени. В действительности, демультикастер может присутствовать, но быть неактивным, а это означает, что перенаправление устройства PL 110 воспроизведения на демультикастер в этом случае было бы не имеющим смысла, поскольку это по меньшей мере означало бы значительную бесполезную задержку с точки зрения QoE (Quality of Experience, качества взаимодействия) устройства PL 110 воспроизведения.

Этот подход является гибким с точки зрения действительного местоположения контроллера CTRL 130, как подробно описано ниже в конкретных вариантах осуществления инфраструктуры по фиг. 4, 6, 8 и 10, и такое действительное местоположение не влияет на вариант реализации устройства PL 110 воспроизведения (т.е. клиента). Кроме того, этот подход является достаточно гибким для поддержки сетей поставщиков услуг без возможности осуществления связи по восходящей линии связи от шлюза GW 140 и локальной сети LAN 101 через указанные сети поставщиков услуг (например, широковещательную сеть), а также сети поставщиков услуг, имеющих указанную возможность передачи по восходящей линии связи. Кроме того, следует отметить, что этот подход подходит для адаптивной потоковой передачи, которая позволяет пользователям получать преимущество от доступности различных альтернативных версий (или представлений) аудиовизуального контента в режиме реального времени, закодированного с различными соответствующими скоростями передачи данных в битах (или разрешениями).

На фиг. 3 схематически изображен пример архитектуры аппаратного обеспечения устройств системы доставки аудиовизуального контента в режиме реального времени. Демультикастер DM 150 и/или контроллер CTRL 130, и/или шлюз GW 140, и/или устройство PL 110 воспроизведения, и/или любой сервер оборудования CDE 120 для доставки контента могут быть построены на основе представленного примера архитектуры аппаратного обеспечения. Для иллюстрации будем считать, что на фиг. 3 представлена архитектура аппаратного обеспечения контроллера CTRL 130.

Согласно представленному примеру архитектуры аппаратного обеспечения контроллер CTRL 130 содержит следующие компоненты, соединенные между собой шиной 310 связи: процессор, микропроцессор, микроконтроллер или ЦП (Central Processing Unit, центральный процессор) 301; ОЗУ (оперативное запоминающее устройство) 302; ПЗУ (постоянное запоминающее устройство) 303, или ЭСППЗУ (электрически стираемое постоянное запоминающее устройство) или электрически перепрограммируемое постоянное запоминающее устройство; накопитель на жестких магнитных дисках или любое другое устройство, выполненное с возможностью считывания информации, хранящейся на носителе данных, предназначенном для долговременного хранения информации, таком как устройство 304 чтения карт SD (Secure Digital); по меньшей мере один интерфейс COM 305 связи, позволяющий осуществлять связь по локальной сети LAN 101 и/или сети PN 102 поставщика услуг.

ЦП 301 выполнен с возможностью исполнения команд, загруженных в ОЗУ 302 из ПЗУ 303 или из внешнего запоминающего устройства запоминающее устройство, такого как карта SD. После включения контроллера CTRL 130 ЦП 301 может считывать команды из ОЗУ 302 и исполнять эти команды. Команды составляют одну компьютерную программу, с помощью которой ЦП 301 выполняет этапы, описанные в данном документе в отношении контроллера CTRL 130.

Следует отметить, что описанные в данном документе этапы могут быть реализованы в форме программного обеспечения путем исполнения набора команд или программы с помощью программируемой вычислительной машины, такой как ПК (Personal Computer, персональный компьютер), DSP (Digital Signal Processor, цифровой сигнальный процессор) или микроконтроллер; или же могут быть реализованы в аппаратной форме с помощью машины или выделенного компонента, такого как FPGA (Field-Programmable Gate Array, программируемая пользователем вентильная матрица) или ASIC (Application-Specific Integrated Circuit, специализированная интегральная схема). В более общем смысле, любое устройство системы доставки аудиовизуального контента в режиме реального времени содержит электронные схемы обработки, выполненные с возможностью реализации соответствующих этапов, описанных в данном документе в отношении рассматриваемого устройства.

На фиг. 4 схематически представлен первый вариант осуществления системы доставки аудиовизуального контента в режиме реального времени, в которой контроллер CTRL 130 расположен в сети PN 102 поставщика услуг или подключен к ней, а именно за шлюзом GW 140 с позиции устройства PL 110 воспроизведения. На фиг. 4 также показан сервер DNS 161 в сети PN 102 поставщика услуг для преобразования доменных имен. Кроме того, оборудование CDE 120 для доставки контента, показанное на фиг. 4, содержит мультикастер или сервер MS 121 многоадресной передачи, а также вышеуказанный восстановительный сервер RUS 122 одноадресной передачи. Восстановительный сервер RUS 122 одноадресной передачи может быть совмещен с сервером MS 121 многоадресной передачи, т.е. может быть физически расположен на той же машине. Восстановительный сервер RUS 122 одноадресной передачи реализует механизм восстановления потерянных сегментов аудиовизуального контента в режиме реального времени, как правило, с помощью стандартизованного протокола связи, выбираемого в зависимости от транспортного протокола, используемого для операций многоадресной передачи (например, транспортного протокола в режиме реального времени (RTP) или FLUTE/ALC). Оборудование CDE 120 для доставки контента может содержать другие серверы, как уже было указано.

В соответствии с конкретным признаком восстановительный сервер RUS 122 одноадресной передачи получает сегменты аудиовизуального контента в режиме реального времени путем объединения различных потоков многоадресной передачи, доставляемых сервером MS 121 многоадресной передачи, для соответствующих различных представлений рассматриваемого аудиовизуального контента в режиме реального времени. Восстановительный сервер RUS 122 одноадресной передачи запоминает в течение заданного периода времени пакеты указанных потоков многоадресной передачи и обслуживает запросы на восстановление от демультикастера DM 150, чтобы компенсировать потенциальные потери сегмента. Например, восстановительный сервер RUS 122 одноадресной передачи предоставляет услугу восстановления, выполняя повторную попытку с применением транспортного протокола в режиме реального времени (RTP) (определенную в нормативном документе RFC 4588) на основе счетчика непрерывности в пакетах RTP, передаваемых сервером MS 121 многоадресной передачи, что позволяет легко обнаруживать потерю данных.

Как показано на фиг. 4, демультикастер DM 150 встроен в шлюз GW 140. Как уже упоминалось, демультикастер DM 150 в другом варианте может быть встроен в другое устройство в локальной сети LAN 101.

На фиг. 5A и 5B схематически показан обмен данными, происходящий в первом варианте осуществления системы доставки аудиовизуального контента в режиме реального времени, показанной на фиг. 4.

На этапе 500 по фиг. 5A и на этапе 510 по фиг. 5B устройство PL 110 воспроизведения выполняет процедуру обнаружения в локальной сети LAN 101 (и/или посредством API), как уже было описано в отношении этапа 200 по фиг. 2A и этапа 210 по фиг. 2B.

Для получения адреса для обращения к контроллеру CTRL 130 устройство PL 110 воспроизведения запрашивает преобразование доменного имени на сервере DNS 161. Адрес для обращения к серверу DNS 161 был сконфигурирован шлюзом GW 140 в устройства PL 110 воспроизведения, когда устройство PL 110 воспроизведения было успешно зарегистрировано в локальной сети LAN 101, управляемой шлюзом GW 140. В качестве альтернативы, адрес для обращения к серверу DNS 161 может быть сконфигурирован пользователем вручную при установке устройства PL 110 воспроизведения. Таким образом, на этапе 501 по фиг. 5A и на этапе 511 по фиг. 5B устройство PL 110 воспроизведения передает запрос REQ0 на сервер DNS 161. В запросе REQ0 запрашивается преобразование FQDN URL-адреса, идентифицирующего аудиовизуальный контент в режиме реального времени, который является целевым для устройства PL 110 воспроизведения, а именно tv.myISP.com в приведенном выше примере. Сервер DNS 161 выполняет преобразование доменного имени и, таким образом, получает адрес контроллера CTRL 130 в сети PN 102 поставщика услуг. Например, преобразование доменного имени приводит к получению следующего IP-адреса: 72.68.18.14.

На этапе 502 по фиг. 5A и на этапе 512 по фиг. 5B сервер DNS 161 возвращает на устройство PL 110 воспроизведения полученный адрес контроллера CTRL 130 в ответном сообщении RESP0. Таким образом, теперь устройство PL 110 воспроизведения может осуществить связь с контроллером CTRL 130.

Выполняемые впоследствии этапы с 503 по 507, показанные на фиг. 5A, соответственно, идентичны этапам с 201 по 205, показанным на фиг. 2A, которые подробно описаны ранее. А выполняемые впоследствии этапы с 513 по 516 по фиг. 5B, соответственно, идентичны этапам с 211 по 214 по фиг. 2B, которые подробно описаны ранее.

При рассмотрении этапа 506 по фиг. 5A, на котором демультикастер DM 150 получает сегменты аудиовизуального контента в режиме реального времени от оборудования CDE 120 для доставки контента, демультикастер DM 150 использует поток многоадресной передачи, передаваемый сервером MS 121 многоадресной передачи и соответствующий представлению аудиовизуального контента в режиме реального времени, запрошенного устройством PL 110 воспроизведения. При обнаружении демультикастером DM 150 потери сегмента демультикастер DM 150 запрашивает рассматриваемый потерянный сегмент в форме, пригодной для одноадресной передачи, на восстановительном сервере RUS 122 одноадресной передачи для непрерывной передачи на устройство PL 110 воспроизведения сегментов аудиовизуального контента в режиме реального времени, что, таким образом, позволяет улучшить QoE несмотря на потенциальные потери сегмента в принимаемых потоках многоадресной передачи. Получение преимущества от такого восстановления возможно в первом варианте осуществления системы доставки аудиовизуального контента в режиме реального времени, показанной на фиг. 4, поскольку сеть PN 102 поставщика услуг структурно позволяет осуществлять связь по восходящей линии связи от шлюза GW 140 и локальной сети LAN 101 к оборудованию CDE 120 для доставки контента. Использование восстановительного сервера RUS 122, в частности, является предпочтительным при потерях многоадресных пакетов, которые обычно передают с использованием транспортного протокола (например, протокола датаграмм пользователя (UDP)), не имеющего механизма повторной передачи. Если потери сегментов вызваны потерей сегментов среди последовательных корректно принятых многоадресных пакетов, то демультикастер DM 150 может запросить недостающие сегменты на сервере одноадресной доставки аудиовизуального контента в режиме реального времени.

На фиг. 6 схематически представлен второй вариант осуществления системы доставки аудиовизуального контента в режиме реального времени, в которой контроллер CTRL 130 также расположен в шлюзе GW 140 или в другом устройстве в локальной сети LAN 101. Как показано на фиг. 6, демультикастер DM 150 встроен в шлюз GW 140. Как уже упоминалось, демультикастер DM 150 в другом варианте может быть встроен в другое устройство в локальной сети LAN 101. Кроме того, как показано на фиг. 6, контроллер CTRL 130 совмещен с демультикастером DM 150, а именно также расположен в шлюзе GW 140. В другом варианте контроллер CTRL 130 может быть встроен в другое устройство в локальной сети LAN 101.

Кроме того, на фиг. 6 показан локальный сервер DNS 162 (local DNS server, LDNS) для преобразования доменных имен. Сервер LDNS 162 расположен в шлюзе GW 140 (на фиг. 6), но может быть расположен в другом устройстве в локальной сети LAN 101. Сеть PN 102 поставщика услуг представляет собой сеть широковещательного типа, и, таким образом, по направлению к оборудованию CDE для доставки контента не может быть осуществлена связь по восходящей линии связи от локальной сети LAN 101 или шлюза GW 140. Таким образом, серверы в оборудовании CDE для доставки контента, доступные для шлюза GW 140 и любого другого устройства в локальной сети LAN 101, могут представлять собой только сервер многоадресной передачи, такой как сервер MS 121 многоадресной передачи, выполненный с возможностью только осуществления связи по нисходящей линии связи. Следует отметить, что в таком контексте серверы сети для широковещательной передачи поставщика услуг рассматриваются в данном документе как серверы многоадресной передачи, поскольку каждый демультикастер выбирает поток аудиовизуального контента в режиме реального времени (например, телевизионный канал) для эффективного приема и обработки, который, таким образом, относится к многоадресным передачам (поскольку широковещательные передачи приведут к тому, что все демультикастеры будут принимать одни и те же данные).

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

На этапе 701 устройство PL 110 воспроизведения выполняет процедуру обнаружения в локальной сети LAN 101 (и/или посредством API), как уже было описано в отношении этапа 200 по фиг. 2A.

Для получения адреса с целью обращения к контроллеру CTRL 130 устройство PL 110 воспроизведения запрашивает преобразование доменного имени на сервере LDNS 162. Адрес для обращения к серверу LDNS 162 был сконфигурирован шлюзом GW 140 в устройстве PL 110 воспроизведения, когда устройство PL 110 воспроизведения было успешно зарегистрировано в локальной сети LAN 101, управляемой шлюзом GW 140. В качестве альтернативы адрес для обращения к серверу LDNS 162 может быть сконфигурирован пользователем вручную при установке устройства PL 110 воспроизведения, в частности, если сервер LDNS 162 расположен в другом устройстве в локальной сети LAN 101. Таким образом, на этапе 702 устройство PL 110 воспроизведения передает запрос REQ0 на сервер LDNS 162. В запросе REQ0 запрашивается преобразование FQDN URL-адреса, идентифицирующего аудиовизуальный контент в режиме реального времени, который является целевым для устройства PL 110 воспроизведения, а именно tv.myISP.com в приведенном выше примере. Сервер LDNS 162 выполняет преобразование доменного имени и, таким образом, получает адрес контроллера CTRL 130. Например, преобразование доменного имени приводит к получению следующего IP-адреса и номера порта: 192.168.1.100:8001.

Конфигурирование сервера LDNS 162 таким образом, чтобы сервер LDNS 162 мог выполнять преобразование доменного имени и получать адрес контроллера CTRL 130, предпочтительно выполняется демультикастером DM 150, когда демультикастер DM 150 был успешно установлен в шлюз GW 140, путем передачи на сервер LDNS 162 на этапе 700 сообщения CONF1 о конфигурации, обеспечивающего ассоциирование между полным доменным именем (FQDN) для URL-адреса рассматриваемого аудиовизуального контента в режиме реального времени и адресом для обращения к контроллеру CTRL 130. Таким образом, такое сообщение является внутренним для шлюза GW 140, если демультикастер DM 150 размещается в шлюзе GW 140. В качестве альтернативы сервер LDNS 162 может быть сконфигурирован с помощью любых других средств, в том числе вручную пользователем при установке демультикастера DM 150 и контроллера CTRL 130.

В конкретном варианте осуществления, в котором демультикастер DM 150 и контроллер CTRL 130 совмещены в одной машине (например, в шлюзе GW 140), преобразование доменного имени, выполняемое сервером LDNS 162, может привести к получению IP-адреса, отличного от IP-адреса, используемого для обращения демультикастера DM 150, который называют IP-псевдонимом. Это, в частности, предпочтительно для облегчения разрешения конфликтов при выделении номера порта другим компонентам шлюза GW 140.

На этапе 703 сервер LDNS 162 возвращает на устройство PL 110 воспроизведения полученный адрес контроллера CTRL 130 в ответном сообщении RESP0. Таким образом, теперь устройство PL 110 воспроизведения может осуществить связь с контроллером CTRL 130.

Согласно конкретному варианту, в котором демультикастер DM 150 и контроллер CTRL 130 совмещены в одной машине (например, шлюзе GW 140), устройство PL 110 воспроизведения определяет адрес для обращения к контроллеру CTRL 130 не в результате преобразования доменного имени. Эта ситуация может возникнуть, если в локальной сети LAN 101 нет локального сервера DNS или если контроллеру CTRL 130 не разрешено конфигурировать такой локальный сервер DNS. Устройству PL 110 воспроизведения в соответствии с признаком этого конкретного варианта известна конфигурация, в соответствии с которой контроллер CTRL 130 совмещен с демультикастер DM 150 в одной машине (например, в шлюзе GW 140). Таким образом, после получения адреса демультикастером DM 150 в ходе процедуры обнаружения контроллер CTRL 130 получает адрес контроллера CTRL 130 из адреса демультикастера DM 150, применяя заданное правило подстановки, для номера порта, выделенного демультикастеру DM 150. Например, контроллер CTRL 130 увеличивает на одну единицу номер порта для адреса демультикастера DM 150, чтобы получить номер порта для адреса контроллера CTRL 130.

Выполняемые впоследствии этапы с 704 по 708, показанные на фиг. 7, соответственно, идентичны этапам с 201 по 205, показанным на фиг. 2A, которые подробно описаны ранее. В данном случае следует отметить, что в отличие от фиг. 5A в данном случае демультикастер DM 150 не может получить преимущество от какого-либо сервера одноадресной передачи на этапе 707, поскольку осуществление связи по восходящей линии связи невозможно в контексте второго варианта осуществления системы доставки аудиовизуального контента в режиме реального времени, показанной на фиг. 6.

На фиг. 8 схематически представлен третий вариант осуществления системы доставки аудиовизуального контента в режиме реального времени, который представляет собой гибридную комбинацию первого и второго вариантов осуществления, описанных выше со ссылкой на фиг. 4 и 6. На фиг. 8 контроллер CTRL 130 также расположен в шлюзе GW 140 или в другом устройстве в локальной сети LAN 101. Как показано на фиг. 8, демультикастер DM 150 встроен в шлюз GW 140. Как уже упоминалось, демультикастер DM 150 в другом варианте может быть встроен в другое устройство в локальной сети LAN 101. Кроме того, как показано на фиг. 8, контроллер CTRL 130 совмещен с демультикастером DM 150, а именно также расположен в шлюзе GW 140. В другом варианте контроллер CTRL 130 может быть встроен в другое устройство в локальной сети LAN 101. Однако на фиг. 8 сеть PN 102 поставщика услуг разрешает осуществление связи по восходящей линии связи, как в первом варианте осуществления на фиг. 4. Таким образом, оборудование CDE 120 для доставки контента, показанное на фиг. 6, содержит мультикастер или сервер MS 121 многоадресной передачи, а также восстановительный сервер RUS 122 одноадресной передачи.

Оборудование CDE 120 для доставки контента по фиг. 6 дополнительно содержит сервер CDNS (Content Delivery Network server) 123 сети доставки контента. Серверу CDNS 123 не известно о возможности многоадресной передачи оборудованием CDE 120 для доставки контента и он представляет собой, например, сторонний сервер, через который может быть запрошен аудиовизуальный контент в режиме реального времени в форме, пригодной для одноадресной передачи. Сервер CDNS 123 может находиться в другом домене полномочий по отношению к оборудованию CDE 120 для доставки контента и, таким образом, может быть отделен от оборудования CDE 120 для доставки контента. Следует отметить, что при обращении для доставки аудиовизуального контента в режиме реального времени сервер CDNS 123 может выполнять перенаправление к другому серверу в сети PN 102 поставщика услуг для эффективной доставки аудиовизуального контента в режиме реального времени. Кроме того, на фиг. 8 показаны сервер DNS 161 и сервер LDNS 162, которые были показаны, соответственно, на фиг. 4 и 6. Сервер LDNS 162 расположен в шлюзе GW 140 (на фиг. 8), но может быть расположен в другом устройстве в локальной сети LAN 101.

На фиг. 9A и 9B схематически показан обмен данными, происходящий в третьем варианте осуществления системы доставки аудиовизуального контента в режиме реального времени, показанной на фиг. 8.

Сервер LDNS 162 сконфигурирован, как уже было описано со ссылкой на фиг. 7. Таким образом, демультикастер DM 150 предпочтительно может сконфигурировать сервер LDNS 162 на этапе 900 с помощью сообщения CONF1 конфигурации, чтобы устройство PL 110 воспроизведения могло получить адрес для обращения к контроллеру CTRL 130 путем преобразования доменного имени. Как описано со ссылкой на фиг. 7, один вариант состоит в том, что устройство PL 110 воспроизведения получает адрес (номер порта) контроллера CTRL 130 из адреса (номера порта) демультикастер DM 150, полученного во время процедуры обнаружения, если контроллер CTRL 130 и демультикастер DM 150 совмещены в одной машине.

На этапе 901 по фиг. 9A и на этапе 911 по фиг. 9B устройство PL 110 воспроизведения выполняет процедуру обнаружения в локальной сети LAN 101 (и/или посредством API), как уже было описано в отношении этапа 200 по фиг. 2A и этапа 210 по фиг. 2B.

На этапе 902 по фиг. 9A и на этапе 912 по фиг. 9B устройство PL 110 воспроизведения передает запрос REQ0 на сервер LDNS 162. В запросе REQ0 запрашивается преобразование FQDN URL-адреса, идентифицирующего аудиовизуальный контент в режиме реального времени, который является целевым для устройства PL 110 воспроизведения, а именно tv.myISP.com в приведенном выше примере. Сервер LDNS 162 выполняет преобразование доменного имени и, таким образом, получает адрес контроллера CTRL 130. Например, преобразование доменного имени приводит к получению следующего IP-адреса и номера порта: 192.168.1.100:8001.

На этапе 903 по фиг. 9A и на этапе 913 по фиг. 9B сервер LDNS 162 возвращает на устройство PL 110 воспроизведения полученный адрес контроллера CTRL 130 в ответном сообщении RESP0. Таким образом, теперь устройство PL 110 воспроизведения может осуществить связь с контроллером CTRL 130.

Выполняемые впоследствии этапы с 904 по 906, показанные на фиг. 9A, соответственно, идентичны этапам с 201 по 203, показанным на фиг. 2A, которые подробно описаны ранее.

Выполняемые впоследствии этапы с 909a по 909b, показанные на фиг. 9A, соответственно, идентичны этапам с 204 по 205, показанным на фиг. 2A, которые подробно описаны ранее. В данном случае следует отметить, что в отличие от фиг. 7 демультикастер DM 150 может получить преимущество от восстановительного сервера RUS 122 одноадресной передачи и/или от сервера CDNS 123 на этапе 909b, поскольку осуществление связи по восходящей линии связи возможно в контексте третьего варианта осуществления системы доставки аудиовизуального контента в режиме реального времени, показанной на фиг. 8. Чтобы демультикастер DM 150 мог воспользоваться преимуществами сервера CDNS 123, контроллер CTRL 130 включает в сообщение REDIR1 о перенаправлении внутренний параметр, содержащий полное доменное имя (FQDN) URL-адреса, идентифицирующего аудиовизуальный контент в режиме реального времени, требуемый устройству PL 110 воспроизведения, как указано в запросе REQ1, а именно tv.myISP.com в приведенном выше примере. В приведенном выше примере сообщение REDIR1 о перенаправлении выглядит, например, следующим образом:

HTTP REDIRECT 192.168.1.100:8000/SportsChannel1.mpd?FQDN_orig= tv.myISP.com&CDN_unicastServer=tv.myISP.com

Это в частности, является предпочтительным, если сервером CDNS 123 управляет сторонняя организация по отношению к контроллеру CTRL 130 и демультикастеру DM 150. Демультикастер DM 150, принявший запрос REQ2 на этапе 906, может использовать услуги агента DNS-клиента, установленного на той же машине, что и демультикастер DM 150, и в сочетании с указанным демультикастером DM 150, чтобы принудительно обеспечить преобразование доменного имени сервером 161 DNS и избежать того, чтобы сервер LDNS 162, если он имеется, осуществлял преобразование доменного имени.

На основании внутреннего параметра, обеспечивающего указанное полное доменное имя, указанное в запросе REQ1, демультикастер DM 150 запрашивает преобразование доменного имени и, соответственно, на этапе 907 передается сообщение REQ3. Сервер DNS 161 обрабатывает запрос REQ3, выполняет преобразование доменного имени и, таким образом, получает адрес сервера CDNS 123. Например, преобразование доменного имени приводит к получению следующего IP-адреса: 72.36.53.18. Затем на этапе 908 сервер DNS 161 возвращает демультикастеру DM 150 полученный адрес сервера CDNS 123 в ответном сообщении RESP3. Демультикастер DM 150, таким образом, может использовать этот адрес для обращения у серверу CDNS 123, когда это необходимо (например, для получения недостающих сегментов аудиовизуального контента в режиме реального времени).

Выполняемый впоследствии этап 914, показанный на фиг. 9B, идентичен этапу 211, показанному на фиг. 2B, который подробно описан ранее. В данном случае считается, что контроллер CTRL 130 не имеет информации, указывающей, доступен ли аудиовизуальный контент в режиме реального времени, запрошенный устройством PL 110 воспроизведения, в форме, пригодной для многоадресной передачи. Даже при совместном размещении на одной машине (например, в шлюзе GW 140) контроллер CTRL 130 и демультикастер DM 150 не знают о присутствии друг друга. Можно было бы обеспечить их взаимодействие, но поддержание изолированности между ними упрощает разработку контроллера CTRL 130, поскольку указанный контроллер CTRL 130 не функционирует по-разному, когда он расположен в шлюзе GW 140 или в сети PN 102 поставщика услуг. Затем контроллер CTRL 130 позволяет демультикастеру DM 150 проверить, доступен ли аудиовизуальный контент в режиме реального времени, запрошенный устройством PL 110 воспроизведения, в форме, пригодной для многоадресной передачи. Если аудиовизуальный контент в режиме реального времени, запрошенный устройством PL 110 воспроизведения, доступен в форме, пригодной для многоадресной передачи, обмен данными продолжается, как показано на фиг. 9A. В противном случае демультикастер DM 150 должен перенаправить устройство PL 110 воспроизведения на сервер CDNS 123.

Чтобы перенаправить устройство PL 110 воспроизведения на сервер CDNS 123, демультикастер DM 150 должен запросить преобразование FQDN URL-адреса, идентифицирующего аудиовизуальный контент в режиме реального времени, требуемый устройству PL 110 воспроизведения. В действительности, предыдущее преобразование доменного имени, направляющее устройство PL 110 воспроизведения на контроллер CTRL 130, было бы неудобным в данной ситуации, поскольку это привело бы к бесконечному циклу. Таким образом, на этапе 917 демультикастер DM 150 передает запрос REQ3 на сервер DNS 161. В запросе REQ3 запрашивается преобразование FQDN URL-адреса, идентифицирующего аудиовизуальный контент в режиме реального времени, требуемый устройству PL 110 воспроизведения, а именно tv.myISP.com в приведенном выше примере, который должен был предоставить контроллер CTRL 130 в виде внутреннего параметра сообщения REDIR1 о перенаправлении на этапе 915. Демультикастер DM 150 может использовать услуги агента DNS-клиента, установленного на той же машине, что и демультикастер DM 150, и в сочетании с указанным демультикастером DM 150, чтобы принудительно обеспечить преобразование сервером 161 DNS и избежать того, чтобы сервер LDNS 162, если он имеется, осуществлял преобразование доменного имени.

Сервер DNS 161 выполняет преобразование доменного имени и, таким образом, получает адрес сервера CDNS 123. Например, преобразование доменного имени приводит к получению следующего IP-адреса: 72.36.53.18. Затем на этапе 918 сервер DNS 161 возвращает демультикастеру DM 150 полученный адрес сервера CDNS 123 в ответном сообщении RESP3. Демультикастер DM 150, таким образом, может предоставить адрес сервера CDNS 123 устройству PL 110 воспроизведения.

На этапе 919 демультикастер DM 150 передает сообщение REDIR2 о перенаправлении на устройство PL 110 воспроизведения в ответ на запрос REQ2. Сообщение REDIR2 о перенаправлении включает адрес сервера CDNS 123 вместо соответствующего FQDN. В приведенном выше примере сообщение REDIR2 о перенаправлении выглядит, например, следующим образом:

HTTP REDIRECT 72.36.53.18:80/SportsChannel1.mpd

причем за IP-адресом сервера CDNS 123 в данном случае следует номер порта по умолчанию (80).

На этапе 920 устройство PL 110 воспроизведения передает еще один запрос REQ4 согласно командам, содержащимся в сообщении REDIR2 о перенаправлении. Таким образом, в запросе REQ4 запрашивается доставка рассматриваемого аудиовизуального контента в режиме реального времени от сервера CDNS 123. На этапе 921 устройство PL 110 воспроизведения принимает аудиовизуальный контент в режиме реального времени в форме, пригодной для одноадресной передачи, от сервера CDNS 123 (т.е. без прохождения через демультикастер DM 150).

На фиг. 10 схематически представлен четвертый вариант осуществления системы доставки аудиовизуального контента в режиме реального времени, который является производным от третьего варианта осуществления, описанного выше со ссылкой на фиг. 8. Как показано на фиг. 10, демультикастер DM 150 встроен в шлюз GW 140. Как уже упоминалось, демультикастер DM 150 в другом варианте может быть встроен в другое устройство в локальной сети LAN 101. Как показано на фиг. 10, контроллер CTRL 130 расположен в сети PN 102 поставщика услуг или подключен к ней, а именно за шлюзом GW 140 с позиции устройства PL 110 воспроизведения. Как показано на фиг. 10, сервер LDNS 162 присутствует в шлюзе GW 140, но может быть расположен в другом устройстве в локальной сети LAN 101.

Проблема, возникающая при такой конфигурации, заключается в преобразовании доменного имени, в частности, если аудиовизуальный контент в режиме реального времени недоступен в форме, пригодной для многоадресной передачи. Если аудиовизуальный контент в режиме реального времени, требуемый устройству PL 110 воспроизведения, доступен в форме, пригодной для многоадресной передачи, обмен данными выполняется, как уже было описано в отношении фиг. 9A, за исключением того, что контроллер CTRL 130 расположен за шлюзом GW 140 с позиции устройства PL 110 воспроизведения. Таким образом, для упрощения на фиг. 11, которая подробно описана ниже, представлена только ситуация, в которой аудиовизуальный контент в режиме реального времени, требуемый устройству PL 110 воспроизведения, недоступен в форме, пригодной для многоадресной передачи, и должен быть предоставлен в форме, пригодной для одноадресной передачи, с сервера CDNS 123, которому в любом случае неизвестно о какой-либо возможности многоадресной передачи по сети PN 102 поставщика услуг.

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

Сервер LDNS 162 конфигурируют с помощью сообщения CONF1 о конфигурации, передаваемого демультикастером DM 150. Конфигурирование сервера LDNS 162 таким образом, чтобы сервер LDNS 162 мог выполнять преобразование доменного имени и получать адрес контроллера CTRL 130, таким образом, выполняется демультикастером DM 150, когда демультикастер DM 150 был успешно установлен в шлюз GW 140 на этапе 1110, путем передачи на сервер LDNS 162 сообщения CONF1 о конфигурации, обеспечивающего ассоциирование между полным доменным именем URL-адреса аудиовизуального контента в режиме реального времени, требуемого устройству PL 110 воспроизведения, и адресом для обращения к контроллеру CTRL 130. Как упоминалось в отношении фиг. 7, в одном варианте это может выполняться вручную.

На этапе 1111 устройство PL 110 воспроизведения выполняет процедуру обнаружения в локальной сети LAN 101 (и/или посредством API), как уже было описано в отношении этапа 200 по фиг. 2A.

На этапе 1112 устройство PL 110 воспроизведения передает запрос REQ0 на сервер LDNS 162. В запросе REQ0 запрашивается преобразование FQDN URL-адреса, идентифицирующего аудиовизуальный контент в режиме реального времени, который является целевым для устройства PL 110 воспроизведения, а именно tv.myISP.com в приведенном выше примере. Сервер LDNS 162 выполняет преобразование доменного имени и, таким образом, получает адрес контроллера CTRL 130. Например, преобразование доменного имени приводит к получению следующего IP-адреса: 72.68.18.14.

На этапе 1113 сервер LDNS 162 возвращает на устройство PL 110 воспроизведения полученный адрес контроллера CTRL 130 в ответном сообщении RESP0. Таким образом, теперь устройство PL 110 воспроизведения может осуществить связь с контроллером CTRL 130.

На этапе 1114 устройство PL 110 воспроизведения передает запрос REQ1 на контроллер CTRL 130, используя адрес, полученный от сервера LDNS 162. Запрос REQ1 формируется, как было описано ранее.

На этапе 1115 контроллеру CTRL 130 неизвестно, доступен ли аудиовизуальный контент в режиме реального времени, требуемый устройству PL 110 воспроизведения, в форме, пригодной для многоадресной передачи, или нет, и указанный контроллер передает в ответ на запрос REQ1 сообщение REDIR1 о перенаправлении. В приведенном выше примере сообщение REDIR1 о перенаправлении выглядит, например, следующим образом:

HTTP REDIRECT 192.168.1.100:8000/SportsChannel1.mpd?FQDN_orig= tv.myISP.com&CDN_unicastServer=tv.myISP.com

При приеме сообщения REDIR1 о перенаправлении устройство PL 110 воспроизведения перенаправляет свой запрос на демультикастер DM 150 с помощью запроса REQ2 на этапе 1116 в соответствии с сообщением REDIR1 о перенаправлении. Учитывая, что демультикастеру DM 150 известно о том, что аудиовизуальный контент в режиме реального времени, требуемый устройству PL 110 воспроизведения, недоступен в форме, пригодной для многоадресной передачи, демультикастер DM 150 передает в ответ на запрос REQ2 на этапе 1119 сообщение REDIR2 о перенаправлении.

В сообщении REDIR2 о перенаправлении демультикастер DM 150 заменил адрес (например, IP-адрес и номер порта), указанный в запросе REQ2, на адрес сервера одноадресной передачи, предоставленный в виде внутреннего параметра (т.е. внутреннего параметра «CDN_unicastServer» в представленном выше примере) запроса REQ2.

Следует отметить, что ссылка на сервер одноадресной передачи с полным доменным именем URL-адреса, идентифицирующего аудиовизуальный контент в режиме реального времени, требуемый устройству PL 110 воспроизведения, а именно tv.myISP.com, в частности, является предпочтительной, если сервером CDNS 123 управляет другая организация по отношению к контроллеру CTRL 130 и демультикастеру DM 150. Демультикастер DM 150, принявший запрос REQ2 на этапе 1116, может использовать услуги агента DNS-клиента, установленного на той же машине, что и демультикастер DM 150, и в сочетании с указанным демультикастером DM 150, чтобы принудительно обеспечить преобразование доменного имени сервером 161 DNS и избежать того, чтобы сервер LDNS 162, если он имеется, осуществлял преобразование доменного имени.

Демультикастер DM 150 запрашивает преобразование доменного имени и, соответственно, на этапе 1117 передается сообщение REQ3. Сервер DNS 161 обрабатывает запрос REQ3, выполняет преобразование доменного имени и, таким образом, получает адрес сервера CDNS 123. Например, преобразование доменного имени приводит к получению следующего IP-адреса: 72.36.53.18. Затем на этапе 1118 сервер DNS 161 возвращает демультикастеру DM 150 полученный адрес сервера CDNS 123 в ответном сообщении RESP3.

Затем демультикастер DM 150 отправляет сообщение REDIR2 о перенаправлении. В приведенном выше примере сообщение REDIR2 о перенаправлении выглядит, например, следующим образом:

HTTP REDIRECT 72.36.53.18:80/SportsChannel1.mpd

При приеме сообщения REDIR2 о перенаправлении на этапе 1120 устройство PL 110 воспроизведения передает запрос REQ4 на сервер CDNS 123, тем самым запрашивая доставку рассматриваемого аудиовизуального контента в режиме реального времени от сервера CDNS 123. Затем, на этапе 1121 устройство PL 110 воспроизведения принимает аудиовизуальный контент в режиме реального времени в форме, пригодной для одноадресной передачи, от сервера CDNS 123 (т.е. без прохождения через демультикастер DM 150).

Изобретение относится к области доставки аудиовизуального контента в режиме реального времени на клиентское устройство. Технический результат заключается в обеспечении гибкого решения для поддержки сетей поставщиков услуг. Предложена система доставки аудиовизуального контента в режиме реального времени, включающая: клиент (110), имеющий доступ к сети (102) поставщика услуг через шлюз (140); оборудование (120) для доставки аудиовизуального контента в режиме реального времени, содержащее мультикастер для передачи аудиовизуального контента в режиме реального времени в форме, пригодной для многоадресной передачи, по сети (102) поставщика услуг; демультикастер (150), выполненный с возможностью осуществления преобразования аудиовизуального контента в режиме реального времени, полученного от мультикастера в форме, пригодной для многоадресной передачи, в форму, пригодную для одноадресной передачи; и контроллер (130), управляющий маршрутизацией запросов на получение аудиовизуального контента в режиме реального времени. Клиент (110) выполняет процедуру обнаружения, предназначенную для приема информации о потенциальном присутствии и доступности демультикастера (150). Когда клиент (110) намеревается получить целевой аудиовизуальный контент в режиме реального времени, клиент (110) отправляет на контроллер (130) запрос, содержащий указание того, присутствует ли и доступен ли демультикастер (150) или нет. Контроллер (130) решает, куда перенаправить клиент (110) для выполнения запроса, в соответствии по меньшей мере с указанием того, присутствует ли и доступен ли демультикастер (150) или нет. 2 н. и 15 з.п. ф-лы, 14 ил.

1. Способ доставки целевого аудиовизуального контента в режиме реального времени клиенту (110), выполняемый системой для доставки аудиовизуального контента в режиме реального времени, содержащей:

- клиент (110), расположенный в локальной сети (101), соединенной с сетью (102) поставщика услуг шлюзом (140), обеспечивающим доступ к сети (102) поставщика услуг, или расположенный в шлюзе (140), обеспечивающем доступ к сети (102) поставщика услуг;

- оборудование (120) для доставки аудиовизуального контента в режиме реального времени, содержащее один или более серверов, среди которых имеется мультикастер для передачи аудиовизуального контента в режиме реального времени в форме, пригодной для многоадресной передачи, посредством сети (102) поставщика услуг;

- демультикастер (150) в шлюзе (140), обеспечивающем доступ к сети (102) поставщика услуг, или в любом устройстве, расположенном в локальной сети (101), причем демультикастер (150) выполнен с возможностью осуществления преобразования аудиовизуального контента в режиме реального времени, полученного от мультикастера в форме, пригодной для многоадресной передачи, в форму, пригодную для одноадресной передачи;

- контроллер (130), управляющий маршрутизацией запросов на получение аудиовизуального контента в режиме реального времени;

отличающийся тем, что он включает:

- выполнение клиентом (110) процедуры (200; 210; 500; 510; 701; 901; 911; 1111) обнаружения, предназначенной для приема от шлюза (140), обеспечивающего доступ к сети (102) поставщика услуг, и от любого устройства, подключенного к локальной сети (101), информации о потенциальном присутствии и доступности демультикастера (150);

а когда клиент (110) намеревается получить целевой аудиовизуальный контент в режиме реального времени:

- отправку клиентом (110) на контроллер (130) запроса (201; 211; 503; 513; 704; 904; 914; 1114) на получение целевого аудиовизуального контента в режиме реального времени, который обеспечивает указание того, присутствует ли и доступен ли демультикастер (150) или нет;

- принятие контроллером (130) решения о том, как перенаправить клиент (110) для выполнения запроса на получение целевого аудиовизуального контента в режиме реального времени по меньшей мере в соответствии с указанием того, присутствует ли и доступен ли демультикастер (150) или нет.

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

3. Способ по любому из пп. 1 и 2, согласно которому сеть (102) поставщика услуг разрешает осуществление связи по восходящей линии связи от шлюза (140) и локальной сети (101) через сеть (102) поставщика услуг, а контроллер (130) расположен в сети (102) поставщика услуг, причем контроллер (130) перенаправляет клиент (110) на сервер (123) одноадресной передачи оборудования для доставки аудиовизуального контента в режиме реального времени, если контроллер (130) определяет, что клиент (110) не может воспользоваться преимуществами от преобразования, а в противном случае перенаправляет клиент (110) на демультикастер (150).

4. Способ по п. 3, согласно которому клиент определяет адрес для обращения к контроллеру (130), запрашивая преобразование доменного имени на сервере (161) доменного имени, расположенном в сети (102) поставщика услуг, причем преобразование доменного имени относится к полному доменному имени, включенному в унифицированный указатель ресурса, идентифицирующий целевой аудиовизуальный контент в режиме реального времени.

5. Способ по п. 3 или 4, согласно которому демультикастер (150) получает отсутствующие сегменты целевого аудиовизуального контента в режиме реального времени, которые находятся в форме, пригодной для многоадресной передачи, от восстанавливающего сервера (122) одноадресной передачи оборудования (120) для доставки аудиовизуального контента в режиме реального времени, который принимает целевой аудиовизуальный контент в режиме реального времени от мультикастера (121).

6. Способ по любому из пп. 3-5, согласно которому при перенаправлении клиента (110) на демультикастер (150) контроллер (130) передает сообщение о перенаправлении, включающее внутренний параметр, содержащий полное доменное имя, включенное в унифицированный указатель ресурса, который был указан в запросе на получение целевого аудиовизуального контента в режиме реального времени и который идентифицирует целевой аудиовизуальный контент в режиме реального времени, причем демультикастер (150) перенаправляет клиент (110) на сервер одноадресной передачи в сети (102) поставщика услуг, если демультикастер (150) определяет, что клиент (110) не может воспользоваться преимуществами от преобразования, при этом демультикастер (150) определяет адрес указанного сервера одноадресной передачи, запрашивая преобразование доменного имени на сервере (161) доменного имени, расположенном в сети (102) поставщика услуг, с использованием внутреннего параметра, содержащего указанное полное доменное имя.

7. Способ по любому из пп. 1 и 2, согласно которому сеть (102) поставщика услуг разрешает осуществление связи по восходящей линии связи от шлюза (140) и локальной сети (101) через сеть (102) поставщика услуг, а контроллер (130) расположен в шлюзе (140) или в локальной сети (101), причем контроллер (140) перенаправляет клиент (110) на сервер одноадресной передачи в сети (102) поставщика услуг, которому неизвестно о возможности многоадресной передачи, если контроллер (130) определяет, что клиент (110) не может воспользоваться преимуществами от преобразования, а в противном случае перенаправляет клиент на демультикастер (150).

8. Способ по п. 7, согласно которому клиент (110) определяет адрес для обращения к контроллеру (130), запрашивая преобразование доменного имени на локальном сервере (162) доменных имен, расположенном в шлюзе (140) или в локальной сети (101), причем преобразование доменного имени относится к полному доменному имени, включенному в унифицированный указатель ресурса, идентифицирующий целевой аудиовизуальный контент в режиме реального времени.

9. Способ по п. 8, согласно которому контроллер (130) предварительно конфигурирует локальный сервер (162) доменных имен для ассоциирования указанного полного доменного имени с адресом контроллера (130).

10. Способ по п. 7, согласно которому контроллер (130) и демультикастер (150) совмещены в одной машине, а клиент (110) определяет адрес для обращения к контроллеру (130) путем получения указанного адреса для обращения к контроллеру (130) из адреса для обращения к демультикастеру (150) в результате осуществления процедуры обнаружения.

11. Способ по любому из пп. 8-10, согласно которому демультикастер (150) получает отсутствующие сегменты целевого аудиовизуального контента в режиме реального времени, которые находятся в форме, пригодной для многоадресной передачи, от восстанавливающего сервера (122) одноадресной передачи оборудования (120) для доставки аудиовизуального контента в режиме реального времени, который принимает целевой аудиовизуальный контент в режиме реального времени от мультикастера (121).

12. Способ по любому из пп. 8-11, согласно которому при перенаправлении клиента (110) на демультикастер (150) контроллер (130) передает сообщение о перенаправлении, включающее внутренний параметр, содержащий полное доменное имя, включенное в унифицированный указатель ресурса, который был указан в запросе на получение целевого аудиовизуального контента в режиме реального времени и который идентифицирует целевой аудиовизуальный контент в режиме реального времени, причем демультикастер (150) перенаправляет клиент (110) на сервер одноадресной передачи в сети (102) поставщика услуг, которому неизвестно о возможности многоадресной передачи, если демультикастер (150) определяет, что клиент (110) не может воспользоваться преимуществами от преобразования, при этом демультикастер (150) определяет адрес указанного сервера одноадресной передачи, которому неизвестно о возможности многоадресной передачи, запрашивая преобразование доменного имени на сервере (161) доменных имен, расположенном в сети (102) поставщика услуг, с использованием внутреннего параметра, содержащего указанное полное доменное имя.

13. Способ по любому из пп. 1 и 2, согласно которому сеть (102) поставщика услуг не позволяет осуществлять связь по восходящей линии связи от шлюза (140) и локальной сети (101) через сеть (102) поставщика услуг, а контроллер (130) расположен в шлюзе (140) или в локальной сети (101), причем контроллер (130) отклоняет запрос на получение целевого аудиовизуального контента в режиме реального времени, если контроллер (130) определяет, что клиент (110) не может воспользоваться преимуществами от преобразования, а в противном случае перенаправляет клиент (110) на демультикастер (150).

14. Способ по п. 13, согласно которому клиент определяет адрес для обращения к контроллеру (130), запрашивая преобразование доменного имени на локальном сервере (162) доменных имен, расположенном в шлюзе (140) или в локальной сети (101), причем преобразование доменного имени относится к полному доменному имени, включенному в унифицированный указатель ресурса, идентифицирующий целевой аудиовизуальный контент в режиме реального времени.

15. Способ по п. 14, согласно которому демультикастер (150) предварительно конфигурирует локальный сервер (162) доменных имен для ассоциирования указанного полного доменного имени с адресом контроллера (130).

16. Способ по п. 13, согласно которому контроллер (130) и демультикастер (150) совмещены в одной машине, а клиент (110) определяет адрес для обращения к контроллеру (130) путем получения указанного адреса для обращения к контроллеру (130) из адреса для обращения к демультикастеру (150) в результате осуществления процедуры обнаружения.

17. Система для доставки аудиовизуального контента в режиме реального времени, содержащая:

- клиент (110), расположенный в локальной сети (101), соединенной с сетью (102) поставщика услуг шлюзом (140), обеспечивающим доступ к сети (102) поставщика услуг, или расположенный в шлюзе (140), обеспечивающем доступ к сети (102) поставщика услуг;

- оборудование (120) для доставки аудиовизуального контента в режиме реального времени, содержащее один или более серверов, среди которых имеется мультикастер для передачи аудиовизуального контента в режиме реального времени в форме, пригодной для многоадресной передачи, посредством сети (102) поставщика услуг;

- демультикастер (150) в шлюзе (140), обеспечивающем доступ к сети (102) поставщика услуг, или в любом устройстве, расположенном в локальной сети (101), причем демультикастер (150) выполнен с возможностью осуществления преобразования аудиовизуального контента в режиме реального времени, полученного от мультикастера в форме, пригодной для многоадресной передачи, в форму, пригодную для одноадресной передачи;

- контроллер (130), выполненный с возможностью управления маршрутизацией запросов на получение аудиовизуального контента в режиме реального времени;

отличающаяся тем, что:

- клиент (110) содержит средства для выполнения процедуры (200; 210; 500; 510; 701; 901; 911; 1111) обнаружения, предназначенной для приема от шлюза (140), обеспечивающего доступ к сети (102) поставщика услуг, и от любого устройства, подключенного к локальной сети (101), информации о потенциальном присутствии и доступности демультикастера (150);

- клиент (110) содержит средства для отправки (201; 211; 503; 513; 704; 904; 914; 1114) на контроллер (130), когда клиент (110) намеревается получить целевой аудиовизуальный контент в режиме реального времени, запроса на получение целевого аудиовизуального контента в режиме реального времени, который обеспечивает указание того, присутствует ли и доступен ли демультикастер (150) или нет;

- контроллер (130) выполнен с возможностью принятия решения о том, как перенаправить клиент (110) для выполнения запроса на получение целевого аудиовизуального контента в режиме реального времени по меньшей мере в соответствии с указанием того, присутствует ли и доступен ли демультикастер (150) или нет.