用于为IP多媒体子系统补充服务配置和实现通知的方法和设备

摘要

根据本发明的第一方面，提供了一种操作为用户实现IP多媒体子系统(IMS)补充服务的应用服务器(AS)的方法。方法包括配置用于用户的规则，规则具有指定是否要提供通知的动作，并且如果要提供通知，则定义要用于通知的媒体。方法还包括确定规则的条件是否由与用户有关的会话启动协议(SIP)消息满足，并且如果是，则根据动作实现通知。

说明书

 

技术领域

本发明涉及用于为IP多媒体子系统(IMS)补充服务配置和实现通知的方法和设备。更具体地说，本发明涉及用于使得IP多媒体子系统(IMS)用户能够灵活地配置与其补充服务相关联的任何通知的方法和设备。

背景技术

IP多媒体子系统(IMS)是由第三代合作伙伴项目(3GPP)定义为通过移动通信网络提供IP多媒体服务的一种技术。IMS通过服务的集成和交互提供关键特征，以便丰富最终用户人与人的通信体验。IMS允许通过基于IP的网络的新的丰富的人与人(客户端到客户端)及人与内容(客户端到服务器)通信。IMS利用会话启动协议(SIP)设置和控制用户终端（或用户终端与应用服务器）之间的呼叫或会话。SIP信令携带的会话描述协议(SDP)用于描述和协商会话的媒体组件。虽然SIP创建为用户到用户协议，但IMS允许运营商和服务提供商控制用户对服务的访问并相应地向用户计费。其它协议用于媒体传送和控制，如实时传输协议和实时传输控制协议(RTP/RTCP)。

图1以示意图方式示出在GPRS/PS接入网络情况下IMS如何适合移动网络体系结构（IMS当然可通过其它接入网络操作）。如图1所示，IMS包括核心网络和服务网络。呼叫/会话控制功能(CSCF)作为IMS核心网络内的SIP代理操作，并且除其它之外，与诸如边界网关控制功能(BGCF)和媒体资源功能控制器(MRFC)的其它实体对接。代理CSCF (P-CSCF)是用于SIP终端的IMS内的第一联系点；服务CSCF (S-CSCF)提供服务给订户；询问CSCF (I-CSCF)识别正确的S-CSCF，并且经P-CSCF将从SIP终端收到的请求转发到该S-CSCF。

在IMS服务网络内，应用服务器(AS)提供用于实现IMS服务功能性。应用服务器向IMS系统中的最终用户提供服务，并可作为端点通过3GPP定义的Mr接口连接，或者通过3GPP定义的ISC接口由S-CSCF“链接”。在后一情况下，初始过滤准则(IFC)由S-CSCF用于确定在SIP会话建立期间图标应该“链接”哪些应用服务器（或实际用于会话或非会话有关的任何SIP方法）。IFC在IMS注册过程期间作为用户的订户配置文件一部分由S-CSCF从HSS接收。

3GPP TS 22.173 (V11.3.0)和3GPP TS 24.173 (V11.0.0)定义IMS支持的补充服务。例如，IMS支持的标准化补充服务包括但不限于始发识别呈现(OIP)、始发识别限制(OIR)、终止识别呈现(TIP)、终止识别限制(TIR)、通信转移(CDIV)、通信保持(HOLD)、通信禁止(CB)、消息等待指示(MWI)、会议(CONF)、显式通信转移(ECT)、计费通知(AOC)、通信等待(CW)、灵活提醒(FA)、通信等待(CW)、定制提醒音(CAT)及定制响铃信号(CRS)。除标准化补充服务外，IMS应用服务器的供应商还能够配置应用服务器以便实现另外的供应商特定的服务。此类供应商特定服务的示例是灵活通信分布服务。

如3GPP TS 24.604 (V11.0.0)中定义的通信转移(CDIV)服务使得用户能够将满足某些预备或配置的条件的进入通信转移/重定向到另一目的地。3GPP TS 24.604规定，在发生通信转移时，提供CDIV补充服务的应用服务器(AS)可向主叫用户启动通知，以便将转移通知主叫用户（参阅章节4.5.2.6.4）。类似地，定义通信禁止(CB)服务的3GPP TS 24.611 (V11.0.0)也规定，在禁止/拒绝通信时，提供CB补充服务的AS能够向始发用户提供通知（参阅章节4.5.2.4.1、4.5.2.6.1和4.5.2.6.2）。另外，3GPP TS 24.604和3GPP TS 24.611陈述，此类通知可根据如3GPP TS 24.628中描述的过程播放。

关于3GPP TS 24.628 (V11.0.0)，此文档规定能够由服务使用以便在通信建立期间和在拒绝通信请求时提供通知的方法。例如，AS能够如IETF RFC 3960定义的，将早期媒体用于发送带内通知。

发明内容

这里，人们认识到，虽然某些补充服务能够选择地实现通知，但无一相关标准指定能够如何确定要播放通知，也未指定如何识别要用于通知的媒体。具体而言，相关标准不提供使得用户能够灵活配置与其补充服务相关联的通知的任何机制。因此，本发明的目的是使得IP多媒体子系统(IMS)用户能够配置与诸如通信转移(CDIV)服务和通信禁止(CB)服务的其补充服务相关联的通知。

根据本发明的第一方面，提供了一种操作为用户实现IP多媒体子系统(IMS)补充服务的应用服务器(AS)的方法。方法包括配置用于用户的规则，规则具有指定是否要提供通知的动作，并且如果要提供通知，则定义要用于通知的媒体。方法还包括确定规则的条件是否由与用户有关的会话启动协议(SIP)消息满足，并且如果是，则根据动作实现通知。

动作可指定要提供通知，并且包括能够用于定位要用于通知的媒体的位置信息。如果此类规则的条件由SIP消息满足，则方法可还包括提供位置信息到要将通知发送到用户的媒体资源功能(MRF)。位置信息可以是要用于通知的媒体的统一资源定位器。

备选地，动作可指定要提供通知，并且包括要用于通知的媒体。如果此类规则的条件由SIP消息满足，则方法可还包括提供媒体到要将通知发送到用户的媒体资源功能(MRF)。

作为又一备选，动作可指定不要提供通知。

AS实现的补充服务可以是任何基于规则的服务。基于规则的服务的示例包括通信转移(CDIV)服务、通信禁止(CB)服务、灵活通信分布(FCD)服务及灵活提醒(FA)服务。

根据本发明的第二方面，提供了一种操作IP多媒体子系统(IMS)媒体资源功能(MRF)以提供与补充服务相关联的通知的方法。方法包括接收来自实现补充服务的应用服务器(AS)的消息，消息识别通知应发送到的用户并且定义要用于通知的媒体。方法还包括将媒体发送到识别的用户。

从AS收到的消息可包括能够用于定位要用于通知的媒体的位置信息。方法则可还包括确定媒体是否存储在该MRF，并且如果媒体位于该MRF，则将存储的媒体发送到识别的用户，或者如果媒体不位于该MRF，则从外部源检索媒体，并且将检索到的媒体发送到识别的用户。位置信息可以是要用于通知的媒体的统一资源定位器。

备选地，从AS收到的消息可包括要用于通知的媒体。方法则可还包括将收到的媒体发送到识别的用户。

根据本发明的第三方面，提供了一种操作用户设备(UE)以便为用户配置IP多媒体子系统(IMS)补充服务的方法。方法包括接受来自用户的输入，输入定义用于用户的规则，规则具有指定是否要提供通知的动作，并且如果要提供通知，则定义要用于通知的媒体。方法还包括将消息发送到实现补充服务的应用服务器(AS)，消息包括由用户输入定义的规则。

动作可指定要提供通知，并且包括能够用于定位要用于通知的媒体的位置信息。位置信息可以是要用于通知的媒体的统一资源定位器。

备选地，动作可指定要提供通知，并且包括要用于通知的媒体。作为又一备选，动作可指定不要提供通知。

根据本发明的第四方面，提供了一种配置成作为为用户实现IP多媒体子系统(IMS)补充服务的应用服务器(AS)操作的设备。设备包括存储用于用户的规则的存储器，规则具有指定是否要提供通知的动作，并且如果要提供通知，则定义要用于通知的媒体。设备还包括处理器用于确定规则的条件是否由与用户有关的会话启动协议SIP消息满足，并且如果是，则根据动作实现通知。

存储器可存储指定要提供通知并且包括能够用于定位要用于通知的媒体的定位信息的动作。处理器可配置成如果此类规则的条件由SIP消息满足，则提供位置信息到要将通知发送到用户的媒体资源功能(MRF)。

存储器可存储指定要提供通知并且包括要用于通知的媒体的动作。处理器可配置成如果此类规则的条件由SIP消息满足，则提供媒体到要将通知发送到用户的媒体资源功能(MRF)。

存储器可存储指定不要提供通知的动作。处理器可配置成如果此类规则的条件由SIP消息满足，则不实现通知。

根据本发明的第五方面，提供了一种配置成作为用于提供与补充服务相关联的通知的IP多媒体子系统IMS媒体资源功能MRF操作的设备。设备包括用于接收来自实现补充服务的应用服务器AS的消息的接收器；消息识别通知应发送到的用户并且定义要用于通知的媒体。设备还包括用于与识别的用户建立媒体会话的处理器和用于将媒体发送到识别的用户的传送器。

接收器可配置成接收来自AS的包括位置信息的消息，并且处理器可配置成使用位置信息定位要用于通知的媒体。处理器可因此配置成确定媒体是否存储在该MRF，并且如果媒体位于该MRF，则实现将存储的媒体发送到识别的用户，或者如果媒体不位于该MRF，则实现从外部源检索媒体，并且将检索到的媒体发送到识别的用户。

接收器可配置成接收来自AS的包括要用于通知的媒体的消息，并且处理器则可配置成实现将收到的媒体发送到识别的用户。

根据本发明的第六方面，提供了一种配置成作为用于为用户配置IP多媒体子系统(IMS)补充服务的用户设备(UE)操作的设备。设备包括用户输入装置、用于接受来自用户输入装置的处理器，所述输入定义用于用户的规则，规则具有指定是否要提供通知的动作，并且如果要提供通知，则定义要用于通知的媒体。设备还包括用于将消息发送到实现补充服务的应用服务器 (AS)的传送器，消息包括由用户输入定义的规则。

处理器可配置成接受具有以下动作的规则的输入，所述动作指定要提供通知并且包括能够用于定位要用于通知的媒体的定位信息。处理器可配置成接受具有以下动作的规则的输入，所述动作指定要提供通知并且包括要用于通知的媒体。处理器可配置成接受具有以下动作的规则的输入，所述动作指定不提供通知。

根据本发明的又一方面，还提供了一种包括计算机可读代码的计算机程序，计算机可读代码在计算机上运行时，促使计算机执行根据第一、第二或第三方面的任何方面的方法。另外，提供了一种包括计算机可读媒体和根据该所述又一方面的计算机程序的计算机程序产品，其中，计算机程序存储在计算机可读媒体上。

附图说明

图1以示意图方式示出与通用分组无线电服务(GPRS)接入网络的移动网络体系结构相关联的IMS网络。

图2是示出根据本文中所述方法实现通知的IP多媒体子系统(IMS)补充服务的过程的示例的信令流程图；

图3是示出根据本文中所述方法实现通知的IP多媒体子系统(IMS)补充服务的过程的示例的信令流程图；

图4是示出根据本文中所述方法实现通知的IP多媒体子系统(IMS)补充服务的过程的示例的信令流程图；

图5是示出根据本文中所述方法配置和实现IP多媒体子系统(IMS)补充服务的过程的示例的流程图；

图6以示意图方式示出适合用于实现本文中所述方法的应用服务器的示例；

图7以示意图方式示出适合用于实现本文中所述方法的用户设备的示例；以及

图8以示意图方式示出适合用于实现本文中所述方法的媒体资源功能的示例。

具体实施方式

现在将描述允许配置与IMS用户的IP多媒体子系统(IMS)补充服务（诸如通信转移(CDIV)服务和通信禁止(CB)）相关联的通知的方法。方法涉及为实现补充服务的应用服务器(AS)配置用于用户的规则，规则具有指定是否要播放通知的动作，并且如果要播放通知，则识别/定义要用于通知的媒体。随后，在接收与用户有关的SIP消息时，AS将确定规则的条件是否由SIP消息满足，并且如果是，则将根据动作实现通知。为此，此方法提供通知能够在逐规则和逐用户的基础上配置，由此提供网络运营商和/或用户能够个性化/个体化为每个基于规则的服务播放的通知。

为实现此方法，如IETF RFC 4745指定的规则语法将被扩展以定义指定是否要播放通知的另外动作。因此，本文中提议定义另外的动作，该动作指示在规则的条件由SIP消息匹配时要播放通知。例如，此另外的动作能够采用以下形式：

<mmt-serv:play-URL-announcement>通知 URL</mmt-serv:play-URL-announcement>

通过包括识别要作为通知播放的媒体资源的统一资源定位器(URL)，动作也识别/定义要用于通知的媒体。此通知URL能够是HTTP、FTP或SFTP URL，或者能够是根据其它协议定义的URL，该URL能够指定要作为通知播放的文件（例如，音频或视频文件）。

作为说明性示例，此另外的动作然后能够用于定义通信禁止规则，该规则禁止来自具有身份“sip:alice@example.com”的用户的进入呼叫，并且播放由URL“file://my.announcements.org/alice.wav”识别的通知。此类规则能够采用以下形式：

<ss:incoming-communication-barring active="true">

<cp:ruleset>

<cp:rule id="个人运营商托管通知">

<cp:conditions>

<cp:identity>

<cp:one id="sip:alice@example.com"/>

</cp:identity>

</cp:conditions>

<cp:actions>

<ss:allow>false</ss:allow>

<mmt-serv:play-URL-announcement>file://my.announcements.org/alice.wav</mmt-serv:play-URL-announcement>

</cp:actions>

</cp:rule>

</cp:ruleset>

</ss:incoming-communication-barring>

图2是示出根据如上所述的规则实现通知的IP多媒体子系统(IMS)补充服务的过程的示例的信令流程图。在此示例中，AS使用早期媒体会话发送带内通知并且要作为通知播放的媒体资源位于MRF。执行的步骤如下所述：

A1.    始发用户的UE（即，UE A）通过向终端用户发送SIP INVITE请求消息来启动通信。INVITE请求包括描述始发用户想使用的媒体的会话描述协议(SDP)提供以及要使用的IP地址和端口等。服务于终端用户的S-CSCF接收INVITE请求，并且评估与终端用户相关联的初始过滤准则。作为评估初始过滤准则的结果，S-CSCF将INVITE请求发送到为终端用户实现补充服务的AS。例如，终端用户可订阅通信禁止服务，使得INVITE请求发送到实现此服务的AS。

A2.    AS实现用于终端用户的服务逻辑。为此，AS将对照SIP消息评估已为终端用户配置的服务规则。在此示例中，为条件由SIP消息匹配的用户配置了规则，并且对应的动作指示要播放通知，以及包括识别要作为通知播放的媒体源。

A3.    AS与提供媒体资源功能控制器(MRFC)和媒体资源功能处理器(MRFP)的媒体资源功能(MRF)交互，以预留要用于通知的资源。为此，AS将包括从始发用户收到的SDP提供的INVITE请求发送到MRFC。INVITE请求的请求URL通过使用地址的用户部分（即，“annc”）和另外的URL参数指定通知服务。这些另外的URL参数包括指定要作为通知播放的资源的“播放”参数。在此示例中，“播放”参数包括在规则的动作部分中指定的URL。

A4.    MRFC响应于具有SIP 200 OK消息的INVITE请求，所述消息包括描述MRFC将接受的媒体的SDP应答以及要使用的IP地址和端口等。

A5.    AS然后将包括在INVITE请求中收到的SDP的应答的SIP 183（会话进展）响应消息发送到UE A。

A6.    UE A通过PRACK请求消息响应SIP 183（会话进展）响应消息。

A7.    在接收PRACK请求时，AS然后将ACK响应消息发送到MRFC。

A8.    AS也将PRACK请求的200 (OK)响应发送到始发用户。

A9.    MRFC与MRFP交互以便开始通知，并且MRFP向UE发送通知。

A10.  MRFC将BYE消息发送到AS。

A11.  AS通过SIP 200 OK消息响应来自MRFC的BYE消息。

在图2的示例中，要作为通知播放的媒体资源通过URL识别，并且位于MRF，使得MRFC/MRFP将该URL识别为本地资源，并且将本地托管媒体作为通知发送。备选地，如果MRFC/MRFP未将URL识别为本地资源，则MRFC/MRFP将根据URL定义的协议检索要作为通知播放的文件。此备选在图3中示出，图3中，除MRFC/MRFP已收到来自AS的INVITE后，MRFC/MRFP从使用在从AS收到的INVITE请求中包括的URL识别的某个外部媒体源检索媒体外，执行的步骤与图2的那些步骤相同。

在图2和3的示例中，AS在通信会话建立期间提供通知，并且因此使用早期媒体会话实现带内通知；然而，取决于触发通知的播放的规则类型，AS也能够配置成在已经建立的通信会话期间提供通知。例如，由外出通信禁止(OCB)和补充服务代码(SSC)规则触发的通知能够要求在建立的通信会话期间提供通知。图4是示出根据如上所述的规则实现通知的IP多媒体子系统(IMS)补充服务的过程的示例的信令流程图，其中，通知在建立的通信会话期间提供。执行的步骤如下所述：

C1.    始发用户的UE（即，UE A）通过向终端用户发送SIP INVITE请求消息来启动通信。INVITE请求包括描述始发用户想使用的媒体的会话描述协议(SDP)提供以及要使用的IP地址和端口等。服务于始发用户的S-CSCF接收INVITE请求，并且评估与终端用户相关联的初始过滤准则。作为评估初始过滤准则的结果，S-CSCF将INVITE请求发送到为始发用户实现补充服务的AS。例如，始发用户可订阅通信禁止服务，使得INVITE请求发送到实现此服务的AS。

C2.    AS实现用于终端用户的服务逻辑。为此，AS将对照SIP消息评估已为始发用户配置的服务规则。在此示例中，为条件由SIP消息匹配的用户配置了规则，并且对应的动作指示要播放通知，以及包括识别要作为通知播放的媒体源。例如，可根据OCB规则禁止INVITE的请求URL，或者可执行SSC命令。

C3.    AS与提供媒体资源功能控制器(MRFC)和媒体资源功能处理器(MRFP)的媒体资源功能(MRF)交互以预留要用于通知的资源。为此，AS将包括从始发用户收到的SDP提供的INVITE请求发送到MRFC。INVITE请求的请求URL通过使用地址的用户部分（即，“annc”）和另外的URL参数指定通知服务。这些另外的URL参数包括指定要作为通知播放的资源的“播放”参数。在此示例中，“播放”参数包括在规则的动作部分中指定的URL。

C4.    MRFC响应于具有SIP 200 OK消息的INVITE请求，所述消息包括描述MRFC将接受的媒体的SDP应答以及要使用的IP地址和端口等。

C5.    然后，AS将SIP 200 OK转发到UE A。

C6.    UE A通过ACK请求消息响应SIP 200 OK消息。

C7.    在接收ACK请求时，AS将ACK响应消息转发到MRFC。

C8.    MRFC与MRFP交互以便开始通知，并且MRFP向UE发送通知。

C9.    通知已播放后，MRFC将BYE发送到AS。

C10.  AS将BYE转发到UE A。

C11.  UE-A通过SIP 200 OK消息响应BYE。

C12.  AS将SIP 200 OK转发到MRFC。

本文中也提议在规则的条件由SIP消息满足时，定义又一另外的动作，该动作指示要播放通知，并且通过将要播放的媒体作为包括动作本身内的通知（即，“通知数据”），还定义了要用于通知的媒体。例如，此又一另外的动作能够采用以下形式：

<mmt-serv:play-binary-announcement file_type=”FileType”>通知数据</mmt-serv:play-binary-announcement>

在此示例中，动作包括相关媒体的二进制数据（即，内容），并且也定义通知数据的文件类型（例如，.wav、.mp3等）（即，其中，file_type="文件类型"）。实现此类动作时，实现补充服务的AS将通知数据提供到要向UE发送通知的MRFC/MRFP。

作为说明性示例，此另外的动作然后能够用于定义通信禁止规则，该规则禁止来自具有身份“sip:alice@example.com”的用户的进入呼叫，并且向用户播放通知。此类规则能够采用以下形式：

<ss:incoming-communication-barring active="true">

<cp:ruleset>

<cp:rule id="个人非运营商托管通知">

<cp:conditions>

<cp:identity>

<cp:one id="sip:alice@example.com"/>

</cp:identity>

</cp:conditions>

<cp:actions>

<ss:allow>false</ss:allow>

<mmt-serv:play-binary-announcement file_type=”FileType”>通知数据</mmt-serv:play-binary-announcement>

</cp:actions>

</cp:rule>

</cp:ruleset>

</ss:incoming-communication-barring>

在动作本身中包括要用于通知的媒体可能造成规则大小较大，并且因此将在存储用户配置文件（包括用户的服务规则）的归属订户服务器(HSS)和在提供服务给用户时托管规则的AS两者中使用较大量的可用存储空间。

要用于通知的媒体（即，托管在MRFC/MRFP，在外部媒体源、或者在提供补充服务的AS）能够由用户上载、由另一服务记录、或者从服务提供商为其用户提供的通知的选择中选择。为了允许用户配置与补充服务相关联的通知，服务提供商能够提供web门户或移动应用，用户能够经其记录其自己的通知和/或从服务提供商提供的通知中选择。从服务提供商提供的通知中选择时，web门户或移动应用将允许用户浏览并选择通知（例如，点击），由此避免用户需要将长的路径键入规则的动作部分，这是因为进行键入将容易出错。

本文中也提议定义仍有的另外的动作，该动作指示在规则的条件由SIP消息匹配时不要播放通知。例如，此又一另外的动作能够采用以下形式：

<mmt-serv:play-no-announcement/> 

用户明确不想播放通知时，此类动作是有用的。例如，如果在规则的动作部分内未定义特定通知，则实现补充服务的AS能够以其它方式配置成播放网络定义的通知。

上述动作能够包括在为补充服务定义的规则内，由此使得实现补充服务的AS能够确定何时要播放通知以及在逐用户，逐规则的基础上识别要用于通知的媒体。另外，取决于在进入的INVITE请求中收到的SDP提供中指示的可用媒体，通过利用为单独补充服务定义的规则内的“媒体”条件，指定其动作内不同通知的不同规则能够用于实现不同/备选通知。例如，“媒体”条件能够用于指定如果视频媒体可用，则要求播放视频通知的规则，以及如果仅音频媒体可用，则要求播放音频通知的又一规则。

图5是示出根据本文中所述方法的用户配置和实现IP多媒体子系统(IMS)补充服务的过程的示例的流程图。执行的步骤如下所述：

D1.    想要配置他们已订阅的补充服务的用户利用他们的UE输入要由补充服务应用的规则。这些规则的至少之一包括指示在规则的条件由SIP消息匹配时是否要播放通知的动作。例如，如果补充服务是CDIV服务，则用户能够配置规则，所述规则的动作要求将任何进入的通信转发到另一UE，并且要求向任何转移的进入通信的始发方播放录音。

D2.    UE然后将消息发送到实现补充服务的AS，消息包括用户输入定义的规则。如在3GPP TS 24.623中指定的，由用户对补充服务的此配置能够通过使用XCAP作为使能协议的Ut接口发生，或者能够使用基于SIP的用户配置。

D3.    实现补充服务的AS接收来自UE的消息，包括用户定义的规则。

D4.    使用在来自UE的消息中收到的规则定义信息，AS配置要为用户应用的补充服务规则。

D5.    随后，始发用户向用户的UE发送INVITE请求。基于指示用户订阅补充服务的初始过滤准则(IFC)，将INVITE请求转发到实现补充服务的AS。

D6.    在AS接收INVITE请求时，AS处理已为用户配置的规则以确定是否应关于INVITE请求执行补充服务支持并且的与规则相关联的动作。例如，如果AS配置成实现CDIV服务，则AS能够使用规则来确定是否将INVITE请求重定向到识别的目标以及是否实现到始发用户的通知。

为了实现本文中所述方法，实现补充服务的用户设备(UE)和应用服务器(AS)将被布置/配置以便允许用户配置一个或更多个规则，规则的动作定义在规则的条件由SIP消息满足时是否以及要如何实现通知。

图6以示意图方式示出用于根据上述方法实现IMS补充服务的AS 1的示例。AS 1能够实现为计算机硬件和软件的组合。AS 1包括处理器2、存储器3、接收器4和传送器5。存储器3存储由处理器2实现的各种程序/可执行文件，并且也提供用于任何要求的数据的存储单元。例如，此数据能够包括但不限于存储为已订阅补充服务的用户配置的规则的规则数据库8。此数据也能够包括能够用作通知并且在发送到MRF的消息中包括的通知媒体数据。存储器3中存储并且由处理器2实现的程序/可执行文件包括但不限于规则配置单元7、规则应用单元/条件评估单元8及动作执行单元9。规则配置单元7能够处理从用户收到的规则配置信息以便配置要为用户应用的补充服务的规则。规则的此配置将包括在存储器3提供的规则数据库8中存储用于用户的规则。AS使用接收器4接收与用户有关的通信时，规则应用单元/条件评估单元8然后能够访问存储器3提供的规则数据库8并且检索用户的用于补充服务的规则。规则应用单元/条件评估单元8然后能够确定在规则中定义的条件是否由通信满足，并且由此确定是否应关于通信执行与规则相关联的动作。如果确定应执行动作，则动作执行单元9能够实现用于该通信的规则中定义的动作，这能够包括使用接收器4和传送器5与MRFC/MRFP进行通信，以便如果动作指定要求通知，则实现通知。

图7以示意图方式示出适合用于实现上述方法的UE 10的示例。UE 10能够实现为计算机硬件和软件的组合。UE 10包括用户输入装置11、处理器12、存储器13、接收器14及传送器15。存储器13存储由处理器12实现的各种程序/可执行文件，并且也提供用于任何要求的数据的存储单元。在存储器13中存储并且由处理器12实现的程序/可执行文件包括但不限于用户输入单元16和规则配置单元17。用户输入单元16能够处理从用户输入装置11收到的任何用户输入。例如，用户输入单元16能够接受来自用户输入装置11的输入，输入定义根据上述方法要由补充服务应用的用户的规则。用户输入单元16然后将提供与规则定义/配置信息有关的任何用户输入到规则配置单元17以允许用户定义此类规则。然后，规则配置单元17将确保消息发送到实现补充服务的应用服务器(AS)，消息包括由用户输入定义的规则定义/配置信息。

图8以示意图方式示出用于根据上述方法实现通知的MRF 20的示例。MRF 20能够实现为计算机硬件和软件的组合。MRF 20包括处理器21、存储器22、接收器23和传送器24。存储器22存储由处理器21实现的各种程序/可执行文件，并且也提供用于任何要求的数据的存储单元。例如，此数据能够包括但不限于如果在从AS收到的消息中已识别，则能够作为通知播放的通知媒体数据25。存储器22中存储并且由处理器21实现的程序/可执行文件包括但不限于会话建立单元26、媒体检索单元27及通知单元28。MRF 20使用接收器23接收来自实现补充服务的AS的消息时，会话建立单元26确保与消息中识别的UE建立媒体会话，并且媒体检索单元27检索在要通过建立的媒体会话发送到UE的消息中定义的媒体。例如，媒体检索单元27能够从存储器22中存储的通知媒体数据25检索要用于通知的媒体。备选地，媒体检索单元27能够使用接收器23和传送器24实现从外部源检索媒体。作为又一备选，媒体检索单元27能够从收到的来自AS的消息检索媒体。一旦媒体已被检索，则通知单元28能够使用传送器将媒体作为通知传送到识别的UE。

上述方法和设备提供了能够实现灵活配置与用户的补充服务相关联的通知的机制。具体而言，上述方法和设备提供通知能够在逐规则和逐用户的基础上配置，由此提供网络运营商和/或用户能够个性化/个体化为每个基于规则的服务播放的通知。

本领域的技术人员将理解，在不脱离本发明范围的情况下，可对上述实施例进行各种修改。例如，虽然上述实施例具体涉及CDIV和CB服务，但这些方法和设备同样能够适用于任何基于规则的服务。另外，上述实施例利用外部MRF，但在AS具有内部MRFC并且经Mp协议(H.248)直接访问MRFP时同样适用。