ИДЕНТИФИКАЦИЯ АКТИВНОГО ГОВОРЯЩЕГО УЧАСТНИКА Российский патент 2013 года по МПК H04L12/18 

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

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

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

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

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

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

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

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

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

Фиг.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, методики и реализации настоящего изобретения могут быть применены к другим алгоритмам протоколов транспортировки данных.

Заключение

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

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

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).