Внедрение сообщения описания сеанса в сообщение протокола управления передачей в реальном масштабе времени (rtcp)

Внедрение сообщения описания сеанса в сообщение протокола управления передачей в реальном масштабе времени (rtcp)

Иллюстрации

Показать все

Реферат

Область техники

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

Предшествующий уровень техники

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

Широко распространенная доступность потоковой передачи мультимедийного содержимого допускает множество типов информационного содержимого, которое не было ранее доступно по Интернет или другим компьютерным сетям. «Живое» содержимое (передающееся непосредственно с места действия) является одним из важных примеров такого содержимого. Используя потоковую передачу мультимедийного содержимого, аудио, видео, или аудио/визуальный обзор примечательных событий могут быть переданы по Интернет, когда разворачиваются события. Точно так же телевизионные и радиостанции могут передавать контент непосредственно с места действия по Интернет.

Протокол описания сеанса (SDP), документ «запрос на комментарии рабочей группы по сетям» (RFC) 2327, является основанным на тексте форматом, используемым для описания свойств мультимедийных представлений, называемых "сеансами", и свойств одного или более потоков аудиовизуальной информации, содержащихся в представлении. SDP был разработан как протокол прикладного уровня, предназначенный для описания мультимедийных сеансов с целью объявления сеанса, приглашения сеанса и других форм инициирования мультимедийного сеанса. SDP может использоваться в соответствии с другими протоколами, такими как Протокол потоковой передачи информации в реальном масштабе времени (RTSP) или протокол передачи гипертекстовых файлов (HTTP), для описания и/или согласования свойств мультимедийного сеанса, используемого для доставки передаваемых в виде потока данных.

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

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

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

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

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

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

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

В соответствии с другими аспектами каналы создают заранее определенным образом (например, заранее выбранные логические адреса, заранее выбранные порты IP-адреса и т.д.) так, чтобы клиенты могли немедленно соединиться с каналом без (или одновременно с) подсоединения(ем) к каналу объявления, чтобы уменьшить задержку запуска.

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

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

Одинаковые ссылочные позиции используются в документе для ссылки на аналогичные компоненты и/или признаки.

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

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

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

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

Фиг. 5 иллюстрирует пример формата сообщения RTCP, имеющего внедренное сообщение описания сеанса.

Фиг. 6 иллюстрирует примерный формат сообщения описания сеанса.

Фиг. 7 иллюстрирует последовательность операций примерного процесса для внедрения сообщений описания сеанса в сообщение RTCP при использовании списка воспроизведения.

Фиг. 8 иллюстрирует последовательность операций примерного процесса для приема сообщений описания сеанса в сообщении RTCP при использовании списка воспроизведения.

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

Фиг. 10 иллюстрирует последовательность операций сервера в системе согласно фиг. 9, согласно одному варианту осуществления.

Фиг. 11 - диаграмма, иллюстрирующая примерные каналы согласно одному варианту осуществления.

Фиг. 12 последовательность операций, иллюстрирующая последовательность операций на клиенте в системе по фиг. 9, согласно одному варианту осуществления.

Фиг. 12A последовательность операций, иллюстрирующая последовательность операций на клиенте в системе по фиг. 9, согласно другому варианту осуществления.

Фиг. 13 - последовательность операций, иллюстрирующая сервер по фиг. 9, согласно одному варианту осуществления.

Фиг. 14 - последовательность операций, иллюстрирующая последовательность операций контроллера конфигурации из фиг. 13, согласно одному варианту осуществления.

Фиг. 15 - блок-схема, иллюстрирующая сервер из фиг. 9, согласно другому варианту осуществления.

Фиг. 16 - последовательность операций, иллюстрирующая последовательность операций сервера с генератором ускоренного потока из фиг. 15, согласно одному варианту осуществления.

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

Фиг. 17A - последовательность операций, иллюстрирующая последовательность операций на клиенте при приеме ускоренного потока, согласно другому варианту осуществления.

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

Подробное описание предпочтительного варианта осуществления

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

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

Фиг. 1 иллюстрирует пример сетевой среды 100, которая может использоваться для потоковой передачи аудиовизуальной информации, используя сообщение описания сеанса, внедренное в сообщение RTCP, как описано ниже. В среде 100 множество (a) клиентских вычислительных устройств 102(1), 102(2), …, 102(a) подсоединены к множеству (b) серверных вычислительных устройств 104(1), 104(2), …, 104(b) через сеть 106. Сеть 106 предназначена для представления любой из ряда обычных сетевых топологий и типов (включая проводные и/или беспроводные сети), используя любой из ряда обычных сетевых протоколов (включая открытые и/или составляющие собственность протоколы). Сеть 106 может включать в себя, например Интернет, а также, возможно, по меньшей мере части одной или более локальных сетей (локальных вычислительных сетей).

Вычислительные устройства 102 и 104 каждое могут быть любым из ряда обычных вычислительных устройств, включая настольные ПК, рабочие станции, универсальные компьютеры, Интернет-устройства, игровые консоли, карманные ПК, сотовые телефоны, персональные цифровые помощники (PDA) и т.д. Одно или более устройств 102 и 104 может быть устройствами одного и того же типа или, альтернативно, устройствами различных типов.

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

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

Используемый термин "передаваемая в виде потока аудиовизуальная информация" относится к потоку одного или более видов аудиовизуальной информации от одного устройства до другого (например, от серверного устройства 104 на клиентское устройство 102). Аудиовизуальные потоки могут включать в себя любой из множества типов содержимого (контента), например одно или более из аудио, видео, текста и т.д.

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

В примере на фиг. 2 протокол 150 прикладного уровня (уровня приложений), транспортный протокол 152 и один или более протоколов 154 канала доставки используются как часть процесса передачи в виде потока. Дополнительные протоколы, не показанные на фиг. 2, также могут быть использованы (например, могут быть дополнительный(е) протокол(ы) между протоколом 150 прикладного уровня и транспортным протоколом 152). Протокол 150 прикладного уровня - это протокол на уровне приложений для управления доставкой данных со свойствами в реальном масштабе времени. Протокол 150 прикладного уровня обеспечивает структуру, опционально расширяемую для обеспечения управляемой доставки «по требованию» в реальном масштабе времени данных, таких как передаваемый в виде потока аудио- и видеоконтент. Протокол 150 прикладного уровня является протоколом управления для инициализизации и направления доставки передаваемой в виде потока мультимедийной информации от серверов аудиовизуальной информации. Примеры протокола 150 прикладного уровня включают в себя Протокол потоковой передачи в реальном масштабе времени (RTSP), как описано в описании «запроса на комментарии рабочей группы по сетям» (RFC) 2326, апрель 1998, и протокол передачи гипертекстовых файлов (HTTP), как описано в описании «запроса на комментарии рабочей группы по сетям» (RFC) 1945, Май 1996, или в описании «запроса на комментарии рабочей группы по сетям» (RFC) 2068, январь 1997.

Протокол 150 прикладного уровня использует транспортный протокол 152 для доставки в реальном масштабе времени данных, таких как потоковое аудио и видео. Транспортный протокол 152 определяет формат пакета для потоков аудиовизуальной информации. Транспортный протокол 152 обеспечивает сквозные сетевые транспортные функции, подходящие для приложений, передающих данные в реальном масштабе времени, такие как аудио, видео или данные моделирования, для многоадресных (мультивещания) или одноадресных сетевых услуг. Примеры транспортного протокола 152 включают в себя Протокол транспортировки в реальном масштабе времени (RTP) и Протокол управления передачей в реальном масштабе времени (RTCP), как описано в описании «запроса на комментарии рабочей группы по сетям» (RFC) 3550, июль 2003. Также могут использоваться другие версии, типа будущих черновых или стандартизированных, версий RTP и RTCP. RTP не направлен на резервирование ресурсов и не гарантирует "качество обслуживания" для услуг в реальном масштабе времени. Транспортировка данных расширяется в соответствии с протоколом управления (RTCP), чтобы позволить контролировать доставку данных способом, масштабируемым к большим многоадресным сетям (сетям мультивещания), и обеспечить некоторое управление и функциональные возможности идентификации.

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

Транспортный протокол 152 использует протокол(ы) 154 канала доставки для соединений транспортировки. Протокол(ы) 154 канала доставки включает(ют) в себя один или более каналов для транспортировки пакетов данных от серверного устройства 104 на клиентское устройство 102. Каждый канал обычно используется для посылки пакетов данных для потока одного типа аудиовизуальной информации, хотя в альтернативных вариантах осуществления может использоваться одиночный канал для посылки пакетов данных для потоков множества типов аудиовизуальной информации. Примеры протоколов 154 канала доставки включают в себя пакеты Протокола управления передачей (TCP) и пакеты Протокола пользовательских дейтаграмм (UDP). TCP гарантирует доставку пакетов данных, в то время как UDP не гарантирует доставку пакетов данных. Как правило, доставка пакетов данных, используя TCP, более надежна, но также и требует больше времени, чем доставка пакетов данных, используя UDP.

Фиг. 3 иллюстрирует пример клиентского и серверного устройств в среде мультивещания, которые могут передавать в виде потока аудиовизуальный контент, используя сообщение описания сеанса, внедренное в сообщение RTCP, как описано ниже. В некоторых вариантах осуществления протоколы 150, 152 и 154 согласно фиг. 2 включены в клиентское и серверное устройства согласно фиг. 3, но не проиллюстрированы. Кроме того, хотя не показано на фиг. 3, одно или более дополнительных устройств (например, брандмауэры, маршрутизаторы, шлюзы, мосты и т.д.) могут быть расположены между клиентским устройством 102 и серверным устройством 104.

Модуль 182 потоковой передачи из серверного устройства 104 передает в виде потока одно и то же мультимедийное представление к каждому из множества клиентских устройств 102(1), 102(2), …, 102(x). Каждое клиентское устройство 102 имеет проигрыватель 184 аудиовизуальной передаваемой в виде потока информации, который принимает потоковое мультимедийное представление и обрабатывает принятый поток в клиентском устройстве 102, обычно воспроизводя мультимедийное представление в клиентском устройстве 102. Те же самые данные передают в виде потока на каждое клиентское устройство 102 приблизительно в одно и то же время, позволяя серверному устройству 104 передавать в виде потока только один экземпляр одного и того же мультимедийного представления одновременно, при этом различные клиентские устройства 102 «прослушивают» наличие этого представления, которое передают в виде потока.

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

Еще не прошедшая экспертизу заявка на патент № 10/693,430, поданная 24 октября, 2003, "Methods and Systems for Self-Describing Multicasting of Multimedia Presentations", которая включена в настоящее описание посредством ссылки, описывает пример такой среды мультивещания.

Фиг. 4 иллюстрирует пример клиентского и серверного устройств в среде со списком воспроизведения на стороне сервера, которая может передавать в виде потока аудиовизуальный контент, используя сообщение описания сеанса, внедренное в сообщение RTCP, как описано ниже. В некоторых вариантах осуществления протоколы 150, 152 и 154 из фиг. 2 включены в клиентское и серверное устройства согласно фиг. 4, но не проиллюстрированы. Кроме того, хотя не показано на фиг. 3, одно или более дополнительных устройств (например, брандмауэры, маршрутизаторы, шлюзы, мосты и т.д.) могут быть расположены между клиентским устройством 102 и серверным устройством 104.

Модуль 202 потоковой передачи из серверного устройства 104 передает в виде потока мультимедийное представление как передаваемую в виде потока аудиовизуальную информацию 204 проигрывателю 206 потоковой аудиовизуальной информации в клиентском устройстве 102. Проигрыватель 206 потоковой аудиовизуальной информации принимает потоковое мультимедийное представление и обрабатывает принятый поток в клиентском устройстве 102, обычно воспроизводя мультимедийное представление в клиентском устройстве 102.

Серверное устройство 104 включает в себя список 208 воспроизведения, который идентифицирует множество (y) частей аудиовизуального контента 210(1), 210(2), …, 210(y). В некоторых вариантах реализации список 208 воспроизведения включает в себя множество записей, причем каждая запись идентифицирует одну из множества частей аудиовизуального контента 210. Альтернативно, список 208 воспроизведения может идентифицировать одну часть аудиовизуального контента, хотя в таких ситуациях одна часть аудиовизуального контента может просто ссылаться на себя вместо использования списка воспроизведения. Клиентское устройство 102 способно выбрать одиночный ресурс для воспроизведения, при этом этот ресурс идентифицирует список 208 воспроизведения. Модуль 202 потоковой передачи обращается к идентифицированному списку 208 воспроизведения, и затем обращается к индивидуальным частям аудиовизуального контента 210, и передает в виде потока эти части 210 на клиентское устройство 102. Таким образом, клиентское устройство 102 способно обратиться к одиночному ресурсу и все же иметь множество различных частей аудиовизуального контента, передаваемых в виде потока от серверного устройства 104. Поскольку список 208 воспроизведения доступен и указан серверным устройством 104 для идентификации частей аудиовизуального контента, вместо клиентского устройства 102, список 208 воспроизведения может также быть назван как список воспроизведения на стороне сервера.

Каждая часть аудиовизуального контента 210 включает в себя один или более аудиовизуальных потоков. Различные части аудиовизуального контента 210 могут включать в себя различное число аудиовизуальных потоков. Каждая часть аудиовизуального контента 210 обычно является мультимедийным представлением. Способ, которым определена "часть" содержимого, может изменяться в зависимости от выполнения и быть основанным на типе аудиовизуальной информации. Например, для музыкального аудио- и/или видеоконтента каждая песня может быть частью контента. Контент может быть разделен на части по естественным границам (например, различные песни), или, альтернативно, другим произвольным образом (например, каждые пять минут содержимого (контента) - это часть). Для сохраненного контента различные части контента могут быть сохранены как множество файлов или, альтернативно, как один и тот же файл.

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

На Фиг. 2, 3 и 4 показано, что на транспортном уровне данные, которые нужно передавать в виде потока от серверного устройства 104 на клиентское устройство 102, внедрены в пакеты RTP. Управляющая информация, относящаяся к данным, которые передают в виде потока, и пакеты RTP внедряют в одно или более сообщений управления в пакете RTCP.

Как правило, пакет RTCP состоит из нескольких сообщений различных типов. Первое сообщение в пакете RTCP является или Отчетом приемника, или Отчетом отправителя. Второе сообщение является сообщением SDES (Описание источника). Сообщение SDES содержит один или более элементов текстовых мета-данных. Сообщение SDES содержит элемент CNAME (каноническое имя). Элемент CNAME является постоянным идентификатором источника аудиовизуального контента на транспортном уровне и обеспечивает отображение (соответствие) между номером источника синхронизации RTP (SSRC) и текстовой строкой. SSRC является источником потока пакетов RTP (и RTCP). CNAME используется так, чтобы отправитель или приемник, который участвует в множестве сеансов RTP, которые принадлежат одному и тому же представлению, могли использовать различные значения SSRC в каждом сеансе RTP, но сохранять значение CNAME одним и тем же.

Дополнительным типом сообщения, которое может быть включено в пакет RTCP, является сообщение управления, имеющее внедренное в него сообщение описания сеанса. Сообщение описания сеанса описывает свойства мультимедийного представления, которое передают в виде потока от серверного устройства 104 на клиентское устройство 102. Различные форматы аудиовизуальной информации или протоколы могут использоваться для таких сообщений описания сеанса. Пример такого формата аудиовизуальной информации является Протокол описания сеанса (SDP), описание «запроса на комментарии рабочей группы по сетям» (RFC) 2327, апрель 1998. В некоторых вариантах осуществления описанное здесь сообщение описания сеанса является сообщением в соответствии с форматом SDP, описанным в RFC 2327.

Хотя различные форматы могут использоваться для описания свойств мультимедийного представления, одно или более сообщений описания сеанса посылают от серверного устройства 104 на клиентское устройство 102, которые включают в себя идентификатор(ы) свойств. Одиночное сообщение описания сеанса может быть послано серверным устройством 104 для конкретного мультимедийного представления или, альтернативно, может быть послано множество сообщений описания сеанса. Если послано множество сообщений описания сеанса, это множество сообщений могжет включать в себя одну и ту же информацию, различную информацию или "перекрывающуюся" информацию.

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

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

Фиг. 5 иллюстрирует пример формата сообщения 250 управления RTCP, имеющего внедренное сообщение описания сеанса. Сообщение 250 RTCP описано ниже как включающее в себя множество полей (также называемых частями), причем каждое хранит различные данные. Должно быть понятно, что эти поля могут быть расположены в отличном порядке, чем порядок, в котором они описаны ниже и показаны на фиг. 5. Дополнительно, хотя размеры или длины этих полей (например, в битах) описаны ниже, должно быть понятно, что это является только примером, и поля альтернативно могут быть больше или меньше, чем эти примеры размеров или длины. В некоторых вариантах осуществления сообщение 250 RTCP включает в себя все поля, показанные на фиг. 5. В дополнительных вариантах осуществления сообщение 250 RTCP включает в себя меньшее количество, чем все поля, показанные на фиг. 5, или может включать в себя дополнительные поля, не показанные на фиг. 5.

Поля сообщения 250 RTCP могут быть рассмотрены как сгруппированные в три группы: заголовок 290, блок 292 RTP-состояния и сообщение 284 описания сеанса. Заголовок 290 включает в себя различную информацию о сообщении 250 RTCP. Блок 292 RTP-состояния является необязательным и когда включен, используется для идентификации RTP-специфической информации о потоке мультимедийного представления, которое описано в сообщении описания сеанса (например, для определения SSRC и начального номера RTP-последовательности потока в сообщении описания сеанса). Как правило, один блок 292 RTP-состояния связан с и включен в сообщение 250 RTCP для каждого потока аудиовизуальной информации в мультимедийном представлении. Сообщение 284 описания сеанса является сообщением описания сеанса, внедренным в сообщение 250 RTCP.

Поле 252 V (версия) - 2-битовое поле, которое идентифицирует версию используемого RTP, которое является тем же в пакетах RTCP, что и в пакетах RTP. Например, версия, определенная с помощью RFC 3550 - 2.

Поле 254 P (заполнение) - одиночный бит, который, если установлен (например, равным значению 1), указывает, что сообщение 250 RTCP содержит некоторое дополнительное заполнение в конце, которое не является частью информации управления. Это заполнение включено в поле 262 длины, но иначе должно игнорироваться. Величина заполнения включена непосредственно в заполнение. В некоторых вариантах реализации дополнительное заполнение задается в октетах, и последний октет заполнения является значением того, сколько заполняющих октетов включено (включая его самого) и, таким образом, должно игнорироваться.

Поле 256 C поле (сжатие) - одиночный бит, который, если установлен (например, равным значению 1), указывает, что данные в поле 284 данных SDP были сжаты. Различные типы сжатия могут использоваться, такие как использования сжатия Zlib, как описано в версии 3.3 Спецификации Формата ZLIB сжатых данных, в описании «запроса на комментарии рабочей группы по сетям» (RFC) 1950, Май 1996.

Поле 258 Res (зарезервировано) - 4-битовое зарезервированное поле. В некоторых вариантах реализации поле 258 Res должно быть установлено в ноль.

Поле 260 заголовка PT (тип полезных данных) - 7-битовое поле, установленное равным значению (например, 141), чтобы указать, что сообщение 250 RTCP внедряет сообщение описания сеанса.

Поле 262 длины - 16-битовое поле, которое идентифицирует длину сообщения 250 RTCP. Эта длина может быть сгенерирована, суммируя длины различных полей в сообщении 250 RTCP, включая любые заголовки и любое заполнение. В некоторых вариантах реализации длина идентифицируется в 32-битовых значениях минус один.

Поле 262 SDPMsgHash (хэш-функция сообщения SDP) - 16-битовое поле, используемое для идентификации сообщения описания сеанса, включенное в сообщение 250 RTCP, и адреса (например, IP-адрес) отправителя (например, серверное устройство 104). В некоторых вариантах реализации идентификатор в поле 264 вычисляется как контрольная сумма по сообщению описания сеанса и адресу так, чтобы при наличии любых изменений значения идентификатора в поле были также изменены. В некоторых вариантах реализации значение поля 264 SDPMsgHash вычисляется ,так же как поле "значение хэш-функции идентификатора сообщения", описанное в Протоколе Объявления Сеанса (SAP), в описании «запроса на комментарии рабочей группы по сетям» (RFC) 2974, октябрь 2000. Если сообщение описания сеанса фрагментировано по множеству сообщений RTCP, как описано ниже, значения поля 264 SDPMsgHash каждого фрагмента должны быть идентичны.

Поле 266 F (более фрагментов) - одиночный бит, который, если установлен (например, имеет значение 1), указывает, что сообщение описания сеанса было фрагментировано во множество сообщений RTCP, и что текущее сообщение RTCP не содержит последнего фрагмента сообщения описания сеанса. Если поле 266 F не установлено (например, имеет значение 0), то сообщение описания сеанса не было фрагментировано (все сообщение описания сеанса включено в сообщение 250 RTCP), или сообщение описания сеанса было фрагментировано, и сообщение 250 RTCP содержит последний фрагмент сообщения описания сеанса.