CN102904733B - 分布式、可缩放、可插入的会议体系结构 - Google Patents

Abstract

用于可缩放、可插入、多方、和分布式多媒体会议的体系结构。集中式策略和控制会议组件允许无缝地插入不同的分布式媒体组件（例如，数据、音频/视频、消息传送），以适应客户机参与会议会话。该集中式会议控制组件包括以下：用于接受对会议状态的订阅并通知订阅者该状态的变化的会议通知服务；用于存储和操纵会议策略和名单的会议策略和名单控制服务；用于基于用户身份信息来授权/认证用户的安全服务；用于会议调度的调度服务；用于分配会议会话的最可用的媒体组件的分配服务；以及用于分布式媒体组件的会议策略和名单管理的MCU管理服务。

Description

分布式、可缩放、可插入的会议体系结构

本发明专利申请是2007年9月5日提交的、进入中国国家阶段的申请号为200780033969.7、发明名称为“分布式、可缩放、可插入的会议体系结构”的发明专利申请的分案申请。

背景

计算设备和联网的技术进步继续提供对各种各样的信息和服务的更多访问，从而实际上允许从世界的任何地方访问。由于需要完成的工作可从大多数位置来执行，因此虚拟办公室变得更加常见。

网络运营商和供应商（蜂窝和非蜂窝）在基础设施上花费大量的金钱和资源，以支持现在存在的和将来将要上市的多种类型的便携式设备和媒体。例如蜂窝运营商正在争相提供允许蜂窝客户经由蜂窝网络访问IP网络（例如，因特网）和相关联的IP服务的基础结构。因此，蜂窝客户现在可访问基于IP的网络上可用的信息。类似地，计算设备可以通过IP网络进行对话，且甚至可以连接到蜂窝用户。

例如，各企业仍然认识到会晤在高效地推动产品开发上的重要性。然而，将用户从其从其所处的多个远程位置聚在一起进行商务活动，并支持多种可用的通信设备和媒体类型，其前景还是很有挑战性。

会议可以是公司企业的雇员可以例如进行会晤的有效手段。然而，给定任何时刻上的位置和连接能力，参与者可能想要经由不同的媒体类型加入。随着便携式无线计算设备的存储和计算能力的进步，用户现在能够与多种类型的不同数据类型进行交互，比如图像、视频剪辑、音频数据和文本数据。此外，用户通常可以具有若干类型的用其连接到会话的设备。例如，一用户可以从会议室通过音频/视频参与，另一用户经由台式计算机通过语音参与，而又一用户使用蜂窝电话通过文本输入参与。

这些不同的媒体能力传统上在服务器级通过本地地合并媒体处理能力来提交。然而，这是有问题的，因为需要更多资源来管理这些系统且这些系统更难以缩放以满足会议需求。

概述

以下呈现了本发明的简化概述，以提供对所公开的本发明的某些方面的基本理解。该概述不是详尽的概览，它不旨在标识关键/重要的元素，也不旨在描绘其范围。其唯一的目的是以简化的形式来介绍一些概念，作为稍后提出的更为详细的描述的序言。

此处所公开的是体系结构，其描述用于多方、多媒体会议的可缩放、可插入的体系结构。提供了用于允许无缝地插入诸如多点控制单元（MCU）等不同的分布式媒体组件的集中式策略和控制组件的框架。会议体系结构支持用于供客户机参与该会话的不同媒体类型（例如，数据、音频/视频、即时消息传送）的多个可插入分布式媒体组件。

例如，为满足会议需求，客户机访问（例如，经由因特网连接）还被称为焦点的集中式控制组件，请求创建、调度会议会话或参与一当前会话。控制组件包括连接到客户机并向其分配适当的媒体接口（例如，音频、视频、数据），配置该媒体接口以满足所请求的客户机媒体类型，提供该会议会话的会话管理，以及针对所有相关联的客户机和系统管理会话的关闭和清除的能力。

该集中式会议控制组件还提供调度服务和会话实例的创建（经由焦点工厂）。该会议控制器还包括向会议会话分配一个或多个最可用的分布式媒体组件（经由媒体工厂）的功能。该会议控制组件还用作会议策略和名单（roster）控制服务。会议策略服务器是可以存储和操纵会议策略和名单的逻辑功能。会议策略是管控会议的操作的规则的总体集合，且可被分解为成员资格策略和媒体策略。

该会议控制组件包括会议通知服务，其是允许焦点用作通知者，接受对会议状态的订阅，以及将该状态的改变通知订阅者的逻辑功能。状态包括例如焦点本身所维护的状态、会议策略和媒体策略。该会议控制组件还用作基于身份信息和/或PIN来经由用户授权和/或认证服务提供会话安全。该集中式会议控制器还通过接口连接到用于会议策略和名单管理服务的分布式媒体组件（例如，MCU）。该会议体系结构使用来自焦点的单个集成式名单向会议参与者提供单个会议图片，且可以通过该焦点控制会议。

为了对其进行支持，此处所公开的和要求保护的体系结构包括计算机实现的会议系统，该系统包括用于集中控制会议会话的会议控制组件和用于使用一媒体类型将客户机通过接口连接到会议会话的分布式媒体组件。该媒体组件可以在任何位置（例如，因特网上），从而允许例如经由HTTP访问。该集中式控制器不需要知道关于该分布式媒体组件的任何事物。

为了实现前述及相关目的，在这里结合下列描述及附图来描述所公开的本发明的某些说明性方面。然而，这些方面仅指示了其中可利用此处公开的原理的各种方法中的少数几种，且旨在包括所有这些方面及其等效方面。结合附图阅读下面的详细描述，则其它优点和新颖特征将变得清楚。

附图简述

图1示出用于分布式媒体访问的计算机实现的会议系统。

图2示出根据所公开的会议体系结构使用分布式媒体组件管理会议会话的方法。

图3示出会话管理的更详细方法。

图4示出使用基于web的会议控制组件和分布式媒体组件便于创建会议会话的系统的更详细框图。

图5示出在内联网客户机与各参与者交互以创建和加入会议的情况下，参与者之间的数据流。

图6示出用于实现会议系统的组件体系结构的示例性详细示图。

图7示出示例性服务器体系结构和用于会议和分布式MCU的协议的示图。

图8示出用于经由web接口/服务发起会议创建的示例性呼叫流程图。

图9示出用于经由SIP邀请（Invite）机制发起会议创建的示例性呼叫流程图。

图10示出用于经由SIP服务（Service）机制发起会议创建的示例性呼叫流程图。

图11示出用于客户机拨入会议的示例性呼叫流程图。

图12示出用于客户机通过addUser（添加用户）拨入经由数据协作MCU加入的示例性呼叫流程图。

图13示出用于客户机通过addUser拨出经由音频/视频MCU加入的示例性呼叫流程图。

图14示出用于客户机经由对MCU的直接邀请来加入的示例性呼叫流程图。

图15示出对另一客户机参与者的产生拨入的自组织（ad hoc）邀请的示例性呼叫流程图。

图16示出对另一客户机的自组织拨出INVITE（邀请）的示例性呼叫流程图。

图17示出使用重定向的示例性呼叫流程图。

图18示出将创建会议和客户机加入会议分开的示例性呼叫流程图。

图19示出服务器池系统，该系统在池中的不同前端机器上运行的多个焦点应用程序实例之间共享状态。

图20示出两个分开的客户机焦点用焦点实例进行对话的示例性呼叫流程图。

图21示出在其中客户机发出用于修改会议状态的C3P命令的示例性呼叫流程图。

图22示出可以根据分布式MCU会议体系结构使用的C3P命令。

图23示出在其中各前端服务器具有等效功能的多服务器池。

图24示出用于故障恢复和高可用性特征的多服务器池配置。

图25示出分布式媒体组件体系结构的各实体之间的各类数据流的拓扑图。

图26示出使用可插入和分布式媒体组件的总体会议体系结构。

图27示出可用于根据所公开的体系结构执行集中式和分布式会议的计算机的框图。

图28示出便于分布式媒体会议的示例性计算环境的示意性框图。

详细描述

现在参照附图描述本发明，其中相同的附图标记用于指代全文中相同的元素。在以下描述中，为解释起见，描绘了众多具体细节以提供对本发明的全面理解。然而，显然，本发明可以在没有这些具体细节的情况下实现。在其它情况下，以框图形式示出了公知的结构和设备以便于描述它们。

所公开的体系结构是用于多方、多媒体会议会话的可缩放、可插入的体系结构。集中式策略和控制会议组件允许无缝地插入不同的分布式媒体组件（例如，数据、音频/视频、消息传送），以适应客户机参与会议会话。该集中式会议控制组件包括以下：用于接受对会议状态的订阅并通知订阅者该状态改变的会议通知服务；用于存储和操纵会议策略和名单的会议策略和名单控制服务；用于基于用户身份信息来授权/认证用户的安全服务；用于会议调度的调度服务；用于向会议会话分配最可用媒体组件的分配服务；以及用于分布式媒体组件的会议策略和名单管理的MCU管理服务。

开始参考附图，图1示出用于分布式媒体访问的计算机实现的会议系统100。系统100是支持供会话参与者经由多个不同设备访问的多个可插入分布式媒体系统的可插入会议体系结构。为此，系统100包括用于集中式地创建和控制会议会话的基于网络的会议控制组件102。系统100的控制组件102通过接口连接以管理诸如多点控制单元（MCU）的一个或多个分布式媒体组件104（由媒体组件₁、……、媒体组件_N表示，其中N是正整数），分布式媒体组件104又提供由客户机106（由客户机₁、……、客户机_M表示，其中M是正整数）经由类似的和/或不同的媒体模式（例如，音频、视频）对会议会话进行客户机访问。

MCU是便于连接和管理一种或多种客户机媒体类型的系统。媒体直接在客户机和MCU之间交换。常规系统不使用MCU，其至少包括根据所公开的新颖体系结构所提供的MCU的分布式能力。

换言之，为满足会议要求，客户机108访问（例如，经由因特网连接）控制组件102，请求创建会议会话。控制组件102便于向会话参与者（例如，客户机101和客户机₁、客户机₂和客户机₃）及其所需连接类型（例如，音频、视频）分配适当的媒体组件104（例如，媒体组件110和112），管理媒体组件104的接口管理，配置一个或多个媒体组件104以满足所请求的会议要求，会话期间的会话管理，以及针对所有相关联系统关闭和清除会话。

图2示出根据所公开的会议体系结构使用分布式媒体组件管理会议会话的方法。尽管出于解释简明的目的，此处例如以流程图形式示出的一个或多个方法被示出并描述为一系列动作，但是可以理解和明白，本发明不受动作的次序的限制，因为根据本发明，某些动作可以按不同次序和/或与此处所示并描述的其它动作同时发生。例如，本领域技术人员将会明白并理解，方法可被替换地表示为一系列相互关联的状态或事件，诸如以状态图的形式。而且，并非所有示出的动作都是实施根据本发明的方法所必需的。

在200，提供中央会议控制组件以供会议会话管理。在202，控制组件以分布式和可寻址的方式提供一个或多个媒体组件（例如，MCU），以经由相同的或不同的媒体类型（例如，即时消息传送、音频）连接会话参与者。在204，从客户机接收创建会议会话的请求。在206，控制组件实例化会议实例。在208，向客户机返回用于访问该会话的访问信息。在210，控制组件评估支持参与者和所请求的参与者媒体类型的媒体组件的可用性。在212，控制组件分配预期会话媒体类型的一个或多个媒体组件。在214，向参与者通知该会话。在216，控制组件通过认证参与者对会话的访问来便于安全处理。

图3示出会话管理的更详细方法。在300，客户机使用网址连接到基于web的会议控制组件。在302，客户机向控制组件发送会议信息。该信息包括该会话的设置和配置信息，比如参与者信息、该会话的时间和数据、以及支持参与者访问的媒体类型。在304，控制组件创建会话实例，并返回该会话的URI（统一资源标识符）和分配给该会话的媒体组件的一个或多个URI。在306，客户机将该URI信息传递给参与者。该会话开始且在308，向参与者通知会话状态的改变。在310，控制组件便于在会话期间创建和终止私下（sidebar）会议。在312，向会话参与者通知会话退出者（离开的参与者），关闭该会话，且系统执行清除（例如，关闭MCU、会话实例等）。

现在参考图4，示出了便于使用基于web的会议控制组件402和分布式媒体组件404创建会议会话的系统400的更详细框图。系统400包括作为集中式会议控制器的会议控制组件402（在此也被称为焦点（focus）组件）。焦点组件402包括提供会议通知服务的通知组件406。会议通知服务是焦点组件402所提供的逻辑功能。焦点组件402可以通过接受对会议状态的订阅和向订阅者（或参与者）通知该状态的改变来作为通知者。

焦点组件402还包括用于提供策略和名单控制服务的会议策略/名单组件408。作为组件408的一部分的会议策略服务器是可以存储和操纵会议策略/名单的逻辑功能。会议策略是管控会议的操作的规则的总体集合，且被分解为成员资格策略和媒体策略。通知组件406所监视的状态包括焦点组件402自身所维护的状态、会议策略、以及媒体策略。

焦点组件402还包括启用会议调度的调度组件/焦点工厂（focusfactory）组件410。认证组件412基于身份（例如，活动目录）或使用PIN来提供用户授权和认证处理。MCU接口组件414便于通过接口连接到用于会议名单/策略管理的多个分布式媒体组件404（例如，各个MCU 404）（由MCU₁、MCU₂、……、MCU_T表示，其中T是正整数）。焦点402包括MCU分配组件（也被称为MCU工厂）416，其功能是对该会议会话分配网络418（例如，因特网）最可用的基于网络的MCU 404。系统400还包括各个可插入会议参与者（由客户机420表示），它们从主焦点获得具有单个集成式名单的单个会议图片，并且可以通过该焦点控制该会议。

图5示出在内联网客户机与各参与者交互以创建和加入会议的情况下，各参与者之间的数据流。在所公开的集中式会议体系结构中，存在对所有会议参与者可见的单个（或主）焦点。该焦点是同一会议中的各参与者的单个中央信令点。每一会议由唯一的SIP（会话发起协议）可路由会议URI来标识。通常，该URI路由到MCU所实现的、主存该会议的焦点。

为了提供改进的用户体验，该系统引入主焦点的概念，其中所有会议URI都路由到该主焦点。客户机用户被该焦点授权参加会议，他们从该焦点获得关于会议状态的改变的通知，且所有的会议控制操作由客户机向该主焦点发起。

该体系结构的各组件是客户机500、焦点工厂502、焦点504、MCU工厂506和MCU 508。所公开的会议体系结构的主特征之一是使用以分布式方式操作的多个组件而非常规的单片服务器体系结构。

会议客户机500是能够加入和参与会议的端点。客户机500首先与焦点工厂502交互来创建会议。

焦点工厂502是创建会议的焦点504的实体。焦点工厂502将客户机500指向将在其中举行会议的适当焦点位置。焦点工厂502是在SIP前端机器上运行的作为SIP端点的应用程序，且其可用SIP URI来寻址。

焦点工厂502是可SIP寻址的，且可使用HTTP（超文本传输协议）和SOAP（简单对象访问协议）URI来寻址。在一个架构实现中，焦点工厂502与焦点504共同配置在一起；在另一架构实现中，其未与之一起配置。每一会议池可被看作焦点工厂。

焦点504是会议会话的集中式策略和状态管理器。焦点504是表示会议的SIP端点，且用作会议的所有方面的中央协调者。焦点504负责实施会议控制策略，管理会议的总体安全，向客户机通知会议状态更新，并提供用于控制命令在客户机500和MCU 508之间流动的管道。

焦点504还代表所有客户机与作为会议的一部分的每一媒体类型的MCU交互。焦点504存储应答会议查询所需的所有状态或在一个前端服务器失效的情况下再生会议所需要的状态。会议信息可被持久保存在SQL（结构化查询语言）服务器数据库以供将来使用，直到会话清除为止。焦点实例运行在会议池上。这允许客户机连接到池中的任何前端服务器，从而允许更好的可用性、负载分布、和更好的缩放性。焦点504还负责程序引导MCU和维护通过例如HTTP接口的连接。在某些情况下，焦点504还可以用作代理来代理C3P（或CCCP——会议控制信道协议）命令和通知。这将在以下描述。

焦点的概念对SIPPING顺应会议是重要的。SIPPING是被特许定义对SIP的会议扩展的IETF（因特网工程任务组）工作组。SIPPING的特许权是定义会议状态事件包模式。

MCU工厂506是SIPPING概念，且向特定媒体类型的会议会话分配MCU 508。MCU工厂506负责使用用于创建会议的本地策略，来在MCU 508上提供特定媒体类型的会议。MCU工厂506在向会议分配MCU之前还可以考虑MCU上的当前负载。在一实现中，每一媒体类型可以有一个MCU工厂506。

MCU 508负责管理一个或多个媒体类型。在所公开体系结构的一个场景中，所有会议控制命令都被客户机500发送到焦点504，焦点504随后在验证发送该请求的客户机500具有执行该操作的特权后，又将这些命令中继到适当的MCU 508。媒体随后直接在客户机500和MCU 508之间交换。

MCU类型可以包括数据协作MCU、音频/视频MCU、IM（即时消息传送）MCU和ACP（音频会议提供商）MCU。合适设计的第三方MCU可以插入到该体系结构中以增强参与者体验，例如，用于音频/视频增强。该体系结构允许视将来所需而容易地添加其它MCU。例如，可以提供合适设计的MCU来用于应用程序共享或聊天。

以下是数据流的更详细概要，其包括通信信道、在各组件之间交换的数据的语义和类型。

图5的客户机/焦点工厂通信（由①所示）通过客户机500首先定位焦点工厂502开始。客户机应用程序与焦点工厂502通信来开始新的会议。如上所述，由于客户机应用程序在用户登入时获得焦点工厂URI，因此客户机500具有在任何时刻与焦点工厂502通信以开始新的自组织会议的手段。客户机500不关心焦点工厂502例如位于服务器池的哪一服务器上；其只需要连接焦点工厂SIP URI。

在所公开的框架中，创建会议意味着创建和配置焦点实例。焦点工厂502的工作是将焦点504的URI返回到客户机500。这意味着客户机500和焦点工厂502之间的对话不必持久，而只需持续充分长直到焦点URI被返回到客户机500为止。在其向客户机504返回焦点URI之前，焦点工厂503创建（若有必要）并配置焦点504。

客户机500可以提前将其需要的关于会议角色定义、媒体类型、特权、参与者等的所有信息传递到焦点工厂502，以使焦点工厂502可返回具有最终数据的成功响应。

参考图5的焦点工厂/焦点通信（由②表示），在从客户机500接收到请求后，焦点工厂502创建焦点504并向客户机500返回焦点URI（由③表示）。正如焦点工厂502一样，焦点504是由应用程序所表示的SIP端点。焦点工厂502将其从客户机500接收到的请求重定向到焦点504，从而允许焦点504成为与客户机500执行媒体协商的端点。在将焦点URI传递到客户机500后，焦点工厂502不必保存任何状态或做任何工作。

MCU工厂506是提供MCU 508的访问信息的逻辑实体。MCU工厂506可以是MCU设备或软件供应商的供应商专用实现。焦点504通过设置知道系统中存在什么MCU工厂和它们支持什么媒体类型。因此，焦点504向MCU工厂506询问关于如何联系MCU 508的信息（由④表示），且MCU工厂506基于其可能运行的任何内部逻辑来返回该信息（由④表示）。

在MCU工厂506被请求向焦点504提供MCU 508（由④表示）时，其找出哪一MCU 508最适合应答该请求并返回该MCU 508的URL（统一资源定位符）。每一MCU都可被发布（例如，在活动目录中），从而允许拓扑中的所有MCU工厂506都能够找到某类可用的MCU。

每一MCU 508还发布其用于在活动目录中控制的HTTP地址。该地址是在MCU工厂506分配MCU资源508时被传递到焦点504的地址。然而，在该URL被传递到焦点504之前，MCU工厂506尝试在MCU 508上提供会议（由⑤表示）。如果MCU的响应是肯定的，则该URL被返回给焦点504。

焦点504随后可以使用HTTP作为传输来与MCU 508通信（由⑥表示）。请求和响应的有效载荷可以是XML文档。客户机500经由信令协议和媒体协议与MCU 508通信（由⑦表示）。对于音频/视频MCU，该信令协议是SIP媒体，且可以通过RTP/RTCP来携带。对于会晤MCU，信令和媒体两者都可以使用PSOM协议通过HTTP作为传输来携带。

图6示出用于实现会议系统600的组件体系结构的示例性详细示图。系统600包括前端计算机602、存储系统604和分布式媒体组件606。前端计算机602包括用作SIP代理610的服务器进程608。除用作SIP代理和路由器之外，服务器进程608还提供由出席（和注册器）服务器（或模块）614所使用的内部API（称为扩展模块API）612、归档代理模块616和SIPAPI模块618。如图所示，所有这些扩展模块612都可以在同一进程中运行。在SIP代理进程610中不需要运行第三方软件。

出席/注册器模块614提供注册器和出席功能。出席和注册器模块614管理SQL服务器数据库（或MSDE）中的所有注册信息和出席信息。

SIP代理和相关联的扩展模块的组合被统称为服务器前端。如图所示，前端的功能被增强以经由会议模块618（也被称为会议管理器）包括会议特征。会议管理器618是提供信令和会议管理功能的服务器组件。会议管理器618的主要元件是焦点和焦点工厂。

如上所述，焦点是表示会议的SIP端点。其负责管理会议的状态，实施安全，管理各个角色和特权，并向客户机（未示出）提供会议状态更新。焦点还代表所有客户机与作为会议的一部分的每一媒体类型的MCU交互。

会议数据库620包含关于在服务器602上提供的会议的每一个的信息。这包括关于会议ID、与该会议相关联的口令和/或PIN、开始时间和结束时间（如果有的话）、角色和特权等的信息。数据库620还包括关于运行会议的信息以供从焦点失效中恢复。出席/注册器信息和会议信息可以是同一物理数据库（例如，会议数据库）的不同表。

每一MCU负责管理一个或多个媒体类型。在一实现中，所有会议控制命令都被客户机发送到焦点，焦点随后在验证发送该请求的客户机具有执行该操作的特权后，又将这些命令中继到适当的MCU。媒体随后直接在客户机和MCU之间交换。

MCU包括两个逻辑片段：媒体控制器（MC）和媒体处理器（MP）。媒体控制器负责管理焦点和MCU之间的控制命令。媒体处理器负责媒体管理，比如，混合、中继、代码转换。在MCU是数据协作MCU的情况下，媒体处理器是负责管理整个数据协作体验的复杂的软件组件。每一MCU可以将其内容和状态信息存储在相关联的存储单元中，以供在故障和/或失效发生时取回。

在MCU是音频/视频MCU的情况下，媒体处理器具有关于混合音频和视频流、缝合视频流、为处于慢链路上的客户机降频转换（down-convert）媒体等等的极为专业的知识。在所有的会议组件中，媒体处理器可以是最为CPU密集和网络密集的组件。因此，MCU可在与还提供缩放的会议管理器不同的物理计算机上操作。在一实现中，媒体控制器和媒体处理器被共同配置在同一机器上以简化部署。在替换实现中，媒体控制器和媒体处理器位于不同的机器604上。

前端计算机602还可以运行包括web服务和web调度应用程序624以及MCU工厂626的web服务器622。如前所述，MCU工厂626负责使用用于创建会议的本地策略来在MCU上提供特定媒体类型的会议。MCU工厂626在向会议分配MCU之前还可以考虑MCU上的当前负载。负载平衡数据可以存储在负载平衡数据库628中。在该特定实现中，每一媒体类型有一个MCU工厂。然而，在替换实现中，一个MCU工厂适当地稳健，以处理多个不同的媒体类型。

web协作特征可由数据协作MCU来提供。数据协作MCU是在“PSOM”技术上设计的。数据协作MCU支持诸如例如呈现软件文档、字处理和电子表格文档、聊天、投票、白板、和应用程序共享等特征。

音频/视频MCU提供建立在工业标准RTP（实时传输协议）和RTCP（RTP控制协议）上的多方音频和视频混合和中继能力。可以设计并提供其它MCU，比如，即时消息传送（IM）MCU和ACP MCU。

web服务器624提供用于调度在线会议的调度应用程序（例如，ASP.NET）。该应用程序使用用于提供会议和用于管理会议策略的web服务API。web调度程序日程安排所使用的数据库可以是焦点/会议数据库620。MCU的内容和状态可以存储在本地数据存储630上。

还可以提供针对丰富存储和视图的服务，以供使用像议程、动作项目、后续议题、与共享工作空间相关联的文档等会晤元数据来管理正在进行的会晤。

认证可以构成会议体系结构的一个集成部分。在一实现中，用户的登录证书可被用于自动地认证该用户（例如，单个登录）。也可向web风格的表单提供表单认证（例如，用户名和口令），其中用户显式地输入其用户名和口令。授权可以基于在初始认证握手之后客户机安全地发送到服务器的白底（opaque）来实施。还可以施加从客户机到服务器的传输信道的强加密（例如，128位加密）。

web会议可以涉及与可能在服务或企业中没有帐号的用户举行在线会晤。这些一次性会晤相当普遍。认证一次性会议参与者可以通过向每一会话分配唯一口令来支持，该口令通过像电子邮件等带外手段传递给可能的参与者。

存在在会议应用程序中授权是必需的若干情形。会议占据服务器/服务上的资源。因此，可以在允许用户创建会议之前施加强迫授权。在另一示例中，在给定的会议中，所有用户都不拥有所有特权。例如，用户的某一子集被允许在该会话中出席并发言，而用户的不同子集只被允许旁听。在另一示例中，并非会议中的所有用户都被允许邀请其它用户加入。存在静音/解除静音（unmute）会议、静音/解除静音特定用户、或将取消用户与会资格等会议控制动作。可以使这些动作的每一个都首先请求一特权或许可。

具有这些特权的用户组对于会议的每一个可以是不同的。每一会议可能具有不同的成员，且即使用户被授权参与多个会议，该用户在这些会议的每一个中也可能具有不同的特权。为此，这样做是更简单的：定义“角色”组，将一组“特权”与这些角色进行关联，并随后使会议创建者向用户分配这些角色的每一个。例如，可以有“组织者”角色、“主持人”角色和“听众”角色。创建会议的用户将不必指定这些角色的每一个拥有什么特权。每一角色的特权可由会议服务器管理员预先配置。角色名称可被选择成暗示（或直观表达）其可能具有的特权种类。

图7示出示例性服务器体系结构和用于会议和分布式MCU的协议的示图。可以在客户机700和服务器702之间使用多个协议，每一个都针对不同的用途。客户机700被示为具有可以访问底层会议控制和管理组件706和会议媒体组件708的用户接口704。管理组件706可以访问提供会话邀请名单和/或第三方会议名单的名单组件710。会议媒体组件708便于访问数据协作和应用程序共享组件712和音频/视频组件714。

服务器702包括焦点组件716、数据协作和应用程序共享MCU组件718、和音频/视频（AV）MCU组件720。客户机700和服务器702包括用于使用各种协议的协议接口组件（例如，SIP、PSOM、RTP/RTCP）。客户机/服务器SIP组件利用信令和控制协议来建立会话和管理会议。在该特定实现中，SIP（例如，如在RFC 3261中所指定的）被用于建立和终止呼叫。另外，同一会议会话可用于使用SIP-CX扩展来进行会议策略控制和第三方控制。在一实现中，SIP-CX命令通过SIP-INFO来隧道传输。在另一实现中，可以使用C3P控制协议命令。在又一实现中，可以利用来自XCON―关于集中式会议的IETF工作组―的用于会议策略控制的标准化传输和协议。SIP可以使用TCP（传输控制协议）或TLS（传输层安全）作为底层传输协议。

独立的订阅-通知对话可用于订阅会议包和在状态改变时获得通知。会议的名单可以基于该订阅-通知对话来驱动。PSOM可以是用于数据协作的媒体协议且可以使用TCP或HTTP作为低层传输。

对于会议中的每一媒体，将使用媒体传输。RTP和RTCP可被用来提供音频/视频功能。在客户机700和服务器702之间的UDP连接可用的情况下，RTP/RTCP可运行在UDP（用户数据报协议）上。如果没有UDP连接，RTP/RTCP可以通过TCP或HTTP来隧道传输。对于其它媒体类型可以使用其它媒体协议。例如，聊天可以在MSRP（消息会话中继协议）上获得支持，而应用程序共享可以在RDP（远程桌面协议）上获得支持。这些的每一个可以作为单独的媒体类型来运行。在另一实现中，这些协议两者都可在PSOM的顶部实现。

图8-18示出用于创建会议，拨入会议，通过拨入和拨出用AV MCU加入媒体会话，执行对参与者的自组织邀请，以及经由数据MCU加入协作会话的各呼叫流程图。

客户机应用程序与焦点工厂通信来开始新的会议。创建会议意味着创建和配置焦点实例。焦点工厂的工作是向客户机返回焦点的URI。客户机和焦点工厂之间的这一通信不必是持久的。其只需要持续到焦点URI被返回到客户机为止。焦点/会议URI被构建为包括唯一会议标识符、唯一服务器标识符、和在用户信息部分主存会议的域，例如，organizerdomain.com；ms-app=conf；ms-conf-id=11。

客户机可以用三种方式创建会议：经由web服务、SIP邀请机制和SIP服务机制。图8示出用于经由web接口/服务发起会议创建的示例性呼叫流程图。客户机连接到已知焦点工厂web URI并使用所暴露的web接口来创建焦点。在成功创建焦点后，网页将客户机指向必要的信息，以使会议客户机拨入到该会议。

图9示出用于经由邀请机制发起会议创建的示例性呼叫流程图。客户机将其需要的关于会议、媒体类型、特权、参与者等的所有信息作为INVITE（邀请）请求的一部分来传递给焦点工厂。焦点工厂创建焦点实例，并使用所生成的焦点URI将客户机重定向到焦点。

更具体地，客户机向焦点工厂发送带有要创建会议的信息的INVITE请求。焦点工厂向客户机发送临时1xx响应，以便在焦点工厂实例化焦点时客户机事务不超时。如果结果是创建焦点所花费的时间小于SIP事务超时，则可以忽略发送该响应。焦点工厂随后从INVITE中解析出所有所需信息，并创建焦点实例。因为焦点工厂和焦点可以共同配置，该创建焦点的调用可以仅仅是本地函数调用。焦点工厂随后发送具有联系报头的302响应，从而重定向客户机以与焦点开始新的邀请会话。客户机将ACK发送回焦点工厂。

图10示出用于经由SIP服务机制发起会议创建的示例性呼叫流程图。客户机将其需要的关于会议、媒体类型、特权、参与者等的所有信息作为服务请求的一部分来传递给焦点工厂。焦点工厂创建焦点实例，并在200OK响应中将连接信息发送回客户机。

更具体地，客户机向焦点工厂发送带有要创建会议的信息的SERVICE请求。焦点工厂从SERVICE中解析出所有所需信息，并创建焦点实例。因为焦点工厂和焦点可以共同配置，该创建焦点的调用可以只是本地函数调用。焦点工厂发送具有会议信息的200OK响应。

图11示出用于客户机拨入会议的示例性呼叫流程图。客户机与焦点建立用于拨入会议的INVITE对话和SUBSCRIBE（订阅）对话。客户机使用INVITE对话来加入会议，并还将其用于从客户机到焦点的命令通信量的第三方控制。来自客户机的控制命令在INFO（信息）消息内部携带。INFO消息的本体包含C3P控制请求且由焦点处理。

客户机使用SUBSCRIBE/NOTIFY（订阅/通知）对话来监视会议状态。焦点接受订阅并将任何会议状态改变通知订阅者。状态包括焦点本身所维护的状态、会议策略和媒体信息。例如，如果客户机在INVITE对话中使用INFO消息所发送的命令是改变会议状态的命令，则焦点还通过发送经更改的会议状态的NOTIFY来通知客户机。

更具体地，客户机向焦点URI发送INVITE请求来加入会议。该INVITE对话有两个目的：其暗示客户机加入会议以及其被用于使用该对话中的INFO请求进行会议的第三方控制。INVITE本体中的C3P addUser请求可被用来指定特定的客户机属性（例如，显示名称、角色、隐藏的参与者）。客户机发送对会议事件包的SUBSCRIBE来监视会议状态通知。初始会议状态文档可以承载在属于表达支持该扩展的客户机的SUBSCRIBE的200OK中。

图12示出用于客户机通过addUser拨入经由数据协作MCU加入的示例性呼叫流程图。对于会议中的每一MCU，焦点分配可路由到焦点本身的虚拟SIP URI。从焦点到客户机的初始通知包含会议中的所有MCU的URI。客户机可以用三种方式来用MCU建立媒体会话：对MCU URI的addUser拨入、使用MCU URI的addUser拨出和对MCU URI的直接媒体INVITE。

对于addUser拨入，客户机发出addUser拨入C3P命令，且焦点将该命令转发给MCU。MCU授权该命令并返回适当的连接信息。客户机随后用该MCU建立引导媒体会话。这可以是对非基于SIP的MCU的拨入的主模式。

更具体地，客户机用其在通知文档中接收到的MCU URI发送INFOaddUser拨入命令。焦点检查MCU是否已分配到该会议的这一特定模式（媒体）。如果MCU未被分配，则焦点向MCU工厂发送HTTP请求，请求其向该会议分配一MCU。假定MCU已被分配给该会议，则焦点随后向所分配的MCU发送HTTP请求，请求其期待新参与者（addUser）。如果焦点是第一次与该MCU通信，则可能必须发送其它程序引导请求以在该MCU上初始化会议。该MCU用预期的参与者（addUser）呼叫的成功消息来响应。该响应还将具有其想要参与者与其对话的MCU的实际URL。在数据协作MCU的情况下，URL可以是POSM URL。也可以返回授权信息（如果有的话）。

焦点向客户机发送PSOM连接信息。客户机随后直接用MCU建立PSOM信道。一旦客户机成功地加入MCU，其就向焦点发送参与者已加入事件。焦点随后向会议的所有监视者发送参与者已加入MCU状态改变通知（经由SIPPING BENOTIFY（或Best Effort NOTIFY（尽力通知）））。

图13示出用于客户机通过addUser拨出经由音频/视频MCU加入的示例性呼叫流程图。客户机发出addUser拨出C3P命令且焦点将该命令转发到MCU。MCU授权该命令并拨出到addUser命令中提到的客户机。客户机随后用该MCU建立直接媒体会话。这在客户机连接到基于SIP的MCU（例如，A/V MCU和IM MCU）中使用。这一机制还可以被用于客户机经由MCU拨出到另一客户机。

更具体地，客户机用其在通知文档中接收到的MCU URI发送INFOaddUser拨出命令。焦点随后检查MCU是否已分配到该会议的这一特定模式。如果MCU未被分配，则焦点向MCU工厂发送HTTP请求，请求其向该会议分配MCU。假定MCU已被分配给该会议，则焦点随后向所分配的MCU发送HTTP请求，请求拨出到用户。该MCU使用通常是焦点服务器本身的外出SIP代理向客户机拨出INVITE。客户机直接用该MCU建立RTP媒体信道。一旦客户机成功地加入MCU，其向焦点发送参与者已加入事件。焦点随后向会议的所有监视者发送参与者已加入MCU状态改变通知。

图14示出用于客户机经由对MCU的直接邀请来加入的示例性呼叫流程图。对MCU的直接媒体INVITE对使用SIP建立会话的MCU（例如，A/V MCU、IM MCU）起作用。客户机可以向MCU URI直接发送媒体会话邀请而无须任何预先的addUser呼叫。INVITE被路由到焦点且焦点代表客户机向MCU发起addUser。MCU授权并用连接信息响应。焦点检查该连接信息是否是可路由的SIP地址并将该INVITE直接转发到MCU。这主要是支持非C3P纯SIP客户机拨入会议。C3P客户机可以从会议通知取得MCU URI并向可以尝试直接拨入MCU的纯SIP客户机发送REFER（引用）消息。

更具体地，客户机向其在通知文档中所接收到的MCU URI发送INVITE。该INVITE被路由到焦点。客户机可以添加关于媒体协商的会话描述。因为焦点知道该INVITE被寻址到特定MCU，所以其在该INVITE的本体中安全地省略任何会话描述。焦点随后向所分配的MCU发送HTTP请求，请求其预期新的参与者（addUser拨入）。如果这是焦点第一次与该MCU通信，则其可以发送其它程序引导请求来在该MCU上初始化会议。该MCU用关于预期的参与者呼叫的成功来响应。该响应还将具有其想要参与者与其通信的MCU的实际URL。

在A/V MCU的情况下，URL指示参与者可以经由SIP与MCU通信。在A/V MCU的情况下，焦点将INVITE转发到MCU。客户机发送回ACK来完成INVITE对话，还被用于与MCU的媒体协商。注意，虽然客户机直接与MCU建立INVITE对话，但SIP请求自身通过焦点。一旦客户机成功地加入MCU，其就向焦点发送参与者已加入事件。焦点向会议的所有监视者发送参与者已加入MCU状态改变通知。获得了客户机和MCU之间的直接媒体协商。在音频/视频的情况下，这可以是RTP/RTCP流。

图15示出对另一客户机参与者的产生拨入的自组织邀请的示例性呼叫流程图。客户机随后向参与者发送应用程序（app）INVITE。具有嵌有授权PIN的会议URL的应用程序邀请将作为消息提示出现在用户的客户机中。一旦参与者接受/点击该消息提示，其将启动将参与者拨入会议的会议客户机。

更具体地，客户机向参与者发送包括参与者拨入会议的所有必需信息的应用程序邀请，包括授权消息（如果有的话）。应用程序邀请将作为提示显示在控制台中。一旦参与者接受该提示，会议客户机将发起使客户机拨入会议。在客户机成功地拨入到会议后，焦点向会议的所有监视者发送名单更新通知。

图16示出对另一客户机的自组织拨出INVITE的示例性呼叫流程图。在客户机1和焦点之间发起客户机加入序列，随后从客户机1向焦点发送INFO addUser拨出消息。从焦点返回200ACCEPT（接受）消息。焦点向MCU发送addUser拨出消息，且MCU用200OK响应。MCU向第二客户机2发送经由焦点路由的INVITE消息。客户机2用200OK消息响应，随后从MCU接收ACK。随后在MCU和客户机2之间发起媒体流（例如，使用RTP）。MCU向焦点发送参与者已加入事件。焦点随后向客户机1发送更新名单消息，指示客户机2已加入会议会话。

上述应用程序邀请机制对理解应用程序邀请和C3P协议机制的新客户机起作用。然而，可以邀请不理解C3P的传统客户机。该机制还可以被用来将纯SIP客户机拉（pull）入会议。客户机可以向初始INVITE对话发送BYE（再见）来离开会议。为了检测到崩溃的客户机，可以使用会话保持活跃消息。

可以进行从MCU到焦点和从焦点到客户机的会议状态通知。状态通知数据模型包括以下元素：会议描述（例如，名称、主题、组织者描述）；包括关于能力、当前状态、设置和策略等信息的会议视图（例如，每一实体焦点的会议级别信息，如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](由媒体id键控。标记是

对会议媒体元素的引用，

见下。）

Sidebars-by-val[0..1]

Entry[0..N](递归地定义分会议对象)。

以下代码表示具有两个MCU（例如，A/V、数据）且没有用户登录的初始会议状态的一个示例。

以下表示供用户尝试加入和程序引导A/V MCU的代码的一个示例。

以下表示关于加入焦点的用户Bob的代码的一个示例。

以下表示关于加入AV MCU的用户Bob的代码的一个示例。

可以用若干方式完成对焦点工厂URI的发现：通过分组策略使用，通过DNS（域名服务器）、服务器的固定URI和用户概况数据。

一种管理员通常用来向客户机分发设置的方法是使用分组策略对象（GPO）。某些应用程序设置和特征可以通过GPO设置来打开或关闭。例如，管理员可以通过GPO选择移除某些菜单选项或添加某些其它选项。通过使用GPO，域管理员可以将特定用户组指向特定焦点工厂。这排除了手动配置要求。

另一选项是使用DNS记录来将客户机指向焦点工厂URI。DNS SRV是标准DNS服务器的扩展，且被用来获取服务器的一个或多个IP地址，每一服务器都具有其自身的优先权。以下是示例SRV记录：

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

SRV记录命名惯例要求记录顺序地包含以下各项：下划线，其后是服务名，点，下划线，其后是协议，点，随后是域名。

另一选项是使用焦点工厂的固定URI，如：

sip:FocusFactorymicrosoft.com

该方法一起排除了猜测和发现要求。运行在池的前端机器上的应用程序将其解释为特殊URI并那样处理。这意味着同一URI由运行在多个池中的各应用程序所表示。

另一方法是通过用户概况数据。用户登入以获得漫游联系人和安全信息。客户机可以订阅各种类型的数据，包括漫游联系人、漫游ACL（访问控制列表）、对用户出席数据的未决订阅请求等。该信息被存储在出席存储中。不管客户机在内联网的内部还是外部，数据都被携带到客户机。在客户机注册其出席信息时，其订阅这些数据类型且服务器使用SIP协议（使用NOTIFY消息）来发送它们。

通过引入另一数据类型，即FocusFactoryURI（焦点工厂URI），客户机然后还可以订阅该数据并将其作为原始握手的一部分来接收。所添加的优点是，在该信息改变时，客户机是使用SIP语义来通知的，因为客户机订阅了FocusFactoryURI数据类型。

关于可以如何存储该数据有两个选项。首先，每一用户可以具有单独的FocusFactoryURI。在该方式下，出席存储可被扩展并存储被允许参与会议的每一用户的URI。在第二种方式下，焦点工厂URI是池级设置，所有用户都寄宿在该池共享上。该方法的一个优点是其不要求针对每一用户管理工厂URI，而是针对整个池存储单个URI。因为池设置是在该池中的所有前端服务器之间共享的，所以运行在每一前端上的用户服务模块可以访问该设置。该设置对系统中的其它池是可见的。

焦点工厂和焦点实例可被主存在不寄宿用户的池上。这产生了对来自客户机去往主存焦点工厂和焦点实例的池的请求的路由需求。即使第一需求不在于此，请求也被从连接到不同池的客户机路由到主存焦点实例的池。

用户服务可以在数据库中查询客户机所询问的各种类型的数据，将其格式化为XML格式，并用NOTIFY消息来响应。对于该特定数据类型，代替去往数据库检索之，接收该请求的前端机器可以查阅池级设置并准备XML文档来用NOTIFY发送。如果该设置被更新，则将其改变在时间窗口（例如，5分钟）内通知用户服务，从而允许其更新它的关于该设置的本地值。

对于寄宿来自多个域的用户的池，该设置对所寄宿的域的每一个来说都是可配置的，以允许所寄宿的不同的域的不同工厂URI。其示例是主存解决方案，其中用户分散在多个可能的域上。提供了每一池存储多个域名和向其分配焦点工厂URI的能力。该设置对所有池是可见的。

客户机应用程序与焦点工厂通信来开始新的会议。如上所述，由于客户机应用程序在用户登入时获得焦点工厂URI，所以其具有在任何时刻与焦点工厂通信以开始新的自组织会议的手段。在SIP客户机想要与另一客户机通信时，客户机之间的SIP对话以一方发送到另一方的INVITE开始。SDP（会话描述协议）包在该INVITE和该同一INVITE的200OK响应中携带，作为用于媒体协商的有效载荷。

在所公开的框架中，创建会议意味着创建和配置焦点实例。焦点工厂的工作是向客户机返回焦点的URI。这意味着客户机和焦点工厂之间的这一对话不必是持久的。其只需要持续到焦点URI被返回到客户机为止。

焦点工厂在其向客户机返回其URI之前创建并配置焦点。该配置设置该会议要使用的媒体类型，预期参与者数量，已知的参与者的角色和特权，角色定义等。

焦点工厂具有允许提前调度会议的web服务接口。在该场景中，会议客户机直接与焦点对话，从不与焦点工厂建立对话。然而，对于自组织会议，会议客户机与焦点工厂对话来使之提供焦点URI。

图17示出使用重定向的示例性呼叫流程图。最初，客户机向焦点工厂URI发送INVITE，其中：

·目的地＝焦点工厂URI

·源＝用户URI

·内容类型＝多方MIME

·内容＝包含初始参与者列表、角色映射和模板标识令牌的XML内容

运行在池上的焦点工厂应用程序接收该消息，并返回100—正在进行中或180—Ringing（振铃）临时响应。这允许客户机等待同时允许焦点工厂执行任何数据准备和查找。焦点工厂创建焦点并在302—重定向响应—的联系人报头中返回焦点URI。这允许客户机缓存联系人报头值作为会议URI。客户机向其接收到的焦点URI发送同一INVITE。唯一的不同之处是，这次目的地：报头具有作为会议ID（conf-id）的GRUID参数。

图18示出将创建会议和客户机加入会议分开处理的示例性呼叫流程图。这更好地反映了发生的操作的各个阶段。因此，创建会议包括将INVITE从客户机传递到焦点工厂，可任选地接收回正在进行中响应180，从焦点工厂向焦点发送CreatFocus（创建焦点）以创建焦点实例，向焦点工厂返回焦点数据，向客户机发送联系人焦点URI，并确认接收。与加入会议相关联的消息包括向焦点发送具有客户机的焦点URI的INVITE，将200OK接收回客户机，并确认接收。

在从客户机接收到INVITE消息时，焦点工厂创建焦点并向客户机返回焦点信息。正如焦点工厂一样，焦点是由应用程序所表示的SIP端点。焦点工厂将其接收到的INVITE请求重定向到焦点，从而允许焦点成为与客户机进行媒体协商的端点。

如上所述，焦点是会议的“经注册”处理程序。焦点URI表示会议，且还被称为会议URI。一种确定性方法是对URI的用户部分使用固定模式，并用会议ID信息来对其注释。这允许以更容易的方式基于该URI来编写路由逻辑，并允许焦点URI被映射到企业内的单个应用程序，这便于对系统的管理。这一使用由对SIP的“GRUU/GRID扩展”来概括，其允许向公知焦点URI附加GRUU参数。示例是：

Sip:conf-mgrconfserver.company.com;grid=Schumacher1980

Sip:FocusFactoryMSconferencing.microsoft.com;grid=conf34242834

焦点工厂行为是焦点驻留在焦点工厂在其上运行的同一池上。这可以是用于缩放完全与SIP注册器服务器分开的会议焦点实例的可配置设置。

焦点实例同时在池中的所有前端机器上运行。这允许客户机连接到池中的任何前端，从而允许负载分布和更好的缩放性。要在会议的焦点实例之间共享的焦点状态保持在数据库中。该数据包含名单、角色和特权、媒体类型和MCU身份等。每一焦点实例都处理连接到特定前端的客户机的连接状态，该焦点实例在特定前端上运行。因为每一焦点实例都是SIP端点，所以这些连接都是SIP对话。

在焦点URI传递给客户机时，该URI的一部分是会议ID，该ID是数据库引擎所生成的引用数据库中的会议记录的数字。该数据库记录包含指示该记录应该在数据库中保持多久以及关于该会议的其它信息的数据。

在将焦点URI传递到客户机后，焦点工厂不必保存任何状态或做任何工作。在客户机通过其所连接的寄宿服务器向焦点URI发送INVITE时，该INVITE被路由到将主存该会议的池。在接收到该INVITE后，池中的前端机器之一创建会议并向客户机作出响应。

如上所述，焦点实例在池的所有前端机器上运行。要考虑的问题包括路由、性能、稳定性、和可靠性。如前所述，与会议相关联的状态存储在可由池的所有前端机器访问的数据库中。这允许与该会议相关的状态在运行在该池中的不同前端机器上的多个焦点应用程序实例之间共享。结果，每一客户机都连接到其池和/或寄宿服务器且它们试图到达的焦点运行在该箱上，准备应答它们可能发送的所有会议相关请求。

图19示出服务器池系统1900，该系统在池中的不同前端机器上运行的多个焦点应用程序实例之间共享状态。系统1900通过将负载分布到遍及所有前端机器（或前端）、排除路由需求、以及使用高可用性特征，来解决路由、性能、稳定性和可靠性问题。连接管理负载随机地在该池中的所有前端机器之间分布。附加前端机器可以容易地添加和移除，因为它们除与池相关联外没有身份。对于稳定性，在前端失效的情况下，连接到该前端的所有用户都可以尝试并重新连接到该会议。所有这些用户将被再次平衡负载并连接到同一池中的其它前端。路由问题被排除，因为都不需要。会议的共享状态被存储在数据库中，且所有前端都可以访问它。没有一个机器需要作为信息中间人。

图20示出两个分开的与焦点实例的客户机-焦点对话的示例性呼叫流程图。INVITE对话是允许客户机加入会议的对话，且其被用于从客户机到焦点的进一步命令话务。来自客户机的命令在INFO消息内携带。INFO消息的本体包含SOAP类XML本体且由焦点处理。注意，图20中的该单个INFO消息表示该会议的持续时间中的所有INFO消息。基于分配给客户机的角色，客户机可以发出用于会议控制、会议策略控制、媒体控制或媒体策略控制的命令。

一旦客户机加入了会议，则应当向其通知该会议中正在发生的事件，如加入和去除的参与者，添加或移除的媒体等。这些对会议状态的改变以及对会议策略和媒体的改变通过在该对话中发送到客户机的NOTIFY消息来携带。如果由客户机在INVITE对话中使用INFO消息所发送的命令是改变会议状态的命令，则焦点通过发送包含会议状态的经更改部分的NOTIFY来通知客户机。注意，图20中的该单个NOTIFY消息表示该会议的持续时间中的所有NOTIFY消息。

用于在会议中开始媒体类型的选项是创建中心并在创建中心时向所有MCU通知该会议。这允许稍后的媒体启用变得快速。另外，由于在前启用媒体，所以MCU将知道可以提前联系他们的名单的那一部分，从而允许无延迟地执行针对媒体的用户加入操作。在该模型中，一旦创建了焦点，其就向MCU发送命令，分配会议状态和传递关于预期参与者的会议名单。该焦点随后用所使用媒体类型的MCU信息来更新会议状态。这样，参与者无论何时进入并加入媒体，该焦点都不必去往MCU来获取连接信息。对于加入该会议的第一和最后参与者来说体验将是一个并且是相同的。

如上所述，MCU工厂是提供MCU的访问信息的逻辑实体。MCU工厂可以是MCU设备或软件供应商的供应商专用实现。焦点通过设置知道系统中存在什么MCU工厂和它们支持什么媒体类型。焦点询问MCU工厂关于如何联系MCU的信息，而MCU工厂基于其可能正在运行的任何内部逻辑来返回该信息。

例如，考虑其中存在用于A/V活动的第一和第三方MCU的部署。这意味着MCU工厂列表将包括两个实体，一个对应于该媒体类型的这些供应商的每一个。设置的示例表示包括以下：

媒体类型	MCU工厂URL
		A/V	http://MCUFactory.1stParty
A/V	http://MCUFactory.3rdParty

在创建具有A/V活动的会议时，表示该会议的焦点联系MCU工厂以请求将在该会议中使用的MCU的类型。在诸如其中存在多个MCU工厂的这样一个场景中，焦点挑选这些MCU工厂的一个。使用模板来解决这点。

C3P是用来修改会议状态的会议控制/操纵控制协议。在所公开的体系结构中，C3P命令从客户机流向焦点并从焦点流向MCU，反方向则应用于会议通知。C3P具有与SIP相似的请求/待决响应/最终响应语义。

图21示出在其中客户机发出用于修改会议状态的C3P命令的示例性呼叫流程图。客户机向焦点发起加入序列。从客户机向焦点发送INFO C3P命令。焦点用202 ACCEPT响应。焦点向数据协作MCU发送C3P请求，随后向音频/视频MCU发送同一类型的请求。焦点还向客户机发送INFOC3P响应，随后发送200OK消息。焦点随后向客户机发送状态改变通知（经由BENOTIFY）。MCU（数据协作和AV）向焦点发送C3P响应。数据协作MCU和AV MCU各自通过C3P命令向焦点发送状态改变通知。焦点随后向客户机发送对应的状态改变通知（经由BENOTIFY）。

图22示出可以根据分布式MCU会议体系结构使用的C3P命令。这些命令与会议级（Conference Level）、用户级（User Level）、私下会议级（SidebarLevel）、端点级（Endpoint Level）、端点媒体级（Endpoint Media Level）、记录（Recording）、负载平衡（HA/Loadbalancing）、和调度专用（Schedulingspecific）相关。在会议级，可以添加、删除、修改会议，修改锁定，修改媒体过滤器，播放记录名，以及获得会议。在用户级，可以添加、删除和修用户，修改用户角色以及设置用户访问。在端点级，可以修改端点角色。在端点媒体级，可以添加、删除和修改媒体端点。在私下会议级，可以添加、删除和修改私下会议。用户还可以移动到私下会议。对于记录，可以开始、停止、暂停和继续记录。对于调度，可以获得（经由get）可用的MCU类型、加密密钥和会议。对于负载平衡，可以获得MCU连同ping（查验）值。

所公开的会议体系结构可以安装在若干配置中，从用于小型和中型公司的简单的单个服务器安装，到具有多服务器安装和具有不同缩放特征的针对会议功能的每一个的不同数量服务器的主存百万服务的部门级安装。配置需求又驱动服务器体系结构和如何分离各功能片段。

在单服务器配置中，提供出席、即时消息传送、多方web会议、音频-视频会议和记录所需的所有服务器组件可被安装在单个机器上。在该模式中，用于例如注册和出席的“寄宿服务器”、会议过滤器、会议焦点、A/VMCU和数据MCU组件将全都在同一服务器上运行。该配置支持小数量的用户和并发会议。例如，单服务器安装可以支持最多达500并发用户出席，假定在任何给定时刻不超过100用户在进行IM且有不超过50并发多媒体会议参与者（数据/音频-视频）。注册以及会议数据库还可以在单个服务器上运行。TCP端口和URL命名空间将作为共享的资源。

图23示出在其中各前端服务器2300具有等效功能的多服务器池。在该模式中，在IP负载平衡器2302后面实现了多个服务器。多个服务器提供高可用性解决方案，其中如果服务器前端之一失效了，则客户机将检测到该前端失效并自动地重新连接到其它可用的前端服务器之一。

这些前端2300的每一个不仅包括注册、出席和路由功能，而且包括会议功能。每一前端都运行焦点工厂、MCU工厂、零个或多个焦点主存进程和媒体MCU进程的实例。失效检测和接管逻辑可被扩展来包括会议会话。如果会议中途失效，则客户机能够连接回焦点，该焦点是一旦在服务器池2300上检测到失效时在另一前端服务器上重新实例化的。该新焦点重新设置像其在该焦点的先前具体化中所拥有的一样多的状态，并允许客户机从它们在会议中停止的地方继续。

所有服务器2300在功能上都是等效的。诸如焦点工厂、焦点、MCU工厂、MCU、web调度接口等软件组件安装在所有前端服务器上。尽管焦点和MCU具有不同的缩放特征，但该配置在提供高可用性和失效恢复的同时提供设置和管理的简化。该体系结构还允许将MCU分散在分开的箱中。

图24示出用于故障恢复和高可用性特征的多服务器池2400配置。另外，其提供将具有不同缩放特征的功能分散到不同服务器上的能力。此外，MCU 2402可被链结在一起以供缩放会议并允许在公司之间或公司和所主存的服务之间联盟。MCU中继、混合和处理媒体。媒体传送和处理与穿过焦点的信令和会议控制数据相比更为CPU和网络密集。因此，MCU可以独立于出席、信令和会议控制元件来缩放。

图25示出分布式媒体组件体系结构的各实体之间的各种类型的数据流的拓扑图。诸如与MCU（例如，IM MCU、A/V MCU）以及到负载平衡器的客户机-服务器（C/S）通信可以经由SIP进行。负载平衡器可以也使用SIP通过接口连接到前端服务器。对于音频/视频流，客户机可以使用RTP/RTCP通过接口连接。对于与数据协作MCU交互，客户机可以使用PSOM。MCU的每一个都可以使用HTTP通过接口连接到前端服务器，MCU工厂也使用HTTP通过接口连接到前端服务器。会议web服务器可由浏览器应用程序访问。该Web服务器可以使用ODB（对象数据库）/ADO（ActiveX数据对象）访问焦点后端服务器（例如，SQL服务器）。前端服务器（例如，前端1）也可以使用ODB/ADO来访问该后端服务器。服务器-服务器（S/S）通信（例如，IM MCU到服务器池、A/V MCU到服务器池）可以使用SIP。负载均衡器可以使用服务器-服务器SIP通过接口连接到前端服务器的一个或多个。

图26示出使用可插入和分布式媒体组件的总体会议体系结构2600。体系结构2600还允许保护多个MCU免被用于同一媒体类型，例如，在语音IP MCU和PSTN MCU之间实现级联以将IP和PSTN参与者桥接到同一会议。一旦会议及其会议URI被分配（使用接口A）且客户机接收到访问该会议的焦点许可（使用接口B），则该客户机订阅会议事件状态信息（通过接口C），并经媒体MCU从来自焦点的第一事件中接收到的文档中检索实际会议URI（通过接口C）。客户机使用所检索到的会议MCU URI来拨入（或加入）该会议，并直接用该MCU执行第一方基本SIP呼叫信令操作（通过接口D）。

该SIP信令（通过接口D）将通过SIP路由手段自动地被代理穿过焦点。PSOM信令和数据协议（通过接口L）直接在客户机和数据MCU之间路由。被代理穿过焦点的SIP连接有机会被检查，且关于认证、授权、成员资格等的本地策略被实施。注意，在PSTN MCU和数据MCU的情况下，第一方呼叫信令不被代理穿过焦点。这些MCU的策略可以显式地从焦点上传到MCU。客户机使用用原始会议URI（通过接口B）建立的SIP对话，来使用在此也被称为C3P的CCCP执行任何其它类型的会议控制。

从焦点的观点来看，ACP MCU被作为任何其它IP MCU，例外之处是传输是SIP代替HTTP。该接口在图中被示为B^**和C^**，其中B^**是通过SIP的CCCP隧道，而C^**是通过SIP隧道传输的XML事件的会议包。在一实现中，ACP GW（网关）逻辑模块被实现为允许ACP，其已经支持SIP-CX协议无缝地集成到该基础结构中。

由于第一方信令（例如，在这种情况下是PSTN信令）对焦点而言是不可见的，因此附加安全握手（寻址授权）在焦点和ACP MCU（以及ACPGW）之间实现。

数据MCU不需要实现SIP。因此，尝试拨入到会议的客户机将导致到指向该数据MCU的HTTP URI的重定向。注意，所有的安全问题（包括认证和授权）都可使用PSOM直接在数据客户机和数据MCU之间处理。

对于会议状态和通知，系统中的每一MCU都维护其主存会议的每一个的状态信息。该信息表示MCU的会议的媒体专用视图。MCU通过接口C^*经由HTTP的XML事件的会议包将其会议状态中的变化推（push）到主焦点。主焦点从每一MCU（通过接口C^*）动态地接收个别状态信息，聚集该信息，并依照各客户机的订阅和特权来向各客户机分发完整的会议视图（通过接口C）。每一感兴趣的客户机和可能的参与者可以向主焦点（通过接口C）订阅（SUBSCRIBE）其感兴趣的会议（使用会议URI）。

在发往每一订阅者的第一个会议状态通知中，焦点包括关于该会议的所有信息。如果对会议的混合是由多个媒体MCU来执行的，则路由到每一MCU的媒体会议URI被列为该会议的会议URI（conf-URI）。客户机分析XML会议状态文档并发起向MCU的适当第一方信令（例如，通过接口D的INVITE或通过接口L的数据MCU）。

使用SIP意味着参与者能够加入和离开会议。使用SIP还意味着参与者可以通过向MCU发送重新INVITE（re-INVITE）来改变其自身的媒体流。这类操作被称为“第一方信令”且被示为接口D。这些操作不影响会议中的其他参与者的状态。

还可以获得用于使用SIP通过焦点控制其他会议参与者（被称为“第三方控制”）的受限操作。为执行更丰富的会议控制，用户客户机可以实现CCCP客户机。通过接口B使用CCCP，客户机可以影响其自身的状态、其他参与者的状态、以及可以直接影响各会议参与者的状态的焦点/MCU的状态。使用CCCP的会议控制逻辑上对会议状态执行。使用CCCP请求，客户机表达其想要看到会议状态如何变化。CCCP服务器执行该操作并更新其“主”会议状态来反映这些变化。

看一个示例，“将特定参与者的特定媒体挂起（on-hold）”请求。为使客户机请求该操作，其首先需要用他/她的主动流知道该特定参与者，并随后使用CCCP来显式地指向该参与者和特定流。焦点在其通知中提供十分丰富的状态信息，以便客户机可以发出针对会议系统的显式的控制命令。焦点最终响应包括该操作的状态且可以包括会议状态的受影响部分。注意，独立于所描述的CCCP事务，会议状态改变可以按照订阅会议状态包的用户的特权来报告给他们。

焦点使用MCU工厂创建新会议。焦点包括系统或池中的具有对应URI的可用MCU工厂、所支持的媒体类型、和每一个的控制URI的列表。每一MCU工厂表示其中新会议可分配到的具有所支持媒体类型的MCU逻辑组。为了分配新会议，焦点从表中选择一个兼容的MCU工厂，并向其控制URI（通过接口F）发出“getMcu（获得MCU）”CCCP原语请求。该选择MCU的CCCP请求可以包括描述所需会议描述和能力的会议对象。成功的响应包括CCCP请求所寻址到的MCU控制URI。在失败的情况下，焦点将尝试另一兼容的MCU工厂。注意，按照MCU工厂实现，MCU工厂控制URI和MCU控制URI可以是相同的或不同的URI。所描述的分解允许每一MCU供应商实现其MCU农场的负载平衡（或其它类逻辑）而不影响该体系结构。

主焦点和每一MCU之间的控制接口（接口B^*）是用于从焦点发出请求的，且可以使用CCCP来实现。通过该接口，焦点用作CCCP客户机而MCU用作CCCP服务器。

现在提供这些接口的简要概述。接口A是用于自组织会议创建的SIP接口；接口B用于呼叫控制会议（cc-conferencing）（第一方和受限的第三方）和通过SIP的CCCP；接口B^*用于通过HTTP的CCCP；接口B^**用于通过SIP的CCCP隧道；接口B^***用于通过SIP的SIP-CX；接口C用于通过SIP的会议包的SUBSCRIBE/NOTIFY；接口C^*用于通过HTTP的会议包XML事件；接口C^**用于通过SIP隧道传输的会议包XML事件；接口C^***用于SIP-CX中的会议报XML事件；接口D用于SIP—只限第一方；接口F用于通过HTTP的CCCP，只限会议创建/分配；接口L用于数据协议（数据和第一方信令）；接口M用于媒体（例如，用于语音和视频的RTP/RTCP）；接口P用于焦点工厂和焦点之间的通信。

如在本申请中所使用的，术语“组件”和“系统”旨在表示计算机相关的实体，其可以是硬件、硬件和软件的组合、软件、或者执行中的软件。例如，组件可以是但不限于：在处理器上运行的进程、处理器、硬盘驱动器、（光和/或磁存储介质的）多个存储驱动器、对象、可执行代码、执行的线程、程序、和/或计算机。作为说明，运行在服务器上的应用程序和服务器都可以是组件。一个或多个组件可以驻留在进程和/或执行的线程内，且组件可以位于一台计算机内上/或分布在两台或更多的计算机之间。

现在参考图27，示出了可用于执行根据所公开的体系结构的集中式和分布式会议的计算机的框图。为了提供用于其各方面的附加上下文，图27及以下讨论旨在提供对其中可实现本发明的各方面的合适的计算环境2700的简要概括描述。尽管以上描述是在可在一个或多个计算机上运行的计算机可执行指令的一般上下文中进行，但是本领域的技术人员将认识到，本发明也可结合其它程序模块和/或作为硬件和软件的组合来实现。

一般而言，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、组件、数据结构等等。此外，本领域的技术人员可以理解，本发明的方法可用其它计算机系统配置来实施，包括单处理器或多处理器计算机系统、小型机、大型计算机、以及个人计算机、手持式计算设备、基于微处理器的或可编程消费电子产品等，其每一个都可操作上耦合到一个或多个相关联的设备。

所示的本发明的各方面也可在其中某些任务由通过通信网络链接的远程处理设备来执行的分布式计算环境中实施。在分布式计算环境中，程序模块可以位于本地和远程存储器存储设备中。

计算机通常包括各种计算机可读介质。计算机可读介质可以是可由计算机访问的任何可用介质，且包括易失性和非易失性介质、可移动和不可移动介质。作为示例，而非限制，计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其它数据之类的信息的任意方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括但不限于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）储存在诸如ROM、EPROM、EEPROM等非易失性存储器2710中，其中BIOS包含帮助诸如在启动期间在计算机2702内的元件之间传输信息的基本例程。RAM 2712还可包括诸如静态RAM等用于高速缓存数据的高速RAM。

计算机2702还包括内置硬盘驱动器（HDD）2714（例如，EIDE、SATA），该内置硬盘驱动器2714还可被配置成在合适的机壳（未示出）中外部使用；磁软盘驱动器（FDD）2716（例如，从可移动磁盘2718中读取或向其写入）；以及光盘驱动器2720（例如，从CD-ROM盘2722中读取，或从诸如DVD等其它高容量光学介质中读取或向其写入）。硬盘驱动器2714、磁盘驱动器2716和光盘驱动器2720可分别通过硬盘驱动器接口2724、磁盘驱动器接口2726和光盘驱动器接口2728连接到系统总线2708。用于外置驱动器实现的接口2724包括通用串行总线（USB）和IEEE 1394接口技术中的至少一种或两者。其它外部驱动器连接技术在本发明所考虑的范围之内。

驱动器及其相关联的计算机可读介质提供了对数据、数据结构、计算机可执行指令等的非易失性存储。对于计算机2702，驱动器和介质容纳适当的数字格式的任何数据的存储。尽管以上对计算机可读介质的描述涉及HDD、可移动磁盘以及诸如CD或DVD等可移动光学介质，但是本领域的技术人员应当理解，示例性操作环境中也可使用可由计算机读取的任何其它类型的介质，诸如zip驱动器、磁带盒、闪存卡、盒式磁带等等，并且任何这样的介质可包含用于执行所公开的发明的方法的计算机可执行指令。

多个程序模块可储存在驱动器和RAM 2712中，包括操作系统2730、一个或多个应用程序2732、其它程序模块2734和程序数据2736。所有或部分操作系统、应用程序、模块和/或数据也可被高速缓存在RAM 2712中。应该明白，本发明可以用各种市场上可购得的操作系统或操作系统的组合来实施。

用户可以通过一个或多个有线/无线输入设备，例如键盘2738和诸如鼠标2740等定点设备将命令和信息输入到计算机2702中。其它输入设备（未示出）可包括话筒、IR遥控器、操纵杆、游戏手柄、指示笔、触摸屏等等。这些和其它输入设备通常通过耦合到系统总线2708的输入设备接口2742连接到处理单元2704，但也可通过其它接口连接，如并行端口、IEEE1394串行端口、游戏端口、USB端口、IR接口等等。

监视器2744或其它类型的显示设备也经由接口，诸如视频适配器2746连接至系统总线2708。除了监视器2744之外，计算机通常包括诸如扬声器和打印机等的其它外围输出设备（未示出）。

计算机2702可使用经由有线和/或无线通信至一个或多个远程计算机，诸如远程计算机2748的逻辑连接在网络化环境中操作。远程计算机2748可以是工作站、服务器计算机、路由器、个人计算机、便携式计算机、基于微处理器的娱乐设备、对等设备或其它常见的网络节点，并且通常包括以上相对于计算机2702描述的许多或所有元件，尽管为简明起见仅示出了存储器/存储设备2750。所描绘的逻辑连接包括到局域网（LAN）2752和/或例如广域网（WAN）2754等更大的网络的有线/无线连接。这一LAN和WAN联网环境常见于办公室和公司，并且方便了诸如内联网等企业范围计算机网络，所有这些都可连接到例如因特网等全球通信网络。

当在LAN网络环境中使用时，计算机2702通过有线和/或无线通信网络接口或适配器2756连接到局域网2752。适配器2756可以帮助到LAN2752的有线或无线通信，而LAN 2752又可包括其上设置的用于与无线适配器2756通信的无线接入点。

当在WAN网络环境中使用时，计算机2702可包括调制解调器2758，或连接到WAN 2754上的通信服务器，或具有用于通过WAN 2754，诸如通过因特网建立通信的其它装置。或为内置或为外置以及有线或无线设备的调制解调器2758经由串行端口接口2742连接到系统总线2708。在网络化环境中，相对于计算机2702所描述的程序模块或其部分可以存储在远程存储器/存储设备2750中。应该理解，所示网络连接是示例性的，并且可以使用在计算机之间建立通信链路的其它手段。

计算机2702可用于与操作上设置在无线通信中的任何无线设备或实体通信，这些设备或实体例如有打印机、扫描仪、台式和/或便携式计算机、便携式数据助理、通信卫星、与无线可检测标签相关联的任何一个设备或位置（例如，公用电话亭、报亭、休息室）以及电话。这至少包括Wi-Fi和蓝牙^TM无线技术。由此，通信可以如对于常规网络那样是预定义结构，或者仅仅是至少两个设备之间的自组织通信。

现在参考图28，示出了帮助分布式媒体会议的示例性计算环境2800的示意性框图。系统2800包括一个或多个客户机2802。客户机2802可以是硬件和/或软件（例如，线程、进程、计算设备）。客户机2802可例如使用通过本发明而容纳cookie和/或相关联的上下文信息。

系统2800还包括一个或多个服务器2804。服务器2804也可以是硬件和/或软件（例如，线程、进程、计算设备）。服务器2804可以例如通过使用本体系结构来容纳线程以执行变换。在客户机2802和服务器2804之间的一种可能的通信能够以适合在两个或多个计算机进程之间传输的数据分组的形式进行。数据分组可包括例如cookie和/或相关联的上下文信息。系统2800包括可以用来使客户机2802和服务器2804之间通信更容易的通信框架2806（例如，诸如因特网等全球通信网络）。

通信可经由有线（包括光纤）和/或无线技术来促进。客户机2802操作上被连接到可以用来存储对客户机2802本地的信息（例如，cookie和/或相关联的上下文信息）的一个或多个客户机数据存储2808。同样地，服务器2804可在操作上连接到可以用来存储对服务器2804本地的信息的一个或多个服务器数据存储2810。

上面描述的包括所公开的本发明的各示例。当然，描述每一个可以想到的组件和/或方法的组合是不可能的，但本领域内的普通技术人员应该认识到，许多其它组合和排列都是可能的。因此，本发明旨在涵盖所有这些落入所附权利要求书的精神和范围内的更改、修改和变化。此外，就在说明书或权利要求书中使用术语“包括”而言，这一术语旨在以与术语“包含”在被用作权利要求书中的过渡词时所解释的相似的方式为包含性的。

Claims (19)

1.一种计算机实现的会议系统，包括：

由所述会议系统响应于客户机提交的会议建立请求而提供的会议控制组件，所述会议控制组件被配置成：

从所述客户机接收所述会议建立请求以创建会议会话；

在接收创建所述会议会话的所述请求之后，向所述会议会话分配向所述客户机提供所述会议会话的媒体的分布式媒体组件；

在所述会议控制组件向所述会议会话分配所述分布式媒体组件之后，向所述客户机返回所述分布式媒体组件的统一资源标识符；

接受所述客户机对所述会议会话的订阅；以及

将与所述会议会话相关联的状态的改变通知给已订阅的客户机，其中所述通知作为BENOTIFY消息来提供。

2.如权利要求1所述的系统，其特征在于，所述分布式媒体组件是适应数据、音频信号、视频信号、和即时消息传送信号的至少一个的多点控制单元。

3.如权利要求1所述的会议系统，其特征在于，所述会议控制组件提供维护管控所述会议会话的操作以及允许参与者参加所述会议会话的规则的策略和名单组件。

4.如权利要求1所述的会议系统，其特征在于，所述会议控制组件提供通过基于参与者身份信息限制对所述会议会话的访问来在所述会议会话上施加安全的认证组件。

5.如权利要求1所述的会议系统，其特征在于，所述会议控制组件提供向所述会议会话分配所述分布式媒体组件的分配组件。

6.如权利要求1所述的会议系统，其特征在于，所述会议控制组件提供调度所述会议会话的调度组件。

7.如权利要求1所述的会议系统，其特征在于，还包括前端服务器的会议池，所述前端服务器的每一个都运行所述会议会话的实例,所述前端服务器池包括处理单元，客户机访问所述前端服务器的一个来访问所述会议会话。

8.如权利要求7所述的系统，其特征在于，所述前端服务器的会议池包括在所述前端服务器之间平衡会话负载的负载平衡器。

9.一种管理多方会议的方法，包括：

从会话参与者接收请求以创建会议会话；

响应于所述请求创建来提供会议控制组件，所述会议控制组件被配置成：

响应于所述请求创建并配置所述会议会话；

在接收所述请求之后，评估分布式多点控制单元MCU的可用性以供所述会话参与者进行媒体访问；

在评估所述分布式MCU的可用性之后，向所述会议会话分配可用的MCU以供所述会话参与者访问会话，所述可用的MCU位于所述分布式MCU中；

在将所述可用的MCU分配给所述会议会话之后，向所述会话参与者返回所述可用的MCU的统一资源标识符；

接受客户机对所述会议会话的订阅；

将与所述会议会话相关联的状态的改变通知给已订阅的客户机，其中所述通知作为BENOTIFY消息来提供；以及

认证参与者对所述会议会话的访问。

10.如权利要求9所述的方法，其特征在于，还包括在数据库中维护所述会议会话的状态信息。

11.如权利要求9所述的方法，其特征在于，还包括：

接收所述分布式MCU中的分配给所述会议会话的每一MCU的个别状态信息；

通过聚集分配给所述会议会话的各MCU的个别状态信息来生成所聚集的状态信息；以及

向所述会议会话的每一客户机分发所聚集的状态信息。

12.如权利要求9所述的方法，其特征在于，还包括基于会话参与者的改变来更新会话名单。

13.如权利要求9所述的方法，其特征在于，还包括将URI地址与所述可用的MCU的每一个进行关联，所述会话参与者经由所述可用的MCU的一个访问所述会议会话。

14.如权利要求9所述的方法，其特征在于，所述请求是会话发起协议(SIP)请求。

15.如权利要求9所述的方法，其特征在于，还包括程序引导可用的MCU进入所述会议会话。

16.如权利要求9所述的方法，其特征在于，还包括使用对MCU URI的拨入，使用所述MCU URI的拨出，或从所述可用的MCU到所述MCU URI的直接邀请，来加入所述可用的MCU，所述MCU URI标识所述可用的MCU。

17.如权利要求9所述的方法，其特征在于，还包括向另一参与者发出自组织邀请。

18.如权利要求9所述的方法，其特征在于，还包括经由所述会议控制组件呈现所述会议会话的单个会议视图。

19.一种管理多方会议的方法，所述方法包括：

响应于客户机提交的会议建立请求来提供集中式会议控制组件，所述会议控制组件被配置成：

从所述客户机接收所述会议建立请求以供初始化会议会话；

响应于接收所述请求来创建所述会议会话的会议实例；

作为对所述请求的响应，创建所述会议会话的地址并将其发送到所述客户机；

在接收所述请求之后向所述会议会话分配分布式MCU，所述会议控制组件基于所述分布式MCU提供的媒体类型的可用性来向所述会议会话分配所述分布式MCU；

在所述会议控制组件将所述MCU分配给所述会议会话之后，向所述客户机返回所述分布式MCU的统一资源标识符；

在所述会议会话期间管理会议状态；

将与所述会议会话相关联的状态的改变通知给已订阅的客户机，其中所述通知作为BENOTIFY消息来提供。