背景技术：
传统通信系统允许诸如个人计算机或者移动设备之类的设备(端点)的用户通过诸如互联网之类的基于分组的计算机网络，与一个或多个其它端点进行语音或者视频呼叫。图1示出了如由用户104使用的这样的用户设备102的例子。用户设备102被示出执行通信客户端120，用于在进行这样的呼叫时使用。经常地，由端点进行的呼叫数据的通信是由遵守经协商的通信协议的这些端点来实现的。这样的一个例子是会话发起协议(SIP)。从广义上讲，SIP指示根据基于端点到端点的请求-响应的事务范例来协商呼叫，其中(除了别的以外)，该呼叫是从初始的未连接状态发展到可以通过SIP用户代理(例如，形成在端点102处执行的客户端软件106的一部分的SIP用户代理108)向其它端点的其它用户代理发送请求消息序列并且转而接收相应的响应消息，使实时媒体在端点之间流动的状态，其中呼叫的维护和最终终止类似地被实现。每个用户代理在整个呼叫期间维护状态机(例如，状态机110)，其中该状态机110被用于跟踪当前呼叫状态。在发送了突出(salient)请求并且接收到突出响应时，对状态机进行适当地更新。图2中示出了两个用户(Alice和Bob)之间的SIP呼叫流程的典型例子。最初，Alice的用户代理向Bob的用户代理发送邀请(INVITE)请求(S202)，Bob的用户代理最初返回临时振铃(RINGING)响应(S204)，接着是用于指示Bob已经接受该呼叫的OK响应(S206)。Alice的用户代理利用确认(ACK)消息对此进行确认(S208)，然后实时媒体流开始(S210)。在S212处，Alice的用户代理通过向Bob的用户代理发送BYE请求，来发起呼叫终止(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示意性地示出了其另外的细节；图10是呼叫建立过程的示意性图示，其中图10A示意性地示出了其另外的细节；图11A和图11B提供了故障转移过程的示意性图示；图11C是用于实现故障转移过程的方法的示意性图示；图12和图12A示意性地示出了根据通信系统架构的用户设备。具体实施方式0.1概述当在一个或多个端点之间建立诸如呼叫(例如，音频呼叫、音频和视频(AV)呼叫等等)之类的实时媒体通信事件时，必须考虑包括下列各项的多种因素和变量来做出多种决策：是否应当允许各方呼叫彼此，使用什么样的音频和视频编解码器，如何将媒体分组从一方端点路由到另一方等等。(除了别的以外)为了确保做出适当的决策，向呼叫中的各方提供最可行的质量，并且尽可能快速地完成呼叫建立，负责呼叫建立的算法、协议、系统和过程(其包括媒体(例如，音频和视频)协商)应当使用任何突出信息，并且应当被分配足够的计算资源以便能够执行它们各自的控制功能。在所描述的实施例中，定制的中央智能云呼叫建立、控制和媒体协商(CICCSMNC)系统提供对于来自“分布式平台”(其另外被称为“云平台”或者简单的“云”)之内的实时媒体通信事件的集中式控制(与基于端点的控制截然相反)，其中对CICCSMNC系统进行修改以利用由这样的云平台提供的计算资源，其中该云平台可以容易地和动态地确保(除了别的以外)满足上面的考虑。如本文使用的，“分布式平台”(“云”)是经由网络(例如，互联网)可访问的计算平台，其包括分布式计算机系统，所述分布式计算机系统包括多个网络化的计算机设备和在其上运行的系统软件，该计算机系统提供物理计算资源(例如，物理处理资源和物理存储器资源、易失性和/或非易失性)的(潜在地非常大的)池，以及该系统软件被配置为通过实现多种独立的、软件实现的(或“虚拟的”)、资源受限的计算机系统来划分该底层物理资源池，其中每个虚拟的资源受限的计算机系统具有它们自己各自的计算机架构(该计算机架构可以与它们在其上运行的底层物理计算机系统的架构不同)。由系统软件向这些虚拟计算机系统中的每个虚拟计算机系统分配总的可用物理资源的预先确定的部分(并且因此可以使用该预先确定的部分)，该部分具有基本上独立于该平台的任何其它虚拟计算机系统的大小。这些虚拟计算机系统中的至少一些虚拟计算机系统被配置为提供针对应用代码的运行时环境，该代码应用在具有相应指令集架构(其可以与在其上运行该虚拟计算机系统的任何物理处理器的指令集架构不同)的例如一个或多个虚拟处理器上的该虚拟计算机系统内执行。这些或者其它这样的虚拟计算机系统可以被配置为数据存取单元(例如，被配置为数据库服务器或者类似部件)，被配置为提供对由该数据存取单元可访问的物理存储器资源的访问，其中应用代码可以通过数据存取单元来从那些物理存储器资源读取数据和向那些物理存储器资源写入数据。对于物理计算机资源的这种池化，以及通过虚拟化动作来划分该池以使硬件和软件考虑解耦是由于(由该平台的系统软件实现的)虚拟化层提供了物理计算机资源(例如，可用的物理处理器时钟周期和存储器的物理比特)与‘虚拟’资源的分离，也就是说，资源在每个虚拟计算机系统之内实际上被看到。可以通过添加新的物理网络计算机设备，或者升级现有的物理网络化的计算机，来对底层硬件的物理资源进行增加，而需要根据传统兼容性作出的考虑是确保所升级的物理计算机系统仍然可以运行相同的通用虚拟机的(即，无需对什么样的操作系统或者应用代码将在那些虚拟机之上运行的任何考虑)。类似地，系统设计人员可以设计系统(可能是具有很多部件的极度复杂的系统)，并且开发与之相关的代码，以在免于物理硬件考虑(例如，订购、部署和容纳物理服务器等等)的云平台上实现，系统设计人员只需要围绕虚拟计算机系统的资源限制(而不是底层硬件的资源限制)来考虑对计算机资源的消耗，那些虚拟系统的资源限制是明确的和已知的。因此，从系统设计人员的角度来看，将计算机资源考虑减少为：对例如应当部署云平台的多少虚拟计算机系统的考虑；从平台自身的操作者(其不同于系统设计人员)的角度来看，将计算机资源减少为：对例如需要多少物理计算机系统来实现具有预先定义的资源分配的所需要数量的虚拟机的考虑。在图8中示出了示例性分布式平台800的高层级概述。该示例性平台包括分布式计算机系统814。图8的计算机系统814包括非常大数量(例如，数万)的网络化的计算机设备(足够大)，在一些上下文中，可以认为这些物理计算资源足够多以至于实际上不受限。这些计算机设备被配置用于与基于分组的数据网络301(例如，互联网)进行通信，并且是全球分布的(例如，分布在多个国家和/或大陆上)。通常地，成组的这样的计算机系统(例如，数千的服务器)被容纳在不同地理位置处(即，国家的不同区域、不同的国家、不同的大陆等等)的各自的数据中心(datacentre)(或者被称为“数据中心(datacentre)”)中。系统软件812运行在分布式计算机系统814之上。系统软件812被配置为实现两组804(运行时组)和808(存储组)独立的、虚拟的、资源受限的计算机系统806、810。每个虚拟系统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，其中API811可以被用于例如通过代码834对其进行适当的函数调用，实现对于去往和来自分配给该计算机系统810的物理存储器资源(主要由物理非易失性存储器在物理层级处实现)的数据的传输。此外，该传输是由系统软件812来调解的。分布式平台的例子包括WindowsAzure(TM)、AmazonWeb服务(TM)等等。根据原理和设计模式的集合来设计和实现CICCSCMN系统，其中内核是具有中央控制和决策作出的核(与例如如关于图1和图2讨论的SIP的端点控制和决策截然相反的)。其包括多个服务逻辑，每个服务逻辑是通过在云平台的一个或多个虚拟计算机系统上执行的应用代码来实现的，那些虚拟计算机系统与该云平台的其它服务逻辑的应用代码不同(也就是说，使得不同的服务逻辑是通过在该云平台的不同的相应的虚拟计算机系统上执行的应用代码的不同集合来实现的)。根据类型对服务逻辑进行分组(每种类型存在多个服务逻辑)。每种类型的服务逻辑被配置为通过与其它服务逻辑和构成终端用户通信客户端应用的一部分的该相同类型的服务代理进行交互，对使用该客户端通过通信系统进行的实时媒体通信事件(例如，AV调用)的不同方面进行控制。中央控制和决策作出不是通过单一的服务逻辑或者软件组件而是通过不同类型的多个独立的服务逻辑(控制器)来实现的，这些不同类型的多个独立的服务逻辑一起工作以控制和有助于任何给定的实时媒体通信事件。这些服务被解耦，具有明确的边界和接口。对于呼叫建立和相应的媒体建立，以及在呼叫进行时对于这些的控制来说，下面的服务分组(服务的类型)是如下文定义的并且如表1中列出的：-第一类型：呼叫控制(监视信令、呼叫状态、控制-控制是经由信令来改变状态的复合体)-第二类型和第三类型：传输控制和管道控制(监视拓扑、端点连接/管道管理、媒体流和分组化、线路上的加密)。传输处理整个端点拓扑，并且指示管道在呼叫的拓扑中的端点之间建立连接。-第四类型：音频媒体控制(监视音频编解码器选择、音频特定的变量管理、端点音频控制(例如，静音))-第五类型：视频媒体控制(视频编解码器选择、视频特定的变量管理、端点视频控制(例如，启用/禁用视频))表1在呼叫期间的任何给定时间，通常由每种类型的服务逻辑中的一个服务逻辑(也就是说，来自每组中的一个)来控制任何给定的呼叫(虽然在某些情况下，该类型的各个服务逻辑在呼叫期间受到改变)。服务逻辑暴露接口(例如，RESTful(“代表性状态传输”)接口)，用于与彼此进行通信和/或与它们各自的代理进行通信。REST是用于以高级的抽象对分布式超媒体内的架构要素进行抽象的架构样式，其中该分布式超媒体包括：处理要素(即，执行功能运行时的要素，其包括目前上下文中的服务逻辑和服务代理)；数据要素(即，由处理要素处理的数据，其包括该上下文中的实时媒体通信事件数据和相关联的控制数据)；以及连接要素(即，有助于该上下文中的通信系统内的处理要素之间的通信的机制)。REST忽略处理要素实现和协议语法的细节，以便集中于处理要素的作用、在它们与其它组件进行交互时的约束、以及它们对于重要数据要素的解释。服务是利用具有基本上不相交的职权范围的不同类型的服务逻辑来‘边界化’的(即，在由不同类型的服务逻辑执行的任务之间存在最小的交迭或者不存在交迭)：如果第一类型的服务逻辑对第一服务的控制需要执行位于第二类型的服务逻辑的职权范围之内的任务而不是执行该任务本身，则该服务逻辑将请求该第二类型的第二服务逻辑来替代地执行该任务。服务间请求是较高层级的请求，其在于：它们不指定较低层级的实现细节(也就是说，它们只请求完成特定的任务，而不指定如何来完成该任务的较低层级的细节)。随后，第二服务逻辑在完成该任务时通知第一服务逻辑，再次无需传送如何完成该任务的任何较低层级的细节。例如，第一服务逻辑可以请求第二服务逻辑建立用于从一个端点向另一个端点传送数据的某种机制(其位于第二服务逻辑的职权范围之内)；随后，第二服务逻辑可以处理该请求的较低层级的细节中的所有细节，例如，选择连接协议，寻找通过该网络的路径，跨越该路径根据该协议来建立并且维持连接，等等。一旦被通知建立了该机制，第一服务逻辑就可以在对于较低层级的实现细节保持基本上不可见的情况下利用该机制。对规则或者‘契约’进行规定，其针对每对服务逻辑，指定该对服务逻辑应当和不应当直接与彼此进行通信的环境，以及针对每个服务和其相应的代理，指定该服务和该代理应当和不应当直接与彼此进行通信的环境。契约本质上规定每个服务围绕接口暴露什么，责任是什么，以及限制是什么。建立实时音频和视频呼叫(为了简单起见，在本文被称为“视频呼叫”)，由传送这些服务的各自的服务逻辑来执行呼叫，其是通过经由呼叫控制服务逻辑的例如RESTful接口接收的或者发起的命令来实现的。该命令产生针对在云中生成的该呼叫的“呼叫表示”，其包括具有呼叫参数形式的“呼叫状态”以及由呼叫控制服务逻辑在整个该呼叫期间存储和维护的信息。除了该服务逻辑的故障以外，这是该呼叫的唯一权威性实例和状态表示；接收的与该特定呼叫有关的任何后续命令导致由呼叫控制服务逻辑关于其表示执行可能的状态修改，并且将该改变传送给任何感兴趣的端点/参与方/用户。作为呼叫建立和控制的一部分，需要对媒体进行协商和控制，以及建立传输机制，以允许媒体数据分组在端点之间流动。这是通过呼叫控制服务逻辑调用由其它控制服务逻辑(传输、管道、音频、视频)暴露的接口向它们通知该呼叫，并且指示它们执行用于在端点之间建立该呼叫的步骤来实现的。这种服务间交互模型导致各个服务执行做出相关决策必要的动作，指示它们的端点代理来执行动作，提供可变的数据和上下文(向呼叫控制服务以及有关的任何其它服务逻辑报告准备就绪)。一旦各个服务已经完成并且全部报告准备就绪，呼叫控制服务逻辑就更新呼叫状态，并且向所有连接的端点(以及任何其它感兴趣的组件)传送该呼叫的更新的状态，允许该呼叫被连接，以及媒体流动。在呼叫期间，如果服务之间的契约未被打破，则端点和代理将向各个服务发送信号，以控制该呼叫参与的主要方面，这是经由呼叫控制服务逻辑来实现的，但是服务代理能够根据需要，使用它们各自的接口来独立地向它们相应的服务逻辑告诉相同的内容。还应当注意到的是，服务被认为拥有基于云的组件和要素二者，以及端点服务代理(如果该服务需要的话)。云服务还拥有端点契约(或者代理)。现在将参照图3来描述根据本主题的通信系统300。通信系统300包括基于分组的通信网络(这里，计算机网络)301(例如，互联网)。被连接到网络300的是与第一用户302a(“Alice”)相关联的用户设备(用户终端)304a和与第二用户302b(“Bob”)相关联的另外的用户设备(用户终端)304b。用户设备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，其被连接到：输出设备，例如，显示器404(其可以被实现为触摸屏)和用于输出音频信号的扬声器(或者“扩音器”)410；输入设备，例如，用于接收音频信号的麦克风426、用于接收图像数据的照相机408和小键盘406；用于存储数据的存储器426；以及网络接口424，例如用于与网络301通信的调制解调器。用户设备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”)，所述UI被用于向该设备的用户呈现信息和从该设备的用户接收信息。用此方式，客户端416执行允许用户(例如，Alice、Bob)通过通信系统300进行通信所需要的处理。该软件栈示出了客户端协议层418、客户端引擎层420和客户端用户接口层422。每个层负责特定的功能。由于每个层通常与两个其它层进行通信，因此它们被视作为布置在如图4中示出的栈中。操作系统414对设备304的硬件资源进行管理，并且对经由网络接口424向网络301发送的数据和从网络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；被连接到网络310的网络基础设施580，用于在数据中心320内的网络化的设备之间交换数据分组，以及经由网络301与该数据中心之外的设备交换数据分组；以及电力基础设施590，用于向该数据中心的设备提供电力。服务器504a、504b和504c分别由电源592和电源592’供给电力，而这些电源从电力基础设施590供给电力。该数据中心还包括被连接到网络基础设施580的数据中心业务管理系统588，用于从网络301接收指引到数据中心320的入站业务并且跨越服务器504a、504b、504c来分发该业务，以及跨越数据中心320的其它服务器(例如，504b、504c)来分发来自数据中心320的一个服务器(例如，504a)的内部业务。DC业务管理系统可以包括诸如硬件负载平衡器、以及在适当的计算机系统处执行的软件或者其组合之类的组件。服务器504a、504b、504c中的每个服务器包括相应的处理器506a、506b、506c，其中这些处理器506a、506b、506c被连接到用于存储数据的相应的存储器514a、514b、514c和用于与其它网络化的设备交换数据的相应的网络接口584a、584b、584c。网络接口584a和584b被连接到网络交换机582，其中网络交换机582使得服务器504a和504b能够与彼此交换数据，以及直接经由该交换机582来与被连接到该交换机582的任何其它服务器(未示出)交换数据。网络接口584c被连接到网络交换机582’，所述网络交换机582’使得服务器504c能够直接经由该交换机582’，与被连接到该交换机582’的任何其它服务器(未示出)交换数据。交换机582被连接到网络基础设施580，所述网络基础设施580还使得服务器504a、504b和被连接到交换机582的任何其它服务器(未示出)，与被连接到该网络基础设施的其它设备(例如，经由诸如交换机582’之类的其它交换机来这样连接的设备)以及与被连接到网络301的另外的设备交换数据。交换机582’类似地被连接，使得服务器504c能够参与类似的数据交换。服务器544是数据中心的控制服务器：其负责对该数据中心中的其它服务器进行控制和监控。控制服务器544是从电源595供给电力的，而电源595自身则从电力基础设施590供给电力。控制服务器544包括处理器546，所述处理器546被连接到用于存储数据的存储器554和用于与其它网络化的设备交换数据的网络接口586。网络接口586被连接到网络基础设施580，所述网络基础设施580使得控制服务器544能够与被连接到该网络基础设施的其它设备(其包括服务器504a、504b、504c)以及与被连接到网络301的另外的设备(例如，图3中的304a、304b)交换数据。将服务器504a、504b、504c分成相应的“故障域”502、502’，故障域是共享共同的故障点的一组服务器(也就是说，依赖于相同的物理电子组件进行操作的服务器，故该相同物理电子组件的故障禁止所有那些服务器的操作)。例如，服务器504a和504b经由网络交换机582(其对于服务器504a、504b二者来说是共同的)被连接到网络基础设施580；该交换机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的处理器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可以具有存在直接硬件实现的虚拟计算机架构)，或者其可以被设计为模拟‘假想的’计算机系统(也就是说，VM可以具有不存在直接硬件实现的计算机架构)。例如，虚拟机可以包括具有特定指令集架构的模拟的处理器；首先将要在该虚拟机上执行的代码编译成一系列低级机器代码指令，这些指令是根据该模拟的处理器的该指令集架构的(即，具有如由该指令集架构指定的操作码和操作数)。但是，这些机器代码指令本身不在物理处理器上执行；而是，管理程序执行另外的指令转换，其最终导致低级机器代码指令在底层物理计算机系统的一个或多个物理处理器(例如，处理器506)上执行，其中在所述底层物理计算机系统上执行该管理程序(并且因此该模拟的处理器)，这些指令是根据讨论中的物理处理器(与模拟的处理器相反)的指令集架构的(即，具有如由该指令集架构指定的操作码和操作数)。对于较小大小的VM来说，VM可以共享物理处理器；对于较大的VM来说，它们是专用的。管理程序512被配置为运行根(父)VM508和一个或多个客户(子)VM510。根VM执行操作系统520，并且每个客户VM510i、512i执行相应的操作系统520i、520ii。适当的操作系统的一个例子是Windows服务器2012TM。(除了别的以外)被配置为能够创建并且终止客户VM510和在其上发起OS510的启动的、具有代码形式的主机控制模块522是通过调用管理程序(未示出)的适当的应用程序接口(API)来在根OS520之上执行的。在每个客户OS510i、510ii之上执行具有代码形式的相应的客户控制模块532i、532ii以及相应的应用代码534i、534ii(例如，软件开发者的定制代码)，其中这些应用代码534i、534ii使其相应的VM510i、510ii仅仅在该VM自身的运行之上和之外执行有用的任务。每个客户控制模块532被配置为(除了别的之外)能够在该VM上发起对应用代码模块的执行(即，对应用代码模块进行实例化以创建其实例)和终止对应用代码模块的执行(即，停止使用那些应用代码实例)。每个OS520被配置为当OS520被启动时，自动地发起对相应客户控制模块532的执行。替代地或另外地，客户VM可以被配置为数据存取单元(未示出)，参见上文。应用代码模块中的至少一些模块用于管理一个或多个通信事件(例如，呼叫)。如由图5B中的虚线指示的，控制服务器544的DC控制模块和根VM508的根控制模块可以例如通过使用适当的API，经由网络基础设施580来与彼此进行通信。根VM对于客户VM的创建和终止是在控制服务器544的DC控制模块556的命令下的。DC控制模块556还例如通过提供该代码的标识符或者可以被用于从例如网络301下载该代码的地址，来指示根控制模块522什么应用模块将要在该机器的子VM上执行。VM510可以运行一个或多个应用代码模块的一个或多个实例。如指示的，经由网络301将配置信息上传到数据中心320；该配置信息是由外部控制模块559接收的。每条控制信息与用于在子VM520上执行的代码有关和/或与将要在其上执行该应用代码的该子VM520(即，要在其上实例化一个或多个应用代码模块)的一个或多个期望的属性有关。根控制模块508可以例如经由管理程序530，与每个客户控制模块532进行通信，反之亦然(这在图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(诸如，具有例如兆字节、吉字节等等的存储器的容量，以及具有兆赫兹、吉赫兹等等的处理资源的量)。将经由网络310被上传到数据中心320的配置信息存储在控制服务器544的存储器554中，并且该存储的配置信息对于DC控制模块556是可访问的，并且对于每个根VM和每个客户VM是(至少部分地)可访问的。仅仅根VM直接访问服务器506的底层物理计算机资源(例如，处理器、存储器)；其它客户VM通过根VM，经由管理程序或者经由虚拟总线(也就是说，逻辑的VM间通信信道)来访问这些资源。根VM522和管理程序512共同地被配置为调节对这些底层物理资源的访问，并且共同地动作以便向每个客户VM分配这些物理资源的相应的预先确定的部分，该预先确定的部分基本上独立于其它客户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终止该子MV510，并且随后使用如上面的所存储的配置信息来对其进行重新创建(其中，所重新创建的VM因此加载并且执行与所终止的VM相同的应用代码)。类似地，根控制代码522向DC控制模块556发送周期性的心跳。如果例如由于物理服务器504的硬件故障(例如，电力故障、网络故障等等)，或者由于根控制节点、管理程序等等的软件故障，而使这些心跳停止，则DC控制模块566假定运行在该服务器上的所有子VM已经故障。作为响应，其使用所存储的配置信息，在具有足够可用物理资源的数据中心的一个或多个功能服务器上重新创建那些VM(如上面的)，并且相应地控制DC业务管理系统588将业务引导到所重新创建的VM。因此，该分布式平台800(其包括多个这样的数据中心320a、320b、320c等等)可以适于运行多个服务逻辑，每个服务逻辑是由执行相应的应用代码534的一个或多个客户虚拟机510来实现的。这些虚拟机可以遍及单一的数据中心320分布，和/或跨越多个数据中心分布，其中数据中心间的业务是经由网络301(例如，互联网)来传送的。0.4服务逻辑的分层结构在下文描述的实施例中，由运行在分布式平台上的虚拟机上执行的应用代码实现的控制服务逻辑(贯穿全文替代地被称为“控制器”)，被配置为传送相应的服务以支持实时媒体通信事件(也就是说，管理其至少一个方面)。被配置为实现服务逻辑的代码模块以上面描述的方式被实例化在虚拟机510上。不同类型的服务逻辑被配置为传送不同的控制服务(不同的服务是例如呼叫控制、音频控制、视频控制、传输控制、管道控制)，而相同类型的服务逻辑被配置为传送相同的服务(例如，呼叫控制、音频控制、视频控制、传输控制、管道控制中的一种)。每种类型的服务中的一个服务通常将在实时媒体通信事件期间的任何给定时间，控制该事件的相应方面。在创建该通信事件时，从每种类型的多个可能的服务逻辑之中选择该种类型的服务逻辑，以支持该通信事件(例如，呼叫)。响应于针对该种类型的服务的请求(无论是来自该种类型的客户端侧服务代理(图4的612)，还是来自另一种类型的另一个服务逻辑)，在业务管理系统330内进行该选择。相同类型的服务逻辑均能够传送相同的服务，并且响应于针对该种类型的服务的请求，它们是可互换地选择的(而不同类型的服务逻辑是不可互换地选择的)。例如，第一类型的每个服务逻辑可以响应于来自向其发送的第一组可能的请求消息中的任何请求消息，并且第二类型的每个服务逻辑可以响应于来自向其发送的第二组可能的请求消息中的任何请求消息，第一组和第二组是不相交的或者部分相交的。随后，这些服务逻辑中的每个服务逻辑在该呼叫的持续时间或者直到该服务逻辑故障为止控制该呼叫(即，为其提供控制服务)(下文讨论的)。通信系统300响应于由发起方(例如，通过相同类型的代理或者通过不同类型的服务逻辑)向服务逻辑发起的并且经由网络301发送的具有请求消息(例如，REST呼叫)形式的指令。具体地，通信系统300进行响应以(在VM510上)分配该服务逻辑的实例(如上所述的进行实例化)，以根据该指令(即，对该指令进行处理)来执行与特定的通信事件相关的操作。在该实施例中，如下文更详细地解释的，由与特定的服务逻辑相关联的负载平衡器来进行分配。所分配的实例可以是响应于该实例向所接收的指令返回响应(该响应被返回到发起方)而从该分配中释放的。这样的指令(请求)/响应交换被称为事务。这里的“释放”意味着被分配给指定实例以使得其能够完成该事务的所有物理资源(处理资源、存储器资源)从此变成未被分配的(例如，变得可用于其它这样的事务)。在该实施例中，那些物理资源是VM在其上运行的虚拟机的物理资源。一旦这样的被释放，实例就不再需要在单独地分配给在其上运行该实例的该VM的存储器资源中维持关于该事务的任何信息(如下文解释的，虽然可以将关于该事务的信息存储在其它地方)，使得一旦这样的被释放，VM就‘忘记’该事务。可以将该实例配置为进行这样的释放(即，释放被嵌入到应用代码中)，或者通过通信系统的释放逻辑来‘强行地’释放该实例(例如，重新分配或者停止使用)。该服务逻辑的实例是针对每个这样的指令(例如，针对特定服务逻辑的多个实例，以循环方式或者基于每个实例的可用资源)独立地分配的实例，并且通信系统300响应于另外的这样的指令，来独立地分配该服务逻辑的本实例或者另一实例处理该另外的指令(其中，响应于该服务逻辑实例向另外的指令返回响应，从该分配中释放该服务逻辑实例)。在该实施例中，虚拟机510中的每个虚拟机使用呼叫控制器代码模块、媒体模态控制器代码模块(音频或者视频，而非二者)、传输控制器代码模块和管道控制器代码模块中的至多一个模块，使得呼叫控制器、媒体模态控制器(音频或者视频，而非二者)、传输控制器或者管道控制器中的仅仅一个运行在该虚拟机上。如讨论的，所述处理单元中的每个处理单元被配置为执行管理程序、在该管理程序上运行的该处理单元的虚拟机。每个服务逻辑具有分层结构，现在将参照图6A和图6B来描述该分层结构。如图6A中示出的，分布式平台800适于运行至少第一类型的第一组602[1]的第一服务逻辑622[1](也就是说，能够传送第一服务)和第二类型的组602[2]的第二服务逻辑622[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运行在相同的数据中心处，并且该组件的负载平衡器形成该数据中心的数据中心业务管理系统588的一部分。特定组件内的VM被配置为具有基于相同配置信息的相同的属性，并且每个VM执行相同应用代码的一个或多个相应的实例(如果那些VM中的一个或一些VM故障，则其提供冗余性)。组件的负载平衡器可操作以接收请求，并且例如，以循环的方式或者基于监控的那些VM的资源可用性(例如，将输入请求引导到具有最大可用资源的VM)，将那些请求引导到该组件的VM中的任何一个VM。组件的负载平衡器假定该组件的每个VM被等同地配置为能够对由该负载平衡器接收的任何请求进行处理。组件的例子包括在WindowsAzure(TM)平台上实现的网络(web)和工作者(worker)角色。图6B示出了包括至少两个组件642和652(其具有相应的负载平衡器648、658)的服务逻辑642。组件642包括至少两个VM510A、510B，其中所述至少两个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可以被配置为访问该分布式平台的物理存储器资源(例如，物理存储器的区域)，所述物理存储器资源是由该平台作为一个整体向该组件分配的，而不是向它们在其上运行的分布式平台800的其中的特定的、单个的VM分配的(例如，通过易失性存储器在物理层级处实现的存储器内存储(例如，高速缓存层))，其中该组件中的每个VM被配置为访问该相同区域的存储器。作为服务请求的一部分，VM可以从该存储器读取和向该存储器写入，并且该存储器的内容可能影响如何对该请求进行服务。但是，该VM仍然是无状态的，在于：其并不依赖于其自己的单个存储器资源，而是依赖于该组件的所有VM可访问的存储器资源。该通信系统的代码模块可以被配置为实现数据存取软件，据此，计算机存储对于服务逻辑(控制器)实例经由该数据存取软件的实例是可访问的。一个虚拟机上的控制器实例可以经由另一个虚拟机上的数据存取软件实例来访问计算机存储。服务逻辑的组件可以被配置为专用存储器内存取组件，该组件的VM被配置为访问这样的共享存储器资源(并且如讨论的，它们本身可以是无状态)，并且执行应用代码，其中该应用代码可操作以只服务来自该服务逻辑的其它组件的读/写请求(即，使得它们只代表该服务逻辑的其它组件来处理存储器访问)。一个例子是Azure(TM)平台上的专用高速缓存工作者角色。替代地或另外地，虚拟机上的控制器实例经由该相同虚拟机上的数据存取软件实例来访问计算机存储。组件的VM可以被配置为访问这样的共享存储器资源，并且还执行应用代码，其中该共享存储器资源(例如，存储器内高速缓存)并不被部署用于专用组件，而是以分布式方式被部署到其它组件上。一个例子是Azure(TM)平台上的角色内(in-role)高速缓存。替代地，可以将组件实现为有状态的，该组件的VM被配置为有状态VM，其的确依赖于使用它们自己各自的单独的存储器资源存储的关于过去事务的信息，以便成功地服务未来的请求。这样的请求特别地是针对该VM的，旁路该组件的负载平衡器(由于该组件的其它VM不能够服务那些请求)。有状态组件可以被用于服务时序要求严格的请求(由于与访问共享的组件范围的存储器资源相比，通常VM能更快速地访问其自己的单独的存储器资源)。但是，与无状态组件相比，有状态组件内的VM的故障可能导致该组件不能够服务已经由该故障的VM服务的后续请求。服务逻辑的组件可以被配置为暴露一个或多个外部可使用的、可寻址的接口624(例如，RESTful)和/或一个或多个内部可使用的、可寻址的接口652(例如，RESTful)，可以利用(即，调用)这些接口以便建立用于与该组件交换数据的逻辑连接。内部接口624仅仅对于相同服务逻辑的其它组件是可见的(并且可被其利用的)，而外部接口则对于相应的客户端侧服务代理612和/或其它服务逻辑是可见的并且可被其利用的。组件的接口被有效地耦合到该组件的负载平衡器，在于：使用该接口的被指向该组件的任何请求是由该负载平衡器接收的，以转发给该组件的VM(这种转发在该组件之外是不可见的)。图6B示出了暴露外部接口624(其被有效地耦合到该组件的负载平衡器648)的组件642，以及暴露内部接口656(其被有效地耦合到该组件的负载平衡器658)的组件652。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中。该策略标识能够传送例如如由通信系统300的运营商指定的该种类型的服务的多个服务逻辑(图7C中的622a、622b、622c)。业务管理器132可操作以依靠从数据中心资源报告模块558a、558b、558c等等中的每个模块接收的资源利用信息，来选择那些服务逻辑622a、622b、622c中的一个服务逻辑。一旦被选择，业务管理器132就向请求方750返回响应(S706)，其中该响应包括该选择的服务部署的地址(例如，图7C中的622a)。该地址是由该服务逻辑622a的组件642a暴露的外部接口624a的地址，其被耦合到该组件622a的负载平衡器648a。响应于接收到该响应消息，请求方750向由负载平衡器648a接收的该地址发送请求(S708)。这里，组件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进行通信，并且可操作以向其注册客户端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供应数据。管道代理322能够向传输代理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，来与传输控制器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、932中的一个)。特定类型的代理可以建立连接，用于经由该种类型的控制器的外部接口(例如，RESTful接口)，来与该种类型的控制器传送控制数据。例如，呼叫代理924可以建立连接，用于经由其相应的外部接口905，来与相应的呼叫控制器904传送数据。音频代理926可以建立连接，用于经由其相应的外部接口907，来与相应的音频控制器906直接地传送数据。视频代理928可以建立连接，用于经由其相应的外部接口909，来与相应的视频控制器908直接地传送数据。传输代理930可以建立连接，用于经由其相应的外部接口911，来与相应的传输控制器910直接地传送数据。管道代理332可以建立连接，用于经由其相应的外部接口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描述的方式已经被实例化在虚拟机510上。在该实施例中，虚拟机具有在其上运行的至多一个控制器实例(因此，对虚拟机的选择等同于对运行于该虚拟机之上的实例的选择)。但是，在其它实施例中，VM可以运行多个实例。呼叫控制器和呼叫代理协力地动作以传送实时媒体呼叫服务(主要的、较高层级的服务)，互相协调地起作用以提供呼叫建立功能、呼叫管理功能(即，添加/删除参与者、响应经由客户端用户界面做出的任何用户选择、经由客户端用户界面呈现可选择项以增强呼叫体验(例如，通过实现诸如屏幕共享或者即时消息传送之类的另外的功能))，提供用于为实时媒体呼叫数据的底层流程创建上下文的信息(例如，呼叫参与者状态)。如讨论的，通过呼叫控制器向呼叫代理传送呼叫控制服务，来实现对该呼叫服务的控制，其中用户侧交互是由呼叫代理在呼叫控制器的控制之下实现的。呼叫代理提供呼叫服务和用户之间的接口。其它模态服务以及它们相应的模态代理协力地动作，以传送各自的模态服务(次要的、较低层级的服务)。模态控制器传送模态控制服务，所述模态控制服务可以在呼叫控制的控制之下(直接控制或者间接控制，即，在该模态服务在呼叫控制器的直接或者间接控制之下由另一模态服务直接控制的情况下)，由呼叫控制器扩展到相应的模态代理以支持呼叫控制器(即，支持由该呼叫控制器传送的呼叫服务以及用于该呼叫的其相应的呼叫代理)。一旦将模态控制服务如此扩展到相应的模态代理，则该模态控制器和该模态代理相互协调地起作用以传送该模态服务。媒体(音频和视频)服务是一个例子。音频(相应的视频)控制器和音频(相应的视频代理)协力地动作以传送音频(相应的视频)服务，相互协调地起作用以确保对在用户设备处捕获的音频(相应的视频)进行最佳地编码，为该编码操作选择最佳的音频(相应的视频)变量，其中音频(相应的视频)代理向传输代理供应该编码的音频(相应的视频)数据，以便作为该音频(相应的视频)服务的一部分来传送给其它呼叫方。传输和管道服务是另一个例子。传输控制器和传输代理相互协调地动作以传送传输服务。管道控制器和管道代理相互协调地动作以传送管道服务。传输控制器控制呼叫的端点的拓扑，基于该呼叫中的所有端点来做出决策，并且因此利用最有效的方式来路由媒体。一旦已经做出了这些决策，传输控制器就指示管道控制器根据需要，在针对这些模态的有关端点之间建立必需的物理套接字连接。1.2.1呼叫控制器呼叫控制器被配置为建立通信事件(并且一旦建立，就对该通信事件进行管理)。在实时媒体(例如，音频/视频)可以在两个或更多端点之间进行流动的时刻，就说建立了通信事件。除了别的之外，建立通信事件包括：创建用于该通信事件的呼叫状态，并且指示其它控制器适当地响应，其它控制器与它们各自的代理进行通信以便建立媒体流。除了别的之外，对通信事件进行管理包括：在该通信事件期间，维持对呼叫状态的更新(例如，通过添加和/或去除呼叫参与者，结合音频控制器来处理静音/非静音音频请求，结合视频控制器来处理视频启用/禁用请求；最终终止该通信事件等等)。根据本主题，该呼叫控制器的实例是响应于经由网络接收的指令被分配来进行通信事件的建立的，并且被配置为向下列各项中的至少一项发起指令：媒体模态控制器；以及端点中的至少一个端点。一般情况下，在呼叫建立期间将发生呼叫控制器实例的多次分配，每个实例独立于其它实例来进行分配，以进行通信事件的建立。例如，可以响应于经由网络接收的指令，分配呼叫控制器的实例来进行通信事件的建立，并且可以对呼叫控制器的该实例或者其它实例进行独立地分配，以响应于经由网络接收的另外的指令来另外进行通信事件的建立。例如，初始分配的实例可以通过创建用于该通信事件的呼叫状态来进行该通信事件的建立，其中后续分配的实例通过相应地对其作出响应，执行呼叫建立操作和更新呼叫状态，来进一步进行该通信事件的建立。呼叫控制器被配置为访问通信系统的计算机存储，以访问用于通信事件的呼叫状态(以创建用于该通信事件的呼叫状态(例如，作为建立该通信事件的一部分)，或者访问用于该通信事件的现有呼叫状态)。具体地，在该实施例中，呼叫控制器的分配的实例被配置为访问呼叫状态，并且该呼叫状态持续到从所述分配中释放该呼叫控制器实例之后，使得呼叫控制器的另一个实例可以访问该事件中的呼叫状态(也就是说，使得呼叫控制器的本实例和/或另一个实例可以在所述释放之后访问该呼叫状态)。可以将从媒体模态控制器接收的媒体模态状态数据存储成呼叫状态的一部分。此外，在通信事件期间通常多次地另外分配呼叫控制器实例，以管理该通信事件(例如，可以响应于添加参与者的请求来分配实例，响应于去除参与者的请求，来独立地分配该实例或者另一个实例等等)。因此，可以分配呼叫控制器的实例来进行通信事件的建立，并且可以独立地分配呼叫控制器的该实例或者另一个实例来管理所建立的通信事件的至少一部分。在该实施例中，通过无状态代码模块来实现呼叫控制器。如图9A中示出的，呼叫控制器服务逻辑904包括无状态呼叫控制组件945(其暴露外部接口905)和内存存储组件952(其暴露内部接口955，并且具有分配的共享物理存储器资源集合)。无状态呼叫控制组件954可以建立连接，用于经由内部接口955，与无状态内存存储组件传送数据。内存存储组件953可操作以在共享物理存储器资源(其是该组件952的VM之间共享的、并且可被该组件952的所有VM访问的)中，存储由呼叫控制器904当前正支持的每个呼叫的呼叫状态953，并且对于该组件952的所有VM可访问，该呼叫状态包括该呼叫的多个当前参数。无状态呼叫控制组件954可以通过经由内部接口955建立的连接，从那些物理存储器资源读取和向其写入。因此，呼叫控制组件954可以取回和修改呼叫状态953或者其至少部分。用于呼叫的呼叫状态表示关于该呼叫的当前信息，例如，通信系统300内的参与端点(用户设备)的标识符以及它们各自的状态(准备就绪、连接、振铃、进行中等等)、当前支持该呼叫的其它服务逻辑的标识符等等。下面讨论呼叫状态以及其创建和维护。(除了别的之外)还可以跟踪以下内容：根据参与者/端点，哪些模态是活动的；模态状态是什么(发送、静音等等)，其准许周围的每个用户可允许地呼叫控制(踢除、添加、静音、其它等等)。所述组件中的每个组件包括各自的负载平衡器，以及以上面讨论的方式运行复制的应用代码实例的各自的多个负载平衡的、复制的VM。由控制组件954的负载平衡器，将在该组件处经由接口905接收的请求转发到其中的多个无状态VM中的任何选择的一个，每个请求被视作为单独的、独立的事务。作为响应，作为对该请求进行处理的一部分，所选择的VM可以通过经由内部接口955来发送内部读取请求，从内存存储组件952接口955来取回呼叫状态952的复本(至少一部分)。该内部请求是由该组件负载平衡器转发到内存存储组件952的VM中的任何选择的一个VM的，作为响应，其从内存存储组件952的共享物理存储器中取回呼叫状态953的复本，并且将该复本返回给呼叫控制组件954。呼叫控制组件临时地维持该复本，并且如果适用的话，相应地修改该维持的复本，并且向内存存储组件952发送该修改的复本以用于存储在其中作为另外的内部写入请求的一部分。再次地，该另外的内部写入请求是由该组件负载平衡器转发给内存存储组件952的VM中的任何选择的一个VM的(其可以与被选择用于初始取回该呼叫状态的复本的VM不同)，作为响应，其将呼叫状态953重写到内存存储组件952的共享物理存储器资源中以实现所接收的修改。如下面进一步讨论的，在实施例中，呼叫控制器是响应于一个或多个指令中的每个指令的；响应于所述一个或多个指令中的每个指令，根据该指令，独立地分配呼叫控制器的各自的实例来进行通信事件的建立，该分配的该呼叫控制器实例被配置为这样进行该通信事件的建立。例如，至少通过更新现有的呼叫状态，可以根据指令来进行通信事件的建立。所述一个或多个指令可以包括第一指令，至少通过创建用于通信事件的呼叫状态，根据第一指令来进行通信事件的建立。替代地或另外地，所述一个或多个指令可以包括：-第二指令，至少通过基于接收的用户标识符来选择一个或多个端点，根据第二指令来进行通信事件的建立；和/或-第三指令，至少通过基于另一个接收的用户标识符来选择一个或多个其它端点，根据第三指令来进行通信事件的建立；和/或-第四指令，至少通过向所述端点中的至少一个端点发起邀请指令，根据第四指令来进行通信事件的建立；和/或-第五指令，至少通过向所述端点中的至少一个端点发起振铃指令，根据第五指令来进行通信事件的建立；和/或-第六指令，至少通过将一个或多个识别的用户附着到该通信事件，根据第六指令来进行通信事件的建立；和/或-第七指令，至少通过将一个或多个识别的用户作为其中的参与者来添加到该通信事件，根据第七指令来进行通信事件的建立；和/或-第八指令，至少通过向所述端点中的一个或多个端点发送准备就绪指令，根据第八指令来进行通信事件的建立。本主题的一个方面是针对对于经由通信系统的通信网络连接的多个端点之间的通信事件进行管理的方法，其中该通信系统包括不同于所述端点的多个处理单元，每个处理单元访问保存可执行代码模块的计算机存储，所述可执行代码模块用于管理通信事件，所述代码模块被配置为实现媒体模态控制器和呼叫控制器，其中所述媒体模态控制器被配置为对建立的通信事件的媒体模态进行管理，所述呼叫控制器被配置为建立该通信事件；该方法包括：经由网络来接收指令；响应于接收到该指令，分配呼叫控制器的实例来进行该通信事件的建立；以及该呼叫控制器实例向下列各项中的至少一项发起指令：媒体模态控制器；以及端点中的至少一个端点。在实施例中，该方法还可以包括：经由网络来接收另一个指令；响应于接收到该另一个指令，独立地分配呼叫控制器的该实例或者另一个实例，以另外进行该通信事件的建立，该实例向下列各项中的至少一项发起另一个指令：媒体模态控制器；以及端点中的至少一个端点。在实施例中，该方法还可以包括：呼叫控制器实例基于接收的用户标识符来选择一个或多个端点，向所选择的端点发起第一指令；以及独立地分配该呼叫控制器实例或者另一个呼叫控制器实例来向媒体模态控制器发起第二指令(其包括所选择的端点中的一个端点的标识符)。1.2.2传输控制器通信系统300的代码模块被配置为实现传输控制器，其中该传输控制器被配置为对通信事件的媒体在该通信事件的端点之间的传输进行管理。分配传输控制器的实例以向端点的各自的传输代理传送该通信事件的传输控制信号，而无需访问这些端点的呼叫代理，独立于呼叫控制器并且响应于经由网络接收的第一指令，来分配该传输控制器实例。响应于传输控制器实例向第一指令返回响应，从所述分配中释放该传输控制器实例，同时呼叫控制器继续操作与端点的呼叫代理和/或与媒体模态控制器相通信(该实例被配置为从通信系统的分配中这样释放，所述通信系统包括用于这样释放该实例的释放逻辑)。第一指令可以是由呼叫控制器发起的。如图9B中示出的，传输控制器906包括无状态传输服务器组件958和有状态转发器组件，其中，无状态传输服务器组件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)之间的、并且根据本主题是由(如由业务管理器332从那些相同类型的各自的多个服务逻辑中选择的)云服务逻辑904、906、908、910、912集中控制的。如将意识到的，可以将该方法扩展到使得呼叫能够在两个以上的用户之间进行。在下文中，除非另外指出，否则向云控制服务逻辑(控制器)发送的所有请求消息(指令)，是通过经由该服务逻辑的组件的外部接口(由参与呼叫的该种类型的代理中的一个代理的请求方，或者支持该呼叫的不同类型的服务逻辑)建立的连接来发送的，该连接是至该组件的负载平衡器而非至该组件的各自虚拟机的连接。如上所述，每个接收的请求消息使该通信系统独立地分配适当的控制器的实例来处理该指令(在该实施例中，其相当于运行于其上的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使用所返回的地址，经由呼叫控制服务逻辑904的接口905来建立与呼叫控制服务逻辑904的连接，据此，客户端代理924向呼叫控制服务逻辑904发送(S1002)呼叫创建消息，其包括Alice的端点标识符和/或用户标识符，请求创建新的呼叫。例如，用户标识符可以包括Alice的用户名(其在该通信系统内对于Alice来说是唯一的)；端点标识符可以包括她的用户设备304a的标识符(例如，介质访问控制(MAC)地址)，注册和出站请求逻辑914先前已经与客户端416的地址相关联的存储了这些信息(参见上文)。该请求是由呼叫控制服务逻辑904的呼叫控制组件954接收的，作为响应，其创建(S1003a)包括除了别的之外的Alice的端点标识符的呼叫状态953。这涉及经由接口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，响应于此，注册和出站请求逻辑913向Bob当前登录到的Bob的用户设备304b发送该通知(或者向多个这样的用户设备发送该通知，如果Bob在一个以上的设备处登录的话)。经由Bob的用户设备304b订制的推送信道(推送信道在本领域中是公知的)来发送该推送通知(通知指令)，该订制是通过注册逻辑913来注册的。在实施例中，例如，如果Bob登录在所有那些用户设备处的话，则Bob可以具有与同一用户标识符(例如，用户名)相关联的多个用户设备(用户设备304b是其中之一)。那些设备中的每个设备订制推送信道，并且由呼叫控制器(以及根据需要由其它控制器(媒体、管道、传输))通过那些推送信道来发送各自的通知。在接收到Bob的用户标识符时，呼叫控制器可操作以选择与该标识符相关联的一个或多个端点(其包括用户设备304b)(即，与单一用户Bob相关联)，并且向所选择的端点发送前述的通知。因此，至端点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)，并且向呼叫控制器904返回(S1059b)所选择的音频控制器906和视频控制器908的各自的地址。所选择的音频控制器和视频控制器在该呼叫的持续时间或者直到该组件故障为止支持该呼叫(下面讨论的)。作为响应，呼叫控制器904使用针对其的各自的返回的地址，向所述媒体控制器906、908中的每个控制器发送各自的会话创建消息(指令)。该会话消息包含从呼叫状态953取回的关于该呼叫(Alice和Bob)的各种信息，例如，呼叫标识符以及Alice和Bob的端点标识符。每个媒体控制器906(音频)、908(视频)的分配的实例(如那些控制器的分配的各自的负载平衡器)向端点的适当代理传送媒体模态控制信号。经由网络接收的指令包括端点中的一个或多个端点的各自的标识符，媒体模态控制信号是使用那些标识符来传送的。在该实施例中，这是与Alice和Bob的音频代理926a、926b二者(相应的928a、928b)协商用于呼叫的媒体(分别为音频和视频)参数的一部分。这涉及：(使用由注册和出站请求逻辑914存储的信息)与Alice的客户端416a和Bob的客户端416b二者的相应的媒体代理926(音频)、928(视频)建立各自的连接，并且通过那些连接来交换各自的数据。这些协商还可以涉及：Alice和/或Bob的媒体代理926(音频)、928(视频)经由各自的外部接口907(音频)、909(视频)来与各自相应的媒体控制器906(音频)、908(视频)建立各自的连接，并且通过那些连接来交换各自的数据。在完成该音频(相应的视频)协商时，音频控制器906(相应的视频控制器908)向呼叫控制器904返回(S1064)响应消息(“OK”)，该消息是对于在S1060处发送的音频(相应的视频)会话创建消息的响应。前述的媒体模态控制器实例中的每个实例还可以被配置为生成用于该媒体模态(例如，音频、视频)的媒体模态状态数据，所生成的媒体模态状态数据被存储在该通信系统的计算机存储中，并且所存储的媒体模态状态数据持续到释放了每个媒体模态控制器实例之后，以便由该媒体模态控制器的另一个实例进行使用。在实施例中，可以向呼叫控制器发送该媒体模态状态数据，响应于此，呼叫控制器被配置为存储那些数据(例如，所返回的包括媒体模态状态数据的响应)。呼叫控制器可以被配置为将所存储的媒体模态状态数据供应给该媒体模态控制器的其它实例。例如，呼叫控制器的实例可以被配置为存储从媒体模态控制器实例接收的媒体模态状态数据，并且呼叫控制器的该实例或者另一个实例可以被配置为向其它媒体模态控制器实例供应所存储的媒体模态状态数据。替代地或另外地，媒体模态控制器实例可以被配置为将媒体模态状态数据作为媒体模态状态的一部分进行存储(参见上面的1.2.4)。在媒体协商期间(S1062)，(响应于指令S1064)分配至少一个媒体实例，并且(在返回响应时S1064)释放至少一个媒体实例，同时呼叫控制器继续进行操作(特别是当发起该指令S1060的呼叫控制器实例继续进行操作时)，例如通过如图10A中示出的传送呼叫状态更新S1040、S1042来与呼叫代理924a、924b相通信。那些实例可以是相同的，使得仅仅分配一个媒体控制器实例，并且随后从该分配中释放该实例，或者在呼叫控制器和媒体控制器之间可以存在另外的请求(由呼叫控制器执行)/响应(由媒体控制器执行)交换，其中在呼叫控制器继续进行操作时，针对每个来分配和释放多个媒体控制器实例。在步骤S1065a处，呼叫控制器904向业务管理器332发送对于分布式平台800的传输控制器的地址的请求。响应于接收到该请求，业务管理器332基于存储器334中存储的传输控制器业务管理简档，并且基于如由那些传输控制器在其处运行的各自的数据中心报告的由那些传输控制器的各自的当前资源使用(如上所述)，从多个传输控制器当中选择传输控制器910，并且返回(S1065b)所选择的传输控制器的地址。所选择的传输控制器在该呼叫的持续时间或者直到该控制器故障为止支持该呼叫(下面讨论的)。作为响应，呼叫控制器904使用针对其所返回的地址，向所述传输控制器910发送会话创建消息。该会话消息包含从呼叫状态953取回的关于该呼叫(Alice和Bob)的各种信息，例如，呼叫标识符以及Alice和Bob的端点标识符。随后，传输控制器910获得关于用户设备304a、304b的细节，并且与Alice和Bob的传输代理412a、412b协商用于该呼叫的传输参数(例如，分组化协议)。这涉及：(使用由注册和出站请求逻辑914存储的信息)建立与Alice的客户端416a和Bob的客户端416b二者的相应传输代理930的各自的连接，并且通过那些传输连接来交换数据。这些协商还可以涉及：Alice和/或Bob的传输代理930经由外部接口911来与传输控制器910建立各自的连接，并且通过那些连接来交换数据。传输控制器还例如按照支持该呼叫的媒体服务的类型(这里，音频和视频)(其是在步骤S1070处返回的)从呼叫控制器904请求媒体细节(S1068)，并且还可以从音频控制器906和/或视频控制器908请求另外的细节(未示出)。根据该信息和从Alice和Bob的传输代理930获得的信息，传输控制器确定(除了别的之外)被用于该呼叫的管道的数量(一个管道用于每种类型的媒体，这里，两个)，并且针对那些管道确定通过网络从Alice的用户设备304a到Bob的用户设备304b的各自的路径。一旦这样被确定，传输控制器就向业务管理器发送针对分布式平台800的管道控制器的地址的请求(S1071a)。响应于接收到该请求，业务管理器332基于存储器334中存储的传输控制器业务管理简档，并且基于如由那些传输控制器在其处运行的各自的数据中心报告的由那些传输控制器的各自当前的资源使用(如上所述)，从多个传输控制器当中选择管道控制器912，并且返回(S1071b)所选择的管道控制器的地址。随后，该管道控制器在该呼叫的持续时间或者直到该控制器故障为止支持该呼叫(下面讨论的)。作为响应，传输控制器910向所选择的管道控制器912发送(S1014)管道创建消息，其中该管道创建消息包括所确定的要被创建的管道的数量(这里，两个)，以及关于针对那些管道中的每个管道的所确定的通过网络301的路径的各自的细节。作为响应，管道控制器根据这些各自的细节来创建(S1076)该数量的管道。对管道的创建涉及：(使用由注册和出站请求逻辑914存储的信息)建立与Alice的客户端416a和Bob的客户端416b二者的相应的管道代理332的各自的连接，并且通过那些传输连接来交换数据。这些协商还可以涉及：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处的这样的信息的请求是由传输服务器组件直接地转发给该VM的，用于进行处理(旁路负载平衡器957)。由于该原因，经由接口911向传输控制器发送的任何请求(其依赖于特定的VM转发器组件对于先前请求的处理的结果)，包括该VM的标识符。在已经完成呼叫建立之后，传输服务器不再维持关于由该呼叫控制器为了帮助服务呼叫创建的会话的任何信息(并且依赖于其它服务逻辑来维持例如在呼叫控制器904的呼叫状态953和/或管道控制器912的管道状态961中的任何必要的信息)。此外，在上面的呼叫建立过程期间，管道状态信息是由管道控制器912的有状态管道状态组件962来维持的，也就是说，管道状态组件956的每个VM的确在其自己各自单独的存储器资源中(而不是在存储器内组件960中)存储关于已完成事务的信息，这是由于与共享的存储器内资源相比，通常会进一步访问这些资源。因此，需要访问被存储在单独的VM处的这样的信息的请求是由管道控制组件直接地转发给该VM的，用于进行处理(旁路负载平衡器963)。由于该原因，在呼叫建立期间，经由接口913向传输控制器发送的任何请求(其依赖于特定的VM转发器组件对于先前请求的处理的结果)，包括该VM的标识符。一旦已经建立了该呼叫(在该时间点，通常管道控制器将接收关于该呼叫的更少的请求)，在不再进一步依赖管道控制器908的VM的有状态行为的情况下，在管道状态961中维持管道状态信息(以类似于呼叫控制器904维持呼叫状态953的方式)。因此，一旦在呼叫建立期间，已经分配了管道控制器实例，(响应于图10B中的指令S1074)，在常规操作中，其将不从该分配中释放，直到已经创建管道为止(即，直到返回图10B中的响应S1078为止)。当这样释放管道控制器时，传输控制器(并且具体地，发起指令S1074的传输控制器的实例)继续进行操作，(例如，如图10B中的S1080中通过向媒体控制器传送管道细节)与传输代理和/或与媒体控制器相通信和/或(例如，如图10B中的S1080中通过向传输控制器返回响应S1088)与呼叫控制器相通信。一旦在呼叫建立期间已经分配了传输控制器实例(例如，响应于指令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呼叫和附着的媒体服务。该解耦的服务设计方案允许每个服务就该服务的内部工作而言是自治的，其包括部署、规模和服务特定的资源管理。该自治性允许每个服务独立地对关于该特定服务的负载和规模的需求作出反应，而不会由于单一服务的规模需求的直接结果，而存在由针对所有其它服务都进行调节或者改变的需求引起的设计方案。这意味着，如果针对特定国家中的所说的视频媒体的需求增加，则仅仅视频媒体服务需要调节该特定国家的服务基础设施，而不对其它服务寄予进行一致的调节的直接需求。注意到的是，可能存在针对其它服务同时进行调节的需求，但是这将纯粹由需求的类型、每个服务的规模限制来驱动，而不是链接的系统设计方案驱动需求。在实施例中，可以如下地实现这样的调节。可以独立于其它类型的服务，向每种类型的服务分配物理计算机资源(例如，物理存储器资源、物理处理资源)。例如，如果第一类型的一个或多个服务逻辑被配置为传送第一类型的服务，以及第二类型的服务的一个或多个服务逻辑被配置为传送第二类型的服务，则可以独立于第二类型的服务，来向第一服务分配另外的资源。可以以下面的方式中的一种或多种方式来增加(相应地减少)用于第一类型的服务的资源分配：-通过部署该种类型的另外的(相应地，终止现有的)服务逻辑，即，通过向第一类型的新服务逻辑分配物理计算机资源(相应地，不分配用于该种类型的现有服务逻辑的计算机资源)，这个方面的一个例子是在WindowsAzureTM云平台上部署新的web应用；-通过增加(相应地，减少)第一类型的一个或多个现有服务逻辑的组件内的虚拟机的数量，即，增加(相应地，减少)用于该组件的计算机资源分配，这个方面的一个例子是改变WindowsAzureTM云平台上的web应用的web角色或者工作者角色内的实例的数量；-通过增加(相应地，减少)第一类型的一个或多个现有服务逻辑的组件内的复制的虚拟机的“大小”(其是被分配的物理资源的相应的数量)，即，增加(相应地，减少)向特定组件的每个这样复制的虚拟机分配的各自的计算机资源，这个方面的一个例子是重新调整WindowsAzureTM云平台上的web应用的web角色或者工作者角色；使用后两种技术，可以独立于(相同类型的和不同类型的二者的)其它服务逻辑，向一个服务逻辑分配资源。例如，可以向第一类型的第一服务逻辑的组件添加更多的VM，和/或对那些组件的VM重新调整，而不改变该种类型的其它服务逻辑的组件，也不改变不同类型的其它服务逻辑的组件。此外，使用后两种技术，可以独立于彼此地向相同服务逻辑的不同组件分配资源(例如，在不改变其它组件的情况下，向一个组件添加VM、或者重新调整一个组件的VM)。每个数据中心320a、320b、320c等等的DC控制模块构成可操作以实现这些分配的资源分配逻辑，这是由于每个都具有关于其自己的数据中心内的物理资源使用的控制。如讨论的，通过向数据中心的外部控制模块559供应配置信息来实现资源分配。例如，可以以独立于彼此的方式(也就是说，在无需改变其它控制器的情况下)，以及独立于在相同的分布式平台800上运行的任何其它呼叫控制器、音频控制器、视频控制器、传输控制器和管道控制器的方式，向呼叫控制器904、音频控制器906、视频控制器908、传输控制器910和管道控制器912中的任何一个控制器分配计算机资源。例如，如果针对特定的国家中的所说的视频媒体的需求增加，则仅仅被部署在该国家中的视频媒体服务逻辑需要调节(通过在该国家部署新的视频控制服务逻辑，或者通过增加向在该国家中运行的现有视频控制服务逻辑分配的资源)，而不对其它服务寄予进行一致的调节的系统设计驱动的需求。此外，可以独立于那些组件中的其它组件，向那些控制器的组件分配资源。例如，可以独立于内存存储组件，向呼叫控制器904的呼叫控制组件954分配资源，反之亦然。例如，如果呼叫控制组件954不具有足够分配的处理资源来处理外部请求，但是内存存储组件具有足够分配的处理资源来处理内部读/写请求，则可以在不改变向内存存储组件分配的处理资源的情况下，向无状态呼叫控制组件分配更多的处理资源(通过向其添加更多的VM或者通过添加其VM的大小)。类似地，可以向内存存储组件分配另外的共享存储器资源，以使得其能够存储更多的呼叫状态，而无需改变向呼叫控制组件的每个VM分配的存储器资源(这可能是不必要的，由于呼叫控制组件的每个VM在任何事务的持续时间，只需要存储至多单一呼叫状态，或者其一部分)。可以类似地独立地调整用于其它控制器的组件的资源分配。3.控制服务逻辑(控制器)故障和呼叫状态复制公开了用于在经由通信网络连接的端点之间实现通信事件的通信系统，该通信系统包括：多个处理单元，每个处理单元使用计算机存储并且保持用于管理通信事件的可执行代码模块，所述代码模块被配置为实现一个或多个呼叫控制器，用于建立通信事件并且用于对所建立的通信事件进行管理；其中，将计算机存储划分成多个故障容许区域；其中，第一呼叫控制器实例被配置为访问计算机存储的第一故障容许区域以访问呼叫状态，分配第一呼叫控制器实例，以响应于经由网络接收的第一指令来访问该呼叫状态；并且其中，将该呼叫状态的至少一部分复制在计算机存储的第二故障容许区域中，使得第二呼叫控制器实例可以访问该呼叫状态的所述至少一部分，分配第二呼叫控制器实例，以响应于经由网络接收的第二指令来访问该呼叫状态的所述至少一部分。还公开了一种对经由通信系统的通信网络连接的端点之间的通信事件进行管理的方法，该通信系统包括多个处理单元，每个处理单元访问保存可执行代码模块的计算机存储，所述可执行代码模块用于管理通信事件，所述代码模块被配置为实现呼叫控制器，以建立通信事件并且对所建立的通信事件进行管理，将计算机存储划分成多个故障容许区域，该方法包括：分配呼叫控制器的第一实例以进行通信事件的建立，响应于此，第一呼叫控制器实例将该通信事件的呼叫状态存储在第一故障容许区域中；以及分配呼叫控制器的第二实例以进一步进行通信事件的建立和/或管理所建立的通信事件，响应于此，第二呼叫控制器实例在第二故障容许区域中，访问呼叫状态的至少一部分的副本。第二故障容许区域与第一故障容许区域不同。在该实施例中，响应于对第一呼叫控制器实例的检测状况，分配呼叫控制器的第二实例来访问该呼叫状态的至少一部分。该检测状况是下列各项中的一项：第一呼叫控制器实例的故障；对第一呼叫控制器实例的停止使用；以及呼叫控制器的第一实例使用处理单元的不足的物理资源来处理第二指令等等。所述处理单元还可以跨越多个故障容许区域分布，第一呼叫控制器实例和第二呼叫控制器实例是在第一故障容许区域和第二故障容许区域中的相应的处理单元上执行的。计算机存储的故障容许区域可以基本上与处理单元的故障容许区域相对齐，或者可以不与其对齐(也就是说，使得对其可访问的处理单元集合和计算机存储集合与相同的故障源隔离)。在下面的例子中，第一实例是第一呼叫控制器的实例，以及第二实例是处于不同的数据中心的第二呼叫控制器的实例(其可以与第一实例具有不同的地理位置，或者可以不具有不同的地理位置)。计算机存储和处理单元的故障容许区域基本上是对齐的，由于二者与处理单元集合和那些集合使用的计算机存储的部分位于的数据中心相对应。根据本公开内容，用户设备包括：网络接口424，其被配置为经由通信系统的通信网络，从该通信系统的呼叫控制器接收指令，该呼叫控制器被配置为访问建立的通信事件的呼叫状态；计算机存储426，其被配置为存储该呼叫状态的本地版本；以及处理单元402，其被配置为执行呼叫代理(其中该呼叫代理使用该呼叫状态的本地版本)，并且被配置为响应于从通信控制器所接收的指令来更新该呼叫状态的本地版本。云800的上述控制系统(其‘支持’该通信系统300)是高性能的并且对于故障是高复原的：如讨论的，特定服务逻辑的组件内的各个VM的故障是由相关的根VM522和/或DC控制模块556来自动地矫正的(参见图5和伴随的文本)。如上面指示的，在DC控制模块556的控制之下，通过在相同数据中心320处运行的多个各自复制的虚拟机(VM)上执行的复制的代码实例，来实现服务逻辑的每个组件。如果组件的那些VM中的一个VM故障(例如，由于在该VM上执行的应用代码的软件故障、该VM自身的软件故障、其所运行在的管理程序的软件故障、该管理程序所运行在的服务器的硬件故障(其中，该管理程序在该服务器本地，或者分布在该服务器所位于的整个故障区))，则这在该组件之外是‘不可见的’：响应于该故障，负载平衡器停止向该VM转发请求，并且简单地将任何请求转发到该组件的剩余VM中的选择的一个VM(这些VM中的所有VM能够对这样的请求进行处理)。例如，由呼叫控制服务逻辑904的内存存储组件952存储用于呼叫的呼叫状态953，其中该呼叫控制服务逻辑904在由该内存存储组件的虚拟机共享的并且对于该内存存储组件的虚拟机中的所有虚拟机可访问的物理存储器资源中控制该呼叫。如果那些虚拟机中的一个虚拟机故障(例如，如上面的)，则呼叫状态953仍然可以(例如，由呼叫控制组件954)经由其它虚拟机中的任何一个虚拟机来访问，同时在该呼叫控制器所运行在的DC控制模块556的控制之下，重新创建该虚拟机。如果整个服务逻辑发生故障(例如，由于特定组件内的所有虚拟机出于任何原因的故障，或者由于整个数据中心的硬件或者软件故障)，则在请求时，业务管理器332可以选择该相同类型的另一个服务逻辑来接管(例如，其运行在不同的数据中心处)。例如，如果媒体控制器906(音频)、908(视频)中的一个控制器或者如果传输控制器(910)在各自的协商阶段(S1062、S1072)期间故障，则响应于检测到该故障，呼叫控制器904可以从业务管理器332请求该种类型的替换服务逻辑的地址，并且可以指示该替换服务逻辑通过如在S1060或者S1066中的向其发送会话创建消息，来重新开始正在讨论的协商。随后，音频、视频或者传输协商可以重新开始，而无需重复较早的呼叫建立步骤(因为由音频控制器、视频控制器或者传输控制器需要的任何信息被维持在呼叫控制器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示出了在第一数据中心920a处运行的第一呼叫控制器905a，其包括具有外部接口905a的第一无状态呼叫控制组件954a和具有内部接口953a的内存存储组件952a。(由该呼叫控制器所运行在的数据中心320a的DC控制模块)将物理共享存储器资源的第一集合分配给第一呼叫控制器905a，用于由该呼叫控制器905a的内存存储组件952a使用。这些物理存储器资源在地理上位于第一数据中心920a处。第一呼叫控制器905a通过向呼叫代理924传送呼叫控制服务来控制呼叫(响应于从业务管理器332接收到该呼叫控制器的地址，呼叫代理924最初已经从该呼叫控制器请求该服务，业务管理器逻辑332至少部分地基于存储器334中存储的呼叫控制器策略724[1]来选择了该呼叫控制器)。为此，第一呼叫控制服务逻辑还与其它服务逻辑(例如，音频控制器、视频控制器、传输控制器)相通信。呼叫状态953a是由内存存储组件953a存储的。在第二数据中心920b处运行的第二呼叫控制器904b，包括具有外部接口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(具体地，分配的其呼叫控制器实例)响应于事件(例如，图10A和图10B中的S1006、S1012、S1020、S1088)，通过与内存存储组件952a进行通信，来(通过修改其至少一部分)更新(S1104)呼叫状态953a。该呼叫控制组件还可操作以经由第二呼叫控制组件954b的外部接口905b，来向第二呼叫控制器904b发送(S1108)更新后的呼叫状态953a的至少一部分的副本(例如，至少通过向其发起指令)。更新后的呼叫状态的该发送的部分包括该呼叫的标识符。响应于对其的接收，第二呼叫控制组件954b(具体地，分配的其呼叫控制器实例)转发所更新的呼叫状态以借此进行存储；第二内存存储组件952b根据该更新来修改(使用呼叫标识符标识的)呼叫状态副本953b。第一呼叫控制组件可以是响应的，以响应于多个这样的指令和/或响应来对第一区域中的呼叫状态进行更新，但是仅仅响应于对该多个指令和/或响应的选择(其是至少一个，而不是全部)，对第二区域中的该呼叫状态的至少一部分进行更新。例如，可以响应于示出的导致图10A和图10B中的呼叫状态更新的指令中的一些指令(例如，在标题1.2.1呼叫控制器之下，仅仅对上面被称为第一指令至第八指令的指令的选择)，仅仅对呼叫状态副本953b进行更新。所述指令的选择可以取决于该呼叫的一个或多个参数(下面讨论的)。这种粒度提供了对于控制器故障的复原能力(其中随着复制越多的呼叫状态，提供更大的信赖，例如，在较低的目标处，在例如控制器故障的事件中，使得终止的呼叫能够被重新启动，以及在较高的目标处，利用或多或少无缝地从故障的控制器‘切换’到新的控制器，来防止呼叫被完全终止)与存储器节约(其中针对较少的呼叫状态复制需要较少的计算机存储)之间的可调整的权衡。如下面解释的，如果第一呼叫控制器故障(图11B中图形地示出的)，则由第二呼叫控制器904b使用呼叫状态副本953b来恢复该呼叫控制服务的传送。第一呼叫控制器的这样的故障(即，其第一实例的故障)是由呼叫代理924可检测的，例如，由于与第一呼叫控制器904a的现有连接被非预期地终止和/或由于与超时周期相比，针对于其的请求消息变得更长时间没有响应。第一呼叫控制器的这种故障也是由业务管理器332基于来自数据中心320(第一呼叫控制器运行在此处)的资源报告模块(例如，图5B的558)的报告可检测的。响应于检测到该故障，业务管理器被配置为：基于呼叫控制器策略722[1]，对于针对呼叫控制器的地址的任何请求进行响应，其中该请求导致对第一呼叫控制器的选择(如果其关于第二呼叫控制器的地址可用的话)。响应于呼叫代理924的这样的检测，呼叫代理924再次从业务管理器332请求呼叫控制器的地址。该请求可以指示第一呼叫控制器是未响应的，并且指示应当返回不同呼叫控制器的地址，或者该请求可以不对此进行指定(并且可以依赖于业务管理器332也检测到第一组件的故障)。无论哪种方式，作为响应，业务管理器332返回第二呼叫控制器904b的地址，可以使用该地址来经由接口905b，与第二呼叫控制组件954b建立连接。随后，服务代理924可以发送包括呼叫标识符的任何请求，其中所述任何请求已经被发送至第一呼叫控制器904a，而未能至第二呼叫控制器904b。第二呼叫控制器使用利用这些请求的呼叫标识符识别的呼叫状态副本953b来对这些请求进行处理。这可以涉及：继续建立通信事件(如果其尚未被建立的话)和/或一旦(由第一呼叫控制器和第二呼叫控制器中的任何一个呼叫控制器)建立了通信事件，对该通信事件进行管理。在一些实施例中，呼叫状态副本953b可以不是呼叫状态953a的完全副本，即，原始呼叫状态可以包含比该副本更多的信息，该副本只包含关于该呼叫的选择性信息。在该情况下，在创建了呼叫状态953a时，由第一呼叫控制器发送给第二呼叫控制器的初始副本，是该呼叫状态的仅仅一部分的副本，其包含足够的信息来使得该呼叫能够继续(即使第一呼叫控制器故障，而不是该呼叫的每一个单独的参数(在第一呼叫控制器故障时，可以对这些参数进行重置))。替代地或另外地，响应于某些事件而不是其它事件，第一呼叫控制器可以只向第二呼叫控制器发送消息以更新呼叫状态副本953b(使得某些事件导致‘主’呼叫状态953a的更新，而不是副本953b的更新)。在该情况下，即使某个最近的历史丢失，在第一呼叫控制组件故障时，副本953b也包含足够的信息来使得该呼叫能够继续。与完全的呼叫状态复制相比，前者需要较多的存储器资源，而后者需要较多的网络资源，虽然与完全复制相比，如果第一呼叫控制器故障，则二者确实导致呼叫信息的某些丢失。对多少呼叫状态进行复制可以取决于该呼叫的一个或多个参数。也就是说，在一个实施例中，呼叫控制器被配置为基于通信事件的一个或多个参数，来选择呼叫状态的至少一部分来进行所述复制。参数可以包括与参与该通信事件的一个或多个用户相关联的一个或多个优先级参数(例如，其中较高优先级的用户是已经为优质服务付费的那些用户，以及较低优先级的用户是尚未为优质服务付费的那些用户)，其中对于较高优先级参数来说，所选择的呼叫状态的至少一部分构成呼叫状态的较大部分，而对于较低优先级参数来说，构成呼叫状态的较少部分。在该情况下，由通信系统300的运营商向用户分配质量参数。替代地或另外地，参数可以包括该通信事件的当前经过的时间(其是自从建立了该通信事件以来的时间量，或者自从第一次创建呼叫状态以来的时间量)，其中对于较长的经过的时间来说，呼叫状态的至少一部分构成该呼叫状态的较大部分，而对于较短的经过的时间来说，构成该呼叫状态的较少部分。参数形成呼叫状态的一部分，使得呼叫状态自身指定应当复制多少该呼叫状态。例如，所复制的该呼叫状态的至少一部分可以包括：参与该通信事件的一个或多个用户的各自的标识符和/或所述端点中的一个或多个端点的各自的标识符。如果原始呼叫状态变得不可访问，则这至少使得该呼叫能够被重新启动。呼叫状态的该至少一部分规定了所述用户之间的关系，例如，将所述用户中的一个用户标识为该呼叫的仲裁者(或者所有者)。所复制的该呼叫状态的至少一部分可以包括：例如，在呼叫的建立期间，如从媒体模态控制器接收的该通信事件的媒体模态状态数据(上面描述的)。例如，媒体模态(例如，音频、相应的视频)状态数据可以包括：针对用户中的每个用户，一个或多个媒体模态(例如，音频、相应的视频)是否是活动的(例如，针对参与用户中的一个或多个用户，是否对各自的音频进行静音，相应地，针对参与用户中的一个或多个用户，是否启用各自的视频的指示)的各自的指示。呼叫控制器(例如，其第二实例)可以从第二区域中的该呼叫状态的所述至少一部分，向媒体控制器供应媒体模态状态数据，响应于此，分配媒体模态控制器的实例，以基于所供应的媒体模态状态数据，向端点传送媒体模态控制信号(就如同例如已经由第一呼叫控制器实例从第一区域中的原始呼叫状态供应媒体模态状态数据)。服务的解耦意味着，无论检测到的什么状况造成第一呼叫控制器的故障，该状况可能不会影响从其供应媒体模态状态数据的媒体模态控制器。因此，该媒体模态控制器可以继续进行操作，以在所检测到的状况之后，管理该通信事件的媒体模态。可以基于所述参数来对所复制的该呼叫状态的所述至少一部分进行选择，以包括下列各项中的一项：该通信事件的媒体模态状态数据，以及参与该通信事件的一个或多个用户的各自的标识符和/或所述端点中的一个或多个端点的各自的标识符(例如，对应于较高优先级的用户/较长的经过的时间)，或者所述标识符而非所述媒体模态状态数据(例如，对应于较低优先级的用户/较短的经过的时间)。因此，可以根据期望，基于用于提供不同水平的稳健性的参数来对复制进行调整。例如，基于所述一个或多个参数，可以选择呼叫状态的所述至少一部分来构成下列各项中的一项：-呼叫状态的第一部分，据此，如果第一故障容许区域变得不可访问，则呼叫控制器可以使用第一部分来继续对通信事件进行管理，而无需终止该通信事件，或者-呼叫状态的第二部分，据此，如果第一故障容许区域变得不可访问，并且作为响应而终止了该通信，则呼叫控制器可以使用第二部分来重新建立该通信事件。例如，呼叫状态的第一部分可以构成呼叫状态的全部，从而将呼叫状态的全部复制到第二故障容许区域中。3.1复制媒体模态状态在实施例中，第一媒体模态控制器实例被配置为访问计算机存储的第三故障容许区域以访问媒体模态状态，响应于经由网络接收的第三指令，分配第一媒体模态控制器实例来这样访问媒体模态状态；并且其中，将该媒体模态状态的至少一部分复制到计算机存储的第四故障容许区域中，使得第二媒体模态控制器实例可以访问该媒体模态状态的至少一部分，响应于经由网络接收的第四指令，分配第二媒体模态控制器实例以这样访问媒体模态状态的至少一部分。媒体模态控制器可以被配置为向呼叫控制器的第一实例供应媒体模态状态数据，响应于此，基于其对第一区域中的呼叫状态和第二区域中的呼叫状态的至少一部分进行更新。可以响应于检测到的第一媒体模态控制器实例的状况，分配媒体模态控制器的第二实例来访问媒体模态状态的所述至少一部分。该检测到的状况可以是下列各项中的一项：第一媒体模态控制器实例的故障；对媒体模态呼叫控制器实例的停止使用；以及媒体模态控制器的第一实例使用处理单元的不足的物理资源来处理第二指令。呼叫控制器可以继续进行操作，以建立该通信事件，和/或在所检测到的状况之后，对所建立的通信事件进行管理。如将显而易见的，可以以等同于上述的呼叫状态复制的方式，来复制媒体模态状态(其中呼叫控制器代替媒体模态控制器，以及呼叫状态代替媒体模态状态)。第三故障容许区域与第四故障容许区域不同。第三故障容许区域和第四故障容许区域可以与在其中维持呼叫状态以及其副本的第一故障容许区域和/或第二故障容许区域不同，或者可以与其相同。3.2虚拟高速缓存实现方式公开了在通信系统中复制数据的方法，其中该通信系统包括不同地理位置处的多个处理单元，每个处理单元使用该地理位置处的计算机存储，所述计算机存储保持用于实现虚拟高速缓存的相应的代码模块，该方法包括：向所述处理单元中的第一处理单元发送第一存储指令，响应于此，该处理单元上的虚拟高速缓存的第一实例访问第一处理单元的计算机存储来存储数据；以及对其作出响应，向与第一处理单元不同的地理位置处的所述处理单元中的第二处理单元发送第二存储指令，响应于此，该处理单元上的第二虚拟高速缓存实例访问第二处理单元的计算机存储来复制所述数据。该数据可以包括在通信系统的两个或更多端点之间进行的通信事件的呼叫状态的至少一部分。4.独立可部署的代理虽然上文已经参照均具有全‘堆栈’的代理(呼叫、诸如音频和视频之类的媒体、传输、管道)的端点进行了描述，但是通信系统架构的解耦性质帮助其自己在单独的设备上部署代理。例如，呼叫控制代理可以被部署在用户的一个设备上，媒体代理被部署在该用户的另一个设备上；呼叫控制器可以简单地向媒体控制器提供其它设备的标识符，并且它们将在该设备和其它呼叫端点之间创建适当的媒体会话，而媒体控制器甚至不需要知道存在控制用户设备。此外，其它用户设备可以具有最小的呼叫控制逻辑或者不具有呼叫控制逻辑，并且可以进行简单地动作来例如接收和捕获视频，其中所有控制是通过呼叫控制器和控制设备之间的交互来处理的。在单独的设备上部署的代理与它们各自的控制器进行交互，并且关于彼此实现间接的控制，就如同它们部署在相同的设备上(如上所述)。公开了一种用于在计算机系统之间实现通信事件的通信系统，该通信系统包括第一计算机设备和第二计算机设备以及经由通信网络连接的一个或多个另外的端点，该通信系统包括：多个处理单元，每个处理单元访问保存可执行代码模块的计算机存储，该可执行代码模块用于管理通信事件，所述代码模块被配置为实现媒体模态控制器和呼叫控制器，其中该媒体模态控制器被配置为对建立的通信事件的媒体模态进行管理，以及该呼叫控制器被配置为建立该通信事件；其中，响应于由呼叫控制器向媒体控制器发起的指令，分配媒体模态控制器的实例，以向第一设备上的媒体代理传送该通信事件的媒体模态控制信号，而无需访问第二设备上的呼叫代理；并且其中，呼叫控制器对于该指令的发起是响应于经由网络从第二设备上的呼叫代理接收的指令。还公开了一种在计算机系统与经由通信系统的通信网络连接的一个或多个另外的端点之间实现通信事件的方法，该计算机系统包括第一计算机设备和第二计算机设备，该通信系统包括多个处理单元，每个处理单元访问保存可执行代码模块的计算机存储，该可执行代码模块用于管理通信事件，所述代码模块被配置为实现媒体模态控制器和呼叫控制器，其中该媒体模态控制器被配置为对建立的通信事件的媒体模态进行管理，以及该呼叫控制器被配置为建立该通信事件，该方法包括：响应于经由网络从第二设备上的呼叫代理接收的指令，呼叫控制器向媒体控制器发起指令；以及响应于由呼叫控制器发起的指令，分配媒体模态控制器的实例，以向第一设备上的媒体代理传送该通信事件的媒体模态控制信号，而无需访问第二设备上的呼叫代理。呼叫控制器可以被配置为：响应于从第二设备上的呼叫代理接收的指令来向媒体模态控制器发送第一设备的标识符，所述由媒体模态控制器实例对于媒体模态控制信号的传送是基于该标识符的。还公开了一种包括第一计算机设备和第二计算机设备的计算机系统。第一计算机设备包括：网络接口，其被配置为经由通信系统的通信网络，与该通信系统的媒体模态控制器进行通信，其中该媒体模态控制器被配置为对建立的通信事件的媒体模态进行管理，该媒体模态控制器响应来自该通信系统的通信控制器的指令；以及处理单元，其被配置为执行媒体模态代理，其中该媒体模态代理被配置为与媒体模态控制器而不与通信控制器进行通信。第二计算机设备包括：网络接口，其被配置为经由网络与呼叫控制器进行通信，该呼叫控制器被配置为建立通信事件；以及处理单元，其被配置为执行呼叫代理，其中该呼叫代理被配置为与呼叫控制器进行通信，并且通过与呼叫控制器的所述通信，来间接地控制第一用户设备的媒体模态代理的操作。因此，第二设备的呼叫代理以上述方式来间接地控制第一设备上的媒体代理。在现有的通信系统中，为了用户能够使用一个以上的设备(例如，智能电话和电视)来同时地参与呼叫(例如，智能电话用于呼叫音频，以及TV用于呼叫视频)，除非通过有线或者无线网络(其包括蓝牙TM以及类似的)来直接连接的那些设备，否则在两个设备处需要全实时控制栈，其包括呼叫控制、媒体控制、媒体和网络栈以及用户层级认证。这样的全栈包括需要被部署到端点的用户和特征服务传送控制逻辑二者，但是由于处理和安全限制，使这个成为更复杂和受约束的选项。本主题允许将用于特定“模态”的用户侧逻辑(也就是说，媒体服务的类型，例如，用于提供特定特征的实时媒体通信事件的用户侧逻辑，诸如呼叫音频、呼叫视频和诸如屏幕共享之类的丰富特征、或者整理成适应较大的高分辨率屏幕的呼叫视频)作为模态代理(也就是说，该类型的服务代理)被单独地安装在不同的设备处，以及在设备或者端点上安装任何需要的媒体和网络栈，允许其被模态控制器发现，并且因此在功能服务传送的背景下被用作有效模态端点(例如，在呼叫中)。当关于通信设置中的媒体、关于音频和视频二者(以及例如屏幕共享和其它模态)来考虑更多的需求使用情况时，利用能够增强和丰富特定模态的体验的专家设备和其它端点是一个强大的工具，例如，在与平板设备(其中呼叫控制在此运行)相反的较大屏幕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[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可以接收呼叫视频，并且运行视频代理而不运行呼叫代理，并且受到智能电话上的呼叫代理的控制。智能电话可以接收呼叫音频并且运行音频代理，或者其可以不接收呼叫音频并且不运行音频代理，并且例如被连接到网络的扬声器系统可以接收呼叫音频并且运行呼叫代理(但不运行呼叫代理或者视频代理)。将媒体传送到不同于对呼叫进行控制的设备的设备的事实，对于媒体控制器和传输控制器是不可见的。对上述呼叫建立的唯一修改在于：呼叫控制器向媒体控制器/传输控制器供应另一个设备的端点标识符。例如，用于传送呼叫的实时音频数据的音频管道可以通过传输控制器和管道控制器来建立，其中该传输控制器和管道控制器分别与用户设备304处实现的客户端416的传输代理和管道代理来传送控制数据(如图10A和图10B中示出的)，而用于传送呼叫的实时视频数据的视频管道可以通过传输控制器和管道控制器来建立，其中该传输控制器和管道控制器分别与另一个设备304’处实现的传输代理和管道代理来传送控制数据(如图10A和图10B中示出的)。呼叫控制是通过呼叫控制器与设备304的呼叫代理进行交互来实现的，并且呼叫代理可以经由呼叫控制器，与另一个设备304’上的代理进行通信，转而，呼叫控制器可以经由相应的云控制器来与那些代理进行通信。因此，不需要另一个用户设备304’来实现任何形式的呼叫控制代理或者任何其它形式的呼叫控制逻辑。该通信系统可以包括任何形式的检测逻辑，其中该检测逻辑被配置为检测第一设备和第二设备的关联性，响应于此，检测逻辑使得向第二设备上的呼叫代理发送通知。例如，该检测逻辑可以被实现在传输层级(例如，由于第一设备和第二设备被连接到共同的接入点1020，所以在传输层级处出现关联性)，例如，作为传输控制器的一部分或者对于传输控制器可访问，传输控制器向呼叫控制器通知所检测到的关联(或者其通知媒体控制器，而媒体控制器通知传输控制器)，然后，呼叫控制器向用户设备上的呼叫代理进行通知。也就是说，在实施例中，通信系统的检测逻辑向下列各项中的一项进行通知：呼叫控制器，响应于此，呼叫控制器发送所述通知；或者媒体模态控制器，响应于此，媒体模态控制器向呼叫控制器进行通知，并且响应于此，呼叫控制器发送所述通知。在该情况下，检测逻辑可以是传输控制器的一部分。替代地，所有控制器可以检测较高层级的关联性。例如，用户可以通过共享密钥的方式来创建第一设备和第二设备之间的关联性，例如，该共享密钥是从第一设备输出的(例如，显示的)并且被输入到第二设备处的配对代码，或者每个设备可以与共同的用户302相关联(例如，如果该用户在两个设备处登录的话)。在该情况下，检测逻辑可以是呼叫控制器的一部分。为了提供隐私和安全性，呼叫控制器可以基于某种策略，只是有条件地允许以上述方式来使用第一设备，其中该策略指示何时可以使用第一设备，以及何时不能如此使用第一设备(该策略例如包括准许的用户(例如，302)的标识符，和/或准许的用户设备的标识符(例如，第一设备304的标识符)。呼叫控制器被配置为访问计算机存储以访问该策略，所述由呼叫控制器向媒体模态控制器发起指令是依赖于该策略的。该策略可以指示准许(或者不准许)第二设备304和/或第二设备的用户402利用第一设备。在通信系统包括分别被配置为对不同的媒体模态进行管理的该媒体模态控制器和另一个媒体模态控制器(例如，音频和视频)的情况下，可以使用第一设备上的第一媒体代理(例如，视频)，使得将该呼叫的例如视频发送到第二设备，并且可以使用第二设备上的第二媒体代理(例如，音频)，使得将例如音频(和呼叫控制)保持在第二设备上。替代地，例如，可以使用第一设备304’上的音频代理和视频代理，其中仅仅呼叫控制是由第二设备304(其执行呼叫代理)来实现的。替代地，第三用户设备(未示出)可以运行例如视频，同时第二设备运行例如音频。在通信系统包括第一媒体模态控制器和第二媒体模态控制器(例如，音频和视频)的情况下，其中第一媒体模态控制器和第二媒体模态控制器被配置为对所建立的通信事件的各自的第一媒体模态和第二媒体模态进行管理，而无需访问第二设备上的呼叫代理。第一媒体模态控制器的实例可以被配置为向第一设备上的第一媒体代理传送该通信事件的第一媒体模态控制信号，而无需访问该计算机系统的第二计算机设备或者第三计算机设备上的第二媒体代理；以及第二媒体模态控制器的实例被配置为向第二媒体代理传送该通信事件的第二媒体模态控制信号，而无需访问第一媒体代理。响应于呼叫控制器向第一媒体模态控制器和第二媒体模态控制器发起的各自的指令，可以分别分配第一媒体模态控制器和第二媒体模态控制器的各自的实例，以传送第一媒体模态控制信号和第二媒体模态控制信号。针对第一媒体模态控制器的指令，是由呼叫控制器响应于从第二设备上的呼叫代理接收的第一指令发起的，并且其中，针对第二媒体模态控制器的指令，是由呼叫控制器响应于从第二设备上的呼叫代理接收的第一指令或者第二指令发起的。第一媒体模态控制器实例可以是响应于第一媒体模态控制器实例向针对其发起的指令返回响应，从所述分配中释放的，而第二媒体模态控制器实例继续进行操作，与第二媒体代理相通信。在实施例中，呼叫控制器可以被配置为响应于从第二设备上的呼叫代理接收的指令，向媒体模态控制器发送第一设备的标识符，所述媒体模态控制器对于媒体模态控制信号的传送是基于该标识符的。该媒体模态控制器实例是响应于媒体模态控制器实例向由呼叫控制器发起的指令返回响应，从所述分配中释放的，而呼叫控制器继续进行操作，与第二设备上的呼叫代理相通信。呼叫控制器的实例可以向媒体控制器发起该指令，并且在释放了该媒体控制器的实例之后，呼叫控制器的实例可以继续进行操作，与第二设备上的呼叫代理相通信。虽然在上文中，对其上的控制器进行实例化的通信系统的处理单元远离于呼叫端点(也就是说，该处理单元是不同于所述端点的处理单元)，但是在替代的实施例中，一些控制仍然可以由端点来实施(其是由端点上的控制器代码来实现的)。例如，在一个实施例中，如上所述，呼叫控制、音频控制、媒体控制、传输控制和管道控制均可以被集中地实现在云800中，而例如即时消息传送控制被实现在端点本身上(而不是由云控制服务逻辑来实现)。此外，虽然在上文中，不同地配置的代理(呼叫、媒体、传输、管道)是由用户设备来实现的，但是在其它实施例中，不同于用户设备的端点(例如，服务器、桥接器等等)可以实现所描述的代理中的一个或多个代理。通常，本文描述的功能中的任何功能可以使用软件、固件、硬件(例如，固定的逻辑电路)、或者这些实现方式的组合来实现。如本文使用的术语“模块”、“功能”、“组件”和“逻辑”通常表示软件、固件、硬件或者其组合。在软件实现的情况下，模块、功能或者逻辑表示当其在处理器(例如，CPU或者数个CPU)上执行时，执行指定的任务的程序代码。该程序代码可以被存储在一个或多个计算机可读存储器设备中。下面描述的技术的特征是独立于平台的，其意味着这些技术可以被实现在具有各种各样的处理器的各种各样的商业计算平台上。例如，用户设备还可以包括使得该用户设备的硬件执行操作(例如，处理器功能模块)等等的实体(例如，软件)。例如，用户设备可以包括可以被配置为维持指令的计算机可读介质，其中所述指令使得用户设备，并且更具体的这些用户设备的操作系统和相关联的硬件执行操作。因此，这些指令用以配置操作系统和相关联的硬件来执行这些操作，并且用此方式产生操作系统和相关联的硬件的转换以执行功能。这些指令可以是由计算机可读介质通过各种各样不同的配置向用户设备提供的。计算机可读介质的一个这样的配置是信号承载介质，并且因此被配置为例如经由网络，向计算设备发送这些指令(例如，作为载波波形)。计算机可读介质还可以被配置为计算机可读存储介质，并且因此不是信号承载介质。计算机可读存储介质的例子包括随机存取存储器(RAM)、只读存储器(ROM)、光盘、闪存、硬盘存储器、以及可以使用磁的、光学的和其它技术来存储指令和其它数据的其它存储器设备。虽然已经利用特定于结构特征和/或方法动作的语言描述了本主题，但是应当理解的是，在所附权利要求书中规定的主题并不必限于上述的特定特征或者动作。更确切地说，上面描述的特定特征和动作被公开为实现权利要求的示例性形式。