РАСПРЕДЕЛЯЕМАЯ, МАСШТАБИРУЕМАЯ, ПОДКЛЮЧАЕМАЯ АРХИТЕКТУРА КОНФЕРЕНЦСВЯЗИ Российский патент 2012 года по МПК H04L12/18 

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

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

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

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

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

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

Раскрытие изобретения

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

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

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

Централизованный компонент управления конференциями также предоставляет службы диспетчеризации и создание экземпляра сеанса (через компонент Focus Factory). Контроллер конференции также включает в себя функциональность, чтобы выделять один или более из самых доступных распределенных мультимедийных компонентов (через компонент Media Factory) для сеанса конференции. Компонент управления конференциями также выступает в качестве службы управления политиками конференций и списками. Сервер политик конференций - это логическая функция, которая позволяет сохранять и обрабатывать политику конференций и списки. Политика конференций - это полный набор правил, управляющих работой конференции, и она может быть разделена на политику членства и мультимедийную политику.

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

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

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

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

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

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

Фиг. 3 иллюстрирует более подробную методологию управления сеансами.

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

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

Фиг. 6 иллюстрирует примерную подробную схему архитектуры компонентов для реализации системы конференцсвязи.

Фиг. 7 иллюстрирует схему примерной архитектуры сервера и протоколов для конференцсвязи и распределенных MCU.

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

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

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

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

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

Фиг. 13 иллюстрирует примерную блок-схему последовательности операций вызова для присоединения клиента через аудио/видео-MCU посредством исходящего коммутируемого подключения addUser.

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

Фиг. 15 иллюстрирует примерную блок-схему последовательности операций вызова для специального (ad hoc) приглашения другому клиенту-участнику, имеющего результатом входящее коммутируемое подключение.

Фиг. 16 иллюстрирует примерную блок-схему последовательности операций вызова для специального (ad hoc) исходящего коммутируемого подключения INVITE к другому клиенту.

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

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

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

Фиг. 20 иллюстрирует примерную блок-схему последовательности операций вызова двух отдельных диалогов "клиент-компонент Focus" с помощью экземпляра компонента Focus.

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

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

Фиг. 23 иллюстрирует пул из нескольких серверов, где внешние интерфейсные серверы имеют эквивалентную функциональность.

Фиг. 24 иллюстрирует конфигурацию пула из нескольких серверов для характеристик высокой доступности и восстановления после сбоя.

Фиг. 25 иллюстрирует представление топологии различных типов потоков данных между объектами архитектуры распределенных мультимедийных компонентов.

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

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

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

Осуществление изобретения

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

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

Фиг. 1 иллюстрирует компьютеризованную систему 100 конференцсвязи для распределенного мультимедийного доступа. Система 100 является подключаемой архитектурой конференцсвязи, которая поддерживает несколько подключаемых распределенных мультимедийных систем для доступа участниками сеанса через ряд различных устройств. Для поддержки этого система 100 включает в себя сетевой компонент 102 управления конференциями для централизованного создания и управления сеансом конференции. Компонент 102 управления системы 100 взаимодействует так, чтобы управлять одним или более распределенных мультимедийных компонентов 104 (обозначенных МУЛЬТИМЕДИЙНЫЙ КОМПОНЕНТ₁,..., МУЛЬТИМЕДИЙНЫЙ КОМПОНЕНТ_N, где N - это положительное целое число), таких как многоточечные устройства управления (MCU), которые дополнительно предоставляют клиентский доступ к сеансу конференции посредством клиентов 106 (обозначенных КЛИЕНТ и КЛИЕНТ₁,..., КЛИЕНТ_M, где М - это положительное целое число) через подобные и/или различные мультимедийные режимы (к примеру, аудио, видео).

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

Другими словами, чтобы удовлетворить потребность в конференцсвязи, клиент 108 осуществляет доступ (к примеру, через Интернет-подключение) к компоненту 102 управления, запрашивая создание сеанса конференции. Компонент 102 управления упрощает выделение соответствующих мультимедийных компонентов 104 (к примеру, мультимедийных компонентов 110 и 112) для участников сеанса (к примеру, клиент 108 и КЛИЕНТ₁, КЛИЕНТ₂ и КЛИЕНТ₃) и их требуемого типа подключения (к примеру, аудио, видео,...), управление интерфейсом мультимедийных компонентов 104, конфигурирование одного или более мультимедийных компонентов 104, чтобы удовлетворить запрашиваемые потребности конференцсвязи, управление сеансами во время сеанса и закрытие и очистку сеанса для всех ассоциированных систем.

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

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

Фиг. 3 иллюстрирует более подробную методологию управления сеансами. На этапе 300 клиент подключается к веб-компоненту управления конференциями с помощью веб-адреса. На этапе 302 клиент отправляет информацию о конференции компоненту управления. Эта информация включает в себя установочную и конфигурационную информацию для сеанса, такую как, например, информация об участниках, время и данные сеанса и типы мультимедиа, чтобы поддерживать доступ участников. На этапе 304 компонент управления создает экземпляр сеанса и возвращает URI (универсальный идентификатор ресурса) для сеанса и один или более URI для мультимедийных компонентов, выделенных для сеанса. На этапе 306 клиент передает информацию о URI участникам. Сеанс начинается, и на этапе 308 участники уведомляются относительно изменений в состоянии сеанса. На этапе 310 компонент управления упрощает создание и завершение альтернативной непрослушиваемой конференции во время сеанса. На этапе 312 участники сеанса уведомляются относительно вышедших из сеанса (участниках, которые вышли), сеанс закрывается, и система выполняет очистку (к примеру, закрывая MCU, экземпляр сеанса и т.д.).

На фиг. 4 проиллюстрирована более подробная блок-схема системы 400, которая упрощает создание сеанса конференции с помощью веб-компонента 402 управления конференциями и распределенных мультимедийных компонентов 404. Система 400 включает в себя компонент 402 управления конференциями (также упоминаемый в данном документе как компонент Focus), который является централизованным контроллером конференции. Компонент 402 Focus включает в себя компонент 406 уведомлений, который предоставляет службу уведомлений о конференциях. Служба уведомлений о конференциях - это логическая функция, предоставляемая компонентом 402 Focus. Компонент 402 Focus может выступать в качестве уведомителя посредством принятия подписок на состояние конференции и уведомления абонентов (или участников) об изменениях этого состояния.

Компонент 402 Focus также включает в себя компонент 408 политик/списков конференций для предоставления служб управления политиками и списками. Сервер политик конференций, как часть компонента 408, является логической функцией, которая может сохранять и обрабатывать политику/список конференций. Политика конференций - это полный набор правил, управляющих работой конференции, и она разделяется на политику членства и мультимедийную политику. Состояние, отслеживаемое посредством компонента 406 уведомлений, включает в себя состояние, поддерживаемое посредством самого компонента 402 Focus, политику конференций и мультимедийную политику.

Компонент 402 Focus также включает в себя компонент 410 диспетчеризации/компонент Focus Factory, который обеспечивает диспетчеризацию конференций. Компонент 412 аутентификации предусматривает обработку авторизации и аутентификации пользователей на основе идентификационных данных (к примеру, активный каталог) или с помощью PIN-кода. Компонент 414 интерфейса MCU упрощает взаимодействие с множеством распределенных мультимедийных компонентов 404 (к примеру, MCU 404) (обозначенных MCU₁, MCU₂,..., MCU_T, где T - это положительное целое число) для управления политиками/списками конференции. Компонент 402 Focus включает в себя компонент 416 выделения MCU (также упоминаемый как компонент MCU Factory), функция которого состоит в том, чтобы выделять самый доступный сетевой MCU 404 из сети 418 (к примеру, Интернета) для сеанса конференции. Система 400 также включает в себя подключаемых участников конференции (обозначаемых как КЛИЕНТЫ 420), которые получают одинаковое изображение конференции с одним интегрированным списком из основного компонента Focus и могут управлять конференцией через этот компонент Focus.

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

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

Компонентами архитектуры являются клиент 500, компонент 502 Focus Factory, компонент 504 Focus, компонент 506 Focus Factory 502 и MCU 508. Одна из основных характеристик раскрытой архитектуры конференцсвязи - это использование нескольких компонентов, которые работают распределенным способом, а не в традиционной цельной серверной архитектуре.

Клиент 500 конференции является конечной точкой, допускающей присоединение и участие в конференции. Клиент 500 сначала взаимодействует с компонентом 502 Focus Factory, чтобы создавать конференцию.

Компонент 502 Focus Factory является объектом, который создает компонент 504 Focus для конференции. Компонент 502 Focus Factory направляет клиента 500 в соответствующее местоположение компонента Focus, где конференция должна быть проведена. Компонент 502 Focus Factory является приложением, которое выполняется на внешней интерфейсной машине SIP как конечная точка SIP, и которое адресуется с помощью URI SIP.

Компонент 502 Focus Factory является SIP-адресуемым, а также адресуемым с помощью URI HTTP (протокол передачи гипертекста) и SOAP (простой протокол доступа к объектам). В одной реализации архитектуры компонент 502 Focus Factory располагается совместно с компонентом 504 Focus; в другой он не располагается совместно с ним. Каждый пул конференцсвязи может быть рассмотрен как компонент Focus Factory.

Компонент 504 Focus является централизованным менеджером политик и состояний для сеанса конференции. Компонент 504 Focus является конечной точкой SIP, которая представляет конференцию и выступает в качестве центрального координатора для всех аспектов конференции. Компонент 504 Focus отвечает за осуществление политики управления конференциями, управление полной безопасностью для конференции, уведомление об обновлениях состояния конференции для клиента(ов) и предоставление канала для команд управления, проходящих между клиентом 500 и MCU 508.

Компонент 504 Focus также взаимодействует с MCU для каждого типа мультимедиа, который является частью конференции, от имени всех клиентов. Компонент 504 Focus хранит все состояния, необходимые для ответа на запросы о конференции или состоянии, необходимые для того, чтобы возобновлять собрание, если происходит сбой одного внешнего интерфейсного сервера. Информация о конференции может быть сохранена в базе данных сервера SQL (язык структурированных запросов) для будущего использования до очистки сеанса. Экземпляр компонента Focus выполняется в пуле конференцсвязи. Это позволяет клиентам подключаться к любому внешнему интерфейсному серверу в пуле, тем самым обеспечивая лучшую доступность, распределение нагрузки и лучшее масштабирование. Компонент 504 Focus также отвечает, например, за MCU самозагрузки и поддержание подключений к MCU по интерфейсу HTTP. Компонент 504 Focus в некоторых случаях также может выступать в качестве прокси-сервера, чтобы пропускать через прокси-сервер команды и уведомления C3P (или CCCP - протокол канала управления конференциями). Это описывается ниже.

Идея компонента Focus является центральной в конференции согласно SIPPING. SIPPING - это рабочая группа IETF (Инженерная группа по развитию Интернета), нанятая для задания расширений конференцсвязи в SIP. Привилегия SIPPING состоит в том, чтобы задавать схему пакетов событий состояния конференции.

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

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

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

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

Обмен данными клиента/компонента Focus Factory по фиг. 5 (обозначен 1) начинается посредством нахождения сначала клиентом 500 компонента 502 Focus Factory. Клиентское приложение обменивается данными с компонентом 502 Focus Factory, чтобы начать новую конференцию. Как пояснено выше, поскольку клиентское приложение запрашивает URI компонента Focus Factory, когда пользователь предъявляет пароль, клиент 500 имеет средство обмениваться данными с компонентом 502 Focus Factory в любое время, чтобы начать новую специальную конференцию. Клиента 500 не интересует то, на котором сервере из пула серверов, например, находится компонент 502 Focus Factory; ему требуется только URI SIP компонента Focus Factory для того, чтобы соединиться.

В раскрытой архитектуре создать конференцию означает создание и конфигурирование экземпляра компонента Focus. Задача компонента 502 Focus Factory состоит в том, чтобы возвратить URI компонента 504 Focus обратно клиенту 500. Это означает, что сеанс связи между клиентом 500 и компонентом 502 Focus Factory не должен быть длительным, а должен иметь достаточную продолжительность, чтобы продолжаться до тех пор, пока URI компонента Focus не будет возвращен клиенту 500. Компонент 503 Focus Factory создает (в случае необходимости) и конфигурирует компонент 504 Focus прежде, чем он возвратит URI компонента Focus обратно клиенту 500.

Клиент 500 может передать всю информацию, которая ему требуется, относительно определений роли конференции, типов мультимедиа, прав доступа, участников в компонент 502 Focus Factory заранее, так что компонент 502 Focus Factory может возвратить ответ об успешном выполнении с конечными данными.

Относительно связи компонента Focus Factory/компонента Focus по фиг. 5 (обозначена 2), после приема запроса от клиента 500, компонент 502 Focus Factory создает компонент 504 Focus и возвращает URI компонента Focus клиенту 500 (обозначенный 3). Компонент 504 Focus, точно так же, как компонент 502 Focus Factory, является конечной точкой SIP, представленной посредством приложения. Компонент 502 Focus Factory перенаправляет запрос, который он принимает от клиента 500, компоненту 504 Focus, давая возможность компоненту 504 Focus стать конечной точкой, которая выполняет согласование мультимедиа с клиентом 500. После передачи URI компонента Focus клиенту 500 компонент 502 Focus Factory не должен поддерживать какое-либо состояние или выполнять какую-либо работу.

Компонент 506 MCU Factory является логическим объектом, который предоставляет информацию о доступе для MCU 508. Компонент 506 MCU Factory может быть специализированной реализацией для поставщиков устройств или программного обеспечения MCU. Компонент 504 Focus знает через настройки то, какие компоненты MCU Factory присутствуют в системе и какие типы мультимедиа они поддерживают. Соответственно, компонент 504 Focus запрашивает у компонента 506 MCU Factory информацию о том, как входить в контакт с MCU 508 (обозначен 4), и компонент 506 MCU Factory возвращает эту информацию на основе любой внутренней логики, которой может следовать (обозначено 4).

Когда компонент 506 MCU Factory запрашивается, чтобы предоставить MCU 508 в компонент 504 Focus (обозначен 4), он выясняет, какой MCU 508 лучше всего подходит для того, чтобы ответить на этот запрос, и возвращает URL (универсальный указатель ресурса) для этого MCU 508. Каждый MCU может быть опубликован (к примеру, в активном каталоге), обеспечивая возможность всем компонентам 506 MCU Factory в топологии найти доступный MCU нужного вида.

Каждый MCU 508 также публикует свой HTTP-адрес для управления в активном каталоге. Этот адрес является тем, который передается в компонент 504 Focus, когда компонент 506 MCU Factory выделяет ресурс 508 MCU. Однако прежде чем URL передается в компонент 504, компонент 506 MCU пытается обеспечить конференцию по MCU 508 (обозначено 5). Если ответ MCU положительный, то URL возвращается компоненту 504 Focus.

Компонент 504 Focus может затем может обмениваться данными с MCU 508 (обозначено 6), используя HTTP в качестве транспорта. Рабочие данные для запросов и ответов могут быть XML-документами. Клиент 500 обменивается данными с MCU 508 (обозначено 7) через протокол сигнализации и мультимедийный протокол. Для аудио/видео-MCU протокол сигнализации - это мультимедиа SIP, и может переноситься по RTP/RTCP. Для MCU собрания как сигнализация, так и мультимедиа могут переноситься по HTTP в качестве транспорта, используя протокол PSOM.

Фиг. 6 иллюстрирует примерную подробную схему архитектуры компонентов для реализации системы 600 конференцсвязи. Система 600 включает в себя внешний интерфейсный компьютер 602, систему 604 хранения и распределенные мультимедийные компоненты 606. Внешний интерфейсный компьютер 602 включает в себя серверный процесс 608, который выступает в качестве прокси-сервера 610 SIP. В дополнение к работе в качестве прокси-сервера SIP и маршрутизатора, серверный процесс 608 также предоставляет внутренний API (называемый API модулей расширения) 612, который используется посредством сервера (или модуля) 614 присутствия (и регистрации), модуля 616 агента архивации и модуля 618 API SIP. Как показано, все эти модули 612 расширения могут запускаться в одном процессе. Никакой код третьей стороны не требуется запускать в процессе 610 прокси-сервера SIP.

Модуль 614 присутствия/регистрации предоставляет функциональность присутствия и регистрации. Модуль 614 присутствия и регистрации управляет всей регистрационной информацией и информацией о присутствии в базе данных SQL Server (или MSDE).

Комбинация прокси-сервера SIP и ассоциированных модулей расширения упоминается вместе как внешний интерфейс сервера. Как указано, функциональность внешнего интерфейса расширена, для включения функций конференцсвязи, через модуль 618 конференцсвязи (также упоминаемый как менеджер конференции). Менеджер 618 конференции является серверным компонентом, который предоставляет сигнализацию и функциональность управления конференцией. Основными элементами менеджера 618 конференции являются компонент Focus и компонент Focus Factory.

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

База 620 данных конференции содержит информацию о каждой из конференций, инициализированных на сервере 602. Она включает в себя информацию об идентификаторе конференции, паролях и/или PIN-кодах, ассоциированных с конференцией, начальном времени и конечном времени (если есть), ролях и правах доступа и т.д. База 620 данных также включает в себя информацию о запущенной конференции для восстановления после сбоев компонента Focus. Информация о присутствии/регистрации и информация о конференцсвязи могут быть различными таблицами одной физической базы данных (к примеру, базы данных конференции).

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

MCU состоит из двух логических частей: мультимедийный контроллер (MC) и мультимедийный процессор (MP). Мультимедийный контроллер отвечает за администрирование команд управления между компонентом Focus и MCU. Мультимедийный процессор отвечает за мультимедийное управление, такое как, например, смешивание, ретрансляция, транскодирование. Если MCU - это MCU совместной работы с данными, мультимедийный процессор является сложным программным компонентом, который отвечает за администрирование всем опытом совместной работы с данными. Каждый MCU может сохранять свое содержимое и информацию о состоянии в ассоциированных модулях памяти для поиска, если происходят ошибки и/или сбой.

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

Внешний интерфейсный компьютер 602 также может запускать веб-сервер 622, который включает в себя веб-службы и приложение 624 веб-диспетчеризации, и компонент 626 MCU Factory. Как указано ранее, компонент 626 MCU Factory отвечает за инициализацию конференции для конкретного типа мультимедиа на MCU, используя локальную политику для создания конференций. Компонент 626 MCU Factory может также учесть текущую загрузку на MCU перед назначением MCU для конференции. Данные балансировки нагрузки могут быть сохранены в базе 628 данных балансировки нагрузки. В этой конкретной реализации есть один компонент MCU Factory на тип мультимедиа. Тем не менее, в альтернативной реализации один компонент MCU Factory является в надлежащей мере отказоустойчивым, чтобы обрабатывать несколько различных типов мультимедиа.

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

Аудио/видео-MCU предоставляет возможности многостороннего смешивания и ретрансляции аудио и видео на основе стандарта RTP (транспортный протокол в реальном масштабе времени) и RTCP (протокол управления RTP). Другие MCU могут быть разработаны и предоставлены, такие как, например, MCU мгновенного обмена сообщениями (IM) и MCU ACP.

Веб-сервер 624 предоставляет приложение диспетчеризации (к примеру, ASP.NET) для диспетчеризации сетевых конференций. Приложение использует API веб-служб для инициализации конференций и для администрирования политиками конференций. Базой данных, используемой для регистрации событий веб-диспетчера, может быть база 620 данных компонента Focus/конференцсвязи. Содержимое и состояние для MCU могут быть сохранены в локальных хранилищах 630 данных.

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

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

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

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

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

Фиг. 7 иллюстрирует схему примерной архитектуры сервера и протоколов для конференцсвязи и распределенных MCU. Несколько протоколов могут использоваться между клиентом 700 и сервером 702, каждый для различной цели. Клиент 700 показан как имеющий пользовательский интерфейс 704, который может осуществлять доступ к базовому компоненту 706 администрирования и управления конференциями и компоненту 708 мультимедиа конференции. Компонент 706 администрирования может осуществлять доступ к компоненту 710 списков, который предоставляет список приглашения в сеанс и/или список сторонних конференций. Компонент 708 мультимедиа конференции упрощает доступ к компоненту 712 совместного использования приложений и совместной работы с данными и компоненту 714 аудио/видео.

Сервер 702 включает в себя компонент 716 Focus, компонент 718 MCU совместной работы с данными и совместного использования приложений и компонент 720 аудио/видео(AV)-MCU. Клиент 700 и сервер 702 включают в себя компоненты интерфейса протокола (к примеру, SIP, PSOM, RTP/RTCP) для использования различных протоколов. Клиент-серверные компоненты SIP используют протокол служебных сигналов и управления для установления сеанса и управления конференцией. В этой конкретной реализации SIP (к примеру, как указано в RFC3261) используется для установления и завершения вызова. Дополнительно, один сеанс конференции может использоваться для управления политикой конференций и стороннего управления с помощью расширений SIP-CX. В одной реализации команды SIP-CX туннелируются по SIP-INFO. В другой реализации могут использоваться команды протокола управления C3P. В еще одной реализации могут быть использованы стандартизированный транспорт и протокол для управления политиками конференций от XCON, рабочей группы IETF для централизованной конференцсвязи. SIP может использовать TCP (протокол управления передачей) или TLS (безопасность транспортного уровня) в качестве базового транспортного уровня.

Отдельный диалог SUB-NOT может использоваться для подписки на пакеты конференции и получение уведомлений, когда состояние изменяется. Список для конференции может управляться на основе этого диалога SUB-NOT. PSOM может быть мультимедийным протоколом для совместной работы с данными и может использовать TCP или HTTP в качестве базового транспорта.

Для каждой из мультимедиа в конференции должен быть использован мультимедийный транспорт. RTP и RTCP могут использоваться для предоставления аудио/видео-функциональности. RTP/RTCP может работать под управлением UDP (протокол пользовательских дейтаграмм), если возможность подключения UDP доступна между клиентом 700 и сервером 702. Если нет возможности подключения UDP, RTP/RTCP может быть туннелирован по TCP или HTTP. Другие мультимедийные протоколы могут использоваться для других типов мультимедиа. Например, чат может поддерживаться по MSRP (протокол пересылки сеанса сообщения), а совместное использование приложений - по RDP (протокол для удаленных рабочих столов). Каждый из них может выполняться как отдельный тип мультимедиа. В другой реализации оба из этих протоколов могут быть реализованы поверх PSOM.

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

Клиентское приложение обменивается данными с компонентом Focus Factory, чтобы начать новую конференцию. Создать конференцию означает создание и конфигурирование экземпляра компонента Focus. Задача компонента Focus Factory состоит в том, чтобы возвратить URI на компонент Focus обратно клиенту. Этот обмен данными между клиентом и компонентом Focus Factory не должен быть длительным. Он должен длиться только до тех пор, пока URI компонента Focus не будет возвращен клиенту. URI компонента Focus/конференции создается так, чтобы включать в себя уникальный идентификатор конференции, уникальный идентификатор сервера и домен, который выступает в качестве хоста для конференции в части пользовательской информации, например, organizer@domain.com;ms-app=conf;ms-conf-id=11.

Есть три способа, которыми клиент может создать конференцию: через веб-службу, механизм SIP Invite и механизм SIP Service. Фиг. 8 иллюстрирует примерную блок-схему последовательности операций вызова для инициализации создания конференции через веб-интерфейс/службу. Клиент подключается к известному веб-URI компонента Focus Factory и использует предоставленные веб-интерфейсы, чтобы создать компонент Focus. После успешного создания компонента Focus веб-страница направляет клиента к необходимой информации для запуска клиента конференции, чтобы выполнить входящее коммутируемое подключение к конференции.

Фиг. 9 иллюстрирует примерную блок-схему последовательности операций вызова для инициализации создания конференции через механизм SIP Invite. Клиент передает всю информацию, которая ему требуется, относительно конференции, типов мультимедиа, прав доступа, участников, как часть запроса INVITE к компоненту Focus Factory. Компонент Focus Factory создает экземпляр компонента Focus и перенаправляет клиента к компоненту Focus с помощью формируемого URI компонента Focus.

Более конкретно, клиент отправляет запрос INVITE компоненту Focus Factory с информацией, чтобы создать конференцию. Компонент Focus Factory отправляет временный ответ 1xx клиенту так, чтобы клиентская транзакция не превысила таймаут, пока компонент Focus Factory создает экземпляр компонента Focus. Если оказывается, что время, потраченное на создание компонента Focus, меньше времени ожидания транзакции SIP, отправка этого ответа может быть проигнорирована. Компонент Focus Factory затем анализирует всю запрошенную информацию от INVITE и создает экземпляр компонента Focus. В случае, если компонент Focus Factory и компонент Focus могут быть совместно расположены, этот вызов для создания компонента Focus может быть просто локальным обращением к функции. Компонент Focus Factory далее отправляет 302 ответ с заголовком контакта, перенаправляя клиента к началу нового сеанса приглашения с компонентом Focus. Клиент отсылает обратно ACK компоненту Focus Factory.

Фиг. 10 иллюстрирует примерную блок-схему последовательности операций вызова для инициализации создания конференции через механизм SIP Service. Клиент передает всю информацию, которая ему требуется, относительно конференции, типов мультимедиа, прав доступа, участников, как часть запроса SERVICE к компоненту Focus Factory. Компонент Focus Factory создает экземпляр компонента Focus и отправляет информацию о подключении обратно клиенту в ответе 200 OK.

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

Фиг. 11 иллюстрирует примерную блок-схему последовательности операций вызова для входящего коммутируемого подключения клиента к конференции. Клиент устанавливает диалог INVITE и диалог SUBSCRIBE с компонентом Focus для входящего коммутируемого подключения клиента к конференции. Клиент использует диалог INVITE, чтобы присоединиться к конференции, и также использует его для дополнительного стороннего управления командным трафиком от клиента к компоненту Focus. Команды управления от клиента переносятся в сообщениях INFO. Тело сообщения INFO содержит запросы управления C3P и обрабатывается компонентом Focus.

Клиент использует диалог SUBSCRIBE/NOTIFY для просмотра состояния конференции. Компонент Focus принимает подписку и уведомляет абонентов о любом изменении состояния конференции. Состояние включает в себя состояние, поддерживаемое самим компонентом Focus, политикой конференции и мультимедийной информацией. Например, если команда, которая была послана клиентом в диалоге INVITE с помощью сообщения INFO, является командой, которая изменяет состояние конференции, компонент Focus также информирует клиента посредством отправки NOTIFY об измененном состоянии конференции.

Более конкретно, клиент отправляет запрос INVITE в URI компонента Focus, чтобы присоединиться к конференции. Этот диалог INVITE имеет две цели: он подразумевает присоединение клиента к конференции, и он используется для стороннего управления конференцией с помощью запроса INFO в этом диалоге. Запрос C3P addUser в теле INVITE может использоваться для того, чтобы указать конкретные клиентские атрибуты (к примеру, отображаемое имя, роли, скрытого участника). Клиент отправляет SUBSCRIBE пакету событий конференции, чтобы просматривать уведомления о состоянии конференции. Начальный документ состояния конференции может быть послан во вложении в 200 OK из SUBSCRIBE в соответствии с выражением клиентом поддержки этого расширения.

Фиг. 12 иллюстрирует примерную блок-схему последовательности операций вызова для присоединения клиента через MCU совместной работы с данными посредством входящего коммутируемого подключения addUser. Для каждого MCU в конференции компонент Focus назначает виртуальный URI SIP, который маршрутизируется на сам компонент Focus. Начальное уведомление от компонента Focus клиенту содержит URI для всех MCU в конференции. Есть три способа, которыми клиенты могут установить мультимедийный сеанс с MCU: входящее коммутируемое подключение addUser к URI MCU, исходящее коммутируемое подключение addUser с помощью URI MCU и прямой мультимедийный INVITE в URI MCU.

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

Более конкретно, клиент отправляет команду входящего коммутируемого подключения INFO addUser с URI MCU, который он принял в документе уведомления. Компонент Focus проверяет, назначен ли MCU для этой конкретной модальности (мультимедиа) для этой конференции. Если MCU был назначен, компонент Focus отправляет HTTP-запрос компоненту MCU Factory, запрашивая его выделить MCU для этой конференции. При условии, что MCU выделен для конференции, компонент Focus затем отправляет HTTP-запрос выделяемому MCU, запрашивая его ожидать нового участника (addUser). Если это первый раз, когда компонент Focus обменивается данными с этим MCU, может потребоваться послать другие запросы самозагрузки, чтобы инициализировать конференцию по MCU. MCU отвечает сообщением успешности для вызова ожидаемого участника (addUser). Ответ также имеет фактический URL, по которому он хочет, чтобы участник взаимодействовал с MCU. В случае MCU совместной работы с данными URL может быть URL PSOM. Информация об авторизации, если имеется, также может быть возвращена.

Компонент Focus отправляет информацию о PSOM-подключении клиенту. Клиент затем непосредственно устанавливает PSOM-канал с MCU. Как только клиент успешно присоединяется к MCU, он отправляет событие "участник присоединился" в компонент Focus. Далее компонент Focus отправляет уведомление изменения состояния MCU "участник присоединился" (через SIPPING BENOTIFY (или NOTIFY по принципу максимальной эффективности)) всем наблюдателям конференции.

Фиг. 13 иллюстрирует примерную блок-схему последовательности операций вызова для присоединения клиента через аудио/видео-MCU посредством исходящего коммутируемого подключения addUser. Клиент выдает команду C3P исходящего коммутируемого подключения addUser, и компонент Focus перенаправляет команду в MCU. MCU авторизует команды и исходящие коммутируемые соединения к клиенту, упомянутому в команде addUser. Далее клиент устанавливает прямой мультимедийный сеанс с MCU. Это используется в соединениях клиента с основанными на SIP MCU (к примеру, A/V-MCU и MCU IM). Этот механизм может также использоваться для клиента, чтобы выполнять исходящее коммутируемое подключение к другому клиенту через MCU.

Более конкретно, клиент отправляет команду исходящего коммутируемого подключения INFO addUser с URI MCU, который он принял в документе уведомления. Компонент Focus затем проверяет, назначен ли MCU для этой конкретной модальности для этой конференции. Если MCU был назначен, компонент Focus отправляет HTTP-запрос компоненту MCU Factory, запрашивая его выделить MCU для этой конференции. При условии, что MCU выделен для конференции, компонент Focus затем отправляет HTTP-запрос выделяемому MCU, запрашивая его выполнить исходящее коммутируемое подключение к пользователю. MCU выполняет команду исходящего коммутируемого подключения INVITE к клиенту с помощью исходящего SIP-прокси-сервера, которым обычно является сам сервер компонента Focus. Клиент напрямую устанавливает мультимедийный RTP-канал с MCU. Как только клиент успешно присоединяется к MCU, он отправляет событие "участник присоединился" в компонент Focus. После этого компонент Focus отправляет уведомление изменения состояния MCU "участник присоединился" всем наблюдателям конференции.

Фиг. 14 иллюстрирует примерную блок-схему последовательности операций вызова для присоединения клиента через прямое приглашение в MCU. Прямой мультимедийный INVITE в MCU работает с MCU, который использует SIP для установления сеансов (к примеру, A/V-MCU, MCU IM). Клиент может отправить приглашение в мультимедийный сеанс в URI MCU непосредственно без какого-либо предшествующего вызова addUser. INVITE маршрутизируется в компоненте Focus, и компонент Focus инициализирует addUser к MCU от имени клиента. MCU авторизуется и отвечает информацией о подключении. Компонент Focus проверяет, является ли информация о подключении маршрутизируемым SIP-адресом, и перенаправляет INVITE непосредственно в MCU. Это прежде всего служит для того, чтобы обеспечить входящее коммутируемое подключение чистого SIP-клиента не-C3P к конференции. Клиент C3P может извлекать URI MCU из уведомления конференции и отправлять сообщению REFER чистому SIP-клиенту, который может попытаться непосредственно выполнить входящее коммутируемое подключение к MCU.

Более конкретно, клиент отправляет INVITE в URI MCU, который он принял в документе уведомления. Этот INVITE маршрутизируется в компоненте Focus. Клиент может добавить описание сеанса для мультимедийного согласования. В случае, если компонент Focus знает, что INVITE адресован в конкретный MCU, он безопасно игнорирует любое описание сеанса в теле INVITE. Компонент Focus затем отправляет HTTP-запрос выделяемому MCU, запрашивая его ожидать нового участника (входящее коммутируемое подключение addUser). Если это первый раз, когда компонент Focus обменивается данными с этим MCU, он может отправить другие запросы самозагрузки, чтобы инициализировать конференцию по MCU. MCU отвечает сообщением успешности для вызова ожидаемого участника (addUser). Ответ также имеет фактический URL, по которому он хочет, чтобы участник обменивался данными с MCU.

В случае A/V-MCU URL указывает то, что участник может обмениваться данными с MCU через SIP. В случае A/V-MCU компонент Focus перенаправляет INVITE в MCU. Клиент отправляет обратно ACK, чтобы завершить диалог INVITE, который также используется для мультимедийного согласования с MCU. Отметим, что, хотя клиент устанавливает диалог INVITE непосредственно с MCU, SIP запрашивает себя, чтобы пройти через компонент Focus. Как только клиент успешно присоединяется к MCU, он отправляет событие "участник присоединился" в компонент Focus. Компонент Focus отправляет уведомление изменения состояния MCU "участник присоединился" всем наблюдателям конференции. Прямое мультимедийное согласование между клиентом и MCU достигается. В случае аудио/видео это могут быть RTP/RTCP-потоки.

Фиг. 15 иллюстрирует примерную блок-схему последовательности операций вызова для специального приглашения другому клиенту-участнику, приводящего к входящему коммутируемому подключению. Клиент в этом случае отправляет INVITE приложения участнику. Приглашение приложения с URL конференцсвязи, включенным с PIN-кодом авторизации, всплывает как подсказка на клиенте пользователя. Как только участник принимает/щелкает на подсказке, он запускает клиента конференцсвязи, который выполняет входящее коммутируемое подключение участника к конференции.

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

Фиг. 16 иллюстрирует примерную блок-схему последовательности операций вызова для специального исходящего коммутируемого подключения INVITE к другому клиенту. Клиентская последовательность присоединения инициализируется между Client1 и компонентом Focus, за которым следует сообщение исходящего коммутируемого подключения INFO addUser от Client1 к компоненту Focus. Сообщение 200 ACCEPT возвращается из компонента Focus. Компонент Focus отправляет сообщение исходящего коммутируемого подключения addUser к MCU, и MCU отвечает 200 OK. MCU отправляет сообщение INVITE, которое маршрутизируется через компонент Focus второму Client2. Client2 отвечает сообщением 200 OK, за которым следует ACK от MCU. Мультимедийный поток (к примеру, с помощью RTP) далее инициализируется между MCU и Client2. MCU отправляет событие "участник присоединился" в компонент Focus. После этого компонент Focus тогда отправляет сообщение списка обновления в Client1, указывающее то, что Client2 присоединился к сеансу конференции.

Механизм приглашения приложения, упомянутый выше, работает с новыми клиентами, которые понимают приглашение приложения и механизм протокола C3P. Тем не менее, могут быть приглашены унаследованные клиенты, которые не понимают C3P. Этот механизм также может использоваться для того, чтобы внедрить чистых SIP-клиентов в конференцию. Клиент может отправлять BYE в начальный диалог INVITE, чтобы выйти из конференции. Для обнаружения отказавших клиентов, могут быть использованы сообщения поддержания сеанса.

Уведомление о состоянии конференции может осуществляться из MCU в компонент Focus и из компонента Focus клиенту. Модель данных уведомления о состоянии включает в себя следующие элементы: описание конференции (к примеру, заголовок, тема, описание организатора); представление конференции (к примеру, информация об уровне конференции для каждого компонента Focus объекта, такого как AV-MCU, IM MCU), которое включает в себя информацию о характеристиках, текущем состоянии, настройках и политике; пользователь (к примеру, список конференций, пользователей, соответствующих конечных точек и мультимедийных сеансов, к которым он подключен); и панель альтернативной конференции, представление вложенной конференции.

Следующий код представляет один пример иерархии состояния конференции.

Conference-info [1...1]

Conference-description [0...1]

Conference-view [0...1]

Entity-view [0...N] (обрабатывается посредством URI объекта)

Entity-capabilities [0...1]

Entity-policy [0...1]

Entity-settings [0...1]

Entity-state [0...1]

Conference-media [0...N] (обрабатывается посредством метки мультимедиа)

Users [0...1]

User [0...N] (обрабатывается посредством URI пользователя)

Endpoint [0...N] (обрабатывается посредством URI конечной точки)

Media [0...N] (обрабатывается посредством идентификатора. Метка - это ссылка на элемент conference-media, см. ниже).

Sidebars-by-val [0...1]

Entry [0...N] (рекурсивно задает объект вложенной конференции).

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

<conference-info>

<conference-description>

<display-text>brownbag </display-text>

<conf-uris>

<entry>

<uri>sip:organizor@msft.com;ms-app=conf/meeting;ms-conf-id=cd</uri>

<display-text>Data MCU</display-text>

<purpose>meeting</purpose>

</entry>

<entry>

<uri>sip:organizor@msft.com;ms-app=conf/audio-video;ms-conf-id=cd/uri>

<display-text>AV MCU</display-text>

<purpose>audio-video</purpose>

</entry>

</conf-uris>

</conference-description>

<conference-info>

Далее представлен один пример кода для пользователя, пытающегося присоединиться, и самозагрузки A/V-MCU.

<conference-info>

<conference-description>

....

</conference-description>

<conference-view>

<entity-view entity="focus " />

<entity-view entity="AV">

<entity-state />

<entity-view />

<entity-view>

<conference-view>

</conference-info>

Далее представлен один пример кода для пользователя Боба, который присоединяется к компоненту Focus.

<conference-info>

<conference-description>

....

</conference-description>

<conference-view>

......

</conference-view>

<users>

<user entity="sip:bob state="full">

<display-text>bob<display-text>

<roles><entry>presenter</entry></roles>

<endpoint entity="sip:bob;focus">

<status>connected</status>

</endpoint>

</user>

</users>

<conference-info>

Далее представлен один пример кода для пользователя Боба, который присоединяется к AV MCU.

<conference-info>

<conference-description>

....

</conference-description>

<conference-view>

......

</conference-view>

<users>

<user entity="sip:bob state="full">

<display-text>bob<display-text>

<roles><entry>presenter</entry></roles>

<endpoint entity="sip:bob;focus" >

<status>connected</status>

</endpoint>

<endpoint entity="sip:bob;AV" >

<status>connected</status>

</endpoint>

</user>

</users>

<conference-info >

Обнаружение URI компонента Focus Factory может выполняться несколькими способами: посредством применения политики группы, посредством DNS (сервер доменных имен), фиксированного URI и данных пользовательского профиля сервера.

Способ, который обычно используется администраторами для того, чтобы распространять настройки клиентам, состоит в использовании объектов групповой политики (GPO). Конкретные настройки и признаки приложений могут быть включены или выключены через GPO-настройки. Например, администратор может выбрать удалять определенные варианты меню или добавлять некоторые другие через GPO. Через использование GPO администратор домена может указать определенные наборы пользователей для определенных компонентов Focus Factory. Это исключает необходимость конфигурирования вручную.

Другой вариант заключается в том, чтобы использовать запись DNS, чтобы указать клиентов для URI компонента Focus Factory. DNS SRV - это дополнение в стандартный DNS-сервер, которое используется для получения одного или более IP-адресов серверов, каждый из которых имеет собственные приоритеты. Ниже содержится примерная запись SRV:

_http._tcp.example.com. SRV 10 5 80. www.example.com

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

Другой вариант заключается в том, чтобы использовать фиксированный URI для компонента Focus Factory, такой как:

sip:FocusFactory@microsoft.com

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

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

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

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

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

Пользовательские службы могут выполнить запрос к базе данных на предмет различных типов данных, которые запрашиваются посредством клиента, форматировать его в XML-формат и ответить сообщениями NOTIFY. Для этого конкретного типа данных, вместо перехода в базу данных для их извлечения, внешняя интерфейсная машина, принимающая запрос, может обратиться к настройке уровня пула и подготовить XML-документ, чтобы отправить с NOTIFY. Если настройка обновляется, пользовательские службы уведомляются относительно ее изменения во временном окне (к примеру, 5 минут), позволяющем им обновить свое локальное значение для данной настройки.

Для пулов, которые подключают пользователей из нескольких доменов, настройка является конфигурируемой для каждого из доменов, которые подключаются, чтобы разрешить различные URI компонентов Factory для различных подключаемых доменов. Примером этого является решение по подключению, когда пользователи распределены по множеству возможных доменов. Предусмотрена возможность сохранить несколько доменных имен на пул и назначать им URI компонента Focus Factory. Данная настройка видна всем пулам.

Клиентское приложение обменивается данными с компонентом Focus Factory, чтобы начать новую конференцию. Как пояснено выше, поскольку клиентское приложение запрашивает URI компонента Focus Factory, когда пользователь предъявляет пароль, оно имеет средство обмениваться данными с компонентом Focus Factory в любое время, чтобы начать новую специальную конференцию. Когда SIP-клиент хочет обмениваться данными с другим, диалоги SIP между клиентами начинаются с INVITE, отправленным одной стороной другой. Пакет SDP (протокол описания сеанса) переносится для мультимедийного согласования в качестве рабочих данных в INVITE и ответа 200 OK для этого INVITE.

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

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

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

Фиг. 17 иллюстрирует примерную блок-схему последовательности операций вызова при использовании перенаправления. Первоначально, клиент отправляет INVITE в URI компонента Focus Factory, где:

- To=URI компонента Focus Factory

- From=URI Пользователя

- Content-Type=Многокомпонентный MIME

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

Приложение компонента Focus Factory, выполняющееся в пуле, принимает сообщение и возвращает 100 In Progress или 180 Ringing provisional response. Это позволяет клиенту ждать, пока не будет выполнена вся подготовка и поиск данных посредством компонента Focus Factory. Компонент Focus Factory создает компонент Focus и возвращает URI компонента Focus в заголовке контакта 302 Redirect Response. Это позволяет клиенту кэшировать значение заголовка контакта как URI конференции. Клиент отправляет тот же INVITE в URI компонента Focus, который он принял. Единственное различие заключается в том, что "To: заголовок" имеет параметр GRUID, который является идентификатором конференции в данный момент.

Фиг. 18 иллюстрирует примерную блок-схему последовательности операций вызова, которая обрабатывает создание конференции отдельно от присоединения клиента к конференции. Это лучше отражает стадии выполняемого процесса. Таким образом, создание конференции включает в себя передачу INVITE от клиента в компонент Focus Factory, необязательно прием ответа 180 In progress, отправки CreatFocus из компонента Focus Factory в компонент Focus, чтобы создать экземпляр компонента Focus, возврат данных компонента Focus в компонент Focus Factory, отправку URI компонента Focus контакта клиенту и подтверждение приема. Сообщения, ассоциированные с присоединением к конференции, включают в себя отправку INVITE с URI компонента Focus для клиента в компонент Focus, прием 200 OK обратно в клиенте и подтверждение приема.

После приема сообщения INVITE от клиента компонент Focus Factory создает компонент Focus и возвращает клиенту информацию о компоненте Focus. Компонент Focus, так же как и компонент Focus Factory, является конечной точкой SIP, представленной приложением. Компонент Focus Factory перенаправляет запрос INVITE, который он принимает, в компонент Focus, давая ему возможность стать конечной точкой, которая осуществляет мультимедийное согласование с клиентом.

Как указано выше, компонент Focus является "зарегистрированным" обработчиком для конференции. URI компонента Focus представляет конференцию и также упоминается как URI конференции. Один детерминированный способ заключается в том, чтобы использовать фиксированный шаблон для пользовательского раздела URI и снабдить его информацией об идентификаторе конференции. Это дает возможность написания логики маршрутизации более простым способом на основе URI и дает возможность сопоставления URI компонента Focus с одним приложением в компании, что упрощает администрирование системы. Это применение описывается посредством "расширения GRUU/GRID" к SIP, которое дает возможность добавления параметра GRUU в известный URI Компонента Focus. Примерами являются:

Sip:conf-mgr@confserver.company.com; grid=Schumacher1980

Sip:FocusFactoryMS@conferencing.microsoft.com; grid=conf34242834.

Поведение компонента Focus Factory состоит в том, что компонент Focus активен в том же самом пуле, в котором выполняется компонент Focus Factory. Это может быть конфигурируемой настройкой для масштабирования экземпляров компонента Focus конференцсвязи полностью отдельно от регистрационного сервера(ов) SIP.

Экземпляр компонента Focus выполняется на всех внешних интерфейсных машинах пула одновременно. Это позволяет клиентам подключаться к любому внешнему интерфейсу в пуле, обеспечивая распределение загрузки и лучшее масштабирование. Состояние компонента Focus, который должен быть совместно использован среди экземпляров компонента Focus для конференции, сохраняется в базе данных. Эти данные содержат список, роли и права доступа, типы мультимедиа и идентификационные данные MCU и т.д. Каждый экземпляр компонента Focus обрабатывает состояние подключения для клиентов, которые подключены к конкретному внешнему интерфейсу, на котором выполняется экземпляр компонента Focus. Поскольку каждый экземпляр компонента Focus - это конечная точка SIP, этими подключения являются диалоги SIP.

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

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

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

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

Фиг. 20 иллюстрирует примерную блок-схему последовательности операций вызова двух отдельных диалогов "клиент-компонент Focus" с помощью экземпляра компонента Focus. Диалог INVITE - это диалог, который позволяет клиенту присоединяться к конференции, и он используется для дополнительного командного трафика от клиента к компоненту Focus. Команды от клиента переносятся в сообщениях INFO. Тело сообщения INFO содержит XML-тело согласно SOAP и обрабатывается компонентом Focus. Отметим, что одно сообщение INFO на фиг. 20 представляет все сообщения INFO на срок действия конференции. На основе роли, назначенной клиенту, клиент может выдавать команды для управления конференциями, управления политиками конференций, управления мультимедиа или управления мультимедийными политиками.

После того как клиент присоединился к конференции, он должен информироваться о событиях, которые происходят в конференции, такие как присоединение и удаление участников, добавление и удаление мультимедиа и т.д. Эти изменения состояния конференции, а также изменения в политиках для конференции и мультимедиа переносятся через сообщения NOTIFY, отправляемые клиенту в этом диалоге. Если команда, которая отправлена посредством клиента в диалоге INVITE с помощью сообщения INFO, является командой, которая изменяет состояние конференции, компонент Focus сообщает клиенту посредством отправки NOTIFY, содержащего измененный раздел состояния конференции. Отметим, что одно сообщение NOTIFY на фиг. 20 представляет все сообщения NOTIFY на срок действия конференции.

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

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

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

Тип мультимедиа URL компонента MCU Factory A/V http://MCUFactory.1stParty A/V http://MCUFactory.3rdParty

Когда конференция с A/V-операциями создается, компонент Focus, который представляет эту конференцию, входит в контакт с компонентом MCU Factory для типа MCU, который должен быть использован в этой конференции. В таком сценарии, как этот, где присутствует несколько компонентов MCU Factory, компонент Focus выбирает один из компонентов MCU Factory. Использование шаблонов обеспечивает это.

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

Фиг. 21 иллюстрирует примерную блок-схему последовательности операций вызова, когда клиент выдает команду C3P для изменения состояния конференции. Клиент инициализирует последовательность присоединения к компоненту Focus. Команда C3P INFO отправляется от клиента к компоненту Focus. Компонент Focus отвечает с помощью 202 ACCEPT. Компонент Focus отправляет запрос C3P в MCU совместной работы с данными, за которым следует этим же тип запроса в аудио/видео-MCU. Компонент Focus также отправляет ответ INFO C3P клиенту, за которым следует сообщение 200 OK. Далее компонент Focus отправляет уведомление изменения состояния (через BENOTIFY) клиенту. MCU (совместной работы с данными и AV) отправляют ответы C3P в компонент Focus. MCU совместной работы с данными и MCU AV каждый отправляют уведомление изменения состояния посредством команды C3P в компонент Focus. Далее компонент Focus отправляет соответствующие уведомления изменения состояния (через BENOTIFY) клиенту.

Фиг. 22 иллюстрирует команды C3P, которые могут быть использованы в соответствии с распределенной архитектурой конференцсвязи MCU. Команды связаны с уровнем конференции, уровнем пользователя, уровнем панели альтернативной конференции, уровнем конечной точки, уровнем мультимедиа конечной точки, регистрацией, балансировкой нагрузки и диспетчеризацией. На уровне конференции, конференция может быть добавлена, удалена, изменена, изменена по блокировке, изменена с мультимедийными фильтрами, воспроизведена по записанному названию и получена из конференции. На уровне пользователя, пользователь может быть добавлен, удален и изменен, изменен по роли пользователя и задан по пользовательскому доступу. На уровне конечной точки, может быть изменена роль конечной точки. На уровне мультимедиа конечной точки, мультимедийная конечная точка может быть добавлена, удалена и изменена. На уровне панели альтернативной конференции, панель альтернативной конференции может быть добавлена, удалена и изменена. Пользователь также может быть перемещен на панель альтернативной конференции. В отношении регистрации, регистрация может быть начата, остановлена, приостановлена и возобновлена. В отношении диспетчеризации, типы доступных MCU, ключ шифрования и конференции могут быть получены (через get). В отношении балансировки нагрузки, MCU может быть получен наряду со значениями ping.

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

В конфигурации с одним сервером все серверные компоненты, необходимые для предоставления присутствия, мгновенного обмена сообщениями, многосторонней веб-конференцсвязи, аудио-видео-конференцсвязи и регистрации, могут быть установлены на одной машине. В этом режиме "домашний сервер" для регистрации и присутствия, менеджер конференции, компоненты Focus конференции, компоненты A/V-MCU и компоненты MCU данных, к примеру, все выполняются на одном сервере. Эта конфигурация поддерживает небольшое количество пользователей и параллельных собраний. Например, установка с одним сервером может поддерживать до 500 параллельных пользователей для присутствия, при условии, что не более 100 пользователей выполняют IM в любой данный момент и задано не более 50 параллельных участников мультимедийной конференции (данные/аудио-видео). Регистрация, а также базы данных конференции также могут выполняться на одном сервере. Порты TCP и пространства имен URL являются совместно используемыми ресурсами.

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

Каждый из этих внешних интерфейсов 2300 включает в себя не только функциональность регистрации, присутствия и маршрутизации, но также и функциональность конференцсвязи. Каждый внешний интерфейс выполняет экземпляр компонента Focus Factory, компонента MCU Factory, нуль или более хост-процессов компонента Focus и процессы MCU мультимедиа. Логика обнаружения и обхода сбоев может быть расширена так, чтобы включать в себя сеансы конференцсвязи. Если конференция выдает ошибку в середине, клиенты могут обратно подключиться к компоненту Focus, экземпляр которого повторно создан на другом внешнем интерфейсном сервере, как только сбой обнаружен в пуле серверов 2300. Новый компонент Focus восстанавливает такое состояние, как он имел из предыдущего воплощения компонента Focus, и позволяет клиентам продолжать работу с места, где они остановились в конференции.

Все серверы 2300 имеют эквивалентную функциональность. Программные компоненты, такие как компонент Focus Factory, компоненты Focus, компонент MCU Factory, MCU, интерфейсы веб-диспетчеризации и т.д., устанавливаются на всех внешних интерфейсных серверах. Хотя компонент Focus и MCU имеют различные характеристики масштабирования, эта конфигурация предлагает простоту установки и управления при обеспечении высокой доступности и восстановления после сбоя. Архитектура также позволяет разделение MCU на отдельные блоки.

Фиг. 24 иллюстрирует конфигурацию 2400 пула из нескольких серверов для характеристик высокой доступности и восстановления после сбоя. Помимо этого, он предлагает возможность разделить функции с различными характеристиками масштабирования на различные серверы. Дополнительно MCU 2402 могут быть соединены в цепочку вместе для масштабирования конференций, а также чтобы обеспечить интеграцию или между компаниями, или между компанией и размещаемой службой. MCU ретранслируют, смешивают и обрабатывают мультимедиа. Передача и обработка мультимедиа является гораздо более затратной в отношении ресурсов процессора и сети по сравнению с сигнализацией и данными управления конференциями, которые передаются через компонент Focus. Соответственно, MCU могут быть масштабированы независимо от элементов управления присутствием, сигнализацией и конференциями.

Фиг. 25 иллюстрирует представление топологии различных типов потоков данных между объектами архитектуры распределенных мультимедийных компонентов. Клиент-серверный (C/S) обмен данными, такой как с помощью MCU (к примеру, IM MCU, A/V-MCU) и к выравнивателю нагрузки, может выполняться через SIP. Выравниватель нагрузки может взаимодействовать с внешними интерфейсными серверами также с помощью SIP. Для аудио/видео-потоков клиент может взаимодействовать с помощью RTP/RTCP. Для взаимодействия с MCU совместной работы с данными клиент может использовать PSOM. Каждый MCU может взаимодействовать с внешними интерфейсными серверами с помощью HTTP, который также использует компонент MCU Factory. Доступ к веб-серверу конференции может осуществляться посредством приложения обозревателя. Веб-сервер может осуществлять доступ к внутреннему интерфейсному серверу компонента Focus (к примеру, SQL Server), например, с помощью ODB (база данных объектов)/ADO (объекты данных ActiveX). Внешний интерфейсный сервер (к примеру, Frontend1) может также осуществлять доступ к внутреннему интерфейсному серверу с помощью ODB/ADO. Сервер-серверный (S/S) обмен данными (к примеру, IM MCU с пулом серверов, A/V-MCU с пулом серверов) может осуществляться с помощью SIP. Выравниватель нагрузки может взаимодействовать с одним или более из внешних интерфейсных серверов с помощью сервер-серверного SIP.

Фиг. 26 иллюстрирует полную архитектуру 2600 конференцсвязи, использующую подключаемые и распределенные мультимедийные компоненты. Архитектура 2600 также дает возможность экранирования нескольких MCU, используемых для того же самого типа мультимедиа, например, реализуя каскадирование между MCU Voice IP и MCU PSTN для соединения IP- и PSTN-участников в одну и ту же конференцию. После того как конференция и ее URI конференции распределены (с помощью интерфейса A), и клиент принимает разрешение компонента Focus для доступа к конференции (с помощью интерфейса B), клиент подписывается на информацию о состоянии события конференции (по интерфейсу C) и извлекает фактический URI конференции на мультимедийный MCU из документа, принимаемого в первом событии от компонента Focus (по интерфейсу C). Клиент использует извлеченный URI MCU конференции для того, чтобы выполнить входящее коммутируемое подключение (или присоединиться) к конференции и выполнить собственные базовые операции сигнализации SIP-вызова непосредственно с MCU (по интерфейсу D).

Сигнализация SIP (по интерфейсу D) будет автоматически направляться через прокси-сервер компонента Focus посредством средства маршрутизации SIP. Протокол сигнализации и данных PSOM (по интерфейсу L) маршрутизируется непосредственно между клиентом и MCU данных. Подключения SIP, направляемые через прокси-сервер компонента Focus, имеют возможность анализа и осуществления локальных политик, касающихся аутентификации, авторизации, членства и т.д. Отметим, что с этих пор в случае MCU PSTN и MCU данных собственная сигнализация вызова не направляется через прокси-сервер компонента Focus. Политика для этих MCU может быть явно выгружена из компонента Focus в MCU. Клиент использует диалог SIP, установленный с первоначальным URI конференции (по интерфейсу B), чтобы выполнить любой другой тип управления конференциями с помощью CCCP, также упоминаемого в данном документе как C3P.

С точки зрения компонента Focus, MCU ACP обрабатывается как любой другой MCU IP за исключением того, что транспортом является SIP вместо HTTP. Этот интерфейс проиллюстрирован показанным на рисунке как B** и C**, где B** является туннелированием CCCP по SIP, а C** является пакетом конференции XML-событий, туннелированным по SIP. В одной реализации логический модуль GW (шлюза) ACP реализуется, чтобы позволить ACP, уже поддерживающим протокол SIP-CX, прозрачно интегрироваться в инфраструктуру.

Поскольку собственная сигнализация (к примеру, в этом случае сигнализация PSTN) не видима компоненту Focus, реализуется дополнительное установление связи безопасности (адресующая авторизация) между компонентом Focus и MCU ACP (и GW ACP).

MCU данных не нуждается в реализации SIP. Следовательно, попытка посредством клиента выполнить входящее коммутируемое подключение к конференции будет иметь результатом перенаправление к URI HTTP, указывающему на MCU данных. Отметим, что все вопросы безопасности (включая аутентификацию и авторизацию) могут рассматриваться непосредственно между клиентом данных и MCU данных с использованием PSOM.

Относительно состояния и уведомлений конференции, каждый MCU в системе хранит информацию о состоянии для каждой из конференций, для которых он выступает в качестве хоста. Эта информация представляет конкретное для мультимедиа представление MCU конференции. MCU помещает изменения в состоянии их конференции в основной компонент Focus по пакету конференции интерфейса C* XML-событий по HTTP. Основной компонент Focus динамически принимает индивидуальную информацию о состоянии от каждого MCU (по интерфейсу C*), объединяет информацию и распространяет готовое представление конференции клиентам (по интерфейсу C) согласно каждой клиентской подписке и правам доступа. Каждый заинтересованный клиент и потенциальный участник может SUBSCRIBE (подписаться) на интересующую конференцию (с помощью URI конференции) с помощью основного компонента Focus (по интерфейсу C).

В первое уведомление о состоянии конференции каждому абоненту компонент Focus включает всю информацию о конференции. Если микширование для конференции выполняется посредством нескольких мультимедийных MCU, URI мультимедийной конференции, маршрутизируемые к каждому из MCU, перечисляются как conf-URI конференции. Клиент анализирует XML-документ состояния конференции и инициализирует соответствующую собственную сигнализацию (к примеру, INVITE по интерфейсу D или MCU данных по интерфейсу L) в направлении MCU.

Использование SIP означает, что участник может присоединяться и выходить из конференции. Использование SIP также означает, что участник может изменить собственные мультимедийные потоки посредством отправки повторного INVITE в MCU. Этот вид операции называется "собственной сигнализацией" и показан как интерфейс D. Эти операции не затрагивают состояние других участников в конференции.

Ограниченные операции для управления другими участниками конференции (называемые "сторонней сигнализацией") через компонент Focus с помощью SIP также могут быть получены. Чтобы выполнять более универсальное управление конференциями, пользовательский клиент может реализовать CCCP-клиент. Используя CCCP по интерфейсу B, клиент может повлиять на собственное состояние, состояние других участников и состояние компонентов Focus/MCU, что может косвенно повлиять на состояние участников конференции. Управление конференциями с помощью CCCP логически выполняется для состояния конференции. Используя запросы CCCP, клиент выражает то, каким бы он хотел видеть состояние конференции. CCCP-сервер выполняет операцию и обновляет свое "главное" состояние конференции так, чтобы отразить изменения.

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

Компонент Focus создает новую конференцию с помощью компонента MCU Factory. Компонент Focus включает в себя список доступных компонентов MCU Factory в системе или пуле с соответствующими URI, поддерживаемыми типами мультимедиа, и URI управления для каждого. Каждый компонент MCU Factory представляет логический набор MCU, имеющих поддерживаемый тип мультимедиа, где новые конференции могут быть выделены. Чтобы выделить новую конференцию, компонент Focus выбирает один совместимый компонент MCU Factory из таблицы и выдает запрос CCCP-примитива getMcu для своего URI управления (по интерфейсу F). CCCP-запрос на то, чтобы выбрать MCU, может содержать объект конференции, описывающий требуемое описание конференции и характеристики. Успешный ответ включает в себя URI управления MCU, которому адресуются CCCP-запросы. В случае сбоя компонент Focus пробует другой совместимый компонент MCU Factory. Отметим, что URI управления компонентом Factory MCU и URI управления MCU могут быть одинаковыми или различными URI согласно реализации компонента Factory MCU. Описанное разложение позволяет каждому поставщику MCU реализовать балансировку нагрузки (или другого вида логики) для своей фермы MCU, не затрагивая архитектуру.

Интерфейс управления между основным компонентом Focus и каждым MCU (интерфейс B*) служит для выдачи запросов от компонента Focus и может быть реализован с помощью CCCP. По этому интерфейсу компонент Focus выступает в качестве CCCP-клиента, а MCU выступает в качестве CCCP-сервера.

Далее предоставляется краткое изложение интерфейсов. Интерфейс A является SIP-интерфейсом для создания специальной (ad hoc) конференции; интерфейс B служит для cc-конференцсвязи (собственной и ограниченной сторонней) и CCCP по SIP; интерфейс B* служит для CCCP по HTTP; интерфейс B** служит для CCCP-туннелирования по SIP; интерфейс B*** - SIP-CX по SIP; интерфейс C служит для SUBSCRIBE/NOTIFY относительно пакета конференции по SIP; интерфейс C* служит для XML-событий пакета конференции по HTTP; интерфейс C** служит для XML-событий пакета конференции, туннелированных по SIP; интерфейс C*** служит для XML-событий пакета конференции как в SIP-CX; интерфейс D служит только для собственных SIP; интерфейс F служит для CCCP по HTTP только для создания/выделения конференции; интерфейс L служит для протокола данных (данные и собственная сигнализация); интерфейс М служит для мультимедиа (к примеру, RTP/RTPC для голоса и видео); интерфейс P служит для обмена данными между компонентом Focus Factory и компонентом Focus.

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

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

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

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

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

Согласно фиг. 27, примерная среда 2700 для реализации различных аспектов включает в себя компьютер 2702, причем компьютер 2702 включает в себя процессор 2704, системное запоминающее устройство 2706 и системную шину 2708. Системная шина 2708 соединяет системные компоненты, в том числе, но не только, системное запоминающее устройство 2706 с процессором 2704. Процессор 2704 может быть любым из различных предлагаемых на рынке процессоров. Архитектуры с двумя микропроцессорами и другие многопроцессорные архитектуры также могут быть использованы в качестве процессора 2704.

Системная шина 2708 может быть любой из нескольких типов шинных структур, которые могут дополнительно соединяться с шиной памяти (с контроллером памяти или без него), периферийной шиной и локальной шиной с помощью любой из множества предлагаемых на рынке шинных архитектур. Системное запоминающее устройство 2706 включает в себя постоянное запоминающее устройство (ROM) 2710 и оперативное запоминающее устройство (RAM) 2712. Базовая система ввода/вывода (BIOS) сохраняется в энергонезависимой памяти 2710, такой как ROM, EPROM, EEPROM, причем BIOS содержит базовые процедуры, которые помогают передавать информацию между элементами в компьютере 2702, к примеру, во время запуска. RAM 2712 также может включать в себя высокоскоростное RAM, такое как статическое RAM для кэширования данных.

Компьютер 2702 дополнительно включает в себя внутренний жесткий диск (HDD) 2714 (например, EIDE, SATA), причем этот внутренний жесткий диск 2714 также может быть выполнен с возможностью внешнего использования в подходящем шасси (не показано), накопитель 2716 на гибких магнитных дисках (FDD) (например, чтобы считывать или записывать на сменную дискету 2718) и накопитель 2720 на оптических дисках (например, осуществляющий считывание диска 2722 CD-ROM, или чтобы считывать или записывать на другие оптические носители большой емкости, такие как DVD). Жесткий диск 2714, накопитель 2716 на магнитных дисках и накопитель 2720 на оптических дисках могут быть подключены к системной шине 2708 посредством, соответственно, интерфейса 2724 жесткого диска, интерфейса 2726 накопителя на магнитных дисках и интерфейса 2728 накопителя на оптических дисках. Интерфейс 2724 для реализаций с внешним накопителем включает в себя, по меньшей мере, одну или обе из интерфейсных технологий универсальной последовательной шины (USB) или IEEE 1394 (FireWire). Другие технологии подключения внешних накопителей находятся в пределах рассмотрения настоящего изобретения.

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

Ряд программных модулей может быть сохранен в накопителях и RAM 2712, включая операционную систему 2730, одну или более прикладных программ 2732, другие программные модули 2734 и программные данные 2736. Все или части операционной системы, приложений, модулей, и/или данных могут также кэшироваться в RAM 2712. Следует принимать во внимание, что изобретение может быть реализовано с различными предлагаемыми на рынке операционными системами или комбинациями операционных систем.

Пользователь может вводить команды и информацию в компьютер 2702 через одно или более проводных/беспроводных устройств ввода данных, например, клавиатуру 2738 и указательное устройство, такое как мышь 2740. Другие устройства ввода данных (не показаны) могут включать в себя микрофон, ИК-пульт дистанционного управления, джойстик, игровую панель, перо, сенсорный экран и т.п. Эти и другие устройства ввода данных часто подключены к процессору 2704 через интерфейс 2742 устройств ввода, который соединяется с системной шиной 2708, но могут быть подключены посредством других интерфейсов, таких как параллельный порт, последовательный порт стандарта IEEE 1394, игровой порт, USB-порт, ИК-интерфейс и т.п.

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

Компьютер 2702 может работать в сетевом окружении, используя логические подключения через проводную и/или беспроводную связь к одним или более удаленным компьютерам, таким как удаленный компьютер(ы) 2748. Удаленный компьютер(ы) 2748 может быть рабочей станцией, сервером, маршрутизатором, персональным компьютером, портативным компьютером, основанным на микропроцессоре развлекательным устройством, равноправным устройством или другим общим сетевым узлом, и типично включает в себя многие или все элементы, описанные относительно компьютера 2702, хотя в целях краткости только запоминающее устройство/устройство 2750 хранения проиллюстрировано. Проиллюстрированные логические подключения включают в себя проводные/беспроводные возможности подключения к локальной вычислительной сети (LAN) 2752 и/или боле крупным сетям, например, глобальной вычислительной сети (WAN) 2754. Такие сетевые окружения LAN и WAN являются общепринятыми в офисах и компаниях и способствуют корпоративным вычислительным сетям, таким как сети интранет, все из которых могут подключиться к сети глобальной связи, например Интернету.

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

При использовании в сетевой среде WAN, компьютер 2702 может включать в себя модем 2758 или подключаться к серверу связи в WAN 2754, или имеет другое средство для установления связи по WAN 2754, к примеру, посредством Интернета. Модем 2758, который может быть внутренним или внешним и проводным или беспроводным устройством, подключается к системной шине 2708 через интерфейс 2742 последовательного порта. В сетевой среде программные модули, показанные относительно компьютера 2702, или их части могут быть сохранены в удаленном запоминающем устройстве/устройстве 2750 хранения. Следует принимать во внимание, что показанные сетевые соединения являются примерными, и другие средства установления линии связи между компьютерами могут быть использованы.

Компьютер 2702 выполнен с возможностью обмениваться данными с любыми беспроводными устройствами или объектами, функционально находящимися в беспроводной связи, например, принтером, сканером, настольным и/или портативным компьютером, портативным цифровым помощником, спутником связи, любой единицей оборудования или местоположением, ассоциированным с обнаруживаемым беспроводными средствами тегом (например, киоском, новостным стендом, помещением для отдыха) и телефоном. Это включает в себя, по меньшей мере, беспроводные технологии Wi-Fi и Bluetooth™. Таким образом, связь может быть заранее заданной структурой, как в случае традиционной сети, или просто специальной связью, по меньшей мере, между двумя устройствами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

14. Способ по п.10, дополнительно содержащий этап, на котором ассоциируют URI-адрес с каждым из MCU, причем участник сеанса осуществляет доступ к сеансу конференции через один из MCU.

15. Способ по п.10, в котором упомянутый запрос является запросом протокола инициирования сеанса (SIP).

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

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

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

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

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