CN1976529B - 在呼叫时进行业务订阅的方法及系统 - Google Patents

Abstract

一种在呼叫时进行业务订阅的方法，在以SIP协议提供业务的网络中，用户终端或网络在用户终端发起的非订阅消息的SIP会话消息中，通过一个头域携带一个或一个以上、表示与当前所述SIP会话相关业务被订阅信息的事件包；业务的业务控制节点接收所述事件包，进行相应的业务处理，若允许用户终端对所述业务的订阅申请，则在条件满足时，发送包含业务应用相关信息的通知消息。本发明克服了现有技术通过SIP INVITE消息携带一个独立头域来指示在呼叫发起时申请的业务信息，会使SIP协议变得不可控、实现流程不统一以及带来资源浪费的缺点，使订阅流程仍沿用SIP协议的现有机制，并使业务应用结果向用户透明，增加用户的业务体验性。

Description

在呼叫时进行业务订阅的方法及系统

技术领域

本发明涉及通信技术领域，尤其涉及一种在呼叫时进行业务订阅的方法及系统。

背景技术

在SIP(Session Initiation Protocol，即会话发起协议)中，提供了一种订阅/通知(SUBSCRIBE/NOTIFY)的机制，订阅者可以向被订阅者(通知者)发送SIP SUBSCRIBE消息(会话发起协议订阅消息)，消息中携带表示订阅信息的事件包(event package)，被订阅者向订阅者发送SIP NOTIFY消息(会话发起协议通知消息)，消息中携带被订阅的内容。目前，按照SIP协议的定义，表示订阅信息的事件包由Event header(事件头域)负责传递，而Event头域只能通过SIP SUBSCRIBE消息、SIPNOTIFY消息以及一种SIP PUBLISH消息(会话发起协议发布消息)携带。

SIP协议的订阅/通知机制向用户提供了一种非常灵活的业务申请的方法，用户在自己终端上可以申请订阅各种各样的业务，比如某个好朋友的在线状态、天气预报、对某个恶意骚扰电话的追查等待。

但是如前所述，用户的订阅只能通过SIP SUBSCRIBE消息来实现，这类申请订阅的业务是和呼叫无关的，不需要和某个具体呼叫相关联。而我们又知道，某些申请订阅的业务是和呼叫相关的，即该业务的申请订阅只在某个呼叫中有效。用户发起某个呼叫，希望在这个呼叫中应用某种业务，则可以临时申请订阅该业务应用于该特定呼叫中，比如，用户发起一次呼叫，希望临时申请“计费通知(Advice of Charge)”业务，使网络可以通知他/她这次呼叫所发生的费用；再如，用户发起一次呼叫，希望临时申请“主叫号码显示限制”业务，使这次呼叫建立过程中网络不将他/她的号码显示给被叫用户。

显然，用户发起呼叫，终端将发送SIP INVITE消息(会话发起协议邀请消息)，而传递用户订阅信息的事件包的Event头域只能在SIPSUBSCRIBE消息中传递，因此目前SIP协议的订阅机制无法实现用户“临时”申请订阅业务作用在某个特定呼叫上的需求。

当前，为了解决这个问题，一般的方法是在SIP INVITE消息中采用一个独立的头域(header)来指示上述的在呼叫发起时申请的业务信息，比如在ETSI(European Telecommunications Standards Institute，欧洲电信标准协会)的TISPAN(Telecommunications and Internet ConvergedServices and Protocols for Advanced Networking)系列标准中，采用一个P-AOC头域来指示呼叫发起时对“计费通知”业务的申请，采用一个Privacy头域来指示呼叫发起时对“主叫号码显示限制”业务的申请。

但是，我们也知道，用户在呼叫发起时“临时”申请订阅的此类业务是会有很多种的，具体数目是由用户需求决定的，当前是无法预知的，如果这类业务实现时都采用一个独立头域的方式，缺乏统一的机制，将会使SIP协议变得不可控，不具有可预见性。再如，已经激活了呼叫等待业务的用户发起一次呼叫时，希望申请“临时撤消呼叫等待”业务，使这次呼叫建立的通话不受新呼入来话的影响。

特别是，某些业务既可在呼叫发起时申请，也可以不在呼叫发起时申请，比如前述的“计费通知”业务，用户在呼叫发起时没有申请该业务，而是在通话中想查询一下已经发生了多少费用，则用户在通话中申请订阅“计费通知”业务，显然，这时的订阅仍然是利用SIP SUBSCRIBE消息携带事件包来完成的。

这样，同一个业务的申请在不同应用场景下将会分别通过一个独立头域、一个订阅事件包来实现，造成实现流程不统一以及带来的资源浪费。

此外，在SIP INVITE消息中通过一个独立头域来指示对业务的申请，很难向用户反馈业务应用成功还是失败的信息，因为SIP INVITE消息的目的是为了建立呼叫进行通话，它的SIP会话建立过程都是为这个目的服务的，没有更多的考虑这类和呼叫相关的业务的应用状况，显然即使业务应用失败，也不能因此而拒绝此次呼叫的建立。比如前述的“主叫号码显示限制”业务，网络对这个业务应用成功还是失败，按目前的标准流程，申请业务的主叫用户都不得而知。

从上述分析可以看出，在用户发起呼叫时，现有技术通过SIPINVITE消息携带一个独立头域来指示在呼叫发起时申请的业务信息主要有如下三个缺点：

1、用户在呼叫发起时“临时”申请订阅的业务是会有很多种的，具体数目是由用户需求决定的，当前是无法预知的，采用一个独立头域的实现方式缺乏统一的机制，将会使SIP协议变得不可控，不具有可预见性。

2、对某些既可在呼叫发起时申请，也可以不在呼叫发起时申请的业务，同一个业务的申请在不同应用场景下将会分别通过一个独立头域、一个订阅事件包来实现，造成实现流程不统一以及带来的资源浪费。

3、用户在呼叫发起时申请业务后，很难知道该业务的应用成功还是失败的信息，业务应用结果对用户不透明，用户体验性不好。

发明内容

本发明所要解决的技术问题是：克服现有技术通过SIP INVITE消息携带一个独立头域来指示在呼叫发起时申请的业务信息，会使SIP协议变得不可控、实现流程不统一以及带来资源浪费的缺点，提供一种在呼叫时进行业务订阅的方法及系统，仍沿用SIP协议的现有机制，保持SIP协议现有机制的完整性，并使业务应用结果向用户透明，增加用户的业务体验性。

本发明为解决上述技术问题所采用的技术方案为：

这种在呼叫时进行业务订阅的方法，包括以下步骤：

在以会话发起协议提供业务的网络中，用户终端在发起的非订阅消息的会话发起协议会话消息中，或网络在发起的非订阅消息的会话发起协议会话消息中，通过一个头域携带一个或一个以上、表示当前所述会话发起协议会话相关业务被订阅信息的事件包；

所述会话发起协议会话相关业务的业务控制节点接收所述事件包，进行相应的业务处理。

所述头域可以为事件头域，并使事件头域能由订阅消息和通知消息之外的其它会话发起协议消息携带。所述头域为事件头域时，并使其可以传递多个所述事件包。

所述头域可以为新扩展的一个会话发起协议头域，使其能由订阅消息和通知消息之外的其它会话发起协议消息携带.所述头域为新扩展的一个会话发起协议头域时，使其可以传递多个所述事件包.

所述非订阅消息的会话发起协议会话消息可以为呼叫消息，包括会话发起协议邀请消息或会话发起协议即时消息。

用户终端发起携带所述事件包的所述呼叫消息，所述会话发起协议会话相关业务控制节点接收到所述的事件包，进行相应的业务处理，若允许用户终端对所述业务的订阅申请，则在条件满足时，发送包含所述业务应用相关信息的通知消息。

所述通知消息可以为会话发起协议通知消息、或会话发起协议发布消息、或会话发起协议响应码消息。

用户终端发起未携带所述事件包的呼叫消息，网络中第一网元在收到该呼叫消息后，根据业务的预置信息和当前会话情况，在该呼叫消息中插入所述事件包，发送至业务控制节点；或者，用户终端发起携带所述事件包的呼叫消息，经过网络中第二网元发送至业务控制节点。

所述第一网元或第二网元收到包含所述会话发起协议会话相关业务应用相关信息的通知消息，如果该通知消息是会话发起协议通知消息，则将该会话发起协议通知消息转换成会话发起协议发布消息或会话发起协议响应码消息，向用户终端发送；如果该通知消息是会话发起协议发布消息，则将该会话发起协议发布消息向用户终端转发，或转换成会话发起协议响应码消息向用户终端发送。

对业务控制节点接受订阅的所述事件包，所述第一网元或第二网元为所述事件包创建订阅实例。

用户终端发起携带所述事件包的所述呼叫消息，在收到所述通知消息后，为该通知消息中携带的事件包创建订阅实例。

所述会话发起协议响应码消息中携带的事件包通过新扩展的会话发起协议头域或事件头域传递。

所述用户终端、或第一网元、或第二网元发起携带所述事件包的所述呼叫消息，为所述事件包对应的订阅和所述呼叫创建一个对话，或分别创建不同的对话。

若所述订阅和所述呼叫被分别创建不同的对话，则在所述头域中携带所述订阅对应的对话参数。

用户终端发起携带所述事件包的所述呼叫消息中指示用户终端是否为所述事件包创建订阅实例。

所述用户终端发起携带所述事件包呼叫消息中通过支持头域的内容来指示用户终端是否为所述事件包创建订阅实例。

相应的一种在呼叫时进行业务订阅的系统，以会话发起协议提供业务的网络中包括：

订阅者，用于在其发出的非订阅消息的会话发起协议会话消息中通过一个头域携带一个或一个以上、表示与当前所述呼叫相关业务被订阅信息的事件包；

通知者，用于接收所述事件包，向所述订阅者发送携带所述业务应用信息的通知消息。

本发明的有益效果为：本发明在SIP协议给出一种和当前SIP订阅/通知机制保持一致的、在呼叫发起时对业务的申请订阅方法，可以通过呼叫消息携带表示被订阅业务信息的事件包.在用户终端发起的呼叫消息中通过一个固定的头域传递表示被订阅业务信息的事件包，对一种被订阅业务只需要定义一个事件包，而不需要扩展不同的独立头域，仍沿用SIP协议的现有机制，保持了SIP协议现有机制的完整性.

同时，该事件包同样可以在SIP SUBSCRIBE消息中通过Event头域传递，即对那些既可在呼叫发起时申请，也可以不在呼叫发起时申请的业务，定义同一个事件包就能在不同应用场景下使用，业务申请订阅成功后的流程基本一致。

同时，对用户终端在呼叫发起时申请订阅的业务，业务控制节点可以通过SIP NOTIFY/PUBLISH消息以及可以携带事件包的SIP响应码，向用户终端通知业务应用成功还是失败的信息，业务应用结果向用户透明，用户的业务体验性良好。

综上所述，本发明具有更广泛的适用性和通用性，使业务的实现变得更加简洁，并使业务应用结果向用户透明，增加用户的业务体验性。

附图说明

图1为本发明在呼叫发起时进行计费通知业务订阅的一种实现流程示意图；

图2为本发明在通话中进行计费通知业务订阅的实现流程示意图；

图3为本发明在呼叫发起时进行计费通知业务订阅的另一种实现流程示意图；

图4为本发明事件发布代理不在业务控制节点时，在呼叫发起时进行计费通知业务订阅的实现流程示意图。

具体实施方式

下面根据附图和实施例对本发明作进一步详细说明：

现有技术通过一个独立头域来指示在呼叫发起时对业务的申请方法是不可取的，基于此，本发明将在SIP协议给出一种和当前SIP订阅/通知机制保持一致的、在呼叫发起时对业务的申请订阅方法，通过SIPINVITE消息携带表示被订阅业务信息的事件包。

从前面分析可以看出，本发明要解决的问题就是在呼叫发起时对业务的申请订阅方法，仍然沿用当前SIP订阅/通知机制，仍通过事件包来表示被订阅业务的信息。要达到这个目的，如前所述，要么使Event头域也可以通过SIP INVITE消息携带；要么新扩展一个头域使其也可以传递表示被订阅业务信息的事件包，该头域通过SIP INVITE消息携带。

对前一种方法，需要改变目前SIP协议的定义，在IETF(Internetengineering task force，因特网工程任务组)RFC3265中，有如下定义：

需要将其修改为：

即表示Event头域对SUBSCRIBE和NOTIFY消息是必选的(mandatory)，对INVITE消息是可选的(optional)。

对后一种方法，本发明新扩展一个能由SUBSCRIBE消息、NOTIFY消息以及PUBLISH消息之外的其它SIP消息携带的、传递表示被订阅业务信息的事件包的头域，比如命名为P-SUB，参照SIP协议中Event头域的定义格式，P-SUB的定义格式如下：

P-SUB             ＝(″P-SUB″)HCOLON(sub-event*(COMMA

                    sub-event))

sub-event         ＝event-type*(SEMI  event-param)

event-type        ＝event-package*(″.″event-template)

event-package     ＝token-nodot

event-template    ＝token-nodot

token-nodot       ＝1*(alphanum/″-″/″！″/″％″/″*″

                       /″_″/″+″/″`″/″’″/″~″)

event-param       ＝generic-param/(″id″EQUAL token)

其中，sub-event表示P-SUB头域中传递的表示被订阅业务信息的事件包，它包含了事件包类型event-type和参数event-param，而event-type和event-param的定义和Event头域中的完全相同，本发明不再详细解释。

可以看出，和Event头域定义不一样的地方是，P-SUB头域中可以传递多个表示被订阅业务信息的事件包，而Event头域中只能传递一个事件包。这是因为，用户在呼叫发起时，可能会申请对多个业务的订阅，比如同时申请“计费通知”和“主叫号码显示限制”。当然，为了实现这个需求，也可以修改Event头域的定义格式，使其也能传递多个事件包。

下面通过一个具体的实施例来说明，用户如何在呼叫发起时申请对“计费通知”业务的订阅，以及在通话中申请对“计费通知”业务的订阅，并展示如何在SIP INVITE消息和SIP SUBSCRIBE消息中传递表示“计费通知”业务订阅信息的事件包，以达到不需要扩展一个独立的头域(P-AOC)、一个业务的订阅只有一个相应事件包的目的。

在本实施例中，假设被申请订阅的业务由业务控制节点这样一个逻辑网元来提供业务逻辑控制和执行环境，它可以存在于某个网络实体(如应用服务器)中，甚至也可以存在于用户终端之中。需要说明的是，本发明中所作的流程图示和文字说明仅为突出本发明的关键技术所作的解释，并不表示一个完整的呼叫和业务控制流程，也没有穷尽所有可能的分支流程。

如图1所示，用户在呼叫发起时申请对“计费通知”业务的订阅流程具体说明如下：

1)SIP终端用户A呼叫用户B，在呼叫发起时申请(本次通话)使用计费通知业务，在终端发出的SIP INVITE消息中有如下内容：

INVITE sip:mary@tele.com SIP/2.0

P-SUB:aoc-message

其中，P-SUB头域即用来传递表示“计费通知”业务订阅信息的事件包aoc-message，需要说明的是，计费通知业务事件包aoc-message是本发明的一个扩展，P-SUB头域和下述的Event头域中事件类型(event-type)的取值“aoc-message”是该事件包名称(event packagename)。如前所述，扩展Event头域的使用范围，此时也可以在SIP INVITE消息中传递Event头域：

INVITE sip:mary@tele.com SIP/2.0

Event:aoc-message

为符合SIP协议的订阅/通知机制，SIP终端A作为订阅者(subscriber)需要为事件包aoc-message创建一个事务(transaction)。

2)业务控制节点接收SIP INVITE消息，向被叫方向发送。

3)用户B的SIP终端接收到SIP INVITE消息，用户B摘机应答，发送200OK响应码。

4)业务控制节点接收到200OK响应码，向主叫方向发送。此时被叫已经应答，业务控制节点根据此前从SIP INVITE消息里P-SUB头域中解析出的aoc-message事件包，判断如果用户A有申请使用计费通知业务的权限，则该业务申请成功，作为通知者(notifier)创建该事件包的订阅实例(subscription)，并在200OK响应码中通过P-SUB头域或Event头域携带订阅成功被接受的事件包：

P-SUB:aoc-message

此时，在该200OK响应码中就已经可以通过携带本次通话的计费通知信息，一般可以通过响应码的消息体携带。

5)用户A的SIP终端接收到200OK响应码，返回ACK确认消息。SIP终端A从200OK响应码中解析出aoc-message事件包，和已经创建事务的事件包匹配，创建该事件包的订阅实例。

若该响应码中已经携带了本次通话的计费通知信息，则用户A的SIP终端还可以提取出计费通知信息。

6)业务控制节点将ACK确认消息向用户B的SIP终端发送，用户A和用户B间的会话建立，双方开始通话。

7)业务控制节点计算本次通话的费率，也可能提前计算出本次通话的费用，通过SIP NOTIFY消息的消息体携带计费通知信息发送给用户A的SIP终端，在SIP NOTIFY消息中必须指明相应的事件包：

Event:aoc-message

8)用户A的SIP终端接收到SIP NOTIFY消息，从消息体中提取出本次通话的费率或费用，返回200OK响应码。

9)SIP终端B用户挂机释放呼叫，发送SIP BYE消息。

10)业务控制节点接收到SIP BYE消息，向主叫方向发送。

11)SIP终端A接收到SIP BYE消息，释放呼叫，返回200OK响应码。

12)业务控制节点接收到200OK响应码，向被叫方向发送。

13)业务控制节点判断该呼叫的相关信息将被完全释放，用户订阅的计费通知业务也随之结束，则计算已经发生的通话费用，通过SIPNOTIFY消息的消息体携带计费通知信息发送给用户A的SIP终端，在SIP NOTIFY消息中必须指明相应的事件包，并通过Subscription-State头域取值为“terminated”指明业务应用结束，释放订阅实例：

Event:aoc-message

Subscription-State:terminated

在Subscription-State头域中还可以通过reason参数来设置业务应用结束的原因。可以看到，本实施例中，计费通知业务的有效期开始于通话建立时，结束于通话释放时，业务订阅实例的释放由业务控制节点决定。

14)用户A的SIP终端接收到SIP NOTIFY消息，从消息体中提取出本次通话的费用，释放订阅实例，返回200OK响应码。

可以看到，在实施例流程图1中，用户终端和业务控制节点之间是通过在针对INVITE消息的SIP响应码(实施例中为200OK响应码，还可以是183 Session Progress等响应码)中携带的事件包来指示哪些事件包已经被业务控制节点接受订阅，用户终端只为SIP响应码中携带的事件包创建订阅实例。实际上，按照这个约定，在实施例流程图1的步骤1中，用户终端为事件包创建事务也可以不是必须的，即，在步骤5中，用户终端既使不将SIP响应码中携带的事件包和已经创建事务的事件包相匹配，也可以就根据SIP响应码中携带的事件包来创建相应的订阅实例。

显然，这里用户终端是根据业务控制节点返回的、已经同意订阅的事件包，来创建该事件包的订阅实例，这样，既使SIP响应码中不通过扩展来携带事件包(此时如果需要的话，SIP响应码也仍然可以携带业务应用信息，如图1的步骤4中携带计费通知信息)，用户终端还可以直接根据业务控制节点发送的第一个的、表示订阅请求已被接受的NOTIFY消息(如实施例流程图1中步骤7发送的NOTIFY消息)中携带的事件包，来创建该事件包的订阅实例。即：业务控制节点返回的事件包(通过SIP响应码或NOTIFY消息)，将表明该事件包已经被业务控制节点同意订阅并创建了相应的订阅实例，因此用户终端可以根据业务控制节点返回的事件包来创建相应的订阅实例。

此外，需要说明的是，由于呼叫发起时对业务的申请订阅依附于SIPINVITE消息，而SIP INVITE消息作为一个会话消息必须要创建一个dialog(对话)，因此用户终端上创建的订阅实例也只能依附于该dialog，即呼叫和订阅将共用一个dialog。

这里需要进一步说明的是，由于dialog是端到端建立的，而订阅实例只存在于SIP终端A和业务控制节点之间，因此业务控制节点将作为B2BUA(Back to Back User Agent，背靠背用户代理)位于SIP INVITE消息建立的呼叫信令路径中，即实施例流程图1的步骤1中，SIP终端A和业务控制节点建立了一个dialog，步骤2中，业务控制节点和业务控制节点建立了另一个dialog，所述订阅实例使用的是SIP终端A和业务控制节点之间建立的dialog。

此外，在上述实施例中，订阅和呼叫共用了一个dialog，如果订阅和呼叫不共用一个dialog，即订阅单独建立一个dialog，此时则需要SIP终端A在步骤1发送SIP INVITE消息中，单独指明订阅的dialog，如扩展P-SUB头域，以携带创建dialog所必须的Call-ID参数和From-tag参数，消息示例如下：

INVITE sip:mary@tele.com SIP/2.0

From:sip:alice@tele.com；tag＝889def

P-SUB:aoc-message；Call-ID＝5678@example.com；

                   From-tag＝123aa9

Call-ID:1234@example.com

其中，From头域中的“889def”和Call-ID头域中的“1234@example.com”将用来创建呼叫的dialog，而P-SUB头域中的“123aa9”和“5678@example.com”将用来创建订阅的dialog。

而业务控制节点则可以在步骤4，通过返回的P-SUB头域携带To-tag参数，消息示例如下：

SIP/2.0200OK

From:sip:alice@tele.com；tag＝889def

To:sip:mary@tele.com；tag＝xyzqqq

P-SUB:aoc-message；Call-ID＝5678@example.com；

                   From-tag＝123aa9；To-tag＝abcmmn

Call-ID:1234@example.com

其中，To头域中的“xyzqqq”属于呼叫的dialog，P-SUB头域中的“abcmmn”属于订阅的dialog。Call-ID、From-tag、To-tag都是属于dialog的参数，可以看到，订阅和呼叫的dialog分别不同，订阅的dialog通过新扩展的头域携带，当然也可以通过其它方式携带。

此时，虽然订阅dialog的路由集重用SIP终端A到业务控制节点间呼叫建立的路由集，即相同的信令路径，但订阅和呼叫却分别建立了两个dialog，该方法同样适用于后面的实施例。

另外，由于每个事件包都有自己的订阅实例，因此当INVITE消息中携带一个以上的事件包时，若这些事件包不共用呼叫的dialog，则需要为每个事件包对应的订阅实例创建一个dialog，即对上述的P-SUB头域来说，每个事件包都要有其对应的dialog参数。

如图2所示，在通话中申请对“计费通知”业务的订阅流程具体说明如下：

1)SIP终端用户A呼叫用户B，发出SIP INVITE消息。

2)业务控制节点接收SIP INVITE消息，向被叫方向发送。

3)用户B的SIP终端接收到SIP INVITE消息，用户B摘机应答，发送200OK响应码。

4)业务控制节点接收到200OK响应码，向主叫方向发送。

5)用户A的SIP终端接收到200OK响应码，返回ACK确认消息。

6)业务控制节点将ACK确认消息向用户B的SIP终端发送，用户A和用户B间的会话建立，双方开始通话。

7)用户A在和用户B通话，经过一段时间后，希望申请使用计费通知业务，看看当前已经产生了多少话费，则用户A在SIP终端上发起对计费通知业务的订阅申请，发出SIP SUBSCRIBE消息，消息中有如下内容：

Event:aoc-message

SIP终端A作为订阅者为事件包aoc-message创建事务。

8)业务控制节点接收SIP SUBSCRIBE消息，从Event头域中解析aoc-message事件包，如果用户A有申请使用计费通知业务的权限，则该业务申请成功，业务控制节点作为通知者创建订阅实例，返回200OK响应码。

SIP终端A接收到同意订阅的200OK响应码，为事件包aoc-message创建订阅实例.

9)业务控制节点计算当前通话已经发生的费用，通过SIP NOTIFY消息的消息体携带发送给用户A的SIP终端，也可能还携带本次通话的费率。在SIP NOTIFY消息中也必须指明相应的事件包：

Event:aoc-message

10)用户A的SIP终端接收到SIP NOTIFY消息，从消息体中提取出本次通话的费用或费率，返回200OK响应码。

需要指出的是，在呼叫发起时申请对业务的订阅的实现方法，在上述实施例中，是由用户主动在发出的INVITE消息中携带表示被订阅业务信息的事件包，但也可能用户始发的INVITE消息中没有携带相关事件包，而是由网络在收到用户始发的INVITE消息后，根据用户的业务签约信息以及当前的呼叫状况，在INVITE消息中插入表示被订阅业务信息的事件包，再发送给后续的业务控制节点以处理被订阅业务的订阅申请。

比如，被叫用户签约了彩铃业务，主叫用户发起呼叫，网络中某网元(第一网元)收到用户始发的INVITE消息后，根据被叫用户的彩铃签约信息以及主叫用户号码，判断要对这次呼叫申请应用彩铃，则在INVITE消息中插入表示申请订阅彩铃业务的事件包，发送给后续提供彩铃的业务控制节点。这里不太一样的地方是，表示订阅业务的事件包的订阅实例创建于该网元(订阅者)和该业务控制节点(通知者)上，用户终端作为INVITE消息的始发者上没有订阅实例，相当于该网元替用户终端创建了一个业务的订阅实例。此时，若该网元收到来自该业务控制节点的SIP NOTIFY订阅通知消息，若需要通知用户业务的应用情况，则可以将该消息转换成SIP PUBLISH消息或某个合适的响应码，发送给用户终端；当然若该网元收到的就是携带业务应用信息的SIPPUBLISH消息，则可以转发给用户终端，或转换成某个合适的响应码发送给用户终端。

此外，可以看到，本发明的技术方案和当前SIP订阅/通知机制保持一致，对用户在呼叫发起时申请订阅的业务，业务控制节点会和收到SIPSUBSCRIBE消息一样，向用户发送SIP NOTIFY订阅通知消息，通过针对SIP INVITE消息的SIP响应码中携带的表示订阅业务的事件包以及SIP NOTIFY消息，业务控制节点就可以向用户通知业务应用成功还是失败的信息。

在前述的技术方案中，沿用了现有的SIP订阅/通知机制，用户发起呼叫时携带表示被订阅业务信息的事件包，在用户终端和业务控制节点上创建该事件包的订阅实例，网络向该用户终端发送SIP NOTIFY订阅通知消息携带被订阅业务的相关应用内容。

我们知道，在SIP协议中，除了SIP NOTIFY订阅通知消息外，还有一个SIP PUBLISH消息同样可以携带事件包并指示该事件包的相关内容。因此，也可以使用户发起呼叫时携带表示被订阅业务信息的事件包，网络向用户终端发送SIP PUBLISH消息携带被订阅业务的相关应用内容，此时，用户终端上不需要创建该事件包的订阅实例。

在SIP协议中，PUBLISH消息的应用更多的是用户终端向网络发送，在本实施例中，将要求SIP终端支持对PUBLISH消息的接收和对PUBLISH状态的维护。采用本方法，前述的用户在呼叫发起时申请对“计费通知”业务的订阅的实施例描述如图3所示，流程解释如下：

1)SIP终端用户A呼叫用户B，在呼叫发起时申请(本次通话)使用计费通知业务，在终端发出的SIP INVITE消息中有如下内容：

INVITE sip:mary@tele.com SIP/2.0

P-SUB:aoc-message

2)业务控制节点接收SIP INVITE消息，从P-SUB头域中解析aoc-message事件包，如果用户A有申请使用计费通知业务的权限，则该业务申请成功。

3)用户B的SIP终端接收到SIP INVITE消息，用户B摘机应答，发送200OK响应码。

4)业务控制节点接收到200OK响应码，向主叫方向发送。

5)用户A的SIP终端接收到200OK响应码，返回ACK确认消息。

6)业务控制节点将ACK确认消息向用户B的SIP终端发送，用户A和用户B间的会话建立，双方开始通话。

7)业务控制节点计算本次通话的费率，也可能提前计算出本次通话的费用，通过SIP PUBLISH消息的消息体携带发送给用户A的SIP终端，在SIP PUBLISH消息中必须指明相应的事件包，并通过Expires头域指明维护PUBLISH状态的监视时长：

Event:aoc-message

Expires:3600

8)用户A的SIP终端接收到SIP PUBLISH消息，从消息体中提取出本次通话的费率或费用，启动对PUBLISH状态的维护，维护状态的监视时长来自于SIP PUBLISH消息中携带的Expires头域取值(3600秒)，返回200OK响应码。

9)SIP终端B用户挂机释放呼叫，发送SIP BYE消息。

10)业务控制节点接收到SIP BYE消息，向主叫方向发送。

11)SIP终端A接收到SIP BYE消息，释放呼叫，返回200OK响应码。

12)业务控制节点接收到200OK响应码，向被叫方向发送。

13)业务控制节点判断该呼叫的相关信息将被完全释放，用户订阅的计费通知业务也随之结束，则计算已经发生的通话费用，通过SIPPUBLISH消息的消息体携带发送给用户A的SIP终端，在SIP PUBLISH消息中必须指明相应的事件包，并通过Expires头域取值为“0”指明业务应用结束：

Event:aoc-message

Expires:0

14)用户A的SIP终端接收到SIP PUBLISH消息，从消息体中提取出本次通话的费用，停止对PUBLISH状态的维护，返回200OK响应码。

可以看到，用户A的SIP终端和业务控制节点一对订阅者和通知者，并没有为订阅的事件包创建订阅实例，而只是维护了事件包的PUBLISH状态。

在实施例图3中，通过发送SIP PUBLISH消息发布事件的事件发布代理(Event Publication Agent)就位于业务控制节点上，我们知道，在很多情况下，事件发布代理可能并不位于业务控制节点上(即业务控制节点不具有发送SIP PUBLISH消息发布事件的能力)，而是位于另一个独立网元(第二网元)上，此时将会有如图4所示的实施流程，流程解释如下：

1)SIP终端用户A呼叫用户B，在呼叫发起时申请(本次通话)使用计费通知业务，在终端发出的SIP INVITE消息中有如下内容：

INVITE sip:mary@tele.com SIP/2.0

P-SUB:aoc-message

2)事件发布代理接收SIP INVITE消息，从P-SUB头域中解析aoc-message事件包，为该事件包创建事务，将SIP INVITE消息向业务控制节点发送。

3)业务控制节点接收SIP INVITE消息，向被叫方向发送。

4)用户B的SIP终端接收到SIP INVITE消息，用户B摘机应答，发送200OK响应码。

5)事件发布代理接收到200OK响应码，向主叫方向发送。

6)业务控制节点接收到200OK响应码，向主叫方向发送。

7)用户A的SIP终端接收到200OK响应码，返回ACK确认消息。

8)事件发布代理接收到ACK确认消息，向被叫方向发送。

9)业务控制节点将ACK确认消息向用户B的SIP终端发送，用户A和用户B间的会话建立，双方开始通话。

10)会话建立，业务控制节点根据从P-SUB头域中解析出的aoc-message事件包，判断如果用户A有申请使用计费通知业务的权限，则该业务申请成功，业务控制节点创建该事件包的订阅实例(subscription)。业务控制节点计算本次通话的费率，也可能提前计算出本次通话的费用，通过SIP NOTIFY消息的消息体携带向主叫方向发送，在SIP NOTIFY消息中必须指明相应的事件包：

Event:aoc-message

11)事件发布代理接收到SIP NOTIFY消息，从P-SUB头域中解析出aoc-message事件包，和已经创建的事务匹配，创建该事件包的订阅实例。事件发布代理将SIP NOTIFY消息转换成SIP PUBLISH消息携带本次通话的费率和/或费用，在消息中必须指明相应的事件包，并通过Expires头域指明维护PUBLISH状态的监视时长：

Event:aoc-message

Expires:3600

12)用户A的SIP终端接收到SIP PUBLISH消息，从消息体中提取出本次通话的费率或费用，启动对PUBLISH状态的维护，维护状态的监视时长来自于SIP PUBLISH消息中携带的Expires头域取值(3600秒)，返回200OK响应码。

13)事件发布代理接收到对SIP PUBLISH消息的200OK响应码，向业务控制节点发送对SIP NOTIFY消息的200OK响应码。

可以看到，在实施例图4流程中，由于业务控制节点不具有事件发布能力，因此只能由事件发布代理和业务控制节点创建对事件包的订阅实例，业务控制节点将SIP NOTIFY订阅通知消息发送给事件发布代理，后者将SIP NOTIFY消息转换成SIP PUBLISH消息发送给用户，当然如前所述，也可以转换成合适的响应码发送给用户.即：对用户A的SIP终端来说，事件发布代理具有事件发布能力，用户A的SIP终端和事件发布代理构成一对订阅者和通知者，维护事件包的PUBLISH状态；对业务控制节点(通知者)来说，事件发布代理就是对事件包的订阅者，这对订阅者和通知者为事件包创建了订阅实例.此外，类似的，此时事件发布代理(第二网元)还可以为所述事件包对应的订阅和所述呼叫创建一个dialog，或分别创建不同的dialog，前述的第一网元也是如此，这里不再详细描述.

在上述的两个技术方案中，发起呼叫时申请业务订阅的用户，其终端既可以为事件包创建订阅实例(技术方案一，实施例图1和图2)，也可以不创建订阅实例(技术方案二，实施例图3和图4)，当整个网络都采用同一种技术方案时显然没有问题，但当整个网络不是采用同一种技术方案时则会出现配合上的问题，比如用户终端采用技术方案二，而网络设备取采用技术方案一，用户终端在收到携带了事件包的SIP响应码后，并没有创建订阅实例，这样它将无法接收后续网络发送的SIPNOTIFY消息，显然，业务应用将因配合差错而失败。

因此，需要用户终端在发起呼叫申请业务订阅时，在SIP INVITE消息中指明其支持的技术方案，通过消息中的Supported头域的内容notifing或publishing，指明用户终端是支持技术方案一还是支持技术方案二，网络将据此进行相应的处理，比如Supported头域的内容为publishing，则网络将需要启动事件发布的能力，将呼叫INVITE消息路由到一个具有事件发布代理能力的网络实体上，并且发送SIP PUBLISH消息而不是SIP NOTIFY消息给用户终端。

此外，在SIP协议中，用户之间建立通信联系，除了可以用SIPINVITE消息外，还可以用SIP MESSAGE消息(会话发起协议即时消息)，本发明呼叫消息包括SIP INVITE消息和SIP MESSAGE消息，即同样可以在SIP MESSAGE消息中通过一个固定的头域传递表示被订阅业务信息的事件包，比如，用户A向用户B发送一个即时消息，同时请求“计费通知”业务，以了解该即时消息所发生的费用，用户A发送的SIP消息示例如下：

MESSAGE sip:mary@tele.com SIP/2.0

P-SUB:aoc-message

或

INVITE sip:mary@tele.com SIP/2.0

Event:aoc-message

此外，还需要说明的是，本发明中所述的用户终端，可以是支持SIP协议的终端设备，如SIP话机、SIP手机等，也可以是支持SIP协议的、管理传统终端设备的SIP用户代理设备，如SIP IAD(Integrated AccessDevice，综合接入设备)等，该SIP用户代理设备可以将不支持SIP协议的传统终端设备接入到以SIP协议提供业务的网络中。

此外，还需要说明的是，除了前述的实施例中用户发起呼叫外，本发明同样适用于网络发起的呼叫，在呼叫中通过携带的事件包表示对业务的订阅。

通过本发明的方案，在用户或网络发起呼叫的SIP INVITE消息或SIP MESSAGE消息中通过一个固定的头域传递表示被订阅业务信息的事件包，对一种被订阅业务只需要定义一个事件包，而不需要扩展不同的独立头域，仍沿用SIP协议的现有机制，保持了SIP协议现有机制的完整性。

同时，该事件包同样可以在SIP SUBSCRIBE消息中通过Event头域传递，即对那些既可在呼叫发起时申请，也可以不在呼叫发起时申请的业务，定义同一个事件包就能在不同应用场景下使用，业务申请订阅成功后的流程基本一致。

同时，对用户在呼叫发起时申请订阅的业务，业务控制节点会可以通过SIP NOTIFY/PUBLISH消息以及SIP响应码，向用户通知业务应用成功还是失败的信息，业务应用结果向用户透明，用户的业务体验性良好.

本发明同时保护在呼叫时进行业务订阅的系统，以会话发起协议提供业务的网络中包括：订阅者，用于在其发出的非订阅消息的会话发起协议会话消息中通过携带一个或一个以上、表示与当前所述呼叫相关业务被订阅信息的事件包；通知者，用于接收所述事件包，向所述订阅者发送携带所述业务应用信息的通知消息。系统的工作原理和方法同前面对于呼叫时进行业务订阅方法的描述，这里不再赘述。

本发明的方案具有更广泛的适用性和通用性，使业务的实现变得更加简洁，并使业务应用结果向用户透明，增加用户的业务体验性。本领域技术人员不脱离本发明的实质和精神，可以有多种变形方案实现本发明，以上所述仅为本发明较佳可行的实施例而已，并非因此局限本发明的权利范围，凡运用本发明说明书及附图内容所作的等效变化，均包含于本发明的权利范围之内。

Claims (27)

1.一种在呼叫时进行业务订阅的方法，其特征在于包括以下步骤：

在以会话发起协议提供业务的网络中，用户终端在发起的非订阅消息的会话发起协议会话消息中，或网络在发起的非订阅消息的会话发起协议会话消息中，通过一个头域携带一个或一个以上、表示当前所述会话发起协议会话相关业务被订阅信息的事件包；

所述会话发起协议会话相关业务的业务控制节点接收所述事件包，进行相应的业务处理。

2.根据权利要求1所述的在呼叫时进行业务订阅的方法，其特征在于：所述头域为事件头域，并使事件头域能由订阅消息和通知消息之外的其它会话发起协议消息携带。

3.根据权利要求2所述的在呼叫时进行业务订阅的方法，其特征在于：所述头域为事件头域，并使其可以传递多个所述事件包。

4.根据权利要求1所述的在呼叫时进行业务订阅的方法，其特征在于：所述头域为新扩展的一个会话发起协议头域，使其能由订阅消息和通知消息之外的其它会话发起协议消息携带。

5.根据权利要求4所述的在呼叫时进行业务订阅的方法，其特征在于：所述头域为新扩展的一个会话发起协议头域，使其可以传递多个所述事件包。

6.根据权利要求1所述的在呼叫时进行业务订阅的方法，其特征在于：所述非订阅消息的会话发起协议会话消息为呼叫消息，包括会话发起协议邀请消息或会话发起协议即时消息。

7.根据权利要求6所述的在呼叫时进行业务订阅的方法，其特征在于：用户终端发起携带所述事件包的呼叫消息，所述会话发起协议会话相关业务控制节点接收到所述的事件包，进行相应的业务处理，若允许用户终端对所述业务的订阅申请，则在条件满足时，发送包含所述业务应用相关信息的通知消息。

8.根据权利要求7所述的在呼叫时进行业务订阅的方法，其特征在于：所述通知消息为会话发起协议通知消息、或会话发起协议发布消息、或会话发起协议响应码消息。

9.根据权利要求6所述的在呼叫时进行业务订阅的方法，其特征在于：用户终端发起未携带所述事件包的呼叫消息，网络中第一网元在收到该呼叫消息后，根据业务的预置信息和当前会话情况，在该呼叫消息中插入所述事件包，发送至业务控制节点；或者，用户终端发起携带所述事件包的呼叫消息，经过网络中第二网元发送至业务控制节点。

10.根据权利要求9所述的在呼叫时进行业务订阅的方法，其特征在于：所述第一网元或第二网元收到包含所述会话发起协议会话相关业务应用相关信息的通知消息，如果该通知消息是会话发起协议通知消息，则将该会话发起协议通知消息转换成会话发起协议发布消息或会话发起协议响应码消息，向用户终端发送；如果该通知消息是会话发起协议发布消息，则将该会话发起协议发布消息向用户终端转发，或转换成会话发起协议响应码消息向用户终端发送。

11.根据权利要求9所述的在呼叫时进行业务订阅的方法，其特征在于：对业务控制节点接受订阅的所述事件包，所述第一网元或第二网元为所述事件包创建订阅实例。

12.根据权利要求7所述的在呼叫时进行业务订阅的方法，其特征在于：用户终端发起携带所述事件包的所述呼叫消息，在收到所述通知消息后，为该通知消息中携带的事件包创建订阅实例。

13.根据权利要求8所述的在呼叫时进行业务订阅的方法，其特征在于：所述会话发起协议响应码消息中携带的事件包通过新扩展的会话发起协议头域或事件头域传递。

14.根据权利要求7所述的在呼叫时进行业务订阅的方法，其特征在于：所述用户终端、或第一网元、或第二网元发起携带所述事件包的所述呼叫消息，为所述事件包对应的订阅和所述呼叫创建一个对话，或分别创建不同的对话。

15.根据权利要求14所述的在呼叫时进行业务订阅的方法，其特征在于：若所述订阅和所述呼叫被分别创建不同的对话，则在所述头域中携带所述订阅对应的对话参数。

16.根据权利要求6所述的在呼叫时进行业务订阅的方法，其特征在于：用户终端发起携带所述事件包的所述呼叫消息中指示用户终端是否为所述事件包创建订阅实例。

17.根据权利要求16所述的在呼叫时进行业务订阅的方法，其特征在于：所述用户终端发起携带所述事件包呼叫消息中通过支持头域的内容来指示用户终端是否为所述事件包创建订阅实例。

18.一种在呼叫时进行业务订阅的系统，其特征在于，以会话发起协议提供业务的网络中包括：

订阅者，用于在其发出的非订阅消息的会话发起协议会话消息中通过一个头域携带一个或一个以上、表示与当前所述呼叫相关业务被订阅信息的事件包；

通知者，用于接收所述事件包，向所述订阅者发送携带所述业务应用信息的通知消息。

19.根据权利要求18所述的在呼叫时进行业务订阅的系统，其特征在于：所述事件包通过会话发起协议头域携带，该头域是事件头域或新扩展头域。

20.根据权利要求18或19所述的在呼叫时进行业务订阅的系统，其特征在于：所述非订阅消息的会话发起协议会话消息为呼叫消息，包括会话发起协议邀请消息或会话发起协议即时消息。

21.根据权利要求18或19所述的在呼叫时进行业务订阅的系统，其特征在于：所述通知消息为会话发起协议通知消息、或会话发起协议发布消息、或会话发起协议响应码消息。

22.根据权利要求21所述的在呼叫时进行业务订阅的系统，其特征在于：所述会话发起协议响应码消息携带所述事件包。

23.根据权利要求20所述的在呼叫时进行业务订阅的系统，其特征在于：所述订阅者为所述事件包对应的订阅和所述呼叫创建一个对话，或分别创建不同的对话。

24.根据权利要求23所述的在呼叫时进行业务订阅的系统，其特征在于：若所述订阅和所述呼叫被分别创建不同的对话，则在所述头域中携带所述订阅对应的对话参数。

25.根据权利要求20所述的在呼叫时进行业务订阅的系统，其特征在于：所述通知者为所述事件包创建对应的订阅实例，或维护发布状态。

26.根据权利要求20所述的在呼叫时进行业务订阅的系统，其特征在于：如果所述订阅者不是所述呼叫消息的始发者，该订阅者收到的通知消息是会话发起协议通知消息，则将该会话发起协议通知消息转换成会话发起协议发布消息或会话发起协议响应码消息，向所述呼叫消息的始发者发送；如果该会话发起协议通知消息是会话发起协议发布消息，则将该会话发起协议发布消息向所述呼叫消息的始发者转发，或转换成会话发起协议响应码消息向所述呼叫消息的始发者发送。

27.根据权利要求20所述的在呼叫时进行业务订阅的系统，其特征在于：所述呼叫消息中指示所述订阅者是否为所述事件包创建订阅实例.

Images