CN102546622B

CN102546622B - 用于高度可扩展的分布式呼叫/媒体建模及控制架构的通信方法和系统

Info

Publication number: CN102546622B
Application number: CN201110455291.XA
Authority: CN
Inventors: 戈登·R·布鲁森; 乔尔·M·伊泽尔; 哈什·V·门迪拉塔; 欧文·D·威廉姆斯
Original assignee: Avaya Inc
Current assignee: Avaya Inc
Priority date: 2010-12-27
Filing date: 2011-12-27
Publication date: 2016-03-23
Anticipated expiration: 2031-12-27
Also published as: GB201122157D0; DE102011122179A1; US20120163571A1; CN102546622A; US8510435B2; GB2486981A; GB2486981B

Abstract

描述了一种高度可扩展的分布式呼叫/媒体建模及控制架构。特别是，提供了多个锚点服务器，其使得一个或多个应用程序即使在通信会话建立期间并未最初绑定到通信会话，也可以对正在进行的通信会话施加呼叫和媒体控制。

Description

用于高度可扩展的分布式呼叫/媒体建模及控制架构的通信方法和系统

技术领域

本发明一般涉及通信，更具体地涉及呼叫建模(callmodeling)与控制架构(controlframework)。

背景技术

计算机电话集成，也被称为计算机—电话机集成(Computer-TelephoneIntegration,CTI)，是允许电话机和计算机的交互可以集成或协调的技术。随着联系渠道从语音扩展到包括电子邮件，web和传真，CTI的定义已扩大到包括所有客户联系渠道(语音，电子邮件，web，传真等)与计算机系统的集成。

传统CTI系统提供了一种非常有用的逻辑呼叫模型和控制机制，但他们有几个重要的缺点。作为一个例子，现有的CTI系统通常是捆绑到一特定的专用分支交换(PBX)，因此受到该PBX所负责的用户/端点域的约束。由于CTI系统到PBX的紧密绑定，也很难设计地理冗余的解决方案。也难以利用单个PBX实现大规模解决方案(例如，支持数以千计的通信端点/用户)。此外，如果多个PBX被一起联网以用于规模或地理分布，则难以构建跨越多个PBX的呼叫的完整模型。再者，很少有CTI系统提供固有的媒体控制机制。大多数需要将应用媒体端点作为第三方明确添加到呼叫。最后，在高可用性方面，大多数的CTI系统受限于PBX提供的可用性。

发明内容

本发明中提供的实施例是关于上述问题及其他问题而构想的。本发明除其他事项外，提出了一种机制，使得能够创建有凝聚力的应用程序使能会话监视和/或控制系统。

在一些实施例中，通过锚点服务器的力量，去往和/或来自用户的呼叫将被定序到可能跨地理区域分布的一个或多个锚点服务器。每个用户一般将会至少具有在会话发起协议(SIP)定序级被指派给他们的首选锚点服务器和次选锚点服务器。当用户发出或收到呼叫时，他们的锚点服务器(无论是首选、次选、再次选，等等)被定序，并且锚点被建立。一旦建立了锚点，锚点就构造该呼叫上的参与者的逻辑呼叫模型。在一些实施例中，呼叫中的每个参与者将具有已设立的锚点，每个所述锚点独立地为该参与者进行呼叫建模。

在美国专利申请第12/783,224和12/783,249号中描述了关于锚点服务器、锚点、利用锚点的逻辑呼叫模型构造等等的另外细节，在本申请中将这两个申请整体合并作为参考。

在一些实施例中，在电话会议的情况下，应用程序将会看到远端实体包括指示出它是一会议焦点(conferencefocus)的参数(例如，SIP中的isfocus参数)。应用程序然后可以订阅针对该会议焦点的会议状态事件，从而构造用于该呼叫的完整的名册清单。每个锚点将会独立地针对呼叫状态事件进行订阅，并在呼叫中维护其自身的完整名册列表。在级联会议(即，哑铃会议(dumbellconference))的情况下，锚点将会看到会议参与者之一自身是焦点，并且随后将会去对该焦点进行订阅。

本发明的一个方面提供了统一的通信会话ID(CSID)。在一些实施例中，CSID在用于同一会话中彼此通信的用户的所有锚点服务器当中都是相同的。对于两方呼叫，这是较易完成的，因为它可以是包括在呼叫信令中不被中间实体修改的头部(例如，SIP的P-Charging-VectorICID)。对于电话会议，这变得有点更复杂。当两方呼叫升级为电话会议时，将把表示该电话会议的新的CSID(例如，SIP中的会议统一资源标识符(URI))通知给应用程序。但是，较旧的CSID也将会与该电话会议相关，从而应用程序可能继续发出针对该CSID的请求。

在一些实施例中，锚点服务器的第一端可包括呼叫建模、呼叫控制和媒体控制远程接口。该远程接口可被配置来将锚点服务器显露给一个或多个应用程序。该远程接口可以采取多种形式，包括SOAPweb服务，RESTweb服务，Bayeux，通过TCP的XML，等等。应用程序将利用客户端侧库，该客户端侧库将会处理协议细节，并处理用户到锚点服务器的映射。客户端侧库一般将会具有至少两个锚点服务器，这至少两个锚点服务器被作为其进入通信系统的第一联系点而供应。当应用程序发出请求时，其最经常在用户从端点发起呼叫或者对已设立的SIP对话采取某种动作的上下文中这样做。

如果库尚未具有给定用户到他们的(一个或多个)锚点服务器的映射，则它将会尝试把请求发送到第一联系点(即，第一锚点服务器)，并且如果该第一联系点对于该用户不是权威(authoritative)的，则得到重定向。该锚点服务器将会利用该用户的首选节点、次选节点、再次选节点(等等)来进行响应，并且库将会存储这些映射。在一些实施例中，所有这些的发生对于应用程序都是透明的。

一旦库具有了用户到他们的锚点服务器的映射，它就会将任何呼叫创建请求发送到该用户的首选锚点服务器(如果活动的话)。如果首选锚点服务器不活动，则请求将发送到次选，等等。

必须考虑的一种特殊情况是应用程序针对给定用户的通信事件进行订阅的情况。在该情况下，存在处理活动-活动冗余的两种可能性。

在第一种可能性中，客户端侧库可以将订阅广播到用户的所有首选锚点服务器和备份锚点服务器，从而如果通过基础设施将任何SIP消息路由到了这些服务器，这些服务器能够将事件发送到该应用程序和/或客户端侧库。在锚点服务器故障的情况下，客户端侧库将会在该锚点服务器恢复时自动重订阅。

在第二种可能性中，库可以仅将订阅发送到首选锚点服务器(或排名最高的活动服务器)，并且该订阅将会是锚点服务器之间最小共享状态的一部分。在此情况下，锚点服务器恢复之后的客户端侧库的重订阅就不必要了。

在这些情况的一个子集中，不是在用户的上下文中发出请求，而是在CSID的上下文(例如，针对呼叫中所有参与者的查询，或将用户添加到呼叫)中发出请求。在这些情况下，仍将请求定向到具有用于该CSID的锚点和呼叫模型的锚点服务器。如果最初将请求定向到未对该CSID建模的锚点服务器，则该最初联系的锚点服务器将会查询其他所有锚点服务器以发现哪个锚点服务器拥有该CSID，并将会把应用程序重定向到该锚点服务器。这防止了锚点服务器必须不断共享任何每呼叫数据，并将会保持足够的性能，这是因为这类请求的使用一般将会是有限的。或者，可以将一CSID上的活动锚点服务器的身份编码在CSID自身当中。理想的实现方式可以是使用这些机制二者：在被编码的锚点服务器从呼叫中挂断(例如，转移)的情况下，广播查询可以是后援机制。

应当指出，解决方案不必依赖于任何呼叫特征服务器或PBX。

在一些实施例中，本申请中描述的体系结构是用于活动-活动高可用性模型的。在此体系结构中，次选、再次选等等的锚点服务器不是空闲服务器。相反，它们对于一组用户是活动的，同时为其他组用户的故障情境预留了未使用容量。

在一些实施例中，提供了一种方法，该方法一般包括：

在应用程序处接收关于一用户的现有通信会话或涉及该用户的下一通信会话的、利用该应用程序所提供的一个或多个特征的请求；

通过所述应用程序，向一个或多个锚点服务器发送接收来自锚点服务器的关于通信会话的事件信息的请求；以及

在所述应用程序与第一锚点服务器之间设立通信链路，以使得所述应用程序能够进行以下操作中的至少一项操作：通过所述通信链路发送用于通信会话的控制信号，以及通过所述通信链路接收关于通信会话的事件信息。

在一些实施例中，提供了一种通信系统，该通信系统一般包括：

第一锚点服务器，该第一锚点服务器被配置来在一个或多个通信会话中至少设立第一锚点；

第二锚点服务器，该第二锚点服务器被配置来在一个或多个通信会话中至少设立第二锚点；

在应用程序服务器上运行的应用程序，该应用程序被配置来利用所述第一锚点服务器和所述第二锚点服务器中的一者或两者来对通信会话施加呼叫控制和媒体控制中的至少一种。

短语“至少一个”，“一个或多个”，以及“和/或”是开放式的表述方式，它们在作用上既是连结性的，又是分离性的。例如，表达方式“A，B和C中至少一个”、“A，B或C中至少一个”、“A，B和C中一个或多个”、“A，B或C中一个或多个”以及“A，B和/或C”中每一个都意味着只有A、只有B、只有C、A和B一起、A和C一起、B和C一起，或者A、B和C一起。

术语“一”实体指一个或多个该实体。这样，术语“一”、“一个或多个”和“至少一个”在本申请中可互换使用。还应该指出，术语“包括”、“包含”和“具有”可互换使用。

在本申请中使用的术语“自动”及其变体指如下的处理或操作：该处理或操作的执行是在没有实质的人工输入的情况下完成的。但是，即使处理或操作的执行使用了实质的或非实质的人工输入，如果该输入是在该处理或操作执行之前接收到的，则该处理或操作也可以是自动的。如果人工输入影响了该处理或操作的执行方式，则此类输入被认为是实质的。同意处理或操作执行的人工输入不被认为是“实质的”。

本申请中使用的术语“计算机可读介质”，是指任何参与向处理器提供指令以供执行的有形介质。这种介质可能采取多种形式，包括但不限于非易失性介质，易失性介质和传输介质。非易失性介质例如包括NVRAM，或磁盘或光盘。易失性介质包括动态存储器，如内存。计算机可读介质的常见形式例如包括软盘，柔性盘(flexibledisk)，硬盘，磁带，或任何其他的磁介质，磁光介质，CD-ROM，任何其他光介质，打孔卡，纸带，具有孔图案的任何其他物理介质，RAM，PROM和EPROM，FLASH-EPROM，像存储卡这样的固态介质，任何其他的存储芯片或墨盒，或计算机可读的任何其他介质。当计算机可读介质被配置为数据库时，应当了解数据库可以是任何类型的数据库，如关系型，层次型，面向对象的，和/或类似物。因此，本发明被认为是包括有形存储介质和现有技术认可的等同物和后来的介质，其中存储了本发明的软件实现方式。

本申请中使用的术语“确定”，“计算”，“演算”及其变体是互换使用的，并包括任何类型的方法，处理，数学运算或技术。

本申请中使用的术语“模块”是指任何已知的或以后开发的的硬件，软件，固件，人工智能，模糊逻辑，或硬件和软件的组合，其能够执行与该元素相关的功能。另外，尽管按照范例实施例描述了本发明，但应当认识到可以单独要求保护本发明的各个方面。

附图说明

结合附图描述本发明：

图1是根据本发明实施例的通信系统的框图；

图2是描绘根据本发明实施例的通信系统元件的第一配置的框图；

图3是描绘根据本发明实施例的通信系统元件的第二配置的框图；

图4是描绘根据本发明实施例的支持共享锚点服务器的两个用户之间的通信会话的通信系统元件的配置的框图；

图5是描绘根据本发明实施例的不支持共享锚点服务器的两个用户之间的通信会话的通信系统元件的配置的框图；

图6是描绘根据本发明实施例的支持三个或更多用户之间的会议通信会话的通信系统元件的配置的框图；

图7是描绘根据本发明实施例的应用程序到锚点服务器绑定处理的流程图；

图8是描绘根据本发明实施例的通过锚点监视用户呼叫活动的应用程序的呼叫信令示图；并且

图9是描绘根据本发明实施例的利用CSID使应用程序能代表通信会话的多个用户进行操作的处理的流程图。

具体实施方式

下面将结合一示例性的通信系统说明本发明。虽然本发明非常适合例如与使用(一个或多个)服务器和/或(一个或多个)数据库的系统一起使用，但本发明不局限于与任何特定类型的通信系统或系统元件的配置一起使用。本领域技术人员会认识到，所公开的技术可用于希望利用锚点的任何通信应用中。

本发明的范例系统和方法也将与分析软件、模块和相关分析硬件相关地描述。然而，为了避免不必要地掩盖了本发明，下面的描述省略众所周知的结构、组件和装置，它们可能以框图的形式示出，是众所周知的，或以其他方式概述。

为了说明的目的，阐述了许多的细节，以提供对本发明的透彻理解。然而，应该认识到，除了本申请所阐述的具体细节之外，可以多种方式实现本发明。

图1描绘了根据本发明实施例的通信系统100。通信系统100可包括企业网络104，该企业网络104通过(通常不受信任的或不安全的或公共的)通信网络108与一个或多个外部通信装置112进行通信。外部通信装置112通常被称为“外部”，这是因为它们要么不在管理企业网络104的企业的直接控制下，要么与企业网络104内的通信装置136相比，与企业网络104的信任水平较低。范例外部通信装置112类型包括但不限于蜂窝电话，笔记本电脑，个人计算机(PC)，个人数字助理(PDA)，数字电话，模拟电话，等等。

通信网络108可以是分组交换和/或电路交换的。范例通信网络108包括但不限于广域网(WAN)(如因特网)，公共交换电话网(PSTN)，普通老式电话服务(POTS)网络，蜂窝通信网络，或其组合。在一个配置中，通信网络108是支持TCP/IP协议组的公共网络。

企业网络104可包括以下部件：边界装置116，其包括服务器表120；通信服务器124，其包括呼叫特征定序器128和用户表132；一个或多个内部通信装置136；锚点服务器140；一个或多个应用程序服务器144，其能够提供一个应用程序148或一组不同的应用程序152；多个其他服务器156；以及企业数据库160，所有这些都通过(受信任的或安全的或私有的)局域网(LAN)164互连。图1描绘的部分或全部的功能可以共同容宿和/或共同驻留在一台服务器上。图1对组件的描绘一般希望是对于系统100组件的逻辑描述。

LAN164可以通过位于LAN164和通信网络108之间的网关和/或防火墙防御不受信任的各方的入侵。在一些实施例中边界装置116可包括网关和/或防火墙的功能。在一些实施例中，可将单独的网关或防火墙设在边界装置116和通信网络108之间。

通信服务器124可以包括专用分支交换机(PBX)，企业交换机，企业服务器，其组合，或其他类型的电信系统交换机或服务器。通信服务器124优选地被配置来执行电信功能，如阿瓦雅公司的AvayaAura^TM应用程序组，其包括CommunicationManager^TM，AvayaAuraCommunicationManager^TM，AvayaIPOffice^TM，CommunicationManagerBranch^TM，SessionManager^TM，SystemManager^TM，MultiVantageExpress^TM，及其组合。

虽然图1中只描绘了单个通信服务器124，但在单个企业网络104中或跨多个不同的局域网164可设置两个或更多的通信服务器124，所述多个不同的局域网164由一个企业拥有和经营，但通过通信网络108分开。在企业或企业网络104包括两个或更多的通信服务器124的配置中，每台服务器124可能包括类似的功能，但可被设置为仅将其特征提供给所有企业用户的一个子集。尤其是，第一通信服务器124可作为企业用户的第一子集的权威并为之提供服务，而第二通信服务器124可作为企业用户的第二子集的权威并为之提供服务，其中用户的所述第一子集和第二子集通常不共享共同的用户。这是网络边界装置116可设有与服务器表120的原因之一。对于锚点服务器140也是如此。

此外，多台服务器124可以支持一个共同的用户社区。例如，在用户不一定绑定到单个应用程序服务器的地理冗余的其他应用中，可能存在等效服务器的集群，其中用户可从集群中的任何服务器获得服务。

根据本发明的至少一些实施例，通信请求中的用户身份的映射并不一定发生在网络边界装置116处。举例来说，一权威的服务器和一用户之间的映射可能会发生在企业网络104内的网络边界装置116“背后”。

在一些实施例中，网络边界装置116负责最初将企业网络104内的通信路由到负责为通信所涉及的特定用户提供服务的通信服务器124。例如，如果外部通信装置112正呼叫第一企业用户，则网络边界装置116最初可接收传入呼叫，判断该呼叫是朝着第一企业用户，参考服务器表120识别用于该第一企业用户的权威通信服务器124，并将传入呼叫路由到该权威通信服务器124。同样，内部企业用户(例如，内部通信装置136)之间的通信可能在通信建立的始发阶段首先由始发端用户的权威通信服务器124提供服务。始发阶段完成后，可调用终止端(或被叫)用户的权威通信服务器124以完成通信建立的终止阶段。在一些实施例中，用于始发端和终止端用户的通信服务器124可能是相同的，但是这不是必需的。在通信会话中涉及多于两个的企业用户的情况下，可采用用于每个所涉及用户的权威通信服务器124而不偏离本发明的范围。此外，用于每个用户的权威通信服务器124可在同一企业网络104，或在不同的企业网络104中，所述不同的企业网络104由一个共同的企业拥有，但通过通信网络108分开。

每个通信服务器124包括特征定序器128和用户表132。用于通信服务器124的用户表132包含以其为权威的每个用户的通信偏好。特别是，用户表132可由用户和/或管理人员设置。定序器128参考特定用户的通信偏好，以确定应将哪些特征(如果有的话)(例如，应用程序148、152)纳入到用户的通信会话中。定序器128可以实际直接将通信特征提供到通信会话中，或者定序器128可以确定将在建立期间调用和在通信会话期间使用的应用程序序列。

根据至少一些实施例，特征定序器128可确定应用程序序列并使一个或多个应用程序148，152被定序到通信会话中。特别是，特征定序器128被配置来分析特定用户的通信偏好，并调用必要的应用程序以满足这种偏好。一旦特征定序器128确定了应用程序序列，通信服务器124就将通信设立消息传递到该应用程序序列中的第一个应用程序，从而使该第一个应用程序能确定通信会话的参数，将其自身插入到通信会话的控制和/或媒体流中，并从而将其自身绑定到该通信会话。一旦第一个应用程序将其自身插入到了通信会话中，该第一个应用程序就要么将通信设立消息传递回特征定序器128以识别应用程序序列中的下一个应用程序，要么直接将通信设立消息传递到应用程序序列中的第二个应用程序。替换地，或附加地，可将该消息重定向，拒绝，等等。此外，可由应用程序将参与方和/或媒体服务器添加到呼叫。可以认识到，这个过程将继续，直到所有的应用程序已包括在通信会话中，并且该过程可以为通信会话中所涉及的每个用户复制。

在一些实施例中，应用程序148、152通过锚点服务器140绑定到一通信会话。因此，特征定序器128可最初在初始通信会话建立期间将锚点服务器140绑定到应用程序序列中。在许多情况下，应用程序148、152会在呼叫发起之前，甚至在锚点服务器140定序到呼叫序列之前，订阅针对给定用户的事件通知。在其他情况下，应用程序148、152可在呼叫已在进行之后订阅事件通知。在任一情况下，应用程序148、152也可利用锚点服务器140对通信会话施加控制。

虽然只描绘了两个应用程序服务器144，但本领域技术人员将会认识到，可以设置一个，两个，三个或更多的应用程序服务器144，并且每个服务器可被配置来提供一个或多个应用程序。特定的应用程序服务器144所提供的应用程序可能会取决于服务器144的能力而有所不同，并且在特定的应用程序服务器144包括一组应用程序152的情况下，该组应用程序152中的一个、某些或所有的应用程序可包括在一特定的应用程序序列中。但是，不要求一组应用程序152中的所有应用程序包含在一应用程序序列中，并且对于应用程序包含在应用程序序列中的顺序没有要求。相反，应用程序序列通常是基于用户的通信偏好确定的，用户的通信偏好可以在用户表132中找到。替代地，或附加地，出现在用户的序列向量中的应用程序和它们在该向量中的顺序可由系统管理员来确定，以满足业务需求。

此外，应用程序序列可以根据通信会话中正在使用的(一个或多个)媒体类型而不同。例如，一用户可能具有用于基于语音通信的第一组偏好，用于基于视频通信的第二组偏好，和用于基于文本通信的第三组偏好。此外，用户可以具有定义优选的媒体类型和用于将通信会话从一种媒体类型的转换到另一不同的媒体类型的规则的偏好。另外，用户还可能具有定义建立和进行多媒体通信的方式的偏好。

在特定的应用程序序列中包含的应用程序一般被包含以适应用户的偏好。应用程序可能根据媒体类型、功能等而有所不同。应用程序的范例类型包括但不限于，EC-500(到蜂窝的扩展)应用程序，呼叫建立应用程序，语音信箱应用程序，电子邮件应用程序，语音应用程序，视频应用程序，文本应用程序，会议应用程序，呼叫记录应用程序，通信日志服务，安全应用程序，加密应用程序，协作应用程序，白板应用程序，移动性应用程序，存在性(presence)应用程序，媒体应用程序，消息应用程序，桥接应用程序，以及可以补充或加强通信的任何其他类型的应用程序。此外，一个，两个，三个或更多的给定类型的应用程序可以包含在单个应用程序序列中而不偏离本发明的范围。

根据本发明的至少一些实施例，将锚点服务器140提供为用于如下功能的机制：在用户的通信序列中创建锚点从而使某些应用程序148、152能在通信会话建立之后了解和控制该会话，或者使得某些应用程序148、152能在会话结束前离开通信会话。特别是，锚点服务器140可以在建立期间将一个锚点或多个锚点绑定到通信会话，但不一定绑定任何媒体资源到该通信会话，直到应用程序标识出对该媒体资源的需求为止。因此，锚点服务器140可在其他被定序的应用程序绑定到通信会话之前和/或之后，将一个或多个锚点纳入到逻辑通信序列中。

在引入锚点之前，如果一应用程序148、152希望有能力对给定的通信施加媒体控制，则它将必须明确作为被定序的应用程序而被供应。然而，一些应用程序不真正关心的通信建立阶段：它们安于让通信进行到最初被寻址的参与方，然后在会话中途施加媒体和呼叫控制。将这种应用程序作为被定序的应用程序而供应常常会导致不必要的媒体资源的浪费和呼叫设立时延的增加。

在一些实施例中，锚点不是一应用程序所独有的。相反，它们是任何应用程序都可以利用的控制点。他们甚至可以不是被供应，而是由特征定序器128自动地定序进来，所述特征定序器128会知道什么锚点服务器140对于给定的用户是权威的，因为该信息也可以在用户表132中找到。锚点服务器140所提供的锚点将总是被定序到应用程序序列中的至少一个点中。放置锚点的位置可能会有所不同，这取决于所需的特征类型。此外，多个锚点可插入一通信会话中而不偏离本发明的范围。

利用锚点的应用程序将具有与计算机支持电话应用程序(CSTA)所提供的逻辑呼叫模型Parlay-X类似的逻辑呼叫模型，或用于在应用程序和锚点之间传送呼叫状态和操作的任何其他范例。可能要利用锚点的这样的应用程序将订阅感兴趣的端点的呼叫事件，并会在通信会话的呼叫/连接状态变化时收到通知。在一些实施例中，锚点对于应用程序会是不可见的。相反，它们将在呼叫或该呼叫内的连接上调用媒体操作，并且锚点的利用将是透明的。

在大多数情况下，锚点最初不会涉及在媒体路径(例如，实时传输协议(RTP)路径)中的媒体资源。相反，锚点将其自身作为背靠背用户代理(Back-to-BackUserAgent，B2BUA)插入在信号路径中。只有当应用程序请求媒体动作时，锚点才会启动媒体服务器标记语言(MSML)，然后应用程序服务器144向每一方RE-INVITE(重新邀请)以将应用程序服务器144插入到RTP路径中。在锚点位于端点“隔壁”的实施例中，始终保证它能够排他地向该给定的端点/用户进行播放或录制。由于可以为企业呼叫中每一个用户添加锚点，因此每方媒体操作一般都会是可能的，而与任何中间会议焦点或应用程序无关。由于实现特定的应用程序所需的媒体资源148、152直到需要时才插入到路径中，因此不浪费媒体资源，避免了额外的RTP延迟。

如果每个锚点总是带来其自身的媒体资源，则这将可能导致资源浪费和额外的RTP延迟。这是可以利用媒体令牌的场合。要插入第一媒体资源(例如，一媒体服务器)的第一锚点将把一媒体令牌包括在INVITE(邀请)或RE-INVITE的头部中，该INVITE或RE-INVITE最终被同一通信会话中涉及的第二锚点接收。在大多数情况下，该另一锚点如果可能的话则随后将会使用媒体令牌信息来利用媒体服务器。然而，如果一中间应用程序或会议焦点已插入其自身的媒体资源，则该另一锚点的这一媒体资源重用可能会导致与以前相同的问题：应用程序认为它正在播放或录制一方，但实际上得到的是多方。为了绕开这个问题，第二锚点会将媒体令牌中的会话描述协议(SDP)信息与其在RE-INVITE中接收到的SDP信息相比较。如果SDP属性匹配，则没有中间的媒体服务器，并且可重用第一媒体资源。如果它们不匹配，那么为第二应用程序引入新的媒体资源。在申请日为2009年10月6日，申请人为Braudes等的美国专利申请第12/574,604号中提供了关于媒体令牌及使用其的优点的另外描述，该申请的全部内容被并入本申请中作为参考。

可支持的一个特征是，应用程序可以告诉锚点，它应始终包括用于一给定用户的所有呼叫的一特定的媒体资源(即，基于用户表132中的用户偏好)。一个例子是，如果应用程序知道它总是要为一给定的用户记录所有呼叫。在这种情况下，应用程序会将此情况指示给锚点(也许是在为该用户建立监视器时用一参数来指示)，因此，消除了否则将会通过在呼叫中途插入新媒体资源而引入的“修剪”(clipping)的可能。

但是，常常出现如下的情况：应用程序148、152不会规定要使用的媒体资源，而是会笼统地要求在通信会话中包括媒体资源。在接收到来自应用程序148、152的这样的请求之后，锚点服务器140将为应用程序148、152选择适当的资源，并调用所选资源。

在一些实施例中，这些锚点也有可能被用于呼叫控制的目的，成为B2BUA。它们将使能代表另一个控制实体的传输，会议，挂断操作。

其他服务器156可包括电子邮件服务器，语音邮件服务器，日历服务器，会议服务器，以及已知的向客户装置提供特定服务的其他类型的服务器。在一些实施例中，其他服务器156也可被认为是应用程序服务器144，它们提供一个或多个应用程序以供在通信会话中使用。

内部通信装置136可与外部通信装置112相似或相同，只不过它们是由企业供应的，并常常是企业所拥有的。通信装置112的示范类型包括但不限于任何有能力的电话，硬电话(hardphone)，软电话(softphone)和/或数字电话。适合的电话的例子包括阿瓦雅公司的1600^TM，2400^TM，4600^TM，5400^TM，5600^TM，9600^TM，9620^TM，9630^TM，9640^TM，9640G^TM，9650^TM，和QuickEdition^TM电话，IP无线电话(如阿瓦雅公司的IPDECT^TM电话)，视频电话(如阿瓦雅公司的Videophone^TM)，以及软电话。

企业数据库160包括企业订户信息，如姓名，职务，电子地址信息(例如，电话号码，电子邮件地址，即时消息句柄(handle)，直拨分机，等等)，订户联系人名单(例如，联系人姓名和电子地址信息)，其他雇员记录，等等。

现在参考图2，根据本发明的至少一些实施例，将描述通信系统200的配置，其中应用程序208利用锚点服务器216来参与通信会话。该通信系统200的配置表示了一组冗余或高度可用的锚点服务器216a-N，这些锚点服务器在用于应用程序208的通信会话中提供一个或多个锚点。应用程序服务器204可与应用程序服务器144相似或相同。锚点服务器216a-N可与锚点服务器140相似或相同。在一些实施例中，锚点服务器216a-N可共同位于一共同的设施中，或可能在物理上相互分离以提供地理冗余。例如，锚点服务器216a-N可能由一个或多个地理界限或边界(如州界，国家边界，海洋等)分开。特征定序器224可与设在通信服务器124上的特征定序器128相似或相同，或者它可以是独立的组件。在某些情况下，特征定序器224可以是地理冗余的，这意味着特征定序器224的多个版本设在不同的物理位置，可能在一个更大的WAN中不同的LAN处。

在一些实施例中，应用程序服务器204提供一个或若干个应用程序208，以及一个或多个客户端库212。客户端库212是一组独立于应用程序的指令，这意味着客户端库212可以服务于多个应用程序208。在一些实施例中，客户端库212被设置来管理用户到锚点服务器的映射，从而包括应用程序208在内的任何应用程序都可以利用客户端库212附接到锚点服务器所设立的锚点。这使得应用程序208可以不知道实际上存在多少锚点服务器140以及与此类锚点服务器140相关的任何映射。相反，这个任务委派给客户端库212，并按照请求使之成为应用程序208可获得的。

更具体地说，客户端库212可包含映射到一个或多个锚点服务器216a-N的用户，用户ID，记录地址(AddressofRecord，AoR)，用户别名的列表。在一些实施例中，客户端库212还包括用于跟踪哪个服务器对于特定用户是首选/次选/再次选的指令，但它不必将任何该信息指示给任何其他组件。相反，它直接利用该信息对从应用程序接收到的请求作出响应。在一些实施例中，客户端库212维护如下信息：该信息指示出锚点服务器216a-N中哪一个是用户的首选锚点服务器(即，如果可用则用作用户的默认锚点服务器的锚点服务器)，锚点服务器216a-N中哪一个是用户的次选锚点服务器(即，如果首选锚点服务器不可用则要使用的锚点服务器)，锚点服务器216a-N中哪一个是用户的再次选锚点服务器(即，如果首选锚点服务器和次选锚点服务器不可用则要使用的锚点服务器)，等等。

同样，每个锚点服务器216a-N可维护其首选用户列表220a和次选用户列表220b。列表220a、220b可以标识锚点服务器216支持哪些用户。如果特定的锚点服务器216对于特定的用户或用户群组不是权威的，则列表220a、220b也可标识哪些锚点服务器216对于特定的用户或用户群组是权威的。因此，客户端库212可以代表应用程序208查询任何一个锚点服务器216，并确定哪个锚点服务器216对于具体的用户是权威的。一旦客户端库212从锚点服务器216获得了这些信息，客户端库212就可以更新其用户到锚点服务器映射的内部记录，并根据需要使得这些信息成为应用程序可获得的。

如上所述，特征定序器224可在呼叫初始化期间，最初将一个或多个锚点服务器216a-N定序到应用程序序列中。在一些实施例中，应用程序208可被配置来从通信会话开始就监视针对给定用户的所有通信会话，它可以利用锚点服务器216a-N来完成这种监视。在其他实施例中，在通信会话已经开始后的某个时刻，用户可调用应用程序208以开始监视通信会话。在被调用后，应用程序208可先参考客户端库212，以确定对于该用户，权威的锚点服务器216a-N是否是已知的。如果是，则客户端库212将映射信息返回应用程序208，或代表应用程序将应用程序208的请求路由到适当的锚点服务器216，以使得应用程序208能够向所识别的锚点服务器216发出呼叫监视/控制请求。但是，如果客户端库212不具有用于该用户的锚点服务器条目，则客户端库212发送请求到默认的锚点服务器216或随机选取的锚点服务器216。如果该服务器恰好对该用户是权威的，则锚点服务器216将会按正常方式处理请求，从而将应用程序208绑定到特定的通信会话。如果查询的服务器对于该用户不是权威的，则服务器216可以简单地参考其内部列表220a、220b以识别锚点服务器216a-N中哪个对于用户是权威的，并将该信息提供回应用程序208。

多个锚点服务器216a-N的供应允许了锚点的高度可用的配置。在一些实施例中，锚点服务器216a-N可配置为活动-不活动(active-passive)配置，其中一个锚点服务器216作为一用户的首选锚点服务器而另一个锚点服务器216作为次选锚点服务器。在活动-不活动配置中，首选锚点服务器216可被特征定序器调用，接收通信会话的媒体流，并执行创建锚点并使应用程序208能利用锚点所需的所有功能。另一方面，次选锚点服务器216可保持空闲状态，直到它检测到首选锚点服务器216不再能够提供必要的功能(即，首选锚点服务器216故障)。如果检测到此类事件，那么可遵循故障转移程序，从而在锚点间通信链路232a、232b的锚点服务器216之间共享一些每呼叫状态信息。该呼叫状态信息使次选锚点服务器216能继续向应用程序208提供连接到通信会话，接收基于呼叫的事件通知，并对通信会话的媒体施加控制的手段。

作为对活动-不活动配置的替代，可将冗余的锚点服务器216建立为活动-活动式的。此配置意味着在通信会话期间多个锚点服务器216可对于单个用户是活动的。只有一个锚点服务器216可由应用程序208使用，另一锚点服务器216可仅仅存储呼叫事件信息而不作进一步处理。活动-活动配置使得可以在故障转移过程中进行快速平稳过渡。活动-活动配置的利用还避免了在故障转移和故障恢复期间拆除通信会话的需要。如果故障转移期间的呼叫保持是一个目标，则可能需要呼叫状态共享，这是因为最初只会对首选锚点服务器进行定序。

在一些实施例中，客户端库212可以为给定的用户发出针对可能对该给定用户成为权威的每个锚点服务器216的订阅。在这种情况下，锚点服务器216不必彼此分享关于应用程序订阅的状态。然而，其他的呼叫状态必须被共享。

在一些实施例中，锚点服务器216a-N被配置来总是只看到通信会话的两个分支(leg)。两种基本情况是：两方通话、或电话会议，在该电话会议中锚点服务器216看到的第二个分支是通往一会议焦点的。使应用程序208能看到集中式的通信会话(类似于基于PBX的通信会话)的是锚点服务器216组建逻辑呼叫模型。它还使锚点服务器216可以对应用程序208隐藏它们是涉及两方呼叫还是电话会议。

从图2中可以看出，第一通信链路228a，228b，228N可分别设立在应用程序服务器204和锚点服务器216a，216b，216N之间。第一通信链路228a，228b，228N可以用来为特定的用户群组交换呼叫事件信息和绑定请求。在一些实施例中，每个锚点服务器216可具有一远程接口，该远程接口辅助设立和维护第一通信链路228a，228b，228N。远程接口可包括呼叫建模、呼叫控制和媒体控制远程接口，该接口将锚点服务器216显露给应用程序服务器204。此远程接口可以采取多种形式，包括但不限于SOAPweb服务，RESTweb服务，Bayeux，通过TCP的XML，等等。

第二通信链路236a，236b，236N也可分别设立在特征定序器224和锚点服务器216a，216b，216N之间。第二通信链路236a，236b，236N可用于承载代表应用程序208去往/来自通信会话的会话信令。第二通信链路236a，236b，236N给应用程序208提供了一种用于接收呼叫状态信息，并对通信会话的媒体资源施加控制的机构。

从图3中可以看出，可能发生如下情况：一个或多个锚点服务器216变得暂时或永久不可用。这种情况通常称为服务器故障，可能会导致需要针对正在利用现在故障的锚点服务器216的用户执行故障转移程序。如上所述，在故障转移过程中所采取的步骤可能取决于锚点服务器216a-N正遵循活动-不活动还是活动-活动模型。在活动-不活动模型中，在使得应用程序208能够利用锚点服务器216所提供的锚点之前，可能需要将某些呼叫状态信息提供给备份锚点服务器216。在活动-活动模型中，用户的次选锚点服务器216不是空闲的。相反，它对于其次选用户列表220b中的所有用户都是活动的，并为故障情境保留了未使用的容量。

在发生故障时，可能会存在一过渡状态，其中多个锚点服务器216a-N具有针对一给定用户的活动呼叫。在这种情况下，任何呼叫中请求(例如，保持呼叫，检索呼叫等)应被客户端库212定向至拥有该呼叫(即，对于发起请求的用户而言是权威)的锚点服务器216。这可以通过如下方式来实现：将直到检测到故障之前一直处理呼叫的锚点服务器216的ID编码到应用程序208用来执行该呼叫中请求的锚点服务器216的连接ID中。在一些实施例中，连接ID可能包括以下三者的组合：特定呼叫的CSID，用户ID(标识发出请求的用户)，以及被请求代表用户执行动作的锚点服务器216的标识。

现在参考图4，根据本发明的实施例，示出了支持共享锚点服务器的两个用户之间的通信会话的通信系统元件的配置。可能出现如下情况：通信会话所涉及的两个用户共享作为他们的首选锚点服务器216的同一锚点服务器216。在一些实施例中，锚点服务器216将对呼叫建模两次，每个用户一次。在这种配置中，单个第一通信链路228设立在应用程序服务器204和锚点服务器216之间，单个第二通信链路236设立在特征定序器224和锚点服务器216之间。第三通信链路412a，412b可设立在特征定序器224和通信会话所涉及的每个端点404a，404b之间。第三通信链路412a，412b可为特定的用户或端点承载会话信令。因此，用于用户A的会话信令可由通信链路412a承载，而用于用户B的会话信令可由通信链路412b承载。还可在端点404a，404b之间设立端点到端点链路408，用于承载端点404a，404b之间的媒体，从而辅助端点404a，404b之间的通信会话。在一些实施例中，端点到端点链路408是RTP或SRTP流。

现在参考图5，根据本发明的实施例，示出了支持不共享锚点服务器的两个用户之间的通信会话的通信系统元件的替代配置。这里，第一锚点服务器216a对于用户A是权威的，第一锚点服务器216b对于用户B是权威的。不需要在锚点服务器216a，216b之间共享逐个呼叫的状态信息。每个锚点服务器216a，216b使应用程序208能为双方用户提供所需的功能，但仍使应用程序能够保持呼叫的单个逻辑视图。

与图4的配置相比，有多个第一通信链路228a，228b和第二通信链路236a，236b。应用程序服务器204和第一锚点服务器216a之间的通信链路228a承载用于用户A的事件和请求数据信号。同样，应用程序服务器204和第二锚点服务器216b之间的通信链路228b承载用于用户B的事件和请求数据信号。用户A的会话信令通过通信链路236a和412a来承载。用户B的会话信令通过通信链路236b和412b来承载。

现在参考图6，根据本发明的实施例，示出了支持三个或更多用户之间的会议通信会话的通信系统元件的配置。与图5的配置一样，不需要在锚点服务器216a和216b之间共享逐个呼叫的状态信息。此外，图6描绘的配置示出了一个锚点服务器(例如，第二锚点服务器216b)对于会议所涉及的两个用户(例如，用户B和用户C)是权威的。可能出现如下情况：所有用户共享相同的锚点服务器216作为其首选服务器，或可能出现如下情况：每个用户都有不同的锚点服务器216作为其权威锚点服务器。图6描绘的示例只用于说明目的，并无意限制本发明的范围。

在会议通信会话中，可引入会议焦点604，作为端点404a，404b，404c之间对媒体进行共享、混合和重新分发的点。在一些实施例中，会议焦点604可包括驻留在会议服务器上的会议桥或会议混合器。或者，会议焦点604可驻留在端点404a，404b，404c之一处。

在此实施例中，通过会议焦点604在端点404a，404b，404c之间交换媒体，并且通过通信链路612a，612b，612c承载媒体信号。在一些实施例中，通信链路612a，612b，612c可对应于已使用SIP或其他某种类似的协议而设立的RTP或SRTP流。

可在会议焦点604和锚点服务器216a和216b之间分别设立另外的通信链路608a和608b。通信链路608a，608b可被锚点服务器216a，216b用来订阅会议状态事件，并直接从会议焦点604而不是通过端点404a，404b，404c和特征定序器224接收关于此类事件的信息。这使得每个锚点服务器216a，216b保持觉察会议焦点处的活动。因此，如果另一个用户通过已经参与会议的端点加入会议，则会议焦点604将知道该新用户的添加，并将会把指示该情况的状态事件发送给锚点服务器216a，216b。

在一些实施例中，锚点服务器216a，216b使用会议事件组建完整的名册清单，即使各个用户的锚点跨越N个服务器分布也是如此。在高度可扩展、高度分布式的网络中也可能存在N个会议焦点，逻辑呼叫模型从该信息中抽象出应用。

现在参考图7，根据本发明的至少一些实施例，将描述应用程序绑定处理。方法开始时，特征定序器224或用户调用应用程序208以开始应用程序绑定处理，通过该应用程序绑定处理，应用程序试图将其自身绑定到一通信会话(步骤704)。在一些实施例中，通信会话可能是正在进行的通信会话，而在其他实施例中，应用程序可能在锚点服务器216最初被定序到通信会话中时，通过锚点服务器216被绑定到通信会话。在接收到开始绑定处理的指令后，应用程序208发出针对去往/来自特定用户的呼叫的监视请求(步骤708)。在客户端库212处接收该请求，并且客户端库212参考其本地维护的数据结构以确定它是否已经知道对于该特定用户的权威(即，首选)锚点服务器216(步骤712)。

如果在客户端库212中找到了针对该特定用户的条目，则客户端库212可识别在其数据结构中映射到该特定用户的锚点服务器216(步骤716)，并代表应用程序208向被识别为首选锚点服务器216的锚点服务器216发出请求(步骤724)。因此，使客户端库212能够代表一个或多个应用程序创建应用程序到锚点绑定。

在使用了锚点服务器216的活动-活动配置的一些实施例中，客户端库212可发出多个请求到多个锚点服务器216。多个请求的发出可通过将请求广播到所有已知的锚点服务器216，或通过发送请求到选定的锚点服务器216来完成。但是，应该指出，多个请求的广播可以在请求是查询或订阅的情形下进行，并且一般在请求是用于呼叫控制的情况下不进行。

或者，如果在客户端库212中没有条目，则客户端库212通过默认选择规则或随机地选择锚点服务器216，并如同该选定的锚点服务器216实际上是针对发出请求的用户的首选锚点服务器216那样动作(步骤720)。对单个锚点服务器216的选择的发生可以与利用的是锚点服务器操作的活动-活动还是活动-不活动模式无关。

一旦已通过客户端库212或通过选择算法，由应用程序208识别了锚点服务器216，该方法就继续，客户端库212代表应用程序208向选定的锚点服务器216发出请求(步骤724)。向(一个或多个)锚点服务器216发出的(一个或多个)请求包含让锚点服务器216利用在特定通信会话(该特定用户可能已经是或可能还不是其中的参与者)中已经建立或很快要建立的锚点来检索呼叫事件、控制和其他数据并将这种数据提供回应用程序208的指令。锚点还可被应用程序208用来通过发送到建立了锚点的锚点服务器216的控制信号，对通信会话施加呼叫控制和媒体控制。请求还可包含如下各项中的一项或多项：用户ID，AoR，别名，CSID，或使得锚点服务器216能够确定其是否被配置来和/或被允许支持应用程序208发出的请求的用户或通信会话的任何其他标识。

在接收到来自应用程序208的请求后，锚点服务器216参考其内部维护的列表220a，220b以确定它是否实际上是对于发出请求的用户权威的锚点服务器216(步骤728)。该步骤可以由接收到来自应用程序208的请求的每个锚点服务器216(即，如果将多个请求发送或广播到多个锚点服务器216)执行。在此步骤中，锚点服务器216将会在其内部维护的列表220a，220b中搜索用户标识符，或者它将会搜索请求中所包含的CSID。如果应用程序208所发送的请求包含CSID，则锚点服务器216将会确定其当前是否具有在被指派了请求中所包含的CSID的通信会话中建立的锚点。

如果对请求的分析指示出锚点服务器216对发出请求的用户不是权威的(或没有CSID匹配)，则锚点服务器216可以要么试图识别作为适合处理请求的服务器的替代锚点服务器216，要么将此类信息发送回发出请求的应用程序208(步骤732)。或者，如果锚点服务器216不知道适合处理请求的锚点服务器216的身份，则锚点服务器216可对应用程序208作出响应说它不能支持该请求，或可以根本不响应。这可以发起一处理，在该处理中应用程序208试图识别替代的锚点服务器216并向该锚点服务器216发出请求，直到找到对于发出请求的用户是权威的锚点服务器216为止。

如果锚点服务器216分析请求，并确定它对于发出请求的用户是权威的(无论是作为首选锚点服务器还是次选锚点服务器)，那么锚点服务器216可发送指示该情况的响应给应用程序208。当接收到来自锚点服务器216的肯定的响应后，客户端库212可通过将用户ID、CSID或其他某种标识符映射到对请求作出了肯定响应的锚点服务器216的标识符，来更新其本地维护的数据结构(步骤736)。

一旦已经利用用户到锚点服务器映射信息更新了客户端库212，方法就继续，应用程序208使用权威锚点服务器216所设立的锚点来对呼叫施加控制，并接收呼叫事件和状态信息(步骤740)。

虽然图7描绘了应用程序208在识别通信会话之前发出监视请求，但本发明的实施例也考虑了如下情况：应用程序208可先发出针对特定用户的所有现有的会话的查询。可将该查询通过客户端库212发送到一个或多个锚点服务器216。如果应用程序208得知该特定用户的正在进行的通信会话，则应用程序208可试图将其自身绑定到该通信会话(如果它还未绑定到该通信会话的话)，然后尝试对该正在进行的通信会话进行动作。

图8描绘根据本发明的至少一些实施例，由应用程序208用来在通信会话开始之前或之后设立针对特定用户的呼叫监视功能的信令序列。与本申请所述其他实施例一样，应用程序208能访问客户端库212，该客户端库212维护一个或多个用于将用户映射到锚点服务器216的数据结构。在图8描绘的实施例中，用户A映射到第一锚点服务器216a(即，第一锚点服务器216a对用户A是权威的)，并且用户B映射到第二锚点服务器216b(即，第二锚点服务器216b对用户B是权威的)。

序列开始时，应用程序208判断它要监视一个或多个用户的所有通信会话(即，尚未设立的会话和已经在进行的会话)。在图8描绘的例子中，应用程序208判断它要监视用户A和B的通信会话。但是能够认识到，应用程序208可能只对监视用户A或用户B，而非二者的通信会话感兴趣。在这种情况下，应用程序208将发出单个原子监视请求到锚点服务器216a，216b之一，而不是如本申请将会更详细描述的那样发出两个不相关的请求到锚点服务器216a，216b二者。

该判断可以是响应于应用程序208接收到请求监视用户A和B的所有呼叫的用户输入而作出的，或者它可以是自动响应于一预先供应的规则而作出的，所述预先供应的规则规定了对于涉及用户A和B的通信会话要调用应用程序208。在一些实施例中，该判断是一旦应用程序208启动(即通电)就作出的。作出此判断后，应用程序208发出请求到客户端库212，该客户端库212将第一锚点服务器216a识别为用户A的权威，将第二锚点服务器216b识别为用户B的权威，并为用户A和用户B分别将请求转发到第一和第二锚点服务器216a，216b(S801和S802)。对用户A和B的权威锚点服务器的识别可以通过使用结合图7描述的方法的部分或全部来实现。

在权威锚点服务器216处接收到请求后，锚点服务器216将等待直到INVITE(或从用户A或用户B接收到类似的呼叫建立请求)。在图8的例子中，用户A发送INVITE给用户B，试图建立通信会话(S803)。该INVITE最初在特征定序器224处被接收和分析。特征定序器224进行检查，看哪些应用程序请求了针对用户A的通知。在这个例子中，特征定序器224判断应用程序208已发出了这样的针对用户A的监视请求，并通过第一锚点服务器216a发送通知给应用程序208(S804)。第一锚点服务器216a发送用户A正在呼叫用户B的通知给应用程序208(S805)。在应用程序208接收到针对用户A的通知之后，应用程序208就准备好对用户A的通信会话采取某种动作。由于尚未接收到针对用户B的通知，因此应用程序208将还未准备好对用户B的通信会话采取动作。

此后，第一锚点服务器216a将INVITE发回特征定序器224(S806)。在重新接收到INVITE后，功能定序器224检查其内部维护的数据结构来判断哪个锚点服务器对于用户B是权威的，然后将INVITE转发到第二锚点服务器216b(S807)。第二锚点服务器216b进行检查，看哪些应用程序请求了针对用户B的通知，并找到指示出应用程序208已经发出了这样的针对用户B的请求的条目。在作出此判断后，第二锚点服务器216b发送通知到应用程序208(S808)。

此后，第二锚点服务器216b将INVITE发回特征定序器224(S809)，该特征定序器224随后发送INVITE消息到用户B的端点(S810)。用来完成通信会话设立的后续的SIP消息随后可以以通常的背靠背UA(B2BUA)方式在端点和锚点服务器216a，216b之间交换，直到在端点之间建立了通信会话为止。

现在参考图9，根据本发明的实施例，将描述利用CSID使得应用程序208能代表通信会话的多个用户进行操作的处理。如上所述，设立通信会话时，通信会话可能被指派唯一的CSID。可将CSID指派给通信会话达该通信会话的持续时间。通信会话终止后，可将CSID退回到CSID存储库，其中该CSID可以在稍后的时间点被指派给另一个通信会话。虽然将CSID指派给一特定的通信会话，但可将该CSID通知给通信会话中所涉及(例如，通过在该通信会话的应用程序序列中建立了一个或多个锚点)的每个锚点服务器216，并且每个锚点服务器216用来参考通信会话的CSID在所有锚点服务器216当中可以是相同的。

在一些实施例中，希望让应用程序208参考它要控制或要被绑定的通信会话，而非向通信会话中所涉及的用户打听。在应用程序208发出针对呼叫中所有参与者的请求或要将用户添加到正在进行的呼叫时，引用CSID而非用户的请求一般是希望的。在这些情况下，如上所述，请求仍被定向到具有用于与该CSID相对应的通信会话的锚点和呼叫模型的锚点服务器216。如果请求最初被定向到并未在通信会话中建立锚点的锚点服务器216，则该锚点服务器216可能要么查询其他锚点服务器216，要么参考其内部维护的列表220a，220b以发现哪个锚点服务器216对于所请求的CSID是权威的，并将会把应用程序208重定向到该锚点服务器216。这防止了锚点服务器216必须不断地共享任何每呼叫数据。

利用CSID而非基于用户的请求的方法开始时，应用程序208接收来自用户的请求，以发出针对呼叫中所有参与者的查询，将用户添加到正在进行的呼叫，或执行需要对通信会话自身的引用而非对特定用户的引用的其他某种功能(步骤904)。响应于接收到请求，应用程序208尝试判断已被指派给该通信会话的CSID(步骤908)。应用程序208能够获得该CSID信息的途径一般有两种：可以在它监视用户时通过通信事件而将CSID告知它，或它可以查询给定用户所涉及的所有呼叫。CSID是应用程序208负责跟踪的，而非客户端库212负责跟踪的；但是，客户端库212，而非应用程序208，将会跟踪CSID和锚点服务器216之间的关联。

应用程序208然后将CSID提供给客户端库212，该CSID使得客户端库212试图识别对于该CSID是权威的锚点服务器216(步骤912)。如果该信息对于客户端库212是未知的，则客户端库212可以发送请求到锚点服务器216之一，希望该锚点服务器216要么是要么知道对于该CSID是权威的锚点服务器216。或者，客户端库212可以通过参考其本地维护的映射来识别与该CSID相关的用户，这是因为该信息可被用来识别对于CSID是权威的锚点服务器216。

应用程序208和客户端库212然后进行关于图7和/或图8描述的处理，并且应用程序208最终通过合适的(一个或多个)锚点服务器216绑定到通信会话。此后，应用程序208能够代表通信会话中所涉及的多个用户，对通信会话施加控制(步骤916)。特别是，可以使得应用程序208能利用锚点服务器216所建立的锚点来对通信会话施加呼叫和媒体控制。

在以上描述中，为了说明目的，按特定顺序描述了方法。应该认识到，在替代的实施例中，其方法和步骤可能会按与上述不同的顺序执行。也应该认识到，上述方法可能由硬件组件执行，或可能包含在机器可执行的指令序列中，所述指令可用来导致被用该指令编程的机器如通用或专用处理器或逻辑电路执行所述方法。这些机器可执行指令可存储在一个或多个机器可读介质，如CD-ROM或其他类型的光盘，软盘，ROM，RAM，EPROM，EEPROM，磁卡或光卡，闪存，或其他类型的适合存储电子指令的机器可读介质上。或者，该方法可以由硬件和软件的组合执行。

在描述中给出了具体细节，以提供对实施例的透彻了解。但是，本领域技术人员将会了解，没有这些具体细节的情况下也可以实现实施例。例如，电路可能通过电路框图示出，以避免不必要的细节掩盖实施例。在其他实例中，公知的电路，处理，算法，结构和技术可能没有示出不必要的细节，以避免掩盖实施例。

此外指出，将实施例描述为处理，该处理被描绘为流程图，流程示图，数据流示图，结构示图，或框图。虽然流程图可能将操作作为一个顺序的过程描述，但许多操作可以平行或同时进行。此外，操作的顺序可重新排列。一个处理在其操作完成时终止，但可能具有图中未包括的另外的步骤。处理可能对应于方法，函数，过程，子例程，子程序等。当处理对应于函数时，其终止对应于函数返回到进行调用的函数或主函数。

此外，实施例可通过硬件，软件，固件，中间件，微代码，硬件描述语言，或其任何组合来实现。当在软件，固件，中间件或微代码中实现时，用于执行必要的任务的程序代码或代码段可能会存储在机器可读介质如存储介质中。(一个或多个)处理器可能会执行必要的任务。代码段可以代表过程，函数，子程序，程序，例程，子例程，模块，软件包，类，或指令、数据结构，或程序语句的任意组合。代码段可能通过传递和/或接收信息，数据，自变量，参数或存储器内容耦合到另一个代码段或硬件电路。可通过任何适当方式，包括存储器共享、消息传递、令牌传递、网络传输等等，传递、转发或发送信息，自变量，参数，数据等。

虽然本申请中详细描述了本发明的说明性实施例，但应当了解，有创造性的概念可能以其他多种方式实现和采用，并且所附权利要求书希望被理解为包括这种变体，除非被现有技术所限制。

Claims

1.一种通信方法，包括：

在应用程序处，接收用于监视和控制用户的通信会话的请求；

通过所述应用程序，向一个或多个锚点服务器发送用于接收来自锚点服务器的用于所述用户的通信会话的事件信息的请求；

确定将在所述用户的通信会话中的至少一些通信会话中建立锚点的第一锚点服务器的身份；

在所述应用程序与第一锚点服务器之间建立通信链路，以使得所述应用程序能通过所述通信链路接收关于所述用户的通信会话的事件信息；以及

允许所述应用程序通过所述第一锚点服务器来对所述用户的通信会话中的至少一些通信会话施加呼叫控制和媒体控制中的至少一种。

2.如权利要求1所述的方法，其中，所述第一锚点服务器对于发出在所述应用程序处接收的请求的第一用户是权威的，并且其中所述第一锚点服务器的身份是通过一客户端库确定的，其中所述客户端库服务于多个应用程序，所述方法还包括：

更新所述客户端库中的数据条目，以反映出所述第一锚点服务器对于所述第一用户是权威的。

3.如权利要求1所述的方法，其中，所述第一锚点服务器对于通信会话是权威的，并且保持相对于被指派给该通信会话的通信会话ID(CSID)上的其他锚点服务器而言排他的控制。

4.如权利要求1所述的方法，其中，所述第一锚点服务器接收来自一会议焦点的关于通信会话的事件信息，并且其中所述第一锚点服务器组建用于该会议的完整的名册清单，其中所述会议焦点包括会议混合器，该会议混合器混合来自参与通信会话的三个或更多端点的三个或更多媒体流。

5.如权利要求1所述的方法，其中，只要所述第一锚点服务器是活动的，所述应用程序就被允许通过所述第一锚点服务器控制所述用户的所有通信会话。

6.一种通信系统，包括：

7.如权利要求6所述的系统，其中，所述第一锚点服务器对于第一用户是权威的，并且其中所述第二锚点服务器对于第二用户是权威的，其中所述第一锚点服务器到所述第一用户的映射和所述第二锚点服务器到所述第二用户的映射被维护在客户端库中。

8.如权利要求7所述的系统，其中，所述客户端库被多个应用程序共享。

9.如权利要求6所述的系统，其中，通信会话是正在进行的通信会话，并且其中，在所述应用程序在通信会话的初始化期间未被最初定序到应用程序序列中的情况中，所述第一锚点服务器和所述第二锚点服务器中的一者或两者被所述应用程序用来对所述正在进行的通信会话施加呼叫控制和媒体控制中的至少一种。

10.如权利要求6所述的系统，其中，所述应用程序在所述第一锚点服务器和所述第二锚点服务器中的至少一者被定序到通信会话中时被最初绑定到该通信会话。