CN101222483A - 业务触发方法、系统及业务触发装置 - Google Patents

Abstract

本发明实施例公开了一种业务触发方法，该方法包括：监测业务触发事件；确定需要根据该业务触发事件触发多个业务控制点；触发该多个业务控制点。本发明实施例还基于上述方法公开了一种业务触发系统及业务触发点装置。本发明实施例提供的上述业务触发方法、系统及业务触发装置，基于同一个业务触发事件，来调用多个业务控制点，而不需要在触发一个业务控制点后，再基于该业务控制点返回初始请求消息，触发下一个业务控制点，能够保证后续业务控制点的触发，并能够提高触发处理效率，还可以提供用户自己选择业务控制点的机会。

Description

业务触发方法、系统及业务触发装置

技术领域

本发明涉及通信技术领域，尤其涉及一种业务触发方法、系统及业务触发装置。

背景技术

IP多媒体子系统(IMS)是基于会话初始化协议(SIP)的体系，在第三代移动通信标准化伙伴项目(3GPP)版本5中被引入。IMS的会话层与业务层分离，会话层的S-CSCF通过预先设置的初始过滤规则(iFC)数据来触发业务层的应用服务器，包括SIP应用服务器(AS)、开放业务接入业务能力服务器(OSA SCS)、IP多媒体业务交换功能(IM-SSF)等。

在现有3GPP TS 29.288标准中，一条iFC数据可包括0个或1个触发点(Trigger Point)描述，1个优先级(Priority)数字描述，1个服务器名(ServerName)描述，以及AS不可路由时的缺省处理(Default Handling)描述。上述触发点的描述给出初始过滤规则匹配的条件；服务器名描述给出与该iFC数据对应的AS地址，且1条iFC数据中只有1个服务器名描述；优先级数字描述给出S-CSCF对该iFC数据的处理次序，且同一个优先级不能指定给多于1条iFC数据使用。

根据3GPP TS 29.288标准，除注册、注销消息之外，S-CSCF触发AS的流程如下：S-CSCF在接收到SIP初始请求消息后，先将该SIP请求消息与优先级较高的iFC1数据中描述的业务触发条件进行匹配，若匹配成功，那么S-CSCF将该SIP请求消息发送给与该iFC1对应的业务控制点AS1，调用该AS1。S-CSCF在接收到该AS1返回的SIP请求消息后，S-CSCF利用AS1返回的SIP请求消息与优先级较低的iFC2数据中描述的业务触发条件进行匹配，若匹配成功，那么S-CSCF将AS1返回的SIP请求消息再发送给与iFC2对应的AS2，调用AS2；依次执行，直至满足业务触发条件的iFC数据处理完毕。即现有技术中后续AS的触发依赖于前面触发的AS发送的SIP初始请求消息。在该流程中，若中间的AS未能返回消息或者返回的消息非SIP初始请求消息，那么S-CSCF将无法继续调用下一个AS。

若用户订阅由多个AS提供的组合业务，用户发送的订阅消息通过公共服务身份(PSI)路由至提供组合业务的业务代理(Service Broker)上，此时需要Service Broker终结该消息，且将该SUBSCRIBE消息分别发送给提供上述组合业务的多个AS，但AS收到发给自身的SUBSCRIBE消息后，将向Service Broker返回200OK响应消息，此时若采用现有的S-CSCF的业务触发方式，Service Broker将无法根据非SIP初始请求消息的200OK消息调用下一个AS。

即现有技术采用上述串行业务触发方式，在触发一个AS之后，基于该AS返回的SIP初始请求消息，继续触发下一个AS，一旦前一个被触发的AS未能返回消息，或者所返回的消息类型非SIP初始请求消息，那么，采用现有的业务触发方式，将无法触发下一个业务控制点，从而无法保证业务触发的实现。

此外目前的S-CSCF采用串行触发的方式，后续AS的触发需要等待前面的AS触发完毕才可以进行，触发效率低下。

现有技术中，S-CSCF在触发一个AS后，需要根据该AS发送回的SIP初始请求消息继续触发后续的AS，但由于AS可能改变SIP消息，这样可能引发业务交互问题，即会引起后续的业务不工作或者工作不正常。例如S-CSCF接收的原始SIP消息中Accept-Contact头域中含+g.PoC.talkburst标志，且用户的iFC规则中存在一条指定根据该标志触发至提供无线一键通(PoC，Push to talk over Cellular)业务的AS的数据。但根据业务优先级，S-CSCF可能先处理别的iFC，此时S-CSCF先触发至AS1，AS1工作于背靠背用户代理(B2BUA，Back to back user agent)模式进行业务处理并对SIP消息进行了修改，该标志被丢失，这样S-CSCF再次接收到此消息后将不能再由前述iFC触发到后续的提供PoC业务的AS上。

目前，S-CSCF根据iFC数据中的服务器名配置触发至一个AS，该触发的AS不能由用户控制，实际上用户可能希望能够实时选择为自己服务的AS，例如网络中有多个提供会议业务的会议服务器，用户希望选择呼叫时响应速度最快的会议服务器，现有技术是不支持这种功能的。

发明内容

有鉴于此，本发明实施例提供一种业务触发方法，保证业务触发的实现。

一种业务触发方法，包括：

监测业务触发事件；

确定需要根据该业务触发事件触发的多个业务控制点；

触发该多个业务控制点。

本发明实施例还提供一种业务触发装置，保证业务触发的实现。

一种业务触发装置，包括：

监测单元、业务控制点信息提供单元和触发单元，其中，

监测单元，用于监测业务触发事件，将监测到的业务触发事件信息传送给业务控制点信息提供单元；

业务控制点信息提供单元，用于接收来自监测单元的业务触发事件信息，确定需要根据该业务触发事件触发多个业务控制点，将该多个业务控制点信息传送给触发单元；

触发单元，用于接收来自业务控制点信息提供单元的多个业务控制点信息，触发该多个业务控制点。

本发明实施例还提供一种业务触发系统，保证业务触发的实现。

一种业务触发系统，包括：业务触发装置和多个业务控制点，其中，

业务触发装置，用于监测业务触发事件，确定需要根据该业务触发事件触发多个业务控制点，且触发该多个业务控制点。

本发明实施例提供的上述业务触发方法、系统及业务触发装置，基于同一个业务触发事件，来触发多个业务控制点，而不需要在触发一个业务控制点后，再基于该业务控制点返回的消息，触发下一个业务控制点，能够保证后续业务控制点的触发，并能够提高触发处理效率，还可以提供用户自己选择业务控制点的机会。

附图说明

图1是本发明实施例中的业务触发系统的架构示意图；

图2是本发明实施例1中并行触发2个业务控制点的流程图；

图3是本发明实施例2中并行触发2个业务控制点的流程图；

图4是本发明实施例3中串行触发2个业务控制点的流程图；

图5是本发明实施例4中串行触发2个业务控制点的流程图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图作进一步详细描述。

本发明实施例首先提供一种业务触发方法，该方法包括：监测业务触发事件；确定需要根据该业务触发事件触发多个业务控制点；触发该多个业务控制点。

即本发明实施例的关键是根据同一个业务触发事件触发多个业务控制点，所述同一业务触发事件例如：业务触发点收到消息A，根据该消息A触发AS1，经过AS1处理后返回消息B，根据同一业务触发事件调用多个业务控制点至少包括如下之一：根据消息A触发后续多个业务控制点，或者根据消息B触发后续多个业务控制点。即同一业务触发事件可以是业务触发点收到的原始业务触发事件，也可以是触发处理过程中收到的业务触发事件，例如AS1返回的消息B。

本发明实施例提及的业务触发事件可包括：接收到业务触发消息，或呼叫状态迁移。

本发明实施例还基于上述业务触发方法，提供一种业务触发系统，该系统包括：业务触发装置和多个业务控制点，其中，

业务触发装置，用于监测业务触发事件，确定需要根据该业务触发事件触发多个业务控制点，且触发该多个业务控制点。

业务触发装置，即业务触发点，包括：

监测单元、业务控制点信息提供单元和触发单元，其中，

监测单元，用于监测业务触发事件，将监测到的业务触发事件信息传送给业务控制点信息提供单元；

业务控制点信息提供单元，用于接收来自监测单元的业务触发事件信息，确定需要根据该业务触发事件触发多个业务控制点，将该多个业务控制点信息传送给触发单元；

触发单元，用于接收来自业务控制点信息提供单元的多个业务控制点信息，触发该多个业务控制点。

参见图1，图1是本发明实施例中的业务触发系统的架构示意图。其中，业务触发系统进一步可包括：业务触发数据存储单元，该单元用于存储业务触发数据，并将业务触发数据传送给业务触发装置；业务触发装置进一步可包括：业务触发数据获取单元，用于获取业务触发数据，将业务触发数据信息传送给业务控制点信息提供单元；业务控制点信息提供单元，进一步用于接收来自业务触发数据获取单元的所述业务触发数据信息，根据与该业务触发事件对应的业务触发数据，确定需要根据该业务触发事件触发多个业务控制点。

业务触发数据存储单元可以是用户归属服务器(HSS)等。业务触发点可以是：S-CSCF或Service Broker等。业务控制点可以是：SIPAS、OSA SCS或IM-SSF等。设业务触发点与业务触发数据存储单元之间的接口用E1表示，业务触发点通过该E1接口从业务触发数据存储单元获取用户签约数据。该E1接口采用的协议可包括：Diameter协议、SIP协议、通用用户档案(GUP)协议、HTTP协议、移动应用部分(MAP)协议等。设业务触发点和业务控制点之间的接口用E2表示，业务触发点通过该E2接口将业务触发事件触发至业务控制点；业务触发后，业务控制点和业务触发点之间通过该E2接口交互通信消息。该E2接口采用的协议可为：SIP协议。

在本发明实施例中，触发多个业务控制点的做法可以是：

根据同一个业务触发事件，并行触发多个业务控制点，即同时触发多个业务控制点；或，

根据同一个业务触发事件，串行触发多个业务控制点，即逐个触发多个业务控制点。

首先详细说明本发明实施例中基于同一个业务触发事件并行触发多个业务控制点的做法，该做法可以是：对现有业务触发数据描述进行扩展，根据与该业务触发事件对应的业务触发数据，确定需要根据该业务触发事件并行触发多个业务控制点。扩展的业务触发数据描述包括：将与业务触发事件对应的多条业务触发数据的优先级设置为相同，或者，在与业务触发事件对应的一条业务触发数据中配置多个业务控制点的地址信息。业务触发点根据扩展的业务触发数据，并行触发该多个业务控制点。

根据在与业务触发事件对应的多条业务触发数据中存在相同优先级配置的信息，确定需要根据该业务触发事件触发所述业务触发数据对应的多个业务控制点，例如：

将2条业务触发数据iFC1与iFC2的优先级设置为相同，则iFC1描述可以是：

<InitialFilterCriteria>

              <Priority>10</Priority>

               <TriggerPoint>

                 ……

                 <SPT>

                 ……

                 <Method>INVITE</Method>

                    </SPT>

                 </TriggerPoint>

                 <ApplicationServer>

                   <ServerName>sip:AS1@homedomain.com</ServerName>

                   <DefaultHandling>0</DefaultHandling>

                </ApplicationServer>

  </InitialFilterCriteria>

   iFC2的描述可以是：

   <InitialFilterCriteria>

                <Priority>10</Priority>

                <TriggerPoint>

                  ……

                  <SPT>

                  ……

                  <Method>INVITE</Method>

                  </SPT>

               </TriggerPoint>

               <ApplicationServer>

                 <ServerName>sip:AS2@homedomain.com</ServerName>

                 <DefaultHandling>0</DefaultHandling>

              </ApplicationServer>

</InitialFilterCriteria>

由上述iFC1与iFC2的描述可见，iFC1与iFC2的优先级均是10，且均根据SIP INVITE消息触发。当业务触发点监测到一个业务触发事件，例如收到一个业务触发消息SIP INVITE消息，确定该消息与该iFC1和iFC2中描述的业务触发条件匹配时，通过本发明实施例中业务触发点的触发单元，并行触发AS1和AS2，即基于该业务触发事件，同时触发至与iFC1对应的业务控制点AS1和与iFC2对应的业务控制点AS2。

基于存在多条优先级相同的与同一业务触发事件对应的业务触发数据，业务触发点并行调用与该多条业务触发数据分别对应的多个业务控制点的具体做法可以是：业务触发点根据各个业务触发数据的优先级，对各个业务触发数据进行排序，并在遍历所有业务触发数据之后，找出优先级相同的多个业务触发数据；业务触发点根据该多条业务触发数据的优先级相同，并行调用与该多条业务触发数据分别对应的多个业务控制点。

下面结合具体的实施例，说明上述将iFC1与iFC2的优先级设置为相同后，并行调用多个业务控制点的做法。

参见图2，图2是本发明实施例1中并行触发2个业务控制点的流程图。其中，业务触发数据存储单元是HSS，业务触发点是S-CSCF，业务控制点可以是SIP AS、OSA SCS或IM-SSF任意之一，本实施例中设2个业务控制点均是SIP AS，分别是AS1和AS2。该流程包括以下步骤：

步骤201、S-CSCF从HSS获取业务触发数据iFC数据。

该步骤中，可通过3GPP定义的Cx接口从HSS获取该iFC数据。

步骤202、S-CSCF接收用户A发送的INVITE消息。

步骤203、S-CSCF从用户A的iFC数据中找到两条优先级相同的iFC1和iFC2。

该步骤中，设iFC1的描述为：

<InitialFilterCriteria>

              <Priority>10</Priority>

              <TriggerPoint>

                  ……

              <SPT>

                 ……

              <Method>INVITE</Method>

               </SPT>

              </TriggerPoint>

              <ApplicationServer>

                <ServerName>sip:AS1@homedomain.com</ServerName>

                <DefaultHandling>0</DefaultHandling>

              </ApplicationServer>

</InitialFilterCriteria>

设iFC2的描述为：

<InitialFilterCriteria>

              <Priority>10</Priority>

              <TriggerPoint>

                  ……

               <SPT>

                  ……

               <Method>INVITE</Method>

                </SPT>

               </TriggerPoint>

               <ApplicationServer>

                  <ServerName>sip:AS2@homedomain.com</ServerName>

                  <DefaultHandling>0</DefaultHandling>

               </ApplicationServer>

 </InitialFilterCriteria>

S-CSCF确定再无其它相同优先级的iFC数据，则对上述iFC1和iFC2进行处理。上述iFC1和iFC2中描述的业务触发条件均为<Method>INVITE</Method>，即若SIP请求方法为INVITE，则可确定接收到的INVITE消息与iFC1和iFC2中的业务触发条件相匹配。即此时存在与同一业务触发事件对应的多条优先级相同的业务触发数据，因此S-CSCF并行调用与该多条业务触发数据对应的多个业务控制点。

步骤204与步骤205、S-CSCF同时向与iFC1对应的AS1和与iFC2对应的AS2发送INVITE消息，该流程结束。

本实施例中，虽然基于同一个INVITE消息触发2个业务控制点，但是，在实际应用中，上述iFC1与iFC2中描述的业务触发条件可以不相同，如业务触发点根据该两个iFC可分别基于同一个INVITE消息的不同头域或消息体内容等描述与接收到的业务触发消息进行匹配，如iFC1中描述的业务触发条件是INVITE消息中的From头域内容，iFC2中描述的业务触发条件是INVITE消息中的To头域内容，在匹配成功后，触发与该2个iFC对应的业务控制点。

至此，对本发明实施例1说明结束。

根据在与业务触发事件对应的一条业务触发数据中存在多个业务控制点的地址配置信息，确定需要根据该业务触发事件触发与该业务触发数据对应的多个业务控制点，例如：

若在iFC1中配置多个AS地址描述，则扩展后的iFC1描述可如下：

<InitialFilterCriteria>

              <Priority>0</Priority>

                    ……

              <TriggerPoint>

                    ……

              </TriggerPoint>

              <ApplicationServer>

                 <ServerName>sip:AS1@homedomain.com</ServerName>

                 <ServerName>sip:AS2@homedomain.com</ServerName>

                 <SequenceMode>0</SequenceMode>

                 <DefaultHandling>0</DefaultHandling>

              </ApplicationServer>

 </InitialFilterCriteria>

在该实施例中，由对iFC1的描述可见，该iFC1中存在两个业务控制点AS1与AS2的地址描述项：

<ServerName>sip:AS1@homedomain.com</ServerName>；

<ServerName>sip:AS2@homedomain.com</ServerName>。

业务触发点根据iFC1的描述，当接收到一个与该iFC1中业务触发条件描述匹配的业务触发事件时，业务触发点基于该业务触发事件触发至与iFC1对应的两个业务控制点AS1和AS2。

另外，在该iFC数据描述中还增加了一个触发顺序模式指示，即其中的SequenceMode指示，该指示可表示：并行触发业务控制点，或者串行触发业务控制点。设Sequence Mode取值为0，表示并行触发AS1和AS2；SequenceMode取值为1，表示串行触发AS1和AS2。并可设定，当iFC数据中不存在Sequence Mode指示且存在多个AS地址描述时，Sequence Mode可取默认值，例如取默认值为0，即并行触发该多个AS，即业务触发数据仅支持并行触发或串行触发时，可以不需要在业务触发数据增加明确的“触发顺序模式指示”，当业务触发数据中描述了多个业务控制点时，要么并行触发，要么按顺序触发。当并行触发AS1和AS2时，可基于该业务触发事件同时触发至AS1和AS2；若需要串行触发AS1和AS2，那么可基于该业务触发事件先触发至AS1与AS2的其中一个业务控制点，再触发另一个业务控制点。无论是并行触发，还是串行触发，都是基于同一个业务触发事件实现。该实施例中，Sequence Mode的取值为0。

下面结合具体的实施例，说明上述在iFC1中配置多个AS地址后，并行触发多个业务控制点的做法。

参见图3，图3是本发明实施例2中并行触发2个业务控制点的流程图。其中，业务触发数据存储单元是HSS，业务触发点是S-CSCF，2个业务控制点分别是AS1和AS2。该流程包括以下步骤：

步骤301、S-CSCF从HSS获取业务触发数据iFC数据。

步骤302、S-CSCF收到用户A发送的INVITE请求消息。

步骤303、S-CSCF检查用户的iFC数据，确定需要将该INVITE请求消息发送给该iFC数据指定的2个AS：AS1和AS2。

该步骤中，设iFC数据描述如下：

<InitialFilterCriteria>

             <Priority>0</Priority>

                    ……

              <TriggerPoint>

              <SPT>

                  ……

              <Method>INVITE</Method>

              </SPT>

              </TriggerPoint>

              <ApplicationServer>

                 <ServerName>sip:AS1@homedomain.com</ServerName>

                 <ServerName>sip:AS2@homedomain.com</ServerName>

                 <SequenceMode>0</SequenceMode>

                 <DefaultHandling>0</DefaultHandling>

              </ApplicationServer>

</InitialFilterCriteria>

S-CSCF根据该iFC数据，确定接收到的INVITE消息与该iFC数据中描述的触发条件<Method>INVITE</Method>相匹配，S-CSCF进一步根据该iFC数据描述中SequenceMode取值为0以及存在多个ServerName的描述，确定需要并行调用ServerName描述的AS1和AS2。即此时存在与同一业务触发事件对应的一条配置有多个业务控制点的地址信息的业务触发数据，因此S-CSCF并行调用与该多条业务触发数据对应的多个业务控制点。

步骤304与步骤305、S-CSCF同时将INVITE消息发送给AS1和AS2，该流程结束。

上述实施例对应的实际应用例如，若AS1和AS2均是提供会议业务的会议应用服务器，那么AS1和AS2在被同时触发之后，可响应该INVITE消息，之后，由用户选择为自己提供服务的会议应用服务器。

至此，对本发明实施例2的说明结束。

在实际应用中，如果一个业务触发过程，如第三方注册流程，不需要严格按照现有iFC的优先级调用业务控制点，那么可采用本发明实施例给出的上述并行触发多个业务控制点的做法进行业务触发，通过一次触发调用多个业务控制点，能够有效提高业务触发的效率。

然后详细说明本发明实施例中基于同一个业务触发事件，串行触发多个业务控制点的做法，该做法可以是：采用相互独立的触发方式，串行触发该多个业务控制点。所述多个业务控制点基于同一业务触发事件被触发，而不是分别基于被触发的上一个业务控制点返回的消息被触发，也就是说下一个业务控制点的触发不依赖于前一业务控制点返回的消息。

进一步说明，在采用相互独立的触发方式实现串行触发多个业务控制点的做法中，可通过扩展业务触发数据描述，确定需要根据该业务触发事件串行触发多个业务控制点。例如可扩展业务触发数据描述，增加一个触发条件模式指示，该指示可表示是否采用被触发的业务控制点的触发结果进行后续触发。当该指示取值表示不采用被触发的业务控制点的触发结果进行后续触发时，指示业务触发点在触发一个业务控制点之后，不采用该业务控制点的返回消息，而继续采用所述业务触发事件触发下一个业务控制点。

进一步说明，所述采用互相独立的触发方式串行触发多个业务控制点的做法中，还可不扩展业务触发数据，当业务触发事件为特定业务触发消息时，业务触发点判断该消息是否需要本地终结以实现串行触发，若是，则业务触发点确定需要根据该业务触发事件触发与其对应的多条业务触发数据中描述的多个业务控制点，所述特定业务触发消息至少包括如下之一：SIPREGISTER注册消息、SIP SUBSCRIBE订阅消息、SIP PUBLISH发布消息、SIP NOTIFY通知消息。

当然，串行触发多个业务控制点的做法还可以是：通过前述的在一个业务触发数据中描述多个业务控制点的方式，确定需要根据该业务触发事件串行触发多个业务控制点，可以通过前述的“触发顺序模式指示”来指示串行触发，也可以缺省的只要一个业务触发数据中描述了多个业务控制点就串行触发所述多个业务控制点。

下面结合本发明实施例3至实施例4，说明根据同一个业务触发事件，串行触发多个业务控制点的做法。

当业务触发事件是特定业务触发消息时，根据该业务触发消息需要本地终结的判定，互相独立的串行触发多个业务控制点，例如：

实施例3：

用户订阅由多个AS提供的组合业务，用户发送的订阅消息通过PSI路由至提供组合业务的Service Broker上，此时需要Service Broker本地终结该消息，且将该SUBSCRIBE消息分别触发至提供上述组合业务的多个AS，但AS收到发给自身的SUBSCRIBE消息后将向Service Broker返回与订阅消息类型不同的200OK响应消息，这时，可采用上述相互独立地触发方式，触发该多个业务控制点。

参见图4，图4是本发明实施例3中触发2个业务控制点的流程图。该流程包括以下步骤：

步骤401、Service Broker从HSS获取业务触发数据。

该步骤中，业务触发数据可采用过滤规则(FC)数据的形式描述，ServiceBroker从HSS获取业务触发数据的具体方法可以是通过3GPP定义的Sh接口获取。

步骤402、Service Broker接收到用户发送的SUBSCRIBE消息。

该步骤中，该SUBSCRIBE消息中的Request-URI为Service Broker自身的地址sb1@home.net。

步骤403、Service Broker确定该SUBSCRIBE消息需要在本地终结，Service Broker检查FC数据，以确定如何将该SUBSCRIBE消息发送给与FC数据对应的业务控制点。

该步骤中，Service Broker根据SUBSCRIBE消息中的Request-URI为本地地址来确定该SUBSCRIBE消息需要在本地终结。该步骤中，与SUBSCRIBE消息相匹配的业务触发数据有2条，分别是FC1与FC2，其中，

设FC1的描述如下：

<FilterCriteria>

             <Priority>10</Priority>

             <TriggerPoint>

                <ConditionTypeCNF>0</ConditionTypeCNF>

                <SPT>

                ……

            <Group>0</Group>

               <RequestURI>sb1@home.net</RequestURI>

               </SPT>

               <SPT>

                ……

               <Group>0</Group>

               <Method>SUBSCRIBE</Method>

               </SPT>

            </TriggerPoint>

            <ApplicationServer>

              <ServerName>sip:AS1@homedomain.com</ServerName>

               <DefaultHandling>0</DefaultHandling>

           </ApplicationServer>

</FilterCriteria>

设FC2的描述如下：

<FilterCriteria>

             <Priority>15</Priority>

             <TriggerPoint>

                <ConditionTypeCNF>0</ConditionTypeCNF>

                <SPT>

              ……

             <Group>0</Group>

               <RequestURI>sb1@home.net</RequestURI>

              </SPT>

              <SPT>

                ……

             <Group>0</Group>

               <Method>SUBSCRIBE</Method>

               </SPT>

            </TriggerPoint>

            <ApplicationServer>

             <ServerName>sip:AS2@homedomain.com</ServerName>

               <DefaultHandling>0</DefaultHandling>

             </ApplicationServer>

</FilterCriteria>

即此时业务触发事件是特定的业务触发消息，业务触发点ServiceBroker判断该业务触发消息SUBSCRIBE需要本地终结，确定需要根据该业务触发事件串行触发与其对应的多条业务触发数据FC1和FC2中描述的多个业务控制点AS1、AS2。根据过滤规则的优先级，Service Broker串行触发AS1、AS2。

步骤404、Service Broker将SUBSCRIBE消息触发给FC1对应的AS1。

步骤405、Service Broker将SUBSCRIBE消息触发给FC2对应的AS2。

步骤406、AS1向Service Broker返回触发成功的200OK响应消息。

步骤407、AS2向Service Broker返回触发成功的200OK响应消息。

上述步骤404至步骤407中，Service Broker根据上述两个FC数据的优先级，先处理优先级为10的FC1，将SUBSCRIBE消息与该FC1中的触发条件：<Method>SUBSCRIBE</Method>进行匹配，在匹配成功后，根据FC1中描述的AS1地址项，将SUBSCRIBE消息发送给AS1。AS1被调用成功后，向Service Broker返回200OK响应消息，但是，Service Broker并不等待AS1返回该200OK响应消息，而是继续处理优先级为15的FC2，将SUBSCRIBE消息与该FC2中的触发条件：<Method>SUBSCRIBE</Method>进行匹配，在匹配成功后，根据FC2中描述的AS2地址项，将SUBSCRIBE消息发送给AS2。

步骤408、Service Broker在接收到AS1与AS2返回的200OK响应消息后，向用户A返回200OK响应消息，该流程结束。

至此，对本发明实施例3的说明结束。

根据与业务触发事件对应的至少一条指示不采用被触发业务控制点的触发结果进行后续触发的业务触发数据，互相独立的串行触发该多个业务控制点，例如：

实施例4：

本实施例中，业务触发数据被扩展，增加了触发条件模式指示，表示是否采用被触发的业务控制点的触发结果进行后续触发。当该指示取值表示不采用被触发的业务控制点的触发结果进行后续触发时，指示业务触发点在触发一个业务控制点之后，不采用该业务控制点的返回消息，而继续采用所述业务触发事件触发下一个业务控制点。参见图5，图5是本发明实施例4中串行触发2个业务控制点的流程图。其中，业务触发点为Service Broker，业务触发数据存储单元为HSS，2个业务控制点分别是AS1和AS2。该流程包括以下步骤：

步骤501、Service Broker从HSS获取业务触发数据，例如采用基于XML的过滤规则形式描述的FC数据。

步骤502、Service Broker接收用户A发送给用户B的INVITE请求消息。

步骤503、经过处理，该INVITE消息被转发至用户B。

步骤504、用户B发送180Ringing消息提示被叫振铃。

该步骤中，Service Broker启动定时器监视被叫用户B是否应答。

步骤505、定时器超时后，Service Broker检查用户A的FC数据。

该步骤中，用户B在Service Broker启动的上述定时器超时前未能发送200OK应答消息，因此，在定时器超时后，Service Broker的业务触发检测处理就被触发，此时Service Broker内部状态迁移至发端无应答。用户A的FC数据存在如下几条描述：

FC1描述如下：

<FilterCriteria>

              <Priority>10</Priority>

              <TriggerPoint>

                 <ConditionTypeCNF>0</ConditionTypeCNF>

                 <SPT>

                 ……

                 <SessionState>O_NoAnswer</SessionState>

                 </SPT>

              </TriggerPoint>

              <ApplicationServer>

<ServerName>sip:AS1@homedomain.com</ServerName>

                  <TriggerConditionMode>0</TriggerConditionMode>

                  <DefaultHandling>0</DefaultHandling>

               </ApplicationServer>

 </FilterCriteria>

FC2描述如下：

<FilterCriteria>

              <Priority>12</Priority>

              <TriggerPoint>

                <ConditionTypeCNF>0</ConditionTypeCNF>

                <SPT>

                ……

                <SessionState>O_NoAnswer</SessionState>

                </SPT>

             </TriggerPoint>

               <ApplicationServer>

<ServerName>sip:AS2@homedomain.com</ServerName>

                  <TriggerConditionMode>1</TriggerConditionMode>

                  <DefaultHandling>0</DefaultHandling>

               </ApplicationServer>

 </FilterCriteria>

其中FC1与FC2的业务触发条件均为<SessionState>O_NoAnswer</SessionState>，即会话状态由建立会话迁移为发端无应答状态。本实施例将基于同一个会话状态迁移事件，调用上述AS1和AS2。另外，本实施例中，FC1与FC2中均增加了一个触发条件模式(TriggerConditionMode)属性，该TriggerConditionMode即用于指示业务触发点是否采用被调用的业务控制点的调用结果，再继续调用下一个业务控制点。设TriggerConditionMode为0表示不采用；TriggerConditionMode为1表示需要采用。那么，在本实施例中，根据FC1的描述<TriggerConditionMode>0</TriggerConditionMode>，Service Broker将INVITE消息触发给AS1后，并不采用AS1返回的消息，就可使用所述INVITE消息继续处理FC2；根据FC2的描述<TriggerConditionMode>1</TriggerConditionMode>，Service Broker将INVITE消息触发给AS2后，需要等待AS2返回消息，以根据该触发结果进行后续的触发处理。

即此时业务触发点Service Broker根据与同一业务触发事件对应的至少一条指示不采用被触发业务控制点的触发结果进行后续触发的业务触发数据，互相独立的串行触发多个业务控制点AS1、AS2。

步骤506、Service Broker根据FC1向AS1发送INVITE消息。

该步骤处理完毕后，由于FC1中TriggerConditionMode为0，表示ServiceBroker可以继续处理下一个低优先级的FC2，而不需要等待AS1返回消息，因此Service Broker继续处理FC2。

步骤507、Service Broker根据FC2向AS2发送INVITE消息。

该步骤中，Service Broker根据FC2的描述，由于FC2中TriggerConditionMode为1，因此Service Broker需要等待AS2返回的消息以根据该触发结果进行后续的触发处理。

步骤508、AS1返回200OK消息。

步骤509、AS2返回INVITE消息。

至此，对本发明实施例4的说明结束。

接下来还需要说明本发明中业务触发点处理基于所述业务触发事件所触发的多个业务控制点的响应的方式至少包括如下之一：分别处理每个业务控制点的触发响应，包括各种触发响应消息及触发未响应的情况；或者，业务触发点只处理所述多个业务控制点中第一个返回的消息；或者，业务触发点只处理指定的业务控制点的响应；或者，只要所述多个业务控制点中有一个没有返回响应，则业务触发点只处理该未响应情况；或者，业务触发点等所述多个业务控制点的响应都一致时，处理该响应，该一致的情况可包括：都是成功的响应、或都是失败的响应、或都未响应。

所述业务触发点的处理至少包括如下之一：针对业务触发消息发送响应消息、失败处理、进行后续的业务触发、SIP对话处理。

所述针对业务触发消息发送响应消息，例如业务触发消息为用户注册消息，该消息可触发多个第三方注册消息。相应地，针对业务触发消息发送响应消息指的是该注册消息的响应消息，如200OK消息。

所述失败处理指当业务触发点调用业务控制点失败后的处理，所述失败至少包括如下之一：业务控制点无响应、业务控制点返回消息指示调用失败。例如当业务触发点并行触发多个业务控制点时，当多个业务控制点都没有响应时，业务触发点进行失败处理，如根据iFC数据中的DefaultHandling进行终止会话或者继续触发等处理。

所述进行后续的业务触发指业务触发点在处理业务控制点的响应后继续进行后续的业务触发处理。例如当业务触发点并行触发多个业务控制点时，当收到所述多个业务控制点中的第一个返回消息时，业务触发点基于该消息进行后续的业务触发处理，如根据该返回消息检查后续的iFC以触发后续业务控制点。

所述SIP对话处理指业务触发点在收到业务控制点返回的响应后处理SIP对话，例如迁移对话状态，例如业务触发点串行向多个业务控制点发送SUBSCRIBE消息，当各个业务控制点返回200OK消息后，业务触发点将对应的多个SIP对话分别置为建立状态。

所述指定的业务控制点的指定方式可以是：在业务触发数据中增加是否需要进行指定处理的描述项。例如指定业务触发点是否需要针对业务触发消息发送响应消息，则该iFC的描述可以是：

<InitialFilterCriteria>

              <Priority>23</Priority>

              <TriggerPoint>

                 <ConditionTypeCNF>0</ConditionTypeCNF>

                 <SPT>

                   <ConditionNegated>0</ConditionNegated>

                   <Group>0</Group>

                   <Method>SUB SCRIBE</Method>

                </SPT>

             </TriggerPoint>

             <ApplicationServer>

<ServerName>sip:AS2@homedomain.com</ServerName>

                  <NeedResponse>0</NeedResponse>

                  <DefaultHandling>0</DefaultHandling>

               </ApplicationServer>

 </InitialFilterCriteria>

该iFC描述中，增加NeedResponse项，该NeedResponse项用于指示：需要向业务触发消息的发起端发送响应消息，或不需要向业务触发消息的发起端发送响应。当iFC数据中该属性项不存在时可提供默认值，例如默认不需要发送响应消息。当业务触发点得到第一个指定需要发送响应消息的业务控制点的调用结果，例如收到业务控制点表示调用成功的消息，或者表示调用失败的消息，或业务控制点无响应时，根据NeedResponse判断是否需要发送上述响应消息，设NeedResponse取值为0表示需要发送上述响应消息。

业务触发点向业务触发事件的发起端发送的响应消息可以是：

业务触发点收到业务控制点的返回的SIP响应消息时，将该SIP响应消息转发给业务触发事件的发起端；

业务触发点收到业务控制点返回的SIP请求消息时，向业务触发事件的发起端发送200OK响应消息；

业务控制点无响应时，业务触发点向业务触发事件的发起端发送响应消息，该响应消息可以是：480Temporarily unavailable、408 Request Timeout或SIP 5XX等系列响应消息。

当业务触发点向业务触发事件的发起端发送过一次响应消息之后，即使后续iFC数据中NeedResponse项指示需要发送上述响应消息，业务触发点也不再向业务触发事件的发起端发送响应消息，即只有得到第一个指定需要发送响应消息的业务控制点的结果后才会发送响应消息。

所述业务触发点对多个业务控制点的响应的处理对并行触发或者串行触发多个业务控制点的方式均适用。

综上所述，本发明实施例提供的上述业务触发方法、系统及业务触发点，基于同一个业务触发事件，来调用多个业务控制点，而不需要在调用一个业务控制点后，再基于该业务控制点返回的消息，调用下一个业务控制点，因此，能够保证后续业务控制点的触发。而且相比较串行调用业务控制点的做法而言，本发明实施例通过一次调用多个业务控制点，能够有效提高业务触发的效率。本发明还具备提供用户自己选择业务控制点的机会的优点。

Claims (18)

1.一种业务触发方法，其特征在于，包括：

监测业务触发事件；

确定需要根据该业务触发事件触发的多个业务控制点；

触发该多个业务控制点。

2.根据权利要求1所述的方法，其特征在于，所述触发该多个业务控制点的步骤包括：并行触发，或串行触发。

3.根据权利要求1所述的方法，其特征在于，所述确定需要根据该业务触发事件触发的多个业务控制点的步骤包括：

根据与该业务触发事件对应的业务触发数据，确定需要根据该业务触发事件触发多个业务控制点。

4.根据权利要求3所述的方法，其特征在于，所述确定需要根据该业务触发事件触发的多个业务控制点的步骤包括：

根据在与该业务触发事件对应的一条业务触发数据中存在多个业务控制点的地址配置信息，确定需要根据该业务触发事件触发与所述业务触发数据对应的多个业务控制点。

5.根据权利要求4所述的方法，其特征在于，所述触发该多个业务控制点的步骤包括：根据所述业务触发数据中的触发顺序模式指示或存在的多个业务控制点地址配置信息，并行或串行触发所述多个业务控制点。

6.根据权利要求3所述的方法，其特征在于，所述确定需要根据该业务触发事件触发的多个业务控制点的步骤包括：根据在与该业务触发事件对应的多条业务触发数据中存在相同优先级配置的信息，确定需要根据该业务触发事件触发所述业务触发数据对应的多个业务控制点。

7.根据权利要求6所述的方法，其特征在于，所述触发该多个业务控制点的步骤包括：并行触发所述多个业务控制点。

8.根据权利要求1所述的方法，其特征在于，所述确定需要根据该业务触发事件触发的多个业务控制点的步骤包括：

当业务触发事件是特定业务触发消息时，判断该业务触发消息是否需要本地终结，若是，则确定需要根据该业务触发事件触发与其对应的多条业务触发数据中描述的多个业务控制点。

9.根据权利要求8所述的方法，其特征在于，所述特定业务触发消息包括：SIP REGISTER注册消息、SIP SUBSCRIBE订阅消息、SIP PUBLISH发布消息或SIP NOTIFY通知消息。

10.根据权利要求3所述的方法，其特征在于，所述确定需要根据该业务触发事件触发的多个业务控制点的步骤包括：

根据与该业务触发事件对应的业务触发数据中至少一条指示不采用被触发的业务控制点的触发结果，触发所述多个业务控制点中的其他业务控制点的信息，确定需要根据该业务触发事件触发与其对应的多条业务触发数据中描述的多个业务控制点。

11.根据权利要求8或10所述的方法，其特征在于，所述触发该多个业务控制点的步骤包括：根据该业务触发事件，串行触发该多个业务控制点。

12.根据权利要求1所述的方法，其特征在于，触发该多个业务控制点之后，该方法进一步包括：处理所述多个业务控制点的响应，所述处理多个业务控制点的响应的步骤包括：

分别处理每个业务控制点的触发响应；或，只处理所述多个业务控制点中第一个返回的消息；或，只处理指定的业务控制点的响应；或，只要所述多个业务控制点中有一个没有返回响应，则只处理该未响应情况；或，等所述多个业务控制点的响应都一致时，处理该响应。

13.根据权利要求12所述的方法，其特征在于，所述处理所述多个业务控制点的响应的步骤进一步包括：

针对业务触发消息发送响应消息、进行失败处理、进行后续的业务触发、或进行SIP对话处理。

14.一种业务触发装置，其特征在于，包括：

监测单元、业务控制点信息提供单元和触发单元，其中，

监测单元，用于监测业务触发事件，将监测到的业务触发事件信息传送给业务控制点信息提供单元；

业务控制点信息提供单元，用于接收来自监测单元的业务触发事件信息，确定需要根据该业务触发事件触发多个业务控制点，将该多个业务控制点信息传送给触发单元；

触发单元，用于接收来自业务控制点信息提供单元的多个业务控制点信息，触发该多个业务控制点。

15.根据权利要求14所述的装置，其特征在于，所述装置进一步包括：

业务触发数据获取单元，用于获取业务触发数据，将业务触发数据信息传送给业务控制点信息提供单元；

业务控制点信息提供单元，进一步用于接收来自业务触发数据获取单元的所述业务触发数据信息，根据与该业务触发事件对应的业务触发数据，确定需要根据该业务触发事件触发多个业务控制点。

16.一种业务触发系统，其特征在于，包括：业务触发装置和多个业务控制点，其中，

业务触发装置，用于监测业务触发事件，确定需要根据该业务触发事件触发多个业务控制点，且触发该多个业务控制点。

17.根据权利要求16所述的系统，其特征在于，所述业务触发装置包括：

监测单元、业务控制点信息提供单元和触发单元，其中，

监测单元，用于监测业务触发事件，将监测到的业务触发事件信息传送给业务控制点信息提供单元；

业务控制点信息提供单元，用于接收来自监测单元的业务触发事件信息，确定需要根据该业务触发事件触发多个业务控制点，将该多个业务控制点信息传送给触发单元；

触发单元，用于接收来自业务控制点信息提供单元的多个业务控制点信息，触发该多个业务控制点。

18.根据权利要求16所述的系统，其特征在于，所述业务触发系统进一步包括：；

业务触发数据存储单元，该单元用于存储业务触发数据，并将业务触发数据传送给业务触发装置；

所述业务触发装置进一步包括：

业务触发数据获取单元，用于接收来自业务触发数据存储单元的业务触发数据信息，将业务触发数据信息传送给业务控制点信息提供单元；

业务控制点信息提供单元，进一步用于接收来自业务触发数据获取单元的所述业务触发数据信息，根据与该业务触发事件对应的业务触发数据，确定需要根据该业务触发事件触发多个业务控制点。

Images