ПРОТОКОЛ КОММУТАЦИИ СМЕСИ МУЛЬТИМЕДИЙНЫХ ДАННЫХ ДЛЯ УПРАВЛЕНИЯ МУЛЬТИМЕДИЙНЫМИ ДАННЫМИ Российский патент 2013 года по МПК G06F9/44 

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

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

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

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

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

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

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

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

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

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

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

На фиг.3 изображена альтернативная система для модификации режима алгоритма смешивания.

На фиг.4 изображен иллюстративный микшер для коммутации входных потоков в выходные потоки на уровне алгоритма смешивания.

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

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

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

На фиг.8 изображен способ манипуляции базовыми алгоритмами смешивания микшера мультимедийных данных для повторной коммутации потоков мультимедийных данных сеанса.

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

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

Подробное описание

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

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

На фиг.1 изображена машинно-реализуемая система 100 управления мультимедийными данными (media) для модификации режима алгоритма смешивания. Система 100 включает в себя один или несколько алгоритмов 102 смешивания микшера 104 мультимедийных данных для смешивания входных потоков 106 мультимедийных данных согласно одному или нескольким режимам 108 смешивания. Микшер 104 является логическим субъектом (entity), принимает набор потоков мультимедийных данных идентичного типа (например, аудиоданных), объединяет мультимедийные данные специфическим для типа способом и перераспределяет результат в один выход или множество выходов (например, участнику(ам) сеанса). Система 100 также включает в себя интерфейс 110 протокола, который включает в себя одну или несколько инструкций 112 для изменений режима 108 смешивания алгоритма(ов) 102 смешивания, для коммутации входных потоков 106 мультимедийных данных для вывода одного или нескольких конкретных выходных потоков 114 мультимедийных данных.

Одна или несколько инструкций 112 интерфейса 110 протокола обеспечивают модификацию алгоритмов 102 смешивания для воздействия на режим(-ы) 108 смешивания для однозначной идентификации потока мультимедийных данных, отправляемого в субъект, или однозначной идентификации потока мультимедийных данных, принимаемого из субъекта, для коммутации входных потоков мультимедийных данных в микшер мультимедийных данных в конкретный выходной поток без порта микшера или функций управления IP и для предоставления информации о коммутации субъекту согласно некоторой политике. Политика может быть политикой предприятия, создаваемой и устанавливаемой администратором, например.

Одна или несколько инструкций 112 интерфейса 110 протокола также обеспечивают изменение в участии сеанса в отношении участников с удалением, по меньшей мере, одного из многих основных участников из сеанса или добавлением нового участника к сеансу. Интерфейс 110 протокола включает в себя одну или несколько инструкций 112 для уведомления основных участников об изменении в участии в сеансе. Например, если основные участники A, B и C присутствуют в конференцсвязи, и участник A запросил просмотр видеопотока участника B, то участнику C не обеспечивают возможность знать то, что участник A наблюдает за участником B. Однако участнику B может быть обеспечена возможность знать, что участник A наблюдает за потоком мультимедийных данных участника B. Интерфейс 110 протокола включает в себя одну или несколько инструкций 112 для добавления входного потока мультимедийных данных нового участника к сеансу и для представления информации о субъекте нового участника основным участникам.

В одной реализации интерфейс 110 протокола включает в себя новый набор инструкций для взаимодействия с алгоритмами 102 смешивания для формирования режима(-ов) 108 смешивания. В альтернативной реализации одна или несколько инструкций 112 включают в себя расширения существующего набора управляющих элементов (controls) для формирования режима(-ов) 108 смешивания. Новый набор инструкций и/или расширений управляющих элементов основан на схеме, которая включает в себя один или несколько элементов схемы из маршрута (route), коммутации (wire) и фильтра (filter).

На фиг.2 изображена мультимедийная система 200, в которой устройство 202 управления мультимедийными данными включает в себя компонент 204 микшера мультимедийных данных для смешивания входных потоков согласно изменениям базовых алгоритмов смешивания. Здесь, компонент 204 микшера мультимедийных данных включает в себя два микшера: первый микшер 206 для приема входного(ых) потока(ов) 208 мультимедийных данных первого типа (например, аудиоданных) для коммутации (или маршрутизации) в выходной поток 210 мультимедийных данных идентичного типа и второй микшер 212 для приема входного(ых) потока(ов) 214 мультимедийных данных второго типа (например, видеоданных) для коммутации (или маршрутизации) в выходной поток 216 мультимедийных данных идентичного типа. Первый микшер 206 мультимедийных данных включает в себя первый алгоритм 218 смешивания для формирования первого режима 220 смешивания.

Пользователь может манипулировать первым алгоритмом 218 смешивания для изменения первого режима 220 смешивания через интерфейс 110 протокола при передаче одной или нескольких инструкций 112 в первый алгоритм 218 смешивания первого микшера 206 мультимедийных данных. Аналогично, второй микшер 212 мультимедийных данных включает в себя второй алгоритм 222 смешивания для формирования второго режима 224 смешивания. Пользователь может манипулировать вторым алгоритмом 222 смешивания для изменения второго режима 224 смешивания через интерфейс 110 протокола при передаче одной или нескольких инструкций 112 во второй алгоритм 222 смешивания второго микшера 212 мультимедийных данных.

Одна или несколько инструкций 112 обеспечивают модификацию алгоритмов 102 смешивания для коммутации входных потоков (208 и 214), как требуется. Одна или несколько инструкций 112 управляют режимом(-ами) (220 и 224) смешивания для однозначной идентификации потока мультимедийных данных, отправляемого в субъект, или однозначной идентификации потока мультимедийных данных, принимаемого из субъекта, для коммутации входных потоков мультимедийных данных в микшер мультимедийных данных в конкретный выходной поток без порта микшера или функций управления IP, и для предоставления информации о коммутации субъекту согласно некоторой политике.

Система 200 обеспечивает коммутацию одного входного потока (например, потока(ов) 208 и 214) из точки в точку, из точки во множество точек, из множества точек во множество точек и из множества точек в одну точку. Система 200 может использоваться как узел сети (например, сервер) и/или как клиент в клиентской вычислительной системе, например.

На фиг.3 изображена альтернативная система 300 для модификации режима алгоритма смешивания. Система 300 включает в себя устройство 302 управления мультимедийными данными, содержащее микшер 304 мультимедийных данных из приема входного потока 306 мультимедийных данных, и маршрутизацию входного потока 306 в выходной поток 308 мультимедийных данных согласно модифицированным режимам смешивания. Более конкретно, микшер 304 мультимедийных данных включает в себя алгоритм 310 смешивания аудиоданных для смешивания аудиоданных (во входном потоке) 306 и алгоритм 312 смешивания видеоданных для смешивания видеоданных (во входном потоке) 306 мультимедийных данных. Микшер 304 мультимедийных данных включает в себя интерфейс 110 протокола для обработки инструкций 112 протокола из интерфейса 314 управления. Другими словами, пользователь может взаимодействовать через интерфейс 314 управления для отправки одной или нескольких инструкций 112 через интерфейс 110 протокола для модификации базового алгоритма 310 смешивания аудиоданных и/или базового алгоритма 312 смешивания видеоданных.

Алгоритмы (310 и 312) смешивания формируют режимы смешивания, которые обрабатываются компонентом 316 маршрутизации для маршрутизации входного потока 306 мультимедийных данных в выходной поток 308 мультимедийных данных. Компонент 316 маршрутизации принимает и обрабатывает сформированный режим 318 смешивания аудиоданных из алгоритма 310 смешивания аудиоданных и режим 320 смешивания видеоданных из алгоритма 312 смешивания видеоданных. Другими словами, входной поток 306 мультимедийных данных может быть смешан с аудио- и/или видеосигналами для маршрутизации как смешанного выходного потока 308 мультимедийных данных в выходной субъект.

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

На фиг.4 изображен иллюстративный микшер 104 для коммутации входных потоков в выходные потоки на уровне алгоритма смешивания. Микшер 104 принимает входные (или вход-микшер (to-mixer)) потоки 400 мультимедийных данных и смешивает входные потоки 400 согласно алгоритму 310 смешивания видеоданных и алгоритму 320 смешивания аудиоданных для вывода выходных (или выход-микшер (from-mixer)) потоков 402 мультимедийных данных. Модификация алгоритмов (310 и 320) смешивания может происходить через интерфейс 110 протокола.

Входные потоки 400 могут идентифицироваться посредством идентификационной информации для пользователя и типа потока мультимедийных данных, например идентификатора пользователя (userID=xx) и идентификатора потока мультимедийных данных (ID=xx). В этом примере типы входного потока мультимедийных данных ID=30, ID=31 и ID=32 и userID=2 могут быть для основного аудиопотока, основного видеопотока и вторичного видеопотока второго участника сеанса (или оконечной точки (endpoint)) соответственно. Аналогично, типы входного потока мультимедийных данных ID=24 и ID=31 связаны с userID=3 для основного аудиопотока и основного видеопотока третьего участника сеанса (или оконечной точки) соответственно. Другие входные потоки 400 могут быть частью сеанса конференцсвязи.

Параметр "label" ("метка") идентифицирует поток мультимедийных данных в микшер 104 и из него. Как обозначено ранее, входные потоки 400 в микшер 104 (от конкретного пользователя и оконечной точки) идентифицируются по ID в модели данных конференцсвязи. Метка является уникальной во всей модели данных конференцсвязи. ID является уникальным внутри элемента мультимедийных данных оконечной точки в модели данных и формируется сервером конференцсвязи.

Будем считать, что label=10 является потоком, содержащим смесь аудиопотоков из всех входных аудиопотоков, предлагаемых каждому участнику сеанса, label=11 включает в себя смесь видеоданных, и что label=12 является чередующейся смесью видеопотков, которая активизируется голосом. Микшер 104 смешивает входящие видеопотки 400 от участников в оба выходных потока label=12 и label=11. Это является одним примером модели микшера, другие модели микшера могут интерпретировать входные потоки по-другому. Однако введение интерфейса 110 протокола обеспечивает модификацию алгоритмов смешивания согласно раскрытой архитектуре. Интерфейс 110 протокола может принимать изменение или модификации алгоритмов (310 и 320) смешивания посредством XML, например, и/или команд CCCP (centralized conference control protocol, протокол управления централизованной конференцсвязью).

На фиг.5 изображено иллюстративное определение 500 схемы для протокола, который может получать доступ к режиму смешивания и модифицировать его в базовых алгоритмах смешивания. Определение 500 схемы может быть следующим. В одной реализации схема определяет новые расширения управляющих элементов (например, маршрут, коммутацию и фильтр) из управляющих элементов, которые определены в модели данных централизованной конференцсвязи (XCON). На недавно добавленные элементы к определению 500 схемы даны ссылки в нижеследующем структурном виде посредством "##", и они очерчены как 502 для ввода в микшер и 504 как выход микшера.

Ниже приведен ряд примеров, которые иллюстрируют способы, в которых архитектура протокола обеспечивает коммутацию мультимедийных данных. Данные, содержащиеся внутри такой схемы, представлены в следующем примере. Рассмотрим сеанс конференцсвязи с состоянием мультимедийных данных, изложенном ниже, для конференцсвязи sip:conf233@example.com, размещенной в MCU

.

<!-это является заданным по умолчанию потоком для foo@example.com-->

<!-это является потоком, где foo@example.com требует манипуляции смешивающимися маршрутами-->

<!-Примечание: Маршруты мультимедийных данных здесь не определены-->

<!-это является заданным по умолчанию потоком для foo@example.com->

Ниже приведен пример команды (команд) CCCP для модификации маршрута мультимедийных данных для участника. Будем считать, что субъекту sip:foo@example.com требуется модифицировать маршрут мультимедийных данных согласно потоку. Субъект может выполнять это посредством выдачи следующей команды CCCP "modifyEndpointMedia" (модифицировать мультимедийные данные оконечной точки). В следующем примере представлен запрос, который делает foo@example.com для приема потоков из bar1@contoso.com и bar2@fabrikam.com (Спецификация XMLNS опущена для удобочитаемости)

(здесь была спецификация xmlns)

<!-Примечание: Модифицированная таблица маршрутизации-->

Ответ может быть следующим:

(здесь была спецификация xmlns)

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

<!-Примечание: Модифицированная таблица маршрутизации в уведомлении C3P-->

В отношении опции упорядоченного опроса, если в отношении предыдущей опции уведомления учитываются размеры, и/или не существует возможности, чтобы система отфильтровывала элементы, которые требуют функций конфиденциальности, то может использоваться механизм упорядоченного опроса для извлечения маршрута коммутации. Упомянутый механизм возвращает список пользователей и оконечных точек (участников сеанса), которые наблюдают за конкретным потоком оконечной точки. В примере ниже иллюстрируется команда, которая может использоваться для извлечения состояния наблюдателя за мультимедийными данными для bar1@contoso.com и оконечной точки sip:bar1@contoso.com;gr=4940254792 с media id=56. Так как foo@example.com является единственным субъектом, наблюдающим за потоком, то возвращается информация об оконечной точке и субъекте этого пользователя.

(здесь была спецификация xmlns)

Ответ может быть следующим:

<!-Примечание: Не существует других элементов XML, возвращаемых под оконечной точкой или пользователем, или пользователями. -->

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

(здесь была спецификация xmlns)

<!-Примечание: Модифицированная таблица маршрутизации->

Ответ может быть следующим:

(здесь была спецификация xmlns)

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

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

Для адаптации опции уведомления Уведомитель (определенный в RFC 3265 и RFC 4353 как агент пользователя, который формирует запросы Уведомить с целью уведомления абонентов о состоянии ресурса) фильтрует определенные элементы, исходя из того, куда отправляется уведомление. Если конфиденциальность не учитывается, то Уведомитель может отправлять эту информацию всем участникам или может предпочесть совсем не отправлять информацию.

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

На фиг.6 изображен способ управления потоками мультимедийных данных. На этапе 600 входной поток мультимедийных данных сеанса конференцсвязи коммутируется в оконечную точку согласно режиму смешивания, определяемому алгоритмом смешивания. На этапе 602 с использованием протокола инструкций получают доступ к алгоритму смешивания. На этапе 604 алгоритм смешивания изменяют с использованием протокола для повторной коммутации входного потока мультимедийных данных согласно новому режиму смешивания.

На фиг.7 изображен способ манипуляции базовыми алгоритмами смешивания микшера мультимедийных данных для повторной коммутации потоков мультимедийных данных сеанса. На этапе 700 с использованием протокола можно получить доступ к базовому(ым) алгоритму(ам) смешивания. На этапе 702 с использованием протокола может быть однозначно идентифицирован входной поток, отправляемый в оконечную точку или принимаемый из оконечной точки. На этапе 704, по выбору, повторно задают коммутацию входного потока мультимедийных данных оконечной точки на выходе для включения смеси других входных потоков (из) других оконечных точек без функций, связанных с портами и данными IP, с использованием протокола. На этапе 706, по выбору, задают коммутацию входного потока мультимедийных данных оконечной точки в конкретные выходные потоки мультимедийных данных соответствующих оконечных точек с использованием протокола.

На фиг.8 изображен способ манипуляции базовыми алгоритмами смешивания микшера мультимедийных данных для повторной коммутации потоков мультимедийных данных сеанса. На этапе 800 к базовому(ым) алгоритму(ам) смешивания можно получить доступ с использованием протокола. На этапе 802 с использованием протокола задается передача коммутации участникам сеанса. На этапе 804 задается передача коммутации участникам сеанса с использованием протокола и согласно политике сеанса. На этапе 806 с использованием протокола лидером сеанса задается изменение в смеси участников сеанса конференцсвязи.

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

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

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

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

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

Согласно фиг.9 иллюстративная вычислительная система 900 для реализации различных аспектов включает в себя компьютер 902, содержащий процессор 904, системную память 906 и системную шину 908. Системная шина 908 обеспечивает интерфейс для системных компонентов, включающих в себя, например, системную память 906 для процессора 904. Процессор 904 может быть любым из различных серийно выпускаемых процессоров. Сдвоенные микропроцессоры и другие многопроцессорные архитектуры также могут использоваться в качестве процессора 904.

Системная шина 908 может быть шинной структурой любого из нескольких типов, которая также может соединяться с шиной памяти (посредством контроллера памяти или без него), шиной периферийных устройств и локальной шиной с использованием любой из множества серийно выпускаемых шинных архитектур. Системная память 906 может включать в себя энергонезависимую память (NON-VOL) 910 и/или энергозависимую память 912 (например, оперативное запоминающее устройство (RAM)). Базовая система ввода-вывода (BIOS) может храниться в энергонезависимой памяти 910 (например, ROM, EPROM, EEPROM и т.д.), причем BIOS является стандартными программами, которые способствуют передаче информации между элементами внутри компьютера 902, например, во время запуска. Энергозависимая память 912 может также включать в себя высокоскоростное RAM, например, статическое RAM для кэширования данных.

Компьютер 902 также включает в себя внутренний накопитель на жестких дисках (HDD) 914 (например, EIDE, SATA), внутренний HDD 914 которого может также быть выполнен с возможностью внешнего использования в подходящем корпусе, накопитель на гибких магнитных дисках (FDD) 916 (например, для считывания со съемной дискеты 918 или записи на нее) и накопитель 920 на оптических дисках (например, считывающий диск 922 CD-ROM или для считывания с других оптических носителей информации большой емкости, например, DVD, или записи на них). HDD 914, FDD 916 и накопитель 920 на оптических дисках могут быть соединены с системной шиной 908 интерфейсом 924 HDD, интерфейсом 926 FDD и интерфейсом 928 накопителя на оптических дисках, соответственно. Интерфейс 924 HDD для реализаций внешнего накопителя может включать в себя, по меньшей мере, одну или обе из технологий интерфейса IEEE 1394 и универсальной последовательной шины (USB).

Накопители и относящиеся к ним машиночитаемые носители информации обеспечивают энергонезависимое запоминающее устройство данных, структур данных, исполнимых компьютером инструкций и т.д. Для компьютера 902 накопители и носители информации обеспечивают хранение любых данных в соответствующем цифровом формате. Хотя приведенное выше описание машиночитаемых носителей информации относится к HDD, съемной магнитной дискете (например, FDD) и съемным оптическим носителям информации, например CD или DVD, специалистам в данной области техники должно быть понятно, что другие типы носителей информации, с которых может считывать компьютер, например zip-накопители, магнитофонные кассеты, платы флэш-памяти, кассеты и т.п., могут также использоваться в иллюстративной рабочей среде, и также, что любые такие носители информации могут содержать исполнимые компьютером инструкции для выполнения новых способов раскрытой архитектуры.

Несколько программных модулей могут храниться в накопителях и энергозависимой памяти 912, в том числе операционная система 930, одна или несколько прикладных программ 932, другие программные модули 934 и данные 936 программ. Одна или несколько прикладных программ 932, другие программные модули 934 и данные 936 программ могут включать в себя алгоритмы 102 смешивания, микшер 104 мультимедийных данных, входные потоки 106 мультимедийных данных, режима 108 смешивания, интерфейс 110 протокола, инструкции 112 протокола, выходные потоки 114 мультимедийных данных, алгоритм 310 смешивания аудиоданных, алгоритм 320 смешивания видеоданных, входные потоки 400 мультимедийных данных, выходные потоки 402 мультимедийных данных и схему 500, например.

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

Пользователь может вводить команды и информацию в компьютер 902 посредством одного или нескольких проводных/беспроводных устройств ввода, например клавиатуры 938 и указательного устройства, например мыши 940. Другие устройства ввода (не изображены) могут включать в себя микрофон, инфракрасный пульт дистанционного управления, джойстик, игровой планшет, перо, сенсорный экран и т.п. Эти и другие устройства ввода часто соединены с процессором 904 через интерфейс 942 устройства ввода, который соединен с системной шиной 908, но могут быть соединены посредством других интерфейсов, например параллельного порта, последовательного порта IEEE 1394, игрового порта, порта USB, инфракрасного интерфейса и т.д.

Монитор 944 или дисплей другого типа также соединен с системной шиной 908 через интерфейс, например видеоадаптер 946. Наряду с монитором 944, компьютер, как правило, содержит другие периферийные устройства вывода (не изображены), например динамики, принтеры и т.д.

Компьютер 902 может функционировать в сетевой среде с использованием логических соединений посредством проводной и/или беспроводной связи с одним или несколькими удаленными компьютерами, например, удаленным(и) компьютером(ами) 948. Удаленный(ые) компьютер(ы) 948 может (могут) быть рабочей станцией, серверным компьютером, маршрутизатором, персональным компьютером, портативным компьютером, развлекательным оборудованием на основе микропроцессора, одноранговым устройством или другим обычным узлом сети и, как правило, включает в себя многие или все элементы, описанные в отношении компьютера 902, хотя, для краткости, иллюстрируется только память/запоминающее устройство 950. Изображенные логические соединения включают в себя проводную/беспроводную связь с локальной сетью (LAN) 952 и/или большими сетями, например глобальной сетью (WAN) 954. Такие сетевые среды WAN и LAN являются обычными для офисов и компаний и обеспечивают компьютерные сети в масштабах предприятия, например интранет, все из которых могут быть соединены с глобальной сетью связи, например Интернет.

При использовании в сетевой среде LAN компьютер 902 соединен с LAN 952 посредством адаптера 956 или интерфейса проводной и/или беспроводной сети связи. Адаптер 956 может обеспечивать проводную и/или беспроводную связь с LAN 952, которая может также содержать точку беспроводного доступа, расположенную в ней, для осуществления связи с беспроводными функциональными возможностями адаптера 956.

При использовании в сетевой среде WAN компьютер 902 может содержать модем 958, или быть соединенным с сервером связи в WAN 954, или содержать другие средства для установления связи через WAN 954, например, посредством Интернета. Модем 958, который может быть внутренним или внешним и проводным и/или беспроводным устройством, соединен с системной шиной 908 через интерфейс 942 устройства ввода. В сетевой среде изображенные программные модули, относящиеся к компьютеру 902, или их части, могут храниться в удаленной памяти/запоминающем устройстве 950. Будет понято, что изображенные сетевые соединения являются иллюстративными, и могут использоваться другие средства установления линии связи между компьютерами.

Компьютер 902 функционирует для осуществления связи с проводными и беспроводными устройствами или субъектами с использованием семейства стандартов IEEE 802, например беспроводными устройствами, функционально размещенными в беспроводной связи (например, способы беспроводной модуляции IEEE 802.11), например с принтером, сканером, настольным компьютером и/или портативным компьютером, персональным цифровым секретарем (PDA), спутником связи, любой частью оборудования или местом расположения, связанным с меткой, обнаруживаемой беспроводным способом (например, киоском, газетным киоском, туалетом), и телефоном. Это включает в себя, по меньшей мере, беспроводные технологии Wi-Fi (или беспроводная достоверность), WiMax и Bluetooth™. Соответственно, связь может быть предопределенной структурой, как с обычной сетью, или просто связью, созданной для данного случая (ad hoc), по меньшей мере, между двумя устройствами. Сети Wi-Fi используют радиотехнологии, называемые IEEE 802.11x (a, b, g и т.д.), для обеспечения безопасной, надежной, быстрой беспроводной связи. Сеть Wi-Fi может использоваться для соединения компьютеров друг с другом, с Интернетом и с проводными сетями (которые используют функции и среды, связанные с IEEE 802.3).

Согласно фиг.10 на ней изображена схематическая блок-схема иллюстративной клиент-серверной вычислительной среды 1000 для получения доступа к базовым алгоритмам смешивания с использованием некоторого протокола доступа. Среда 1000 включает в себя один клиент или несколько клиентов 1002. Клиент(ы) 1002 может (могут) быть аппаратным обеспечением и/или программным обеспечением (например, потоками, процессами, вычислительными устройствами). Клиент(ы) 1002 может (могут) содержать куки-файл(ы) и/или связанную контекстную информацию, например.

Среда 1000 также включает в себя один сервер или несколько серверов 1004. Сервер(ы) 1004 также может (могут) быть аппаратным обеспечением и/или программным обеспечением (например, потоками, процессами, вычислительными устройствами). Серверы 1004 могут содержать потоки для выполнения преобразований с применением упомянутой архитектуры, например. Одна возможная связь между клиентом 1002 и сервером 1004 может быть в виде пакета данных, адаптированного для передачи между двумя или несколькими компьютерными процессами. Пакет данных может включать в себя куки-файл и/или связанную контекстную информацию, например. Среда 1000 включает в себя инфраструктуру 1006 связи (например, такую глобальную сеть связи, как Интернет), которая может использоваться для обеспечения связи между клиентом(ами) 1002 и сервером(ами) 1004.

Связь может быть обеспечена посредством проводной (включающей в себя оптоволокно) и/или беспроводной технологии. Клиент(ы) 1002 функционально соединен(ы) с одним хранилищем или несколькими хранилищами 1008 данных клиента, который(ые) может (могут) использоваться для хранения информации, локальной для клиента(ов) 1002, (например, куки-файла(ов) и/или связанной контекстной информации). Аналогично, сервер(ы) 1004 функционально соединяется(ются) с одним хранилищем или несколькими хранилищами 1010 данных сервера, который(ые) может (могут) использоваться для хранения информации, локальной для серверов 1004.

Сервер(ы) 1004 может (могут) содержать алгоритмы 102 смешивания, микшер 104 мультимедийных данных, входные потоки 106 мультимедийных данных, режима 108 смешивания, интерфейс 110 протокола, инструкции 112 протокола, выходные потоки 114 мультимедийных данных, устройство 202 управления мультимедийными данными, компонент 204 микшера мультимедийных данных, микшери (206 и 212) мультимедийных данных, алгоритмы (218 и 222) смешивания и соответствующие режима (220 и 224) смешивания, алгоритм 310 смешивания аудиоданных, алгоритм 320 смешивания видеоданных, входные потоки 400 мультимедийных данных, выходные потоки 402 мультимедийных данных и схему 500, например. Клиент(ы) 1002 может (могут) также содержать несколько или все субъекты, описанные для сервера(ов) 1004, кроме MCU, которое является, как правило, сетевым субъектом.

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

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

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

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

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

4. Система по п.1, в которой интерфейс протокола включает в себя одну или более инструкций для предоставления информации о коммутации субъекту на основе политики.

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

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

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

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

9. Система по п.1, в которой интерфейс протокола и алгоритм смешивания используются в устройстве управления мультимедийными данными.

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

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

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

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

14. Способ по п.13, дополнительно содержащий этап, на котором задают изменения алгоритма смешивания с использованием файла XML или команд CCCP.

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

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

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

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

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

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

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