CN101911635B

CN101911635B - 用于在电信网络中向未注册或不可用的用户提供呼叫完成服务的方法

Info

Publication number: CN101911635B
Application number: CN200780102107.5A
Authority: CN
Inventors: S·斯瓦米纳桑; A·苏雅萨
Original assignee: Alcatel Optical Networks Israel Ltd
Current assignee: Alcatel Lucent SAS; Alcatel Optical Networks Israel Ltd
Priority date: 2007-12-27
Filing date: 2007-12-27
Publication date: 2014-05-28
Anticipated expiration: 2027-12-27
Also published as: WO2009083754A1; US8359015B2; US20110028130A1; EP2243274A1; EP2243274B1; CN101911635A

Abstract

公开了一种用于向未注册或不可用的用户提供呼叫完成服务(CCNReg)的方法：从发起应用服务器(AS1)向终止I-CSCF发送(9-10)SUBSCRIBE消息；接着从终止I-CSCF朝HSS发送(11)位置信息请求(LIR)，请求关于终止S-CSCF(S-CSCF2)的信息；接着从HSS向终止I-CSCF发送(12)包含S-CSCF能力或/和名称的位置信息应答(LIA)；接着分配(13)S-CSCF，该S-CSCF称为终止S-CSCF(S-CSCF2)，并且将SUBSCRIBE消息转发给所述终止S-CSCF(S-CSCF2)；接着从终止(S-CSCF2)向HSS发送(14)服务器分配请求(SAR)；接着从HSS向终止S-CSCF(S-CSCF2)发送(15)包含第二用户的配置简档信息的服务器分配应答(SAA)；接着向终止应用服务器(AS2)转发(16)SUBSCRIBE消息，以便请求处理CCNReg服务；并且接着发送(21-23)NOTIFY，该NOTITY带有对CCNReg服务的CCNReg订阅是活跃的以及针对第一用户(用户A)与第二用户(用户B)通信的CCNReg请求已经被排队的指示。

Description

用于在电信网络中向未注册或不可用的用户提供呼叫完成服务的方法

技术领域

本发明一般地涉及呼叫完成服务，其使得呼叫尝试由电信网络来完成而主叫用户自身不需要发起(重复的)新的尝试。其特别涉及通过基于SIP的电信网络，特别是IP多媒体子系统，建立的呼叫。

背景技术

缩写

AKA 认证和密匙协商机制

AS 应用服务器

AVP 属性值对

CCBS 占线订户的呼叫完成

CCNR 无应答呼叫完成

CCNReg 对未注册或不可用的用户的呼叫完成服务

HSS 归属订户服务器

I-CSCF 询问呼叫会话控制功能

IMS IP多媒体子系统

IP 网际协议

ISUP ISDN(综合业务数字网)用户部分

LIA 位置信息应答

LIR 位置信息请求

MAA 多媒体-认证-应答

MAR 多媒体-认证-请求

MGCF 媒体网关控制器功能

MRF 媒体资源功能

NGN 下一代网络

P-CSCF 代理-呼叫会话控制功能

PLMN 公共陆地移动网络

PPA 推送属性应答

PPR 推送属性请求

PS (SIP)代理服务器

PSTN 公共交换电话网络

REL (ISUP)释放消息

RLC (ISUP)释放完成消息

RTA 注册终止应答

RTP 实时传输协议

RTR 注册-终止-请求

SAA 服务器-分配-应答

SAR 服务器-分配-请求

S-CSCF 服务-呼叫会话控制功能

SDP 会话描述协议

SIP 会话发起协议

SL 订户定位符

TCAP 事务处理能力应用部分

UAA 用户-认证-应答

UAR 用户-认证-请求

现在的呼叫完成服务的例子包括占线订户的呼叫完成(CCBS)和无应答呼叫完成(CCNR)。

网元监视被叫用户的状态，并且当被叫用户变为“有空再呼叫(recall)”时“再呼叫”主叫用户。在多个主叫用户对相同的被叫用户做出呼叫尝试时，使用被叫用户队列来存储相关的信息，并且接着按顺序完成呼叫尝试。(责任方：终止交换机)。一个主叫用户可以对不同的被叫用户多次调用“呼叫完成”服务，这也通过使用针对主叫用户的队列来管理。(责任方：发起交换机)。

对于当他们的电话终端被呼叫时正在忙或者不在场的用户，目前在公共交换电话网络(PSTN)和公共陆地移动网络(PLMN)中可以使用CCBS和CCNR。对于不能联系上的情形，可以使用PLMN内的呼叫完成。对于基于IP的电信网络，出现了新的概念：注册和呈现(presence)。在基于IP的网络中，如果用户没有在注册服务器中“注册”，用户将不能被呼叫。类似地，如果用户在呈现服务器中不具有状态“可用的”，则用户不能从呈现业务获益。

就用户的电话终端被呼叫时正在忙或者不在场的用户而言，在标准体(ETSI TISPAN)中正在讨论针对下一代网络(NGN)以及针对基于会话发起协议(SIP)的网际协议多媒体子系统(IMS)的CCBS和CCNR。IETF中正在讨论针对基于SIP(不一定是IMS)的网络的CCBS和CCNR服务，并且已经提议了草案。

就未注册/不可用的用户而言，现在没有针对未注册/不可用的用户的呼叫完成服务，使得针对未注册/不可用的被叫IMS/SIP用户的通信尝试能够完成而不需要主叫用户不得不发起新的通信尝试。

因此，需要提供一种用于在基于SIP的网络(IMS或非IMS网络)中的针对未注册/不可用的用户的呼叫完成(CCNReg)服务。

本发明的另一个目的是提供CCNReg服务到PSTN/PLMN的交互(interworking)。交互将使得该服务能够被提供给：

-PSTN/PLMN用户，当该用户做出到以下用户的通信尝试时：

-SIP/IMS用户，其当前并未注册，或被叫用户的“呈现”状态指示出被叫用户不可用；

-或PLMN用户，当发起PSTN/PLMN和终止PLMN网络仅经由它们之间的IMS/SIP/VOIP网络来连接。

-IMS/VOIP/SIP用户，当此类用户做出到以下用户的通信尝试时：

-PLMN用户，其不在线/不能联系上/不可用，

-或IMS/VOIP/SIP用户，当发起和终止IMS/SIP/VOIP网络仅经由它们之间的PSTN/PLMN来连接。

注意，在IMS/SIP用户之间的呼叫的情形中，主叫和被叫用户可以属于相同的IMS/SIP网络或不同的IMS/SIP网络。

图1到图4图示出交互的各种例子。

-图1示出其中PSTN/PLMN用户A呼叫IMS/SIP用户B的例子；

-图2示出其中PSTN/PLMN用户A呼叫PLMN用户B、发起和终止网络经由IMS/SIP网络连接的例子；

-图3示出其中IMS/SIP用户A呼叫PLMN用户B的例子；

-图4示出其中IMS/SIP用户A呼叫IMS/SIP用户B、发起和终止网络经由PSTN/PLMN网络连接的例子。

发明内容

根据本发明的第一方面，提供一种用于向未注册或不可用的用户提供呼叫完成服务的方法，该服务称为CCNReg，呼叫发起于第一用户并且终止在第二用户处，该第一用户和第二用户都在IMS电信网络中，该电信网络包括：

-P-CSCF，

-针对第一用户的发起I-CSCF，该第一用户正在发起到第二用户的呼叫，

-针对第二用户的终止I-CSCF，

-针对第一用户的发起S-CSCF，

-针对第二用户的终止S-CSCF，

-针对第一用户的发起应用服务器，

-针对第二用户的终止应用服务器，

-归属订户服务器；

该方法包括多个步骤，包括检测第二用户未注册或不可用，并且接着监视第二用户的状态；

其特征在于，针对监视第二用户的状态，所述方法包括步骤：

-经由发起S-CSCF，从发起应用服务器向终止I-CSCF发送第一SUBSCRIBE消息，第一SUBSCRIBE消息包含向终止I-CSCF通知发起CCNReg服务以便完成第一用户和第二用户之间的通信尝试的指示。

-接着，在通过找到上述的指示而确定第一SUBSCRIBE(订阅)消息针对于CCNReg时，从终止I-CSCF朝HSS发送位置信息请求，请求关于终止S-CSCF的信息，

-接着从HSS向终止I-CSCF发送包含S-CSCF能力或/和名称的位置信息应答，

-接着，在终止I-CSCF中接收到S-CSCF能力或/和名称时，分配一个S-CSCF，称为终止S-CSCF，并且将SUBSCRIBE消息转发到该终止S-CSCF，

-接着，从该终止S-CSCF向HSS发送服务器分配请求，

-接着从HSS向终止S-CSCF发送包含第二用户的配置简档信息的服务器分配应答，

-接着，从终止S-CSCF向终止应用服务器转发第一SUBSCRIBE消息，以便请求处理针对第二用户的CCNReg服务功能，

-接着从终止应用服务器向发起应用服务器发送第一NOTIFY(通知)消息，该第一NOTIFY消息带有对CCNReg服务的CCNReg订阅是活跃的以及针对第一用户与第二用户通信的CCNReg请求已经被排队的指示，

-以及当第二用户再次变成已注册/可用时，并且准备好完成CCNReg呼叫时，并且第一用户成为呼叫完成队列中的第一条目时，则从终止应用服务器向发起应用服务器发送第二NOTIFY消息，该第二NOTIFY消息带有对CCNReg服务的CCNReg订阅是活跃的并且第二用户现在已注册/可用(即准备好进行对第一用户的呼叫完成)的指示。

所要求保护的方法提供了一种CCNReg服务，因为上述的SUBSCRIBE-NOTIFY机制提供一种监视第二用户的状态的方式。

本发明也提供一种询问呼叫会话控制功能实体、一种服务呼叫会话控制功能、一种应用服务器以及一种归属订户服务器，其功能上适于实现所要求保护的方法。

有可能向任何的基于SIP(非IMS)的网络提供CCNReg服务，其中由上面网元所执行的角色由例如SIP网络中的代理服务器和注册器的网元来承担。服务概念保持相同并且可以通过对呼叫/信令消息流的略微修改而容易地扩展。

因此，根据本发明的第二方面，提供一种用于向未注册或不可用的用户提供呼叫完成服务的方法，该服务称为CCNReg，呼叫发起于第一用户并且在第二用户处终止，第一用户和第二用户都位于非IMS的基于SIP的电信网络中，该电信网络包括：

-针对第一用户的发起代理服务器，该第一用户正在发起到第二用户的呼叫，

-针对第二用户的终止代理服务器，

-从发起代理服务器向终止代理服务器发送第一SUBSCRIBE消息，该第一SUBSCRIBE消息包含向终止代理服务器通知发起CCNReg服务以便完成第一用户和第二用户之间的通信尝试的指示，

-接着，在通过找到上述的指示而确定第一SUBSCRIBE消息针对于CCNReg时，从终止代理服务器朝发起代理服务器发送第一NOTIFY消息，以便传达CCNReg事件订阅现在是活跃的并且请求被排队的CCNReg特定信息。

-接着，在确定第二用户注册/变得可用时，从终止代理服务器向发起代理服务器发送NOTIFY消息，该NOTIFY消息包含第二用户有空再呼叫(即准备好进行呼叫完成)的指示。

在IMS网络的情形中通过媒体网关控制功能以及在(非IMS)SIP网络中通过SIP(到PSTN/PLMN)网关，可以附加地提供CCNReg服务到PSTN/PLMN的交互，PSTN/PLMN交换机(连接用户)功能上适用于实现所要求保护的方法。

可以对该方法进行若干种扩展/增强，并且所建议的方法可以被容易地修改以便例如提供：作为终止特征的CCNReg、选择性的CCNReg等。

当结合附图时，从下面的本发明实现的详细描述，本发明的其他特征和优势将变得明显。

附图说明

为了详细地阐述本发明实现的特征和优势，下面将参考附图。如果可能，贯穿所有附图和描述，相似或类似的参考标号指代相同或类似的部件，其中：

-图1(上面已经提到)示出其中PSTN/PLMN用户A呼叫IMS/SIP用户B的例子；

-图2(上面已经提到)示出其中PSTN/PLMN用户A呼叫PLMN用户B、发起和终止网络经由IMS/SIP网络连接的例子；

-图3(上面已经提到)示出其中IMS/SIP用户A呼叫PLMN用户B的例子；

-图4(上面已经提到)示出其中IMS/SIP用户A呼叫IMS/SIP用户B、发起和终止网络经由PSTN/PLMN网络连接的例子；

-图5绘出其中可以应用根据本发明的方法的IMS网络的例子；

-图6到图16绘出其中呼叫方A和被叫方B属于同一基于SIP的网络的例子中的呼叫流程，其中利用了该方法的第一处理；

-图17到图18绘出针对其中呼叫方A和被叫方B属于同一基于SIP的网络的相同例子的呼叫流程的一部分，但是其中利用了暗含对某些步骤的修改的第二处理；

-图19到图21绘出其中呼叫方和被叫方属于一个非IMS的SIP网络的例子中的呼叫流程；

-图12到图25绘出其中主叫方属于PSTN/PLMN，并且被叫方属于基于SIP的网络的例子中的呼叫流程；

-图25到30绘出其中主叫方属于SIP网络而被叫方属于PLMN网络的例子中的呼叫流程。

具体实施方式

主叫用户和被叫用户属于基于IMS的网络

图5绘出IMS网络的例子，在所述IMS网络中通过在节点中执行一些已修改的软件可以实现根据本发明的方法。

该例子的IMS网络包括两个部分，N1和N2，它们连接在一起。用户A的IMS终端连接到第一网络部分N1，当用户A正在呼叫时，第一网络部分N1将被称为发起网络。网络N1包括：

-归属订户服务器HSS1，其是支持实际处理呼叫的IMS网络实体的主(master)用户数据库。其包含订阅相关的信息(用户配置简档)，执行对用户的认证和授权，并且可以提供关于用户的物理位置的信息。其类似于PLMN的归属位置寄存器(HLR)和认证中心(AUC)。

-代理呼叫会话控制功能P-CSCF1，其是针对用户A的IMS终端的第一接触点的SIP代理。IMS终端发现其P-CSCF，或者因为通过协议DHCP(动态主机配置协议)指示，或者因为其在通用分组无线服务(GPRS)的PDP(公共数据协议)上下文中分配。P-CSCF在注册期间分配给IMS终端，并且在该注册的持续期间不会改变。代理呼叫会话控制功能P-CSCF 1位于来往于用户A的终端的所有信令消息的路径上，并且可以检查每个消息。其认证用户并且建立与IMS终端的IPsec安全关联。其也产生计费记录。

-服务呼叫会话控制功能S-CSCF1，其是信令平面的中心节点。其向用户提供他们订阅的服务。每个终端在SIP注册上与S-CSCF关联。进入和外出的会话通过它。归属订户服务器HSS1维护关于S-CSCF1的信息以及用户的关联。归属订户服务器HSS1知道用户的位置以及订制的服务。S-CSCF通常是SIP服务器，但也执行会话控制。其使用到归属订户服务器HSS1的DIAMETER Cx和Dx接口以便下载和上传用户配置简档-其不具有用户的本地存储。所有必要的信息从HSS加载。附着到网络部分N1的每个终端在SIP注册上与S-CSCF1关联。其处理SIP注册，这允许其将用户位置(例如，用户的IP地址)与用户的SIP地址绑定。其位于所有信令消息的路径上，并且可以检查每个消息。其决定SIP消息将被转发到哪个或哪些应用服务器以便提供它们的服务。其通常使用电子编号(ENUM)查询来提供路由服务。其强制执行网络运营商的策略。出于负荷分担以及高可用性的原因，网络中可以有多个S-CSCF。

-询问呼叫会话控制功能I-CSCF1，其为用户定位关联的S-CSCF，并且将请求路由到它。其IP地址在域的域名系统(DNS)中公开，从而远程服务器可以找到I-CSCF1并且使用其作为SIP分组到该域的转发点。询问呼叫会话控制功能I-CSCF1通过使用DIAMETER Cx接口取回用户位置来查询归属订户服务器HSS1，并且接着将SIP请求路由到其分配的服务呼叫会话控制功能S-CSCF1。当由询问呼叫会话控制功能I-CSCF1进行查询时，由归属订户服务器HSS1将服务呼叫会话控制功能S-CSCF1分配给用户。

-应用服务器AS1，其主控和执行服务，并且使用协议SIP来与服务呼叫会话控制功能S-CSCF1对接。其可以查询归属订户服务器HSS1。

-媒体资源功能MRF1，其提供媒体相关功能，例如媒体操纵(例如，话音流混合)以及音调和公告的播放(媒体服务器)。

用户B的终端连接到另一网络部分N2，当用户B被呼叫时，其将被称为终止网络。网络N2包括与发起网络N1的节点类似的节点：

-代理CSCF P-CSCF2。

-服务CSCF S-CSCF2。

-询问呼叫会话控制功能，ICSCF2。

-应用服务器AS2。

-媒体资源功能MRF2。

如果此类基于SIP的网络N1-N2必须与公共交换电话网络(PSTN)交互，则其进一步包括PSTN网关。对于信令，电路交换网络使用ISDN用户部分(ISUP)或消息传输部分(MTP)上的与承载无关的呼叫控制(BICC)，而IMS网络使用IP上的会话发起协议(SIP)。对于媒体，电路交换网络使用脉冲编码调制(PCM)，而IMS网络使用实时传输协议(RTP)。PSTN网关是：

-信令网关(SGW)，其与电路交换网络的信令平面对接。其将较低层的协议(例如流控制传输协议(SCTP)、网际协议)转变成消息传输部分(MTP)、7号信令系统(SS7)协议，以便将ISDN用户部分(ISUP)从MGCF传递到电路交换网络。

-媒体网关控制器功能(MGCF)，其执行SIP和ISUP之间的呼叫控制协议转换，并且通过流控制传输协议(SCTP)与SGW对接。其也利用H.248接口控制MGW中的资源。

-通过在RTP和PCM之间转换，媒体网关(MGW)与电路交换网络的媒体平面对接。当编解码器不匹配时(例如，IMS可能使用AMR，而PSTN可能使用G.711)，其可以进行代码转换。

IMS网络中的注册

根据3GPP TS 24.228和3GPP TS 24.229中所描述的过程来执行IMS网络中的注册，根据此类过程：

UE应该利用属于UE的相关的联系地址来仅注册以及撤销注册其公共用户身份。初始注册过程包括UE发送未保护的初始REGISTER请求，并且在被质疑时，发送完整的受保护的REGISTER请求。在UE已经获得了IP地址、发现P-CSCF以及建立可以用于SIP信令的IP-CAN承载后，UE可以在任何时候以其联系地址来注册公共用户身份。然而，当UE已经接收到来自注册器的针对正在进行的注册的最终响应，或先前的REGISTER请求已经超时时，UE应该仅发起新的注册过程。

UE应该在P-CSCF发现过程期间向广告给UE的端口仅发送初始REGISTER请求。如果UE在P-CSCF发现过程期间没有接收到任何特定的端口信息，则如RFC 3261中所规定的，UE应该向SIP默认端口值发送初始REGISTER请求。REGISTER消息的内容等应该符合3GPP TS 24.229。

在初始注册期间执行认证。可以在随后的重新注册、撤销注册或附加公共用户身份的注册期间，对UE进行重新认证。当网络要求对UE认证或重新认证时，UE将接收到针对REGISTER请求的401(未授权)响应。在接收到此类响应时，由UE执行的动作应该符合3GPP TS 24.229。

在3GPP TS 24.228中说明了针对注册的示例消息流程。在REGISTER中所涉及的典型IMS网元是P-CSCF、I-CSCF、HSS以及在某些情形中的AS，以及通常充当注册器的S-CSCF。

CCNReg服务描述

所建议的CCNReg服务使得主叫用户A(碰到还未注册到网络N1-N2或已经从网络N1-N2撤销注册的被叫用户B)能够完成通信而不必做出新的通信尝试。该服务可以直接使用在IMS网络中、在非IMS的基于SIP的网络中、以及PSTN/PLMN网络中当被叫用户是IMS或SIP用户，以及主叫用户是IMS或SIP用户或者PSTN或PLMN用户时。

我们将稍后描述当被叫方属于PLMN并且主叫方是PSTN或PLMN用户、IMS或SIP用户时必要的交互方法。

尽管在该服务CCNReg与CCBS/CCNR之间存在某些相似性，但就呼叫流程以及各种网元中所需的功能性而言，还存在若干项重要的区别。

在激活该CCNReg服务时，网络监视被叫用户(用户B)的注册状态并且将监视用户B何时再次注册。类似于CCBS/CCNR服务，网络将等待短的时间，以便在用户B注册后允许资源可以重用于发起通信的用户B。如果资源没有在该时间内由用户B重用，则网络将自动地再呼叫用户A。当用户A接受CCNReg再呼叫时，则网络将自动地产生到用户B的CCNReg呼叫。

对CCNReg服务的控制由应用服务器来完成，并且用户可以通过使用合适的过程来修改CCNReg队列。发起应用服务器AS1保持跟踪用户A的CCNReg请求一个给定的时间段，直到某个可规定的限度，并且这可以通过维护每个服务的用户的队列来完成。终止应用服务器AS2保持跟踪针对用户B的CCNReg请求一个给定的时间段，并且这可以通过维护针对给定用户的未完成通信的队列来完成。在成功的CCNReg呼叫建立后，将从两个队列(由发起应用服务器AS1和终止应用服务器AS2分别保持)都删除相应的条目。

在被叫用户B存在多于一个的端点的情形中，该特征仅在它们都未注册时才变得活跃。当被叫用户的所有端点(终端)都未注册或如果主叫用户尝试与未注册的特定的端点(终端)通信时，该“未注册”情形可能出现。在该建议中所描述的处理可以被扩展到覆盖后者的情形。

对于CCNReg，根据本发明的方法可以被扩展用于基于被叫用户的“呈现”的呼叫完成。

CCNReg实现的例子的详细描述

图6到图16绘出其中主叫A和被叫B属于IMS网络或基于SIP的网络的例子中的呼叫流程。他们分别使用都连接到例如基于IP的网络的用户设备UE1和UE2，该网络包括：

-代理呼叫会话控制功能P-CSCF。

-针对用户A和用户B的公共的询问呼叫会话控制功能I-CSCF(即，在该例子中，同一个I-CSCF是发起I-CSCF和终止I-CSCF)。

-针对用户A(用户设备UE1)的服务呼叫会话控制功能S-CSCF1。

-针对用户B(用户设备UE2)的服务呼叫会话控制功能。

-针对用户A(用户设备UE1)的应用服务器AS1。

-针对用户B(用户设备UE2)的应用服务器AS2。

-归属订户服务器HSS。

-媒体服务器，其是未绘出的媒体资源功能的一部分并且可以播放通告。

在该例子中，假设：

-用户B“未注册”或“不可用”；

-对于UE1和UE2，P_CSCF和I_CSCF是相同的。

CCNReg预约

当用户(如用户设备UE1的用户A)做出到被叫用户(用户设备UE2的用户B)的通信尝试时，网络检测用户B的注册状态。我们考虑其中该状态是“未注册”的情形。

重要评论：如果对于该用户B已经分配了S-CSCF(这将发生在当S-CSCF早先已经请求HSS保留其身份时)，则用户的注册状态将是“非注册”而不是“未注册”。在这种情形下，HSS将向I-CSCF1返回分配的S-CSCF2身份，并且进入的请求(在该场景中的INVITE)将接着被发送到S-CSCF2。仅当没有向用户B分配S-CSCF，并且用户的注册状态是“未注册”时，下面描述的第一和第二处理才是相关的。

第一处理

在图6上，步骤：

1-3)用户A的用户设备UE1经由P-SCCF1和S-CSCF1向发起应用服务器AS1发送INVITE(邀请)。

4-5)发起应用服务器AS1经由S-CSCF1向终止I-CSCF(在该例子中，同一I-CSCF也是发起I-CSCF，仅为了简化阐述概念，在实际中其可以不同，因为用户A和用户B可以属于不同的IMS/SIP网络)转发INVITE。

6)终止I-CSCF向HSS发送直径位置信息请求(LIR-Cx)，以获得UE2/用户B的S-CSCF。

在图7上，步骤：

7)HSS 将位置信息应答(LIA)中的DIAMETER_ERROR_IDENTITY_NOT_REGI_STED指示返回给I-CSCF。

8)终止I-CSCF经由发起S-CSCF1将404未找到(404Not Found)响应发送回用户A的应用服务器AS1。404未找到响应包含下面的指示：

-允许事件头部：呼叫-完成；

-原因头部：“用户未注册/用户不可用”。

参见下面的注释2。

注释：在用户“不可用”的情形中(相应地，在“呈现”业务情形中用户“不在线”)，在原因头部中应该发送合适的值。

在接收到404未找到(在图中未绘出)时，发起应用服务器AS1通过检查以下来检查CCNReg对于用户A是否是可能的：

-用户A是否已经订阅服务(以及其是否被激活)。

-该404响应中的原因头部是否指示“用户未注册”。参见下面的注释2。

-CCNReg禁止是否不可应用(允许事件头部包含呼叫完成)。

-用户A的CCNReg队列是否未满。

在确保上述的条件得到满足时，发起应用服务器AS1将启动CCNReg保留定时器(T1)，在该定时器到期前，由用户A预约的CCNReg必须发生。发起应用服务器AS1也将经由S-CSCF1来触发媒体服务器(在未绘出的媒体资源功能(MRF)中)，以便由媒体服务器向用户A播放通告，通知他/她CCNReg预约是可能的，并且提示用户A来执行预约。随后，由MRF收集数字(指示CCNReg预约确认)，并且将其发送到发起应用服务器AS1(经由S-CSCF1)。接着发起应用服务器AS1发起针对用户B的状态监视：当在CCNReg保留定时器T1到期前接收到来自用户A的CCNReg预约确认时，AS1停止定时器T1，并且将用户B添加到用户A的CCNReg队列。

注释1：在确认了CCNReg预约后(对于这里所描述的第一处理，以及对于在下面部分描述的第二处理)，用户A可以挂机，即，终止到用户B的当前通信尝试。

注释2：对于纯IMS/IP网络呼叫(即，主叫和被叫用户属于IMS/SIP网络，在它们之间不涉及任何的PSTN/PLMN)，404/480响应中的原因头部不是强制的，但取决于标准化/实现方面，当与PSTN/PLMN交互时，其可能是必需的。

9-10)随后，发起应用服务器AS1经由发起S-CSCF1向终止I-CSCF(在该例子中与发起I-CSCF相同，仅为了示例说明的目的)发送SUBSCRIBE消息。此外，发起应用服务器AS1启动CCNReg请求操作定时器T2，以便监督CCNReg事件的订阅请求。SUBSCRIBE消息具有下面的内容：

-事件：呼叫完成；

注释：

1.呼叫完成事件包定义在针对欧洲电信标准协会的支持呼叫完成服务的针对会话发起协议(SIP)的IETF草案扩展draft-poetzl-bliss-call-completion-00，可在以下处获得：http://tools.ietf.org/id/draft-poetzl-bliss-call-completion-00.txt。

2.下面的声明摘自上述的IETF草案，因为其也可以应用于CCNReg服务：“SUBSCRIBE请求可以包含“接受”头部字段。如果不存在这样的头部字段，则其具有“应用/呼叫完成”的默认值。如果存在该头部字段，则其必须包括“应用/呼叫完成”。

如果在IETF draft-poetzl-sipping-call-completion-02(或其后来版本)中所给出的建议跟着用于定义针对呼叫完成服务的队列相关字段或操作，则可以定义新的队列类型“CCNReg”。这意味着下面的字段也将包括在SUBSCRIBE中：

-队列性质：CCNReg；

-队列操作：添加。

注意，针对该处理以及稍后部分中所描述的第二处理所描述的SUBSCRIBE将也在“到期(Expire)”头部包含非零值(指示订阅的持续时间)。由于这对于在IETF RFC 3265中所述的任意SUBSCRIBE-NOTIFY机制是共同的，因此其可以不必在下面的所有部分中明确地规定。

一般性的重要评论

评论1：

注意，仅在下面情况中，上面(以及在下面的部分中对于SUBSCRIBE和NOTIFY消息)所提到的“队列性质”(或，一般地，队列类型，提供关于呼叫完成服务的类型的信息)信息在(初始)SUBSCRIBE消息中是可选的(以便启动对未注册/不可用的用户B的状态监视)：

1.在呼叫仅涉及IMS/SIP网络的情形下，并且对于不同类型的呼叫完成服务(CCBS、CCNR、CCNReg等)，不需要在被叫用户侧(即，对于IMS网络和SIP网络，分别在用户B的应用服务器和用户B的代理服务器中)维护不同的队列。

2.在呼叫涉及与PSTN/PLMN的交互情形下，仅当PSTN/PLM N是发起网络，即，PSTN/PLMN不扮演互连两个IMS/SIP网络的角色，并且其也不是终止网络(被叫方不是PLMN用户)时。

这主要是因为为了调用不同的呼叫完成服务(现在例如是CCBS、CCNR以及CCNReg)，到TCAP消息的映射不同，从而例如在从IMS/IP到PLMN用户的呼叫的情形下，当由主叫用户调用CCNReg，应该确保从SIP SUBSCRIBE消息到合适的TCAP消息(及其内容)的映射以便呼叫完成服务的正确工作。

在NOTIFY消息中，队列性质(或，一般地，队列类型)是可选的，因为可以使用在RFC 3265中所描述的标准机制来将NOTIFY与触发该通知的订阅相关。

队列操作(添加、删除、中止、重新开始)是可选的，因为其可以用于清楚(以及直接)地规定由接收实体执行的实际操作(如在draft-poetzl-sipping-call-completion-02中所描述的)，或者如果其不被使用，则此类信息可以由接收实体使用其他手段来“推导”，取决于其是否被实施，实施逻辑可以略微地改变，然而这样基本服务将不会有任何影响。

在任意情形中，此类队列相关信息(例如，队列性质以及队列操作)的存在或不存在，以及其由各种网元的处理将不会影响这里所描述的CCNReg服务的基本工作。假设考虑评论1，取决于实际的标准和实现，在各种所涉及网元的实际功能逻辑中可能存在某些略微的差别。进一步，在SUBSCRIBE和NOTIFY消息中的传达呼叫完成服务相关信息(在本文档中所描述)的精确字段也将不会影响这里所述的CCNReg服务的基本工作。

对于纯IMS/SIP网络呼叫(即，主叫和被叫用户属于IMS/SIP网络，它们之间不涉及任何的PSTN/PLMN)，404/480响应中的原因头部不是强制的，但取决于标准/实现方面，当与PSTN/PLMN交互时其可能是必要的。

基于draft-poetzl-sipping-completion-02描述了例如“拒绝-原因”和“取消-原因”的多个方面。从而如果这不是必须使用的，则这些字段都可以根本不使用。因此，在整个文档中，这些方面描述为“可选的”，因此它们对于CCNReg服务的基本功能不具有影响。

评论6：

如在下面部分中描述的NOTIFY消息中，可以使用队列状态(带有请求被排队的值或用户有空再呼叫)替代呼叫完成状态。

一般性评论：在该部分以及在下面的部分中，事件特定信息，例如呼叫完成状态，将在SIP消息体中，带有如“应用/呼叫完成”的内容类型。

在图8上，步骤：

11)在确定该SUBCRIBE是针对CCNReg的(通过找到上述的内容)时，终止I-CSCF使用根据3GPP TS 29.228中规定的规则的新的属性值对(AVP)朝HSS发送LIR请求，以请求S-CSCF能力。LIR中要求新的AVP类型向HSS指示S_CSCF信息应该总是在LIA中返回(即使用户未注册)。

注释：当SUBSCRIBE具有下面的内容时，上述的AVP将由I-CSCF包括在LIR中：

-事件：呼叫完成；

此外，如上所述，可选地包含(也参见一般性的重要评论)：

-队列性质：CCNReg；

-队列操作：添加。

新的AVP将导致HSS返回S-CSCF能力/名称，即使当用户B未注册时，并且在撤消注册状态中不具有任何活跃的服务时，也是如此。

12)HSS通过向I-CSCF发送包含所请求的S-CSCF能力/名称的位置信息应答(LIA)来做出响应。

13)在从HSS接收到S-CSCF能力/名称时，I-CSCF将分配S-CSCF(自此以后这将被称为终止S-CSCF，即S-CSCF2)。接着I-CSCF将相同的SUBSCRIBE转发到S-CSCF2。该SUBSCRIBE消息包含下面的指示：

-事件：呼叫完成；

此外，如上所述，可选地包含(也参见一般性的重要评论)：

-队列性质：CCNReg；

-队列操作：添加；

以便请求终止应用服务器AS2来处理针对第二用户(用户B)的CCNReg服务功能。换句话说，在将其发送(转发)到终止应用服务器AS2之前，S-CSCF2将在接收到的SUBSCRIBE中检查上述的指示。

14)终止S-CSCF2向HSS发送服务器分配请求(SAR)。这是重要的，因为当用户B(其先前已经撤消注册)再次注册时，就是该S-CSCF将必须被使用。

在图9上，步骤：

15)HSS通过向终止S-CSCF2发送带有用户B的配置简档信息的服务器分配应答(SAA)，而做出响应。

16)随后，终止S-CSCF2朝终止应用服务器AS2发送如上所述的从I-CSCF接收到的SUBSCRIBE。因此，要求终止应用服务器AS2来处理针对被叫用户B的CCNReg服务功能。

17-20)在接收到该SUBCRIBE时，终止应用服务器AS2首先以带有订阅持续时间(在到期头部中)的200OK来做出响应(参见下面的注释)。消息200OK经由S-CSCF2、I-CSCF、S-CSCF1从终止应用服务器AS2发送到终止应用服务器AS1。

21-23)随后，终止应用服务器AS2经由S-CSCF2和S-CSCF1向发起应用服务器AS1发送带有下面内容的NOTIFY：

-事件：呼叫完成，

-订阅状态：活跃，

-呼叫完成状态：排队。

此外，如早些所述，可选地带有(也参见一般性的重要评论)，下面的队列相关信息：

-队列性质：CCNReg。

评论：在下面的NOTIFY消息中以及针对呼叫完成事件包的所有NOTIFY消息中的队列性质是可选的。

除了上面所描述的内容以外，如果支持如在draft-poetzl-bliss-call-completion-00(或其后来版本)中所描述的(或针对例如PSTN/PLMN的其他呼叫完成服务，在PSTN/PLMN中当前支持的)服务保留选项，则NOTIFY消息应该也包含服务保留指示。

应用服务器AS2此外还将用户A添加到用户B的CCNReg队列中，并且启动CCNReg服务持续时间定时器T7(针对用户B)-该定时器规定了CCNReg将为有效(即，用户A的条目将保留在用户B的CCNReg队列中，并且SUBSCRIBE-NOTIFY将被处理)的持续时间。在从终止应用服务器AS2接收到第一NOTIFY时，发起应用服务器AS1停止定时器T2，启动针对用户A的CCNReg持续时间定时器T3。该定时器T3规定了CCNReg将为有效(即，用户B的条目将保留在用户A的CCNReg队列中，并且SUBSCRIBE-NOTIFY将被处理)的持续时间。

在图10，步骤：

24-26)消息200OK从发起应用服务器AS1经由S-CSCF1以及S-CSCF2发送到终止应用服务器AS2。随后，由发起应用服务器AS1(经由S-CSCF1)通过媒体资源功能MRF来发起确认通告，其中媒体服务器向用户A播放对用户B的CCNReg预约是成功的通告。

注释：在上面所述的第一处理中，由于仅在由用户A进行CCNReg预约确认后才通知终止S-CSCF2和终止AS2，如果用户B具有CCNReg禁止，仍允许用户A来预约服务。这是因为用户B的配置简档将仅由终止S-CSCF2和AS2来审查。因此在用户B具有CCNReg禁止的情形下，403禁用响应可以由应用服务器2(AS2)发送到应用服务器1(AS1)，这是“长期拒绝”的情形。

可替换地，响应于SUBSCRIBE，应该发送正确的NOTIFY(在发送了合适的2xx响应后)。该NOTIFY将包含：

-订阅状态：终止；

-原因：驳回。

此外，如早些所述，可选地包含(也参见一般性的重要评论)，下面的信息：

-队列性质：CCNReg；(队列相关的)，以及，

-拒绝原因：长期拒绝。

如果用户B具有CCNReg禁止，则在预约确认期间，正确的通告应该播放给用户A(由发起AS1触发)。

注释：在由于其而不能接受SUBSCRIBE的某些临时故障条件的情形中，例如如果用户B的呼叫完成队列是满的，则应用服务器2(AS2)应该向应用服务器1(AS1)发送480临时不可用响应。在某个一般性错误的情形中(例如，如上所讨论的CCNReg禁止)，应用服务器2(AS2)应该向应用服务器1(AS1)发送403禁止响应。可替代地，在确认SUBSCRIBE请求后(利用2xx响应)，可以由应用服务器AS2向应用服务器AS1发送正确的NOTIFY，其规定订阅被“终止”等，可选地带有合适的“拒绝原因”(短期拒绝或长期拒绝)。

将参考图17到图18来进一步描述第二处理。

空闲保护间隔定时器处理：

稍后，用户B注册回网络(在这里没有详细示出认证方面等)。

在图10上，步骤：

27-28)当用户B注册时，UE2向P-CSCF发送REGISTER，P-CSCF将其转发到I-CSCF。P-CSCF将执行域名系统查询，并且将消息转发到I-CSCF。

29)I-CSCF向HSS发送Cx查询(以确定S-CSCF)。

30)HSS向I-CSCF发送Cx响应，其带有S-CSCF2的名称(在SUBSCRIBE由S-CSCF2接收后，存储在HSS中)。

31)I-CSCF接着向S-CSCF2发送REGISTER。

32)S-CSCF2向HSS发送SAR(Cx)。

33)HSS以SAA(Cx)向S-CSCF2做出响应。

在图11上，步骤：

34)S-CSCF2向终止应用服务器AS2发送(第三方)REGISTER。

35)终止应用服务器AS2以发送200OK做出响应。

36-38)S-CSCF2经由I-CSCF以及P-CSCF向UE2转发该200OK。

39)终止应用服务器AS2向S-CSCF2发送SUBSCRIBE(事件：注册)(参见下面的注释1)。

40)S-CSCF2向终止应用服务器AS2发送200OK。

41)接着，S-CSCF2向终止应用服务器AS2发送NOTIFY(注册状态：活跃的)。

42)终止应用服务器AS2通过200OK向S-CSCF2应答。从而经由S-CSCF2向终止应用服务器AS2通知了注册事件(参见下面的注释1)。如果对于用户B存在任何未决的CCNReg队列条目，则终止应用服务器AS2启动目的地空闲保护间隔定时器T8，在该期间，用户B将能够发起通信尝试。在该时间段期间，所有进入的呼叫将碰到“忙”指示(参见下面的注释2和3)。当用户B注册回网络时，可以可选地由AS2来启动空闲保护间隔定时器T8。仅在空闲保护间隔定时器到期时(并且用户B有空时)，才向发起AS发送关于用户B有空再呼叫的NOTIFY。在这里没有图示出与空闲保护间隔定时器关联的动作。

在图12上，步骤：

43)在定时器T8到期时(并且用户B有空)，则终止应用服务器AS2向S-CSCF2发送带有下面指示的NOTIFY(参见下面的注释4)。其也启动定时器T9以便再呼叫CCNReg目的地节点。

-事件＝呼叫完成；

-订阅状态：活跃；

-呼叫完成状态：准备好呼叫完成。

-队列性质：CCNReg。

注释：上述带有指示“准备好呼叫完成”的NOTIFY消息被发送到用户B队列中的第一条目。这里以及下面的部分中，假设用户A是用户B队列中的第一条目。

44-45)S-CSCF2和S-CSCF1转发带有相同指示的NOTIFY，直到转发到发起应用服务器AS1。

46-48)发起应用服务器AS1经由S-CSCF1和S-CSCF2以200OK向AS2应答。

注释1：在接收到REGISTER时，S-CSCF2将向(终止)AS2(其已经分配给用户B)发起第三方REGISTER。当终止AS2接收到第三方REGISTER请求时，终止AS2能够订阅“reg”事件包，基本机制在IETF RFC 3680和3GPP TS 24.229中描述(章节“公共应用服务器(AS)过程”)。

注释2：当然，其变形也可以是允许用户B在空闲保护间隔(即，空闲保护间隔定时器可以是可由运营商配置的值)期间接收进入的呼叫(如果用户B有空)。

注释3：该“忙”指示可以导致与CCBS服务的交互。

注释4：上述的NOTIFY被发送到用户B的CCNReg队列的第一(活跃的)条目。

针对用户A的CCNReg再呼叫：

由于用户B有空再呼叫，AS1发起CCNReg呼叫完成过程。在图12上，步骤：

49)在接收到用户B已经注册/现在可用的信息后，通过指示“准备好呼叫完成”(经由NOTIFY消息)，发起应用服务器AS1通过向S-CSCF1发送INVITE(没有SDP)来再呼叫用户A。发起应用服务器AS1也将启动CCNReg(发起节点)再呼叫定时器T4，在该定时器内，用户A必须对INVITE做出应答。

在图13上，步骤：

50)S-CSCF1向UE1转发INVITE。

51-52)当用户A接受再呼叫时，通过拿起电话，UE1经由S-CSCF1向应用服务器AS1发送200OK。用户B现在将被再呼叫。在从用户A接收到200OK(带有SDP Offer)时，发起应用服务器AS1发起通告，其向用户A指示正在完成CCNReg呼叫，并且到用户B的呼叫正被连接。通过经由S-CSCF1联系媒体资源功能来触发该通告(该步骤未示出)。

针对用户B的CCNReg呼叫

在图13上，步骤：

53-55)在完成向用户A播放通告后(CCNReg呼叫正在完成)，发起应用服务器AS1经由S-CSCF1和S-CSCF2向终止应用服务器AS2发送INVITE(没有SDP)，带有包含值“ccss”的P-服务指示(P-Service-Indication)头部。

56-57)在接收到该INVITE时，终止应用服务器AS2经由S-CSCF2朝被叫用户设备UE2(用户B)转发INVITE。

注释：在某些呼叫场景中，可以发送183会话进度或200OK响应以替代180响铃。也在这些情形中，下面解释的订阅终止操作将由终止AS在发送183会话进度或200OK响应之后发起。

58-59)UE2经由S-CSCF2以180响铃消息向终止应用服务器AS2做出响应。随后，在接收到来自UE2的180响铃时，终止应用服务器AS2取消定时器T9和T7，并且释放与该CCNReg请求关联的资源，包括相应的队列条目。

在图14上，步骤：

60-62)在(经由S-CSCF2)接收到来自UE2的180响铃时，终止应用服务器AS2终止针对监视用户B的注册状态的订阅请求。这可以通过经由S-CSCF1和S-CSCF2朝发起应用服务器AS1发送带有以下内容的NOTIFY并且通过清除相应的队列条目和定时器来完成。

-事件：呼叫完成；

-订阅状态：终止；

-原因：没有资源。

此外，如早些所述，可选地带有(也参见一般性的重要评论)，下面的信息：

-队列性质：CCNReg；(其是队列相关的)，并且

-取消原因：服务完成。

在接收到该(成功的)订阅取消时，发起应用服务器AS1停止定时器T3并且向终止应用服务器AS2发送200OK(未绘出)。

63-65)终止应用服务器AS2经由S-SCCF2和S-SCCF1向发起应用服务器AS1发送180响铃。

在图15上，步骤：

66-67)稍后，当用户B摘机并接听呼叫时，经由S-CSCF2朝终止应用服务器AS2发送200OK(带有SDP)。200OK接着被传递向发起应用服务器AS1。

68-70)终止应用服务器AS2经由S-SCCF2和S-SCCF1向发起应用服务器AS1转发该200OK。

71-73)UE1经由S-SCCF1向AS1发送200OK。

在图16上，步骤：

74-75)发起应用服务器AS1接着经由S-CSCF1向用户A发起Re-INVITE，其具有B的SDP offer。

76-77)用户设备UE1经由S-CSCF1、通过消息200OK向AS1做出响应。

78-79)在从用户A接收到200OK后，应用服务器AS1直接向UE1发送消息ACK，并且直接向UE2发送消息ACK(具有A的SDP)，而不涉及终止应用服务器AS2。在UE1和UE2之间建立RTP路径。随后(未绘出的步骤)，发起应用服务器AS1也释放朝MRF的呼叫(其被建立以便向用户A播放CCNReg呼叫连接通告)。

到此，呼叫完成动作已结束，并且另外的步骤将类似于常规呼叫场景。

一般性评论：在用户之一是PSTN/PLMN订户的情形下(例如主叫用户是PSTN/PLMN，或如果被叫用户是PLMN用户)，SIP特定的消息/参数应该被映射到TCAP中的合适动作。更多描述，参见下面与PSTN/PLMN交互的部分。

第二处理

图17-18图示出针对上述实现的第二处理。步骤1-5不变，而步骤6-13用图17-18上示出的步骤206-213来替代，以及步骤14-79不变。

206)在步骤6中，终止I-CSCF向HSS发送直径位置信息请求(LIR-Cx)，以便获得针对用户B的用户设备UE2的S-CSCF。

207)响应于该LIR，HSS向终止I-CSCF返回S-CSCF能力/名称(如在3GPP TS 29.228的章节6.7中所定义)，以替代不分配S-CSCF的响应(因为用户B未注册)。

208)I-CSCF接着基于返回的能力来选择(终止)S-CSCF。所选择的S-CSCF是终止S-CSCF2。其稍后从HSS获得用户配置简档(使用SAR/SAA)(步骤未示出)。

209)通过向终止应用服务器AS2发送接收的INVITE，终止S-CSCF2接着激活终止应用服务器AS2。

210-213)随后，终止应用服务器AS2经由终止S-CSCF2、发起S-CSCF1、I-CSCF以及发起S-CSCF1再次向发起应用服务器AS1发送404未找到响应(参见下面的注释2)。

404未找到响应中的原因头部包含“用户未注册“(参见下面的注释3)。此外，终止应用服务器AS2在404响应中的允许事件头部中包括“呼叫完成”(参见下面的注释4、注释5以及一般性的重要评论)。

随后，当用户A确认CCNReg预约时，这将直接到达S-CSCF1，而不像第一处理中那样必须要确定一个。所有的其他动作类似于上述的第一处理，即，跟着是步骤9。

一般性评论：替代404未找到响应，可以发送在允许事件和原因头部中具有相同指示的480临时不可用响应(或某个其他合适的错误响应-参见下面的注释5)。在这种情形下，所有其他的动作类似于当发送404未找到响应时的情形。

注释1：在该第二处理中，将总是向S-CSCF和应用服务器通知发生到未注册用户的呼叫(即使对于CCNReg不是由用户A调用的情况)。甚至对于非INVITE请求也是这种情形，因此对于I-CSCF，一种增强将是在LIR中包括新的AVP以指示请求的类型(INVITE、SUBSCRIBE等)，并且接着HSS可以仅针对因INVITE触发的LIR返回S-CSCF能力/名称。

注释2：如果初始INVITE没有被转发到终止AS2，则S-CSCF也可以驱动404未找到响应。在该情形下，S-CSCF应该针对终止AS2填充如上所述的404未找到响应的内容。

注释3：在用户“不可用”/“不在线”的情形中(在“呈现”业务的情形中)，应该在原因头部中发送合适的值。

注释4：允许事件：如果用户B不具有CCNReg禁止，则呼叫完成，并且用值“用户未注册”/“用户不可用”等来填充原因头部。

注释5：在不同错误响应(并且不是404/480)的情形中，原因头部以及针对404响应情形所述的允许事件应该被填值。此外，发起AS应该相应地解释这些内容，并且发起针对CCNReg预约的动作。

注释6：下面的声明取自于上面提到的IETF草案，因为其可以应用于CCNReg服务，也可应用于第二种处理：“SUBSCRIBE请求可以包含接受头部字段。如果不存在这样的头部字段，则其具有“应用/呼叫完成”的默认值。如果该头部字段存在，则其必须包括“应用/呼叫完成””。

主叫用户和被叫用户属于(非IMS的)基于SIP的网络

在前面部分中针对IMS网络的CCNReg服务的描述可以容易地地修改以便使用在非IMS的基于SIP的网络中。

下面概括了主要步骤，并且对于类似于IMS网络的功能方面，提供对先前部分的参考。

(非IMS的)基于SIP的网络中的注册

注册服务器(或SIP注册服务器)接受SIP REGISTER请求。其可以与代理服务器或重定向服务器位于相同的位置。其向同一管理域内的其他SIP服务器提供关于注册的SIP用户代理(UA)的信息。如果用户代理打算接收呼叫，其必须注册到注册器。对于做出呼出呼叫，注册不是必需的。

在请求注释(RFC)2543中已经提到了针对注册的SIP子协议。通过向多播地址“sip.multicast.net”(224.0.1.75)发送请求，用户代理可以注册到本地SIP服务器。同一用户代理可以从不同的位置进行注册。也允许第三方注册。请求按照它们被接收的顺序来处理。

服务描述

将参考附图19到附图21来描述如何在任意的(非IMS的)基于SIP的网络中提供该服务的简化视图。

将由代理服务器来执行I-CSCF+S-CSCF+AS功能，除了对REGISTER消息的处理，由SIP注册服务器(或注册器)来处理REGISTER消息。IMS的HSS可以是SIP网络中的数据库，并且此类数据库与代理服务器(或注册器)之间的交互并未标准化(并且可以使用直径或任意其他协议)。

图19到图21绘出其中主叫方(用户A)和被叫方(用户B)属于非IMS的SIP网络的例子中的呼叫流程。用户A具有注册器RA以及代理服务器PSA。用户B具有注册器RB和代理服务器PSB。在呼叫流程开始时，用户B是“未注册”或“不可用的”。撤消注册的消息流程没有示出。

图19，步骤：

501)用户A的用户设备UE1向用户B发送INVITE消息。该消息由用户设备UE1的代理服务器PSA来接收。

502)代理服务器A将该INVITE消息向用户B的代理服务器PSB转发。在这里未示出用户B的注册器RB和用户B的代理服务器PSB之间的信息交换。

503)代理服务器PSB以404未找到消息向代理服务器PSA应答，该消息带有下面的内容：

-允许事件：呼叫完成。

-(可选地)原因头部＝“用户未注册”/“用户不可用”。

注释：在IMS网络情形下(早些描述过)针对原因头部和允许事件的相同评论也可应用于基于SIP的网络，例如，参见描述第二处理的前文部分的注释3-5以及一般性的重要评论。

下面的场景是其中提示用户A调用CCNReg服务的部分。

504)代理服务器PSA接着发起CCNReg过程以便监视用户B的状态。其向代理服务器PSB发送SUBSCRIBE消息，该消息带有下面的内容：

-事件：呼叫完成；

此外，如早些所述，可选地带有(也参见一般性的重要评论)：

-队列性质：CCNReg；

-队列操作：添加。

注释：可以使用呼叫完成事件包。新的队列类型“CCNReg”以及队列操作可以是可选的(也参见一般性的重要评论)，该新的队列类型“CCNReg”被用在针对呼叫完成事件包的所有SUBSCRIBE消息中。

505)代理服务器PSB检查该订阅是否可被接受(即，CCNReg预约是否可被允许)等，接着在成功的情形下，向代理服务器PSA发送200OK。

506)代理服务器PSB向代理服务器PSA发送带有下面内容的NOTIFY消息：

-事件：呼叫完成；

-订阅状态：活跃；

-队列性质：CCNReg；

-呼叫完成状态：排队。

在上述的NOTIFY消息中以及在针对呼叫完成事件包的所有NOTIFY消息中所述的队列性质是可选的(也参见一般性的重要评论)。

507)代理服务器PSA以200OK消息应答代理服务器PSB。现在将向用户A提供关于CCNReg已经成功预约的指示。

稍后，用户B注册回网络。在附图中未示出认证方面以及注册器如何向代理服务器通知该注册。注册消息将从用户B发送到注册器PSB。随后，代理服务器PSB将向代理服务器PSA通知CCNReg呼叫可以完成：

508)用户B的用户设备UE2向注册器RB发送REGISTER消息。

509)注册器RB以200OK消息向用户设备UE2应答。注册信息被传送到代理服务器B(这里未示出消息)。当用户B注册回网络时，可选地由代理服务器PSB启动空闲保护间隔定时器。仅在空闲保护间隔定时器到期时(并且用户B有空)，才向代理服务器PSA发送NOTIFY消息，指示用户B有空再呼叫。与空闲保护间隔定时器关联的动作是传统的并且不在这里描述。

510)代理服务器PSB向代理服务器A发送带有下面内容的NOTIFY消息：

-事件：呼叫完成；

-订阅状态：活跃；

-队列性质：CCNReg；

-呼叫完成状态：准备好呼叫完成。

-队列性质：CCNReg。

511)代理服务器PSA以200OK消息向代理服务器PSB应答。

512)由于用户B有空再呼叫，代理服务器A发起CCNReg呼叫完成过程。其向用户A的用户设备发送INVITE消息。定时器(T4)由代理服务器A启动，在该定时器内，用户A必须要对INVITE进行回复(发起节点再呼叫定时器)。

513)用户A的用户设备以200OK消息对用户B的设备应答。

514)用户A是可用的，因此通过从代理服务器PSA向代理服务器PSB发送INVITE消息来再呼叫用户B，该消息带有P-服务指示头部：“ccss”。

515)该INVITE由代理服务器PSB转发到用户B的用户设备。

516-518)用户B的用户设备经由代理服务器PSB和代理服务器PSA向用户A的用户设备发送180响铃消息。从用户B的队列移除用户A，并且也通知代理服务器PSA。

519)必须从用户A的队列释放用户B。代理服务器PSB向代理服务器A发送带有下面内容的NOTIFY消息：

-事件：呼叫完成；

-队列性质：CCNReg；

-订阅状态：终止；

-取消原因：服务完成。

注意，在该NOTIFY消息中，队列性质和取消原因是可选的(也参见一般性的重要评论)。

520)代理服务器PSA以200OK(NOTIFY)消息向代理服务器PSB应答。

521)接着代理服务器PSA向用户A的用户设备发送INVITE消息。这是带有用户B的SDP offer的针对用户A的Re-INVITE。随后建立A和B之间的实时传输协议路径，并且其他动作将类似于针对常规呼叫的动作。

主叫用户属于一个基于SIP的网络而被叫用户属于一个(非 IMS的)基于SIP的网络：详细的服务描述

用户A属于SIP网络1，并且用户B属于SIP网络2。当用户A(通过发送INVITE)向未注册的用户B发起通信尝试时，该INVITE将到达用户B的代理服务器PS2。代理服务器PS2将检查用户B的注册/可用性状态，以及其服务，例如CCNReg禁止(这可以通过访问外部数据库来确定)。当确定用户B未注册/不可用时，代理服务器PS2可以用404/480响应来做出响应。如在IMS网络的情形中，正确的原因头部(包含“用户未注册”/“用户不可用”以及允许事件头部(包含“呼叫完成”)应该被包括在此类的响应中。(注释：IMS网络情形中的针对原因头部和允许事件头部的相同评论也可应用于基于SIP的网络，例如，参见描述第二处理的先前部分的注释3-5以及一般性的重要评论)。

当该404/480响应到达用户A的代理服务器PS1时，其将接着执行类似于IMS网络的应用服务器AS1的类似动作，包括：确定用户A是否已经订阅CCNReg服务，启动相关定时器等；并且接着触发用户进行CCNReg预约确认。在接收到来自用户A的确认时(这里没描述如何发生的)，代理服务器PS1将执行与应用服务器AS1的动作类似的动作，包括：队列更新、启动/停止相关定时器等；以及接着发送SUBSCRIBE请求(如早些针对IMS网络所描述的带有CCNReg服务特定信息)，如应用服务器AS1所进行的那样。

带有CCNReg特定信息的SUBCRIBE消息(如早些所描述的那样)将到达代理服务器PS2，代理服务器PS2接着将执行与IMS网络的应用服务器AS2的动作对应的动作，包括：检查(SUBSCRIBE是否可以被接受)(参见下面的注释1)、启动相关定时器、队列动作以及随后发送NOTIFY以传达CCNReg特定信息，包括订阅状态，以及CCNReg请求已经被排队(如针对IMS网络所提到的关于服务保留指示的相同评论也可以应用于非IMS的基于SIP的网络)。在接收到带有CCNReg特定信息的NOTIFY时，代理服务器PS1将执行与应用服务器AS1的动作类似的动作(启动/停止相关定时器，通知用户A CCNReg已经被成功激活等)。

随后，当用户B注册/变得可用时，代理服务器PS2变得知道该情况，并且发送带有关于用户B准备好呼叫完成的指示的NOTIFY，并且执行与应用服务器AS2的动作类似的动作。当该NOTIFY消息到达代理服务器PS1时，其发起类似于应用服务器AS1的动作的呼叫完成动作，其中消息的内容非常类似于IMS情形中的消息的内容(例如，INVITE中的“ccss”指示)。代理服务器PS2也将扮演应用服务器AS2针对IMS网络情形所扮演的角色，并且呼叫将被成功地完成(并且对“呼叫完成”事件的订阅被成功地终止而其相关的资源被释放等)。

注释：

1.可不由PS2执行的唯一的重要动作是到用户B的注册状态的“SUBSCRIBE”(如在IMS网络中所做的)。SIP注册服务器(注册器)处理所有的REGISTER请求，并且如何将注册相关的信息提供给代理服务器在本发明的范围之外(应该使用当前的现有机制)。

2.对于(非IMS的)基于SIP的网络，涉及确定S-CSCF的查询(LIR/LIA，包括针对处理1的新AVP，以及针对处理2的触发HSS总是返回S-CSCF信息)是不相关的。这里不描述SIP代理与数据库、SIP注册器与SIP代理、SIP注册器与数据库之间的交互。

3.在“可用性”相关的服务的情形下，可能涉及呈现服务器/呈现代理，并且其可能必须被接触以便找出被叫用户的“呈现”相关的信息。

4.由用户A的代理服务器(PS1)执行的动作也可以由用户A的终端(用户代理)本身来执行。

5.下面的声明摘自上述的IETF草案，因为其也可以应用于CCNReg服务，对于(非IMS的)基于SIP的网络也可以应用：“SUBSCRIBE请求可以包含接受头部字段。如果不存在这样的头部字段，则其具有“应用/呼叫完成”的默认值”。如果存在该头部字段，则其必须包括“应用/呼叫完成”。

TCAP和SIP之间以及ISUP和SIP之间的交互

当被叫用户变得可用时，无论主叫用户是否是SIP/IMS/PSTN/PLMN用户，以及被叫用户是否是SIP/IMS/PLMN用户，对于主叫用户来说重要的是完成针对(临时)不可用的被叫用户的呼叫。此外，在涉及漫游的PLMN/IMS网络中，可能会频繁地出现(临时)不可用性，并且对于端用户来说高度期望在这种情形下完成呼叫。此类的域间(在PSTN/PLMN与SIP/IMS之间)通信将变得很普遍，因为若干运营商“演进”进入到NGN/IMS。

此外，存在众多基于呈现的指示，并且对于此类的用户可以提供各种呼叫完成服务。然而，如果例如当PSTN/PLMN用户是主叫用户并且他呼叫IMS/SIP用户时，此类的服务必须要提供给PSTN/PLMN用户，则必须在PSTN和VOIP之间定义合适的接口，就如针对CCBS/CCNR所做的那样(参见ETSI TISPAN草案TS 183042)。因此，本发明的另一个目的是解决该接口问题，并且随后当通信尝试也涉及VOIP/IMS用户时，甚至对PSTN/PLMN用户也提供端到端呼叫完成服务。特别地，其解决该服务的域间可用性(即，跨PSTN/PLMN和VOIP域)。其令CCNReg服务可以被提供给：

-做出到下面用户的通信尝试的PSTN/PLMN用户：

--当前未注册的SIP/IMS用户或如果被叫用户的“呈现”状态指示被叫用户不可用(图1)。

--PLMN用户，但仅当发起PSTN/PLMN和终止PLMN网络仅经由它们之间的IMS/SIP/VOIP网络来连接(图2)。

-IMS/VOIP/SIP用户，当此类用户做出到下面用户的通信尝试时：

--不在线/无法联系上/不可用/...的PLMN用户(图3)。

--IMS/VOIP/SIP用户，但仅当发起和终止IMS/SIP/VOIP网络仅经由它们之间的PSTN/PLMN连接(图4)。

为了能够实现上述，CCNReg服务调用(被叫用户的状态监视)以及其他队列操作在协议TCAP和SIP之间交互工作。换句话说，针对该服务在PSTN/PLMN中使用的协议是TCAP(事务处理能力应用部分)并且在IMS/SIP(VOIP域)中使用的协议是SIP。

从PSTN/PLMN中的用户到被叫用户的初始通信尝试(常规基本呼叫)可以通过7号信令系统来发送(信令协议是ISUP，ISUP是ISDN(综合业务数字网络)用户部分的缩写)，并且从SIP/IMS得到的错误响应(例如，404未找到)可以映射到ISUP，以便提供给主叫用户，其带有调用CCNReg服务可能性的指示。

随后，服务激活以及用户状态监视更新在PSTN/PLMN中通过TCAP发送，并且映射到SIP。这些映射可以通过IMS网络中的媒体网关控制器功能(MGCF)来执行，或一般地通过软交换来执行。

由AS、S-CSCF、HSS、I-CSCF针对PSTN/PLMN和IMS/SIP用户之间的呼叫所执行的动作与针对当呼叫是处于两个IMS/SIP用户之间的情形是相同的。对于前者，差异在于协议映射、由MGCF完成的动作、以及PSTN/PLMN。

从PSTN/PLMN发起的呼叫

在从PSTN/PLMN发起呼叫的情形中(图1-图2)，当主叫用户是IMS/SIP订户时，发起PSTN/PLMN交换机应该执行由发起应用服务器AS1所完成的动作.

注释：使用通用术语IMS/SIP订户，并且如果被叫用户是非IMS(基于SIP)网络中的SIP订户，则用户B(被叫用户)代理服务器将执行由应用服务器2(AS2)完成的所述动作。进一步，在这样的情形中(非IMS的SIP终止网络)，要由MGCF执行的动作通常将由SIP到PSTN/PLMN的网关来执行。

进一步，在下面的部分中，与前面部分所描述的CCNReg服务关联的各种定时器在这里也是可应用的。由前面部分中的发起应用服务器AS1处理的定时器现在将由发起PSTN/PLMN交换机来执行，并且由前面部分中的终止应用服务器AS2处理的定时器在这里也将由终止应用服务器AS2来处理。

图22到图25绘出从PSTN/PLMN中的用户A发起到IMS/VOIP网络中的未注册/不可用的用户B的示例呼叫流程图。

初始呼叫建立

在图22上，步骤：

301)当PSTN/PLMN用户A尝试与IMS/VOIP用户B通信时，发起PSTN/PLMN交换机发送IAM消息，其到达MGCF。

302)该IMA由MGCF映射到INVITE，并且朝IMS/VOIP网络发送该INVITE，即，MGCF向终止I-CSCF(即，用户B的归属网络的I-CSCF)发送该INVITE。

303)终止I-CSCF向HSS发送LIR。该LIR-Cx是用于获得用户B的S-CSCF的查询。

304)HSS在回送给终止I-CSCF的LIA中返回DIAMETER_ERROR_IDENTITY_NOT_REGISTERED指示。

305)终止I-CSCF向MGCF发送回404未找到响应，其带有下面的指示：

-允许事件：呼叫完成；并且可选地，

-原因头部＝“用户未注册”/“用户不可用”。

在用户“不可用”/“不在线”(“呈现”业务的情形中)的情形中，应该在原因头部中发送合适的值。注意，这里如果原因头部与上面所提供到的指示存在，则MGCF将执行如上所述的到REL消息的正确映射，否则，MGCF将基于允许事件：呼叫完成信息(也参见一般性的重要评论)来执行(到REL)的映射。

306)在接收到此类的错误响应时，MGCF将其映射到REL消息，其带有合适的起因值：‘A’(参见下面的注释2)以及包含“CCNReg可能”指示的诊断，并且经由发起PSTN/PLMN交换机将其发送到UE1。

307)UE1通过RLC消息对MGCF做出响应。

注释1：上面的步骤基于上面描述中解释的第一处理(参考图6到图16)。结合上面所描述的合适改变，第二处理可以被类似地实现。注释2：对于“未注册”和“不可用/不在线”，所使用的起因值可以不同(即，分别为起因A和起因B)。

开始服务保留过程(未绘出)

当接收到带有起因A/起因B的REL时，如果：

a)UE1已经订阅CCNReg服务，

b)以及通过检查REL消息中的起因参数的诊断中的CCNReg可能指示，UE2支持CCNReg。

c)以及用户A的CCNReg队列未满(队列大小可以是可由运营商规定的网络选项)，

则将由发起PSTN/PLMN交换机启动CCNReg服务保留过程。

接着发起PSTN/PLMN交换机启动CCNReg保留定时器T1，在该定时器期间，用户A可以激活CCNReg服务。如果上面条件(a)-(c)之一没有得到满足，则合适的通告将提供给用户A。

用户A的CCNReg激活(未绘出)

在启动了CCNReg保留定时器T1后，发起PSTN/PLMN交换机将发起向用户A播放的通知，并且在由用户A进行CCNReg激活确认后(通过带内交互过程)，在CCNReg保留定时器T1到期前，发起PSTN/PLMN交换机应该停止该定时器，并且将用户B添加到用户A的CCNReg队列。

发起针对用户B的状态监视

在图23上，步骤：

308)在接收到用户A的CCNReg激活确认后，发起PSTN/PLMN交换机(未示出)向用户B的终止网络发送TCAP消息TC-BEGIN(CCNReg请求调用)，该消息具有如在下面的协议映射部分内描述的内容。该消息在MGCF中接收。

309)MGCF将该TC-BEGIN(CCNReg请求调用)消息映射到SUBSCRIBE消息，如下面的协议映射部分所指出的那样。该SUBSCRIBE到达用户B的终止应用服务器AS2，类似于如上所述的常规CCNReg情形，具有在I-CSCF、HSS和S-CSCF中的中间步骤和动作。

310)I-CSCF向HSS发送LIR-Cx查询，以便获得用户B的S-CSCF，该查询包括有新的AVP，以便向HSS通知总是返回S-CSCF信息。

311)接着，HSS向I-CSCF发送带有S-CSCF信息的LIA-Cx响应。

312-313)接着，I-CSCF经由S-CSCF2向终止应用服务器AS2发送SUBSCRIBE，其带有在IMS/SIP网络呼叫中所发送的类似内容，即，事件：呼叫完成(以及“到期”头部中的非零值)，并且可选地带有队列特定的信息(也参见一般性的重要评论)(如针对IMS/SIP网络所描述的那样)，例如：

-队列性质：CCNReg；

-队列操作：添加。

在图24上，步骤：

314-316)响应于SUBSCRIBE消息，终止应用服务器AS2经由S-CSCF2以及I-CSCF向MGCF发送200OK。

317-318)接着，终止应用服务器AS2经由S-CSCF2向MGCF发送带有下面内容的NOTIFY：

-事件：呼叫完成；

-订阅状态：活跃；

-呼叫完成状态：排队。

此外，如早些所述，可选地带有(也参见一般性的重要评论)，下面的队列相关信息(如在IMS/SIP网络呼叫的情形中那样)：

-队列性质：CCNReg；

如在下面的协议映射部分所说明的那样。

评论：除了上面所提到的，如果支持如在draft-poetzl-bliss-call-completion-00(或其后来版本)中所述的(或针对例如PSTN/PLMN的其他呼叫完成服务，在PSTN/PLMN中当前支持的)服务保留选项，则NOTIFY消息应该也包含服务保留指示。该指示接着将被映射到如下所述的TCAP TC CONT消息中的合适指示(“支持保留”)。

319)该NOTIFY消息由MGCF映射到TCAP TC CONT(带有成功的结果代码)。该消息被发送到发起网络PSTN/PLMN，以向用户A指示用户B的状态监视已经被成功地发起。在接收到消息TCCONT(带有成功的结果代码)时，发起PSTN/PLMN交换机应该：

-停止定时器T2。

-启动针对用户A的CCNReg持续时间定时器T3.

-对用户A触发关于服务已经被成功调用的确认通告。

320)MGCF也负责经由S-CSCF2用合适的200OK向终止应用服务器AS2确认SUBSCRIBE/NOTIFY消息。

CCNReg呼叫完成过程

随后，当用户B变为注册的/可用的时，通知终止应用服务器AS2(步骤未绘出)(参见下面的注释1)

图25，步骤：

322-323)用户B的终止应用服务器AS2经由S-CSCF2向MGCF发送NOTIFY(参见下面的注释1)，其带有下面的内容：

-事件：呼叫完成；

-订阅状态：活跃；

-呼叫完成状态：准备好呼叫完成。

此外，如早些所述，可选地带有(也参见一般性的重要评论)，下面的队列相关信息(如IMS/SIP网络呼叫情形中那样)：

-队列性质：CCNReg；

如在下面的协议映射部分所说明地那样。

324)该消息NOTIFY由MGCF映射到TCAP消息TC CONT(远程用户有空)，并且接着朝PSTN/PLMN发送。在接收到TCAP消息TC CONT(远程用户有空)时，发起PSTN/PLMN交换机应该发起CCNReg再呼叫过程。

325-326)MGCF经由S-CSCF2向应用服务器AS2发送200OK。

注释1：对于当主叫用户和被叫用户都是IMS/SIP用户的情形(在前面部分描述过)，空闲保护间隔定时器处理过程是相同的。如果空闲保护间隔定时器由终止应用服务器AS2启动，则NOTIFY将仅在该定时器到期时(并且用户B是可用的)才发送。

到用户A的CCNReg再呼叫(未绘出)

通过发送合适的指示(响铃)，用户A被再呼叫并且CCNReg(发起节点)再呼叫定时器(T4)被启动。当用户A通过拿取电话来接受再呼叫时，发起PSTN/PLMN交换机发起要播放的通告，向用户A指示针对用户B的CCNReg呼叫正在完成。

图25，步骤：

327)随后(在完成了通告后)，将朝MGCF发送具有CCSS参数的消息IAM。

328)MGCF向I-CSCF发送INVITE。其包含类似于带有值“ccss”的P-服务指示头部的指示。

到用户B的呼叫完成(未绘出)

在(经由S-CSCF)从用户B接收到180响铃时，终止应用服务器AS2也将终止针对监视用户B的注册状态的订阅请求。这通过向MGCF发送带有下面内容的NOTIFY以及通过清除相应的队列条目和定时器来完成：

-事件：呼叫完成；

-订阅状态：终止；

-原因：没有资源；

-队列性质：CCNReg；(其是队列相关的)，以及

-取消原因：服务完成。

在接收到该(成功的)订阅取消后，MGCF发送针对NOTIFY的200OK，并且也将其映射到TC CONT(CCBS CANCEL)消息。来自用户B的180响铃(从S-CSCF接收)由MGCF映射到ACM/CPG消息，其被发送给PSTN/PLMN。这也将使得发起PSTN/PLMN交换机清除相应的队列条目，并且停止定时器T3。

稍后，当用户B摘机并且接受呼叫时，经由S-CSCF朝终止AS发送200OK(带有SDP)，并且将其朝MGCF传递。该200OK映射到ANM消息，其由MGCF朝PSTN/PLMN发送。

随后的动作类似于PSTN/PLMN用户和IMS/VOIP用户之间的基本呼叫流程。

在PLMN中的呼叫终止

在PLMN中的呼叫终止的情形中(图2-图3)，当被叫用户是IMS/SIP订户时，终止PLMN交换机应该执行由终止应用服务器AS2所执行的动作。对于其中主叫用户A属于IMS/基于SIP的网络而被叫用户B属于PLMN的情形，在图26到图33上绘出示例呼叫流程图。

进一步，在下面的部分中，前面部分(对于当主叫用户和被叫用户都是IMS/SIP用户时的情形)中所述的与CCNReg服务关联的各种定时器也可以在此应用。在前面部分中由发起应用服务器AS1处理的定时器现有也将由这里的发起应用服务器AS1处理，但在前面部分中由终止应用服务器AS2处理的定时器将由终止PLMN交换机来处理。

注释：使用通用术语IMS/SIP订户，并且如果主叫用户是非IMS(基于SIP的)网络中的SIP订户，则用户A的代理服务器(或用户A的终端本身)将执行所述的由应用服务器1(AS1)所完成的动作。进一步，在此类(非IMS的SIP发起网络)的情形中，由MGCF执行的动作将通常由SIP到PLMN的网关来执行。

假设：用户B不可用/联系不上。

初始呼叫建立

在图26上，步骤：

401-405)当IMS/VOIP用户A做出到PLMN用户B的通信尝试时，经由P-CSCF、S-CSCF1、发起应用服务器AS1以及S-CSCF1再次朝MGCF发送INVITE(注意可能在某些情况中，在INVITE处理中可能不涉及发起应用服务器AS1)。

406)MGCF将INVITE消息映射到IAM消息，并且接着将其朝终止PLMN交换机发送。

407)如果用户B不可用/联系不上，并且不具有CCNReg禁止，则终止PLMN交换机将REL(带有合适的起因值，即起因“B”以及诊断信息“CCNReg可能”)发送回MGCF。

在图27上，步骤：

408)MGCF通过RLC向终止PLMN交换机做出响应。

409)接着MGCF将带有上述内容的REL消息映射到“404未找到”或“480临时不可用”响应(或某个其他合适的错误响应)，其中原因头部指示“用户不可用”，并且允许事件头部包含“呼叫完成”(也参见用于解释原因头部的一般性的重要评论)。该“404未找到”或“408临时不可用响应”被发送到用户A的发起S-CSCF1。

410)在检查上述的404/480响应中的指示后，S-CSCF1将其转发到用户A的应用服务器AS1(即使在处理初始INVITE中不涉及用户A的应用服务器AS1，也是如此)。

在CCNReg预约确认后，AS(使用SUBSCRIBE)触发用户B的注册/可用性状态监视。

注释：可以使用呼叫完成事件包。新的队列类型“CCNReg”以及队列操作可以是可选的(也参见一般重要性详论)，该新的队列类型“CCNReg”被用在针对呼叫完成事件包的所有SUBSCRIBE消息中。

用户A的CCNReg激活

在接收到480临时不可用/404未找到(在附图上没有绘出)响应后，发起应用服务器AS1通过检查下面的内容来检查CCNReg对于用户A是否可能：

-用户A是否已经订阅到该服务(并且其是否已经被激活)。

-404响应中的原因头部是否指示“用户未注册”。

-CCNReg禁止是否是不可用的(允许事件头部包含呼叫完成)。

-用户A的CCNReg队列是否是不满的。

在确保满足上述的条件时，发起应用服务器AS1将启动CCNReg保留定时器(T1)，在该定时器到期前，用户A的CCNReg预约必须发生。发起应用服务器AS1也将经由S-CSCF1触发媒体服务器(在未绘出的媒体资源功能(MRF)中)，以便由媒体服务器向用户A播放通告，通知他/她CCNReg预约是可能的，并且提示用户A来执行预约。随后由MRF收集数字，并且(经由S-CSCF1)将其发送到发起应用服务器AS1。

在CCNReg预约确认后，用户A的应用服务器AS1触发用户B的注册/可用性状态监视(使用SUBSCRIBE)。对于当主叫用户和被叫用户都是SIP/IMS用户时的情形，步骤是相同的(如上所述)。

发起针对用户B的状态监视

在图28上，步骤：

414)在用户A的CCNReg激活后，发起应用服务器AS1向用户B的网络中的S-CSCF1发送SUBSCRIBE(队列-操作‘add’)，其带有内容：事件：呼叫完成和到期头部中的非零值。此外，下面的队列特定的信息(如在IMS/SIP网络呼叫的情形中一样)：

-队列性质：CCNReg；以及可选地，如早些所述，

-队列操作：添加。

注意，在该呼叫场景中，对于MGCF来说知道队列的“类型”是非常重要的，从而才能执行到正确的TCAP操作的映射。当然，该字段的精确格式以及值可能与上面所描述的不同。也参见一般性的重要评述。

下面的声明摘自上面提到的IETF草案，因为其也可以应用于从IMS/SIP网络到PLMN的呼叫：“SUBSCRIBE请求可以包含接受头部字段。如果不存在此类的头部字段，则其具有“应用/呼叫完成”的默认值”，如果该头部字段存在，则其必须包括“应用/呼叫完成”。

415)该SUBSCRIBE通过S-CSCF1转发到MGCF。

416-417)MGCF经由S-CSCF1向发起应用服务器AS1发送200OK。

418)MGCF将SUBSCRIBE映射到TCAP消息TC BEGIN(CCNReg请求调用)并且将后者发送到用户B的PLMN交换机。

419)在接收到该TC BEGIN时，用户B的PLMN交换机用TCCONT对MGCF做出响应(返回代码指示成功)，在发起监视用户B的状态的动作后，将用户A添加到用户B的CCNReg队列。

在图29上，步骤：

420-421)TC CONT消息由MGCF映射到NOTIFY，该NOTIFY经由S-CSCF1向发起应用服务器AS1发送，其内容是：

--事件：呼叫完成；

--订制状态：活跃；

--呼叫完成状态：排队

此外，如早些所述，可选地包含(也参见一般性的重要评论)下面的队列相关的信息(如在IMS/SIP网络呼叫的情形下一样)：

--队列性质：CCNReg；

如在下面的协议映射部分所述的那样。

评论：除了上面所提到的，如果支持在draft-poetzl-bliss-call-completion-00(或其后来版本)中所述的(或针对例如PSTN/PLMN的其他呼叫完成服务，在PSTN/PLMN中当前支持的)服务保留选项，则TCAP TC CONT消息中的“支持保留”指示被编码为“TRUE”，接着其应该被映射到NOTIFY消息中的服务保留指示(参见协议映射部分)。

422-423)发起应用服务器AS1也负责利用经由S-CSCF1向MGCF发送合适的200OK来确认SUBSCRIBE/NOTIFY消息。

用户A的应用服务器AS1(经由MRF)向用户A提供关于CCNReg被成功预约的通告(步骤未示出)。

CCNReg呼叫完成过程

424)当用户B变得可以再呼叫时，终止PLMN交换机朝MGCF发送TC CONT(远程用户有空)。

在图30上，步骤：

425-426)MGCF将其映射到NOTIFY消息并且将其经由S-CSCF1发送给应用服务器AS1，其带有下面的内容：

-事件：呼叫完成；

-订制状态：活跃；

-呼叫完成状态：准备好呼叫完成

此外，如早些所述，可选地带有(也参见一般性的重要评论)下面的队列相关的信息(如在IMS/SIP网络呼叫的情形下一样)：

-队列性质：CCNReg；

427-428)发起应用服务器AS1经由S-CSCF1向MGCF发送200OK。

429)在接收到该NOTIFY时，发起应用服务器AS1向用户A和用户B发起CCNReg再呼叫动作。例如，发起应用服务器AS1向S-CSCF1发送INTIVE。

随后的步骤与针对当用户B也是IMS/SIP用户情形所描述的步骤非常类似，不同仅在于MGCF必须将INVITE消息(带有具有值“ccss”的P服务指示头部)映射到带有CCSS参数的IAM消息。通过朝MGCF发送TC CONT(CCBS CANCEL)，PLMN也终止订阅。MGCF将它映射到针对发起AS的带有订阅状态为“终止”的NOTIFY。

根据本发明的方法使得CCNReg服务也可以提供给如下面的情形：

(a)主叫/被叫IMS/SIP网络通过PSTN/PLMN互连，

(b)主叫PSTN/PLMN网络通过IMS/SIP网络与被叫PLMN网络互连。

换句话说，该服务可以在当被叫用户是IMS/SIP/PLMN用户时提供给任何IMS/SIP/PSTN/PLMN主叫用户。

例如SUBSCRIBE消息的“队列性质”和“队列操作”的内容不必强制是如上定义的那样。重要的是应该有足够的信息传达到SUBSCRIBE消息的接收方(处理SUBSCRIBE的实体)，其中所述信息包括：

1.该SUBSCRIBE涉及呼叫完成服务；

2.CCNReg激活/去激活正被请求。可能，如果我们具有一个针对所有呼叫完成服务的队列，则通知正在请求呼叫完成激活/去激活(CCBS/CCNR/CCNReg/...)就足够了。

3.可选地，哪种类型的呼叫完成正在被提及(在针对不同的呼叫完成服务维持不同队列的情形中尤其需要)，也参见用于解释这将是需要的(并且不是可选的)情形的一般性的重要评论。

例如NOTIFY消息的“队列性质”和“队列操作”的内容不必强制如上定义的那样。重要的是有足够的信息传达到NOTIFY消息的接收方(处理NOTIFY的实体，即，发起SUBSCRIBE的实体)，其中所述信息包括：

1.该NOTIFY涉及呼叫完成服务；

2.呼叫完成请求的状态-请求是否已经被排队(并且被叫用户的可用性是未决的)，或请求是否可以被满足(即，对其发起呼叫完成请求的用户现在是否可以进行呼叫完成)。

3.可选地，哪种类型的呼叫完成正在被提及(对于针对不同呼叫完成服务维护不同队列的情形下尤其需要)，并且实际需要将其通知给它的主叫网络。如果该信息没有在NOTIFY消息中发送，则主叫网络仍可以使用其他手段来导出该信息(例如，通过分析已经到达的NOTIFY针对哪种事件订阅，并且哪种呼叫完成服务造成发送发起SUBSCRIBE消息)。

评论1：在一些情形下，由于主叫用户(被服务的用户)的不可用性，可能必须要“中止”订阅，并且随后当主叫用户再次变为可用时再次“重新开始”订阅。对于这种特殊的情形，可能需要向SUBSCRIBE的接收机发送指示。

评论2：可能的是，跟着的是如draft-poetzl-bliss-call-completion-00(或其后面版本)中所概述的处理。在那种情形中，可能不需要在SUBSCRIBE中发送规定“中止/重新开始”的队列操作，替代地，主叫用户的AS将简单地终止订阅，并且通过再次订阅呼叫完成事件包来重新开始。如果接着是这种处理，则针对可应用的TCAP操作的TCAP与SIP消息之间的映射应该被相应地修改。

协议映射

下面所描述的映射通常在MGCF处执行(或，一般地，在软交换处执行)。MGCF也应该负责与SUBSCRIBE-NOTIFY机制关联的常规操作，包括：

-在订阅定时器到期前刷新SUBSCRIBE请求，以及

-发送针对SUBSCRIBE/NOTIFY消息的合适的200OK。

注释1：在下面的所有SUBSCRIBE/NOTIFY消息中，事件包是“呼叫完成”，并且队列性质是“CCNReg”(如果“队列”特定的信息正被传输，也参见上面的一般性的重要评论)。如果IETFdraft-poetzl-sipping-call-completion-02(或其后来版本)被用作呼叫完成服务的基础，则(除了“队列性质”之外，还)提供“队列”相关的信息映射作为选项。如果IETFdraft-poetzl-bliss-call-completion-00(或其后来版本)被用作基础，则(除了“队列性质”之外)不需要“队列”相关的信息映射。

注释2：服务用户A或用户B的PSTN/PLMN节点应该实现/支持下面所列的TCAP操作(类似于CCBS/CCNR服务)，并且除了特征处理操作(例如，队列管理、定时器处理等，类似于在应用服务器处所执行的动作)以外，还支持针对ISUP所提到的改变。

针对在前向方向上发送的消息的TCAP<->SIP映射

对于从PSTN/PLMN到IMS/SIP用户的呼叫，应该从左向右读(针对前向方向消息的TCAP->SIP映射)。对于从IMS/SIP到PLMN用户的呼叫，下表应该从右向左读(针对前向方向消息的SIP->TCAP映射)。

TCAP消息	SIP消息
		TC BEGIN CCNRegREQUEST(调用)	在到期头部中带有非零值的SUBSCRIBE(参见下面的注释1)，可选地，另外带有：队列操作＝“添加”(参见一般性的重要评论)
-被叫方号码-支持保留-用户服务信息-主叫方号码-首要用户服务信息-接入传输	-在To头部中的SIP URL-“服务保留”参数-未映射-From头部/P声称ID头部-未映射-未映射
		TC CONT CCBSSUSPEND	具有到期头部＝0的SUBSCRIBE (或)SUBSCRIBE(队列操作＝“中止”)(参见注释3)
TC CONT CCBSRESUME	在到期头部中带有非零值的SUBSCRIBE(参见下面的注释1)(或)SUBSCRIBE(队列操作＝“重新开始”)(参见注释

	3)
		TC CONT CCBSCANCEL	SUBSCRIBE(“到期”头部＝0)
-支持保留	-服务保留参数
		-取消起因	-原因，并且可选地，取消原因参数(参见注释4)
TC END CCNRegREQUEST	SUBSCRIBE(“到期”头部＝0)

注释：

1.假如对应于用户A的条目已经不存在于用户B的队列中，则具有事件“呼叫完成“(参见上面映射表的注释1)以及具有非零的到期头部的SUBSCRIBE应该足以发起新的订阅(以监视用户B的状态)。如果一个条目已经存在于用户B的队列中，其将导致“重新开始”操作，即，重新开始订阅。

2.应用服务器2(AS2)应该能够在订阅“中止”、基于接收到的SUBSCRIBE的内容的订阅“取消/终止”、以及呼叫状态之间做出区分。

3.如早些所述，如果IETF draft-poetzl-bliss-call-completion-00(或其后来版本)被用作基础，则不需要“队列”相关的信息映射。如果IETF draft-poetzl-sipping-call-completion-02(或其后来版本)被用作呼叫完成服务的基础，则具有队列操作＝“中止”或“重新开始”的SUBSCRIBE将被映射。

4.如早些所述，如果IETF draft-poetzl-sipping-call-completion-02(或其后来版本)被用作呼叫完成服务的基础，则需要映射取消-原因。

进一步，在IETF draft-poetzl-bliss-call-completion-00中所定义的某些其他字段可以用在IETF draft-poetzl-sipping-call-completion-02中规定的不同命名的类似字段(传达相同的含义)来替代，例如“呼叫完成状态”可以用“队列状态”来替代。

5.注意，对于CCNR，新的TCAP操作仅是CCNReg REQUEST，其他与针对CCBS的操作是相同的。因此，事实上，如果不需要映射队列特定的信息，则对于CCBS/CCNR，如上所述的映射表中的若干个条目将是相同的。

针对在后向方向上发送的消息的SIP<->TCAP映射

对于从PSTN/PLMN到IMS/SIP用户的呼叫，下面的表应该从左往右读(针对后向方向消息的SIP->TCAP映射)。对于从IMS/SIP到PLMN用户的呼叫，应该从右向左读(针对后向方向消息的TCAP->SIP)。

SIP消息	TCAP消息
		NOTIFY(呼叫完成状态＝排队的)或NOTIFY(队列状态＝“请求被排队”)NOTIFY	TC CONT CCNReg REQUEST返回结果错误
-“服务保留”参数-“拒绝原因”参数值设置为“短期拒绝”(或)480临时不可用(参见下面的注释1)-“拒绝原因”参数值设置为“长期拒绝”(或)403禁止(参见下面的注释1)	-支持保留-短期拒绝-长期拒绝
		NOTIFY(呼叫完成状态＝准备好呼叫完成)(或)NOTIFY(队列状态＝“用户不能进行再呼叫”)(参见下面的注释2)	TC CONT REMOTE USER FREE

NOTIFY(“到期”头部＝0，订阅状态＝“终止”)	TC CONT CCBS CANCEL
		-服务保留参数	-支持保留
-取消原因参数(可选地)(参见下面的注释2)	-取消起因

注释：

1.如早些所述，如果IETF draft-poetzl-bliss-call-completion-00(或其后来版本)被用作基础，则TCAP中的长期拒绝和短期拒绝将分别映射到403禁止响应和480临时不可用。否则，如果使用IETFdraft-poetzl-sipping-call-completion-02(或其后来版本)，则TCAP中的长期拒绝和短期拒绝将映射到在拒绝原因参数中具有合适内容的NOTIFY。注意在TCAP TC CONT消息中的其他错误响应的情形中，其将被映射到SIP中的合适的4xx/5xx/6xx响应中。

2.如早些所述，如果IETF draft-poetzl-bliss-call-completion-00(或其后来版本)被用作基础，则不需要“队列”相关的信息映射。因此在该情形下，具有带有呼叫完成状态的SUBSCRIBE的第一NOTIFY将被映射到TCAP中的TC CONT REMOTE USER FREE。

3.如早些所述，如果IETF draft-poetzl-sipping-call-completion-02(或其后来版本)被用作呼叫完成服务的基础，则将需要映射取消原因。

4.注意，对于CCNR，用于CCNReg的新TCP操作仅是CCNRegREQUEST，其他与针对CCBS的操作是相同的。因此，事实上，如果不需要映射队列特定的信息，则对于CCBS/CCNR，如上所示的映射表中的若干个条目将是相同的。

针对在后向方向上发送的消息的SIP<->ISUP映射

对于从PSTN/PLMN到IMS/SIP用户的呼叫，下面的表应该从左往右读(针对后向方向消息的SIP->ISUP映射)。对于从IMS/SIP到PLMN用户的呼叫，应该从右向左读(针对后向方向消息的ISUP->SIP映射)。

SIP消息	ISUP消息
		404未找到/480临时不可用(参见注释1)	REL
-原因：SIP；起因＝A；文本＝“用户未注册”(参见注释4)-原因：SIP；起因＝B；文本＝“用户不可用”(参见注释4)-允许事件：呼叫完成-允许事件不存在	-起因A(参见注释2)-起因B(参见注释2)-诊断：CCNReg指示符值＝CCNReg可能(00000001)-诊断：CCNReg指示符值＝CCNReg不可能(00000002)(参见注释3)

注释：

1.根据服务(“未注册”/“不可用”/...)以及起因值，合适的SIP错误响应将被发送。

2.A和B的值可以是或者在ITU-T中所定义的新值，或是由运营商/管理当局所定义的国家起因值。替代于将“用户未注册”映射到起因A以及将“用户不可用”映射到起因B，另一个选项是将这些情形都映射到指示“用户不可用”的单个起因值。对于SIP 404未找到/480临时不可用之间的映射，请参见ITU-T Q.1912.5-会话发起协议(SIP)和与承载无关的呼叫控制协议或ISDN用户部分之间的交互，表21(第6.11.2段)。

实施此的另一个选项是：如果诊断不随起因A/B一起被包括，则可以假设CCNReg是不可能的。换句话说，仅允许事件头部中的呼叫完成的出现可能需要被映射到ISUP。

如果原因头部不存在(也参见一般性的重要评论)，则映射将仅基于“允许事件：呼叫完成”。

针对在前向方向发送的消息的ISUP<->SIP映射

对于从PSTN/PLMN到IMS/SIP用户的呼叫，下面的表应该从左向右读(针对前向方向消息的ISUP->SIP映射)。对于从IMS/SIP到PLMN用户的呼叫，应该从右向左读(针对前向方向消息的SIP->ISUP映射)。

ISUP消息	SIP消息
		IAM	INVITE
-CCSS	-P服务指示＝“ccss”

注意：如果决定对于CCNReg服务在SIP中的P服务指示头部中实现不同值，则其必须映射到新的参数/参数值(而不是“ccss”)。

(协议)标准方面

此外，如果下述方面被标准化(在现在已经可以获得的标准之上)，则所建议的解决方案可以在跨运营商/厂商的IMS/NGN网络上实现/提供而没有任何互操作性问题。

-如前面部分所说明的在TCAP和SIP之间以及ISUP和SIP之间的映射(第4部分：协议映射)

-对TCAP和ISUP的下列更新：

TCAP

工作的基本原理十分类似于如在ITU-T Q.733.3/Q.733.5中所定义的CCBS/CCNR服务，包括常规操作、定时器、异常情形等。需要支持下面的新的操作：

1.CCNRegREQUEST(TC BEGIN)

这需要从发端端局进行发送。该动作恰好与针对CCNR/CCBSREQUEST的动作相同。

2.CCNRegREQUEST(TC CONT)

这需要被发送到发端端局。响应可以提供返回结果或错误(类似于CCBS/CCNR)。

3.CCNRegREQUEST(TC END)

这可以从发端端局发送，以终止CCNReg过程。

ISUP

除了在ITU-T Q.850中所定义的之外，所需的更新还在REL消息中的起因参数中。

1.起因值

两个新的起因值，即，A和B需要被支持，以便指示情形“被叫用户未注册”以及“被叫用户不可用”。

2.诊断

对于起因A和B，诊断子字段应该存在，并且应该被如下编码：

位H-A：
		00000000000000010000001000000011到0111111110000000到1111111011111111	未使用(备用)CCNReg可能CCNReg不可能备用(未使用)备用，以供国家使用预留用于扩展

注释：如果决定对于CCNReg服务在SIP中的P服务指示头部中实现不同值(而不是使用“ccss”)，则其必须映射到新的参数/参数值。

如果诊断没有随起因A/B一起被包括，则可以假设CCNReg是不可能的(如果是这种情形，则可能根本不需要针对诊断子字段的值00000010(“CCNReg不可能”))。利用这些协议改变，所建议的服务可以被扩展到纯PLMN域(PLMN->PLMN呼叫)，以及针对从PSTN->PLMN的呼叫，针对其中被叫用户不能联系上、关机等情形。

关于传统IMS网络的过程改变

在下面部分中描述的改变是在IMS网络中的典型影响。当然，对于网元中的影响，具体的实现可能具有多种变形，-例如规定由应用服务器执行的一些动作可以在S-CSCF中进行处理。利用在早些部分中提供的关于基于非IMS SIP网络的背景，在下面部分中的影响描述可以被扩展到此类非IMS的基于SIP的网络。

在(用户B的)HSS处的动作

-如果采用第一处理，支持LIR中的新的AVP。在从I-CSCF接收到该(新的)AVP时，应该在LIA中返回S-CSCF能力，而不是返回DIAMETER_ERROR_IDENTITY_NOT_REGISTERED。

-如果采用第二处理，则响应于来自I-CSCF的LIR，总是在LIA中提供S-CSCF能力，而不是在LIA中返回DIAMETER_ERROR_IDENTITY_NOT_REGISTERED。

-另外，如果选择第二处理，并且定义新的AVP来指示请求的类型(INVITE、SUBSCRIBE等)，则HSS可以检查该AVP，并且仅针对由于INVITE触发的LIR返回S-CSCF能力。

在进入的I-CSCF处的动作

如果采用第一处理，则进入的I-CSCF(对应于用户B的网络的I-CSCF)I-CSCF2必须执行下述内容：

-当从HSS接收到带有错误DIAMETER_ERROR_IDENTITY_NOT_REGISTERED的LIA时，将下面的内容包括在发送回发起S-CSCF的404未找到响应中：

-原因头部：”用户未注册”；

-允许事件：呼叫完成。

注释：对于纯IMS/SIP网络呼叫(即，主叫用户和被叫用户属于IMS/SIP网络，且在它们之间不涉及任何PSTN/PLMN)，404响应中的原因头部不是强制的，但当与PSTN/PLMN交互时其可能是必需的。

-检查接收到的SUBSCRIBE请求以查看其是否是针对CCNReg服务的。这可以通过检查SUBSCRIBE消息的内容以查看其是否包含下述内容来实现：

--事件：呼叫完成。

此外，如在早些部分中所解释的，可选地包含(也参见一般性的重要评论)：

-队列操作：添加；

-队列性质：CCNReg。

-如果如上所解释的，终止I-CSCF、I-CSCF2接收到针对CCNReg服务的SUBSCRIBE，该终止I-CSCF2必须发送带有新的AVP的LIR。

在发起应用服务器AS1处的动作：

CCNReg允许

通过检查用户A是否已经订阅CCNReg服务(即，该服务对于用户A是否是活跃的)，发起应用服务器AS1检查对于主叫用户(用户A)而言，CCNReg是否被允许。

启动服务保留过程

当接收到404未找到(参见下面的注释2)响应时，如果下述条件满足则CCNReg服务过程保留过程将被启动：

a)用户A已经订阅CCNReg服务，以及

b)通过检查404未找到响应(参见下面的注释，用户不可用或针对存在性服务的其他原因)中的允许事件：呼叫完成(以及在可应用的情况下，检查原因头部＝用户未注册，)，用户B支持CCNReg，以及

c)如果用户A的CCNReg队列未满(队列大小可以是网络选项，由运营商规定)。

发起AS接着启动CCNReg保留定时器T1，在该定时器T1期间，用户A可以激活CCNReg服务。

注释1：在上述条件(a)-(c)之一未满足的情形中，将向用户A提供合适的通告(由MRF播放)。

注释2：如果选择处理2或在一些实现中，可以发送480临时不可用响应，以替代404未找到响应。最重要的方面是允许事件指示，并且可选地，是原因头部(参见一般性的重要评论)。

用户A的CCNReg激活

在启动了CCNReg保留定时器T1后，发起AS1将使用S-CSCF1和媒体服务器(在MRF内)来发起向用户A播放的通告，指示CCNReg可以被激活。随后，在用户A的激活确认后(通过带内交互过程实现)，媒体服务器(经由S-CSCF1)向AS1提供信息。

服务保留过程的完成

当在CCNReg保留定时器T1到期前接收到CCNReg激活确认的情况下，发起AS1应该停止该定时器，并且将用户B添加到用户A的CCNReg队列。

向终止AS发送CCNReg请求

发送SUBSCRIBE

在接收到来自用户A的确认后，发起应用服务器AS1应该：

a)朝终止AS1发起SUBSCRIBE消息(经由发起S-CSCF1和终止S-CSCF2)。该SUBSCRIBE应该包含下面的信息：

-事件：呼叫完成；

此外，如早些部分所解释的，可选地包含(也参见一般性的重要评论)：

-队列性质：CCNReg；

-队列操作：添加。

b)启动CCNReg请求操作定时器(T2)。

c)在接收到带有SUBSCRIBE到期指示的200OK时，存储该信息，并且在该到续时间期持之前负责周期性地更新该SUBSCRIBE请求。

第一NOTIFY的接收

在从终止AS2接收到第一NOTIFY后(参见下面的注释)(并且发送针对NOTIFY的200OK)，则发起AS1应该：

a)停止定时器T2。

b)启动针对用户A的CCNReg持续时间定时器(T3)。

c)向用户A触发关于该服务已经被成功调用的确认通告。该通告在S-CSCF的帮助下以及接着在播放该通告的媒体服务器(MRF)的帮助下发起。

注释：NOTIFY消息应该包含下面的信息：

-事件：呼叫完成；

-订阅状态：活跃；

-呼叫完成＝排队

此外，如早些所述，可选地包含(也参见一般性的重要评论)下面的队列相关的信息：

-队列性质：CCNReg；

CCNReg呼叫完成过程

在接收到带有下面指示的NOTIFY(即，指示用户B已经注册，并且有空被用户A“再呼叫”)：

-事件：呼叫完成；

-订阅状态：活跃；

-呼叫完成状态＝准备好呼叫完成

此外，如早些所述，可选地带有(也参见一般性的重要评论)下面的队列相关的信息：

-队列性质：CCNReg；

发起应用服务器AS1应该以200OK对NOTIFY做出响应。现在用户A可以被再呼叫。

对用户A的CCNReg再呼叫

在(经由NOTIFY消息)接收到关于用户B已经注册的信息，并且“准备好呼叫完成”后，通过经由S-CSCF发送INVITE(没有SDP)，该发起AS对用户A进行再呼叫，并且启动CCNReg(发起节点)再呼叫定时器(T4)。在从用户A(经由S-CSCF)接收到200OK(带有SDP Offer)(当用户A通过拿起电话来接受再呼叫时)时，应用服务器AS1发起通告，该通告将被播放给用户A以指示CCNReg呼叫正在完成，并且他/她将连接到用户B。该通告通过(经由S-CSCF1)联系MRF来触发。

随后(在完成通告后)，从发起AS1朝用户B发送(经由S-CSCF1、S-CSCF2以及终止AS2)INVITE。该INVITE没有SDP，并且包含了类似于带有值“ccss”的P服务指示头部的指示。

针对用户B的呼叫完成

在(经由S-CSCF)接收到来自用户B的180响铃时，终止应用服务器AS2也将终止针对监视用户B的注册状态的订阅请求。这通过朝发起应用服务器AS1发送带有下面内容的NOTIFY来完成(经由S-CSCF1、S-CSCF2)：

-事件＝呼叫完成；

-订阅状态：终止；

-原因：没有资源；

此外，如早些所述，可选地带有(也参见一般性的重要评论)下面的信息：

-队列性质：CCNReg；(其是队列相关的)，以及

-取消原因：服务完成。

在接收到该(成功的)订阅取消时，发起AS1将停止定时器T3(并且发送针对NOTIFY的200OK)。随后，终止AS1(经由S-CSCF1、S-CSCF2)向发起AS2发送180响铃。这使得发起AS也清除相应的队列条目。

稍后，当用户B摘机并且接受呼叫时，经由S-CSCF朝终止AS2发送的200OK(带有SDP)将被传递给发起AS。发起AS1接着朝用户A发起带有B的SDP的Re-INVITE，并且在(经由S-CSCF)从用户A接收到200OK后，直接向用户B发送(带有A的SDP的)ACK。

随后，发起AS1也将释放针对MRF的呼叫(该MRF被建立以便向用户A播放CCNReg呼叫连接通告)。

注释：现实场景中的呼叫流程可能有些轻微变化，例如，可能首先接收183会话进度而非180响铃。重要的是CCNReg呼叫被成功地完成，并且为了发生该呼叫完成而分配给状态监视的所有相关的资源被成功地清除/释放。

CCNReg去激活

这将通过发送带有下面的内容的SUBSCRIBE消息来生成：

-到期＝0.

随后，(为了完成到用户B的呼叫)涉及该针对用户A的特定条目的所有CCNReg资源。

用户A请求的去激活

在接收到来自用户A(主叫用户)的去激活请求时，将由发起AS1朝终止AS2(经由S-CSCF1、S-CSCF2)发送带有下面内容的SUBSCRIBE：

-事件＝呼叫完成；

-到期＝0；

-队列性质＝CCNReg。

使用媒体服务器和S-CSCF1向用户A播放去激活确认通告。随后，(为了完成到用户B的呼叫)涉及该针对用户A的特定条目的所有CCNReg资源。

由定时器到期所引起的去激活

动作将类似于前面部分(用户A请求的去激活)。

在进入S-CSCF(终止S-CSCF2)处的动作

一般性评论：与终止S-CSCF2以及终止应用服务器AS2之间的SUBSCRIBE-NOTIFY关联以便使用“reg”事件包来监视用户B的注册状态的动作在此不详细地进行描述。

发送404未找到

如果选择第二处理，则对于每次呼叫，在接收INVITE期间，终止S-CSCF2将是活跃的。如果初始INVITE没有被转发到终止AS，则用户B的S-CSCF2将不得不执行下面的动作：在检查用户B的配置简档以便确保用户B不具有CCNReg禁止时，404未找到响应应该包括：

-原因头部：用户未注册/用户不可用；(参见下面的注释2)

-允许事件：呼叫完成

注释：

1.在一些实现中，当跟着的是第二处理时，可以发送480临时不可用响应来替代404未找到响应。在该情形下，对于上面所列出的允许事件和原因头部的更新应该在480响应中而非404响应中支持。

对于纯IMS/SIP网络呼叫(即，主叫用户和被叫用户属于IMS/SIP网络，且在它们之间不涉及任何的PSTN/PLMN)，404/480响应中的原因头部不是强制的，但当与PSTN/PLMN交互时其可能是必需的。

用户B的配置简档中的CCNReg允许

如果选择第一处理，则在接收到针对CCNReg服务的带有下面内容的SUBSCRIBE时，终止S-CSCF2将必须检查针对用户B的CCNReg允许。同样通过新的事件包来驱使(不是由初始过滤器准则IFC来触发)，当接收到带有下面内容的SUBSCRIBE时，应用服务器将被调用：

-事件：呼叫完成；

以及此外，如早些所述，可选地带有(也参见一般性的重要评论)下面的信息：

-队列性质：CCNReg。

如果用户B不具有CCNReg禁止，它必须将SUBSCRIBE转发到终止AS2。否则，可以由S-CSCF2向应用服务器1(AS1)发送403禁止响应，这是“长期拒绝”的情形。作为对发送403响应的替代，可以由终止S-CSCF2向发起S-CSCF1(在发送针对SUBSCRIBE的200OK后)回送拒绝订阅请求的NOTIFY，其接着被发起S-CSCF1发送给发起应用服务器AS1。该NOTIFY消息应该包含下面的内容：

-事件：呼叫完成；

-订阅状态：终止；

-原因：拒绝；

此外，如早些所述，可选地包含(也参见一般性的重要评论)下面的信息：

-队列性质：CCNReg；

-拒绝原因：长期拒绝。

在由于SUBSCRIBE不能被接受的一些临时故障条件的情形中，S-CSCF2应该向应用服务器1(AS1)发送480临时不可用响应。在某个一般错误的情形中(例如，如上所述的CCNReg禁止)，终止S-CSCF2应该向应用服务器1(AS1)发送403禁止响应。可替换地，在(用2xx响应)确认SUBSCRIBE请求后，可以由终止S-CSCF2向应用服务器1(AS1)发送规定订阅被“终止”等的合适NOTIFY，(其可选地带有“拒绝原因”)。

注释：替代于S-CSCF，终止AS也可以在处理1以及处理2中检查用户B的配置简档(针对CCNReg禁止)，并且在这样的情形中，接收到的请求(INVITE/SUBSCRIBE)将简单地由S-CSCF转发给AS，而不需要执行任何检查。

向终止AS通知用户B的注册

注册消息(REGISTER)从用户发送到P_CSCF。这将转发到I_CSCF。I_CSCF向HSS发送UAR，HSS以UAA进行答复。UAA将包含S_CSCF，该S_CSCF是由HSS在第一处理中的SUBSCRIBE处理或在第二处理中的INVITE处理期间分配的。

I-CSCF将REGISTER消息转发到S_CSCF。其又接着被转发到(终止)AS(特定于针对“通告者”的“reg”事件包的动作由终止S-CSCF2来执行)。

在终止AS(AS2)处的动作

发送404未找到

如果选择第二处理，则对于每个呼叫，在接收INVITE期间，终止S-CSCF和终止AS将是活跃的。如果初始INVITE被转发到终止AS，则其必须如下进行：在检查用户B的配置简档以确保用户B不具有CCNReg禁止后，404未找到响应应该包括：

-原因报头：用户未注册/用户不可用；(参见下面的注释2)

-允许事件：呼叫完成

注释：

1.在一些实现中，当跟着的是第二处理2时，可以发送480临时不可用响应来替代404未找到响应。在该情形下，对于上面所列出的允许事件和原因头部的更新应该在480临时不可用中而非404未找到中支持。

2.对于纯IMS/SIP网络呼叫(即，主叫用户和被叫用户属于IMS/SIP网络，且在它们之间不涉及任何PSTN/PLMN)，404/480响应中的原因头部不是强制的，但当与PSTN/PLMN交互时其可能是必需的。

SUBSCRIBE的接收

在接收到针对监视用户B的注册状态的SUBSCRIBE时，终止AS应该发送带有订阅持续期间(到期)的200OK。

如果订阅请求可以被接受(即，用户B不具有CCNReg禁止，在该情形下，订阅将被“终止”)，并且用户B的CCNReg队列也不满，则应该(经由S-CSCF)向发起AS发送带有下面内容的NOTIFY：

-事件：呼叫完成；

-订阅状态：活跃；

-呼叫完成状态＝排队

-队列性质：CCNReg；

评论：除了上面所提到的内容之外，如果还支持如在draft-poetzl-bliss-call-completion-00(或其后来版本)中所述的(或针对例如PSTN/PLMN的其他呼叫完成服务，在PSTN/PLMN中当前支持的)服务保留选项，则NOTIFY消息应该也包含服务保留指示。

终止AS也启动CCNReg服务持续时间定时器T7(针对用户B)。用户A应该被添加到用户B的CCNReg队列(对于NOTIFY的200OK也应该被成功地处理)。

在由于SUBSCRIBE不能被接受的一些临时故障条件的情形中，例如用户B的呼叫完成队列是满的，则应用服务器2(AS2)应该向应用服务器1(AS1)发送480临时不可用响应。在某个一般错误的情形中(例如，如上讨论的CCNReg禁止)，应用服务器2(AS2)应该向应用服务器1(AS1)发送403禁止响应。可替换地，在(利用2xx响应)确认SUBSCRIBE请求后，可以由应用服务器2(AS2)向应用服务器1(AS1)发送规定订阅被“终止”等的合适NOTIFY(可选地伴有“拒绝原因”)。

监视用户B的注册状态

终止AS应该监视用户B的注册状态(经由从S-CSCF接收到的信息来更新)，并且应该在SUBSCRIBE持续时间到期前对任何SUBSCRIBE刷新尝试进行响应。

空闲保护间隔定时器处理

当针对其已经调用了CCNReg服务的用户(用户B)再次注册时，(终止)S-CSCF(S-CSCF2)向(终止)AS通告该事件(即，在成功注册后)。在接收到REGISTER后，S-CSCF将向AS发送第三方REGISTER。当终止AS接收到第三方REGISTER请求时，其可以SUBSCRIBE(订阅)“reg”事件包：基本机制在IETF RFC 3680以及3GPP TS 24.229中描述(章节“公共应用服务器(AS)过程”)。在了解到用户B已经成功注册后(如上所述)，则启动CCNReg空闲保护间隔定时器(T8)(参见下面的注释1)。在该“空闲保护间隔”时间段期间，将仅允许用户B(其恰好已注册)做出呼出呼叫，而所有进入的呼叫将碰到“忙”指示(参见下面的注释2)。

在定时器T8到期时，终止AS向发起AS发送带有下面内容的NOTIFY(参见下面的注释3)：

-事件＝呼叫完成；

-订阅状态：活跃；

-呼叫完成状态＝准备好呼叫完成

此外，如早些所述，可选地(也参见一般性的重要评论)带有下面的队列相关的信息：

-队列性质：CCNReg。

其也将启动(CCNReg目的地节点)再呼叫定时器(T9)。

注释：

1.其变形是允许用户B在空闲保护间隔时间段期间接收进入的呼叫(如果他有空)(即，空闲保护间隔定时器可以是可由运营商配置的值)。

2.该“忙”指示可以导致与CCBS服务的交互。

3.上述的NOTIFY被发送到用户B的CCNReg队列中的第一条目。

针对用户B的呼叫完成

在完成向用户A播放通告(CCNReg呼叫正在完成)后，发起AS(经由S-CSCF)向终止AS发送(没有SDP的)INVITE，其带有包含值“ccss”的P服务指示头部(参见注释2)。在接收到该INVITE时，终止AS经由S-CSCF2朝被叫用户(用户B)发送该INVITE(P服务指示头部可以被S-CSCF2移除)。随后，在接收到来自用户B的180响铃时，终止AS应该取消定时器T9和T7，并且释放与该CCNReg请求关联的资源，包括相应的队列条目。

在(经由终止S-CSCF(S-CSCF2))接收到来自用户B的180响铃时，终止AS(经由这2个S-CSCF)向发起AS发送180响铃。

随后，终止AS也将终止针对监视用户B的注册状态的订阅请求。这可以通过(经由2S-CSCF)朝发起AS发送带有下面内容的NOTIFY来完成。

-事件＝呼叫完成；

-订阅状态：终止；

-原因：没有资源；

-队列性质：CCNReg；(其是队列相关的)，以及

-取消原因：服务完成。

稍后，当用户B摘机并且接受呼叫时，经由S-CSCF朝终止AS发送(带有SDP的)200OK。其接着被传递给发起应用服务器AS1。

注释：

1.针对200OK的ACK(带有A的SDP)由发起AS直接发送到用户B而不涉及终止AS。

2.新的令牌，即“ccnreg”也将被使用，以替代现有的“ccss”。

相对于现实场景中的呼叫流程可能有些轻微变化，例如，可能首先接收来自用户B的183会话进度而非180响铃。重要的是CCNReg呼叫被成功地完成，并且为了发生该呼叫完成而分配给状态监视等的所有相关的资源被成功地清除/释放。

在MGCF处的动作

注释：仅当该服务跨PSTN/PLMN网络提供时，才需要对MGCF的更新。MGCF应该提供如在“TCAP和SIP之间以及ISUP和SIP之间的交互”的章节中所述的映射功能。

服务交互

可能存在CCNReg服务与其他服务的交互，它们中的一些例子给出如下：

排队处理优先级

如果使用不同的队列来实现不同的呼叫完成服务，并且另一个用户C在下面的期间预约针对用户B(其已经刚刚注册回来，并且用户A具有对用户B的CCNReg预约)的CCBS请求：

·(CCNReg)空闲保护间隔定时器运行

·CCNReg再呼叫过程

·...

则必须确定哪个队列将具有优先级(CCNRge/CCBS)。可以使其成为可规定的，从而运营商将有可能确定其网络的优先级。

用户A以具有CCNReg和CCBS预约而结束

假设用户A具有对用户B的CCNReg预约。用户B随后注册回来，但：

·在空闲保护间隔期间/再呼叫过程/...期间变为忙

·当用户B处于与另一个用户的谈话时(在CCNReg服务完成前)，用户A发起另一个呼叫尝试。

上述将导致这样的情形，其中用户A对于相同的用户B将具有CCNReg和CCBS预约二者。在此类的场景中，有2种可能性：

1.如果两个呼叫尝试的属性是相同的(相同的媒体、相同的主叫方/被叫方身份等)：

网络有2种方式来处理这种情况，->这2种服务预约(CCNReg/CCBS)被视为：

·2个不同的预约：根据CCNReg的过程和CCBS的过程，每个(CCNReg/CCBS)将被分别地单独处理。

·单个预约：无论哪个再呼叫(CCNReg/CCBS)首先获得完成(参见针对处理优先级的先前部分)，其将导致从它们相应的队列清除这两个条目。

2.如果两个呼叫尝试的属性是不同的：

这2个服务预约(CCNReg/CCBS)被视为2个不同的预约，并且根据CCNReg的过程和CCBS的过程，将分别地单独处理每个(CCNReg/CCBS)。

扩展/增强

基于呈现的呼叫完成

上述的过程可以被容易地扩展用于基于用户可用性/呈现的呼叫完成。仅有的主要更新将是对于“不在线”(但已注册的)的用户，S-CSCF和应用服务器AS将已经是活跃的。此外，SUBSCRIBE/NOTIFY内容可能需要一些改变，并且可能需要管理不同的队列。

选择性的呼叫完成

用户B可以提供关于未决队列条目的通告/指示，并且他接着可以确定仅接受针对“所选择的”用户的再呼叫尝试。

针对所有呼叫完成服务(CCBS、CCNR、CCNReg，...)的同一队列

为了解决跨不同呼叫完成服务的优先级问题，单个队列可以用于AS内的所有呼叫完成服务(不影响到协议消息内容)。

作为终止服务的CCNReg

在上面的描述中，已经将CCNReg讨论为发起服务，即，提供给主叫用户的服务。也可以将该概念扩展到令该服务对于用户B来说可用，即，用户B将能够激活该服务(例如，在变得“不可用”前)，并且接着在不可用期间对他的任意呼叫尝试将被存储在队列中，以及一旦用户B变为“可用/注册”，则此类的尝试将通过网络自动地完成。作为另外的步骤，此类的CCNReg终止服务可以提供为“选择性的”，即，类似于上面的选择性的呼叫完成。

标准相关的修改

重要的评论：

在撰写该文档时，IETF草案draft-poetzl-bliss-call-completion-00，IETF draft-poetzl-sipping-call-completion-02、ETSI TISPAN草案TS183042V.0.0.18被用作参考。

所建议的修改本身是暗含的，并且可能存在对此处建议的方案的某些改变。例如，以下是可能的：

(a)新的“队列性质”可以不必在NOTIFY中发送(因为稍后可以确定下述情况：(a)字段“队列性质”可以根本就不存在，并且留给受影响的网元来正确地实现队列，或(b)不同的字段将被用于携带关于呼叫完成的“类型”的信息，例如CCBS、CCNR、CCNReg等)，

(b)不同的名称被用于不同的队列相关字段，但传达类似的信息，例如，在IETF draft-poetzl-sipping-call-completion-02中定义的“队列状态”可用于替代“呼叫完成状态”。

事件包：可以使用如在“IETF草案draft-poetzl-bliss-call-completion-00：Extension to the Session InitiationProtocol(SIP)for the support of the Call Completion Services forETSI”中定义的呼叫完成事件包。(如果不是，则可以基于其中所建议的内容来标准化针对该服务所需的方面)。在其之上仅需要下面的更新/添加：

404未找到中的允许事件

“允许事件”头部字段将被包括在针对INVITE的404响应中。该头部字段应该被如下编码在针对INVITE的404响应中：

“允许事件：呼叫完成”

注释：

1.可能存在已经支持的其他指示，上面所提供到的仅仅是附加方面。

2.可能还要求支持上述针对480临时不可用响应中的允许事件头部的更新(更多信息参见前面部分)。

404未找到中的原因头部

404响应中的用于指示用户当前未注册的新原因代码：

原因：SIP；起因＝404；文本＝“用户未注册“

原因：SIP；起因＝404；文本＝“用户不可用“(对于呈现这种情况，如需要的话可以添加更多的文本类型，并且SIP错误响应还可以是480临时不可用而非404未找到)。

这样，结合允许事件头部将使得主叫侧能够确定这是CCNReg情形，并且可以完成CCNReg预约。如上所述的404响应中的原因头部对于仅涉及IMS/SIP网络的呼叫来说是可选地，但对于与PSTN/PLMN的交互可能是必要的(取决于标准/实现的实际结果)。

注释：可能也需要支持针对480临时不可用响应中的原因头部的上述更新(更多信息参见前面的部分)。

P服务指示头部

如对于CCBS，针对CCNReg服务，这可用于向由UAS的包含该头部的进入请求给出高于不具有该头部的其他进入请求的优先级。

存在2个选项：新的令牌，即，“CCNReg”可以被定义，或者，现有的服务请求“ccss”也可以被用于指示CCNReg呼叫。

注释：如果基于draft-poetzl-sipping-call-completion-02(或其后来版本)标准化呼叫完成服务，则对于CCNReg，在其之上将需要下面的涉及队列处理的方面：

队列性质：

队列性质＝CCNReg(新的队列类型)。

(CCNReg指示其是针对CCNReg队列的请求)。

DIAMETER

可以在从I-CSCF朝HSS的LIR中定义新的AVP，如果该AVP存在，则请求HSS总是返回S-CSCF能力/S-CSCF身份。下表基于[10]。

可替代地，可以在支持的特征AVP中定义新的AVP值，以便指示“CCNReg”特征，并且接着在接收到LIR中的该AVP值时，HSS可以返回S-CSCF能力。

注释：如果跟着的是第二处理，则作为增强，可以引入新的AVP以指示请求类型(例如，INVITE)，从而HSS可以总是仅针对因INVITE触发的LIR来返回S-CSCF能力/身份。

TCAP

注释：仅针对PSTN/PLMN交互，需要对TCAP的更新。该工作的基本原理十分类似于如在ITU-T Q.733.3/Q.733.5中所定义的CCBS/CCNR服务，包括常规操作、定时器、异常情形等。在早些部分中描述了对TCAP的更新。

ISUP

注释：仅针对PSTN/PLMN交互，需要对ISUP的更新，

起因参数

两个新的起因值，即，A和B需要被支持以便指示情形“被叫用户未注册”以及“被叫用户不可用”。

诊断

对于起因A和B，诊断子字段应该存在，并且带有前面部分中所描述的值。

注意，如果诊断不存在，则可以假设“CCNReg是不可能的”。如果跟着的是这种方法，则仅当“CCNReg是可能的”时才需要诊断存在。

附加评论：如果决定对于CCNReg服务在SIP中的P服务指示头部中实现不同值(以替代“ccss”)，则其必须映射到新的参数/参数值。

对PLMN/PSTN的扩展

队列管理过程可以通过PSTN/PLMN交换机来执行，类似于CCBS/CCNR。(除了对于基本CCNReg服务所需的更新，即，在SIP和DIAMETER中所需的更新之外)在TCAP和ISUP中也需要协议更新。协议映射和交互功能性被建议实现在MGCF中(或，更一般地，实现在软交换中)。所建议的方法使得CCNReg服务范围接近于无处不在，即，由于所建议的协议映射，其可以被提供给任意的用户(PSTN/PLMN/SIP/IMS)，而无论主叫和被叫用户网络是哪种。

Claims

1.一种用于向未注册或不可用的用户提供呼叫完成服务的方法，该服务称为CCNReg，该呼叫发起于第一用户并且终止在第二用户处，该第一用户和第二用户都在IMS电信网络中，该电信网络包括：

-P-CSCF，

-针对第二用户的终止I-CSCF，

-针对第一用户的发起S-CSCF，

-针对第二用户的终止S-CSCF，

-针对第一用户的发起应用服务器，

-针对第二用户的终止应用服务器，

-归属订户服务器HSS；

-经由发起S-CSCF从发起应用服务器向终止I-CSCF发送(9-10)第一SUBSCRIBE消息，所述第一SUBSCRIBE消息包含向终止I-CSCF通知发起CCNReg服务以便完成第一用户和第二用户之间的通信尝试的指示，

-接着，在通过找到上述的指示而确定第一SUBSCRIBE消息针对于CCNReg时，从终止I-CSCF朝HSS发送(11)位置信息请求，请求关于终止S-CSCF的信息，

-接着从HSS向终止I-CSCF发送(12)包含S-CSCF能力或／和名称的位置信息应答，

-接着，在终止I-CSCF中接收到S-CSCF能力或／和名称时，分配(13)一个S-CSCF，称为终止S-CSCF，并且将SUBSCRIBE消息转发到所述终止S-CSCF，

-接着，从终止S-CSCF向HSS发送(14)服务器分配请求，

-接着从HSS向终止S-CSCF发送(15)包含第二用户的配置简档信息的服务器分配应答，

-接着，从终止S-CSCF向终止应用服务器转发(16)第一SUBSCRIBE消息，以便请求处理针对第二用户的CCNReg服务功能，

-以及，接着从终止应用服务器向发起应用服务器发送(21-23)第一NOTIFY消息，所述第一NOTIFY消息带有对CCNReg服务的CCNReg订阅是活跃的以及针对第一用户与第二用户通信的CCNReg请求已经被排队的指示，

-以及，当第二用户再次变成已注册或可用时，并且准备好完成CCNReg呼叫时，并且第一用户成为呼叫完成队列中的第一条目时，则从终止应用服务器向发起应用服务器发送(43-45)第二NOTIFY消息，所述第二NOTIFY消息带有对CCNReg服务的CCNReg订阅是活跃的并且第二用户现在已注册或可用，即准备好进行对第一用户的呼叫完成，的指示。

2.根据权利要求1所述的方法，其特征在于，针对检测第二用户未注册或不可用，所述方法包括步骤：

-从第一用户的用户设备朝所述终止I-CSCF发送(1-5)INVITE消息，

-接着从终止I-CSCF向HSS发送(6)直径位置信息请求，以获得关于针对第二用户的终止S-CSCF的信息，

-接着从HSS向终止I-CSCF发送(7)位置信息应答，所述应答包含DIAMETER ERROR IDENTITY NOT REGISTED指示，

-接着从终止I-CSCF向发起S-CSCF回送(8)404未找到响应，发起S-CSCF接着将其转发到发起应用服务器，所述响应包含下面的指示：

-允许事件头部：呼叫-完成，以及，可选地，

-原因头部：“用户未注册或用户不可用”，

-接着将SUBSCRIBE消息从发起应用服务器经由发起S-CSCF向终止I-CSCF转发(9-10)，该SUBSCRIBE消息包含向终止I-CSCF通知发起CCNReg服务以便完成所述第一和第二用户之间的通信尝试的指示，

-接着，在通过找到上述的指示而确定所述SUBSCRIBE消息针对于CCNReg时，从终止I-CSCF朝HSS发送(11)位置信息请求，请求关于终止S-CSCF的信息，所述位置信息请求包含属性值对，以向HSS指示即使用户未注册或不可用，也应该总是在其应答中返回S-CSCF信息，

-接着从HSS向终止I-CSCF发送(12)包含S-CSCF能力和名称的位置信息应答。

3.根据权利要求1所述的方法，其特征在于，针对检测所述第二用户未注册或不可用，所述方法包括步骤：

-从终止I-CSCF向HSS发送(206)直径位置信息请求，以便获得关于终止S-CSCF的信息，

-接着，响应于该直径位置信息请求，总是从HSS向所述终止I-CSCF发送(207)S-CSCF能力和／或名称，

-接着基于返回的S-CSCF能力和／或名称，在I-CSCF中选择(208)终止S-CSCF，

-接着从所述终止S-CSCF向终止应用服务器发送(209)INVITE消息，以便激活终止应用服务器，

-接着从所述终止应用服务器朝所述发起应用服务器发送(210-213)404未找到响应或480临时不可用响应，所述响应包含下面的指示：

-允许事件头部：呼叫完成。

4.根据权利要求3所述的方法，其中所述响应还包含下面的指示：

-原因头部：“用户未注册或用户不可用”。

5.一种用于向未注册或不可用的用户提供呼叫完成服务的方法，该服务称为CCNReg，呼叫发起于PSTN或PLMN中的第一用户并且终止在IMS电信网络中的第二用户处，所述IMS电信网络包括：

-P-CSCF，

-I-CSCF，

-针对第二用户的终止S-CSCF，

-针对第二用户的终止应用服务器，

-归属订户服务器HSS；

-在发起PSTN／PLMN和终止IMS网络的接口处的媒体网关控制器功能MGCF；

-从发起PSTN／PLMN向在所述发起PSTN／PLMN和所述终止IMS网络的接口处的MGCF发送(308)TCAP消息TC-BEGINCCNReg请求调用，

-在所述MGCF中将该TC-BEGIN CCNReg请求调用映射(309)到第一SUBSCRIBE消息，并且接着将其发送给终止I-CSCF，

-从终止I-CSCF向HSS发送(310)位置信息请求，以便获得关于针对第二用户的终止S-CSCF的信息，所述位置信息请求包括新的属性值对，以向HSS指示总是返回S-CSCF信息，

-从HSS向所述终止I-CSCF发送(311)带有S-CSCF信息的位置信息应答，

-从终止I-CSCF经由终止S-CSCF向终止应用服务器发送(312-313)第二SUBSCRIBE消息，以便请求处理针对第二用户的CCNReg服务功能，

-并且接着向在发起PSTN／PLMN和终止IMS网络的接口处的MGCF发送(317-318)第一NOTIFY，所述第一NOTIFY带有对CCNReg服务的CCNReg订阅是活跃的以及针对第一用户与第二用户通信的CCNReg请求已经被排队的指示，

-接着在MGCF中将第一NOTIFY消息映射(319)到TCAP消息TC CONT CCNReg请求，所述TCAP消息TC CONT CCNReg请求带有成功结果的代码，并且将所述第一NOTIFY消息发送给所述发起网络，以向第一用户指示所述第二用户的状态监视已经被成功地发起，

-接着，当第二用户再次变成以注册或可用时，从所述终止应用服务器经由所述终止S-CSCF向所述MGCF发送(322-323)第二NOTIFY消息，所述第二NOTIFY消息带有关于第二用户有空再呼叫，即准备好呼叫完成，的指示，以使得所述第一和第二用户之间的CCNreg呼叫完成尝试可发生，

-将所述第二NOTIFY消息映射(324)到TCAP TC CONT远程用户有空消息，

-接着从所述发起PSTN／PLMN向在发起PSTN／PLMN与终止IMS网络的接口处的MGCF发送(327)IAM消息，该IAM包含《ccss》参数，

-将该IAM映射到SIP INVITE消息并且将其发送给终止IMS网元，

-以及，将IAM消息中的《ccss》参数映射到在SIP中的该消息的P服务指示头部，其值为《ccss》。

6.一种用于向未注册或不可用的用户提供呼叫完成服务的方法，该服务称为CCNReg，呼叫发起于基于IMS的电信网络中的第一用户并且终止在PLMN网络中的第二用户处，所述IMS电信网络包括：

-针对第一用户的发起S-CSCF，所述第一用户正在向第二用户发起呼叫，

-针对第一用户的发起应用服务器，

-针对第一用户的发起I-CSCF，

-针对第二用户的终止I-CSCF，

-归属订户服务器HSS，

-在基于IMS的电信网络和PLMN的接口处的媒体网关控制功能二

-该方法包括多个步骤，包括检测第二用户未注册或不可用，并且接着监视第二用户的状态；

-从发起应用服务器向发起S-CSCF发送(414)SUBSCRIBER消息，该SUBSCRIBE消息包含通知发起CCNReg服务以便完成所述第一用户和第二用户之间的通信尝试的指示，

-将该SUBSCBRIBE从发起S-CSCF向媒体网关控制器功能MGCF转发(415)；

-在所述MGCF中将该SUBSCRIBE映射(418)到带有CCNReg请求调用的TCAP消息TC BEGIN，并且将TCAP消息TC BEGIN发送给所述PLMN，

-接着从所述PLMN接收(419)带有指示成功的返回代码的TCCONT CCNReg请求消息，

-在基于IMS的电信网络和PLMN的接口处的MGCF中，将TCCONT消息映射(420-421)到第一NOTIFY消息，并且向发起应用服务器发送第一NOTIFY消息，所述第一NOTIFY消息带有对CCNReg服务的CCNReg订阅是活跃的以及针对第一用户与第二用户通信的CCNReg请求已经被排队的指示，

-当所述第二用户变为可用时，在所述MGCF中从PLMN接收(424)TC CONT消息，其指示所述第二用户是可用的，

-接着在所述MGCF中将该消息TC CONT映射(425-426)到第二NOTIFY消息并且将其发送给所述发起应用服务器，所述第二NOTIFY消息带有指示：第二用户有空再呼叫，即准备好呼叫完成，以使得所述第一和第二用户之间的CCNreg呼叫完成尝试可发生，

-接着从所述发起应用服务器向在发起IMS网络与终止PLMN的接口处的MGCF发送SIP INVITE消息(429-430)，该INVITE消息包含该消息中具有值《ccss》的P服务指示头部，

-接着将该INVITE消息映射(431)到IAM，并且将其发送给所述终止PLMN，并且将所述INVITE消息中的P服务指示头部映射到所述IAM消息中的《ccss》参数。

7.一种用于向未注册或不可用的用户提供呼叫完成服务的方法，该服务称为CCNReg，呼叫发起于第一用户并且在第二用户处终止，第一用户和第二用户都位于非IMS的基于SIP的电信网络中，该非IMS的基于SIP的电信网络包括：

-针对第一用户的发起代理服务器，所述第一用户正在发起到第二用户的呼叫，

-针对第二用户的终止代理服务器，

-从发起代理服务器向终止代理服务器发送(504)SUBSCRIBE消息，该SUBSCRIBE消息包含向终止代理服务器通知发起CCNReg服务以便完成第一用户和第二用户之间的通信尝试的指示，

-接着，在通过找到上述的指示而确定SUBSCRIBE消息针对于CCNReg时，从终止代理服务器朝发起代理服务器发送(506)第一NOTIFY消息，以便传达CCNReg事件订阅现在是活跃的并且请求被排队的CCNReg特定信息，

-接着，在确定第二用户注册或变得可用时，从终止代理服务器向发起代理服务器发送(510)NOTIFY消息，该NOTIFY消息包含第二用户有空再呼叫，即准备好呼叫完成，的指示。

8.根据权利要求1、5、6、7的任意一项所述的方法，其中所述SUBSCRIBE消息包含下面的指示：

-事件：呼叫完成。

9.根据权利要求8所述的方法，其中所述SUBSCRIBE消息进一步包含下面的指示：

-队列性质：CCNReg，

-队列操作：添加。

10.根据权利要求1、5、6、7的任意一项所述的方法，其中所述第一NOTIFY消息包含：

-事件：呼叫完成，

-呼叫完成状态：排队。

11.根据权利要求1、5、6、7的任意一项所述的方法，其中所述第一NOTIFY消息进一步包含：

-队列状态：“请求被排队”，

-队列性质：CCNReg。

12.根据权利要求1、5、6的任意一项所述的方法，其中所述第二NOTIFY消息包含：

-事件：呼叫完成；

-呼叫完成状态：准备好呼叫完成。

13.根据权利要求1、5、6的任意一项所述的方法，其中所述第二NOTIFY消息进一步包含：

-队列状态：“用户有空再呼叫”，

-队列性质：CCNReg。