[发明专利]通过第三方设备进行呼叫建立和控制

说明书

技术领域

本发明涉及通过第三通信网络设备来建立和控制在两个通信设备之间建立的呼叫。

背景技术

这种问题是通过缩写词3PCC(第三方呼叫控制)而为本领域技术人员所知的。这可以通过图1看出，图1中网络设备C希望触发两个设备A和B之间的通信会话(或呼叫)的建立。可以通过网络设备C所收到的激励来引发这个触发，网络设备C可以属于另一种类型。

在现代通信网络中，通信会话(多媒体或其他)通过交换信令消息来建立，特别是符合SIP协议的信令消息。这个协议由IETF的RFC 3261说明，其标题为“Session Initiation Protocol”。

本领域技术人员知道如何利用SIP协议在通信网络上实现第三方呼叫控制(3PCC)。

美国专利申请US 2006/020036说明了这种呼叫控制(3PCC)。然而，它相当基础并且只能使得呼叫被触发。一旦通信被建立，发起人就不能控制呼叫，他不再能够修改它或结束它。发起人也不能够获得关于通信状态的信息(也就是说当呼叫结束通知，其持续时间等)。

这个解决方案也不再对应于由RFC 3725定义的第三方呼叫控制。

IETF的RFC 3725的标题是“Best Current Practices for Third PartyCall Control(3pcc)in the Session Initiation Protocol(SIP)”。其描述了几种具有主要缺点的解决方案，以及推荐的解决方案。

然而，这个推荐的解决方案也具有许多缺点。

首先，文件RFC 3725本身承认其推荐的方案所设立的情形具有这样的缺点：即主叫终端A的用户将在有效进行呼叫之前听到较长的静音。

可以通过实现通告服务器来抵消这个缺点，该通告服务器播放保持音乐或信息消息。然而，这个解决方案需要部署附加的设备并且使得呼叫建立过程更复杂。

此外，RFC 3725所推荐的解决方案需要设备C用作SIP协议的B2BUA(背靠背用户代理)。这种B2BUA的缺点是它并未在RFC 3261及各种IETF的各项工作中被很好地说明。因此，在针对并不简单的情形进行部署之前，需要大量的规范和开发工作。

RFC 3725仅介绍了简单的操作场景，但是更一般的场景需要在几种其他情形下设备C的行为的规范：例如，如果被叫用户具有几个终端，或如果会话必须与通信网络的其他服务交互，或者是在符合标准化IMS(IP多媒体子系统)结构的实现的背景下，所述IMS结构由3GPP和TISPAN主体指明，其要求利用RFC 3262中描述的扩展(也就是说“PRACK”消息)来建立呼叫从而提供服务质量保证。要考虑的其他情形包括媒体重新协商、取消、对立情形(当主叫方发送取消消息以及被叫方发送重新协商消息时采取什么行为？)。

在所有这些情形中，针对潜在重新传输、差错场景等，设备C内的用于管理SIP协议的状态机的规范工作非常复杂并且在实践中使得解决方案难以使用。

此外，B2BUA型设备要求上下文信息得以维持从而管理多媒体会话之间的交互。这带来将这个上下文信息存储到存储器中的问题。首先这需要很大的体积，即很大的存储容量，其次需要提供用于保护上下文信息的安全以解决设备C的可能故障的机制。

最后，RFC推荐的解决方案是基于“无提供的”SIP邀请消息的(即其不提供任何建立多媒体会话的手段)。然而，这些消息不总是被通信设备适当地支持的。所提出的解决方案因而会导致互操作性问题。

出于上面所有的原因，RFC 3725所阐述的解决方案并不令人满意。

另一现有技术涉及标题为“3pcc using the REFER method”的文件“draft-bhatia-3pcc-refer-01.txt”。

根据这个解决方案，控制器设备C发送给代理A一“REFER”型信令消息M₁。这个信令消息包括“Refer-to”报头，其指示了控制器设备C的地址。根据说明了“REFER”消息的RFC 3515，当接收时，代理A发送邀请消息M₂(“INVITE”)给控制器C，控制器C可以将它转发给代理B(消息M₃)。

然而，这个解决方案具有很多缺点。

为使得控制器C能够确定邀请消息M₂是对消息M₁的响应，它必须插入“replace”参数，如该文件的段落4.0中指出的那样。然而，通信代理并不十分能够支持这个参数并且它的使用因而会导致互操作性问题。