CN107005567B - 实现通信事件 - Google Patents

Abstract

本文公开了用于经由通信网络在客户端设备的用户与另一客户端设备的另一用户之间建立实时通信事件的方法和设备(例如，服务器)。与通信事件相关(例如，与通信事件建立过程相关)的消息包括与通信事件相关的多个选项，并且针对所述多个选项中的每个选项，可以访问对该选项唯一的不同的网络地址以选择该选项。

Description

实现通信事件

背景技术

常规的通信系统允许诸如个人计算机或移动设备之类的客户端设备 (端点)的用户通过诸如互联网之类的基于分组的计算机网络与一个或多个其他的端点进行语音或视频通话。时常地，由端点进行的通话数据的通信是由坚持经同意的通信协议的端点来实现的。其一个示例是会话发起协议(SIP)。广义上讲，SIP指示通话根据基于端点对端点请求响应的事务范式来进行协商，其中(除了其他的以外)，通话从初始的未连接的状态发展到实时媒体可以通过以下方式在端点之间流动，SIP用户代理向其他端点的其他用户代理发送一系列请求消息并且作为回应而接收相应的响应消息，其中可以类似地实现对通话的维持和最终的终止。每个用户代理可以在通话持续期间维持状态机，其用于追踪当前的通话状态。根据对突出请求的发送和对突出的响应的接收来适当地更新状态机。

发明内容

提供了该发明内容以用简化的形式介绍了进一步在下文的具体实施方式中所描述的概念的选择。该发明内容不旨在标识所要求保护的主题的关键特征或本质特征，也不旨在用于限制所要求保护的主题的范围。

所公开的是一种用于经由通信网络在客户端设备的用户与另一客户端设备的另一用户之间建立实时通信事件的方法。所述方法包括在客户端设备上运行的客户端通过经由网络向另一个客户端设备或者向连接至网络的服务器发送消息来执行通信事件建立过程的第一阶段。该消息包括与尚未执行的通信事件建立过程的第二阶段相关的多个选项。针对多个选项中的每个选项，该消息包括对该选项唯一的不同的网络地址，其可以被以选择该选项。所述方法还包括：检测对多个选项中的一个选项唯一的网络地址已经被访问；并且，作为响应，根据多个选项中的所述一个选项而发起通信事件建立过程的第二阶段。

还公开的是一种用于经由通信网络在客户端设备的用户与另一客户端设备的另一用户之间实现实时通信事件的服务器。所述服务器包括：计算机存储；网络接口，其被配置为从网络接收消息；以及处理器。所述处理器被配置为接收消息。所述消息包括与通信事件相关的多个选项，并且针对多个选项中的每个选项，可以访问对该选项唯一的不同的网络地址以选择该选项。所述处理器还被配置为，针对多个网络地址中的每个网络地址，将该网络地址和对应的服务器网络地址之间的映射存储在计算机存储中，将服务器网络地址发送至另一客户端设备或者连接至网络的另外的服务器。所述处理器还被配置为检测与对多个选项中的一个选项唯一的网络地址相对应的服务器网络地址已经被访问，并且响应于访问对该选项唯一的网络地址以选择该选项。

附图说明

图1是云平台的示意概述；

图2是对通信系统的示意图；

图3是对用户设备的示意图；

图4A是对数据中心的示意图；

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

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

图6示出了特定配置中的通信系统；

图7是通话建立过程的示意概述；

图8A是针对通话建立过程的信令图；

图8B是示出了可以如何终止通话的信令图；

图8C是示出了可以如何引导通话的信令图；

图8D是示出了呼叫者可以如何取消通话的信令图；

图9是对由通话控制器部署所存储的一组URI映射的示意图；

图10是一系列通话控制器部署的示意图，所述每个通话控制器部署实现一个URI重写过程；

图11A是形成对象图(例如，通话状态)的服务对象的示意图，而图 11B是可以如何在存储器中实现该图的示例；

图12A是形成对象图(例如，通话状态)的持续的和参考对象的示意图，而图12B是可以如何在存储器中实现该图的示例；

图13是针对序列化过程的流程图；

图14是针对反序列化过程的流程图；

图15是针对实现通话中服务请求的方法的流程图；

图16示意性地示出了示例性活动通话状态。

具体实施方式

当在网络的端点之间建立诸如通话(例如，音频通话、音频和视频(AV) 通话等)之类的实时媒体通信事件时，必须进行将包括是否允许双方彼此进行通话、使用什么音频和视频编码解码器、如何将媒体分组从一方端点路由至另一方等之类的多个因素和变量考虑在内的多个决策。在下文中所描述的实施例对来自“分布式平台”(另外被称为“云平台”或简单地称为“云”)内的实时媒体通信事件提供了集中式(相对于基于端点的)控制。即，通话是由在云上运行的各种中央控制器来控制的。

云意指经由网络(例如，互联网)可访问的计算平台，其包括由多个联网的计算机设备和在其上运行的系统软件所组成的分布式计算机系统，所述计算机系统提供了(潜在地非常大的)物理计算资源池——例如物理处理资源和物理存储器/存储资源、易失性的和/或非易失性的——并且系统软件被配置为通过实现多个独立的虚拟机(VM)(即对计算机系统的软件仿真)来划分该底层物理资源池。云提供者的示例包括Windows Azure (TM)、Amazon Web Services(TM)等。

对物理计算机资源的该池化以及通过虚拟化划分该池用于将硬件和软件考虑去耦合，这是由于(由平台的系统软件所实现的)虚拟化层提供将物理计算机资源(例如，可用的物理处理器时钟循环和存储器的物理位) 与“虚拟的”资源(即，实际上在每个虚拟计算机系统中被看见的资源) 分离所导致的。底层硬件的物理资源可以通过添加新的物理网络计算机设备或者升级现有的物理联网计算机来增加，并且仅仅在传统兼容性方面需要进行的考虑能够确保经升级的物理计算机系统仍然可以运行相同的通用虚拟机(即，不用对要在这些虚拟机上运行什么操作系统或应用代码进行任何考虑)。类似地，系统设计者可以设计系统(可能是具有许多组件的极度复杂的系统)，并且开发与其相关的代码，以用于在云平台上实现而免于物理硬件考虑(例如，排序、部署、和容纳物理服务器等)——系统设计者只需要在虚拟计算机系统的资源限制(不是底层硬件的资源限制)方面考虑计算机资源的消耗，对这些虚拟系统的资源限制是明确定义的并且是已知的。因此，从系统设计者的角度来看，计算机资源考虑被降低为对例如应该部署云平台中的多少虚拟计算机系统的考虑；从平台的操作者自身 (其可以与系统设计者不同)的角度来看，计算机资源被降低为对例如需要多少物理计算机系统来实现具有预先定义的资源分配的、所需数量的虚拟机的考虑。

在图1中示出了示例性分布式平台100的高级概述。示例性平台包括分布式计算机系统114。图1的计算机系统114由非常大数量的(例如，数万个)联网的计算机设备组成——在一些上下文中，数量大得足以使得物理计算资源能够被认为是足够丰富以至于是有效地无限的。这些计算机设备被配置以用于与网络201(其是基于分组的网络，例如互联网)进行通信，并且是全球地分布的(例如，跨多个国家和/或洲分布)。通常地，这样的计算机系统的分组(例如，数千个服务器)被安置在位于不同地理位置处(例如，在国家的不同地区、不同的国家、不同的洲等中)的相应的数据中心 (数据中心)中。

系统软件112在分布式计算机系统114顶层运行。系统软件112被配置为实现独立的虚拟机106、110的两个集合104(运行时集合)和108(存储集合)。

运行时集合104包括多个VM 106，其提供用于执行应用代码134的运行时环境，应用代码134是在该虚拟计算机系统106上执行的。系统软件 112被配置为使得期望利用平台100的软件开发者能够经由网络201而将他们的定制代码134上传至平台100以在其上执行。作为响应，系统软件112 创建这样的运行时环境并且将代码134供应给新近创建的运行时环境以供执行。通过系统软件调解对分配给该环境的底层的物理处理资源和(主要由物理易失性存储器在物理等级实现的)物理存储器资源的访问使得在虚拟系统106上执行该代码134成为可能。

存储集合108包括被配置为提供数据存储的多个虚拟机110。每个虚拟机具有对应的应用程序接口(API)111，API 111可以用于例如通过代码134 进行对其的合适的函数调用而往来于分配给计算机系统110的(主要由物理非易失性存储器在物理等级实现的)物理存储器资源实现对数据的传输的数据。再一次，该传输是由系统软件112调解的。

实施例提供了一种系统，其包括保存被配置为实现各种类型的控制器的代码的计算机存储。这些包括：

1.通话控制器，其处理高等级信令功能，例如用于建立通信事件，例如两个或多个用户之间的通话，以及针对对所建立的通信事件的高等级管理，例如，通话中管理，例如添加/移除参与者、添加/移除媒体模态等，以及终止所建立的通信事件；

2.一个或多个媒体(模态)控制器，每个用于管理所建立的通信事件的媒体模态；媒体模态控制器在通话控制器的控制下控制实际的媒体内容的流动，例如，通过控制在参与的端点之间建立覆盖网络连接(例如，对等和/或中继连接)的方式；媒体模态包括音频、视频、屏幕共享、共享的白板等。在一些实施例中，媒体模态服务仅仅是针对群通话(三个或更多用户之间的)而传递的。

控制器的实例是由在云平台的一个或多个VM上执行的应用代码来实现的。

即，通话控制器(CC)是负责两方通话的通话建立&管理的服务器实体，并且其也帮助多方通话建立&管理。

通话代理(CA)是用于指代与通话控制器进行交互的客户端实体的术语。

0.概述：

0.1底层系统组件：

图2示出了通信系统200。通信系统200包括网络201。连接至网络200 的是与第一用户202a(“Alice”)相关联的用户设备(也称为用户设备或客户端设备)204a以及与第二用户202b(“Bob”)相关联的另外的用户设备 204b。用户设备204a、204b是网络201的端点。用户设备204a、204b被布置成从相关用户接收信息并且将信息输出给相关用户。尽管在图2中仅仅示出了两个用户设备，但是在通信系统200中可以包括更多的用户设备。每个用户设备是这样的计算机设备，其可以采取各种形式，例如台式计算机或膝上型计算机、移动通话(例如，智能电话)、平板计算设备、可穿戴计算设备、电视机(例如，智能TV)、机顶盒、游戏控制台等。

同样连接至网络201的是多个数据中心(DC)220a、220b、…、220c 和业务管理系统230。业务管理系统230包括一个或多个存储器设备234以及一个或多个处理器，所述一个或多个处理器被配置为执行用于管理如在下文中更加详细地描述的数据中心业务的业务管理代码232(业务管理器/ 业务管理逻辑)。业务管理系统230和数据中心220形成了分布式平台800 的一部分。

作为代理服务器的服务器602也连接至网络201，将以正当行为来描述其功能。

图3示出了用户设备204(例如，用户设备204a和204b)的详细视图。用户设备204包括中央处理单元(“CPU”)302，向其连接有：输出设备，例如可以被实现为触摸屏的显示器304，以及用于输出音频信号的扬声器 (或“扩音器”)310；输入设备，例如用于接收音频信号的麦克风312、用于接收图像数据的相机308、以及键盘306；用于存储数据的存储器326；以及网络接口324，例如用于与网络201进行通信的调制解调器。用户设备 204可以包括除了在图3中所示出的那些的其他元件。显示器304、扬声器 310、麦克风312、存储器326、相机308、键盘306、和网络接口324将被集成到用户设备204中。可替代地，显示器304、扬声器310、麦克风312、存储器326、相机308、键盘306、和网络接口324中的一个或多个可以不被集成到用户设备中，并且可以经由相应的接口而连接至CPU 302。这样的接口的一个示例是USB接口。如果用户设备204经由网络接口324至网络201的连接是无线连接，则网络接口324可以包括用于将信号无线地发送至网络201并且从网络201无线地接收信号的天线。

图3还示出了在CPU 302上执行的操作系统(“OS”)314。在OS 314 的顶层运行的是通信系统200的通信客户端应用(客户端)的实例316的软件堆栈。客户端316与操作系统314进行通信并且通过通信系统200来管理连接，包括与其他用户设备以及与数据中心220的连接。客户端316 具有客户端用户接口(“UI”)，其用于向设备的用户呈现信息并且从设备的用户接收信息。软件堆栈示出了客户端协议层318、客户端引擎层320、和客户端用户接口层322。每一层负责特定的功能。因为每一层通常与其他两个层进行通信，所以它们被认为布置在堆栈中，如在图3中所示出的那样。操作系统314管理设备204的硬件资源并且处理经由网络接口324往来于网络201所发送的数据。客户端软件的客户端协议层318与操作系统314进行通信并且通过通信系统200来管理所述连接。需要较高等级的处理的过程被传递至客户端引擎层320。客户端引擎320也与客户端用户接口层 322进行通信。客户端引擎320被布置为控制客户端用户接口层322以经由客户端的用户接口向用户呈现信息，并且经由所述用户接口从用户接收信息。以该方式，客户端316执行所需的处理以允许用户(例如，Alice、Bob) 通过通信系统200进行通信。

用户接口可以包括，例如，经由显示器304输出信息的图形用户界面 (GUI)和/或使得用户能够以“自然的”方式与设备进行交互而脱离了由诸如鼠标、键盘、远程控制等之类的某些输入设备所施加的人为的约束的自然用户界面(NUI)。NUI方法的示例包括利用以下项的那些方法：触摸感应显示器、语音和话音识别、意图和目标理解、使用深度相机(例如，立体或飞行时间相机系统、红外相机系统、RGB相机系统、以及这些的组合)的运动姿势检测、使用加速度计/陀螺仪的运动姿势检测、面部识别、 3D显示器、头部、眼睛和视线追踪、浸入式增强现实和虚拟现实系统等。

客户端引擎层包括多个服务代理512。每个服务代理处理实时媒体通信事件(例如，通话)的不同方面。代理意指定义了端点如何与具体的云服务进行交互的端点/客户端逻辑实现，例如，针对通话代理的通话控制器；针对媒体模态代理的媒体模态控制器等。所述代理可以在客户端的软件库中被实施。

图4A是对数据中心220(例如，数据中心220a、220b、220c…)的示意图。数据中心包括多个服务器444、404a、404b、404c；网络基础结构480，其连接至网络201，以用于在数据中心220内的联网设备之间交换数据分组，并且经由网络201与在数据中心外部的设备交换数据分组；以及电力基础结构490，其用于向数据中心的设备提供电力。服务器404a、404b、和服务器402c由电源492供电，并且电源492其自身分别地从电力基础结构490 供电。数据中心还包括连接至网络基础结构480的数据中心业务管理系统 488，其用于接收来自网络201去往数据中心220的入站业务并跨服务器 404a、404b、404c来分配所述业务，并且用于跨数据中心220的其他服务器(例如，404b、404c)来分配来自数据中心220的一个服务器(例如，404a)的内部业务。DC业务管理系统可以包括诸如硬件负载平衡器之类的组件、在合适的计算机系统上执行的软件、或其组合。

服务器404a、404b、404c中的每个服务器包括至相应的网络接口484a、 484b、484c的相应的处理器406a、406b、406c，以用于与其他联网设备交换数据。每个处理器能够直接访问相应的存储器414a、414b、414c；以给处理器提供对保存在计算机存储中的数据的访问。

网络接口484a和484b连接至网络交换机482，其使得服务器404a和 404b能够彼此发送和接收数据，并且经由该交换机482往来于直接连接至该交换机482的任何其他服务器(未示出)而发送和接收数据。网络接口 484c连接至网络交换机482’，其使得服务器404c能够经由该交换机482’往来于直接连接至该交换机482’的任何其他服务器(未示出)而发送和接收数据。交换机482连接至网络基础结构480，其也使得服务器404a、404b 以及连接至交换机482的任何其他服务器(未示出)能够往来于连接至网络基础结构(例如，经由诸如交换机482’之类的其他交换机这样连接的设备)的其他设备以及连接至网络201的另外的设备而发送和接收数据。交换机482’类似地连接以提供等同的功能。

服务器444是针对数据中心220的控制服务器：其负责对数据中心中的其他服务器的控制和监测。控制服务器444从电源494供电，电源494 本身从电力基础结构490供电。控制服务器444包括处理器446，其连接至存储器454和网络接口486，以用于与其他联网设备交换数据。网络接口 486连接至网络基础结构480，其使得控制服务器444能够与连接至网络基础结构的其他设备(包括服务器404a、404b、404c)以及连接至网络201 的另外的设备(例如，图2中的204a、204b)交换数据。

服务器404a、404b、404c被分组为相应的故障域402、402’，故障域是共享公共的故障点的一组服务器(即，依赖于用于操作的相同的物理电子组件的服务器，其故障因此禁止了所有这些服务器的操作)。例如，服务器404a和404b经由对于服务器404a、404b是公共的网络交换机482而连接至网络基础结构480；该交换机482的故障引起了服务器404a、404b中的每个以及连接至该交换机的任何其他服务器的故障，这是因为所有这样的服务器变得与网络基础结构480断开，并且因此在该事件中与网络201 断开。因此，可以说网络交换机482将故障域定义为连接至该交换机482 的所有服务器中的一组服务器。类似地，服务器404a和404b两者都从自身由是电力基础结构490供电的电源492供电；该电源492的故障引起了服务器404a、404b中的每个以及由该电源492供电的任何其他服务器的故障。因此，电源492定义了故障域，其是由该电源492供电的所有服务器中的一组服务器。在图4A中，被示出连接至交换机482的每个服务器也被示出由电源492供电，因此图4A中的交换机482和电源492定义了公共的故障域402；通常而言，由同一电源供电的服务器可以连接至不同的网络交换机，并且反之亦然。类似地，图4A示出了特征在于网络交换机482以及电源492’的第二故障域402’。故障域402’的服务器404c被示出为连接至交换机482’和电源492’。数据中心220在故障域402、402’中以及在特征为额外的网络交换机、电源、和其他物理组件(未示出)的其他故障域两者中包括额外的服务器(有可能数千个)。

图4B示出了服务器404(例如，404a、404b、404c)的另外的细节。处理器406(例如，406a、406b、406c)运行管理程序。管理程序是创建、运行、和管理虚拟机410i、410ii的一段计算机软件。相应的操作系统420i、 420ii(例如，Windows Server(TM))在每一个VM 410i、410ii上运行，并且进而，相应的应用代码410i、410ii在每一个操作系统420i、420ii上运行。所述应用代码可以实现控制器，例如通话控制器、媒体模态控制器。

处理器406具有存储器414(例如，414a、414b、414c)，其可以由处理器406直接访问。为了在处理器上运行应用的实例，将应用代码410i/410ii 从外部计算机存储(即，外部的且对于处理器而言可间接存取)加载到存储器414a、414b、414c中，以使得处理器406a、406b、406c能够直接访问存储器414中的应用代码。对应的运行时状态数据也被保存在存储器414 中，其当实例进展时被更新，例如当从网络201接收实例过程消息时。

同一控制器的两个实例(例如，通话控制器、媒体模态控制器)能够传递相同的服务(例如，通话控制、媒体模态控制)，并且在某一程度上可互换，以使得特定控制的不同实例可以以在不同的时间点处控制相同的通信事件的相关方面而结束。通信系统300对例如由客户端316的对应的代理512(例如，通话代理、媒体代理)向特定的控制器(例如，通话控制器、媒体模态控制器)发起的消息进行响应。具体而言，作为响应，通信系统 300分配该控制器的实例以处理所述消息。在一定程度上，实例是通过直截了当的负载平衡的方式来分配的，但是，如下文中所解释的，不总是该情况。

在下文中，术语“服务逻辑”(等同为“部署”)用于指代可以传递相同服务(例如，通话控制、媒体模态控制)的一组特定的实例。这些实例中的任何两个可以在不同的处理器上运行，或者它们可以刚好在同一处理器上运行。每个服务逻辑具有分层结构，现在将参考图5A和5B来对其进行描述。通常而言，控制器将利用在各种通话间共享的其资源来同时地处理多个，并且可能是很多个通话等。

如在图5A中所示出的，云100适用于在具有第一类型的第一服务器逻辑523[1](即，能够传递第一服务)的至少第一分组502[1]处和具有第二类型的第二服务逻辑523[2](即，能够传递第二服务)的分组502[2]处运行。用户设备204的客户端316包括针对每种类型的服务的服务代理512[2](第一类型)、512[2](第二类型)。服务代理512[1]可以经由网络201与第一类型的服务逻辑523[1]中的每个服务逻辑进行通信，而服务代理523[2]可以经由网络201与第二类型的服务逻辑523[2]中的每个服务逻辑进行通信。

每个服务代理512和每个服务逻辑523可以与业务管理器230进行通信。服务逻辑以及他们相应的代理之间的通信在某种程度上是由业务管理系统230调解的。例如，当通话代理或媒体代理首先请求通话控制或媒体模态控制服务时，该代理将请求引导至业务管理器，所述业务管理器基于诸如在相应的数据中心、地理位置等处的资源可用性之类的合适的标准来选择特定的通话控制或媒体模态控制逻辑。此后，通话/媒体模态代理可以将针对特定的通信事件的相关消息引导至所选择的通话/媒体模态服务逻辑。

如在图5B中所示出的，用于传递特定的服务的服务逻辑包括协作以传递该服务的一个或多个聚类522、552。聚类的示例包括在Windows Azure (TM)云平台上实现的网络和工作者角色。在该实施例中，每个服务逻辑是在相应的单个数据中心(例如，220a、220b、220c中的一个)上实现的。服务逻辑的每个聚类包括负载平衡器548、558以及执行应用代码434的相应的实例的一个或多个虚拟机410。聚类的负载平衡器可以从网络201接收消息，并且将这些请求引导至所述聚类的VM中的任何一个VM，例如以轮循的方式或者基于所述VM的所监测的资源可用性(例如，将到来的请求引导至当前具有最多可用资源的VM)。聚类的负载平衡器假定该聚类的每个VM被等同地配置为能够处理由该负载平衡器所接收的任何消息。

图5B示出了服务逻辑523，其包括具有相应的负载平衡器548、558 的至少两个聚类522和552。聚类522包括至少两个VM 410A、410B。VM 410A执行第一应用代码的实例434A，而VM 410B执行第一应用代码的另一实例434B。类似地，聚类552包括至少两个VM 410A’、410B’。VM 410A’执行第二应用代码的实例434A’，而VM 410B’执行第二应用代码的实例434B’。服务逻辑的聚类可以被配置为暴露一个或多个外部可寻址的接口 424和/或一个或多个内部可寻址的接口556，其可以被调用以便建立用于与该聚类交换数据的逻辑连接。内部接口556仅仅能够由同一服务逻辑的其他聚类访问，而外部接口能够例如由对应的客户端侧服务代理512从聚类外部访问。聚类的接口耦合到该聚类的负载平衡器，以使得由该负载平衡器来接收使用该接口被引导至该聚类的任何请求，以用于转发至该聚类的 VM(该转发对该聚类外部是不可见的)。图5B示出了暴露外部接口524(其耦合至该聚类的负载平衡器548)的聚类552，以及暴露内部接口556(耦合至该聚类的负载平衡器558)的聚类552。

可以用以下方式中的一种或多种方式来增加(相应地，降低)针对任何类型的服务(例如，通话控制、媒体模态控制)的资源分配：

-通过部署具有该类型的额外的(相应地，终止现有的)服务逻辑，即通过将物理计算机资源分配至具有第一类型的新的服务逻辑(相应地，对现有的该类型的服务逻辑重新分配计算机资源)——其一个示例将是在 Windows Azure^TM云平台上部署新的网络应用；

-通过增加(相应地，降低)具有第一类型的现有的一个或多个服务逻辑的组件内的虚拟机的数量，即增加(相应地，降低)针对该组件的计算机资源分配——其一个示例将是改变Windows Azure^TM云平台上的网络应用的网络角色或工作者角色内的实例的数量；

-通过增加(相应地，降低)具有第一类型的现有的一个或多个服务逻辑的组件内的复本(duplicate)虚拟机的“大小”，即增加(相应地，降低) 分配至特定的组件的每个这样的复本虚拟机的相应的计算机资源——其一个示例将是调整Windows Azure^TM云平台上的网络应用的网络角色或工作者角色的大小。

使用后两种技术，可以将资源与其他服务逻辑(相同类型或不同类型的服务逻辑)无关地分配至一个服务逻辑(即，一个部署)。例如，可以将更多VM添加至具有第一类型的第一服务逻辑的组件，和/或可以调整这些组件的VM的大小，而不改变具有该类型的其他服务逻辑的组件并且不改变具有不同类型的其他服务逻辑的组件。

此外，使用后两种技术，可以将资源彼此独立地分配至同一服务逻辑的不同组件(例如，在不改变另一个组件的情况下，将VM添加至一个组件，或者改变一个组件的VM的大小)。

0.2系统架构概述

在本文中，术语“事务”指的是一系列的低等级操作，其共同地实现高等级控制操作，例如建立通信事件、终止已建立的通信事件、或者执行通话中功能，所述通话中功能例如：在已建立的通信事件期间将参与者添加至已建立的通信事件或者将参与者从已建立的通信事件移除、将已建立的通信事件设置为挂起、在已建立的通信事件期间将媒体模态(例如，音频、视频)添加至已建立的通信事件/将媒体模态(例如，音频、视频)从已建立的通信事件移除等。事务涉及在被指定在客户端上实现事务和相关代理512的实例之间经由网络201来发送和/或接收一个或多个消息。

在下文描述的实施例中，由控制器的同一实例来执行任何一项事务。这不是必需的；其是通过重新使用在事务开始时所创建的资源和上下文来使得事务处理时间更快的一种优化。这不显著地损害系统的高可用性，是因为事务的寿命相当短，并且当处理实例在处理正在进行的事务时处理实例死亡的可能性非常低。

然而放弃该优化(为了高可用性)，并且允许任何实例来处理事务中消息是可能的——为了实现这一点，在处理了每条消息之后，通话控制器实例将通话状态转储(flush)至外部存储；在处理新消息之前，接收新的消息的处理实例从外部存储器提取所述状态、重建通话状态、并且重新初始化可能需要的任何其他资源(例如，至客户端的TLS/TCP连接)。

以下呈现了：

1.信令协议，其使能在客户端代理和控制器之间进行通信(章节1)；

2.用于将通信事件的状态数据串行化以使得控制器的不同实例可以处理不同的事务的机制(章节2)

3.用于确保在可能的情况下，每一单个事务由控制器的同一实例来处理的机制(章节3)。

应当注意的是，上文的机制“2”在多个实例处理相同事务的实例中可以用于允许不同的实例处理与相同事务相关的消息。

例如，在图5B中，服务逻辑523的第一聚类522可以实现主要控制服务(例如，通话控制、媒体模态控制)。接着，第二聚类552可以实现用于支持主要控制服务的辅助服务，例如由在聚类中的每个VM上运行的第二代码所实现的数据存储服务，其被配置为提供用于访问在聚类间共享的计算机存储的接口。接着，通话/媒体模态控制器实例434A、434B可以在针对特定通信事件的事务结束时向第二聚类552写入可以由第一聚类522的其他实例访问的经序列化的状态数据，以使得它们能够处理针对特定通信事件的未来的事务。

图6示出了通信系统200的示例性配置。客户端316包括通话代理512C 和媒体代理512M。

通话代理512C可以将发起消息经由网络201引导至通话控制服务逻辑 523C的通话控制器聚类522C的外部接口524C。通话控制器聚类包括通话控制器的多个实例434C1、434C2。通话控制器聚类522C的负载平衡器548C 针对每条消息而选择通话控制器实例中的一个实例并且将消息引导至所选择的实例。所选择的实例以在下文中所描述的方式来处理该消息。

通话控制服务逻辑523C还包括存储聚类552C，其包括数据存储软件(例如，AzureTable Store等)的一个或多个实例434S1、434S2。数据存储软件实例434S1、434S2提供对计算机存储608的访问。存储聚类552C可以由通话控制器聚类522C经由前者的内部接口(在图6中未示出，但是如在上文中所描述的)来访问。

媒体代理512M可以经由网络201将消息发起至媒体模态控制服务逻辑523M的媒体模态控制器聚类522M的外部接口524M，其被类似地引导至在聚类522M中所选择的媒体模态实例434M1、434M2。

在客户端316与代理服务器602之间建立了开放的(即进行中的)连接604。该连接是WebSocket连接，其在代理服务器602与客户端设备204 之间提供全双工通信。WebSocket连接是本领域公知的。通话控制器434C、 434C2和媒体模态控制器434M1、434M2的实例可以经由代理服务器602 而分别地向通话代理512C和媒体代理512M发送信号。这使得控制器实例能够将消息引导至它们对应的代理，即使客户端设备204在网络地址翻译器(NAT)或防火墙之后。

通话控制器可以建立诸如通话之类的通信事件(对话)，并且可以管理所建立的对话；其负责发送信号以实现以下各项：

1.通话建立；

2.重新协商，例如：

a.保持/释放；

b.添加/移除视频或其他媒体模态，例如屏幕共享或者所共享的白板；

3.通话拆除；

4.通话相关名单更新。名单意指与参与该通话的各种端点有关的信息。使用该信息，客户端可以给UI提供例如通话中的参与者的列表，并且可以允许操作例如移除通话参与者(“移除参与者”)，将通话参与者静音(“将参与者静音”)等。

通话控制器还可以通过媒体模态控制器实例来引导并控制媒体模态服务，而在一些实施例中，媒体模态控制器仅仅用于群通话。

1.信令协议；

在下文中呈现了用于在通话代理与通话控制器实例之间发送信号的机制。这些是在通话控制器的上下文中描述的，但是底层原理中的一些底层原理可以应用于其他类型的云服务(例如，应用于媒体模态控制器)。

所述协议提供了：

1.使用回拨链接作为用于发送消息以驱动客户端和服务器两者上的状态机 (例如，通话控制器)的机制；

2.使用url重写(由通话控制器)来创建可以提供安全性的拦截服务器(通过将所涉及方的路由细节彼此隐藏)，并且还确保通话维持在一致的状态；

3.使用url重写来允许创建可以通过添加或更新url来添加新功能的代理 (参见下文中的章节1.4)；

4.使用url重写来透明地提供高可用性。不同的回拨链接可以指向不同实体，其可以当客户端将回拨链接视为不透明时独立地缩放而不打断客户端。类似地，提供回拨链接的实体(如通话控制器)可以使其指回数据中心，或者基于其逻辑而指向任何特定的实例，并且因此在客户端没有任何特殊逻辑的情况下，透明地实现高可用性。这与如SIP的其他技术不同，SIP需要将所有消息发送至固定实体，因此损害了可缩放性和可用性。

相比于SIP，本协议使用在所有的客户端平台上具有广泛的支持的 HTTP，并且不需要创建定制客户端侧堆栈以使能开发客户端。这允许更容易的第三方开发，并且对与其他解决方案的容易的集成开辟了道路。

该协议定义了允许以下各项的消息：

1.通话建立

2.通话拆除

3.支路至多个端点

4.通话重新定向

5.媒体重新协商

6.通话转移(基本的和咨询的两者)

7.添加新的参与者

8.参与者拨号进入到正在进行的通话

9.名单管理

所提供的是一种用于经由通信网络在第一客户端设备的第一用户(呼叫者，例如Alice)与第二客户端设备的第二用户(被叫者，例如Bob)。该方法是由在第一客户端设备上运行的第一客户端实现的。

客户端通过经由网络向另一客户端设备发送消息来执行通信事件(例如，通话)建立过程的第一阶段。所述消息包括与还未执行的通信事件建立过程的第二阶段相关的多个选项。

例如，第一阶段可以是初始阶段，其响应于第一用户经由第一客户端的用户接口选择选项以向第二用户发起通话而被发起。第二阶段可以是其中通话例如被建立(如果Bob接受该通话)或者其中该过程被终止(如果 Bob拒绝该通话)的阶段。

针对多个选项中的每个选项，所述消息包括对该选项唯一的不同的网络地址，所述网络地址可以被访问以选择该选项，并且第二阶段发展的方式是由访问不同的网络地址中的哪个网络地址确定的。即，所述方法包括第一客户端检测到已经访问了对多个选项中的一个选项唯一的网络地址，并且根据所述多个选项中的一个选项来发起通信事件建立过程的第二阶段。

在下文中，网络地址是URI(统一资源指示符)，由此每个选项与对该选项唯一的不同的URI相关联。即，Alice的客户端针对与该过程的第二阶段相关的每个选项提供了不同的URI。URI指向Alice的客户端具有与其的全双工WebSocket连接的代理服务器，并且当已经访问了相关的网络地址时，服务器向Alice的客户端发送信号以使得Alice的客户端知道已经选择了哪些选项。例如当Alice的客户端在NAT或防火墙之后，并且因此其自身不是直接可寻址的时，使用代理是有用的，而在一些情况下，URI仍然有可能直接指向Alice的客户端设备。

网络地址(例如，URL)对选项是唯一的意指URL与选项中的一个选项相关并且不与其他选项中的任何一个选项相关(例如，以使得 end_Alice_url URL将永远不用于尝试并接受或重新定向该通话等)。

例如，URI可以是URL(统一资源定位符)，也被称为网络地址或链接。

所述消息不被直接发送给Bob，而是经由通话控制器的实例来发送。通话控制器实例在将消息发送给Bob之前重写消息中的URI。经重写的URI 指向通话控制器实例的聚类而不是Alice的代理服务器(或设备)，这提供了增加的安全性，这是因为Alice的代理(或客户端)永远不会变得对Bob 的客户端直接可见。

可以通过向URI发布内容或者在URI处删除内容来访问指向Alice的代理(或设备)或者指向通话控制器聚类的URI。所述内容是使用所谓的 POST(发布)请求方法来发布的，以及使用所谓的DELETE(删除)请求方法来删除的，所述方法是良好建立的HTTP协议的一部分。POST请求请求网络服务器接受在请求消息的主体中包含的数据以供存储，并且向URL发起的DELETE请求请求删除该URL处的内容。即，通过向与选项对应的 URI发起特定的请求(例如，发布、删除)来选择该选项。在URI已经由通话控制器实例重写的情况下，Bob的响应将被发布至经重写的URI(指向通话控制器实例的聚类)，并且原始的实例或通话控制器中的另一实例将重写Bob对由Alice的客户端所提供的原始URI的响应。Bob的响应还可以包括指向代理服务器的URI，其中Bob的客户端具有至所述代理服务器的类似连接(或者直接连接至Bob的设备)。在该情况下，原始的实例或另一个通话控制器实例重写Bob的URI，以替代地以类似的方式指向通话控制器聚类。

通话控制器实例还可以在其生成的消息中提供URL，即，其源自通话控制器实例。这些可以视情况被发布至由Alice/Bob的客户端所提供的指向 Alice/Bob的代理的URI。

Alice的客户端可以首先获得业务管理器的URI，其中，在该URI处发布来自业务管理器的初始通话邀请请求消息(通话邀请请求)，所述业务管理器以在上文中所描述的方式来指定通话控制器聚类。此后，消息可以由 Alice/Bob的客户端发布至该聚类的URI，这将使得该聚类的负载平衡器选择该聚类中的通话控制器实例，并且将该消息转发至所选择的实例。

对于发布至通话控制器聚类的、与当前正在进行的事务相关的消息，在章节3中提供了用于确保处理进行中的事务的特定的通话控制器接收该消息，即使其最初着陆在该聚类的不同实例上。相同的机制用于确保如果针对同一通话同时发生了多个事务，则由同一实例处理全部这些事务，即使消息中的一个消息着陆在不同的实例上。这确保了仅仅存在一个修改通话状态的实体，并且因此不可能存在否则由多个写入者引起的状态的不一致或破坏。

针对仍然与现有的(即，已经建立的)通信事件(例如，添加参与者、终止通信事件等)相关的发布至发起新的事务的通话控制器聚类的消息，在章节2中提供了使得聚类中的任何通话控制器实例能够处理新的事务的机制。简而言之，当处理先前的事务时，通话控制器实例向客户端提供了回拨URL，其包括“工厂对象标识符”和“持久对象标识符”。所述标识符与已经被写入到(以序列化格式)在聚类间共享的计算机存储的通信事件的通话状态相关。回拨URL指向该聚类。当客户端向回拨URL发布消息以发起新的事务时，在URL中出现的这两个标识符使用序列化数据为该聚类中能够处理与现有的通信事件相关的新的事务的任何实例提供了足够的信息。这将在章节2中详细解释。

每个通话与唯一的通话ID相关联，所述通话ID被包括在指向通话控制器聚类的回拨URL中。这使得处理实例能够以如在章节2中详细解释的其从外部存储读取/或向外部存储写入的方式执行一些优化。应当注意的是， URL自身的选择(并不仅仅是发布至所选择的URL的消息的任何内容)向 URL的原始提供者提供信息。例如，在简单的示例中，通话控制器可以向 https://proxy.io/Alice/CallID/Accept发布空消息以指示Bob已经接受了通话邀请，并且向https://proxy.io/Alice/CallID/Reject发布空消息以指示Bob已经拒绝了通话邀请。这些URL指向Alice的代理，并且将已经在发送通话邀请请求消息时由Alice的客户端提供。然而，在以下的示例中，在消息的内容中提供了补充信息。

图7示出了针对在该示例中由Alice 204a发起的、Alice(呼叫者)204a 与Bob(被叫者)204b之间的通话的成功通话建立过程的概述。

在以下的示例中，Alice和Bob的客户端具有至同一代理602的连接。实际上，它们可以使用不同的代理。

Alice的客户端316a的通话代理512Ca发起(S1)通话创建请求消息(CallInvitationRequest)，其向通话控制服务逻辑523C(在下文中为“CC”) 请求通话控制服务，例如，使用业务管理器232所发现的。通话控制器实例434C被指定为通过负载平衡来处理该请求。该请求识别Bob是期望的通话参与者，并且所指定的通话控制服务逻辑434C向Bob的客户端320b的 Bob的通话代理512Cb发起通话通知消息。所述通知是经由代理602向Bob 的设备发送的。Bob是经由Bob的客户端UI被通知的，例如，通过UI输入响铃模式，并且响应于Bob选择加入该通话，Bob的通话代理向CC发起附接请求(S3)，响应于该附接请求，Bob被附接至该通话。在S4处，经由集线器/代理在Bob和Alice的通话代理512Ca、512Cb之间发送和接收通话进展请求、媒体回答请求和媒体确认响应、以及最后的通话接受请求和通话接受确认响应，以协商针对该通话的媒体参数从而使得媒体可以在客户端的媒体代理512Ma、512Mb之间流动(S5)，在该示例中这不涉及媒体模态控制器。通话媒体不通过通话控制器流动，并且根本无需经由云流动；例如，其可以经由对等连接、媒体中继连接、或一些其他覆盖网络连接而流动。媒体中继是允许NAT和防火墙之后的客户端与其他实体交换媒体分组的实体。其通过具有公共可访问的IP地址，并经由该地址将所有媒体分组中继到隐藏的客户端或从隐藏的客户端中继来这样做。这与代理602 允许NAT/防火墙之后的客户端执行信号发送的方式是类似的(媒体中继是针对代理602要进行信号发送的媒体的)。

媒体回答和媒体回答确认有助于创建被称为临时媒体流的东西。临时媒体流是在呼叫者端点与所有被叫者端点之间创建的。例如如果被叫者在多个用户设备处登录，则可以存在多个被叫者端点。这在被叫者上的“响铃”UI绘制(输出)之前发生，以使得一旦被叫者接听通话，她就可以开始谈话而无须等待媒体建立。媒体确认确保被叫者端点真的知道其发送的媒体回答的确已经被呼叫者客户端看见和处理了，并且因此，可以确定媒体流已经开始。额外地，客户端使用媒体确认作为触发以确保媒体回答的确被呼叫者端点看见。如果呼叫者端点在合理的时间(例如，15秒)内没有看见媒体确认，则客户端可以重新发送媒体回答。

CallAcceptance(通话接受)被用作用于取消没有接听通话的任何端点的响铃并且用于终止与它们的媒体流的信号等。

CallAcceptance还充当针对以下情况的机制：

1.被叫者客户端将其通话中回拨URL发送至CC

2.通话控制器向呼叫者发送通话中动作URL

CallAcceptanceAcknowledgement(通话接受确认)被用作：

1.呼叫者端点向将其通话中回拨URL发送至CC

2.CC向被叫者端点发送通话中动作链接

额外地，客户端还使用CallAcceptanceAcknowledgement作为触发以确保CallAcceptance的确已经被呼叫者端点看见。如果呼叫者端点在合理的时间(例如，15秒)内没有看见CallAcceptanceAcknowledgement，则客户端可以重新发送CallAcceptance。

S1-S4继续单个事务，即以建立通信事件。响应于初始的通话邀请请求，通话控制器510C的单个实例被指定为控制整个事务S1-S4。为了确保事务中消息着陆在通话控制器的同一实例上，与该事务相关的URL指回至聚类的特定实例，而不是指向聚类负载平衡器。与不同事务相关的URL指向负载平衡器。

这涉及创建针对通信事件的通话状态，并且在过程进展时更新所述通话状态。一旦已经建立了所述通话，则以在上文中所描述的方式将通话状态存储至计算机存储608，其中通话控制器聚类中的其他通话控制器实例能够访问所述通话状态。如在下文中所解释的(在章节2中)，将通话状态序列化以使得其可以在通话建立过程结束时以该方式存储。接着，通话控制器实例510C从该指定被释放，即从对通信事件进行控制被释放。在这里，“被释放”意指先前被占用以实现S1-S4的、实例434C在其上运行的处理器的物理资源(处理资源、存储器资源)再次变得可用。在以下的示例中，一旦实例的运行时状态已经被序列化并且被存储，则这发生，以使得另一实例可以重新创建运行时状态并且因此恢复对相关服务的传递(参见章节 2)。

现在将描述各种示例性的信号流以帮助理解本教导下的原理中的一些原理。

1A.URL:

应当注意的是，以下的符号用于表示URL：

-<opertaion>_<pointsTo>_url(<操作>_<指向>_url)

其中，“操作”表示URL与其相关的操作，而“指向”指示URL指向哪个实体，即，哪个实体最终在访问该url之后检测并行动。在下文中<pointsTo> 是

-“Alice”针对指向Alice的URL(即，Alice的代理或设备)；

-“Bob”针对指向Bob的代理的URL(即，Bob的代理或设备)；

-“CC”针对指向通话控制服务逻辑的URL——指向特定的实例或指向负载平衡器。

以下的示例涉及两方通话。在两方通话的上下文中，<pointsTo>针对指向通话控制服务逻辑(CC)的URL而具有“CC<user>”(“CC<用户>”) 的形式，但是其是由通话控制服务逻辑映射至指向<user>(例如Alice、Bob 的URL)的URL的(参见下一部分)。

1B.URL“重写”：

如在上文中所述，CC利用指向自身的URL来重写在消息中指向端点的URL。当CC用指向自身的新的URL(即，<operation>_CC<user>)来代替指向<user>的原始的URL(即，<operation>_<pointsTo>_url)时，其以对客户端不可见的方式存储原始的URL与新的URL之间的映射。因此，每当在新的URL<operation>_CC<user>上执行访问操作(例如，发布、或删除) 时，这可以由CC检测，并且作为响应，CC从存储取回原始的 URL<operation>_<user>_url，并且在原始的URL<operation>_<user>_url上执行合适的操作。

因此，例如：

-如果从Alice到Bob的消息：

包含第一URL<operation>_Alice_url，即指向Alice，并且

被发布至第二URL<operation2>_CCBob_url，即指向CC但是在CC处映射到第四URL<operation2>_CCBob_url，即以对Alice不可见的方式指向 Bob；

-则：

CC通过用第三URL<operation1>_CCAlice_url(其现在指向CC(不是 Alice))代替第一URL来修改该消息，并且

向第四(不是第二)URL<operation2>_Bob_url(其指向Bob)发布经修改的消息。

以该方式，可以确保的是，Bob从不具有对指向Alice的任何URL的直接可见性，并且反之亦然，即重写是确保Alice和Bob的代理总是将CC 用作通信中介所需的全部。

该协议使得在客户端与通话控制器之间的所有通信能够以请求-响应为基础进行操作——因此，根据该协议，不需要客户端来维持至通话控制器的任何种类的开放连接，例如，以它们对待代理服务器的方式。

在这些特定的示例中，发布(相应地，删除)意指使用HTTP POST(相应地，DELETE)方法。

在本文中公开的协议为客户端提供了灵活性。客户端可以自由地选择其想要在各种消息中使用的无论何种URL——已知每个URL可以由其他相关的实体(客户端、控制器等)访问，并且对URL所表示的操作是唯一的，以使得客户端在访问先前由其自身所提供的任何给定的URL时知道正在请求哪一个操作(即，已知URL将足够的上下文编码为不混淆的)。换句话说，选择URL以便当访问URL时不引起后来的混淆是客户端自己的责任。如所提及的，URL重写通过确保呼叫者URL从不对呼叫者直接可见并且反之亦然而在呼叫者和被叫者之间提供安全层。这将客户端从必须在他们的 URL上维持安全性的负担中释放了，这是因为所述URL仅仅每个被显露给受信任的实体(即，通话控制器)。

1.1示例性信号流：

1.2.1通话建立信号流(其中，通话由被叫者接受)：

在图8A中更加详细地示出了针对图7中的成功的通话建立过程的信令流。两个通话代理之间的成功的通话建立涉及以下步骤。

在步骤S802处，Alice的通话代理512Ca(CA1)向CC发送通话邀请请求消息(通话邀请请求)。具体地，通话邀请请求被发布(即，使用诸如 HTTP POST之类的发布请求而被发送)至CC的通话URL(call_url)，例如其可以使用业务管理器232而被发现，并且有可能通过进一步的协商例如以发现与Alice的客户端兼容的通话控制器版本。消息已经被发布了特定的URL的确切的事实告诉CC：尽管消息的内容的确包含用于建立通话的额外的信息，但期望新的通话而不管消息的内容。

特别地，通话邀请请求包括被叫者(Bob)的标识符(例如，用户名)，并且指示被叫者是期望的参与者。所述消息可以包括群通话的其他期望的参与者的标识符。所述消息还标识了Alice的客户端可以支持那些媒体模态，例如，其可以指示Alice的客户端可以支持音频和视频、仅音频等。

通话邀请请求包括以下链接(回拨连接)即URL：

-progress_Alice_url(进展_Alice_url)：针对Alice的通话进展URL——其用于继续建立该通话(参见S814)；

-mediaAnswer_Alice_url(mediaAnswer_Alice_url)：针对Alice的媒体回答URL，用于继续建立通话(参见S818)；

-acceptance_Alice_url(acceptance_Alice_url)：针对Alice的通话接受URL——其用于最终接受该通话，以使得通话媒体可以例如响应于Bob选择接受(即“接起”通话)而流动、被访问(参见S828)；

-redirection_Alice_url(redirction_Alice_url)：针对Alice的通话重新定向URL——其用于自动地或响应于Bob的选择而重新定向该通话(参见S842，图8C)；

-endNotification_Alice_url(结束通知_Alice_url)：针对Alice的结束通话通知URL——其用于通知Alice的端点关于通话的结束，因为其没有被Bob 接受，或者因为Bob在接受通话之后挂掉(参见S836，图8D)。

这些URL彼此全都不同，但是全部都指向Alice的代理服务器。例如，它们可以具有形式https://proxy.io/<Alice的用户名>/<﹡>，其中<﹡>表示标识不同操作的不同的上下文标识符。

从CA1的角度来看，步骤S802构成通话建立过程的第一阶段。

该消息还可以携带媒体协商(例如，编码解码器协商)所需的任何数据，例如与Alice的客户端/设备的媒体能力有关的信息。该消息还可以包含其他有用的信息，例如参与者更新回拨链接(update_Alice_url)。这是 Alice的代理的URL，如果该信息变化，则CC可以向其发布通话参与者的经更新的列表。

在S804处，CC用通话邀请响应消息(通话邀请响应)来对CA1的通话邀请请求进行响应，其包括以下回拨链接以由CA1使用：

-call_CC_url(通话_CC_url)：表示整个通话的通话URL——其可以用于完全地终止该通话

-callLegAlice_CC_url(通话支路Alice_CC_url)：表示Alice和CC之间的通话支路的终止支路URL——其可以用于将Alice作为通话参与者移除；

-participantInvitation_CC_url(参与者邀请_CC_url)：供CA1添加更多参与者的URL。

这些URL指向CC。

该响应是HTTP响应，其中，“201创建的”状态码指示在S802处由 CA1进行的成功发布。

在步骤S806处，CC将通话通知消息(CallNotification)发送至被叫者的通话代理511Cb(CA2)。所述通话通知包括：

-CA2可以用于附接至通话的附接URL(attachBob_CC_url)：在步骤 S808处使用。

使用在S802的通话邀请请求中包括的标识符来发送消息，并且经过 Bob的代理。

在各种移动场景中，终端可以没有任何注册的代理回拨用于接收到来的通话通知。但是，它们可以有其他的方式被通知——例如针对现代 Windows/电话的WNS、针对Android的Google推送通知、针对iOS的 APNS。可以适当地重新定义通话通知的格式并在Bob的端点已经注册的各种推送信道上发送。一旦端点接收了推送通知，已知它们可以解译并且相应地行动的通知Blob，所述端点将由合适的OS唤醒，在该情况下其指的是：

1.如果至代理的连接尚未存在，则对其进行建立；

2.在attach_CC_URL上发送附接请求。

作为响应，在步骤S808处，CA2向在S806的通话通知中所包括的附接Bob_CC_url发布附接请求消息(附接请求)——应当注意的是，这是自动的，并且不依赖于例如Bob选择接受该通话。附接请求包括：

-指向如果Alice终止该通话，则CC可以向其发布通知的Bob的代理服务器的URL(callNotification_Bob_url)(通话通知_Bob_url)——参见 S848。

在步骤S810，CC用附接响应消息(附接响应)进行响应，该附接响应消息包含进行进一步的通话协商所需的所有数据。

附接响应消息是具有“200OK”状态码的HTTP响应。

附接响应包含以下URL：

-progress_CCAlice_url

-mediaAnswer_CCAlice_url

-acceptance_CCAlice_url

-redirction_CCAlice_url

应当注意的是，在所有以上URL中都出现了“CC”——这些URL是根据在章节1B中所描述的URL“重写”过程而由CC生成的，并且与URL 相对应：

-progress_Alice_url

-mediaAnswer_Alice_url

-acceptance_Alice_url

-redirction_Alice_url

它们在S802处由CA1在通话邀请请求消息中向CC提供，这在上文的章节1B中详细阐述。CC存储了Alice的原始URL与由CC相应地生成的替代URL之间的映射900，其在图9中被示出。

S810的附接响应消息构成了S802的通话邀请请求消息的经修改的版本。

如在上文中所提及的，CC url将仅仅在两方通话中映射至Alice的URL。针对多方通话，CC使用媒体控制器来处理协商。

其还包含：

-Call_CC_url——其表示整个通话(如在S804向Alice提供的)；

-callLegBob_CC_url——其表示CC和CA2之间的通话的支路(等于在S804处向Alice提供的callLegAlice_CC_url)。

在步骤S812处，CA2接着继续以经由CC向CA1发送通话进展更新消息(通话进展)。该消息例如可以指示Bob的客户现在已经进入了响铃状态。

通话进展更新已经被发布至progress_CCAlice_url，并且因此被CC接收。在该示例中，通话进展消息不包括任何URL，因此其内容不由CC重写。CC访问映射900以取回progress_Alice_url，并且将该消息发布至该未经修改的URL，以使得其由Alice接收(S814)。

在步骤S816处，CA2接着发送其响应于在通话通知或附接响应中所接收的媒体提议所生成的媒体回答消息(mediaAnswer)。媒体回答消息被发布至mediaAnswer_CCAlice_url，并且其包括指向Bob的以下回拨URL：

-mediaAck_Bob_url，以下在S822处使用

因为mediaAnswer_CCAlice_url指向CC，所以其是由CC接收的。因为在MediaAnswer中所包括的mediaAck_Bob_url指向Bob，所以CC生成指向CC的新的URLmediaAck_CCBob_url，并且修改MediaAnswer以用 mediaAck_CCBob_url来替换mediaAck_Bob_url。CC访问相关的映射900 以取回mediaAnswer_Alice_url(没有CC)，并且将经修改的MediaAnswer 发布至mediaAnswer_Alice_url(S818)。CA1现在具有URL mediaAck_CCBob_url。

CC创建新的映射902以在S822处使用，其将mediaAck_CCBob_url 映射至mediaAck_Bob_url(没有CC)。

在步骤S820处，在处理了媒体回答之后，CA1向CA2发送媒体确认消息(媒体确认)(S820)。

媒体确认被发布至在S818处所接收的mediaAck_CCBob_url，并且因此是由CC接收的。

在该示例中，媒体确认不包括指向Alice的任何URL，因此在S822处， CC将未修改的媒体确认发布(S822)至mediaAck_Bob_url(没有CC)——后者是从映射902获得的。

媒体确认告诉Bob的端点Alice接收到MediaAnswer，因此媒体建立被认为是成功的，并且可以绘制“响铃”UI以给用户接听通话的机会。其还告诉Bob的端点MediaAnswer被成功地传递到了Alice的端点，否则Bob 的端点可以重新发送MediaAnswer(在适当的超时之后，例如15秒)。

在该点处，媒体能够在端点的媒体代理512Ma1(MA1)、512Mb(MA2) 之间流动，以使得当被叫者接起该通话时，没有媒体建立延迟。

响应于被叫者接受(即，接起该通话)，最终通话接受消息 (CallAcceptance)经由通话控制器而被发送至CA1，其首先由CA2发布至 acceptance_CCAlice_url(S826)，并且接着由CC发布至acceptance_Alice_url (S828)。

CallAcceptance包含：

-callAccAck_Bob_url

其以相同的方式用callAck_CCBob_url来代替。

在处理了通话接受有效载荷之后，CA1将通话接受确认发布至 callAck_CCBob_url(S830)，CC将其重新发布至callAck_Bob_url。作为响应，通话媒体(音频/视频)开始在MA1和MA2之间流动(S823)。

CallAcceptance被用作用于取消未接起通话的任何端点的响铃的信号，并且终止与其的媒体流。

CallAcceptance还充当以下机制：

1.被叫者客户端向CC发送其通话中回拨URL；

2.通话控制器向呼叫者发送通话中动作URL。

CallAcceptanceAcknowledgement由以下项使用：

1.呼叫者端点向CC发送其通话中回拨URL；

2.CC向被叫者端点发送通话中动作链接。

额外地，客户端还使用CallAcceptanceAcknowledgement作为触发以确保CallAcceptance确实被呼叫者端点看见。如果在合理时间(例如15秒) 内呼叫者端点没有看见CallAcceptanceAcknowledgement，则可以重新发送 CallAcceptance。

1.2.2被叫者离开通话：

在图8B中示出了被叫者拒绝拨入的通话的场景。在该场景中，过程如上文从S802到S810继续。然而，在CA2已经附接到该通话之后，拨入的通话是由被叫者(在通话建立之前)通过以下方式拒绝的：使用在S806处所提供的URL callLegBob_CC_url上的删除请求来发送结束通话支路消息 (S834)。通过CC将拒绝通知消息发布至由Alice在S802处所提供的endNotification_Alice_url来通知Alice该拒绝(S836)。

应当注意的是，这仅仅是示例——被叫者可以将其自身从已经接受了其的通话中移除(如在图8A中)，以使得S834可以例如在图8A中在S832 之后或在附接响应和通话接受之间的任何时间发生。这样做将结束2方通话，但不是多方通话。

S834可以是响应于被叫者经由其客户端UI选择拒绝选项，或者其可以是自动的，例如，如果Bob已经将其客户端配置为自动地拒绝拨入的通话。

1.2.3被叫者请求重新定向：

图8C示出了被叫者的客户端CA2将通话重新定向到不同的目标用户的场景。过程如上文所述的从步骤S802进行到S810。拨入的通话是通过 CA2将重新定向消息发布至redirection_CCAlice_uri来重新定向的(S838) ——该URL已经由CC在S810处提供。重新定向消息标识不同的目标用户 (例如，通过用户名)。这是由CC接收的并且被发布至redirction_Alice_uri (S840)——这已经在S802处由CA1提供。这样做引起呼叫者创建与所供应的目标的新通话(S842)。S842等于S802，但是是针对新目标用户的，并且此后该过程以相同的方式继续。新的通话邀请消息被示出为被引导至不同的通话控制器523C’，而在其他示例中可能不是这种情况。

S838可以是响应于被叫者经由他们的客户端UI选择通话重新定向选项的，或者是自动的。

以S838开始的通话重新定向过程可以在接收附接响应(S810)与发送通话接受或通话结束(或接收通话结束通知)之间的任何时间完成。

1.2.4呼叫者取消通话：

图8D示出了这样的场景，其中，呼叫者的客户端CA1结束了通话，例如响应于呼叫者经由他们的客户端UI选择了结束通话选项。

呼叫者可以在任何时间结束拨出的通话——甚至是在通话建立之前 (如在该示例中)。在该示例中，该过程如上文所述的从S802进行到S822。

结束该通话是由CA1在表示整个通话的URI call_CC_url上使用删除 (例如，HTTPDELETE)请求来发送结束通话消息而实现的，并且在步骤 S804处被提供(S846)。CA2通过CC向由CA2在S808处所提供的URL callNotification_Bob_url发布通话结束通知而被通知(S848)。

针对多方通话，CC将更新名单(将Alice从其中移除)，并向剩余的参与者发送POST参与者更新消息。

通话终止(由被叫者进行)与通话取消(由呼叫者进行)之间的区别与例如SIP不同。在SIP中，有两种方法：

1.取消——由呼叫者发送以结束尚未被接受的通话

2.再见——由任何参与者发送以结束已经被接受的通话

这两种方法引起了状态机实现中的混淆，并且使得SIP倾向于竞争条件(因为，可能在正在处理取消时接受通话，并且在该时刻，某一实体不得不将取消转换成再见)。

本协议通过以下方式一起来避免该问题，只有一种不混淆的方式来结束通话(DELETE callLeg_CC_URL)以及关于通话结束而被通知(POST endNotification_<User>_URL)。不管通话的状态是什么，未连接还是连接的，这些都是有效的。

应当注意的是，上文考虑了双方通话。针对多方通话，由Alice所执行的操作不去到在另一侧的任何特定的用户，而是由通话控制器直接地处理的。例如，如果Alice在多方通话中执行媒体重新协商，则媒体回答是由媒体控制器所生成的，而其他的参与者不会变得直接感知到任何改变(尽管经由名单更新他们可以变得间接感知)。

针对多方通话，指向通话控制器的链接不能够直接映射至另一参与者的URL。通话控制器可以与像“媒体控制器”一样的其他服务器进行交互以对其在其链接上获得的请求起作用。

1.3针对所建立的通话的新事务：

在上文中定义了构成单个事务的图8A的信令流。在其中执行的所有 CC功能都是由相同的通话控制器实例执行的(虽然这不是必须的——参见上文)、在过程开始处被指定的。在于步骤S832处关联了通话接受确认之后，将针对该通话的序列化状态数据存储在相关的通话控制器聚类的经共享的存储中(参见章节2)，并且该实例被释放。在图8B(通话终止)的情况下，可以在这已经发生之后(即在已经释放了通话控制器实例之后)发起步骤S834以结束该通话。对于图8C中的S838以及图8D中的S846同样如此。

此外，应当注意的是，在图8A的信令过程中，在步骤S804处，在通话邀请响应中给CA1提供URL participantInvitation_CC_url。CA1可以例如在通话期间的任何时间向participantInvitation_CC_url发布添加参与者消息以添加新的参与者。这将触发与S806-S826类似的信令流，但是是针对新邀请的参与者的。在结束时，CC将向CA1发布在S802处所提供的URL update_Alice_url的更新消息，以指示已经添加了新的参与者。

针对诸如这些之类的通话中的操作(其中处理通话的建立的原始实例针对其已经被释放为已经将通话状态序列化)，聚类中的任何通话控制器实例可以被指定为处理通话中的处理。章节2呈现了使其可行的机制。

1.3透明的/独立可缩放代理：

由该协议所提供的灵活性提供了客户端与代理服务(例如，如在上文中由代理服务器602所提供的)的无缝集成。例如，客户端可以通过改变其提供以指向代理的URL来在代理(即，经由代理接收消息)和直接消息接收之间进行切换——不需要对消息内容的改变，或者底层信令协议。作为另一示例，客户端可以在具有类似缓和的代理之间切换。

协议提供了独立的可缩放性，例如，通过将代理服务从通话控制器去耦合。

例如，在一个实施例中，在代理服务器602上需要资源以供其能够维持至客户端的所需数量的开放(例如，Websocket)连接，其中代理服务器向所述客户端提供代理服务；然而，当协议允许客户端与通话控制器之间的通信以请求-响应(例如，HTTP)为基础进行操作时，不需要这样的资源。

因此，如果在通信系统200内需要额外的代理服务器资源，例如当用户基数增长以使得例如在通信系统内需要维持的更大数量的Websocket连接同时向增长的用户基数提供代理服务时，代理服务可以为此独立于通话控制器而被缩放。

一般而言，在通信系统200内，物理资源可以被分配至控制器(例如，通话/媒体控制器)，其与向这些客户端所提供的代理服务无关地向客户端提供服务。

在一个示例中，代理服务(例如，代理服务器602)可以作为应用在云平台100上实现，并且资源是以相同的方式但是独立地向控制器和代理服务分配的(例如，通过缩放聚类中的VM的数量，创建新的服务部署等)，以使得对控制器的物理资源的授权是独立的并且与对代理服务器的物理资源许可不同。

1.4透明地创建提供不同能力的代理服务器的链；

1.4.1通话控制器代理的透明的增加：

URL重写机制是在章节1B中阐述的并且被应用至控制器的链，其中，当消息从一个端点行进到另一个端点时，连续的URL重写操作发生，例如，以透明地提供高可用性。

图10示出了这样的示例，其中CA1与CA2之间的消息遍历三个通话控制器部署523C1(CC1)、523C2(CC2)、和523C1(CC3)。CA1将消息引导至CC1，其包含指向Alice的回拨URL<option>_Alice_url(URL<选项>_Alice_url)。CC1将其重写以替代地指向其自身，并且在消息的第一经修改版本中向CC2提供经重写的URL<option>_CC1Alice_url。CC1存储 <option>_Alice_url与<option>_CC1Alice_url之间的映射900.1。

CC2重写该URL<option>_CC1Alice_url以指向其自身，并且在消息的第二经修改版本中向CC3提供经修改的URL<option>_CC2Alice_url。CC2 存储URL<option>_CC2Alice_url与URL<option>_CC1Alice_url之间的映射 900.2。

CC3重写该URL<option>_CC2Alice_url以指向自身，并且在该消息的第三经修改版本中向CA2提供经修改的URL<option>_CC3Alice_url。CC3 存储URL<option>_CC2Alice_url与URL<option>_CC1Alice_url之间的映射 900.3。

因此，该消息遍历三个通话控制器CC1、CC2、和CC3的链，并且当其从CA1到CA2遍历通信系统时，受制于三个分离的URL重写操作。

当CA2例如通过将响应发布至<option>_CC3Alice_url而响应Alice的消息时，该响应首先行进至CC3，并从CC3到CC2(凭借映射900.3)，从 CC2到CC1(凭借映射900.2)，并最后到CA1(凭借映射900.1)。

CC2位于该链的中间，并且因此对CA1和CA2完全不可见——CA1 和CA2曾看见的全部是分别指向CC1和CC3的URL；它们看不见指向CC2 的任何URL。

这意味这通话控制器部署CC2可以是针对新的通话控制器部署CC4的替代，如在图10的下半部分中所描绘的。所需的全部是：

-CC3修改其映射900.3，以用相等的但是替代地指向CC4的 URL<option>_CC4Alice_url来替换<option>_CC2Alice_url，并且

-CC1开始将消息重新定向至CC4而不是CC2。

利用这些改变，此后被引导至<option>_CC1Alice_URL(由CA1)或 <option>_CC3Alice_URL(由CA2)的所有消息将经由CA4而不是CA2行进。因此，部署CA2已经以对端点(即，对CA1和CA2)完全不可见的方式针对CA4交换——其完全不需要对它们的动作，并且它们甚至无需知道这已经发生。

1.4.2透明地提供高可用性：

回拨可以指向聚类负载平衡器或指向一个特定的实例或甚至指向横跨多个数据中心的业务管理器而不改变协议，以允许在适当时通话控制器透明地提供高可用性。贯穿该通话，存在例如在指向单个实例、聚类负载平衡器、和业务管理器的回拨之间的自由切换。

例如，如果在系统高度使用时通话控制器部署变得负担过重，则可以创建新的部署并且将这些通话中的一些以对这些客户端完全透明的方式切换至所述新的部署。

例如，在图10的示例中，诸如通话建立、通话中事务的处理等所有主要的通话控制功能都由CA2或CA4-CC1处理的，而CC2仅充当透明接口。即，CC1和CC3分别对Alice和Bob的客户端“假装”它们实际上是通话控制器(即，实行核心通话控制功能)。在其他示例中，通话控制功能可以在不同的通话控制器部署之间共享。

CC1和CC3被示出为分离的部署以有助于描述，但是实际上，相同的部署可以执行CC1和CC3两者的功能，即CC2/CC4可以对单个部署之后的客户端隐藏。

如将理解的，该连续的URL重写机制可以应用于任何长度的控制器链。

应当注意的是，本文中的“向客户端发送消息”(或类似的)包括经由服务器发送消息，其可以修改消息的内容。

1.4.3代理链的额外使用：

代理链可以用于实现其他的功能；以下是一些示例。

为了创建消息记录解决方案(其记录在通话代理与通话控制器之间发送和接收的所有消息)，创建了这样的代理服务器，其“假装”是通话控制器，并且在从客户端接收了任何消息之后执行以下操作：

a.记录消息；

b.创建库，所述库将客户端提供的回拨URL映射至指向代理服务器的回拨 URL；

c.在消息主体中更新回拨URL以指向代理服务器；

d.向“实际的”通话控制器发送经更新的消息。

类似地，通过在客户端与通话控制器之间插入代理可以创建计费解决方案，并且使其追踪该通话的寿命和更新。

通过在客户端与通话控制器之间插入代理可以创建授权解决方案，其验证每个动作。

额外地，可以创建新的代理服务器，其添加仅需要由客户端理解而不是由“实际的”通话控制器理解的新能力。这可以通过使客户端与代理服务器讨论哪些新功能来实现，其可以理解并将添加额外的链接和消息内容 (在通话控制器理解的基本集合之外)。

2.控制器实例的高可用性：

2.1介绍：

在下文呈现了提供云控制器的高可用性的机制，即使在系统故障的事件中。这些在通话控制器的上下文中描述的，但是所述技术可以应用于其他类型的云服务(例如，应用于媒体模态控制器)。

通话控制器是基于云的服务，其需要高可靠性和可用性来确保用户即使在面对机器故障时也注意不到明显的服务中断，所述服务终端在大型数据中心中是非常常见的，例如，这是由于网络/电力基础结构中的故障或软件故障所导致的。

在高可用性之后的基本概念中的一个基本概念是具有向用户提供服务的机器的聚类(参见上文)，并且确保当一些实例停机时，来自用户的请求是由活动的其他实例来服务的。

针对该问题存在两个方面(从通话控制器的角度来看)：

1.聚类中的实例的子集的故障不应该引起用户无法进行新的通话；

2.聚类中的实例的子集的故障不应该引起正在进行的通话发生故障。

第一个问题可以通过使用云(如，Azure)的PaaS(平台即服务)能力并且创建其前面有负载平衡器(参见上文)的聚类来解决，这确保了新请求去往活动的实例。即，要解决的第一个问题在于确保机器故障不引起整体中断。可以使用聚类来解决该问题。通话控制器部署包括其前面有负载平衡器的许多实例，这确保了业务被路由至活动的实例。客户端与负载均衡器交谈，并且因此或多或少不受个体的实例故障的影响。在连通性方面的一些小的波动由客户端重试处理以考虑到瞬时故障。

这足以给予“新通话”高的可用性，因为通话创建请求会自动着陆在活动的实例上。然而，对于正在进行的通话这是不够的，因为其不足以确保通话中的命令(例如将视频添加至仅音频通话，或者将通话挂起)着陆在活动的实例上。确保通话的运行时状态被正确恢复是必需的，以使得通话中命令可以被正确地执行。

解决该问题的一种方式是将所有的回拨链接(例如那些在章节1中向特定实例所呈现的)(其与可以针对进行中的通话在通话控制器上调用的命令相对应)绑至特定的实例，因此确保所有的运行时状态已经存在(即，活动的)，以使得通话中的命令可以被正确地执行。然而，这有害于高可用性，因为实例的故障将引起通话的故障。

另一解决方案将是：

1.确保针对通话中的动作的回拨URL指向聚类负载平衡器，而不是任何特定的实例

2.将服务的运行时状态存储在诸如Azure储存表之类的高度可用的外部存储中。然而，由于以下原因，靠其自身是不够的：

a.服务的运行时状态是复杂的，并且在非常复杂的对象图表中分布。由此，不容易简单地序列化该图表以供外部存储，并且不容易基于外部数据来重新构建该图表。

b.多个机器可以同时作用于相同的运行时状态，并且可能不容易能够达成对数据的一致观点。例如，对于通话服务，添加参与者请求可以着陆在一个实例上，而删除参与者请求可以着陆在另一个实例上，这需要两个实例对最终的结果达成一致。尽管通过使用公知的同步基元可以以传统的编程来解决该问题，但是这在分布式环境中不再起作用。

以下的部分将覆盖可以用于确保聚类中的任何实例可以处理通话中命令的方法。首先，将描述围绕运行时状态的概念的一些上下文以帮助说明。

2.2运行时状态：

在面向对象编程(OOP)的上下文中，计算机程序(即，代码)可以定义对象类。类是针对特定类型的对象的模板，并且类在处理器上被实例化以在处理上创建(逻辑)对象。对象具有状态(即，在处理器存储器的一些单元处保存的状态数据)，以及行为(即，与可执行代码关联的)。对象可以被视为类的具体实例。可以将模板实例化多次以创建具有相同类型的多个对象。

运行时对象曲线作为处理任何操作的结果而被创建，并且由以许多方式彼此引用的各种逻辑对象组成。

例如，简单的示例性计算机程序可以将对象类定义如下：

在这里，A引用B(因为其具有类型B的成员)，并且B引用C，而C 进而引用A。所有这些对象类型在它们的状态中还具有一些简单的普通老式数据类型，即针对类A的整型变量x，针对类B的字符串变量y，以及针对类C的布尔型变量z。

在下文中，符号InstanceOf(<class>)指的是通过在处理器上将对象类 <class>实例化而创建的活动对象，从在处理器能够直接访问的处理器的存储器414中实现的意义上来说所述对象是活动的。

这些类的实例化创建了在图11A中示意性地表示的对象图表G。即，分别是类A、B、和C的实例的对象ObA、ObB、ObC形成了对象图表G。由于类彼此引用的方式，所以对象图表G可以被视为具有从ObA至ObB、从ObB至ObC、以及从ObC回到ObA的边缘。

完全作为示例，图11B示出了可以如何在处理器存储器414中实现通过将在上文中所定义的类实例化所创建的对象图表G。当然，实现对象实例的准确方式将取决于编译器和平台实现细节。

在该示例中：

-ObA被实现为在存储器114中的单元addrO处所保存的存储器指针(引用) p4，以及在addrO+4处的变量x的值(在该示例中，每个存储器位置保存4 个字节)；

-ObB被实现为在addrP处保存的存储器指针p4，以及在addrP+4处的y的值

-ObC被实现为addrQ处的指针p3，以及addrQ+4处的z的值。

在addrO+4、addrP+4、addrQ+4处的值x、y和z分别构成了ObA、 ObB、和ObC的状态数据。

指针p1、p2、p3是利用其实现对象之间的引用的机制：p1指向addrP，在该处ObB在存储器114中被实现；p2指向addrQ，在该处ObC在存储器 114中被实现；以及p3回至addrO，在该处ObA在存储器114中被实现。

可以看见的是，由于类定义的复杂性和所定义的引用其他类的更多的类，因此所得出的对象图表倾向于具有长且可能复杂的指针链，其倾向于随着更多对象被创建而增加长度。

引用必须被实现为存储器中的指针的事实使得它们在本质上难以序列化。“序列化”是在处理器的存储器中所实现的将对象图表(例如R’)翻译成可以存储在外部存储中的格式的过程，例如，存储在文件或存储器缓冲器中或者跨网络连接链路而发送，并且之后在相同的或另一个计算机环境中重建。当根据序列化格式重新读取所得出的位的序列时，其可以用于在相同的处理器的或另一处理器的存储器中创建对原始对象在语义上相同的克隆。

2.3对象图表恢复：

该公开提供了一种用于创建运行时状态的通用框架，其即使针对非常复杂的计算机程序也保持可序列化。所述框架规定了在计算机程序内如何定义对象类，并且特别地定义了对象类应该如何彼此引用。当坚持该引用的系统时，被创建为这些类的所得出的对象图表被实例化为保持容易可序列化，而不管它们变得如何复杂。

在章节2中，呈现了以下技术：

1.用于以可序列化的方式表示整个运行时对象图表的技术；

2.用于在给定序列化状态的情况下创建对象图表的技术；

3.用于创建指向对象的回拨链接(如在章节1中所使用的)的技术，从该对象处可以重新创建所需的图表的部分；

4.用于确保该恢复不引起堆栈溢出的技术。

在章节3中，公开了以下技术：

5.用于确保对象图表的单个恢复以确保一致性的技术

6.用于在整个聚类中保持所有实例的健康知识是最新的技术；

7.用于通过创建针对序列化状态数据的虚拟存储来优化序列化状态数据的读/写的技术。

一般服务的运行时状态包括彼此引用的多个对象。这些对象一起形成了活动的对象图表，并且彼此协调以执行服务功能——例如，通话控制器功能。当通话被建立时，对象图表被创建并且随着通话建立过程进展而被修改。对象图表构成了通话的通话状态，这在于其实施了关于该通话的当前状态的所有信息。如在下文中更加详细地描述的，一旦该通话已经被建立，则对象图表被序列化以创建存储在计算机存储中的状态数据，对象图表可以在之后的时间根据其在该处理器或另一处理器上被重新构造(重新激活)。

服务(例如，通话控制服务、媒体控制服务)是由多个协作的对象传递的，其各自实现相应的服务功能并且具有某一形式的状态数据(服务对象)。服务类指的是定义了针对服务对象的模板的类。服务类提供了(定义了)相应的服务功能和状态数据的结构，例如，通过定义当服务列表被实例化时向其分配值的一个或多个变量以创建服务对象(所述值构成了状态数据)。服务功能是基于状态数据实现的，并且其还可以修改状态数据。

对于需要较高可用性的分布式系统而言，该对象图表需要在需要处理针对正在进行的通话的用户请求的任何实例上被恢复。

任何通用对象包括两种形式的状态：

1.简单的可序列化的状态，例如字符串、整型、布尔型(或由这些简单实体组成的任何其他复杂的结构)

2.对其他对象的引用

将对象状态的第一部分存储在任何外部存储中是非常容易的，但是存储第二部分(引用)不这么容易。

该公开的通用恢复框架是基于以下概念的(类的类型)：

1.PersistedObject(持续型对象)——包含某一简单的可序列化状态，并且“可序列化引用”(参见下文)其他PersistedObject(持续型对象)的任何对象：

a.每个持续型对象实现GetReference()函数，该函数将PersistedObjectReference(持续型对象引用)返回至该对象；每个服务对象是PersistedObject；

2.PersistedObjectReference——对PersistedObject的可序列化引用。序列化的PersistedObjectReference仅仅包括两段数据：

a.PersistedObject的唯一标识符(ID)；

b.PersistedObjectFactory(持续型对象工厂)(工厂对象标识符)的唯一 ID——参见下文；

3.每个PersistedObjectReference实现被称为GetObject()的函数，该函数将指针返回至指向PersistedObjectReference对象所指向的、在本地可激活/恢复的PersistedObject的位置的指针；

4.PersistedObjectFactory——知道如何基于来自外部存储的数据来创建特定类型的PersistedObject的对象。每个工厂实现CreateObject()函数，其由PersistedObjectReference调用以实际上创建(或定位——参见下文的章节 2.2)该对象；

5.PersistedObjectFactoryLocator(持续型对象工厂定位器)——所有的工厂都向其登记以使得任何人都可以访问所需的工厂的对象；提供了 GetFactory()函数，该函数对工厂标识符实现以返回经标识的工厂；

6.PersistedObjectStore(持续型对象存储)——隐藏外部存储器的实现的抽象化，以使得恢复基础结构对任何特定的外部存储器都没有依赖；其被配置为提供GetState()函数，该函数在对象ID上调用以从存储取回经标识的对象的序列化状态数据(例如，GetState(ObjectID)返回具有标识符ObjectID 的服务对象的状态数据)。

每个PersistedObject类还被配置为提供Initialize()函数，该函数用于利用由GetState()所取回的状态数据将新创建的对象初始化。

“Class[大写C]对象”(或类似的)指的是通过将类“Class”实例化所创建的对象。例如，“PersistedObejctA对象”指的是通过将类 PersistedObejctA实例化所创建的对象。

换句话说，PersistedObjectReference是可序列化的对象，其不混淆地指向PersistedObejct。此外，我们创建了PersistedObjectFactory和PersistedObjectFactoryLocator的概念，或者在给定PersistedObjectReference 的情况下创建了对象。

每个PersistedObjectReference对象(引用对象)具有以下的状态数据：

1.ObjectId——针对PersistedObject对象的唯一的id，其可以由PersistedObjectFactory使用从任何外部存储提取任何状态；

2.FactoryId——针对PersistedObjectFactory对象的唯一的id，其可以创建由ObjectId所表示的PersistedObject。该ID通过调用 PersistedObjectFactoryLocator.Get(<FactoryId>)来定位工厂对象。

“对<持续型对象>的PersistedObjectReference”被用作速记以指其状态数据包括<持续型对象>的PersistedObject标识符的引用对象。

任何PersistedObject对象(持续型对象)具有至少一种方法(函数)：GetReference()，该函数返回针对该PersistedObject对象的PersistedObjectReference。

所有PersistedObjectReference对象具有方法：GetObeject()，其返回引用对象所指向的PersistedObject的实例，即在引用对象中由ObjectID所标识的PersistedObject对象。

所有的PersistedObjectFactory对象(工厂对象)具有方法： CreateObject()，其采用将PersistedObject标识为输入的ObjectID，并且从对应的序列化状态数据创建经标识的PersistedObject，或如果经识别的 PersistedObject已经被创建，则对其进行定位。

PersistedObjectFactoryLocator是单件实例(工厂定位器对象)，其中所有的PersistedObjectFactory对象都在过程开始时(例如，在启动时当计算机程序首先在处理器上实例化时)向其登记。即，在启动时，所有的持续型对象工厂都向PersistedObjectFactoryLocator的单件实例登记，以使得已知任何PersistedObjectReference可以用于创建实际的PersistedObject实例。

由于PersistedObjectReference是可序列化的，因此有可能将每个对象的状态存储到外部存储器中，并且由于存在与每个对象引用相对应的不混淆的工厂，因此总是有可能从序列化状态创建PersistedObject的实例。

所有通话控制器对象都是PersistedObject，其将它们的状态序列化并且在它们的寿命中良好定义的点处写入PersistedObjectStore。任何其他实例将能够仅仅通过从根对象开始来恢复整个对象图表。

PersistedObjectStore也在启动时被实例化以创建存储对象。

通话控制器通过使用以下的URL方案来创建通话中回拨链接：

https://<Call Controller fqdn>/<PersistedObjectFactoryId>/<PersistedObjectId>

因此，如果接收到任何通话中命令，则通话控制器可以通过解析出工厂Id和对象Id来创建PersistedObjectReference，并且接着，可以对参考对象调用GetObject()，以得到实际的PersistedObject的句柄。

一旦其具有了到一个PersistedObject的句柄，则对象图表的子图表(针对该子图表，经标识的PersistedObject是根)可以通过跟随引用链而被渐进地构造。即，来自经标识的持续型对象向下的一切都被构造——这可能不包括图表中的所有对象。

因此，遵守该框架的计算机程序可以：

-定义一个或多个PersistedObject类，即针对持续型对象的一个或多个模板，其每个被配置为提供：

GetReference()函数；

-针对一个或多个PersistedObject类中的每个类的PersistedObjectFactory类，其每个可以被配置为提供：

CreateObject()函数，该函数从其序列化表示来创建该类型的持续型对象；

-PersistedObjectReference类，其被配置为提供：

持续型对象ID；

能够创建(或定位)经标识的持续型对象的工厂ID；

GetObject()函数，其返回经标识的持续型对象；

-PersistedObjectFactorLocator类；以及

-PersistedObjectStore类。

因此，在上文中所定义的类A、B、和C根据以下的当前框架而被重新定义：

应当注意的是，PersistedObjectReference PersistedA、PersistedB、PersistedC不直接引用其他PersistedObject类，即没有PersistedObject类具有PersistedObject类型的成员——PersistedObject类仅仅具有PersistedObjectReference类型的成员，并且因此仅仅间接地引用其他 PersistedObject类。

对于每一类型的PersistedObject，也将存在对应的PersistedObjectFactory类：

工厂类将在启动时被实例化以创建工厂对象POFA、POFB、和POFC，它们分别用于创建具有类型PersistedA、PersistedB、和PersistedC的对象。 POFA、POFB、和POFC可以从序列化的状态数据分别重新创建具有类型 PersistedA、PersistedB、和PersistedC的对象。

如在上文中所定义的，类PersistedA-PersistedC将接着在程序的某一阶段被实例化以分别创建持续型对象PObA、PObB、PObC，如 PersistedObjectReference类将会创建对应的持续型对象引用那样：

-PORA：包含PObA的持续型对象标识符，以及POFA的工厂标识符；

-PORA：包含PObB的持续型对象标识符，以及POFB的工厂标识符；

-PORA：包含PObC的持续型对象标识符，以及POFC的工厂标识符。

持续型对象POA、POB、和POC以及引用对象PORA、PORB、PORC 被构造为对象图表PG，在图12A中示出了其概念性视图。

由于各种类彼此引用的方式所致，对象图表PG可以被视为具有边缘 (被示出为箭头)。

图12B示出了可以如何在处理器的存储器414中实现对象和边缘的一个示例。再一次，这仅仅是用于帮助示出的示例——在实践中，这将取决于对编译器/处理器平台的实现细节。

类似于图11A，每个服务PObA、PObB、PObC在存储器中被实现(在 addrO至addrO+4、addrP至addrP+4、以及addrQ至addrQ+4处分别地实现) 为：

-addrO处相应的存储器指针p1，addrP处的p2、addrR处的p3；以及

-addrO+4处的x的值，addrP+4处的y的值，addrQ+4处的z的值。

然而，相比于图11A，指针p1、p2、p3不指向其他持续型对象的存储器单元；它们而是指向相关引用对象的单元addrR、addrS、addrT。这是因为PersistedObject类仅仅具有PersistedObjectReference成员类型。

addrR至addrR+4是实现PORB的地方(并且因为类PersistedA间接地引用PersistedB，所以p1指向这里)：addrR保存POFB<POFB的ID>的工厂对象标识符，而addrR+4保存PObB<PObB的ID>的持续型对象标识符。addrS 至addrS+4是实现PORC的地方(并且因为类PersistedB间接地引用 PersistedC，所以p2指向这里)：addrS保存POFC<POFC的ID>的工厂对象标识符，并且addrR+4保存PObC<PObC的ID>的持续型对象标识符。addrT 至addrT+4是实现PORA的地方(并且因为类PersistedC间接地引用 PersistedA，所以p3指向这里)：addrS保存POFA<POFA的ID>的工厂对象标识符，并且addrR+4保存PObA<PObA的ID>的持续型对象标识符。

也保存在存储器414中的是一组映射M，其针对每个活动的持续型对象，将持续型对象的标识符映射至标识在其处实现经标识的持续型对象的位置的相应的存储器指针(即，保存其状态数据的地方)——在该示例中， M包括：

-第一映射m1：<PObA的ID>-﹥<指向addrO的指针>

-第二映射m2：<PObB的ID>-﹥<指向addrP的指针>

-第三映射m3：<PObC的ID>-﹥<指向addrQ的指针>

所述映射被保持在本地激活高速缓存中(参见下文的章节2.2)。

也保存在存储器中的是一组工厂映射FM，其将工厂标识符映射至实现相关的工厂对象POFA、POFB、POFC的存储器中的单元。当对应的工厂对象向FactoryObjectLocator登记时，创建FM中的每个映射。

不管对象图表变得变得如何复杂(即，由于定义了引用其他类的更多类以及所创建的更多对象)，框架避免产生指针的长链的情形(即，指针指向指针，其指向其他指针，其指向另外的指针，其指向另外的指针等)。换句话说，PersistedObjectReference对象的出现有效地打破了对象间引用的链，以使得尽管其复杂性，但是要序列化的结构保持易处理。即，不管对象图表多复杂，将序列化函数应用于持续型对象被保证为在相对较短的时间内生成易处理的输出，这是因为对个体的持续型对象的序列化保证能以持续型对象所指向的参考对象终止。

2A.序列化：

已知该结构和序列化函数(例如，已知的JSON序列化函数)：

1.Serialize(InstanceOf(PersistedA))将返回以下内容(如果使用JSON序列化器来序列化))：

2.Serialize(InstanceOf(PersistedB))将返回以下内容(如果使用JSON序列化器来序列化))：

3.Serialize(InstanceOf(PersistedC))将返回以下内容(如果使用JSON序列化器来序列化))：

在该示例中，经序列化的状态数据是纯文本格式的。

在计算机程序实现通话控制器的情况下，可以针对由通话控制器的实例所建立的每个通话而创建相应的对象图表。当通话被建立时，在处理器的存储器中创建实现函数以建立通话的新的服务对象——这些形成了对象图表，这构成了通话的活动通话状态(参见以下的示例)。接着，一旦通话已经被建立(例如)，活动通话状态被序列化、被存储在外部存储中、并且活动通话状态被去激活，由此释放了处理器上的资源。在通话中之后的时间，例如，响应于诸如将新的参与者添加至通话的请求之类的某一通话中请求消息，对象图表的至少一部分是(即，至少一些服务对象是)可以被执行以实现该请求的事务。执行该事务可以修改所恢复的活动通话状态。当完成该事务时，可以以相同的方式来序列化经修改的活动的通话状态以更新在外部存储中所保存的通话状态的经序列化的版本。

图13是用于序列化持续型对象的方法的流程图。在该示例中，每个持续型对象在每次其状态改变时被序列化——这仅仅是出于说明的目的的一个示例。

在流程图的右手侧，提供了插图以帮助理解在相关的方法步骤处执行的操作。

在步骤S1304处，持续型对象POb中的第一个(例如，PObA)被序列化以生成针对POb的个体的经序列化的状态1302，例如，使用JSON序列化函数。个体的状态数据1302包括：

-由PO所引用的任何持续型对象的持续型对象标识符1306——例如，针对 PObA，因为PObA引用了PObB，所以是<PObB的ID>——以及；

-用于重新创建对象所引用的持续型对象的工厂对象的工厂对象标识符1304——例如，针对PObA，是<POFB的ID>，因为PObA引用了PObB；

-针对POb的状态数据(例如，针对PObA，x的值)。

还可以使用任何其他合适的序列化技术；例如，BOND序列化，二进制序列化等。

在步骤S1306处，在表示整个对象图表PG的序列化状态数据1300中包括个体的状态数据1302。个体的数据1302在序列化数据1300中由以下项来标记i)持续型对象POb自身的持续型对象标识符1308(例如，<PObA 的ID>)，以及ii)用于重新创建POb的工厂的工厂对象标识符1310(例如， <POFA的ID>。

在步骤S1308处，生成了回拨URL 1312，其包括工厂对象标识符1308 和持续型对象标识符1310。

由工厂对象标识符1310所标识的工厂对象被配置为从经序列化的数据 1300重新创建持续型对象POb，当POb的持续型对象标识符1308被输入到工厂对象的CreateObject()函数时。

例如，已经在S1306处被序列化的持续型对象可以实现某一通话控制服务功能，例如，用于将参与者添加至通话；在S1308处所生成的回拨URL 被发送至参与通话的客户端；为了将参与者添加至通话，客户端访问该链接。当该链接被访问时：

-因为URL包含工厂对象标识符1308，所以可以从URL自身识别重新创建POb所需要的工厂对象；并且

-在URL自身中包含的持续型对象标识符1310可以被输入到经标识的工厂对象以重新创建持续型对象POb。

接着，客户端知道如果其请求添加新的通话参与者，则访问该链接。

针对任何剩余的PersistedObject对象(例如，PObB、PObC)而重复过程S1304-S1308，(S1310)。

例如如果创建了新的持续型对象，或者现有的持续型对象被更新，则可以再次执行该过程，以便保持经序列化的状态1300是最新的。

2B.对象重新创建(去序列化)：

现在已知任何经序列化的数据，其可以被去序列化(这意味着从其经序列化的表示创建对象)，并且从这里开始，可以跟随其引用链来创建可能需要的任何其他对象。

针对上文中的示例，可以将针对InstanceOf(PersistedC)的经序列化的数据去序列化以恢复InstanceOf(PersistedC)，即PObC。

接下来，对PORA的PersistedObjectReference可以被恢复，这是因为 PObC的经序列化的状态数据包含服务对象标识符<PObA的ID>，即和 <POFA的ID>——这两个标识符是重新创建引用对象PORA所需的全部，这是因为它们表示了引用对象PORA的状态数据的总和。

接下来，调用InstanceOf(PersistedC).PORA.GetObject()。从这里开始，可以以相同的方式来恢复PORB以及因此PObB。

PersistedObjectReference.GetObject()被简单地实现为：

1.Factory＝ PersistedObjectFactoryLocator.GetFactory(PersistedObjectReference.FactoryId)

2.Object＝Factory.CreateObject(PersistedObjectReference.ObjectId)

在本文中，“POb.f()”意指调用(即，进行函数调用)由服务对象POb所实现的函数f()。

通过在构造具有任何PersistedObject类型的实例时生成合适的 FactoryId和ObjectId，并且将所生成的标识符输入至实例的构造器来使得实现PersistedObject.GetReference()是可行的。

例如，PersistedA的构造器可以将两个参数FactoryId和ObjectId作为输入。

图14是从经序列化的状态数据重新创建服务对象的方法的流程图。再一次，定位了绘图表示以示出可以在对应的方法步骤处执行的示例性操作。这些仅仅是出于说明的目的的示例。

在步骤S1402处，接收服务重新激活消息。例如，所述服务激活消息可以与所建立的通话相关，并且请求添加新的参与者。所述服务请求消息被发布至回拨URL 1312(例如，如先前在图13的S1308处所生成的)，并根据章节1的信令协议而提供至客户端。

图14的步骤S1404至S1410构成了子例程，其被重复地执行以重新激活以经序列化的状态数据1300表示的对象图表的至少一部分——具体地，对象图表的子图表，针对该子图表，在S1302的服务请求消息中所标识的持续型对象是根，即由经标识的对象引用的所有持续型对象，并且进而，由这些对象引用的任何另外的持续型对象，并且进而，由所述另外的持续型对象引用的任何另外的持续型对象等。

回拨链接1312被解析以获得持续型对象标识符1310以及用于重新创建该类型的持续型对象的标识工厂的工厂对象标识符1308，并且所述子例程最开始是针对这些持久型和工厂对象执行的：

在该示例中，链接包括<PObA的ID>和<POFA的ID>，即持续型对象 PObA的持续型对象标识符，以及用于从相关的序列化状态数据创建PObA 的工厂对象POF的工厂对象标识符。

在步骤S1404处，工厂对象ID 1308和服务对象ID 1310用于恢复由服务对象标识符1310所标识的持续型对象POb的PersistedObjectReference对象POR——如在上文中所指示的，这两个标识符是重新构造引用对象所需的全部。

在步骤S1406处，搜索根据图13所生成的经序列化的状态数据1300 以找到具有与从回拨链接1312所获得的工厂对象标识符1308和持续型对象标识符1310相匹配的标签的条目。

在步骤S1408处，该条目中的个体的经序列化的状态数据1302被输入至由工厂对象标识符1308所标识的工厂对象以恢复持续型对象POb——这通过调用POR.GetObejct()来实现的。

在该示例中，所讨论的服务对象是PObA，并且重新创建的PObA是在存储器中在addrD至addrD+4处实现的。变量x的值从经序列化的状态数据被加载到addrD+4中；因为PObA引用PORB(参见上文)，所以存储器位置被预留以保存指向PORB的指针——但是在该阶段PORB还未被重新创建，所以addrD最开始时是空的。

映射m1’也在存储器414中被创建，其将<PObA的ID>映射至标识 PObA在存储器414中在哪里被实现的存储器指针，在该示例中即指向 addrD的指针。

在步骤S1410处，是取决于刚刚被重新创建的持续型对象是否引用任何其他持续型对象的子例程分支：如果否，则子例程结束。如果是，则重复子例程S1404-S1410，但是这一次是针对所引用的服务对象，即由刚刚被重新创建的持续型对象间接地引用的(那些)对象。

图14的右手侧作为示例示出了PORB和PObB(由PObA所引用的)如何被重新创建。一个PORB已经在addrH至addrH+4处被重新创建，在存储器414中的addrH处生成了指针p1’以完成对PObA的重新构造。

为了重复该子例程，仅仅当实际上需要与引用对象POR相对应的服务对象来实现服务功能时才调用POR.GetObject()。例如，在PObB实现服务功能fB()的情况下，PObA可以调用PORB.GetObject().fB()，这使得PObB 被重新激活并且接着使得fB()在被重新激活的PObB上被调用。

接着，再次执行子例程以用相同的方式来重新构造PORC和PObC。

2.2恢复并提取对象：

如将显而易见的，针对非循环对象图表，过程将最终以不引用任何其他服务对象的服务对象终止。

针对循环对象图表，提供了额外的机制。循环的对象图表是具有闭环的引用的图表——图12A的对象图表是循环对象图表的一个示例。

考虑以下的场景：存在两个持续型对象A和B。A引用B，并且B引用A。如果A恢复B，并且在恢复期间B尝试恢复A，则这将引起死循环，该死循环将最终导致堆栈溢出和崩溃。

为了照顾好该场景，在服务对象恢复之后，服务对象的标识符与指向存储器414中的在其处实现该服务对象的单元处的存储器指针之间的映射 (例如，图12B中的m1、m2、m3)在本地激活高速缓存中被创建。未来对恢复该对象的尝试(通过在对应的引用对象上调用GetObject())仅仅引起高速缓存的值被返回，因此打破了循环链。

当在实例上“恢复”持续型对象时，算法(PersistedObjectFactory遵循的)是：

1.从外部存储提取持久型状态：

State(状态)＝PersistedObjectStore.GetState(ObjectId)

2.在本地存储器中创建对象：

X＝新的PersistedObejct()

3.利用从外部存储所取回的状态来初始化所创建的对象，

X.Initialize(State)

4.将所创建的实例放入本地激活高速缓存，其是从对象id到对在本地恢复的对象的引用的字典(dictionary)。

此时，X是驻留在本地存储器中的被完全恢复的(被重新组合)的PersistedObject对象(即，服务对象)。因此，实例X是对存储器中的实际的对象的引用。

因此，当某一其他对象(Y)具有对X的PersistedObjectReference并且想要调用其上的方法时，以下情况将发生：

1.Y将调用PersistedObjectReference(X).GetObject()——这将最终去往PersistedObjectFactory()。CreateObejct()，其将首先看本地激活高速缓存，并且如果针对ObjectId的条目已经存在，则将返回对已经创建的对象的引用。如果条目不存在，则其将遵循以上的算法以对其创建并且将其放入本地激活高速缓存

2.现在Y具有对X的本地实例化的引用，并且可以调用X上的任何方法以将其视为任何其他对象

即，返回高速缓存的对象，并且没有创建高速缓存的对象的另一版本。使用该机制确保了所有PersistedObjectReference(X)对象引用 PersistedObject(X)的相同实例。该属性确保了PersistedObject图表的行为与具有在图11A中所示出的类型的图表完全相同，其中对象直接引用彼此的存储器单元(并且因此“自动地”指对象的相同实例)。

3.确保单个恢复：

下文提供了一种机制以确保如果针对相同通话的多个事务同时发生，则它们全都由相同的实例来处理以确保通话状态的一致性。

由于不同的通话中请求可以去往通话控制器的不同实例，所以这可能引起针对通话的对象图表同时在多个通话控制器实例上被恢复的情况。

当相同对象的不同恢复试图将它们的(不同的)状态写入到外部存储中时，这可能引起数据的不一致。

尽管有可能使用乐观并发性的详尽方案，但是重新尝试和回退以调解数据并达到一致的值是复杂的和不可预测的。

针对该原因，通话控制器部署以一种不同的、更加可预测的方式确保了数据的一致性。该机制确保存在对象图表的单个恢复，以使得相同的对象图表获得处理并发请求的机会。利用该方式，对象可以使用传统的同步技术——例如锁、监视器、和信号装置——以容易地确保数据一致性。

所公开的一种用于在通信网络的端点之间实现通信事件的通信系统。所述系统包括：数据库；用于接收消息的输入端；被配置为保存代码的计算机存储；以及一个或多个处理器。所述代码被配置为实现用于管理所建立的通信事件的控制器。所述处理器被配置为运行控制器的多个实例。针对控制器的每个实例，响应于所述实例接收请求与所建立的通信事件相关的动作的消息，所述实例访问数据库以确定其是否包含有效的拥有权条目，所述有效的拥有权条目将控制器的另一实例标识为当前拥有该通信事件。如果这样，则该实例将该消息转发至其他实例；如果否，则该实例在数据库中创建将该实例标识为当前拥有该通信事件的有效的拥有者条目，并且执行所请求的动作，其包括修改在计算机存储中所保存的通信事件的状态。

在下文中，Fdqn意指完全合格域名。“<通话控制器Fqdn>”意指通话控制器聚类的域名。该聚类内的个体的实例具有不同的IP地址并且由相关联的实例ID来区分。

这可以通过使用以下方案来实现：

1.每个通话与唯一的上下文相关联，其具有将其与任何其他上下文区分开的唯一的ID(上下文标识符)<上下文ID>；此外，该部署的通话控制聚类中的每个通话控制器实例具有将其与该聚类中任何其他实例区分开的唯一的实例ID。

2.指向通话控制器的每个回拨URL在URL中具有该上下文id，其具有以下形式：https://<通话控制器Fqdn>/<上下文

Id>/<PersistedObjectFactoryId>/PersistedObject>。

3.当在通话控制器实例上调用任何动作时，其执行以下算法(“ProxyOrTakeOver”)：

a.针对通话创建请求，在外部存储中的数据库(1502，图15)中创建以下条目：<ContextId，Processing Instance ID>，其最初是有效的。“处理实例ID”是创建该条目的实例的实例ID。因此，该条目将该实例标识为当前拥有该通话，只要该条目保持有效。在一段时间之后该条目过期(变得无效)。针对该条目的过期时间是其完成任何单个事务(例如，建立通话)所花费的最大时间。

i.应当注意的是，该条目与对象图表的状态(只要该通话是活动的，其就留存)不同；

ii.针对通话控制器，最大时间是90秒(基于该协议)；

iii.在不活动的时间间隔之后，拥有权条目到期(失效)，其中在该时间间隔上不执行针对该通话的通话控制操作，这是出于以下两个原因：

1.当新请求着陆在任何实例上时，该实例应该仅能够变成新的拥有者而不是必须总将该请求代理至原始的实例。这通过避免不需要的代理而提供了更优化的处理，并且其还确保了更好的负载分配；

2.拥有权条目保持有效越久，拥有者在通话活动时发生故障的可能性越大，并且因此需要另一服务器来试验拥有者、检测其故障、并且接着试图接管；

4.如果不发生什么的话，则可以通过允许拥有权到期来避免以上的两个问题。

a.对于着陆在实例(1504，图15)上的通话中请求，检查其是否存在未过期的<ContextId，Processing Instance ID>

b.如果不存在这样的条目，则创建条目<ContextId，Current Instance ID>(1506，图15)，并且开始处理该请求；“Current Instance ID”是通话中请求已经着陆在其上的实例的标识符，因此将该实例标识为当前的拥有者，只要该条目保持有效；

c.如果存在这样的条目，并且处理实例的实例ID的值与当前实例的实例ID相同，则扩展条目的寿命，并且开始处理该请求

d.如果该条目的实例ID与当前实例的实例ID不同，则检查该处理实例是否活动(使用下文呈现的算法)，并且如果活动，则将该请求代理至该实例。该实例将再次执行相同的算法

e.如果处理实例死了，则更新用于将当前实例标记为新的处理实例的条目，并且开始处理该请求

i.多个同时的写入是使用乐观并发性来处理的。因此，当实例1和实例2尝试同时变成拥有者时，一个将胜利而另一个会了解它并代理至胜利者。

当针对通话的通话状态被序列化时，将其与该通话的上下文ID相关联地存储，以使得正确的通话状态可以在之后被恢复。

图15是用于处理通话中请求消息的流程图(例如，将新的参与者添加至所建立的通话、结束所建立的通话等)。在右侧示出了该方法步骤的绘图表示。

在步骤S1502处，请求事务(其涉及一个或多个操作)的通话中请求消息(即，其与已经建立的通话相关)被发布至URL。该URL指向通话控制器聚类522C，并且所述消息因此是由聚类的负载平衡器548接收的，并且相应地被转发至通话控制器的实例——在该示例中，是434C2。该消息被发布至的URL包含对所建立的通话唯一的“contextID”(参见上文)。

作为响应，实例434C2访问数据库1502以确定是否存在将该通话控制器的另一实例标识为当前拥有该通话的有效的拥有权条目(S1204)。这样的条目将包含该拥有实例的实例标识符(例如，图15中的“ID1”)。

如果这样，则实例434C2检查(S1507)其他的实例是否仍然起作用(活动)——参见下文。如果活动，则实例432C将该消息转发至在有效条目中所标识的其他实例(例如，434C1)(S1506)。这被称为“代理操作”。

如果不存在有效的拥有权条目或其他实例不活动，则该实例创建有效的拥有权条目，所创建的条目包括该实例的实例标识符(“ID2”)和上下文 ID，由此将其自身标识为该通话的当前拥有者(S1508)。这被称为“上下文接管操作”。

接着，该实例继续以执行所请求的事务，所述事务涉及从外部存储606 中的相关的经序列化的状态数据(其在存储中由该通话的上下文ID所标识) 重新创建针对该通话的对象图表(即，通话状态)、执行实现该事务所需的动作(其将固有地涉及修改所恢复的状态)、以及将经修改的通话状态的经序列化的版本存储回外部存储606中。

使用上下文的读/写优化：

通过采用在上文中所定义的上下文的概念，可以优化对外部对象高速缓存的读/写。

这可以通过根据上下文来创建虚拟外部存储来实现，其累积所有的写& 服务所有的读，并且接着成批地将所有的写推出至“实际的”外部存储——例如，通过对存储器中的经序列化的图表拍快照。

每个个体的PersistedObject将继续“认为”它们正将它们数据写入外部存储，但是实际上，它们正写入本地存储器；对于所有的读同样如此。

针对通话控制器，虚拟存储器基于通话的阶段而将其数据写入实际的外部存储。例如，针对1：1通话，当该通话被建立时数据被转储，而当该通话结束时数据被删除。

并且通过确保单个对象图表恢复，所有的读&写被保证是一致的。

虚拟上下文存储可以自身作为其中本地实例变成处理实例的上下文接管操作的一部分而被填充。这具有确保在成功接管了该上下文之后，没有恢复将因为读取失败而发生故障的优点，这确保了可预测性。

实例可用性检查：

为了检查实例是否活动(出于代理或接管操作算法的目的)，通话控制器遵循简单的技术：

1.每隔4秒每个实例将心跳消息写入具有10秒到期时间的外部存储中的数据库608(10秒＝2*4+2秒的安全极限)。该到期时间给予了条目对瞬时故障的一些弹性——心跳需要连续故障两次以供其他实例认为特定的实例死亡。

2.每隔4秒，每个实例还读取由所有其他实例所写的条目。

3.找到针对其的条目的实例被认为是活动的，而其他的实例则被认为是死亡的

4.以该方式，在特定的实例故障的14秒内(在最坏的情况下)，其他实例开始知道该故障，并且对先前由现在死亡的实例所服务的通话进行适当的“接管”。

使用通话处理的示例：

为了有助于描绘，呈现了示例性和简化的情况，在该情况下，图表在通话控制器实例处理通话时被创建，并且接着，一旦该通话已经被建立，则在该通话自身期间，至少一部分图表被重新创建。

协作以传递通话控制服务的所有对象被创建为持续型对象，并且在它们的状态中仅仅包含PersistedObjectReference(除了其他本质上可序列化的状态之外)。当它们需要对它们引用的任何对象进行作用时，它们仅仅调用PersistedObjectReferece.GetObject().<要调用的方法>。

在下文中，对引用另一服务对象(对象2)的服务对象(对象1)的引用指的是使用对应的引用对象(引用2)的间接引用。在对象2实现服务函数(f2())的情况下，对象2通过调用reference2.GetObject().f2()在对象上调用f2()(reference2.GetObject()返回对象2，f2()接着在对象2上被调用)。

序列是：

1.用户A(Alice)呼叫用户B(Bob)

a.CallInvitationRequest(通话邀请请求)包括由通话控制器使用以在其上发送通知的一组回拨URL 2.通话控制器接收该请求，并且在将其解析之后，创建以下的服务对象：

a.UserAFacingCallbackHandler——其具有从用户A作为状态接收的各种URL。该对象暴露了以下方法

i.Accept()，其使用接受url来向呼叫者发送通话接受消息

ii.Reject()，其使用拒绝url来向呼叫者发送通话结束消息

b.Call0——其是商业逻辑层可以对其进行作用的抽象。其特征在于：

i.状态：

1.通话内容，例如呼叫者、被叫者、以及通话模态(音频/视频)

2.对UserAFacingCallbackHandler的引用

3.支路——对通过调用CreateFork方法所创建的Call(通话) 对象的引用的阵列(分支是在下文的点中的一个点中描述的，并且指的是将一个通话发送至多个端点的过程)

ii.方法：

1.Accept——当被叫者接受该通话时被调用

2.Reject——当被叫者拒绝该通话时被调用

3.Cancel——当呼叫者取消该通话时被调用

4.CreateFork——由背对背(Back-to-Back)控制器(在下文中所描述的)使用来创建针对通话的支路

iii.其工作的方式是——如果逻辑层呼叫Call0.Accept，则UserAFacingCallbackHandler的AcceptUrl将被读取，并且CallAcceptance 消息将被发送至该URL

3.接着，通话控制器将该Call0对象给予商业逻辑层

4.商业逻辑包括被称为背对背路由控制器的对象的链；

a.这些对象可以参与通话的路由；

b.对Call对象使用所述方法，它们可以影响整个消息流，并且暂时地或永久得保持在该消息流链中；

c.背对背路由器的几个示例是：

i.计费控制器——从通话开始时其就保持在链中，并追踪对该用户的计费，并且如果用户超时，则可以切断该通话；

ii.许可实施控制器——该控制器确保用户A仅仅可以执行根据政策是允许的通话操作(例如，用户B可能已经屏蔽了用户A)；

iii.端点路由控制器——该控制器定位被叫用户(用户B)的端点，并将通话路由至合适的目的地；

d.每个背对背路由器获得Call对象，并且创建一个或多个Call对象(通过呼叫CreateFork)——所创建的Call对象中的每一个表示原始通话的支路。例如，如果用户B具有2个端点，则端点路由控制器将创建2个Call 对象，其每一个将被适当地路由(至相应的端点)

e.假定控制器链是：许可实施-﹥计费-﹥端点路由；

5.许可实施控制器获得Call0对象，并且创建另一Call对象—— ForkedCall1，其具有以下特征

a.状态：

i.对父Call对象的引用——其工作方式是：如果 ForkedCall1.Accept获得通话，则Call0.Accept将被调用。

ii.支路——如果任何一个被创建

b.方法：

i.与Call对象相同

c.应当注意的是，作为许可施加控制器在原始Call对象上调用 CreateFork()的结果，父对象的支路阵列将被附加有ForkedCall1-﹥ Call0.Forks＝{ForkedCall1}

6.计费控制器接着获得ForkedCall1并且创建ForkedCall2

a.ForkedCall2引用了父ForkedCall1，并且具有与ForkedCall对象相同的类型

b.ForkedCall1.Forks＝{ForkedCall2}

7.端点路由控制器获得ForkedCall2并且创建ForkedCall31和ForkedCall32

a.这两个支路都具有与通话相同的类型并且包含对父对象ForkedCall2 的引用

b.ForkedCall2.Forks＝{ForkedCall31,ForkedCall32}

8.通话控制器现在生成两个通话通知请求——针对ForkedCall31和ForkedCall32各一个

a.通话通知请求中的每个通话通知请求包含指向合适的通话对象的附接URL

b.CallNotification(ForkedCall31).AttachUrl＝https://<Call ControllerProcessing Instance>/<Id representing ForkedCall31>/Attach

c.对ForkedCall32类似

9.当用户B的端点中的任何一个端点附接(通过向在CallNotification中所接收的附接URL发送附接请求)，ForkedCall31/32的通话状态将被附加有作为AttachRequest(附接请求)的一部分接收的End URL(结束URL)。

10.作为AttachResponse(附接响应)的一部分，端点将获得与它们的 ForkedCall(支路通话)相对应的链接。例如，针对ForkedCall31的Accept URL(接受URL)将看起来象

a.https://<call Controller Processing Instance>/<Id representingForkedCall31>/Accept

11.假定ForkedCall31被接受(通过向与ForkedCall31相对应的接受URL 发送CallAcceptance消息)：

a.该接受消息包含针对通话中链接的回拨URL(例如，媒体重新协商、传输等)；

b.在接收到CallAcceptance消息之后，通话控制器将创建对象 UserBFacingAcceptedCallCallbackHandler(用户B面对经接受的通话回拨句柄)，其具有作为其状态的用户B的端点供应的URL。该对象暴露了以下方法：

i.RenegotiateMedia()——其使用媒体重新协商url来将 ediaRengotiation(媒体重新协商)消息发送回用户B

ii.transfer()，其使用传输url来将传输消息发送回用户B；

12.ForkedCall31.Accept()产生了UserBFacingAcceptedCall(用户B面对经接受的通话)，其具有以下特性：

a.状态：

i.对UserBFacingAcceptedCallCallbackHandler的引用；

ii.对在ForkedCall2.Accept()被调用时作为ForkedCall31.Accept() 的一部分所产生的AccetptedCall2对象的引用；

b.方法：

i.HandleMediaRenegotiation()——其调用回拨句柄的 RenegotiateMedia()；

ii.HandleTransfer()——其调用回拨句柄的Transfer()；

iii.RenegotiateMedia()——其调用

AcceptedCall2.RenegotiateMedia()。这是当用户B通过发送目标是UserBFacingAcceptedCall对象的媒体重新协商消息而开始媒体重新协商时所调用的方法；

iv.Transfer()——其调用AcceptedCall2.Transfer()。这是当用户B通过发送目标是UserBFacingAcceptedCall对象的传输消息而开始传输时所调用的方法；

13.如在上文中所提及的，ForkedCall31.Accept()也调用 ForkedCall2.Accept()，其创建了具有以下特性的AcceptedCall2：

a.状态：

i.对UserBFacingAcceptedCall的引用；

ii.对当ForkedCall1.Accept()被调用时作为ForkedCall1.Accept()的一部分所产生的AcceptedCall1对象的引用；

b.方法：

i.与UserBFacingAcceptedCall相同；

14.类似地，ForkedCall2.Accept()也调用ForkedCall1.Accept()，其创建具有以下特性的AcceptedCall1：

a.状态：

i.对AcceptedCall2的引用；

ii.对当Call0.Accept()被调用时作为Call0.Accept()的一部分所产生的UserAFacingAcceptedCall对象的引用；

b.方法：

i.与其他的AcceptedCall对象相同。

15.ForkedCall1.Accept()还调用Call0.Accept()，其创建具有以下特性的UserAFacingAcceptedCall：

a.状态：

i.对AccetpedCall1的引用；

ii.对当用户A利用其通话中回拨URL来发送

CallAcceptanceAckowlegement时所创建的

UserAFacingAcceptedCallCallbackHandler的引用；

b.方法：

i.与其他AcceptedCall对象相同。

16.Call0.Accept()还调用在接受URL上发送CallAcceptance消息的 UserAFacingCallbackHandler.Accept()

17.在接收CallAcceptance之后，用户A的端点发送具有通话中回拨URL 的CallAcceptanceAckowlegement消息。

18.通话控制器创建具有作为状态的这些回拨URL以及具有以下方法的 UserAFacingAcceptedCallCallbackHandler：

a.RenegotiateMedia()，其使用媒体重新协商url来将mediaRengotiation 消息发送回用户A；

b.Transfer()，其使用传输url来将传输消息发送回用户A。

在图16中示出了针对活动通话而被生成的运行时图表1600。运行时图表1600是针对这样的通话的活动通话状态，所述通话在其在处理器能够直接访问的存储器中实现的意义上是活动的。

用户A执行的任何通话中操作引起在UserAFacingAcceptedCall上调用合适的方法。

例如，由用户A触发的媒体重新协商将引起以下顺序的对象调用：

UserAFacingAcceptedCall.RenegotiateMedia()-﹥

AcceptedCall1.HandleMediaRenegotiation()-﹥

AcceptedCall2.HandleMediaRenegotiation()-﹥

UserBFacingAcceptedCall.HandleMediaRenegotiation()-﹥

UserBFacingAcceptedCallCallbackHandler.RenegotiateMedia()-﹥

在由用户B所发送的MediaRenegotiation回拨URL上发送媒体重新协商消息。

类似地，用户B执行的任何通话中操作引起了在 UserBFacingAcceptedCall上调用合适的方法。

例如，由用户B触发的媒体重新协商将引起以下操作：

UserBFacingAcceptedCall.RenegotiateMedia()-﹥

AcceptedCall2.HandleMediaRenegotiation()-﹥

AcceptedCall1.HandleMediaRenegotiation()-﹥

UserAFacingAcceptedCall.HandleMediaRengotiation()-﹥

UserFacingAcceptedCallCallbackHandle.RenegotiateMedia()-﹥

在由用户A所发送的MediaRenegotiation回拨URL上发送媒体重新协商消息。

为了确保任何通话中操作可以在任何实例上执行，我们需要确保整个运行时状态图表可以在任何实例上被恢复。

这意味着，针对接受通话的对象图表应该以在上文中所描述的方式被序列化并且被存储到到高度可用的外部存储中。

一旦转换到合适的形式，则可以通过跟随从任何对象开始的引用链来恢复图表的合适的部分(在上文的示例中，我们可以从 UserFacingAcceptedCall开始、或者从UserBFacingAcceptedCall开始)。

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

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

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

根据第一方面，一种用于经由通信网络在客户端设备的用户和另一客户端设备的另一用户之间建立实时通信事件的方法。所述方法包括在所述客户端设备上运行的客户端执行以下操作：通过经由所述网络向所述另一客户端设备或向连接至所述网络的服务器发送消息来执行通信事件建立过程的第一阶段。所述消息包括与还未执行的所述通信事件建立过程的第二阶段相关的多个选项。所述消息针对所述多个选项中的每个选项而包括对所述选项唯一的不同的网络地址，所述不同的网络地址能够被访问以选择所述选项。所述方法还包括：检测到已经访问了对所述多个选项中的一个选项唯一的上所述网络地址；并且作为响应，根据所述多个选项中的所述一个选项而发起所述通信事件建立过程的所述第二阶段。

在第一实施例中，所述消息被发送至所述服务器，所述方法包括所述服务器执行以下操作：存储对所述多个选项中的所述一个选项唯一的所述网络地址与服务器网络地址之间的映射；将所述服务器网络地址发送至所述另一客户端设备或者发送至连接至所述网络的另外的服务器；检测到已经访问了所述服务器网络地址；并且作为响应，访问对所述多个选项中的所述一个选项唯一的所述网络地址，其中所述访问是由所述客户端检测到的以便触发第一方面的发起步骤。在第二实施例中，所述方法还包括所述另外的服务器执行以下操作：存储所述服务器网络地址与另外的服务器网络地址之间的另一映射；将所述另外的服务器网络地址发送至所述另一客户端设备或者发送至又一服务器；检测到已经访问了所述另外的服务器网络地址；并且作为响应，访问所述服务器网络地址，其中所述访问是由所述服务器所检测到的以便触发第一实施例的访问步骤。

在第三实施例中，所述消息被发送至所述向服务器，并且所述方法包括：针对每个网络地址，所述服务器存储所述网络地址与对应的服务器网络地址之间的映射、修改所述消息以用所述对应的服务器网络地址来替代所述网络地址、并且将经修改的消息发送至所述另一客户端设备或者发送至连接至所述网络的另外的服务器；所述服务器检测到已经访问了与对所述多个选项中的所述一个选项唯一的所述网络地址相对应的服务器网络地址；以及作为响应，所述服务器访问对所述多个选项中的所述一个选项唯一的所述网络地址，其中所述访问是由所述客户端检测到的以便触发第一方面的所述发起步骤。在第四实施例中，对应的网络地址被发送至所述另外的服务器，并且所述方法包括：所述另外的服务器存储所述对应的网络地址与另外的对应的服务器网络地址之间的另一映射、进一步修改所述消息以用另外的对应的网络地址来替代所述对应的服务器网络地址、并且将经进一步修改的消息发送至所述另一客户端设备或者发送至连接至所述网络的又一服务器；所述另外的服务器检测到已经访问了与所述服务器网络地址相对应的所述另外的服务器网络地址，其中，所述服务器网络地址与对所述多个选项中的所述一个选项唯一的所述网络地址相对应；以及作为响应，所述另外的服务器访问与对所述多个选项中的所述一个选项唯一的所述网络地址相对应的所述服务器网络地址，其中所述访问是由所述服务器所检测到的以便触发第三实施例的所述访问步骤。

可以在客户端设备和代理服务器之间建立连接，网络地址是代理服务器的；第一方面的检测步骤可以包括所述客户端检测到经由所述连接所接收的信号，所述信号指示已经访问了对所述多个选项中的所述一个选项唯一的所述网络地址。所述连接可以是WebSocket连接。

网络地址可以是URI，例如URL。对所述多个选项中的一个选项唯一的网络地址可以根据HTTP协议来访问，例如使用POST或DELETE请求方法。

根据第二方面，一种用于经由通信网络而在客户端设备的用户与另一客户端设备的另一用户之间实现实时通信事件的服务器。所述服务器包括：计算机存储；网络接口，其被配置为从所述网络接收消息；处理器，其被配置为：接收消息，所述消息包括与通信事件有关的多个选项，并且针对所述多个选项中的每个选项而包括对所述选项唯一的不同的网络地址，所述不同的网络地址能够被访问以选择所述选项；针对多个网络地址中的每个网络地址，将所述网络地址与对应的服务器网络地址之间的映射存储在所述计算机存储中；将所述服务器网络地址发送至所述另一客户端设备或者发送至连接至所述网络的另外的服务器；以及检测到与对所述多个选项中的所述一个选项唯一的所述网络地址相对应的所述服务器网络地址已经被访问，并且作为响应来访问对所述选项唯一的所述网络地址以选择所述选项。

所述处理器可以被配置为将所述消息记录在计算机存储中。

所述处理器可以被配置为将一段时间的通信事件记录在计算机存储中。

所述消息可以被发送至另外的服务器，以便使得所述另外的服务器作为响应而执行与所述通信事件相关的动作。所述处理器可以被配置为：接收与所述通信事件相关的另一消息，所述消息包括另一选项，该选项与所述通信事件的另一选项和可以访问以选择另一选项的、对该选项唯一的另一网络地址相关；将在所述另一网络地址和另一对应的服务器网络地址之间的另一映射存储在计算机存储中；并且向与所述另外的服务器不同的所述网络的另一服务器发送所述另一对应的网络地址，以使得所述另一服务器执行与所述通信事件相关的另一动作。

网络地址和所述(另外)服务器网络地址可以是URI，例如URL。可以根据HTTP协议来访问对所述多个选项中的一个选项唯一的网络地址。

根据第三方面，一种用于传递服务的方法，所述方法是由计算机系统实现的，所述计算机系统包括处理器、能够由所述处理器访问的存储器、以及计算机存储。所述存储器保存定义服务对象类的代码。服务对象类被配置为提供服务功能。该方法包括以下步骤。接收至少一个服务发起消息。响应于所述至少一个服务发起消息，所述服务对象类被实例化以创建服务对象。所述服务对象实现所述服务功能以传递所述服务。每个服务对象具有保存在所述存储器中的相关联的状态数据，并且所述服务对象中的至少一些服务对象引用其他服务对象。针对每个服务对象，在存储器中生成相关联的服务对象标识符，所述服务对象标识符对所述服务对象与任何其他服务对象进行区分。服务对象被序列化以生成经序列化的数据，所述经序列化的数据包括对每个服务对象的表示，并且所述表示包括所述服务对象的服务对象标识符，所述服务对象的相关联的状态数据、以及由所述服务对象所引用的任何其他服务对象的服务对象标识符。所述经序列化的数据被存储在所述计算机存储器中。当所述服务对象已经被去激活时，接收到标识服务对象被重新激活的服务重新激活消息，并且针对所标识的服务对象而执行重新激活过程。所述重新激活过程包括：从其以所述经序列化的数据的表示重新激活所述经标识的服务对象，并且如果所述经标识的服务对象引用实现服务功能所需的至少一个服务对象，则针对所引用的至少一个服务对象而重复所述重新激活过程，由此创建服务对象的替代组以替代经去激活的服务对象中的至少一些服务对象。

在实施例中，所述方法可以用于在通信网络的端点之间建立通信事件，并且用于管理所建立的通信事件；所述服务请求消息是通信事件建立请求，并且所述服务对象被创建以建立通信事件；所述服务重新激活消息请求与所述所建立的通信事件相关的动作，并且服务对象的所述替代组实现所请求的动作。

所述动作可以例如是：

-终止所述通信事件；

-向所述通信事件添加参与者/从所述通信事件移除参与者；

-将所述通信事件的参与者静音或取消静音；

-将所述通信事件暂停；

-向所述通信事件添加媒体模态/从所述通信事件移除媒体模态。

所述通信事件可以是通话。

所述代码可以定义针对每个服务对象类的对应的工厂对象类，每个工厂对象类被配置为提供服务对象重新激活功能以用于从在所述经序列化的数据中的所述表示来创建所述服务对象类的服务对象，所述方法可以包括：

针对每个服务对象类，将所述对应的工厂对象类实例化以生成对应的工厂对象，所述对应的工厂对象被配置为实现由所述工厂对象类所提供的所述服务对象重新激活功能；

针对每个工厂对象，在所述存储器中生成相关联的工厂对象标识符，所述工厂对象标识符将所述工厂对象与任何其他工厂对象进行区分；

对每个服务对象的所述表示还可以包括与所述服务对象的服务对象类相对应的所述工厂对象的所述工厂对象标识符；

所述服务重新激活消息标识与所述经标识的服务对象的服务对象类相对应的工厂对象，其中，针对所述经标识的服务对象而执行所述重新激活过程可以包括：

经标识的对应的工厂对象在所述经标识的服务对象的所述经序列化的数据中的表示上实现其服务对象重新激活功能以重新激活所述经标识的服务对象。

所述代码可以定义被配置为提供获取对象函数的引用对象类，并且所述方法包括：针对每个服务对象：将持续型对象引用类实例化以生成对应的引用对象，所述对应的应用对象具有保存在存储器中的相关联的状态数据，所述相关联的状态数据不包括指向所述存储器中的任何单元的任何存储器指针，但是包括所述服务对象的所述服务对象标识符；针对所述至少一个服务对象的所述重新激活过程在所述引用对象已经被去激活时被执行，并且包括：使用在所述至少一个服务对象的表示中的所述服务对象标识符来重新激活与所述至少一个服务对象相对应的所述引用对象；当在经重新激活的引用对象上被调用时，所述获得对象函数被配置为从所述至少一个服务对象的所述表示重新激活所述至少一个服务对象，并且所述至少一个服务对象是通过在所述经重新激活的以用对象上调用所述获得对象函数而被重新激活的。

获得对象功能可以被配置为，当在至少一个服务对象已经被去激活之前在重新激活的引用对象上再次被调用时，返回存储器指针以重新激活的至少一个服务对象，由此仅仅创建单个替代服务来替代至少一个服务对象。

针对所述服务对象中的至少一些服务对象中的每个服务对象，可以生成包括所述服务对象的相关联的服务对象标识符的相关联的网络地址，并且所述服务重新激活消息是在与将被重新激活的服务对象相关联的网络地址处接收的，所述服务对象将被重新激活是从所述网络地址识别的。

每个网络地址可以是URI(例如，URL)，并且所述方法可以包括解析与要被重新激活的服务对象相关联的URI，以识别所述服务要被重新激活。

所述方法可以包括包括缓存指向每个经重新激活的服务对象的相应的存储器指针，其中，如果所述重新激活过程是针对已经被重新激活的服务对象并且是在所述已经被重新激活的服务对象被重新激活之前被执行的，则所述重新激活过程返回指向所述已经被重新激活的服务对象的存储器指针，由此，仅仅创建单个相应的替代服务对象来替代每个经重新激活的服务对象。

所述服务发起消息是由所述代码的实例接收的，其中，所述实例执行接收、实例化、生成、序列化、和存储的步骤；所述服务重新激活消息是由所述代码的另一实例接收的，并且所述另一实例执行所述重新激活过程。

所述服务重新激活消息是由所述代码的实例接收的，并且所述实例访问数据库以确定其是否包含将所述代码的另一实例标识为当前拥有所述经序列化的数据的有效的拥有权条目，并且：

如果包含，则所述实例将所述服务重新激活消息转发至所述另一实例以使得所述另一实例执行所述重新激活过程，而

如果不包含，所述实例在所述数据库中创建将所述实例标识为当前拥有所述经序列化的状态数据的有效的拥有权条目，并且所述实例执行所述重新激活过程。

当从所述拥有权条目被创建开始已经过了预先确定的量的时间时，每个拥有权条目变得无效。每个实例被配置为周期性地向所述数据库写入有效的心跳消息，所述心跳消息将所述实例标识为当前是活动的，当从所述心跳消息被创建开始已经过了预先确定的量的时间时，每个心跳消息变得无效，其中，每个拥有权条目只有在其标识的实例也由有效的心跳消息标识为是活动的的情况下采是有效的，以使得所述服务重新激活消息只有在所述另一实例由有效的心跳消息标识为是活动的的情况下才被转发至所述另一实例。

所述经序列化的数据是在所述存储器中生成的，并且通过在所有服务对象已经被序列化时执行单个写操作而从所述存储器写至所述计算机存储。

响应于接收到所述重新激活消息，创建所述服务对象的替代组所需要的所有状态数据通过执行单个写操作而从所述计算机存储被加载在所述存储器中或者能够由所述计算机系统的另一处理器访问的另一存储器中，并且所述替代组是从加载在所述存储器或所述另一存储器中的所述经序列化的数据而创建的。

根据第四方面，计算机系统包括：被配置为接收消息的输入端；计算机存储；处理器；能够由所述处理器访问的存储器。所述存储器保存定义服务对象类的代码，所述服务对象类被配置为提供服务功能。所述处理器被配置为响应于至少一个服务发起消息而执行以下操作：

将所述服务对象类实例化以创建服务对象，所述服务对象实现所述服务功能以传递所述服务，每个服务对象具有保存在所述存储器中的相关联的状态数据，所述服务对象中的至少一些服务对象引用其他服务对象；

针对每个服务对象，在存储器中生成相关联的服务对象标识符，所述服务对象标识符将所述服务对象与任何其他服务对象进行区分；

将服务对象序列化以生成经序列化的数据，所述经序列化的数据包括对每个服务对象的表示，所述表示包括所述服务对象的服务对象标识符、所述服务对象的相关联的状态数据、以及由所述服务对象所引用的任何其他服务对象的服务对象标识符；以及

将所述经序列化的数据存储在所述计算机存储器中。

当所述服务对象已经被去激活时并且响应于标识将被重新激活的服务对象的服务重新激活消息，所述计算机系统的所述处理器或另一处理器被配置为针对经标识的服务对象而执行重新激活过程，包括：

从其在所述经序列化的数据中的表示来重新激活所述经标识的服务对象，并且

如果所述经标识的服务对象引用实现服务功能所需的至少一个服务对象，则针对所引用的至少一个服务对象而重复所述重新激活过程

由此创建服务对象的替代组以替代经去激活的服务对象中的至少一些服务对象。

所述计算机系统可以是云平台，由此所述处理器和所述另一处理器各自被配置为运行多个虚拟机，其中，所述代码的实例在所述多个虚拟机中的每个虚拟机上运行。

所述代码被配置为实现通话控制器以用于在通信网络的端点之间建立通信事件并且用于管理所建立的通信事件，其中，所述服务请求消息是通信事件建立请求，而所述服务对象由所述通话控制器的实例创建以用于建立通信事件；例如：

所述服务重新激活消息是由所述通话控制器的所述实例或另一实例接收的；

或者所述代码还被配置为实现媒体控制器以用于管理所述所建立的通信事件的媒体模态，并且所述服务重新激活消息是由所述媒体控制器的实例接收的；

在任何一种情况中，所述服务重新激活消息请求与所述所建立的通信事件相关的动作，并且服务对象的所述替代组实现所请求的动作。

根据第五方面，计算机程序产品包括代码，所述代码被存储在计算机可读存储介质上，并且被配置为当被执行时实现在本文中所公开的方法和系统中的任何方法和系统，包括第一和第三方面的方法，第二方面的服务器的功能，以及第四方面的计算机系统。

尽管已经用于特定于结构特征和/或方法动作的语言描述了本主题，但是应当理解的是，在所附权利要求中所定义的主题并不一定限于在上文中所描述的具体的特征或动作。相反，在上文中所描述的具体的特征和动作是作为实现权利要求的示例性形式而公开的。

Claims (15)

1.一种用于经由通信网络在作为第一客户端设备的用户的呼叫者与作为另一第二客户端设备的另一用户的被叫者之间建立实时通信事件的方法，所述方法包括：

通过经由所述网络向所述第二客户端设备或向连接至所述网络的服务器发送消息来执行通信事件建立过程的第一阶段，所述消息包括与还未执行的所述通信事件建立过程的第二阶段相关的多个选项；

其中，所述消息针对所述多个选项中的每个选项而包括对所述选项唯一的不同的网络地址，所述不同的网络地址能够被访问以选择所述选项，并且所述方法还包括：

经由来自所述服务器的通知，检测到对所述多个选项中的一个选项唯一的哪个网络地址已经被所述第二客户端设备访问；并且

作为响应，根据所述多个选项中的所述一个选项而发起所述通信事件建立过程的所述第二阶段。

2.根据权利要求1所述的方法，其中，所述消息被发送至所述服务器，所述方法包括所述服务器执行以下操作：

存储对所述多个选项中的所述一个选项唯一的所述网络地址与服务器网络地址之间的映射；

将所述服务器网络地址发送至所述第二客户端设备或者发送至连接至所述网络的另外的服务器；

检测到已经访问了所述服务器网络地址；并且

作为响应，访问对所述多个选项中的所述一个选项唯一的所述网络地址，其中所述访问是由所述第一客户端设备检测到的以便触发发起所述通信事件建立过程的所述第二阶段。

3.根据权利要求2所述的方法，包括所述另外的服务器执行以下操作：

存储所述服务器网络地址与另外的服务器网络地址之间的另一映射；

将所述另外的服务器网络地址发送至所述第二客户端设备或者发送至又一服务器；

检测到已经访问了所述另外的服务器网络地址；并且

作为响应，访问所述服务器网络地址，其中所述访问是由所述服务器所检测到的以便触发访问所述网络地址。

4.根据权利要求1所述的方法，其中，所述消息被发送至所述服务器，并且所述方法包括：

针对每个网络地址，所述服务器存储所述网络地址与对应的服务器网络地址之间的映射、修改所述消息以用所述对应的服务器网络地址来替代所述网络地址、并且将经修改的消息发送至所述第二客户端设备或者发送至连接至所述网络的另外的服务器；

所述服务器检测到已经访问了与对所述多个选项中的所述一个选项唯一的所述网络地址相对应的服务器网络地址；以及

作为响应，所述服务器访问对所述多个选项中的所述一个选项唯一的所述网络地址，其中所述访问是由所述第一客户端设备检测到的以便触发发起所述通信事件建立过程的所述第二阶段。

5.根据权利要求4所述的方法，其中，对应的网络地址被发送至所述另外的服务器，并且所述方法包括：

所述另外的服务器存储所述对应的网络地址与另外的对应的服务器网络地址之间的另一映射、进一步修改所述消息以用另外的对应的网络地址来替代所述对应的服务器网络地址、并且将经进一步修改的消息发送至所述第二客户端设备或者发送至连接至所述网络的又一服务器；

所述另外的服务器检测到已经访问了与所述服务器网络地址相对应的所述另外的服务器网络地址，其中，所述服务器网络地址与对所述多个选项中的所述一个选项唯一的所述网络地址相对应；以及

作为响应，所述另外的服务器访问与对所述多个选项中的所述一个选项唯一的所述网络地址相对应的所述服务器网络地址，其中所述访问是由所述服务器所检测到的以便触发访问所述网络地址。

6.根据权利要求1所述的方法，其中，在所述第一客户端设备与代理服务器之间建立连接，所述网络地址是所述代理服务器的，其中，权利要求1的检测步骤包括所述第一客户端设备检测到经由所述连接所接收的信号，所述信号指示已经访问了对所述多个选项中的所述一个选项唯一的所述网络地址。

7.根据权利要求1所述的方法，其中，所述网络地址是URI。

8.根据权利要求7所述的方法，其中，对所述多个选项中的所述一个选项唯一的所述网络地址是根据HTTP协议来访问的。

9.一种用于经由通信网络而在作为第一客户端设备的用户的呼叫者与作为另一第二客户端设备的另一用户的被叫者之间实现实时通信事件的服务器，所述服务器包括：

计算机存储；

网络接口，其被配置为从所述网络接收消息；

处理器，其被配置为：

接收消息，所述消息包括与通信事件有关的多个选项，并且针对所述多个选项中的每个选项而包括对所述选项唯一的不同的网络地址，所述不同的网络地址能够被访问以选择所述选项；

针对多个网络地址中的每个网络地址，将所述网络地址与对应的服务器网络地址之间的映射存储在所述计算机存储中；

将所述服务器网络地址发送至所述第二客户端设备或者发送至连接至所述网络的另外的服务器；以及

检测到与对所述多个选项中的一个选项唯一的所述网络地址相对应的所述服务器网络地址已经被所述第二客户端设备或者所述服务器访问，并且作为响应来访问对所述选项唯一的所述网络地址以选择所述选项。

10.根据权利要求9所述的服务器，其中，所述处理器被配置为将所述消息记入在所述计算机存储中。

11.根据权利要求9所述的服务器，其中，所述处理器被配置为将一段时间的所述通信事件记录在所述计算机存储中。

12.根据权利要求9所述的服务器，其中，所述消息被发送至所述另外的服务器，以便使得所述另外的服务器作为响应而执行与所述通信事件相关的动作。

13.根据权利要求12所述的服务器，其中，所述处理器被配置为：

接收与所述通信事件相关的另一消息，所述另一消息包括与所述通信事件相关的另一选项以及对所述另一选项唯一的、能够被访问以选择所述另一选项的另一网络地址；

将所述另一网络地址与另一对应的服务器网络地址之间的另一映射存储在所述计算机存储中；以及

向与所述另外的服务器不同的所述网络的另一服务器发送所述另一对应的网络地址，以便使得所述另一服务器执行与所述通信事件相关的另一动作。

14.根据权利要求9所述的服务器，其中，所述网络地址和所述服务器网络地址是URI。

15.一种存储代码的计算机可读存储介质，所述代码被配置为当被执行时实现权利要求1至8中任何一项所述的方法或者实现权利要求9-14中任何一项所述的服务器的功能。

Images