[发明专利]应用服务器对Replace参数的替换方法及系统

说明书

技术领域

本发明涉及通信技术领域，尤其涉及一种IMS(IP Multimedia Subsystem，IP多媒体子系统)中，应用服务器对Replace参数的替换方法及系统。

背景技术

3GPP(3rd Generation Partner Project，第三代合作伙伴计划)定义AS(Application Server，应用服务器)在处理SIP(Session Initiation Protocol，会话发起协议)消息时，行为模式可以为Proxy(代理)、Routeing B2BUA(Routeing Back to Back User Agent，路由背靠背用户代理)或InitiatingB2BUA(初始背靠背用户代理)。其中Routeing B2BUA是一种很类似Proxy的处理模式，当AS采用Routeing B2BUA或Initiating B2BUA行为模式时，AS两侧的Dialog ID(会话标识)经由AS修改，AS两侧的Dialog ID将不一样。

按照3GPP 24.229 5.7.5章节的定义，当IMS中的AS收到带有ReplaceHeader(替换头部)的对话的初始请求(Initial request for a dialog)时，需要检查AS是否为Routeing B2BUA或Initiating B2BUA行为模式。如果是，并且此AS就是Replace Header所携带的Dialog ID的替换者，则需要在转发此初始请求前将Replace Header的Dialog ID替换。替换的目的是，在此AS前向的网元只能识别Dialog1，无法识别Dialog2，必须由进行Dialog替换的网元(此Routeing B2BUA AS)。

具体流程参见图1，针对Dialog1的请求，AS作为Routeing B2BUA或Initiating B2BUA执行B2BUA行为，使用新的Dialog2转发请求。当收到新的初始请求(使用Dialog3)，且携带有Replace Header为Dialog2时，AS需要将Replace Header修改为Dialog1转发。转发该请求的Dialog可以继续使用Dialog3，也可以使用新的Dialog ID(Dialog4)。

现有技术中存在如下问题：3GPP只是定义了AS收到此类请求后的处理，但是在实际应用时，Dialog3的初始请求可能并不会送到此AS，导致后续网元无法识别Replace Header的Dialog ID(如图1中的Dialog1)。根据RFC3891，无法识别/匹配Replace Header的Dialog ID，接受方可以使用481拒绝请求。

因此，需要提供一种解决方案，保证新的初始请求，如果携带有ReplaceHeader，并且Replace Header所带的Dialog ID曾经被B2BUA行为模式的AS替换，则该Dialog ID可以在被送到前向网元的过程中被重新正确替换，以保证Replace Header可以被正确处理。

发明内容

本发明要解决的技术问题是提供一种应用服务器对Replace参数的替换方法及系统，保证初始请求带有的Replace Header可以被正确替换，解决现有3GPP AS对Relpace参数支持的欠缺带来的影响。

为了解决上述问题，本发明提供了一种应用服务器对Replace参数的替换方法，应用于IP多媒体子系统(IMS)，所述方法包括：

作为路由背靠背用户代理(Routeing B2BUA)或初始背靠背用户代理(Initiating B2BUA)的应用服务器(AS)收到对话的初始请求(Initial requestfor a dialog)，修改所述初始请求的发送方用户的初始过滤规则(iFC)，或修改所述初始请求的接收方用户的iFC，或修改所述接收方的业务相关用户的iFC。

进一步地，所述用户包括用户私有用户身份(PVI)对应的所有公共用户身份(PUI)，或用户别名(alias)。

进一步地，所述AS修改所述iFC具体包括：

由所述AS修改归属用户服务器(HSS)中的iFC，并通过所述HSS修改呼叫会话控制功能(S-CSCF)中的iFC；或者，

由所述AS修改所述HSS及所述S-CSCF中的iFC。

进一步地，所述S-CSCF为所述初始请求的接收方用户的S-CSCF，且所述HSS为所述初始请求的接收方用户的HSS；或者，