传统通信系统允许设备用户(端点)(诸如个人计算机或移动设备)通过诸如互联网之类的基于分组的计算机网络与一个或多个其它端点进行语音或视频呼叫。图1示出了这样的用户设备102的示例，如用户104所使用的。用户设备102被显示为执行通信客户端120以用于进行这些呼叫。端点的呼叫数据的通信频繁地受到坚持已达成的通信协议的端点的影响。其中一个示例是会话发起协议(SIP)。在广义的术语中，SIP指示呼叫是根据基于端点到端点的请求应答事务范式协商的，其中(除了其它事务)，呼叫从初始未连接状态发展到实时媒体能够通过SIP用户代理(诸如构成端点102处执行的客户端软件106的一部分的SIP用户代理108)而在端点之间流动的状态，该SIP用户代理向其它端点的其它用户代理发送请求消息序列并接收返回的相应的响应消息，同时呼叫的保持和最后终止都以类似的方式生效(effect)。每个用户代理在该呼叫的持续时间内保持一个状态机(诸如状态机110)，其用于跟踪当前呼叫状态。该状态机根据显著请求的传输和显著响应的接收适当地更新。
在图2中描绘了两个用户(Alice和Bob)之间的SIP呼叫流的典型示例。首先，Alice的用户代理向Bob的用户代理发送INVITE请求(S202)，Bob的用户代理首先返回临时的RINGING响应(S204)，其后紧跟着OK应答(S206)指示Bob已经接受该呼叫。Alice的用户代理用ACK消息(S208)对此进行应答，并且实时媒体流开始(S210)。在S212处，Alice的用户代理通过向Bob的用户代理发送BYE请求促使呼叫终止(S212)。作为响应，Bob的用户代理返回OK响应(S214)并且终止该呼叫。如图所示，Alice和Bob的用户代理可以通过SIP代理服务器(proxy)120交换这些消息。例如，Alice和Bob的用户代理可以首先向代理服务器120注册它们各自的地址以便使它们相对于对方“可见”。通常，代理服务器120到目前为止是无状态的，因为它不保持任何关于当前呼叫状态的数据(而是仅仅用作中继器)，或者到目前为止是处于事务状态的，因为它只保持关于当前事务(即，单个请求—响应交换)的以及仅针对那些事务的持续过程中的有限的信息。
技术实现要素：
提供发明内容，以便以简化形式引入一系列的概念，下面在具体实施方式中将进一步描述这些概念。该发明内容不是旨在标识出所要求保护的主题的关键特征或重要特征，也不旨在用作限定所要求保护的主题的范围。所要求保护的主题也并不仅限于解决
背景技术：
中提出的任何或全部缺点的实现方式。
本公开了用于使得通过通信网络连接的多个端点之间的通信事件生效的通信系统。该通信系统除了所述端点之外包括多个处理单元，每个处理单元具有对保存用于管理通信事件的可执行代码模块的计算机存储装置的访问。该代码模块被配置为实现：被配置为管理已建立的通信事件的媒体模态的媒体模态控制器和被配置为建立该通信事件的呼叫控制器。该呼叫控制器的一个实例被指派为响应于通过网络接收到的指令而进行该通信事件的建立，并且被配置为向该媒体模态控制器和至少一个所述端点中的至少一项发起指令。
还公开了用于管理通过通信系统的通信网络连接的多个端点之间的通信事件的方法，该通信系统除了所述端点之外包括多个处理单元，每个处理单元具有对保存用于管理通信事件的可执行代码模块的计算机存储装置的访问。该代码模块被配置为实现：被配置为管理已建立的通信事件的媒体模态的媒体模态控制器，和被配置为建立该通信事件的呼叫控制器。该方法包括通过网络接收指令，以及作为对接收所述指令的响应，指派该呼叫控制器的一个实例进行该通信事件的建立。该方法还包括该呼叫控制器实例向该媒体模态控制器和至少一个所述端点中的至少一项发起指令。
还公开了一种包括网络接口和处理单元的用户设备。该网络接口配置为通过通信系统的通信网络与该通信系统的呼叫和媒体模态控制器通信。该媒体模态控制器响应于来自该通信控制器的的指令，并且该呼叫和媒体控制器分别配置为建立通信事件和管理已建立的通信事件的媒体模态。该处理单元配置为执行媒体模态代理，该媒体模态代理配置为与媒体模态控制器而不与呼叫控制器通信，并且呼叫代理配置为向该呼叫控制器发起指令以便间接控制该用户设备的媒体模态代理的操作。
还公开了配置为实现任何所公开的方法和/或通信系统和/或代理的计算机程序产品。
附图说明
为了辅助理解所公开的主题以及如何使其生效，现在将通过举例的方式参考下面的附图，其中：
图1是执行SIP客户端的用户设备的示意图；
图2是基于SIP的呼叫流的示意图；
图3是通信系统的示意图；
图4是用户设备的示意图；
图5A是数据中心的示意图；
图5B是数据中心的服务器的示意图；
图6A和6B示意性的描绘了分层通信系统架构的原理；
图7A和7B示意性的描绘了与通信系统交换数据的方法；
图7C是通信系统中的数据交换的示意图；
图8是通信系统架构的示意性概览。
图9是特定通信系统架构的示意图，图9A、9B和9C示意性地描绘其额外细节；
图10是呼叫设置过程的示意图，图10A示意性地描绘其额外细节；
图11A和11B提供失败转移(failover)过程的示意图；
图11C是用于实现失败过渡过程的方法的示意图；
图12和12A根据通信系统架构示意性地描绘了用户设备；
具体实施方式
0.1概述
在一个或多个端点之间设置诸如呼叫(例如，音频呼叫、音频和视频(AV)呼叫等等)之类的实时媒体通信事件时，需要考虑很多因素和变量来做出若干决定，包括是否允许参与方互相呼叫、使用什么音频和视频编解码器、如何将媒体分组从一方端点路由到另一方等等。为了(除了其它事务)确保做出适当的决定，为呼叫中的参与方提供最好的切实可行的质量，并且尽快完成呼叫设置，负责该呼叫设置的算法、协议、系统和处理(包括媒体(例如，音频和视频)协商)应该具有对任何显著信息的访问并且应该被分配足够的计算资源以便能够执行它们各自的控制功能。
在所描述的实施例中，定制的中央智能云呼叫设置控制和媒体协商(CICCSMNC)系统从“分布式平台”(或者称为“云平台”或简称为“云”)内部提供对实时媒体通信事件的集中化(与基于端点正相反)控制，CICCSMNC系统被定制为使用这一云平台所提供的计算资源，该云平台可以容易地并且动态地确保(除了其它事务)满足上面的考虑。
如本申请中所使用的，“分布式平台”(“云”)是一个计算平台，可通过网络(例如，互联网)访问，其包括由多个联网的计算机设备和其上运行的系统软件组成的分布式计算机系统，该计算机系统提供(潜在地非常大的)物理计算资源(诸如物理处理资源和物理存储资源，易失性的和/或非易失性的)池，并且所述系统软件被配置为通过实现多个独立的、软件实现的(或“虚拟的”)、资源有限的计算机系统来划分这一底层物理资源池，每个所述计算机系统具有它们自己各自的计算机架构(可以不同于它们在其上运行的底层物理计算机系统的架构)。这些虚拟计算机系统的每一个由系统软件分配(并且因此可以利用)总的可用物理资源的预定的一部分，该部分具有实质上独立于任何其它的该平台的虚拟计算机系统的尺寸。这些虚拟计算机系统中的至少一些被配置为提供应用代码的运行时环境，在具有各自的指令集架构(可以不同于该虚拟计算机系统在其上运行的任何物理处理器的结构)的虚拟计算机系统中(例如，在一个或多个虚拟处理器上)执行代码应用。这些或其它这种虚拟计算机系统可以被配置为数据访问单元(例如，被配置为数据库服务器或类似单元)，配置为提供对数据访问单元可访问的物理存储资源的访问，通过这些疏浚访问单元，应用代码可以从那些物理存储资源读取数据并向其写入数据。
这一物理计算机资源池，以及通过虚拟化对该池的划分能够产生使硬件和软件考虑分解的效果，因为(由该平台的系统软件实现的)虚拟化分层提供物理计算机资源(例如，可用的物理处理器时钟周期和存储器的物理比特)从“虚拟”资源的分离—也就是，资源实际是在每个虚拟计算机系统中看到的。底层硬件的物理资源可以通过新的物理网络计算机设备的添加，或现有物理联网计算机的升级来增加，并且在旧系统兼容方面唯一需要的考虑就是确保升级后的物理计算机系统还是能够运行相同的通用虚拟机(即，无需任何关于什么操作系统或应用代码将运行在那些虚拟机上的考虑)。类似的，系统设计者可以设计系统(可能是具有很多组件的极其复杂的系统)，并且开发与之有关的，用于与物理硬件考虑(诸如顺序、部署和安置物理服务器等)无关的云平台上的实现的代码—系统设计者只需要考虑在虚拟计算机系统的资源限制(而非底层硬件的资源限制)方面的计算机资源开销，那些虚拟系统的资源限制是明确定义的并且已知。因此，从系统设计者的角度，计算机资源考虑被减少到，例如该云平台应该部署多少个虚拟计算机系统之类的考虑；从平台本身的运营者的角度(该运营者可能不同于系统设计者)，计算机资源考虑被减少到，例如实现要求数量的具有预定义资源分配的虚拟机需要多少个物理计算机系统之类的考虑。
图8中示出了示例性分布式平台800的高级概述。该示例性平台包括分布式计算机系统814。图8的计算机系统814由非常大量的(例如，成千上万)联网计算机设备组成—大到足够物理计算资源在一些上下文(context)中可以被视为足够丰富就像实际上无限的一样。这些计算机设备被配置为与基于分组的数据网络301(例如，互联网)通信并且是全球分布的(例如，分散遍布多个国家和/或大洲)。通常，这些计算机系统的分组(例如，成千个服务器)被安置在不同地理位置处(即，一个国家的不同区域、不同国家、不同大洲等)的各个数据中心中(作为替代可称为“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中介。
分布式平台的示例包括WindowsAzure(TM)、Amazon网络服务(TM)等。
CICCSCMN系统是根据一组原则和设计模式的集合设计和实现的，其核心在于中央控制和决策制定(与例如端点控制和关于图1和图2所讨论的SIP的决策制定正相反)。它包括很多服务逻辑，每个服务逻辑由云平台的一个或多个虚拟计算机系统上执行的应用代码来实现，那些虚拟计算机系统不同于该云平台的其它服务逻辑的计算机系统(也就是，使得不同服务逻辑可以由该云平台的各个不同虚拟计算机系统上执行的不同应用代码集合来实现)。
服务逻辑可以根据类型分组(每个类型有多个服务逻辑)。每个类型的服务逻辑被配置为：通过与构成终端用户通信客户端应用的一部分的相同类型的其它服务逻辑和服务代理交互，来控制使用该客户端的通信系统上进行的实时媒体通信事件(例如，AV呼叫)的不同方面。
中央控制和决策制定并不是由单个服务逻辑或软件组件实现的，而是由不同类型的多个独立的服务逻辑(控制器)实现的，它们共同工作以控制并辅助任何给定的实时媒体通信事件。所述服务是通过明确定义的边界和接口分解的。针对呼叫设置和相应的媒体设置，以及在呼叫进行的同时对这些的控制，如下定义了并在表1中列出了下面的服务分组(服务的类型)：
-第一类型：呼叫控制(监督信令、呼叫状态、控制—控制是经由信令改变状态的组合)
-第二和第三类类型：传输控制和管道控制(监督拓扑结构、端点连接/管道管理、媒体流和分组化、线路上的加密)。传输处理整个端点拓扑结构，并且指示管道在呼叫的拓扑中的端点之间建立连接。
-第四类型：音频媒体控制(监督音频编解码器选择、音频专用变量管理、端点音频控制(例如，静音))
-第五类型：视频媒体控制(视频编解码器选择、视频专用变量管理、端点视频控制(例如，启用/禁用视频))
表1
任何给定呼叫通常在该呼叫过程中的任何给定时间由每类服务逻辑中的一个(也就是，每个分组中的一个)控制(虽然该类型的个体服务逻辑在某些条件下服从呼叫过程中的变化)。
服务逻辑展露(expose)接口(例如，REST式(“代表性状态转移”)接口)用于彼此通信和/或与它们各自的代理通信。REST是一种抽象了分布式混合媒体中的架构化单元的架构风格，以较高的抽象水平包括处理单元(即，执行运行时功能的单元—在当前上下文中包括服务逻辑和服务代理)；数据单元(即，由处理单元处理的数据—在这一上下文中包括实时媒体通信事件数据和与之相关联的控制数据)；以及连接单元(即，在这一上下文中有助于通信系统中的处理单元之间通信的机制)。REST忽略了处理单元实现和协议语法的细节，以便聚焦在处理单元的角色、它们与其它组件的交互上的约束和它们对重要数据单元的解释上。
服务被具有基本不相交的职权范围(即，在不同类型的服务逻辑所执行的任务之间有最小化的重叠或没有重叠)的不同类型的服务逻辑“划分边界”：如果由第一类服务逻辑的第一服务的控制迫使必须执行第二类服务逻辑的职权中的任务，则该服务逻辑将请求该第二类型的第二服务逻辑执行该任务，而不是它自己去执行该任务。服务间请求是高层级请求，这体现在它们不指定低层级的实现细节(也就是，它们只请求完成特定任务，而不指定如何完成它的低层级细节)。然后，一旦该任务完成则该第二服务逻辑通知第一服务逻辑，还是无需传输任何关于如何完成该任务的低层级细节。例如，第一服务逻辑可以请求第二服务逻辑建立一些用于从一个端点向另一个(位于第二服务逻辑的职权范围内)传输数据的机制；然后该第二服务逻辑可以处理该请求的所有低层级细节，例如选择连接协议、找到穿过该网络的路径、根据所述协议建立并保持跨越该路径的连接等等。一旦被通知这一机制的建立，第一服务逻辑可以开始利用该机制，同时低层级实现细节还是对其保持很大程度上不可见。
定义了规则或“合约”，其针对每对服务逻辑指定该对服务逻辑在其中应该相互直接通信的环境和不应该相互直接通信的环境，针对每个服务及其相应代理指定该服务和该代理在其中应该相互直接通信的环境和不应该直接相互通信的环境。合约本质上定义了每个服务在接口方面展露什么，负责什么以及限制是什么。
设置实时音频和视频呼叫(本申请中简称为“视频呼叫”)是由交付这些业务的各自服务逻辑执行的，其是通过经由例如呼叫控制服务逻辑的REST式接口接收到或发起的命令而生效的。这一命令得到用于在云中创建该呼叫的“呼叫表征”，它包括以呼叫参数形式的“呼叫状态”以及由该呼叫控制服务逻辑在该呼叫的持续过程中存储并保持的信息。抛开该服务逻辑的失败，这是该呼叫唯一权威性的实例和状态表征；接收到的关于该特定呼叫的任何后续命令造成该呼叫控制服务逻辑对该呼叫表征执行可能的状态修改，并且这一变化被传输给任何感兴趣的端点/参与方/订户。
作为呼叫设置和控制的一部分，需要协商并控制媒体，并且建立传输机制以允许媒体数据分组在端点之间流动。这通过呼叫控制服务逻辑调用其它控制服务逻辑(传输、管道、音频、视频)展露出来的接口通知它们该呼叫并指示它们执行在端点之间设置该呼叫的步骤来实现。这一服务间交互的模型使得各种服务做任何必要的事情以做出相关决定，指示它们的端点代理执行动作，提供变量数据和上下文(向呼叫控制服务报告准备就绪)和任何其它有关的服务逻辑。一旦各种服务已经完成并且都报告准备就绪，该呼叫控制服务逻辑更新呼叫状态并将该呼叫的更新后的状态传输给所有连接的端点(以及任何其它感兴趣的组件)，以允许连接该呼叫并且允许媒体流动。
在该呼叫持续过程中，将由端点和代理向各个服务发送信号以用于控制呼叫参与的主要方面，这是通过呼叫控制服务逻辑进行的，但是如果业务之间的合约没有被破坏，业务代理应该能够独立地使用它们各自的接口根据需要与它们相应的相同的服务逻辑通话。
还应该注意的是，一个服务被认为拥有基于云的组件和元件以及端点服务代理(如果该服务要求的)二者。云服务也拥有端点合约(或代理)。
现在将参照图3描述根据本发明的主题的通信系统300。通信系统300包括基于分组的通信网络(这里是计算机网络)301(例如，互联网)。连接到网络300的是与第一用户302a(“Alice”)相关联的用户设备(用户终端)304a和与第二用户302b(“Bob”)相关联的其它用户设备(用户终端)204b。用户设备304a、304b被安排从各自设备的用户接收信息并向其输出信息。虽然在图3中只显示了两个用户设备，但是通信系统300中可以包括更多的用户设备。用户设备304a、304b中的每一个可以是，例如移动电话(例如，智能电话)、平板电脑、笔记本电脑、个人计算机(“PC”)(包括，例如WindowsTM、MACOSTM和LinuxTMPC)、游戏设备、个人数字助理(“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；输入设备，诸如用于接收音频信号的麦克风416，用于接收图像数据的摄像机408，以及键盘406；用于存储数据的存储器426；以及诸如用于与网络301通信的调制解调器之类的网络接口424。用户设备114可以包括除了图4中示出的那些之外的其它元件。显示器404、扬声器410、麦克风412、存储器426、摄像机408、键盘406和网络接口424可以整合到用户设备304中。作为替代，显示器404、扬声器410、麦克风412、存储器426、摄像机408、键盘406和网络接口424中的一个或多个也可以不整合到该用户设备中，而是通过各自的接口连接到CPU402。这种接口的一个示例就是USB接口。如果用户设备304通过网络接口424到网络301的连接是无线连接，则网络接口424可以包括用于向互联网301无线地发送信号和从互联网301无线地接收信号的天线。
图4还描绘了CPU402上执行的操作系统(“OS”)414。在OS414上运行的是通信系统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连接到网络基础设施580，网络基础设施580也能够使服务器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)的示意图。控制服务器548的处理器546执行操作系统(OS)550。该操作系统550管理控制服务器544的硬件资源并处理通过网络接口586发送的数据。运行在OS550上的是采用数据中心控制软件(代码)形式的数据中心管理器块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被配置为运行一个根(父)VM508和一个或多个客人(子)VM510。该根VM执行操作系统520，每个客人VM510i、512i执行各自的操作系统520i、520ii。适当操作系统的一个示例是Windows服务器2012TM。在根OS520上执行以代码形式的主控制块522，其被配置为(除了其它事务)能够创建并终止客人VM510并通过调用该管理程序的适当应用编程接口(API)(未示出)在其上发起OS510的启动。在每个客人OS510i、510ii上执行各自的以代码形式的客人控制块532i、532ii，以及使得其各自VM510i、510ii执行比该VM自身的运行更多的有用任务的各自应用代码534i、534ii(例如，软件开发者的订制代码)。每个客人控制块532被配置为(除了其它事务)能够在该VM上促使应用代码模块的执行(即，实例化该应用代码模块以创建其实例)和终止应用代码模块的执行(即，解除那些应用代码实例)。每个OS520被配置为在该OS520启动时自动发起相应客人控制块532的执行。客人VM可以替代地或另外地被配置作为数据访问单元(未示出)—见上文。至少一些应用代码模块用于管理一个或多个通信事件(例如，呼叫)。
控制服务器544的DC控制块和根VM508的根控制块能够经由图5B中虚线指示的网络基础设施580相互通信，例如通过适当API的使用。由根VM进行的对客人VM的创建和终止是在控制服务器544的DC控制块556的命令下进行。例如通过提供该代码的标识符或提供可以用于例如从网络301下载代码的地址，DC控制块556还可以向根控制块522指示应该在该虚拟机的子VM上执行什么应用块。VM510可以运行一个或多个应用代码模块的一个或多个实例。
如本文中所指出的，配置信息经由网络301被上传到数据中心320；这一配置信息由外部控制块559接收到。每一条控制信息与在子VM520上执行的代码有关和/或与该应用代码要在其上执行的该子VM520(即，一个或多个应用代码模块要在其上实例化)的一个或多个期望属性有关。
根控制块508能够与每个客人控制块532通信并且反之亦然，例如经由管理程序530—再次在图5B中用虚线示出。一旦已经由根控制块508在DC控制块556的命令下创建了客人VM510，该根控制块指示客人控制代码发起应用代码的执行，例如作为对从根控制块522接收应用代码534的地址或标识符的响应(如DC控制块556从配置信息所提供的)，客人控制块532使用该标识符或地址下载该应用代码534以便在OS530上执行。
例如，应用代码可以由软件开发者或系统设计者上传到适当网络位置，并且该位置被作为配置信息传输到控制服务器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建立逻辑连接)。例如，该配置信息还可以指定一个或多个物理计算机资源各自要被分配给子VM510的部分(诸如总计兆字节、千兆字节的存储器和总计例如兆赫兹、千兆赫兹等的处理资源的量)，该代码要在该子VM上执行。
经由网络310上传到数据中心320的配置信息被存储在控制服务器544的存储器554中，并且这一存储的配置信息是DC控制块556可访问的，并且(至少部分)对每个根VM和每个客人VM都是可访问的。
只有根VM具有对服务器506的底层物理计算机资源(例如，处理器、存储器)的直接访问；其它客人VM经由管理程序或经由虚拟总线(也就是，逻辑VM间通信信道)通过根VM访问这些信息。根VM522和管理程序512共同地配置为管理对这些底层物理资源的访问并共同地将这些物理资源的各个预定部分分配给每个客人VM，所述预定部分实质上独立于其它客人VM，即使得其它客人VM的任何行为或修改不会增加或减少该客人VM可使用的物理资源的部分。因此，每个客人VM(例如，510i)提供资源有限的运行时环境，其实质上与同一个处理器506上运行的任何其它客人VM(例如，510ii)分离开。
客人VM510不经由管理程序512直接相互通信，并且如上所讨论的对彼此的可用物理资源有最微小的影响(由管理程序的虚拟化提供这一实质上的独立性)。在这些方面，VM无视彼此的存在。也就是说，客人VM还是能被配置为经由网络基础设施580相互通信，在DC内(数据中心320中)和通过网络301二者都可以。
如图5B中所示，DC控制块556还负责控制DC业务管理系统588以便在数据中心中管理针对从网络301接收到的数据和经由网络基础设施580交换的内部数据二者的业务流。
每个子VM510上的子控制代码532有两个功能(除了别的之外)：首先，它向其对应的根VM发送周期性心跳；其次，它监视该VM上执行的应用代码532。如果发生应用代码失败，则该子控制代码尝试使用存储的配置信息重新启动该应用代码。如果它无法这样做，它将这一失败传输给对应的根控制代码522。此外，如果发生该子VM的失败，则来自子控制代码532的心跳将会停止。作为对这些事件之一的响应，根控制532终止子VM510，然后使用如上所述的存储的配置信息重新创建它(所述重新创建的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根据该指令(即，处理该指令)做出响应，指派该服务逻辑(如上所述实例化的)的一个实例(在VM510上)执行与特定通信事件有关的操作。在这一实施例中，如下面更详细解释说明的，通过与特定服务逻辑相关联的负载均衡器做出这一指派。
响应于所指派的实例返回对接收到的指令的响应(该响应被返回给启动程序)，从该指派释放该指派的实例。这一指令(请求)/响应交换被称为事务。本申请中“释放”意为被分配给指派的实例以便使其能够完成该事务的所有物理资源(处理资源、存储器资源)被从其收回(例如，变得对其它这种事务可用)。在这一实施例中，那些物理资源是该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和执行各自应用代码的实例530的一个或多个客人虚拟机510，其中负载均衡器被如上参考图5B所描述地配置为指派一个实例作为对接收到的指令(请求消息)的响应。该应用代码响应于在该VM处接收到的请求消息，例如从用户设备(例如，304a、304b)和不同数据中心处的其它服务逻辑等接收到的“外部”请求，或者从该服务逻辑的其它组件接收到的“内部”请求。特定组件的每个VM运行在相同的数据中心处，并且该组件的负载均衡器构成该数据中心的数据中心业务管理系统558的一部分。该特定组件中的VM被基于相同配置信息配置为具有相同的属性，并且每一个VM运行一个或多个各自的相同应用代码的实例(其提供那些VM中的一个或一些可能失败的冗余)。组件的负载均衡器可操作用于接收请求并例如以轮询的方式或基于监视到的那些VM的资源可用性(例如，将输入的请求送往具有最多可用资源的VM)将那些请求送往该组件的任何一个VM。组件的负载均衡器假设该组件的每个VM等效地配置为能够处理该负载均衡器接收到的任何请求。
组件的示例包括在WindowsAzure(TM)平台上实现的网络和工作者角色。
图6B示出了服务逻辑642，其包括至少两个具有各自负载均衡器648、658的组件642和652。组件642包括至少两个VM510A、510B，基于相同的配置信息被配置为具有一致的属性。VM510A执行应用代码的实例534A，而VM510B执行相同的(或者至少复制的)应用代码的实例534B。类似的，组件652包括至少两个VM510A’、510B’，该两个VM510A’、510B’基于所述相同的配置信息被配置为具有相似的属性。VM510A’执行应用代码的实例534A’，而VM510B’执行相同的(或者至少复制的)应用代码的实例534B’。
一个组件可以被实现为包含无状态VM的无状态组件。这取决于该组件和服务是如何设计和编写的。无状态VM是运行这样一种应用代码实例的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(例如，REST式的)和/或一个或多个内部可用、可寻址的接口652(例如，REST式的)，它们可以被利用(即，调用)以便建立用于与该组件交换数据的逻辑连接。内部接口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并将该请求转发给它。VM510a-B执行各种操作作为响应。例如，在这一示例中，服务逻辑622a包括另一个组件652a—它本身包括耦合到展露出来的内部接口656a的负载均衡器658a以及多个虚拟机510a-A’、510a-B’。由VM510a-B所执行的所述操作可以包括向所述内部接口656a发送一个或多个内部请求。作为对其响应，负载均衡器658a选择组件652a的虚拟机510a-B’并将该请求转发给该VM。VM510a-B’执行各种操作作为响应，然后一旦完成则向VM510a-B返回响应(S716)。作为响应，组件642a的VM510a-B执行额外的操作，包括向请求者700的原始请求返回响应(S718)。作为替代，VM510a-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通信，并且可操作用于向该注册和导出请求逻辑914注册该客户端416的地址(例如，包括客户端被执行在其上的用户设备304的互联网协议(IP)地址)。发送给该地址的任何请求由块943接收并转发给目标代理接收方，从而使该注册和导出请求逻辑向该客户端的个体代理发送请求消息(从各个服务逻辑中的一个接收到的)。这使得每个类型的控制器能够与该类型的相应代理建立用于传输相应的控制数据的连接(例如，使呼叫控制器能够与该呼叫代理建立用于传输呼叫控制数据的连接，使音频控制器能够与该音频代理建立用于传输音频控制数据的连接，使视频控制器能够与该视频代理建立用于传输视频控制数据的连接，使传输控制器能够与该传输代理建立用于传输传输控制数据的连接，使管道代理能够与该管道代理建立用于传输管道控制数据的连接)。
服务到端点消息发送是通过推送类型的服务到端点消息信道的方式，这意味着它不要求客户端请求能够交付服务消息(或响应)。如果服务需要向一个端点发送消息或命令，它通过适当的推送信道“随意”地这样做。
更具体的，客户端416具有登录/注册设备，它将用户设备304与特定的相应用户(例如，Alice、Bob)关联起来。作为登录程序的一部分，该用户的用户名被与执行该客户端的设备的地址相关联地存储起来，用户在该客户端处通过通信系统300的注册和导出请求逻辑914登录。用户可以有运行在与相同的登录/注册细节相关联的其它设备上的通信客户端实例。在具有特定用户名的相同用户能够同时登录到不同设备上的相同客户端应用的多个实例的情况中，逻辑914被安排将该用户名(用户ID)映射到全部那些多个实例，但是也将不同的子标识符(子ID)映射到每个特定个体实例。因此，通信系统300能够区分不同实例同时还保持用户在该通信系统中的身分的一致性。Alice302a和Bob302b二者都在它们各自的图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和932)。该注册和导入请求块934被配置为从分布式平台800的注册和导出请求逻辑914接收那些数据，并将那些数据送往目标的客户端一侧代理(924、926、928、930、932中的一个)。
特定类型的代理能够建立用于通过该类型的控制器的外部接口(例如，REST式接口)与该控制器传输控制数据的连接。例如，呼叫代理924能够建立用于通过相应的呼叫控制器904各自的外部接口905与其传输数据的连接。音频代理926能够建立用于通过相应的音频控制器906各自的外部接口907直接与其传输数据的连接。视频代理928能够建立用于通过相应的视频控制器908各自的外部接口909直接与其传输数据的连接。传输代理930能够建立用于通过相应的传输控制器910各自的外部接口911直接与其传输数据的连接。管道代理332能够建立用于通过相应的管道控制器912各自的外部接口913直接与其传输数据的连接。
任何这种已建立的连接可以用于，例如发送请求消息，所述接收机执行操作作为响应，并且一旦完成操作则通过该连接返回响应消息。
每个控制器通常同时控制多个(并且可能很多个)呼叫的各自一个方面。在特定呼叫的任何两个给定事务(即，基于请求—响应交换的事务)之间，每个控制器可以完成一个或多个其它呼叫的任何数量(零或更多)的事务。针对参与那些事务的无状态组件的无状态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存储在组件共享物理存储器资源中的内存存储组件906。该管道控制组件展露外部接口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所存储的并从其转发给目标客户端的关于该客户端的信息建立的(通过该类型的相应控制器)。当服务发送服务到端点消息时，该响应并不沿着相同的连接；而是该端点/代理以REST式消息的形式向该服务发起一个新的消息。
为了使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接收，作为响应，呼叫控制组件954创建呼叫状态953(S1003a)，该呼叫状态953除了其它之外包括Alice的端点标识符。这涉及建立通过接口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可能有多个与相同用户标识符(例如，用户名)相关联的用户设备(例如如果Bob在所有那些用户设备处都登录了)(用户设备304b是其中一个)。那些设备的每一个签约一个推送信道，并且通过那些推送信道由呼叫控制器(并且根据要求由其它控制器(媒体、管道、传输控制器))发送各自的通知。
一旦接收到Bob的用户标识符，呼叫控制器可操作用于选择该标识符相关联(即，与单个用户Bob相关联)的一个或多个端点(包括用户设备304b)，并向所选择的端点发送上面提到的通知。针对端点304b的通知可以因此是发送到端点的多个指令中的一个，每个指令都是响应于(从Alice)接收到的所述相同的指令而发送的。
作为对接收到该推送通知的响应，Bob的呼叫代理通过向呼叫控制器904发送附接消息来附接到该呼叫上，该消息包括Bob的端点标识符；Bob的呼叫代理924b也输出“响铃(ringing)”通知(例如，听得见的铃声)并通过客户端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、416之间流动)，并且向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以便处理。由于这个原因，依赖于转发组件的特定VM的先前请求的处理结果通过接口911发送给传输控制器的任何请求包括该VM的标识符。在呼叫设置已经完成之后，传输服务器不再保持关于该呼叫控制器为了帮助服务呼叫所创建的会话的任何信息(并且依赖其它服务逻辑来在例如在呼叫控制器904的呼叫状态953和/或管道控制器912的管道状态961中保持任何必要的信息)。
此外，在上述呼叫设置过程中，管道状态信息由管道控制器912的有状态管道状态组件962保持，也就是，管道状态组件956的每个VM在它自己各自单独的存储器资源(而不是内存组件960中)中存储关于完成的事务的信息，因为这些通常除了被共享在内存资源中还会被进一步访问。因此，要求访问这一存储在单独VM处的信息的请求由管道控制组件绕过负载均衡器963直接转发给该VM以便处理。由于这个原因，依赖于转发器组件的特定VM的先前请求的处理结果在呼叫设置过程中通过接口913发送给传输控制器的任何请求包括该VM的标识符。一旦呼叫已经建立(在这一点上，通常管道控制器将接收更少的与该呼叫有关的请求)，管道状态信息被保持在管道状态961中，而不再依赖于该管道控制器908的有状态行为(以类似于由呼叫控制器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上执行的代码实现。
该通信系统320能够扩展以满足具体的、精细(discreet)的功能需求，例如在潜在的具体地理区域中(因为通信系统300可以是全球通信系统，即能够在不同国家和/或大洲之间进行呼叫)。
为此，NRT呼叫和RTM服务的设计不仅分离逻辑上的还分离精细服务部署的基础设施，它向用户提供总的服务交付的具体部分—例如，视频媒体、音频媒体、呼叫控制。所述服务并不是部署为一组在系统的内部逻辑上逻辑分离的耦合比特，而是实际上部署为完全分离的服务和处理。
传统上随着通信服务的需求的增长，例如在世界上一个具体部分中，以及对具体特性的需求的增长，诸如分组视频呼叫，整个解决方案需要被向上扩展以处理增长的需求。
但是，本发明内容的呼叫控制系统900设计允许例如独立于例如呼叫控制和信令基础设施，响应于需求变化而扩展视频媒体基础设施。当然，作为对该相同的变化的需求的响应，也需要扩展其它服务，但这是一个分解的独立决定。
如上所讨论的，实时AV呼叫的建立由多个分解的、独立的控制器(云控制服务逻辑)执行，所述控制器通过明确定义的接口和约定交互以提供实时AV呼叫和附属的媒体服务。
这一分解的服务设计允许每个服务在该服务的内部工作方面是自治的，包括部署、扩展和服务专用资源管理。
这一自治性允许每个服务独立地做出反应以加载和扩展具体服务上的要求，而不会有一种设计由于单个服务的扩展需要的直接结果引起所有其它服务扩展或变化的需要。这意味着，如果具体国家中对所述视频媒体的需求增加，只有该视频媒体服务需要扩展该具体国家中的服务基础设施，同时不直接要求其它服务也一齐扩展。要注意的是，也可能需要其它服务也同时扩展，但是这将会单纯地由该类型的需求、每个服务的扩展限制来驱动，而不需要联动式系统设计驱动。
在一些实施例中，这种扩展可以受到如下影响。
物理计算机资源(例如，物理存储器资源、物理处理资源)可以被独立于其它类型的服务地分配给每个类型的服务。例如，如果一个或多个第一类型的服务逻辑被配置为交付第一类型的服务，并且一个或多个第二类型的服务逻辑被配置为交付第二类型的服务，额外的资源可以被独立于第二类型服务地分配给该第一类型服务。
针对第一类型服务的资源分配可以用下面一个或多个方式增加(相对应于减少)：
-通过部署额外的(相对应于终止现有的)该类型的服务逻辑，即通过向第一类型的新的服务逻辑分配物理计算机资源(相对应于收回针对该类型的现有服务逻辑的计算机资源)—这种方式的一个示例可以是在WindowsAzureTM云平台上部署新的网络应用；
-通过增加(相对应于减少)第一类型的一个或多个现有服务逻辑的组件中的虚拟机数量，即增加(相对应于减少)该组件的计算机资源分配—这种方式的一个示例可以是修改WindowsAzureTM云平台上的网络应用的网络角色或工作者角色中的实例数量；
-通过增加(相对应于减少)第一类型的一个或多个现有服务逻辑的组件中的复制的虚拟机的“尺寸”(也就是分配给它的各自的物理资源量)，即增加(相对应于减少)分配给特定组件的每个这样的复制的虚拟机相应的计算机资源—这种方式的一个示例可以是调整WindowsAzureTM云平台上的网络应用的网络角色或工作者角色的大小。
使用后两种技术，资源可以被分配给一个服务逻辑，独立于相同类型和不同类型二者的其它服务逻辑。例如，更多的VM可以被添加到第一类型的第一服务逻辑的组件，和/或那些组件的VM可以被调整大小，而不需要修改该类型的其它服务逻辑的组件，也无需修改不同类型的其它服务逻辑的组件。
此外，使用后两种技术，资源可以被相互独立地分配给相同服务逻辑的不同组件(例如，向一个组件添加VM或调整其VM的大小，而不修改其它的)。
每个数据中心320a、320b、320c等的DC控制块构成资源分配逻辑，可操作用于影响这些分配，因为每个控制块具有对其自己的数据中心内的物理资源使用的控制。如上所讨论的，资源分配通过向数据中心的外部控制块559提供配置信息而生效。
例如，呼叫控制器904、音频控制器906、视频控制器908、传输控制器910和管道控制器912中的任何一个可以被以这种方式相互独立地(也就是，无需其它被修改)并且独立于相同分布式平台800上运行的任何其它呼叫控制器、音频控制器、视频控制器、传输控制器和管道控制器地分配计算机资源。
例如，如果在具体国家中对所述视频媒体的需求增加，则只有部署在该国家的视频媒体服务逻辑需要扩展(通过在该国家中部署新的视频控制器服务逻辑或通过增加分配给该国家中运行的现有视频控制服务逻辑的资源)，同时不在其它服务上产生一致地扩展的系统设计驱动需求。
此外，那些控制器的组件可以被独立于那些组件的其它组件分配资源。例如，呼叫控制器904的呼叫控制组件954可以被独立于内存存储组件分配资源，反之亦然，例如如果该呼叫控制组件954没有足够的已分配的处理资源来处理外部请求，但是内存存储组件有足够的已分配的处理资源来处理内部读/写请求，则无状态呼叫控制组件可以被分配更多的处理资源(通过向其添加更多VM或增加其VM的尺寸)而无需修改分配给内存存储组件的处理资源。类似的，额外的共享存储器资源可以被分配给内存存储组件以便使其能够存储更多的呼叫状态，而无需修改指派给该呼叫控制组件的每个VM的存储器资源(这是不必要的，因为该呼叫控制组件的每个VM在任何事物的持续过程中只需要存储最多一个呼叫状态或者其一部分)。
其它控制器的组件的资源分配可以被类似地独立地调整。
3.控制服务逻辑(控制器)失败和呼叫状态复制
本发明公开了用于影响通过通信网络连接的端点之间的通信事件的通信系统，该通信系统包括：多个处理单元，每个处理单元具有对保存用于管理通信事件的可执行代码模块的计算机存储的访问，所述代码模块被配置为实现：被配置为建立通信事件和管理已建立的通信事件的一个或多个呼叫控制器；其中，该计算机存储装置被划分为多个容错区域；其中，第一呼叫控制器实例被配置为访问该计算机存储的第一容错区域以访问呼叫状态，该第一呼叫控制器实例被指派为响应于通过该网络接收到的第一指令来访问该呼叫状态；并且其中，该呼叫状态的至少一部分在计算机存储的第二容错区域中被复制，这样第二呼叫控制实例可以访问所述呼叫状态的该至少一部分，该第二呼叫控制器实例被指派为响应于通过网络接收到的第二指令而访问该呼叫状态的至少一部分。
本发明还公开了用于使得通过通信系统的通信网络连接的端点之间的通信事件生效的方法，该通信系统包括：多个处理单元，每个处理单元具有对保存用于管理通信事件的可执行代码模块的计算机存储的访问，所述代码模块被配置为实现用于建立通信事件和管理已建立的通信事件的呼叫控制器，该计算机存储被划分为多个容错区域，该方法包括：指派该呼叫控制器的第一实例进行通信事件的建立，作为对此的响应，该第一呼叫控制器实例将该通信事件的呼叫状态存储在第一容错区域中；并且指派该呼叫控制器的第二实例进一步进行该通信事件的建立和/或管理已建立的通信事件，作为对此的响应，该第二呼叫控制器实例访问第二容错区域中的该呼叫状态的至少一部分的副本。
该第二容错区域不同于该第一容错区域。
在这一实施例中，响应于检测到该第一呼叫控制器实例的情况，该呼叫控制器的第二实例被指派访问该呼叫状态的至少一部分。该检测到的情况是：第一呼叫控制器实例的失败；第一呼叫控制器实例的解除；和该第一呼叫控制器实例具有对处理单元的不足够处理该第二指令的物理资源的访问等等之一。
所述处理单元还可以遍布多个容错区域分布，该第一和第二呼叫控制器实例在第一和第二容错区域中的各自处理单元上执行。该计算机存储装置的容错区域可以基本上与处理单元的容错区域对准或不对准(也就是，这样处理单元集合和其可访问的计算机存储装置集合与相同的失败源分离)。
在下面的示例中，第一实例是第一呼叫控制器的实例，第二实例是不同数据中心处的第二呼叫控制器的实例(其可以具有与该第一呼叫控制器不同或相同的地理位置)。该计算机存储装置和处理单元的容错区域基本对齐体现在二者都对应于处理单元集合和这些集合可访问的计算机存储装置的部分所位于的数据中心。
根据本发明内容，用户设备包括：被配置为通过通信系统的网络从该通信系统的呼叫控制器接收指令的网络接口424，该呼叫控制器被配置为访问已建立的通信事件的呼叫状态；被配置为存储该呼叫状态的本地版本的计算机存储416；以及被配置为执行具有对该呼叫状态的本地版本的访问的呼叫代理，并且被配置为响应于从该通信控制器接收到的指令而更新该呼叫状态的本地版本的处理单元402。
上述为通信系统300“供电”的云800的控制系统是高性能的并且对故障有很好的容错性：如上所讨论的，特定服务逻辑的组件中的个体VM的失败由相关根VM522和/或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的共享存储器资源中存储的(而不是任何特定VM的单独指派的存储器资源中)呼叫状态953中。这些共享存储器资源地理上位于其中运行该组件(以及该呼叫控制器)的数据中心处。因此，该呼叫状态包含一个呼叫控制器能够无缝地从另一个进行接管(根据呼叫过程中一个呼叫控制器的失败)所要求的全部信息，初始发往该呼叫控制器的任何请求可以被重定向到存储复制的(副本)呼叫状态的另一个呼叫控制器，该复制的呼叫状态包含足够所述其它呼叫控制器能够处理那些请求的信息。
现在将参考图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的共享物理存储器资源中。
在呼叫控制服务的交付过程中，该呼叫控制组件954a(尤其是经指派的它的呼叫控制器实例)通过与内存存储组件952a通信来响应于一个事件(例如，图10A和10B中的S1006、S1012、S1020、S1088)而更新(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可以替代地向第二呼叫控制器904b发送包括该呼叫标识符的任何请求，所述请求本来应该被(如果其没有失败的话)发送到第一呼叫控制器904a。该第二呼叫控制器使用呼叫状态副本953b处理这些请求，该呼叫状态副本是使用这些请求的呼叫标识符识别出来的。这可以包括继续建立该通信事件(如果其还没有被建立)和/或一旦已经建立则管理该通信事件(通过第一和第二呼叫控制器之一)。
在一些实施例中，呼叫状态副本953b可能不是呼叫状态953a的完整副本，即初始呼叫状态可能包含比该副本更多的信息，该副本只包含关于该呼叫的选择出的信息。在这种情况中，由第一呼叫控制器在创建呼叫状态953a时向第二呼叫控制器发送的初始副本只是该呼叫状态的一部分的副本，，该副本包含足够使该呼叫即使第一呼叫控制器失败也能继续进行的信息，而不是包含该呼叫的每个单独参数(一旦第一呼叫控制器失败，这些参数可以被重置)。作为替代或者另外，第一呼叫控制器可以仅响应于一些事件而不是其它事件(这样一些事件导致“主”呼叫状态953a而不是副本953b的更新)而向第二呼叫控制器发送消息以更新该呼叫状态副本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通信。每个可操作用于分别向注册和导出请求逻辑914注册用户设备304和其它用户设备304’的地址。
如上所述，第一服务逻辑能够使用云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[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)、光盘、闪存、硬盘存储器和可以使用电磁、光学和其它技术来存储指令和其它数据的其它存储器设备。
虽然已经用专用于结构化特征和/或方法化动作的语言描述了本发明主题，但是应该理解的是，所附权利要求中定义的本发明主题不一定仅限于上面具体描述的特征或动作。而是，上面所描述的具体特征和动作是作为实现权利要求的示例形式公开的。