CN101188598A - 控制业务调用的系统、方法及业务控制点装置 - Google Patents
控制业务调用的系统、方法及业务控制点装置 Download PDFInfo
- Publication number
- CN101188598A CN101188598A CNA2007101123723A CN200710112372A CN101188598A CN 101188598 A CN101188598 A CN 101188598A CN A2007101123723 A CNA2007101123723 A CN A2007101123723A CN 200710112372 A CN200710112372 A CN 200710112372A CN 101188598 A CN101188598 A CN 101188598A
- Authority
- CN
- China
- Prior art keywords
- service
- indication
- callable
- control point
- trigger
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 54
- 230000006854 communication Effects 0.000 claims abstract description 86
- 238000004891 communication Methods 0.000 claims abstract description 82
- 238000012545 processing Methods 0.000 claims abstract description 16
- 238000001514 detection method Methods 0.000 claims description 13
- 230000005540 biological transmission Effects 0.000 claims description 5
- 238000010276 construction Methods 0.000 claims description 2
- 230000000977 initiatory effect Effects 0.000 claims description 2
- 230000011664 signaling Effects 0.000 abstract description 8
- 230000001960 triggered effect Effects 0.000 abstract description 5
- GOLXNESZZPUPJE-UHFFFAOYSA-N spiromesifen Chemical compound CC1=CC(C)=CC(C)=C1C(C(O1)=O)=C(OC(=O)CC(C)(C)C)C11CCCC1 GOLXNESZZPUPJE-UHFFFAOYSA-N 0.000 abstract 1
- 101150002629 TAS1 gene Proteins 0.000 description 21
- 101150080315 SCS2 gene Proteins 0.000 description 7
- 238000013507 mapping Methods 0.000 description 7
- 238000012544 monitoring process Methods 0.000 description 6
- 102100021277 Beta-secretase 2 Human genes 0.000 description 5
- 102100027674 CTD small phosphatase-like protein Human genes 0.000 description 5
- 101710156847 CTD small phosphatase-like protein Proteins 0.000 description 5
- 238000006243 chemical reaction Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 2
- 101710150190 Beta-secretase 2 Proteins 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 235000015096 spirit Nutrition 0.000 description 1
Images
Landscapes
- Telephonic Communication Services (AREA)
Abstract
本发明实施例提供一种控制业务调用的系统，其应用于多业务服务器环境下，包括：业务触发点，用于检测业务触发条件，并在触发条件满足时将通信触发至第一业务控制点；以及至少一个第一业务控制点，用于从业务触发点发送的通信事件消息中获得可调用业务指示，并据此控制所述可调用业务的执行。本发明实施例还提供一种控制业务调用的方法以及业务控制点装置。本发明实施例能够保证多业务服务器环境下业务优先级的要求，还可以在业务触发点连接需要进行二次触发的业务控制点的情况下做统一的触发控制处理，提高了触发处理效率。本发明实施例还可以减少信令时延以及减轻网络负荷，并且在出现业务冲突时可禁止冲突业务调用。
Description
技术领域
本发明实施例涉及通信领域，尤其是涉及一种控制业务调用的系统、方法以及业务控制点装置。
背景技术
IP多媒体子系统(IMS)是第三代移动通信标准化伙伴项目(3GPP)在版本5中引入的，它是一个基于会话初始化协议(SIP)的体系，它的会话层和业务层是分离的，会话层的服务呼叫会话控制功能(Serving CSCF，简称S-CSCF)可以通过预先配置的初始过滤规则(iFC)来调用业务层的IMS应用服务器(AS)。
3GPP技术标准(3GPP TS)23.218中定义的IMS系统业务架构如图1所示，图中的应用服务器包括三类：SIP应用服务器，开放业务接入(OSA)应用服务器及IMS业务交换功能(IM-SSF)。SIP应用服务器用于实现基于SIP的增值应用，OSA应用服务器用于实现基于OSA应用接口(API)的第三方应用，OSA应用服务器需通过OSA业务能力服务器(SCS)与IMS核心网进行交互，而IM-SSF用于支持在IMS域内提供移动网络增强逻辑的客户化应用(CAMEL)业务能力。在IMS网络中业务可以分布在多个AS上提供，同时一个AS内部也可以提供多种业务，在具体实施时同类业务一般放在同一个AS上提供，例如电话AS(TAS)专门提供呼叫控制类的业务，开放业务接入业务能力服务器(OSA SCS)AS专门提供使用OSA API开发的业务。
如上所述，IMS网络中业务可以分布在多个AS上提供，而一个AS又可以提供多种业务，由于AS之间互相不感知，一个AS收到通信消息后将执行所有满足触发条件的业务，这样可能存在如下问题：
用户签约了业务s1、s2、s3、s4、s5，它们在用户发起INVITE消息的时候被触发，其中s1、s2、s3在AS1上提供，s4、s5在AS2上提供，实际的业务调用优先级应为先调用AS1上的s1、s2，然后调用AS2上的s4，再调用AS1上的s3，最后调用AS2上的s5。
按照现有技术，AS1收到INVITE消息时将一次性执行完业务s1、s2、s3，这样将无法满足上述业务优先级要求。因此考虑业务触发点指示业务控制点可调用的业务，业务控制点据此来控制业务的执行。
另外，现有IMS系统中，IM-SSF以及OSA SCS需要做二次触发或者分发以将通信消息发送至智能业务控制点(SCP)或者OSA应用，即S-CSCF首先需要触发到IM-SSF或者OSA SCS，然后再通过IM-SSF或者OSA SCS触发到具体的应用。同时IM-SSF、OSA SCS的触发功能与S-CSCF、Service Broker(业务代理)的触发功能又重复。因此，为提高处理效率，考虑在IM-SSF以下的业务触发点做统一的触发控制，IM-SSF、OSA SCS只做信令转换处理。
发明内容
本发明实施例要解决的技术问题在于，克服上述现有技术存在的不足，提供一种控制业务调用的系统、方法以及业务控制点装置，以满足根据业务优先级调用业务的要求。
为解决上述技术问题，本发明实施例提供一种控制业务调用的系统，其应用于多业务服务器环境下，包括：
业务触发点，用于检测业务触发条件，并在触发条件满足时将通信触发至第一业务控制点；以及
至少一个第一业务控制点，用于从业务触发点发送的通信事件消息中获得可调用业务指示，并据此控制所述可调用业务的执行。
本发明实施例还提供一种控制业务调用的方法，其应用于多业务服务器环境下，包括以下步骤：
A.业务触发点检测业务触发条件，并根据业务触发规则发送携带可调用业务指示的通信事件消息至第一业务控制点；以及
B.第一业务控制点从所述通信事件消息获得可调用业务指示，并据此控制所述可调用业务的执行。
本发明实施例还提供一种业务控制点装置，其包括：
业务调用消息接收单元：用于接收业务触发点发送的业务调用通信事件消息；
业务调用匹配单元：用于从业务调用消息接收单元接收的消息中获得可调用业务指示；以及
业务处理控制单元：用于根据从业务调用匹配单元得到的可调用业务指示来控制所述可调用业务的执行。
本发明实施例具有以下有益的效果：能够保证多业务服务器环境下业务优先级的要求，还可以在业务触发点连接需要进行二次触发的业务控制点的情况下做统一的触发控制处理，提高了触发处理效率。本发明实施例还可以减少信令时延以及减轻网络负荷并且在出现业务冲突时可禁止冲突业务调用。
附图说明
图1是IMS系统业务架构示意图。
图2是本发明实施例多业务服务器环境下控制业务调用的系统架构示意图。
图3是本发明实施例多业务服务器环境下控制业务调用的方法第一实施例的流程图。
图4是本发明实施例多业务服务器环境下控制业务调用的方法第二实施例的流程图。
具体实施方式
以下结合附图对本发明实施例进行详细描述。
本发明实施例的网络架构如图2所示，图中各逻辑网元说明如下：
1、业务触发点提供业务触发条件检测功能，并在触发条件满足时将通信触发至第一业务控制点。业务触发点至少包括：S-CSCF、Service Broker。
业务触发点内部还包括三个单元模块：
业务触发检测单元：用于检测业务触发条件
业务调用消息构造单元：用于当业务触发条件满足时构造业务调用的通信事件消息
业务调用消息发送单元：用于通过E1接口发送业务调用通信事件消息
2、第一业务控制点用于从业务触发点发送的通信事件消息中获得可调用业务指示，并据此控制所述可调用业务的执行。第一业务控制点可以独立提供业务流程控制功能或者在第二业务控制点控制下执行业务流程。当存在第二业务控制点时，它还可以根据业务调用条件将通信触发至第二业务控制点，在第二业务控制点的控制之下执行业务流程，并执行第二业务控制点和业务触发点之间的信令转换功能，例如第一业务控制点为IM-SSF时，它将业务触发点发来的SIP消息转换为智能协议消息发送给SCP。第一业务控制点至少包括：SIP AS、IM-SSF、OSA SCS。网络中可以存在多个第一业务控制点，且一个第一业务控制点上可以提供多种业务。
第一业务控制点内部还包括三个单元模块：
业务调用消息接收单元：用于通过E1接口接收业务触发点发送的业务调用通信事件消息
业务调用匹配单元：用于从业务调用消息接收单元接收的消息中获得可调用的业务指示
业务处理控制单元：用于根据从业务调用匹配单元得到的可调用业务指示来控制所述可调用业务的执行。
3、第二业务控制点用于控制第一业务控制点执行业务流程，当存在第二业务控制点时，第一业务控制点需要执行业务触发点和第二业务控制点之间的信令消息转换功能，第二业务控制点至少包括：SCP、OSA应用。第二业务控制点在网络中不是必须的，如当网络中只提供SIP AS时，可以不需要第二业务控制点。
4、业务触发点至第一业务控制点存在E1接口，该接口协议至少包括：SIP、内部接口协议(例如业务触发点和第一业务控制点合设)。
5、第一业务控制点至第二业务控制点存在E2接口，该接口协议至少包括：智能网应用规程(INAP)、移动网络增强逻辑的客户化应用部分协议(CAP)、移动应用部分(MAP)协议、OSA应用编程接口(API)、内部接口协议(例如第一业务控制点和第二业务控制点合设)。
6、可选的，当第一业务控制点和业务触发点合设时，业务触发点和第二业务控制点间存在E3接口，该接口协议至少包括：智能网应用规程(INAP)、移动网络增强逻辑的客户化应用部分协议(CAP)、移动应用部分(MAP)协议、OSA应用编程接口(API)、内部接口协议(例如第一业务控制点、业务触发点以及第二业务控制点合设)。
本发明实施例的技术方案为：
业务触发点检测业务触发条件，并根据业务触发规则发送携带可调用业务指示的通信事件消息至第一业务控制点，第一业务控制点根据所述可调用业务指示，控制所述可调用业务的执行。
其中：
1、所述可调用业务指示至少可以通过如下业务触发规则元素之一获得：服务器地址配置、业务信息透明数据、业务标识配置。业务触发点执行所述业务触发规则，如IMS网络中的iFC(初始过滤规则，Initial Filter Criteria)，获得可调用业务指示，将其携带于所述通信事件消息中，可调用业务指示用于向第一业务控制点指示可以调用的业务，第一业务控制点可以根据该指示控制业务的执行。
通过服务器地址配置表示的可调用业务指示可以设置在业务触发规则数据中，业务触发规则数据中可以只有一条服务器地址配置，指示一个或一个以上的可调用业务信息；或者，也可以有多条服务器地址配置，指示一个以上的可调用业务信息。
以iFC为样例，业务触发规则数据中的服务器地址配置描述部分示例为：
<ApplicationServer>
<ServerName>sip:AS1.home1.net；service＝s1，s3，s5</ServerName>
</ApplicationServer>
又如：
<ApplicationServer>
<ServerName>sip:part1@AS1.home1.net</ServerName>
</ApplicationS erver>
或者，
<ApplicationServer>
<ServerName>sip:part1.AS1.home1.net</ServerName>
</ApplicationServer>
又如：
<ApplicationServer>
<ServerName>sip:s1@AS1.home1.net，sip:s3@AS1.home1.net，
sip:s5@AS1.home1.net</ServerName>
</ApplicationServer>
有多条服务器地址配置的示例为：
<ApplicationServer>
<ServerName>sip:s1@AS1.home1.net</ServerName>
<ServerName>sip:s3@AS1.home1.net</ServerName>
<ServerName>sip:s5@AS1.home1.net</ServerName>
</ApplicationServer>
在上述示例中，“ApplicationServer”表示应用服务器信息，“ServerName”表示服务器名称，在<ServerName>和</ServerName>之间的内容就是所述服务器地址配置，业务触发点将上述服务器地址配置放至SIP消息Route头域，即通过SIP头域携带可调用业务指示。上面的例子中业务触发点发出的SIP消息中的可调用业务指示通过SIP消息Route头域携带包括第一业务控制点的地址条目来表示。
所述SIP消息中Route头域的示例如下：
Route：<sip:AS1.home1.net；service＝s1，s3，s5；lr>
或者，
Route：<sip:part1@AS1.home1.net；lr>
或者，
Route：<sip:part1.AS1.home1.net；lr>
或者，
Route：<sip:s1@AS1.home1.net；lr>，<sip:s3@AS1.home1.net；lr>，
<sip:s5@AS1.home1.net；lr>
或者，
Route：<sip:s1@AS1.home1.net；lr>
Route：<sip:s3@AS1.home1.net；lr>
Route：<sip:s5@AS1.home1.net；lr>
第一业务控制点收到该SIP消息后，根据其中的“s1”、“s3”、“s5”执行对应的业务s1、s3和s5；或者，感知其中的“part1”对应s1、s3和s5业务，再执行对应的业务。
可以看到，当可调用业务指示中包括一个以上的业务信息时，可以在一个Route头域中列出具体的所有的业务信息；或者，也可以在多个Route头域中列出所有的业务信息，每个Route头域中携带一个业务信息。
此外，当可调用业务指示中包括一个以上的业务信息时，这些业务信息在服务器地址配置中出现的顺序，可以就是第一业务控制点执行这些业务的优先级顺序，如按顺序执行s1、s3、s5业务。
此外，当业务触发规则数据中设置有多条服务器地址配置，业务触发点可以将这些服务器地址配置一一放至在多条Route头域中或一个Route头域中，业务触发点向第一业务控制点发送携带这些Route头域的SIP消息。第一业务控制点收到所述SIP消息，依次处理完所有所述服务器地址配置对应的业务后，向业务触发点返回一个SIP消息，此时，若第一业务控制点要将自身加入SIP信令路径中，则在该消息的Record-Route头域中可以只携带其中一个服务器地址配置，也可以仍携带所有的服务器地址配置。
通过业务信息透明数据表示的可调用业务指示例如：
Content-Type:application/serviceinfo+xml
<？xml version＝″1.0″encoding＝″UTF-8″？>
<serviceinfo xmlns＝″urn:ietf:params:xml:ns:serviceinfo″>
<service>
<servicekey>s1</servicekey>
<priority>0</priority>
</service>
</serviceinfo>
业务信息透明数据的含义为它对业务触发点透明，业务触发点在构造发送至第一业务控制点的通信事件消息时，将上述如业务触发规则数据中的业务信息透明数据拷贝至SIP消息的消息体部分，如上述的serviceinfo消息体，即通过SIP消息体携带可调用业务指示。上面的例子中业务触发点发出的SIP消息中的可调用业务指示通过SIP消息的消息体中携带业务信息透明数据来表示。
通过业务标识配置表示的可调用业务指示可以设置在业务触发规则数据中，以iFC为例，示例为：
<ApplicationServer>
<ServerName>sip:AS1.home1.net</ServerName>
<ServiceIdentity>
<ServiceName>s1</ServiceName>
<ServiceName>s3</ServiceName>
<ServiceName>s5</ServiceName>
</ServiceIdentity>
</ApplicationServer>
在上述示例中，<ServiceIdentity>本发明为iFC中新扩展的、表示业务标识配置的标签条目，其中给出了可调用业务指示“s1”、“s3”和“s5”这三个业务标识，业务触发点在构造发送至第一业务控制点的通信事件消息时，将上述iFC中的可调用业务指示通过SIP消息中表示业务标识的信息段传递，如通过P-Asserted-Service头域传递。
可见，所述通信事件消息根据服务器地址配置路由至第一业务控制点，第一业务控制点根据消息中携带的可调用业务指示执行特定的业务。服务器地址配置除了包括路由地址信息外，还包括可调用业务信息，如AS1.home1.net即是路由地址信息，被用来将通信事件消息路由至第一业务控制点，而“s1”、“s3”、“s5”、“part1”等即是可调用业务信息，向第一业务控制点指示执行特定的业务；或者，第一业务控制点解析业务信息透明数据，获得可调用业务信息，如上面示例中的servicekey标签对应的值“s1”，执行特定的业务；或者，第一业务控制点解析消息中的业务标识信息段，获得可调用业务信息，执行特定的业务。
此外，业务触发点调用第一业务控制点，向第一业务控制点发送的通信事件消息中携带第一可调用业务指示，业务触发点收到第一业务控制点返回的调用响应后，继续执行业务触发规则数据的匹配，如果匹配成功，获得第二业务控制点，业务触发点向第二业务控制点发送的通信事件消息中携带第二可调用业务指示，使第二业务控制点从收到的通信事件消息的可调用业务指示中获得第二可调用业务指示的方法有如下几种：
方法一：业务触发点删除收到的第一业务控制点返回的调用响应中的第一可调用业务指示，即业务触发点向第二业务控制点发送的、由其添加的可调用业务指示中只有第二可调用业务指示。比如，业务触发点向第一业务控制点发送SIP INVITE邀请消息，消息中携带了第一可调用业务指示“s1”、“s3”和“s5”，第一业务控制点完成业务处理，向业务触发点返回SIP INVITE消息，消息中携带了第一可调用业务指示的全部或部分(部分是指只有“s1”、“s3”和“s5”中的部分)，业务触发点在向第二业务控制点发送SIP INVITE消息前，删除消息中的第一可调用业务指示，第二业务控制点收到的SIP INVITE消息中没有第一可调用业务指示。
方法二：业务触发点按顺序在向业务控制点发送的通信事件消息中添加可调用业务指示，第二业务控制点收到通信事件消息后，按顺序取出最近添加的可调用业务指示作为第二可调用业务指示，如从所有的可调用业务指示中将最后面的、或最前面的作为第二可调用业务指示。比如，业务触发点调用第一业务控制点的消息示例如下：
P-Asserted-Service:s1，s3，s5
在上述示例中，在一个P-Asserted-Service头域中携带第一可调用业务指示“s1”、“s3”和“s5”这三个业务标识，此后，业务触发点调用第二业务控制点的消息示例如下：
P-Asserted-Service:s2，s4
P-Asserted-Service:s1，s3，s5
在上述示例中，业务触发点将第二可调用业务指示携带于另一个P-Asserted-Service头域，并放置在其它P-Asserted-Service头域的最前面，这样，第二业务控制点收到消息后，将放置在最前面的P-Asserted-Service头域内容作为最近添加的可调用业务指示，即第二可调用业务指示。
此外，业务触发点调用第一业务控制点，向第一业务控制点发送的通信事件消息中携带可调用业务指示时，可以进一步携带和所述可调用业务指示对应的业务触发点标签，该标签可以是业务触发点地址、或一个标识符等，该标识符由业务触发点产生或是一个预置数据(如预置在业务过滤规则中)，业务触发点或第一业务控制点可以根据所述业务触发点标签判断所述可调用业务指示是由业务触发点添加的。
2、所述同一个第一业务控制点实体可以具备多个不同的业务触发规则。
同一个物理上的第一业务控制点可以分为多个逻辑上的第一业务控制点，所述多个逻辑上的第一业务控制点在业务触发规则中可以通过不同的服务器地址配置区分，例如AS1的路由地址为sip:as1.home1.net，AS1可以提供业务1、业务2、业务3、业务4，它可以分为sip:part1@as1.home1.net、sip:part2@as1.home1.net两个逻辑上的业务控制点，其中sip:part1@as1.home1.net提供业务1、业务3，sip:part2@as1.home1.net提供业务2、业务4。地址sip:part1@as1.home1.net以及sip:part2@as1.home1.net各单独使用一个业务触发规则。上述例子中地址sip:part1@as1.home1.net、sip:part2@as1.home1.net仅为示例说明，该地址还可以是sip:part1.as1.home1.net、sip:part2.as1.home1.net的形式。
业务触发点使用的业务触发规则中，业务控制点还可以使用同样的服务器地址配置，但使用其它的可调用业务指示方式，如上述的业务信息透明数据等。
3、业务触发规则和可调用业务指示的对应关系至少包括：一条业务触发规则对应一个可调用业务的指示、一条业务触发规则对应多个可调用业务的指示。
一条业务触发规则对应一个可调用业务的指示的情况例如业务触发规则数据配置为：
存在三条业务触发规则数据，其服务器地址配置分别如下：
<ApplicationServer>
<ServerName>sip:s1@AS1.home1.net</ServerName>
</ApplicationServer>
、
<ApplicationServer>
<ServerName>sip:s3@AS1.home1.net</ServerName>
</ApplicationServer>
、
<ApplicationServer>
<ServerName>sip:s5@AS1.home1.net</ServerName>
</ApplicationServer>
上述三条业务触发规则数据分别对应业务s1、s3、s5的可调用业务指示。
一条业务触发规则对应多个可调用业务的指示的情况例如业务触发规则数据配置为：
存在一条业务触发规则数据，其服务器地址配置分别如下：
<ApplicationServer>
<ServerName>sip:AS1.home1.net；service＝s1，s3，s5</ServerName>
</ApplicationServer>
即通过服务器地址配置中的service参数携带s1、s3、s5这三个业务的可调用业务指示
或者服务器地址配置为
<ApplicationServer><ServerName>sip:part1@AS1.home1.net</ServerNa
me>
</ApplicationServer>
即服务器地址配置设置了一个条目，通过part1这一个可调用业务指示向第一业务控制点指示执行s1、s3、s5这三个业务。
4、业务触发点构造通信事件消息中的可调用业务指示的方式至少包括：将一条业务触发规则数据中的可调用业务指示携带至一条通信事件消息中、将多条业务触发规则数据中的可调用业务指示合并在同一条通信事件消息中。
将业务触发规则数据中的可调用业务指示携带至一条通信事件消息中例如：
存在一条业务触发规则数据，其只有一个服务器地址配置如下：
<ApplicationServer>
<ServerName>sip:AS1.home1.net；service＝s1，s3，s5</ServerName>
</ApplicationServer>
业务触发点将其携带到一个Route头域中。
存在一条业务触发规则数据，其有多个服务器地址配置如下：
<ApplicationServer>
<ServerName>sip:s1@AS1.home1.net</ServerName>
<ServerName>sip:s3@AS1.home1.net</ServerName>
<ServerName>sip:s5@AS1.home1.net</ServerName>
</ApplicationServer>
业务触发点将其携带于一个Route头域的多个条目中或多个Route头域中。
存在一条业务触发规则数据，其有多个业务标识配置如下：
<ApplicationServer>
<ServerName>sip:AS1.home1.net</ServerName>
<ServiceIdentity>
<ServiceName>s1</ServiceName>
<ServiceName>s3</ServiceName>
<ServiceName>s5</ServiceName>
</ServiceIdentity>
</ApplicationServer>
业务触发点将其携带于一个P-Asserted-Service头域的多个条目中或多个P-Asserted-Service头域中。
存在三条业务触发规则数据，其服务器地址配置分别如下：
<ApplicationServer>
<ServerName>sip:s1@AS1.home1.net</ServerName>
</ApplicationServer>
、
<ApplicationServer>
<ServerName>sip:s3@AS1.home1.net</ServerName>
</ApplicationServer>
、
<ApplicationServer>
<ServerName>sip:s5@AS1.home1.net</ServerName>
</ApplicationServer>
业务触发点将其合并为一个Route头域的多个条目或者合并为多个Route头域中。
例如一个Route头域的多个条目：
INVITE sip:bob@home.net SIP/2.0
Route：<sip:s1@AS1.home1.net；lr>，<sip:s3@AS1.home1.net；lr>，
<sip:s5@AS1.home1.net；lr>
或者多个Route头域：
INVITE sip:bob@home.net SIP/2.0
Route：<sip:s1@AS1.home1.net；lr>
Route：<sip:s3@AS1.home1.net；lr>
Route：<sip:s5@AS1.home1.net；lr>
即在一条INVITE消息中携带业务s1、s3和s5的可调用业务指示。
5、业务触发点构造通信事件消息中的可调用业务指示的方式还包括：在第4点说明的基础上删除特定业务的可调用业务指示。
这种方式可用于业务交互检出冲突时的冲突业务禁止调用控制，即当业务触发点通过信令消息或者通过业务触发规则数据识别出已经调用的业务，通过查询业务冲突检测数据发现即将调用的特定业务和所述已经调用的业务冲突时，禁止所述冲突的即将调用的特定业务被调用。
上述说明中如何检出业务冲突以及业务冲突检测数据的描述不在本发明实施例的范围内，此处关注的是检出冲突后删除即将调用的业务的可调用业务指示。
例如：
用户已经调用了业务s1，后续的业务触发规则数据中服务器地址配置为sip:s2@AS1.home1.net，sip:s4@AS1.home1.net，sip:s5@AS1.home1.net；
业务触发点已经获得业务s1的业务冲突级别C1，业务触发点通过执行业务触发规则数据获得所述服务器配置以及对应的业务冲突级别，如sip:s4@AS1.home1.net对应的业务冲突级别C4；
业务触发点通过业务冲突检测数据得知C1对应的业务和C4对应的业务冲突；
业务触发点删除业务s4的可调用业务指示，即此时业务触发点发出的消息中的可调用业务指示为sip:s2@AS1.home1.net，sip:s5@AS1.home1.net。
上述示例同样适用于其它的服务器地址配置形式，如服务器地址配置为sip:AS1.home1.net；service＝s2，s4，s5的情况，业务触发点删除业务s4的可调用业务指示，此时业务触发点发出的消息中的可调用业务指示为sip:AS1.home1.net；service＝s2，s5。
6、所述通信事件中的可调用业务指示为显式或者隐式指示
可调用业务指示用于指示第一业务控制点收到通信事件消息后可以调用的业务，它可以是显式指示也可以是隐式指示。
显式的可调用业务指示为使用明确的可调用业务信息指示第一业务控制点能调用的业务名称。
显式的可调用的业务指示的例子如：
INVITE sip:bob@home.net SIP/2.0
Route：<sip:AS1.home1.net；service＝s1，s3，s5；lr>
……
上述例子中Route头域使用了一个service参数，指示AS1收到消息后能调用业务s1、s3以及s5，另外，参数中“s1”、“s3”以及“s5”的出现顺序还表明了业务调用的优先级。
显式的可调用业务指示的例子又如：
INVITE sip:bob@home.net SIP/2.0
Route：<sip:AS1.home1.net；lr>
……
Content-Type:application/serviceinfo+xml
<？xml version＝″1.0″encoding＝″UTF-8″？>
<serviceinfo xmlns＝″urn:ietf:params:xml:ns:serviceinfo″>
<service>
<servicekey>s1</servicekey>
<priority>0</priority>
</service>
<service>
<servicekey>s3</servicekey>
<priority>2</priority>
</service>
<service>
<servicekey>s5</servicekey>
<priority>6</priority>
</service>
</serviceinfo>
……
上述例子中INVITE消息中使用了一种serviceinfo消息体指示可以调用的业务为s1、s3、s5以及上述业务对应的业务优先级。
显式的可调用业务指示的例子又如：
INVITE sip:bob@home.net SIP/2.0
Route：<sip:s1@AS1.home1.net；lr>
Route：<sip:s3@AS1.home1.net；lr>
Route：<sip:s5@AS1.home1.net；lr>
上述例子中INVITE消息携带了多个Route头域，sip:s1@AS1.home1.net以及sip:s3@AS1.home1.net、sip:s5@AS1.home1.net，业务控制点通过可调用业务信息“s1”、“s3”、“s5”可知道分别对应可调用的业务s1、s3、s5。
另外上述Route头域的出现顺序还表明了业务调用优先级为s1、s3、s5。
显式的可调用业务指示的例子又如：
INVITE sip:bob@home.net SIP/2.0
Route：<sip:s1@AS1.home1.net；lr>，<sip:s3@AS1.home1.net；lr>，<sip:s5@AS1.
home1.net；lr>
上述例子中INVITE消息的一个Route头域携带了三个业务s1、s3、s5的可调用业务指示。
隐式的可调用业务指示为可调用业务信息没有明确指示可调用的业务，但通过配置数据或程序预置等方式，第一业务控制点能够获得可调用业务信息对应的可调用的业务名称。
隐式的可调用业务指示的例子如：
INVITE sip:bob@home.net SIP/2.0
Route：<sip:10001@AS1.home1.net；lr>
Route：<sip:20403@AS1.home1.net；lr>
Route：<sip:30015@AS1.home1.net；lr>
上述例子中INVITE消息携带了多个Route头域，sip:10001@AS1.home1.net以及sip:20403@AS1.home1.net、sip:30015@AS1.home1.net分别对应可调用的业务s1、s3、s5，业务控制点通过配置数据或程序预置等方式获知，例如配置数据中将sip:10001@AS1.home1.net或10001映射至业务s1。
隐式的可调用业务指示的例子又如：
INVITE sip:bob@home.net SIP/2.0
Route：<sip:part1.AS1.home1.net；lr>
……
业务控制点根据配置数据或预置程序等将地址sip:part1.AS1.home1.net或part1映射为可调用的业务，例如映射为业务s1、s3、s5。
7、所述业务可调用指示还可以进一步包含可调用业务的业务优先级信息。
例如：
INVITE sip:bob@home.net SIP/2.0
Route：<sip:AS1.home1.net；lr>
……
Content-Type:application/serviceinfo+xml
<？xml version＝″1.0″encoding＝″UTF-8″？>
<serviceinfo xmlns＝″urn:ietf:params:xml:ns:serviceinfo″>
<service>
<servicekey>s1</servicekey>
<priority>0</priority>
</service>
</serviceinfo>
……
上述消息中指示业务s1的优先级为0。
前面的描述中还包括其它的指示业务优先级的例子，例如Route头域中的可调用业务指示出现的顺序指示的业务优先级。
8、业务触发点向第一业务控制点发送通信事件消息的方式包括：使用新的对话发送、使用原有的对话发送。
使用新的对话发送通信事件消息，例如业务触发点创建新的SIP对话，使用新的SIP消息From以及Call-ID头域发送通信事件消息。
使用原有的对话发送通信事件消息至少包括如下几种形式：使用添加路由的方式发送、使用对话中的通知的方式发送。
使用添加路由的方式发送通信事件消息，例如业务触发点添加至第一业务控制点的Route头域至所述通信事件消息。使用原有的对话添加路由发送的这种方式一般只适用于所述通信事件消息通过SIP初始请求发送，此时SIP对话尚未建立完成，可以继续添加Route头域。
使用对话中的通知的方式发送，例如业务触发点至第一业务控制点的通信事件消息通过SIP INFO消息、SIP PUBLISH消息等方式发送，其中可调用业务指示可以前述的业务信息透明数据等方式携带。
9、所述第一业务控制点根据可调用业务指示控制可调用业务的执行包括：第一业务控制点判断所述通信事件消息中的可调用业务指示相应的业务为自身提供的业务时，处理所述业务，直到所述业务处理完毕，所述第一业务控制点在向业务触发点返回的消息中携带已经调用的业务的可调用业务指示。
例如第一业务控制点AS1收到的消息为：
INVITE sip:bob@home.net SIP/2.0
Route：<sip:s1@AS1.home1.net；lr>
Route：<sip:s3@AS1.home1.net；lr>
Route：<sip:s5@AS1.home1.net；lr>
此时AS1发现上述Route头域对应本地提供的业务s1、s3、s5，此时AS1根据业务优先级按顺序处理上述业务的调用，当上述业务处理完毕以后，AS1发送INVITE消息路由至业务触发点以进行后续的业务触发或者会话控制，如果AS1只成功调用了业务s1和s5，则AS1在向业务触发点发送的INVITE消息中携带业务s1和s5的可调用业务指示，业务触发点解析收到的INVITE消息中的可调用业务指示获得已经调用的业务，如解析s1和s5的可调用业务指示，获得s1和s5已经被第一业务控制点调用；或者，业务触发点比较其发送的可调用业务指示和收到的可调用业务指示，获得已经调用的业务，比如，业务触发点向第一业务控制点发送的可调用业务指示是s1、s3、s5，而从第一业务控制点收到的可调用业务指示是s1、s5，通过比较，业务触发点获得s1、s5已经被第一业务控制点调用。
10、所述业务触发点要检测的业务触发条件至少包括：业务触发规则中配置要检测的业务触发条件、第一业务控制点在通信过程中请求业务触发点检测的业务触发条件。
所述业务触发条件至少包括以下一种：接收的通信消息、会话状态、时间信息、用户呈现(Presence)信息、用户状态等。
业务触发点检测业务触发条件，若业务触发规则被匹配，则向描述在业务触发规则中的所述第一业务控制点发送所述通信事件消息。
例如当第一业务控制点为IM-SSF时，此种方式包括业务触发点上获取的业务触发规则数据中静态配置智能业务TDP(Trigger Detection Point，触发检测点)。
第一业务控制点在通信过程中请求业务触发点检测的业务触发条件，包括第一业务控制点在通信过程中向业务触发点下发业务触发规则或者订阅需要接收的通信事件消息。
例如当第一业务控制点为IM-SSF时，此种方式包括IM-SSF向业务触发点下发智能业务EDP(Event Detection Point，事件检测点)检测请求，例如使用因特网工程任务组(IETF)制定的征求意见稿(RFC)3910下发SPRITS(Servicesin PSTN(公共电话交换网)requesting Internet Services，PSTN业务请求因特网业务)协议，请求业务触发点检测EDP事件。
第一业务控制点下发的EDP检测请求中还可以携带透明业务数据，业务触发点上报对应的通信事件消息时，将所述的透明业务数据拷贝到通信事件消息中。例如第一业务控制点为IM-SSF时，为了能够将业务触发点上报的通信消息事件对应到IM-SSF调用的具体智能业务上，可以扩展SPIRITS协议在下发的事件监视请求中携带透明业务数据，例如携带IM-SSF内部的状态机号或者携带业务键、SCP地址、智能网协议以及协议版本等，业务触发点监视到对应的通信事件消息后将上述数据拷贝至上报通信事件消息中，通过这种方式IM-SSF能够方便的识别业务触发点上报的通信事件消息需要发送给哪个智能业务，其后IM-SSF可以根据这些数据快速构造智能网协议消息并发送到对应的SCP。例如IM-SSF调用了智能业务1以及智能业务2，这两个业务在IM-SSF内部分别对应两个控制块1001与1002，智能业务1配置了发端_忙事件，智能业务1和智能业务2都配置了发端_应答事件，则IM-SSF请求业务触发点检测EDP事件的SPIRITS协议消息中对于发端_忙事件携带对应智能业务1的控制块编号的透明数据1001；对于发端_应答事件携带对应智能业务1的控制块编号的透明数据1001以及对应智能业务2的控制块编号的透明数据1002。后续业务触发点上报发端_忙事件后，携带对应智能业务1的控制块编号的透明数据1001，IM-SSF根据此数据可快速定位到内部控制块1001，并向智能业务1上报发端_忙事件事件；类似的业务触发点上报发端_应答事件后，携带对应智能业务1的控制块编号的透明数据1001以及对应智能业务1的控制块编号的透明数据1002，IM-SSF根据此数据可快速定位到内部控制块1001以及1002，并向智能业务1以及智能业务2上报发端_忙事件。
11、所述第一业务控制点不做触发检测，将业务触发点上报的通信事件消息转换为第二业务控制点可识别的格式后，触发到第二业务控制点。
例如第一业务控制点为IM-SSF，它使用SPRITS协议，请求业务触发点检测EDP事件。业务触发点根据SPRITS协议进行事件监视，并在IM-SSF请求的事件发生时上报SPRITS协议事件，IM-SSF收到所述事件后不再做触发检测，将所上报的SPRITS协议DP事件消息进行协议转换，转换为SCP可识别的智能DP事件消息后上报给SCP。
12、所述第一业务控制点在呼叫外获得可调用业务指示，若所述可调用业务指示对应的业务只有被激活后才能使用，则所述第一业务控制点在所有所述业务被激活后，直接或通过归属用户服务器向业务触发点通知所述可调用业务指示所在的业务触发规则可用。
第一业务控制点可以通过业务触发点发起的第三方注册、或通过向归属用户服务器发起的请求等与呼叫无关的过程获得可调用业务指示，如获得s1、s3和s5，其中，归属用户服务器是存储用户的业务触发规则的服务器。
若s1和s5业务只有被激活后才能使用，如，用户签约了s1和s5业务，但只有在用户为s1和s5业务配置了业务应用数据后，才能使用该业务，则第一业务控制点判断s1和s5业务都被激活后，向归属用户服务器通知s1和s5业务所在的业务触发规则可用，所述通知中至少需要携带用户标识和所述业务触发规则标识，或者，所述通知中至少需要携带用户标识、第一业务控制点的服务器地址配置和已激活业务的可调用业务指示。归属用户服务器向业务触发点通知s1和s5业务所在的业务触发规则可用，如向业务触发点下载所述业务触发规则，或者，修改业务触发点上的所述业务触发规则为可用等。
或者，第一业务控制点判断s1和s5业务都被激活后，直接向业务触发点通知s1和s5业务所在的业务触发规则可用。
此后，业务触发点收到一个通信事件消息，执行所述可用的业务触发规则，获得第一业务控制点，发送携带可调用业务指示的通信事件消息至第一业务控制点。
以下针对采用本专利的具体实施例进行进一步的说明：
第一实施例：
请参照图3所示：本实施例中业务触发点为Service Broker、第一业务控制点分别为TAS1和OSA SCS2、第二业务控制点为OSA APP3。其中TAS1上提供业务1、业务2、业务3，OSA SCS2以及OSA APP3提供业务5。要求的业务调用的顺序为业务1、业务2、业务5、业务3。
步骤1：Service Broker收到SIP INVITE消息。
步骤2：Service Broker检查用户的业务触发规则，此时存在触发规则1，它具备最高的触发规则优先级0，例如触发规则描述为：
<FilterCriteria>
<Priority>0</Priority>
……
<ApplicationServer>
<ServerName>sip:11000@tas1.home1.net</ServerName>
<DefaultHandling>0</DefaultHandling>
</ApplicationServer>
</FilterCriteria>
其中的服务器地址配置描述sip:11000@tas1.home1.net对应服务器TAS1。
步骤3：Service Broker根据触发规则1，将上述服务器地址配置添加至SIPINVITE消息的Route头域中，触发到TAS1。
步骤4：TAS1根据收到的INVITE消息中的Route头域中的地址sip:11000@tas1.home1.net查询本地配置的可调用业务映射数据，例如服务器地址配置-业务映射表，得到本次可调用的业务为业务1、业务2。TAS1调用业务1、业务2。
步骤5：TAS1将业务1、业务2调用后，将INVITE消息路由至Service Broker
步骤6：Service Broker检查用户的业务触发规则，此时存在触发规则2，它具备次高的触发规则优先级1，触发规则2中配置的服务器地址配置为OSASCS2的逻辑地址sip:231003@osa2.home1.net。
步骤7：Service Broker根据触发规则2触发到OSA SCS2，并将上述服务器地址配置添加至SIP INVITE消息的Route头域中。
步骤8：OSA SCS2根据收到的INVITE消息中的Route头域中的地址sip:231003@osa2.home1.net查询服务器地址配置-业务映射表，得到本次可调用的业务为业务5。OSA SCS2调用OSAAPP3上的业务5。
步骤9：业务5调用后，OSA SCS2将INVITE消息路由至Service Broker。
步骤10：Service Broker检查用户的业务触发规则，此时存在触发规则3，它具备触发规则优先级2，触发规则3中配置的服务器地址配置为TAS1的逻辑地址sip:11110@tas1.home1.net。
步骤11：Service Broker根据触发规则2触发到OSA SCS2，并将上述服务器地址配置添加至SIP INVITE消息的Route头域中。
步骤12：TAS1根据收到的INVITE消息中的Route头域中的地址sip:11110@tas1.home1.net查询服务器地址配置-业务映射表，得到本次可调用的业务为业务3，TAS1调用业务3。
步骤13：业务3调用后，TAS1将INVITE消息路由至Service Broker。
本实施例中采用的是业务触发点隐式指示第一业务控制点可调用的业务的方法，也可以采用其它的方法指示可调用的业务，例如触发规则1中配置的服务器地址配置为sip:tas1.home1.net；service＝s1，s2，其中的service＝s1，s2表示此触发规则触发后TAS1可调用业务1、业务2，s1，s2的顺序表示业务优先级为s1，s2；也可以是将服务器地址配置为sip:s1@tas1.home1.net，sip:s2@tas1.home1.net，上述服务器地址配置出现的顺序表示业务优先级为s1，s2；还可以是通过触发规则中的业务信息透明数据指示可调用的业务，例如触发规则1中配置的业务信息透明数据为：
Content-Type:application/serviceinfo+xml
<？xml version＝″1.0″encoding＝″UTF-8″？>
<serviceinfo xmlns＝″urn:ietf:params:xml:ns:serviceinfo″>
<service>
<servicekey>s1</servicekey>
<priority>0</priority>
</service>
<service>
<servicekey>s2</servicekey>
<priority>1</priority>
</service>
</serviceinfo>
表示该触发规则触发后TAS1可调用业务1、业务2，业务1的优先级为0，业务2的优先级为1。
本实施例中TAS1后续的业务调用消息通过使用添加路由的方式发送，也可以采用前述的其它技术发送，例如使用更新路由头域的方式或使用对话中的通知等方式发送。
本实施例中业务触发点也可以为S-CSCF。
第二实施例：
请参照图4所示：本实施例中业务触发点为Service Broker、第一业务控制点分别为TAS1和IM-SSF2、第二业务控制点为SCP3。其中TAS1上提供业务1、业务2，IM-SSF2以及SCP3提供业务9。要求的业务调用的顺序为业务1、业务2、业务9。
步骤1：Service Broker收到SIP INVITE消息。
步骤2：Service Broker检查用户的业务触发规则，此时存在触发规则1，它具备最高的触发规则优先级0，其中的服务器地址配置包括两个地址条目sip:s1@tas1.home1.net，sip:s2@tas1.home1.net对应服务器TAS1。
步骤3：Service Broker根据触发规则1，将上述服务器地址配置添加至SIPINVITE消息的Route头域中，触发到TAS1。
步骤4：TAS1根据收到的INVITE消息中的Route头域中的地址sip:s1@tas1.home1.net，sip:s2@tas1.home1.net查询服务器地址配置-业务映射表，得到本次可调用的业务为业务1、业务2。TAS1调用业务1、业务2。
步骤5：TAS1将业务1、业务2调用后，将INVITE消息路由至Service Broker。
步骤6：Service Broker检查用户的业务触发规则，此时存在触发规则2，它具备次高的触发规则优先级1，触发规则2中配置的服务器地址配置为IM-SSF2的逻辑地址sip:s9@imssf2.home1.net。
步骤7：Service Broker根据触发规则2触发到IM-SSF2，并将上述服务器地址配置添加至SIP INVITE消息的Route头域中。
步骤8：IM-SSF2根据收到的INVITE消息中的Route头域中的地址sip:s9@imssf2.home1.net查询服务器地址配置-业务映射表，得到本次可调用的业务为SCP3上的业务9。IM-SSF向SCP发送CAP消息Initia1DP，其中的业务键填充为业务9的，SCP3根据此业务键调用业务9。
步骤9：SCP3在业务9的流程中下发CAP RequestReportBCSMEvent指令请求IM-SSF2监视发端_忙DP事件。
步骤10：SCP3下发CAP Continue指令指示IM-SSF2继续处理。
步骤11：IM-SSF2将INVITE消息路由至Service Broker。
步骤12：IM-SSF2使用扩展的SPIRITS协议请求Service Broker监视主叫用户是否收到忙事件，例如：
SUBSCRIBE sip:ISB1.home1.net SIP/2.0
To：<sip:6302240216@home1.net>
……
Event:spirits-INDPs-expand
Allow-Events:spirits-INDPs-expand
Accept:application/spirits-event-expand+xml
Content-Type:application/spirits-event-expand+xml
……
<？xml version＝″1.0″encoding＝″UTF-8″？>
<spirits-event-expand xmlns＝″urn:ietf:params:xml:ns:spirits-expand″>
<Event type＝″INDPs″name＝″OCPB″mode＝″R″>
<CallingPartyNumber>6302240216</CallingPartyNumber>
</Event>
<transparentInfo>
<SSMID>861223311</SSMID>
</transparentInfo>
</spirits-event>
上述消息中IM-SSF2请求地址为sip:ISB1.home1.net的Service Broker监视用户sip：6302240216@home1.net的忙事件(对应name＝″OCPB″的描述)，监视模式为请求模式(对应mode＝″R″的描述)。
上述消息对SPIRITS协议有扩展，在消息体中还携带了透明数据部分(对应Transparent Info中的描述)，其中SSMID为IM-SSF2内部的状态机编号。
Service Broker收到上述消息后保存需要监视的事件，Service Broker还将其中的透明数据部分一起保存下来。
步骤13：Service Broker将需要监视的SPIRITS事件映射为对应的SIP消息事件并进行监视。
步骤14：其后经过若干呼叫过程，Service Broker收到SIP响应486 BusyHere。
步骤15：Service Broker发现该事件为IM-SSF2要求监视的事件，此时使用NOTIFY通知IM-SSF2，例如：
NOTIFY sip:imssf2.home1.net SIP/2.0
……
Subscription-State:terminated；reason＝fired
Accept:application/spirits-event-expand+xml
Event:spirits-INDPs-expand
Allow-Events:spirits-INDPs-expand
Content-Type:application/spirits-event-expand+xml
……
<？xml version＝″1.0″encoding＝″UTF-8″？>
<spirits-event xmlns＝″urn:ietf:params:xml:ns:spirits-expand″>
<Event type＝″INDPs″name＝″OCPB″mode＝″R″>
<CallingPartyNumber>6302240216</CallingPartyNumber>
<CalledPartyNumber>3125551212</CalledPartyNumber>
</Event>
<transparentInfo>
<SSMID>861223311</SSMID>
</transparentInfo>
</spirits-event>
上述消息中Service Broker上报的事件为主叫方收到忙事件(对应name＝″OCPB″的描述)，监视模式为请求模式(对应mode＝″R″的描述)。ServiceBroker还将保存的SUBSCRIBE请求中的透明数据拷贝至NOTIFY消息中。
步骤16：IM-SSF2根据此NOTIFY消息中的SSMID找到对应的智能协议控制块，从而得到与SCP3通信的地址、协议类型等，IM-SSF2根据上述NOTIFY消息中的事件迁移状态至发端_忙，并将Service Broker上报的事件转换为CAP消息EventReportBCSM上报给SCP3。
本发明实施例能够保证多业务服务器环境下业务优先级的要求，还可以在业务触发点连接需要进行二次触发的业务控制点的情况下做统一的触发控制处理，提高了触发处理效率。本发明实施例还可以减少信令时延以及减轻网络负荷，并且在出现业务冲突时可禁止冲突业务调用。
Claims (27)
1.一种控制业务调用的系统，其应用于多业务服务器环境下，其特征在于：包括：
业务触发点，用于检测业务触发条件，并在触发条件满足时将通信触发至第一业务控制点；以及
至少一个第一业务控制点，用于从业务触发点发送的通信事件消息中获得可调用业务指示，并据此控制所述可调用业务的执行。
2.根据权利要求1所述的系统，其特征在于：所述业务触发点是服务呼叫会话控制功能S-CSCF或业务代理Service Broker。
3.根据权利要求1所述的系统，其特征在于：所述业务触发点包括：
业务触发检测单元：用于检测业务触发条件；
业务调用消息构造单元：用于当业务触发条件满足时构造业务调用的通信事件消息；以及
业务调用消息发送单元：用于通过E1接口发送业务调用通信事件消息。
4.根据权利要求1所述的系统，其特征在于：所述第一业务控制点是会话初始化协议应用服务器SIP AS、IP多媒体子系统业务交换功能IM-SSF、或开放业务接入业务能力服务器OSA SCS。
5.根据权利要求1所述的系统，其特征在于：所述第一业务控制点包括：
业务调用消息接收单元：用于通过E1接口接收业务触发点发送的业务调用通信事件消息；
业务调用匹配单元：用于从业务调用消息接收单元接收的消息中获得可调用业务指示；以及
业务处理控制单元：用于根据从业务调用匹配单元得到的可调用业务指示来控制所述可调用业务的执行。
6.根据权利要求1所述的系统，其特征在于：还包括：
第二业务控制点，用于控制所述第一业务控制点执行业务流程。
7.根据权利要求6所述的系统，其特征在于：第一业务控制点通过E1接口请求业务控制点检测业务触发条件。
8.一种控制业务调用的方法，其应用于多业务服务器环境下，包括以下步骤：
A.业务触发点检测业务触发条件，并根据业务触发规则发送携带可调用业务指示的通信事件消息至第一业务控制点；以及
B.第一业务控制点从所述通信事件消息获得可调用业务指示，并据此控制所述可调用业务的执行。
9.根据权利要求8所述的方法，其特征在于：所述步骤A中的可调用业务指示通过所述业务触发规则获得。
10.根据权利要求8所述的方法，其特征在于：所述同一个第一业务控制点具备多个不同的业务触发规则。
11.根据权利要求8所述的方法，其特征在于：所述业务触发规则和可调用业务指示的对应关系至少包括如下之一：一条业务触发规则对应一个可调用业务的指示、一条业务触发规则对应多个可调用业务的指示。
12.根据权利要求8所述的方法，其特征在于：所述业务触发点构造通信事件消息中的可调用业务指示的方式至少包括如下之一：将一条业务触发规则数据中的可调用业务指示携带至一条通信事件消息中、将多条业务触发规则数据中的可调用业务指示合并在同一条通信事件消息中。
13.根据权利要求12所述的方法，其特征在于：所述业务触发点构造通信事件消息中的可调用业务指示的方式还包括：在所述通信事件消息中删除特定业务的可调用业务指示。
14.根据权利要求13所述的方法，其特征在于：所述删除特定业务的可调用业务指示的情况包括：业务触发点检出存在业务冲突时，删除冲突业务的可调用业务指示。
15.根据权利要求8所述的方法，其特征在于：所述可调用业务指示为显式或者隐式指示。
16.根据权利要求8所述的方法，其特征在于：所述携带于所述通信事件消息的可调用业务指示至少包括如下方式之一：SIP消息Route头域包含第一业务控制点的地址条目、SIP消息体中携带业务信息透明数据。
17.根据权利要求8所述的方法，其特征在于：所述可调用业务指示还进一步包括可调用业务的业务优先级信息。
18.根据权利要求8所述的方法，其特征在于：所述步骤A中业务触发点向第一业务控制点发送通信事件消息的方式包括：使用新的对话发送、在原有对话中使用添加路由发送、或在原有对话中使用对话中的通知发送。
19.根据权利要求8所述的方法，其特征在于：所述业务触发点要检测的业务触发条件包括：业务触发规则数据中配置要检测的业务触发条件和/或第一业务控制点在通信过程中请求业务触发点检测的业务触发条件。
20.根据权利要求8所述的方法，其特征在于：所述第一业务控制点控制可调用业务的执行后，在向业务触发点返回的消息中携带已调用业务的可调用业务指示。
21.根据权利要求8所述的方法，其特征在于：所述第一业务控制点不做触发检测，将业务触发点上报的通信事件消息转换为第二业务控制点可识别的格式，触发到第二业务控制点。
22.根据权利要求20所述的方法，其特征在于：所述业务触发点收到第一业务控制点返回的消息后，解析或比较所述消息中携带的可调用业务指示，获得已调用业务。
23.根据权利要求8所述的方法，其特征在于：所述步骤A之前，所述第一业务控制点获得可调用业务指示，若所述可调用业务指示对应的业务只有被激活后才能使用，则所述第一业务控制点在所有所述业务被激活后，直接或通过归属用户服务器向业务触发点通知所述可调用业务指示所在的业务触发规则可用。
24.根据权利要求8所述的方法，其特征在于：所述步骤A中，业务触发点检测构造携带可调用业务指示的通信事件消息时，删除其此前添加的可调用业务指示，和/或，按顺序将所述可调用业务指示添加在所述通信事件消息中。
25.根据权利要求8所述的方法，其特征在于：业务触发点在所述通信事件消息中进一步携带和所述可调用业务指示对应的业务触发点标签。
26.一种业务控制点装置，其特征在于：包括：
业务调用消息接收单元：用于接收业务触发点发送的业务调用通信事件消息；
业务调用匹配单元：用于从业务调用消息接收单元接收的消息中获得可调用业务指示；以及
业务处理控制单元：用于根据从业务调用匹配单元得到的可调用业务指示来控制所述可调用业务的执行。
27.根据权利要求26所述的业务控制点装置，其特征在于：所述业务控制点通过E1接口在通信中请求业务触发点检测业务触发条件。
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2007101123723A CN101188598A (zh) | 2006-11-22 | 2007-06-12 | 控制业务调用的系统、方法及业务控制点装置 |
| PCT/CN2007/071113 WO2008061481A1 (fr) | 2006-11-22 | 2007-11-22 | Système, procédé, contrôle de services, et dispositif déclencheur pour contrôler l'invocation de services |
| EP07817303A EP2086181A4 (en) | 2006-11-22 | 2007-11-22 | SYSTEM, METHOD, SERVICE CONTROL AND TRIGGERING DEVICE FOR CONTROLLING TERMINATION |
| US12/436,474 US20090216896A1 (en) | 2006-11-22 | 2009-05-06 | System and method for controlling service invocations, service control apparatus, and service triggering apparatus |
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200610157020.5 | 2006-11-22 | ||
| CN200610157020 | 2006-11-22 | ||
| CN200710100761.4 | 2007-04-17 | ||
| CNA2007101123723A CN101188598A (zh) | 2006-11-22 | 2007-06-12 | 控制业务调用的系统、方法及业务控制点装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101188598A true CN101188598A (zh) | 2008-05-28 |
Family
ID=39480788
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNA2007101123723A Pending CN101188598A (zh) | 2006-11-22 | 2007-06-12 | 控制业务调用的系统、方法及业务控制点装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101188598A (zh) |
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102025731A (zh) * | 2010-12-03 | 2011-04-20 | 华为技术有限公司 | 智能业务触发方法及相关设备和系统 |
| CN102217357A (zh) * | 2011-05-20 | 2011-10-12 | 华为技术有限公司 | 用于控制业务的方法及其装置和系统 |
| CN102238439A (zh) * | 2010-04-30 | 2011-11-09 | 中兴通讯股份有限公司 | 一种基于g.709的业务映射过程的控制方法和系统 |
| CN102325142A (zh) * | 2011-09-19 | 2012-01-18 | 大唐移动通信设备有限公司 | 消息处理方法和设备 |
| CN101388887B (zh) * | 2008-10-15 | 2012-09-19 | 中兴通讯股份有限公司 | 一种网络服务的处理方法和系统 |
| CN101989915B (zh) * | 2009-08-06 | 2014-01-01 | 中兴通讯股份有限公司 | 一种业务嵌套和业务冲突的处理方法及装置 |
| WO2014015776A1 (zh) * | 2012-07-25 | 2014-01-30 | 烽火通信科技股份有限公司 | 一种灵活适应ims系统业务标签的业务解析方法 |
| CN107657393A (zh) * | 2017-10-30 | 2018-02-02 | 中铁二院工程集团有限责任公司 | 近断层地震作用下桥梁的抗震评估方法 |
| CN107846435A (zh) * | 2016-09-20 | 2018-03-27 | 中国移动通信有限公司研究院 | 业务实现系统及方法 |
| CN110046028A (zh) * | 2018-11-30 | 2019-07-23 | 阿里巴巴集团控股有限公司 | 数据处理方法、装置及服务器 |
-
2007
- 2007-06-12 CN CNA2007101123723A patent/CN101188598A/zh active Pending
Cited By (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101388887B (zh) * | 2008-10-15 | 2012-09-19 | 中兴通讯股份有限公司 | 一种网络服务的处理方法和系统 |
| CN101989915B (zh) * | 2009-08-06 | 2014-01-01 | 中兴通讯股份有限公司 | 一种业务嵌套和业务冲突的处理方法及装置 |
| CN102238439B (zh) * | 2010-04-30 | 2014-12-10 | 中兴通讯股份有限公司 | 一种基于g.709的业务映射过程的控制方法和系统 |
| CN102238439A (zh) * | 2010-04-30 | 2011-11-09 | 中兴通讯股份有限公司 | 一种基于g.709的业务映射过程的控制方法和系统 |
| CN102025731A (zh) * | 2010-12-03 | 2011-04-20 | 华为技术有限公司 | 智能业务触发方法及相关设备和系统 |
| CN102025731B (zh) * | 2010-12-03 | 2013-04-24 | 华为技术有限公司 | 智能业务触发方法及相关设备和系统 |
| CN102217357A (zh) * | 2011-05-20 | 2011-10-12 | 华为技术有限公司 | 用于控制业务的方法及其装置和系统 |
| WO2011144060A2 (zh) * | 2011-05-20 | 2011-11-24 | 华为技术有限公司 | 用于控制业务的方法及其装置和系统 |
| WO2011144060A3 (zh) * | 2011-05-20 | 2012-04-26 | 华为技术有限公司 | 用于控制业务的方法及其装置和系统 |
| CN102217357B (zh) * | 2011-05-20 | 2013-10-09 | 华为技术有限公司 | 用于控制业务的方法及其装置和系统 |
| CN102325142A (zh) * | 2011-09-19 | 2012-01-18 | 大唐移动通信设备有限公司 | 消息处理方法和设备 |
| WO2014015776A1 (zh) * | 2012-07-25 | 2014-01-30 | 烽火通信科技股份有限公司 | 一种灵活适应ims系统业务标签的业务解析方法 |
| CN107846435A (zh) * | 2016-09-20 | 2018-03-27 | 中国移动通信有限公司研究院 | 业务实现系统及方法 |
| CN107657393A (zh) * | 2017-10-30 | 2018-02-02 | 中铁二院工程集团有限责任公司 | 近断层地震作用下桥梁的抗震评估方法 |
| CN107657393B (zh) * | 2017-10-30 | 2020-09-01 | 中铁二院工程集团有限责任公司 | 近断层地震作用下桥梁的抗震评估方法 |
| CN110046028A (zh) * | 2018-11-30 | 2019-07-23 | 阿里巴巴集团控股有限公司 | 数据处理方法、装置及服务器 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101188598A (zh) | 控制业务调用的系统、方法及业务控制点装置 | |
| US20090193131A1 (en) | Communication network system and method for providing a service broker function, and service broker apparatus | |
| EP2093970B1 (en) | Call service handling in an IMS-based system | |
| EP2119179B1 (en) | Supplementary services in communication networks | |
| WO2010015893A1 (en) | Enhancement to sip forking for improved user services | |
| EP2418817B1 (en) | Application server for managing communications towards a set of user entities | |
| US20090122794A1 (en) | Packet network and method implementing the same | |
| CN101222483A (zh) | 业务触发方法、系统及业务触发装置 | |
| KR101375983B1 (ko) | 멀티미디어 서브시스템, 시그널링 메시지 전송 방법, 질의 기능 엘리먼트 및 연합 기능 엘리먼트 | |
| US8724777B2 (en) | Method, device and system for implementing emergency call override service | |
| US8036211B1 (en) | Legacy user proxy call session control function | |
| EP1305913B1 (en) | System and method for determining when a cscf should act like i-cscf or like s-cscf | |
| WO2008061481A1 (fr) | Système, procédé, contrôle de services, et dispositif déclencheur pour contrôler l'invocation de services | |
| WO2008106885A1 (fr) | Procédé et système permettant une compatibilité de services | |
| CN101272530A (zh) | 业务触发方法及系统 | |
| JP4280284B2 (ja) | 通信システムにおけるサービスの提供 | |
| CN101282288B (zh) | 在分组域网络中处理业务的系统、装置及方法 | |
| JP2006521717A5 (zh) | ||
| CN101102266B (zh) | 基于分组网络的路由方法及系统 | |
| Gouya et al. | Managing service capability and service feature interactions in the IMS of UMTS | |
| CN101132394A (zh) | 确定服务用户方向的方法 | |
| Kim et al. | IM-SSF Application Server—Interworking with CAMEL | |
| EP2523484B1 (en) | Call method, device and communication system for private branch exchange user | |
| Gouya et al. | Managing Service Capability and | |
| WO2008025218A1 (fr) | Procédé et système pour traiter une interaction de service |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Open date: 20080528 |