CN105765939B - 一种通信系统及方法、计算机系统 - Google Patents

Abstract

公开了用于实现包括第一和第二计算机设备的计算机系统和通过通信网络连接的额外端点之间的通信事件的通信系统，所述通信系统包括处理单元，每个处理单元具有对保存用于管理通信事件的可执行代码模块的计算机存储器的访问，所述可执行代码模块被配置为实现被配置为管理已建立的通信事件的媒体模态的媒体模态控制器，和被配置为建立该通信事件的呼叫控制器。媒体模态控制器的实例是响应于由该呼叫控制器向媒体控制器发起的指令而指派的，以无需访问第二设备上的呼叫代理而将该通信事件的媒体模态控制信号传送给第一设备上的媒体代理。由呼叫控制器发起指令是响应于通过网络从第二设备上的呼叫代理接收到的指令的。

Description

一种通信系统及方法、计算机系统

背景技术

传统通信系统允许设备用户(端点)(诸如个人计算机或移动设备)通过诸如互联网之类的基于分组的计算机网络与一个或多个其它端点进行语音或视频呼叫。图1示出了这样的用户设备102的示例，如用户104所使用的。用户设备102被显示为执行通信客户端120以用于进行这些呼叫。端点的呼叫数据的通信频繁地受到遵守已达成的通信协议的端点的影响。其中一个示例是会话发起协议(SIP)。在广义的术语中，SIP指示呼叫是根据端点到端点的基于请求应答事务范式协商的，其中(除了别的之外)，呼叫从初始未连接状态发展到实时媒体能够通过SIP用户代理(诸如构成端点102处执行的客户端软件106的一部分的SIP用户代理108)向其它端点的其它用户代理发送请求消息序列并接收相应响应消息作为回报而在端点之间流动的状态，同时呼叫的维护和最后终止都受到类似的影响。每个用户代理针对该呼叫的持续时间维护状态机(诸如状态机110)，其用于跟踪当前呼叫状态。该状态机根据显著请求的传输和显著响应的接收适当地更新。

在图2中描绘了两个用户(Alice和Bob)之间的SIP呼叫流的典型示例。首先，Alice的用户代理向Bob的用户代理发送邀请请求(S202)，Bob 的用户代理首先返回临时的响铃响应(S204)，其后紧跟着OK应答(S206) 指示Bob已经接受该呼叫。Alice的用户代理用ACK消息(S208)和实时媒体流开始(S210)对此进行确认。在S212处，Alice的用户代理通过向Bob的用户代理发送再见请求(S212)促使呼叫终止。作为响应，Bob的用户代理返回OK应答(S214)并且终止该呼叫。如图所示，Alice和Bob的用户代理可以通过SIP代理120交换这些消息。例如，Alice和Bob的用户代理可以首先向代理120注册它们各自的地址以便使它们相对于对方“可见”。通常，代理120到目前为止是无状态的，因为它不维护任何关于当前呼叫状态的数据(而是仅仅用作中继器)，或者到目前为止是事务有状态的，因为它只维护关于当前事务(即，单个请求-响应交换)的以及仅针对那些事务的持续过程中的有限的信息。

发明内容

提供这一简要概述，以便以简化形式引入选择的概念，下面在具体实施方式中将进一步描述这些概念。这一简要概述不是旨在标识出所声明主题的关键特征或重要特征，也不旨在用作限定所声明主题的范围。所声明的主题也并不仅限于解决背景技术中提出的任何或全部缺点的实现方式。

公开了用于实现包括第一和第二计算机设备的计算机系统和通过通信网络连接的一个或多个额外端点之间的通信事件的通信系统。该通信系统包括多个处理单元，每个处理单元具有对保存用于管理通信事件的可执行代码模块的计算机存储器的访问。该代码模块被配置为实现被配置为管理已建立的通信事件的媒体模态的媒体模态控制器，以及被配置为建立该通信事件的呼叫控制器。媒体模态控制器的实例被指派为响应于由呼叫控制器向媒体控制器发起的指令，以无需访问第二设备上的呼叫代理而将通信事件的媒体模态控制信号传送给第一设备上的媒体代理。响应于通过网络从第二设备上的呼叫代理接收到的指令，该呼叫控制器发起所述指令。

还公开了一种用于实现包括第一和第二计算机设备的计算机系统和通过通信系统的通信网络连接的一个或多个额外端点之间的通信事件的方法。该通信系统包括多个处理单元，每个所述处理单元具有对保存用于管理通信事件的可执行代码模块的计算机存储器的访问。该代码模块被配置为实现被配置为管理已建立的通信事件的媒体模态的媒体模态控制器，以及被配置为建立该通信事件的呼叫控制器。该方法包括响应于通过网络从第二设备上的呼叫代理接收到的指令，呼叫控制器向媒体控制器发起指令，响应于该呼叫控制器发起的指令，指派媒体模态控制器的实例无需访问第二设备上的呼叫代理而将通信事件的媒体模态控制信号传送给第一设备上的媒体代理。

还公开了一种包括第一计算机设备和第二计算机设备的计算机系统。该第一用户设备包括网络接口和处理单元。第一设备的网络接口被配置为通过通信系统的通信网络与该通信系统的媒体模态控制器通信。该媒体模态控制器被配置为管理已建立的通信事件的媒体模态，该媒体模态控制器是响应于来自该通信系统的通信控制器的指令的。第一设备的处理单元被配置为执行媒体模态代理，该媒体模态代理被配置为与媒体模态控制器而不与通信控制器通信。该第二计算机设备包括网络接口和处理单元。第二设备的网络接口被配置为通过网络与呼叫控制器通信，该呼叫控制器被配置为建立该通信事件。第二设备的处理单元被配置为执行呼叫代理，该呼叫代理被配置为与呼叫控制器通信并且通过与所述呼叫控制器的所述通信间接地控制第一用户设备的媒体模态代理的操作。

还公开了包括网络接口和处理单元的第一计算机设备。该网络接口被配置为通过通信系统的通信网络与该通信系统的媒体模态控制器通信，以便管理已建立的通信事件的媒体模态。媒体模态控制器是响应于来自通信系统的通信控制器的指令的，该通信控制器被配置为建立通信事件。处理单元被配置为执行媒体模态代理，该媒体模态代理被配置为与媒体模态控制器而不与通信控制器通信，第一用户设备的媒体模态的操作是通过与所述呼叫控制器通信的第二用户设备而被间接地控制的。

附图说明

为了辅助理解所公开的主题以及示出可以如何使其生效，现在将通过举例的方式参考下面的附图，其中：

图1是执行SIP客户端的用户设备的示意图；

图2是基于SIP的呼叫流的示意图；

图3是通信系统的示意图；

图4是用户设备的示意图；

图5A是数据中心的示意图；

图5B是数据中心的服务器的示意图；

图6A和6B示意性地描绘了分层通信系统架构的原理；

图7A和7B示意性地描绘了在通信系统内交换数据的方法；

图7C是通信系统中的数据交换的示意图；

图8是通信系统架构的示意性概览。

图9是特定通信系统架构的示意图，其中图9A、9B和9C示意性地描绘其额外细节；

图10A 是呼叫建立过程的示意图，其中图10B 示意性地描绘其额外细节；

图11A和11B提供故障转移过程的示意图；

图11C是用于实现故障转移过程的方法的示意图；

图12和12A根据通信系统架构示意性地描绘了用户设备；

具体实施方式

0.1概述

在一个或多个端点之间建立诸如呼叫(例如，音频呼叫、音频和视频 (AV)呼叫等等)之类的实时媒体通信事件时，需要考虑很多因素和变量来做出若干决定，包括是否应允许参与方互相呼叫、使用什么音频和视频编解码器、如何将媒体分组从一方端点路由到另一方等等。为了(除了别的之外)确保做出适当的决定，为呼叫中的参与方提供最好的切实可行的质量，并且尽可能快地完成呼叫建立，负责该呼叫建立(包括媒体(例如，音频和视频)协商)的算法、协议、系统和处理应该具有对任何显著信息的访问并且应该被分配足够的计算资源以便能够执行它们各自的控制功能。

在所描述的实施例中，定制的中央智能云呼叫建立、控制和媒体协商 (CICCSMNC)系统从“分布式平台”(或者称为“云平台”或简称为“云”)内部提供对实时媒体通信事件的集中化(与基于端点正相反)控制，其中 CICCSMNC系统被定制为使用这一云平台所提供的计算资源，该云平台可以容易地并且动态地确保(除了别的之外)满足上面的考虑。

如本申请中所使用的，“分布式平台”(“云”)是计算平台，可通过网络 (例如，互联网)访问，其包括由多个联网的计算机设备和其上运行的系统软件组成的分布式计算机系统，该计算机系统提供(潜在地非常大的) 物理计算资源(诸如物理处理资源和物理存储资源，易失性的和/或非易失性的)池，并且所述系统软件被配置为通过实现多个独立的、软件实现的 (或“虚拟的”)、资源有限的计算机系统来划分这一底层物理资源池，每个所述计算机系统具有它们自己各自的计算机架构(其可以不同于它们在其上运行的底层物理计算机系统的架构)。这些虚拟计算机系统的每一个由系统软件分配(并且因此可以利用)总的可用物理资源的预定的一部分，该部分具有实质上独立于该平台的任何其它虚拟计算机系统的尺寸。这些虚拟计算机系统中的至少一些被配置为提供应用代码的运行时环境，在该虚拟计算机系统中(例如，在一个或多个虚拟处理器上)执行的代码应用具有各自的指令集架构(其可以不同于该虚拟计算机系统在其上运行的任何物理处理器的架构)。这些或其它这种虚拟计算机系统可以被配置为数据访问单元(例如，被配置为数据库服务器或类似的)，被配置为提供该数据访问单元可访问的物理存储资源的访问，因此应用代码可以从那些物理存储资源读取数据并向其写入数据。

这一物理计算机资源池，以及通过虚拟化动作对该池的划分能够由于虚拟化分层(由该平台的系统软件实现的)使硬件和软件考虑解耦合，该虚拟化分层提供物理计算机资源(例如，可用的物理处理器时钟周期和存储器的物理比特)从“虚拟”资源的分离—也就是，资源实际是在每个虚拟计算机系统中看到的。底层硬件的物理资源可以通过新的物理网络计算机设备的添加，或现有物理联网计算机的升级来增强，并且在传统兼容方面唯一需要的考虑就是确保升级后的物理计算机系统还是能够运行相同种类的虚拟机(即，无需任何关于什么操作系统或应用代码将运行在那些虚拟机上的考虑)。类似地，系统设计者可以设计系统(可能是具有很多组件的极其复杂的系统)，并且开发与之有关的、用于与物理硬件考虑(诸如顺序、部署和安置物理服务器等)无关的云平台上的实现的代码—系统设计者只需要考虑在虚拟计算机系统的资源限制(而非地底层硬件的资源限制)方面的计算机资源消耗，那些虚拟系统的资源限制是明确定义的并且已知。因此，从系统设计者的角度，计算机资源考虑被减少到，例如该云平台应该部署多少个虚拟计算机系统之类的考虑；从平台本身的运营者的角度(该运营者可能不同于系统设计者)，计算机资源考虑被减少到，例如实现要求数量的具有预定义资源分配的虚拟机需要多少个物理计算机系统之类的考虑。

图8中示出了示例性分布式平台800的高级概述。该示例性平台包括分布式计算机系统814。图8的计算机系统814由非常大量的(例如，成千上万)联网计算机设备组成—大到足够物理计算资源在一些上下文中可以被视为足够丰富就像实际上无限的一样。这些计算机设备被配置为与基于分组的数据网络301(例如，互联网)通信并且是全球分布的(例如，分散遍布多个国家和/或大洲)。通常，这些计算机系统的分组(例如，成千个服务器)被安置在不同地理位置处(即，国家的不同区域、不同国家、不同大洲等)的相应数据中心(datacentre)中(作为替代可称为“数据中心 (datacentre)”)。

系统软件812运行在该分布式计算机系统814之上。系统软件812被配置为实现独立的、虚拟的、资源有限的计算机系统806、810的两个集合 804(运行时集合)和808(存储集合)。每个虚拟系统806、810是资源有限的，这体现在其被系统软件812分配了分布式计算机系统814的全部可用底层物理资源的预定的有限的一部分，并且它也是独立的，这体现在这一部分资源的尺寸实质上独立于平台800的其它虚拟系统。每个虚拟系统 806、810就其被软件配置为模拟计算机架构(其通常不同于物理计算机系统814的架构)方面而言是虚拟的。

运行时集合804包括多个虚拟计算机系统806，它为应用代码834的执行提供运行时环境，应用代码834在该虚拟计算机系统806上执行。系统软件812被配置为使希望使用平台800的软件开发者能够通过网络301将他们的定制代码834上传到平台800以便在其上执行。作为响应，系统软件812创建这一运行时环境并将代码834提供给新创建的运行时环境用于执行。这一代码834在虚拟系统806上的执行是通过对分配给该环境的底层物理处理资源和物理存储资源(主要由物理易失性存储器实现在物理层级)的系统软件中介访问而变为可能的。

存储集合808包括被配置为提供数据存储的多个虚拟计算机系统810。每个具有相应的应用编程接口(API)811，该API可以用于实现数据向和从分配给该计算机系统810的物理存储资源(主要由物理非易失性存储器实现在物理层级)的数据转移，例如通过代码834做出对其适当的函数调用。这一转移再次由系统软件812中介。

分布式平台的示例包括Windows Azure(TM)、Amazon网络服务(TM) 等。

CICCSCMN系统是根据一组原则和设计模式的集合设计和实现的，其核心在于中央控制和决策制定(与例如端点控制和关于图1和图2所讨论的SIP的决策制定正相反)。它包括很多服务逻辑，每个服务逻辑由云平台的一个或多个虚拟计算机系统上执行的应用代码来实现，那些虚拟计算机系统不同于该云平台的其它服务逻辑的计算机系统(也就是，这样不同服务逻辑就由该云平台的各自不同虚拟计算机系统上执行的不同应用代码集合来实现)。

服务逻辑可以根据类型分组(每个类型有多个服务逻辑)。每个类型的服务逻辑被配置为—通过与构成终端用户通信客户端应用的一部分的相同类型的其它服务逻辑和服务代理交互—控制使用该客户端的通信系统上进行的实时媒体通信事件(例如，AV呼叫)的不同方面。

中央控制和决策制定并不是由单个服务逻辑或软件组件实现的，而是由不同类型的多个独立的服务逻辑(控制器)实现的，它们共同工作以控制并辅助任何给定的实时媒体通信事件。所述服务是解耦合的，具有明确定义的边界和接口。针对呼叫建立和相应的媒体建立，以及在呼叫进行的同时对这些的控制，如下定义了并在表1中列出了下面的服务分组(服务的类型)：

-第一类型：呼叫控制(监督信令、呼叫状态、控制—控制是通过信令的变化状态的复合)

-第二和第三类类型：传输控制和管道控制(监督拓扑、端点连接/管道管理、媒体流和分组化、线路上的加密)。传输处理整个端点拓扑，并且指示管道在呼叫的拓扑中的端点之间建立连接。

-第四类型：音频媒体控制(监督音频编解码器选择、音频特定变量管理、端点音频控制(例如，静音))

-第五类型：视频媒体控制(视频编解码器选择、视频特定变量管理、端点视频控制(例如，启用/禁用视频))

表1

任何给定呼叫通常将在该呼叫期间的任何给定时间由每类服务逻辑中的一个(也就是，每个分组中的一个)控制(虽然该类型的个体服务逻辑在某些条件下遭受呼叫过程中的变化)。

服务逻辑暴露接口-例如，RESTful(“代表性状态转移”)接口—用于与相互和/或与它们各自的代理通信。REST是一种抽象了分布式超媒体中的架构元件的架构风格，在较高的抽象水平抽象处理元件(即，执行运行时功能的元件—在当前上下文中包括服务逻辑和服务代理)；数据元件(即，由处理元件处理的数据—在这一上下文中包括实时媒体通信事件数据和相关联的控制数据)；以及连接元件(即，在这一上下文中有助于通信系统中的处理元件之间通信的机制)。REST忽略了处理元件实现和协议语法的细节，以便聚焦在处理元件的角色、它们与其它组件的交互上的约束和它们对重要数据元件的解释上。

服务被具有基本不相交的职权(即，在不同类型的服务逻辑所执行的任务之间有最小化的重叠或没有重叠)的不同类型的服务逻辑“划分边界”：如果由第一类服务逻辑的第一服务的控制迫使必须执行第二类服务逻辑的职权中的任务，则该服务逻辑将请求该第二类型的第二服务逻辑代替执行该任务，而不是它自己去执行该任务。服务间请求是高层级请求，在该请求中它们不指定低层级的实现细节(也就是，它们只请求完成特定任务，而不指定如何完成它的低层级细节)。然后，一旦该任务完成则该第二服务逻辑通知第一服务逻辑，还是无需传输任何关于如何完成该任务的低层级细节。例如，第一服务逻辑可以请求第二服务逻辑建立一些用于从一个端点向另一个(位于第二服务逻辑的职权内)传输数据的机制；然后该第二服务逻辑可以处理该请求的所有低层级细节，例如选择连接协议、找到穿过该网络的路径、根据所述协议建立并维护跨越该路径的连接等等。一旦被通知这一机制的建立，第一服务逻辑可以利用该机制，同时低层级实现细节还是对其保持很大程度上不可见。

定义了规则或“合同”，其针对每对服务逻辑指定该对服务逻辑在其中应该和不应该相互直接通信的环境，针对每个服务及其相应代理指定该服务和该代理在其中应该和不应该直接相互通信的环境。合同本质上定义了每个服务在接口方面暴露什么，负责什么以及限制是什么。

建立实时音频和视频呼叫(本申请中简称为“视频呼叫”)是由递送这些业务的各自服务逻辑执行的，其通过例如呼叫控制服务逻辑的RESTful 接口接收到或发起的命令而实现。这一命令使得在云中创建该呼叫的“呼叫表示”，它包括以呼叫参数形式的“呼叫状态”以及由该呼叫控制服务逻辑在该呼叫的持续过程种存储并维护的信息。抛开该服务逻辑的失败，这是该呼叫唯一权威性的实例和状态表示；接收到的关于该特定呼叫的任何后续命令造成由呼叫控制服务逻辑在其表示上执行可能的状态修改，并且这一变化被传输给任何感兴趣的端点/参与方/订户。

作为呼叫建立和控制的一部分，需要协商并控制媒体，并且建立传输机制以允许媒体数据分组在端点之间流动。这通过呼叫控制服务逻辑调用其它控制服务逻辑(传输、管道、音频、视频)暴露出来的接口通知它们该呼叫并指示它们执行在端点之间建立该呼叫的步骤来实现。这一服务间交互的模型使得各种服务做任何必要的事情以做出相关决定，指示它们的端点代理执行动作，提供变量数据和上下文—向呼叫控制服务和任何其它有关的服务逻辑报告准备就绪。一旦各种服务已经完成并且都报告准备就绪，该呼叫控制服务逻辑更新呼叫状态并将该呼叫的更新后的状态传输给所有连接的端点(以及任何其它感兴趣的组件)，以允许连接该呼叫并且允许媒体流动。

在该呼叫期间，将由端点和代理向各个服务发送信号—用于控制呼叫参与的主要方面，这是通过呼叫控制服务逻辑进行的，但是如果服务之间的合同没有被破坏，服务代理能够独立地使用它们各自的接口根据需要与它们相应的相同的服务逻辑通话。

还应该注意的是，服务被认为拥有基于云的组件和元件以及端点服务代理(如果该服务要求的)二者。云服务也拥有端点合同(或代理)。

现在将参照图3描述根据本发明的主题的通信系统300。通信系统300 包括基于分组的通信网络(这里是计算机网络)301(例如，互联网)。连接到网络300的是与第一用户302a(“Alice”)相关联的用户设备(用户终端)304a和与第二用户302b(“Bob”)相关联的其它用户设备(用户终端) 204b。用户设备304a、304b被布置为从各自设备的用户接收信息并向其输出信息。虽然在图3中只显示了两个用户设备，但是通信系统300中可以包括更多的用户设备。用户设备304a、304b中的每一个可以是，例如移动电话(例如，智能电话)、平板电脑、笔记本电脑、个人计算机(“PC”)(包括，例如Windows^TM、Mac OS^TM和Linux^TM PC)、游戏设备、个人数字助理(“PDA”)或能够连接到该网络301的其它嵌入式设备。

同时连接到网络301的还有多个数据中心(DC)320a、320b,…,320c 和业务管理系统330，该业务管理系统是计算机系统。业务管理系统330包括一个或多个存储器设备334和一个或多个处理器，所述处理器被配置为执行业务管理代码332(业务管理器/业务管理逻辑)以便如下面更详细描述的管理数据中心业务。业务管理系统330和数据中心320构成分布式平台800的一部分。

通信系统300用于实现通过通信网络301连接的多个端点之间的通信事件(例如，AV呼叫)。该端点可以是用户设备(例如，304a、304b)和/ 或其它计算机设备/计算机系统(例如，服务器或者桥接)。通信系统300 包括多个处理单元，每个处理单元具有对保存用于管理通信事件的可执行 (应用)代码模块的计算机存储器的访问。如下面更详细讨论的，所述代码模块被配置为实现：

-呼叫控制器，其被配置为建立通信事件并管理已建立的通信事件；

-一个或多个媒体模态控制器(例如，音频控制器、视频控制器)，其被配置为管理已建立的通信事件(其包括例如在该通信事件的建立期间与端点协商媒体模态参数)的各自媒体模态(例如，音频、视频)；

-传输控制器，其被配置为管理端点之间通信事件的媒体的传输(其包括，例如在该通信事件的建立期间与端点协商传输参数，以及控制管道控制器)；以及

-管道控制器，其被配置为针对所述传输控制器的控制下的所述媒体传输在各对所述端点之间创建管道(在通信事件的建立期间)。

任何一个或多个所述控制器可以是虚拟控制器，如下面解释的。

处理单元跨多个容错区域分布，并且计算机存储器被划分到多个容错区域中。容错区域是实质上与任何其它容错区域中的组件(硬件和软件) 的故障隔离的区域。示例包括数据中心中的不同故障域(下面讨论的)、不同数据中心(数据中心定义各自的容错区域)、不同地理位置(地理位置定义各自的容错区域)。在这一实施例中，处理单元是联网服务器的处理单元。所述服务器遍布多个数据中心分布(并且遍布每个数据中心中的不同故障域)。该通信系统包括多个控制服务器，每个控制服务器被配置为控制各自组的一个或多个所述联网服务器的操作。每个控制服务器被配置为响应于从网络接收至少一个可执行代码模块，将接收到的代码模块存储在计算机存储器中，因此所述存储的代码模块是对该控制服务器控制的一个或多个服务器可访问的。响应于从网络接收到代码模块，该控制服务器被配置为在服务器上实例化虚拟机，因此该虚拟机响应于接收到的指令以在该虚拟机上实例化该代码模块。该控制服务器被配置为在一个或多个服务器上实例化多个虚拟机，因此每个虚拟机响应于接收到的指令以实例化相同的代码模块。

在这一实施例中，如下面更详细描述的，每个所述处理单元被配置为运行多个虚拟机，每个所述虚拟机具有对至少一个所述代码模块的访问，因此该代码模块的一个或多个实例运行在该虚拟机上。但是，在替代实施例中，一些或所有处理单元可以不运行虚拟机并且代码模块可以“直接”在那些处理单元上执行(例如，在“直接”运行在该处理单元上的操作系统之上)。

0.2用户设备

图4描绘了用户设备304(诸如用户设备304a和304b)的详细视图。用户设备114包括中央处理单元(“CPU”)402，连接到该CPU的有：输出设备，诸如可以实现为触摸屏的显示器404，以及用于输出音频信号的扬声器(或“扩音器”)410；输入设备，诸如用于接收音频信号的麦克风426，用于接收图像数据的相机408，以及小键盘406；用于存储数据的存储器426；以及用于与网络301通信的诸如调制解调器之类的网络接口424。用户设备 114可以包括除了图4中示出的那些之外的其它元件。显示器404、扬声器 410、麦克风412、存储器426、相机408、小键盘406和网络接口424可以整合到用户设备304中。作为替代，一个或多个显示器404、扬声器410、麦克风412、存储器426、相机408、小键盘406和网络接口424也可以不整合到该用户设备中，而是通过各自的接口连接到CPU 402。这种接口的一个示例就是USB接口。如果用户设备304通过网络接口424到网络301 的连接是无线连接，则网络接口424可以包括用于向互联网301无线地发送信号和从互联网301无线地接收信号的天线。

图4还描绘了CPU 402上执行的操作系统(“OS”)414。在OS 414之上运行的是通信系统300的通信客户端应用(客户端)的实例416，显示为软件栈。客户端416与操作系统414通信并且管理该通信系统300上的连接，包括与其它用户设备和与数据中心320的连接。客户端416有客户端用户界面(“UI”)，其用于向设备的用户呈现信息和从该用户接收信息。以此方式，客户端416执行允许用户(例如，Alice、Bob)通过该通信系统 300进行通信所需要的处理。该软件栈显示了客户端协议层418、客户端引擎层420和客户端用户界面层422。每一层负责具体功能。由于每一层通常与其它两层通信，因此它们可以被视为布置在如图4中所示的栈中。操作系统414管理设备304的硬件资源，并处理通过网络接口424向和从网络301发送的数据。该客户端软件的客户端协议层418与操作系统414通信并管理该通信系统300上的连接。要求更高层级处理的处理被传递给客户端引擎层420。客户端引擎420还与客户端用户界面层422通信。该客户端引擎420被布置为控制客户端用户界面层334通过客户端的用户界面向用户呈现信息，以及通过该用户界面从该用户接收信息。

客户端引擎层包括多个服务代理421。每个服务代理处理实时媒体通信事件(例如，呼叫)的不同方面；所述多个服务代理累积起来使用户能够通过客户端用户界面进行这一实时媒体通信事件。这将在下面更详细地进行描述。每个服务代理有相应的API(例如，C++API)，并且所述代理通过那些API相互通信。代理是定义端点如何与每个服务交互(并且有时是相互交互)的端点/客户端逻辑实现。

0.3数据中心结构

图5A是数据中心320(例如，图3中的数据中心320a、320b、320c) 的示意图。该数据中心包括多个服务器544、504a、504b、504c；网络基础设施580，其连接到网络310用于通过网络301在该数据中心320中的联网设备和该数据中心外部的设备之间交换数据分组；以及电力基础设施590，用于为该数据中心的设备供电。服务器504a、504b和服务器502c分别由电源592和电源592’(它们自身由电力基础设施590供电)供电。该数据中心还包括连接到网络基础设施580的数据中心业务管理系统588，用于接收从网络301发往该数据中心320的流入业务并将所述业务遍布服务器504a、 504b、504c分布，并且用于将来自数据中心320的一个服务器(例如，504a) 的内部业务跨该数据中心320的其它服务器(例如，504b、504c)分布。 DC业务管理系统可以包括诸如硬件负载均衡器之类的组件，以及在适当计算机系统处执行的软件或它们的组合。

服务器504a、504b、504c的每一个包括各自的处理器506a、506b、506c，它们连接到各自的用于存储数据的存储器514a、514b、514c和各自的用于与其它联网设备交换数据的网络接口584a、584b、584c。网络接口584a和 584b连接到网络开关582，它能够使服务器504a和504b通过该开关582 相互地或与连接到该开关582的任何其它服务器(未示出)直接交换数据。网络接口584c连接到网络开关582’，它能够使服务器504c通过该开关582’直接与连接到该开关582’的任何其它服务器(未示出)交换数据。开关582 连接到网络基础设施582，它也能够使服务器504a、504b和连接到开关582 的任何其它服务器(未示出)与连接到该网络基础设施的其它设备(例如，通过诸如开关582’之类的其它开关连接的设备)以及与连接到网络301的其它设备交换数据。开关582’类似地连接使得服务器504c能够参与类似的数据交换。

服务器544是该数据中心的控制服务器：它负责控制和监测该数据中心中的其它服务器。控制服务器544由电源595供电，而该电源自身由电力基础设施590供电。控制服务器544包括处理器546，其连接到用于存储数据的存储器554和用于与其它联网设备交换数据的网络接口586。网络接口586连接到网络基础设施580，它能够使控制服务器544与连接到该网络基础设施的其它设备(包括服务器504a、504b、504c)以及与连接到网络 301的其它设备(例如，图3中的304a、304b)交换数据。

服务器504a、504b、504c被分组到各自的“故障域”502、502’中，故障域是一组共享公共故障点的服务器(也就是，针对操作依赖于相同物理电子组件的服务器，其故障因此抑制所有那些服务器的操作)。例如，服务器 504a和504b通过网络开关582连接到网络基础设施580，该网络开关对服务器508a、508b二者是公用的；这一开关582的故障会造成服务器504a、 504b的每一个以及连接到该开关的任何其它服务器的故障，因为所有这些服务器都会从网络基础设施580断开连接并且在那种情况下继而从网络301 断开连接。因此可以说网络开关582将故障域定义为连接到该开关582的所有服务器的分组。类似地，服务器504a和504b二者都由电源592供电，而该电源自身由电力基础设施509供电；这一电源592的故障会造成服务器504a、504b的每一个和该电源592供电的任何其它服务器的故障。因此可以说电源592将故障域定义为该电源592供电的所有服务器的分组。在图5A中，示出的连接到开关582的每个服务器也显示为由电源592供电，因此图5A的开关582和电源592定义了公共故障域502；一般来讲，相同电源供电的服务器可以连接到不同网络开关，反之亦然。类似地，图5A示出了由网络开关582’和电源592’二者特征化的第二故障域502’。故障域502’的服务器504c显示为连接到开关582’和电源592’。数据中心320包括同时在故障域502、502’中和由额外的网络开关、电源和其它物理组件(未示出) 特征化的其它故障域中的额外的服务器(可能有几千个)。

图5B示出了控制服务器546和服务器504(例如，504a、504b、504c) 的示意图。控制服务器546的处理器执行操作系统(OS)550。该操作系统 550管理控制服务器544的硬件资源并处理通过网络接口586发送的数据。运行在OS 550之上的是采用数据中心控制软件(代码)形式的数据中心管理器块552。数据中心管理器552与操作系统550通信并管理与该数据中心的其它服务器和与连接到网络301的其它设备的连接。数据中心管理器包括数据中心控制和监测块(DC控制块)556，资源报告块558和外部控制块559。该DC控制块556负责监测该数据中心中的其它服务器(例如，504) 的资源利用并且控制所述服务器的操作。DC控制块将通过这一监测获取的信息提供给资源报告块558。资源报告块558负责通过网络301报告遍及 DC的资源使用情况(即，关于该数据中心的物理资源的整个使用情况的信息)。外部控制块559被配置为从网络301接收配置信息并将该信息传输给 DC控制块556。作为响应，DC控制块556被配置为依此控制数据中心320 的操作。

服务器504的处理器506执行超管理器512。在本上下文中，超管理器是创建、运行并管理虚拟机(通常多于一个)的一片计算机软件。在本上下文中，“虚拟机”(VM)是具有第一计算机架构的第一计算机系统的软件实现(或“模拟”)，其运行在具有不同于该第一计算机架构的第二计算机架构的第二计算机系统上。换句话说，VM具有它自己的计算机架构，其可以非常不同于该VM最终运行在其上的任何底层物理计算机系统(例如，服务器504)的计算机架构。超管理器运行多个VM时，每个VM可以具有不同于其它VM的各自的计算机结构。VM通常支持代码在其上的执行(例如，应用或可以在其上执行应用的操作系统的执行)。VM可以被设计为模拟现有类型的“现实”计算机系统(也就是，VM可以具有存在直接硬件实现方案的虚拟计算机架构)，或者它可以被设计为模拟“假设的”计算机系统(也就是，VM可以具有不存在直接硬件实现方案的计算机架构)。

例如，虚拟机可以包括具有特定指令集架构的模拟处理器；要在该虚拟机上执行的代码首先被编译到低层级机器代码指令的序列中，这些指令是根据该模拟处理器的指令集架构的(即，具有由其指定的操作码和操作对象)。但是，这些机器代码指令并不在物理处理器本身上执行；而是由超管理器执行进一步的指令翻译，最终得到要在该超管理器(以及因此的模拟处理器)在其上执行的底层物理计算机系统的一个或多个物理处理器(例如，处理器506)上执行的低层级机器代码指令，那些指令是根据讨论中的该物理处理器(与模拟处理器正相对)的指令集结构的(即，具有由其指定的操作码和操作对象)。针对更小尺寸的VM，VM可以共享物理处理器；针对更大的VM，这些应该是专用的。

超管理器512被配置为运行一个根(父)VM 508和一个或多个客人(子) VM 510。该根VM执行操作系统520，并且每个客人VM 510i、512i执行各自的操作系统520i、520ii。适当操作系统的一个示例是Windows服务器 2012^TM。在根OS 520之上执行代码形式的主控制块522，其被配置为(除了别的之外)能够创建并终止客人VM 510并通过调用该超管理器的适当应用编程接口(API)(未示出)在其上发起OS 510的启动。在每个客人OS 510i、 510ii之上执行各自的代码形式的客人控制块532i、532ii，以及使得其各自 VM 510i、510ii执行多于或超出该VM自身的运行的有用任务的各自应用代码534i、534ii(例如，软件开发者的订制代码)。每个客人控制块532被配置为(除了别的之外)能够促使应用代码模块的执行(即，实例化该应用代码模块以创建其实例)并且终止该VM上的应用代码模块的执行(即，退役那些应用代码实例)。每个OS 520被配置为在该OS 520启动时自动发起相应客人控制块532的执行。客人VM可以替代地或另外地被配置为数据访问单元(未示出)—见上文。至少一些应用代码模块用于管理一个或多个通信事件(例如，呼叫)。

控制服务器544的DC控制块和根VM 508的根控制块能够经由图5B 中虚线指示的网络基础设施580相互通信，例如通过适当API的使用。由根VM进行的客人VM的创建和终止是在控制服务器544的DC控制块556 的命令下进行。DC控制块556还可以向根控制块522指示应该在该虚拟机的子VM上要执行什么应用块，例如通过提供该代码的标识符或可以用于例如从网络301下载代码的地址。VM 510可以运行一个或多个应用代码模块的一个或多个实例。

如本文中所指出的，配置信息经由网络301被上传到数据中心320；这一配置信息由外部控制块559接收到。每一片控制信息与在子VM 520上执行的代码有关和/或与该应用代码要在其上执行的该子VM 520(即，一个或多个应用代码模块要在其上实例化)的一个或多个期望属性有关。

根控制块508能够与每个客人控制块532通信并且反之亦然，例如经由超管理器530—再次在图5B中用虚线示出。一旦已经由根控制块508在 DC控制块556的命令下创建了客人VM 510，该根控制块指令客人控制代码发起应用代码的执行，例如响应于从根控制块522接收应用代码534的地址或标识符(如DC控制块556从配置信息所提供的)，客人控制块532 使用该标识符或地址下载该应用代码534以便在OS 530上执行。

例如，应用代码可以由软件开发者或系统设计者上传到适当网络位置，并且该位置被作为配置信息传输到控制服务器544的外部控制块559。然后，该外部控制块559将该位置传输给DC控制块556，作为响应，DC控制块 556指令根控制块552在与根VM相同的服务器506上创建新的客人VM，并且将该代码下载到该新创建的VM上，或者将该代码下载到该服务器上的现有客人VM。

这些配置信息还可以包括指定应用代码要在其上执行的子VM的属性的信息。例如，该配置信息可以指定子VM应该是“内部可见的”(也就是，被配置为使得分布式平台800的其它VM能够经由网络301或经由DC网络基础设施580与该VM建立逻辑连接)和/或“外部可见的”(也就是，被配置为使得例如连接到网络301的304a、304b之类的设备能够经由网络301 与VM建立逻辑连接)。例如，该配置信息还可以指定一个或多个物理计算机资源各自要被分配给子VM 510的部分(诸如量为例如兆字节、千兆字节等的存储器和量为例如兆赫兹、千兆赫兹等的处理资源)，该代码要在该子 VM上执行。

经由网络310上传到数据中心320的配置信息被存储在控制服务器544 的存储器554中，并且这一存储的配置信息是DC控制块556可访问的，并且(至少部分)对每个根VM和每个客人VM都是可访问的。

只有根VM具有对服务器506的底层物理计算机资源(例如，处理器、存储器)的直接访问；其它客人VM经由超管理器或经由总线(也就是，逻辑VM间通信信道)通过根VM访问这些信息。根VM 522和超管理器 512共同地被配置为管理对这些底层物理资源的访问并共同地动作以将这些物理资源的各个预定部分分配给每个客人VM，所述预定部分实质上独立于其它客人VM，即其它客人VM的任何行为或修改不会增加或减少该客人VM可使用的物理资源的部分。因此，每个客人VM(例如，510i)提供资源有限的运行时环境，其实质上与同一个处理器506上运行的任何其它客人VM(例如，510ii)分离开。

客人VM 510不经由超管理器512直接相互通信，并且如上所讨论的对彼此的可用物理资源有最小的影响(由超管理器的虚拟化提供这一实质上的独立性)。在这些方面，VM无视彼此的存在。也就是说，客人VM还是能被配置为经由网络基础设施580相互通信，在DC内(数据中心320中) 和通过网络301二者都可以。

如图5B中所示，DC控制块556还负责控制DC业务管理系统588以便在数据中心中管理针对从网络301接收到的数据和经由网络基础设施580 交换的内部数据二者的业务流。

每个子VM 510上的子控制代码532有两个功能(除了别的之外)：首先，它向其对应的根VM发送周期性心跳；其次，它监测该VM上执行的应用代码532。如果发生应用代码故障，则该子控制代码尝试使用存储的配置信息重新启动该应用代码。如果它无法这样做，它将这一故障传输给对应的根控制代码522。此外，如果发生该子VM的故障，则来自子控制代码532的心跳将会停止。响应于这些事件之一，根控制532终止子VM 510，然后使用如上所述的存储的配置信息重新创建它(所述重新创建的VM因此加载并执行与被终止的VM相同的应用代码)。

类似地，根控制代码522向DC控制块556发送周期性心跳。如果这些心跳停止，例如由于物理服务器504的硬件故障(例如，电源故障、网络故障等等)或由于根控制代码、超管理器等的软件故障，该DC控制块 566假设该服务器上运行的所有子VM都发生故障。作为响应，其使用存储的配置信息在具有足够可用物理资源的数据中心的一个或多个运行的服务器上重新创建那些VM(如上所述)，并且控制DC业务管理系统588相应地将业务发送给所述重新创建的VM。

该分布式平台800(包括多个这种数据中心320a、320b、320c等)可以因此适合于运行多个服务逻辑，每个服务逻辑由执行各自应用代码534 的一个或多个客人虚拟机510实现。这些虚拟机可以遍布单个数据中心320 分布和/或使用经由网络301(例如，互联网)传输的数据中心之间业务跨多个数据中心分布。

0.4服务逻辑的分层结构

在下面描述的实施例中，控制服务逻辑(或者通篇中称为“控制器”)(由运行在分布式平台上的虚拟机上执行的应用代码实现)被配置为递送各自服务以支持(也就是，管理其至少一个方面)实时媒体通信事件。被配置为实现服务逻辑的代码模块以如上所描述的方式在虚拟机510上实例化。不同类型的服务逻辑被配置为递送不同控制服务(不同服务是，例如呼叫控制、音频控制、视频控制、传输控制、管道控制)，同时相同类型的服务逻辑被配置为递送相同的服务(例如，呼叫控制、音频控制、视频控制、传输控制、管道控制中的一个)。

每个类型的服务之一通常在实时媒体通信事件期间的任何给定时间将控制该事件的相应方面。一旦创建通信事件，从每个类型的多个可能服务逻辑中选择该类型的服务逻辑以支持该通信事件(例如，呼叫)。这一选择是在业务管理系统330中响应于从客户端一侧该类型服务代理(612，图4) 或从另一类型的另一个服务逻辑对该类型服务的请求所做出的。

响应于针对该类型服务的这一请求，相同类型的服务逻辑的每一个能够递送相同的服务并且是可互换地可选择的(然而不同类型的服务逻辑不是可互换地可选择的)。例如，第一类型的每个服务逻辑可以响应于来自向其发送的可能的请求消息的第一集合中的任何请求消息，并且第二类型的每个服务逻辑可以响应于来自向其发送的可能的请求消息的第二集合中的任何请求消息，该第一和第二集合是不相交的或部分的。然后，这些服务逻辑的每一个在该呼叫的持续时间内或直到该服务逻辑发生故障之前控制 (即，为其提供控制服务)该呼叫(如下讨论的)。

通信系统300响应于由启动程序以请求消息(例如，REST呼叫)的形式向服务逻辑发起(例如，通过相同类型的代理或通过不同类型的业务代理)并通过网络301发送的指令。具体来讲，通信系统300根据该指令(即，处理该指令)做出响应，指派该服务逻辑(如上所述实例化的)的实例(在 VM 510上)执行与特定通信事件有关的操作。在这一实施例中，如下面更详细解释说明的，通过与特定服务逻辑相关联的负载均衡器做出指派。

响应于该实例向接收到的指令返回响应(该响应被返回给启动程序)，可以从该指派释放所述指派的实例。这一指令(请求)/响应交换被称为事务。本申请中“释放”意为被分配给指派的实例以便使其能够完成该事务的所有物理资源(处理资源、存储器资源)被从其收回(例如，变得对其它这种事务可用)。在这一实施例中，那些物理资源是该VM在其上运行的虚拟机的物理资源。实例一旦被如此释放则不再被要求在单独分配给其运行在的VM的存储器资源中维护关于该事务的任何信息(如下所解释的，即使关于该事务的信息被存储在别的地方)，这样该VM一旦被如此释放就“忘记”该事务。该实例可以被配置为这样被释放(即，所述释放被构建到该应用代码中)，或者该实例可以通过该通信系统的释放逻辑被“强制”释放(例如，被重新指派或被退役)。

该服务逻辑的实例是针对每个这种指令独立指派的实例(例如，针对特定服务逻辑的多个实例、以轮询方式或基于每个实例的可用资源)，并且通信系统300响应于这样的进一步指令以便独立地指派该服务逻辑的该实例或另一个实例来处理该进一步指令(响应于该服务逻辑实例返回对所述进一步指令的响应，从该指派释放该服务逻辑实例)。

在这一实施例中，每个虚拟机510具有对呼叫控制器代码模块、媒体模态控制器代码模块(音频或视频之一，或二者)、传输控制器代码模块和管道控制器代码模块中的最多一个的访问，这样所述呼叫控制器、媒体模态控制器(音频或视频之一，或二者)、传输控制器或管道控制只有一个运行在该虚拟机上。如上所讨论的，每个所述处理单元被配置为执行超管理器，该处理单元的虚拟机运行在该超管理器之上。

每个服务逻辑具有分层结构，现在将参考图6A和6B描述。如图6A 中所示，分布式平台800适合于至少运行第一类型的第一服务逻辑622[1] 的第一分组602[1](也就是能够递送第一服务)，和第二类型的第二服务逻辑622[2]的分组602[2](也就是能够递送第二服务)。相同类型的服务逻辑独立工作，因为一个服务逻辑的服务的成功递送确实要求该相同类型的其它服务逻辑中的任何一个都正确工作。虽然有相互依赖性，但是在针对一些层级的功能的解耦的/单独的服务中也具有自主性—例如，一旦建立该初始呼叫，并且正在递送模态，则有元件完全处于该模态业务的控制和范围之中，它们能够在完全无需涉及其它服务的情况下被执行。

用户设备304的客户端416包括每个类型的服务的服务代理612[1](第一类型)、612[2](第二类型)。服务代理612[1]能够与第一类型服务逻辑 622[1]的每一个直接通信，并且服务代理612[2]能够与第二类型服务逻辑 622[2]的每一个直接通信；特定类型的服务逻辑只与该相同类型的服务代理直接通信，并且不与其它类型的服务代理直接通信。但是，不同类型的服务逻辑能够直接相互通信。每个服务代理612和每个服务逻辑622能够与业务管理系统130通信。服务逻辑间通信以及服务逻辑和它们各自的代理之间的通信在一定程度上由业务管理系统330中介。下面将更详细地讨论。

如图6B中所示，递送特定服务的服务逻辑包括一个或多个互相依赖的组件642、652，它们串联工作以递送该服务。一般来讲，服务逻辑的单个组件(例如，642、652中的一个)的故障造成该服务逻辑的故障。在这一实施例中，每个服务逻辑实现在各自单独的数据中心处(例如320a、320b、 320c中的一个)，并且每个任何给定类型的服务逻辑被实现在不同数据中心处(即，这样没有两个相同类型的服务逻辑(例如，视频服务逻辑)被实现在同一个数据中心处)。在替代实施例中，服务逻辑的组件可以遍布多个数据中心分布和/或相同类型的多个服务逻辑可以运行在同一个数据中心处。此外，在图6A中，每个数据中心实现每个类型的服务逻辑中的一个，但这不是必要的，并且一些数据中心可以实现一些类型的服务逻辑而不实现其它的(例如，只实现音频控制服务逻辑而不实现视频控制服务逻辑)。

服务逻辑的每个组件包括负载均衡器648、658和执行各自应用代码的实例535的一个或多个客人虚拟机510，其中负载均衡器被如上参考图5B 所描述的被配置为响应于接收到的指令(请求消息)指派实例。该应用代码响应于在该VM处接收到的请求消息，例如从用户设备(例如，304a、 304b)和不同数据中心处的其它服务逻辑等接收到的“外部”请求，或者从该服务逻辑的其它组件接收到的“内部”请求。特定组件的每个VM运行在相同的数据中心处，并且该组件的负载均衡器构成该数据中心的数据中心业务管理系统558的一部分。该特定组件中的VM基于相同配置信息被配置为具有相同的属性，并且每一个VM运行相同应用代码的一个或多个各自的实例(其提供那些VM中的一个或一些如果发生故障时的冗余)。组件的负载均衡器可操作用于接收请求并将那些请求送往该组件的任何一个VM，例如以轮询的方式或基于监测到的那些VM的资源可用性(例如，将输入的请求送往具有最多可用资源的VM)。组件的负载均衡器假设该组件的每个VM等效地被配置为能够处理该负载均衡器接收到的任何请求。

组件的示例包括在Windows Azure(TM)平台上实现的网络和工作者角色。

图6B示出了服务逻辑642，其包括至少两个具有各自负载均衡器648、 658的组件642和652。组件642包括至少两个VM 510A、510B，其基于相同的配置信息被配置为具有一致的属性。VM 510A执行应用代码的实例 534A，而VM 510B执行相同的(或者至少副本)应用代码的实例534B。类似地，组件652包括至少两个VM 510A’、510B’，其基于相同的配置信息被配置为具有相似的属性。VM 510A’执行应用代码的实例534A’，而VM 510B’执行相同的(或者至少副本)应用代码的实例534B’。

组件可以被实现为包含无状态VM的无状态组件。这取决于该组件和服务是如何设计和编写的。无状态VM是运行不依赖在先前请求的处理期间已经存储在该VM处(即，存储在独立分配给该VM的物理存储器资源中)的任何信息而服务于其接收的任何请求的应用代码实例的VM。也就是，无状态VM将每个请求作为独立的事务对待并且不记录它已经在其被独立分配的存储器资源上执行过的先前事务(虽然它可以取回，并且可能修改存储在别的地方的信息，例如由该请求(例如其识别该特定呼叫)定义的特定呼叫的呼叫状态)。

针对无状态组件的任何请求可以因此被送往该组件的负载均衡器(因为该组件中的哪个无状态VM实际来服务该请求是无所谓的)。这提供了冗余，因为如果组件中的一个VM(或者其应用代码)发生故障，该组件中的其它VM能够在纠正该故障的同时无缝地接管工作。

尽管如此，无状态VM可以被配置为访问分布式平台的物理存储资源 (例如，物理存储器的一块区域)，它是由该平台整个地分配给该组件的而不是分配给它们运行在的分布式平台800中的具体的各个VM的(例如，内存存储，诸如由易失性存储器在物理层面处实现的缓存层)，该组件中的每个VM被配置为访问相同的存储器区域。作为服务请求的一部分，VM 可以从这一存储器读取和向其写入，并且这一存储器的内容可以影响如何服务该请求。但是，该VM还是无状态的，因为它不依赖于它自己的各个存储器资源，而是依赖于该组件的所有VM都可访问的存储器资源。

通信系统的代码模块可以被配置为实现数据访问软件，借此服务逻辑 (控制器)实例可通过该数据访问软件的实例访问计算机存储器。

一个虚拟机上的控制器实例可以通过另一个虚拟机上的数据访问软件实例访问计算机存储器。服务逻辑的组件可以被配置为专用内存访问组件，该组件的VM被配置为访问这些共享存储器资源(并且如上所讨论的，它们本身可以是无状态的)并且执行可操作用于只服务来自该服务逻辑的其它组件的读/写请求的应用代码(即，这样它们只代表该服务逻辑的其它组件处理存储器访问)。一个示例是Azure(TM)平台上的专用缓存工作者角色。

作为替代或者另外，虚拟机上的控制器实例通过该相同虚拟机上的数据访问软件实例访问计算机存储器。组件的VM可以被配置为访问这些共享存储器资源并且还执行应用代码，该共享存储器资源(例如，内存缓存) 不是针对专用组件部署的而是以分布式方式部署到其它组件上的。一个示例是Azure(TM)平台上的角色内缓存。

作为替代，组件可以被实现为有状态的，该组件的VM被配置为有状态VM，其依赖于关于使用它们自己的各自的各个存储器资源存储的过去的事务的信息以便成功地服务未来的请求。这些请求绕过该组件的均衡负载器被专门送往该VM(因为该组件的其它VM应该无法服务那些请求)。有状态组件可以用于服务时间严格的请求(因为一般来讲VM访问它自己的各个存储器资源要比访问共享的、组件范围的存储器资源更快)。但是，相比于无状态组件，有状态组件中的VM的故障可能导致该组件无法服务本来应该由该发生故障的VM服务的后续的请求。

服务逻辑的组件可以被配置为暴露一个或多个外部可用的、可寻址的接口624(例如，RESTful)和/或一个或多个内部可用、可寻址的接口652 (例如，RESTful)，它们可以被利用(即，调用)以便建立用于与该组件交换数据的逻辑连接。内部接口624只对相同服务逻辑的其它组件可见(并且可由其利用)，而外部接口对相应的客户端一侧服务代理612和/或其它服务逻辑可见并且由其利用。组件的接口有效地耦接到该组件的负载均衡器，因为使用该接口发往该组件的任何请求由该负载均衡器接收以便转发给该组件的VM(这一转发在该组件外部不可见)。

图6B示出了组件642暴露外部接口624(其有效地耦接到该组件的负载均衡器648)，并且组件652暴露内部接口656(其有效地耦接到该组件的负载均衡器658)。

DC控制块556以如上参考图5A和5B所讨论的方式控制组件的VM 和负载均衡器(它们是DC业务管理系统558的一部分)。数据中心320的资源报告块558可操作用于从每个服务逻辑接收资源利用信息，并且将关于该数据中心中资源使用的信息传输给业务管理器332(这一信息是块558 所报告的关于该服务逻辑运行在的数据中心处的物理计算机资源的使用和可用性的整体信息的一部分)。该业务管理器332可操作用于从多个数据中心(例如，320a、320b、320c)接收这一信息。

如上所讨论的，响应于针对特定类型的服务的各自请求(来自该类型的客户端一侧代理(因为一个类型的服务代理只向该相同类型的服务逻辑而不会向不同类型的服务逻辑发送请求)或来自另一个不同类型的服务逻辑)，从各自可能的分组602[1]、602[2]选择那些类型的相应服务逻辑622[1]、 622[2]以便递送那些各自的服务。这一选择是由业务管理器132响应于这些请求而做出的—这现在将参考图7A、7B和7C描述，它们描绘了用于请求特定类型的服务的示例性处理。图7A和7B是描绘了所述处理的流程图，而图7C示意性的描绘了该处理的示例性数据交换。

在步骤S702处，特定类型的服务的请求者700(例如，该服务类型的客户端一侧代理或另一个服务类型的服务逻辑)发送针对能够向业务管理系统330递送该特定类型的服务的服务逻辑的地址的请求(指令)。例如，在实施例中，业务管理系统330与特定域名(例如，tm.net)相关联，并且针对服务的每个类型(例如，服务“m”的每个类型)定义该服务的类型的子域名(例如，service-m.provider.tm.net)。然后，每个子域名与和该服务的供应商(例如，通信系统300的运营商)相关联的域名(例如，provider.net) 的相应子域名(例如，service_m.provider.net)相关联。这一关联性是使用规范名称(CNAME)DNS(“域名系统”)记录720生效的，它使得供应商子域名(例如，service_m.provider.net)能够用于在该业务管理系统中获取能够向其请求针对该类型的服务的请求的地址，该地址与该类型的服务的业务管理策略724相关联。CNAME记录是本领域内公知的。

该类型的服务(例如，“服务1”，可以是，例如呼叫控制服务、音频控制服务、视频控制服务、业务控制服务、管道控制服务等)的业务管理策略722被存储在业务管理系统330的存储器334中。这一策略识别能够递送该类型的服务的多个服务逻辑(图7C中的622a、622b、622c)，例如如该通信系统300的运营商所指定的。业务管理器132可操作用于根据从每个数据中心资源报告块558a、558b、558c等接收到的资源利用信息选择那些服务逻辑622a、622b、622c中的一个。一旦选定，业务管理器132向请求者750返回响应(S706)，该响应包括所选择的服务部署(例如，图7C 中的622a)的地址。该地址是该服务逻辑622a的组件642a暴露的外部接口624a的地址，其耦接到该组件622a的负载均衡器648a。响应于接收到这一响应消息，请求者750向该地址发送请求(S708)，该请求由负载均衡器648a接收到。这里，组件642a是无状态组件，包括能够服务于该请求的多个无状态虚拟机510a-A、510a-B，并且响应于接收到该请求，负载均衡器648a然后选择那些虚拟机之一510a-B并将该请求转发给它。VM 510a-B 执行各种操作作为响应。例如，在这一示例中，服务逻辑622a包括另一个组件652a(它本身包括耦接到暴露的内部接口656a的负载均衡器658a)以及多个虚拟机510a-A’、510a-B’。由VM 510a-B所执行的所述操作可以包括向所述内部接口656a发送一个或多个内部请求。响应于其，负载均衡器 658a选择组件652a的虚拟机510a-B’并将该请求转发给该VM。该VM 510a-B’执行各种操作作为对此的响应，然后一旦完成其则向VM 510a-B返回响应(S716)。作为响应，组件642a的VM 510a-B执行额外的操作，包括向请求者700的原始请求返回响应(S718)。作为替代，VM 510a-B可以服务来自请求者750的原始请求，而无需向服务逻辑622a的其它组件发送任何其它请求。

1.中央智能化云呼叫建立、控制和媒体协商(CICCSCMN)

上面通过举例说明的方式提供了对服务代理与相应的相同类型的服务逻辑通信以及服务逻辑与其它类型的服务逻辑通信的机制的概述，以便解释说明其基本原理。

现在将描述实施例，其中，服务代理和服务逻辑采用(除了别的之外) 这种机制以支持实时媒体通信事件(例如，呼叫)，从而允许用户(例如， 302a、302b)相互通信。

在这一实施例中，如图9中所示，分布式平台适于运行下面类型的云控制服务逻辑(控制器)中的多个，每个服务逻辑由各自的以上述方式在分布式平台800的虚拟机上执行的代码实现：用于递送呼叫控制服务的呼叫控制服务逻辑904(呼叫控制器)；用于递送音频媒体控制服务的音频媒体控制服务逻辑906(音频控制器)；用于递送视频媒体控制服务的视频媒体控制服务逻辑908(视频控制器)；用于递送传输控制服务的传输控制服务逻辑910(传输控制器)；以及用于递送管道控制服务的管道控制服务逻辑912(管道控制器)。该音频和视频控制服务是不同媒体模态控制服务的各自示例(音频是一种类型的媒体模态，视频是另一种类型的媒体模态)。每一个被配置为暴露各自的外部接口905、907、909、911、913。分布式平台还适于实现注册和导出请求逻辑914。

该呼叫控制服务提供对该呼叫最高级别的控制，除了该呼叫控制服务之外的控制服务提供较低级别的控制功能以支持该呼叫(每个功能很大程度上独立地同时根本上，虽然有时间接地，由呼叫控制器作为呼叫控制服务的一部分控制)。这些包括一个或多个“模态服务”，“模态”是通信传送的模式—诸如音频或视频。

这些云逻辑构成用于控制呼叫的云呼叫控制系统900的一部分，那些相同类型的其它控制器(图9中未示出)也构成该系统900的一部分。

这些各个逻辑和通信客户端416(运行在，例如用户设备304a、304b 处)构成通信系统300的一部分。

控制器控制它们的服务并且暴露针对其它服务的到呼叫的接口—以及到它们各自代理的接口。

1.1服务代理

用户设备304的客户端416包括多个不同类型的代理(对应于每个类型的控制器)，也就是呼叫控制代理924、音频媒体代理926(音频代理)、视频媒体代理928(视频代理)、传输代理930和管道代理332。客户端416 还包括注册和导入请求块934，它能够通过网络301与该注册和导出请求逻辑914通信，并且可操作用于向其注册该客户端416的地址(例如，包括客户端被执行在的用户设备304的互联网协议(IP)地址)。发送给该地址的任何请求由块943接收并转发给目标代理接收方，从而使该注册和导出请求逻辑向该客户端的各个代理发送请求消息(从各个服务逻辑中的一个接收到的)。这使得每个类型的控制器能够与该类型的相应代理建立用于传输相应的控制数据的连接(例如，使呼叫控制器能够与该呼叫代理建立用于传输呼叫控制数据的连接，使音频控制器能够与该音频代理建立用于传输音频控制数据的连接，使视频控制器能够与该视频代理建立用于传输视频控制数据的连接，使传输控制器能够与该传输代理建立用于传输传输控制数据的连接，使管道代理能够与该管道代理建立用于传输管道控制数据的连接)。

服务到端点消息传递是通过推送类型的服务到端点消息信道的方式，这意味着它不要求客户端请求能够递送服务消息(或响应)。如果服务需要向一个端点发送消息或命令，它通过适当的推送信道“随意”地这样做。

更具体地，客户端416具有登录/注册设备，它将用户设备304与特定的各自用户(例如，Alice、Bob)关联起来。作为登录程序的一部分，该用户的用户名被与执行该客户端的设备的地址相关联地存储起来，用户在该客户端处通过通信系统300的注册和导出请求逻辑914登录。用户可以有运行在与相同的登录/注册细节相关联的其它设备上的通信客户端实例。在具有特定用户名的相同用户能够同时登录到不同设备上的相同客户端应用的多个实例的情况中，逻辑914被布置为将该用户名(用户ID)映射到全部那些多个实例，但是也将分别的子标识符(子ID)映射到每个特定个体实例。因此，通信系统300能够区分不同实例同时还保持用户在该通信系统中的一致性身份。Alice 302a和Bob 302b二者都在它们各自的图3的用户设备304a、304b处登录。

公共客户端(例如，416)的代理(例如，924、926、928、930、932) 能够使用那些代理的API(如上所讨论的)相互传输数据(包括各种类型的控制数据以及该呼叫的实时媒体数据)。

公共客户端的代理相互提供数据，例如通过适当API(例如，C++API) 的使用。呼叫代理924能够向音频代理926、视频代理928和传输代理929 中的每一个提供数据。音频代理926和视频代理928二者都能够向传输代理930提供数据。该传输代理930能够向管道代理332提供数据。管道代理332能够向传输代理930提供数据。这些数据被提供到的代理可以，例如执行操作和/或向提供者返回进一步的数据作为响应。这一般被看作最优化的而不是最纯粹的设计模式的机制。根据最纯粹的设计模式，代理生成的命令/请求可以被发送给该代理的各自服务(而最优化的设计模式使用代理间接口来替代)。

用于控制呼叫的所有用户输入被传输给呼叫被传输给呼叫代理924用于初始处理(其可以作为响应使其它代理或呼叫控制器以如上所讨论的方式执行进一步的处理)。除了与支持该呼叫的呼叫控制器传输呼叫控制数据外，该呼叫代理从客户端416的客户端用户界面接收控制信号并向其输出呼叫信息(诸如关于当前参与者及它们各自的状态的信息)。

该代理帮助建立用于要发送的分组的适当的“管道”。底层媒体库(就是使用编解码器的语音引擎、视频引擎等)进行实际的媒体数据捕捉(例如，从相机和麦克风)并将所述分组发送给正确的套接字。

1.2云控制器

呼叫控制器提供对呼叫的高级别控制并且以该呼叫的呼叫状态的形式维护关于该呼叫的信息。它与参与该呼叫的相应呼叫代理交互。该呼叫控制器提供该呼叫的实时媒体流的上下文并且最终监督其它服务逻辑的低级别控制(例如，音频控制、视频控制、传输控制、管道控制等等)，确保它们正确地串联工作以支持该呼叫。

呼叫状态的本地版本是由该呼叫的每个端点维护的。响应于来自该呼叫控制器的呼叫状态更新，该端点的呼叫代理相应地更新该设备上存储的呼叫状态的本地版本。呼叫代理并不以它们自己的意志更新该呼叫状态(也就是，只有响应于通过网络来自该呼叫控制器的更新才更新该呼叫状态的本地版本，而不是直接响应于发送请求或接收对这一请求的响应的端点)，并且该呼叫状态的本地版本不是权威的；只有存储在云端的呼叫状态是权威的(这是相应通信事件的“主”呼叫状态)。

呼叫控制器904向相应的呼叫控制代理924(并且向参与该呼叫的该类型的任何其它代理)递送呼叫控制服务。音频控制器906向相应的音频代理926(并且向参与该呼叫的该类型的任何其它代理)递送音频控制服务。视频控制器908向相应的视频代理928(并且向参与该呼叫的该类型的任何其它代理)递送视频控制服务。传输控制器向相应的传输代理930(并且向参与该呼叫的该类型的任何其它代理)递送相应的传输控制服务。管道控制代理向相应的管道代理332(并且向参与该呼叫的该类型的任何其它代理)递送管道控制服务。

每个控制器(控制服务逻辑)是运行在该云平台800上的多个这种控制器(控制服务逻辑)中的一个(所述多个控制器中的每一个在这一实施例中运行在不同数据中心处，它们可以有不同的地理位置)，例如呼叫控制器是多个呼叫控制器(那些呼叫控制器中的每一个运行在相互不同的数据中心处)中的一个，该音频控制器是多个音频控制器(那些音频控制器中的每一个运行在相互不同的数据中心处)中的一个，该视频控制器是多个视频控制器(那些视频控制器中的每一个运行在相互不同的数据中心处) 中的一个，该传输控制器是多个传输控制器(那些传输控制器中的每一个运行在相互不同的数据中心处)中的一个，并且该管道控制器是多个管道控制器(那些管道控制器中的每一个运行在相互不同的数据中心处)中的一个。

音频和视频控制器提供对呼叫的音频和视频方面的分别控制，并且控制(除了别的之外)音频(或视频)编解码器选择、音频(或视频)特定变量管理、通过与参与该呼叫的相应音频(或视频)代理的交互的端点音频(或视频)控制。该音频和视频控制器是不同的媒体模态控制器。

传输控制器和管道控制器共同控制呼叫的媒体(例如，音频/视频)数据如何在该呼叫的端点之间传送。除了别的之外，它们合作创建“管道”形式的传输机制，它能够用于在参与者之间传输呼叫的实时媒体数据，传输控制器监督其较高层级的方面(诸如网络拓扑)并且管道控制器实现较低层级细节，并在该传输代理的控制之下最终创建该管道。

呼叫控制器904、音频控制器906、视频控制器908、传输控制器910 和管道控制912中的每一个是分别运行在分布式平台800上的该相同类型的(并且能够递送该相同服务)多个服务逻辑中的一个。每个代理924、926、 928、930、932可以用如上所讨论的并且在下面的上下文中描述的方式从业务管理器332请求相应服务逻辑(分别是904、906、908、910和912)的地址。

呼叫控制器能够建立用于通过音频控制器906、视频控制器908(媒体控制器)和传输控制器910各自的外部接口907、909、911与它们的每一个传输控制数据的连接。该传输控制器能够建立用于通过呼叫控制器904、音频控制器906、视频控制器908和管道控制器912各自的外部接口950、 907、909、913与它们的每一个传输数据的连接。管道控制器912能够建立用于通过传输控制器911的外部接口911与之传输数据的连接。一般来讲，只有传输控制器直接与管道控制器交互(其它服务可以通过呼叫控制器与管道控制器间接交互)。

一个类型(呼叫、音频、视频、传输、管道)的控制器只访问该相同类型的端点代理而不会访问(即，不会与之建立连接或从其直接接收指令) 不同类型的代理。

服务间通信的本质一般以呼叫控制器开始，并且该呼叫控制器提供到其它服务的链接和返回它自己的链接(有必要的话)。但是，这并不排除其它流程。

控制器904、906、908、910和912的每一个能够建立用于与注册和导出请求逻辑914传输数据的连接，借此它们能够如下所描述的向它们各自对应的代理传输相关控制数据。

如上所讨论的，注册和导出请求逻辑914能够建立用于使用客户端416 的注册和导入请求块注册的地址与该块传输数据的连接，借此从控制器 904、906、908、910和912的每一个接收到的数据能够被转发给目标代理 (分别是824、926、928、930和332)。该注册和导入请求块934被配置为从分布式平台800的注册和导出请求逻辑914接收那些数据，并将那些数据送往目标的客户端一侧代理(924、926、928、930、332中的一个)。

特定类型的代理能够建立用于通过该类型的控制器的外部接口(例如， RESTful接口)与该控制器传输控制数据的连接。例如，呼叫代理924能够建立用于通过相应的呼叫控制器904各自的外部接口905与相应的呼叫控制器904传输数据的连接。音频代理926能够建立用于通过相应的音频控制器906各自的外部接口907直接与相应的音频控制器906传输数据的连接。视频代理928能够建立用于通过相应的视频控制器908各自的外部接口909直接与相应的视频控制器908传输数据的连接。传输代理930能够建立用于通过相应的传输控制器910各自的外部接口911直接与相应的传输控制器910传输数据的连接。管道代理332能够建立用于通过相应的管道控制器912各自的外部接口913直接与相应的管道控制器912传输数据的连接。

任何这种已建立的连接可以用于，例如发送请求消息，所述接收机执行操作作为响应，并且一旦完成操作则通过该连接返回响应消息。

每个控制器通常同时控制多个(并且可能很多个)呼叫的各自方面。在特定呼叫的任何两个给定事务(即，基于请求—响应交换的事务)之间，每个控制器可以完成一个或多个其它呼叫的任何数量(零或更多)的事务。针对参与那些事务的无状态组件的无状态VM，这些VM中的任何一个可以工作以进一步完成这两个给定事务和其它事务。从这个意义上，特定类型的控制器的无状态VM为该控制器提供控制资源池；可以在任何时间从该池选择任何自由VM(即，当前没有执行处理以促进事务的任何VM)以促进任何给定呼叫的事务，并且一旦该事务完成，所选择的VM可以被返回到该池以用于未来的这种选择。

每次通过网络30接收到发往特定控制器(例如，呼叫、媒体模态(例如音频、视频等)、传输、管道)的指令(请求消息)，例如REST呼叫，该控制器的实例被指派处理该指令(如上所描述的，在这一实施例中通过与该控制器相关联的负载均衡器)。响应于该控制器实例返回对该指令的响应，该控制器实例被从该指派释放，这样所分配的用于实现完成该指派的任何物理资源(处理资源、存储器资源)变成未分配的(从而变为可用于处理其它这种指令)。

图9示出了呼叫控制器的多个实例974a、974b,…；音频控制器的多个实例976a、976b,…；视频控制器的多个实例978a、978b,…；传输控制器的多个实例980a、980b,…；以及管道控制器的多个实例982a、982b,…。在这一实施例中，每个所述实例是运行在虚拟机510上的一个或多个应用代码模块的实例534，已经以如上参考图5A和5B所描述的方式将其实例化。在这一实施例中，虚拟机上运行最多一个控制器实例(因此虚拟机的选择等效于运行在该虚拟机上的实例的选择)。但是，在其它实施例中，VM可以运行多个实例。

呼叫控制器和呼叫代理串联行动以递送实时媒体呼叫服务(主要的、较高级别服务)，联合运行以提供呼叫建立功能、呼叫管理功能(即，添加 /移除参与者、响应于通过客户端用户界面做出的任何用户选择、通过客户端用户界面呈现可选择的选项以提高呼叫体验，例如通过使诸如屏幕分享或即时消息传递之类的额外功能实现)、提供创建实时媒体呼叫数据的底层流的上下文的信息(诸如呼叫参与者状态)。如上所讨论的，这一呼叫服务的控制通过向该呼叫代理递送呼叫控制服务的呼叫控制器实现，用户一侧交互通过所述呼叫控制器的所述控制之下的呼叫代理实现。呼叫代理提供呼叫服务和用户之间的接口。

其它模态服务和它们相应的模态代理串联动作以递送各自的模态服务 (次要的，低层级的服务)。该模态控制器递送模态控制服务，其可以在呼叫控制的控制之下(直接控制或间接控制之一，即，该模态服务由呼叫控制器直接或间接控制下的另一个模态服务直接控制)扩展到相应的模态代理，以便由呼叫控制器支持该呼叫控制器(即，以便支持该呼叫控制器及其相应呼叫代理针对该呼叫递送的呼叫服务)。一旦模态控制服务如此扩展到相应的模态代理，该模态控制器和该模态代理功能联合以递送该模态服务。

媒体(音频和视频)服务是一个示例。音频(或视频)控制器和音频 (或视频代理)串联行动以递送音频(或视频)服务，联合工作以确保在用户设备处捕捉到的音频(或视频)被优化地编码，这样针对该编码选择优化的音频(或视频)变量，并且该音频(或视频)代理向传输代理提供经编码音频(或视频)数据，用于作为该音频(或视频)服务的一部分传输给其它呼叫方。

传输和管道服务是另一个示例。传输控制器和传输代理联合行动以递送传输服务。管道控制器和管道代理联合行动以递送管道服务。

传输控制器控制该呼叫的端点的拓扑，基于该呼叫中的所有端点做出决策，并且因此决定最有效的路由媒体的方式。一旦已经做出这些决策，传输控制器指令管道控制器根据需要在所述模态的相关端点之间建立必要的物理套接字连接。

1.2.1呼叫控制器

该呼叫控制器被配置为建立通信事件(并且一旦建立则管理所述通信事件)。通信事件被称为建立在实时媒体(例如，音频/视频)可以在两个或多个端点之间流动的点处。除了别的之外，建立该通信事件包括，创建该通信事件的呼叫状态并指令其它控制器适当地响应于其它控制器与它们各自的代理传输的，以便建立媒体流。除了别的之外，管理该通信事件包括，在该通信事件期间维护呼叫状态的更新(例如，通过添加和/或移除呼叫参与者、联合音频控制器处理静音/非静音音频请求、联合视频控制器处理视频启用/禁用请求、最终终止该通信事件等等)。

根据本发明的主题，响应于通过网络接收到的指令，呼叫控制器的实例被指派推进通信事件的建立，并且被配置为向媒体模态控制器和至少一个端点中的至少一个发起指令。

通常，多个呼叫控制器实例的指派将会发生在呼叫建立期间，每个实例被独立于其它实例地指派推进通信事件的建立。例如，响应于通过网络接收到的指令，呼叫控制器的实例可以被指派推进通信事件的建立，并且响应于通过网络接收到的进一步指令，该呼叫控制器的该实例或另一个实例可以被独立地指派进一步推进该通信事件的建立。例如，初始指派的实例可以通过创建该通信事件的呼叫状态推进该通信事件的建立，后续指派的指令通过执行呼叫建立操作并作为对其响应相应地更新所述呼叫状态来推进该通信事件的建立。

呼叫控制器被配置为访问通信系统的计算机存储器以访问该通信事件的呼叫状态(以便创建该通信事件的呼叫状态，例如作为建立该通信事件的一部分，或者访问该通信事件的现有呼叫状态)。具体来讲，在这一实施例中，被指派的呼叫控制器实例被配置为访问该呼叫状态，并且该呼叫状态持续紧跟在该呼叫控制器实例被从所述指派的释放之后，这样该呼叫控制器的另一个实例能够在该事件中访问该呼叫状态(也就是，这样该呼叫控制器的该实例和/或另一个实例能够紧跟着所述释放之后访问所述呼叫状态)。从媒体模态控制器接收到的媒体模态状态数据可以作为该呼叫状态的一部分来存储。

此外，通常呼叫控制器实例的多个其它指派发生在该通信事件期间，以便管理该通信事件(例如，实例可以被指派响应于添加参与者的请求，该实例或另一个实例被独立地指派响应于移除参与者的请求等等)。因此，该呼叫控制器的实例可以被指派推进该通信事件的建立，并且该呼叫控制器的该实例或者另一个实例可以被独立地指派管理所建立的通信事件的至少一部分。

在这一实施例中，呼叫控制器是由无状态代码模块实现的。如图9A中所示，呼叫控制器服务逻辑904包括暴露外部接口905的无状态呼叫控制组件945，和暴露内部接口955并具有分配的共享物理存储器资源集合的内存存储组件952。该无状态呼叫控制组件954能够建立用于通过该内部接口 955与无状态内存存储组件传输数据的连接。该内存存储组件953可操作用于将该呼叫控制器904当前支持的每个呼叫的呼叫状态953存储在该组件 952的所有VM之间共享的并且所有VM可访问的共享物理存储器资源中，该呼叫状态包括该呼叫的多个当前参数。无状态呼叫控制组件954可以通过经由内部接口955建立的连接从那些物理存储器资源读取和向其写入。因此呼叫控制组件954能够取回并修改呼叫状态953或者它的至少一部分。

呼叫的呼叫状态代表关于该呼叫的当前信息，诸如通信系统300中的参与端点(用户设备)的标识符和它们各自的状态(准备好、连接中、响铃中、进行中等等)、当前支持该呼叫的其它服务逻辑的标识符等等。下面讨论呼叫状态及其创建和维护。它还可以跟踪下面的(除了别的之外)：每个参与者/端点的哪些模态是活跃的、模态状态是什么(发送中、静音等等) —围绕允许的呼叫控制(踢出、添加、静音其它等等)的对每个用户的授权。

所述组件的每一个包括各自的负载均衡器和各自的多个负载均衡的、以如上讨论的方式运行副本应用代码实例的副本VM。通过接口905在控制组件954处接收到的请求被转发给多个无状态VM中由该组件的负载均衡器选择的任何一个VM，每个请求被作为不同的、独立的事务来对待。作为响应，所选择的VM可以，作为处理该请求的一部分，通过经由内部接口 955发送内部读取请求从内存存储组件952接口955取回该呼叫状态952的副本(至少它的一部分)。这一内部请求被转发给由该组件的负载均衡器选择的内存存储组件952的任何一个VM，作为响应，该VM从该内存存储组件952的共享物理存储器取回该呼叫状态953的副本并将该副本返回给呼叫控制组件954。该呼叫控制组件临时保存这一副本，并且如果可以的话相应地修改所保存的副本，并将修改后的副本发送给内存存储组件952以便作为额外的内部写入请求的一部分将其存储其中。并且，这一额外的内部写入请求被转发给该组件的负载均衡器所选择的内存存储组件952中的任何一个VM(其可以不同于被选择用于初始取回该呼叫状态的副本的所述 VM)，作为响应，该VM覆写内存组件952的共享物理存储器资源中的呼叫状态953以实现接收到的修改。

如下进一步讨论的，在实施例中，呼叫控制器响应于一个或多个指令的每一个；响应于一个或多个指令中的每一个，该呼叫控制器的各自实例被独立地指派用于根据该指令推进通信事件的建立，所指派的呼叫控制器实例被配置为如此推进通信事件的建立。通信事件的建立可以，例如根据一个指令至少通过更新现有呼叫状态来推进。

所述一个或多个指令可以包括第一指令，根据该第一指令至少通过创建通信事件的呼叫状态推进通信事件的建立。作为替代或者另外，所述一个或多个指令可以包括：

-第二指令，根据该第二指令至少通过基于接收到的用户标识符选择一个或多个端点推进通信事件的建立；和/或

-第三指令，根据该第三指令至少通过基于另一个接收到的用户标识符选择一个或多个其它端点推进通信事件的建立；和/或

-第四指令，根据该第四指令至少通过向至少一个所述端点发起邀请指令推进通信事件的建立；和/或

-第五指令，根据该第五指令至少通过向至少一个所述端点发起响铃指令推进通信事件的建立；和/或

-第六指令，根据该第六指令至少通过将一个或多个已识别的用户附着到通信事件上推进通信事件的建立；和/或

-第七指令，根据该第七指令至少通过向通信事件添加一个或多个已识别的用户作为其中的参与者推进通信事件的建立；和/或

-第八指令，根据该第八指令至少通过向一个或多个所述端点发送准备好指令推进通信事件的建立。

本主题的一个方面针对用于管理通过通信系统的通信网络连接的多个端点之间的通信事件的方法，该通信系统除了所述端点之外包括多个处理单元，每个处理单元具有对保存用于管理该通信事件的可执行代码模块的计算机存储器的访问，该代码模块被配置为实现被配置为管理已建立的通信事件的媒体模态的媒体模态控制器，和被配置为建立该通信事件的呼叫控制器，该方法包括：通过网络接收指令；响应于接收到该指令，指派该呼叫控制器的实例推进通信事件的建立；并且该呼叫控制器实例向媒体模态控制器和至少一个所述端点中的至少一个发起指令。

在实施例中，该方法还可以包括：通过网络接收另一个指令；响应于接收到所述其它指令，独立地指派该呼叫控制器的该实例或另一个实例进一步推进通信事件的建立，该实例向媒体模态控制器和至少一个所述端点中的一个发出另一个指令。

在实施例中，该方法还可以包括：呼叫控制器实例基于接收到的用户标识符选择一个或多个端点并向所选择的端点发起第一指令；并且独立地指派该或另一个呼叫控制器实例向包括所选择端点中的一个的标识符的媒体模态控制器发起第二指令。

1.2.2传输控制器

通信系统300的代码模块被配置为实现传输控制器，其被配置为在该通信事件的端点之间管理该通信事件的媒体的传输。传输控制器的实例被指派无需访问所述端点的呼叫代理而向所述端点的各自传输代理传送该通信事件的传输控制信号，该传输控制器实例被独立于呼叫控制器指派并且响应于通过网络接收到的第一指令。响应于该传输控制器实例返回对第一指令的响应，从所述指派释放该传输控制器实例，同时呼叫控制器继续工作与所述端点的呼叫代理和/或与媒体模态控制器通信(该实例或者被配置为从包括用于如此释放该实例的释放逻辑的通信系统的指派如此释放)。可以由该呼叫控制器发起该第一指令。

如图9B中所示，传输控制器906包括，包括负载均衡器和多个无状态 VM的无状态传输服务器组件958，以及包括负载均衡器和多个有状态VM 的有状态转发器组件，有状态的意义是每个VM使用它们单独被分配的物理存储器资源存储关于过去的事务的信息，即使那些事务已经完成之后，并且依赖该信息成功地完成未来的事务—这一信息只能通过该特定VM访问(并且如果特定VM发生故障则变得不可访问并且因此有效地丢失，使得该转发器组件无法处理某些未来的请求，因为对这些请求的处理依赖于那个丢失的信息)。无状态传输服务器暴露耦接到该组件的负载均衡器的外部接口907。有状态转发器组件956暴露耦接到该组件的负载均衡器的内部接口957。该传输服务器组件958能够建立用于通过该内部接口955与该转发器传输数据的连接。无状态传输控制组件也能够建立到该转发器组件的特定的各个VM的连接；如下所解释说明的(1.4部分)，某些状况必须以这种方式绕过有状态转发器组件的负载均衡器，即，发往该转发器组件的某些内部请求可以从该传输组件发送到该转发器组件的特定的识别出的 VM。

1.2.3管道控制器

通信系统300的代码模块被配置为实现管道控制器，它被配置为在所述传输控制器的控制下在两个所述端点之间创建用于所述媒体传输的管道。管道控制器的实例被指派用于独立于传输控制器并且响应于通过网络接收到的第二指令创建所述管道。该传输控制器在所述管道控制器实例从所述指派释放之后，继续工作以与所述端点的传输代理和/或媒体模态控制器和/或呼叫控制器通信。所述第二指令是由传输控制器发出的(而不是由呼叫控制器发起的，该呼叫控制器被配置为不向管道控制器发起指令)。响应于管道控制器对管道的创建，该传输控制器被配置为向媒体控制器提供已创建的管道的一个或多个参数。

在这一实施例中，管道控制器被配置为针对各个不同的媒体模态创建多个管道，每个所述管道经由所述网络或另一个网络(例如，该管道控制器可以经由互联网与管道代理通信，但是该管道可以经由诸如局域网之类的另一个网络或经由PSTN)。具体来讲，管道控制器被配置为分别针对音频和视频数据的传输创建单独分开的音频和视频管道。

如图9C中所示，管道控制器908包括无状态传输控制组件964、有状态管道状态组件962和可操作用于将管道状态961存储在组件共享物理存储器资源中的内存存储组件960。该管道控制组件暴露外部接口909，并且该管道状态组件962和内存存储组件960的每一个暴露它们各自的内部接口965、963。无状态管道控制组件954能够建立用于经由所述内部接口965 与有状态管道状态组件962传输数据的连接。该有状态管道状态组件962 能够建立用于经由所述内部接口963与内存存储组件传输数据的连接。下面讨论管道控制器的有状态行为(部分1.4)。

1.2.4媒体模态控制器(例如，音频控制器、视频控制器)

根据本发明的主题，媒体模态控制器的实例(正如由通信系统300的处理单元可访问的上述代码模块所实现的)被指派用于将多个端点之间的通信事件(由通信系统300实现)的媒体模态控制信号传送给所述端点各自的媒体模态代理而不访问所述端点各自的呼叫代理，该媒体模态控制器实例被独立于呼叫控制器并且响应于经由该网络接收到的指令如此被指派。响应于该媒体模态控制器实例向接收到的指令返回响应，从所述指派释放该媒体模态控制器实例，同时该呼叫控制器继续工作以与所述端点的呼叫代理通信。在这一实施例中，媒体模态控制器实例的响应的所述返回是对该端点的媒体代理关于媒体模态参数的协商的完成的响应。在实施例中，接收到的指令包括所述端点的每一个的各自标识符，使用所述接收到的标识符传送媒体模态控制信号。

该媒体模态控制器实例可以继续工作以与所述端点的媒体代理通信，同时被指派用于推进通信事件的建立的呼叫控制器实例被从该指派释放和/ 或失效(例如，被退役或发生故障)，并且另一个呼叫控制器实例被指派用于推进该通信事件的建立。

所述接收到的指令可以由呼叫控制器(或者其它控制器，例如传输控制器)发起，所述响应被返回给该呼叫控制器(或其它控制器，例如传输控制器)。例如，该呼叫控制器的实例可以向媒体控制器发起所述指令，并且呼叫控制器的该实例可以在媒体控制器的实例被释放之后继续工作以与所述端点的呼叫代理通信。在这一实施例中，该媒体控制器不向呼叫控制器发起指令。

媒体模态控制器还被配置为响应经由该网络接收到的其它指令，该媒体模态控制器的该实例或另一个实例被独立地指派用于处理所述其它指令。

除了其它之外，媒体模态(例如，音频或视频)控制器被配置为用于选择媒体(例如，音频或视频)编解码器和/或媒体(例如，音频或视频) 变量，并控制端点的媒体(例如，音频或视频)代理以基于所述选择处理该通信事件的媒体(例如，音频或视频)数据。

在这一实施例中，通信系统的代码模块被配置为实现至少第一和第二媒体模态控制器，它们被配置为分别管理已建立的通信事件的第一和第二媒体模态。第一媒体模态控制器的实例被指派将该通信事件的第一媒体模态控制信号传送给所述端点各自的第一媒体模态代理而不访问所述端点各自的第二媒体代理，该第一媒体模态控制器的实例独立于该第二媒体模态控制并且响应于经由该网络接收到的指令如此被指派。该第一媒体模态控制器的实例被配置为响应于实例返回对所接收到的指令的响应而从所述指派释放，同时该第二媒体模态控制器继续工作以与该第二媒体代理通信。所述媒体模态控制器中的一个是用于管理已建立的通信事件的音频的音频控制器，而另一个所述媒体模态控制器是用于管理已建立的通信事件的视频的视频控制器。该音频控制器操作用于向端点的音频代理而不向该端点的视频代理传送音频控制信号，并且该视频控制器操作用于向端点的视频代理而不向该端点的音频代理传送视频控制信号。

每个媒体模态控制器还包括可操作用于存储媒体模态状态(例如，音频状态、视频状态)的内存存储组件(类似于呼叫控制器)，所述状态例如包括在其间进行通信事件的一个或多个端点各自的标识符。该媒体模态状态数据可以包括该媒体模态是否针对所述端点的至少一个实现的指示(当该媒体模态控制器是音频控制器时，该指示是音频针对该至少一个端点是否静音的指示；当该媒体模态控制器是视频控制器时，该指示是视频是否针对该端点实现的指示)。

在实施例中，被指派的媒体模态控制器实例可以被配置为访问该通信系统的计算机存储器以访问已建立的通信事件的媒体模态状态。在实施例中，该媒体模态状态可以坚持紧跟在该媒体模态控制器从所述指派的释放之后，这样该媒体模态控制器的另一个实例能够该事件中访问该媒体模态状态。例如，媒体模态控制器实例可以生成媒体模态状态数据。该媒体模态状态数据可以作为该媒体模态状态的一部分存储。访问该媒体模态状态可以包括更新该媒体模态状态。该媒体模态控制器实例可以被配置为基于该媒体模态状态传送媒体模态控制信号。

作为替代或者另外，由该媒体模态控制器实例返回的对指令的响应可以包括该媒体模态状态数据。该响应可以被返回该指令的发起者，作为响应，该发起者可以存储接收到的媒体模态状态数据。所述接收到的指令可以是由呼叫控制器(或传输控制器)发起的，所述响应被返回给该呼叫控制器(或传输控制器)。

媒体模态控制器与传输控制器和管道控制器协同工作以便向端点传输管道细节：该媒体控制器被配置为从该传输控制器接收一个或多个管道参数，并将接收到的管道参数的至少一个传输给端点的媒体代理。

该媒体模态控制器被配置为向所述端点中的一个的媒体代理发送发起控制信号(例如，在通信事件开始时或在已建立的通信事件期间)，作为响应，该媒体代理发起向所述端点的另一个的媒体数据的传输。该媒模态控制器还被配置为向该媒体代理发送停止控制信号，作为响应，该媒体代理停止所述媒体数据的传输。

在这个实施例中，呼叫控制器由无状态代码模块以类似于呼叫控制器的方式实现。

进一步根据本发明的主题，公开了用于管理通过通信系统的通信网络连接的端点之间的通信事件的方法，该通信系统包括多个处理单元，每个处理单元具有对保存用于管理该通信事件的可执行代码模块的计算机存储器的访问，该代码模块被配置为实现被配置为管理已建立的通信事件的媒体模态的媒体模态控制器，以及被配置为建立该通信事件的呼叫控制器，该方法包括：指派该媒体模态控制器的实例向所述端点各自的媒体代理传送该通信事件的媒体模态控制信号而不访问所述端点各自的呼叫代理；从所述指派释放该媒体模态控制器实例；以及指派该呼叫控制器的实例推进通信事件的建立，该呼叫控制器实例在所述媒体模态控制器实例的所述释放之后工作以与该端点的呼叫代理通信。在实施例中，该呼叫控制器实例可以在所述媒体模态控制器的所述释放之前或之后被如此指派。

媒体模态控制器实例可以被配置为响应于通过网络接收到的指令以访问该通信系统的计算机存储器，以便：创建该通信事件的媒体模态状态，和/或访问该通信事件的现有媒体模态状态以更新该现有媒体模态状态。所创建的媒体模态状态和/或更新后的媒体模态状态坚持紧跟在所述媒体模态控制器实例的释放之后，这样该实例或后续被指派用于传送该通信事件的其它媒体模态控制信号的另一个媒体模态控制器实例能够该事件中访问已创建的和/或已更新的媒体模态状态。

1.2.5业务管理器

业务管理器332被配置为响应于来自请求者(发起者)的针对该类型的控制器的请求(例如不同类型的服务逻辑、相同类型的代理)，从多个该类型的控制器选择特定类型的控制器，该请求者被配置为从业务管理逻辑请求媒体模态控制器地址。作为响应，该业务管理器返回所选择的媒体模态控制器的地址，该发起者被配置为使用所述返回的地址向该媒体模态控制器发起指令。

针对呼叫控制器请求，该请求者可以是该通信事件的端点之一或者除了所述端点之外的网络实体(例如，另一个控制器)，或者被配置为在预定时间发起调度的通信事件的建立的会议管理系统。针对媒体模态控制器请求，该请求者可以是呼叫控制器(或可能的传输控制器)，或者没有参与该通信事件但是造成该通信事件被建立的用户设备。针对传输控制器请求，该请求者可以是呼叫控制器。针对管道控制器请求，该请求者可以是传输控制器。

1.3呼叫设立(建立)和管理

现在将参考图10A和10B描述呼叫建立方法。在这种情况中，该呼叫是在两个用户Alice(图3的302a)和Bob(图3的302b)之间的，并且根据本发明主题，由云服务逻辑904、906、908、910、912集中控制，所述云服务逻辑是由业务管理器332从各自的多个那些相同类型的服务逻辑中选择的。

应该了解的是，该方法可以扩展到能够在多于两个用户之间进行呼叫。

除非另外声明，在下文中，向云控制服务逻辑(控制器)发送的所有请求消息(指令)通过经由该服务逻辑的组件的外部接口建立的连接(由请求者建立，它是参与呼叫的该类型的代理或支持该呼叫的不同类型的服务逻辑之一)发送，该连接是到该组件的负载均衡器的连接，而不是到该组件个体的虚拟机的连接。

如上所述，每个接收到的请求消息使得通信系统独立地指派适当的控制器的实施例来处理该指令(其在这一实施例中相当于在其上运行的VM 的指派，在这个实施例中，每个VM上最多运行一个控制器实例)。每个这一请求消息由该组件的负载均衡器接收，作为响应，该负载均衡器根据该负载均衡器的负载均衡机制(例如，轮询负载均衡机制、VM资源使用依赖负载均衡机制)从多个可能的虚拟机选择该组件的虚拟机，并且将该消息转发给所选择的虚拟机以便由该虚拟机上运行的控制器实例处理；每个这种请求消息(通过相同的这种连接发送的或通过不同的这种连接发送的二者)可以被转发给该组件的不同虚拟机—也就是，不假设(或确保)任意两个这种请求消息将会被转发到同一个虚拟机。对那些消息的响应(以响应消息的形式)被经由相同的连接返回。响应于该VM返回对该指令的响应(也就是运行在该VM上的控制器实例)，如上所述的从所述指派释放该 VM(也就是，运行在该VM上的控制器实例)。

除非另外声明，在下文中，由服务逻辑响应于指令所执行的操作由如上所指派的并响应该实例返回响应而从该指派释放的该服务逻辑的第一实例执行；由该服务逻辑响应于其它指令所执行的操作由该服务逻辑的第一实例或独立于上述第一实例的指派而指派的第二实例来执行，所述第一实例或第二实例也响应于该实例返回对所述其它指令的响应而从该指派释放。上述由第一实例执行的操作可以涉及或不涉及生成状态数据(例如，呼叫控制器实例生成呼叫状态数据；媒体模态控制器实例生成媒体状态数据)，该状态数据坚持紧跟在释放该第一实例之后以便由该第二实例使用。

除非另外声明，在下文中，向特定类型的客户端一侧代理发送的所有请求消息(指令)通过到注册和导入请求块934的连接发送，该连接是使用云800的注册和导出请求逻辑914所存储的并从其转发给目标客户端的关于该客户端的信息建立的(通过该类型的相应控制器)。当服务发送服务到端点消息时，该响应并不沿着相同的连接；而是该端点/代理以RESTful 消息的形式向该服务发起新的消息。

为了使Alice能创建呼叫，Alice的客户端416a的客户端用户界面显示可选择的选项，可以通过，例如触摸或滑动设备304a的触摸屏和/或通过做出设备304a可检测的适当手势或语音命令来选择。响应于这一选项的选择， Alice的客户端416a的呼叫代理924a向业务管理器332发送(S1000a)对呼叫控制云逻辑的地址的请求。响应于接收到这一请求，业务管理器332 基于存储器334中存储的呼叫控制业务管理简档并基于多个可能的云控制服务逻辑运行在的各自的数据中心所报告的那些逻辑各自的当前资源使用，从所述多个可能的云控制服务逻辑中选择呼叫控制云逻辑(如上所描述的)，并向呼叫代理924a返回(S1000b)所选择的呼叫控制服务逻辑904 的地址。所选择的呼叫服务逻辑904在该呼叫期间或直到该呼叫控制服务逻辑904发生故障都处理该呼叫(如下所讨论的)。

呼叫代理924a使用返回的地址经由接口905建立到该呼叫控制服务逻辑904的连接，通过该连接客户端代理924向呼叫控制服务逻辑904发送 (S1002)呼叫创建消息(包括Alice的用户标识符和/或端点标识符)，请求创建新的呼叫。该用户标识符可以包括，例如Alice的用户名，该用户名在通信系统中对于Alice是唯一的；该端点标识符可以包括她的用户设备 304a的标识符(诸如媒体接入控制(MAC)地址)，这些先前已经由注册和导出请求逻辑914将其与客户端416的地址相关联地存储起来(见上文)。

这一请求由呼叫控制服务逻辑904的呼叫控制组件954接收，作为响应，创建呼叫状态953，其除了其它之外包括Alice的端点标识符(S1003a)。这涉及建立通过接口955到内存存储组件952的连接，通过该连接，呼叫控制组件954向内存存储组件952发送呼叫状态创建消息。响应于该消息的接收，该存储组件952创建该呼叫的呼叫状态953(其由该存储组件952 在该呼叫持续期间维护)并向呼叫控制组件954返回响应以将其通知该呼叫控制组件954。然后，呼叫控制组件954向呼叫代理924a发送(S1003b) 消息，该消息指示该呼叫的呼叫状态953的成功创建并且包括该新的呼叫状态的至少一部分，该部分至少包含该呼叫状态的呼叫标识符，该标识符在通信系统300中是唯一的并且因此能够将该呼叫与通信系统300中的其它呼叫区分开。

该呼叫创建消息可以选择性地指定应该创建该呼叫状态953的未来时间，该呼叫控制器904将该呼叫状态的创建推迟到那个时间。这使得能够在该呼叫之前提前指定呼叫创建。

在步骤S1004，呼叫代理924a通过向呼叫控制器904发送呼叫附着消息附着到该呼叫，该消息包括Alice的呼叫标识符和端点标识符。作为响应 (S1005a)，呼叫控制器904修改该呼叫状态953的至少一部分(如上参照图9A所描述的)以指示Alice已经附着到该呼叫上并且向Alice的呼叫代理924a发送(S1005b)至少包括该呼叫状态的修改后的部分的消息。

附着是为了建立连接并且因此允许消息交换(信令)、状态交换等等—不意味着“回答”或“加入”(其通过单独的指令实现)，但是它允许建立媒体路径、确定能力、开始响铃等等。

在步骤S1006处，Alice的呼叫代理924a向呼叫控制器904发送加入消息指示该客户端416a准备好从其它呼叫参与者接收实时媒体，该消息包括呼叫标识符和端点标识符。作为响应，该呼叫控制器904修改(S1008) 呼叫状态的至少一部分以指示Alice已经加入该呼叫，并向Alice的呼叫代理924a发送(S1010)至少包括该呼叫状态的修改后部分的消息。

在步骤S1012处，Alice的呼叫代理924a向呼叫控制器904发送邀请消息，该消息包括另一个用户(Bob)的标识符(例如，包括用户名的用户标识符)并指示该用户应该被邀请加入该呼叫。作为响应，该呼叫控制器修改(S1014)呼叫状态的至少一部分以指示Bob正在连接到该呼叫，向 Alice的呼叫代理924a发送(S1016)至少包括该呼叫状态的修改后部分的消息，并且向Bob的呼叫代理924b发送(S1018)推送通知指示Bob已经被邀请并包括该呼叫的标识符。该推送通知与Bob的标识符(例如，用户名)被首先一起发送给注册和导出请求逻辑913，作为响应，该注册和导出请求逻辑914将该通知发送给Bob当前登录到的Bob的用户设备304b(或者如果Bob在多于一个设备处登录则发送给多个这样的用户设备)。该推送通知(通知指令)是通过Bob的用户设备304b订阅的推送信道发送的(推送信道是本领域内公知的)，这一订阅由注册逻辑913注册。

在实施例中，Bob可能有多个与相同用户标识符(例如，用户名)相关联的用户设备(用户设备304b是其中一个)，例如如果Bob在所有那些用户设备处都登录了。那些设备的每一个订阅一个推送信道，并且通过那些推送信道由呼叫控制器(并且根据要求由其它控制器—媒体、管道、传输控制器)发送各自的通知。

一旦接收到Bob的用户标识符，呼叫控制器可操作用于选择与该标识符相关联(即，与单个用户Bob相关联)的一个或多个端点(包括用户设备304b)，并向所选择的端点发送上面提到的通知。针对端点304b的通知可以因此是发送到端点的多个指令中的一个，每个指令都是响应所述相同的接收到的指令(来自Alice)而发送的。

响应于接收到该推送通知，Bob的呼叫代理通过向呼叫控制器904发送附着消息附着到该呼叫上，该消息包括Bob的端点标识符；Bob的呼叫代理924b也输出“响铃”通知(例如，听得见的铃声)并通过客户端416b 的用户界面显示加入该呼叫的可选择的“加入”选项。该端点标识符可以，例如包括他的用户设备304b的标识符，诸如媒体接入控制(MAC)地址。响应于接收到这一附着消息，该呼叫控制器904修改(S1022)呼叫状态的至少一部分以指示Bob的客户端当前处于“响铃”状态，并分别向Alice的呼叫代理924a和Bob的呼叫代理二者发送(S1024、S1026)消息，那些消息至少包括该呼叫状态的修改后的部分。

在步骤S1028处，响应于Bob的“加入”选项的选择，Bob的呼叫代理向呼叫控制器904发送包括Bob的呼叫标识符和端点标识符的消息。响应于接收到这一加入消息，呼叫控制器904修改(S1030)该呼叫状态的至少一部分以指示Bob已经加入该呼叫，并分别向Alice的呼叫代理924a和Bob 的呼叫代理二者发送(S1032、S1034)消息，那些消息至少包括该呼叫代理的修改后的部分。并且作为对其响应，呼叫控制器与其它服务逻辑通信 (S1036)；作为响应，这些其它服务逻辑与它们相应的服务代理协商(并且在一定程度上相互协商)以决定如何在端点之间传送实时媒体和如何以“管道”的形式创建这一传送的机制。管道是由该管道控制器和有关端点上的管道代理中介/辅助的端点网络库栈之间的逻辑连接。下面将参考图10B对此进行描述。

针对发往该呼叫控制器的每个请求(即，S1002-来自Alice的创建呼叫指令，S1004-来自Alice的附着指令，S1006-来自Alice的加入指令，S1012- 来自Alice的“邀请Bob”指令，S1020-来自Bob的附着指令，S1028-来自Bob 的加入指令)，独立地指派(由无状态呼叫控制组件954的负载均衡器)该呼叫控制器的实施例以处理该请求，并且一旦完成该处理(即，响应于创建该呼叫状态；响应于将Alice附着到该呼叫；响应于将Alice作为参与者添加到该呼叫；响应于邀请Bob；响应于附着Bob；以及响应于S1044处的端点之间媒体流的发起(其发生在添加Bob作为参与者并且完成各种协商和管道创建S1038之后))则从该指派释放该实例。

在这一实施例中，只将识别特定端点的端点标识符(与用户标识符正相反，该用户标识符可以与多个端点相关联，例如如果用户同时在所有那些端点处都登录)提供给除了该呼叫控制器之外的控制器。因此，只有该呼叫控制器“知道”用户；其它控制器根据指令在特定设备之间创建会话并且“不知道”它们与特定用户相关联的事实。

如图10B中所示，响应于在步骤S1038处更新呼叫状态953，呼叫控制器904向该业务管理器332发送针对该分布式平台800的媒体控制器(也就是音频控制器和视频控制器)各自的地址的请求。响应于接收到这一请求，业务管理器332基于存储器334中存储的音频(或视频)控制业务管理简档并基于多个可能的音频(或视频)控制器当前运行在的各自的数据中心所报告的那些音频(或视频)控制器各自的当前资源使用，从所述多个可能的音频(或视频)控制器选择音频控制器906(或视频控制器908) (如上所描述的)，并且将所选择的音频控制器906和视频控制器908各自的地址返回(S1059b)给呼叫控制器904。所选择的音频和视频控制器在该呼叫持续期间或直到该组件发生故障一直支持该呼叫(如下所讨论)。

作为响应，呼叫控制器904使用针对其返回的各自的地址向每个所述媒体控制器906、908发送相应的会话创建消息(指令)。该会话消息包含从呼叫状态953取回的关于该呼叫(Alice和Bob)的各种信息，诸如Alice 和Bob的呼叫标识符和端点标识符。

每个媒体控制器906(音频)、908(视频)的指派的实例(如那些控制器的负载均衡器各自指派的)向端点的适当代理传送媒体模态控制信号。通过网络接收到的指令包括一个或多个端点各自的标识符，该媒体模态控制信号就是使用那些标识符传送的。在这一实施例中，这是针对该呼叫的媒体(音频和视频分别地)参数而与Alice和Bob二者的音频代理926a、 926b(或928a、928b)的协商的一部分。这包括建立到Alice的客户端416a 和Bob的客户端416b二者的相应媒体代理926(音频)、928(视频)的各自连接(使用注册和导出请求逻辑914所存储的信息)，以及通过那些连接交换各自的数据。这些协商还可以包括Alice和/或Bob的媒体代理926(音频)、928(视频)建立通过各自的外部接口907(音频)、909(视频)到各自的相应媒体控制器906(音频)、908(视频)的各自连接，并且通过那些连接交换各自的数据。一旦完成音频(或视频)协商，音频控制器906(或视频控制器908)向呼叫控制器904返回(S1064)响应消息(“OK”)，该消息是对在S1060处发送的音频(或视频)会话创建消息的响应。

上面提到的每个媒体模态控制器实例还可以被配置为生成该媒体模态 (例如，音频、视频)的媒体模态状态数据，所生成的媒体模态状态数据被存储在该通信系统的计算机存储器中，并且存储的媒体模态状态数据坚持紧跟着每个媒体模态控制器实例的释放之后，以便由该媒体模态控制器的另一个实例使用。在实施例中，该媒体模态状态数据可以被发送给呼叫控制器，作为响应，该呼叫控制器被配置为存储那些数据(例如，所述返回的包括该媒体模态状态数据的响应)。该呼叫控制器可以被配置为将存储的媒体模态状态数据提供给该媒体模态控制器的其它实例。例如，该呼叫控制器的实例可以被配置为存储从该媒体模态控制器实例接收到的媒体模态状态数据，并且该呼叫控制器的该实例或另一个实例可以被配置为将存储的媒体模态状态数据提供给其它媒体模态控制器实例。

作为替代或者另外，该媒体模态控制器实例可以被配置为将该媒体模态状态数据作为该媒体模态状态的一部分存储(见上文1.2.4)。

在媒体协商(S1062)期间，指派至少一个媒体实例(响应于指令S1064)，并且释放(一旦返回响应S1064)至少一个媒体实例，同时该呼叫控制器继续操作以(尤其是同时发起该指令S1060的呼叫控制器实例继续工作)与呼叫代理924a、924b通信，例如通过如图10A中所示的传输呼叫状态更新 S1040、S1042。那些实例可以是相同的，这样只指派一个媒体控制器实例，并且然后从该指派被释放。或者可以在该呼叫控制器和媒体控制器之间有额外的请求(由该呼叫控制器)/响应(由该媒体控制器)交换，其中针对每个呼叫控制器指派和释放多个媒体控制器实例，同时该呼叫控制器继续工作。

在步骤S1065a处，呼叫控制器904向业务管理器332发送针对分布式平台800的传输控制器的地址的请求。响应于接收到这一请求，业务管理器332基于存储在存储器334中的传输控制器业务管理简档并基于多个传输控制器运行在的各自的数据中心所报告的那些传输控制器各自的当前资源使用，从所述多个传输控制器选择传输控制器910(如上所述)，并且返回(S1065b)所选择的传输控制器的地址。所选择的传输控制器在该呼叫持续期间或直到该控制器发生故障一直支持该呼叫(如下面讨论的)。

作为响应，呼叫控制器904使用针对其所返回的地址向所述传输控制器910发送会话创建消息。该会话消息包含从呼叫状态953取回的关于该呼叫(Alice和Bob)的各种信息，诸如Alice和Bob的呼叫标识符和端点标识符。然后，该传输控制器910获取关于用户设备304a、304b的细节并与Alice和Bob的传输代理412a、412b二者协商该呼叫的传输参数(诸如分组协议)。这包括建立到Alice的客户端416a和Bob的客户端416b二者的相应传输代理930的各自连接(使用注册和导出请求逻辑914所存储的信息)，并通过传输那些连接交换数据。这些协商也可以包括Alice和/或Bob 的传输代理930通过外部接口911建立到传输控制器910的各自连接，并且通过那些连接交换数据。该传输控制器还从呼叫控制器904请求媒体细节(S1068)，诸如支持该呼叫的媒体服务的类型(在这里是音频和视频)(它是在步骤S1070处被返回的)并且还可以从音频控制器906和/或视频控制器908(未示出)请求其它细节。从这一点以及从Alice和Bob的传输代理 930获得的信息，传输控制器确定(除了其它之外)若干个管道用于该呼叫 (一个管道针对每个类型的媒体—在这里是两个)并且确定针对那些管道从Alice的用户设备304a到Bob的用户设备304b的穿过该网络的相应路径。一旦这样确定，传输控制器向业务管理器发送(S1071a)针对分布式平台 800的管道控制器的地址的请求。响应于接收到这一请求，业务管理器332 基于存储在存储器334中的传输控制器业务管理简档并基于多个传输控制器运行在的各自的数据中心所报告的那些传输控制器各自的当前资源使用，从所述多个传输控制器选择一个管道控制器912(如上所述)，并且返回(S1071b)所选择的管道控制器的地址。然后，这一管道控制器在该呼叫期间或直到该控制器发生故障一直支持该呼叫(如下面讨论的)。

作为响应，传输控制器910向所选择的管道控制器912发送(S1014) 管道创建消息，其包括确定的要创建的管道数量(这里是两个)以及关于针对那些管道的每一个确定的穿过网络310的路径的各自细节。作为响应，管道控制器根据这些各自的细节创建(S1076)该数量的管道。管道的创建包括建立到Alice的客户端416a和Bob的客户端416b二者的相应管道代理 332的各自连接(使用注册和导出请求逻辑914所存储的信息)，并且通过传输那些连接交换数据。这些协商还可以包括Alice和/或Bob的管道代理 332通过外部接口913建立到管道控制器910的各自连接，并且通过那些连接交换数据。一旦完成，该管道控制器912向传输控制器910返回响应消息(S1078)以指示管道已经建立并且该消息包括音频和视频管道的各自管道标识符。

作为响应，传输控制器向音频控制器906(或视频控制器908)发送 (S1080)包括音频(或视频)管道标识符的消息。作为响应，该音频(或视频)控制器将这些管道细节发送给Alice和Bob二者的音频代理926(或视频代理928)，它们的每一个返回响应(“OK”)消息(S1084)。在步骤 S1086处，音频(或视频)控制器906(908)向传输控制器910返回响应消息(对S1080的消息的响应)，指示该管道标识符已经被正确地传送给适当的客户端一侧媒体代理(并且它们因此现在可操作用于利用讨论中的管道来传送实时媒体数据)。作为响应，该传输控制器向呼叫控制器发送 (S1088)响应消息(是对S1066的会话创建消息的响应)，指示用于在Alice 和Bob的用户设备304a、304b之间传送实时媒体的机制已经被成功建立并可以投入使用。

返回图10A，响应于这些各个协商的完成和管道的创建(即，响应于S1088的响应)，呼叫控制器904再次更新(S1038)该呼叫状态的至少一部分以便指示该呼叫针对Alice和Bob二者是“进行中的”(也就是，指示该实时媒体现在能够在Alice和Bob各自的客户端416a、416b之间流动)，并且向Alice和Bob的呼叫代理发送(S1040、S1042)各自的消息，该消息至少包括该呼叫状态的更新后的部分。并且作为对其的响应，呼叫控制器904 指令(S1044)媒体控制器906(音频)、908(视频)开始从Alice向Bob 流动媒体并且反之亦然(也就是，向其发起不同的各自的指令)。响应于那些指令S1044，各个媒体控制器实例被独立地指派发起所述流。

作为响应，音频控制器906(或视频控制器908)(尤其是指派的它的实例)指令Alice和Bob二者的音频代理926a、926b(或视频代理928a、 928b)开始实时音频(或视频)的流动。作为响应(S1050、S1052)，每个音频(或视频)代理926发起通过音频(或视频)管道(其细节已经由音频/视频控制器在S1082处提供)的实时音频数据(或视频数据)的流动。

用户设备(例如，304a、304b)上的呼叫代理间接控制该设备上的其它代理—间接在于该呼叫代理向该呼叫控制器发起指令，作为响应，该呼叫控制器向另一个控制器发起指令，作为响应，该另一个控制器向该设备上的相应代理发起控制信号。

1.4呼叫建立期间传输和管道控制器的有状态行为

该传输控制器和管道控制器二者存储各自的传输和管道状态信息。在上述呼叫建立期间，传输状态信息由该传输控制器910的有状态传输转发器组件956维护—也就是，该转发器组件956的每个VM在它自己各自单独的存储器资源而不是共享内存资源中存储关于完成的事务的信息，因为这些通常会被进一步访问。因此，要求访问存储在单独VM处的这一信息的请求由传输服务器组件绕过负载均衡器957直接转发给该VM以便处理。由于这个原因，通过接口911发送给传输控制器的任何请求，依赖于特定 VM的先前请求的处理结果，该转发器组件包括该VM的标识符。在呼叫建立已经完成之后，传输服务器不再维护关于该呼叫控制器为了帮助服务呼叫所创建的会话的任何信息(并且依赖其它服务逻辑，在例如在呼叫控制器904的呼叫状态953和/或管道控制器912的管道状态961中维护任何必要的信息)。

此外，在上述呼叫建立期间，管道状态信息由管道控制器912的有状态管道状态组件962维护—也就是，管道状态组件956的每个VM在它自己各自单独的存储器资源(而不是内存组件960中)而不是共享内存资源中存储关于完成的事务的信息，因为这些通常会被进一步访问。因此，要求访问这一存储在单独VM处的信息的请求由管道控制组件绕过负载均衡器963直接转发给该VM以便处理。由于这个原因，在呼叫建立期间通过接口913发送给传输控制器的任何请求，依赖于特定VM的先前请求的处理结果，该转发器组件包括该VM的标识符。一旦呼叫已经建立(在这一点上，通常管道控制器将接收更少的与该呼叫有关的请求)，管道状态信息被维护在管道状态961中，而不再依赖于该管道控制器908的VM的有状态行为(以类似于由呼叫控制器904对呼叫状态953的维护的方式)。

因此，一旦管道控制器实例已经在呼叫建立期间被指派(响应于图10B 中的指令S1074)，在常规操作中它将不会被从该指派释放，直到管道已经被创建(即，直到返回图10B中的响应S1078)。当该管道控制器如此被释放时，该传输控制器(并且尤其是发起指令S1074的该传输控制器的实例) 继续与传输代理和/或与媒体代理(例如，通过向媒体控制器传输管道细节，如图10B中的S1080)和/或呼叫控制器(例如，通过向该传输控制器返回响应S1088，如图10B中的S1080)通信。

一旦传输控制器实例已经在呼叫建立期间被指派(例如，响应于指令 S1066)，在常规操作中它将不会被从该指派释放，直到向该媒体控制器提供了管道细节(图10B中的S1080)。因此，图10B中由传输和管道控制器执行的步骤在常规操作中将分别由单个传输控制器实例和单个管道控制器实例执行。

在这个实施例中，该通信系统的一些代码模块(尤其是实现传输和管道控制器的那些)被配置为在建立通信事件的呼叫建立阶段期间是有状态的，而在通信事件建立之后是无状态的。但是，在其它实施例中可能并非如此，一个或多个管道和传输控制器可以被配置为在呼叫建立期间是无状态的，其中在呼叫建立期间多次指派和释放传输和管道实例。

根据本公开内容，用户设备包括网络接口424，该接口被配置为通过通信系统的通信网络从该通信系统的呼叫和媒体模态控制器接收各自的指令，它们分别被配置为用于建立通信事件和管理已建立的通信事件的媒体模态；以及处理单元402，被配置为执行呼叫代理和媒体代理，该呼叫代理被配置为响应于从呼叫控制器接收到的指令，并且媒体模态代理被配置为响应于从该媒体模态控制器接收到的指令而不响应于从呼叫控制器接收到的指令。

在实施例中，呼叫代理可以不响应来自媒体模态控制器的指令。该呼叫代理可以被配置为通过网络接口向呼叫控制器发送通信事件建立指令，作为响应该呼叫控制器建立该通信事件。该呼叫代理可以被配置为响应于从该呼叫控制器接收到的邀请而加入已建立的通信事件。该处理单元可以被配置为执行音频代理和视频代理，该音频代理和视频代理是各自的媒体模态代理，该音频代理响应于从该通信系统的音频控制器接收到的指令但是不响应于从该通信系统的视频控制器接收到的指令，并且该视频代理响应于从该视频控制器接收到的指令而不响应于从该音频控制器接收到的指令。该网络接口还可以被配置为从该通信系统的传输控制器接收指令，该传输控制器被配置为管理该通信事件的媒体的传输；并且该处理单元还可以被配置为执行传输代理，该传输代理被配置为响应于从该传输控制器接收到的指令而不响应于从该呼叫控制器或媒体控制器接收到的指令。该网络接口还可以被配置为从管道控制器接收指令，该管道控制器被配置为创建所述媒体的传输的管道，并且该处理单元还可以被配置为执行管道代理，该管道代理被配置为响应于从该管道控制器接收到的指令。响应于来自该管道控制器的指令，该管道代理可以被配置为创建到另一个端点的管道代理的至少一个媒体管道。该媒体代理可以被配置为通过已创建的媒体管道发送该通信事件的媒体数据。该管道代理可以创建单独的音频和视频管道。该处理单元可以被配置为执行音频代理和视频代理，该音频代理和视频代理是各自的媒体模态代理，该音频代理被配置为通过音频管道发送音频，并且该视频代理被配置为通过已创建的管道发送视频。

还根据本公开内容，用户设备包括：被配置为通过通信系统的通信网络与该通信系统的呼叫和媒体模态控制器通信的网络接口424，该媒体模态控制器响应于来自通信控制器的指令，该呼叫和媒体控制器分别被配置为建立通信事件和管理已建立的通信事件的媒体模态；以及处理单元402，被配置为执行被配置为与媒体模态控制器通信而不与呼叫控制器通信的媒体模态代理和被配置为向呼叫控制器发起指令以间接控制该用户设备的媒体模态代理的操作的呼叫代理。

在实施例中，该呼叫代理可以被配置为与呼叫控制器通信而不与媒体模态控制器通信。该呼叫代理可以被配置为通过网络接口向呼叫控制器发送通信事件建立指令，作为响应，该呼叫控制器建立该通信事件。呼叫代理可以被配置为响应于从该呼叫控制器接收到的邀请而加入已建立的通信事件。该处理单元可以被配置为执行音频代理和视频代理，该音频代理和视频代理是各自的媒体模态代理，该音频代理被配置为与该通信系统的音频控制器通信而不与该通信系统的视频控制器通信，并且该视频代理与视频控制器通信而不与该音频控制器通信。该网络接口还可以被配置为与通信系统的传输控制器通信，该传输控制器被配置为管理该通信事件的媒体的传输；并且该处理单元还可以被配置为执行传输代理，该传输代理被配置与传输控制器通信而不与呼叫控制器或媒体控制器通信。该网络接口还可以被配置为与管道控制器通信，该管道控制器被配置为创建所述媒体的传输的管道，并且该处理单元还可以被配置为执行管道代理，该管道代理被配置为与该管道控制器通信。

2.独立的资源分配

本发明公开了用于实现通过通信网络连接的端点之间的通信事件的通信系统，该通信系统包括：多个处理单元，每个处理单元具有对保存用于管理通信事件的可执行代码模块的计算机存储器的访问，所述代码模块被配置为实现被配置为管理已建立的通信事件的媒体模态的媒体模态控制器和被配置为建立该通信事件的呼叫控制器；以及资源分配器，被配置为将该处理单元和计算机存储器的物理资源分配给呼叫控制器和媒体模态控制器中的每一个；其中，对呼叫控制器的物理资源的授权是独立于且不同于对媒体模态控制器的物理资源的授权的。

如上所讨论的，在这一实施例中，代码模块被配置为实现单独的音频和视频控制器，所述音频和视频控制器的每一个是各自的媒体模态控制器。对该音频控制器的物理资源的授权可以独立于且不同于对该视频控制器的物理资源的授权。

物理资源可以遍布多个容错区域分布(如上所讨论的；包括数据中心中的故障域)，授权给该呼叫控制器的物理资源是在不同于授权给媒体模态控制器的物理资源的容错区域中的。授权给该呼叫控制器的物理资源可以具有不同于授权给媒体模态控制器的物理资源的地理定位。同样，对音频控制器的物理资源的授权可以在不同于授权给视频控制器的物理资源的故障区域中(并且可能的地理定位)。该传输和管道控制器在这一实施例中具有类似的不同且独立的物理资源的准予(相互独立且不同、独立且不同于呼叫控制器和媒体控制器)。

在这个实施例中，通过控制那些控制器各自的虚拟机(即，那些控制器的实例各自运行在的虚拟机)来实现对各个控制器(呼叫、媒体(例如音频和视频)、传输、管道)的所有物理资源的授权。

此外，任何控制器的各个组件(例如，642、652)被独立于相同控制器的其它组件分配物理资源。例如，呼叫控制器组件954、952具有不同的和独立的物理资源的准予；传输控制器组件958、956具有不同的和独立的物理资源的准予；管道控制器组件964、962和960具有不同的和独立的物理资源的准予；并且任何媒体(音频/视频)控制器组件具有不同的和独立的物理资源的准予。

在这一实施例中，资源分配器由各种(并且可能的地理上分散的)数据中心320的控制服务器544的处理单元546上执行的代码实现。

该通信系统300能够扩展以满足特定的、谨慎的功能需求，例如在潜在的特定地理区域中(因为通信系统300可以是全球通信系统，即能够在不同国家和/或大洲之间进行呼叫)。

为此，NRT呼叫和RTM服务的设计不仅分离逻辑上的还分离谨慎服务部署的基础设施，它向用户提供总的服务递送的特定部分—例如，视频媒体、音频媒体、呼叫控制。所述服务并不是部署为一组在系统的内部逻辑上逻辑分离的耦合比特，而是实际上部署为完全分离的服务和处理。

传统上随着通信服务的需求的增长，例如在世界上一个特定部分中，以及对特定特征的需求的增长，诸如分组视频呼叫，整个解决方案需要被向上扩展以处理增长的需求。

但是，本公开内容的呼叫控制系统900设计允许独立于例如呼叫控制和信令基础设施，作为对需求变化的响应而例如扩展视频媒体基础设施。当然，响应于该相同的变化的需求，也需要扩展其它服务，但这是一个解耦合的独立决定。

如上所讨论的，实时AV呼叫的建立由多个解耦合的、独立的控制器(云控制服务逻辑)执行，所述控制器通过明确定义的接口和约定交互以提供实时AV呼叫和附着的媒体服务。

这一解耦的服务设计允许每个服务在该服务的内部工作方面是自治的，包括部署、扩展和服务特定资源管理。

这一自治性允许每个服务独立地做出反应以加载和扩展特定服务上的要求，而不会有一种设计由于单个服务的扩展需要的直接结果引起所有其它服务扩展或变化的需要。这意味着，如果特定国家中对所述视频媒体的需求增加，只有该视频媒体服务需要扩展该特定国家中的服务基础设施，同时不直接要求其它服务也一起扩展。要注意的是，也可能需要其它服务也同时扩展，但是这将会单纯地由该类型的需求、每个服务的扩展限制来驱动，而不需要联动式系统设计驱动。

在一些实施例中，这种扩展可以如下实现。

物理计算机资源(例如，物理存储器资源、物理处理资源)可以被独立于其它类型的服务地分配给每个类型的服务。例如，如果一个或多个第一类型的服务逻辑被配置为递送第一类型的服务，并且一个或多个第二类型的服务逻辑被配置为递送第二类型的服务，额外的资源可以被独立于第二类型服务地分配给该第一服务。

针对第一类型服务的资源分配可以用下面一个或多个方式增加(或减少)：

-通过部署额外的(或终止现有的)该类型的服务逻辑，即通过向第一类型的新的服务逻辑分配物理计算机资源(或收回针对该类型的现有服务逻辑的计算机资源)—这种方式的一个示例可以在Windows Azure^TM云平台上部署新的网络应用；

-通过增加(或减少)第一类型的一个或多个现有服务逻辑的组件中的虚拟机数量，即增加(或减少)该组件的计算机资源分配—这种方式的一个示例可以是修改WindowsAzure^TM云平台上的网络应用的网络角色或工作者角色中的实例数量；

-通过增加(或减少)第一类型的一个或多个现有服务逻辑的组件中的副本虚拟机的“尺寸”(也就是分配给它的各自的物理资源量)，即增加(或减少)分配给特定组件的每个这样的副本虚拟机各自的计算机资源—这种方式的一个示例可以是调整Windows Azure^TM云平台上的网络应用的网络角色或工作者角色的大小。

使用后两种技术，资源可以被分配给一个服务逻辑，独立于相同类型和不同类型二者的其它服务逻辑。例如，更多的VM可以被添加到第一类型的第一服务逻辑的组件，和/或那些组件的VM可以被调整大小，而不需要修改该类型的其它服务逻辑的组件，也无需修改不同类型的其它服务逻辑的组件。

此外，使用后两种技术，资源可以被相互独立地分配给相同服务逻辑的不同组件(例如，向一个添加VM或调整其VM的大小，而不修改其它的)。

每个数据中心320a、320b、320c等的DC控制块构成资源分配逻辑，可操作用于实现这些分配，因为每个控制块具有对其自己的数据中心内的物理资源使用的控制。如上所讨论的，资源分配通过向数据中心的外部控制块559提供配置信息而实现。

例如，呼叫控制器904、音频控制器906、视频控制器908、传输控制器910和管道控制器912中的任何一个可以被以这种方式相互独立地(也就是，无需其它被修改)并且独立于相同分布式平台800上运行的任何其它呼叫控制器、音频控制器、视频控制器、传输控制器和管道控制器地分配计算机资源。

例如，如果在特定国家中对所述视频媒体的需求增加，则只有部署在该国家的视频媒体服务逻辑需要扩展(通过在该国家中部署新的视频控制器服务逻辑或通过增加分配给该国家中运行的现有视频控制服务逻辑的资源)，同时不在其它服务上放置系统设计驱动需求以便一致地扩展。

此外，那些控制器的组件可以被独立于那些组件的其它组件分配资源。例如，呼叫控制器904的呼叫控制组件954可以被独立于内存存储组件分配资源，反之亦然，例如如果该呼叫控制组件954没有足够的已分配的处理资源来处理外部请求，但是内存存储组件有足够的已分配的处理资源来处理内部读/写请求，则无状态呼叫控制组件可以被分配更多的处理资源(通过向其添加更多VM或增加其VM的尺寸)而无需修改分配给内存存储组件的处理资源。类似地，额外的共享存储器资源可以被分配给内存存储组件以便使其能够存储更多的呼叫状态，而无需修改指派给该呼叫控制组件的每个VM的存储器资源(这可以是不必要的，因为该呼叫控制组件的每个VM在任何事物期间只需要存储最多单个呼叫状态或者其一部分)。

其它控制器的组件的资源分配可以被类似地独立地调整。

3.控制服务逻辑(控制器)故障和呼叫状态复制

公开了用于实现通过通信网络连接的端点之间的通信事件的通信系统，该通信系统包括：多个处理单元，每个处理单元具有对保存用于管理通信事件的可执行代码模块的计算机存储器的访问，所述代码模块被配置为实现用于建立通信事件和管理已建立的通信事件的一个或多个控制器；其中，该计算机存储器被划分为多个容错区域；其中，第一呼叫控制器实例被配置为访问该计算机存储器的第一容错区域以访问呼叫状态，该第一呼叫控制器实例被指派如此访问该呼叫状态作为对通过该网络接收到的第一指令的响应；并且其中，该呼叫状态的至少一部分在计算机存储器的第二容错区域中被复制，这样第二呼叫控制实例可以访问所述呼叫状态的该至少一部分，该第二呼叫控制器实例被指派访如此问该呼叫状态的至少一部分作为对通过网络接收到的第二指令的响应。

还公开了用于管理通过通信系统的通信网络连接的端点之间的通信事件的方法，该通信系统包括：多个处理单元，每个处理单元具有对保存用于管理通信事件的可执行代码模块的计算机存储器的访问，所述代码模块被配置为实现用于建立通信事件和管理已建立的通信事件的呼叫控制器，该计算机存储器被划分为多个容错区域，该方法包括：指派该呼叫控制器的第一实例推进通信事件的建立，作为响应，该第一呼叫控制器实例将该通信事件的呼叫状态存储在第一容错区域中；并且指派该呼叫控制器的第二实例进一步推进该通信事件的建立和/或管理已建立的通信事件，作为响应，该第二呼叫控制器实例访问第二容错区域中的该呼叫状态的至少一部分的复制品。

该第二容错区域不同于该第一容错区域。

在这一实施例中，该呼叫控制器的第二实例被指派访问该呼叫状态的至少一部分，作为对检测到的该第一呼叫控制器实例的状况的响应。该检测到的状况是：第一呼叫控制器实例的故障；第一呼叫控制器实例的退役；和该第一呼叫控制器实例具有对不足够处理该第二指令的处理单元的物理资源的访问等等之一。

所述处理单元还可以遍布多个容错区域分布，该第一和第二呼叫控制器实例在第一和第二容错区域中的各自处理单元上执行。该计算机存储器的容错区域可以基本上与处理单元的容错区域对准或不对准(也就是，这样处理单元集合和其可访问的计算机存储器集合与相同的故障源分离)。

在下面的示例中，第一实例是第一呼叫控制器的实例，而第二实例是不同数据中心处的第二呼叫控制器的实例(其可以具有与该第一呼叫控制器不同或相同的地理位置)。该计算机存储器和处理单元的容错区域基本对齐，因为二者都对应于处理单元集合和那些集合可访问的计算机存储器的部分所位于的数据中心。

根据本公开内容，用户设备包括：被配置为通过通信系统的通信网络从该通信系统的呼叫控制器接收指令的网络接口424，该呼叫控制器被配置为访问已建立的通信事件的呼叫状态；被配置为存储该呼叫状态的本地版本的计算机存储器426；以及被配置为执行具有对该呼叫状态的本地版本的访问的呼叫代理并且被配置为响应于从该通信控制器接收到的指令而更新该呼叫状态的本地版本的处理单元402。

上述为通信系统300“供电”的云800的控制系统是高性能的并且对故障有很好的容错性：如上所讨论的，特定服务逻辑的组件中的各个VM的故障由相关根VM 522和/或DC控制块556自动改正(见图5和所附文字)。

如上所指出的，服务逻辑的每个组件在DC控制块556的控制下，由运行在相同数据中心320处的多个各自的副本虚拟机(VM)上执行的副本代码实例实现。如果组件的那些VM之一发生故障(例如，由于该VM上执行的应用代码的软件故障、该VM自身的软件故障、它运行在其上的超管理器的软件故障、该超管理器运行在的服务器的硬件故障，该超管理器相对于该服务器本地运行或穿过该服务器所位于的整个故障域地运行所在的服务器的硬件故障)，这在该组件外部是“不可见的”：响应于该故障，负载均衡器停止向该VM转发请求并简单地将任何请求转发给该组件的剩余 VM中选择的一个VM(所有VM都能够处理这些请求)。

例如，呼叫的呼叫状态953由控制该呼叫的呼叫控制服务逻辑904的内存存储组件952存储在该呼叫控制服务逻辑在该内存存储组件的所有虚拟机共享的并且可访问的物理存储器资源中。如果那些虚拟机中的一个发生故障(例如，如上所述)，该呼叫状态953还是可以被通过任何其它虚拟机访问(例如，由呼叫控制组件954)，而该虚拟机在该呼叫控制器正在运行在的DC控制块556的控制下重新创建。

如果整个服务逻辑发生故障(例如，由于特定组件中的所有虚拟机因为无论什么原因的故障或由于整个数据中心的硬件或软件故障)，则业务管理器332可以根据请求选择相同的另一个服务逻辑来接管(例如，运行在不同数据中心处)。例如，如果媒体控制器906(音频)、908(视频)之一或者如果传输控制器(910)在各自的协商阶段期间发生故障(S1062、 S1072)，则呼叫控制器904响应于检测到的这一故障，可以从业务管理器 332请求该类型的替代服务逻辑的地址，并且可以指令该替代服务逻辑通过向其发送如S1060或1066中的会话创建消息重新开始讨论中的协商。然后音频、视频或传输协商可以重新开始，而无需重复较早的呼叫建立步骤(因为该音频、视频或传输控制器所需要的任何信息被维护在该呼叫控制器904 的呼叫状态953中)。

如下所讨论的，也复制其它服务的状态(例如，媒体模态控制器的媒体模态状态)有助于更快的恢复和更少的破坏可能是有益的。其它服务的状态可以用类似于呼叫状态复制的方式来复制，正如根据本公开内容的考虑将会显而易见的。

但是，根据呼叫控制器904的类似的故障，诸如该呼叫的呼叫状态953 之类的信息会被丢失(或者至少变为不可访问)。同时可以由业务管理器332 以如上方式选择新的呼叫控制器，如果该呼叫状态953被丢失，则可能需要从头创建新的呼叫，例如通过Alice或Bob的呼叫代理924之一从业务管理器332请求新的呼叫控制器的地址。

被处理的呼叫信号可以修改该呼叫的状态，其为了可靠性、扩展和恢复力可以推迟。这一推迟的呼叫状态通过呼叫信号处理组件从第一DC中的专用内存(例如，缓存)层读取该呼叫状态，处理与该呼叫有关的信令，以及将该呼叫状态的任何变化写入该缓存层来实现。在此，推迟呼叫状态意味着每次处理修改该呼叫状态的请求(而不是该呼叫状态被留存或维持在处理该命令的虚拟机中)，都从组件(例如，缓存层)的共享存储器资源读取/写入。

下面描述的是故障转移过程，借此控制呼叫的呼叫控制器的故障被改正而无需终止该呼叫。

呼叫状态是在状态变化时以基于事件的方式从第一容错区域(在此是第一数据中心(DC)，例如图3中的302a)复制到至少第二容错区域(在此至少是第二数据中心，例如图3中的302b)的，以确保如果该第一DC 发生故障，该呼叫能够被恢复、继续或者至少能够用正确的参与者列表重新开始。

根据本发明主题，每个呼叫的呼叫状态953或其至少一部分在多个呼叫控制器之间复制(也就是，遍布多个数据中心)。如果一个呼叫控制器发生故障，另一个呼叫控制器可以使用复制的呼叫状态接管，而不需要从头重新开始。

如上所讨论的，特定呼叫控制器的每个虚拟机是无状态的(无状态呼叫控制组件954的那些和内存存储组件952的那些)—被超出特定事务维护的关于该呼叫的唯一有用的信息被维护在内存存储组件952的共享存储器资源中存储的呼叫状态953中(而不是任何特定VM的单独指派的存储器资源中)。这些共享存储器资源地理上位于该组件(以及该呼叫控制器) 运行在的数据中心处。因此，该呼叫状态包含一个呼叫控制器能够无缝地从另一个进行接管(当呼叫期间一个呼叫控制器发生故障时)所要求的全部信息，初始发往该呼叫控制器的任何请求可以被重定向到存储副本(复制品)呼叫状态的另一个呼叫控制器，该副本呼叫状态包含足够所述其它呼叫控制器能够处理那些请求的信息。

现在将参考图11A、11B和11C描述呼叫状态复制处理。

图11A示出了第一呼叫控制器905a—运行在第一数据中心920a处—包括具有外部接口905a的第一无状态呼叫控制组件954a，以及具有内部接口 953a的内存存储组件952a。第一物理共享存储器资源集合被分配(由该呼叫控制器运行在的数据中心320a的DC控制块)给第一呼叫控制器905a 以便由该呼叫控制器905a的内存952a存储组件使用。这些物理存储器资源地理上位于第一数据中心920a处。该第一呼叫控制器905a通过向呼叫代理 924递送呼叫控制服务来控制呼叫(该呼叫代理924已经初始响应于从业务管理器332接收到该呼叫控制器的地址而从该呼叫控制器请求了该服务，已由业务管理器逻辑332至少部分基于存储器334中存储的呼叫控制器策略724[1]选择该呼叫控制器)。为此目的，该第一呼叫控制服务逻辑还与其他服务逻辑通信，例如音频控制器、视频控制器、传输控制器。呼叫状态 953a由内存存储组件953a存储。

第二呼叫控制器940b(运行在第二数据中心920b处)包括具有外部接口905b的第二无状态呼叫控制组件954b，以及具有内部接口955b的内存存储组件952b。第二物理共享存储器资源集合被分配(由该呼叫控制器运行在的数据中心320b的DC控制器块)给该第二呼叫控制器905b以便由该呼叫控制器905b的内存存储组件952b使用。这些物理存储器资源地理上位于第一数据中心920a处。

该第一和第二物理存储器资源集合位于不同地理位置(也就是每一个位于不同于另一个的地理位置)，该第一和第二数据中心320a、320b位于不同地理位置。例如，它们可以位于一个国家的不同州或地区、在不同国家、在不同大洲上、在不同时区或者分开为使得对二者都产生影响(即影响其操作)的单个运动事件(例如，地震、战争)不太可能发生。

现在将参考图11C描述呼叫状态复制的处理。

如上所讨论的，一旦接收到初始呼叫创建消息，该第一呼叫控制组件 905a创建呼叫状态952b(包括该呼叫在该通信系统300中唯一的标识符)，通过接口955a将创建的呼叫状态发送给内存存储组件952a以便存储，并且发起向呼叫代理924的呼叫控制服务的递送(S1102)。该呼叫控制组件905a 还向第二呼叫控制器954b发送新创建的呼叫状态的副本952b(例如，至少通过向其发出指令)—尤其是通过接口905b向第二呼叫控制组件954b发送；作为响应，该呼叫控制组件954b将接收到的呼叫状态发送给第二内存存储组件，它将该呼叫状态副本953b存储在该第二内存存储组件952b的共享物理存储器资源中。

在呼叫控制服务的递送过程中，响应于事件(例如，图10A和10B中的S1006、S1012、S1020、S1088)，该呼叫控制组件954a(尤其是指派给它的呼叫控制器实例)通过与内存存储组件952a通信来更新(S1104)该呼叫状态953a(通过修改其至少一部分)。该呼叫控制组件还可操作用于通过第二呼叫控制组件954b的外部接口905b(例如，至少通过向其发送指令)向该第二呼叫控制器904b发送(S1108)更新后的呼叫状态953a的至少一部分的副本。发送的这一部分更新后的呼叫状态包括该呼叫的标识符。响应于接收到该呼叫状态，第二呼叫控制组件954b(尤其是，指派给它的呼叫控制器实例)将更新后的呼叫状态转发以便由此存储；该第二内存存储组件952b根据所述更新修改该呼叫状态副本953b(使用该呼叫标识符识别出的)。

该第一呼叫控制组件可以响应于更新第一区域中的该呼叫状态作为对多个这种指令和/或响应的响应，但是更新第二区域中的该呼叫状态的至少一部分作为只对所述多个指令和/或响应的选择(也就是至少一个但不是全部)的响应。例如，只响应于对示出的导致图10A和10B中的呼叫状态更新的一些指令才更新呼叫状态副本953b(例如，仅被称为如上标题1.2.1呼叫控制器下的第一到第八指令的指令的选择)。所述指令的选择可以依赖于该呼叫的一个或多个参数(下面讨论)。这一粒度在对控制器故障的恢复性 (随着该呼叫状态的更多部分被复制(例如，在低端)能提供更好的可靠性，使得如果例如控制器发生故障，终止的呼叫能够重新开始，并且在高端处用从发生故障的控制器向新控制器的或多或少的无缝“切换”彻底避免该呼叫被终止)和存储器节省(越少的呼叫状态复制要求越少的计算机存储)之间提供可调整的平衡。

如果该第一呼叫控制器发生故障(图11B中以图表描绘的)，该呼叫控制服务的递送由第二呼叫控制器904b如下所解释地使用呼叫状态副本953b 继续。

第一呼叫控制器的这一故障(即，其第一实例的故障)是可由呼叫代理924检测到的，例如由于与第一呼叫控制器904的现有连接意外地终止和/或由于发往其的请求消息在大于超时周期后还没有被响应。第一呼叫控制器的这一故障还可由业务管理器332基于从该第一呼叫控制器运行在的数据中心320的资源报告块(例如，图5B的558)的报告来检测。响应于检测到这一故障，该业务管理器被配置为基于呼叫控制器策略722[1]，用第二呼叫控制器的地址响应于针对已经导致该第一呼叫控制器可用时被选择的呼叫控制器的地址的任何请求。

响应于呼叫代理924的这一检测，呼叫代理924再次从业务管理器332 请求呼叫控制器的地址。该请求可以指示第一呼叫控制器是无反应的并且指示应该返回不同呼叫控制器的地址，或者该请求可以不指定这些(并且可以依赖于该业务管理332也检测到该第一组件的故障)。无论哪种方式，作为响应，业务管理器332返回第二呼叫控制器904b的地址，其可以用于通过接口905与第二呼叫控制组件954b建立连接。

然后，该服务代理924可以发送包括该呼叫标识符的任何请求，所述请求本来应该被发送到第一呼叫控制器904a(如果其没有失败的话)，替代地被发送到第二呼叫控制器904b。该第二呼叫控制器使用呼叫状态副本 953b处理这些请求，该呼叫状态副本是使用这些请求的呼叫标识符识别出来的。这可以包括继续建立该通信事件(如果其还没有被建立)和/或一旦已经建立则管理该通信事件(通过第一和第二呼叫控制器之一)。

在一些实施例中，呼叫状态副本953b可能不是呼叫状态953a的完整副本，即初始呼叫状态可能包含比该副本更多的信息，该副本只包含关于该呼叫的选择性的信息。在这种情况中，呼叫状态953a创建时，由第一呼叫控制器向第二呼叫控制器发送初始副本只是该呼叫状态的一部分的副本，其包含足够使该呼叫即使第一呼叫控制器发生故障也能继续进行的信息，而不是包含该呼叫的每个单独参数(一旦第一呼叫控制器发生故障，这些参数可以被重置)。作为替代或者另外，第一呼叫控制器可以只向第二呼叫控制器发送消息以更新该呼叫状态副本953b，作为对一些事件而不是其它事件的响应(这样一些事件导致“主”呼叫状态953a而不是副本953b 的更新)。在这种情况中，副本953b包含足够的信息使得一旦第一呼叫控制组件发生故障，即使一些最近的历史被丢失该呼叫也能够继续进行。相比完全呼叫状态复制，前者要求更多存储器资源而后者要求更多网络资源，但是与完全复制相比，二者都易于造成第一呼叫控制器发生故障的话呼叫信息的一些丢失。

呼叫状态中的多少要被复制可以取决于该呼叫的一个或多个参数。也就是，在一个实施例中，该呼叫控制器被配置为基于该通信事件的一个或多个参数为所述复制选择该呼叫状态的至少一部分。所述参数可以包括与参与该呼叫事件的一个或多个用户相关联的一个或多个优先级参数(例如，具有较高优先级的用户是那些已为优质服务付费的用户，而较低优先级用户是那些没有为优质服务付费的用户)，所选择的该呼叫状态的至少一部分组成较高优先级参数的呼叫状态的主要部分和较低优先级参数的呼叫状态的一小部分。在这种情况中，由该通信系统300的运营商向用户指派质量参数。

作为替代或者另外，所述参数可以包括该通信事件当前过去的时间(也就是从该通信事件建立的时间量或从首次创建该呼叫状态的时间量)，该呼叫状态的至少一部分组成针对较长的过去时间的呼叫状态的主要部分和针对较短的过去时间的呼叫状态一小部分。

所述参数构成该呼叫状态的一部分，这样该呼叫状态本身指示该呼叫状态中的多少应该被复制。

所复制的该呼叫状态的至少一部分可以，例如包括参与该通信事件的一个或多个用户的各自标识符和/或一个或多个所述端点的各自标识符。这至少使该呼叫能够在原始呼叫状态变得不可访问的事件中重新开始。所述呼叫状态的至少一部分定义了所述用户之间的关系，例如将所述用户之一识别为该呼叫的主持人(或拥有者)。

所复制的该呼叫状态的至少一部分可以包括从媒体模态控制器接收到的(例如，在该呼叫的建立期间)该通信事件的媒体模态状态数据(如上所描述的)。例如，该媒体模态(例如，音频或视频)状态数据可以包括一个或多个媒体模态(例如，音频或视频)针对每个用户是否活跃的各自指示(例如，各自的音频对一个或多个参与用户是否静音、或各自的视频对一个或多个参与用户是否启用的指示)。该呼叫控制器(例如，其第二实例) 可以从第二区域中的呼叫状态的至少一部分向该媒体控制器提供媒体模态状态数据，作为响应，该媒体模态控制器的实例被指派用于基于所提供的媒体模态状态数据向端点传送媒体模态控制信号(就像媒体模态状态数据已经从第一区域中的原始呼叫状态提供(例如，由第一呼叫控制器实例) 一样)。

服务解耦意味着无论什么检测出状况造成了第一呼叫控制器的故障，该状况都不会影响提供该媒体模态状态数据的媒体模态控制器。因此，该媒体模态控制器可以继续工作以便在检测出的条件之后管理该通信事件的媒体模态。

所复制的该呼叫状态的至少一部分可以基于参数被选择为包括下面之一：通信事件的媒体模态状态数据和参与该通信事件的一个或多个用户的各自标识符和/或一个或多个所述端点的各自标识符(例如，针对较高优先级用户/较长的过去时间)，或者所述标识符而不是所述媒体模态状态数据 (例如，针对较低优先级用户/较短的过去时间)。

因此，复制可以被基于参数调节以根据需要提供不同水平的健壮性。例如，基于一个或多个参数，所述呼叫状态的至少一部分可以被选择为组成下面之一：

-该呼叫状态的第一部分，借此如果该第一容错区域变得不可访问，则呼叫控制器能够使用该第一部分继续管理该通信事件而无需终止该通信事件，或者

-该呼叫状态的第二部分，借此如果第一容错区域变得不可访问且该通信被终止作为响应，则该呼叫控制器能够使用该第二部分重新建立该通信事件。

该呼叫状态的第一部分可以，例如组成该呼叫状态的整体，从而该呼叫状态的整体被复制在第二容错区域中。

3.1复制媒体模态状态

在实施例中，第一媒体模态控制器实例被配置为访问计算机存储器的第三容错区域以访问媒体模态状态，该第一媒体模态控制器实例被指派访问该媒体模态状态作为对通过网络接收到的第三指令的响应；并且其中，在该计算机存储器的第四容错区域中复制该媒体模态状态的至少一部分，这样第二媒体模态控制器实例能够访问该媒体模态状态的至少一部分，该第二媒体模态控制器实例被指派为如此访问该媒体模态状态的至少一部分作为对通过网络接收到的第四指令的响应。

该媒体模态控制器可以被配置为向该呼叫控制器的第一实例提供媒体模态状态数据，作为响应，第一区域中的呼叫状态和第二区域中的该呼叫状态的至少一部分被基于该媒体模态状态数据更新。该媒体模态控制器的第二实例可以被指派访问该媒体模态状态的至少一部分作为对检测到的该第一媒体模态控制器实例的状况的响应。所检测出的状况可以是下面之一：第一媒体模态控制器实例的故障；该媒体模态呼叫控制器实例的退役；以及该媒体模态控制器的第一实例具有对不足够处理该第二指令的处理单元的物理资源的访问。该呼叫控制器可以接着检测到的状况继续工作以建立该通信事件和/或管理已建立的通信事件。

媒体模态状态可以用等效于上述呼叫状态复制的方式来复制，正如将会显而易见的(呼叫控制器替代媒体模态控制器，并且呼叫状态替代媒体模态状态)。

第三容错区域不同于第四容错区域。该第三和第四容错区域可以与在其中维护该呼叫状态及其复制品的第一和/或第二容错区域不同或相同。

3.2虚拟缓存实现

公开了一种在包括不同地理位置处的多个处理单元的通信系统中复制数据的方法，每个处理单元具有对在该地理位置处的计算机存储器的访问，该计算机存储器保存用于实现虚拟缓存的各自代码模块，该方法包括：向所述处理单元的第一个发送第一存储指令，作为响应，该处理单元上的该虚拟缓存的第一实例访问第一处理单元的计算机存储器以存储数据；并且作为对其响应，向不同于该第一个的地理位置处的所述处理单元的第二个发送第二存储指令，作为响应，该处理单元上的第二虚拟缓存实例访问该第二处理单元的计算机存储器以复制所述数据。

所述数据可以包括在通信系统的两个或多个端点之间进行的通信事件的呼叫状态的至少一部分。

4.独立的可部署代理

上面已经参考每个都具有完整代理“栈”(呼叫、媒体(例如音频和视频)、传输、管道)的端点进行了描述，该通信系统架构的解耦和特性将其自身提供给单独不同设备上的代理的部署。例如，呼叫控制代理可以被部署在用户的一个设备上，媒体代理部署在该用户的另一个设备上；该呼叫控制器能够简单地向媒体控制器提供所述其它设备的标识符并且它们将在该设备和所述其它呼叫端点之间创建合适的媒体会话，而该媒体控制器永远不需要知道该控制用户设备的存在。此外，所述其它用户设备可以具有最小化的或者没有呼叫控制逻辑，并且能够简单地动作以接收和捕捉视频，所有呼叫控制通过该呼叫控制器和控制设备之间的交互来处理。

部署在不同设备上的代理与它们各自的控制器交互，并且实现对相互的间接控制，就像它们被部署在同一个设备上时所做的那样(如上所描述的)。

公开了用于实现包括第一和第二计算机设备的计算机系统和通过通信网络连接的一个或多个额外的端点之间的通信事件的通信系统，该通信系统包括：多个处理单元，每个具有对保存用于管理通信事件的可执行代码模块的计算机存储器的访问，该代码模块被配置为实现被配置为管理已建立的通信事件的媒体模态的媒体模态控制器和被配置为建立该通信事件的呼叫控制器；其中，响应于由该呼叫控制器向媒体控制器发起的指令，媒体模态控制器的实例被指派，以便将该通信事件的媒体模态控制器信号传输给第一设备上的媒体代理，而无需访问第二设备上的呼叫代理；并且其中，该呼叫控制器发起的指令是对通过网络从第二设备上的呼叫代理接收到的指令的响应的。

还公开了用于实现包括第一和第二计算机设备的计算机系统和通过通信系统的通信网络连接的一个或多个额外的端点之间的通信事件的方法，该通信系统包括：多个处理单元，每个具有对保存用于管理通信事件的可执行代码模块的计算机存储器的访问，该代码模块被配置为实现被配置为管理已建立的通信事件的媒体模态的媒体模态控制器和被配置为建立该通信事件的呼叫控制器，该方法包括：该呼叫控制器向媒体控制器发起指令，作为对通过网络从该第二设备上的呼叫代理接收到的指令的响应；并且作为对该呼叫控制器发起的指令的响应，指派媒体模态控制器的实例将该通信事件的媒体模态控制信号传送给第一设备上的媒体代理而无需访问该第二设备上的呼叫代理。

该呼叫控制器可以被配置为将第一设备的标识符发送给媒体模态控制器，作为对从第二设备上的呼叫代理接收到的指令的响应，由该媒体模态控制器实例进行的所述媒体模态控制信号的传送基于该标识符。

还公开了包括第一和第二计算机设备的计算机系统。该第一计算机设备包括：被配置为通过通信系统的通信网络与该通信系统的媒体模态控制器通信的网络接口，该媒体模态控制器被配置为管理已建立的通信事件的媒体模态，该媒体模态控制器响应于来自该通信系统的通信控制器的指令；以及被配置为执行媒体模态代理的处理单元，该媒体模态代理被配置为与该媒体模态控制器而不与通信控制器通信。该第二计算机设备包括：被配置为通过网络与呼叫控制器通信的网络接口，该呼叫控制器被配置为建立该通信事件；以及被配置为执行呼叫代理的处理单元，该呼叫代理被配置为与呼叫控制器通信并通过与呼叫控制器的所述通信间接控制该第一用户设备的媒体模态代理的操作。

因此该第二设备的呼叫代理以如上所描述的方式间接地控制第一设备上的媒体代理。

在现有通信系统中，为了用户能够同时使用多于一个设备(例如，智能手机和电视)参与呼叫(例如，该智能手机用于呼叫音频，TV用于呼叫视频)，除非那些设备通过有线或无线网络(包括蓝牙及类似的)直接连接，否则在两个设备处都需要完整的实时控制栈，包括呼叫控制、媒体控制、媒体和网络栈以及用户层面的认证。这一完整栈包括需要被部署到端点的用户和特征两者服务递送控制逻辑，由于处理和安全性约束使其成为更复杂和约束性的选择。

本发明主题允许特定“模态”的用户一侧逻辑(也就是，媒体服务的类型，例如用于提供实时媒体通信事件的特定特征的用户一侧逻辑，诸如呼叫音频、呼叫视频和诸如屏幕分享或针对很大的高分辨率屏幕定制的呼叫视频之类更丰富的特征)被单独地安装在不同设备处作为模态代理(也就是，该类型的服务代理)，与任何必要的媒体和网络栈一起安装在设备或端点上，使得它能够被媒体控制器发现，并且从而在功能性服务递送的上下文中(例如在呼叫中)被用作有效的模态端点。

在通信设置中考虑关于媒体的更多要求高的使用情况时，关于音频和视频二者(以及例如屏幕分享和其它模态)利用能够提高和丰富特定模态的体验的专门设备和其它端点(诸如在大屏幕TV上而不是该呼叫控制运行在的平板电脑上观看接收到的视频)是很有效的工具。

作为上述解耦合的服务逻辑设计的一部分，服务代理可以被部署到提供自动可发现基础设施点的端点，以提高和扩展该特定服务的能力(例如，音频、视频或诸如屏幕分享和高分辨率视频之类的丰富的服务)以及更广的功能、端到端服务递送和能力。

代理可以被配置为以独立的方式部署在端点处(用户设备)。部署可以是作为OS层中的嵌入式代理，或者作为运行在这一OS之上(例如，也就是通过应用商店类型模型“空中”递送的)的应用。所部属的代理被配置为知道关于要向该模态类型的相应云服务逻辑注册的设备的足够信息，反过来该设备能够通知上下文服务或客户端关于针对特定模态该端点用于呼叫或其它上下文服务中的可用性。

该媒体代理启动后连接到该类型相应的控制服务逻辑(例如视频)用关于如何被该服务逻辑联系、其模态专用能力是什么的足够的信息和其它相关信息注册到所述端点。该代理需要用必要的媒体被部署在网络栈上以便允许其执行预期的模态功能。

这意味着“视频输出代理”可以被部署在例如电视机上，该电视机将它自己注册在网络上，并且如果客户端(例如，用户设备304a上的客户端416a 或用户设备304b上的客户端416b)正在使用同一个设备作为电视机(例如，如果二者都连接到公用无线路由器)，该客户端能够将活跃呼叫的输入视频输出并呈现在该电视机上。这不会要求电视机上有用户一侧呼叫控制逻辑 (即，没有呼叫代理)并且该电视机可以完全根据云800的视频媒体服务逻辑控制(例如，作为对来自客户端416的控制数据的响应)。这一关系可以通过其它途径建立，诸如预先配置的关系。假设有路径用于发送媒体，这可以远程使用。

现在参考图12对其进行描述。如图12中所示，不同类型的代理(例如，呼叫代理、音频代理、视频代理、传输代理、管道代理)被相互独立地部署在不同设备处。例如，图12示出用户302的(第二)用户设备304 实现：第一类型的服务代理612[1]、第二类型的服务代理612[2]，和注册和导入请求块934，所有这些构成客户端416的一部分；以及另一个(第一)用户设备304’实现第一类型的另一个服务代理612’[1]而无需实现第二类型的另一个服务代理，和另一个注册和导入请求块934’，它们可以构成在其它设备304’处执行的另一个客户端的一部分或者替代地嵌入其它设备304’处执行的操作系统中。该设备304和其它设备304’二者都可以实现其它服务代理(虽然该其它服务不实现该第二类型的服务代理)。

注册块934、934’可以与分布式平台808的注册和导出请求逻辑914通信。每个可操作用于将用户设备304和其它用户设备304’的地址分别向注册和导出请求逻辑914注册。

如上所述，第一服务逻辑能够使用云800的注册和导出请求逻辑914 所存储的地址建立到第一类型的服务代理612[1]和到第一类型的其它服务代理612’[1]的数据连接，并且第二服务逻辑602[2]能够建立到第二类型的服务代理612[2]的数据连接。类似地，服务代理612[1]和612’[1]能够建立到第一服务逻辑602[1]的数据连接，并且该服务代理612[2]能够建立到第二服务逻辑602[2]的数据连接。

该用户设备304的注册块935如上所描述的工作(即，注册用户302 的用户名和设备304的可能的设备标识符)。其它用户设备304’的其它注册块934’可以用类似的方式工作，或者其可以将其它用户设备的地址注册为公开可访问的(也就是，可由其它设备304的附近的任何用户使用的)，例如通过向注册逻辑914(该逻辑存储与设备304’的地址相关联的标识符)注册该设备的标识符。

例如，在这一实施例中，用户设备304和其它用户设备304’二者都连接到公共无线接入点1202(例如，二者都可以通过该接入点1202连接到网络301)。用户设备的注册块934和其它用户设备的注册块943’二者可操作用于(例如，一旦启动)向云注册逻辑914注册这一接入点的标识符(例如，MAC地址)。该客户端注册逻辑(或其它检测逻辑)可操作用于检测两个设备都已经注册这一公共接入点，并且作为对这一检测的响应，通知该客户端416，该客户端在该事件中通知用户设备302。

一旦创建或加入呼叫，用户302然后可以指定不是将第一类型的控制服务(例如，音频或视频)扩展到它们的用户设备304处的相应代理(例如，音频代理或视频代理)，服务应该被替代地扩展到其它用户设备304’ (并且不是在该用户设备304处)处实现的相应代理。作为替代或者另外，在呼叫期间，用户102可以指定它们想要将已经被扩展到用户设备304的代理的服务转移到用户设备304’的相应代理。然后，该服务逻辑以上述方式与其它用户设备的服务代理和其它服务逻辑通信以创建借此呼叫数据能够在该代理和其它呼叫参与者之间流动的机制。

用户设备304的第一类型服务代理612[1]能够通过与第一服务逻辑 602[1]建立数据连接与其它用户设备304’的第二类型服务代理612’[2]通信，作为响应，该第一服务逻辑602[1]与该第二服务逻辑602[2]建立数据连接，作为响应，该第二服务逻辑602[2]使用注册逻辑914存储的关于该用户设备304’的信息与其它用户设备304’的第二类型服务代理612’[2]建立连接。这在图12A中描绘了。

例如，在一个实施例中，(第二)用户设备304实现完整的代理集合，即第一呼叫代理、第一音频代理、第一视频代理、第一传输代理和第一管道代理；其它用户设备304’不实现呼叫代理，而是只实现第二传输代理、第二管道代理和至少一个第二媒体代理(音频代理和/或视频代理)。

用户302可以指定一旦创建或加入呼叫，他们期望至少一个媒体(例如，视频)控制服务要被扩展到其它(第一)用户设备304’的相应媒体代理而不是用户设备304的相应媒体代理。在这种情况中，用户设备104的客户端代理向呼叫控制器指定这一决定并向其提供其它设备304’的标识符。然后，该呼叫控制器指令相应媒体(例如，视频)控制器与其它设备304’的媒体(视频)代理(而不是与设备304的任何媒体代理)协商(使用注册逻辑914存储的与其它设备304’有关的信息)媒体(例如，视频)参数。类似地，它指示该传输控制器创建用于与其它呼叫参与者交换该类型的实时媒体(例如，视频)的传输机制；反过来该传输控制器指令管道控制器为该类型的媒体(例如，视频)创建其它用户设备304’的相应媒体(例如，视频)代理(而不是，例如设备304的视频代理)之间的管道。

用于建立媒体(音频、视频)管道的处理与上面参考图10A和10B描述的相同，差别在于参与该处理的媒体代理926、928之一或二者被实现在设备304’处，并且那些管道是通过与在其它设备304’处实现的传输代理和管道代理的控制数据的传输建立的。也就是，在实施例中，代理924、926、 928的任何一个都可以运行在不同设备上(即，总共3个设备)，或者任何两个代理可以运行在同一个设备上而剩余的第三个代理运行在一个不同设备上(即，总共2个设备)。具有媒体代理(例如，926、928)的任何设备将还需要运行传输和管道代理以便实现媒体的传输。只有一个设备需要以呼叫代理的形式运行呼叫控制逻辑，并且整个呼叫可以是使用该设备的控制器(其它设备仅仅用作媒体“从属”)—其它设备不需要运行呼叫代理(或任何其它形式的呼叫控制逻辑)。在设备只运行呼叫代理(所有媒体代理运行在其它设备上)时，该设备不需要运行管道或传输代理(因为不会有媒体向/从该设备发送，只有控制信号向/从该呼叫控制器发送)。

第二设备可以因此运行呼叫代理(但是可能不运行媒体代理)，同时第一设备运行媒体代理(音频/视频)而不运行呼叫代理。该第二设备可以运行另一个类型的另一个媒体代理(视频/音频)并且该第一设备可以运行或不运行该类型的另一个媒体代理；或者第三设备可以运行其它媒体代理(视频/音频)并且第一和/或第二设备可以不运行该类型的媒体代理(视频/音频)。例如，TV可以接收呼叫视频并运行视频代理而不是呼叫代理，并且由智能手机上的呼叫代理控制。该智能手机可以接收呼叫音频并运行音频代理，或者它可以不接收，并且例如连接到该网络的扬声器系统可以接收呼叫音频并运行呼叫代理(而不是呼叫代理或视频代理)。

媒体被递送给除了控制该呼叫的设备之外的设备这个事实是对媒体和传输控制器不可见的。对前面提到的呼叫建立的唯一修改是呼叫控制器向媒体/传输控制器提供其它设备的端点标识符。

例如，用于传输呼叫的实时音频数据的音频管道可以通过传输控制器和管道控制器分别与如图10A和10B中的用户设备304处实现的客户端416 的传输代理和管道代理传输控制数据来建立，而用于传输该呼叫的实时视频数据的视频管道可以通过传输控制器和管道控制器分别与如图10A和 10B中的其它设备304’处实现的传输代理和管道代理传输控制数据来建立。

呼叫控制通过呼叫控制器与设备304的呼叫代理交互而实现，并且该呼叫代理能够通过该呼叫控制器与其它设备304’上的代理通信，反过来所述呼叫控制器能够通过相应云控制器与那些代理通信。因此，不需要其它用户设备304’实现任何形式的呼叫控制代理或任何其它形式的呼叫控制逻辑。

该通信系统可以包括任何形式的检测逻辑，其被配置为检测第一和第二设备的关联性，作为响应，该检测逻辑致使向第二设备上的呼叫代理发送通知。例如，这一检测逻辑可以被实现在传输层面(例如，由于第一和第二设备连接到公共接入点1020而在传输层面出现所述关联性)，例如作为传输控制器的一部分或可由该传输控制器访问，该传输控制器通知呼叫控制器(或者其通知媒体控制器，媒体控制器通知传输控制器)关于所检测到的关联性—然后该呼叫控制器通知用户设备上的呼叫代理。也就是，在实施例中，通信系统的检测逻辑执行下面之一：通知呼叫控制器，作为响应，该呼叫控制器发送所述通知；或者通知媒体模态控制器，作为响应，该媒体模态控制器通知呼叫控制器，并且作为响应，该呼叫控制器发送所述通知。在这种情况中该检测逻辑可以是传输控制器的一部分。

作为替代，呼叫控制器可以检测较高层级的关联性。例如，用户可以通过共享的秘密创建第一和第二设备之间的关联性，例如共享的秘密是从第一设备输出的(例如，显示的)并且在第二设备处输入的配对代码，或者每个设备可以与公共用户302相关联(例如，如果该用户在两个设备处都登录了)。该检测逻辑在这种情况中可以是呼叫控制器的一部分。

为了提供隐私性和安全性，呼叫控制器可以只基于指示何时第一设备可以和不可以用如上所述方式使用的策略(例如，该策略包括允许的用户 (例如，302)的标识符和/或允许的用户设备的标识符(例如，第一设备 304的标识符))，有条件地允许第一设备这样的使用。该呼叫控制器被配置为访问计算机存储器以访问该策略，由呼叫控制器向所述媒体模态控制器发起指令依赖于该策略。该策略可以指示第二设备304和/或第二设备的用户402被(或不被)允许使用该第一设备。

当通信系统包括分别被配置为管理不同媒体模态的所述媒体模态控制器和另一个媒体模态控制器(例如，音频和视频)时，第一设备上的第一媒体代理(例如，视频)可以被用于使得例如该呼叫的视频被发送给第二设备，并且第二设备上的第二媒体代理(例如，音频)可以被用于使得例如音频(和呼叫控制器)被保留在第二设备上。

作为替代，例如，第一设备304’上的音频和视频代理可以只用呼叫控制部署，该呼叫控制通过第二设备304(执行呼叫代理)而实现。

作为替代，第三用户设备(未示出)可以运行，例如视频，而第二设备运行，例如音频。

通信系统包括第一和第二媒体模态控制器(例如，音频和视频)，它们被配置为管理已建立的通信事件的各自的第一和第二媒体模态而无需访问第二设备上的呼叫代理的情形。该第一媒体模态控制器的实例可以被配置为将该通信事件的第一媒体模态控制信号传送给第一设备上的第一媒体代理而无需访问该计算机系统的第二或第三计算机设备上的第二媒体代理；并且该第二媒体模态控制器的实例被配置为将该通信事件的第二媒体模态控制信号传送给第二媒体代理而无需访问该第一媒体代理。第一和第二媒体模态控制器的各自实例可以分别被指派用于传送该第一和第二媒体模态控制信号，作为对呼叫控制器向第一和第二媒体模态控制器发起的各自指令的响应。针对该第一媒体模态控制器的指令是由呼叫控制器响应于从第二设备上的呼叫代理接收到的第一指令而发起的，并且其中，针对第二媒体模态控制器的指令是由呼叫控制器响应于从第二设备上的呼叫代理接收到的第一或第二指令而发起的。作为对第一媒体模态控制器实例对向它发起的指令返回响应的响应，该第一媒体模态控制器实例可以从所述指派释放，而该第二媒体模态控制器实例继续工作以与该第二媒体代理通信。

在实施例中，呼叫控制器可以被配置为将第一设备的标识符发送给媒体模态控制器作为对从第二设备上的呼叫代理接收到的指令的响应，由所述媒体模态控制器实例进行的所述媒体模态控制信号的传送基于该标识符。

作为对该媒体模态控制器实例返回对呼叫控制器发起的指令的响应的响应，该媒体模态控制器实例可以从所述指派释放，而该呼叫控制器继续工作以与第二设备上的呼叫代理通信。呼叫控制器的实例可以向该媒体控制器发起指令并且该呼叫控制器的实例可以在该媒体控制器的实例释放之后继续工作以与该第二设备上的呼叫代理通信。

对比在上文中，在其上实例化控制器的通信系统的处理单元距离呼叫端点很远(也就是所述处理单元是除了所述端点之外的处理单元)，在替代实施例中，一些控制还是可能通过端点而实现(也就是通过端点上的控制器代码而实现)。例如，在一个实施例中，呼叫控制、音频控制、媒体控制、传输控制和管道控制而以如上所述的集中实现在云800中，而例如即时消息控制被实现在端点本身上(并且不是由云控制服务逻辑实现)。

此外，对比在上文中，各种不同配置的代理(呼叫、媒体、传输、管道)由用户设备实现，在其它实施例中，除了用户设备之外的端点(例如，服务器、桥接等)可以实现一个或多个上述代理。

一般来讲，本申请中描述的任何功能可以使用软件、固件、硬件(例如，固定的逻辑电路)或这些实现的组合来实现。本申请中使用的术语“模块”、“功能单元”、“组件”和“逻辑”一般代表软件、固件、硬件或它们的组合。在软件实现的情况中，模块、功能单元或逻辑代表在处理器(例如，一个或多个CPU)上执行时执行指定任务的程序代码。所述程序代码可以存储在一个或多个计算机可读存储器设备中。下面描述的技术的特征是平台无关的，意味着所述技术可以实现在具有各种处理器的各种商业计算平台上。

例如，所述用户设备还可以包括使得用户设备的硬件执行操作(例如处理器功能块等等)的实体(例如，软件)。例如，所述用户设备可以包括计算机可读介质，其可以被配置为保存使得用户设备，更具体地是使得操作系统和该用户设备相关联的硬件执行操作的指令。因此，所述指令的功能是配置操作系统和相关联的硬件以执行操作并且以此方式致使操作系统和相关联的硬件转换到执行功能。所述指令可以由计算机可读介质通过各种不同配置向用户设备提供。

计算机可读介质的一个这种配置是信号承载介质并且因此被配置为向计算设备发送指令(例如，作为载波波形)，诸如通过网络。该计算机可读介质还可以被配置为计算机可读存储介质并且因此不是信号承载介质。计算机可读存储介质的示例包括随机访问存储器(RAM)、只读存储器 (ROM)、光盘、闪存、硬盘存储器和可以使用电磁、光学和其它技术来存储指令和其它数据的其它存储器设备。

虽然已经用特定于结构化特征和/或方法化动作的语言描述了本发明主题，但是应该理解的是，所附权利要求中定义的本发明主题不必要仅限于上面描述的特定特征或动作。而是，上面所描述的特定特征和动作是作为实现权利要求的示例形式公开的。

Claims (15)

1.一种用于实现包括第一设备和第二设备的计算机系统与通过通信网络连接的一个或多个额外端点之间的通信事件的通信系统，所述通信系统包括：

多个处理单元，每个处理单元具有对保存用于管理通信事件的可执行代码模块的计算机存储器的访问，所述代码模块被配置为实现被配置为管理已建立的通信事件的媒体模态的媒体模态控制器和被配置为建立所述通信事件的呼叫控制器；

其中，所述媒体模态控制器的实例是响应于由所述呼叫控制器向所述媒体模态控制器发起的指令而指派的，以无需访问所述第二设备上的呼叫代理而将所述通信事件的媒体模态控制信号传送给所述第一设备上的媒体代理；以及

其中，所述由所述呼叫控制器发起所述指令是响应于通过所述网络从所述第二设备上的所述呼叫代理接收到的指令的。

2.如权利要求1所述的通信系统，还包括：被配置为检测所述第一和第二设备的关联性的检测逻辑，作为对此的响应，所述检测逻辑致使向所述第二设备上的所述呼叫代理发送通知。

3.如权利要求2所述的通信系统，其中，所述检测包括：检测所述第一和第二设备连接到所述网络的公共接入点。

4.如权利要求1所述的通信系统，其中，所述呼叫控制器被配置为：响应于从所述第二设备上的所述呼叫代理接收到的指令，向所述媒体模态控制器发送所述第一设备的标识符，由所述媒体模态控制器实例进行的媒体模态控制信号的所述传送是基于所述标识符的。

5.如权利要求1所述的通信系统，其中，所述计算机系统中的每个设备是与公共用户相关联的。

6.如权利要求2所述的通信系统，其中，所述检测逻辑执行以下各项之一：通知所述呼叫控制器，作为对此的响应，所述呼叫控制器发送所述通知；或者通知所述媒体模态控制器，作为对此的响应，所述媒体模态控制器通知所述呼叫控制器，并且作为对此的响应，所述呼叫控制器发送所述通知。

7.如权利要求1所述的通信系统，其中，所述代码模块被配置为：实现用于管理所述通信事件的所述媒体的传输的传输控制器。

8.如权利要求1所述的通信系统，其中，所述呼叫控制器被配置为：访问所述计算机存储器以访问策略，所述由所述呼叫控制器向所述媒体模态控制器发起所述指令是依赖于所述策略的。

9.一种用于实现包括第一设备和第二设备的计算机系统与通过通信系统的通信网络连接的一个或多个额外端点之间的通信事件的方法，所述通信系统包括被配置为管理已建立的通信事件的媒体模态的媒体模态控制器和被配置为建立所述通信事件的呼叫控制器，所述媒体模态控制器是响应于来自所述呼叫控制器的指令的，所述第一设备被配置为执行媒体模态代理，所述媒体模态代理被配置为通过所述通信网络与所述媒体模态控制器而不与所述呼叫控制器通信，所述第二设备被配置为执行呼叫代理，所述呼叫代理被配置为与所述呼叫控制器通信，所述方法包括：

所述第二设备的所述呼叫代理向所述呼叫控制器发起指令以间接地控制所述第一设备的所述媒体模态代理的操作，作为对此的响应，所述呼叫控制器向所述媒体模态控制器发起指令，作为对此的响应，所述媒体模态控制器向所述第一设备的所述媒体模态代理发起控制信号。

10.如权利要求9所述的方法，其中，所述第一设备不执行呼叫代理。

11.如权利要求9所述的方法，包括：所述第二设备的所述呼叫代理向所述呼叫控制器发送关联数据，所述关联数据将所述第一和第二设备关联起来。

12.如权利要求11所述的方法，其中，所述第一设备被配置为通过输出组件输出配对代码，所述关联数据包括所述配对代码，并且所述方法包括所述第二设备的所述呼叫代理通过输入组件从用户接收所述关联数据。

13.如权利要求9所述的方法，其中：

第一设备被配置为通过所述网络与所述通信系统的另一个媒体模态控制器通信，所述另一个媒体模态控制器被配置为管理所述已建立的通信事件的另一媒体模态，所述另一个媒体模态控制器是响应于来自所述呼叫控制器的指令的；以及

所述第一设备还被配置为执行另一个媒体模态代理，所述另一个媒体模态代理被配置为与所述另一个媒体模态控制器而不与所述呼叫控制器或所述媒体模态控制器通信；所述方法包括：

所述第二设备的所述呼叫代理向所述呼叫控制器发起指令以间接地控制所述第一设备的所述另一个媒体模态代理的操作，作为对此的响应，所述呼叫控制器向所述另一个媒体模态控制器发起指令，作为对此的响应，所述媒体模态控制器向所述第一设备的所述另一个媒体模态代理发起控制信号。

14.如权利要求13所述的方法，其中，所述媒体模态控制器之一是被配置为管理所述通信事件的音频的音频控制器，并且所述媒体模态控制器的所述另一个媒体模态控制器是被配置为管理所述通信事件的视频的视频控制器。

15.一种计算机系统，包括：

第一设备，包括：

被配置为通过通信系统的通信网络与所述通信系统的媒体模态控制器通信的网络接口，所述媒体模态控制器被配置为管理已建立的通信事件的媒体模态，所述媒体模态控制器是响应于来自所述通信系统的呼叫控制器的指令的；以及

被配置为执行媒体模态代理的处理单元，所述媒体模态代理被配置为与所述媒体模态控制器而不与所述呼叫控制器通信；

第二设备，包括：

被配置为通过所述网络与所述呼叫控制器通信的网络接口，所述呼叫控制器被配置为建立所述通信事件；以及

被配置为执行呼叫代理的处理单元，所述呼叫代理被配置为与所述呼叫控制器通信并且通过与所述呼叫控制器的所述通信间接地控制所述第一设备的所述媒体模态代理的操作；

其中，所述第一设备不执行呼叫代理，并且其中，所述第二设备的所述呼叫代理被配置为通过所述网络接口向所述呼叫控制器发送通信事件建立指令，作为对此的响应，所述呼叫控制器建立所述通信事件。