专利名称：分布式、可缩放、可插入的会议体系结构的制作方法
分布式、可缩放、可插入的会议体系结构本发明专利申请是2007年9月5日提交的、进入中国国家阶段的申请号为200780033969. 7、发明名称为“分布式、可缩放、可插入的会议体系结构”的发明专利申请的分案申请。背景计算设备和联网的技术进步继续提供对各种各样的信息和服务的更多访问，从而实际上允许从世界的任何地方访 问。由于需要完成的工作可从大多数位置来执行，因此虚拟办公室变得更加常见。网络运营商和供应商(蜂窝和非蜂窝)在基础设施上花费大量的金钱和资源，以支持现在存在的和将来将要上市的多种类型的便携式设备和媒体。例如蜂窝运营商正在争相提供允许蜂窝客户经由蜂窝网络访问IP网络(例如，因特网)和相关联的IP服务的基础结构。因此，蜂窝客户现在可访问基于IP的网络上可用的信息。类似地，计算设备可以通过IP网络进行对话，且甚至可以连接到蜂窝用户。例如，各企业仍然认识到会晤在高效地推动产品开发上的重要性。然而，将用户从其从其所处的多个远程位置聚在一起进行商务活动，并支持多种可用的通信设备和媒体类型，其前景还是很有挑战性。会议可以是公司企业的雇员可以例如进行会晤的有效手段。然而，给定任何时刻上的位置和连接能力，参与者可能想要经由不同的媒体类型加入。随着便携式无线计算设备的存储和计算能力的进步，用户现在能够与多种类型的不同数据类型进行交互，比如图像、视频剪辑、音频数据和文本数据。此外，用户通常可以具有若干类型的用其连接到会话的设备。例如，一用户可以从会议室通过音频/视频参与，另一用户经由台式计算机通过语音参与，而又一用户使用蜂窝电话通过文本输入参与。这些不同的媒体能力传统上在服务器级通过本地地合并媒体处理能力来提交。然而，这是有问题的，因为需要更多资源来管理这些系统且这些系统更难以缩放以满足会议需求。概述以下呈现了本发明的简化概述，以提供对所公开的本发明的某些方面的基本理解。该概述不是详尽的概览，它不旨在标识关键/重要的元素，也不旨在描绘其范围。其唯一的目的是以简化的形式来介绍一些概念，作为稍后提出的更为详细的描述的序言。此处所公开的是体系结构，其描述用于多方、多媒体会议的可缩放、可插入的体系结构。提供了用于允许无缝地插入诸如多点控制单元(MCU)等不同的分布式媒体组件的集中式策略和控制组件的框架。会议体系结构支持用于供客户机参与该会话的不同媒体类型(例如，数据、音频/视频、即时消息传送)的多个可插入分布式媒体组件。例如，为满足会议需求，客户机访问(例如，经由因特网连接)还被称为焦点的集中式控制组件，请求创建、调度会议会话或参与一当前会话。控制组件包括连接到客户机并向其分配适当的媒体接口(例如，音频、视频、数据)，配置该媒体接口以满足所请求的客户机媒体类型，提供该会议会话的会话管理，以及针对所有相关联的客户机和系统管理会话的关闭和清除的能力。该集中式会议控制组件还提供调度服务和会话实例的创建(经由焦点工厂)。该会议控制器还包括向会议会话分配一个或多个最可用的分布式媒体组件(经由媒体工厂)的功能。该会议控制组件还用作会议策略和名单(roster)控制服务。会议策略服务器是可以存储和操纵会议策略和名单的逻辑功能。会议策略是管控会议的操作的规则的总体集合，且可被分解为成员资格策略和媒体策略。该会议控制组件包括会议通知服务，其是允许焦点用作通知者，接受对会议状态的订阅，以及将该状态的改变通知订阅者的逻辑功能。状态包括例如焦点本身所维护的状态、会议策略和媒体策略。该会议控制组件还用作基于身份信息和/或PIN来经由用户授权和/或认证服务提供会话安全。该集中式会议控制器还通过接口连接到用于会议策略和名单管理服务的分布式媒体组件(例如，MCU)。该会议体系结构使用来自焦点的单个集成式名单向会议参与者提供单个会议图片，且可以通过该焦点控制会议。为了对其进行支持，此处所公开的和要求保护的体系结构包括计算机实现的会议 系统，该系统包括用于集中控制会议会话的会议控制组件和用于使用一媒体类型将客户机通过接口连接到会议会话的分布式媒体组件。该媒体组件可以在任何位置(例如，因特网上)，从而允许例如经由HTTP访问。该集中式控制器不需要知道关于该分布式媒体组件的任何事物。为了实现前述及相关目的，在这里结合下列描述及附图来描述所公开的本发明的某些说明性方面。然而，这些方面仅指示了其中可利用此处公开的原理的各种方法中的少数几种，且旨在包括所有这些方面及其等效方面。结合附图阅读下面的详细描述，则其它优点和新颖特征将变得清楚。附图简述图I示出用于分布式媒体访问的计算机实现的会议系统。图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管理服务。开始参考附图，图I示出用于分布式媒体访问的计算机实现的会议系统100。系统100是支持供会话参与者经由多个不同设备访问的多个可插入分布式媒体系统的可插入会议体系结构。为此，系统100包括用于集中式地创建和控制会议会话的基于网络的会议控制组件102。系统100的控制组件102通过接口连接以管理诸如多点控制单元(MCU)的一
个或多个分布式媒体组件104 (由媒体组件P ......、媒体组件N表示，其中N是正整数),分
布式媒体组件104又提供由客户机106 (由客户机P……、客户机M表示，其中M是正整数)经由类似的和/或不同的媒体模式(例如，音频、视频)对会议会话进行客户机访问。MCU是便于连接和管理一种或多种客户机媒体类型的系统。媒体直接在客户机和MCU之间交换。常规系统不使用MCU，其至少包括根据所公开的新颖体系结构所提供的MCU的分布式能力。换言之，为满足会议要求，客户机108访问(例如，经由因特网连接)控制组件102，请求创建会议会话。控制组件102便于向会话参与者(例如，客户机101和客户机i、客户机2和客户机3)及其所需连接类型(例如，音频、视频)分配适当的媒体组件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还包括启用会议调度的调度组件/焦点工厂(focus factory)组件410。认证组件412基于身份(例如，活动目录)或使用PIN来提供用户授权和认证处理。MCU接口组件414便于通过接口连接到用于会议名单/策略管理的多个分布式媒体组件404(例如，各个MCU 404) ^MCUpMCUy……、MCUT表示，其中T是正整数)。焦点402包括MCU分配组件(也被称为MCU工厂)416，其功能是对该会议会话分配网络418 (例如，因特网)最可用的基于网络的MCU 404。系统400还包括各个可插入会议参与者(由客户机420表示)，它们从主焦点获得具有单个集成式名单的单个会议图片，并且可以通过该焦点控制该会议。图5示出在内联网客户机与各参与者交互以创建和加入会议的情况下，各参与者之间的数据流。在所公开的集中式会议体系结构中，存在对所有会议参与者可见的单个(或主)焦点。该焦点是同一会议中的各参与者的单个中央信令点。每一会议由唯一的SIP (会话发起协议)可路由会议URI来标识。通常，该URI路由到MCU所实现的、主存该会议的焦点。为了提供改进的用户体验，该系统引入主焦点的概念，其中所有会议URI都路由到该主焦点。客户机用户被该焦点授权参加会议，他们从该焦点获得关于会议状态的改变的通知，且所有的会议控制操作由客户机向该主焦点发起。
该体系结构的各组件是客户机500、焦点工厂502、焦点504、MCU工厂506和MCU508。所公开的会议体系结构的主特征之一是使用以分布式方式操作的多个组件而非常规的单片服务器体系结构。会议客户机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 (由④表示)时，其找出哪一 MCU508最适合应答该请求并返回该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是在“PS0M”技术上设计的。数据协作MCU支持诸如例如呈现软件文档、字处理和电子表格文档、聊天、投票、白板、和应用程序共享等特征。音频/视频MCU提供建立在工业标准RTP (实时传输协议)和RTCP (RTP控制协议)上的多方音频和视频混合和中继能力。可以设计并提供其它MCU，比如，即时消息传送(M)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中所指定的)被用于建立和终止呼口H。另外，同一会议会话可用于使用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被构建为包括唯一会议标识符、唯一服务器标识符、和在用户信息部分主存会议的域，例如，organizeridomain, com ；ms-app=conf ;ms-conf-id=ll。客户机可以用三种方式创建会议经由web服务、SIP邀请机制和SIP服务机制。图8示出用于经由web接口 /服务发起会议创建的示例性呼叫流程图。客户机连接到已知焦点工厂web URI并使用所暴露的web接口来创建焦点。在成功创建焦点后，网页将客户机指向必要的信息，以使会议客户机拨入到该会议。图9示出用于经由邀请机制发起会议创建的示例性呼叫流程图。客户机将其需要的关于会议、媒体类型、特权、参与者等的所有信息作为INVITE (邀请)请求的一部分来传递给焦点工厂。焦点工厂创建焦点实例，并使用所生成的焦点URI将客户机重定向到焦点。更具体地，客户机向焦点工厂发送带有要创建会议的信息的INVITE请求。焦点工厂向客户机发送临时Ixx响应，以便在焦点工厂实例化焦点时客户机事务不超时。如果结果是创建焦点所花费的时间小于SIP事务超时，则可以忽略发送该响应。焦点工厂随后从INVITE中解析出所有所需信息，并创建焦点实例。因为焦点工厂和焦点可以共同配置，该创建焦点的调用可以仅仅是本地函数调用。焦点工厂随后发送具有联系报头的302响应，从而重定向客户机以与焦点开始新的邀请会话。客户机将ACK发送回焦点工厂。
图10示出用于经由SIP服务机制发起会议创建的示例性呼叫流程图。客户机将其需要的关于会议、媒体类型、特权、参与者等的所有信息作为服务请求的一部分来传递给焦点工厂。焦点工厂创建焦点实例，并在2000K响应中将连接信息发送回客户机。更具体地，客户机向焦点工厂发送带有要创建会议的信息的SERVICE请求。焦点工厂从SERVICE中解析出所有所需信息，并创建焦点实例。因为焦点工厂和焦点可以共同配置，该创建焦点的调用可以只是本地函数调用。焦点工厂发送具有会议信息的2000K响应。图11示出用于客户机拨入会议的示例性呼叫流程图。客户机与焦点建立用于拨入会议的INVITE对话和SUBSCRIBE (订阅)对话。客户机使用INVITE对话来加入会议，并还将其用于从客户机到焦点的命令通信量的第三方控制。来自客户机的控制命令在INFO(信息)消息内部携带。INFO消息的本体包含C3P控制请求且由焦点处理。客户机使用SUBSCRIBE/NOTIFY (订阅/通知)对话来监视会议状态。焦点接受订阅并将任何会议状态改变通知订阅者。状态包括焦点本身所维护的状态、会议策略和媒体信息。例如，如果客户机在INVITE对话中使用INFO消息所发送的命令是改变会议状态的命令，则焦点还通过发送经更改的会议状态的NOTIFY来通知客户机。更具体地，客户机向焦点URI发送INVITE请求来加入会议。该INVITE对话有两个目的其暗示客户机加入会议以及其被用于使用该对话中的INFO请求进行会议的第三方控制。INVITE本体中的C3P addUser请求可被用来指定特定的客户机属性(例如，显示名称、角色、隐藏的参与者)。客户机发送对会议事件包的SUBSCRIBE来监视会议状态通知。初始会议状态文档可以承载在属于表达支持该扩展的客户机的SUBSCRIBE的2000K中。图12示出用于客户机通过addUser拨入经由数据协作MCU加入的示例性呼叫流程图。对于会议中的每一 MCU，焦点分配可路由到焦点本身的虚拟SIP URI。从焦点到客户机的初始通知包含会议中的所有MCU的URI。客户机可以用三种方式来用MCU建立媒体会话对MCU URI的addUser拨入、使用MCU URI的addUser拨出和对MCU URI的直接媒体INVITEo对于addUser拨入，客户机发出addUser拨入C3P命令，且焦点将该命令转发给MCU0 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 BEN0TIFY (或Best Effort NOTIFY(尽力通知)))。图13示出用于客户机通过addUser拨出经由音频/视频MCU加入的示例性呼叫流程图。客户机发出addUser拨出C3P命令且焦点将该命令转发到MCU。MCU授权该命令并拨出到addUser命令中提到的客户机。客户机随后用该MCU建立直接媒体会话。这在客户机连接到基于SIP的MCU (例如，A/V MCU和頂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的示例性呼叫流程图。在客户机I和焦点之间发起客户机加入序列，随后从客户机I向焦点发送INFO addUser拨出消息。从焦点返回200ACCEPT (接受)消息。焦点向MCU发送addUser拨出消息，且MCU用2000K响应。MCU向第二客户机2发送经由焦点路由的INVITE消息。客户机2用2000K消息响应，随后从MCU接收ACK。随后在MCU和客户机2之间发起媒体流(例如，使用RTP)。MCU向焦点发送参与者已加入事件。焦点随后向客户机I发送更新名单消息，指示客户机2已加入会议会话。 上述应用程序邀请机制对理解应用程序邀请和C3P协议机制的新客户机起作用。然而，可以邀请不理解C3P的传统客户机。该机制还可以被用来将纯SIP客户机拉(pull)入会议。客户机可以向初始INVITE对话发送BYE (再见)来离开会议。为了检测到崩溃的客户机，可以使用会话保持活跃消息。可以进行从MCU到焦点和从焦点到客户机的会议状态通知。状态通知数据模型包括以下元素会议描述(例如，名称、主题、组织者描述)；包括关于能力、当前状态、设置和策略等信息的会议视图(例如，每一实体焦点的会议级别信息，如AV MCU、IM MCU);用户(例如，会议名单、用户、对应的端点和其连接到的媒体会话)；以及私下会议(分会议的表示)。以下代码表示会议状态分层结构的一个示例。Conference-info[I. . I]Conference-description[O. . I]Conference-view[O.. I]Entity-view
(由实体 URI 键控)Entity-capabilities
Entity-policy
Entity-settings
Entity-state
Conference-media
(由媒体标记键控)Users
User
(由用户 URI 键控)Endpoint
(由端点 URI 键控)Media
(由媒体id键控。标记是对会议媒体元素的引用，见下。)Sidebars-by-val
Entry
(递归地定义分会议对象)。以下代码表示具有两个MCU (例如，A/V、数据)且没有用户登录的初始会议状态的
一个示例。<conference~info >
<conference-descrip Ii on >
<disp!ay-iexi>hrownhag </disp lay-1 ex/ >
<c(mf-uris>
<eniry>
<tirl>sip:()rganizor@nvsfix:o'm;ms-app conf/meeiing;ms-conf~id=cd</ifri>
<d is p lay-1 ex I > I )a I a M( J</disp!ay-text>
<pu rp os e > m e e i ng < /p u rp os e >
</entry>
<entry>
<Nri>sip:organtorfcnmsf}.com;ms-app conj/aiuii.o-video;ms--conJ-i(J cd/uri><disp1ay-texi>A V MC !J</display-iexi>
<purpose>aifdi()-vicico</purpose>
</entry>
</conf-uris>
</conference-clescri.pfi()n>
<c()}iference-uifo >以下表示供用户尝试加入和程序引导A/V MCU的代码的一个示例。
<c(>nference-info >
<conference-descripiion>
</conference-description>
<conference-vie\\'>
<eniliy-vic\v en/iiy "focus "/>
<enlify~view enliiy nA Vn >
<eniuy-siaie />
<cmliy-view />
<entity-view>
<c()nference-view>
</c ο nfere n c e-info >以下表示关于加入焦点的用户Bob的代码的一个示例。
以下表示关于加入AV MCU的用户Bob的代码的一个示例。
<c ο nfere nce- info > <conference-descripiion></conference-descripiion>
<c ο nfe re nce-、e ι,ν >
</conference-view>
<users >
<user enliiy "sip:bob stale "full” >
<(.Hs p I ay-1 ex l>hob< /isp! ay -1 ex t >
<roles > < en iry >pres en I er</enlry> </ro I e.s > <endpoi.nl enliiy ”sip:Iwb:foci'!s" > <siaiiis>connecied</siatns>
</endpoini>
<endpoin! enliiy "sip:hob;A V" >
<s la I us > c o n n c c I e d < /s ta I us >
</encipoini>
</user>
</mers
<c o nfere nce-info >可以用若干方式完成对焦点工厂URI的发现通过分组策略使用，通过DNS (域名服务器)、服务器的固定URI和用户概况数据。一种管理员通常用来向客户机分发设置的方法是使用分组策略对象(GP0)。某些应用程序设置和特征可以通过GPO设置来打开或关闭。例如，管理员可以通过GPO选择移除某些菜单选项或添加某些其它选项。通过使用GP0，域管理员可以将特定用户组指向特定焦点工厂。这排除了手动配置要求。另一选项是使用DNS记录来将客户机指向焦点工厂URI。DNS SRV是标准DNS服务器的扩展，且被用来获取服务器的一个或多个IP地址，每一服务器都具有其自身的优先权。以下是示例SRV记录_http. _tcp. example, com. SRV 10 5 80. www. example, comSRV记录命名惯例要求记录顺序地包含以下各项下划线，其后是服务名，点，下划线，其后是协议，点，随后是域名。另一选项是使用焦点工厂的固定URI，如sip:FocusFactoryimicrosoft. 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的2000K响应中携带，作为用于媒体协商的有效载荷。在所公开的框架中，创建会议意味着创建和配置焦点实例。焦点工厂的工作是向客户机返回焦点的URI。这意味着客户机和焦点工厂之间的这一对话不必是持久的。其只需要持续到焦点URI被返回到客户机为止。焦点工厂在其向客户机返回其URI之前创建并配置焦点。该配置设置该会议要使用的媒体类型，预期参与者数量，已知的参与者的角色和特权，角色定义等。焦点工厂具有允许提前调度会议的web服务接口。在该场景中，会议客户机直接与焦点对话，从不与焦点工厂建立对话。然而，对于自组织会议，会议客户机与焦点工厂对话来使之提供焦点URI。图17示出使用重定向的示例性呼叫流程图。最初，客户机向焦点工厂URI发送INVITE，其中·目的地=焦点工厂URI
源=用户 URI 内容类型=多方MME·内容=包含初始参与者列表、角色映射和模板标识令牌的XML内容运行在池上的焦点工厂应用程序接收该消息，并返回100—正在进行中或180—Ringing(振铃)临时响应。这允许客户机等待同时允许焦点工厂执行任何数据准备和查找。焦点工厂创建焦点并在302—重定向响应一的联系人报头中返回焦点URI。这允许客户机缓存联系人报头值作为会议URI。客户机向其接收到的焦点URI发送同一 INVITE。唯一的不同之处是，这次目的地报头具有作为会议ID (conf-id)的GRUID参数。图18示出将创建会议和客户机加入会议分开处理的示例性呼叫流程图。这更好地反映了发生的操作的各个阶段。因此，创建会议包括将INVITE从客户机传递到焦点工厂，可任选地接收回正在进行中响应180,从焦点工厂向焦点发送CreatFocus (创建焦点)以创建焦点实例，向焦点工厂返回焦点数据，向客户机发送联系人焦点URI，并确认接收。与加入会议相关联的消息包括向焦点发送具有客户机的焦点URI的INVITE，将2000K接收回客户机，并确认接收。在从客户机接收到INVITE消息时，焦点工厂创建焦点并向客户机返回焦点信息。正如焦点工厂一样，焦点是由应用程序所表示的SIP端点。焦点工厂将其接收到的INVITE请求重定向到焦点，从而允许焦点成为与客户机进行媒体协商的端点。 如上所述，焦点是会议的“经注册”处理程序。焦点URI表示会议，且还被称为会议URI。一种确定性方法是对URI的用户部分使用固定模式，并用会议ID信息来对其注释。这允许以更容易的方式基于该URI来编写路由逻辑，并允许焦点URI被映射到企业内的单个应用程序，这便于对系统的管理。这一使用由对SIP的“GRUU/GRID扩展”来概括，其允许向公知焦点URI附加GRUU参数。示例是Sip:conf-mgriconfserver, company, com;grid=Schumacher1980Sip:FocusFactoryMSiconferencing. 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工厂列表将包括两个实体，一个对应于该媒体类型的这些供应商的每一个。设置的示例表示包括以下
权利要求
1.一种计算机实现的会议系统，包括 存储指令的存储设备；以及 访问并执行所述指令的处理单元，所述处理单元对所述指令的执行使得所述会议系统响应于客户机提交的会议建立请求来提供会议控制组件，所述会议控制组件被配置成从所述客户机接收所述会议建立请求以创建会议会话； 在接收创建所述会议会话的所述请求之后，向所述会议会话分配向所述客户机提供所述会议会话的媒体的分布式媒体组件； 在所述会议控制组件向所述会议会话分配所述分布式媒体组件之后，向所述客户机返回所述分布式媒体组件的统一资源标识符； 接受所述客户机对所述会议会话的订阅；以及 将与所述会议会话相关联的状态的改变通知给已订阅的客户机，其中所述通知作为BENOTIFY消息来提供。
2.如权利要求I所述的系统，其特征在于，所述分布式媒体组件是适应数据、音频信号、视频信号、和即时消息传送信号的至少一个的多点控制单元。
3.如权利要求I所述的会议系统，其特征在于，所述会议控制组件提供维护管控所述会议会话的操作以及允许参与者参加所述会议会话的规则的策略和名单组件。
4.如权利要求I所述的会议系统，其特征在于，所述会议控制组件提供通过基于参与者身份信息限制对所述会议会话的访问来在所述会议会话上施加安全的认证组件。
5.如权利要求I所述的会议系统，其特征在于，所述会议控制组件提供向所述会议会话分配所述分布式媒体组件的分配组件。
6.如权利要求I所述的会议系统，其特征在于，所述会议控制组件提供调度所述会议会话的调度组件。
7.如权利要求I所述的会议系统，其特征在于，还包括前端服务器的会议池，所述前端服务器的每一个都运行所述会议会话的实例，所述前端服务器池包括处理单元，客户机访问所述前端服务器的一个来访问所述会议会话。
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所述的方法，其特征在于，还包括使用对MCUURI的拨入，使用所述MCU URI的拨出，或从所述可用的MCU到所述MCU URI的直接邀请，来加入所述可用的MCU，所述MCU URI标识所述可用的MCU。
17.如权利要求9所述的方法，其特征在于，还包括向另一参与者发出自组织邀请。
18.如权利要求9所述的方法，其特征在于，还包括经由所述会议控制组件呈现所述会议会话的单个会议视图。
19.一种不包括已传播的数据信号的计算机存储介质，所述计算机存储介质包括指令，计算设备对所述指令的执行将所述计算设备配置成 响应于客户机提交的会议建立请求来提供集中式会议控制组件，所述会议控制组件被配置成 从所述客户机接收所述会议建立请求以供初始化会议会话； 响应于接收所述请求来创建所述会议会话的会议实例； 作为对所述请求的响应，创建所述会议会话的地址并将其发送到所述客户机； 在接收所述请求之后向所述会议会话分配分布式MCU，所述会议控制组件基于所述分布式MCU提供的媒体类型的可用性来向所述会议会话分配所述分布式MCU ； 在所述会议控制组件将所述MCU分配给所述会议会话之后，向所述客户机返回所述分布式MCU的统一资源标识符； 在所述会议会话期间管理会议状态； 将与所述会议会话相关联的状态的改变通知给已订阅的客户机，其中所述通知作为BENOTIFY消息来提供。
全文摘要
用于可缩放、可插入、多方、和分布式多媒体会议的体系结构。集中式策略和控制会议组件允许无缝地插入不同的分布式媒体组件(例如，数据、音频/视频、消息传送)，以适应客户机参与会议会话。该集中式会议控制组件包括以下用于接受对会议状态的订阅并通知订阅者该状态的变化的会议通知服务；用于存储和操纵会议策略和名单的会议策略和名单控制服务；用于基于用户身份信息来授权/认证用户的安全服务；用于会议调度的调度服务；用于分配会议会话的最可用的媒体组件的分配服务；以及用于分布式媒体组件的会议策略和名单管理的MCU管理服务。
文档编号H04L29/06GK102904733SQ20121034250
公开日2013年1月30日 申请日期2007年9月5日 优先权日2006年9月15日
发明者D·D·塞卡莱, S·D·皮尔斯, S·D·考克斯, S·舍洛夫, P·科蒂斯, D·尼科尔斯, B·K·梅达, V·艾戴尔曼, V·K·H·帕塔萨拉蒂, O·莱文, G·基米驰 申请人:微软公司