CN101459650A - 业务路由方法、业务路由器、客户端设备及业务网络系统 - Google Patents

Abstract

本发明公开一种业务路由方法、业务路由器、客户端设备及业务网络系统，其中业务路由方法包括：接收包括业务请求者所需业务的业务信息的业务请求消息；获取所述业务请求消息中携带的业务请求者所需业务的业务信息；根据所述获取的业务请求者所需业务的业务信息进行业务路由选择处理，确定所述获取的业务信息对应的业务路由信息；按照选择确定的业务路由信息路由转发业务请求消息。本发明可以使业务请求者可以在不需要指定业务目的地址的情况下根据自身的需求发起相关业务请求，简化业务交互流程，提高业务交互的灵活性，并降低用户使用业务网络的复杂性。

Description

业务路由方法、业务路由器、客户端设备及业务网络系统

技术领域

本发明涉及业务网络技术领域，更具体的说，本发明涉及一种业务路由方法、业务路由器、客户端设备及业务网络系统。

背景技术

参考图1，业务网络就是把许多业务互联起来，共享资源、互相协作并最终完成用户的需求，业务网络中可包括业务路由器以及注册服务器、目录服务器以及管理中心等设备，是一种提供了使具体业务可以商业化部署的基础架构。通过业务网络，电讯业者和信息技术(IT，Information Technology)经营者一起，整合服务和内容，形成端到端的整体，为个人或企业的最终用户提供有价值的服务，即业务网络把许多业务互联起来，共享资源互相协作并最终满足用户的需求。

现有的业务网络中，在业务目的地址已知的情况下可以较好的满足用户的需求。如图2所示，以基于会话初始协议(SIP，Session Initiation Protocol)路由机制的业务网络为例，用户代理客户端(UAC，User Agent Client)首先需要根据用户的需求，查询相关的信息，获取能满足用户需求的业务逻辑地址，并将业务请求消息的To头部设置为该业务逻辑地址，然后将该业务请求消息发送出去。SIP代理服务器(Proxy)接收到用户代理客户端的业务请求消息后可进行相关的检查，如语法检查，环路检测等。如果该代理服务器是中间代理服务器，就不需要做进一步的处理，直接转发请求到下一跳。而如果代理服务器是目标通用资源标志符(Target URI)的代理服务器，则就要为该业务请求确定具体的请求目标，可能是一个也可能是一组SIP URI，该代理服务器按照优先级先后处理，把业务请求消息的请求通用资源标志符Request-URI替换成目标地址，并发送到对应的用户代理服务端(UAS，UserAgent Server)。用户代理服务端接收到请求消息后，判断请求消息是否合法，并在判断请求消息合法后，完成相关的处理，并回送成功响应，建立会话。

而随着业务网络的发展，业务的种类和形式会越来越丰富，业务网络也越来越复杂，在这种情况下，采用图2所示的业务路由方式，用户查找能满足自己需要的服务会变得很困难。并且，在图2所示的业务路由方式中，业务网络中用户往往只关心自己的具体需求，具体的业务路由选择由网络代替用户进行，这样，由于目前的业务路由机制只支持明确的目的地址路由，无法根据用户的具体需求进行动态的路由选择。

针对现有的路由方式无法根据用户的具体需求进行动态路由的问题，目前在业务网络中主要通过对业务请求重定向解决，例如通过设置采用重定向服务器，在某些架构下，重定向允许服务器在一个请求的应答中，推送业务路由信息到客户端，这样就可以做到把自己从后续的消息流中脱离出来，但是同时又能提供准确的请求定位服务。重定向服务器可以预先把用户请求和其目的对象(用户、服务)的关系配置好，在用户发起重定向请求时，重定向服务器可以根据预先的配置信息，返回请求者所需要的目的对象地址信息，从而请求者可与其需要的对象建立会话。

由于采用了重定向机制，用户需要先向重定向服务器请求目的对象地址信息，然后再根据重定向服务器返回的对象地址信息与目的对象建立会话，导致业务使用的流程比较复杂，且不够灵活，用户使用业务网络比较复杂。而且，考虑到未来不同业务之间通过协作完成用户需求的情况会比较普遍，若业务与业务之间的搜索发现机制也采用重定向机制，则除了上述用户的重定向流程外，协作的业务之间还需要重定向，这样会使致业务之间交互的流程比较复杂，用户使用业务网络的复杂度更大。

发明内容

本发明实施例解决的技术问题是提供一种业务路由方法、业务路由器、客户端设备及业务网络系统，以使业务请求者可以在不需要指定业务目的地址的情况下根据自身的需求发起相关业务请求，简化业务交互流程，提高业务交互的灵活性，并降低用户使用业务网络的复杂性。

一种业务路由方法，包括：

接收包括业务请求者所需业务的业务信息的业务请求消息；

获取所述业务请求消息中携带的业务信息；

根据所述获取的业务信息进行业务路由选择处理，确定所述获取的业务信息对应的业务路由信息；

按照选择确定的业务路由信息路由转发业务请求消息。

一种业务路由器，包括：

接收单元，用于接收包括业务请求者所需业务的业务信息的业务请求消息；

解析处理单元，用于解析所述业务请求消息，获取所述业务请求消息中携带的业务信息；

业务路由选择处理单元，用于根据所述获取的业务信息进行业务路由选择处理，确定所述获取的业务信息对应的业务路由信息；

消息转发处理单元，用于按照所述路由选择处理单元选择确定的业务路由信息，路由转发所述业务请求消息。

一种客户端设备，包括：

业务请求消息封装单元，用于封装包括有业务请求者所需业务的业务信息的业务请求消息；

业务请求消息发送单元，用于将所述业务请求消息封装单元封装的包括有业务请求者所需业务的业务信息的业务请求消息发送到业务网络。

一种业务网络系统，包括：发起业务请求的客户端设备，处理业务路由转发的业务路由器；

其中所述客户端设备包括：

业务请求消息封装单元，用于封装包括有业务请求者所需业务的业务信息的业务请求消息；

业务请求消息发送单元，用于将所述业务请求消息封装单元封装的包括有业务请求者所需业务的业务信息的业务请求消息发送到业务网络；

所述业务路由器包括：

接收单元，用于接收包括业务请求者所需业务的业务信息的业务请求消息；

解析处理单元，用于解析所述业务请求消息，获取所述业务请求消息中携带的业务信息；

业务路由选择处理单元，用于根据所述获取的业务信息进行业务路由选择处理，确定所述获取的业务信息对应的业务路由信息；

消息转发处理单元，用于按照所述业务路由选择处理单元选择确定的业务路由信息，路由转发所述业务请求消息。

根据上述本发明实施例提供的业务路由方法、业务路由器、客户端设备及业务网络系统，用户发送的业务请求消息中携带业务请求者所需业务的业务信息；业务路由器解析所述业务请求消息以获取业务请求者所需业务的业务信息；然后根据所述获取的业务请求者所需业务的业务信息进行业务路由选择处理；最后按照选择确定的业务路由信息路由转发业务请求消息，由于不需要指定业务目的地址的情况下根据自身的业务需求发起相关业务请求，业务路由器根据业务请求者所需业务的业务信息进行业务路由选择处理，因此，可简化业务交互流程，提高业务交互的灵活性，并降低用户使用业务网络的复杂性。

附图说明

图1是现有技术一种业务网络结构示意图；

图2是现有技术基于SIP的业务路由处理过程；

图3是本发明实施例业务路由方法的流程图；

图4是本发明实施例应用的SIP协议的逻辑实体组网示意图；

图5是本发明实施例基于SIP的业务路由方法的流程图；

图6是本发明实施例基于SIP协议扩展IR参数的业务路由方法的流程图；

图7是本发明实施例业务网络系统的结构示意图；

图8是本发明实施例业务路由器的另一种结构示意图；

图9是本发明实施例业务路由选择处理单元的一种结构示意图；

图10是本发明实施例业务路由选择处理单元的另一种结构示意图；

图11是本发明应用的一种基于SIP的业务网络系统的实施例组网示意图。

具体实施方式

参考图3，该图是本发明实施例业务路由方法的流程图。

本实施例中业务请求者不是在指定被触发业务的目的地址的情况下发起相关业务请求，而是根据自身的业务需求发起相关业务请求，即业务请求者发送的业务请求消息中可携带有业务请求者所需业务的业务信息，例如所述业务请求者所需业务的业务信息可能是业务功能、业务名称和/或业务属性信息等，或者其他业务请求者所需业务的业务信息，这里不再详述，业务网络中负责处理业务路由的设备，可按照下述步骤进行业务路由：

步骤S101，接收包括业务请求者所需业务的业务信息的业务请求消息。具体实现时，例如，接收包括业务功能、业务名称和业务属性信息等业务请求者所需业务的业务信息中的一个或几个的组合的业务请求消息，根据不同的业务网络，所述业务请求消息可能是不同协议的消息，例如，SIP业务请求消息或者业务网络中采用的其他协议类型的业务请求消息，例如简单对象访问协议(SOAP，Simple Object Access Protocol)的业务请求消息等。

另外，需要说明的，具体接收包括业务请求者所需业务的业务信息的业务请求消息时，还可根据接收到的业务请求消息判断是否需要进行业务路由选择处理，在判断结果为是时执行业务请求消息解析处理的步骤，即步骤S102，在判断结果为否时则可正常转发接收到的业务请求消息。

步骤S102，获取所述业务请求消息中携带的业务信息。具体实现时，例如，若所述业务请求消息为SIP业务请求消息，则对所述SIP业务请求消息进行解析，获取所述SIP业务请求消息中携带的业务请求者所需业务的业务信息。

步骤S103，根据所述获取的业务信息进行业务路由选择处理，确定所述获取的业务信息对应的业务路由信息。具体实现时，可以根据获取的业务信息进行关键字匹配确定相应的业务路由信息，例如，预先保存业务信息及其对应的业务路由信息，在进行业务路由选择时，可根据获取的业务信息的关键字与预先存储的业务信息关键字进行匹配，进而根据匹配的业务信息确定相应的业务路由信息；或者也可以根据获取的业务信息作语义解析，确定相应的业务路由信息，例如，通过集成独立支持语义的相关推理引擎来实现语义解析。其中，语义解析主要是根据本体信息，使得计算机能够理解词语的含义，本实施例中可根据语义解析的结果确定相应的业务路由信息，举例说，如业务请求者所需业务的业务信息是“茗典咖啡”，计算机通过查询语义解析库进行语义解析，可以判断该业务请求者实际上是想找一个餐馆，还可能进一步分析是西餐馆，从而根据语义解析结果可为用户确定相应的业务路由信息。

步骤S104，按照选择确定的业务路由信息路由转发业务请求消息。具体实现时，例如，可直接按照确定的业务路由信息将业务请求消息转发给下一跳；或者，先更新业务请求消息中的业务路由信息，再对更新后的业务请求消息进行路由转发；或者，将选择确定的业务路由信息填充到业务请求消息的对应消息域中，再对填充后的业务请求消息进行路由转发。

另外，若上述步骤中当前无法确定业务路由信息，则继续下一跳，由后续的业务路由器进行确定业务路由信息的处理。

需要说明的，本实施例中在进行业务路由选择处理时还可以根据路由控制策略进行控制，例如，对某些非法的请求(可能违反政策)拒绝提供路由功能等。

从上述本实施例可知，业务请求者根据自身的业务需求发起相关业务请求，业务网络中负责处理业务路由的设备根据业务请求者需求的业务信息进行业务路由选择，确定业务路由信息，进而按照选择确定的业务路由信息进行路由转发，从用户的角度来说，用户只需要根据自身的业务需求发起业务请求，不需要知道提供所需业务的目的设备地址，从而降低了用户使用业务网络的复杂性；从业务的角度来说，负责处理业务路由的设备直接根据业务请求者需求的业务信息进行业务路由选择，简化了业务交互流程，并且提高了业务交互的灵活性。

下面以SIP协议的业务网络为例进行说明。

SIP是在诸如SMTP(简单邮件传送协议)和HTTP(超文本传送协议)基础之上建立起来的，是一个应用层的协议，可以建立、修改或者中止多媒体会话或者呼叫。

参考图4，该图是本发明实施例应用的SIP协议的逻辑实体组网示意图。

如图示，用户代理(UA，User Agent)是发起或接收会话的逻辑实体；UA又分为UAC和UAS；UAC是用来产生业务请求的，UAS是用来响应业务请求的。

代理服务器路由SIP业务请求到UAS，并且路由SIP应答到UAC。一个业务请求可能通过多个proxy到达UAS。每一个都会作出路由决定，在发送给下一个节点前可对业务请求做一点修改，而应答会通过和业务请求逆序的proxy路径回送给UAC，即当一个UAC发送一个业务请求，这些业务请求可能通过一些代理服务器传递到UAS上。当UAS产生一个应答，那么这个应答就会同样的被传送到UAC。

参考图5，该图是本发明实施例基于SIP协议的业务路由方法的流程图。

本实施例中UAC可以是用户手机、PDA或PC；路由器SR-A、SR-B为支持SIP业务路由功能的代理服务器；UAS是服务器，为用户提供其最终需要使用的一个服务，具体路由处理流程如下：

步骤S201，UAC根据用户的业务需求发起SIP Invite(SIP请求，会话初始协议请求)，即向SR-A发送SIP Invite请求消息，其中所述SIP Invite请求消息中携带业务请求者所需业务的业务信息，所述SIP Invite请求消息即为SIP业务请求消息。

步骤S202，SR-A根据SIP Invite请求消息中携带的业务请求者所需业务的业务信息内容，进行业务路由查询选择处理，确定业务路由信息，指定具体的目的地址和后续的路由信息等。

步骤S203，SR-A根据步骤S202获取的业务路由信息，转发SIP Invite消息给下一跳的SR-B。

步骤S204，SR-B按照正常的SIP消息处理，即把SIP Invite的业务请求消息转发给目的地UAS。UAS按照正常的请求进行响应，UAC收到响应后更新或填充头域To的内容，后续的信令处理同一般的SIP处理。

具体实现时，本实施例中为了在SIP业务请求消息中携带业务请求者所需业务的业务信息，可扩展SIP业务请求消息，例如，通过在SIP业务请求消息中的Request-URI头域增加新的参数，携带业务请求者所需业务的业务信息；或者通过新扩展SIP头域携带业务请求者所需业务的业务信息；或者通过重用已有的SIP头域携带业务请求者所需业务的业务信息。

以通过SIP业务请求消息中的Request-URI头域的新增加参数携带业务请求者所需业务的业务信息为例，通常，SIP协议中已经定义了uri-parameter参数，uri-parameter的取值有transport-param/user-param/method-param/ttl-param/maddr-param/lr-param/other-param。本实施例中为了在SIP业务请求消息中携带业务请求者所需业务的业务信息，可扩展uri-parameter参数定义，新增一个参数ir-param(ir)携带业务请求者所需业务的业务信息，并作为确定业务路由信息的指示，具体所述ir-param(ir)的定义参考表一所示：

表一

 

参数名	格式	说明
			Ir-Param(ir)	Function:attribute	Function和attribute为业务网络运营者对网络上业务的分类和描述。Function：用于描述SIP请求者需要的功能特性；Attribute：对于前面特定function功能描述的附加信息

上述Function描述的SIP请求者需要的功能特性可以包括业务类型，业务名称等，例如Query restaurant Menu、Search Engine、POC Service、LocationService、Presence Service等；而Attribute是对Function功能描述的附加信息，例如Function描述为’Query Restaurant Menu’而attribute进一步附加描述为’nearby’或’cheapprice’，或Function描述为’Search Engine’，attribute进一步附加描述为’English’或’Chinese’等。举例说，假设用户希望使用搜索服务，并且代理服务器要支持中文检索，通过新增参数ir-param(ir)携带业务请求者所需业务的业务信息，则步骤S201的SIP Invite请求消息可采用如下形式：

INVITE sip:Proxy-A.com；ir＝Search Engine:Chinese SIP/2.0

Via:SIP/2.0/UDP 10.70.108.1；branch＝z9hG4bK99a

From:bob<sip:bob@Proxy-A.com>；tag＝n88ah

Call-ID:1j9FpLxk3uxtma7@host.example.com

CSeq:1 INVITE

......

其中，ir参数携带业务请求者需要的业务的信息，即’Search Engine：Chinese’，代表需要支持中文检索的搜索服务。

另外，若通过重用已有的SIP头域来实现携带业务请求者所需业务的业务信息，则可采用下述方式，例如，在To头域中可以用display-name来表示上述扩展方案中的ir-param(ir)参数信息，新增一个特殊的Tag值表示这是一个支持SIP路由的To头域，例如“SIP-service-routing”。这样上述的实施例中的步骤S201的UAC发出去的SIP Invite请求消息主要参数的一个例子可采用如下形式：

     INVITE sip:Proxy1.com；SIP/2.0

     Via:SIP/2.0/UDP 10.70.108.1；branch＝z9hG4bK99a

     To:Search Engine:Chinese<sip:service@example.com>；tag＝

SIP-service-routing

From:User<sip:user@Proxy1.com>；tag＝n88ah

CSeq:1 INVITE

......

其中，To头域中携带业务请求者需要的业务的信息，即’Search：Chinese’，并以tag值为SIP-service-routing表示这是一个支持SIP路由的To头域，以便业务路由器根据To头域中携带的业务请求者需要的业务的信息确定业务路由信息。

另外，与前面所述的扩展方法类似，还可通过新增SIP头域来携带业务请求者所需业务的业务信息，例如新增的SIP头域为Service-info，其值也可以上述方案中描述的功能和属性字段的形式。这样上述的实施例中的UAC发出去的SIP Invite请求消息主要参数如下所示：

INVITE sip:Proxy1.com；SIP/2.0

Via:SIP/2.0/UDP 10.70.108.1；branch＝z9hG4bK99a

To:<sip:service@example.com>；

From:User<sip:user@Proxy1.com>；tag＝n88ah

Service-info:Search Engine:Chinese

CSeq:1 INVITE

......

其中，新增的SIP头域Service-info，携带业务请求者需要的业务的信息，即’Search Engine:Chinese’。

参考图6，该图是本发明实施例基于SIP协议扩展IR参数的业务路由方法的流程图。

Proxy接收到SIP Invite请求消息(步骤S301)，判断Request-URI是否包含ir参数(步骤S302)；如果不包含ir参数，则按照正常的SIP请求处理流程进行处理(步骤S303)；如果检测到ir参数，Proxy提取ir参数内容即前述的Function:attribute(步骤S304)，然后根据该内容查询符合要求的目标对象，判断是否可以确定目的地址(步骤S305)，若是，根据目标地址，构建新的路由信息，并把此新的路由信息更新或填充到SIP Invite请求消息中，同时删除ir参数，然后把修改后的SIP invite请求消息按照正常的处理方式发送出去(步骤S307)；若否，例如如果Proxy检测到ir参数，但是该Proxy无法根据相关的信息为原始SIP请求确定目标对象，那么该Proxy不删除ir参数，按照它自身的路由机制，把该Invite消息路由到下一个Proxy进行处理(步骤S306)。

需要说明的，若通过重用已有的SIP头域来实现携带业务请求者所需业务的业务信息，后续的Proxy处理流程与本实施例类似。例如，当重用To头域时，首先判断To头域的Tag值是否是业务路由的特殊值，如果是，Proxy就提取To头域中的功能和属性信息，进行查找和匹配，为当前的SIP业务请求确定一个最合适的业务路由信息，并根据匹配结果更新或填充原SIP业务请求中的业务路由信息，最终把业务请求路由到目的端。

同样的，若通过新增SIP头域来携带业务请求者所需业务的业务信息，后续Proxy的处理流程与本实施例类似。例如，当新增Service-info头域时，首先检测有没有新增的头域Service-info，如果有，Proxy就提取Service-info头域中的功能和属性信息，并进行查找和匹配，为当前的SIP业务请求确定一个最合适的业务路由信息，并根据匹配结果更新或填充原SIP业务请求中的业务路由信息，最终把请求路由到目的端。

为了实现本发明实施例所提供的上述方法，需要对现有的网络系统及设备的功能作相应的扩展。

参考图7，该图是本发明实施例业务网络系统的结构示意图。

本实施例中业务网络系统包括：客户端设备1和业务路由器2，其中

客户端设备1，本实施例中客户端设备1不仅指用户代理，也可以是服务请求者和服务提供者，根据不同业务网络采用的协议，客户端设备1可以是相应协议的客户端设备，例如SIP协议客户端设备，本实施例中所述客户端设备可包括：

业务请求消息封装单元11，用于封装包括有业务请求者所需业务的业务信息的业务请求消息，具体实现时，例如，参考前述说明，若业务网络采用SIP协议，业务请求消息封装单元11可通过各种方式在SIP业务请求消息中封装业务请求者所需业务的业务信息，例如通过Request-URI头域的新增加参数携带业务请求者所需业务的业务信息；或者通过新扩展SIP头域携带业务请求者所需业务的业务信息；或者通过重用已有的SIP头域携带业务请求者所需业务的业务信息等，这里不再一一例举；

业务请求消息发送单元12，用于将所述业务请求消息封装单元封装的包括有业务请求者所需业务的业务信息的业务请求消息发送到业务网络。

业务路由器2，本实施例中业务路由器2不仅负责基本的消息处理，还包括业务路由信息处理功能，例如，查询相关信息并进行匹配，最终为用户的业务请求确定业务路由信息并进行路由转发，具体实现时，例如，业务路由器2可包括：

接收单元21，用于接收包括业务请求者所需业务的业务信息的业务请求消息。具体实现时，根据业务网络采用的不同协议，接收单元按照相应的协议进行接收处理，例如，业务网络采用SIP协议，则可按照SIP协议进行接收处理；

解析处理单元22，用于解析所述业务请求消息，获取所述业务请求消息中携带的业务信息。具体实现时，例如，业务请求消息为SIP业务请求消息，则可解析该SIP业务请求消息获取该该SIP业务请求消息中相应参数(例如ir参数)携带的业务请求者所需业务的业务信息；

业务路由选择处理单元23，用于根据所述获取的业务请求者所需业务的业务信息进行业务路由选择处理，确定所述获取的业务信息对应的业务路由信息。具体实现时，例如参考前述说明，业务路由选择处理单元可根据获取的业务请求者所需业务的业务信息进行关键字匹配确定相应的业务路由信息；或者也可根据其他方式，例如根据获取的业务请求者所需业务的业务信息作语义解析确定相应的业务路由信息，具体参考图9，作为一个具体的实施例，业务路由选择处理单元23可包括：

存储单元231，用于保存业务信息与业务路由信息的对应关系；和

路由选择单元232，用于根据所述获取的业务信息，查询所述存储单元保存的业务信息与业务路由信息的对应关系，确定相应的业务路由信息。

作为另一个具体的实施例，参考图10，业务路由选择处理单元23可包括：

语义解析处理单元233，用于根据获取的业务请求者所需业务的业务信息，作语义解析确定相应的业务路由信息。

消息转发处理单元24，用于按照所述路由选择处理单元选择确定的业务路由信息，路由转发所述业务请求消息。

根据本实施例的业务网络系统，业务请求者根据自身的业务需求通过客户端设备发起相关业务请求后，业务网络中负责处理业务路由的业务路由器根据业务请求者需求的业务信息进行业务路由选择处理，进而按照选择确定的业务路由信息进行路由转发，从用户的角度来说可降低用户使用业务网络的复杂性；从业务的角度来说可简化业务交互流程，并且提高业务交互的灵活性。

需要说明的，若上述业务路由选择处理单元当前无法确定业务路由信息，则可继续下一跳，由后续的业务路由器进行处理。

另外，参考图8，该图是本发明实施例业务路由器的另一种结构示意图。

与上述实施例相同的，本实施例的业务路由器包括有：

接收单元21、解析处理单元22、业务路由选择处理单元23以及消息转发处理单元24，

另外，本实施例与上述实施例不同的在于，本实施例的业务路由器还包括有：

路由控制策略处理单元25，用于向路由选择处理单元23提供路由控制策略，例如，如前所述，所述策略可以是对某些非法的请求(可能违反政策)拒绝提供路由功能等。

此时，业务路由选择处理单元23，还用于根据所述路由控制策略处理单元提供的路由控制策略，对所述业务请求消息进行控制。

根据本实施例的业务网络路由器，不仅从用户的角度来说可降低用户使用业务网络的复杂性；从业务的角度来说可简化业务交互流程，并且提高业务交互的灵活性，而且通过路由控制策略处理单元25的处理，可进一步提高业务路由处理的灵活性，以满足各种实际需求。

上述的业务网络系统可基于各种协议实现，不失一般性，下面以基于SIP协议的业务网络为例进行说明。

参考图11，该图是本发明应用的一种基于SIP的业务网络系统的实施例组网示意图。

如图所示，本实施例中UA之间通过Proxy相互联系，这里的UA不仅指用户代理，也可以是服务请求者和服务提供者。而UA既能进行基本SIP消息处理，也能进行业务路由相关信息处理，例如SIP中携带的业务需求者所需业务的业务信息的封装处理；同样的，Proxy能进行基本SIP消息处理，例如SIP消息的接收处理以及SIP消息的路由转发以及更新等，另外，Proxy也能进行SIP业务路由功能的处理，例如根据业务请求者所需业务的业务信息确定业务路由信息以及一些路由控制策略等，下面以一个具体的应用过程为例进行说明：

本应用过程是假设上述UA1是一个移动用户User终端上的应用；UA2是在深圳一个提供Query restaurant Menu的服务。并且相关的信息都已经发布到网络上了，即上图中的Proxy上。另外Proxy可以根据具体的目的地址确定路由信息。

当用户User漫游到某地后想查询一下附近一些餐馆的菜单，通过UA1发送一个SIP请求给网络。主要参数如下所示：

INVITE sip:Proxy1.com；ir＝Query restaurant Menu：nearby SIP/2.0

Via:SIP/2.0/UDP 10.70.108.1；branch＝z9hG4bK99a

From:User<sip:user@Proxy1.com>；tag＝n88ah

CSeq:1 INVITE

......

其中ir参数携带业务请求者所的业务的业务信息，即’Query restaurantMenu:nearby’。

Proxy1分析ir参数，并根据该参数内容，Query restaurant menu:nearby’生成查询请求，然后将该查询请求发送到确定处理单元，确定处理单元根据相关的配置策略初步分析该请求，如是否需要拒绝该请求(例如违反政策等待)，如果是正常请求，确定处理单元进一步通过例如业务信息存储模块的相关信息确定具体的目的地址。

根据所述新的目的地址更新或填充原有SIP请求消息，并生成相关的路由信息，再转发出去。具体到这个实施例子，得到的目的地址为service@UAS.com，根据得到的目的地址，更新所述SIP请求主要参数如下：

INVITE sip:service@UAS.com；SIP/2.0

Via:SIP/2.0/UDP Proxy1.com；branch＝z9hG4bKafar1

Via:SIP/2.0/UDP 10.70.108.1；branch＝z9hG4bK99a

From:User<sip:user@Proxy1.com>；tag＝n88ah

To:<service@UAS.com>

Route:Proxy2.com

Call-ID:1j9FpLxk3uxtma7@host.example.com

CSeq:1 INVITE

Proxy2按照正常的SIP请求消息处理，即把请求转发给目的端UAS；后续处理同一般的SIP消息处理，这里不再详细介绍。

综上，根据上述本发明实施例提供的业务路由方法、业务路由器、客户端设备及业务网络系统，用户端发送的业务请求消息中携带业务请求者所需业务的业务信息；业务路由器解析所述业务请求消息以获取业务请求者所需业务的业务信息；然后根据所述获取的业务请求者所需业务的业务信息进行业务路由选择处理；最后按照选择确定的业务路由信息路由转发业务请求消息。由于不需指定业务目的地址，只要根据自身的业务需求发起相关业务请求，然后业务路由器根据业务请求者所需业务的业务信息进行业务路由选择处理，因此，可简化业务交互流程，提高业务交互的灵活性，并降低用户使用业务网络的复杂性。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (16)

1、一种业务路由方法，其特征在于，包括：

接收包括业务请求者所需业务的业务信息的业务请求消息；

获取所述业务请求消息中携带的业务信息；

根据所述获取的业务信息进行业务路由选择处理，确定所述获取的业务信息对应的业务路由信息；

按照选择确定的业务路由信息路由转发业务请求消息。

2、根据权利要求1所述的业务路由方法，其特征在于，当所述业务路由选择处理未能确定对应的业务路由信息时，转发所述业务请求消息至下一跳。

3、根据权利要求1所述的业务路由方法，其特征在于，在所述接收包括业务请求者所需业务的业务信息的业务请求消息之后：

根据接收到的业务请求消息判断是否需要进行业务路由选择处理，并在判断结果为是时，获取所述业务请求消息中携带的业务信息，并进一步进行业务路由选择处理。

4、根据权利要求1所述的业务路由方法，其特征在于，根据所述获取的业务信息进行业务路由选择处理时还包括：

根据路由控制策略对所述业务请求消息进行控制。

5、根据权利要求1所述的业务路由方法，其特征在于，所述根据所述获取的业务信息进行业务路由选择处理，确定所述业务信息对应的业务路由信息为：

根据所述获取的业务信息，查询保存的业务信息与业务路由信息的对应关系，确定相应的业务路由信息；或者

根据所述获取的业务信息作语义解析，确定相应的业务路由信息。

6、根据权利要求1所述的业务路由方法，其特征在于，所述业务请求消息为会话初始协议业务请求消息。

7、根据权利要求6所述的业务路由方法，其特征在于，所述会话初始协议业务请求消息中通过下述方式携带业务请求者所需业务的业务信息：

通过请求通用资源定位符头域的新增加参数携带业务请求者所需业务的业务信息；或者

通过新扩展会话初始协议头域携带业务请求者所需业务的业务信息；或者

通过重用已有的会话初始协议头域携带业务请求者所需业务的业务信息。

8、根据权利要求1-7任一项所述的业务路由方法，其特征在于，所述业务请求者所需业务的业务信息包括：

业务功能、业务名称和业务属性信息中的一种或几种的组合。

9、一种业务路由器，其特征在于，包括：

接收单元，用于接收包括业务请求者所需业务的业务信息的业务请求消息；

解析处理单元，用于解析所述业务请求消息，获取所述业务请求消息中携带的业务信息；

业务路由选择处理单元，用于根据所述获取的业务信息进行业务路由选择处理，确定所述获取的业务信息对应的业务路由信息；

消息转发处理单元，用于按照所述路由选择处理单元选择确定的业务路由信息，路由转发所述业务请求消息。

10、根据权利要求9所述的业务路由器，其特征在于，还包括：

路由控制策略处理单元，用于向路由选择处理单元提供路由控制策略；

所述业务路由选择处理单元，还用于根据所述路由控制策略处理单元提供的路由控制策略，对所述业务请求消息进行控制。

11、根据权利要求9所述的业务路由器，其特征在于，所述业务路由选择处理单元包括：

存储单元，用于保存业务信息与业务路由信息的对应关系；

路由选择单元，用于根据所述获取的业务信息，查询所述存储单元保存的业务信息与业务路由信息的对应关系，确定相应的业务路由信息。

12、根据权利要求9所述的业务路由器，其特征在于，所述业务路由选择处理单元包括：

语义解析处理单元，用于根据获取的业务信息作语义解析，确定相应的业务路由信息。

13、一种客户端设备，其特征在于，包括：

业务请求消息封装单元，用于封装包括有业务请求者所需业务的业务信息的业务请求消息；

业务请求消息发送单元，用于将所述业务请求消息封装单元封装的包括有业务请求者所需业务的业务信息的业务请求消息发送到业务网络。

14、根据权利要求13所述的客户端设备，其特征在于，所述客户端设备为会话初始协议用户代理客户端设备，所述业务请求消息为会话初始协议业务请求消息；

其中所述业务请求消息封装单元通过下述方式在会话初始协议业务请求消息中封装业务请求者所需业务的业务信息：

通过请求通用资源定位符头域的新增加参数携带业务请求者所需业务的业务信息；或者

通过新扩展会话初始协议头域携带业务请求者所需业务的业务信息；或者

通过重用已有的会话初始协议头域携带业务请求者所需业务的业务信息；

其中，所述业务请求消息封装单元封装的业务请求者所需业务的业务信息包括：业务功能、业务名称和/或业务属性信息。

15、一种业务网络系统，包括：发起业务请求的客户端设备，处理业务路由转发的业务路由器；

其特征在于，所述客户端设备包括：

业务请求消息封装单元，用于封装包括有业务请求者所需业务的业务信息的业务请求消息；

业务请求消息发送单元，用于将所述业务请求消息封装单元封装的包括有业务请求者所需业务的业务信息的业务请求消息发送到业务网络；

所述业务路由器包括：

接收单元，用于接收包括业务请求者所需业务的业务信息的业务请求消息；

解析处理单元，用于解析所述业务请求消息，获取所述业务请求消息中携带的业务信息；

业务路由选择处理单元，用于根据所述获取的业务信息进行业务路由选择处理，确定所述获取的业务信息对应的业务路由信息；

消息转发处理单元，用于按照所述业务路由选择处理单元选择确定的业务路由信息，路由转发所述业务请求消息。

16、根据权利要求15所述的业务网络系统，其特征在于，所述客户端设备为会话初始协议用户代理客户端设备，所述业务路由器为会话初始协议业务路由器，所述业务请求消息为会话初始协议业务请求消息。

Images