CN101309329B - 一种呼叫完成业务的激活及发生时的实现方法 - Google Patents

Abstract

本发明公开了一种呼叫完成业务的激活及发生的实现方法，降低了主叫被叫服务器上与业务实施相关的信息同步的复杂性。涉及主叫用户设备、主叫应用服务器、被叫用户设备、被叫应用服务器，其中被叫应用服务器支持CCSS业务，所述激活方法包括以下步骤：(a)主叫用户设备发起呼叫，呼叫消息经主叫应用服务器、被叫应用服务器发送至被叫用户设备；(b)所述被叫用户设备返回无法应答的消息或无应答，或所述被叫应用服务器得知所述被叫用户设备无法应答，则所述被叫应用服务器在被叫的CCSS监控队列中增加此次会话记录，并监控被叫用户设备的状态。

Description

一种呼叫完成业务的激活及发生时的实现方法

技术领域

本发明涉及通信领域，更具体地涉及一种IP多媒体子系统中的呼叫完成业务建立。

背景技术

IP(网络互联协议，Internet Protocol，简称IP)多媒体子系统(IPMultimedia Core Network Subsystem，简称IMS)是由第三代合作伙伴计划(3rdGeneration Partnership Project，简称3GPP)提出的一种基于IP的网络架构，构建了一个的开放而灵活的业务环境，支持多媒体应用，能够为用户提供丰富的多媒体业务。

在IMS业务体系中，控制层和业务层是分离的，控制层不提供具体业务，只向业务层提供必要的触发、路由、计费等功能。控制层中业务触发和控制功能是呼叫会话控制功能(Call Session Control Function，简称CSCF，分为代理Proxy、查询Interrogating和服务Serving三种类型，其中负主要责任的是Serving，Interrogating类型是可选的)完成的，业务层是由一系列应用服务器(Application Server，简称AS)组成，能提供具体业务服务，AS可以是独立的实体，也可以存在于S-CSCF中。控制层(S-CSCF)根据用户的签约信息控制业务触发，调用AS上的业务，实现业务功能。会话中的端到端设备称为用户设备UE(User Equipment)，负责与使用者的交互。这些功能实体使用SIP(Session Initiation Protocol)协议通讯。

呼叫完成业务(CCSS，暂无英文全名)指：当一方呼叫另一方，而被叫因某种原因无法与主叫建立会话时，通讯网络能在该原因消除的情况下自动完成原会话。目前只支持遇忙和无应答两种情况，前者以CCBS(Completion of Communications to Busy Subscriber，遇忙呼叫完成)表示，后者以CCNR(Completion of Communications by No Reply，无应答呼叫完成)表示。为了简化流程表示，突出实际的业务控制功能实体，在本文所有的流程图中都省略了CSCF实体，这些实体在该业务中只是简单的转发消息。

现有技术主要是在主叫侧实现业务，并需要被叫侧辅助。

图1是现有的终端判断遇忙条件下激活CCBS业务的基本消息流程图，描述的是当主叫开通了CCBS业务，主叫呼叫被叫，而被叫正忙时，网络激活CCBS业务的情况，其步骤如下：

步骤101～103，UE-A发送INVITE(邀请)消息呼叫UE-B，消息途径AS-A和AS-B最终到达UE-B；

步骤104，UE-B发现用户正忙，向UE-A回应遇忙消息“486BUSY”；

步骤105，遇忙消息途径AS-B，AS-B判断自己具有支持CCBS业务的能力；

步骤106，AS-B转发遇忙消息给UE-A，并携带AS-B支持CCBS业务的指示；

步骤107，遇忙消息途径AS-A，AS-A判断UE-A是否开通了CCBS业务；

步骤108，AS-A知道UE-A开通了CCBS业务，于是发送“183SessionProgress”消息通知UE-A呼叫继续；

步骤109，UE-A与AS-A间继续呼叫过程，AS-A将UE-A的呼叫与媒体资源功能处理器连接起来，最终建立会话，会话建立后，AS-A通知媒体资源功能处理器播放录音，询问使用UE-A的用户是否愿意激活CCBS业务；

步骤110，UE-A通过按键表示愿意激活；

步骤111，AS-A向AS-B发送SUBSCRIBE消息订阅CCBS业务；

步骤112，AS-B判断被叫用户的CCBS监控队列是否有足够空间增加新的记录，如果资源允许，则增加监控记录；

步骤113，AS-B发送NOTIFY消息通知AS-A订阅CCBS业务成功；

步骤114，AS-A收到通知后，判断主叫的CCBS业务队列是否有足够的空间增加新的会话记录，如果资源允许，则增加业务记录；

步骤115，AS-A通知媒体资源功能处理器播放录音，告知使用UE-A的用户业务激活成功；

步骤116，录音播放完后，AS-A发送遇忙消息给UE-A结束UE-A的会话；

对于网络可以判断被叫是否忙的情况，步骤103和104就不需要了，呼叫在途经AS-B时，AS-B就能判断UE-B是否忙。对于无应答情况，步骤104和106使用的消息相应改为“180Ringing”，步骤105相应的改为判断超时无应答和是否支持CCNR业务，其他流程没有变化。

在具体实现时，现有技术方案存在一个监控队列与业务队列同步的问题，即因超时等原因需要删除一个队列中的记录时，必须通知另一方删除相应记录。

图2是现有的CCBS业务发生时主叫遇忙的消息流程图，描述的是当被叫闲，从而引起CCBS业务发生时，主叫却忙的情况，此时网络将挂起此次业务，直到主叫闲时再继续此次CCBS业务，其步骤如下：

步骤201，被叫方网络的应用服务器AS-B监控到被叫UE-B已闲；

步骤202，AS-B发送NOTIFY消息通知AS-A被叫已闲，可以启动CCBS业务；

步骤203，AS-A收到通知，发送REFER(转移)或INVITE消息给UE-A开始CCBS业务会话；

步骤204，UE-A遇忙，回应“486BUSY”给AS-A；

步骤205，AS-A发送SUBSCRIBE消息给AS-B，要求挂起此次CCBS业务；

步骤206，AS-A利用已有的CCBS队列记录监控主叫UE-A；

步骤207，AS-A监控到UE-A已闲，AS-A发送SUBSCRIBE(订阅)消息给AS-B，要求重启此次CCBS业务。

AS-B收到消息后会再次执行步骤202。直到业务完成后，AS-A和AS-B中的该业务队列记录才会被删除。

但基于现有的实现方案，存在以下不足之处：

1、业务激活需要主叫方与被叫方网络同时支持CCSS业务，并同时需要双方应用服务器队列资源的协助，如果主叫不支持该业务或主叫方资源限制被超出，例如，在图1步骤114中队列如果溢出，业务就无法激活，从而更无法开展；

2、与业务实施相关的信息分散在主叫与被叫的应用服务器中，增加了同步的复杂性；

3、当CCBS业务发生时，主叫却无应答，对于这种情况现有技术并没给出解决方案，当CCNR业务发生时，主叫却忙，也无相应方案。

发明内容

本发明要解决的技术问题是提供一种呼叫完成业务的激活及发生的实现方法，降低了主叫被叫服务器上与业务实施相关的信息同步的复杂性。

为了解决上述技术问题，本发明提供了一种呼叫完成业务CCSS的激活方法，涉及主叫用户设备、主叫应用服务器、被叫用户设备、被叫应用服务器，其中被叫应用服务器支持CCSS业务，所述方法包括以下步骤：

(a)主叫用户设备发起呼叫，呼叫消息经主叫应用服务器、被叫应用服务器发送至被叫用户设备；

(b)所述被叫用户设备返回无法应答的消息或无应答，或所述被叫应用服务器得知所述被叫用户设备无法应答，则所述被叫应用服务器在被叫的CCSS监控队列中增加此次会话记录，并监控被叫用户设备的状态。

进一步地，所述CCSS业务包括遇忙呼叫完成业务CCBS和无应答呼叫完成业务CCNR。

进一步地，所述会话记录包括主叫用户设备地址，或者还包括媒体信息。

进一步地，所述无法应答的消息是指遇忙消息或其他会话建立失败的消息。

进一步地，所述主叫应用服务器支持CCSS业务，且所述主叫用户设备开通了CCSS业务，在所述步骤(b)中，所述被叫应用服务器收到被叫用户设备发出的无法应答的消息，将无法应答消息转发给所述主叫应用服务器，或所述被叫应用服务器得知被叫用户设备无法应答后，发送无法应答消息给所述主叫应用服务器，所述主叫应用服务器收到无法应答消息或等待被叫应答超时，所述主叫应用服务器判断若主叫用户设备开通了CCSS业务，则与其建立会话，在主叫用户设备确认激活所述CCSS业务后，通知所述被叫应用服务器，所述被叫应用服务器在资源允许的情况下向CCSS监控队列中增加此次会话记录；在所述步骤(b)后，还包括步骤(c)：所述被叫应用服务器通知所述主叫用户设备CCSS业务激活成功。

进一步地，所述主叫应用服务器支持CCSS业务，且所述主叫用户设备配置了CCSS业务，在所述步骤(a)中，所述主叫应用服务器收到主叫用户设备发出的呼叫消息后，判断所述主叫用户设备开通了CCSS业务，则在向所述被叫应用服务器转发呼叫信息时携带CCSS业务标识；在所述步骤(b)中，所述被叫应用服务器收到所述被叫用户设备返回无法应答的消息或得知所述被叫用户设备无法应答或等待应答超时后，与所述主叫用户设备建立会话，在主叫用户设备确认激活CCSS业务后，所述被叫应用服务器在资源允许的情况下向CCSS监控队列中增加此次会话记录；在所述步骤(b)后，还包括步骤(c)：所述被叫应用服务器通知所述主叫用户设备CCSS业务激活成功。

进一步地，所述被叫用户设备开通了CCSS业务，在所述步骤(b)中，所述被叫应用服务器收到所述被叫用户设备返回的无法应答的消息或得知所述被叫用户设备无法应答或等待应答超时后，判断若被叫用户设备开通了CCSS业务，则与主叫用户设备建立会话，在主叫用户设备确认激活所述CCSS业务后，所述被叫应用服务器在资源允许的情况下向CCSS监控队列中增加此次会话记录；在所述步骤(b)后，还包括步骤(c)：所述被叫应用服务器通知所述主叫用户设备CCSS业务激活成功。

为了解决上述技术问题，本发明还提供了一种呼叫完成业务CCSS的实现方法，所述方法包括以下步骤：

(a)主叫用户设备发起呼叫而被叫用户设备无法应答或不应答时，主叫用户设备激活CCSS业务，所述被叫应用服务器在被叫的CCSS监控队列中增加此次会话记录，并监控被叫用户设备的状态；

(b)所述被叫应用服务器监控到所述被叫用户设备已闲或可应答时，通知所述主叫应用服务器被叫的状态改变，或要求所述主叫用户设备重新呼叫，或呼叫所述主叫用户设备，所述主叫应用服务器收到状态改变通知或要求呼叫消息，则呼叫所述主叫用户设备或要求所述主叫用户设备发起呼叫，所述主叫用户设备应答呼叫或者发起呼叫，建立与被叫用户设备的会话；

或者，此时主叫用户设备再次发起向所述被叫用户设备的呼叫，被叫应用服务器收到请求后，且监控到所述被叫用户设备已闲或可应答，则转发呼叫请求给被叫用户设备，建立主叫用户设备与被叫用户设备的会话。

进一步地，在所述步骤(b)中，所述主叫用户设备返回无法应答的消息给所述主叫应用服务器或不应答时，所述主叫应用服务器在主叫的CCSS业务队列中增加此次会话记录，监控所述主叫用户设备的状态，并通知所述被叫应用服务器挂起此次CCSS业务，当所述主叫用户设备已闲或可应答时，再由所述主叫应用服务器通知所述被叫应用服务器重启此次CCSS业务。

进一步地，所述主叫应用服务器向所述被叫应用服务器发送订阅SUBSCRIBE消息或通知NOTIFY消息，通知所述被叫应用服务器挂起此次CCSS业务或重启此次CCSS业务。

进一步地，所述主叫应用服务器在主叫的CCSS业务队列中增加此次会话记录采用以下方式之一：如果没有主叫的CCSS业务队列，所述主叫应用服务器新建一主叫的CCSS业务队列，在队列中增加监控记录；如果有主叫的CCSS业务队列，判断针对主叫的CCSS业务队列空闲空间如果足够，则在队列中增加监控记录。

进一步地，所述步骤(a)进一步包括以下步骤：(i)主叫用户设备发起呼叫，呼叫消息经主叫应用服务器、被叫应用服务器发送至被叫用户设备；(ii)所述被叫用户设备返回无法应答的消息或无应答，或所述被叫应用服务器得知所述被叫用户设备无法应答，则所述被叫应用服务器在被叫的CCSS监控队列中增加此次会话记录，并监控被叫用户设备的状态。

进一步地，在所述步骤(b)中，

当所述CCSS激活由被叫实现时，所述被叫应用服务器通过转移REFER消息要求主叫用户设备发起到所述被叫用户设备的呼叫，或通过邀请INVITE消息直接发起到所述主叫用户设备的呼叫，所述主叫应用服务器转发消息，或收到REFER消息时通过邀请INVITE消息直接发起呼叫；

或当所述CCSS激活由主叫实现时，所述被叫应用服务器通过通知NOTIFY消息告知主叫应用服务器所述被叫用户设备已闲或可应答，所述主叫应用服务器通过转移REFER消息要求主叫用户设备发起呼叫，或通过邀请INVITE消息直接发起呼叫；

或当所述主叫用户设备正好在所述被叫应用服务器得知所述被叫用户设备已闲或可应答时再次呼叫所述被叫用户设备，所述被叫应用服务器转发呼叫请求给所述被叫用户设备。

进一步地，当所述主叫用户设备正好在所述被叫应用服务器得知所述被叫用户设备已闲或可应答时再次呼叫所述被叫用户设备，所述被叫应用服务器修改呼叫中的会话媒体信息，使用原有媒体类型建立会话。

进一步地，在所述步骤(b)中，所述主叫应用服务器呼叫所述主叫用户设备是通过邀请INVITE消息直接发起到所述主叫用户设备的呼叫，所述主叫应用服务器要求所述主叫用户设备发起呼叫是通过转移REFER消息要求主叫用户设备发起到所述被叫用户设备的呼叫。

本发明方法基于在必要的时候才需要主叫方参与监控，从而避免了主叫过度参与造成的业务可实施性降低的问题；同时通过信息集中，降低了业务信息同步的复杂性。

附图说明

图1为现有的终端判断遇忙条件下激活CCBS业务的消息流程图；

图2为现有的CCBS业务发生时主叫遇忙的消息流程图；

图3为第一实施例终端判断遇忙条件下激活CCBS业务(主叫业务，主叫AS与主叫交互)的消息流程图；

图4为第二实施例终端判断遇忙条件下激活CCBS业务(主叫业务，被叫AS与主叫交互)的消息流程图；

图5为第三实施例终端判断遇忙条件下激活CCBS业务(被叫业务)的消息流程图；

图6为第四实施例CCBS业务发生时实现呼叫完成的消息流程图；

图7为第五实施例CCBS业务发生时主叫遇忙的消息流程图。

图8为第六实施例CCBS业务发生时主叫正呼叫被叫的消息流程图。

具体实施方式

下面将结合附图及实施例对本发明的技术方案进行更详细的说明。

本发明的主要思路是将图1步骤114中的主叫业务队列放到被叫应用服务器中，与其中的监控队列合一。

主要包括以下步骤：

(1)初始化设置，在被叫方网络的应用服务器上为被叫用户终端(UE-B)开通该业务(被叫业务)即被叫用户开通CCSS业务，或在主叫方网络的应用服务器上为主叫用户终端(UE-A)开通CCSS业务(主叫业务)即主叫用户开通CCSS业务；

(2)当主叫呼叫被叫，而被叫方无法实现会话应答时，主叫方应用服务器不记录每次的业务信息，而是由被叫方应用服务器记录。

进一步的，当被叫闲从而使该业务发生，但此时主叫又无法进行对被叫的再次呼叫(因主叫忙，不在线等原因)，或不应答或无法应答应用服务器发起的第三方控制的呼叫(可以是主叫方AS发起，也可以是被叫方AS发起)，则主叫方应用服务器可使用监控队列监控主叫的状态，一旦状态改变，主叫方应用服务器通知队列中记录的被叫方应用服务器重启业务，或主叫方应用服务器或被叫方应用服务器使用短信、消息等方法通知主叫这一情况，使主叫可选择是否再次呼叫被叫。

下面用六个应用实例进一步说明本发明，所有流程都是以CCBS业务来说明的，对于其他条件引起的会话未建立情况，比如CCNR，则只需修改激活业务的条件和发生业务的条件。

第一实施例

图3为终端判断遇忙条件下激活CCBS业务(主叫业务，主叫AS与主叫交互)的消息流程图，描述了当主叫开通了CCBS业务，主叫呼叫被叫，而被叫正忙时，网络激活CCBS业务的过程，其中由主叫AS与主叫交互，询问是否激活业务。包括以下步骤：

步骤301，UE-A呼叫UE-B，UE-A向AS-A发送呼叫消息，比如INVITE(邀请)消息；

步骤302，AS-A将该消息转发给AS-B；

步骤303，AS-B将该消息转发给UE-B；

步骤304，UE-B判断用户正忙，则向AS-B回应遇忙，比如发送“486BUSY”；

步骤305，AS-B收到遇忙消息后，判断自己是否具有支持CCBS业务的能力，如果是，则执行下一步；

步骤306，AS-B转发遇忙消息给AS-A；遇忙消息中携带支持CCBS业务的指示，用于通知AS-A其支持CCBS。

步骤307，AS-A收到遇忙消息后，判断UE-A是否开通了CCBS业务，如果是，执行下一步；

步骤308，AS-A通知UE-A呼叫继续，比如发送“183Session Progress”消息；

步骤309，UE-A与AS-A间继续呼叫过程，AS-A将UE-A的呼叫与媒体资源功能处理器连接起来，最终建立会话，会话建立后，AS-A通知媒体资源功能处理器播放录音，询问使用UE-A的用户是否愿意激活CCBS业务；

步骤310，UE-A表示愿意激活，比如通过按键方式；

步骤311，AS-A通知AS-B订阅该业务，比如发送SUBSCRIBE消息；

步骤312，AS-B判断针对被叫的CCBS业务队列是否有足够的空间增加新的会话记录，如果资源允许，则增加记录，记录此次会话相关的信息，包括主叫用户设备地址等，还可以包括会话的媒体信息(媒体类型、媒体协议、媒体端口等)，并监控被叫UE-B的状态；

步骤313，AS-B通知AS-A订阅CCBS业务成功，比如发送NOTIFY(通知)消息；

步骤314，AS-A通知媒体资源功能处理器播放录音，告知使用UE-A的用户业务激活成功；

步骤315，录音播放完后，AS-A发送遇忙消息给UE-A结束与UE-A的会话。

当被叫网络能得知被叫是否忙的状态信息时，步骤303和304可以没有。

当某次CCBS业务实现后，AS-B上队列中的记录即可以删除或使其无效。

对于被叫用户设备无应答的情况，应用服务器等待应答超时，则进行后续处理。

第二实施例

图4是终端判断遇忙条件下激活CCBS业务(主叫业务，被叫AS与主叫交互)的消息流程图，描述了当主叫开通了CCBS业务，主叫呼叫被叫，而被叫正忙时，由被叫应用服务器实现CCBS业务的激活过程，其中由被叫AS与主叫交互，询问是否激活业务(与图3的差别之处)。包括以下步骤：

步骤401，UE-A呼叫UE-B，UE-A向AS-A发送呼叫消息，比如发送INVITE消息；

步骤402，AS-A判断UE-A是否开通了CCBS业务，如果是，则在转发呼叫消息时，携带CCBS业务标识；

步骤403，AS-B收到AS-A发来的消息后，将其转发给UE-B；

步骤404，UE-B判断用户正忙，则向AS-B回应遇忙，比如发送“486BUSY”；

步骤405，AS-B收到遇忙消息后，判断自己是否具有支持CCBS业务的能力，并判断主叫是否开通了CCBS业务，如果是，则执行下一步；

步骤406，AS-B通知主叫可继续进行呼叫过程，向AS-A发送继续呼叫消息，比如发送“183Session Progress”，消息中可携带CCBS业务的指示；

步骤407，AS-A转发继续呼叫消息给主叫UE-A；

步骤408，UE-A与AS-B间继续呼叫过程，AS-B将UE-A的呼叫与媒体资源功能处理器连接起来，最终建立会话，会话建立后，AS-B通知媒体资源功能处理器播放录音，询问使用UE-A的用户是否愿意激活CCBS业务；

步骤409，UE-A表示愿意激活，比如通过按键方式；

步骤410，AS-B判断针对被叫的CCBS业务队列是否有足够的空间增加新的会话记录，如果资源允许，则增加业务记录，记录此次会话相关的信息，并监控被叫UE-B的状态；

步骤411，AS-B通知媒体资源功能处理器播放录音，告知使用UE-A的用户业务激活成功；

步骤412，录音播放完后，AS-B发送遇忙消息给AS-A；

步骤413，AS-A将遇忙消息转发UE-A，从而结束UE-A的会话。

当被叫网络能得知被叫是否忙的状态信息时，步骤403和404可以没有。

第三实施例

图5是终端判断遇忙条件下激活CCBS业务(被叫业务)的消息流程图，描述了当被叫开通了CCBS业务(与图4的区别)，主叫呼叫被叫，而被叫正忙时，网络激活CCBS业务的过程。包括以下步骤：

步骤501～503，UE-A呼叫UE-B，UE-A向AS-A发送呼叫消息，比如发送INVITE(邀请)消息，消息途径AS-A和AS-B最终到达UE-B；

步骤504，UE-B判断用户正忙，则向UE-A回应遇忙，比如发送“486BUSY”；

步骤505，AS-B判断被叫UE-B是否开通了CCBS业务，如果是，执行下一步；

步骤506，AS-B通知主叫可继续进行呼叫过程，发送继续呼叫消息，比如发送“183Session Progress”，消息中可携带CCBS业务的指示；

步骤507，继续呼叫消息由AS-A转发给主叫UE-A；

步骤508，UE-A与AS-B间继续呼叫过程，AS-B将UE-A的呼叫与媒体资源功能处理器连接起来，最终建立会话。会话建立后，AS-B通知媒体资源功能处理器播放录音，询问使用UE-A的用户是否愿意激活CCBS业务；

步骤509，UE-A通过按键表示愿意激活；

步骤510，AS-B判断被叫用户的CCBS监控队列是否有足够空间增加新的会话与监控记录，如果资源允许，则增加记录；

步骤511，AS-B通知媒体资源功能处理器播放录音，告知使用UE-A的用户业务激活成功；

步骤512～513，录音播放完后，AS-B发送遇忙消息给UE-A，消息途径AS-A，从而结束UE-A的会话。

当被叫网络能得知被叫是否忙的状态信息时，步骤503和504可以没有。

第一实施例是主叫开通CCSS业务，且由主叫实现CCSS业务的激活；而第二实施例是主叫开通CCSS业务，但由被叫实现CCSS业务的激活；第三实施例是被叫开通CCSS业务，且由被叫实现该CCSS业务的激活。三个实施例都是只有被叫记录信息。

从以上三个应用实例的实施步骤看出，由于主叫应用服务器没有业务相关的队列，自然也就不需要额外的同步措施了，降低了同步的复杂性，同时也不会因为主叫网络资源不足，而导致CCSS业务无法激活。

由于激活方法的改变，相应的也引起了业务发生时方法的改变。

第四实施例

图6是CCBS业务发生时实现呼叫完成的消息流程图，描述了当被叫闲，从而引起CCBS业务发生，最终实现呼叫完成的情况。包括以下步骤：

步骤601，被叫方网络的应用服务器AS-B监控到被叫UE-B已闲或可应答时；

步骤602，AS-B通知主叫UE-B已闲，消息中可携带会话的具体信息，比如媒体信息等；

当激活是由主叫实现时，AS-B可以通过发送NOTIFY消息告知主叫被叫已闲；

或者，当激活是由被叫实现时，AS-B可以要求UE-A再次呼叫UE-B，如发送REFER(转移)消息；AS-B也可以直接发起第三方控制的呼叫，即发送INVITE消息呼叫UE-A。这些消息中需携带CCBS指示，可携带会话的具体信息；

步骤603，AS-A收到AS-B的通知后，呼叫UE-A或者要求UE-A发起呼叫；

如果AS-A收到的是NOTIFY消息，则判断如果自己支持CCBS业务，则可通过发送REFER消息要求UE-A再次呼叫UE-B，或发起第三方控制的呼叫，呼叫UE-A；如果AS-A收到REFER或INVITE消息，则转发给UE-A，转发消息可不携带CCBS业务指示；

步骤604，UE-A收到通知，如果收到的是REFER消息，则AS-A呼叫UE-B，比如发送INVITE消息；如果收到AS-A或AS-B的INVITE消息，则应答呼叫；

步骤605，步骤604的消息到达AS-A时，如果步骤602是NOTIFY或REFER消息，则当AS-A使用REFER消息时，转发步骤604的呼叫请求，当AS-A使用INVITE消息时，则呼叫UE-B，比如发送INVITE消息给UE-B；如果步骤602是INVITE消息，则AS-A转发UE-A的应答AS-B的呼叫的消息；

步骤606，步骤605的消息到达AS-B时，如果步骤602中AS-B使用NOTIFY或REFER消息，则转发605的消息给UE-B；如果使用INVITE消息，则AS-B呼叫UE-B，比如使用INVITE消息；

步骤607，经过标准的盲转呼叫流程或第三方发起的呼叫控制流程，UE-A和UE-B间的会话建立；

第五实施例

图7是CCBS业务发生时主叫遇忙的消息流程图，描述了当被叫闲，从而引起CCBS业务发生时，主叫却忙的情况，此时网络将挂起此次业务，直到主叫闲时再继续此次CCBS业务的过程。包括以下步骤：

步骤701～703，同于步骤601～603；

步骤704，UE-A遇忙，回应遇忙消息给AS-A，比如“486BUSY”；

步骤705，AS-A新建一主叫的CCBS监控队列，或者判断针对主叫的CCBS监控队列空闲空间如果足够，则在队列中增加监控记录，记录监控信息，比如被叫地址，监控UE-A的状态；

如果AS-A不支持CCBS业务，则转发遇忙消息，如果支持CCBS业务但队列空间不足，可告知AS-B业务无法完成；AS-B得知业务失败后可选择通知(比如发送NOTIFY消息或MESSAGE消息)主叫和/或被叫业务无法完成以及业务的相关信息，比如告知主叫被叫号码、告知被叫主叫号码或原始呼叫时间、呼叫媒体类型等。

步骤706，AS-A通知AS-B挂起此次CCBS业务，比如发送SUBSCRIBE消息或NOTIFY消息；

步骤707，AS-A监控UE-A，当UE-A闲，则从监控队列中删除此次监控记录，或使其无效；

应用服务器可同时使队列中的记录都无效，并通知相应的被叫AS重启业务，也可依次使队列中的记录无效，等其业务完成或失败后再执行下一个记录。

步骤708，AS-A通知AS-B重启此次CCBS业务，比如发送SUBSCRIBE消息或NOTIFY消息。

AS-B收到消息后会再次执行步骤702。

在步骤704中，UE-A如因其他原因(比如无应答)无法继续业务，只需步骤705中在相应的监控队列(比如CCNR队列)中增加记录，步骤707的条件也相应改变即可。

第六实施例

图8是CCBS业务发生时主叫正呼叫被叫的消息流程图，描述了当CCBS业务激活后，被叫AS监控到被叫用户设备已闲，同时又收到UE-A再次呼叫UE-B的消息的情况。包括以下步骤：

步骤801，UE-A和UE-B间的CCBS业务已激活；

步骤802，UE-A再次呼叫UE-B；

步骤803，消息途经AS-A，AS-A转发该呼叫请求；

步骤804，消息途经AS-B，AS-B同时监控到UE-B已闲；

步骤805，AS-B表示CCBS业务可以完成，从而可删除该被叫用户的CCBS队列中的记录，同时转发呼叫请求给UE-B；

如果记录中有媒体信息，如媒体类型，则可修改呼叫请求中的媒体信息，建议UE-A和UE-B间使用原有媒体信息建立会话。

步骤806，UE-A和UE-B间使用标准的呼叫建立流程进行媒体信息的协商，并最终建立会话。

当然，本发明还可有其他多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。

Claims (15)

1.一种呼叫完成业务CCSS的激活方法，涉及主叫用户设备、主叫应用服务器、被叫用户设备、被叫应用服务器，其中被叫应用服务器支持CCSS业务，所述方法包括以下步骤：

(a)主叫用户设备发起呼叫，呼叫消息经主叫应用服务器、被叫应用服务器发送至被叫用户设备；

(b)所述被叫用户设备返回无法应答的消息或无应答，或所述被叫应用服务器得知所述被叫用户设备无法应答，则所述被叫应用服务器在被叫的CCSS监控队列中增加此次会话记录，并监控被叫用户设备的状态；

所述主叫应用服务器不记录每次的业务信息，而是由被叫应用服务器记录，主叫应用服务器没有业务相关的队列。

2.如权利要求1所述的方法，其特征在于，所述CCSS业务包括遇忙呼叫完成业务CCBS和无应答呼叫完成业务CCNR。

3.如权利要求1所述的方法，其特征在于，所述会话记录包括主叫用户设备地址，或者还包括媒体信息。

4.如权利要求1所述的方法，其特征在于，所述无法应答的消息是指遇忙消息或其他会话建立失败的消息。

5.如权利要求1所述的方法，其特征在于，所述主叫应用服务器支持CCSS业务，且所述主叫用户设备开通了CCSS业务，在所述步骤(b)中，所述被叫应用服务器收到被叫用户设备发出的无法应答的消息，将无法应答消息转发给所述主叫应用服务器，或所述被叫应用服务器得知被叫用户设备无法应答后，发送无法应答消息给所述主叫应用服务器；所述主叫应用服务器收到无法应答消息或等待被叫应答超时，所述主叫应用服务器判断若主叫用户设备开通了CCSS业务，则与其建立会话，在主叫用户设备确认激活所述CCSS业务后，通知所述被叫应用服务器，所述被叫应用服务器在资源允许的情况下向CCSS监控队列中增加此次会话记录；在所述步骤(b)后，还包括步骤(c)：所述被叫应用服务器通知所述主叫用户设备CCSS业务激活成功。

6.如权利要求1所述的方法，其特征在于，所述主叫应用服务器支持CCSS业务，且所述主叫用户设备开通了CCSS业务，在所述步骤(a)中， 所述主叫应用服务器收到主叫用户设备发出的呼叫消息后，判断所述主叫用户设备开通了CCSS业务，则在向所述被叫应用服务器转发呼叫信息时携带CCSS业务标识；在所述步骤(b)中，所述被叫应用服务器收到所述被叫用户设备返回无法应答的消息或得知所述被叫用户设备无法应答或等待应答超时后，与所述主叫用户设备建立会话，在主叫用户设备确认激活CCSS业务后，所述被叫应用服务器在资源允许的情况下向CCSS监控队列中增加此次会话记录；在所述步骤(b)后，还包括步骤(c)：所述被叫应用服务器通知所述主叫用户设备CCSS业务激活成功。

7.如权利要求1所述的方法，其特征在于，所述被叫用户设备开通了CCSS业务，在所述步骤(b)中，所述被叫应用服务器收到所述被叫用户设备返回的无法应答的消息或得知所述被叫用户设备无法应答或等待应答超时后，判断若被叫用户设备开通了CCSS业务，则与主叫用户设备建立会话，在主叫用户设备确认激活所述CCSS业务后，所述被叫应用服务器在资源允许的情况下向CCSS监控队列中增加此次会话记录；在所述步骤(b)后，还包括步骤(c)：所述被叫应用服务器通知所述主叫用户设备CCSS业务激活成功。

8.一种呼叫完成业务CCSS的实现方法，所述方法包括以下步骤：

(a)主叫用户设备发起呼叫而被叫用户设备无法应答或不应答时，主叫用户设备激活CCSS业务，所述被叫应用服务器在被叫的CCSS监控队列中增加此次会话记录，并监控被叫用户设备的状态；

(b)所述被叫应用服务器监控到所述被叫用户设备已闲或可应答时，通知所述主叫应用服务器被叫的状态改变，或要求所述主叫用户设备重新呼叫，或呼叫所述主叫用户设备，所述主叫应用服务器收到状态改变通知或要求呼叫消息，则呼叫所述主叫用户设备或要求所述主叫用户设备发起呼叫，所述主叫用户设备应答呼叫或者发起呼叫，建立与被叫用户设备的会话；

或者，此时主叫用户设备再次发起向所述被叫用户设备的呼叫，被叫应用服务器收到请求后，且监控到所述被叫用户设备已闲或可应答，则转发呼叫请求给被叫用户设备，建立主叫用户设备与被叫用户设备的会话。

9.如权利要求8所述的方法，其特征在于，在所述步骤(b)中，所 述主叫用户设备返回无法应答的消息给所述主叫应用服务器或不应答时，所述主叫应用服务器在主叫的CCSS业务队列中增加此次会话记录，监控所述主叫用户设备的状态，并通知所述被叫应用服务器挂起此次CCSS业务，当所述主叫用户设备已闲或可应答时，再由所述主叫应用服务器通知所述被叫应用服务器重启此次CCSS业务。

10.如权利要求9所述的方法，其特征在于，所述主叫应用服务器向所述被叫应用服务器发送订阅SUBSCRIBE消息或通知NOTIFY消息，通知所述被叫应用服务器挂起此次CCSS业务或重启此次CCSS业务。

11.如权利要求9所述的方法，其特征在于，所述主叫应用服务器在主叫的CCSS业务队列中增加此次会话记录采用以下方式之一：

如果没有主叫的CCSS业务队列，所述主叫应用服务器新建一主叫的CCSS业务队列，在队列中增加监控记录；

如果有主叫的CCSS业务队列，判断针对主叫的CCSS业务队列空闲空间如果足够，则在队列中增加监控记录。

12.如权利要求8所述的方法，其特征在于，所述步骤(a)进一步包括以下步骤：

(i)主叫用户设备发起呼叫，呼叫消息经主叫应用服务器、被叫应用服务器发送至被叫用户设备；

(ii)所述被叫用户设备返回无法应答的消息或无应答，或所述被叫应用服务器得知所述被叫用户设备无法应答，则所述被叫应用服务器在被叫的CCSS监控队列中增加此次会话记录，并监控被叫用户设备的状态。

13.如权利要求8所述的方法，其特征在于，在所述步骤(b)中，

当所述CCSS激活由被叫实现时，所述被叫应用服务器通过转移REFER消息要求主叫用户设备发起到所述被叫用户设备的呼叫，或通过邀请INVITE消息直接发起到所述主叫用户设备的呼叫，所述主叫应用服务器转发消息，或收到REFER消息时通过邀请INVITE消息直接发起呼叫；

或当所述CCSS激活由主叫实现时，所述被叫应用服务器通过通知NOTIFY消息告知主叫应用服务器所述被叫用户设备已闲或可应答，所述主 叫应用服务器通过转移REFER消息要求主叫用户设备发起呼叫，或通过邀请INVITE消息直接发起呼叫；

或当所述主叫用户设备正好在所述被叫应用服务器得知所述被叫用户设备已闲或可应答时再次呼叫所述被叫用户设备，所述被叫应用服务器转发呼叫请求给所述被叫用户设备。

14.如权利要求13所述的方法，其特征在于，当所述主叫用户设备正好在所述被叫应用服务器得知所述被叫用户设备已闲或可应答时再次呼叫所述被叫用户设备，所述被叫应用服务器修改呼叫中的会话媒体信息，使用原有媒体类型建立会话。

15.如权利要求8所述的方法，其特征在于，在所述步骤(b)中，所述主叫应用服务器呼叫所述主叫用户设备是通过邀请INVITE消息直接发起到所述主叫用户设备的呼叫，所述主叫应用服务器要求所述主叫用户设备发起呼叫是通过转移REFER消息要求主叫用户设备发起到所述被叫用户设备的呼叫。

Images