H.323补充业务

5.6.1补充业务描述

H.323系统补充业务的描述和实现机制借鉴专用综合业务网(PISN)的1SO标准和公用综合业务数字网(ISDN)的Q系列建议，由H.450系列建议定义。其中，H.450.1定义了适用于各种补充业务控制的通用功能协议，相当于ISO/IEC11582标准或Q.932建议。它给出了补充业务实现的一般机制，包括所用的控制数据结构及其传送过程。H.450.2-X建议则逐个定义每个补充业务的含义以及如何利用通用功能协议具体实现，包括数据单元的形式化定义，控制过程描述、信令消息流程和SDL图等，它们相当于Q.950建议。

目前共定义了7种补充业务，分别由H.450.2-H.450.8描述。下面简要说明各种业务的含义。

1.呼叫转交(Calltransfer)

设用户A有权使用此项业务。当A和B通信时，A可以通过转交功能将A-B通信转为B-C通信。在转交之前，A可以先和C通信，也可以不经和C的通信直接进行转交。常将A-B间呼叫称为第一呼叫，A-C间呼叫称为第二呼叫。其应用背景是，A向C咨询后认为C能更好地解决B的问题，于是将呼叫转为B-C通信。

假设在转交之前第二呼叫已存在，则其基本过程为，首先A应告之C呼叫要转交给他，C同意后返回一个临时标识，供后续转交过程标识此第二呼叫。然后，A请求B呼叫C,B向C发送的呼叫建立消息应包含第二呼叫的临时标识。B必须在收到C发回的证实消息后才释放第一呼叫，也就是如果转交未成功，原呼叫依然保留；C必须在收到B发来的呼叫请求后才释放第二呼叫。

2.呼叫转移(calldiversion)

包括无条件前转(CFU)、遇忙前转(CFB)、无应答前转（CFNR)和呼叫转向(CD-call deflection)。其中，CD指的是呼叫到达后，用户可指示将该呼叫转移至某端点。这些呼叫转移功能可以对全部呼叫有效，也可仅对符合筛选条件的呼叫有效，该项业务是在呼叫建立过程中执行的。

3.呼叫保持(callhold)

这项业务允许用户在呼叫过程中暂停和对方的信息通信，但信息逻辑信道依然保留，在需要时再恢复和对方的通信。在保留期间，用户可以进行其它呼叫或调用其它补充业务，被保留方将听到话音提示、录音通知或图像显示。有两种保留方式：一种称为近端保留，即上述提示信息是由本端发送给对方的，其好处是可以向对方播放所需的广告等信息。另一种称为远端保留，即上述提示信息由对方端点生成，本方通过信令告诉对方发送何种信息，其好处是可以节省网络话务量。

4.呼叫迁移和代答(callparkpick-up)

该项业务允许用户将来话呼叫迁移至另一端点，然后由另一端点用户应答此呼叫，在许多应用情况下是迁移用户自己至该端点应答此呼叫。此业务也有两种方式：一种是直接迁移和代答，即指定某一个代答端点。另一种是组代答，同一组中的任一端点均可代答。允许端点属于多个代答组，代答时可以指定应答某一呼叫，也可随机应答某一呼叫。

5.呼叫等待(callwaiting)

该项业务可向忙用户指示有来话呼叫进入，用户可选择接受该呼叫、拒绝该呼叫或不理会呼叫等待指示。

6.报文等待指示(MWI-messagewaitingindication)

该项业务主要用于报文中心通知用户已有报文来到，报文类型可为语音信箱留言、传真、智能用户电报等。通常报文等待指示将启动H.323终端的报文检索。该业务还允许用户主动向中心查询有尤等待的报文，其用途是在用户一段时间退出服务（如关机）后又进入服务时，通过查询更新其报文等待状态。

7.名字标识(n皿eidentification)

它包括4项业务：主叫用户名显示和限制、被接用户名显示和限制提示用户名显示和限制、忙用户名显示和限制。这些用户名分别在Setup消息、Connect消息、Alerting消息和ReleaseComplete消息中提供。

5.6.2 补充业务实现的通用机制

和ISDN一样，H.323系统采用通用的远程操作服务(ROS-Re­moteOperationService)机制来实现补充业务。它认为，无论是什么补充业务，其在线登记、激活和使用都可以抽象为两个远程节点之间特定操作的请求和执行过程，业务的不同只是操作类观和参数的不同而已，因此可以借用X.219建议定义的ROSE协议来传递补充业务控制信息，实际上，7号信令的TCAP协议也是基于同样的机制。

在ROSE协议中，两个远程对等应用进程之间交换的应用协议数据单元称为ROSEAPDU，它有如下4种类型：

(1)调用(INV-Invoke)：向对方发出执行某项操作的请求。其主要参数有：

•Invoke ID：调用标识号。标识对等节点之间的一个操作交互过程。一般说来，一对节点间可以同时进行多个操作交互。

•Linked ID：关联标识号。标识和本交互过程相关的另一个交互过程。例如：另一操作的执行尚缺少某项数据，为此执行本操作以获取该数据，这时就要用到此参数。一般用得不多。

•Opcode：操作名。标识每一个具体的操作，其编号由应用协议确定。例如，在H.450.X建议中就为补充业务用到的各个操作规定了操作码。

•argurnent：操作参数。

(2)回复结果(RR-ReturnResult)：对方执行操作后，将结果返回本方，此结果也可以是简单的证实信息。某些操作不要求对方回复结果，则消息交互可以不含RR。其主要参数有：

•InvokeID：指明是哪一个调用的返回结果。

•Result：内含Opcode和结果。

(3)回复出错(RE-ReturnError)：对方指示无法执行所要求的操作，例如对方不能支待该项补充业务。其主要参数有：

•InvokeID

•erroocode：出错代码。每个应用协议都规定了各个代码的具体含义。

•Parameter：参数。

(4)回复拒绝(RJ-ReturnReject)：对方指示拒绝执行该操作，其原因是发现消息有误，即出现协议性差错。其主要参数有：

•InvokeID

•Problem：给出发现的具体问题。也以编号表示。

上述ROSEAPDU都可用规范的ASN.l标记方法形式化描述。

H.450.1建议规定：所有补充业务的控制信息都采用ROSEAP-DU形式传送，关于某一补充业务的若干ROSEAPDU组成一个h4501ssAPDU，该APDU作为一个用户信息封装在相关消息的UUIE中传送。其结构如图5.35所示。

图5.35  补充业务控制信息传送的通用机制

在一个UUIE中允许有多个h4501SS APDU，在一个h4501SS AP­DU可包含多个ROSE APDU，要求同－SS APDU中的所有ROSE AP­DU的目的实体均相同。

h4501SS APDU由如下三个数据单元组成：

· 扩展的网络设施(NFE-NetworkFacilityExtensions);

· 解释APDU;

· 服务APDU。

其中，服务APDU可由一个或多个ROSEAPDU组成，为补充业务的操作控制信息。解释APDU指示接收端点对服务APDU中任一InvokeROSEAPDU不能识别时应如何处理。处理方法有三种：

．如果解释APDU指示值为＂拒绝不可识别InvokePDU"，则接收方应向源实体发送RJAPDU，其problem参数指示为“不可识别的操作＂。这是ROSE协议对该类问题的正常处理，如果没有解释APDU,亦按照此原则处理。

．如果解释APDU指示值为“若任何InvokePDU不可识别则清除呼叫＂，则接收方向源实体发R送JAPDU，同时释放该InvokeAPDU相关的呼叫或信令连接。

．如果解释APDU指示值为＂丢弃不可识别的InvokePDU"，则简单地丢弃，不回送RJAPDU。

NFE可包含4项数据元素：源实体、源实体地址、目的实体和目的实体地址，用以识别源和目的地，提供SSAPDU选路信息。发送方确定NFE目的实体及地址的规则为：

．如果远端补充业务控制实体就是该SSAPDU的目的实体，则置目的实体为＂端点”，目的实体地址可省略。

．如果未指定目的实体，则置目的实体为“任何实体”。此时，只要任一接收实体能理解该SSAPDU，它就是目的实体。

．如果至远端端点信令路径上某H.323实体为目的实体，则目的实体置为“任何实体”，目的实体地址置为指定实体的地址。

．如果至远端信令路径上的下一实体（如网闸）为目的实体，则NFE可省略。

在消息发送路径上的每一接收实体根据上述规定判定自身是否为该SSAPDU的目的实体。如果是目的实体，则按顺序逐个处理ssAPDU中的各个ROSEAPDU，并按解释APDU的指示处理异常情况；如果不是目的实体，则前传该SSAPDU。

在H.225.0中，下述消息可以传送SSAPDU:Alerting、CallPro­ceeding、Connect、Setup、ReleaseComplete、Progress和Facility。任一实体发送SSAPDU时，首先应选择呼叫建立或呼叫清除消息发送，如果当时没有这些消息需发送，则由Facility消息发送。另外，若前一发送或接收的Setup消息尚未应答，则暂不发送Facility消息。

SSAPDU的传送有两种可能的方式。种是借助呼叫相关的信令过程，经由相关消息发送，这些消息中都带有CRv。适于和呼叫相关的补充业务的信息传送。另一种方式是用H.225.0呼叫建立过程在补充业务对等控制实体之间建立－个呼叫无关的信令连接，然后在此连接上传送SSAPDU，适用于与呼叫无关的补充业务信息传送在这种方式中，二对策实体间没有H.245控制信道，也没有媒体逻辑信道，网闸选路过程和RAS过程仍然适用。但此时Setup消息中的承载能力(BC)IE的字段定义和一般呼叫有所不同，其信息传送能力应置为“不受限数字信息”，传送模式和信息传送速率都置为“呼叫无关信令连接”。另外，Setup-UUIE中应包含参数Conference­Goa（会议目标），置值为＂呼叫无关补充业务”。

H.450.1建议规定的上述原则是所有补充业务使用的公共协议机制，其本身并不控制任何一个补充业务。具体补充业务的h4501SSAPDU的定义及信令过程由相应的H.450.X规定。下面简要叙述呼叫等待和报文等待指示两个补充业务的实现过程，前者是呼叫相关业务，后者是呼叫无关业务。

5.6.3呼叫等待信令过程

设B为被服务用户，当前A-B正进行通话，用户C又呼叫B，此时B-C之间的信令消息过程如图5.36所示。

C向B发送Setup消息后，B在向C回送的Alerting消息的UUIE中传送呼叫等待的h4501SSAPDU。其中，NFE的目的实体置为“端点”；解释APDU指示值置为＂丢弃任何不可识别的InvokePDU"；服务APDU仅含一个InvokeAPDU。该APDU无需对方回复操作结果；操作码为105，表示是呼叫等待操作；可带仔选参数＂累计等待呼叫数”，指示有多少呼叫在等待中。

B端点发出SSAPDU后，启动定时器T-CW。如果定时器到时，B用户尤响应，则应向C发送ReleaseComplete，理由置为“目的地拒绝‘’（如果B用户接受该等待呼叫，则向C发送Connect消息，对A-B

图5.36  呼叫等待信令过程

呼叫有3种处理方法：释放呼叫；对A呼叫保持(H.450.4过程）；对A呼叫迁移(H.450.5过程），由其它人代答。

C收到带呼叫等待APDU的Alerting消息后，可以等待，直至B接受此呼叫；也可以释放至B的呼叫；或者调用其它不冲突的补充业务。

5.6.4报文等待指示信令过程

此业务包括三个信令过程：

·激活(Activate)：用于报文中心向被服务用户通知有到达的报文，同时可告之报文类型、等待报文数等详细信息。该过程也可用来向用户发送向指定端点回叫的Callback请求。

·去活(Deactivate)：用于报文中心告之用户已无等待报文。此时，用户处的报文等待指示应去除。

·询问(Interrogate)：用于用户向报文中心询问是否有报文等待。

报文可以是多种型式，每一类报文对应一种基本服务（如传真、语音信箱等），每种基本服务可有其自己的报文等待指示补充服务。

由于报文等待指示和呼叫尤关，因此其SSAPDU都是在呼叫尤关信令信道上传送的。该信道也由Setup消息建立，在SSAPDU传送完毕后就释放。

所有报文等待指示的操作都要求证实，因此均包含Invoke和RR两类APDU,InvokeAPDU中NFE的目的实体置为＂端点”;不含解释APDU，也就是说，若接收方收到不可辨认的InvokeAP­DU，就回送RJAPDU。

图5.37示出报文等待指示(MWI)的激活信令过程。报文中心经由Setup消息的UUIE向用户发送激活InvokeAPDU，用户则

图5.37报文等待指示的激活过程

经由Connect消息返回激活RRAPDUc报文中心收到证实后，发现又有新的报文到来，于是又通过Facility消息和用户交换新的激活InvokeAPDU和RRAPDU，告之更新信息。最后，报文中心发送Re­leaseComplete，关闭该信令信道。

NWI的激活InvokeAPDU主要包括以下数据单元：

．被服务用户的端点地址

．基本服务

．报文中心标识

．等待报文数

．在中心留下报文的用户的地址

．留报文的时间

．等待报文中的最高级别

其中，前二项为必备数据。其操作码设定为80。该APDU也可用作回叫指示，此时，等待报文数置零；报文中心标识置为回叫的用户端点地址；基本服务一般詈为”所有服务＂，即巾H.245过程确定媒体类型。

图5.38示出报文等待指示的去活过程（其InvokeAPDU比较简单，一般仅含用户地址、基本服务和报文中心标识三项数据单元，用于去活所有匹配码在此之前的激活操作。有时还可包含一个布尔数据CallbackReq，如果该数据置真，则仅去活匹配的回叫激活操作；如果置假，则仅去活匹配的非回叫激活操作。

图5.38报文等待指示的去活过程

由于报文中心可能会同时收到多种媒体的报文，因此，中心发出的同一个SSAPDU中可包含多个激活和去激活Invoke APDU。

图5.39示出报文等待指示的询问过程。它和去活过程类似，只是消息的传送方向相反。其InvokeAPDU较简单，和去激活相同；RR APDU包含数据较多，和激活InvokeAPDU基本相同。

图5.39报文等待指示的询问过