CN105308924A - 用于实现通信禁止服务的方法和装置 - Google Patents

Abstract

一种在IP多媒体子系统IMS网络内针对进行中的IMS会话或早期会话阶段中的IMS会话实现通信禁止CB服务的方法。该方法包括，在IMS网络内的应用服务器AS处，解析与会话相关的SIP消息，以检测用以向该会话添加一个或多个媒体流的尝试。CB服务规则被应用于确定媒体流被添加的允许性。如果不允许媒体流被添加，则采取动作以阻止媒体流的添加，否则允许媒体流添加进行。

Description

用于实现通信禁止服务的方法和装置

技术领域

本发明涉及实现IP多媒体子系统情境中的通信禁止服务的方法和装置。

背景技术

IP多媒体子系统(IMS)是由第三代合作伙伴关系项目(3GPP)定义的技术，以在移动通信网络上提供IP多媒体服务。3GPP规范TS23.002中一般性地描述了IMS的构架和一般特征，TS23.228中更具体地进行了描述。通过服务集成和交互，IMS提供重要特征以丰富终端用户的人与人之间的通信体验。IMS实现了基于IP的网络上全新和丰富的人与人(客户端到客户端)以及人与内容(客户端到服务器)通信。IMS利用会话发起协议(SIP)建立和控制用户终端(或者用户终端和应用服务器)之间的呼叫或会话。由SIP信令承载的会话描述协议(SDP)被用于描述和协商会话的媒体组件。当SIP被作为用户到用户协议创建时，IMS允许运营商和服务提供商控制用户接入服务以及相应地向用户收费。其他协议如实时传输协议和实时传输控制协议(RTP/RTCP)被用于媒体传输和控制。

IMS逻辑上被部署进所谓的“核心网络”层和所谓的“服务层”中。核心网络层是由功能性实体(下文简要描述)实现的。服务层主要包括“应用服务器”，其被布置用于向用户终端(下文称为用户设备(UE))提供服务。这些应用服务器经由IMS被连接，以及/或被布置为通过执行特定的基于服务的逻辑在服务提供中进行中介，例如在某些情况下转移呼入多媒体会话。

当前的IMS标准提供用于通信禁止(CB)的服务，以使得网络能够控制订户接入服务。3GPPTS24.611中描述了IMS中3GPP标准化的CB服务的当前状态。这个标准遵从并扩展了用于TS24.088中考虑的电路交换(CS)和分组交换(PS)网络中呼叫限制补充服务的基本原则。

TS24.611特别描述了在会话初始请求满足CB服务订户的简档中规定的CB服务需求的事件中，IMSAS对该请求执行CB服务的动作。根据条件和动作的规则，定义了这些服务需求，由同一规范还进一步参考RFC4745定义了这些规则。尤其是，TS24.611定义了呼入通信禁止(ICB)服务以及呼出通信禁止(OCB)，该ICB服务是代表终止用户拒绝满足某些规定的或配置的条件的呼入通信的服务，该OCB代表始发用户拒绝满足某些规定的或配置的条件的呼出通信的服务。图1图示了该功能构架，假设在两个订户UE-A和UE-B之间建立会话，UE-A为始发方，UE-B为终止方。

现有规范除了会话发起不包括任何(与ICB或OCB相关的)对用户场景的规定。当前的方法可能为订户在某些情况下规避CB服务创造了机会。

发明内容

本发明的一个目的是克服或者至少减轻上面讨论的CB相关问题。这一目的和其他目的的实现是通过引起IMSAS解析与进行中的IMS会话或早期会话阶段中的IMS会话有关的SIP消息，以标识和控制针对该会话的媒体变化和添加。

根据本发明的第一方面，提供一种在IP多媒体子系统IMS网络内针对进行中的IMS会话或早期会话阶段中的IMS会话实现通信禁止CB服务的方法。该方法包括，在IMS网络内的应用服务器AS处，解析与会话相关的SIP消息，以检测用以向会话添加一个或多个媒体流的尝试。CB服务规则被应用以确定媒体流被添加的允许性。如果不允许媒体流被添加，则采取动作以阻止媒体流的添加，否则允许媒体流添加进行。

本发明的实施例可被用于针对欺诈和不恰当的收费，保护订户和/或网络运营商。

在媒体流不被允许的事件中可采取的动作可以包括在AS处拒绝请求。

在所述消息是与早期会话阶段的IMS会话相关的SIPPRACK请求的情况下，该动作可包括在上游方向从SIPPRACK请求中移除未被允许的媒体提议(offer)，转发该请求到其目的用户代理，以及在下游方向在响应中拒绝该媒体流。

SIP消息可以是可靠的SIP响应，所述动作可包括在转发前在SIP响应中禁止个体的未被允许的媒体流。

CB服务规则可被应用于包含会话描述协议SDP提议的SIP消息。

CB服务规则可以是在会话发起期间所应用的相同的规则。

该方法可包括仅应用至少包含一个媒体条件的那些CB服务规则。

该方法可包括存储来自发起进行中的IMS会话的请求和任何相关响应的会话参数，以及随后在应用CB服务规则以确定媒体流被添加的允许性时，使用这些会话参数。

根据本发明的第二个方面，提供一种用于在IP多媒体子系统IMS网络内针对进行中的IMS会话或早期会话阶段中的IMS会话实现通信禁止CB服务的应用服务器AS。该装置包括SIP消息解析器，用于解析与会话相关的SIP消息，以检测用以向该会话添加一个或多个媒体流的尝试；以及策略单元，用于应用CB服务规则以确定媒体流被添加的允许性。该装置进一步包括策略实施单元，被配置为如果不允许媒体流被添加，则采取动作以阻止媒体流的添加，否则允许媒体流添加进行。

策略单元可被配置为仅应用至少包含一个媒体条件的那些CB服务规则。

策略实施单元可被配置为采取以下动作中的一个：

-拒绝包含未被允许请求的SIP消息；

-禁用未被允许的媒体流，该未被允许的媒体流在可靠响应中所接收的媒体提议中被添加或修改；

-完全移除在SIPPRACK中包含未被允许的媒体流的媒体提议。

所述应用服务器可进一步包括数据记录器，用于存储来自发起进行中的IMS会话的请求和任何相关响应的会话参数；所述策略单元被配置为在应用CB服务规则以确定媒体流被添加的允许性时，使用这些会话参数。

附图说明

图1示出了在IMS内实现的始发和终止通信禁止服务的示意图；

图2示出了在早期会话阶段或已建立的会话阶段与通信会话更新相关的信令，使用SIPUPDATE；

图3示出了在早期会话阶段或已建立的会话阶段与通信会话更新相关的信令，使用SIPPRACK；

图4示出了在早期会话阶段或已建立的会话阶段与通信会话更新相关的信令，其中用户代理中的一个在会话内“可靠的响应”中包括媒体描述，这个描述构成媒体提议；

图5是示出了在早期会话阶段或已建立的会话阶段中针对通信会话更新的CB服务的实现的流程图；以及

图6示出了与图5相一致的被配置为实现CB服务的IMS应用服务器的示意图。

具体实施方式

如上面已经考虑的，在IP多媒体子系统情境中，3GPPTS24.611和TS24.088描述了通信禁止(CB)服务，其包括呼出CB(OCB)和呼入CB(ICB)。然而，现有技术关注的唯一的用户场景是会话发起，即在IMS会话的发起期间CB服务的实现。认识到的是，通过发生在会话过程中(以及在早期会话阶段中)以及来自始发或终止用户代理(UA)始发的会话更新，绕过来自CB服务的呼叫限制是可能的。这尤其与操纵会话中所使用的媒体的会话更新相关。其结果，除了别的以外，包括向订户提议的高级服务的威胁，例如，用户可能建立语音电话并为语音电话付费，随后在呼叫中添加“免费的”视频，而可能的是用户为无法使用CB进行阻止的服务受到过多收费。进一步考虑后一种问题，当例如公司负责支付电话账单，不允许其员工拨打视频电话(因为其导致额外收费或由于安全原因)时，这可能是有问题的。同样还可能产生问题的是，当私人订户在漫游时，由于额外收费，希望阻止拨打/接收视频电话或被升级为视频电话(在某些国家接收电话也会被收费)，或者当他或她希望避免在高峰时间使用某些服务时。

通过两个主要操作，通信会话更新可以发生在早期会话阶段或已建立的会话阶段。首先，为了更新会话或改变会话参数，参与的用户代理(UA)中的一个能够在会话内生成SIP请求。这可以例如通过如图2中所示的SIPINVITE(或使用SIPUPDATE代替INVITE)或使用如图3中的SIPPRACK完成。在图中，多媒体电话应用服务器(MTAS)被配置为代表UE-A实CB服务。MTAS是MMTelAS的具体实现。第二种方式涉及用户代理之一在会话内的“可靠响应”中包括媒体描述，该媒体描述构成媒体提议。在图4中示出了这种情况。

提出解决这个问题的方案是利用现有CB服务的扩展而非为此目的专门开发新服务。这提供了两个优点，即：

(1)将新功能包含进现有具有CB的解决方案(例如MMTel模拟服务)相对直接明了；

(2)扩展的服务能够重复利用已有的(标准化的)用于禁止会话起始的通信规则，尽管有一些适应性的修改。归因于如下原因，这尤其有吸引力，该原因是可望实现的是适用于会话发起的规则应该在整个会话存在期被实施，即不太可能要求在会话发起期间有第一组规则并且针对会话存在期的其他时间有不同的第二组规则。

为了确定具有受限媒体实施(RME)的CB服务是否应该禁止会话更新，用于命令会话更新的消息必须在相关AS处例如MTAS处被调查。重要的是，RME必须仅在由媒体提议添加或修改的媒体流上被激活。如果不是这种情况，那么存在成功协商的进行中的会话可能被CB服务的介入而中断的风险。而且，同样重要的是，CB服务不干扰其他会话信令，因为任何这样的干扰可能影响服务。

当具有RME的CB服务在AS中被触发，具有RME的CB服务将应用为这个服务定义并提供给服务订户的标准规则集合。然而，对于与会话更新相关联的用户场景，来自标准规则的条件评估并非不重要。

要注意的第一点是，规则集合必须被过滤，以便只有构成媒体约束的规则得到应用。根据RFC4547，这意味着规则必须包含至少一个<媒体>条件。而且，与会话发起的CB形成对比，为了能够评估标准的规则条件，会话更新的CB必须追踪和保存会话上下文。这是由于以下的原因：

1)需要用于评估条件的会话参数可能在触发会话更新的消息中没有正确的内容或格式；

2)会话更新可能由通信会话的接收方触发，这种情况下，在AS节点中执行的CB服务集合被逆转，即，在OCB先前被执行处执行ICB，反之亦然。

在已经标准化的CB条件中，必须采用在会话发起过程中存储的会话上下文评估至少下列条件：

●<标识>

●<其他-标识>

●<匿名>

●<通信-转移>

●<漫游>

●<国际>

●<国际-exHC>

●<外部-列表>

当CB服务(在给定的AS内实施)确定会话更新应该被禁止且该会话更新在SIP请求而非PRACK(例如INVITE或者UPDATE)中已经被接收时，根据现有标准，简单地通过拒绝该请求，该服务能够完成。一个例外是，当在可靠SIP响应中已经命令了会话更新要被禁止时(图4)。在这种情况下，对AS来说最有效的是，在禁用被规定的CB规则限制的媒体流(在提议中所请求的)之后转发该可靠响应。这样做的好处是先前成功协商的会话不被中断得以继续。不利的是会话更新发起者没有被通知该限制。如果这样的通知是需要的，必须独立地解决这个问题。RFC3264将禁用在媒体提议中的媒体流定义为设置流的媒体线的端口属性为“0”。为了禁用在提议中受限的流，CB服务必须考虑适用于会话更新(如上所述)的完整规则集合，以及禁用每个被添加或修改且其媒体类型以任何匹配规则与媒体条件中的类型相匹配的媒体流。

当在PRACK中已经指令了要被禁止的会话更新时(图3)，在AS转发PRACK请求时，AS应该从PRACK请求中移除媒体提议。在向PRACK的200OK响应中，为了用信号将提议已经被拒绝反馈回至UA，AS应该发送所有媒体流被禁止的媒体应答。这种在PRACK中处理具有受限媒体的媒体提议的方式比禁用媒体流更好，与在可靠应答中处理媒体提议类似。

图5是进一步示出在IP多媒体子系统(IMS)网络内针对进行中的IMS会话或早期会话阶段中的IMS会话实现通信禁止CB服务的流程图。接着会话的发起(S1)，IMS应用服务器(AS)解析与该会话相关的SIP消息，以检测添加一个或多个媒体流到该会话的尝试(S2)。在AS内实现的CB服务应用CB服务规则以确定媒体流被添加的允许性(S3，S4)。如果不允许媒体流被添加，则采取动作阻止其添加(S5)，否则允许媒体流添加进行(S6)。

现在考虑图6，其示意性示出了IMS应用服务器1。该AS可以是被配置为向订户提供IMS多媒体电话服务的MMTelAS。为了实现要求的服务，该AS将包括某些标准功能，与标准功能关联的组件未在图6中示出。仅示出了与新CB服务功能关联的组件。这些组件包括SIP消息解析器2，其可以是独立的实体或可包括对现有消息解析器的扩展。该SIP消息解析器被配置为解析与建立的会话或在早期会话阶段的会话相关的SIP消息，以便检测添加一个或多个媒体流到该会话的尝试(由UA中的一个所进行的)。该AS进一步包括策略单元3，其应用CB服务规则以确定媒体流被添加的允许性；策略实施单元4被配置为，如果不允许媒体流被添加，则采取动作以阻止添加，否则允许媒体流添加进行。

图6进一步示出了数据记录器5，其用于存储来自发起进行中的IMS会话的请求和任何相关响应的会话参数。策略单元3能够访问存储的数据并当应用CB服务规则以确定媒体流被添加的允许性时使用该数据。

图6中的AS可采用处理器、数据存储器和软件代码存储器的组合实现。该软件将被配置为实现上述的功能。独立的处理器和存储器可被提供用于图6中示出的每个功能组件。

本领域技术人员应该理解的是，在不脱离本发明保护范围的前提下可以对上述实施例进行不同修改。

Claims (16)

1.一种在IP多媒体子系统IMS网络内针对进行中的IMS会话或早期会话阶段中的IMS会话实现通信禁止CB服务的方法，所述方法包括：

在所述IMS网络内的应用服务器AS处，解析(S2)与所述会话相关的SIP消息，以检测用以向所述会话添加一个或多个媒体流的尝试；

应用CB服务规则以确定所述媒体流被添加的允许性(S3，S4)；以及

如果不允许所述媒体流被添加，则采取动作以阻止其添加(S5)，否则允许所述媒体流添加进行(S6)。

2.根据权利要求1所述的方法，其中所述SIP消息是与所述会话相关的SIPUPDATE和/或REINVITE消息。

3.根据权利要求2所述的方法，其中所述动作(S5)包括在所述AS处拒绝所述请求。

4.根据权利要求1所述的方法，其中所述消息是与早期会话阶段中的IMS会话相关的SIPPRACK请求。

5.根据权利要求4所述的方法，其中所述动作(S5)包括在上游方向从所述SIPPRACK请求中移除未被允许的媒体提议，向其目的用户代理转发所述请求，以及在下游方向在响应中拒绝所述媒体流。

6.根据权利要求1所述的方法，其中所述SIP消息是可靠的SIP响应，以及所述动作(S5)包括在转发前在所述SIP响应中禁用个体的未被允许的媒体流。

7.根据前述权利要求中的任一项权利要求所述的方法，其中所述CB服务规则被应用于包含会话描述协议SDP提议的SIP消息。

8.根据前述权利要求中的任一项权利要求所述的方法，其中所述CB服务规则是在所述会话的发起期间所应用的相同的规则。

9.根据前述权利要求中的任一项权利要求所述的方法，其中所述CB服务规则已经被所述AS针对给定的IMS订户从归属订户服务器HSS获得。

10.根据前述权利要求中的任一项权利要求所述的方法，并且包括仅应用至少包含一个媒体条件的那些CB服务规则。

11.根据前述权利要求中的任一项权利要求所述的方法，并且包括存储来自发起所述进行中的IMS会话的请求和任何相关的响应的会话参数，以及随后在应用CB服务规则以确定所述媒体流被添加的允许性时使用这些会话参数。

12.一种用于在IP多媒体子系统IMS网络内针对进行中的IMS会话或早期会话阶段中的IMS会话实现通信禁止CB服务的应用服务器AS，所述装置包括：

SIP消息解析器(2)，用于解析与所述会话相关的SIP消息，以检测用以向所述会话添加一个或多个媒体流的尝试；

策略单元(3)，用于应用CB服务规则以确定所述媒体流被添加的允许性；以及

策略实施单元(4)，被配置为如果不允许所述媒体流被添加，则采取动作以阻止其添加，否则允许所述媒体流添加进行。

13.根据权利要求12所述的应用服务器，其中所述SIP消息解析器(2)被配置为标识和解析以下各项中的一项或多项：SIPINVITE、UPDATE、RACK以及包含媒体提议的可靠响应消息。

14.根据权利要求12或13所述的应用服务器，其中所述策略单元(3)被配置为仅应用至少包含一个媒体条件的那些CB服务规则。

15.根据权利要求12-14中任一项所述的应用服务器，其中所述策略实施单元(4)被配置为通过以下各项中的一项来采取所述动作：

拒绝包含未被允许请求的SIP消息；

禁用未被允许的媒体流，所述未被允许的媒体流在可靠响应中所接收的媒体提议中被添加或修改；

在SIPPRACK中完全移除包含未被允许的媒体流的所述媒体提议。

16.根据权利要求12-15中任一项所述的应用服务器，并且包括数据记录器(5)，所述数据记录器(5)用于存储来自发起所述进行中的IMS会话的请求和任何相关的响应的会话参数，所述策略单元(3)被配置为在应用CB服务规则以确定所述媒体流被添加的允许性时，使用这些会话参数。