Идентификация активного говорящего участника



Идентификация активного говорящего участника
Идентификация активного говорящего участника
Идентификация активного говорящего участника
Идентификация активного говорящего участника

 


Владельцы патента RU 2483452:

МАЙКРОСОФТ КОРПОРЕЙШН (US)

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

 

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

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

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

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

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

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

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

Перечень фигур чертежей

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

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

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

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

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

Описание предпочтительных вариантов осуществления

Обзор

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

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

Иллюстративная среда

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

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

Для аудио-события, включающего в себя Клиентов 106 "A", 108 "B", 110 "C", 112 "D" и 114 "E", в котором Клиенты 106 "A" и 114 "E" способствуют вводу аудио (так как Клиенты 106 и E 114 продолжают разговор), неактивным Клиентам 108 "B", 110 "C", 112 "D" может быть предоставлен отправленный от медиа-сервера 102 поток "A+E", или комбинация двух говорящих, в то время как Клиенты 106 "A" и 114 "E" соответственно принимают противоположную часть отправленного от медиа-сервера 102 потока (например, Клиент 106 "A" принимает отправленный Клиентом "E" поток, в то время как Клиент 114 "E" - отправленный Клиентом 106 "A" поток). Применяемые клиентские устройства включают в себя, но не ограничены ими, телефоны с передачей голоса по IP-протоколу (VoIP), вычислительное устройство с поддержкой аудио, телефоны коммутируемой телефонной сети общего пользования (PSTN), телефоны, подключенные через шлюз к цифровой аудио-сессии, и так далее.

В некоторых реализациях активно говорящим может не предоставляться сигнал, включающий в себя отправленный самими говорящими поток для того, чтобы избежать обратной связи или эха (например, Клиенту 106 "A" может не отправляться аудио-поток, содержащий аудио Клиента "A"). Можно рассмотреть несколько основных сценариев идентификации, например, Клиент A может "переговорить" Клиента E (так, как если ассоциированный с Клиентом 106 А участник говорит громко, в то время как Участник "E" (ассоциированный с Клиентом 114 E) говорит относительно нормальным голосом), Участники "А" и "E" занимаются быстрым обменом, в котором говорящий в настоящее время меняется между двумя участниками, либо Участник "А" преобладает в разговоре, в то время как Участвующий "E" предоставляет относительно меньший ввод информации. Пример последней ситуации может включать в себя участника, который добавляет незначительные подтверждения к преобладающему монологу основного говорящего.

В реализациях медиа-сервер 102 может определить доминирующего клиента (и, соответственно, говорящего), основываясь на количестве принятых от клиента пакетов, когда принят аудио-контент, размере пакета, уровне энергии аудио и так далее. Таким образом, хотя два или более клиента предоставляют контент одновременно, один активный клиент может быть обозначен как доминирующий клиент (и, соответственно, говорящий), основываясь на вышеупомянутых факторах. Например, медиа-сервер 102 может определить текущего активного клиента (и ассоциированного говорящего), основываясь на включающих в себя аудио-контент текущих пакетах данных, принятых от активного клиента, в сочетании со смешиванием и/или переключением между входными данными, принятыми от отличающихся клиентов. Например, медиа-сервер 102 может обозначить Клиента 106 А, как текущего "активного" клиента, если Клиент E в настоящее время не предоставляет пакеты данных. В других случаях, если и Клиент 106 A и Клиент 114 E являются активными, но Клиент 106 A предоставляет аудио-контент с большим уровнем энергии, чем Клиент 114 E (то есть, участник A говорит громко, в то время как E говорит тише), Клиент 106 А может быть обозначен как доминирующий активный говорящий. Клиенты могут быть обеспечены списком активных клиентов, который начинается с Клиента 106 А. Этот тип определения может быть сделан во время смешивания/переключения аудио-потоков клиентского ввода для одной или более продолжающихся конференций. Например, процессор медиа-сервера 102, может проводить различие между активными клиентами, задействуя алгоритм смешивания, в то время как модуль 116 идентификации может быть использован для того, чтобы вставить информацию в подходящие пакеты данных.

С основной ссылкой на Фиг.2, в реализациях, когда реализуют протокол транспортного уровня в реальном времени (RTP) и ассоциированный протокол управления в реальном времени (RTCP), медиа-сервер 102 может идентифицировать активных клиентов и, соответственно, активно говорящих, исследуя данные в рамках отправленных от клиентов потоков, включающих в себя транспортируемые данные и сигнальные потоки. В случае Клиента 106 A медиа-сервер 102 может идентифицировать, что отправленный клиентом аудио-поток исходит от Клиента 106 А, с помощью исследования поля источников синхронизации (SSRC) в пределах пакета RTP или из SSRC Клиента (идентификатор для клиента в пределах сессии) и канонического имени (CNAME), включенного в отчет RTCP. Также может быть исследована другая информация. SSRC также может быть получен из заголовка пакета RTP. Например, SSRC может быть приведен в соответствие с CNAME в отчете RTCP.

В то время как сигнализация RTCP может использоваться для того, чтобы идентифицировать потерянные пакеты, обеспечивая качество транспортировки данных и так далее, отчет RTCP может быть получен из внеполосных сигналов RTCP. Например, отчет RTCP может включать в себя произвольно сформированный SSRC клиента, приведенный в соответствие с CNAME клиента. Как правило, CNAME является идентификатором/записью, который ассоциирован с псевдонимами, используемыми для клиентского устройства. В некоторых случаях, CNAME - это строка цифр и т.п. В реализациях медиа-сервером 102 может назначаться SSRC в пределах сессии. В некоторых случаях, SSRC может изменяться для включенного в сессию клиента. Например, SSRC клиента может измениться, если клиент прерывается (например, длинная пауза, а затем отвечает), если SSRC клиентов конфликтуют (появляется больше одного клиента с общим SSRC), и так далее. Таким образом, входной поток данных может быть идентифицирован по SSRC в потоке данных или по сигнализации RTCP. Медиа-сервер 102 может также получить из сигнализации RTCP каноническое имя для использования при идентификации клиента.

При формировании отправляемого потока (включающего в себя выходные аудиоданные), по SSRC и CNAME, полученных от активного клиента, медиа-сервер 102 может идентифицировать, какие клиенты предоставляют аудио-ввод в сессии. Например, медиа-сервер 102 может ассоциировать SSRC, CNAME, вставленные в пакет RTCP c отправляемым потоком аудиоконтента (то есть выходными потоками медиа-сервера, несущими аудиоданные). Возвращаясь к предыдущему примеру сессии между Клиентами 106 "A", 108 "B", 110 "C", 112 "D" и 114 "E", в случае смешанного сигнала "А+E", медиа-сервер 102 может упорядочить Клиентов "A" и "E", в соответствии с тем, какой клиент в настоящее время активен, какой является активным и доминирующим в сессии и тому подобным. Порядок может меняться исходя из клиента, предоставляющего аудио-ввод. В этом случае, список может начинаться с идентификатора Клиента 106 А и включать в себя Клиента 114 E, если Клиент A в настоящее время предоставляет ввод, или если Клиент A доминирует в разговоре. В ситуациях, в которых происходит аудио-обмен между Клиентом 106 А и Клиентом 114 E, прядок может быть изменен, основываясь на говорящем в настоящее время участнике, что указывается на по-пакетной основе.

Со ссылкой на Фиг.2, в конфигурации RTP, модуль 116 идентификации медиа-сервера может вставлять упорядоченный список SSRC в заголовок пакета RTP выходного потока. Например, упорядоченные идентификаторы вставляются (204) в поле списка составляющих источников (CSRC) в заголовке отправляемого в потоке данных пакета. Если Клиент A и Клиент E меняют текущие активные роли, расположение SSRC может измениться от 204(a) "Клиент A, Клиент E…" к 204(b) "Клиент E, Клиент A…". В предыдущей методике клиенты, принимающие поток данных (слушающие клиенты или участники сессии), могут быть информированы относительно того, какие клиенты предоставляют ввод, относительный вклад и так далее, избегая дополнительной сигнализации, связанной с проблемами синхронизации и накладными расходами сети. Например, поле CSRC может иметь возможность включать в себя до пятнадцати идентификаторов по тридцать два бита каждый, при этом оставаясь в соответствии с техническими требованиями. Клиенты, не действующие в соответствии с обсуждаемыми здесь методиками, могут участвовать, не имея обсуждаемых здесь преимуществ. Тем самым создаются обратно совместимые система и методики.

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

Медиа-сервер 102 может вставить CNAME активного клиента в отправляемые клиентам пакеты RTCP (например, таким образом, чтобы другие "слушающие" клиенты могли быть поставлены в известность о CNAME и SSRC активных клиентов). Например, модуль 116 идентификации медиа-сервера может "распределять" идентификаторы активных клиентов, отправляемые "слушающим клиентам" в пакетах RTCP медиа-сервера. Например, если несколько активных клиентов вносят вклад в конференцию, медиа-сервер может вставлять полученные идентификаторы клиентов с определяемыми интервалами в пакеты RTCP, отправляемые вместе с потоком данных медиа-сервера. Тогда как пакеты RTCP могут включать в себя CNAME в каждом пакете. Для того чтобы минимизировать транспортные накладные расходы, CNAME могут быть вставлены в промежутки отправляемых слушающим клиентам пакетов RTCP. Клиенты, принимающие данные RTCP медиа-сервера, включающие в себя идентификаторы активных клиентов, могут сохранять эти данные в локальной памяти так, чтобы CNAME могло быть ассоциировано с пакетами данных, когда принимается аудиоконтент. Например, CNAME, поставленное в соответствие с SSRC, и другая относящаяся информация может быть сохранена в таблице соответствия и т.п. Например, тогда как включенный в поток данных аудио-контент в большинстве случаев может посылаться непрерывно, сигнализация RTCP может появляться только периодически, например, c определенными интервалами (например, с 5 или 10-секундными интервалами). Таким образом, принимающий пакет данных клиент, может ассоциировать SSRC в CSRC с ранее принятым CNAME. В реализациях для того, чтобы идентифицировать конкретного клиента может использоваться универсальный индикатор ресурса глобально маршрутизируемого агента пользователя (GRUU).

В реализациях активный клиент может информироваться, что в конференции этот клиент является активным. Например, участник (ассоциированный с активным клиентом) может желать знать, что он/она не "переговаривает" другого участника. Возвращаясь к сессии между Клиентами 106 "A", 108 "B", 110 "C", 112 "D" и 114 "E", если, например, Клиент 106 А активен, а Клиенты 108 "B", 110 "C", 112 "D" и 114 "E" не активны, это может быть определено посредством отправленного Клиенту A сигнала RTCP. Таким образом, наряду с тем, что медиа-сервер 102 может формировать отправляемый для Клиентов "B", "C", "D" и "E" медиа-поток, при прохождении отправленного потока через Клиента A, в качестве "слушающего" клиента или участника сессии Клиент 106 А может определить, что нет другого активного клиента, основываясь на пакетах CSRC/RTCP.

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

Наряду с тем, что Интернет (Всемирная сеть) может использоваться для подключения клиентов и других компонентов, другие сети и различные линки также применимы. Например, соединяющая медиа-сервер 102 и клиента сеть может включать в себя глобальную сеть (WAN), локальную сеть (LAN), беспроводную сеть, телефонную сеть общего пользования, интранет и так далее. Сеть может быть сконфигурирована для того, чтобы включать в себя множество подсетей.

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

Иллюстративные процедуры

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

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

В реализациях используемый в качестве хоста или центральной точки медиа-сервер может определять (302) клиента аудио-ввода в соответствии с вводом, предоставляемым каждым активным клиентом. Например, определение может быть осуществлено, как часть смешивания и/или переключения вводимого клиентом аудио. Таким образом, Клиент A может быть назначен в качестве основного активного клиента, пока отличающийся клиент не предоставляет аудио-ввод. В еще одном примере Клиент A может быть выбран, если Клиент A и Клиент E вносят вклад, но аудио Клиента A имеет более высокий уровень энергии. Аудио клиента может иметь более высокий уровень энергии, если ассоциированный с клиентом участник говорит громким голосом или говорит в безостановочной манере, как если бы клиент предоставлял доминирующий аудио-ввод.

Вводящий аудио клиент может быть идентифицирован как "высший" клиент, если клиент в настоящее время активен, доминирует в разговоре и так далее. В системах RTP/RTCP, функционирующих в соответствии с настоящими методиками, медиа-сервер может получать (304) потоки клиентского ввода и ассоциированные пакеты RTCP (например, пакеты RTCP, отправленные от клиента), включающие в себя SSRC, поставленный в соответствие с CNAME для конкретного клиента, формирующего поток, включающий в себя аудио-контент. Например, медиа-сервер может получить SSRC и CNAME для клиента. CNAME идентифицирует клиента в сочетании с SSRC. Медиа-сервер может упорядочить (306) SSRC клиентов ввода в соответствии с тем, какие клиенты в настоящее время предоставляют аудио-ввод, доминируют в разговоре и так далее. Например, медиа-сервер может упорядочить идентификаторы SSRC активных клиентов по убыванию, начиная с текущего активного "говорящего", например активного клиента предоставляющего ввод. В примерах, RTP может предоставить возможность идентификации 15 активных говорящих участников, используя включенный в CRSC тридцати двух битный идентификатор на каждого активного клиента.

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

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

Упорядоченные идентификаторы клиента аудио-ввода могут быть вставлены (308) в список в заголовке пакета. Например, если Клиенты "A" и "E" предоставляют аудио-ввод (Клиент А - текущий активный клиент), поле CSRC в заголовке RTP может включать в себя источники SSRC с SSRC Клиента "A", начинающего список. Таким образом, слушающему клиенту (который может включать в себя клиента аудио-ввода, который принимает аудио-ввод от еще одного активного клиента) внутри потока контента может быть сообщена идентификационная информация говорящего. В еще одном примере порядок вводящих аудио клиентов в списке может основываться, по крайней мере, частично, на том, какой клиент аудио-ввода доминирует в медиа-сессии. Факторы доминирования могут включать в себя уровень энергии аудио-ввода, продолжительность ввода, продолжительность периодов молчания, размер пакета и так далее. Например, список может начинаться с Клиента А, потому что Клиент A в настоящее время активен и отправленный Клиентом А поток показывает высокий уровень энергии по сравнению с одним или более другими клиентами аудио-ввода.

Медиа-сервер может отправить (310) слушающему клиенту (клиенту сессии) SSRC и CNAME в отправляемых медиа-сервером потоках (например, в пакетах RTCP, отправленных вместе с транспортируемым контентом). SSRC для клиентов аудио-ввода также может располагаться в поле CSRC в заголовке пакета потоковых данных, в пакетах RTP. Например, если из пяти клиентов медиа-события три участника говорят, SSRC и CNAME клиента, ассоциированные с клиентами аудио-ввода, могут быть включены в пакеты RTCP медиа-сервера (отправляемые слушающим клиентам), ассоциированные с передающими аудио-контент пакетами RTP. Таким образом, медиасервер может отправлять SSRC и CNAME клиентов, идентифицирующие активных аудио-клиентов. Таким образом, слушающий клиент может идентифицировать начальный источник аудиоконтента в соответствии с источниками SSRC и именами CNAME в пакете RTP. SSRC клиента может быть обновлен, если SSRC клиента конфликтует с SSRC, выданным другому клиенту, или если клиент изменяет адрес источника передачи по другой причине. Источники SSRC и имена CNAME могут быть сохранены (312) в локальной памяти так, чтобы слушающий клиент мог получить доступ к информации на всем протяжении медиа-события.

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

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

Может быть сформирован (404) упорядоченный список одного или более активных клиентов в пределах конференции. Например, смешивающий/переключающий поток аудио-ввода медиа-сервер может упорядочить список активных клиентов (идентификаторы SSRC в RTP/RTCP), или тех клиентов, которые предоставляют ввод в конференции или сессии. Например, медиа-сервер является смешивающим аудио/видео сервером (AVMCU), который получает идентификацию SSRC из отправленного активным клиентом потока, который может поочередно включать в себя часть данных и ассоциированную сигнальную часть. Затем AVMCU может определить относительное расположение SSRC активных клиентов или другого идентификатора клиента в пределах сессии. SSRC может быть идентифицирован из отчета RTCP, который может соответствовать CNAME клиента. Например, ранжирование может быть основано на том, какой клиент активен в настоящее время. В других реализациях факторы, такие как уровень энергии, количество предоставленных пакетов данных, продолжительность периодов молчания, размер пакета и так далее, могут быть приняты во внимание. Например, упорядоченный список может начинаться с активного клиента, который может доминировать в сессии из-за количества предоставленных пакетов, в то время как второму активному в тоже время клиенту назначается меньший относительный статус.

Упорядоченный список может быть вставлен (406) в поле списка CSRC, включенное в заголовки пакета, в рамках последовательности операций отправки медиа-сервером потока данных. Например, вывод медиа-сервера включает в себя предоставленное активным клиентом аудио, поле CSRC с упорядоченным списком идентификаторов SSRC активных клиентов. В результате, слушающему клиенту, то есть клиенту, принимающему поток аудиоконтента, может быть сообщено, какие клиенты активны, и сравнительное взаимоотношение активных клиентов. Кроме того, SSRC и CNAME могут быть включены в отправляемые медиа-сервером пакеты RTCP.

SSRC могут быть ассоциированы (408) с CNAME активного аудио-клиента. Например, медиа-сервер может отправлять пакет RTCP, который включает в себя CNAME клиента, связанное с SSRC, включенным в поле CRSC в заголовке пакета RTCP. CNAME может быть получено из пакетов RTCP.

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

В дальнейших реализациях, GRUU может быть ассоциирован с SSRC для активного клиента. В некоторых ситуациях, в которых клиент является активным, а другие клиенты не являются активными, медиа-сервер может предоставлять (410) активному клиенту указание так, чтобы активный клиент был уведомлен, что нет других активных клиентов, несмотря на то что отправленный активным клиентом поток не возвращается активному клиенту. Таким образом, активному клиенту становиться известно, что участник не "переговаривает" другого участника.

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

Заключение

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

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

2. Компьютерно-реализуемый способ по п.1, в котором список вставляется в список составляющих источников (CSRC) транспортного протокола реального времени (RTP) в заголовке пакета.

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

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

5. Компьютерно-реализуемый способ по п.4, в котором CNAME и ассоциированную идентификацию SSRC получают из записи протокола управления в реальном времени (RTCP) для конкретного клиента.

6. Компьютерно-реализуемый способ по п.5, в котором CNAME и ассоциированная идентификация SSRC отправляются слушающему клиенту в пакете RTCP.

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

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

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

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

11. Машиночитаемый носитель по п.10, при этом упорядоченный список начинается с доминирующего активного клиента.

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

13. Машиночитаемый носитель по п.11, при этом идентификация SSRS поставлена в соответствие CNAME, полученному из пакета управления для одного или более принятых аудиопотоков.

14. Машиночитаемый носитель по п.13, при этом пакет управления совместим с протоколом управления в реальном времени (RTCP).

15. Машиночитаемый носитель по п.13, при этомидентификация SSRC и CNAME включены в пакет протокола управления в реальном времени (RTCP).

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

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

18. Система по п.17, в которой медиасервер вставляет упорядоченный список в список составляющих источников (CSRC) транспортного протокола реального времени (RTP) в заголовке пакета.

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

20. Система по п.17, в которой медиасервер посылает клиентам, принимающим посланные медиапотоки, идентификаторы активных клиентов, включающие в себя каноническое имя (CNAME) и идентификацию источника синхронизации (SSRC), поставленную в соответствие CNAME для активного клиента, в пакете протокола управления в реальном времени (RTCP).



 

Похожие патенты:

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

Изобретение относится к области удаленного доступа в сети передачи данных. .

Изобретение относится к области конференцсвязи в сетях передачи данных. .

Изобретение относится к средствам совместного использования данных в реальном времени. .

Изобретение относится к области связи и распространения контента (содержания), в частности к организации группы и связи между участниками группы во время группового просмотра контента.

Изобретение относится к области связи, и в частности к системе для реализации многоязычной конференцсвязи. .

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

Изобретение относится к системам и способам для предоставления избирательного многоадресного прокси-сервера в компьютерной сети. .

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

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

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

Изобретение относится к видеоконференциям и, в частности, к системе дистанционного присутствия. Техническим результатом является улучшение системы дистанционного панорамного присутствия в части представления глубины, отображения без стыков и контакта глаз. Указанный технический результат достигается тем, что система дистанционного присутствия включает в себя: устройство сбора видеоданных, устройство отображения видеоизображений, устройство сбора звука, проигрыватель звуков и устройство передачи аудио-видеоданных. Устройство передачи аудио-видеоданных передает видеоданные, собранные устройством сбора видеоданных на локальном конце, и звуки, собранные устройством сбора звука на локальном конце, в удаленный конец через сеть; устройство отображения видеоизображений и проигрыватель звуков на удаленном конце воспроизводят изображения и звуки, соответственно; и устройство сбора видеоданных представляет собой панорамную камеру. 2 н. и 19 з.п. ф-лы, 23 ил.

Изобретение относится к cистеме мультимедийной конференц-связи, которая отображает различные типы мультимедийного содержания с использованием различных окон или представлений графического пользовательского интерфейса. Техническим результатом является улучшение идентификации различных участников встречи в виртуальной среде. Указанный технический результат достигается тем, что устройство управления встречей в системе мультимедийной конференции содержит компонент визуальной композиции, действующий для генерации визуальной композиции для события мультимедийной конференции. Компонент визуальной композиции может содержать модуль видео декодера, действующий для декодирования множества мультимедийных потоков для события мультимедийной конференции; модуль детектора активного участника, действующий для обнаружения участника в декодированном мультимедийном потоке в качестве активного говорящего участника; модуль администратора мультимедийных потоков, действующий для отображения декодированного мультимедийного потока с активным говорящим участником на активный кадр дисплея, а других декодированных мультимедийных потоков на неактивные кадры дисплея; и модуль генератора визуальной композиции, действующий для генерации визуальной композиции со списком участников, имеющим активные и неактивные кадры дисплея, расположенные в предопределенном порядке. 3 н. и 11 з.п. ф-лы, 6 ил.

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

Изобретение относится к области видеоконференцсвязи. Техническим результатом является обеспечение подписок на видеоконференции с использованием потоков с множеством скоростей передачи битов. Сервер видеоконференции может принимать видеопотоки от каждого клиента в видеоконференции и может принимать запросы на подписку от каждого клиента. Запросы на подписку могут включать в себя запросы на просмотр видеопотоков от конкретных других клиентов с заданным разрешением и/или частотой кадров. Сервер видеоконференции может сопоставлять принятые видеопотоки с запросами на подписку, чтобы послать подписавшимся клиентам необходимые им видеопотоки. Сервер может также запрашивать различные версии видеопотоков от участников (например, с другими разрешениями) и/или изменять видеопотоки, чтобы они лучше соответствовали запросу на подписку. 3 н. и 17 з.п. ф-лы, 6 ил.

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

Изобретение относится к средствам для выполнения мультимедийной услуги в беспроводной локальной сети. Технический результат заключается в повышении качества передачи мультимедийного потока данных. Принимают, посредством устройства доступа, многоадресный поток данных, отправленный с помощью сервера данных. Контролируют, посредством устройства доступа, в реальном времени скорость приема терминала, подсоединенного к устройству доступа. Если скорость приема терминала выше или равна скорости многоадресной рассылки, с которой устройство доступа отправляет многоадресные данные, отправляют, посредством устройства доступа, в многоадресном режиме, многоадресный поток данных, отправленный с помощью сервера данных в терминал. Если скорость приема терминала ниже, чем скорость многоадресной рассылки, преобразуют, посредством устройства доступа, многоадресный поток данных, отправленный с помощью сервера данных, в одноадресный поток данных, и отправляют, посредством устройства доступа, одноадресный поток данных в терминал. 11 н. и 3 з.п. ф-лы, 6 ил.

Изобретение относится к области видеоконференций, в частности, к формированию многооконных изображений высокой четкости. Техническим результатом является формирование многооконных изображений высокой четкости в многоточечной видеоконференции без необходимости значительного улучшения возможностей кодека видеосигналов. Указанный технический результат достигается тем, что способ включает следующие шаги: вычисление блоком многоадресного управления (MCU) формата кодового потока видео высокой четкости согласно управляющей информации видеоконференции и передачу набора возможностей, содержащего формат кодового потока видео высокой четкости, в выбранный терминал; кодирование выбранным терминалом изображения видео высокой четкости на основании формата кодового потока видео высокой четкости, указанного в наборе возможностей, и передачу кодового потока кодированного видео высокой четкости в блок MCU; включение блоком MCU принимаемого изображения кодового потока видео высокой четкости в многооконное изображение согласно управляющей информации видеоконференции, формирование кодового потока многооконного видеоизображения высокой четкости и передача его в терминалы, принимающие участие в конференции. 5 н. и 4 з.п. ф-лы, 5 ил.
Наверх