CN106302419B - 建立跨域会话连接的方法和装置 - Google Patents

Abstract

本发明涉及一种建立跨域会话连接的方法和装置。所述方法包括步骤：接收本站点内的起呼用户设备发送的建立会话连接的单播请求，单播请求包括被呼用户设备的信息；检测到被呼用户设备不在本站点内时，将多播请求发送给多播组的各个站点，其中多播请求包括多播组的地址和被呼用户设备的信息；接收被呼用户设备所在站点根据多播请求向所述多播组的各个站点发送的多播重定向响应，多播重定向响应包括从起呼用户设备所在站点到达被呼用户设备所在站点的第一路由信息；根据第一路由信息建立起呼用户设备和被呼用户设备之间的会话连接。本发明适用于机动分布式通信网络，实现在不同管理域之间建立业务会话连接。

Description

建立跨域会话连接的方法和装置

技术领域

本发明涉及通信技术领域，特别是涉及一种建立跨域会话连接的方法和装置。

背景技术

在大规模紧急事件(例如自然灾害、战争等)或其他原因导致某个区域移动通信基础设施无法提供服务，而且卫星通信也不能满足该区域的通信业务要求的情况下，为了维持该特定区域的通信联络，需要部署临时的移动通信站点提供应急通信。这种应急移动通信站点为了适应快速机动部署的要求，通常装载在机动车上或者临时架设，因此可称为机动通信站点。由于单个机动通信站点的通信覆盖范围有限，为了实现更大范围地域的通信覆盖，需要部署更多的机动通信站点，同时这些站点可以通过无线手段(如微波或卫星等)相互连接组成临时的应急分布式机动通信网络，如图1所示。

每个机动通信站点需要拥有完全的业务连接控制能力和单独的用户管理域，可以独立管理本站点内用户及用户之间的所有业务活动，因此可以将一个机动通信站点看作一个通信管理域。为了实现更大的通信覆盖面积并且满足用户在更大范围内通信活动的需求，若干个机动通信站点可以联合构建成一个拥有多个管理域的采用分布式控制方式机动部署的移动通信网络(以下简称机动分布式通信网络)，该网络需要支持网内属于不同管理域的用户之间建立业务连接。如图1所示，管理域1的用户可以建立到管理域N的用户的业务连接。

为了建立跨管理域的业务连接，首先需要确定到达被呼用户所在站点的路由，由于每个管理域只管理本域用户的活动状态，无法获知其它管理域用户的位置，因此需要一种机制快速发现非本管理域被呼用户的当前位置，从而确定跨域寻呼的路由。

随着通信技术进步，互联网和移动通信网已经逐步融合为基于IP(InternetProtocol，互联网协议)的移动互联网，SIP(Session Initiation Protocol，会话初始协议)作为互联网的多媒体业务会话连接核心控制协议在移动互联网上得到进一步发展。例如3GPP(3rd Generation Partnership Project，第三代合作伙伴计划)提出的互联网多媒体子系统(IMS，Internet Multimedia Subsystem)就是以SIP架构为基础的电信级多媒体通信系统。IMS包括4个基础功能部分，分别是会话连接控制功能、用户签约数据管理功能、媒体资源管理功能以及互联网关功能。会话连接控制功能对应的功能实体为CSCF(CallSession Control Function)，用户签约数据管理功能对应的功能实体为HSS(HomeSubscriber Server)。CSCF实体主要负责会话连接的建立、维护和移除。HSS存放所在管理域的所有用户的签约数据和活动状态信息，其中活动状态信息记录了用户当前的注册状态和注册时的位置信息。

如图2所示，为IMS跨域呼叫的处理流程。在建立业务会话时，CSCF分析被呼用户的地址，如果是本管理域的用户地址则可以通过访问本管理域的HSS获得被呼用户当前的注册状态，如果是非管理域的用户地址则需要依据预先配置的路由方向表或由DNS(DomainName System，域名系统)提供信息来确定会话连接建立请求的下一跳发送路由。目标管理域的CSCF在收到跨管理域的会话连接建立请求消息后，同样需要对被呼用户地址分析，从而决定会话连接建立请求的下一跳路由。

基于DNS或静态路由的寻址方式决定了IMS建立会话连接需要依赖可靠的网络基础设施以及预先规划好的网络连接关系。但是在机动分布式通信网络中，站点组网的手段主要采用无线、微波和卫星等，这些连接方式不能提供完全可靠并且带宽资源充裕的链路连接，同时组成网络的站点也会因为各种原因而不能提供不间断服务，因此机动分布式通信网络是动态变化的。动态变化并且资源受限的网络环境使得在建立跨域业务会话连接过程中采用IMS的跨域寻址机制并不合适。首先网络连接的不可靠和基于分布式部署的松散网络结构使得无法采用基于集中式的DNS提供地址解析服务。其次，不断变化的网络连接关系和组成网络站点的不确定性也大大增加了规划用于寻址的路由方向参数的难度。另一方面，如果需要进一步支持用户在网络中不同管理域之间迁移时，在不增加用户跟踪开销(例如增加移动通信网络中的用户位置更新管理功能)的情况下，采用IMS的寻址机制将无法找到发生迁移的用户。

综上所述，在建立跨域会话连接过程中，基于良好网络基础设施设计的传统跨域寻呼机制(例如IMS的跨域寻呼机制)并不适合用于机动分布式通信网络。

发明内容

基于此，有必要针对上述问题，提供一种适用于机动分布式通信网络的建立跨域会话连接的方法和装置，能够在不同管理域之间建立业务会话连接。

为了达到上述目的，本发明采取的技术方案如下：

一种建立跨域会话连接的方法，包括步骤：

接收本站点内的起呼用户设备发送的建立会话连接的单播请求，其中所述单播请求包括被呼用户设备的信息；

检测到所述被呼用户设备不在本站点内时，将多播请求发送给多播组的各个站点，其中所述多播请求包括所述多播组的地址和所述被呼用户设备的信息；

接收所述被呼用户设备所在站点根据所述多播请求向所述多播组的各个站点发送的多播重定向响应，所述多播重定向响应包括从所述起呼用户设备所在站点到达所述被呼用户设备所在站点的第一路由信息；

根据所述第一路由信息建立所述起呼用户设备和所述被呼用户设备之间的会话连接。

一种建立跨域会话连接的装置，包括：

单播请求接收模块，用于接收本站点内的起呼用户设备发送的建立会话连接的单播请求，其中所述单播请求包括被呼用户设备的信息；

多播请求发送模块，用于检测到所述被呼用户设备不在本站点内时，将多播请求发送给多播组的各个站点，其中所述多播请求包括所述多播组的地址和所述被呼用户设备的信息；

多播重定向响应接收模块，用于接收所述被呼用户设备所在站点根据所述多播请求向所述多播组的各个站点发送的多播重定向响应，所述多播重定向响应包括从所述起呼用户设备所在站点到达所述被呼用户设备所在站点的第一路由信息；

会话连接建立模块，用于根据所述第一路由信息建立所述起呼用户设备和所述被呼用户设备之间的会话连接。

本发明建立跨域会话连接的方法和装置，与现有技术相互比较时，具备以下优点：

1、针对机动分布式通信网络组成站点的不确定性，以及用户可能会有在不同管理域之间迁移的需求，在建立跨域会话时，本发明采用泛搜索方式遍历网络中所有可达的管理域寻呼用户，很好地适应了动态变化的网络，并且可以快速找到发生迁移的用户，因此具有较好的网络环境自适应能力，能够高效的建立跨域业务会话连接，适用于机动分布式通信网络；

2、为了保证携带路由信息的多播重定向响应能够被起呼站点接收并处理，以成功建立会话连接，本发明减少泛搜索过程中的信令个数，只有终呼站点(即被呼用户设备所在站点)发出多播重定向响应，其它站点接收到多播请求时不作响应，只有终呼站点响应的方式同样也减少了泛搜索过程产生的网络开销；

3、本发明泛搜索所采用的多播技术涉及的会话控制消息和相关流程完全遵循IETF(The Internet Engineering Task Force，国际互联网工程任务组)RFC(Request forComments，请求评议)3261，因此具有良好的协议通用性和健壮性；

4、本发明只需要规划和配置泛搜索的多播群组和对应的多播组地址，无需预先规划和配置需要建立跨域业务的关联站点和路由参数，也无需因网络发生变化而修改路由配置参数，大大降低了实现跨域会话控制所需的系统维护难度。

附图说明

图1为现有技术中应急分布式机动通信网络实施例的结构示意图；

图2为现有技术中IMS跨域寻呼的处理流程示意图；

图3为本发明建立跨域会话连接的方法实施例的流程示意图；

图4为本发明起呼用户设备和被呼用户设备建立跨域会话连接具体实施例的流程示意图；

图5为本发明被呼用户路由表的维护方法实施例的流程示意图；

图6为本发明建立跨域会话连接的装置实施例一的结构示意图；

图7为本发明多播请求发送模块实施例一的结构示意图；

图8为本发明多播请求发送模块实施例二的结构示意图；

图9为本发明建立跨域会话连接的装置实施例二的结构示意图；

图10为本发明路由信息更新模块实施例的结构示意图。

具体实施方式

为了能够在机动分布式通信网络中提供跨管理域的业务会话服务，在建立跨域会话过程中确定被呼用户位置时需要有相应的高效跨域寻呼机制。该机制应该能够满足以下需求：

1)适应网络拓扑动态变化；

2)站点新加入或者脱离后再加入网络后能够立即支持跨域寻呼；

3)用户迁移到其它管理域后仍能作为被叫被快速发现；

4)跨域寻呼的流程处理和消息传输的开销少；

5)符合IETF RFC 3261；

6)具有良好的自适应能力，无需人工过多干预。

对于上述需求，本发明针对机动分布式通信网络的特点，结合建立跨域会话连接的需求，利用SIP(IETF RFC 3261)定义的消息多播技术，提供一种适用于机动分布式通信网络的自适应的跨域寻呼路由机制，达到在不良网络环境下提高跨域会话连接建立效率的目的。

为了更好地理解本发明，首先对在机动分布式通信网络中确定采用多播技术的过程进行简单介绍。

1、跨域寻呼方式的选择

在机动分布式通信网络中，组成网络的每个通信站点都是可以独立运行的，它们只配置了驻留于本管理域的用户的签约数据，同时也只管理驻留用户的注册状态。当建立跨域会话连接时，站点需要确定被呼用户当前驻留的管理域，获得被呼用户所在的管理域的方式有两种：

第一种是由外部信息源提供。例如由DNS提供地址解析或者由预先配置好的寻呼路由方向表提供发送路由。但是受到机动分布式通信网络的特殊网络环境限制，不可能由DNS提供地址解析，而预先配置好的静态寻呼路由方向表也不能适应网络的动态变化。因此通过外部信息源得到跨域寻呼所需路由信息的方案并不可行。

第二种是由通信站点主动到网上探寻。由于机动分布式通信网络的组成是动态变化的，随时可能有通信站点新加入或者脱网或者脱网后又加入，因此不可能预知当前网络上有哪些站点，另一方面，如果用户有在管理域之间迁移的需求，用户和站点之间就不存在必然的和可以推导的绑定关系，因此需要采用盲探的方式查询被呼用户当前的位置，即会话发起站点向网络所有可达到站点发送查询请求，被呼用户当前所在的站点将对查询请求返回确认响应，这种方式被称为泛搜索或者饱和路由。泛搜索实现较为简单，但它为了查找目标需要对整个网络实施饱和路由，在瞬间会产生较大的网络资源开销，因此泛搜索一般适用于规模较小并且需要发起泛搜索频度不高的网络。机动分布式通信网络是临时性的小规模网络，而且业务主要集中在站点内，跨域业务发生的机会较小，因此适合采用泛搜索实现跨域寻呼。

2、在IP网络实现泛搜索的方法

在基于IP的机动分布式通信网络中利用泛搜索发现某个用户就是要向全网有关站点发送探询，实现这个目的有两种方法：

第一种方法是会话发起站点向网络中每个站点逐一用IP单播(unicast)方式发送被呼查询请求，这种方法的问题是IP单播包需要给出明确的目标地址，即在所有要发起跨域会话的站点上都要预先配置好寻呼路由表，其中包括所有可能出现在网络上的站点的地址。这样做不但大大增加了系统的维护难度，而且无法访问临时新加入的站点，降低了系统的灵活性。这种方法产生的另一个问题是同一个信令用单播发送到同一方向的多个目的地址时要发多次，造成信令的IP包冗余，浪费了宝贵的传输资源。因此不采用IP单播方式实现泛搜索。

第二种方法是会话发起站点利用IP多播(multicast)方式发送查询请求，这种方法的前提条件是承载网络支持IP多播功能，而具有多播路由能力是对IP多媒体业务承载网络的基本要求。网络上属于同一多播组的站点都可以收到利用IP多播方式发送的查询请求。由于IP承载网络维护了多播路由，会话发起站点只需要发送一个被呼查询请求信令即可，封装该信令的IP包的目的地址为用于泛搜索的多播组地址。采用多播方式实现泛搜索只需要配置好相应的多播组地址参数，而不需要明确知道网络上有哪些站点，增加了系统的灵活性，降低了维护难度。另一方面，IP多播包在网络中转发时如果有多个目标都在同一个方向时则只需要转发一次，大大减轻了网络的负担。

根据上述分析，在IP承载网络选用多播技术实现泛搜索比较合适，带来的好处是系统维护简单、网络开销小并且具有良好的灵活性。

下面结合附图及较佳实施例，对本发明所采取的技术手段及取得的效果，进行清楚和完整的描述。

如图3所示，一种建立跨域会话连接的方法，包括步骤：

S110、接收本站点内的起呼用户设备发送的建立会话连接的单播请求，其中所述单播请求包括被呼用户设备的信息；

S120、检测到所述被呼用户设备不在本站点内时，将多播请求发送给多播组的各个站点，其中所述多播请求包括所述多播组的地址和所述被呼用户设备的信息；

S130、接收所述被呼用户设备所在站点根据所述多播请求向所述多播组的各个站点发送的多播重定向响应，所述多播重定向响应包括从所述起呼用户设备所在站点到达所述被呼用户设备所在站点的第一路由信息；

S140、根据所述第一路由信息建立所述起呼用户设备和所述被呼用户设备之间的会话连接。

本发明方法可以根据相应的程序或芯片实现，程序或芯片运行在起呼用户设备所在的起呼站点。为了更好地理解本发明，下面对各个步骤的具体实施过程进行详细介绍。

在步骤S110中，起呼用户设备发起建立会话连接的单播请求，单播请求包含被呼用户设备的信息等。起呼用户设备所在的起呼站点接收到该单播请求后，根据被呼用户设备的地址分析被呼用户设备是否属于本管理域。如果被呼用户设备是本管理域内的用户地址，则可以通过访问本管理域的HSS获得被呼用户设备当前的注册状态。如果被呼用户设备不是本管理域内的用户地址，则进入步骤S120，利用SIP的多播技术实现泛搜索。

SIP是多媒体会话的核心控制协议。按照SIP规定，建立SIP业务会话连接一般采用INVITE请求对话。因此起呼用户设备发起的单播请求一般为单播INVITE请求。需要说明的是，本发明并不对建立SIP业务会话连接的请求形式进行限定，还可以采用除INVITE请求外的其它请求建立业务会话连接。

在步骤S120中，如果被呼用户设备不是本管理域内的用户地址，利用SIP的多播技术实现泛搜索。在IETF RFC 3261中定义了使用SIP发起多播的方法，包括消息格式和流程。根据IETF RFC 3261定义，需要在用于多播方式发送的请求消息中的请求行(Request-URI)中包含多播地址“maddr”参数。其中“maddr”参数值为用于泛搜索的多播组地址。

在IP网络中为了防止承载泛搜索信令的IP多播包给网络带来冲击，可以限制IP多播包的跳数，因此，在一个实施例中，所述多播请求还可以包括消息生存期参数，所述消息生存期参数用于限制多播请求的路由跳数，即IP多播包包头中还可以包括消息生存期“ttl”参数。应用层可以根据实际使用情况将“ttl”参数设置为一个合适的值。例如，“ttl”参数为15，即承载泛搜索信令的IP多播包在经过15跳路由转发后“ttl”值将减至0，此时该IP多播包将不再被转发，从而限制了泛搜索影响的范围。

根据IETF RFC 3261定义，一个对话中如果发起对话的是多播请求，则该对话的其它消息也是采用多播方式发送的。例如，如果采用多播INVITE请求建立会话连接，则会话建立过程后续对多播INVITE请求的“100”、“180”、“200”等响应消息等都是采用多播方式发送。而且为了完成会话业务能力协商，参与协商的消息都需要携带庞大的body字段，使得IP多播包很大。由于多播包会占用较多的网络资源，因此需要尽可能减少在一次会话建立过程中发送的多播消息的数量以及每条消息的长度。基于上述原因，不采用直接用多播请求建立会话连接的方式，多播请求对话独立于会话建立过程，只用于跨域寻找被呼用户。由于不需要进行会话业务能力协商，所以，在一个实施例中，所述多播请求不携带body字段，从而后续对该多播请求的响应消息均不携带body字段，因此大大缩短了消息长度，减少了信令开销。

IP多播包是由应用层发起的，网络承载层按照多播组的地址将多播请求发送到指定多播组的所有在线站点，在线站点包括原来的站点，新加入的站点，以及脱离后再加入网络的站点等，很好的适应了网络拓扑动态变化。

以采用多播INVITE请求发起泛搜索为例，多播INVITE请求的请求行中包含“maddr”参数和“ttl”参数，“maddr”参数值为指定的多播组地址，“ttl”参数值为允许多播请求转发的跳数，多播INVITE请求不用携带body字段。起呼站点的网络承载层按多播INVITE请求的“maddr”参数值将多播INVITE请求发送到指定多播组的所有在线站点。

为了节省时间，提高建立跨域会话连接的效率，在一个实施例中，将多播请求发送给多播组的各个站点的同时，还可以包括步骤：开启等待多播重定向响应的定时器。定时器的设置可以根据现有技术中已有的方式实现。

在步骤S130中，根据SIP的多播处理规定，多播请求发送方只会处理第一个收到的对应的多播响应，而后续收到的多播响应消息被当作重传丢弃。对于这种处理方式，如果所有收到多播请求的站点都返回响应，而且在非被呼用户设备所在站点返回的失败响应首先到达多播请求发起方时，则会造成后续携带了被呼用户设备所在站点的路由信息的成功响应被当作重传消息丢弃。因此为了保证携带被呼用户设备所在站点路由信息的成功响应，例如“302”响应，能够被多播请求发送方收到并处理，非被呼用户设备所在的站点将不对多播请求响应，这样做带来的另一个好处是大大减少了发送多播失败响应消息带来的网络开销。同样，除起呼站点之外的其它站点接收到多播重定向响应后也不做任何处理。

被呼用户设备所在的站点接收到起呼用户设备所在的站点发送的多播请求后，根据多播请求包含的被呼用户设备的信息检测到该被呼用户设备属于本管理域，然后按照SIP规定，用多播方式返回多播重定向响应的消息，例如302Moved Temporarily，消息中携带了从所述起呼用户设备所在站点到达所述被呼用户设备所在站点的路由信息。如果先前发送的多播请求没有携带body字段，则返回的多播重定向响应也不携带body字段，大大缩短了信息长度，减少了信令开销。

如果起呼用户设备所在的站点在发送多播请求后开启了定时器，若在所述定时器指定的时间内没有接收到所述多播重定向响应，则认为寻呼失败，将寻呼失败的消息返回给所述起呼用户设备。若在所述定时器指定的时间内接收到所述多播重定向响应，则认为寻呼成功，将所述定时器关闭，进入步骤S140。

在步骤S140中，多播请求的发起方(即起呼站点)可以从收到的多播重定向响应中获取到达被呼用户设备所在站点的路由信息，然后按照正常流程完成会话连接建立过程。即起呼站点重新发起到被呼用户设备所在站点的单播请求，该单播请求中可以携带用于会话能力协商的完整的body字段，被呼用户设备所在站点(即终呼站点)收到单播请求后，查询被呼用户设备的运行状态，如果被呼用户设备处于在线状态，则终呼站点继续向被呼用户设备发送单播请求，然后根据被呼用户设备的回应向起呼站点返回对应的响应，起呼站点将对应的响应发送给起呼用户设备，从而建立起呼用户设备与被呼用户设备之间的会话连接或者结束本次呼叫操作。

为了提高跨域寻呼的效率，尽可能降低用于泛搜索的多播消息对网络负荷产生的压力，在一个实施例中，检测到所述被呼用户设备不在本站点内时，将多播请求发送给多播组的各个站点之前，还可以包括步骤：

检测本站点存储的被呼用户路由表中是否存在从所述起呼用户设备所在站点到达所述被呼用户设备所在站点的第一路由信息；

若不存在所述第一路由信息，进入将多播请求发送给多播组的各个站点的步骤；

若存在所述第一路由信息，根据所述第一路由信息向被呼用户设备所在站点发送所述单播请求；

接收所述被呼用户设备所在站点根据所述单播请求返回的响应信息；

在所述响应信息为不存在所述被呼用户设备时，将所述被呼用户路由表中的所述第一路由信息删除，进入将多播请求发送给多播组的各个站点的步骤。

在每个需要发起跨域寻呼的站点设置被呼用户路由表，用于缓存通过泛搜索得到的被呼用户设备所在站点的路由信息。在下次寻呼相同被呼用户设备时，起呼站点可以在被呼用户路由表中快速获取到该被呼用户设备所在站点的路由信息，直接向终呼站点发送跨域单播请求(例如INVITE单播请求)建立会话连接，该方法被称为确知路由法。

终呼站点收到单播请求后，查询被呼用户设备的运行状态。如果被呼用户设备处于在线状态，则继续向被呼用户设备发送单播请求，然后根据被呼用户设备的回应向起呼站点返回对应的响应。例如，呼叫成功则返回成功响应，例如180 Ringing或200OK；呼叫不成功则返回暂时呼叫失败响应，例如480 Temporarily Unavailable；被呼用户设备占线则返回已占用响应，例如486 Busy Here。起呼站点接收到成功响应后，将成功响应返回给起呼用户设备，起呼用户设备与被呼用户设备成功建立会话连接。起呼站点接收到暂时呼叫失败响应或者已占用响应时，起呼站点认定该次会话连接建立失败，向起呼用户设备返回响应后结束操作。如果终呼站点不存在跨域单播请求中指定的被呼用户设备时，则返回没找到用户响应，例如404 Not Found。起呼站点在发出跨域单播请求后如果收到的对应失败响应的原因是没找到被呼用户设备时，则删除该被呼用户设备在被呼用户路由表中的记录，并且重新发起对该用户的泛搜索。

为了更好的理解本发明通过泛搜索与确知路由相结合方式高效建立跨域会话连接的过程，下面结合一个具体实施例进行详细介绍。

如图4所示，本发明建立跨域会话连接的方法包括以下步骤：

S1、起呼站点接收起呼用户设备发送的建立业务会话连接的单播INVITE请求；

S2、起呼站点根据单播INVITE请求分析出被呼用户设备不属于本管理域，并且查询出本站内存储的被呼用户路由表存在该被呼用户设备所在终呼站点的路由信息，则根据该路由信息向终呼站点发送跨域单播INVITE请求；

S3、终呼站点不存在跨域单播INVITE请求中指定的被呼用户设备时，返回没找到用户响应，例如404Not Found；

S4、起呼站点接收到没找到用户响应时，删除该被呼用户设备在被呼用户路由表中的路由信息，重新发起对此被呼用户设备的多播INVITE请求，并且开启等待多播重定向响应的定时器，多播INVITE请求不包含body字段；

S5、非被呼用户设备所在的站点接收到多播INVITE请求时不做任何响应，被呼用户设备所在的终呼站点接收到多播INVITE请求时返回多播重定向响应，多播重定向响应包括被呼用户设备的路由信息；

S6、起呼站点在定时器规定的时间内接收到多播重定向响应后，关闭定时器，并从接收到的多播重定向响应中获取到达被呼用户设备的路由信息，根据路由信息向终呼站点发送建立会话连接的单播INVITE请求。其它站点接收到多播重定向响应后不做任何处理；

S7、终呼站点根据接收到的单播INVITE请求向在线被呼用户设备转发INVITE请求；

S8、终呼站点接收到被呼用户设备返回的对INVITE请求的响应后，向起呼站点返回对单播INVITE请求的响应；

S9、起呼站点接收到对单播INVITE请求的响应后，向起呼用户设备返回响应。

在跨域寻呼的过程中使用的被呼用户路由表通过记录泛搜索结果来加快下次寻呼相同用户的速度，缩短了呼叫延时并且减少了网络资源的消耗。由于用户的位置信息具有时效性(特别是用户可以在网内不同管理域之间迁移的情况)，同时表项过大也会影响查询效率，增加系统处理开销，因此为了确保在表中记录的有效性，每个站点的被呼用户路由表的容量(记录“被呼用户路由”的数目)可以根据该站点需要跨域寻呼的用户数量和频繁度来确定，例如可能需要频繁跨域寻呼的用户数量约为20个时，则被呼用户路由表的容量可设置为不大于20。同时用户在表中的记录项是唯一的，即表中不能存在同一个用户的两条记录。所以，在一个实施例中，接收所述被呼用户设备所在站点根据所述单播请求返回的响应信息之后，还包括步骤：在所述响应信息为呼叫成功时，将所述第一路由信息更新至所述被呼用户路由表的表首；

和/或，

接收所述被呼用户设备所在站点根据所述多播请求向所述多播组的各个站点发送的多播重定向响应之后，还包括步骤：检测本站点存储的所述被呼用户路由表的容量是否已满；若容量已满，将位于所述被呼用户路由表表尾的第二路由信息删除，将所述第一路由信息添加到所述被呼用户路由表的表首；若容量未满，将所述第一路由信息添加到所述被呼用户路由表的表首。

如图5所示，本发明对被呼用户路由表进行维护，将最近一次成功跨域寻呼的用户设备的路由信息置于被呼用户路由表的表首，之前一次成功跨域寻呼的另一个用户的记录将次之，以此类推，而对于曾经被成功跨域寻呼但后来一段时间再没有被寻呼的用户的记录将逐渐退至表尾，直至从表中移除。当通过确知路由寻呼发现被呼用户设备已不在终呼站点时(起呼站点收到终呼站点返回的对确知路由寻呼请求的响应是用户不存在，例如404Not Found，或者起呼站点在有效期内没有收到对所述确知路由寻呼请求的响应)，则在被呼用户路由表中移除该用户的路由记录。成功跨域寻呼的用户设备包括采用泛搜索方式和确知路由方式成功跨域寻呼的用户设备。成功跨域寻呼是指对于寻呼请求返回的响应表示被呼用户设备被确认是在终呼站点内。

采用上述方法维护被呼用户路由表，使得本站点到近期经常发生业务的其他管理域用户的路由信息被及时缓存在表中，而且越频繁发生业务的被呼用户的记录越是靠近表首的位置，过期记录也能够被及时移除。因此该方法虽然维护算法并不复杂，但却提供了较高的查询效率，在提高跨域寻呼成功率和减少网络资源开销之间取得了较好的平衡。

基于同一发明构思，本发明还提供一种建立跨域会话连接的装置，下面结合附图对本发明装置的具体实施方式做详细描述。

如图6所示，一种建立跨域会话连接的装置，包括：

单播请求接收模块110，用于接收本站点内的起呼用户设备发送的建立会话连接的单播请求，其中所述单播请求包括被呼用户设备的信息；

多播请求发送模块120，用于检测到所述被呼用户设备不在本站点内时，将多播请求发送给多播组的各个站点，其中所述多播请求包括所述多播组的地址和所述被呼用户设备的信息；

多播重定向响应接收模块130，用于接收所述被呼用户设备所在站点根据所述多播请求向所述多播组的各个站点发送的多播重定向响应，所述多播重定向响应包括从所述起呼用户设备所在站点到达所述被呼用户设备所在站点的第一路由信息；

会话连接建立模块140，用于根据所述第一路由信息建立所述起呼用户设备和所述被呼用户设备之间的会话连接。

起呼用户设备发起建立会话连接的单播请求，单播请求可以为INVITE单播请求等，单播请求接收模块110接收到该单播请求后，多播请求发送模块120根据被呼用户设备的地址分析被呼用户设备是否属于本管理域，如果被呼用户设备不是本管理域内的用户地址，利用SIP的多播技术实现泛搜索。

在IETF RFC 3261中定义了使用SIP发起多播的方法，包括消息格式和流程。根据IETF RFC 3261定义，需要在用于多播方式发送的请求消息中的请求行(Request-URI)中包含多播地址“maddr”参数。其中“maddr”参数值为用于泛搜索的多播组地址。

在IP网络中为了防止承载泛搜索信令的IP多播包给网络带来冲击，可以限制IP多播包的跳数，因此，在一个实施例中，所述多播请求还可以包括消息生存期参数，所述消息生存期参数用于限制多播请求的路由跳数，即IP多播包包头中还可以包括消息生存期“ttl”参数。应用层可以根据实际使用情况将“ttl”参数设置为一个合适的值。

根据IETF RFC 3261定义，一个对话中如果发起对话的是多播请求，则该对话的其它消息也是采用多播方式发送的。而且为了完成会话业务能力协商，参与协商的消息都需要携带庞大的body字段，使得IP多播包很大。由于多播包会占用较多的网络资源，因此需要尽可能减少在一次会话建立过程中发送的多播消息的数量以及每条消息的长度。基于上述原因，不采用直接用多播请求建立会话连接的方式，多播请求对话独立于会话建立过程，只用于跨域寻呼被呼用户。由于不需要进行会话业务能力协商，所以，在一个实施例中，所述多播请求不携带body字段，从而后续对该多播请求的响应消息均不携带body字段，从而大大缩短了消息长度，减少了信令开销。

为了节省时间，提高建立跨域会话连接的效率，在一个实施例中，所述多播请求发送模块120将多播请求发送给多播组的各个站点的同时，还用于开启等待多播重定向响应的定时器。

根据SIP的多播处理规定，多播请求发送方只会处理第一个收到的对应的多播响应，而后续收到的多播响应消息被当作重传而被丢弃。对于这种处理方式，如果所有收到多播请求的站点都返回响应，而且在非被呼用户设备所在站点返回的失败响应首先到达多播请求发起方时，则会造成后续携带了被呼用户设备所在站点路由信息的成功响应被当作重传消息丢弃。因此为了保证携带被呼用户设备所在站点的路由信息的成功响应能够被多播请求发送方收到并处理，非被呼用户设备所在的站点将不对多播请求响应，这样做带来的另一个好处是大大减少了发送多播失败响应消息带来的网络开销。同样，除起呼站点之外的其它站点接收到多播重定向响应后也不做任何处理。

如果所述多播请求发送模块120在发送多播请求后开启了定时器，所述多播重定向响应接收模块130还用于在所述定时器指定时间内没有接收到所述多播重定向响应时，将寻呼失败的消息返回给所述起呼用户设备，在所述定时器指定时间内接收到所述多播重定向响应时，将所述定时器关闭，然后会话连接建立模块140可以从收到的多播重定向响应中获取到达被呼用户设备所在站点的路由信息，按照正常流程完成会话连接建立过程。

为了提高跨域寻呼的效率，尽可能降低用于泛搜索的多播消息对网络负荷产生的压力，在一个实施例中，如图7所示，所述多播请求发送模块120可以包括：

第一路由信息检测单元1201，用于在检测到所述被呼用户设备不在本站点内时，检测本站点存储的被呼用户路由表中是否存在从所述起呼用户设备所在站点到达所述被呼用户设备所在站点的第一路由信息；

第一多播请求发送单元1202，用于在不存在所述第一路由信息时，将多播请求发送给多播组的各个站点；

单播请求发送单元1203，用于在存在所述第一路由信息时，根据所述第一路由信息向被呼用户设备所在站点发送所述单播请求；

响应信息接收单元1204，用于接收所述被呼用户设备所在站点根据所述单播请求返回的响应信息；

第二多播请求发送单元1205，在所述响应信息为不存在所述被呼用户设备时，将所述被呼用户路由表中的所述第一路由信息删除，将多播请求发送给多播组的各个站点。

在跨域寻呼过程中使用的被呼用户路由表通过记录泛搜索结果来加快下次寻呼相同用户的速度，缩短了呼叫延时并且减少了网络资源的消耗。由于用户的位置信息具有时效性(特别是用户可以在网内不同管理域之间迁移的情况)，同时表项过大也会影响查询效率，增加系统处理开销，因此为了确保在表中记录的有效性，每个站点的被呼用户路由表的容量(记录被呼用户路由的数目)可以根据该站点需要跨域寻呼的用户数量和频繁度来确定，例如可能需要频繁跨域寻呼的用户数量约为20个时，则被呼用户路由表的容量可设置为不大于20。同时用户在表中的记录项是唯一的，即表中不能存在同一个用户的两条记录。所以，在一个实施例中，如图8所示，所述多播请求发送模块120还可以包括与所述响应信息接收单元1204相连的第一路由信息更新单元1206，所述第一路由信息更新单元1206用于在所述响应信息为呼叫成功时，将所述第一路由信息更新至所述被呼用户路由表的表首；

和/或，

为了记录由泛搜索过程获得的被呼用户路由信息，在一个实施例中，如图9所示，建立跨域会话连接的装置还可以包括与所述多播重定向响应接收模块130相连的路由信息更新模块150。如图10所示，所述路由信息更新模块150可以包括：

路由表容量检测单元1501，用于检测本站点存储的所述被呼用户路由表的容量是否已满；

第二路由信息更新单元1502，用于在容量已满时，将位于所述被呼用户路由表表尾的第二路由信息删除，将所述第一路由信息添加到所述被呼用户路由表的表首；

第三路由信息更新单元1503，用于在容量未满时，将所述第一路由信息添加到所述被呼用户路由表的表首。

本发明建立跨域会话连接的方法和装置，与现有技术相互比较时，具备以下优点：

本发明支持在动态变化的网络中寻呼用户。由于网络是临时组建，不可能像固定网络那样可以部署用于用户地址解析的DNS服务器。而采用在站点预先配置静态寻呼路由表的方法无法适应动态网络的变化。本发明不需要DNS提供地址解析，也不需要预先配置静态寻呼路由表，而采用按需泛搜索的方式寻找用户，很好地适应了动态变化的网络。

本发明支持寻呼在不同管理域间迁移的用户。由于用户可以在不同的管理域之间迁移，因此用户地址和管理域地址之间不存在固定的或者可推导的关系。本发明采用按需遍历网络中所有可达管理域的方式寻找用户，因此可以快速找到发生迁移的用户。

本发明在跨域寻呼过程中的网络开销较少。由于泛搜索要遍历全网相关的站点，会对网络造成一定的压力，因此本发明采取了多种措施尽可能减少泛搜索带来的网络开销，达到寻呼性能与开销的平衡。首先机动分布式通信网络是临时组成的规模不大的网络，因此从扩散范围和响应时延考虑采用泛搜索是适合的。其次为了尽可能减少泛搜索过程产生的网络开销，本发明采取以下几方面措施：一是尽可能精简泛搜索信令的长度，泛搜索信令只携带查找被呼必需的地址和路由信息；二是减少泛搜索过程中的信令个数，只有起呼方发出的泛搜索请求和终呼方发出的重定向路由响应，其它站点收到泛搜索请求不作响应；三是采用IP的多播路由，相比于单播路由大大减少了泛搜索同一方向多个目标需要传输的IP包；四是限制多播路由跳数，通过设置“ttl”参数，防止泛搜索请求超过有效范围扩散；五是缓存通过泛搜索获得的用户路由信息，用于加快再次寻呼。

本发明泛搜索所采用的SIP多播技术涉及的会话控制消息和相关流程完全遵循IETF RFC 3261，因此具有良好的协议通用性和健壮性。

本发明由于采用了泛搜索和确知路由相结合的跨域寻呼方法，具有较好的网络环境自适应能力。无需预先规划和配置需要建立跨域业务的关联站点和路由参数，也无需因网络发生变化而修改路由配置参数。系统只需要规划和配置泛搜索的多播群组和对应的多播组地址以及限制多播范围的“ttl”等参数即可，大大降低了实现跨域会话控制所需的系统维护难度。

综上所述，本发明为应急机动分布式通信网络建立跨域会话连接提供了一种运行高效、维护简便和协议通用的寻呼机制，达到了高效地和鲁棒地建立跨域多媒体业务会话连接的目的。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种建立跨域会话连接的方法，其特征在于，包括步骤：

接收本站点内的起呼用户设备发送的建立会话连接的单播请求，其中所述单播请求包括被呼用户设备的信息；

检测到所述被呼用户设备不在本站点内时，将多播请求发送给多播组的各个站点，其中所述多播请求包括所述多播组的地址和所述被呼用户设备的信息；

接收所述被呼用户设备所在站点根据所述多播请求向所述多播组的各个站点发送的多播重定向响应，所述多播重定向响应包括从所述起呼用户设备所在站点到达所述被呼用户设备所在站点的第一路由信息；

根据所述第一路由信息建立所述起呼用户设备和所述被呼用户设备之间的会话连接。

2.根据权利要求1所述的建立跨域会话连接的方法，其特征在于，检测到所述被呼用户设备不在本站点内时，将多播请求发送给多播组的各个站点之前，还包括步骤：

检测本站点存储的被呼用户路由表中是否存在从所述起呼用户设备所在站点到达所述被呼用户设备所在站点的第一路由信息；

若不存在所述第一路由信息，进入将多播请求发送给多播组的各个站点的步骤；

若存在所述第一路由信息，根据所述第一路由信息向被呼用户设备所在站点发送所述单播请求；

接收所述被呼用户设备所在站点根据所述单播请求返回的响应信息；

在所述响应信息为不存在所述被呼用户设备时，将所述被呼用户路由表中的所述第一路由信息删除，进入将多播请求发送给多播组的各个站点的步骤。

3.根据权利要求2所述的建立跨域会话连接的方法，其特征在于，

接收所述被呼用户设备所在站点根据所述单播请求返回的响应信息之后，还包括步骤：在所述响应信息为呼叫成功时，将所述第一路由信息更新至所述被呼用户路由表的表首；

和/或，

接收所述被呼用户设备所在站点根据所述多播请求向所述多播组的各个站点发送的多播重定向响应之后，还包括步骤：检测本站点存储的所述被呼用户路由表的容量是否已满；若容量已满，将位于所述被呼用户路由表表尾的第二路由信息删除，将所述第一路由信息添加到所述被呼用户路由表的表首；若容量未满，将所述第一路由信息添加到所述被呼用户路由表的表首。

4.根据权利要求1所述的建立跨域会话连接的方法，其特征在于，

将多播请求发送给多播组的各个站点的同时，还包括步骤：开启等待多播重定向响应的定时器；

若在所述定时器指定的时间内没有接收到所述多播重定向响应，将寻呼失败的消息返回给所述起呼用户设备；

若在所述定时器指定的时间内接收到所述多播重定向响应，将所述定时器关闭。

5.根据权利要求1至4任意一项所述的建立跨域会话连接的方法，其特征在于，所述多播请求不携带body字段；所述多播请求还包括消息生存期参数，所述消息生存期参数用于限制多播请求的路由跳数。

6.一种建立跨域会话连接的装置，其特征在于，包括：

单播请求接收模块，用于接收本站点内的起呼用户设备发送的建立会话连接的单播请求，其中所述单播请求包括被呼用户设备的信息；

多播请求发送模块，用于检测到所述被呼用户设备不在本站点内时，将多播请求发送给多播组的各个站点，其中所述多播请求包括所述多播组的地址和所述被呼用户设备的信息；

多播重定向响应接收模块，用于接收所述被呼用户设备所在站点根据所述多播请求向所述多播组的各个站点发送的多播重定向响应，所述多播重定向响应包括从所述起呼用户设备所在站点到达所述被呼用户设备所在站点的第一路由信息；

会话连接建立模块，用于根据所述第一路由信息建立所述起呼用户设备和所述被呼用户设备之间的会话连接。

7.根据权利要求6所述的建立跨域会话连接的装置，其特征在于，所述多播请求发送模块包括：

第一路由信息检测单元，用于在检测到所述被呼用户设备不在本站点内时，检测本站点存储的被呼用户路由表中是否存在从所述起呼用户设备所在站点到达所述被呼用户设备所在站点的第一路由信息；

第一多播请求发送单元，用于在不存在所述第一路由信息时，将多播请求发送给多播组的各个站点；

单播请求发送单元，用于在存在所述第一路由信息时，根据所述第一路由信息向被呼用户设备所在站点发送所述单播请求；

响应信息接收单元，用于接收所述被呼用户设备所在站点根据所述单播请求返回的响应信息；

第二多播请求发送单元，在所述响应信息为不存在所述被呼用户设备时，将所述被呼用户路由表中的所述第一路由信息删除，将多播请求发送给多播组的各个站点。

8.根据权利要求7所述的建立跨域会话连接的装置，其特征在于，

所述多播请求发送模块还包括与所述响应信息接收单元相连的第一路由信息更新单元，所述第一路由信息更新单元用于在所述响应信息为呼叫成功时，将所述第一路由信息更新至所述被呼用户路由表的表首；

和/或，

建立跨域会话连接的装置还包括与所述多播重定向响应接收模块相连的路由信息更新模块，所述路由信息更新模块包括：

路由表容量检测单元，用于检测本站点存储的所述被呼用户路由表的容量是否已满；

第二路由信息更新单元，用于在容量已满时，将位于所述被呼用户路由表表尾的第二路由信息删除，将所述第一路由信息添加到所述被呼用户路由表的表首；

第三路由信息更新单元，用于在容量未满时，将所述第一路由信息添加到所述被呼用户路由表的表首。

9.根据权利要求6所述的建立跨域会话连接的装置，其特征在于，

所述多播请求发送模块将多播请求发送给多播组的各个站点的同时，还用于开启等待多播重定向响应的定时器；

所述多播重定向响应接收模块还用于在所述定时器指定的时间内没有接收到所述多播重定向响应时，将寻呼失败的消息返回给所述起呼用户设备，在所述定时器指定的时间内接收到所述多播重定向响应时，将所述定时器关闭。

10.根据权利要求6至9之一的所述的建立跨域会话连接的装置，其特征在于，所述多播请求不携带body字段；所述多播请求还包括消息生存期参数，所述消息生存期参数用于限制多播请求的路由跳数。