H.323协议分析

最新推荐文章于 2023-06-13 13:50:51 发布

pinghappy96

最新推荐文章于 2023-06-13 13:50:51 发布

阅读量1.1k

点赞数

分类专栏：多媒体传输文章标签： H.323

多媒体传输专栏收录该内容

1 篇文章 0 订阅

订阅专栏

原文出处：http://blog.csdn.net/bripengandre/article/details/2230087

H.323协议分析

第1章. 文档说明

H.323是ITU-T提出的一个建议书。它是一个协议族，用来在IP分组交换网上实现语音通信、视频通信和数据会议。H.323当前已发展到了第6个版本。

H.323第6版本的建议书长达300多页，限于篇幅，不可能一一叙述。为了对H.323有个直观的了解，本文首先介绍H.323协议族的组成，这个部分主要介绍协议族中相关协议的功能；然后介绍H.323的各个组件，这个部分主要介绍各个组件的功能；在了解了协议和功能组件的基础上，再重点讲述H..323的通信过程，这个部分主要介绍呼叫信令控制和多媒体控制信令等的建立和释放，以及多媒体信息的传输。

图 1 H.323协议栈

第2章. H.323的相关知识

2.1. H.323协议栈

H.323协议族是建立在运输层之上的体系结构。正因为建立在传输层之上，所以它屏蔽了底层网络的差异，而使其与其他网络的VOIP协议交互起来比较容易。图 1是H.323的协议栈。

从图中可以看出，H.323有三个功能模块：信令控制模块、媒体传输模块和数据会议（Data Conference）模块。信令控制模块又由H.225.0 认证/接受/状态RAS（Registration/Admission/Status）信令、H.245媒体控制信令和H.225.0呼叫信令组成。媒体传输模块由音频传输和视频传输两部分组成，这两部分各自又包括编码标准、RTP实时传输和RTCP实时传输控制。数据会议模块则主要由建立在TCP上的T.120协议族来负责。

这里需要注意的是H.323只是H.32X多媒体通信标准系列中的一个。H.32X系列标准各自针对一种特定网络上的多媒体通信。它们公用了很多协议，例如H.245就是大多数H.32X协议族系列的一个公共的协议。H.32X协议族包括：H.320是在N-ISDN上进行多媒体通信的标准，H.321是在B-ISDN上进行多媒体通信的标准，H.322是在有服务质量保证的LAN上进行多媒体通信的标准，H.324是在GSTN和无线网络上进行多媒体通信的标准，而H.323为现有的分组网络PBN（如IP网络）提供多媒体通信标准。

图 1所示的协议栈中的各个协议都比较复杂，我们将在单独的部分中介绍它们。图 1中所示的协议栈是在什么上面实现的？当然是在H.323的功能组成部分——组件上了，因此，下面介绍H.323的组件。

2.2. H.323的组件

2.2.1. H.323拓扑图

图 2 一个简单的H.323拓扑图

图 2给出了一个简单的H.323系统的拓扑图。可以看出，H.323一般有四个组件：Terminal（终端）、Gateway（网关）、MCU（Mutipoint Control Units多点控制单元）和Gatekeeper（关守）。Terminal、Gateway和MCU都可称为endpoint（端点）。

2.2.2. Terminal

Terminal是一个产生和终止H.323数据流／信令的endpoint。它是一个带有H.323协议栈的器件，例如PC、嵌入式IP电话机和IP电话软件Net2Phone等。

根据H.323的规定，Terminal必须支持音频通信，而视频通信和数据会议则是可选的。

2.2.3. Gateway

Gateway是H.323网络中一个可选组件。Gateway最重要的作用就是协议转换。通过Gateway，两个不同协议体系结构的网络得以通信。例如，有了Gateway，一个H.323终端能够与PSTN终端语音通信。可以看出，当我们的通信要经过不同协议体系结构的网络时，Gateway是必须的。

2.2.4. MCU

MCU主要负责多方会话。MCU由一个必须的MC（Multipoint Controller）和可选的多个MP（Multipoint Processor）组成。MC负责信令控制，MP负责混音、Transcode等媒体处理。

2.2.5. Gatekeeper

Gatekeeper也是H.323网络的一个可选组件。Gatekeeper主要负责认证控制、地址解析、带宽管理和路由控制等。

当H.323网络中不存在Gatekeeper时，两个endpoint是不需要经过认证就能直接通信。这不便于运营商开展计费服务，而且两个endpoint的地址解析被分散到Gateway中，这无疑会加大Gateway的复杂度。另外，如果没有Gatekeeper，扩充新功能（如添加带宽管理和路由控制）是比较困难的。

Gatekeeper则恰好弥补了上述缺陷，当然也带来了成本的提高。Gatekeeper本质上是将认证控制、地址解析、带宽管理和路由控制等功能集成到一个器件中。这样，当H.323网络中存在Gatekeeper时，两个endpoint要通信，必须先经过Gatekeeper的认证。然后Gatekeeper从endpoint提交的认证信息（如Net2Phone提供的号码序列）中，获取到两个endpoint间的路由，从而让两个endpoint实现通信。当然，为加强整个网络的管理，我们可以方便地将带宽管理和路由控制等功能方便地添加到Gatekeeper中。

2.2.6. 小结

上面提到的组件只是逻辑上的功能组件，在具体的物理实现中，它们中的几个有可能被集成到一个器件上。例如，Gateway、Gatekeeper和MCU有可能集成到一个器件上，就像链路层交换和网络层路由往往能被集成到一个路由器上一样。

2.3. 信令控制协议

2.3.1. H.225.0 RAS信令

2.3.1.1. RAS是什么

H.225.0 RAS认证/接受/状态（Registration/Admission/Status）用来实现endpoint和Gatekeeper间的认证。RAS信令提供如下功能。

1) 允许Gatekeeper管理endpoint。

2) 允许endpoint向Gatekeeper提出各种请求，如认证请求、接受请求和带宽调整等请求。

3) 允许Gatekeeper响应endpoint的请求，接受或拒绝提供某项服务，如认证许可、带宽调整和地址解析等。

2.3.1.2. RAS消息的格式

同其它信令一样，H.225.0 RAS信令也是通过RAS消息来交互的。RAS消息的常用格式如下所示。

1) xRQ /*请求（一般情况下是，由endpoint发送至Gatekeeper），x随具体请求的不同而不同*/

2) xRJ /* Gatekeeper发回的拒绝响应，x随拒绝的内容的不同而不同 */

3) xCF /* Gatekeeper发回的确认响应，x随确认的内容的不同而不同 */

当然，RAS消息对一些特殊情况有特殊的格式，此处不再累述。

2.3.1.3. RAS交互的一般过程

如图 1所示，RAS是建立在UDP上。RAS单播通信（如IP电话）一般使用UDP端口1719，RAS多播通信（如视频会议）则一般使用UDP端口1718。

图 3 RAS交互过程

我们以RAS认证过程为例来讲述RAS的交互过程。图 3示意性地给出了RAS的认证过程。

可以看出，RAS的认证过程如下（其它交互过程是类似的）。

1) Gateway向Gatekeeper发送RRQ认证请求消息。RRQ认证请求给出了必要的认证信息。

2) Gatekeeper处理Gateway传来的认证信息，并向Gateway回送相应的响应。如果认证成功，则回送RCF认证确认消息；如果认证失败，则回送RRJ认证拒绝消息。

更完整的通信过程可参考第3章的内容。

2.3.2. H.245媒体控制信令

2.3.2.1. H.245媒体控制信令是什么

媒体传输时，有很多配置需要调整：需要协商发送方的发送特性和接收方的接收特性，需要打开或关闭某逻辑传输信道，需要实时控制媒体流。H.245媒体控制信令就是用来实现上述媒体控制功能的。它的功能如下。

1) 能力协商。H.323允许各endpoint具有不同的发送和接收能力。因此，两个endpoint要通信，必须先通过H.245消息来协调各自的能力。

2) 打开或关闭逻辑信道。H.323中，音频通信、视频通信和数据会议通信的信道是独立的，H.245被用来管理这些信道。H.245本身使用逻辑信道0。

3) 媒体流或数据流控制。H.245的反馈信息可用来调节endpoint的各项操作。

4) 其它管理功能。主要还是用来协调endpoint间的行为。例如，当发送endpoint的传输编码改变时，接收endpoint也需做相应的改变，这是由H.245负责的。

2.3.2.2. H.245消息的封装

图 4 H.245的封装

图 4给出了H.245消息的封装，这里做几点补充说明。

1) H.245信息是经H.245控制信道传输的，这个信道是可选的，例如在快速连接（Fast Connect）中，就没有这个信道。关于快速连接请参考2.3.3的相关内容。

2) H.245逻辑信道通常是一个单独的TCP连接，但是在快速连接等情况下，它是通过H.225.0呼叫信令隧道（Tunnel）实现的。这种情况其实是1)中所述情况中的一种。关于Tunnel，请参看第5章中的相关内容。

关于TPKT、ASN1等请参看相应的资料，此处不再累述。

2.3.2.3. H.245消息的类型和H.245的交互过程

H.245消息有如下四种常用的类型。

1) 请求（Request）。例如，主从确定请求masterSlaveDetermination和终端能力配置请求terminalCapabilitySet。

2) 响应（Response）。例如主从确定响应masterSlaveDeterminationAck和终端能力配置响应terminalCapabilitySetAck。

3) 命令（Command）。例如发送终端能力配置命令sendTerminalCapabilitySet。

4) 指示（Indication）。例如用户输入指示userInput。

H.245的交互过程与RAS的交互过程类似，可参考2.3.1.3和第3章的相应内容。

2.3.3. H.225.0呼叫信令

2.3.3.1. H.225.0呼叫信令是什么

图 5 H.225.0呼叫信令的封装

H.225.0呼叫信令，顾名思义是用来在两个endpoint间建立或释放一个呼叫信令连接。它部分地采用了Q.931（ISDN呼叫信令），并加上了一些适合分组交换网的特定内容；H.225.0呼叫消息也部分地采用了Q.932。

2.3.3.2. H.225.0呼叫信令的封装

图 5给出了H.225.0呼叫信令的封装，这里做几点补充说明。

1) H.225.0呼叫信令信道在TCP或UDP都可建立。

2) 图 5中所示的IE（Information Element）随所带信息的不同而不同。例如，SETUP有“Calling Party Number”、“Called Party Number”和“Display”等IE。

同样地，TPKT，Q.931和ASN.1请参考相关资料。

2.3.3.3. H.225.0消息的类型和H.225.0交互过程

H.225.0呼叫信令的交互也是通过呼叫信令消息实现的。呼叫信令消息的常见类型是：Setup，Call Proceeding，Alerting，Information，Release Complet，Facility，Progress，Status，Status Inquiry，Setup Ackowledge，Notify，Connect。

呼叫信令的交互过程就是两endpoint间交流呼叫信令消息的过程。图 6给出了一个基本的呼叫信令的交互过程。

图 6 RAS和H.225.0呼叫信令的建立过程

对图 6做些说明。

1) 图中给出的一个是最简单呼叫信令交互过程。Gateway之间是直接交互的，而没有通过Gatekeeper的中转。

2) 整个呼叫信令的建立过程能够最简化成两步，即“Setup”和“Connect”。当然呼叫信令的释放直接用“Release Complete”即可。

3) 图中给出的交互过程还有可选的步骤，如“Call Proceeding”、“Progress”和“Alerting”。这些步骤主要是用来避免超时错误和提供带内（in-band）广播等服务。

2.3.3.4. 小结

前面我们已讲述了3个媒体控制协议。这三个协议的执行顺序是怎样的？它们之间的关系又是怎样的呢？

三个协议的执行顺序是这样的：H.255.0 RAS协议最先进行，然后H.225.0呼叫信令控制协议和H.245媒体控制协议同时进行。具体的过程可参考第3章的相关内容。

三个协议的关系：三个协议按照时间顺序执行，各司其职，为H.323体系提供好的媒体控制功能。

2.4. 媒体传输相关协议

音频、视频等信息要传输，首先要编码，这需要编码协议。为保证它们的传输质量（实时性等），我们用UDP来传输它们，但UDP的可靠性不好，所以我们需在UDP之上加上自己的检错、纠错机制，这就是说我们要在UDP上加上另外的传输协议。

H.323协议体系中，从上到下与媒体传输相关的协议有：音频编码协议G.711和G.723.1等，视频编码协议H.261和H.263等，实时运输协议RTP以及与其配套的实时运输控制协议RTCP。

音频编码协议和视频编码协议请参看相应的标准。

RTP协议是用来提供端到端的实时运输功能，但并不保证服务质量；而配套的RTCP协议是用来保证服务质量的。这两个协议的详细情况请参看RFC3550（RFC1889是过期标准）和另一篇文章《RTP协议分析》。

2.5. 数据会议相关协议

这里主要讲建立在TCP上的T.120协议。

2.5.1. T.120是什么

T.120是一个TCP之上的协议族，使用熟知端口1503。它用来提供如下的功能。

1) 数据会议

2) 白板、共享图片。

3) 文件传输。

4) 即时文本聊天。

5) 共享应用（Application sharing），这个尚未标准化。

2.5.2. T.120协议栈

图 7 T.120协议栈

图 7虚线框内所示的即是T.120的协议栈，各协议的功能请参考图中的文字说明。如想深入了解整个协议栈，请参看相关H.323等相关文档。

第3章. H.323的通信过程

3.1. 总览

图 8 一个典型的H.323的通信过程

图 8给出了一个典型的H.323通信过程。可以看出这个通信过程分为4步。

1) 建立RAS信令。这主要完成认证、地址解析等功能。

2) 建立呼叫信令。这主要是通过Setup，Alerting，Connect等步骤来完成。

3) 建立呼叫控制（即媒体控制）。这主要完成协商endpoint的能力，打开或关闭媒体逻辑信道等。

4) 传输音频或视频等信息。

需要注意的是在快速连接（Fast Connect）模式下，并没建立单独的呼叫控制信道，所有的呼叫控制信息以“隧道”的方式在呼叫信令信道中传输。

下面分步骤地来讲解一个完整的通信过程。所给的例子中，左边的终端T1向右边的终端T2发起媒体通信。当然，T1和T2所在的网络中是有Gatekeeper的，然而我们假定T1与T2是直接路由的。

3.2. 建立呼叫

图 9给出了呼叫建立的过程。图中的绿实线表示RAS信息，而黑虚线表示H.225呼叫信令信息。图中的呼叫建立过程叙述如下。

1) T1向Gatekeeper发送认可请求ARQ（Admission Request）。

2) Gatekeeper确认T1的ARQ，向T1回送ACF。

3) T1发送“Setup”信息给T2。

4) T2向T1回送一个“Call Proceeding”响应，表明呼叫正在建立中。这个时候，如果T2已经向GateKeeper注册，则转6)。

5) T2到Gatekeeper处注册。

6) T2向T1发送“Alerting”信息，表明T2正在建立呼叫。

7) T2向T1发送“Connect”信息，表明已经成功地在T1和T2间建立了呼叫连接。

图 9 建立呼叫的过程

图 10 建立呼叫控制的过程

3.3. 建立呼叫控制

图 10给出了呼叫控制的建立过程。整个建立过程比较简单，就是T1（T2）向T2（T1）发送某个请求，然后T2（T1）向T1（T2）确认相应的请求。

3.4. 传输媒体信息

图 11 媒体传输示意图

图 12 释放呼叫连接的过程

图 11给出了媒体信息传输的示意图。RTP用来提供端到端的实时运输功能，但并不保证服务质量，而配套的RTCP用来保证服务质量。

3.5. 释放呼叫连接

图 12给出了释放呼叫的示意图。整个流程大致如下。

1) T1和T2向对方发送H.245消息“End Session Command”来建议释放呼叫连接。

2) T2向T1发送H.225信令消息“Release Complete”来释放呼叫连接。

3) T1和T2各自从Gatekeeper上登出。

第4章. H.323 VS SIP

H.323 是ITU-T提出的建议标准。它是基于电信网信令和协议制定的IP多媒体标准，而不是为IP电话专门提出的。因此以H.323为标准构建的多媒体通信网很容易与传统PSTN 电话网兼容，从这点上看， H.323 更适合于构建电信级大网。国际上几乎所有的商业性 IP 电话网或视频会议网都是以 H.323 为基础的。

SIP是IETF提出的标准，对应的RFC文档为RFC3261。它利用已有的IP 网络协议提供多媒体业务，协议简单但功能也比较简单。它的设计思想是，将网络设备的复杂性推向网络边缘，是一个分散式协议。SIP适合用来构建家庭网络和小商业网络。

总体来说，H.323适合集中管理，适合用来构建电信级大网，因而在企业级应用上占有了大部分市场。而SIP实现简单，但功能也相对简单，适合用来构建小型网络，因而在家庭应用等应用上占有了很大的市场。