多方呼叫和具有桥接通道的呼叫中的特征交互检测

摘要

公开了多方呼叫和具有桥接通道的呼叫中的特征交互检测。公开了用于检测多方呼叫(即，涉及多于两个端点的呼叫)和具有桥接通道的呼叫中的特征交互的方法。依照示例性实施例，将一组规则应用于两个特征的规范，以便检测特征之间的交互。这些规则规定了特征的原始连接、特征的结果连接、特征的触发方、以及连接的发起和终止方的条件或它们之间的关系。对于多方呼叫，当呼叫的原始和结果连接的任何一个与规则的条件匹配时，认为与规则匹配。类似地，对于具有一个或多个桥接通道的呼叫，当包括桥接通道的那些的呼叫的原始和结果连接的任何一个与规则的条件匹配时，认为与规则匹配。

说明书

相关申请的交叉引用

本申请涉及与本申请同日提交的如下两个申请：发明名称为“Mid-Call Detection And Resolution Of Feature Interactions”的美国专利申请第12/392445号(代理人案号：630-393us)、和发明名称为“Feature Interaction Detection During Calls With Multiple-LegSignaling Paths”的美国专利申请第12/392461号(代理人案号：630-394us)。

技术领域

本发明一般涉及电信，尤其涉及检测多方呼叫和具有桥接通道(bridged appearance)的呼叫中的特征(feature)交互。

背景技术

多年来，人们已经开发出了多种多样的电信特征(也被称为服务)，譬如，呼叫转移、三向呼叫、等待音乐等。但是，当将两个或更多个特征应用于电话呼叫时，特征之间的交互可能引起出乎意料或不想要的行为，譬如，允许避开一些策略或使呼叫失败。例如，假定通过拨入式电话会议(meet-me conferencing)特征建立呼叫，然后在呼叫期间激活等待音乐特征。如果呼叫参与者之一继续等待，那么，呼叫的所有其它各方也将听到音乐。

通常，电话平台的销售商在设计时试图预期特征交互。但是，设计时技术的局限性在于，难以预期一个或多个第三方加入除平台销售商设计中的那些特征之外的新特征时可能发生的特征交互。同时，运行时的特征交互的检测和解决技术通常依赖于在分布式联网环境下难以保持并且引入在呼叫建立期间不能处理的计算开销的详细模型。

发明内容

本发明提供了一种用于检测多方呼叫(即，涉及多于两个端点的呼叫)和具有桥接通道的呼叫中的特征交互的技术。依照示例性实施例，将一组规则应用于两个特征的规范，以便检测特征之间的交互。尤其，这些规则规定了如下的一个或多个的条件，或如下的一个或多个之间的关系：

●第一特征的一组原始连接(即，应用第一特征之前的一组原始连接)；

●第一特征的一组结果连接(即，应用第一特征之后的一组连接)；

●第一特征的触发方(即，触发第一特征的激活的端点的身份)；

●第一特征的原始连接的发起方；

●第一特征的原始连接的终止方；

●第一特征的结果连接的发起方；

●第一特征的结果连接的终止方；

●第二特征的一组原始连接；

●第二特征的一组结果连接；

●第二特征的触发方；

●第二特征的原始连接的发起方；

●第二特征的原始连接的终止方；

●第二特征的结果连接的发起方；以及

●第二特征的结果连接的终止方。

如果发现两个特征与规则的任何一个相匹配，那么，在特征之间存在交互。对于多方呼叫，当呼叫的原始连接和结果连接的任何一个与规则的条件相匹配时，认为与规则匹配。类似地，对于具有一个或多个桥接通道的呼叫，当包括桥接通道的那些呼叫的呼叫的原始连接和结果连接的任何一个与规则的条件相匹配时，认为与规则匹配。

该示例性实施例包含：确定包含多于两个端点的呼叫的第一特征和该呼叫的第二特征是否交互。

附图说明

图1描绘了与依照本发明第一示例性实施例的为多方和桥接通道呼叫检测和解决特征交互的方法相对应的流程图；

图2描绘了依照本发明第二示例性实施例的用于在呼叫期间检测和解决特征交互的有限状态机；

图3描绘了依照本发明第二示例性实施例的与如图2所示的有限状态机200相对应的方法的流程图；

图4描述了依照本发明第二示例性实施例的用于执行如图3所示的任务360的第一技术的流程图；

图5描述了依照本发明第二示例性实施例的用于执行任务360的第二技术的流程图；

图6描述了依照本发明第二示例性实施例的用于执行任务360的第三技术的流程图；

图7描绘了依照本发明第三示例性实施例的为具有多分支信令路径的呼叫检测和解决特征交互的第一方法的流程图；

图8描绘了依照本发明第三示例性实施例的为具有多分支信令路径的呼叫检测和解决特征交互的第二方法的流程图；以及

图9描绘了依照本发明第四示例性实施例的包含透明背对背用户代理(B2BUA)的示例性信令路径。

具体实施方式

为了用在这个说明书和所附权利要求中，对于下面出现的术语给出如下定义。

就说明书和权利要求书而言，术语“呼叫”被定义为涉及一个或多个电信终端用户的交互式通信。呼叫可以是传统的语音电话呼叫、网际协议语音(VoIP)呼叫、会话发起协议(SIP)会话、即时消息传送(IM)会话、视频会议等。

依照本发明的第一示例性实施例，应用五条基本规则来检测特征交互，每个具有用于多方呼叫的一种变体和用于具有桥接通道的呼叫的一种变体。这些规则的一些应对一些作业(treatment)，这些作业是被网络触发以便处理呼叫期间的某些条件(例如，什么时候屏蔽呼叫、什么时候阻止呼叫等)的通知或音调(tone)。潜在地，可能在一个特定呼叫中涉及多个作业。例如，在呼叫期间一个特征可能将一方连接到一个繁忙的作业，而在同一个呼叫期间第二个特征可能将一方(同一方或另一方)连接到网络不可用的作业。

依照第一示例性实施例，应用符号表示法来准确地描述特征的行为，其额外好处是便于自动的规则匹配。作为这种符号表示法的一个例子，可以利用这种符号表示法将特征“呼叫转移”或缩写“CFU”表示如下：

CFU：TP：C；A，C→A，B

其中，

●“TP：C”指的是端点C是触发方(即，激活特征的端点)；

●箭头左侧的“A，C”指的是在端点A和C之间存在原始连接(即，特征激活之前A和C之间的连接)；以及

●箭头右侧的“A，B”指的是在端点A和B之间存在结果连接(即，特征激活之后A和B之间的连接)。

作为另一个例子，可以利用这种符号表示法将特征“多方呼叫加入”或缩写“Confjoin”表示如下：

Confjoin：TP：A；[A，C]A，B→A，B，C

其中，

●“TP：A”指的是端点A是触发方；

●箭头左侧的[A，C]指的是在端点A和已经在等待的端点C之间存在原始连接；

●箭头左侧的“A，B”指的是在端点A和B之间存在原始连接；

●箭头右侧的“A，B，C”指的是在端点A、B和C之间存在结果连接(即，A和B、A和C、以及B和C之间的结果连接)。

多方呼叫

用于多方呼叫的规则1a

如果

特征1和特征2具有相同的触发方

而且

(特征1的结果连接＝特征2的结果连接

或者

特征1的原始连接＝特征2的原始连接)

那么

特征1和特征2交互。

用于多方呼叫的规则2a

如果

特征1的原始连接＝特征2的结果连接

而且

特征2的原始连接＝特征1的结果连接

那么

特征1和特征2交互。

用于多方呼叫的规则3a

如果

特征2连接到作业

而且

{特征1的结果连接}∩{特征2的原始连接}≠φ

而且

[发起方(X)＝发起方(Y)∧

终止方(X)≠终止方(Y)]

或者

[发起方(X)＝终止方(Y)∧

发起方(Y)＝终止方(X)]

那么

特征1和特征2交互。

用于多方呼叫的规则4a

如果

{特征1的结果连接}∩{特征2的原始连接}≠φ

而且

[

[发起方(X)＝终止方(Y)∧

发起方(Y)＝终止方(X)]]

或者

[

[发起方(X)＝发起方(Y)∧

终止方(X)≠终止方(Y)]]

那么

特征1和特征2交互。

用于多方呼叫的规则5a

如果

特征1的原始连接＝特征2的原始连接

而且

[

[终止方(Y)＝作业∧

发起方(X)＝触发方(特征1)]]

或者

[

[终止方(Y)＝作业∧

发起方(X)＝触发方(特征2)]]

那么

特征1和特征2交互。

桥接通道(BA)

如果端点A呼叫端点B，以及B已经在与端点C的桥接通道上，那么，A与B连接，C也被连接。类似地，如果端点B呼叫端点A，以及B已经在与端点C的桥接通道上，那么，导致相同的连接结果，只是发起方和终止方相反。使用符号表示法，第一种情况可以表示成：

BA：TP：B；A，B  →A，B-C

其中“B-C”指示B在与C的桥接通道上，而第二种情况可以表示成：

BA：TP：B；B，A  →B-C，A

如下规则可以为已经存在桥接通道的呼叫检测两个特征的交互。换句话说，这些规则检测BA特征激活之后应用的两个特征之间什么时候存在交互。

用于具有一个或多个BA的呼叫的规则1b：与规则1a相同

如果

特征1和特征2具有相同的触发方

而且

(特征1的结果连接＝特征2的结果连接

或者

特征1的原始连接＝特征2的原始连接)

那么

特征1和特征2交互。

用于具有一个或多个BA的呼叫的规则2b：与规则2a相同

如果

特征1的原始连接＝特征2的结果连接

而且

特征2的原始连接＝特征1的结果连接

那么

特征1和特征2交互。

用于具有一个或多个BA的呼叫的规则3b

如果

特征2连接到作业

而且

{特征1的结果连接，包括BA上的各方}∩

{特征2的原始连接，包括BA上的各方}≠φ

而且

[发起方(X)＝发起方(Y)∧

终止方(X)≠终止方(Y)]

或者

[发起方(X)＝终止方(Y)∧

发起方(Y)＝终止方(X)]

那么

特征1和特征2交互。

用于具有一个或多个BA的呼叫的规则4b

如果

{特征1的结果连接，包括BA上的各方}∩

{特征2的原始连接，包括BA上的各方}≠φ

而且

[

[发起方(X)＝终止方(Y)∧

发起方(Y)＝终止方(X)]]

或者

[

[发起方(X)＝发起方(Y)∧

终止方(X)≠终止方(Y)]]

那么

特征1和特征2交互。

用于具有一个或多个BA的呼叫的规则5b

如果

特征1的原始连接＝特征2的原始连接

而且

[

[终止方(Y)＝作业∧

发起方(X)＝触发方(特征1)]]

或者

[

[终止方(Y)＝作业∧

发起方(X)＝触发方(特征2)]]

那么

特征1和特征2交互。

图1描绘了依照本发明第一示例性实施例的为多方和桥接通道呼叫检测和解决特征交互的方法的流程图。本领域的普通技术人员在阅读了本公开之后可以清楚地知道，描绘在图1中的任务可以同时执行或以与所描绘的顺序不同的顺序执行。

在任务110中，将特征f1初始化成用于具有多于两个的端点，或具有一个或多个桥接通道，或具有这两者的呼叫C的第一特征。

在任务120中，将特征f2初始化成用于呼叫C的第二特征。

任务130确定特征f1和f2是否与规则1a-5a和规则1b-5b中的任何一条规则相匹配。本领域的普通技术人员应当懂得，存在多种多样在技术上公知的进行这种确定的方式，譬如，专家系统的规则匹配引擎、逻辑程序、约束满足系统、质朴强制搜索等，并且，本领域的普通技术人员在阅读了本公开之后，可以清楚地知道如何构建和使用能够执行任务130的本发明实施例。

如果任务130确定没有规则与特征f1和f2相匹配，那么，执行过程转到任务140，否则，继续执行任务150。

在任务140中，以公知的方式激活特征f1和f2。在任务140之后，终止执行图1的方法。

在任务150中，以公知的方式激活特征f1和f2之一，而不是两者。本领域的普通技术人员应当懂得，存在多种多样的任务150可以选择两个特征之一加以激活(即，任务150进行特征交互解决)的方式。例如，在本发明的一些实施例中，任务150可以确定性地选择首先被调用的特征，而在本发明的一些其它实施例中，任务150可以确定性地选择最后被调用的特征，而在另一些其它实施例中，可以执行像下面参照第二示例性实施例和图2到6所述的那些的一些其它解决方法。无论如何，本领域的普通技术人员在阅读了本公开之后都可以清楚地知道如何构建和使用能够执行任务150的本发明实施例。

在任务150之后，终止执行图1的方法。

本领域的普通技术人员应当懂得，图1的方法可以结合多种多样的电话平台和协议(例如，基于会话发起协议[SIP]的网际协议语音[VoIP]电话、通过公共交换电话网络[PSTN]的传统电路交换电话等)来实现，并且，本领域的普通技术人员在阅读了本公开之后可以清楚地知道如何针对这样的平台和协议来构建和使用基于这种方法的本发明实施例。

呼叫中间的特征交互检测和解决

本发明的第二示例性实施例能够在呼叫期间检测和解决特征交互(即，呼叫中间的特征交互检测和解决)。第二示例性实施例的技术可以与第一示例性实施例的那些技术组合，以便为多方呼叫和具有桥接通道的呼叫提供呼叫中间的特征交互检测和解决。

图2描绘了依照本发明第二示例性实施例的在呼叫期间检测和解决特征交互的有限状态机(FSM)200。如图2所示，有限状态机(FSM)200包含状态201～206，其中，状态201是开始状态，而状态205和206是最后状态。有限状态机(FSM)200中的每条弧线(或有向边)指示从第一状态到第二状态的合法转变，其中，弧线上的标记提供了对转变的描述。

在开始状态201下，特征f1被激活。在本发明的一些实施例中，可以在呼叫建立之前进入开始状态201，而在一些其它实施例中，可以在呼叫建立期间进入开始状态201，而在另一些其它实施例中，可以在呼叫期间在呼叫建立之后进入开始状态201。

当在呼叫期间调用特征f2时，有限状态机(FSM)200离开开始状态201，并进入状态202。

在状态202下，进行对特征f1和f2的交互检验。如果存在交互，则有限状态机(FSM)200离开状态202，并进入状态203。

根据特征f1还是特征f2具有更高优先级，状态203转变到状态204、205、和206之一(用于选择特征f1和f2之一的特征优先级和解决技术将在下面参照图3到6加以详细描述)。如果特征f1具有比特征f2高的优先级，那么，状态203转变到状态206。如果特征f2具有比特征f1高的优先级并且特征f2是有条件的，那么，状态203转变到状态204。如果特征f2具有比特征f1高的优先级并且特征f2是无条件的，那么，状态203转变到状态205。

在状态204下，进行是否使用特征f2的检验。如果使用，那么，状态204转变到状态205，否则，状态204转变到状态206。

在最后状态205下，重复呼叫而没有特征f1。

在最后状态206下，处理下一个特征。

图3描绘了依照本发明第二示例性实施例的与有限状态机(FSM)200相对应的方法的流程图。本领域的普通技术人员在阅读了本公开之后可以清楚地知道，描绘在图3中的任务可以同时执行或以与所描绘的顺序不同的顺序执行。

在任务310中，以公知方式接收指示特征f1被激活的第一信号。本领域的普通技术人员应当懂得，在本发明的一些实施例中，这个第一信号可以通过交换机接收，而在一些其它实施例中，这个第一信号可以通过用户交换机(PBX)接收，而在又一些其它实施例中，这个第一信号可以从一些其它数据处理系统接收。本领域的普通技术人员应当进一步懂得，在本发明的一些实施例中，特征f1可以在处置特定呼叫之前在任务310被激活，而在一些其它实施例中，特征f1可以在特定呼叫期间被激活。无论如何，本领域的普通技术人员在阅读了本公开之后都可以清楚地知道如何构建和使用能够执行任务310的本发明实施例。

在任务320中，在呼叫期间接收第二信号，该第二信号指示在呼叫期间调用特征f2。

任务330在呼叫期间确定特征f1和f2是否交互。本领域的普通技术人员应当懂得，存在多种多样的可以检测特征交互的方式。例如，在本发明的一些实施例中，可以通过第一示例性实施例的该组规则来确定特征交互，而在一些其它实施例中，可以通过一些可替代技术进行特征交互检测。无论如何，本领域的普通技术人员在阅读了本公开之后都可以清楚地知道如何构建和使用能够执行任务330的本发明实施例。

任务340根据任务330的确定来进行分支。如果在任务330中确定特征f1和f2没有交互，那么，执行转到任务350，否则继续执行任务360。

在任务350中，以公知的方式激活特征f2。在任务350之后，终止执行图3的方法。

在任务360中，解决特征交互。本领域的普通技术人员应当懂得，存在多种多样的可以解决特征交互的方式。例如，在本发明的一些实施例中，可以应用下面参照图4到6所述的技术之一来解决特征交互，而在本发明的一些其它实施例中，可以应用一些其它技术来解决特征交互。无论如何，本领域的普通技术人员在阅读了本公开之后都可以清楚地知道如何构建和使用能够执行任务360的本发明实施例。

在任务360之后，终止执行图3的方法。

图4描述了依照本发明第二示例性实施例的用于执行任务360的第一技术的流程图。在这种第一技术中，不变地将优先级给予较早激活的特征(即，特征f1)，而没有任何其它考虑(例如，特征f1和f2的性质、在特征f1被激活和特征f2被调用之间经过了多长时间等)。

在任务410中，拒绝激活特征f2。本领域的普通技术人员应当懂得，在一些实施例中，该拒绝可能伴随有为什么不激活特征f2的某种通告或说明，而在一些其它实施例中，可能拒绝激活而没有任何伴随动作。

在完成了任务410之后，终止图4的技术和图3的方法。

图5描述了依照本发明第二示例性实施例的用于执行任务360的第二技术的流程图。在这种第二技术中，不变地将优先级给予较晚激活的特征(即，特征f2)，而没有任何其它考虑。本领域的普通技术人员在阅读了本公开之后可以清楚地知道，描绘在图5中的任务可以同时或以与所描绘的顺序不同的顺序执行。

在任务510中，以公知的方式去活特征f1。

在任务520中，以公知的方式激活特征f2。

本领域的普通技术人员应当懂得，在本发明的一些实施例中，任务510和520可能伴随有这些动作的某种通告或说明，而在一些其它实施例中，可能没有任何通告或说明。

在完成了任务520之后，终止图5的技术和图3的方法。

图6描述了依照本发明第二示例性实施例的用于执行任务360的第三技术的流程图。在这种第三技术中，通过指定给特征的优先级来确定特征优先。本领域的普通技术人员在阅读了本公开之后可以清楚地知道，描绘在图6中的任务可以同时执行或以与所描绘顺序不同的顺序执行。

任务610检验特征f2是否具有比特征f1更高的优先级。如果不是，执行前进到任务620，否则，执行在任务630继续。

在任务620中，拒绝激活特征f2。本领域的普通技术人员应当懂得，在一些实施例中，该拒绝可能伴随有为什么不激活特征f2的某种通告或说明，而在一些其它实施例中，可能拒绝激活而没有任何伴随动作。

在完成了任务620之后，终止图6的技术和图3的方法。

在任务630中，以公知的方式去活特征f1。

在任务640中，以公知的方式激活特征f2。

本领域的普通技术人员应当懂得，在本发明的一些实施例中，任务630和640可能伴随有这些动作的某种通告或说明，而在一些其它实施例中，可能没有任何通告或说明。

在完成了任务640之后，终止图6的技术和图3的方法。

本领域的普通技术人员应当懂得，在本发明的一些其它实施例中，可能有利于特征f2而不是有利于特征f1地打破特征f1和f2之间的优先级的“平分”，并且，本领域的普通技术人员在阅读了本公开之后可以清楚地知道如何构建和使用这样的可替代实施例。

本领域的普通技术人员应当懂得，图3至6的方法可以结合多种多样的电话平台和协议(例如，基于会话发起协议[SIP]的网际协议语音[VoIP]电话、通过公共交换电话网络[PSTN]的传统电路交换电话等)来实现，并且，本领域的普通技术人员在阅读了本公开之后可以清楚地知道如何针对这样的平台和协议来构建和使用基于这种方法的本发明实施例。

用于具有多分支信令路径的呼叫的呼叫中间检测

本发明的第三示例性实施例能够为具有多分支信令路径的呼叫检测和解决特征交互。第三示例性实施例的技术可以与第一和第二示例性实施例的那些技术组合，以便为具有多于两个端点和/或桥接通道的多分支呼叫提供呼叫中间的特征交互检测和解决。

图7描绘了依照本发明第三示例性实施例的为具有多分支信令路径的呼叫检测和解决特征交互的第一方法的流程图。本领域的普通技术人员在阅读了本公开之后可以清楚地知道，描绘在图7中的任务可以同时执行或以与所描绘顺序不同的顺序执行。

在任务710中，以公知的方式接收指示为具有多分支信令路径的呼叫的分支L调用特征的信号。

在任务720中，相应地更新分支L的特征状态信息，并且将其存储在网络中的适当节点处。本领域的普通技术人员应当懂得，在本发明的一些实施例中，可以将特征状态信息存储在如下面参照第四示例性实施例所述的一个或多个背对背用户代理(B2BUA)处，而在一些其它实施例中，可以将特征状态信息存储在诸如交换机、服务器、专用交换机(PBX)等的一些其它类型的节点处。无论如何，本领域的普通技术人员在阅读了本公开之后都可以清楚地知道如何构建和使用能够执行任务720的本发明实施例。

在任务730中，以公知的方式沿着呼叫的信令路径传播更新后的特征状态信息。

在任务740中，如有必要，跨越信令路径的分支进行地址映射。例如，沿着信令路径的信令单元可以除去要不然将在信令信息中携带的沿着路径的一些部分的信令单元的地址。这样的信令单元还可以改变要不然将在信令信息中携带的其它信令单元和端点的地址信息。这样的映射和变换用于隐藏内部信令拓扑的细节不让外部信令单元和端点看见，并且允许改变一个或多个端点不可见的信令路径。任务740中的地址映射将实际处于呼叫中的端点的一致看法提供给特征交互检测规则。

任务750检验调用的特征是否与(i)呼叫信令路径的不同分支的特征或(ii)分支L的另一个特征交互。如果是，那么，转到任务770执行，否则，继续执行任务760。

在任务760中，以公知的方式激活特征。在任务760之后，终止执行图7的方法。

在任务770中，解决特征交互。本领域的普通技术人员应当懂得，存在多种多样的可以解决特征交互的方式。例如，在本发明的一些实施例中，可以应用上面参照图4到6所述的技术之一来解决特征交互，而在本发明的一些其它实施例中，可以应用一些其它技术来解决特征交互。无论如何，本领域的普通技术人员在阅读了本公开之后都可以清楚地知道如何构建和使用能够执行任务770的本发明实施例。

在任务770之后，终止执行图7的方法。

图8描绘了依照本发明第三示例性实施例的为具有多分支信令路径的呼叫检测和解决特征交互的第二方法的流程图。本领域的普通技术人员在阅读了本公开之后可以清楚地知道，描绘在图8中的任务可以同时执行或以与所描绘顺序不同的顺序执行。

在任务810中，接收指示新分支将被加入呼叫中或新分支已经被加入呼叫中的信号。

在任务820中，以公知的方式沿着呼叫的信令路径传播新分支的特征状态信息。

在任务830中，如有必要，跨越信令路径的分支进行地址映射。例如，沿着信令路径的信令单元可以除去要不然将在信令信息中携带的沿着路径的一些部分的信令单元的地址。这样的信令单元还可以改变要不然将在信令信息中携带的其它信令单元和端点的地址信息。这样的映射和变换用于隐藏内部信令拓扑的细节不让外部信令单元和端点看见，并且允许改变一个或多个端点不可见的信令路径。任务830中的地址映射将实际处于呼叫中的端点的一致看法提供给特征交互检测规则。

任务840检验新分支的任何特征是否与呼叫的任何现有分支的任何特征交互。如果是，那么，转到任务860执行，否则，继续执行任务850。

在任务850中，以公知的方式激活特征。在任务850之后，终止执行图8的方法。

在任务860中，解决特征交互。本领域的普通技术人员应当懂得，存在多种多样的可以解决特征交互的方式。例如，在本发明的一些实施例中，可以应用上面参照图4到6所述的技术之一来解决特征交互，而在本发明的一些其它实施例中，可以应用一些其它技术来解决特征交互。无论如何，本领域的普通技术人员在阅读了本公开之后都可以清楚地知道如何构建和使用能够执行任务860的本发明实施例。

在任务860之后，终止执行图8的方法。

本领域的普通技术人员应当懂得，图7和8的方法可以结合多种多样的电话平台和协议(例如，基于会话发起协议[SIP]的网际协议语音[VoIP]电话、通过公共交换电话网络[PSTN]的传统电路交换电话等)来实现，并且，本领域的普通技术人员在阅读了本公开之后可以清楚地知道如何针对这样的平台和协议来构建和使用基于这种方法的本发明实施例。

使用背对背用户代理的VoIP实现

第四示例性实施例提供了能够执行与上述第一、第二和第三示例性实施例相关联的任务的网际协议语音(VoIP)呼叫的实现。因此，第四示例性实施例可以处理呼叫中间的特征交互检测和解决、具有多分支信令路径的呼叫、多方呼叫、以及具有桥接通道的呼叫。

第四示例性实施例的手段实际上是分布式的，这有助于将它应用于网际协议语音(VoIP)电话和会话发起协议(SIP)。被激活的每个特征将它的触发方和连接类型包括在SIP消息中。如果在消息中已经存在一个或多个项目，则对照当前特征的描述来检验这些项目。因此，无论哪里需要都执行该算法，而且不需要中央特征管理器。这使得该手段高度可伸缩。

对于会话发起协议(SIP)，标准SIP首标不提供足够的细节，因此，已经定义了携带所需信息的附加首标并可以包括在SIP消息中。已经定义了两个专用首标来携带这种手段所需的信息：P-ConType和P-Forwarded-To。P-ConType首标包含在当前会话上已经激活的特征的描述，而P-Forwarded-To首标包含当INVITE请求被重定向到另一方时受邀方的ID。

在特征排序期间，检验当前SIP消息中的P-ConType首标。如果未发现这样的首标，那么，以前没有激活其它特征，因此，不会发生特征交互。在这样的情况下，将描述当前特征的新P-ConType首标插入消息中。例如，对于转移特征，该首标是：

P-ConType：ID＝Forward；TP＝sip：bob@d254203.com；

OrigFrom＝chris@discus.com；OrigTo＝bob@d254203.com；

FinalFrom＝chris@discus.com；FinalTo＝alice@d254203.com

该首标包含ID字段、触发方和连接类型。ID标识在首标中描述的特征。TP包含触发方，而其余四个字段对应于连接类型的四个字段。

依照第四示例性实施例，背对背用户代理(B2BUA)存储并维护呼叫分支的特征状态和信令信息，并且沿着信令路径传播这个信息。在技术上公知的是，背对背用户代理(B2BUA)起会话发起协议(SIP)呼叫的两端的用户代理的作用，并负责处理从呼叫建立到终止，呼叫的两端之间的所有SIP信令。对于SIP客户机，背对背用户代理在一侧起用户代理服务器的作用，而在另一侧(背对背)起用户代理客户机的作用。背对背用户代理(B2BUA)也可以提供诸如呼叫管理(例如，记费、自动呼叫断开、呼叫转移等)、网络联网(也许协议自适应)、网络内部(例如，专用地址、网络拓扑等)的隐藏、两条呼叫分支之间的编解码转换等的附加功能。在技术上还公知，背对背用户代理(B2BUA)可以是透明B2BUA或监视B2BUA，或可以起会话边界控制器(SBC)的作用。

透明B2BUA

对于透明B2BUA，存在两种情况：在第一种情况下，透明B2BUA可以携带按规定转发的P-ConType首标，并且能够发回由交互引起的特征禁用。发生这种情况而不改变首标中的任何信息。

在第二种情况下，透明B2BUA修改一些首标中的信息，这可以影响特征交互手段。例如，通过改变From/To/RequestURI而改变端点的身份，破坏那些首标和包含在P-ConType首标中的信息之间的映射。而且，P-ConType首标仍然可能泄露各方的‘以前’身份。因此，B2BUA需要进行与变更后的SIP首标中相同的对P-ConType首标中的值的地址映射。对于上游和下游消息，这种映射应当都会发生。

图9描绘了依照本发明的第四示例性实施例的第二种情况的示例性会话发起协议(SIP)信令路径900。如图9所示，信令路径900包含如图所示互连的用户代理901-1和901-2、服务器902-1和902-2、和透明背对背用户代理(B2BUA)903，并且包含两条呼叫分支904-1和904-2。

在技术上公知，用户代理901-1和901-2是会话发起协议(SIP)端点。

在技术上公知，服务器902-1和902-2是会话发起协议(SIP)服务器。

如上所述，透明背对背用户代理(B2BUA)903对P-ConType首标以及其它会话发起协议(SIP)首标进行地址映射。用户代理901-1和901-2、服务器902-1和902-2、和透明背对背用户代理(B2BUA)903之间的会话发起协议(SIP)消息以公知的方式描绘在信令路径900的下面。在信令路径包含两个或更多个透明B2BUA(即，链接的B2BUA)的情况下，在每个B2BUA都发生映射。因此，本领域的普通技术人员应当懂得，可以将链接的B2BUA的行为看作一系列单个B2BUA情况。

监视B2BUA

会话的监视可以是不可见的(例如，通过诸如合法侦听等的特征)，也可以是可见的(例如，通过诸如会话记录等的特征)。不可见监视应当是呼叫中的其它端点检测不到的，因此，来自监视端点的信令需要隐藏起来不让其它端点看见。可以应用B2BUA来提供这种功能；然而，存在可能因P-ConType首标而受到损害的隐私问题。

当通过比受监视呼叫更高的优先级使监视不可见时，诸如合法侦听或监督监视的特征应当具有超过任何特征交互问题的优先级。换句话说，即使这意味着可能不能处理由监视引起的一些交互，监视也应当保持不可见。这种情形的例子是当监视方在受监视呼叫的各方之一的屏蔽列表上时。在这样的情况下，来自监视方的特征的P-ConType首标将不被发送给呼叫的其它各方，并且，呼叫建立决不应当由于特征交互(禁用特征之一)而重复，因为这可以在其它端点处检测到并泄露监视。取而代之，通过将优先级给予监视方的特征来解决这样的交互。

当通过与受监视呼叫相等或更低的优先级使监视方不可见时，应当禁止监视。这种情形的例子是当激活对呼叫的监视，并且具有不允许监视呼叫的特征的一方(例如，首席执行官等)加入该呼叫时。

当监视可见时，不存在隐私问题，因此，P-ConType首标可以以正常方式被包括在消息中。另外，可以像在前面示例性实施例中所述的那样进行特征交互解决，附加条件是对于将B2BUA作为发起或终止点的呼叫分支，在B2BUA处解决呼叫分支内的特征交互。

注意，可能具有跨越不能使其一致的多方呼叫的呼叫分支的特征交互。在这样的情况下，应当非对称地对不同分支分析特征交互。

会话边界控制器(SBC)

会话边界控制器(SBC)的主要功能是隐藏域路由和端点身份不让外部端点和信令单元看见。当然，这种功能与第四示例性实施例的特征交互检测手段相冲突：尤其是，会话边界控制器(SBC)将不转发P-ConType首标中的信息，因为这样做可能会泄露身份和由那些身份使用的特征。

但是，通过隔离每个域内的特征交互逻辑，一个域内的特征交互分析仍然是可能的。虽然这将解决在一个域内使用的服务之间的交互，但不会掌握涉及来自不同域的服务的交互。

可替代地，会话边界控制器(SBC)能够以不公开内部拓扑或信令的方式来映射特征交互反馈。例如，可能存在从P-ConType首标中滤出以防止在域外看见的被隐藏特征的列表。作为另一个例子，可以只让公开端点在域外可见。当然，存在折衷，因为任何这样的手段都为了换取加强隐私的好处而对管理一些交互的能力产生一些影响。本领域的普通技术人员应当懂得，应用的具体策略(例如，除去所有P-ConType首标、只除去一些P-ConType首标、只处理局域内的特征交互等)是取决于特定域的隐私要求的实现决策，因此，使这样的策略是可配置的是有利的。

本领域的普通技术人员应当懂得，尽管第四示例性实施例的主要任务(例如，保持和传播特征状态信息、地址映射等)由一个或多个背对背用户代理(B2BUA)完成，但在一些其它实施例中，这些任务的一些或全部可以由一个或多个其它数据处理系统(例如，交换机、服务器、专用交换机(PBX)等)完成，并且，本领域的普通技术人员在阅读了本公开之后可以清楚地知道如何构建和使用本发明的这种实施例。本领域的普通技术人员应当进一步懂得，尽管第四示例性实施例是在网际协议语音(VoIP)电话和会话发起协议(SIP)的背景下公开的，但第四示例性实施例的技术也可以适用于其它类型的电话平台和协议，并且，本领域的普通技术人员在阅读了本公开之后可以清楚地知道如何构建和使用本发明的这样可替代实施例。

应当明白，该公开仅仅讲述了示例性实施例的一个例子，本领域的普通技术人员在阅读了本公开之后可以容易地设想出本发明的许多变体，和本发明的范围由所附权利要求决定。