Распределяемая, масштабируемая, подключаемая архитектура конференцсвязи

Распределяемая, масштабируемая, подключаемая архитектура конференцсвязи

Иллюстрации

Показать все

Реферат

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

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

Операторы и поставщики сетей (как сотовых, так и несотовых) тратят огромные суммы денег и ресурсы на инфраструктуру для того, чтобы поддерживать множество типов портативных устройств и мультимедиа, существующих сегодня, и тех, которые появятся на рынке в будущем. Например, операторы сотовой связи стараются предоставить инфраструктуру, которая позволяет клиенту сотовой связи осуществлять доступ к 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, мультимедийный процессор имеет очень специализированное знание о смешивании аудио и видеопотоков, стыковке видеопотоков, преобразовании с понижением частоты мультимедиа для клиентов, которые находятся на медленных линиях связи, и так далее. Из всех компонентов конфер