IDC资讯中心
文章摘要
本文介绍ITU-T制订的H.323建议所定义的多媒体会议系统的结构、音视频编解码、数据通信和码流复用，并特别讨论了该系统工作在IP网上时服务质量保证手段。
关键词： H.323建议 多媒体会议系统 音频编解码 视频编解码 码流复用 服务质量
1．引言
在IP网上开发多媒体应用有巨大的商业前景，WWW的成功更使业界对此充满信心。H．323建议是由ITU-T制订的基于分组交换网络（PBN）的多媒体会议系统（以下简称H.323会议系统）。H.323会议系统不假定其工作的网络基础能提供服务质量（QoS）保证。实际上，随着IP网的迅速发展，其主要应用于IP网中。
2．H.323会议系统的结构
H.323会议系统中传输的信息流中包含音频、视频、数据和控制信息。所有的信息流采用H.225.0建议来进行打包和传送。
为了实现在会议系统中传输上述信息流，H.323建议定义的多媒体会议系统主要由终端、网守（GateKeeper，亦称网闸）、网关（Gateway）、多点控制器（MC）、多点处理器（MP）和多点控制单元（MCU）等组成。
2.1 H.323终端
H.323终端是能够在分组交换网络中提供实时、双向通信的节点设备。H.323终端功能框图如图1所示。其中系统控制单元、H.225.0层、分组网络接口、音频编解码单元是H.323终端必须具备的，视频编解码单元和数据应用是可选的。下面简介终端基本组件的主要作用。
·音频编解码器：采用特定的音频编码算法产生数字化音频信号并进行相应的解码。在运用中，编解码器使用的音频算法是在能力交换期间通过使用H.245协商得到的。音频流应根据H.255.0标准进行格式化。H.323终端可以同时发送或接收多个音频信道信息。例如，它可以允许两种语音传送；对于多点会议，H.323终端需实施音频混合的功能。
·视频编解码器：采用特定的视频编码算法产生数字化视频信号并进行相应的解码。视频编码不进行BCH纠错，且允许以不对称的视频比特率、帧速率、图像分辨率运行。类似于音频编解码器，视频编解码器使用的编解码算法是在能力交换期间通过使用H.245协商得到的，视频流也应根据H.255.0建议规定的格式进行打包传送。
·数据信道： H.323终端通过H.245的控制消息建立一个或多个数据信道。H.323会议系统的数据功能是建立在T.120系列建议的基础之上的。根据应用的要求，数据信道是双向或单向的逻辑信道，在这些逻辑信道上实现H.323会议系统的全部数据功能。图1 H.323终端
·H.245控制：H.245控制信道承载管理H.323通信实体操作的端到端控制消息，包括能力交换、逻辑信道的开和关、模式选择请求、流量控制消息及通用命令和指示。H.245信令在两个终端间或一个终端和MC间再或一个终端和网关间建立。对于端点参与的呼叫，端点应在每个方向上建立一个H.245控制信道，并使用H.245建议的消息和规程。
·H.225呼叫控制：运用H.225.0呼叫控制信令来建立两个H.323终端间或终端与网守间的连接。呼叫信令信道的建立先于H.323终端间的H.245控制信道和其它任何逻辑信道，因此，它的建立不受H.245控制信道的管理。
·RAS控制：RAS（Registration, Admission and Status, 登记、接纳和状态协议）信号运用H.225.0控制消息在终端与网守之间执行登记、接纳、带宽改变和使二者脱离关系等过程。RAS信道不受H.245控制信道管理。系统没有网守时，无需建立RAS信道。若系统中存在网守，RAS信道建立早于终端间的任何信道。
·分组网络接口：H.323终端的网络接口是H.225建议所描述的，它规定了下述必须的功能：
一、 对H.245控制信道、数据信道、呼叫信令信道提供可靠的端到端服务（TCP、SPX等）；
二、 对于音频、视频和RAS信道提供不可靠的端到端服务（UDP、IPX等）。
这些服务可以是单工、双工、单播或多播的。
2.2 网守（GateKeeper）
网守是H.323系统的一个可选组件，其功能是向H.323端点提供呼叫控制服务。H.323网守在系统中必须提供4种基本服务：地址翻译、带宽控制、许可控制与区管理功能。带宽管理、呼叫鉴权、呼叫控制信令和呼叫管理等为网守的可选功能。在H.323系统中网守并不是必需的，然而如果存在网守，那么终端必须使用由网守提供的服务。这些服务在RAS中定义。在逻辑上，网守是一个独立于端点的功能单元，但在物理实现时可以包含在终端、MCU和网关中。
2.3 多点控制单元（MCU）
多点控制单元用于支持三个以上端点设备的会议。在H.323系统中，一个多点控制单元由一个多点控制器（MC）和几个多点处理器（MP）组成，但也可以不包含MP。多点控制器处理终端间的H.245控制信息，从而决定它对视频和音频通常的处理能力。在必要情况下，多点控制器还可以判断哪些视频流和音频流需要多播以控制会议系统使用的资源。
MC并不直接处理任何媒体信息流，而将它留给MP来处理。MP对音频、视频或数据信息进行混合、切换及其它处理。多点处理器和多点控制器可能存在于一台专用设备中或作为别的H.323组件的一部分，但MCU一般是独立的单元设备，具有自已的运输层地址。
2.4 网关（Gateway）
网关是H.323会议系统的一个可选件。网关能提供很多服务，其中包含H.323会议节点设备与其他ITU标准相兼容的终端之间的转换功能，这种功能包括数据传输格式（如H.225.0到H.221）和通信规程的转换（如H.245到H.242）。另外，在分组网络和电路交换网络之间，网关完成视频、音频和数据信息编码格式之间的互译。
通常网关的目的是将分组网络终端的特性映射到电路交换网络终端上或相反。网关的主要应用在于通过N-ISDN建立与远程H.320兼容终端的连接；通过B-ISDN建立与远程H.321兼容终端的连接或通过通用电话交换网或无线网络建立与远程H.324和V.70兼容终端的连接等方面。终端使用H.245和Q.931建议与网关进行通信。若没有必要与其他网络建立连接，而且终端直接与同一分组网络上的其他终端进行通信，则无需网关。利用适当的解码器，H.323网关可支持符合H.310，H.321，H.322以及V.70标准的终端。
3. H.323会议系统中的图象编码
H.323会议系统中的图象编码主要有两种，即H.261和H.263。其是H.261 QCIF是必备的格式，除此而外，可以通过能力协商采用其它的编码形式。
3.1 H.261图象编码算法
H.261建议是1990年提出的运动图象编码算法，具有开创性的意义。它的编码效率高，图象质量好且实时性好，已被广泛运用于会议系统的运动图象的编码方式之中。
H.261建议的编码算法具有如下特点：
·采用通用的中间格式（CIF）；
·图象按视频的整数倍速率抽取，与数字网络时钟同步；
·视频编码器提供一组独立的数字比特流；
·采用混合编码算法，帧间预测用来降低图象信号的时间冗余度，而变换编码用于降低空间域的多余度；
·视频的编码速率从40kb/s ~ 2Mb/s;
·传输比特流包含BCH（511，493）前向纠错码。
H.261建议在编码方面主要采用了三种技术来实现压缩：
·预测编码
·变换域编码
·游程熵编码
3.2 H.263图象编码算法
H.263建议是为了满足低码率运动图象编码而制订的。同H.261一样，H.263采用了运动补偿和DCT编码方法，但它参照MPEG标准引入以I帧、P帧、PB帧（选项）三种帧模式和INTER（帧间编码）、INTRA（帧内编码）两种编码模式。
为提高压缩比，H.263又采取以一些新的措施：取消了H.261中可选的环路滤波器，将运动补偿的精度提高到半象素；改进了运动估值算法，充分利用以运动矢量的相关性来提高预测质量，减轻块效应；精减了部分附加信息的编码，提高了编码效率；采用三维哈夫曼编码、算术编码来进一步提高压缩比。
为了改进性能还包含了四个可选的编码选项：
·无限制运动矢量模式
·算术编码
·先进预测模式
·PB帧模式
4. H.323会议系统中的音频编码
H.323会议系统中的音频（语音）编码方式主要有六种：G.711、G.722、G.723.1、G.728、G.729和MPEG audio。其中G.711是必备的，其它为可选项。除了上述六种编码方式外，也可以通过能力协商来采用其它方法。
在图象编码方面，H.263采用了多种方法使编码尺度可变，即根据不同的信道质量对码流进行调整以保证适当的服务质量。对于语音编码，这一点同样重要。目前，H.323会议系统中主要采用G.723.1和G.729两种语音方式。
4.1 G.723.1语音编码
G.723.1是一个双速率的语音编码器，它的两个编码速率分别为6.3k和5.3k。高速率（6.3k）采用多脉冲激励最大似然量化（MP_MLQ）算法，低速率（5.3k）采用代数码本激励线性预测（ACELP）算法。这两种算法具有相同的理论基础，都是基于线性预测（LPC），都采用非周期性分量的激励源。不同之处在于对MP_MLQ采用多脉冲最大似然量化激励，而对ACELP采用的是代数码本激励。
G.723.1具有较好的语音质量。其5.3k速率编码，语音质量优于VCELP（8kb/s）；其6.3k速率编码，语音质量等价于32kb/s的G.726建议相应指标。两者基本上均能达到长途电话质量的要求。G.723.1的缺点是固有时延较大。
4.2 G.729语音编码
G.729是一个8kb/s的语音编码标准，它采用的算法是共轭结构代数码本激励线性预测编码（CS_ACELP），能达到32kb/sADPCM语音质量。研究发现，CS_ACELP算法很有特点：作不太大的改动后，向下可达6.4kb/s，向上可达13kb/s，且可传送更好的语音质量。
5. H.323会议系统中的数据通信
H.323会议系统中除了传输视频和音频信号外，还要进行数据信息的传送。会议系统中的数据通信是多个与会者之间的通信，因此它的一个十分重要的基础是建立一个多点通信服务（MCS）的通信体系结构。由于数据通信对差错控制要求较高，而对时延则不太敏感，因此MCS的通信体系结构应建立在可靠的通信连接(如TCP)基础上。
H.323会议系统中的数据通信采用T.120系列建议，该系列建议是由九个建议书（T.120~ T.128）组成的完整的数据通信协议，它分为四个层面来完成会议系统中的数据通信。
第一个层面是下四层的通信协议栈，在T.123建议中规定。
第二个层面是多点通信服务（MCS），在T.122/T.125中规定。
第三个层面是通用会议控制（GCC），在T.124中规定。
第四个层面是应用层面，在T.121 、T.126、 T.127 和T.128中规定。其中T.126中规定的电子白板和T.127中规定的二进制文件传送已获得应用。
6. H.323会议系统中的码流复用
H.323会议系统是基于分组交换的，因而会议系统中的码流在传输之前就必须进行打包，根据数据包上的标签进行统计复用。同时，由于会议系统中的不同信息码流各自有不同的特点。所以，它们对下层网络的承载要求也不同。对于IP网，在实现时可以用以下方法解决个问题：音频和视频码流对实时性要求很高，即使少量的时延，对视频会议来说也是无法忍受的。但是，它们对于少量的包丢失却不太敏感。因此，对于音频和视频码流，采用实时传输协议RTP来对它们进行打包再运用面向无连接的UDP协议进行实时传输。对RAS信号也采用UDP协议来传输。相反，数据和控制信号对于服务质量要求很高，少量的包丢失或出错都是无法忍受的。因此对于数据和控制码流，在传输层运用面向连接、提供可靠服务的TCP协议，从而完成对它们的可靠传送。图2给出了H.323会议系统的协议栈，从中可见具体的码流复用关系如所示。
图2 H.323系统中码流复用关系
7. H.323会议系统中的QoS保证
H.323建议不假定会议系统所基于的分组交换网络能提供QoS保证，要在真正实现实时的高质量的视频会议系统还需要一些相关技术和协议的支持。下文讨论IP网中的QoS保证技术。
7.1 多播技术
视频会议业务需要占用较大的带宽资源，在现有的网络条件下，极大地限制了视频会议业务的发展。多播技术是解决这个问题的有效途径。多播技术能够有效地解决多点对多点数据通信的网络带宽问题。在传输过程中，根据发送和接收各方的网络拓扑分布，确定并优化数据传送的树状路径，在同一网段，相同内容的数据流只需传送一次。多播地址可以采用一个通用的多播地址，但这不是有效的通信方式，最好是能够动态地分配一组地址。
7.2 资源预留管理
资源预留是指根据业务数据的QoS要求和带宽资源管理策略进行带宽资源分配，在IP网上提供一条完整的路径。IETF的RFC2205资源预留协议（RSVP）就是提供这种管理机制的协议。
RSVP是网络中预留所需资源的传送通道建立和控制的信令协议。通过预留网络资源建立一条从发送端到接收端的路径，使得IP网络能提供接近于电路交换质量的业务，即在面向无连接的网络上，增加了面向连接的特性；它既利用了面向无连接网络的多种业务承载能力，又提供了接近面向连接网络的质量保证。但是RSVP没有提供多媒体数据的传输能力，它必须配合其它实时传输协议来完成多媒体通信服务。
7.3 RTP/RTCP
RTP为交互式音频、视频等具有实时特征的数据提供端到端的传送服务。如果底层网络支持多播，RTP还可使用多播向多个目的端点发送数据。RTP协议包含两个密切相关的部分，即负责传送具有实时特征的多媒体数据的RTP和负责反馈控制、监测QoS和传递相关信息的RTCP。在RTP数据包的头部中包含了一些重要的字段：净荷数据类型的标志（PT）以说明多媒体信息所采用的编码方式；定时标志（TIMESTAMP）使接收端能够恢复收到的数据包发送时的定时关系，从而降低了网络引起的时延和时延抖动；序号（SN）可用来在接收端对收到的数据包进行正确的排序以及统计包丢失率。RTCP是RTP的控制协议，它周期性地与所有会话的参与者进行通信，并采用和传送数据包相同的机制来发送控制包。
值得注意的是，RTP协议本身并不提供任何QoS保证机制，QoS必须由下层网络来保证。但是通过RTCP控制包可以为应用程序动态提供网络的当前信息，据此可对RTP的数据收发作相应调整使之最大限度地利用网络资源。
8. 结束语
基于分组网络的多媒体会议系统有着广阔的应用前景。在H.323建议及其相关协议、RTP/RTCP、RSVP等协议和技术的支持下，能够实现具有一定服务质量保证的多媒体会议系统。然而要真正在Internet和其它分组网络上开展多媒体会议业务还需要考虑到保密性和安全性等问题，详细内容可参考ITU-T的H.235建议。
摘自www.vajet.net
