2024年9月1日发(作者：东依柔)
国际电信联盟
ITU-T H.323
ITU的电信标准化区段 （11/96）
H系列：视听和多媒体系统
视听服务的基础-视听服务的系统和终端设备
为局域网提供无质量保证服务的可视电话系统和设备
ITU-T协议H.323
（早期由CCITT协议）
ITU-T H系列协议
视听和多媒体系统
用于除电话用途之外的传输信道的特性
用于音频报务的电话型电路的使用
用于各种类型的电报传输或同步传输电话电路或电缆
用于传真电报的电话型电路
数据信号的特性
可视电话系统的特性
视听服务的基础构架
通则
多路传输和同步传输
系统概况
通信过程
运动视频编码
相关系统概况
视听服务系统和终端设备
细节请参见ITU-T系列协议。
H.10.19
H.20.29
H.30.39
H.40.49
H.50.99
H.100.199
H.200.399
H.200.219
H.220.229
H.230.239
H.240.259
H.260.279
H.280.299
H.300.399
ITU-T协议H.323
为局域网提供无质量保证服务的可视电话系统和设备
摘要
H.323协议描述了基于无质量保证服务的局域网（LAN）上的多媒体通信的终端，设备
和服务。H.323终端和设备可以传输实时语音、数据和视频，或上述的任意组合，包括视频
电话。
用于H.323终端通信的LAN，可以是单个网段或令牌环网，也可以是多个具有复杂拓补
结构的段。注意：基于多个LAN网段上（包括Internet）的H.323的终端工作性能可能很低。
保证这种类型的LAN/互联网的服务质量的可能方法超出了本协议的范围。
H.323终端可以被集成进PC或在像视频电话这种独立设备上实现。支持语音是必须的，
而支持数据和视频是可选的，但是一旦支持的话，就必须具备使用特定通用方式的操作的能
力，这样所有支持该媒体形式的终端就能互相协作。本协议允许每种媒体类型的多通道同时
使用。H.323系列协议还包括：H.225.0打包和同步，H.245控制，H.261和H.263视频编码
器，G.711、G.722、G.728、G.729和G.723音频编码器，以及T.120系列多媒体通信协议。
本协议利用了H.245协议的逻辑信道信令进程，当通道打开时每个逻辑信道的内容已被
描述好了。对接收器和传送器能力的表示由进程提供，因此传输被限制什么接收器能译码上，
这样接收器可以请求传送器的特定方式。由于H.245协议的进程也用于ATM网的H.310协
议以及GSTN和V.70的H.324协议中，因此与这些系统的协作应该不会要求H.225～H.245
协议的传输达到与H.320系统相同的情况。
H.323终端可以用于多点配置，也可以和B-ISDN上的H.310终端，N-ISDN上的H.320
终端，B-ISDN上的H.321终端，保证服务质量的LANs上的H.322终端，GSTN和无线网络
上的H.324终端，以及GSTN上的V.70终端相互协作。
来源
ITU-T协议 协议H.323是由ITU-T第15研究组（1993-1996）撰稿，并于1996年11月8日
经WTSC决议的NO.1程序认可。
绪言
ITU（国际电信联盟）是联合国在电信领域中的专门机构。ITU电信标准化区段（ITU-T）
是ITU的永久性机构。ITU-T负责研究技术，操作，征询问题以及在全球标准化通信方面制
定标准协议。
世界电信标准化会议（WTSC），每四年召开一次，为ITU-T研究组的研究工作制定论题，
然后ITU-T研究组为这些论题制定协议。
由ITU的成员核准的协议必须通过WTSC的NO.1解决方案的程序核实。
在信息技术的一些区域内，在ITU-T范围内，必要的标准由ISO和IEC共同制定。
说明
在本协议中，表达式管理机构是用于精确指示电信管理和识别操作机构的。
知识产权
ITU 1997保留所有的权利。
目录
1概况······································································1
2标准的参考································································2
3定义······································································3
4符号和缩写································································8
5常规······································································10
6系统描述··································································10
6.1信息流··································································10
6.2终端特性································································11
6.2.1本协议以外的终端元素··············································11
6.2.2本协议以内的终端元素··············································12
6.2.3LAN接口···························································12
6.2.4视频编码··························································12
6.2.5音频编码··························································13
6.2.6接收路径迟延······················································14
6.2.7数据通道··························································14
6.2.8H.245控制函数·····················································16
6.2.9RAS信号函数·······················································20
6.2.10呼叫信号函数·····················································20
6.2.11H.225.0层························································21
6.3网关特性································································21
6.4网闸特性································································24
6.5多点控制器特性··························································25
6.6多点处理器特性··························································26
6.7多点控制单元特性························································27
6.8多点能力································································27
6.8.1中心多点能力······················································27
6.8.2非中心多点能力····················································27
6.8.3混合多点-中心音频·················································28
6.8.4混合多点-中心视频·················································28
6.8.5建立常规模型······················································28
6.8.6多点速率匹配······················································29
6.8.7多点边缘同步······················································29
6.8.8多点加密··························································30
6.8.9级联多点控制单元··················································30
7 呼叫信号·······························································30
7.1地址····································································30
7.1.1LAN地址···························································30
7.1.2TSAP标识符························································30
7.1.3别名地址··························································30
7.2注册，管理和状态通道····················································31
7.2.1网闸的发现························································31
7.2.2端点注册··························································32
7.2.3端点定位··························································33
7.2.4许可，带宽改变，状态，断开········································34
7.3呼叫信号通道····························································34
7.3.1呼叫信号通道路由选择··············································34
7.3.2控制信道路由选择··················································35
7.4呼叫基准值······························································36
7.5会议ID和会议目标·······················································37
8 呼叫信令过程····························································37
8.1A阶段-建立呼叫··························································37
8.1.1基本呼叫建立-双方没有端点注册·····································37
8.1.2双方端点注册到同一网闸············································38
8.1.3只有主叫方端点有网闸··············································39
8.1.4只有被叫方端点有网闸··············································41
8.1.5双方端点注册到不同网闸············································42
8.1.6通过网关建立呼叫··················································46
8.1.7通过MCU建立呼叫··················································47
8.1.8呼叫转发··························································47
8.1.9建立广播呼叫······················································48
8.2B阶段-初始化通信和交换能力··············································48
8.3C阶段-建立视听通信······················································48
8.3.1模式转换··························································48
8.3.2双方协议的视频转换················································48
8.3.3媒体流地址分布····················································49
8.4D阶段-呼叫服务··························································49
8.4.1带宽改变··························································49
8.4.2状态······························································51
8.4.3特别多点会议扩展····················································51
8.4.4附加服务··························································58
8.5E阶段-呼叫结束··························································59
8.5.1不带网闸的呼叫清除················································59
8.5.2带网闸的呼叫清除··················································59
8.5.3使用网闸的呼叫清除················································60
8.6协议失败处理····························································61
9 与其他终端类型的协作····················································61
9.1只有话音的终端··························································61
9.2基于ISDN（H.320）的可视电话终端·········································62
9.3基于GSTN（H.324）的可视电话终端·········································62
9.4基于无线移动（H.324/M）的可视电话终端·································62
9.5基于ATM（H.324）的可视电话终端··········································62
9.6基于质量保证的LANs服务（H.322）的可视电话终端··························63
9.7基于GSTN（V.70）的同步语音和数据终端····································63
9.8LAN上的T.120终端·······················································63
10 可选扩展································································63
10.1加密···································································63
11 维护···································································64
11.1保护性回退·····························································64
11.2监测方法·······························································65
附件A-H.323端点使用的H.245消息···········································65
附录I-网关中Q.931消息的处理过程···········································65
ITU-T协议H.323
为局域网提供无质量保证服务的可视电话系统和设备
（Geneva，1996）
1 概述
本协议囊括了H.200/AV.120系列协议中定义的在传输路径包含一个或多个局域网
（LAN）的条件下的窄带可视电话服务的技术要求，这些局域网也许不能提供与N-ISDN相
同的质量保证服务的。这种类型的局域网有：
-以太网（IEEE 802.3）；
-快速以太网（IEEE 802.10）；
-FDDI（无质量保证服务方式）；
-令牌环网（IEEE 802.5）。
本协议囊括了在传输路径包含一个或多个局域网（LAN）的条件下的可视电话服务的情
况，这些局域网被配置成能够提供与N-ISDN相同的质量保证服务（QOS）从而使终端无需
提供任何H.320协议要求之外的附加保护性或恢复性机制的。相关的参数是数据错误和丢失
属性以及传输延迟的变化。一个恰当的LAN的例子是：综合服务（IS）局域网：IEEE 802.9A
具有载波侦听多路访问及冲突监测（CSMA/CD）媒体访问控制（MAC）服务的同步服务。
H.323终端可以用于多点配置，也可以和B-ISDN上的H.310终端，N-ISDN上的H.320
终端，B-ISDN上的H.321终端，有质量保证服务的LAN上的H.322终端，GSTN和无线网
络上的H.324终端，以及GSTN上的V.70终端相互协作。参见图1。
本协议范围不包含LAN本身，或可以用于连接不同局域网的传送层。本协议范围仅包
含与交换电路网交互（SCN）所需的元素。H.323网关，H.323终端，以及外围LAN的组合
在SCN上以H.320，H.310，H.324，或V.70终端的形式出现。
本协议描述了H.323系统的组件。其中包含终端（terminals），网关（Gateways），网闸
（Gatekeepers），多点控制器（Multipoint Controllers），多点处理器（Multipoint Processors）
和多点控制单元（Multipoint Control Units）。本协议中的控制消息（messages）和进程
（procedures）定义了这些组件如何通信。这些组件的详细描述参见条款（clause）6。
本协议中描述的组件由H.323的端点（endpoints）和实体（entities）组成。端点能通过
条款8的建立呼叫进程（call set-up procedures）呼叫（call）或被叫（callable）。然而实体是
不能被叫的，他们能被寻址（be addressed）到从而执行他们的专用功能。例如，虽然终端不
能呼叫网闸，但网闸被寻址到作为呼叫建立进程（call establishment procedures）的一部分。
Sc
H
H323.
Termnali
Non-guaranteed QOS LAN
(Note)
H323.
Gatekeeper
H323.
Gateway
H323.
Termnali
H323.
MCU
H323.
Termnai
GSTNGuaranteed
QOS
LAN
N-ISDNB-ISDN
V70.
Termnali
2
H324.
Termnali
图1/hH.323-H.323终端协作
SpeechH322.
Termnal
i
Termnali
Speech
Termnali
H320.
Termnali
H321.
Termnali
参考标准
NOTE ?Agat eway may supportone or more of he tGSTN N,-ISDNand/ or B-ISDNconnect ons.i
下列ITU-T协议和其他参考包含构成本协议的条款。在出版时，版本提示是有效的。所
有协议和其他参考易受修订；本协议的所有使用者最好查找下列协议和参考文献的最近版本。
近期有效的ITU-T协议应该定期出版。〖见H.323协议〗
3 定义
出于本协议的忠旨，H.225.0 [1]的条款3和H.245 [2]的条款3给出的定义同样适用于本
协议。这些定义只适用于LAN方面。其他用于交换电路网络（SCN）方面的术语应该会重点
指出。
3.1活动MC（active MC）：一种在主/从决定进程（master-slave determination procedure）中
获胜的MC，目前为会议提供多点控制功能。
3.2特别多点会议（ad hoc multipoint conference）：特别多点会议是一种在呼叫的某一时刻已
经扩展为多点会议的点对点（point-to-point）会议。如果初始的点对点会议的一个或多个终
端包含MC，或者呼叫是通过使用包含MC功能的网闸实现的，或初始呼叫是通过一个在两
个终端之间作为多点呼叫的MCU实现的，则特别多点会议就会发生。
3.3可寻址（addressable）：在LAN上的H.323实体有相应的传送地址。这与可被叫不同。
终端或MCU是可寻址且可被叫的。网闸是可寻址但不可被叫的。MC和MP是不可寻址也
不可被叫的，但却被包含在可寻址或可被叫的端点或网闸中。
3.4静音抑制（audio mute）： 对单个或所有声源（s）的音频信号的抑制。发送静音是指音
频数据流发生器削减自身的麦克风的噪声和/或根本不传送任何音频信号。接收静音是指接收
终端忽略某种特别的音频数据流或削减自身的喇叭的噪声。
3.5广播会议（broadcast conference）：广播会议是一种拥有一个媒体数据流发送器和多个接
受器的会议。它没有控制或媒体数据流的双向传送。如果可行的话，这种会议应该使用LAN
多用途传送设备实现。这种会议形式有待研究。
3.6广播面板会议（broadcast panel conference）：广播面板会议是多点会议和广播会议的一
种组合形式。在这种会议中，一些终端用于多点会议，而其他终端仅用于接收媒体数据流。
会议的多点端口的终端之间可以双向传送，但这些终端与收听终端之间不能双向传送。这种
会议形式有待研究。
3.7呼叫（call）：基于H.323端点之间的点对点多媒体通信。呼叫以呼叫建立进程开始，以呼
叫结束进程结束。呼叫由端点之间的可靠信道和非可靠信道的采集构成。当一些SCN端点通
过网关相互协作时，所有信道终止于网关，在网关他们被转换为SCN终端系统的适当的表示
形式。
3.8呼叫信令信道（call signalling channel）：基于二个H.323实体之间的用于传送呼叫建立和
拆除消息（遵循H.225.0协议）的可靠信道。
3.9可被叫（callable）：正如条款8中所描述的可被呼叫。终端，MCU和网关是可被叫的，
但网闸和MC是不可被叫的。
3.10集中式多点会议（centralized multipoint conference）：集中式多点会议是一种所有参加
的终端通过MCU以点对点的方式进行通信的会议。终端向MCU传送他们的控制，音频，
视频，和/或数据流。MCU中的MC集中管理会议。MCU中的MP处理音频，视频，和/或
数据流，以及向每个终端返回处理的数据流。
3.11控制和指示（C&I）（control and indication）：由控制和指示构成的终端之间的端到端信
号。其中，控制引起接收器状态的改变，指示提供系统状态或功能信息（详细信息和缩写请
参见协议H.245 [2]）
3.12数据（data）：不同于音频，视频和控制的信息流，在逻辑数据信道中传输（参见协议
H.225.0 [1]）。
3.13分散式多点会议（decentralized multipoint conference）：分散式多点会议是一种参加的
终端不使用MCU就能将他们的音频和视频数据向所有其他参加的终端发送的会议。终端负
责：
a）累计接收到的音频数据流；以及
b）选择一组或多组接收到的视频数据流用于显示。
这种情况下不需要音频或视频MP。终端在他们的H.245控制信道上使用有管理会议功能的
MC进行通信。数据流仍然由MCS-MCU集中处理，这些MCS-MCU可能包含在MP之内。
3.14端点（endpoint）：H.323终端，网关，或MCU。端点能呼叫或被叫。它产生和/或终止
数据流。
3.15网闸（gatekeeper）：网闸（GK）是在LAN上的H.323实体，它为H.323的终端、网关
和MCU提供地址转换和对局域网的控制访问。网闸也可以为终端、网关和MCU提供其他
服务，例如：带宽管理和网关定位。
3.16网关（gateway）：H.323网关（GW）是局域网上的一种端点，它提供LAN上H.323终
端与广域网络上其他ITU终端或另一个H.323网关之间的实时、双路通信。其他ITU终端包
括那些遵循协议H.310 （H.320在 B-ISDN）， H.320 （ISDN）， H.321 （ATM）， H.322
（GQOS-LAN）， H.324 （GSTN）， H.324M （移动），以及 V.70 （DSVD）的终端。
3.17 H.323实体（H.323 Entity）：任何H.323元素，包括终端、网关、网闸、MC、MP和
MCU。
3.18 H.245控制信道（H.245 control channel）：用于在H.323端点之间传送H.245控制信息
消息（遵循 H.245）的可靠信道。
3.19 H.245逻辑信道（H.245 logical channel）：用于在H.323端点之间传送信息流的信道。这
些信道的建立遵循H.245的OpenLogicalChannel进程。非可靠信道用于传送音频、音频控制、
视频以及视频控制信息流。可靠信道用于传送数据和H.245控制信息流。逻辑信道和物理信
道之间没有联系。
3.20 H.245对话（H.245 session）：呼叫的一部分开始于H.245的控制信道的建立，结束于接
收到H.245的EndSessionCommand或由于失败而结束。不要将对话与呼叫混淆，呼叫是由
H.225.0的Setup 和 Release Complete消息描述的。
3.21混合多点会议-集中式音频（hybrid multipoint conference – centralized audio）：混合多
点-集中式音频会议是一种终端向其他参加的终端多点发送他们的视频数据，以及向MP单点
发送他们的音频数据用于混合的会议。MP向每个终端返回混合的音频数据流。
3.22混合多点会议-集中式视频（hybrid multipoint conference – centralized video）：混合多
点-集中式视频会议是一种终端向其他参加的终端多点发送他们的音频数据，以及向MP单点
发送他们的视频数据用于交换和混合的会议。MP向每个终端返回混合的视频数据流。
3.23信息流（information stream）：从单个来源到一个或多个目的地的一种特定媒体信息形
式的（e.g.音频）信息流动。
3.24 LAN地址（LAN address）：由所使用的网络层协议定义的H.323实体的网络层地址（
地址）。通过网络协议中定义的规范，这种地址被映射成目标系统层上的另一个地址。
3.25唇同步（lip synchronization）：提供能感觉到显示的人物说话的动作与他的声音同步的
操作。
3.26局域网（LAN）（local area network）：一种共享或交换媒体，对等通信网络，能让适当
地域范围内的所有工作站收到广播信息，比如单个办公楼或校园。网络通常由某单个组织拥
有，使用和操作。在H.323协议中，LAN也包括通过网桥和路由器连接的几个LAN构成的
互联网。
3.27混合多点会议（mixed multipoint conference）：混合多点会议（参见图2）有一些终端 （D，
E和 F）使用集中方式参加而其他终端 （A， B和 C）在使用分散方式参加。终端并不清
楚会议的混合体制，只知道它参与的会议类型。MCU提供两种会议之间的桥接。
F
MCU
E
A
B
C
D
Unicast Audio and Video
Centralized Side
T1521210-96
Multicast Audio and Video
Decentralized Side
图2/H.233 混合多点会议
3.28 多点传送（multicast）：一种将PDU从一个源端点传送到多个目的端点的过程。这种过
程的实际机制（ 多点传送，多点-单点传送，等等）会因不同的LAN技术而不同。
3.29多点会议（multipoint conference）：多点会议是在三个或多个终端之间的会议。终端可
以在LAN或SCN上。多点会议应该总是由MC控制。本条款中定义了不同的多点会议类型
但他们每个会议都需要一个MC。在SCN上他们也可以包括一个或多个H.231 MCU。在LAN
上的终端也可以通过网关连接到SCN上的 MCU来参加SCN多点会议。这就不需要使用
MC。
3.30多点控制单元（multipoint control unit）：多点控制单元（MCU）是局域网上的一种端
点，它能提供三个或多个终端和网关参加多点会议的能力。它也可以连接在以后应该升级到
多点会议的点对点会议中的二个终端。MCU通常工作在H.231的MCU方式中，但语音处理
器并非必须的。MCU由二部分组成：必备的多点控制器和可选的多点处理器。在最简单的
情况下，MCU可以不需要MP而仅仅由一个MC组成。
3.31多点控制器（multipoint controller）：多点控制器（MC）是局域网上的一种H.323实体，
它能提供三个或多个终端参加多点会议的控制。它也可以连接在以后应该升级到多点会议的
点对点会议中的二个终端。MC提供所有终端能力协商以使通信达到普通水平。它也可以控
制会议资源，比如，是谁在多点传送视频数据。MC不执行音频、视频和数据的混合或交换。
3.32多点处理器（multipoint processor）：多点处理器（MP）是局域网上的一种H.323实体，
它能提供多点会议中音频、视频和/或数据流的集中处理。MP在MC的控制下提供媒体数据
流的混合、交换或其他处理。根据会议支持的形式MP可以处理单个或多个媒体数据流。
3.33多点-单点传送（multi-unicast）：一种传输PDU的过程，其中，端点向不同的端点发送
出一个以上相同的媒体数据流。这种传送也许在不支持多点传送的网络中是必备的。
3.34点对点会议（point-to-point conference）：点对点会议是一种基于二个终端的会议。它可
以直接基于二个H.323终端，也可以通过网关基于H.323终端和SCN终端。呼叫基于二个终
端之间（参见“呼叫”）。
3.35 RAS信道（RAS channel）：用于在二个H.323实体之间传送注册、管理、带宽改变以及
状态消息（参见协议H.225.0）的非可靠信道。
3.36可靠信道（reliable channel）：用于将信息流从源端点可靠地传送到目的端点的一种传输
连接。
3.37可靠传送（reliable transmission）：使用连接模式数据传送将消息从发送者到接收者的
传送。传送服务保证消息在传送连接中顺序的、错误释放的、流量控制的传送到接收者。
3.38 RTP对话（RTP session）：对每个参加者，对话由一对特定的目标传送地址（一个LAN
地址加上一个针对RTP和RTCP的TSAP标识符）所规定。目标传送地址对可能对于所有参
加者都是公有的，例如在IP多点传送中，也可能是对每个人都是不同的，例如在个体单点传
送网络地址中。在多媒体对话中，媒体音频和视频在分隔的RTP对话中以他们自己的RTCP
包传送。多个RTP对话以不同的传送地址区分。
3.39交换电路网（SCN）（switched circuit network）：公共或私有的交换通信网，比如GSTN，
N-ISDN，或B-ISDN。
3.40终端（terminal）：H.323终端是局域网上的端点，它提供与另一个H.323终端、网关、
或多点控制单元的实时、双路通信。这种通信包括二个终端之间的控制、指示、音频、移动
颜色视频图像和/或数据。终端可以只提供话音、话音和数据、话音和视频、或者话音、数据
和视频。
3.41传送地址（transport address）：由目前使用的网络协议组定义的可寻址的H.323实体的
传送层地址。H.323实体的传送层地址由LAN地址加上可寻址的H.323实体的TSAP标识符
组成。
3.42传送连接（transport connection）：为了传送数据而由传送层在两个H.323实体之间建立
的关联。在本协议中，传送连接提供信息的可靠传送。
3.43 TSAP标识符（TSAP identifier）：用于将单个 H.323实体上的同样类型的几路连接与所
有的连接进行多路复用并共享相同的LAN地址的信息（e.g. 在 TCP/UDP/IP环境下的端口
编号）。TSAP标识符可由一些国际权威（事先）静态指定，也可以在建立呼叫时动态分配。
动态指定的TSAP标识符是瞬时存在的，即他们的值仅在一个呼叫周期内有效。
3.44 单点传送（unicast）：一种从一个源端点到一个目的端点传送消息的过程。
3.45非可靠信道（unreliable channel）：用于从源端点到一个或多个目的端点不可靠的传送信
息流的逻辑通信路径。
3.46非可靠传送（unreliable transmission）：消息以非连接模式数据传送方式从发送者到一
个或多个接收者的传送。传送服务是PDU的最佳效果递送，即由发送者传送的消息可能被遗
失、复制、或被接收者认为无序。
3.47众所周知的TSAP标识符（well-known TSAP identifier）：由负责为特定（国际）互连网
协议和相关传送协议（e.g.为TCP和UDP端口编号分配的IANA）的分配TSAP标识符的（国
际）权威分配的TSAP标识符。这种标识符在各自协议的内容中保证是唯一的。
3.48地域（zone）：地域（参见图3）是所有终端（Tx）、网关（GW）、以及由单个网闸（GK）
管理的多点控制单元（MCU）的集合。地域至少包含一个终端，以及可能包含或不包含网关
或MCU。一个地域有且只有一个网闸。地域可以与LAN拓补结构无关，也可以由使用路由
器或其他设备连接的多个的局域网段构成。
Zone
T1
T2
GK
T3
GW
R
T4
R
图3/H.323 -地域
T5
MCU
T1521220-96
4 符号和缩写
根据本协议的忠旨，下列符号和缩写是：
4CIF
16CIF
ACF
ARJ
ARQ
BAS
BCF
BCH
4次 CIF
16次 CIF
许可确认
许可放弃
许可请求
位速率定位信号
带宽改变确认
Bose， Chaudhuri，和 Hocquengham
B-ISDN
BRQ
C&I
CID
CIF
DCF
DID
宽带综合数字服务网
带宽改变请求
控制和指示
会议标识符
共同的中间形式
放弃确认
直接内部拨号
DRQ
ECS
EIV
FAS
FIR
GCF
GK
GQOS
GRJ
GRQ
GSTN
GW
IANA
IP
IPX
IRQ
IRR
ISDN
ITU-T
LAN
LCF
LCN
LRJ
LRQ
MC
MCS
MCU
MP
MSN
N-ISDN
NACK
QCIF
放弃请求
加密控制信号
加密初始化矢量
帧定位信号
完全内部请求
网闸确认
网闸
质量保证服务
网闸放弃
网闸请求
通用电话交换网
网关
互联网指定编号权威
互联网协议
互联网协议交换
信息请求
信息请求应答
综合数字服务网
国际电信联盟标准化区
局域网
定位确认
逻辑信道编号
定位放弃
定位请求
多点控制器
多点通信系统
多点控制单元
多点处理器
多点用户编号
窄带综合数字服务网
消极确认
四分之一 CIF
RCF
RRJ
RRQ
RTP
RTCP
SBE
SCM
SCN
SPX
SQCIF
TCP
TSAP
UCF
UDP
URJ
URQ
5 约定
注册确认
注册放弃
注册请求
实时协议
实时控制协议
单比特扩展
已选通信模式
交换电路网
连续协议转换
副 QCIF
传送控制协议
传送层服务访问点
未注册确认
用户自带寻址协议
未注册放弃
未注册请求
在本协议中，使用了下列约定：
"Shall"意味着强制性要求。
"Should"意味着建议但在操作中可选。
"May"意味着在操作中可选，胜于某些已实现的协议。
对于条款、子条款、附件和附录的参考是指本协议以内的术语，除非另一个文档明确地
列表显示出来。例如，1.4是指本协议中的1.4;6.4/H.245是指协议H.245中的6.4。
当LAN和SCN中存在相同的术语，对SCN术语的将作出明确解释。例如，MCU是指
LAN上的H.323 MCU，SCN-MCU是指在SCN上的MCU。
本协议描述了三个不同消息类型的使用：H.245、RAS和Q.931。以下是不同消息类型的
区别。H.245消息和参数名由多重的连结字以粗体字突出显示构成（maximumDelayJitter）。
RAS消息名由三个字母缩写代表（ARQ）。Q.931消息名由第一个字母大写的一个或两个单
词构成（Call Processing）。
6 系统描述
本协议描述了H.323组件的元素。它们是终端、网关、网闸、MC和MCU。这些组件通
过信息流的传送进行通信。本条款中将描述这些组件的特性。
6.1信息流
可视电话组件通过信息流的传送进行通信。这些信息流分为如下的视频、音频、数据、
通信控制和呼叫控制。
音频信号包含数字化语音和编码语音。为了减少音频信号的平均位速率，需要提供语音
激活。音频信号伴随着音频控制信号。
视频信号包含数字化视频和移动编码视频。由于能力交换，视频以不大于采样频率的速
率进行传送。视频信号伴随着视频控制信号。
数据信号包含静态图像、传真、文档、计算机文件和其他数据流。
通信控制信号在类似于远程功能元素之间传送控制数据，并用于能力交换、打开和关闭
逻辑信道、方式控制和其他部分通信控制功能。
呼叫控制信号用于呼叫建立、断开和其他呼叫控制功能。
上述信息流是规定格式的，并按照协议H.225.0中所描述的传送到网络界面。
6.2终端特性
图4是H.323终端一个例子。图中显示了用户设备界面、视频编码器、音频编码器、远
程信息处理设备， H.225.0层、系统控制功能和与LAN交互的界面。所有H.323终端应该有
一个系统控制单元、H.225.0层、网络界面和音频编码器单元。视频编码器单元和用户数据应
用程序是可选的。
323.H oe pcoS
tenmpiueq OI/ eodiV
ecdoC eodiV
362.H ,162.H
eveceiR
hatP
ayelD
tenmpiueq OI/ oiduA
ecdoC oiduA
,227.G ,117.G
,827.G ,327.G
927.G
snoicatilppAa atDser U
c.,t e0.21T
lrotnoC emstyS
lrotnoC 542.H
lrotnoC emstyS
erfacetInser U
lrotnoC alC
0.522.H
l
rotnoC SAR
图4/H.323 - H.323终端设备
0.522.H
6.2.1本协议以外的终端元素
下列元素不属于本协议范围内，因此没有在本协议中定义：
0.522.H
erayL
附属音频设备提供语音激活感应、麦克风和喇叭、电话工具或等价物、多重的麦克风混
频器、以及回声消除器。
附属视频设备提供照相机和监视器以及他们的控制和选择，改善压缩或提供分屏功能的
视频处理。
使用T.120的数据应用程序和相关的用户界面或基于数据通道的其他数据服务。
附属网络界面，它提供与LAN的界面，支持适当的信号和电平，遵循国内和国际标准。
人类用户系统控制、用户接口和操作。
6.2.2本协议以内的终端元素
下列元素属于本协议范围内，因此易于标准化并在本协议中定义：
视频编码器（H.261等等）把从视频源（i.e.照相机）传来的视频编码传送出去以及将接
收到的视频代码解码并输出到视频显示器。
音频编码器（G.711等等）把从麦克风传来的音频信号编码传送出去以及将接收到的音
频代码解码并输出到喇叭。
数据通道支持远程信息处理应用程序如电子白板、静态图象传输、文件交换、数据库访
问、可视会议等等。用于实时可视会议的标准化数据应用程序是协议T.120。其他应用
程序和协议也可以通过在 6.2.7中指定的H.245协商使用。
系统控制单元（H.245，H.225.0）为 H.323终端适当的操作提供信号。它提供呼叫控制、
能力交换、命令和指令的信号化以及消息打开并完全描述逻辑信道的内容。
H.225.0层（H.225.0）使传送的视频、音频、数据和控制流转化成消息格式从而输出到
网络界面，以及从网络界面输入的消息中恢复接收到的视频、音频、数据和控制流。此
外，它执行适合每种媒体形式的逻辑分帧、顺序编号、错误检测和错误改正。
6.2.3 LAN界面
LAN界面是专用的实现，而且已超出了本协议范围之外。尽管如此，LAN界面应该提
供在H.225.0协议中描述的服务。这包括以下内容：可靠的（， SPX）端对端服务是
H.245控制信道、数据信道以及呼叫信号通道必备的；非可靠的 （， IPX）端对端
服务是音频信道、视频信道、以及 RAS信道必备的；这些服务可以是双工的或单工的，单
点传送或多点传送，这取决于应用程序、终端能力以及LAN的配置。
6.2.4视频编码器
视频编码器是可选的。所有提供视频通信的H.323终端应该能够根据H.261 QCIF对视频
进行编码和译码。终端也可以任意根据 H.261 CIF或H.263 SQCIF、QCIF、CIF、4CIF，以
及16CIF对视频进行编码和译码。如果终端能以CIF或更高的分辨率支持H.263，则它也能
以CIF支持H.261。所有支持H.263的终端应该能以QCIF支持H.263。在LAN上使用H.261
和H.263编码器不应该包含BCH错误纠正和错误纠正帧。
其他视频编码器以及其他图片格式，也可以通过H.245协商使用。一个或多个视频信道
按照通过H.245控制信道协商的方法也可以被传送和/或被接收。H.323终端可以任意同时传
送一个以上视频信道，例如，传送演讲者和一秒视频源信号。H.323终端可以任意同时接收
一个以上视频信道，例如，显示分布式多点会议多个参加者。
H.261协议定义了CIF和QCIF。H.263协议定义了SQCIF、4CIF和16CIF。就H.261算
法而言，SQCIF是任何尺寸小于QCIF的活动图片，由黑边框填充，并以QCIF格式编码。
所有这些格式，像素纵横比跟CIF格式一样。
说明-H.263 SQCIF导致的图片纵横比不同于其他格式。
视频位速率、图片格式以及解码器能够接受的算法选择在使用H.245进行能力交换时定
义。编码器可以自由传送在解码器能力范围之内的任何东西。解码器应该能够通过H.245为
某种特定模式产生请求，但如果他们不是命令模式，编码器可以允许简单地忽略这些请求。
指示某种特定的算法选项能力的解码器也应该能够接受没有使用那种算法选择的视频比特
流。
H.323终端应该能够在对称呼叫视频位速率、帧速率下运作，而且如果支持双图片以上
的分辨率的话，也能在该图片分辨率下运作。例如，有此能力的CIF终端应该能在接收 CIF
图像时传送 QCIF。
当每个视频逻辑信道打开时，包含使用最大操作模式信道信息的H.245
OpenLogicalChannel消息应该传送给接收者。最大模式信号包含最大图片格式、算法选择、
最大编码器位速率等等。视频逻辑信道中的标题指示了在既定最大模式下每幅图片实际采用
的模式。例如，为CIF格式打开的视频逻辑信道可以传送CIF、QCIF或SQCIF图像，但不
能传送4CIF或16CIF图像。仅以 unrestrictedVector和 arithmeticCoding选项打开的视频逻辑
信道可以两者都不使用，或者使用其中之一，或者两者都用，但不能使用没有信号指定的选
项。
视频数据流采用H.225.0协议中描述的格式。
6.2.4.1基于终端的连续显示
H.323终端可以接收到一个以上视频信道，特别是在多点会议中。在这些情况中，H.323
终端可能需要执行视频混合或交换功能从而能为用户显示视频信号。这种功能可能包括从一
个以上终端向用户显示图像。H.323终端应该使用H.245同步功能来指示它能够对多少同步
视频数据流解码。终端同步功能不应限制会议中属于多点传送的视频数据流的编号（由MC
决定）。
6.2.5音频编码器
所有H.323终端应该有音频编码器。所有H.323终端应该能根据G.711协议对语音进行
编码和译码。所有终端应该能够传送和接收A-律和u-律信号。终端可以任意根据协议 G.722、
G.728、G.729、MPEG 1音频，以及G.723对语音进行编码和译码。编码器使用的音频算法应
该在使用H.245进行能力交换时获得。H.323终端应该能够对在其语音能力范围内的所有语
音能力进行非对称呼叫操作，例如，如果它能够遵循G.711和G.728，那么它就能传送 G.711，
也能接收 G.728。
音频数据流采用H.225.0协议中描述的格式。
H.323终端可以同时任意传送一个以上音频信道，例如，允许二路语言被传送。
音频数据包应该定期递送给传送层，时间间隔由使用的音频编码器协议决定（音频帧间
隔）。每个音频数据包的递送应该在从第一个音频帧发送开始计算的（音频延迟抖动）一整个
音频帧间隔后5 ms之内发生。音频编码器也可以使用包含在终端能力设置消息内的由H.245
协议的h2250Capability结构的maximumDelayJitter参数来进一步限制他们的声音延迟抖动
的能力，这样，接收者可以任意减少他们的抖动延迟缓冲区。这与RTCP间隔抖动区域不同。
说明-对最大延迟抖动的测试点是在网络传送层的输入端。不包括网络堆栈、网络、驱动器和
界面卡片抖动。
6.2.5.1音频混合
H.323终端可以接收一个以上音频信道，特别是在多点会议中。在这些情况中，H.323
终端可能需要执行音频混合功能从而能为用户重现合成语音信号。H.323终端应该使用H.245
同步功能来指示它能够对多少同步音频数据流解码。终端同步功能不应限制会议中属于多点
传送的音频数据流的编号。
6.2.5.2最大音频-视频传送时滞
为了允许H.323终端能适当的设置他们的接收缓冲池（s）大小， H.323终端应该在向
网络传送时传送h2250MaximumSkewIndication消息指示音频和视频信号之间最大时滞。
h2250MaximumSkewIndication应该发送给每对音频和视频组合逻辑信道。对于仅有音频信号
或混合会议唇同步是没有这个要求的，如果要求的话，终端可以通过使用时间戳来实现。
6.2.6接收路径延迟
接收路径延迟包含为保持同步而叠加在媒体数据流上的延迟和网络数据包到达时间的
抖动的累计。媒体数据流可以在接收器处理路径上任意延迟从而保持与其他媒体数据流的同
步。具体地说，就是媒体数据流可以任意延迟从而允许网络延迟引起数据包到达时间的抖动。
H.323终端不应该因此而在它的传送媒体路径上加延迟。
中间处理点如MCU或网关可以改变视频和音频的时间标记信息，而且也应该适当的传
送修改了的音频和视频时间标记以及顺序编号，映射他们的传送信号。接收端点可以在音频
路径上加适当的延迟从而达到唇同步。
6.2.7数据通道
一个或多个数据通道是任选的。数据通道可以是单向或双向的，这取决于数据应用程序
的要求。T.120协议是数据在H.323终端和其他H.323， H.320，或 H.310终端交互的默认基
础。使用一个或多个可通过H.245协商的ITU-T协议可以实现任何可选的数据应用程序，等
价的T.120应用程序，若有的话，应该是那些提供的协议之一。使用H.281和 H.224提供远
程-端点照相机控制的终端并不要求也支持 T.120远程-端点照相机控制协议。
注意，不管等价T.120应用程序是否支持，非标准数据应用程序（dataApplicationCapability
=非标准应用程序， dataProtocolCapability =非标准）和透明用户数据
（dataApplicationCapability = 用户应用程序， dataProtocolCapability = 透明）都会被使用。
T.120能力应该使用 dataApplicationCapability = t120应用程序， dataProtocolCapability =
separateLANStack 来标识。
数据通道采用H.225.0协议中描述的格式。
6.2.7.1 T.120数据通道
在 H.323呼叫内容中有二种建立 T.120连接的方法。一是当 H.323呼叫作为呼叫的内部
呼叫部分，使用H.245的进程打开逻辑信道时建立 T.120连接。二是在H.323呼叫之前建立
T.120连接。
在H.323呼叫先建立的情况下，随之而来的是8.1的普通呼叫过程。能力交换发生，以
及根据普通 H.245进程双向逻辑信道应该为 T.120连接打开，指示一个新连接应该按如下描
述创建。
为 T.120打开的双向逻辑信道可以由任意实体传送的 openLogicalChannel初始化，然后
遵循H.245协议的双向逻辑信道进程。
为了实际打开逻辑信道，初始化实体应该传送 openLogicalChannel消息，以
forwardLogicalChannelParameters和reverseLogicalChannelParamete指示T.120数据通道应该
被打开。初始化者应该决定是否在 openLogicalChannel消息中包含传送地址。如果对方（应
答器）接受了该逻辑信道，它应该用 openLogicalChannelAck确认逻辑信道的打开。在
openLogicalChannelAck中，应答器应该包含用于建立T.120连接的传送地址，如果它没有收
到初始化者传来的传送地址。否则，就会缺少传送地址。在这两种情况中， 用于T.120连接
的传送地址应该由separateStack参数传送。
实体传输传送地址应该为在该传送地址接受 T.120连接作准备。实体接收传送地址应该
使用前面接收到的传送地址为建立T.120连接初始化。
在openLogicalChannel和openLogicalChannelAck消息中，associateConference参数应该
设置为false。
T.120协议应该遵循T.123协议关于由dataProtocolCapability标识的协议栈的进程，但上
述传送地址应该为建立连接所专用的情况除外。 H.245主/从决定进程的获胜者应该有权成为
T.120连接中的上层节点。
说明：完成建立连接的T.120操作超出了本协议的范围。
在 T.120连接先建立的情况下，H.323呼叫跟随在8.1的普通呼叫建立进程之后。能力
交换发生，而且它应该将T.120连接和H.323呼叫关联起来。H.245协议的进程用于为 T.120
数据通道打开双向逻辑信道，如下详述。
为T.120打开的双向逻辑信道可以由任意实体传送的openLogicalChannel初始化，然后
遵循H.245协议的双向逻辑信道进程。建立连接的初始化者应该在openLogicalChannel消息
中包含已经存在的T.120连接的标识信息，指示对方哪一个T.120连接（如果有一些的话）
应该被关联。
为了实际打开逻辑信道，初始化实体应该为双向逻辑信道传送openLogicalChannel消息，
以forwardLogicalChannelParameters和reverseLogicalChannelParameters指示T.120数据通道应
该被打开。如果对方（应答器）接受了该逻辑信道，它应该返回一个 openLogicalChannelAck
给初始化者，该消息中可能包含了它自身用于传送连接的本地标识符。在这两种消息中，
associateConference参数应该设置为true。
作为标识信息，T.120连接的初始传送连接的本地（动态例示）传送地址应该由
separateStack参数提供。此外，externalReference参数用于提供哪一个T.120连接应该被关联
的进一步信息。
如果没有任何标识信息对初始化者有效，初始化者应该省略各自的值（s）。
说明-如果传送地址不明确而且二个端点共享了一个以上的T.120连接，那么接收者就不能明
确所指的是哪一个T.120连接。这种模糊的含意和避免它出现的方法有待研究。
6.2.8 H.245控制功能
H.245控制功能使用H.245控制信道传送端对端管理H.323实体的操作的控制消息，包
括能力交换、逻辑信道的打开和关闭、流控制消息以及常用命令和指令。
H.245信令在二个端点之间建立：一个端点和一个MC，或一个端点和一个网闸。端点
应该为每一个有端点参加的呼叫建立一条明确的H.245控制信道。信道应该使用H.245的消
息和进程。注意：终端、MCU、网关或网闸可以支持多个呼叫，于是就有多个H.245控制信
道。H.245控制信道应该由逻辑信道0承担。逻辑信道0应该被认为是从H.245控制信道的
建立开始就永久开放的，直到关闭H.245控制信道。普通的打开和关闭逻辑信道的进程不应
适用于H.245控制信道。
H.245协议指定了许多支持端对端信号的独立协议的实体。协议实体是由它的语法（消
息）、语义以及指定消息交互和用户交互的一系列进程定义的。H.323端点应该支持语法、语
义以及下列协议实体的进程：
主/从决定。
能力交换。
逻辑信道信令。
双向逻辑信道信令。
关闭逻辑信道信令。
模式请求。
环路延迟决定。
环路保持信令。
常用命令和指示应该从H.245协议包含的消息集中抽取出来。另外，其他已经指定了用
于带内传输视频、音频或数据流的命令和指示信号可以被传送出去（如果这样的信号已经被
定义，请参见适当的协议作出决定）。
H.245消息分为四类：请求、响应、命令以及指示。请求和响应消息由协议的实体使用。
请求消息需要接收者的专用操作，包括立即应答。应答消息响应相应的请求。命令消息需要
专用操作，但不需要应答。指示消息仅仅是情报性的，且不需要任何操作或应答。H.323终
端应该响应附件A中指定的所有H.245命令和请求，而且应该传送反映终端状态的指示。
H.323终端应该能够剖析所有H.245 MultimediaSystemControlMessage消息，而且应该发
送和接收所有实现必需功能以及终端支持的可选功能的消息。附件A包含的表格显示出对于
H.323终端哪些 H.245消息是命令的、可选的或禁止的。H.323终端应该发送
functionNotSupported消息来响应任何未被确认的请求，应答，或它接收到的命令消息。
H.245指示，userInputIndication，对用户从键区或键盘输入的有效文字数字字符的传送
是有效的，等价于用于类似电话技术的DTMF信号，或协议H.230中的SBE编号消息。这
个指令可以用于手动操作远程设备如语音电子邮件或视频邮件系统、菜单驱动方式信息服务
等等。H.323终端应该支持用户输入字符0-9、“*”和“#”的传送。其他字符的传送是可选
的。
说明-如果使用了本协议的加密进程，H.245控制信道不会被加密。因此用户要警惕H.245控
制信道中用户数据的托架，非标准消息的使用，以及从H.245控制信道的流量分析中得出的
可能危险。
三个H.245请求消息与RTCP控制包冲突。H.245 videoFastUpdatePicture，
videoFastUpdateGOB和videoFastUpdateMB请求应该用于代替充满节点内请求（FIR）和否
定承认（NACK）的RTCP控制包。接受FIR和NACK的能力在H.245能力交换时转换成信
号。
6.2.8.1能力交换
能力交换应该遵循H.245协议的进程，该进程提供了分隔接收和发送的能力，以及终端
可以同时描述它在各种模式的组合中的操作能力。
接收能力描述了终端接收和处理输入信息流的能力。发送者应该限制他们发送的信息含
量符合接收者表明的它能够接收的能力。缺乏接收能力意味着终端不能接收数据 （仅仅是个
发送者）。
发送能力描述了终端发送信息流的能力。发送能力用来向接收者提供可能的操作方式，
这样接收者可以请求它的最佳接收方式。缺乏发送能力意味着终端不能向接收者提供最佳接
收方式（但它仍然可以在接收者的能力范围之内发送一些数据的）。
发送终端为每个独立的方式指定终端，这些终端能够以capabilityTable中的编号操作。
例如，G.723音频，G.728视频，以及CIF H.263视频应该分别被指定单独的编号。
这些能力编号被分组成alternativeCapabilitySet结构。每个alternativeCapabilitySet意味着
终端只能以设置中的一种确定的方式操作。例如，列出了{G.711，G.723，G.728}的
alternativeCapabilitySet意味着终端能够以这些音频方式中的任意一种方式工作，但不能多于
一种方式。
这些alternativeCapabilitySet结构被分组成simultaneousCapabilities结构。每个
simultaneousCapabilities结构意味着终端能够同时使用的一系列方式。例如，
simultaneousCapabilities结构包含二个alternativeCapabilitySet结构{H.261，H.263}和{G.711，
G.723，G.728}，意味着终端能同时操作任何一个视频编码器和任何一个音频编码器。
SimultaneousCapabilities系列{{H.261}，{H.261， H.263}，{G.711，G.723，G.728}}意味着终
端能同时操作二个视频信道和一个音频信道：一个遵循H.261的视频信道，一个遵循H.261
或H.263的视频信道，一个遵循G.711或G.723或G.728的音频信道。
说明-存储于capabilityTable中的实际能力通常比上述提到的更复杂。例如，每个H.263能力
意味着包含支持不同的图片格式在给定的最小图片间隔的能力，以及使用可选的编码方式的
能力的具体细节。具体描述请参见H.245协议。
终端总能力由一套capabilityDescriptor结构描述，其中每一个都由一个
simultaneousCapabilities结构和capabilityDescriptorNumber组成。通过传送一个以上
capabilityDescriptor，终端可以依靠所描述的能够同时使用的不同的系列方式来用信号通知操
作方式之间的依赖关系。例如，一个终端拥有二个capabilityDescriptor结构，一个是前例中
的{{H.261，H.263}，{G.711，G.723，G.728}}，而另一个是{{H.262}，{G.711}}，这意味着终
端能够操作H.262视频编码器，但只能和G.711低复杂度音频编码器同时使用。
终端可以在一个通信对话期内通过发送附加capabilityDescriptor结构来动态地增加性能，
或通过发送修改了的 capabilityDescriptor结构来删除性能。所有的H.323终端应该能传送至
少一个capabilityDescriptor结构。
非标准性能和控制消息可以用H.245协议中定义的nonStandardParameter结构产生。注
意：当非标准消息的含义由个体组织定义后，如果这种定义是众所周知的，那么任何厂商生
产的设备可以以任何非标准消息为信号。
根据H.245协议的进程，在任何时候终端都可以再产生性能集合。
6.2.8.2逻辑信道信令
每个逻辑信道从一个发送者向一个或多个接收者传送信息，并且由一个逻辑信道编号识
别，这个逻辑信道编号是为每个传送方向专用的。
逻辑信道通过使用openLogicalChannel和closeLogicalChannel消息和H.245协议的进程
打开和关闭。当逻辑信道打开时，openLogicalChannel消息完全描述了逻辑信道的内容，包
括媒体类型、使用的算法以及接收者需要解释逻辑信道的内容的其他所有信息。当不再需要
使用时，逻辑信道可以被关闭。打开逻辑信道可以是非激活的，如果消息源没有信息需要传
送的话。
本协议中，大多数逻辑信道是单向的，这样非对呼叫操作，即在每个传送方向上信息流
的编号和类型是不同的，是可以进行的。然而，如果接收者仅能操作某种特定的对称呼叫方
式，除了本协议特别指出以外，它可以发送一个接收性能集来反映它的限制。终端也能够仅
在一个传送方向上使用特别的方式传送。某种特定的媒体类型，包括数据协议如T.120，他
们的操作需要固有的双向信道。在这种情况下，一对单向逻辑信道，每个方向各一个，可以
使用H.245协议的双向信道打开进程打开并关联在一起形成双向信道。这对关联的信道不需
要共享相同的逻辑信道编号，因为逻辑信道编号在每个传送方向上是独立的。
逻辑信道应该按照下列进程打开：
初始终端应该发送H.245协议中描述的OpenLogicalChannel消息。如果逻辑信道要使用
RTP传送媒体类型（音频或视频），则OpenLogicalChannel消息应该包含 mediaControlChannel
参数，该参数包含RTCP反向信道的传送地址。
应答终端应该以H.245协议中描述的OpenLogicalChannelAck消息应答。如果逻辑信道
要使用RTP传送媒体，则OpenLogicalChannelAck消息应该包含mediaTransportChannel参数
和mediaControlChannel参数，其中，mediaTransportChannel参数包含媒体信道的RTP传送地
址，mediaControlChannel参数包含前向RTCP信道的传送地址。
没有使用RTP/RTCP的媒体类型（比如T.120数据）应该省略mediaControlChannel参数。
如果一个相应的反向信道为一个特定存在的RTP对话（由RTP sessionID识别）打开，
则由OpenLogicalChannel进程交换的mediaControlChannel传送地址应该与那些使用了前向信
道的相同。如果发生了冲突，即两端点同时企图建立冲突的RTP对话，主端点应该按照H.245
协议中描述的那样，拒绝冲突企图。然后，被拒绝的OpenLogicalChannel企图可以在稍后时
间再试。
6.2.8.3方式选择
接收者可以请求发送者使用H.245 requestMode消息发送一个描述最佳方式的特别方式。
如果可能的话，发送者应该服从该请求。
从MC接收到multipointModeCommand的端点应该服从所有requestMode命令，如果命
令请求在它们的能力集之内的话。注意：在分散会议中，就象在集中会议中一样，所有终端
的requestMode命令是指向MC的。MC可以授予请求或不授予；决定权留给厂商。
6.2.8.4主/从决定
H.245主/从决定进程用于解决都能成为会议的MC的二个端点之间，或企图打开一个双
向通道的二个端点之间的冲突。在这一进程中，二端点在H.245 masterSlaveDetermination消
息中随机地交换编号，决定主/从工作端点。H.323端点应该将terminalType的值设置成下表
1中指定的值，将statusDeterminationNumber的值设置成0～2
24
-1范围内的随机数。每个呼
叫的端点应该只能选择一个随机数，除了H.245协议中描述的相同的随机编号的情况。
表1/H.323 - H.245主/从决定的H.323终端类型
终端类型值列表
特征系列 终端
H.323实体
网关 网闸
MCU
没有MC的实体
包含MC但没有MP的实体
包含带有数据MP的MC的实体
包含带有数据和音频MP的MC的实体
包含带有数据、音频和视频MP的MC的实
体
50
70
NA
NA
NA
60
80
90
100
110
NA
120
130
140
150
NA
160
170
180
190
会议中的活动MC应该使用值240。层叠MC有待研究。
如果单个H.323实体能参与多重呼叫，那么在主/从决定进程中terminalType使用的值应
该基于H.323实体已经或将要分配给呼叫信令的特征。
已经充当了MC的MC应该总是保持活动MC。因此，一旦一个MC已经被选定作为会
议的活动MC，那么在会议的所有后来的连接中都应该使用活动MC值。
如果没有MC是活动的而且实体都是相同类型，那么实体最高特征设置的H.323实体（如
表1所示）应该在主/从决定中获胜。如果没有MC是活动而且实体是不同类型，那么位于
MCU中的MC应该具有比位于网闸中的MC高的优先级，位于网闸中的MC的优先级高于
位于网关中的MC，当然，位于网闸中的MC的优先级相应的高于位于终端中的MC。
如果H.323实体能与表1中二个以上的分类相关联，那么它应该使用它具有的最高值。
6.2.8.5定时器和计数器的值
所有H.245协议中定义的定时器应该有至少与传送H.245控制信道的数据链路层（包括
任何重传）允许的最大数据递送时间一样长的周期。
H.245重算计数器N100应该至少是3。
与H.245协议错误处理相关的进程在8.6中详述。
6.2.9 RAS信令功能
RAS信令功能使用H.225.0消息执行注册、许可、带宽变化、状态以及端点和网闸之间
的断开过程。RAS信令信道独立于呼叫信令信道和H.245控制信道。H.245打开逻辑信道进
程不能用于建立RAS信令信道。在没有网闸的LAN环境中没有使用RAS信令信道。在包含
网闸（地域）的LAN环境中，RAS信令信道在端点和网闸之间打开。RAS信令信道的打开
先于任何其他位于H.323端点之间的信道的建立。这一信道在条款7中详细描述。
6.2.10呼叫信令功能
呼叫信令功能使用H.225.0呼叫信令在H.323二个端点之间建立连接。呼叫信令信道独
立于RAS信道和H.245控制信道。H.245打开逻辑信道进程不能用于建立呼叫信令信道。呼
叫信令信道的打开先于位于H.323端点之间的H.245信道和任何其他信道的建立。在没有网
闸的系统中，呼叫信令信道在包含于呼叫中的二个端点之间打开。在包含网闸的系统中，呼
叫信令信道在端点和网闸之间，或由网闸选中的端点之间打开。这一信道在条款7中详细描
述。
6.2.11 H.225.0层
视频、音频、数据或控制信息的逻辑信道是根据H.245协议的进程建立的。逻辑信道是
单向的，而且在每个传送方向上是独立的。一些逻辑信道，比如数据，可能是双向的，而且
与H.245协议打开双向逻辑信道的进程相关联。每种媒体类型的任何逻辑信道编号是可传送
的，但每一个呼叫都必须有一个控制信道的H.245控制信道除外。除逻辑信道之外，H.323
端点为呼叫控制使用二个信令信道，以及网闸的相关功能。这些信道使用的格式应该遵循
H.225.0协议。
6.2.11.1逻辑信道编号
每个逻辑信道由一个范围在0～65535的逻辑信道编号（LCN）标识，逻辑信道编号仅
用于将逻辑信道和传送连接关联起来。逻辑信道编号由传送者任意选定，但逻辑信道0应该
被永久地分配给H.245控制信道。传送者应该传送的实际传送地址，应该由接收者以
openLogicalChannelAck消息返回。
6.2.11.2逻辑信道位速率限制
逻辑信道的带宽应该有一个上限，这个上限由端点的传送能力（如果是当前值）和接收
端点的接收能力的最小值决定。基于这一限制，端点应该以等于或小于该限制的位速率打开
逻辑信道。传送者应该在以等于或小于打开逻辑信道的位速率传送的逻辑信道内传送信息流。
这种限制适用于包含逻辑信道的内容（s）的信息流，但它不包括RTP消息头，RTP有效负
载消息头以及LAN消息头和其他头上信息。
H.323端点应该服从H.245的flowControlCommand消息，这个消息规定了对逻辑信道的
位速率或所有逻辑信道的位速率累计的限制。试图限制逻辑信道位速率或所有逻辑信道的位
速率累计的H.323端点，应该将flowControlCommand消息发送给传送端点。
当终端没有信息向给定信道发送时，终端不应该发送信息。为了保证一定的数据码率，
填充数据不应该在LAN上发送。
6.3网关特性
网关应该在传送格式之间（例如H.225.0到/从H.221）和通信进程之间（例如 H.245到/
从 H.242）提供适当的翻译。网关也应该在LAN和SCN上执行呼叫建立和清除功能。视频、
音频和数据格式之间的翻译也可以在网关中进行。通常，网关的目的（当不充当MCU时）
是以透明方式向SCN端点反映LAN端点的特性，以及反向翻译。
H.323端点可以在相同LAN上直接与另一个H.323端点通信，而且不需要网关。如果与
SCN终端（终端不在LAN上）的通信未被要求的话，可以省略网关。它也可以使在一段LAN
上的终端通过路由器或低带宽链接，从一个网关呼叫再通过另一个网关返回到LAN上成为
可能。
网关有LAN上H.323终端或MCU的特性，以及SCN上SCN终端或MCU的特性。终
端或MCU的选择留给厂商。网关提供不同终端类型之间的必要转换。注意：网关可以最初
作为终端工作，但稍后使用 H.245信号为初始是点对点的相同的呼叫充当MCU。当终端/网
关向网闸注册后，网闸就知道哪一个终端是网关。
在SCN和LAN之间传送T.120数据的网关可以包含T.120 MCS提供者，该提供者将LAN
上的T.120 MCS提供者与SCN上的T.120 MCS提供者连接起来。
四个H.323网关的例子显示在图5中。该图显示了H.323终端或MCU的功能，SCN终
端或MCU的功能，以及转换功能。H.323终端功能有6.2中描述的特性。H.323 MCU功能有
6.5中描述的特性。对LAN上其他H.323终端而言，网关可以看成是一个或多个H.323终端，
或 H.323 MCU。它使用本协议中的进程与其他H.323终端通信。
SCN终端或MCU的功能在适当的协议中（H.310， H.320， H.321， H.322， H.324，
V.70， GSTN或 ISDN语音终端）有特性描述。对SCN上的终端而言，网关可以看成是一
个或多个相同终端类型或MCU。它在SCN上使用相应协议中对该终端描述的进程与该终端
通信。SCN信令进程，包括类似于对SCN而言，是否将H.323网关看成终端或网络的问题
等，均超出了本协议的范围。注意：网关不需要通过H.320就可以直接将H.323转换成H.324
或H.310。
支持GSTN或ISDN上只有语音的终端的互联的网关应该产生并检测DTMF信号在0-9、
*和#范围内与H.245 userInputIndications相符。
LAN
H323.
Termnali
Functoni
Conversion
Functoni
SCN
Termnali
Functoni
Gateway A
LAN
H323.
MCU
Functoni
Conversion
Functoni
SCN
Termnali
Functoni
Gateway B
LAN
H323.
Termnali
Functoni
Conversion
Functoni
SCN
MCU
Functoni
Gateway C
LAN
H323.
Conversion
MCUFunctoni
图5/H.323 - H.323网关配置转换
Functoni
SCN
MCU
Functoni
转换功能提供了两个不同协议终端之间的传送格式、控制、音频、视频和/或数据流的必
Gateway D
要转换。至少，网关应该为传送格式、呼叫建立信号和进程以及通信控制信号和进程提供转
换功能。必要时，网关应该提供H.242到H.245的转换。网关执行H.225.0呼叫信令和SCN
信令系统（Q.931， Q.2931，等等）之间的适当的转换。LAN上的Q.931消息和SCN上的
Q.931消息之间的转换在附录A中描述。
网关从ISDN端点接收到的所有Q.931信号以及不适用于网关的信号应该被通过并传向
下一个LAN端点，反之亦然。这种信号包含Q.932和Q.950系列消息。这样就能使H.323
端点实现其他协议中规定的补充的服务。其他SCN呼叫信号系统的过程有待研究。
本协议描述了一个LAN上的H.323终端通过网关与一个SCN上的外部终端的连接。能
与网关通信的H.323终端的实际编号是不需要标准化的。同样地，SCN连接的编号，同步独
立会议的编号，音频/视频/数据转换功能，以及是否包含多点功能是由厂商决定的。如果网
关包含在LAN上的MCU功能，那么该功能应该是LAN上的H.323 MCU。如果网关包含在
SCN上的MCU功能，那么它将以SCN上的H.231/H.243 MCU，或用于H.310或H.324系统
的MCU（这些MCU在相应的协议中将有待研究）的形式出现。
网关可以通过SCN与其他网关连接从而提供不在相同LAN上的H.323终端的通信。
提供LANs之间的透明网络互连而不使用H.320的设备（比如路由和远程拨号单元）不
是本协议范围内定义的网关。
6.4网闸特性
网闸在H.323系统中是任选的，它提供对H.323端点的呼叫控制服务。一个以上网闸可
以一种非固定模式出现并互相通信。虽然网闸与端点是逻辑分开的，但它物理上可以与终端，
MCU，网关，MC，或其他非H.323 LAN设备共存。
当网闸在系统中出现时，它应该提供下列服务：
地址转换-网闸应该将别名地址转换为传送地址。这种转换应该使用一个转换表，转换表
使用在条款7描述的Registration消息更新。使用其他更新转换表的方法也可以。
许可控制-网闸应该使用ARQ/ACF/ARJ H.225.0消息授权LAN访问。这种授权可以基于
呼叫授权，带宽，或留给厂商决定的其它一些标准，也可以是一种无效的功能，这样将
允许所有请求的访问。
带宽控制-网闸应该支持BRQ/BRJ/BCF消息。这种控制可以基于带宽管理，也可以是无
效的功能，后者将意味着接受所有带宽变化的请求。
地域管理-网闸应该为已经按7.2所述与它注册的终端，MCU，以及网关提供上述功能。
网闸也可以执行其他任选的功能，比如：
呼叫控制信令-网闸可以选择是否完成与端点的呼叫信令，也可以自己处理呼叫信令。或
者，网闸可以引导端点使呼叫信令信道直接彼此互联。这样，网闸能避免处理 H.225.0
呼叫控制信号。为了支持增补服务，网闸可能不得不充当作为Q.931协议中规定的网络。
这种操作有待研究。
呼叫授权-通过使用H.225.0信令，网闸可以拒绝从终端传来的由于授权失败的呼叫。拒
绝的理由可以包括但不限于下列原因：到/从特定终端或网关的严格访问，以及在确定时
段之内的严格访问。决定授权通过或失败的标准超出了本协议的范围。
带宽管理-H.323终端编号的控制允许同时访问LAN。通过使用H.225.0信令，网闸可以
拒绝从终端传来的由于带宽限制的呼叫。当网闸发现网络上没有足够的可用带宽支持呼
叫时就会出现这种情况。决定带宽是否可用的标准超出了本协议的范围。注意：这可以
是无效的功能，即所有终端都被授权访问。在活动呼叫中当终端请求附加带宽时，这个
功能也会起作用。
呼叫管理-例如，网闸可以保持进行的H.323呼叫的列表。这一信息对于指示呼叫终端忙
也许是必要的，并且为带宽管理功能提供信息。
网闸管理信息数据结构-有待研究。
不具备本功能的终端的带宽保留-有待研究。
目录服务-有待研究。
为了支持特别多点会议，网闸可以选择是否接收点对点会议中二个终端之间的H.245控
制信道。当会议交换到多点会议时，网闸能将H.245控制信道重定向到MC。网闸不需要处
理H.245信令；它仅需让信令在终端之间或终端和MC之间通过。
为了把输入的E.164地址译成传送地址，包含网关的LAN也应该包含网闸。
包含网闸的H.323实体应该有禁止内部网闸的机制，这样当LAN上有多个包含网闸的
H.323实体时，H.323实体能被配置进相同地域。
6.5多点控制器特性
MC提供支持多点会议中三个或多个端点之间的会议的控制功能。在多点会议中MC与
每个端点进行能力交换。MC向会议中的端点发送能力集指示他们可以传送的操作方式。作
为终端连接或离开会议或其他原因的结果，MC可以修订要传送到终端的能力集。
这样，MC为会议决定已选通信方式（SCM）。SCM对会议中所有端点是公用的。或者，
会议中一些端点的SCM可能与其他端点不同。MC决定SCM的方法超出了本协议的范围。
作为多点会议建立的一部分，端点应该在它的H.245控制信道上连接到MC。这种连接
可以发生在：
通过与MCU显式连接;
通过与网闸中的MC隐式连接;
通过与多点会议中另一个终端或网关内的MC隐式连接;
通过经网闸与MCU隐式连接。
会议方式（e.g.集中式或分散式）的选择发生在使用H.245信号与MC连接之后。会议方
式的选择可以由端点或MC的能力限制。
MC可以在网闸、网关、终端或MCU内定位。参见图6。
Terminal 1
MC
Terminal 2Gaetkeeper1
MC
Gaetkeeper2
MCMP
Gaet
LAN
MCMCMPMCMP
Gaetway1 Gaetway2
Gaetway3
MCU1 MCU2
图6/H.323 - H.323系统中MC和MP的可能位置
NOTE? GaetwayG ,aetkeepera ndM CUc anb ea s nigeld evcie.
终端中的MC是不可被叫的。它能被包含在呼叫内用以处理H.245信令从而支持特别多
点会议。这种情况下，终端的MC和H.245控制功能（参见6.2.8）可能是没有区别的。他们
之间的通信超出了本协议的范围。
网闸中的MC是不可被叫的；然而，网闸中的MCU是可被叫的。网闸中的MCU是作
为独立的MCU工作的。当网闸从端点接收到H.245控制信道时，网闸中的MC可以用于支
持特别多点会议。这样，网闸能在呼叫的开始或当会议交换到多点会议时将H.245控制信道
指向MC。
网关能起终端或MCU的作用。当作为终端时，网关可以包含MC。这与上述终端中的
MC有相同特性。
MCU总是包含MC。MCU是可被叫的，而且MC处理所有端点的H.245控制信道。
当会议中有二个以上端点时，端点应该使用H.245协议的主/从决定进程来决定将要控制
会议的MC。
在能力交换和主/从决定之后，MC可以使用 terminalNumberAssign先给一个新的端点指
定一个终端编号。然后，MC应该使用 terminalJoinedConference通知会议中其他的新端点。
新端点可以使用 terminalListRequest请求会议中其他端点的列表。
6.6多点处理器特性
MP从集中或混合多点会议的端点接收到音频、视频和/或数据流。MP处理这些媒体流
并将他们返回给端点。
MC和MP之间的通信不需要标准化。
MP可以处理一个以上媒体流类型。当MP处理视频时，它应该按6.2.4所述处理视频算
法和格式。当MP处理音频时，它应该按6.2.5所述处理音频算法。当MP处理数据时，它应
该按6.2.7所述处理数据流。
处理视频的MP应该提供视频交换或视频混合。视频交换是选择MP从源终端输出另一
个终端的视频的过程。交换使用的标准可以通过察觉演讲者的改变（由联合的声音层次判断）
或通过H.245控制来决定。视频混合是将一个以上的视频源格式化成由MP输出到终端的视
频数据流。一个视频混合的例子是在视频输出图片中将四个源图像混合成二二数组。标准图
像来源以及多少图像被混合的标准通常由MC决定，除非规定了其他控制。这一控制功能的
T.120系列协议的使用有待研究。
处理音频的MP应该准备从M-音频输入并由交换，混合，或组合直到N-音频输出的过
程。音频混合需要将输入音频译码成线性信号（PCM或模拟信号），执行信号的线性组合并
将结果再编码成适当的音频格式。为了减少噪声和其他不必要的信号，MP可以除去或消弱
一些输入信号。每个音频输出可能是输入的提供私人会话信号的不同组合。终端应该假定他
们的音频不是现在返回给他们的音频数据流。从MP音频输出中除去属于终端自己的音频的
方法有待研究。
处理T.120数据的MP应该能够充当非页面MCS提供者和Top MCS提供者。MP也可以
处理非标准数据，透明用户数据和/或数据的其他类型。
MP可以提供算法和格式转换，允许在不同的SCM上的终端参加会议。
MP是不可被叫的，而它的一部分—MCU则是可被叫的。MP终止并打开媒体信道。
6.7多点控制单元特性
MCU是为多点会议提供支持的端点。MCU应该包含MC和零个或多个MP。MCU使用
H.245消息和进程实现与H.243协议相似的特点。典型的支持集中式多点会议的MCU包含一
个MC和一个音频、视频和数据MP。典型的支持分散式多点会议的MCU包含一个MC和
一个支持T.120协议的数据MP。它依靠分散音频和视频处理。
LAN的网关可以是MCU。网闸也可以包含MCU。在任意两种情况中，他们是独立的功
能但碰巧共同定位。
MCU应该是其他端点使用条款8的进程可以被叫的。
6.8多点能力
6.8.1集中式多点能力
所有终端应该有集中式多点能力。作为LAN上的终端出现的网关也应该有集中式多点
能力。在这种操作方式下，他们在控制信道上以点对点的方法使用MCU中的MC通信，并
且在音频，视频和数据通道上使用MP。在这种方式下，MC执行H.245多点控制功能，而
MP执行视频交换或混合，音频混合，以及T.120多点数据分布。MP将产生的视频，音频和
数据流返回终端。MP可以在不同音频、视频和数据格式以及位速率之间进行转换，允许终
端使用不同通信方式参加会议。
如果会议中的终端能接收多点传送的话，那么MCU可以使用多点传送分发处理过的视
频。处理过的音频的多点传送分发有待研究。
这种方式由下列H.245能力发送信号： centralizedControl， centralizedAudio，
centralizedVideo，以及 centralizedData。
6.8.2分散式多点能力
如果终端有分散式多点能力，他们在H.245控制信道上使用以点对点方式的MCU中的
MC、网关、网闸或终端通信或者在数据信道上任选的使用MP。终端应该有向会议中的所有
其他端点多点传送他们的音频和视频信道的能力。MC可以控制哪一个或哪些终端主动地多
点发送音频和/或视频（例如在两个信道之间使用 flowControlCommand）。
终端接收到多点发送的视频信道并选择一个或多个可行的信道显示给用户。终端接收到
多点发送的音频信道并执行音频混合功能从而能为用户播放复合音频信号。
MC可以提供会议控制功能如座位控制，视频广播和视频选择。这将通过从终端接收
H.245然后向其他终端发送适当的控制从而允许或禁止他们的视频多点发送。T.120命令可以
随意提供相同功能。
这种方式由下列H.245能力发送信号： centralizedControl， decentralizedAudio，
decentralizedVideo，以及 centralizedData。
6.8.3混合多点-集中式音频
如果终端和MCU有混合多点-集中式音频能力，他们可以为视频使用分布式多点并为音
频使用集中式的多点。在这种方式中，终端在H.245控制信道上使用以点对点方式的MC或
者在数据信道上任选的使用MP。
终端应该有向会议中的所有其他端点多点发送他们的视频信道的能力。MC可以控制哪
一个或哪些终端主动地多点发送视频。终端接收到多点发送的视频信道并选择一个或多个可
行的信道显示给用户。
会议中所有的终端向MP传送他们的音频信道。MP执行音频混合功能并向终端输出产
生的音频数据流。MP可以为会议中的每个终端产生排斥音频总数。处理音频的多点分布式
发送有待研究。
这种方式由下列H.245能力发送信号： centralizedControl， centralizedAudio，
decentralizedVideo，以及 centralizedData。
6.8.4混合多点-集中式视频
如果终端和MCU有混合多点-集中式视频能力，他们可以为音频使用分布式多点和为视
频使用集中式的多点。在这种方式中，终端在H.245控制信道上使用以点对点方式的MC或
者在数据信道上任选的使用MP。
终端应该有向会议中的所有其他端点多点发送他们的音频信道的能力。MC可以控制哪
一个或哪些终端主动地多点发送音频。终端接收到多点发送的音频信道并执行音频混合功能
从而能为用户播放复合音频信号。
会议中所有的终端向MP传送他们的视频信道。MP执行视频混合功能并向终端输出产
生的视频数据流。MP可以为会议中的每个终端产生排斥视频总数，或者可以向所有参加的
终端多点发送视频数据流，从而缩小LAN中使用的带宽。
这种方式由下列H.245能力发送信号： centralizedControl， centralizedAudio，
decentralizedVideo，以及 centralizedData。
6.8.5 普通方式的建立
MC应该使多点会议中的终端之间的普通通信方式对等。MC可以通过向终端发送一个
仅列出请求传送的方式的接收能力集来迫使终端进入传送的一个特定的普通方式（当允许由
他们的能力设置时），或者MC可以依靠multipointModeCommand和迫使方式对称的方式参
考命令。后一种方法应该被采用因为它允许终端知道可以请求的可行会议能力的整个范围。
如果MCU有转换音频和/或视频格式的能力，它不必迫使所有终端进入相同的通信方式。
6.8.6多点速率匹配
由于多点配置中的每个链接的终端企图以不同的位速率操作，因此MC应该传送H.245
flowControlCommand消息来限制那些能够发送到接收者的传送位速率。
6.8.7多点唇同步
在集中式或混合式多点会议中提供音频混合的MP应该修改音频和视频数据流的时间标
记，重视它的时间基准，从而标准音频和视频同步。具体地说，当MP处理音频和/或视频产
生源于MP的新的数据流，MP应该在音频和视频包中产生自己的顺序编号。
当混合音频时，MP应该使每个输入的音频数据流与它自己的时间同步，混合音频数据
流，然后应基于自己的时间用它自己的顺序编号产生新的音频数据流。如果MP也交换视频，
转换的数据流应该用MP的时间替换原始的时间戳从而与混合的音频数据流同步，而且应该
有一个新的序号代表从MP输出的数据流。
在分布式的多点会议的情况中，接收终端能通过使用RTP时间标记使选定的视频数据流
和它的相关音频对齐保持唇同步。其他音频数据流的对齐不是必需的。如果多个视频数据流
被显示出来，那么相关的音频数据流应该被对齐。
它在混合多点会议中保持唇同步是不可能的。
6.8.8多点加密
在集中式多点配置中，MP被认为是一个信任的实体。MP的每个端口将每个来自H.323
终端的信息流解密并按照10.1为输出到每个终端的信息流加密。非信任的MCU的操作有待
研究。
分散式和混合式多点会议的加密有待研究。
6.8.9层叠多点控制单元
多点控制功能可以在几个MCU实体之间分布式执行。这样操作有待研究。
7呼叫信令
呼叫信令是用于建立呼叫，请求呼叫的带宽改变，获得呼叫端点的状态，以及断开呼叫
的消息和进程。呼叫信令使用H.225.0协议中规定的消息以及条款8中描述的进程。这个条
款描述了一些呼叫信令概念。
7.1地址
7.1.1 LAN地址
每个H.323实体应该至少有一个LAN地址。这个地址独立的识别LAN上的H.323实体。
一些实体可以共享一个LAN地址（i.e.终端和共定位的MC）。这个地址是端点所在的LAN
环境专用的。不同的LAN环境可以有不同的LAN地址格式。
端点可以在同一呼叫中为不同信道使用不同的LAN地址。
7.1.2 TSAP标识符
对于每个LAN地址，每个H.323实体可以有几个TSAP标识符。这些TSAP标识符允许
几个信道共享相同的LAN地址的多路技术。
端点有一个众所周知的TSAP标识符定义：呼叫信令信道TSAP标识符。网闸有一众所
周知的TSAP标识符定义：RAS信道TSAP标识符，以及一个众所周知的多点传送地址定义：
发现多点传送地址。这些都是在附录IV/H.225.0定义的。
端点和H.323实体应该为H.245控制信道，音频信道，视频信道，以及数据信道使用动
态TSAP标识符。网闸应该为呼叫信令信道使用动态TSAP标识符。RAS信道和信令信道可
以在注册进程中改变动态TSAP标识符的方向。
7.1.3别名地址
端点也可以有一个或多个与它相关的别名地址。别名地址提供另一个端点寻址方法。这
些地址包含E.164地址（网络访问号码，电话号码，等等），H.323 ID（名字，类似于地址的
电子邮件，等等），以及任何H.225.0协议中定义的其他地址。别名地址在地域中应该是唯一
的。网闸，MC，以及MP不应该有别名地址。
当系统中没有网闸时，呼叫端点应该使用被叫端点的呼叫信令信道传送地址来直接寻址
被叫端点。当系统中有网闸时，呼叫端点可以使用被叫端点的呼叫信令信道传送地址或别名
地址来寻址被叫端点。后者应该由网闸翻译成呼叫信令信道传送地址。
呼叫端点的E.164地址可以由一个可选的跟随在E.164地址之后的访问代码组成。访问
代码由0～9， *，以及 #范围内的n个数字组成。数字的编号和他们的意思由厂商决定。这
种访问代码的目的之一可能是请求访问网关。网闸可以在向目标转发之前改变这个地址。
H.323 ID包含一串在H.225.0协议中规定的ISO/IEC 10646-1字符。它可以是用户名，电
子邮件名称，或其他标识符。
端点可以有一个以上别名地址（包括一个以上相同类型的）被翻译成相同的传送地址。
端点的别名地址在地域内应该是唯一的。
7.2注册，许可和状态（RAS）信道
RAS信道应该用于在网闸发现和端点注册过程中传送消息，端点注册过程将端点的别名
地址和它的呼叫信令信道传送地址关联起来。RAS信道应该是非可靠信道。
7.2.1网闸发现
网闸发现是端点用于决定与哪一个网闸注册的过程。这可以手工完成或自动完成。手工
发现依靠超出本协议的范围以外的方法决定端点是与哪一个网闸相关联。端点由相关联的网
闸的传送地址配置。例如，它可以在端点配置中被加进去，或者它可以被加进一个初始化文
件。这样，端点知道与它相关联的前一个网闸。端点现在可以与网闸注册。
自动发现的方法允许端点-网闸的关联随着时间的改变而改变。端点可以不知道它的网闸
是谁，或由于失败而需要识别另一个网闸。这可以通过自动发现实现。自动发现允许在配置
单个端点时低级管理阶层，此外还允许现存网闸的替换而不用手工重新配置所有相关端点。
端点可以多点传送（或使用附录IV/H.225.0描述的其他方法）一个网闸请求（GRQ）消
息，询问“谁是我的网闸？”。这个信息被传送到网闸的众所周知的发现多点传送地址。一个
或多个网闸可以用网闸确认（GCF）消息应答，指示“我能是你的网闸。”，并返回网闸的RAS
信道的传送地址。如果网闸不想要端点注册它，它应该返回网闸拒绝（GRJ）。参见图7。如
果一个以上网闸应答，端点可以选择它想使用的网闸。这样，端点知道它是与哪一个网闸注
册的。端点现在可以和那个网闸注册。
Endpoint
GRQ
GCF/GRJ
Gatekeeper
图7/H.323 -自动发现
T1521260-96
如果在超时之前没有网闸应答，端点可以再试GRQ.端点不应该在发送完前一个的5秒
之内发送GRQ.如果没有收到响应，端点可以使用手工发现方法。
如果在任何时候端点发现它与网闸的注册是无效的，它必须重新寻找它的网闸。无效注
册可以通过从网闸接收对端点的RRQ应答的RRJ消息，或者在超时之前不接收任何对端点
的RRQ的应答而检测出来。
GRQ可以周期性重复（i.e.在端点供电时），这样网闸应该能处理来自同一端点的多个请
求。
7.2.2端点注册
注册是端点加入地域，并向网闸告知它的传送地址和别名地址的过程。作为他们的配置
过程的一部分，所有端点应该与通过发现过程识别的网闸注册。注册应该在任何呼叫发生之
前发生，必要时也可以周期性发生（例如，在端点供电时）。
端点应该向网闸发送注册请求（RRQ）。这个请求被传送到网闸的RAS信道传送地址。
端点从网闸发现过程中获得网闸的LAN地址并使用众所周知的RAS信道TSAP标识符。网
闸应该以注册确认（RCF）或注册拒绝（RRJ）应答。参见图8。端点应该仅与单个网闸注册。
RRQ可以周期性重复（i.e.在终端供电时），这样网闸应该能处理来自同一端点的多个请
求。如果网闸收到一个与前一个RRQ有相同别名地址和相同传送地址的RRQ，它应该以RCF
应答。如果网闸收到一个与前一个RRQ有相同别名地址但不同传送地址的RRQ，它应该拒
绝注册即指出是重复注册。如果网闸收到与前一个RRQ有相同传送地址但不同别名地址的
RRQ，它应该替换转换表输入项。网闸可以鉴别这些改变的方法有待研究。
网闸应该保证每个别名地址唯一的翻译成单个传送地址。不明确的注册应该被网闸拒
绝。网闸可以由于其他原因而拒绝注册，比如在发现中的变化或安全问题。
如果端点在RRQ消息中不包含别名地址，网闸可以分配一个别名地址。网闸应该在 RCF
消息中把分配的别名地址返回给终端。
Endpoint
RRQ
Gatekeeper
RCF or RRJ
URQ
UCF/URJ
Endpoint initiated
Unregister Reques
URQ
图
UCF
8/H.323 -注册
Gatekeeer initia
p
Unregister Reque
端点可以向网闸发出取消注册请求（URQ）消息来取消其注册.网闸以取消注册确认
（UCF）消息作为应答。这使得端点能够改变与它的传输地址相连系的别名地址,反之亦然。
若端点没有注册到网闸,则向端点发出取消注册拒绝（URJ）消息。
网闸可以向端点发出取消注册请求（URQ）消息来取消其注册。 端点以取消注册确认
（UCF）消息作为应答。 在开始呼叫之前,端点可以再次注册到网闸。这可能要求端点注册
到新的网闸。
没有注册到网闸的端点被称作非注册端点。这种类型的端点不能对网闸进行许可请求,
因此也不能参加由网闸执行的许可控制,带宽控制,地址翻译和其他功能。
7.2.3端点定位
具有一个别名地址 （别名地址决定相应端点的传送地址）的端点或者网闸能够发出定位
T1524050-96
请求消息（LRQ）。 LRQ消息可以被送到特定的网闸,或象GRQ消息那样被多点传送。它被
送到网闸的众所周知的RAS信道TSAP标识符上;如果被多点传送,则送到众所周知的网闸多
址发现上。被要求的端点所注册的网闸,应该以包含端点的呼叫信令信道或网闸的呼叫信令信
道的传送地址的定位确认（LCF）消息响应。所有未被要求的端点注册的网闸,如果他们在RAS
信道上接受到LRQ的话,应该返回定位拒绝消息（LRJ）。 所有未被要求的端点注册的网闸,
如果他们在多址发现接受到LRQ的话,都不应该对LRQ消息做出响应。
7.2.4许可，带宽改变，状态，断开
RAS 信道也被用于传送许可,带宽改变,状态, 断开消息。这些消息产生于端点和网闸之
间,用来提供许可控制和带宽管理功能。在第8节将对如何应用他们进行详细的描述。
许可请求消息（ARQ）中指明了请求的带宽。它是所有能发送和接收的音频,视频流（不
包含任何RTP头,RTP有效载荷头,LAN头,和其他的）的总比特率的上限。数据和控制信道不
受此限制。网闸可以在ACF消息中降低所请求的带宽。端点将确保（平均每秒的） 发送和
接收音频,视频流的总比特率不超过带宽。在呼叫中,端点或网闸可利用带宽改变请求（BRQ）
消息来修改呼叫带宽。
7.3呼叫信令信道
呼叫信令信道被用来承载H.225.0呼叫控制信息。呼叫信令信道应该是可靠的信道。
在没有网闸的网络里,呼叫信令消息利用呼叫信令传送地址在主叫和被叫之间直接传输。
在这样的网络里,是假定主叫端点知道被叫端点的呼叫传送地址的,因而能够直接通信。
在包含网闸的网络里, 利用网闸的RAS信道传送地址,初始的许可信息交换发生于主叫
端点和网闸之间。在进行初始的许可信息交换时,网闸在ACF消息中指定是否直接将呼叫信
令消息送到其他端点,或利用网闸来发送。呼叫信令消息被送到端点的呼叫转移地址或网闸的
呼叫转移地址。
H.225.0协议中定义了本协议中用来表示呼叫信令消息的Q.931消息结构。第8节将介绍
使用它们的方法。
7.3.1呼叫信令信道传输
呼叫信令有两种传输方式。第一种是基于网闸传输的（见图9）。在这种方式中,呼叫信令
消息经由网闸在端点之间传输。第二种是呼叫信令消息直接在端点之间传输（见图10）。在
此方式中,呼叫信令消息直接在端点之间传输。使用哪种方式由网闸来决定。
为达到同样的目的,两种方法都使用了一些相同的连接和相同的消息结构。许可消息在
RAS信道上与网闸交换,接着是在呼叫信令信道上呼叫信令消息的交换。然后是H.245控制信
道的建立。网闸对许可消息的反应方式决定使用的是哪一种呼叫方式。这不是处于端点的控
制之下,但是端点具有首决权。
对于基于网闸传输的方式,网闸可以选择在呼叫建立完成以后关闭呼叫信令信道,也可以选
择在呼叫过程中保持连接状态来对附加的设备提供支持。只有网闸能够关闭呼叫信道,但在涉
及到网关的呼叫中网闸是不能关闭呼叫信道的。
附录D/Q.931的对称的信令方式应用于所有的强制性的呼叫过程中。
图9至图12中的网闸云包含一个或几个网闸,它们之间有的能够通信,有的不能。图中的端
点可以连接到相同的网闸,也可以连接到不同的网闸。
GatekeeperC loud
1A RQ
2A CF/ARJ
3S et-up
4S et-up
5A RQ
6A CF/ARJ
7C onnect
8C onnect
12384567
Endpoint 1Endpoint 2
T1521280-96
Call SignallingC hanne Messages
Figure 9/H.323 –
l
Gatekeeper routed call signalling
RASC hannel Messages
Gatekeeper Cloud
1
1A RQ
2A CF/ARJ
3S et-up
4A RQ
5A CF/ARJ
6C onnect
245
3
Endpoint 1
6
Endpoint 2
Call Signalling Channel Messages
RAS Channel Messages
T1521290-96
Figure 10/H.323 – Direct endpoint call signalling
7.3.2控制信道传输
当采用基于网闸的信号传输方式时,有两种方式来传输H.245控制信息。在第一种方式
中,H.245控制信道直接建立于端点之间。参见图11。这种方式以后再讨论。第二种方式
中,H.245控制信道信息经由网闸在端点之间传输。参见图12。这种方式允许当一个可扩展会
议从点至点方式转换到多点方式时,网闸能够将H.245控制信道重定向到一个MC。这个选择
权在于网闸。当使用端点直接传输方式时, H.245控制信道只能在端点之间建立。
Gatekeeper Cloud
1A RQ
2A CF/ARJ
3S et-up
4S et-up
5A RQ
6A CF/ARJ
7C onnect
8C onnect
9H 2.45C hannel
12384567
Endpoint 1
9
Endpoint 2
H2.45C ontrol Channel Messages
T1521300-96
Call SignallingC hannel Messages
RASC hannel Messages
Figure 11/H.323 – Direct H.245 control channel connection between endpoints
Gatekeeper Colud
1A RQ
2A CFA/RJ
3S et-up
4S et-up
5A RQ
6A CFA/RJ
7C onnect
8C onnect
9H 2.45C hannel
10H 2.45C hannel
12389456
0
7
1
Endponi1 t
Endponi2 t
H2.45C ontroC lhanneM lessages
T1521310-9
CallS ginalingC hannel Messages
RASC hannel Messages
Figure 12/H.323 – Gatekeeper routed H.245 control
7.4呼叫参考值
所有呼叫信令信息和RAS消息都包含有呼叫参考值（CRV）。参见H.225.0 协议。它
们被用来联系与同一呼叫相关的所有消息。 在与同一呼叫相关的所有许可,呼叫建立,附加设
备,带宽改变及呼叫中止消息中,都应该使用相同的CRV。新的CRV应该用于新的呼叫。一个
端点邀请别的端点参加同一会议而发起的新呼叫也应该使用新的CRV。CRV不同于会议ID
（CID） 。CRV 联系同一呼叫的消息,CID则联系的是同一会议中的所有呼叫。
7.5会议ID和会议目标（意图）
CID是由主叫端点产生的唯一非零值,它在不同的消息中传递。（这些H.225.0消息以八字
节的CID开头）。 CID确定该消息对应的会议。CID的16字节形式如下:
CID octet
Value
15
N5
14
N4
13
N3
12 11 10
N0
9
C1
8
C0
7
H1
6 5 4 3 2
L2
1
L1
0
L0 N2 N1 AV M1 M0 L3
在这里,0下标指的是相应组值中的最低字节。（如N0中的0指的是N0是N0--N5组中的最
低字节。）
N5:0 48比特的LAN物理地址,如果可用的话。
C1:0 对会议数计数的计数器,占16比特,如果时钟不能保证是不变的话。
H1,A,M1:0 自当地时间1582年11月15日起100*E-11秒的最低60比特。（E-11等于1秒
的十亿分之一）。比特分配如下:
H1
59 52 51
A
48 47
M1 M0
32 31
L3
L2
L1 L0
0
V: CID的低字节起第六字节的4比特低位代表的是版本号,其值为0001。
会议目标指的是呼叫的意图。有下列备选项:
Create:建立一个新的会议;
Join: 申请加入一个已有的会议;
Invite:邀请一个新的端点加入到一个已有的会议中。
8.呼叫信令过程
通信过程由下列阶段组成:
----A阶段:呼叫建立（参看8。1节）。
----B阶段:通信初始化和能力交换（参看8。2节）。
----C阶段:语音视频通信开始建立（参看8。3节）。
----D阶段:呼叫服务（参看8。4节）。
----E阶段:呼叫中止（参看8。5节）。
8.1 A阶段----呼叫建立阶段
根据下面所定义的呼叫控制过程相应的呼叫控制信息（呼叫控制信息在H.225.0协议中定
义）来建立呼叫。第一步是对带宽资源预留的申请。
如果别名地址和传送地址都给出，优先使用别名地址。
8.1.1基本呼叫建立----没有任何注册端点
在图13的假定中，端点都没有注册到网闸。图中的两个端点直接通信。端点1（主叫端
点）向 端点2的众所周知的呼叫信令通道TSAP标示符上 发出建立消息。端点2以连接信
息（4号信息）对端点1做出反应（连接信息中包含了用于H.245中H.245控制信道的传送
地址）。
Endpoint 1
Set-up (1)
Call proceeding (2)
Alerting (3)
Connect (4)
Endpoint 2
T1527150-97
Figure 13/H.323 – Basic call set-up, no Gatekeepers
Call Signalling Messages
8.1.2两个端点注册到同一网闸
在图14的假定中, 两个端点注册到同一网闸,并且网闸已经选择了信号直接传输方式。端
点1开始与网闸交换ARQ（1）/ACF（2）信息。网闸应该在ACF中返回端点2（被叫端点）
的呼叫信令信道传送地址。然后端点1利用该传送地址向端点2发送呼叫建立消息（3）。如
果端点2要接受呼叫,则它开始与网闸交换ARQ（5）/ACF（6） 信息。在端点2向端点1发
送“释放完毕”消息的情况下,它从网闸那里接受到ARJ（6）消息。 端点2以连接信息（8）
对端点1做出回应（连接信息中包含了用于H.245中H.245控制信道传送地址）。
Endpoint 1
ARQ (1)
ACF/ARJ (2)
Set-up (3)
Gatekeeper 1Endpoint 2
Call proceeding (4)
ARQ (5)
ACF/ARJ (6)
Alerting (7)
Connect (8)
T1527160-97
Figure 14/H.323 – Both endpoints registered, same Gatekeeper – Direct call signalling
RAS Messages
Call Signalling Messages
在图15的假定中, 两个端点注册到同一网闸,并且网闸已经选择了转接呼叫信令的传输方
式。端点1开始与网闸交换ARQ（1）/ACF（2）信息。网闸应该在ACF中返回它自己的呼
叫信令信道的传送地址。 然后端点1利用该传送地址向网闸发送呼叫建立消息（3）。接着网
闸向端点2发送呼叫建立消息（4）。如果端点2要接受呼叫,则它开始与网闸交换ARQ（6）
/ACF（7） 信息。 在端点2向网闸发送“释放完毕”消息的情况下,它从网闸那里接受到ARJ
（7）消息。 端点2以连接信息（9）对网闸做出回应（连接信息中包含了用于H.245中H.245
控制信道传送地址）。网闸向端点1发送包含有端点2或者网闸的H.245控制信道传送地址的
连接消息（10）, 连接消息中包含谁的控制信道传送地址取决于网闸选择转发方式与否。
Endpoint 1
ARQ (1)
ACF (2)
Set-up (3)
Gatekeeper 1Endpoint 2
Set-up (4)
Call Proceeding (5)
Call Proceeding (5)
ARQ (6)
ACF/ARJ (7)
Alerting (8)
Connect (10)
Alerting (8)
Connect (9)
Figure 15/H.323 – Both endpoints registered, same Gatekeeper – Gatekeeper routed call signalling
T1524060-96
RAS Messages
Call Signalling Messages
8.1.3 仅主叫端点注册到网闸上
在图16的假定中,端点1注册到网闸上,而端点2则没有,同时网闸选择信号直接传输方式。
端点1开始与网闸交换ARQ（1）/ACF（2）信息。然后端点1利用众所周知的呼叫信道传
送地址向端点2发送连接建立信息（3）。 如果端点2要接受呼叫,它以连接信息（4）对端点
1做出反应（连接信息中包含了用于H.245中H.245控制信道传送地址）。
Endpoint 1
ARQ (1)
ACF/ARJ (2)
Set-up (3)
Gatekeeper 1Endpoint 2
Call proceeding (4)
Alerting (5)
Connect (6)
Figure 16/H.323 – Only calling endpoint registered – Direct call signalling
RAS Messages
Call Signalling Messages
在图17的假定中,端点1注册到网闸上,而端点2则没有,同时网闸已经选择了转接呼叫信
号的传输方式。 端点1开始与网闸交换ARQ（1）/ACF（2）信息。网闸应该在ACF中返
回它自己的呼叫信令信道传送地址。然后端点1利用该传送地址向网闸发送呼叫建立消息
（3）。 接着网闸利用端点2的众所周知的呼叫信道传送地址向其发送连接建立信息（4）。 如
果端点2要接受呼叫,它以连接信息（7）对网闸做出反应（连接信息中包含了用于H.245中
H.245控制信道传送地址）。网闸向端点1发送包含有端点2或者网闸的H.245控制信道传送
地址的连接消息（8）, 连接消息中包含谁的控制信道传送地址取决于网闸选择转发方式与否。
Endpoint 1
ARQ (1)
ACF (2)
Set-up (3)
Gatekeeper 1Endpoint 2
Setup (4)
Call Proceeding (5)
Call Proceeding (5)
Alerting (6)
Connect (7)
Alerting (6)
Connect (8)
T1524070-96
RAS Messages
Figure 17/H.323 - Only calling endpoint registered - Gatekeeperrouted call signalling
8.1.4仅被叫端点连接到网闸上
Call Signalling Messages
Endpoint 1
Set-up (1)
Gatekeeper 2
Endpoint 2
Call proceeding (2)
ARQ (3)
ACF/ARJ (4)
Alerting (5)
Connect (6)
RAS Messaes
Figure 18/H.323 –
g
Only called endpoint registered – Direct call signalling
Call Signalling Messages
在图19的假定中,端点2注册到网闸上,而端点1则没有, 同时网闸已经选择了转接呼叫
信号的传输方式。 端点1利用众所周知的呼叫信道传送地址向端点2发送连接建立信息（1）。
如果端点2要接受呼叫, 它开始与网闸交换ARQ（3）/ACF（4）信息。如果被允许,网闸应
该在ARJ（4）中返回它自己的呼叫信道传送地址,with a cause code of route。。。 。 端点2向
端点1发送包含有网闸的呼叫传送地址的Facility消息（5）作为应答。然后端点1向端点2
发出释放完毕消息（6）。 端点1向网闸的呼叫传送地址发出建立消息（7）。 网闸向端点2
发出建立消息（8）。 端点2开始与网闸交换ARQ（9）/ACF（10）信息。端点2以连接信
息（12）对网闸做出反应（连接信息中包含了用于H.245中H.245控制信道传送地址）。网闸
向端点1发送包含有端点2或者网闸的H.245控制信道传送地址的连接消息（13）, 连接消
息中包含谁的控制信道传送地址取决于网闸选择转发方式与否。
Endpoint 1
Set-up (1)
Gatekeeper 1Endpoint 2
Call Proceeding (2)
ARQ (3)
ARJ (4)
Facility (5)
Release Complete (6)
Set-up (7)
Set-up (8)
Call Proceeding (2)
Call Proceeding (2)
ARQ (9)
ACF/ARJ (10)
Alerting (11)
Connect (13)
Alerting (11)
Connect (12)
Figure 19/H.323 – Only called endpoint registered – Gatekeeperrouted call signalling
T1524080-96
RAS Messages
8.1.5 两个端点分别连接到不同的网闸上
MessagesCall Signalling
假定在图20中, 两个端点分别连接到不同的网闸上,并且两个网闸都选择了呼叫信号直
接传输方式。 端点1开始与网闸1交换ARQ（1）/ACF（2）信息。 若网闸1按某种方式
能与网闸2通信,则网闸1应该在ACF消息中返回端点2的呼叫信令信道传送地址。然后端
点1或向网闸1返回的呼叫传送地址发出建立消息（3）,或利用众所周知的呼叫信道传送地
址向端点2发送连接建立信息（3）。 如果端点2要接受呼叫, 它开始与网闸2交换ARQ（5）
/ACF（6）信息。 在端点2向端点1发送“释放完毕”消息的情况下,它从网闸2那里接受到
ARJ（6）消息。 端点2以连接信息（8）对端点1做出反应（连接信息中包含了用于H.245
中H.245控制信道传送地址）。
Endpoin1t
ARQ(1 )
ACFA/RJ (2)
Gatekeeper 1Gatekeeper 2
Set-up(3 )
Calp roceednig(4 )
ARQ(5 )
ACFA/RJ (6)
Aertlnig(7 )
Connect(8 )
Figure 20/H.323 – Both endpoints registered – Both gatekeepersdirect call signalling
在图21的假定中, 两个端点分别连接到不同的网闸上,并且主叫端点的网闸选择呼叫信
号直接传输方式,被叫端点的网闸选择转发呼叫信令传输方式。 端点1开始与网闸1交换ARQ
（1）/ACF（2）信息。 若网闸1按某种方式能与网闸2通信,则网闸1应该在ACF（2）消
息中返回端点2的呼叫信令信道传送地址。然后端点1或向网闸1返回的呼叫传送地址发出
建立消息（3）,或利用众所周知的呼叫信道传送地址向端点2发送连接建立信息（3）。 如果
端点2要接受呼叫, 它开始与网闸2交换ARQ（5）/ACF（6）信息。 如果被接受,网闸2应
该在ACF（6）中返回它自己的呼叫信道传送地址,连同的还有routeCallToGatekeeper。 端点
2向端点1发送包含有网闸2的呼叫传送地址的Facility消息（7）作为应答。 端点1向端点
2发出释放完毕消息（8）。 端点1向网闸1发出 DRQ（9）消息,网闸1以DCF（10）消息
做出应答。然后端点1开始与网闸1交换新的ARQ（11）/ACF（12）信息。 端点1向网闸
2的呼叫信令信道传送地址发出建立消息（13）。 网闸2向端点2发出建立消息（14）。 端
点2开始与网闸2交换ARQ（15）/ACF（16）信息。端点2以连接信息（18）对网闸2做
出反应（连接信息中包含了用于H.245中H.245控制信道传送地址）。网闸2向端点1发送包
含有端点2或者网闸2的H.245控制信道传送地址的连接消息（19）, 连接消息中包含谁的
控制信道传送地址取决于网闸选择转发方式与否。
RASM essages
CalS ginalnigM essages
Endpoint 1
Gatekeeper 1
ARQ (1)
ACF (2)
Set-up (3)
CallProceeding (4)
Gatekeeper 2
Endpoint 2
ARQ (5)
Faciitly (7)
Release Complete (8)
DRQ (9)
DCF (10)
ARQ (11)
ACF (12)
Set-up (13)
Set-up (14)
CallProceeding (4)
CallProceeding (4)
ARQ (15)
ACF/ARJ (16)
Alerting (17)
Connect(18)
ARJ (6)
Alerting (17)
Connect(19)
Figure 21/H.323 – Both endpoint registered – Direct/routed call signalling
图22的假定中, 两个端点分别连接到不同的网闸上,并且主叫端点的网闸选择转发呼叫
信号传输方式,被叫端点的网闸选择呼叫信号直接传输方式。 端点1开始与网闸1交换ARQ
（1）/ACF（2）信息。网闸1应该在ACF（2）消息中返回它自己的呼叫信令信道传送地址。
端点1利用该地址向网闸1发出建立消息（3）。 然后网闸1向端点2的众所周知的呼叫信令
信道传送地址发送包含了网闸1自身的呼叫信令信道传送地址的建立信息（4）。 如果端点2
要接受呼叫, 它开始与网闸交换ARQ（6）/ACF（7）信息。 在端点2向端点1发送“释放完
毕”消息的情况下,它从网闸2那里接受到ARJ（7）消息。 端点2以连接信息（9）对网闸1
做出反应（连接信息中包含了用于H.245中H.245控制信道传送地址）。网闸1向端点1发送
T15240909-6
RAS Messages
CallSi gnalling Messages
包含有端点2的H.245控制信道传送地址或网闸1的H.245控制信道传送地址的连接消息（10）,
连接消息（10）中包含谁的控制信道传送地址取决于网闸选择转发方式与否。
Endpoin1t
ARQ(1 )
ACF(2 )
Gatekeeper 1Gatekeeper 2Endpoin2t
Set-up(3 )
CallP roceeding(5 )
Set-up(4 )
CallP roceeding(5 )
ARQ(6 )
ACF/ARJ (7)
Aertilng(8 )
Connect(1 0)
Aelrting(8 )
Connect(9 )
Figure 22/H.323 – Both endpoint registered – Routed/direct call signalling
RASM essages
T15241
CallS ginalingM essages
在图23的假定中, 两个端点分别连接到不同的网闸上,并且两个网闸都选择了转发呼叫
信号传输方式。 端点1开始与网闸1交换ARQ（1）/ACF（2）信息。网闸1应该在ACF（2）
中返回它自己的呼叫信道传送地址。然后端点1利用该地址向网闸1发出建立消息（3）。接
着网闸1向端点2的众所周知的呼叫信令信道传送地址发送建立消息（4）。如果端点2要接
受呼叫,它开始与网闸2交换ARQ（6）/ACF（7）信息。 如果被接受,网闸2应该在ARJ（7）
中返回它自己的呼叫信道传送地址, routeCallToGatekeeper。 端点2向网闸1发送包含有网闸
2的呼叫传送地址的Facility消息（8）作为应答。网闸1向端点2发出释放完毕消息（9）。
网闸1向网闸2的呼叫传送地址发出建立消息（10）。 网闸2向端点2发出建立消息（11）。
端点2开始与网闸2交换ARQ（12）/ACF（13）信息。端点2以连接信息（15）对网闸2
做出反应（连接信息中包含了用于H.245中H.245控制信道传送地址）。网闸2向网闸1发送
包含有端点2或者网闸2的H.245控制信道传送地址的连接消息（16）, 连接消息中包含谁
的控制信道传送地址取决于网闸2选择转发方式与否。 网闸1向端点1发送可能包含有网闸
1或者网闸2的H.245控制信道传送地址的连接消息（17）, 连接消息中包含谁的控制信道传
送地址取决于网闸1选择转发方式与否。
Endpoint 1
ARQ(1)
ACF (2)
Set-up (3)
CallProceeding (5)
Gatekeeper 1Gatekeeper 2Endpoint 2
Set-up (4)
CallProceeding (5)
ARQ(6)
ARJ (7)
Faciitly (8)
Release Complete (9)
Set-up (10)
CallProceeding (5)
Set-up (11)
CallProceeding (5)
ARQ(12)
ACF/ARJ (13)
Aertilng (14)
Connect(17)
Aertilng (14)
Connect(16)
Aertilng (14)
Connect(15)
T15241109-6
Figure 23/H.323 – Both endpoint registered – Both Gatekeepersrouting call signalling
RAS Messages
CallSi gnalling Messages
8.1.6通过网关建立呼叫
8.1.6.1通过网关对内建立呼叫
当一个外部的端点通过网关呼叫LAN内的端点时,在网关和LAN端点之间呼叫建立的过
程与端到端的呼叫建立过程是一样的。当在网络上建立呼叫时网关可能需要向外端点发送呼
叫处理信息。
不能直接将外来的SCN呼叫向H.323端点转发的网关应该具备接受两阶段拨号的能力。
对于连接到H.320网络（也可以是H.321,H.322,H.321方式的H.310网络）的网关,应该能从
H.320端点接受SBE号码。 对于连接到H.324网络或者连接到本地方式H.310网络的网关,
应该具备从H.324端点接受 userInputIndication消息的能力。在这两种情况下,对DTMF的
支持是可选的。对连接到纯语音终端的网关,应该具备从纯语音终端接受DTMF码的能力。
DTMF码在访问LAN上的单个端点时指出第二阶段拨号码。
8.1.6.2通过网关对外建立呼叫
当一个LAN内的终端通过网关呼叫外部的终端时,在网关和LAN终端之间呼叫建立的过
程与端到端的呼叫建立过程是一样的。网关将接受到的呼叫建立消息中所包含的目的地的E。
164地址。然后网关利用该地址对外发起呼叫。当在建立对外呼叫时网关可能需要向LAN终
端发送呼叫处理信息。
进程指示器信息元用来表明内部网络正在运转。网关应该在警告,呼叫处理,或连接消息
内发出进程指示器信息元。它们也可以被发送到进程消息之中。
LAN端点应在呼叫建立消息中发送出由它发起的呼叫的所有E。164地址。例如,在ISDN
上的6_B信道呼叫将需要在呼叫建立消息中包含6个E。164地址。网关对呼叫建立消息发
出如下消息作为应答:连接,释放,警告,呼叫处理,或进程消息等。一个失败的SCN呼叫将通过
释放完毕消息报告给LAN端点。多CRV值和多呼叫建立消息的使用方法以后再讨论。SCN
呼叫中的附加信道问题以后再研究。
注册到网闸的LAN端点应该在ARQ消息中请求充足的呼叫带宽以满足所有的SCN呼
叫。若在ARQ消息中充足的呼叫带宽要求得不到满足，应紧接着发出8。4。1中讲述的带
宽改变消息,以便获得另外的呼叫带宽。
将第一阶段的呼叫置于SCN上之后,网关将向B阶段推进。后来呼叫的SCN E。164地
址在同网关进行能力交换和同SCN端点建立语音通信之后再处理。
8.1.7 使用MCU建立呼叫
对于集中式的多点会议,所有的端点同MCU（多点控制单元）交换呼叫信令。端点同MCU
之间的呼叫建立过程与8。1。1至8。1。5中所讲的端到端的呼叫建立过程是相同的。MCU
可能是被叫端点,也可能是主叫端点。
在集中式的多点会议中,端点与MCU中的MC之间的H.245控制信道是开通的。 端点
与MCU中的MP之间的音频,视频,数据流信道是开通的。 在非集中式的多点会议中, 端点与
MC之间的H.245控制信道是开通的（可能有许多H.245控制信道,每个呼叫对应一个）。在会
议中, 音频,视频流应该是多点传送到所有的端点的。数据流信道对MP数据应该是开通的。
在端点内没有MC的可扩展会议中,H.245控制信道应该经由网闸转发。开始时，H.245
控制信道将经由网闸在端点之间传输。但会议转换到多点时，网闸可以将端点连接到与该网
闸相关的MC上。
在端点内含有一个或多个MC的多点会议中，使用的是8。1。1至8。1。5中定义的正
常呼叫建立过程。主从决定进程用来决定在会议中哪一个MC是主动的。
8.1.8前向呼叫
想要向别的端点发出一个前向呼叫的端点可以发出一个暗含新的端点地址的Facility消
息。接受到此Facility消息的端点应该发出释放完毕消息,然后重新开始同新的端点建立呼叫
联系。
8.1.9广播方式下的呼叫建立
这一子专题以后再研究。
8.2 B阶段---通信初始化和能力交换
一旦通信双方在A阶段已经交换了呼叫建立信息,端点间就建立了H.245控制信道。协议
H.245中的流程被用来进行H.245控制信道上的能力交换和用来打开媒体流信道。
备注---可选地,H.245控制信道可以通过被叫端点收到的建立消息来设置,和通过主叫端
点收到的警告,呼叫处理消息来设置。在连接未建立或者端点发出释放完毕消息的情况
下,H.245控制信道将关闭。
端点的系统能力通过H.245中terminalCapabilitySet 消息的发送来交换。能力信息应该是
最先发送的H.245消息。
主从决定流程将象6。2。8。4中描述的那样进行。在呼叫的两个端点都有MC 能力的
情况下, 主从决定用来决定会议中的哪一个MC是主动的。 然后那个主动的MC就发出
mcLocationIndication 消息。该流程也对开放式的双向数据传输提供了主从决定方式的支持。
如果开始的能力交换和主从决定失败,在端点放弃连接努力而进入到E阶段之前应该再至
少多试两次。
在能力交换完成之后,接着是端点直接进入到期望的操作方式,例如,C阶段。
8.3 C阶段---语音视频通信的建立
在能力交换和主从决定完成后,用H.245协议中规定的流程来为各种信息流打开逻辑信道。
在H.245呼叫建立阶段打开的逻辑信道中传输的音频,视频流,在利用不可靠的协议的动态
TSAP标识符上传输（参见H.225.0协议）。在H.245呼叫建立阶段打开的逻辑信道中传输的
数据通信流,则利用可靠的协议传输（参见H.225.0协议）。
OpenLogicalChannelAck 返回接收端点指定的逻辑信道的传送地址。然后传输通道通过该
逻辑信道向该地址发送信息流。
音频视频的逻辑信道建立后,发送端应该为每一语音视频对发送出一个
h2250MaximumSkewIndication消息。
8.3.1模式改变
在一个会话期,应该象H.245协议中规定的那样对信道结构,能力,接收模式等改变采取措
施。
8.3.2遵守共同协议的视频流的交换
协议H.245中定义了videoIndicateReadyToActivate 。对它的使用是可选的。但如果要
用它,则按下面的法子办。
除非并且直到端点1已经设置好使得视频流能够传输,端点2才准备就绪来发送视频流。
当初始的能力交换完成后,端点1将发出videoIndicateReadyToActivate指示，但直到从端点２
接收到videoIndicateReadyToActivate或视频流，它才传输视频流。
不使用上述可选项的端点,不必非等到接受到videoIndicateReadyToActivate指示或视频流
之后才开始自己的视频流发送。
8.3.3媒体流地址分配
对单点传送,端点建立到MCU或其他端点的逻辑信道。地址通过openLogicalChannel或
openLogicalChannelAck。 来传递。
对多点传送, 多点传送地址由MC 分配（在communicationsModeCommand中分配到各
个端点）。分配唯一的多点地址是MC的任务。端点将一个开放的逻辑信道分配到具有多点
地址的MC上,该地址由openLogicalChannel获得。MC将向每个端点转发openLogicalChannel。
在多点-单点会议中,端点将与其他的每个端点建立逻辑信道。 OpenLogicalChannel发送
到MC,并包含与信道有关的所有端点的数目。端点能够通过forwardLogicalChannelNumber
与一个openLogicalChannelAck匹配。
8.4 D阶段---呼叫服务
8.4.1带宽改变
在许可交换中首先建立呼叫带宽并被网闸认可。端点将确保所有发出和接受到的音频,
视频信道（RTP头,RTP有效载荷,LAN头及其他开支）在此带宽范围之内。数据和控制信道
的带宽不受此限。
在会议的任何时间,端点或网闸可能增加或降低呼叫带宽资源的申请。如果发出和接受信
道的总比特率不超过当前的呼叫带宽,端点可以不申请带宽改变而改变一个逻辑信道的比特
率。但是当这一改变导致总的比特率超过了当前的呼叫带宽时,端点的比特率在得到实际的增
加之前,它必须从它的网闸那里申请改变带宽并且等待网关的确认。建议当一个端点在较长一
段时间内对待宽需求降低时也申请带宽改变,为其他的呼叫释放多余带宽。
欲要改变带宽的端点向它的网闸发送带宽改变请求消息（BRQ）（1）。网闸决定是否答
应请求。如何决定的一些原则问题超过了本协议的范围。如果网闸拒绝接受该请求,它向端点
发送拒绝带宽改变消息（BRJ）（2）。反之,则发送带宽改变许可消息（BCF）（2）。
若端点1想要增加它在逻辑信道上的传输比特率,它首先看是否超过了呼叫带宽。参看图
24。若超过了,端点1将向网闸1请求带宽改变（1和2）。当带宽足以满足此改变时,端点1
发出closeLogicalChannel消息（3）来关闭逻辑信道。然后它用指明了新的比特率的
openLogicalChannel消息（4）来重新打开逻辑信道。如果接收端点要接受新的传输率,它必须
首先确保这一改变不会导致带宽不足。如果确实导致了,那么它就向它的网闸请求带宽改变（5
和6）。 当呼叫带宽足以满足此改变时,端点2向端点1发出openLogicalChannelAck（7）作
为应答,否则发出openLogicalChannelReject表明其不能接受新的传输率。
Gaetkeeper 1
BRQ(1 )
BCFB/RJ (2)
ColseLogciaClhanne(3 l)
OpenLogciaClhanne(4 l)
Endpoin1t Endpoin2t
G
BRQ(5 )
BCFB/RJ (6)
OpenLogciaClhAck(7 )
N
O
若端点1
t
想要从端点2那里增加它在逻辑信道上的传输比特率,它首先看是否超过了呼叫
TE? Gaekeeper 1a ndG aetkeeper 2m ayb eht esa meG aetkeeper.
带宽（端点1先前降低了自己的传输比特率）。参看图25。若超过了,端点1将向网闸1请求
带宽改变。当带宽足以满足此改变时,端点1向端点2发出flowControlCommand 消息（3）
来指明新的传输比特率上限。如果端点2决定要增加传输率,它必须首先确保这一改变不会导
致带宽不足。如果确实导致了（带宽不足）,那么它就向它的网闸请求带宽改变（4和5）。 当
呼叫带宽足以满足此改变时,端点2将发出closeLogicalChannel （6）来关闭逻辑信道。然后
端点2用指明了新的比特率的openLogicalChannel（7）来重新打开逻辑信道。此时端点1应
该同意新的传输率,并向端点2发出openLogicalChannelAck（8）作为回答。
Gaetkeeper 1
BRQ(1 )
Endpoin1t
Endpoin2t
BCFB/RJ (2)
FolwConrotClommand(3 )
BRQ(4 )
BCFB/RJ (5)
ColseLogciaClhanne(6 l)
OpenLogciaClhanne(7 l)
OpenLogciaClhAck(8 )
Figure 25/H.323 – Bandwidth change request – Receiver change
NOTE? Gaetkeeper 1a ndG aetkeeper 2m ayb eht esa meG aetkeeper.
想改变端点1的传输率的网闸向端点1发出BRQ消息。如果请求的是降低比特率,端点
1将一直遵守它自己的传输率降低请求并且返回一个BCF消息。端点1可以发起适当的H.245
信令来通知端点2:比特率已经发生了改变。这将允许端点2将改变通知到它的网闸。 如果
请求的是增加比特率,端点可以在必要时提高传输速率。
8。4。2状态
为了让网闸知道端点是否关断,或者是否进入了故障模式,网闸可以利用IRQ/IRR消息序列
（参看H.225.0协议）来定期轮询各个端点（轮询间隔由制造商决定）。 轮询间隔（一般）
大于10秒。此消息也可被11。2节中讲述的诊断工具设备来利用。
网闸可以要求端点定期发送一个非请求式的IRR消息。网闸可以通过ACF消息结构的
irrFrequency域指定的IRR来向端点指明这一点。接受这一irrFrequency速率的端点在整个呼
叫过程中以此速率发出IRR消息．在这一速率有效时，网闸仍然可以向端点发出IRR消息．
在呼叫过程中，端点或者网闸可以定期的从别的端点请求得到呼叫的状态．发出请求的端
点或网闸发出状态查询消息．接收到状态查询消息的端点应答一个暗含当前状态的状态消
息．网闸可以使用这一过程来定期地检查一个呼叫是否仍在继续．注意这一点：呼叫信令信
道上的H.225.0信息不能与RAS信道上的IRR信息冲突。
8.4.3 特别多点会议扩展
下列的流程对端点和网关是可选的,但对MC是必须有的。
特别多点会议指的是能从具有一个MC的点对点将其扩展到多点会议。首先,在端点（端
点1 和端点2）之间建立点对点会议。至少一个端点或网闸必须包含有一个MC。一旦点对
点的会议建立,可由两种方式将其扩展为多点会议。第一种是:想邀请别的端点（端点3）加入
到会议的端点通过MC呼叫被邀请的端点。第二种方式是:端点（端点3）通过呼叫会议中的
端点来加入已有的会议。
无论是直接信号传输方式还是信号转发传输方式均可以进行特别多点 会议扩展。 直接
信号传输方式下的H.245控制信道拓扑图如下:
Endpoint 1
MC
Endpoint 2
Endpoint 3
信号转发传输方式下的H.245控制信道拓扑图如下:
T1524120-96
Endpoint 1
MC
Gatekeeper
Endpoint 3
T1524130-96
Endpoint 2
在任何情况下,在扩展到超过2个端点的会议中,MC 是必须有的。
对于每种呼叫方式,通过邀请或申请的办法建立一个点对点会议并将其扩展为多点会议
所需的流程,将在下面的子专题中讲述。
应该指出的是,由提供MC的实体发生故障时来中止呼叫过程。
8.4.3.1建立直接信号传输方式下的会议
端点1按如下方式建立一个两端点的会议:
A1） 端点1用 一个全局唯一的CID（=N）号和会议目标=CREATE 向端点2发送建
立消息。,如何产生见8.1节中。
A2） 端点2有下列的步骤可选:
A2a） 若它想加入到会议中,则向端点1发出具有CID=N的连接消息。 在这种
情况下,又有两种可能:
1）不参加别的会议;
2）参加别的会议,同时具备参加多点会议的能力,并且接受到的CID=N
与此时参加的会议的CID中的任何一个都不匹配。
A2b） 如果端点2已参加另一个CID=M的会议,并且在某一时刻只能参加一个会
议,那么它可以1）或2）:
1）通过发出释放完毕消息暗示自己已参加会议而来拒绝该呼叫。
2）可以通过发送一个Facility消息请求端点1加入到CID=M的会议 。
Facility消息在routeCallToMC中包含了CID=M的会议和含有MC的
端点的呼叫信令信道传输地址。。
A2c） 如果它不想加入这个会议,它通过发出释放完毕暗示正忙而拒绝该呼叫。
A3） 如果端点2进入会议,端点1用连接消息中提供的信道的传送地址来建立到端点2
的控制信道。
A4） 然后H.245消息按如下步骤交换:
A4a） 端点之间TerminalCapabilitySet的交换决定了所用H.245的版本号以便正
确地分解出保留的接受信息。
A4b） 用H.245主从决定,确定端点2是主动的。在网闸转发模式中,主端点必须
连接到网闸的MC上。若主端点含有MC,它将变为主动的。然后它可以向其他端点发出
MCLocationIndication 消息。MC在当前的会议中可以是主动的,或当用户初始化多点会议函
数时使其主动,这由制造商决定。
A4c） 主端点可以向其他端点发出terminalNumberAssign 消息。端点使用8比特
的端点号,而不使用8比特的MCU号, 端点号来自于RTP头的SSRC域的低8比特。SSRC
的低8比特指明来自特定端点的信息流。
A4d） 发送端从TerminalCapabilitySet消息处获知了收端的能力,它打开逻辑信道。
对每一对语音视频流,发端发出一个h2250MaximumSkewIndication消息。
8.4.3.2直接信号传输方式下邀请（端点）参加会议
有两种邀请方式。其一,包含主动MC的端点邀请别的端点参加会议。其二,不包含主动
MC的端点邀请别的端点参加会议。
用A1-A4的方法建立一个点对点的会议之后,一个包含主动MC的端点（端点2）邀请
别的端点参加会议的流程如下:
B1） 端点2用一个全局唯一的CID（=N）号和会议目标=CREATE向端点3发送建
立消息。参看8.1节。见图26。
B2） 端点3有下列的步骤可选:
B2a） 若它想接受邀请加入到会议中,则向端点2发出具有CID=N的连接消息。
B2b） 如果它不想接受邀请加入这个会议,它通过发出释放完毕暗示正忙而拒绝
该呼叫。
B2c） 若端点3正在参加CID=M的会议,它可以通过发送一个Facility息请求端
点2加入到CID=M的会议 。 Facility消息在routeCallToMC中包含了的 会
议CID=M 和含有MC的端点的呼叫信令信道传输地址。。
B2d）若接受到的CID与当前正在参加的会议的CID相同,则通过发出释放完毕消
息暗示已经参加该会议而拒绝该呼叫。
B3） 若端点接受了邀请,端点2用连接消息中提供的信道的传送地址来建立到端点3
的控制信道。
B4） 然后H.245消息按如下步骤交换:
C1） TerminalCapabilitySet消息在MC和端点3之间交换。
C2） 用H.245主从决定,确定端点2具有主动的MC。然后它向端点3发出
MCLocationIndication 消息。
C3） 这时MC向所有的3个端点发出multipointModeCommand消息。
C4） MC可以向端点3发出terminalNumberAssign 消息。若接收到了,端点使用8比特
的端点号,而不使用8比特的MCU号, 端点号来自于RTP头的SSRC域的低8比特。SSRC
的低8比特指明来自特定端点的信息流。
C5） 端点向MC发送terminalListRequest消息,可以获得当前会议的其他所有端点的列
表。MC以terminalListResponse作为应答。
C6） 任何一个新端点加入到会议的时候,MC向端点4发送terminalNumberAssign消息,
向端点1,2,3发送terminalJoinedConference消息。
C7） 当有端点离开时,MC向留下的端点发送terminalLeftConference消息。
C8） MC向所有会议端点发送communicationModeCommand消息。
C9） 如果端点1和2没有保持communicationModeCommand中的信息,它们在点对点
会议时建立的逻辑信道将被关闭。
C10） 现在MC和其他端点之间的逻辑信道可以打开。
Endpoint 2 (E2)Endpoint 3 (E3)
Set-up (E3, CID = N, invite)
Alerting/Call Proceeding
Connect (E3 H.245 TA)
Figure 26/H.323 – MC invite signalling
用A1-A4的方法建立一个点对点的会议之后,一个不包含主动MC的端点（端点1）邀
请别的端点参加会议的流程如下:
B1） 端点1向MC（端点2）发出具有新的CRV的建立消息。该新的CRV含有一个到端
点3的呼叫,并提供了呼叫端点3的传送地址。CID=N,会议目标=INVITE。见图27。
B2） 端点2向3发出具有CID=N, 会议目标=INVITE的建立消息。见8.1节。
B3） 在端点1和3呼叫期间,端点2将向端点1（最初的发起者）转发从端点3收到的呼叫
信令消息（包括连接信息）。
B4） 如前所述,端点3有接受或拒绝邀请的选择权。
B5） 在端点2和3之间的呼叫建立过程完成后,端点2将向1发出释放完毕消息。
B6） 若端点3接受邀请, 端点2用连接消息中提供的信道的传送地址来建立到端点3的控
制信道。
B7） 然后H.245消息按上面的C1-C10步骤交换。
Endpoint 1 (E1)
Set-up (E3, CID = N, invite)
Endpoint 2 (E2)Endpoint 3 (E3)
Set-up (E3, CID = N, invite)
Alerting/Call Proceeding
Alerting/Call Proceeding
Connect (E3 H.245 TA)
Connect (E3 H.245 TA)
Release Complete (cause)
T1524150-96
Figure 27/H.323 – Non-MC invite signalling
8.4.3.3直接信号传输模式下（端点主动）加入会议
有两种主动申请参加会议方式。其一, 申请参加会议的端点呼叫包含主动MC的端点参
加会议。其二, 申请参加会议的端点呼叫不包含主动MC的端点参加会议。
用A1-A4的方法建立一个点对点的会议之后, 申请参加会议的端点（端点3）通过呼叫
包含主动MC的端点来参加会议参加会议的流程如下:
B1） 端点3用 一个全局唯一的CID（=N）号和会议目标=JOIN向端点2发送建立
消息。参看8.1节。见图28。
B2） 若CID与MC内某主动会议的CID匹配,端点2（MC）将有以下选择:
B2a） 若它允许端点2参加会议,它发送CID=N的连接信息。
B2b） 若它不允许端点2参加会议,它发送释放完毕消息表明正忙。
B3） 若CID与MC内所有主动会议的CID都不匹配, 端点2发送释放完毕消息表明
CID是错误的。
B4） 若端点2允许端点3加入会议,则它打开到端点3的逻辑信道。
B5） 然后H.245消息按上面的C1-C10步骤交换。
Endpoint 2 (E2)Endpoint 3 (E3)
Set-up (E3, CID = N, join)
Alerting/Call Proceeding
Connect (E2 H.245 TA)
Figure 28/H.323 – MC join signalling
用A1-A4的方法建立一个点对点的会议之后, 申请参加会议的端点（端点3）通过呼叫
不包含主动MC的端点来参加会议参加会议的流程如下:
B1） 端点3用 一个全局唯一的CID（=N）号和会议目标=JOIN向端点1发送建立消
息。参看8.1节。见图29。
B2）端点1返回含有routeCallToMC的Facility消息。 RouteCallToMC中有端点2（含
MC）的呼叫信道传送地址
B3）端点3向2（含MC）发送具有CID=N,会议目标=JOIN的建立消息。其余同上述
的JOIN流程。
Endpoint 1 (E1)
Set-up(E 1 C,ID= N , join)
Facility(c ause E,2)
ReleaseC omplete(c ause)
Endpoint 3 (E3)
Endpoint 2 (E2)
Set-up(E 2 C,ID= N , join)
Alerting/Call Proceeding
Connect (E2H 2.45 TA)
Figure 29/H.323 – Non-MC join signalling
8.4.3.4网闸转发方式下会议的建立
在网闸转发呼叫信令和H.245控制信令情况下,网闸应该包含（或能访问）MC或MCU。
A1-A4过程用于建立点对点的呼叫。在进行主从决定时（A4b）,若网闸的端点类型
（terminalType）大于从masterSlaveDetermination消息中的端点收到的terminalType,网闸可以
在向目标端点发送信息之前以该端点的terminalType值替代它原来的值。 若网闸的端点类型
（terminalType）不大于从该端点的terminalType,则网闸不能修改terminalType值。实际上,
网闸与每个端点之间进行主从决定。若网闸与每个端点进行主从决定后均取得主的地位,则与
它相连的MC是主动的MC,否则,某个别的端点的MC是主动的MC。
8.4.3.5网闸转发信号方式下INVITE会议
用A1-A4的方法建立一个点对点的会议之后,一个不包含主动MC的端点（端点1或2）
邀请别的端点参加会议的流程如下:
B1） 端点1通过网闸直接向端点3发送建立消息（CID=N和会议目标=INVITE,新的
CRV值）。见图30。
B2） 网闸（MC）向端点3发送建立消息（CID=N,会议目标=INVITE）。参见8。1节。
B3） 在端点1和3呼叫期间,网闸将向端点1（最初的发起者）转发从端点3收到的呼
叫信令消息（包括连接信息）。
B4） 如前所述,端点3有接受或拒绝邀请的选择权。
B5） 在端点3和网闸之间的呼叫建立过程完成后, 网闸将向1发出释放完毕消息。
B6） 若端点3接受邀请, 网闸用连接消息中提供的信道的传送地址来建立到端点3的
控制信道。
B7） 然后H.245消息按上面的C1-C10步骤交换。网闸参与所有的主从决定以决定随
时主动的MC。这时,从端点开始的控制信道必须连接到主动的MC上,并且MC应该在会议的
控制之中。
Endpoint 1 (E1)
Set-up(E 3 C,ID= N , invite)
GatekeeperEndpoin
Set-up(E 3 C,ID= N , invite)
Call Proceeding/Alerting
Connect (E3H 2.45 TA)
Connect (GK H2.45T A)
ReleaseC omplete(c ause)
Figure 30/H.323 - Gatekeeper routed invite signalling
Call Proceeding/Alerting
8.4.3.6网闸转发信号方式下的JOIN会议
用A1-A4的方法建立一个点对点的会议之后, 申请参加会议的端点（端点3）通过呼叫
不包含主动MC的端点来参加会议参加会议的流程如下:
B1） 端点3通过网闸直接向端点1发送建立消息（CID=N和会议目标=JOIN）。参看
8.1节。见图30。
B2） 若CID与MC内某主动会议的CID匹配,网闸（MC）将有以下选择:
B2a） 若它允许端点3参加会议,它发送CID=N的连接信息。
B2b） 若它不允许端点3参加会议,它发送释放完毕消息表明正忙。
B3c） 网闸可以向端点1发出建立消息。 端点1可以以表明routeCallToMC的
Facility消息或释放完毕消息作为应答。
B3） 若CID与MC内所有主动会议的CID都不匹配, 网闸发送释放完毕消息表明CID
是错误的。
B4） 若网闸允许端点3加入会议,则它利用建立消息中提供的呼叫传送地址信息打开
到端点3的逻辑信道。
B5） 然后H.245消息按上面的C1-C10步骤交换。网闸参与所有的主从决定以决定随
时主动的MC。这时,从端点开始的控制信道必须连接到主动的MC上,并且MC应该在会议的
控制之中。
Endpoint 3 (E3)GatekeeperEndpoint 1
Set-up( E1 C,ID= N , join)
CallP roceeding/Alerting
Connect( GK H2.45T A)
Figure 31/H.323 – Gatekeeper routed join signalling
8.4.4附加设备
本协议中规定:允许端点使用Q.931-, Q.932-, Q.95X 协议系列中定义的附加设备。这些设
备将使用呼叫信令和Q.931消息。 它们可以提供象保持,转移,先前,重定向之类的特性。
8.5 E阶段-----呼叫中止
通过以下过程,任何端点均可以中止呼叫。
1） 在最后一张画面传完后,该端点应该停止传送视频流,并且关闭为视频流打开的所有逻辑信
道。
2） 该端点应该停止传送数据,并且关闭为数据打开的所有逻辑信道。
3） 该端点应该停止传送音频流,并且关闭为音频流打开的所有逻辑信道。
4） 在H.245控制信道中发送H.245消息: endSessionCommand,向远处的端点表明自己想中止
呼叫;然后停止H.245消息的发送。接着要做的是关闭H.245控制信道。
5） 它等待从别的端点那里接收到endSessionCommand消息,然后关闭H.245控制信道。
6） 若呼叫信道是开通的,应该发送出释放完毕消息,然后关闭该信道。
7） 用下面定义的流程清除呼叫。
不是首先发出endSessionCommand消息的端点在收到了（别的端点发来的）
endSessionCommand消息时,它执行的步骤是上面的1---7步,除了在第5步中不必等待（别的
端点发来的） endSessionCommand消息的到来。
中止一个呼叫并不能中止一个会议;可以通过H.245消息（dropConference）来中止会议。
在这种情况下,端点必须等待MC按上述步骤来中止呼叫。
8.5.1无网闸时的呼叫清除
在无网闸的网络里,在经过上面的1-6步后,呼叫就中止了。不需要做更多的处理。
8.5.2有网闸时的呼叫清除
在有网闸的网络里,网闸需要知道释放的带宽。在完成上面的1---6步后,每个端点向它的
网闸发送（H.245中）的脱离请求消息（DRQ）（3）。 网闸以脱离标识符消息（4）作为应答。
在发送DRQ消息之后,端点不再向网闸发送更主动的IRR消息。参见图32。在这一点上,呼
叫中止了。图32对应的是直接呼叫模式。网闸转发模式下的流程（在下面讲到）与此相似。
DRQ和DCF消息在RAS信道上传输。
Gatekeeper 1Endpoin1t Endpoin2t Gatekeeper 2
EndSessionCommand(1 )
EndSessionCommand(1 )
Release Competle (2)
DRQ(3 )
DCF(4 )
DRQ(3 )
DCF(4 )
T1524200-96
RASm essages
CallS ginalingm essages
Figure 32/H.323 – Endpoint initiated call clearing
H2.45m essages
NOTE? Gatekeeper 1an dG atekeeper 2m ayb e hte same Gatekeeper.
8.5.3由网闸清除呼叫
网闸可以向端点发出DRQ消息来中止呼叫。见图33。端点应该立即执行上面的1-6步,
然后向网闸发出DCF消息作为应答。另一端点,应该跟着执行上面的流程。 图33对应的是
直接呼叫模式。网闸转发模式下的流程（在下面讲到）与此相似。
若会议是多点会议,网闸应该向所有参加会议的端点发出DRQ消息来关闭整个会议。
Gatekeeper 1
DRQ(3 )
EndSessionCommand(1 )
EndSessionCommand(1 )
Endpoin1t Endpoin2t Gatekee
ReleaseC ompelet(2 )
DCF(4 )
DRQ(3 )
DCF(4 )
T1524210-9
RASm essages
CallS ginalingm essages
H2.45m essages
– Gatekeeper initiated call clearing Figure 33/H.323
NOTE? Gaetkeeper 1a ndG atekeeper 2m ayb eht esa meG aetkeeper.
8.6对协议出错的处理
在报告出错之前,遵循可靠协议的H.245信道会尽适当的努力去收发信道上的数据。因此,
如果在信道上出现错误报告,那么H.245控制信道及所有相关的逻辑信道都将关闭。（这时,）
正如象别的端点发出了H.245消息: endSessionCommand的情况下那样,应该做E阶段的处理。
这包括向网闸发送DRQ消息和中止呼叫信令信道。在多点会议中,若错误由MC 检测到,MC
将向剩下的端点发出terminalLeftConference消息。下面执行的是:是否在无用户干预的情况下
重建呼叫。无论哪种情况,对端点（和网闸）而言,就象一个新的呼叫一样。
呼叫信令信道也使用可靠的协议。依赖于呼叫信令信道的转发方式,网闸或端点可以检测
到出错。若网闸检测到出错,将试图尽力重建信道。这意味着端点始终具备在它的呼叫信道传
送地址上建立信道的能力。呼叫信道上的出错不能改变Q.931的呼叫状态。在重建呼叫信道
后,网闸可发出状态消息来请求得到端点的呼叫状态,以确保它们处于同步中。
若端点检测到出错,它可以选择E阶段描述的那样来中止呼叫,或象上面所讲的那样重建
呼叫信道。
在呼叫中,若端点想知道其他端点是否仍在工作或处入连接状态,它可以发出H.245消息:
roundTripDelayRequest。因为H.245控制信道是可靠信道,所以它可从其他端点得到应答,或从
传输界面得到出错信息。在后种情况下,使用上面描述的处理方法。多点会议中的端点可使用
相同的方法。但是,它仅能了解是否仍然连接到MC上。要注意的是对端点而言这一点是可能
的:它可以与MC进行忽视错误的连接,但此时不能从会议的其他端点那里接收音频或视频流。
9与其他类型终端的互连
与其他类型终端的互连必须通过网关。见6.3节。
9.1纯语音终端
可由下列基于ISDN或GSTN的网关提供与纯语音终端的互连。
1）
2）
使用 H.323-ISDN 语音网关;
使用 H.323-GSTN 语音网关。
网关必须考虑到下面的方面。
- 音频编码转换:
-
-
-
ISDN: If desired, since ISDN uses G.711。
GSTN: from analogue to G.711。
比特流转换:
-
-
ISDN: H.225.0 to/from unframed。
GSTN:产生 H.225.0。
-
-
-
控制转换 （产生 H.245）。
呼叫控制信令转换。
DTMF tone conversion to/from H.245 userInputIndication message。
9.2基于ISDN（H.320）的可视电话终端
利用基于ISDN（H.320）的H.323-H.320网关实现与可视电话终端的互连。
网关必须考虑到下面的方面。
-
-
-
-
-
-
9.3基于GSTN（H.324）的可视电话终端
可由下列基于GSTN（H.324）的网关提供与可视电话终端的互连。
1）
2）
使用H.323-H.324 网关;
使用H.323-H.320 网关。
视频格式转换-视频编码转换。
数据协议转换。
比特流转换。
控制转换。
呼叫控制信令转换。
SBE Number conversion to/from H.245 userInputIndication message。
网关必须考虑到下面的方面:
•
•
-
-
-
视频格式转换。
数据协议转换。
视频编码转换。
比特流转换。
呼叫控制信令转换。
9.4基于移动通信的可视电话
以后研究。
9.5基于ATM的可视电话
可由下列基于ATM（H.321）的网关提供与可视电话终端的互连。
1） using a H.323-H.321 Gateway;
2） using a H.323-H.320 Gateway, assuming that there exists an I.580 ISDN/ATM Interworking
Unit in the network。
网关必须考虑到下面的方面:
•
•
-
视频格式转换 （If desired, H.261 is mandatory for both terminal types。）
数据协议转换。
视频编码转换（If desired, G.711 is mandatory for both terminal types。）
- 比特流转换。 （H.225.0 to/from H.221）
- 控制转换。（H.245 to/from H.242。）
•
9.6基于有质量保证的LAN（H.322）的可视电话终端
由下述网关提供与基于有质量保证的LAN（H.322）的可视电话终端的互连。
- 使用H.323-H.320网关。
呼叫控制信令转换
网关必须考虑到下面的方面:
•
•
-
视频格式转换 （If desired, H.261 is mandatory for both terminal types。）
数据协议转换。
视频编码转换（If desired, G.711 is mandatory for both terminal types。）
- 比特流转换。 （H.225.0 to/from H.221）
- 控制转换。（H.245 to/from H.242。）
•
9.7基于GSTN（V7。0）的能进行语音和数据同时传输的终端
由下述网关提供与基于GSTN（V7。0）的能进行语音和数据同时传输的终端的互连:
- 使用H.323-V。70 网关。
网关必须考虑到下面的方面:
•
•
•
•
•
9.8 LAN上的T.120终端
具备T.120能力的H.323终端应该被配置为能在标准的T.120 TSAPSH上监听和接收信
息的纯T.120终端。这将允许具备T.120能力的H.323终端参加纯T.120会议。
视频编码转换（G.711 to/from Annex A/G.729。）
数据协议转换。
比特流转换。 （H.225.0 to/from V。76/V。75。）
控制转换。 （Both terminals use H.245。）
呼叫控制信令转换
呼叫控制信令转换
LAN上的纯T.120终端可以参加H.323多点会议中的T.120部分。参见6。2。7。1
节。
10 可选的增加功能
10.1加密技术
以后研究。
11 维护
11.1取维护作用的lOOPBACKS
在H.245中定义了一些loopback 功能来验证终端的一些功能,以确保系统正确运行和提
供令人满意的服务质量。
不能使用SystemLoop和 logicalChannelLoop 请求。 MediaLoop要求是可选的。接收到
maintenanceLoopOffCommand消息的终端关掉当前所有有效的loopback功能。
为了此目地,定义了两种方式:
a）正常运行模式:无loopback。见图34。这时缺省的模式,当收到maintenanceLoopOffCommand
消息时进入这种模式。
b) 媒体环模式:在模拟I/O界面的媒体流的Loopack。接收到H.245协议中定义的mediaLoop
请求时,所选逻辑通道的内容的回退应该激活到指向尽可能近的视频/音频编码器,以形成
解码和再编码媒体环路。见图34的b）图。这种媒体环是可选的。仅在当每个方向上的
单向逻辑通道包含相同的媒体类型时,才可以采用。多通道在返回方向上是开通情况下的
操作没有定义。
a) Normal
Codec
Network
Interface
b) Medialo op
Codec
Figure 34/H.323 – Loop back
Network
Interface
T1521570-96
接收到systemLoop和logicalChannelLoop（H.245消息）请求的网关（连接到H.324和
H.310）,或从SCN终端接收到H.320数字环命令的网关,可以在网关内执行适当的LOOPBACK
功能函数。网关不会将这些请求传递到LAN终端。接收到mediaLoop（H.245消息）的网关
（连接到H.324和H.310）,能将这些请求传递到LAN终端。从SCN终端接收到 H.230 Vid-loop
或Au-loop命令的网关（连接到H.320）,将这些消息转换为适当的H.245 mediaLoop请求并
将其传递到LAN终端。
从LAN终端接收到H.245请求的H.320网关,将mediaLoop消息转换为适当的H.230
Vid-loop或Au-loop命令并且发送到SCN终端。
连接到H.324和H.310的网关,可向SCN终端发送H.245 systemLoop和
logicalChannelLoop消息。连接到H.230的网关,可向SCN终端发出H.230 Vid-loop或Au-loop
命令。若LAN终端与SCN终端建立了呼叫,发送到LAN终端的音频和视频流,可以是
LOOPBACK的音频和视频流,预录的音频和视频流,或没有音频和视频流。
11.2 监视方法
所有终端应支持H.225.0的 IRQ/IRR消息。IRR消息包含所有信道（含T.120,H.245控
制,音频和视频信道）上的当前有效呼叫TSAP标识符。第三方维护设备可利用这些信息来监
视H.323会议,以保证系统正常运行。
附录（不译）
ANNEX A
H.245 messages used by H.323 endpoints
The following rules apply to the use of H.245 messages by H.323 endpoints:
• An endpoint shall not malfunction or otherwise be adversely affected by receiving H.245
messages that it does not recognize。 An endpoint receiving an unrecognized request,
response, or command shall return "function not supported"。 （This is not required for
indications。）
• The following abbreviations are used in Tables A.1 to A.11:
M Mandatory
O Optional
F
•
Forbidden to transmit
A message marked as mandatory for the receiving endpoint indicates that the endpoint
shall accept the message and take the appropriate action。 A message marked as
mandatory for the transmitting endpoint indicates that the endpoint shall generate the
message under the appropriate circumstances。
Table A.1/H.323 - Master-slave determination messages
Message
Endpoint Status
Determination
Determination Acknowledge
Determination Reject
Determination Release
Receiving Endpoint Status Transmitting
M
M
M
M
M
M
M
M
Table A.2/H.323 - Terminal capability messages
Message Receiving Endpoint Status Transmitting
Endpoint Status
Capability Set M M
Capability Set Acknowledge M M
Capability Set Reject M M
Capability Set Release M M
Table A.3/H.323 - Logical channel signalling messages
Message Receiving Endpoint
Transmitting Endpoint Status
Open Logical Channel M M
Open Logical Channel Acknowledge M M
Open Logical Channel Reject M M
Open Logical Channel Confirm M M
Close Logical Channel M M
Close Logical Channel Acknowledge M M
Request Channel Close M O
Request Channel Close Acknowledge O O
Request Channel Close Reject O M
Request Channel Close Release O M
Table A.4/H.323 - Multiplex table signalling messages
Message Status
Multiplex Entry Send F
Multiplex Entry Send Acknowledge F
Multiplex Entry Send Reject F
Multiplex Entry Send Release F
Table A.5/H.323 - Request multiplex table signalling messages
Message Status
Request Multiplex Entry F
Request Multiplex Entry Acknowledge F
Status
Request Multiplex Entry Reject
Request Multiplex Entry Release
F
F
Table A.6/H.323 - Request mode messages
Message Receiving Endpoint
Transmitting Endpoint Status
Request Mode M O
Request Mode Acknowledge M O
Request Mode Reject O M
Request Mode Release O M
Table A.7/H.323 - Round trip delay messages
Message Receiving Endpoint
Transmitting Endpoint Status
Round Trip Delay Request M O
Round Trip Delay Response O M
Table A.8/H.323 - Maintenance loop messages
Message Receiving Endpoint
Transmitting Endpoint Status
Maintenance Loop Request
System Loop F
Media Loop O （Note）
（Note）
Logical Channel Loop
Maintenance Loop Acknowledge O O
Maintenance Loop Reject O M
Maintenance Loop Command Off M O
NOTE - Mandatory in Gateways。
Status
Status
Status
F
O
F F
Table A.9/H.323 - Commands
Message Receiving Endpoint Status
Send Terminal Capability Set
Encryption
Flow Control
End Session
Miscellaneous Commands
Transmitting Endpoint Status
M M
O O
M O
M M
Equalize Delay O O
Zero Delay O O
Multipoint Mode Command M
Cancel Multipoint Mode Command M
Video Freeze Picture M
Video Fast Update Picture M
Video Fast Update GOB M
Video Fast Update MB M
Video Temporal Spatial Trade Off O
Video Send Sync Every GOB O
Video Send Sync Every GOB Cancel
O
MCLocationIndication M
Terminal ID Request O
O
O
O
O
O
O
O
O
O
O
O
Terminal List Request
broadcast Me O
cancel Broadcast Me
Make Terminal Broadcaster
Send This Source
Cancel Send This Source
Drop Terminal O
Make Me Chair O
Cancel Make Me Chair
Drop Conference
Enter H.243 Password
Enter H.243 Terminal Id
Enter H.243 Conference ID
Request Terminal ID
Terminal ID Response
Terminal List Response
Video Command Reject
Make Me Chair Response
O O
O
O O
O O
O O
O O
O
O
O O
O O
O O
O O
O O
O O
O O
O O
O O
O O
Table A.10/H.323 - Conference mode commands
Message
Communication Mode Command
Communication Mode Request
Communication Mode Response
Receiving Endpoint Status
Transmitting Endpoint Status
M
O
O
O
O
O
Message
Function Not Supported
Miscellaneous Indication
Table A.11/H.323 - Indications
Receiving Endpoint Status
Transmitting Endpoint Status
M M
Logical Channel Active O O
Logical Channel Inactive O O
Multipoint Conference M O
Cancel Multipoint Conference M O
Multipoint Zero Comm O O
Cancel Multipoint Zero Comm O O
Multipoint Secondary Status O O
Cancel Multipoint Secondary Status O O
Video Indicate Ready to Activate O O
Video Temporal Spatial Trade Off O O
SBE Number O O
Terminal Number Assign M O
Jitter Indication
H.223 Skew Indication
H2250MaximumSkewIndication
New ATM Virtual Channel Indication
User Input
0-9, *燼nd #）
Non-standard commands, requests, etc。
Terminal Joined Conference O
Terminal Left Conference O
Seen By At Least One Other O
Cancel Seen By At Least One Other O
Seen By All O O
Cancel Seen By All O
Terminal You Are Seeing O
Request For Floor O
O O
F F
O M
F F
M （for 0-9, * and #） M
are allowed。
O
O
O
O
O
O
O
for （
APPENDIX I
Processing of Q.931 messages in Gateways
The Gateway shall terminate the Q.931 Call Signalling Channel between an H.323 endpoint and the
Gateway on one hand and the call signalling channel （if any） between the Gateway and the SCN
endpoint on the other。 The following applies only if the SCN side supports a call signalling
protocol such as Q.931 or Q.2931。
The Gateway shall conform to the call signalling procedures recommended for the SCN side
independent from the LAN side。 The Gateway shall conform to the call signalling procedures of
this Recommendation for the LAN side independent from the SCN side。
In addition, call signalling messages received from one side （LAN/SCN） may require forwarding
to the other side （SCN/LAN）。 Some forwarded messages may contain information elements or
parts of information elements which are unmodified or uninterpreted by the Gateway。 Other
forwarded messages may contain information elements or parts of information elements may be
added or removed by the Gateway, as needed。
In the following, an overview of the actions to be taken by the gateway in response to Q.931
messages and the information elements, is provided。 Messages and information elements that are
forbidden in Recommendation H.225.0 are not considered。
Q.931 messages originating on the H.323 side:
•
•
A SETUP message side shall lead to initiation of call set-up procedure for the SCN side。
A RELEASE COMPLETE shall lead to initiation of the call disconnect as defined for the
SCN side。
• A CALL PROCEEDING message shall be forwarded to the SCN side。 This shall not be
done if a CALL PROCEEDING has been sent before to the SCN in compliance to the
respective SCN specification （Q.931 in the ISDN case）。
• A CONNECT message shall be forwarded to the SCN side upon receipt from an H.323
endpoint。
• A CONNECT ACKNOWLEDGE message shall be forwarded to the SCN side upon
receipt。 This shall not be done if CONNECT ACKNOWLEDGE has been sent before to
the SCN in compliance to the respective SCN specification。 If the Gateway has sent a
CONNECT to an H.323 endpoint and has not received the corresponding CONNECT
ACKNOWLEDGE from the H.323 endpoint within the time frame required for successful
completion of the call, it shall generate the CONNECT ACKNOWLEDGE to the SCN
side as appropriate to comply to the SCN call set-up procedures。
• Messages for supplementary services （FACILITY, HOLD, HOLD ACKNOWLEDGE,
HOLD REJECT, RETRIEVE, RETRIEVE ACKNOWLEDGE, RETRIEVE REJECT and
the INFORMATION messages） that are not processed by the Gateway, shall be
forwarded to the SCN side。
• All messages forbidden to be originated from an H.323 endpoint shall be generated by the
Gateway autonomously as required by the SCN protocol。
The information elements of the respective messages are to be converted as follows:
• The contents of connection specific information elements （such as Call Reference Value）
shall be adapted as required by the SCN protocol。
• Information elements that are not in use on the H.323 side shall be generated by the
Gateway as required by the SCN protocol。
• Translation of other information elements shall be done as required by the SCN protocols
and procedures。 Where interoperability is not an issue, conversion is left to the discretion
of the manufacturer。
• Only the user-data part of the user-user information element shall be forwarded to the
SCN side。 It shall be re-encoded following Figure 4-36/Q.931 and Table 4-26/Q.931。
All Q.931 messages originating on the SCN side are forwarded to the H.323 endpoint without
modification except for the following:
•
•
•
Messages forbidden by Recommendation H.225.0 shall not be passed to the H.323 side。
The call reference value is mapped to the appropriate value for the H.323 side。
The user data field is copied into the corresponding ASN。1 user-user information element
structure。
• The user-user information element structure shall be generated according to the
specification in Recommendation H.225.0。
ITU-T RECOMMENDATIONS SERIES
Series A
Series B
Series C
Series D
Series E
Series F
Series G
Series H
Series I
Series J
Series K
Series L
plant
Series M
Organization of the work of the ITU-T
Means of expression: definitions, symbols, classification
General telecommunication statistics
General tariff principles
Overall network operation, telephone service, service operation and human factors
Non-telephone telecommunication services
Transmission systems and media, digital systems and networks
Audiovisual and multimedia systems
Integrated services digital network
Transmission of television, sound programme and other multimedia signals
Protection against interference
Construction, installation and protection of cables and other elements of outside
Maintenance: international transmission systems, telephone circuits, telegraphy,
facsimile and leased circuits
Series N
Series O
Series P
Series Q
Series R
Series S
Series T
Series U
Series V
Series X
Series Z
Maintenance: international sound programme and television transmission circuits
Specifications of measuring equipment
Telephone transmission quality, telephone installations, local line networks
Switching and signalling
Telegraph transmission
Telegraph services terminal equipment
Terminals for telematic services
Telegraph switching
Data communication over the telephone network
Data networks and open system communication
Programming languages
2024年9月1日发(作者：东依柔)
国际电信联盟
ITU-T H.323
ITU的电信标准化区段 （11/96）
H系列：视听和多媒体系统
视听服务的基础-视听服务的系统和终端设备
为局域网提供无质量保证服务的可视电话系统和设备
ITU-T协议H.323
（早期由CCITT协议）
ITU-T H系列协议
视听和多媒体系统
用于除电话用途之外的传输信道的特性
用于音频报务的电话型电路的使用
用于各种类型的电报传输或同步传输电话电路或电缆
用于传真电报的电话型电路
数据信号的特性
可视电话系统的特性
视听服务的基础构架
通则
多路传输和同步传输
系统概况
通信过程
运动视频编码
相关系统概况
视听服务系统和终端设备
细节请参见ITU-T系列协议。
H.10.19
H.20.29
H.30.39
H.40.49
H.50.99
H.100.199
H.200.399
H.200.219
H.220.229
H.230.239
H.240.259
H.260.279
H.280.299
H.300.399
ITU-T协议H.323
为局域网提供无质量保证服务的可视电话系统和设备
摘要
H.323协议描述了基于无质量保证服务的局域网（LAN）上的多媒体通信的终端，设备
和服务。H.323终端和设备可以传输实时语音、数据和视频，或上述的任意组合，包括视频
电话。
用于H.323终端通信的LAN，可以是单个网段或令牌环网，也可以是多个具有复杂拓补
结构的段。注意：基于多个LAN网段上（包括Internet）的H.323的终端工作性能可能很低。
保证这种类型的LAN/互联网的服务质量的可能方法超出了本协议的范围。
H.323终端可以被集成进PC或在像视频电话这种独立设备上实现。支持语音是必须的，
而支持数据和视频是可选的，但是一旦支持的话，就必须具备使用特定通用方式的操作的能
力，这样所有支持该媒体形式的终端就能互相协作。本协议允许每种媒体类型的多通道同时
使用。H.323系列协议还包括：H.225.0打包和同步，H.245控制，H.261和H.263视频编码
器，G.711、G.722、G.728、G.729和G.723音频编码器，以及T.120系列多媒体通信协议。
本协议利用了H.245协议的逻辑信道信令进程，当通道打开时每个逻辑信道的内容已被
描述好了。对接收器和传送器能力的表示由进程提供，因此传输被限制什么接收器能译码上，
这样接收器可以请求传送器的特定方式。由于H.245协议的进程也用于ATM网的H.310协
议以及GSTN和V.70的H.324协议中，因此与这些系统的协作应该不会要求H.225～H.245
协议的传输达到与H.320系统相同的情况。
H.323终端可以用于多点配置，也可以和B-ISDN上的H.310终端，N-ISDN上的H.320
终端，B-ISDN上的H.321终端，保证服务质量的LANs上的H.322终端，GSTN和无线网络
上的H.324终端，以及GSTN上的V.70终端相互协作。
来源
ITU-T协议 协议H.323是由ITU-T第15研究组（1993-1996）撰稿，并于1996年11月8日
经WTSC决议的NO.1程序认可。
绪言
ITU（国际电信联盟）是联合国在电信领域中的专门机构。ITU电信标准化区段（ITU-T）
是ITU的永久性机构。ITU-T负责研究技术，操作，征询问题以及在全球标准化通信方面制
定标准协议。
世界电信标准化会议（WTSC），每四年召开一次，为ITU-T研究组的研究工作制定论题，
然后ITU-T研究组为这些论题制定协议。
由ITU的成员核准的协议必须通过WTSC的NO.1解决方案的程序核实。
在信息技术的一些区域内，在ITU-T范围内，必要的标准由ISO和IEC共同制定。
说明
在本协议中，表达式管理机构是用于精确指示电信管理和识别操作机构的。
知识产权
ITU 1997保留所有的权利。
目录
1概况······································································1
2标准的参考································································2
3定义······································································3
4符号和缩写································································8
5常规······································································10
6系统描述··································································10
6.1信息流··································································10
6.2终端特性································································11
6.2.1本协议以外的终端元素··············································11
6.2.2本协议以内的终端元素··············································12
6.2.3LAN接口···························································12
6.2.4视频编码··························································12
6.2.5音频编码··························································13
6.2.6接收路径迟延······················································14
6.2.7数据通道··························································14
6.2.8H.245控制函数·····················································16
6.2.9RAS信号函数·······················································20
6.2.10呼叫信号函数·····················································20
6.2.11H.225.0层························································21
6.3网关特性································································21
6.4网闸特性································································24
6.5多点控制器特性··························································25
6.6多点处理器特性··························································26
6.7多点控制单元特性························································27
6.8多点能力································································27
6.8.1中心多点能力······················································27
6.8.2非中心多点能力····················································27
6.8.3混合多点-中心音频·················································28
6.8.4混合多点-中心视频·················································28
6.8.5建立常规模型······················································28
6.8.6多点速率匹配······················································29
6.8.7多点边缘同步······················································29
6.8.8多点加密··························································30
6.8.9级联多点控制单元··················································30
7 呼叫信号·······························································30
7.1地址····································································30
7.1.1LAN地址···························································30
7.1.2TSAP标识符························································30
7.1.3别名地址··························································30
7.2注册，管理和状态通道····················································31
7.2.1网闸的发现························································31
7.2.2端点注册··························································32
7.2.3端点定位··························································33
7.2.4许可，带宽改变，状态，断开········································34
7.3呼叫信号通道····························································34
7.3.1呼叫信号通道路由选择··············································34
7.3.2控制信道路由选择··················································35
7.4呼叫基准值······························································36
7.5会议ID和会议目标·······················································37
8 呼叫信令过程····························································37
8.1A阶段-建立呼叫··························································37
8.1.1基本呼叫建立-双方没有端点注册·····································37
8.1.2双方端点注册到同一网闸············································38
8.1.3只有主叫方端点有网闸··············································39
8.1.4只有被叫方端点有网闸··············································41
8.1.5双方端点注册到不同网闸············································42
8.1.6通过网关建立呼叫··················································46
8.1.7通过MCU建立呼叫··················································47
8.1.8呼叫转发··························································47
8.1.9建立广播呼叫······················································48
8.2B阶段-初始化通信和交换能力··············································48
8.3C阶段-建立视听通信······················································48
8.3.1模式转换··························································48
8.3.2双方协议的视频转换················································48
8.3.3媒体流地址分布····················································49
8.4D阶段-呼叫服务··························································49
8.4.1带宽改变··························································49
8.4.2状态······························································51
8.4.3特别多点会议扩展····················································51
8.4.4附加服务··························································58
8.5E阶段-呼叫结束··························································59
8.5.1不带网闸的呼叫清除················································59
8.5.2带网闸的呼叫清除··················································59
8.5.3使用网闸的呼叫清除················································60
8.6协议失败处理····························································61
9 与其他终端类型的协作····················································61
9.1只有话音的终端··························································61
9.2基于ISDN（H.320）的可视电话终端·········································62
9.3基于GSTN（H.324）的可视电话终端·········································62
9.4基于无线移动（H.324/M）的可视电话终端·································62
9.5基于ATM（H.324）的可视电话终端··········································62
9.6基于质量保证的LANs服务（H.322）的可视电话终端··························63
9.7基于GSTN（V.70）的同步语音和数据终端····································63
9.8LAN上的T.120终端·······················································63
10 可选扩展································································63
10.1加密···································································63
11 维护···································································64
11.1保护性回退·····························································64
11.2监测方法·······························································65
附件A-H.323端点使用的H.245消息···········································65
附录I-网关中Q.931消息的处理过程···········································65
ITU-T协议H.323
为局域网提供无质量保证服务的可视电话系统和设备
（Geneva，1996）
1 概述
本协议囊括了H.200/AV.120系列协议中定义的在传输路径包含一个或多个局域网
（LAN）的条件下的窄带可视电话服务的技术要求，这些局域网也许不能提供与N-ISDN相
同的质量保证服务的。这种类型的局域网有：
-以太网（IEEE 802.3）；
-快速以太网（IEEE 802.10）；
-FDDI（无质量保证服务方式）；
-令牌环网（IEEE 802.5）。
本协议囊括了在传输路径包含一个或多个局域网（LAN）的条件下的可视电话服务的情
况，这些局域网被配置成能够提供与N-ISDN相同的质量保证服务（QOS）从而使终端无需
提供任何H.320协议要求之外的附加保护性或恢复性机制的。相关的参数是数据错误和丢失
属性以及传输延迟的变化。一个恰当的LAN的例子是：综合服务（IS）局域网：IEEE 802.9A
具有载波侦听多路访问及冲突监测（CSMA/CD）媒体访问控制（MAC）服务的同步服务。
H.323终端可以用于多点配置，也可以和B-ISDN上的H.310终端，N-ISDN上的H.320
终端，B-ISDN上的H.321终端，有质量保证服务的LAN上的H.322终端，GSTN和无线网
络上的H.324终端，以及GSTN上的V.70终端相互协作。参见图1。
本协议范围不包含LAN本身，或可以用于连接不同局域网的传送层。本协议范围仅包
含与交换电路网交互（SCN）所需的元素。H.323网关，H.323终端，以及外围LAN的组合
在SCN上以H.320，H.310，H.324，或V.70终端的形式出现。
本协议描述了H.323系统的组件。其中包含终端（terminals），网关（Gateways），网闸
（Gatekeepers），多点控制器（Multipoint Controllers），多点处理器（Multipoint Processors）
和多点控制单元（Multipoint Control Units）。本协议中的控制消息（messages）和进程
（procedures）定义了这些组件如何通信。这些组件的详细描述参见条款（clause）6。
本协议中描述的组件由H.323的端点（endpoints）和实体（entities）组成。端点能通过
条款8的建立呼叫进程（call set-up procedures）呼叫（call）或被叫（callable）。然而实体是
不能被叫的，他们能被寻址（be addressed）到从而执行他们的专用功能。例如，虽然终端不
能呼叫网闸，但网闸被寻址到作为呼叫建立进程（call establishment procedures）的一部分。
Sc
H
H323.
Termnali
Non-guaranteed QOS LAN
(Note)
H323.
Gatekeeper
H323.
Gateway
H323.
Termnali
H323.
MCU
H323.
Termnai
GSTNGuaranteed
QOS
LAN
N-ISDNB-ISDN
V70.
Termnali
2
H324.
Termnali
图1/hH.323-H.323终端协作
SpeechH322.
Termnal
i
Termnali
Speech
Termnali
H320.
Termnali
H321.
Termnali
参考标准
NOTE ?Agat eway may supportone or more of he tGSTN N,-ISDNand/ or B-ISDNconnect ons.i
下列ITU-T协议和其他参考包含构成本协议的条款。在出版时，版本提示是有效的。所
有协议和其他参考易受修订；本协议的所有使用者最好查找下列协议和参考文献的最近版本。
近期有效的ITU-T协议应该定期出版。〖见H.323协议〗
3 定义
出于本协议的忠旨，H.225.0 [1]的条款3和H.245 [2]的条款3给出的定义同样适用于本
协议。这些定义只适用于LAN方面。其他用于交换电路网络（SCN）方面的术语应该会重点
指出。
3.1活动MC（active MC）：一种在主/从决定进程（master-slave determination procedure）中
获胜的MC，目前为会议提供多点控制功能。
3.2特别多点会议（ad hoc multipoint conference）：特别多点会议是一种在呼叫的某一时刻已
经扩展为多点会议的点对点（point-to-point）会议。如果初始的点对点会议的一个或多个终
端包含MC，或者呼叫是通过使用包含MC功能的网闸实现的，或初始呼叫是通过一个在两
个终端之间作为多点呼叫的MCU实现的，则特别多点会议就会发生。
3.3可寻址（addressable）：在LAN上的H.323实体有相应的传送地址。这与可被叫不同。
终端或MCU是可寻址且可被叫的。网闸是可寻址但不可被叫的。MC和MP是不可寻址也
不可被叫的，但却被包含在可寻址或可被叫的端点或网闸中。
3.4静音抑制（audio mute）： 对单个或所有声源（s）的音频信号的抑制。发送静音是指音
频数据流发生器削减自身的麦克风的噪声和/或根本不传送任何音频信号。接收静音是指接收
终端忽略某种特别的音频数据流或削减自身的喇叭的噪声。
3.5广播会议（broadcast conference）：广播会议是一种拥有一个媒体数据流发送器和多个接
受器的会议。它没有控制或媒体数据流的双向传送。如果可行的话，这种会议应该使用LAN
多用途传送设备实现。这种会议形式有待研究。
3.6广播面板会议（broadcast panel conference）：广播面板会议是多点会议和广播会议的一
种组合形式。在这种会议中，一些终端用于多点会议，而其他终端仅用于接收媒体数据流。
会议的多点端口的终端之间可以双向传送，但这些终端与收听终端之间不能双向传送。这种
会议形式有待研究。
3.7呼叫（call）：基于H.323端点之间的点对点多媒体通信。呼叫以呼叫建立进程开始，以呼
叫结束进程结束。呼叫由端点之间的可靠信道和非可靠信道的采集构成。当一些SCN端点通
过网关相互协作时，所有信道终止于网关，在网关他们被转换为SCN终端系统的适当的表示
形式。
3.8呼叫信令信道（call signalling channel）：基于二个H.323实体之间的用于传送呼叫建立和
拆除消息（遵循H.225.0协议）的可靠信道。
3.9可被叫（callable）：正如条款8中所描述的可被呼叫。终端，MCU和网关是可被叫的，
但网闸和MC是不可被叫的。
3.10集中式多点会议（centralized multipoint conference）：集中式多点会议是一种所有参加
的终端通过MCU以点对点的方式进行通信的会议。终端向MCU传送他们的控制，音频，
视频，和/或数据流。MCU中的MC集中管理会议。MCU中的MP处理音频，视频，和/或
数据流，以及向每个终端返回处理的数据流。
3.11控制和指示（C&I）（control and indication）：由控制和指示构成的终端之间的端到端信
号。其中，控制引起接收器状态的改变，指示提供系统状态或功能信息（详细信息和缩写请
参见协议H.245 [2]）
3.12数据（data）：不同于音频，视频和控制的信息流，在逻辑数据信道中传输（参见协议
H.225.0 [1]）。
3.13分散式多点会议（decentralized multipoint conference）：分散式多点会议是一种参加的
终端不使用MCU就能将他们的音频和视频数据向所有其他参加的终端发送的会议。终端负
责：
a）累计接收到的音频数据流；以及
b）选择一组或多组接收到的视频数据流用于显示。
这种情况下不需要音频或视频MP。终端在他们的H.245控制信道上使用有管理会议功能的
MC进行通信。数据流仍然由MCS-MCU集中处理，这些MCS-MCU可能包含在MP之内。
3.14端点（endpoint）：H.323终端，网关，或MCU。端点能呼叫或被叫。它产生和/或终止
数据流。
3.15网闸（gatekeeper）：网闸（GK）是在LAN上的H.323实体，它为H.323的终端、网关
和MCU提供地址转换和对局域网的控制访问。网闸也可以为终端、网关和MCU提供其他
服务，例如：带宽管理和网关定位。
3.16网关（gateway）：H.323网关（GW）是局域网上的一种端点，它提供LAN上H.323终
端与广域网络上其他ITU终端或另一个H.323网关之间的实时、双路通信。其他ITU终端包
括那些遵循协议H.310 （H.320在 B-ISDN）， H.320 （ISDN）， H.321 （ATM）， H.322
（GQOS-LAN）， H.324 （GSTN）， H.324M （移动），以及 V.70 （DSVD）的终端。
3.17 H.323实体（H.323 Entity）：任何H.323元素，包括终端、网关、网闸、MC、MP和
MCU。
3.18 H.245控制信道（H.245 control channel）：用于在H.323端点之间传送H.245控制信息
消息（遵循 H.245）的可靠信道。
3.19 H.245逻辑信道（H.245 logical channel）：用于在H.323端点之间传送信息流的信道。这
些信道的建立遵循H.245的OpenLogicalChannel进程。非可靠信道用于传送音频、音频控制、
视频以及视频控制信息流。可靠信道用于传送数据和H.245控制信息流。逻辑信道和物理信
道之间没有联系。
3.20 H.245对话（H.245 session）：呼叫的一部分开始于H.245的控制信道的建立，结束于接
收到H.245的EndSessionCommand或由于失败而结束。不要将对话与呼叫混淆，呼叫是由
H.225.0的Setup 和 Release Complete消息描述的。
3.21混合多点会议-集中式音频（hybrid multipoint conference – centralized audio）：混合多
点-集中式音频会议是一种终端向其他参加的终端多点发送他们的视频数据，以及向MP单点
发送他们的音频数据用于混合的会议。MP向每个终端返回混合的音频数据流。
3.22混合多点会议-集中式视频（hybrid multipoint conference – centralized video）：混合多
点-集中式视频会议是一种终端向其他参加的终端多点发送他们的音频数据，以及向MP单点
发送他们的视频数据用于交换和混合的会议。MP向每个终端返回混合的视频数据流。
3.23信息流（information stream）：从单个来源到一个或多个目的地的一种特定媒体信息形
式的（e.g.音频）信息流动。
3.24 LAN地址（LAN address）：由所使用的网络层协议定义的H.323实体的网络层地址（
地址）。通过网络协议中定义的规范，这种地址被映射成目标系统层上的另一个地址。
3.25唇同步（lip synchronization）：提供能感觉到显示的人物说话的动作与他的声音同步的
操作。
3.26局域网（LAN）（local area network）：一种共享或交换媒体，对等通信网络，能让适当
地域范围内的所有工作站收到广播信息，比如单个办公楼或校园。网络通常由某单个组织拥
有，使用和操作。在H.323协议中，LAN也包括通过网桥和路由器连接的几个LAN构成的
互联网。
3.27混合多点会议（mixed multipoint conference）：混合多点会议（参见图2）有一些终端 （D，
E和 F）使用集中方式参加而其他终端 （A， B和 C）在使用分散方式参加。终端并不清
楚会议的混合体制，只知道它参与的会议类型。MCU提供两种会议之间的桥接。
F
MCU
E
A
B
C
D
Unicast Audio and Video
Centralized Side
T1521210-96
Multicast Audio and Video
Decentralized Side
图2/H.233 混合多点会议
3.28 多点传送（multicast）：一种将PDU从一个源端点传送到多个目的端点的过程。这种过
程的实际机制（ 多点传送，多点-单点传送，等等）会因不同的LAN技术而不同。
3.29多点会议（multipoint conference）：多点会议是在三个或多个终端之间的会议。终端可
以在LAN或SCN上。多点会议应该总是由MC控制。本条款中定义了不同的多点会议类型
但他们每个会议都需要一个MC。在SCN上他们也可以包括一个或多个H.231 MCU。在LAN
上的终端也可以通过网关连接到SCN上的 MCU来参加SCN多点会议。这就不需要使用
MC。
3.30多点控制单元（multipoint control unit）：多点控制单元（MCU）是局域网上的一种端
点，它能提供三个或多个终端和网关参加多点会议的能力。它也可以连接在以后应该升级到
多点会议的点对点会议中的二个终端。MCU通常工作在H.231的MCU方式中，但语音处理
器并非必须的。MCU由二部分组成：必备的多点控制器和可选的多点处理器。在最简单的
情况下，MCU可以不需要MP而仅仅由一个MC组成。
3.31多点控制器（multipoint controller）：多点控制器（MC）是局域网上的一种H.323实体，
它能提供三个或多个终端参加多点会议的控制。它也可以连接在以后应该升级到多点会议的
点对点会议中的二个终端。MC提供所有终端能力协商以使通信达到普通水平。它也可以控
制会议资源，比如，是谁在多点传送视频数据。MC不执行音频、视频和数据的混合或交换。
3.32多点处理器（multipoint processor）：多点处理器（MP）是局域网上的一种H.323实体，
它能提供多点会议中音频、视频和/或数据流的集中处理。MP在MC的控制下提供媒体数据
流的混合、交换或其他处理。根据会议支持的形式MP可以处理单个或多个媒体数据流。
3.33多点-单点传送（multi-unicast）：一种传输PDU的过程，其中，端点向不同的端点发送
出一个以上相同的媒体数据流。这种传送也许在不支持多点传送的网络中是必备的。
3.34点对点会议（point-to-point conference）：点对点会议是一种基于二个终端的会议。它可
以直接基于二个H.323终端，也可以通过网关基于H.323终端和SCN终端。呼叫基于二个终
端之间（参见“呼叫”）。
3.35 RAS信道（RAS channel）：用于在二个H.323实体之间传送注册、管理、带宽改变以及
状态消息（参见协议H.225.0）的非可靠信道。
3.36可靠信道（reliable channel）：用于将信息流从源端点可靠地传送到目的端点的一种传输
连接。
3.37可靠传送（reliable transmission）：使用连接模式数据传送将消息从发送者到接收者的
传送。传送服务保证消息在传送连接中顺序的、错误释放的、流量控制的传送到接收者。
3.38 RTP对话（RTP session）：对每个参加者，对话由一对特定的目标传送地址（一个LAN
地址加上一个针对RTP和RTCP的TSAP标识符）所规定。目标传送地址对可能对于所有参
加者都是公有的，例如在IP多点传送中，也可能是对每个人都是不同的，例如在个体单点传
送网络地址中。在多媒体对话中，媒体音频和视频在分隔的RTP对话中以他们自己的RTCP
包传送。多个RTP对话以不同的传送地址区分。
3.39交换电路网（SCN）（switched circuit network）：公共或私有的交换通信网，比如GSTN，
N-ISDN，或B-ISDN。
3.40终端（terminal）：H.323终端是局域网上的端点，它提供与另一个H.323终端、网关、
或多点控制单元的实时、双路通信。这种通信包括二个终端之间的控制、指示、音频、移动
颜色视频图像和/或数据。终端可以只提供话音、话音和数据、话音和视频、或者话音、数据
和视频。
3.41传送地址（transport address）：由目前使用的网络协议组定义的可寻址的H.323实体的
传送层地址。H.323实体的传送层地址由LAN地址加上可寻址的H.323实体的TSAP标识符
组成。
3.42传送连接（transport connection）：为了传送数据而由传送层在两个H.323实体之间建立
的关联。在本协议中，传送连接提供信息的可靠传送。
3.43 TSAP标识符（TSAP identifier）：用于将单个 H.323实体上的同样类型的几路连接与所
有的连接进行多路复用并共享相同的LAN地址的信息（e.g. 在 TCP/UDP/IP环境下的端口
编号）。TSAP标识符可由一些国际权威（事先）静态指定，也可以在建立呼叫时动态分配。
动态指定的TSAP标识符是瞬时存在的，即他们的值仅在一个呼叫周期内有效。
3.44 单点传送（unicast）：一种从一个源端点到一个目的端点传送消息的过程。
3.45非可靠信道（unreliable channel）：用于从源端点到一个或多个目的端点不可靠的传送信
息流的逻辑通信路径。
3.46非可靠传送（unreliable transmission）：消息以非连接模式数据传送方式从发送者到一
个或多个接收者的传送。传送服务是PDU的最佳效果递送，即由发送者传送的消息可能被遗
失、复制、或被接收者认为无序。
3.47众所周知的TSAP标识符（well-known TSAP identifier）：由负责为特定（国际）互连网
协议和相关传送协议（e.g.为TCP和UDP端口编号分配的IANA）的分配TSAP标识符的（国
际）权威分配的TSAP标识符。这种标识符在各自协议的内容中保证是唯一的。
3.48地域（zone）：地域（参见图3）是所有终端（Tx）、网关（GW）、以及由单个网闸（GK）
管理的多点控制单元（MCU）的集合。地域至少包含一个终端，以及可能包含或不包含网关
或MCU。一个地域有且只有一个网闸。地域可以与LAN拓补结构无关，也可以由使用路由
器或其他设备连接的多个的局域网段构成。
Zone
T1
T2
GK
T3
GW
R
T4
R
图3/H.323 -地域
T5
MCU
T1521220-96
4 符号和缩写
根据本协议的忠旨，下列符号和缩写是：
4CIF
16CIF
ACF
ARJ
ARQ
BAS
BCF
BCH
4次 CIF
16次 CIF
许可确认
许可放弃
许可请求
位速率定位信号
带宽改变确认
Bose， Chaudhuri，和 Hocquengham
B-ISDN
BRQ
C&I
CID
CIF
DCF
DID
宽带综合数字服务网
带宽改变请求
控制和指示
会议标识符
共同的中间形式
放弃确认
直接内部拨号
DRQ
ECS
EIV
FAS
FIR
GCF
GK
GQOS
GRJ
GRQ
GSTN
GW
IANA
IP
IPX
IRQ
IRR
ISDN
ITU-T
LAN
LCF
LCN
LRJ
LRQ
MC
MCS
MCU
MP
MSN
N-ISDN
NACK
QCIF
放弃请求
加密控制信号
加密初始化矢量
帧定位信号
完全内部请求
网闸确认
网闸
质量保证服务
网闸放弃
网闸请求
通用电话交换网
网关
互联网指定编号权威
互联网协议
互联网协议交换
信息请求
信息请求应答
综合数字服务网
国际电信联盟标准化区
局域网
定位确认
逻辑信道编号
定位放弃
定位请求
多点控制器
多点通信系统
多点控制单元
多点处理器
多点用户编号
窄带综合数字服务网
消极确认
四分之一 CIF
RCF
RRJ
RRQ
RTP
RTCP
SBE
SCM
SCN
SPX
SQCIF
TCP
TSAP
UCF
UDP
URJ
URQ
5 约定
注册确认
注册放弃
注册请求
实时协议
实时控制协议
单比特扩展
已选通信模式
交换电路网
连续协议转换
副 QCIF
传送控制协议
传送层服务访问点
未注册确认
用户自带寻址协议
未注册放弃
未注册请求
在本协议中，使用了下列约定：
"Shall"意味着强制性要求。
"Should"意味着建议但在操作中可选。
"May"意味着在操作中可选，胜于某些已实现的协议。
对于条款、子条款、附件和附录的参考是指本协议以内的术语，除非另一个文档明确地
列表显示出来。例如，1.4是指本协议中的1.4;6.4/H.245是指协议H.245中的6.4。
当LAN和SCN中存在相同的术语，对SCN术语的将作出明确解释。例如，MCU是指
LAN上的H.323 MCU，SCN-MCU是指在SCN上的MCU。
本协议描述了三个不同消息类型的使用：H.245、RAS和Q.931。以下是不同消息类型的
区别。H.245消息和参数名由多重的连结字以粗体字突出显示构成（maximumDelayJitter）。
RAS消息名由三个字母缩写代表（ARQ）。Q.931消息名由第一个字母大写的一个或两个单
词构成（Call Processing）。
6 系统描述
本协议描述了H.323组件的元素。它们是终端、网关、网闸、MC和MCU。这些组件通
过信息流的传送进行通信。本条款中将描述这些组件的特性。
6.1信息流
可视电话组件通过信息流的传送进行通信。这些信息流分为如下的视频、音频、数据、
通信控制和呼叫控制。
音频信号包含数字化语音和编码语音。为了减少音频信号的平均位速率，需要提供语音
激活。音频信号伴随着音频控制信号。
视频信号包含数字化视频和移动编码视频。由于能力交换，视频以不大于采样频率的速
率进行传送。视频信号伴随着视频控制信号。
数据信号包含静态图像、传真、文档、计算机文件和其他数据流。
通信控制信号在类似于远程功能元素之间传送控制数据，并用于能力交换、打开和关闭
逻辑信道、方式控制和其他部分通信控制功能。
呼叫控制信号用于呼叫建立、断开和其他呼叫控制功能。
上述信息流是规定格式的，并按照协议H.225.0中所描述的传送到网络界面。
6.2终端特性
图4是H.323终端一个例子。图中显示了用户设备界面、视频编码器、音频编码器、远
程信息处理设备， H.225.0层、系统控制功能和与LAN交互的界面。所有H.323终端应该有
一个系统控制单元、H.225.0层、网络界面和音频编码器单元。视频编码器单元和用户数据应
用程序是可选的。
323.H oe pcoS
tenmpiueq OI/ eodiV
ecdoC eodiV
362.H ,162.H
eveceiR
hatP
ayelD
tenmpiueq OI/ oiduA
ecdoC oiduA
,227.G ,117.G
,827.G ,327.G
927.G
snoicatilppAa atDser U
c.,t e0.21T
lrotnoC emstyS
lrotnoC 542.H
lrotnoC emstyS
erfacetInser U
lrotnoC alC
0.522.H
l
rotnoC SAR
图4/H.323 - H.323终端设备
0.522.H
6.2.1本协议以外的终端元素
下列元素不属于本协议范围内，因此没有在本协议中定义：
0.522.H
erayL
附属音频设备提供语音激活感应、麦克风和喇叭、电话工具或等价物、多重的麦克风混
频器、以及回声消除器。
附属视频设备提供照相机和监视器以及他们的控制和选择，改善压缩或提供分屏功能的
视频处理。
使用T.120的数据应用程序和相关的用户界面或基于数据通道的其他数据服务。
附属网络界面，它提供与LAN的界面，支持适当的信号和电平，遵循国内和国际标准。
人类用户系统控制、用户接口和操作。
6.2.2本协议以内的终端元素
下列元素属于本协议范围内，因此易于标准化并在本协议中定义：
视频编码器（H.261等等）把从视频源（i.e.照相机）传来的视频编码传送出去以及将接
收到的视频代码解码并输出到视频显示器。
音频编码器（G.711等等）把从麦克风传来的音频信号编码传送出去以及将接收到的音
频代码解码并输出到喇叭。
数据通道支持远程信息处理应用程序如电子白板、静态图象传输、文件交换、数据库访
问、可视会议等等。用于实时可视会议的标准化数据应用程序是协议T.120。其他应用
程序和协议也可以通过在 6.2.7中指定的H.245协商使用。
系统控制单元（H.245，H.225.0）为 H.323终端适当的操作提供信号。它提供呼叫控制、
能力交换、命令和指令的信号化以及消息打开并完全描述逻辑信道的内容。
H.225.0层（H.225.0）使传送的视频、音频、数据和控制流转化成消息格式从而输出到
网络界面，以及从网络界面输入的消息中恢复接收到的视频、音频、数据和控制流。此
外，它执行适合每种媒体形式的逻辑分帧、顺序编号、错误检测和错误改正。
6.2.3 LAN界面
LAN界面是专用的实现，而且已超出了本协议范围之外。尽管如此，LAN界面应该提
供在H.225.0协议中描述的服务。这包括以下内容：可靠的（， SPX）端对端服务是
H.245控制信道、数据信道以及呼叫信号通道必备的；非可靠的 （， IPX）端对端
服务是音频信道、视频信道、以及 RAS信道必备的；这些服务可以是双工的或单工的，单
点传送或多点传送，这取决于应用程序、终端能力以及LAN的配置。
6.2.4视频编码器
视频编码器是可选的。所有提供视频通信的H.323终端应该能够根据H.261 QCIF对视频
进行编码和译码。终端也可以任意根据 H.261 CIF或H.263 SQCIF、QCIF、CIF、4CIF，以
及16CIF对视频进行编码和译码。如果终端能以CIF或更高的分辨率支持H.263，则它也能
以CIF支持H.261。所有支持H.263的终端应该能以QCIF支持H.263。在LAN上使用H.261
和H.263编码器不应该包含BCH错误纠正和错误纠正帧。
其他视频编码器以及其他图片格式，也可以通过H.245协商使用。一个或多个视频信道
按照通过H.245控制信道协商的方法也可以被传送和/或被接收。H.323终端可以任意同时传
送一个以上视频信道，例如，传送演讲者和一秒视频源信号。H.323终端可以任意同时接收
一个以上视频信道，例如，显示分布式多点会议多个参加者。
H.261协议定义了CIF和QCIF。H.263协议定义了SQCIF、4CIF和16CIF。就H.261算
法而言，SQCIF是任何尺寸小于QCIF的活动图片，由黑边框填充，并以QCIF格式编码。
所有这些格式，像素纵横比跟CIF格式一样。
说明-H.263 SQCIF导致的图片纵横比不同于其他格式。
视频位速率、图片格式以及解码器能够接受的算法选择在使用H.245进行能力交换时定
义。编码器可以自由传送在解码器能力范围之内的任何东西。解码器应该能够通过H.245为
某种特定模式产生请求，但如果他们不是命令模式，编码器可以允许简单地忽略这些请求。
指示某种特定的算法选项能力的解码器也应该能够接受没有使用那种算法选择的视频比特
流。
H.323终端应该能够在对称呼叫视频位速率、帧速率下运作，而且如果支持双图片以上
的分辨率的话，也能在该图片分辨率下运作。例如，有此能力的CIF终端应该能在接收 CIF
图像时传送 QCIF。
当每个视频逻辑信道打开时，包含使用最大操作模式信道信息的H.245
OpenLogicalChannel消息应该传送给接收者。最大模式信号包含最大图片格式、算法选择、
最大编码器位速率等等。视频逻辑信道中的标题指示了在既定最大模式下每幅图片实际采用
的模式。例如，为CIF格式打开的视频逻辑信道可以传送CIF、QCIF或SQCIF图像，但不
能传送4CIF或16CIF图像。仅以 unrestrictedVector和 arithmeticCoding选项打开的视频逻辑
信道可以两者都不使用，或者使用其中之一，或者两者都用，但不能使用没有信号指定的选
项。
视频数据流采用H.225.0协议中描述的格式。
6.2.4.1基于终端的连续显示
H.323终端可以接收到一个以上视频信道，特别是在多点会议中。在这些情况中，H.323
终端可能需要执行视频混合或交换功能从而能为用户显示视频信号。这种功能可能包括从一
个以上终端向用户显示图像。H.323终端应该使用H.245同步功能来指示它能够对多少同步
视频数据流解码。终端同步功能不应限制会议中属于多点传送的视频数据流的编号（由MC
决定）。
6.2.5音频编码器
所有H.323终端应该有音频编码器。所有H.323终端应该能根据G.711协议对语音进行
编码和译码。所有终端应该能够传送和接收A-律和u-律信号。终端可以任意根据协议 G.722、
G.728、G.729、MPEG 1音频，以及G.723对语音进行编码和译码。编码器使用的音频算法应
该在使用H.245进行能力交换时获得。H.323终端应该能够对在其语音能力范围内的所有语
音能力进行非对称呼叫操作，例如，如果它能够遵循G.711和G.728，那么它就能传送 G.711，
也能接收 G.728。
音频数据流采用H.225.0协议中描述的格式。
H.323终端可以同时任意传送一个以上音频信道，例如，允许二路语言被传送。
音频数据包应该定期递送给传送层，时间间隔由使用的音频编码器协议决定（音频帧间
隔）。每个音频数据包的递送应该在从第一个音频帧发送开始计算的（音频延迟抖动）一整个
音频帧间隔后5 ms之内发生。音频编码器也可以使用包含在终端能力设置消息内的由H.245
协议的h2250Capability结构的maximumDelayJitter参数来进一步限制他们的声音延迟抖动
的能力，这样，接收者可以任意减少他们的抖动延迟缓冲区。这与RTCP间隔抖动区域不同。
说明-对最大延迟抖动的测试点是在网络传送层的输入端。不包括网络堆栈、网络、驱动器和
界面卡片抖动。
6.2.5.1音频混合
H.323终端可以接收一个以上音频信道，特别是在多点会议中。在这些情况中，H.323
终端可能需要执行音频混合功能从而能为用户重现合成语音信号。H.323终端应该使用H.245
同步功能来指示它能够对多少同步音频数据流解码。终端同步功能不应限制会议中属于多点
传送的音频数据流的编号。
6.2.5.2最大音频-视频传送时滞
为了允许H.323终端能适当的设置他们的接收缓冲池（s）大小， H.323终端应该在向
网络传送时传送h2250MaximumSkewIndication消息指示音频和视频信号之间最大时滞。
h2250MaximumSkewIndication应该发送给每对音频和视频组合逻辑信道。对于仅有音频信号
或混合会议唇同步是没有这个要求的，如果要求的话，终端可以通过使用时间戳来实现。
6.2.6接收路径延迟
接收路径延迟包含为保持同步而叠加在媒体数据流上的延迟和网络数据包到达时间的
抖动的累计。媒体数据流可以在接收器处理路径上任意延迟从而保持与其他媒体数据流的同
步。具体地说，就是媒体数据流可以任意延迟从而允许网络延迟引起数据包到达时间的抖动。
H.323终端不应该因此而在它的传送媒体路径上加延迟。
中间处理点如MCU或网关可以改变视频和音频的时间标记信息，而且也应该适当的传
送修改了的音频和视频时间标记以及顺序编号，映射他们的传送信号。接收端点可以在音频
路径上加适当的延迟从而达到唇同步。
6.2.7数据通道
一个或多个数据通道是任选的。数据通道可以是单向或双向的，这取决于数据应用程序
的要求。T.120协议是数据在H.323终端和其他H.323， H.320，或 H.310终端交互的默认基
础。使用一个或多个可通过H.245协商的ITU-T协议可以实现任何可选的数据应用程序，等
价的T.120应用程序，若有的话，应该是那些提供的协议之一。使用H.281和 H.224提供远
程-端点照相机控制的终端并不要求也支持 T.120远程-端点照相机控制协议。
注意，不管等价T.120应用程序是否支持，非标准数据应用程序（dataApplicationCapability
=非标准应用程序， dataProtocolCapability =非标准）和透明用户数据
（dataApplicationCapability = 用户应用程序， dataProtocolCapability = 透明）都会被使用。
T.120能力应该使用 dataApplicationCapability = t120应用程序， dataProtocolCapability =
separateLANStack 来标识。
数据通道采用H.225.0协议中描述的格式。
6.2.7.1 T.120数据通道
在 H.323呼叫内容中有二种建立 T.120连接的方法。一是当 H.323呼叫作为呼叫的内部
呼叫部分，使用H.245的进程打开逻辑信道时建立 T.120连接。二是在H.323呼叫之前建立
T.120连接。
在H.323呼叫先建立的情况下，随之而来的是8.1的普通呼叫过程。能力交换发生，以
及根据普通 H.245进程双向逻辑信道应该为 T.120连接打开，指示一个新连接应该按如下描
述创建。
为 T.120打开的双向逻辑信道可以由任意实体传送的 openLogicalChannel初始化，然后
遵循H.245协议的双向逻辑信道进程。
为了实际打开逻辑信道，初始化实体应该传送 openLogicalChannel消息，以
forwardLogicalChannelParameters和reverseLogicalChannelParamete指示T.120数据通道应该
被打开。初始化者应该决定是否在 openLogicalChannel消息中包含传送地址。如果对方（应
答器）接受了该逻辑信道，它应该用 openLogicalChannelAck确认逻辑信道的打开。在
openLogicalChannelAck中，应答器应该包含用于建立T.120连接的传送地址，如果它没有收
到初始化者传来的传送地址。否则，就会缺少传送地址。在这两种情况中， 用于T.120连接
的传送地址应该由separateStack参数传送。
实体传输传送地址应该为在该传送地址接受 T.120连接作准备。实体接收传送地址应该
使用前面接收到的传送地址为建立T.120连接初始化。
在openLogicalChannel和openLogicalChannelAck消息中，associateConference参数应该
设置为false。
T.120协议应该遵循T.123协议关于由dataProtocolCapability标识的协议栈的进程，但上
述传送地址应该为建立连接所专用的情况除外。 H.245主/从决定进程的获胜者应该有权成为
T.120连接中的上层节点。
说明：完成建立连接的T.120操作超出了本协议的范围。
在 T.120连接先建立的情况下，H.323呼叫跟随在8.1的普通呼叫建立进程之后。能力
交换发生，而且它应该将T.120连接和H.323呼叫关联起来。H.245协议的进程用于为 T.120
数据通道打开双向逻辑信道，如下详述。
为T.120打开的双向逻辑信道可以由任意实体传送的openLogicalChannel初始化，然后
遵循H.245协议的双向逻辑信道进程。建立连接的初始化者应该在openLogicalChannel消息
中包含已经存在的T.120连接的标识信息，指示对方哪一个T.120连接（如果有一些的话）
应该被关联。
为了实际打开逻辑信道，初始化实体应该为双向逻辑信道传送openLogicalChannel消息，
以forwardLogicalChannelParameters和reverseLogicalChannelParameters指示T.120数据通道应
该被打开。如果对方（应答器）接受了该逻辑信道，它应该返回一个 openLogicalChannelAck
给初始化者，该消息中可能包含了它自身用于传送连接的本地标识符。在这两种消息中，
associateConference参数应该设置为true。
作为标识信息，T.120连接的初始传送连接的本地（动态例示）传送地址应该由
separateStack参数提供。此外，externalReference参数用于提供哪一个T.120连接应该被关联
的进一步信息。
如果没有任何标识信息对初始化者有效，初始化者应该省略各自的值（s）。
说明-如果传送地址不明确而且二个端点共享了一个以上的T.120连接，那么接收者就不能明
确所指的是哪一个T.120连接。这种模糊的含意和避免它出现的方法有待研究。
6.2.8 H.245控制功能
H.245控制功能使用H.245控制信道传送端对端管理H.323实体的操作的控制消息，包
括能力交换、逻辑信道的打开和关闭、流控制消息以及常用命令和指令。
H.245信令在二个端点之间建立：一个端点和一个MC，或一个端点和一个网闸。端点
应该为每一个有端点参加的呼叫建立一条明确的H.245控制信道。信道应该使用H.245的消
息和进程。注意：终端、MCU、网关或网闸可以支持多个呼叫，于是就有多个H.245控制信
道。H.245控制信道应该由逻辑信道0承担。逻辑信道0应该被认为是从H.245控制信道的
建立开始就永久开放的，直到关闭H.245控制信道。普通的打开和关闭逻辑信道的进程不应
适用于H.245控制信道。
H.245协议指定了许多支持端对端信号的独立协议的实体。协议实体是由它的语法（消
息）、语义以及指定消息交互和用户交互的一系列进程定义的。H.323端点应该支持语法、语
义以及下列协议实体的进程：
主/从决定。
能力交换。
逻辑信道信令。
双向逻辑信道信令。
关闭逻辑信道信令。
模式请求。
环路延迟决定。
环路保持信令。
常用命令和指示应该从H.245协议包含的消息集中抽取出来。另外，其他已经指定了用
于带内传输视频、音频或数据流的命令和指示信号可以被传送出去（如果这样的信号已经被
定义，请参见适当的协议作出决定）。
H.245消息分为四类：请求、响应、命令以及指示。请求和响应消息由协议的实体使用。
请求消息需要接收者的专用操作，包括立即应答。应答消息响应相应的请求。命令消息需要
专用操作，但不需要应答。指示消息仅仅是情报性的，且不需要任何操作或应答。H.323终
端应该响应附件A中指定的所有H.245命令和请求，而且应该传送反映终端状态的指示。
H.323终端应该能够剖析所有H.245 MultimediaSystemControlMessage消息，而且应该发
送和接收所有实现必需功能以及终端支持的可选功能的消息。附件A包含的表格显示出对于
H.323终端哪些 H.245消息是命令的、可选的或禁止的。H.323终端应该发送
functionNotSupported消息来响应任何未被确认的请求，应答，或它接收到的命令消息。
H.245指示，userInputIndication，对用户从键区或键盘输入的有效文字数字字符的传送
是有效的，等价于用于类似电话技术的DTMF信号，或协议H.230中的SBE编号消息。这
个指令可以用于手动操作远程设备如语音电子邮件或视频邮件系统、菜单驱动方式信息服务
等等。H.323终端应该支持用户输入字符0-9、“*”和“#”的传送。其他字符的传送是可选
的。
说明-如果使用了本协议的加密进程，H.245控制信道不会被加密。因此用户要警惕H.245控
制信道中用户数据的托架，非标准消息的使用，以及从H.245控制信道的流量分析中得出的
可能危险。
三个H.245请求消息与RTCP控制包冲突。H.245 videoFastUpdatePicture，
videoFastUpdateGOB和videoFastUpdateMB请求应该用于代替充满节点内请求（FIR）和否
定承认（NACK）的RTCP控制包。接受FIR和NACK的能力在H.245能力交换时转换成信
号。
6.2.8.1能力交换
能力交换应该遵循H.245协议的进程，该进程提供了分隔接收和发送的能力，以及终端
可以同时描述它在各种模式的组合中的操作能力。
接收能力描述了终端接收和处理输入信息流的能力。发送者应该限制他们发送的信息含
量符合接收者表明的它能够接收的能力。缺乏接收能力意味着终端不能接收数据 （仅仅是个
发送者）。
发送能力描述了终端发送信息流的能力。发送能力用来向接收者提供可能的操作方式，
这样接收者可以请求它的最佳接收方式。缺乏发送能力意味着终端不能向接收者提供最佳接
收方式（但它仍然可以在接收者的能力范围之内发送一些数据的）。
发送终端为每个独立的方式指定终端，这些终端能够以capabilityTable中的编号操作。
例如，G.723音频，G.728视频，以及CIF H.263视频应该分别被指定单独的编号。
这些能力编号被分组成alternativeCapabilitySet结构。每个alternativeCapabilitySet意味着
终端只能以设置中的一种确定的方式操作。例如，列出了{G.711，G.723，G.728}的
alternativeCapabilitySet意味着终端能够以这些音频方式中的任意一种方式工作，但不能多于
一种方式。
这些alternativeCapabilitySet结构被分组成simultaneousCapabilities结构。每个
simultaneousCapabilities结构意味着终端能够同时使用的一系列方式。例如，
simultaneousCapabilities结构包含二个alternativeCapabilitySet结构{H.261，H.263}和{G.711，
G.723，G.728}，意味着终端能同时操作任何一个视频编码器和任何一个音频编码器。
SimultaneousCapabilities系列{{H.261}，{H.261， H.263}，{G.711，G.723，G.728}}意味着终
端能同时操作二个视频信道和一个音频信道：一个遵循H.261的视频信道，一个遵循H.261
或H.263的视频信道，一个遵循G.711或G.723或G.728的音频信道。
说明-存储于capabilityTable中的实际能力通常比上述提到的更复杂。例如，每个H.263能力
意味着包含支持不同的图片格式在给定的最小图片间隔的能力，以及使用可选的编码方式的
能力的具体细节。具体描述请参见H.245协议。
终端总能力由一套capabilityDescriptor结构描述，其中每一个都由一个
simultaneousCapabilities结构和capabilityDescriptorNumber组成。通过传送一个以上
capabilityDescriptor，终端可以依靠所描述的能够同时使用的不同的系列方式来用信号通知操
作方式之间的依赖关系。例如，一个终端拥有二个capabilityDescriptor结构，一个是前例中
的{{H.261，H.263}，{G.711，G.723，G.728}}，而另一个是{{H.262}，{G.711}}，这意味着终
端能够操作H.262视频编码器，但只能和G.711低复杂度音频编码器同时使用。
终端可以在一个通信对话期内通过发送附加capabilityDescriptor结构来动态地增加性能，
或通过发送修改了的 capabilityDescriptor结构来删除性能。所有的H.323终端应该能传送至
少一个capabilityDescriptor结构。
非标准性能和控制消息可以用H.245协议中定义的nonStandardParameter结构产生。注
意：当非标准消息的含义由个体组织定义后，如果这种定义是众所周知的，那么任何厂商生
产的设备可以以任何非标准消息为信号。
根据H.245协议的进程，在任何时候终端都可以再产生性能集合。
6.2.8.2逻辑信道信令
每个逻辑信道从一个发送者向一个或多个接收者传送信息，并且由一个逻辑信道编号识
别，这个逻辑信道编号是为每个传送方向专用的。
逻辑信道通过使用openLogicalChannel和closeLogicalChannel消息和H.245协议的进程
打开和关闭。当逻辑信道打开时，openLogicalChannel消息完全描述了逻辑信道的内容，包
括媒体类型、使用的算法以及接收者需要解释逻辑信道的内容的其他所有信息。当不再需要
使用时，逻辑信道可以被关闭。打开逻辑信道可以是非激活的，如果消息源没有信息需要传
送的话。
本协议中，大多数逻辑信道是单向的，这样非对呼叫操作，即在每个传送方向上信息流
的编号和类型是不同的，是可以进行的。然而，如果接收者仅能操作某种特定的对称呼叫方
式，除了本协议特别指出以外，它可以发送一个接收性能集来反映它的限制。终端也能够仅
在一个传送方向上使用特别的方式传送。某种特定的媒体类型，包括数据协议如T.120，他
们的操作需要固有的双向信道。在这种情况下，一对单向逻辑信道，每个方向各一个，可以
使用H.245协议的双向信道打开进程打开并关联在一起形成双向信道。这对关联的信道不需
要共享相同的逻辑信道编号，因为逻辑信道编号在每个传送方向上是独立的。
逻辑信道应该按照下列进程打开：
初始终端应该发送H.245协议中描述的OpenLogicalChannel消息。如果逻辑信道要使用
RTP传送媒体类型（音频或视频），则OpenLogicalChannel消息应该包含 mediaControlChannel
参数，该参数包含RTCP反向信道的传送地址。
应答终端应该以H.245协议中描述的OpenLogicalChannelAck消息应答。如果逻辑信道
要使用RTP传送媒体，则OpenLogicalChannelAck消息应该包含mediaTransportChannel参数
和mediaControlChannel参数，其中，mediaTransportChannel参数包含媒体信道的RTP传送地
址，mediaControlChannel参数包含前向RTCP信道的传送地址。
没有使用RTP/RTCP的媒体类型（比如T.120数据）应该省略mediaControlChannel参数。
如果一个相应的反向信道为一个特定存在的RTP对话（由RTP sessionID识别）打开，
则由OpenLogicalChannel进程交换的mediaControlChannel传送地址应该与那些使用了前向信
道的相同。如果发生了冲突，即两端点同时企图建立冲突的RTP对话，主端点应该按照H.245
协议中描述的那样，拒绝冲突企图。然后，被拒绝的OpenLogicalChannel企图可以在稍后时
间再试。
6.2.8.3方式选择
接收者可以请求发送者使用H.245 requestMode消息发送一个描述最佳方式的特别方式。
如果可能的话，发送者应该服从该请求。
从MC接收到multipointModeCommand的端点应该服从所有requestMode命令，如果命
令请求在它们的能力集之内的话。注意：在分散会议中，就象在集中会议中一样，所有终端
的requestMode命令是指向MC的。MC可以授予请求或不授予；决定权留给厂商。
6.2.8.4主/从决定
H.245主/从决定进程用于解决都能成为会议的MC的二个端点之间，或企图打开一个双
向通道的二个端点之间的冲突。在这一进程中，二端点在H.245 masterSlaveDetermination消
息中随机地交换编号，决定主/从工作端点。H.323端点应该将terminalType的值设置成下表
1中指定的值，将statusDeterminationNumber的值设置成0～2
24
-1范围内的随机数。每个呼
叫的端点应该只能选择一个随机数，除了H.245协议中描述的相同的随机编号的情况。
表1/H.323 - H.245主/从决定的H.323终端类型
终端类型值列表
特征系列 终端
H.323实体
网关 网闸
MCU
没有MC的实体
包含MC但没有MP的实体
包含带有数据MP的MC的实体
包含带有数据和音频MP的MC的实体
包含带有数据、音频和视频MP的MC的实
体
50
70
NA
NA
NA
60
80
90
100
110
NA
120
130
140
150
NA
160
170
180
190
会议中的活动MC应该使用值240。层叠MC有待研究。
如果单个H.323实体能参与多重呼叫，那么在主/从决定进程中terminalType使用的值应
该基于H.323实体已经或将要分配给呼叫信令的特征。
已经充当了MC的MC应该总是保持活动MC。因此，一旦一个MC已经被选定作为会
议的活动MC，那么在会议的所有后来的连接中都应该使用活动MC值。
如果没有MC是活动的而且实体都是相同类型，那么实体最高特征设置的H.323实体（如
表1所示）应该在主/从决定中获胜。如果没有MC是活动而且实体是不同类型，那么位于
MCU中的MC应该具有比位于网闸中的MC高的优先级，位于网闸中的MC的优先级高于
位于网关中的MC，当然，位于网闸中的MC的优先级相应的高于位于终端中的MC。
如果H.323实体能与表1中二个以上的分类相关联，那么它应该使用它具有的最高值。
6.2.8.5定时器和计数器的值
所有H.245协议中定义的定时器应该有至少与传送H.245控制信道的数据链路层（包括
任何重传）允许的最大数据递送时间一样长的周期。
H.245重算计数器N100应该至少是3。
与H.245协议错误处理相关的进程在8.6中详述。
6.2.9 RAS信令功能
RAS信令功能使用H.225.0消息执行注册、许可、带宽变化、状态以及端点和网闸之间
的断开过程。RAS信令信道独立于呼叫信令信道和H.245控制信道。H.245打开逻辑信道进
程不能用于建立RAS信令信道。在没有网闸的LAN环境中没有使用RAS信令信道。在包含
网闸（地域）的LAN环境中，RAS信令信道在端点和网闸之间打开。RAS信令信道的打开
先于任何其他位于H.323端点之间的信道的建立。这一信道在条款7中详细描述。
6.2.10呼叫信令功能
呼叫信令功能使用H.225.0呼叫信令在H.323二个端点之间建立连接。呼叫信令信道独
立于RAS信道和H.245控制信道。H.245打开逻辑信道进程不能用于建立呼叫信令信道。呼
叫信令信道的打开先于位于H.323端点之间的H.245信道和任何其他信道的建立。在没有网
闸的系统中，呼叫信令信道在包含于呼叫中的二个端点之间打开。在包含网闸的系统中，呼
叫信令信道在端点和网闸之间，或由网闸选中的端点之间打开。这一信道在条款7中详细描
述。
6.2.11 H.225.0层
视频、音频、数据或控制信息的逻辑信道是根据H.245协议的进程建立的。逻辑信道是
单向的，而且在每个传送方向上是独立的。一些逻辑信道，比如数据，可能是双向的，而且
与H.245协议打开双向逻辑信道的进程相关联。每种媒体类型的任何逻辑信道编号是可传送
的，但每一个呼叫都必须有一个控制信道的H.245控制信道除外。除逻辑信道之外，H.323
端点为呼叫控制使用二个信令信道，以及网闸的相关功能。这些信道使用的格式应该遵循
H.225.0协议。
6.2.11.1逻辑信道编号
每个逻辑信道由一个范围在0～65535的逻辑信道编号（LCN）标识，逻辑信道编号仅
用于将逻辑信道和传送连接关联起来。逻辑信道编号由传送者任意选定，但逻辑信道0应该
被永久地分配给H.245控制信道。传送者应该传送的实际传送地址，应该由接收者以
openLogicalChannelAck消息返回。
6.2.11.2逻辑信道位速率限制
逻辑信道的带宽应该有一个上限，这个上限由端点的传送能力（如果是当前值）和接收
端点的接收能力的最小值决定。基于这一限制，端点应该以等于或小于该限制的位速率打开
逻辑信道。传送者应该在以等于或小于打开逻辑信道的位速率传送的逻辑信道内传送信息流。
这种限制适用于包含逻辑信道的内容（s）的信息流，但它不包括RTP消息头，RTP有效负
载消息头以及LAN消息头和其他头上信息。
H.323端点应该服从H.245的flowControlCommand消息，这个消息规定了对逻辑信道的
位速率或所有逻辑信道的位速率累计的限制。试图限制逻辑信道位速率或所有逻辑信道的位
速率累计的H.323端点，应该将flowControlCommand消息发送给传送端点。
当终端没有信息向给定信道发送时，终端不应该发送信息。为了保证一定的数据码率，
填充数据不应该在LAN上发送。
6.3网关特性
网关应该在传送格式之间（例如H.225.0到/从H.221）和通信进程之间（例如 H.245到/
从 H.242）提供适当的翻译。网关也应该在LAN和SCN上执行呼叫建立和清除功能。视频、
音频和数据格式之间的翻译也可以在网关中进行。通常，网关的目的（当不充当MCU时）
是以透明方式向SCN端点反映LAN端点的特性，以及反向翻译。
H.323端点可以在相同LAN上直接与另一个H.323端点通信，而且不需要网关。如果与
SCN终端（终端不在LAN上）的通信未被要求的话，可以省略网关。它也可以使在一段LAN
上的终端通过路由器或低带宽链接，从一个网关呼叫再通过另一个网关返回到LAN上成为
可能。
网关有LAN上H.323终端或MCU的特性，以及SCN上SCN终端或MCU的特性。终
端或MCU的选择留给厂商。网关提供不同终端类型之间的必要转换。注意：网关可以最初
作为终端工作，但稍后使用 H.245信号为初始是点对点的相同的呼叫充当MCU。当终端/网
关向网闸注册后，网闸就知道哪一个终端是网关。
在SCN和LAN之间传送T.120数据的网关可以包含T.120 MCS提供者，该提供者将LAN
上的T.120 MCS提供者与SCN上的T.120 MCS提供者连接起来。
四个H.323网关的例子显示在图5中。该图显示了H.323终端或MCU的功能，SCN终
端或MCU的功能，以及转换功能。H.323终端功能有6.2中描述的特性。H.323 MCU功能有
6.5中描述的特性。对LAN上其他H.323终端而言，网关可以看成是一个或多个H.323终端，
或 H.323 MCU。它使用本协议中的进程与其他H.323终端通信。
SCN终端或MCU的功能在适当的协议中（H.310， H.320， H.321， H.322， H.324，
V.70， GSTN或 ISDN语音终端）有特性描述。对SCN上的终端而言，网关可以看成是一
个或多个相同终端类型或MCU。它在SCN上使用相应协议中对该终端描述的进程与该终端
通信。SCN信令进程，包括类似于对SCN而言，是否将H.323网关看成终端或网络的问题
等，均超出了本协议的范围。注意：网关不需要通过H.320就可以直接将H.323转换成H.324
或H.310。
支持GSTN或ISDN上只有语音的终端的互联的网关应该产生并检测DTMF信号在0-9、
*和#范围内与H.245 userInputIndications相符。
LAN
H323.
Termnali
Functoni
Conversion
Functoni
SCN
Termnali
Functoni
Gateway A
LAN
H323.
MCU
Functoni
Conversion
Functoni
SCN
Termnali
Functoni
Gateway B
LAN
H323.
Termnali
Functoni
Conversion
Functoni
SCN
MCU
Functoni
Gateway C
LAN
H323.
Conversion
MCUFunctoni
图5/H.323 - H.323网关配置转换
Functoni
SCN
MCU
Functoni
转换功能提供了两个不同协议终端之间的传送格式、控制、音频、视频和/或数据流的必
Gateway D
要转换。至少，网关应该为传送格式、呼叫建立信号和进程以及通信控制信号和进程提供转
换功能。必要时，网关应该提供H.242到H.245的转换。网关执行H.225.0呼叫信令和SCN
信令系统（Q.931， Q.2931，等等）之间的适当的转换。LAN上的Q.931消息和SCN上的
Q.931消息之间的转换在附录A中描述。
网关从ISDN端点接收到的所有Q.931信号以及不适用于网关的信号应该被通过并传向
下一个LAN端点，反之亦然。这种信号包含Q.932和Q.950系列消息。这样就能使H.323
端点实现其他协议中规定的补充的服务。其他SCN呼叫信号系统的过程有待研究。
本协议描述了一个LAN上的H.323终端通过网关与一个SCN上的外部终端的连接。能
与网关通信的H.323终端的实际编号是不需要标准化的。同样地，SCN连接的编号，同步独
立会议的编号，音频/视频/数据转换功能，以及是否包含多点功能是由厂商决定的。如果网
关包含在LAN上的MCU功能，那么该功能应该是LAN上的H.323 MCU。如果网关包含在
SCN上的MCU功能，那么它将以SCN上的H.231/H.243 MCU，或用于H.310或H.324系统
的MCU（这些MCU在相应的协议中将有待研究）的形式出现。
网关可以通过SCN与其他网关连接从而提供不在相同LAN上的H.323终端的通信。
提供LANs之间的透明网络互连而不使用H.320的设备（比如路由和远程拨号单元）不
是本协议范围内定义的网关。
6.4网闸特性
网闸在H.323系统中是任选的，它提供对H.323端点的呼叫控制服务。一个以上网闸可
以一种非固定模式出现并互相通信。虽然网闸与端点是逻辑分开的，但它物理上可以与终端，
MCU，网关，MC，或其他非H.323 LAN设备共存。
当网闸在系统中出现时，它应该提供下列服务：
地址转换-网闸应该将别名地址转换为传送地址。这种转换应该使用一个转换表，转换表
使用在条款7描述的Registration消息更新。使用其他更新转换表的方法也可以。
许可控制-网闸应该使用ARQ/ACF/ARJ H.225.0消息授权LAN访问。这种授权可以基于
呼叫授权，带宽，或留给厂商决定的其它一些标准，也可以是一种无效的功能，这样将
允许所有请求的访问。
带宽控制-网闸应该支持BRQ/BRJ/BCF消息。这种控制可以基于带宽管理，也可以是无
效的功能，后者将意味着接受所有带宽变化的请求。
地域管理-网闸应该为已经按7.2所述与它注册的终端，MCU，以及网关提供上述功能。
网闸也可以执行其他任选的功能，比如：
呼叫控制信令-网闸可以选择是否完成与端点的呼叫信令，也可以自己处理呼叫信令。或
者，网闸可以引导端点使呼叫信令信道直接彼此互联。这样，网闸能避免处理 H.225.0
呼叫控制信号。为了支持增补服务，网闸可能不得不充当作为Q.931协议中规定的网络。
这种操作有待研究。
呼叫授权-通过使用H.225.0信令，网闸可以拒绝从终端传来的由于授权失败的呼叫。拒
绝的理由可以包括但不限于下列原因：到/从特定终端或网关的严格访问，以及在确定时
段之内的严格访问。决定授权通过或失败的标准超出了本协议的范围。
带宽管理-H.323终端编号的控制允许同时访问LAN。通过使用H.225.0信令，网闸可以
拒绝从终端传来的由于带宽限制的呼叫。当网闸发现网络上没有足够的可用带宽支持呼
叫时就会出现这种情况。决定带宽是否可用的标准超出了本协议的范围。注意：这可以
是无效的功能，即所有终端都被授权访问。在活动呼叫中当终端请求附加带宽时，这个
功能也会起作用。
呼叫管理-例如，网闸可以保持进行的H.323呼叫的列表。这一信息对于指示呼叫终端忙
也许是必要的，并且为带宽管理功能提供信息。
网闸管理信息数据结构-有待研究。
不具备本功能的终端的带宽保留-有待研究。
目录服务-有待研究。
为了支持特别多点会议，网闸可以选择是否接收点对点会议中二个终端之间的H.245控
制信道。当会议交换到多点会议时，网闸能将H.245控制信道重定向到MC。网闸不需要处
理H.245信令；它仅需让信令在终端之间或终端和MC之间通过。
为了把输入的E.164地址译成传送地址，包含网关的LAN也应该包含网闸。
包含网闸的H.323实体应该有禁止内部网闸的机制，这样当LAN上有多个包含网闸的
H.323实体时，H.323实体能被配置进相同地域。
6.5多点控制器特性
MC提供支持多点会议中三个或多个端点之间的会议的控制功能。在多点会议中MC与
每个端点进行能力交换。MC向会议中的端点发送能力集指示他们可以传送的操作方式。作
为终端连接或离开会议或其他原因的结果，MC可以修订要传送到终端的能力集。
这样，MC为会议决定已选通信方式（SCM）。SCM对会议中所有端点是公用的。或者，
会议中一些端点的SCM可能与其他端点不同。MC决定SCM的方法超出了本协议的范围。
作为多点会议建立的一部分，端点应该在它的H.245控制信道上连接到MC。这种连接
可以发生在：
通过与MCU显式连接;
通过与网闸中的MC隐式连接;
通过与多点会议中另一个终端或网关内的MC隐式连接;
通过经网闸与MCU隐式连接。
会议方式（e.g.集中式或分散式）的选择发生在使用H.245信号与MC连接之后。会议方
式的选择可以由端点或MC的能力限制。
MC可以在网闸、网关、终端或MCU内定位。参见图6。
Terminal 1
MC
Terminal 2Gaetkeeper1
MC
Gaetkeeper2
MCMP
Gaet
LAN
MCMCMPMCMP
Gaetway1 Gaetway2
Gaetway3
MCU1 MCU2
图6/H.323 - H.323系统中MC和MP的可能位置
NOTE? GaetwayG ,aetkeepera ndM CUc anb ea s nigeld evcie.
终端中的MC是不可被叫的。它能被包含在呼叫内用以处理H.245信令从而支持特别多
点会议。这种情况下，终端的MC和H.245控制功能（参见6.2.8）可能是没有区别的。他们
之间的通信超出了本协议的范围。
网闸中的MC是不可被叫的；然而，网闸中的MCU是可被叫的。网闸中的MCU是作
为独立的MCU工作的。当网闸从端点接收到H.245控制信道时，网闸中的MC可以用于支
持特别多点会议。这样，网闸能在呼叫的开始或当会议交换到多点会议时将H.245控制信道
指向MC。
网关能起终端或MCU的作用。当作为终端时，网关可以包含MC。这与上述终端中的
MC有相同特性。
MCU总是包含MC。MCU是可被叫的，而且MC处理所有端点的H.245控制信道。
当会议中有二个以上端点时，端点应该使用H.245协议的主/从决定进程来决定将要控制
会议的MC。
在能力交换和主/从决定之后，MC可以使用 terminalNumberAssign先给一个新的端点指
定一个终端编号。然后，MC应该使用 terminalJoinedConference通知会议中其他的新端点。
新端点可以使用 terminalListRequest请求会议中其他端点的列表。
6.6多点处理器特性
MP从集中或混合多点会议的端点接收到音频、视频和/或数据流。MP处理这些媒体流
并将他们返回给端点。
MC和MP之间的通信不需要标准化。
MP可以处理一个以上媒体流类型。当MP处理视频时，它应该按6.2.4所述处理视频算
法和格式。当MP处理音频时，它应该按6.2.5所述处理音频算法。当MP处理数据时，它应
该按6.2.7所述处理数据流。
处理视频的MP应该提供视频交换或视频混合。视频交换是选择MP从源终端输出另一
个终端的视频的过程。交换使用的标准可以通过察觉演讲者的改变（由联合的声音层次判断）
或通过H.245控制来决定。视频混合是将一个以上的视频源格式化成由MP输出到终端的视
频数据流。一个视频混合的例子是在视频输出图片中将四个源图像混合成二二数组。标准图
像来源以及多少图像被混合的标准通常由MC决定，除非规定了其他控制。这一控制功能的
T.120系列协议的使用有待研究。
处理音频的MP应该准备从M-音频输入并由交换，混合，或组合直到N-音频输出的过
程。音频混合需要将输入音频译码成线性信号（PCM或模拟信号），执行信号的线性组合并
将结果再编码成适当的音频格式。为了减少噪声和其他不必要的信号，MP可以除去或消弱
一些输入信号。每个音频输出可能是输入的提供私人会话信号的不同组合。终端应该假定他
们的音频不是现在返回给他们的音频数据流。从MP音频输出中除去属于终端自己的音频的
方法有待研究。
处理T.120数据的MP应该能够充当非页面MCS提供者和Top MCS提供者。MP也可以
处理非标准数据，透明用户数据和/或数据的其他类型。
MP可以提供算法和格式转换，允许在不同的SCM上的终端参加会议。
MP是不可被叫的，而它的一部分—MCU则是可被叫的。MP终止并打开媒体信道。
6.7多点控制单元特性
MCU是为多点会议提供支持的端点。MCU应该包含MC和零个或多个MP。MCU使用
H.245消息和进程实现与H.243协议相似的特点。典型的支持集中式多点会议的MCU包含一
个MC和一个音频、视频和数据MP。典型的支持分散式多点会议的MCU包含一个MC和
一个支持T.120协议的数据MP。它依靠分散音频和视频处理。
LAN的网关可以是MCU。网闸也可以包含MCU。在任意两种情况中，他们是独立的功
能但碰巧共同定位。
MCU应该是其他端点使用条款8的进程可以被叫的。
6.8多点能力
6.8.1集中式多点能力
所有终端应该有集中式多点能力。作为LAN上的终端出现的网关也应该有集中式多点
能力。在这种操作方式下，他们在控制信道上以点对点的方法使用MCU中的MC通信，并
且在音频，视频和数据通道上使用MP。在这种方式下，MC执行H.245多点控制功能，而
MP执行视频交换或混合，音频混合，以及T.120多点数据分布。MP将产生的视频，音频和
数据流返回终端。MP可以在不同音频、视频和数据格式以及位速率之间进行转换，允许终
端使用不同通信方式参加会议。
如果会议中的终端能接收多点传送的话，那么MCU可以使用多点传送分发处理过的视
频。处理过的音频的多点传送分发有待研究。
这种方式由下列H.245能力发送信号： centralizedControl， centralizedAudio，
centralizedVideo，以及 centralizedData。
6.8.2分散式多点能力
如果终端有分散式多点能力，他们在H.245控制信道上使用以点对点方式的MCU中的
MC、网关、网闸或终端通信或者在数据信道上任选的使用MP。终端应该有向会议中的所有
其他端点多点传送他们的音频和视频信道的能力。MC可以控制哪一个或哪些终端主动地多
点发送音频和/或视频（例如在两个信道之间使用 flowControlCommand）。
终端接收到多点发送的视频信道并选择一个或多个可行的信道显示给用户。终端接收到
多点发送的音频信道并执行音频混合功能从而能为用户播放复合音频信号。
MC可以提供会议控制功能如座位控制，视频广播和视频选择。这将通过从终端接收
H.245然后向其他终端发送适当的控制从而允许或禁止他们的视频多点发送。T.120命令可以
随意提供相同功能。
这种方式由下列H.245能力发送信号： centralizedControl， decentralizedAudio，
decentralizedVideo，以及 centralizedData。
6.8.3混合多点-集中式音频
如果终端和MCU有混合多点-集中式音频能力，他们可以为视频使用分布式多点并为音
频使用集中式的多点。在这种方式中，终端在H.245控制信道上使用以点对点方式的MC或
者在数据信道上任选的使用MP。
终端应该有向会议中的所有其他端点多点发送他们的视频信道的能力。MC可以控制哪
一个或哪些终端主动地多点发送视频。终端接收到多点发送的视频信道并选择一个或多个可
行的信道显示给用户。
会议中所有的终端向MP传送他们的音频信道。MP执行音频混合功能并向终端输出产
生的音频数据流。MP可以为会议中的每个终端产生排斥音频总数。处理音频的多点分布式
发送有待研究。
这种方式由下列H.245能力发送信号： centralizedControl， centralizedAudio，
decentralizedVideo，以及 centralizedData。
6.8.4混合多点-集中式视频
如果终端和MCU有混合多点-集中式视频能力，他们可以为音频使用分布式多点和为视
频使用集中式的多点。在这种方式中，终端在H.245控制信道上使用以点对点方式的MC或
者在数据信道上任选的使用MP。
终端应该有向会议中的所有其他端点多点发送他们的音频信道的能力。MC可以控制哪
一个或哪些终端主动地多点发送音频。终端接收到多点发送的音频信道并执行音频混合功能
从而能为用户播放复合音频信号。
会议中所有的终端向MP传送他们的视频信道。MP执行视频混合功能并向终端输出产
生的视频数据流。MP可以为会议中的每个终端产生排斥视频总数，或者可以向所有参加的
终端多点发送视频数据流，从而缩小LAN中使用的带宽。
这种方式由下列H.245能力发送信号： centralizedControl， centralizedAudio，
decentralizedVideo，以及 centralizedData。
6.8.5 普通方式的建立
MC应该使多点会议中的终端之间的普通通信方式对等。MC可以通过向终端发送一个
仅列出请求传送的方式的接收能力集来迫使终端进入传送的一个特定的普通方式（当允许由
他们的能力设置时），或者MC可以依靠multipointModeCommand和迫使方式对称的方式参
考命令。后一种方法应该被采用因为它允许终端知道可以请求的可行会议能力的整个范围。
如果MCU有转换音频和/或视频格式的能力，它不必迫使所有终端进入相同的通信方式。
6.8.6多点速率匹配
由于多点配置中的每个链接的终端企图以不同的位速率操作，因此MC应该传送H.245
flowControlCommand消息来限制那些能够发送到接收者的传送位速率。
6.8.7多点唇同步
在集中式或混合式多点会议中提供音频混合的MP应该修改音频和视频数据流的时间标
记，重视它的时间基准，从而标准音频和视频同步。具体地说，当MP处理音频和/或视频产
生源于MP的新的数据流，MP应该在音频和视频包中产生自己的顺序编号。
当混合音频时，MP应该使每个输入的音频数据流与它自己的时间同步，混合音频数据
流，然后应基于自己的时间用它自己的顺序编号产生新的音频数据流。如果MP也交换视频，
转换的数据流应该用MP的时间替换原始的时间戳从而与混合的音频数据流同步，而且应该
有一个新的序号代表从MP输出的数据流。
在分布式的多点会议的情况中，接收终端能通过使用RTP时间标记使选定的视频数据流
和它的相关音频对齐保持唇同步。其他音频数据流的对齐不是必需的。如果多个视频数据流
被显示出来，那么相关的音频数据流应该被对齐。
它在混合多点会议中保持唇同步是不可能的。
6.8.8多点加密
在集中式多点配置中，MP被认为是一个信任的实体。MP的每个端口将每个来自H.323
终端的信息流解密并按照10.1为输出到每个终端的信息流加密。非信任的MCU的操作有待
研究。
分散式和混合式多点会议的加密有待研究。
6.8.9层叠多点控制单元
多点控制功能可以在几个MCU实体之间分布式执行。这样操作有待研究。
7呼叫信令
呼叫信令是用于建立呼叫，请求呼叫的带宽改变，获得呼叫端点的状态，以及断开呼叫
的消息和进程。呼叫信令使用H.225.0协议中规定的消息以及条款8中描述的进程。这个条
款描述了一些呼叫信令概念。
7.1地址
7.1.1 LAN地址
每个H.323实体应该至少有一个LAN地址。这个地址独立的识别LAN上的H.323实体。
一些实体可以共享一个LAN地址（i.e.终端和共定位的MC）。这个地址是端点所在的LAN
环境专用的。不同的LAN环境可以有不同的LAN地址格式。
端点可以在同一呼叫中为不同信道使用不同的LAN地址。
7.1.2 TSAP标识符
对于每个LAN地址，每个H.323实体可以有几个TSAP标识符。这些TSAP标识符允许
几个信道共享相同的LAN地址的多路技术。
端点有一个众所周知的TSAP标识符定义：呼叫信令信道TSAP标识符。网闸有一众所
周知的TSAP标识符定义：RAS信道TSAP标识符，以及一个众所周知的多点传送地址定义：
发现多点传送地址。这些都是在附录IV/H.225.0定义的。
端点和H.323实体应该为H.245控制信道，音频信道，视频信道，以及数据信道使用动
态TSAP标识符。网闸应该为呼叫信令信道使用动态TSAP标识符。RAS信道和信令信道可
以在注册进程中改变动态TSAP标识符的方向。
7.1.3别名地址
端点也可以有一个或多个与它相关的别名地址。别名地址提供另一个端点寻址方法。这
些地址包含E.164地址（网络访问号码，电话号码，等等），H.323 ID（名字，类似于地址的
电子邮件，等等），以及任何H.225.0协议中定义的其他地址。别名地址在地域中应该是唯一
的。网闸，MC，以及MP不应该有别名地址。
当系统中没有网闸时，呼叫端点应该使用被叫端点的呼叫信令信道传送地址来直接寻址
被叫端点。当系统中有网闸时，呼叫端点可以使用被叫端点的呼叫信令信道传送地址或别名
地址来寻址被叫端点。后者应该由网闸翻译成呼叫信令信道传送地址。
呼叫端点的E.164地址可以由一个可选的跟随在E.164地址之后的访问代码组成。访问
代码由0～9， *，以及 #范围内的n个数字组成。数字的编号和他们的意思由厂商决定。这
种访问代码的目的之一可能是请求访问网关。网闸可以在向目标转发之前改变这个地址。
H.323 ID包含一串在H.225.0协议中规定的ISO/IEC 10646-1字符。它可以是用户名，电
子邮件名称，或其他标识符。
端点可以有一个以上别名地址（包括一个以上相同类型的）被翻译成相同的传送地址。
端点的别名地址在地域内应该是唯一的。
7.2注册，许可和状态（RAS）信道
RAS信道应该用于在网闸发现和端点注册过程中传送消息，端点注册过程将端点的别名
地址和它的呼叫信令信道传送地址关联起来。RAS信道应该是非可靠信道。
7.2.1网闸发现
网闸发现是端点用于决定与哪一个网闸注册的过程。这可以手工完成或自动完成。手工
发现依靠超出本协议的范围以外的方法决定端点是与哪一个网闸相关联。端点由相关联的网
闸的传送地址配置。例如，它可以在端点配置中被加进去，或者它可以被加进一个初始化文
件。这样，端点知道与它相关联的前一个网闸。端点现在可以与网闸注册。
自动发现的方法允许端点-网闸的关联随着时间的改变而改变。端点可以不知道它的网闸
是谁，或由于失败而需要识别另一个网闸。这可以通过自动发现实现。自动发现允许在配置
单个端点时低级管理阶层，此外还允许现存网闸的替换而不用手工重新配置所有相关端点。
端点可以多点传送（或使用附录IV/H.225.0描述的其他方法）一个网闸请求（GRQ）消
息，询问“谁是我的网闸？”。这个信息被传送到网闸的众所周知的发现多点传送地址。一个
或多个网闸可以用网闸确认（GCF）消息应答，指示“我能是你的网闸。”，并返回网闸的RAS
信道的传送地址。如果网闸不想要端点注册它，它应该返回网闸拒绝（GRJ）。参见图7。如
果一个以上网闸应答，端点可以选择它想使用的网闸。这样，端点知道它是与哪一个网闸注
册的。端点现在可以和那个网闸注册。
Endpoint
GRQ
GCF/GRJ
Gatekeeper
图7/H.323 -自动发现
T1521260-96
如果在超时之前没有网闸应答，端点可以再试GRQ.端点不应该在发送完前一个的5秒
之内发送GRQ.如果没有收到响应，端点可以使用手工发现方法。
如果在任何时候端点发现它与网闸的注册是无效的，它必须重新寻找它的网闸。无效注
册可以通过从网闸接收对端点的RRQ应答的RRJ消息，或者在超时之前不接收任何对端点
的RRQ的应答而检测出来。
GRQ可以周期性重复（i.e.在端点供电时），这样网闸应该能处理来自同一端点的多个请
求。
7.2.2端点注册
注册是端点加入地域，并向网闸告知它的传送地址和别名地址的过程。作为他们的配置
过程的一部分，所有端点应该与通过发现过程识别的网闸注册。注册应该在任何呼叫发生之
前发生，必要时也可以周期性发生（例如，在端点供电时）。
端点应该向网闸发送注册请求（RRQ）。这个请求被传送到网闸的RAS信道传送地址。
端点从网闸发现过程中获得网闸的LAN地址并使用众所周知的RAS信道TSAP标识符。网
闸应该以注册确认（RCF）或注册拒绝（RRJ）应答。参见图8。端点应该仅与单个网闸注册。
RRQ可以周期性重复（i.e.在终端供电时），这样网闸应该能处理来自同一端点的多个请
求。如果网闸收到一个与前一个RRQ有相同别名地址和相同传送地址的RRQ，它应该以RCF
应答。如果网闸收到一个与前一个RRQ有相同别名地址但不同传送地址的RRQ，它应该拒
绝注册即指出是重复注册。如果网闸收到与前一个RRQ有相同传送地址但不同别名地址的
RRQ，它应该替换转换表输入项。网闸可以鉴别这些改变的方法有待研究。
网闸应该保证每个别名地址唯一的翻译成单个传送地址。不明确的注册应该被网闸拒
绝。网闸可以由于其他原因而拒绝注册，比如在发现中的变化或安全问题。
如果端点在RRQ消息中不包含别名地址，网闸可以分配一个别名地址。网闸应该在 RCF
消息中把分配的别名地址返回给终端。
Endpoint
RRQ
Gatekeeper
RCF or RRJ
URQ
UCF/URJ
Endpoint initiated
Unregister Reques
URQ
图
UCF
8/H.323 -注册
Gatekeeer initia
p
Unregister Reque
端点可以向网闸发出取消注册请求（URQ）消息来取消其注册.网闸以取消注册确认
（UCF）消息作为应答。这使得端点能够改变与它的传输地址相连系的别名地址,反之亦然。
若端点没有注册到网闸,则向端点发出取消注册拒绝（URJ）消息。
网闸可以向端点发出取消注册请求（URQ）消息来取消其注册。 端点以取消注册确认
（UCF）消息作为应答。 在开始呼叫之前,端点可以再次注册到网闸。这可能要求端点注册
到新的网闸。
没有注册到网闸的端点被称作非注册端点。这种类型的端点不能对网闸进行许可请求,
因此也不能参加由网闸执行的许可控制,带宽控制,地址翻译和其他功能。
7.2.3端点定位
具有一个别名地址 （别名地址决定相应端点的传送地址）的端点或者网闸能够发出定位
T1524050-96
请求消息（LRQ）。 LRQ消息可以被送到特定的网闸,或象GRQ消息那样被多点传送。它被
送到网闸的众所周知的RAS信道TSAP标识符上;如果被多点传送,则送到众所周知的网闸多
址发现上。被要求的端点所注册的网闸,应该以包含端点的呼叫信令信道或网闸的呼叫信令信
道的传送地址的定位确认（LCF）消息响应。所有未被要求的端点注册的网闸,如果他们在RAS
信道上接受到LRQ的话,应该返回定位拒绝消息（LRJ）。 所有未被要求的端点注册的网闸,
如果他们在多址发现接受到LRQ的话,都不应该对LRQ消息做出响应。
7.2.4许可，带宽改变，状态，断开
RAS 信道也被用于传送许可,带宽改变,状态, 断开消息。这些消息产生于端点和网闸之
间,用来提供许可控制和带宽管理功能。在第8节将对如何应用他们进行详细的描述。
许可请求消息（ARQ）中指明了请求的带宽。它是所有能发送和接收的音频,视频流（不
包含任何RTP头,RTP有效载荷头,LAN头,和其他的）的总比特率的上限。数据和控制信道不
受此限制。网闸可以在ACF消息中降低所请求的带宽。端点将确保（平均每秒的） 发送和
接收音频,视频流的总比特率不超过带宽。在呼叫中,端点或网闸可利用带宽改变请求（BRQ）
消息来修改呼叫带宽。
7.3呼叫信令信道
呼叫信令信道被用来承载H.225.0呼叫控制信息。呼叫信令信道应该是可靠的信道。
在没有网闸的网络里,呼叫信令消息利用呼叫信令传送地址在主叫和被叫之间直接传输。
在这样的网络里,是假定主叫端点知道被叫端点的呼叫传送地址的,因而能够直接通信。
在包含网闸的网络里, 利用网闸的RAS信道传送地址,初始的许可信息交换发生于主叫
端点和网闸之间。在进行初始的许可信息交换时,网闸在ACF消息中指定是否直接将呼叫信
令消息送到其他端点,或利用网闸来发送。呼叫信令消息被送到端点的呼叫转移地址或网闸的
呼叫转移地址。
H.225.0协议中定义了本协议中用来表示呼叫信令消息的Q.931消息结构。第8节将介绍
使用它们的方法。
7.3.1呼叫信令信道传输
呼叫信令有两种传输方式。第一种是基于网闸传输的（见图9）。在这种方式中,呼叫信令
消息经由网闸在端点之间传输。第二种是呼叫信令消息直接在端点之间传输（见图10）。在
此方式中,呼叫信令消息直接在端点之间传输。使用哪种方式由网闸来决定。
为达到同样的目的,两种方法都使用了一些相同的连接和相同的消息结构。许可消息在
RAS信道上与网闸交换,接着是在呼叫信令信道上呼叫信令消息的交换。然后是H.245控制信
道的建立。网闸对许可消息的反应方式决定使用的是哪一种呼叫方式。这不是处于端点的控
制之下,但是端点具有首决权。
对于基于网闸传输的方式,网闸可以选择在呼叫建立完成以后关闭呼叫信令信道,也可以选
择在呼叫过程中保持连接状态来对附加的设备提供支持。只有网闸能够关闭呼叫信道,但在涉
及到网关的呼叫中网闸是不能关闭呼叫信道的。
附录D/Q.931的对称的信令方式应用于所有的强制性的呼叫过程中。
图9至图12中的网闸云包含一个或几个网闸,它们之间有的能够通信,有的不能。图中的端
点可以连接到相同的网闸,也可以连接到不同的网闸。
GatekeeperC loud
1A RQ
2A CF/ARJ
3S et-up
4S et-up
5A RQ
6A CF/ARJ
7C onnect
8C onnect
12384567
Endpoint 1Endpoint 2
T1521280-96
Call SignallingC hanne Messages
Figure 9/H.323 –
l
Gatekeeper routed call signalling
RASC hannel Messages
Gatekeeper Cloud
1
1A RQ
2A CF/ARJ
3S et-up
4A RQ
5A CF/ARJ
6C onnect
245
3
Endpoint 1
6
Endpoint 2
Call Signalling Channel Messages
RAS Channel Messages
T1521290-96
Figure 10/H.323 – Direct endpoint call signalling
7.3.2控制信道传输
当采用基于网闸的信号传输方式时,有两种方式来传输H.245控制信息。在第一种方式
中,H.245控制信道直接建立于端点之间。参见图11。这种方式以后再讨论。第二种方式
中,H.245控制信道信息经由网闸在端点之间传输。参见图12。这种方式允许当一个可扩展会
议从点至点方式转换到多点方式时,网闸能够将H.245控制信道重定向到一个MC。这个选择
权在于网闸。当使用端点直接传输方式时, H.245控制信道只能在端点之间建立。
Gatekeeper Cloud
1A RQ
2A CF/ARJ
3S et-up
4S et-up
5A RQ
6A CF/ARJ
7C onnect
8C onnect
9H 2.45C hannel
12384567
Endpoint 1
9
Endpoint 2
H2.45C ontrol Channel Messages
T1521300-96
Call SignallingC hannel Messages
RASC hannel Messages
Figure 11/H.323 – Direct H.245 control channel connection between endpoints
Gatekeeper Colud
1A RQ
2A CFA/RJ
3S et-up
4S et-up
5A RQ
6A CFA/RJ
7C onnect
8C onnect
9H 2.45C hannel
10H 2.45C hannel
12389456
0
7
1
Endponi1 t
Endponi2 t
H2.45C ontroC lhanneM lessages
T1521310-9
CallS ginalingC hannel Messages
RASC hannel Messages
Figure 12/H.323 – Gatekeeper routed H.245 control
7.4呼叫参考值
所有呼叫信令信息和RAS消息都包含有呼叫参考值（CRV）。参见H.225.0 协议。它
们被用来联系与同一呼叫相关的所有消息。 在与同一呼叫相关的所有许可,呼叫建立,附加设
备,带宽改变及呼叫中止消息中,都应该使用相同的CRV。新的CRV应该用于新的呼叫。一个
端点邀请别的端点参加同一会议而发起的新呼叫也应该使用新的CRV。CRV不同于会议ID
（CID） 。CRV 联系同一呼叫的消息,CID则联系的是同一会议中的所有呼叫。
7.5会议ID和会议目标（意图）
CID是由主叫端点产生的唯一非零值,它在不同的消息中传递。（这些H.225.0消息以八字
节的CID开头）。 CID确定该消息对应的会议。CID的16字节形式如下:
CID octet
Value
15
N5
14
N4
13
N3
12 11 10
N0
9
C1
8
C0
7
H1
6 5 4 3 2
L2
1
L1
0
L0 N2 N1 AV M1 M0 L3
在这里,0下标指的是相应组值中的最低字节。（如N0中的0指的是N0是N0--N5组中的最
低字节。）
N5:0 48比特的LAN物理地址,如果可用的话。
C1:0 对会议数计数的计数器,占16比特,如果时钟不能保证是不变的话。
H1,A,M1:0 自当地时间1582年11月15日起100*E-11秒的最低60比特。（E-11等于1秒
的十亿分之一）。比特分配如下:
H1
59 52 51
A
48 47
M1 M0
32 31
L3
L2
L1 L0
0
V: CID的低字节起第六字节的4比特低位代表的是版本号,其值为0001。
会议目标指的是呼叫的意图。有下列备选项:
Create:建立一个新的会议;
Join: 申请加入一个已有的会议;
Invite:邀请一个新的端点加入到一个已有的会议中。
8.呼叫信令过程
通信过程由下列阶段组成:
----A阶段:呼叫建立（参看8。1节）。
----B阶段:通信初始化和能力交换（参看8。2节）。
----C阶段:语音视频通信开始建立（参看8。3节）。
----D阶段:呼叫服务（参看8。4节）。
----E阶段:呼叫中止（参看8。5节）。
8.1 A阶段----呼叫建立阶段
根据下面所定义的呼叫控制过程相应的呼叫控制信息（呼叫控制信息在H.225.0协议中定
义）来建立呼叫。第一步是对带宽资源预留的申请。
如果别名地址和传送地址都给出，优先使用别名地址。
8.1.1基本呼叫建立----没有任何注册端点
在图13的假定中，端点都没有注册到网闸。图中的两个端点直接通信。端点1（主叫端
点）向 端点2的众所周知的呼叫信令通道TSAP标示符上 发出建立消息。端点2以连接信
息（4号信息）对端点1做出反应（连接信息中包含了用于H.245中H.245控制信道的传送
地址）。
Endpoint 1
Set-up (1)
Call proceeding (2)
Alerting (3)
Connect (4)
Endpoint 2
T1527150-97
Figure 13/H.323 – Basic call set-up, no Gatekeepers
Call Signalling Messages
8.1.2两个端点注册到同一网闸
在图14的假定中, 两个端点注册到同一网闸,并且网闸已经选择了信号直接传输方式。端
点1开始与网闸交换ARQ（1）/ACF（2）信息。网闸应该在ACF中返回端点2（被叫端点）
的呼叫信令信道传送地址。然后端点1利用该传送地址向端点2发送呼叫建立消息（3）。如
果端点2要接受呼叫,则它开始与网闸交换ARQ（5）/ACF（6） 信息。在端点2向端点1发
送“释放完毕”消息的情况下,它从网闸那里接受到ARJ（6）消息。 端点2以连接信息（8）
对端点1做出回应（连接信息中包含了用于H.245中H.245控制信道传送地址）。
Endpoint 1
ARQ (1)
ACF/ARJ (2)
Set-up (3)
Gatekeeper 1Endpoint 2
Call proceeding (4)
ARQ (5)
ACF/ARJ (6)
Alerting (7)
Connect (8)
T1527160-97
Figure 14/H.323 – Both endpoints registered, same Gatekeeper – Direct call signalling
RAS Messages
Call Signalling Messages
在图15的假定中, 两个端点注册到同一网闸,并且网闸已经选择了转接呼叫信令的传输方
式。端点1开始与网闸交换ARQ（1）/ACF（2）信息。网闸应该在ACF中返回它自己的呼
叫信令信道的传送地址。 然后端点1利用该传送地址向网闸发送呼叫建立消息（3）。接着网
闸向端点2发送呼叫建立消息（4）。如果端点2要接受呼叫,则它开始与网闸交换ARQ（6）
/ACF（7） 信息。 在端点2向网闸发送“释放完毕”消息的情况下,它从网闸那里接受到ARJ
（7）消息。 端点2以连接信息（9）对网闸做出回应（连接信息中包含了用于H.245中H.245
控制信道传送地址）。网闸向端点1发送包含有端点2或者网闸的H.245控制信道传送地址的
连接消息（10）, 连接消息中包含谁的控制信道传送地址取决于网闸选择转发方式与否。
Endpoint 1
ARQ (1)
ACF (2)
Set-up (3)
Gatekeeper 1Endpoint 2
Set-up (4)
Call Proceeding (5)
Call Proceeding (5)
ARQ (6)
ACF/ARJ (7)
Alerting (8)
Connect (10)
Alerting (8)
Connect (9)
Figure 15/H.323 – Both endpoints registered, same Gatekeeper – Gatekeeper routed call signalling
T1524060-96
RAS Messages
Call Signalling Messages
8.1.3 仅主叫端点注册到网闸上
在图16的假定中,端点1注册到网闸上,而端点2则没有,同时网闸选择信号直接传输方式。
端点1开始与网闸交换ARQ（1）/ACF（2）信息。然后端点1利用众所周知的呼叫信道传
送地址向端点2发送连接建立信息（3）。 如果端点2要接受呼叫,它以连接信息（4）对端点
1做出反应（连接信息中包含了用于H.245中H.245控制信道传送地址）。
Endpoint 1
ARQ (1)
ACF/ARJ (2)
Set-up (3)
Gatekeeper 1Endpoint 2
Call proceeding (4)
Alerting (5)
Connect (6)
Figure 16/H.323 – Only calling endpoint registered – Direct call signalling
RAS Messages
Call Signalling Messages
在图17的假定中,端点1注册到网闸上,而端点2则没有,同时网闸已经选择了转接呼叫信
号的传输方式。 端点1开始与网闸交换ARQ（1）/ACF（2）信息。网闸应该在ACF中返
回它自己的呼叫信令信道传送地址。然后端点1利用该传送地址向网闸发送呼叫建立消息
（3）。 接着网闸利用端点2的众所周知的呼叫信道传送地址向其发送连接建立信息（4）。 如
果端点2要接受呼叫,它以连接信息（7）对网闸做出反应（连接信息中包含了用于H.245中
H.245控制信道传送地址）。网闸向端点1发送包含有端点2或者网闸的H.245控制信道传送
地址的连接消息（8）, 连接消息中包含谁的控制信道传送地址取决于网闸选择转发方式与否。
Endpoint 1
ARQ (1)
ACF (2)
Set-up (3)
Gatekeeper 1Endpoint 2
Setup (4)
Call Proceeding (5)
Call Proceeding (5)
Alerting (6)
Connect (7)
Alerting (6)
Connect (8)
T1524070-96
RAS Messages
Figure 17/H.323 - Only calling endpoint registered - Gatekeeperrouted call signalling
8.1.4仅被叫端点连接到网闸上
Call Signalling Messages
Endpoint 1
Set-up (1)
Gatekeeper 2
Endpoint 2
Call proceeding (2)
ARQ (3)
ACF/ARJ (4)
Alerting (5)
Connect (6)
RAS Messaes
Figure 18/H.323 –
g
Only called endpoint registered – Direct call signalling
Call Signalling Messages
在图19的假定中,端点2注册到网闸上,而端点1则没有, 同时网闸已经选择了转接呼叫
信号的传输方式。 端点1利用众所周知的呼叫信道传送地址向端点2发送连接建立信息（1）。
如果端点2要接受呼叫, 它开始与网闸交换ARQ（3）/ACF（4）信息。如果被允许,网闸应
该在ARJ（4）中返回它自己的呼叫信道传送地址,with a cause code of route。。。 。 端点2向
端点1发送包含有网闸的呼叫传送地址的Facility消息（5）作为应答。然后端点1向端点2
发出释放完毕消息（6）。 端点1向网闸的呼叫传送地址发出建立消息（7）。 网闸向端点2
发出建立消息（8）。 端点2开始与网闸交换ARQ（9）/ACF（10）信息。端点2以连接信
息（12）对网闸做出反应（连接信息中包含了用于H.245中H.245控制信道传送地址）。网闸
向端点1发送包含有端点2或者网闸的H.245控制信道传送地址的连接消息（13）, 连接消
息中包含谁的控制信道传送地址取决于网闸选择转发方式与否。
Endpoint 1
Set-up (1)
Gatekeeper 1Endpoint 2
Call Proceeding (2)
ARQ (3)
ARJ (4)
Facility (5)
Release Complete (6)
Set-up (7)
Set-up (8)
Call Proceeding (2)
Call Proceeding (2)
ARQ (9)
ACF/ARJ (10)
Alerting (11)
Connect (13)
Alerting (11)
Connect (12)
Figure 19/H.323 – Only called endpoint registered – Gatekeeperrouted call signalling
T1524080-96
RAS Messages
8.1.5 两个端点分别连接到不同的网闸上
MessagesCall Signalling
假定在图20中, 两个端点分别连接到不同的网闸上,并且两个网闸都选择了呼叫信号直
接传输方式。 端点1开始与网闸1交换ARQ（1）/ACF（2）信息。 若网闸1按某种方式
能与网闸2通信,则网闸1应该在ACF消息中返回端点2的呼叫信令信道传送地址。然后端
点1或向网闸1返回的呼叫传送地址发出建立消息（3）,或利用众所周知的呼叫信道传送地
址向端点2发送连接建立信息（3）。 如果端点2要接受呼叫, 它开始与网闸2交换ARQ（5）
/ACF（6）信息。 在端点2向端点1发送“释放完毕”消息的情况下,它从网闸2那里接受到
ARJ（6）消息。 端点2以连接信息（8）对端点1做出反应（连接信息中包含了用于H.245
中H.245控制信道传送地址）。
Endpoin1t
ARQ(1 )
ACFA/RJ (2)
Gatekeeper 1Gatekeeper 2
Set-up(3 )
Calp roceednig(4 )
ARQ(5 )
ACFA/RJ (6)
Aertlnig(7 )
Connect(8 )
Figure 20/H.323 – Both endpoints registered – Both gatekeepersdirect call signalling
在图21的假定中, 两个端点分别连接到不同的网闸上,并且主叫端点的网闸选择呼叫信
号直接传输方式,被叫端点的网闸选择转发呼叫信令传输方式。 端点1开始与网闸1交换ARQ
（1）/ACF（2）信息。 若网闸1按某种方式能与网闸2通信,则网闸1应该在ACF（2）消
息中返回端点2的呼叫信令信道传送地址。然后端点1或向网闸1返回的呼叫传送地址发出
建立消息（3）,或利用众所周知的呼叫信道传送地址向端点2发送连接建立信息（3）。 如果
端点2要接受呼叫, 它开始与网闸2交换ARQ（5）/ACF（6）信息。 如果被接受,网闸2应
该在ACF（6）中返回它自己的呼叫信道传送地址,连同的还有routeCallToGatekeeper。 端点
2向端点1发送包含有网闸2的呼叫传送地址的Facility消息（7）作为应答。 端点1向端点
2发出释放完毕消息（8）。 端点1向网闸1发出 DRQ（9）消息,网闸1以DCF（10）消息
做出应答。然后端点1开始与网闸1交换新的ARQ（11）/ACF（12）信息。 端点1向网闸
2的呼叫信令信道传送地址发出建立消息（13）。 网闸2向端点2发出建立消息（14）。 端
点2开始与网闸2交换ARQ（15）/ACF（16）信息。端点2以连接信息（18）对网闸2做
出反应（连接信息中包含了用于H.245中H.245控制信道传送地址）。网闸2向端点1发送包
含有端点2或者网闸2的H.245控制信道传送地址的连接消息（19）, 连接消息中包含谁的
控制信道传送地址取决于网闸选择转发方式与否。
RASM essages
CalS ginalnigM essages
Endpoint 1
Gatekeeper 1
ARQ (1)
ACF (2)
Set-up (3)
CallProceeding (4)
Gatekeeper 2
Endpoint 2
ARQ (5)
Faciitly (7)
Release Complete (8)
DRQ (9)
DCF (10)
ARQ (11)
ACF (12)
Set-up (13)
Set-up (14)
CallProceeding (4)
CallProceeding (4)
ARQ (15)
ACF/ARJ (16)
Alerting (17)
Connect(18)
ARJ (6)
Alerting (17)
Connect(19)
Figure 21/H.323 – Both endpoint registered – Direct/routed call signalling
图22的假定中, 两个端点分别连接到不同的网闸上,并且主叫端点的网闸选择转发呼叫
信号传输方式,被叫端点的网闸选择呼叫信号直接传输方式。 端点1开始与网闸1交换ARQ
（1）/ACF（2）信息。网闸1应该在ACF（2）消息中返回它自己的呼叫信令信道传送地址。
端点1利用该地址向网闸1发出建立消息（3）。 然后网闸1向端点2的众所周知的呼叫信令
信道传送地址发送包含了网闸1自身的呼叫信令信道传送地址的建立信息（4）。 如果端点2
要接受呼叫, 它开始与网闸交换ARQ（6）/ACF（7）信息。 在端点2向端点1发送“释放完
毕”消息的情况下,它从网闸2那里接受到ARJ（7）消息。 端点2以连接信息（9）对网闸1
做出反应（连接信息中包含了用于H.245中H.245控制信道传送地址）。网闸1向端点1发送
T15240909-6
RAS Messages
CallSi gnalling Messages
包含有端点2的H.245控制信道传送地址或网闸1的H.245控制信道传送地址的连接消息（10）,
连接消息（10）中包含谁的控制信道传送地址取决于网闸选择转发方式与否。
Endpoin1t
ARQ(1 )
ACF(2 )
Gatekeeper 1Gatekeeper 2Endpoin2t
Set-up(3 )
CallP roceeding(5 )
Set-up(4 )
CallP roceeding(5 )
ARQ(6 )
ACF/ARJ (7)
Aertilng(8 )
Connect(1 0)
Aelrting(8 )
Connect(9 )
Figure 22/H.323 – Both endpoint registered – Routed/direct call signalling
RASM essages
T15241
CallS ginalingM essages
在图23的假定中, 两个端点分别连接到不同的网闸上,并且两个网闸都选择了转发呼叫
信号传输方式。 端点1开始与网闸1交换ARQ（1）/ACF（2）信息。网闸1应该在ACF（2）
中返回它自己的呼叫信道传送地址。然后端点1利用该地址向网闸1发出建立消息（3）。接
着网闸1向端点2的众所周知的呼叫信令信道传送地址发送建立消息（4）。如果端点2要接
受呼叫,它开始与网闸2交换ARQ（6）/ACF（7）信息。 如果被接受,网闸2应该在ARJ（7）
中返回它自己的呼叫信道传送地址, routeCallToGatekeeper。 端点2向网闸1发送包含有网闸
2的呼叫传送地址的Facility消息（8）作为应答。网闸1向端点2发出释放完毕消息（9）。
网闸1向网闸2的呼叫传送地址发出建立消息（10）。 网闸2向端点2发出建立消息（11）。
端点2开始与网闸2交换ARQ（12）/ACF（13）信息。端点2以连接信息（15）对网闸2
做出反应（连接信息中包含了用于H.245中H.245控制信道传送地址）。网闸2向网闸1发送
包含有端点2或者网闸2的H.245控制信道传送地址的连接消息（16）, 连接消息中包含谁
的控制信道传送地址取决于网闸2选择转发方式与否。 网闸1向端点1发送可能包含有网闸
1或者网闸2的H.245控制信道传送地址的连接消息（17）, 连接消息中包含谁的控制信道传
送地址取决于网闸1选择转发方式与否。
Endpoint 1
ARQ(1)
ACF (2)
Set-up (3)
CallProceeding (5)
Gatekeeper 1Gatekeeper 2Endpoint 2
Set-up (4)
CallProceeding (5)
ARQ(6)
ARJ (7)
Faciitly (8)
Release Complete (9)
Set-up (10)
CallProceeding (5)
Set-up (11)
CallProceeding (5)
ARQ(12)
ACF/ARJ (13)
Aertilng (14)
Connect(17)
Aertilng (14)
Connect(16)
Aertilng (14)
Connect(15)
T15241109-6
Figure 23/H.323 – Both endpoint registered – Both Gatekeepersrouting call signalling
RAS Messages
CallSi gnalling Messages
8.1.6通过网关建立呼叫
8.1.6.1通过网关对内建立呼叫
当一个外部的端点通过网关呼叫LAN内的端点时,在网关和LAN端点之间呼叫建立的过
程与端到端的呼叫建立过程是一样的。当在网络上建立呼叫时网关可能需要向外端点发送呼
叫处理信息。
不能直接将外来的SCN呼叫向H.323端点转发的网关应该具备接受两阶段拨号的能力。
对于连接到H.320网络（也可以是H.321,H.322,H.321方式的H.310网络）的网关,应该能从
H.320端点接受SBE号码。 对于连接到H.324网络或者连接到本地方式H.310网络的网关,
应该具备从H.324端点接受 userInputIndication消息的能力。在这两种情况下,对DTMF的
支持是可选的。对连接到纯语音终端的网关,应该具备从纯语音终端接受DTMF码的能力。
DTMF码在访问LAN上的单个端点时指出第二阶段拨号码。
8.1.6.2通过网关对外建立呼叫
当一个LAN内的终端通过网关呼叫外部的终端时,在网关和LAN终端之间呼叫建立的过
程与端到端的呼叫建立过程是一样的。网关将接受到的呼叫建立消息中所包含的目的地的E。
164地址。然后网关利用该地址对外发起呼叫。当在建立对外呼叫时网关可能需要向LAN终
端发送呼叫处理信息。
进程指示器信息元用来表明内部网络正在运转。网关应该在警告,呼叫处理,或连接消息
内发出进程指示器信息元。它们也可以被发送到进程消息之中。
LAN端点应在呼叫建立消息中发送出由它发起的呼叫的所有E。164地址。例如,在ISDN
上的6_B信道呼叫将需要在呼叫建立消息中包含6个E。164地址。网关对呼叫建立消息发
出如下消息作为应答:连接,释放,警告,呼叫处理,或进程消息等。一个失败的SCN呼叫将通过
释放完毕消息报告给LAN端点。多CRV值和多呼叫建立消息的使用方法以后再讨论。SCN
呼叫中的附加信道问题以后再研究。
注册到网闸的LAN端点应该在ARQ消息中请求充足的呼叫带宽以满足所有的SCN呼
叫。若在ARQ消息中充足的呼叫带宽要求得不到满足，应紧接着发出8。4。1中讲述的带
宽改变消息,以便获得另外的呼叫带宽。
将第一阶段的呼叫置于SCN上之后,网关将向B阶段推进。后来呼叫的SCN E。164地
址在同网关进行能力交换和同SCN端点建立语音通信之后再处理。
8.1.7 使用MCU建立呼叫
对于集中式的多点会议,所有的端点同MCU（多点控制单元）交换呼叫信令。端点同MCU
之间的呼叫建立过程与8。1。1至8。1。5中所讲的端到端的呼叫建立过程是相同的。MCU
可能是被叫端点,也可能是主叫端点。
在集中式的多点会议中,端点与MCU中的MC之间的H.245控制信道是开通的。 端点
与MCU中的MP之间的音频,视频,数据流信道是开通的。 在非集中式的多点会议中, 端点与
MC之间的H.245控制信道是开通的（可能有许多H.245控制信道,每个呼叫对应一个）。在会
议中, 音频,视频流应该是多点传送到所有的端点的。数据流信道对MP数据应该是开通的。
在端点内没有MC的可扩展会议中,H.245控制信道应该经由网闸转发。开始时，H.245
控制信道将经由网闸在端点之间传输。但会议转换到多点时，网闸可以将端点连接到与该网
闸相关的MC上。
在端点内含有一个或多个MC的多点会议中，使用的是8。1。1至8。1。5中定义的正
常呼叫建立过程。主从决定进程用来决定在会议中哪一个MC是主动的。
8.1.8前向呼叫
想要向别的端点发出一个前向呼叫的端点可以发出一个暗含新的端点地址的Facility消
息。接受到此Facility消息的端点应该发出释放完毕消息,然后重新开始同新的端点建立呼叫
联系。
8.1.9广播方式下的呼叫建立
这一子专题以后再研究。
8.2 B阶段---通信初始化和能力交换
一旦通信双方在A阶段已经交换了呼叫建立信息,端点间就建立了H.245控制信道。协议
H.245中的流程被用来进行H.245控制信道上的能力交换和用来打开媒体流信道。
备注---可选地,H.245控制信道可以通过被叫端点收到的建立消息来设置,和通过主叫端
点收到的警告,呼叫处理消息来设置。在连接未建立或者端点发出释放完毕消息的情况
下,H.245控制信道将关闭。
端点的系统能力通过H.245中terminalCapabilitySet 消息的发送来交换。能力信息应该是
最先发送的H.245消息。
主从决定流程将象6。2。8。4中描述的那样进行。在呼叫的两个端点都有MC 能力的
情况下, 主从决定用来决定会议中的哪一个MC是主动的。 然后那个主动的MC就发出
mcLocationIndication 消息。该流程也对开放式的双向数据传输提供了主从决定方式的支持。
如果开始的能力交换和主从决定失败,在端点放弃连接努力而进入到E阶段之前应该再至
少多试两次。
在能力交换完成之后,接着是端点直接进入到期望的操作方式,例如,C阶段。
8.3 C阶段---语音视频通信的建立
在能力交换和主从决定完成后,用H.245协议中规定的流程来为各种信息流打开逻辑信道。
在H.245呼叫建立阶段打开的逻辑信道中传输的音频,视频流,在利用不可靠的协议的动态
TSAP标识符上传输（参见H.225.0协议）。在H.245呼叫建立阶段打开的逻辑信道中传输的
数据通信流,则利用可靠的协议传输（参见H.225.0协议）。
OpenLogicalChannelAck 返回接收端点指定的逻辑信道的传送地址。然后传输通道通过该
逻辑信道向该地址发送信息流。
音频视频的逻辑信道建立后,发送端应该为每一语音视频对发送出一个
h2250MaximumSkewIndication消息。
8.3.1模式改变
在一个会话期,应该象H.245协议中规定的那样对信道结构,能力,接收模式等改变采取措
施。
8.3.2遵守共同协议的视频流的交换
协议H.245中定义了videoIndicateReadyToActivate 。对它的使用是可选的。但如果要
用它,则按下面的法子办。
除非并且直到端点1已经设置好使得视频流能够传输,端点2才准备就绪来发送视频流。
当初始的能力交换完成后,端点1将发出videoIndicateReadyToActivate指示，但直到从端点２
接收到videoIndicateReadyToActivate或视频流，它才传输视频流。
不使用上述可选项的端点,不必非等到接受到videoIndicateReadyToActivate指示或视频流
之后才开始自己的视频流发送。
8.3.3媒体流地址分配
对单点传送,端点建立到MCU或其他端点的逻辑信道。地址通过openLogicalChannel或
openLogicalChannelAck。 来传递。
对多点传送, 多点传送地址由MC 分配（在communicationsModeCommand中分配到各
个端点）。分配唯一的多点地址是MC的任务。端点将一个开放的逻辑信道分配到具有多点
地址的MC上,该地址由openLogicalChannel获得。MC将向每个端点转发openLogicalChannel。
在多点-单点会议中,端点将与其他的每个端点建立逻辑信道。 OpenLogicalChannel发送
到MC,并包含与信道有关的所有端点的数目。端点能够通过forwardLogicalChannelNumber
与一个openLogicalChannelAck匹配。
8.4 D阶段---呼叫服务
8.4.1带宽改变
在许可交换中首先建立呼叫带宽并被网闸认可。端点将确保所有发出和接受到的音频,
视频信道（RTP头,RTP有效载荷,LAN头及其他开支）在此带宽范围之内。数据和控制信道
的带宽不受此限。
在会议的任何时间,端点或网闸可能增加或降低呼叫带宽资源的申请。如果发出和接受信
道的总比特率不超过当前的呼叫带宽,端点可以不申请带宽改变而改变一个逻辑信道的比特
率。但是当这一改变导致总的比特率超过了当前的呼叫带宽时,端点的比特率在得到实际的增
加之前,它必须从它的网闸那里申请改变带宽并且等待网关的确认。建议当一个端点在较长一
段时间内对待宽需求降低时也申请带宽改变,为其他的呼叫释放多余带宽。
欲要改变带宽的端点向它的网闸发送带宽改变请求消息（BRQ）（1）。网闸决定是否答
应请求。如何决定的一些原则问题超过了本协议的范围。如果网闸拒绝接受该请求,它向端点
发送拒绝带宽改变消息（BRJ）（2）。反之,则发送带宽改变许可消息（BCF）（2）。
若端点1想要增加它在逻辑信道上的传输比特率,它首先看是否超过了呼叫带宽。参看图
24。若超过了,端点1将向网闸1请求带宽改变（1和2）。当带宽足以满足此改变时,端点1
发出closeLogicalChannel消息（3）来关闭逻辑信道。然后它用指明了新的比特率的
openLogicalChannel消息（4）来重新打开逻辑信道。如果接收端点要接受新的传输率,它必须
首先确保这一改变不会导致带宽不足。如果确实导致了,那么它就向它的网闸请求带宽改变（5
和6）。 当呼叫带宽足以满足此改变时,端点2向端点1发出openLogicalChannelAck（7）作
为应答,否则发出openLogicalChannelReject表明其不能接受新的传输率。
Gaetkeeper 1
BRQ(1 )
BCFB/RJ (2)
ColseLogciaClhanne(3 l)
OpenLogciaClhanne(4 l)
Endpoin1t Endpoin2t
G
BRQ(5 )
BCFB/RJ (6)
OpenLogciaClhAck(7 )
N
O
若端点1
t
想要从端点2那里增加它在逻辑信道上的传输比特率,它首先看是否超过了呼叫
TE? Gaekeeper 1a ndG aetkeeper 2m ayb eht esa meG aetkeeper.
带宽（端点1先前降低了自己的传输比特率）。参看图25。若超过了,端点1将向网闸1请求
带宽改变。当带宽足以满足此改变时,端点1向端点2发出flowControlCommand 消息（3）
来指明新的传输比特率上限。如果端点2决定要增加传输率,它必须首先确保这一改变不会导
致带宽不足。如果确实导致了（带宽不足）,那么它就向它的网闸请求带宽改变（4和5）。 当
呼叫带宽足以满足此改变时,端点2将发出closeLogicalChannel （6）来关闭逻辑信道。然后
端点2用指明了新的比特率的openLogicalChannel（7）来重新打开逻辑信道。此时端点1应
该同意新的传输率,并向端点2发出openLogicalChannelAck（8）作为回答。
Gaetkeeper 1
BRQ(1 )
Endpoin1t
Endpoin2t
BCFB/RJ (2)
FolwConrotClommand(3 )
BRQ(4 )
BCFB/RJ (5)
ColseLogciaClhanne(6 l)
OpenLogciaClhanne(7 l)
OpenLogciaClhAck(8 )
Figure 25/H.323 – Bandwidth change request – Receiver change
NOTE? Gaetkeeper 1a ndG aetkeeper 2m ayb eht esa meG aetkeeper.
想改变端点1的传输率的网闸向端点1发出BRQ消息。如果请求的是降低比特率,端点
1将一直遵守它自己的传输率降低请求并且返回一个BCF消息。端点1可以发起适当的H.245
信令来通知端点2:比特率已经发生了改变。这将允许端点2将改变通知到它的网闸。 如果
请求的是增加比特率,端点可以在必要时提高传输速率。
8。4。2状态
为了让网闸知道端点是否关断,或者是否进入了故障模式,网闸可以利用IRQ/IRR消息序列
（参看H.225.0协议）来定期轮询各个端点（轮询间隔由制造商决定）。 轮询间隔（一般）
大于10秒。此消息也可被11。2节中讲述的诊断工具设备来利用。
网闸可以要求端点定期发送一个非请求式的IRR消息。网闸可以通过ACF消息结构的
irrFrequency域指定的IRR来向端点指明这一点。接受这一irrFrequency速率的端点在整个呼
叫过程中以此速率发出IRR消息．在这一速率有效时，网闸仍然可以向端点发出IRR消息．
在呼叫过程中，端点或者网闸可以定期的从别的端点请求得到呼叫的状态．发出请求的端
点或网闸发出状态查询消息．接收到状态查询消息的端点应答一个暗含当前状态的状态消
息．网闸可以使用这一过程来定期地检查一个呼叫是否仍在继续．注意这一点：呼叫信令信
道上的H.225.0信息不能与RAS信道上的IRR信息冲突。
8.4.3 特别多点会议扩展
下列的流程对端点和网关是可选的,但对MC是必须有的。
特别多点会议指的是能从具有一个MC的点对点将其扩展到多点会议。首先,在端点（端
点1 和端点2）之间建立点对点会议。至少一个端点或网闸必须包含有一个MC。一旦点对
点的会议建立,可由两种方式将其扩展为多点会议。第一种是:想邀请别的端点（端点3）加入
到会议的端点通过MC呼叫被邀请的端点。第二种方式是:端点（端点3）通过呼叫会议中的
端点来加入已有的会议。
无论是直接信号传输方式还是信号转发传输方式均可以进行特别多点 会议扩展。 直接
信号传输方式下的H.245控制信道拓扑图如下:
Endpoint 1
MC
Endpoint 2
Endpoint 3
信号转发传输方式下的H.245控制信道拓扑图如下:
T1524120-96
Endpoint 1
MC
Gatekeeper
Endpoint 3
T1524130-96
Endpoint 2
在任何情况下,在扩展到超过2个端点的会议中,MC 是必须有的。
对于每种呼叫方式,通过邀请或申请的办法建立一个点对点会议并将其扩展为多点会议
所需的流程,将在下面的子专题中讲述。
应该指出的是,由提供MC的实体发生故障时来中止呼叫过程。
8.4.3.1建立直接信号传输方式下的会议
端点1按如下方式建立一个两端点的会议:
A1） 端点1用 一个全局唯一的CID（=N）号和会议目标=CREATE 向端点2发送建
立消息。,如何产生见8.1节中。
A2） 端点2有下列的步骤可选:
A2a） 若它想加入到会议中,则向端点1发出具有CID=N的连接消息。 在这种
情况下,又有两种可能:
1）不参加别的会议;
2）参加别的会议,同时具备参加多点会议的能力,并且接受到的CID=N
与此时参加的会议的CID中的任何一个都不匹配。
A2b） 如果端点2已参加另一个CID=M的会议,并且在某一时刻只能参加一个会
议,那么它可以1）或2）:
1）通过发出释放完毕消息暗示自己已参加会议而来拒绝该呼叫。
2）可以通过发送一个Facility消息请求端点1加入到CID=M的会议 。
Facility消息在routeCallToMC中包含了CID=M的会议和含有MC的
端点的呼叫信令信道传输地址。。
A2c） 如果它不想加入这个会议,它通过发出释放完毕暗示正忙而拒绝该呼叫。
A3） 如果端点2进入会议,端点1用连接消息中提供的信道的传送地址来建立到端点2
的控制信道。
A4） 然后H.245消息按如下步骤交换:
A4a） 端点之间TerminalCapabilitySet的交换决定了所用H.245的版本号以便正
确地分解出保留的接受信息。
A4b） 用H.245主从决定,确定端点2是主动的。在网闸转发模式中,主端点必须
连接到网闸的MC上。若主端点含有MC,它将变为主动的。然后它可以向其他端点发出
MCLocationIndication 消息。MC在当前的会议中可以是主动的,或当用户初始化多点会议函
数时使其主动,这由制造商决定。
A4c） 主端点可以向其他端点发出terminalNumberAssign 消息。端点使用8比特
的端点号,而不使用8比特的MCU号, 端点号来自于RTP头的SSRC域的低8比特。SSRC
的低8比特指明来自特定端点的信息流。
A4d） 发送端从TerminalCapabilitySet消息处获知了收端的能力,它打开逻辑信道。
对每一对语音视频流,发端发出一个h2250MaximumSkewIndication消息。
8.4.3.2直接信号传输方式下邀请（端点）参加会议
有两种邀请方式。其一,包含主动MC的端点邀请别的端点参加会议。其二,不包含主动
MC的端点邀请别的端点参加会议。
用A1-A4的方法建立一个点对点的会议之后,一个包含主动MC的端点（端点2）邀请
别的端点参加会议的流程如下:
B1） 端点2用一个全局唯一的CID（=N）号和会议目标=CREATE向端点3发送建
立消息。参看8.1节。见图26。
B2） 端点3有下列的步骤可选:
B2a） 若它想接受邀请加入到会议中,则向端点2发出具有CID=N的连接消息。
B2b） 如果它不想接受邀请加入这个会议,它通过发出释放完毕暗示正忙而拒绝
该呼叫。
B2c） 若端点3正在参加CID=M的会议,它可以通过发送一个Facility息请求端
点2加入到CID=M的会议 。 Facility消息在routeCallToMC中包含了的 会
议CID=M 和含有MC的端点的呼叫信令信道传输地址。。
B2d）若接受到的CID与当前正在参加的会议的CID相同,则通过发出释放完毕消
息暗示已经参加该会议而拒绝该呼叫。
B3） 若端点接受了邀请,端点2用连接消息中提供的信道的传送地址来建立到端点3
的控制信道。
B4） 然后H.245消息按如下步骤交换:
C1） TerminalCapabilitySet消息在MC和端点3之间交换。
C2） 用H.245主从决定,确定端点2具有主动的MC。然后它向端点3发出
MCLocationIndication 消息。
C3） 这时MC向所有的3个端点发出multipointModeCommand消息。
C4） MC可以向端点3发出terminalNumberAssign 消息。若接收到了,端点使用8比特
的端点号,而不使用8比特的MCU号, 端点号来自于RTP头的SSRC域的低8比特。SSRC
的低8比特指明来自特定端点的信息流。
C5） 端点向MC发送terminalListRequest消息,可以获得当前会议的其他所有端点的列
表。MC以terminalListResponse作为应答。
C6） 任何一个新端点加入到会议的时候,MC向端点4发送terminalNumberAssign消息,
向端点1,2,3发送terminalJoinedConference消息。
C7） 当有端点离开时,MC向留下的端点发送terminalLeftConference消息。
C8） MC向所有会议端点发送communicationModeCommand消息。
C9） 如果端点1和2没有保持communicationModeCommand中的信息,它们在点对点
会议时建立的逻辑信道将被关闭。
C10） 现在MC和其他端点之间的逻辑信道可以打开。
Endpoint 2 (E2)Endpoint 3 (E3)
Set-up (E3, CID = N, invite)
Alerting/Call Proceeding
Connect (E3 H.245 TA)
Figure 26/H.323 – MC invite signalling
用A1-A4的方法建立一个点对点的会议之后,一个不包含主动MC的端点（端点1）邀
请别的端点参加会议的流程如下:
B1） 端点1向MC（端点2）发出具有新的CRV的建立消息。该新的CRV含有一个到端
点3的呼叫,并提供了呼叫端点3的传送地址。CID=N,会议目标=INVITE。见图27。
B2） 端点2向3发出具有CID=N, 会议目标=INVITE的建立消息。见8.1节。
B3） 在端点1和3呼叫期间,端点2将向端点1（最初的发起者）转发从端点3收到的呼叫
信令消息（包括连接信息）。
B4） 如前所述,端点3有接受或拒绝邀请的选择权。
B5） 在端点2和3之间的呼叫建立过程完成后,端点2将向1发出释放完毕消息。
B6） 若端点3接受邀请, 端点2用连接消息中提供的信道的传送地址来建立到端点3的控
制信道。
B7） 然后H.245消息按上面的C1-C10步骤交换。
Endpoint 1 (E1)
Set-up (E3, CID = N, invite)
Endpoint 2 (E2)Endpoint 3 (E3)
Set-up (E3, CID = N, invite)
Alerting/Call Proceeding
Alerting/Call Proceeding
Connect (E3 H.245 TA)
Connect (E3 H.245 TA)
Release Complete (cause)
T1524150-96
Figure 27/H.323 – Non-MC invite signalling
8.4.3.3直接信号传输模式下（端点主动）加入会议
有两种主动申请参加会议方式。其一, 申请参加会议的端点呼叫包含主动MC的端点参
加会议。其二, 申请参加会议的端点呼叫不包含主动MC的端点参加会议。
用A1-A4的方法建立一个点对点的会议之后, 申请参加会议的端点（端点3）通过呼叫
包含主动MC的端点来参加会议参加会议的流程如下:
B1） 端点3用 一个全局唯一的CID（=N）号和会议目标=JOIN向端点2发送建立
消息。参看8.1节。见图28。
B2） 若CID与MC内某主动会议的CID匹配,端点2（MC）将有以下选择:
B2a） 若它允许端点2参加会议,它发送CID=N的连接信息。
B2b） 若它不允许端点2参加会议,它发送释放完毕消息表明正忙。
B3） 若CID与MC内所有主动会议的CID都不匹配, 端点2发送释放完毕消息表明
CID是错误的。
B4） 若端点2允许端点3加入会议,则它打开到端点3的逻辑信道。
B5） 然后H.245消息按上面的C1-C10步骤交换。
Endpoint 2 (E2)Endpoint 3 (E3)
Set-up (E3, CID = N, join)
Alerting/Call Proceeding
Connect (E2 H.245 TA)
Figure 28/H.323 – MC join signalling
用A1-A4的方法建立一个点对点的会议之后, 申请参加会议的端点（端点3）通过呼叫
不包含主动MC的端点来参加会议参加会议的流程如下:
B1） 端点3用 一个全局唯一的CID（=N）号和会议目标=JOIN向端点1发送建立消
息。参看8.1节。见图29。
B2）端点1返回含有routeCallToMC的Facility消息。 RouteCallToMC中有端点2（含
MC）的呼叫信道传送地址
B3）端点3向2（含MC）发送具有CID=N,会议目标=JOIN的建立消息。其余同上述
的JOIN流程。
Endpoint 1 (E1)
Set-up(E 1 C,ID= N , join)
Facility(c ause E,2)
ReleaseC omplete(c ause)
Endpoint 3 (E3)
Endpoint 2 (E2)
Set-up(E 2 C,ID= N , join)
Alerting/Call Proceeding
Connect (E2H 2.45 TA)
Figure 29/H.323 – Non-MC join signalling
8.4.3.4网闸转发方式下会议的建立
在网闸转发呼叫信令和H.245控制信令情况下,网闸应该包含（或能访问）MC或MCU。
A1-A4过程用于建立点对点的呼叫。在进行主从决定时（A4b）,若网闸的端点类型
（terminalType）大于从masterSlaveDetermination消息中的端点收到的terminalType,网闸可以
在向目标端点发送信息之前以该端点的terminalType值替代它原来的值。 若网闸的端点类型
（terminalType）不大于从该端点的terminalType,则网闸不能修改terminalType值。实际上,
网闸与每个端点之间进行主从决定。若网闸与每个端点进行主从决定后均取得主的地位,则与
它相连的MC是主动的MC,否则,某个别的端点的MC是主动的MC。
8.4.3.5网闸转发信号方式下INVITE会议
用A1-A4的方法建立一个点对点的会议之后,一个不包含主动MC的端点（端点1或2）
邀请别的端点参加会议的流程如下:
B1） 端点1通过网闸直接向端点3发送建立消息（CID=N和会议目标=INVITE,新的
CRV值）。见图30。
B2） 网闸（MC）向端点3发送建立消息（CID=N,会议目标=INVITE）。参见8。1节。
B3） 在端点1和3呼叫期间,网闸将向端点1（最初的发起者）转发从端点3收到的呼
叫信令消息（包括连接信息）。
B4） 如前所述,端点3有接受或拒绝邀请的选择权。
B5） 在端点3和网闸之间的呼叫建立过程完成后, 网闸将向1发出释放完毕消息。
B6） 若端点3接受邀请, 网闸用连接消息中提供的信道的传送地址来建立到端点3的
控制信道。
B7） 然后H.245消息按上面的C1-C10步骤交换。网闸参与所有的主从决定以决定随
时主动的MC。这时,从端点开始的控制信道必须连接到主动的MC上,并且MC应该在会议的
控制之中。
Endpoint 1 (E1)
Set-up(E 3 C,ID= N , invite)
GatekeeperEndpoin
Set-up(E 3 C,ID= N , invite)
Call Proceeding/Alerting
Connect (E3H 2.45 TA)
Connect (GK H2.45T A)
ReleaseC omplete(c ause)
Figure 30/H.323 - Gatekeeper routed invite signalling
Call Proceeding/Alerting
8.4.3.6网闸转发信号方式下的JOIN会议
用A1-A4的方法建立一个点对点的会议之后, 申请参加会议的端点（端点3）通过呼叫
不包含主动MC的端点来参加会议参加会议的流程如下:
B1） 端点3通过网闸直接向端点1发送建立消息（CID=N和会议目标=JOIN）。参看
8.1节。见图30。
B2） 若CID与MC内某主动会议的CID匹配,网闸（MC）将有以下选择:
B2a） 若它允许端点3参加会议,它发送CID=N的连接信息。
B2b） 若它不允许端点3参加会议,它发送释放完毕消息表明正忙。
B3c） 网闸可以向端点1发出建立消息。 端点1可以以表明routeCallToMC的
Facility消息或释放完毕消息作为应答。
B3） 若CID与MC内所有主动会议的CID都不匹配, 网闸发送释放完毕消息表明CID
是错误的。
B4） 若网闸允许端点3加入会议,则它利用建立消息中提供的呼叫传送地址信息打开
到端点3的逻辑信道。
B5） 然后H.245消息按上面的C1-C10步骤交换。网闸参与所有的主从决定以决定随
时主动的MC。这时,从端点开始的控制信道必须连接到主动的MC上,并且MC应该在会议的
控制之中。
Endpoint 3 (E3)GatekeeperEndpoint 1
Set-up( E1 C,ID= N , join)
CallP roceeding/Alerting
Connect( GK H2.45T A)
Figure 31/H.323 – Gatekeeper routed join signalling
8.4.4附加设备
本协议中规定:允许端点使用Q.931-, Q.932-, Q.95X 协议系列中定义的附加设备。这些设
备将使用呼叫信令和Q.931消息。 它们可以提供象保持,转移,先前,重定向之类的特性。
8.5 E阶段-----呼叫中止
通过以下过程,任何端点均可以中止呼叫。
1） 在最后一张画面传完后,该端点应该停止传送视频流,并且关闭为视频流打开的所有逻辑信
道。
2） 该端点应该停止传送数据,并且关闭为数据打开的所有逻辑信道。
3） 该端点应该停止传送音频流,并且关闭为音频流打开的所有逻辑信道。
4） 在H.245控制信道中发送H.245消息: endSessionCommand,向远处的端点表明自己想中止
呼叫;然后停止H.245消息的发送。接着要做的是关闭H.245控制信道。
5） 它等待从别的端点那里接收到endSessionCommand消息,然后关闭H.245控制信道。
6） 若呼叫信道是开通的,应该发送出释放完毕消息,然后关闭该信道。
7） 用下面定义的流程清除呼叫。
不是首先发出endSessionCommand消息的端点在收到了（别的端点发来的）
endSessionCommand消息时,它执行的步骤是上面的1---7步,除了在第5步中不必等待（别的
端点发来的） endSessionCommand消息的到来。
中止一个呼叫并不能中止一个会议;可以通过H.245消息（dropConference）来中止会议。
在这种情况下,端点必须等待MC按上述步骤来中止呼叫。
8.5.1无网闸时的呼叫清除
在无网闸的网络里,在经过上面的1-6步后,呼叫就中止了。不需要做更多的处理。
8.5.2有网闸时的呼叫清除
在有网闸的网络里,网闸需要知道释放的带宽。在完成上面的1---6步后,每个端点向它的
网闸发送（H.245中）的脱离请求消息（DRQ）（3）。 网闸以脱离标识符消息（4）作为应答。
在发送DRQ消息之后,端点不再向网闸发送更主动的IRR消息。参见图32。在这一点上,呼
叫中止了。图32对应的是直接呼叫模式。网闸转发模式下的流程（在下面讲到）与此相似。
DRQ和DCF消息在RAS信道上传输。
Gatekeeper 1Endpoin1t Endpoin2t Gatekeeper 2
EndSessionCommand(1 )
EndSessionCommand(1 )
Release Competle (2)
DRQ(3 )
DCF(4 )
DRQ(3 )
DCF(4 )
T1524200-96
RASm essages
CallS ginalingm essages
Figure 32/H.323 – Endpoint initiated call clearing
H2.45m essages
NOTE? Gatekeeper 1an dG atekeeper 2m ayb e hte same Gatekeeper.
8.5.3由网闸清除呼叫
网闸可以向端点发出DRQ消息来中止呼叫。见图33。端点应该立即执行上面的1-6步,
然后向网闸发出DCF消息作为应答。另一端点,应该跟着执行上面的流程。 图33对应的是
直接呼叫模式。网闸转发模式下的流程（在下面讲到）与此相似。
若会议是多点会议,网闸应该向所有参加会议的端点发出DRQ消息来关闭整个会议。
Gatekeeper 1
DRQ(3 )
EndSessionCommand(1 )
EndSessionCommand(1 )
Endpoin1t Endpoin2t Gatekee
ReleaseC ompelet(2 )
DCF(4 )
DRQ(3 )
DCF(4 )
T1524210-9
RASm essages
CallS ginalingm essages
H2.45m essages
– Gatekeeper initiated call clearing Figure 33/H.323
NOTE? Gaetkeeper 1a ndG atekeeper 2m ayb eht esa meG aetkeeper.
8.6对协议出错的处理
在报告出错之前,遵循可靠协议的H.245信道会尽适当的努力去收发信道上的数据。因此,
如果在信道上出现错误报告,那么H.245控制信道及所有相关的逻辑信道都将关闭。（这时,）
正如象别的端点发出了H.245消息: endSessionCommand的情况下那样,应该做E阶段的处理。
这包括向网闸发送DRQ消息和中止呼叫信令信道。在多点会议中,若错误由MC 检测到,MC
将向剩下的端点发出terminalLeftConference消息。下面执行的是:是否在无用户干预的情况下
重建呼叫。无论哪种情况,对端点（和网闸）而言,就象一个新的呼叫一样。
呼叫信令信道也使用可靠的协议。依赖于呼叫信令信道的转发方式,网闸或端点可以检测
到出错。若网闸检测到出错,将试图尽力重建信道。这意味着端点始终具备在它的呼叫信道传
送地址上建立信道的能力。呼叫信道上的出错不能改变Q.931的呼叫状态。在重建呼叫信道
后,网闸可发出状态消息来请求得到端点的呼叫状态,以确保它们处于同步中。
若端点检测到出错,它可以选择E阶段描述的那样来中止呼叫,或象上面所讲的那样重建
呼叫信道。
在呼叫中,若端点想知道其他端点是否仍在工作或处入连接状态,它可以发出H.245消息:
roundTripDelayRequest。因为H.245控制信道是可靠信道,所以它可从其他端点得到应答,或从
传输界面得到出错信息。在后种情况下,使用上面描述的处理方法。多点会议中的端点可使用
相同的方法。但是,它仅能了解是否仍然连接到MC上。要注意的是对端点而言这一点是可能
的:它可以与MC进行忽视错误的连接,但此时不能从会议的其他端点那里接收音频或视频流。
9与其他类型终端的互连
与其他类型终端的互连必须通过网关。见6.3节。
9.1纯语音终端
可由下列基于ISDN或GSTN的网关提供与纯语音终端的互连。
1）
2）
使用 H.323-ISDN 语音网关;
使用 H.323-GSTN 语音网关。
网关必须考虑到下面的方面。
- 音频编码转换:
-
-
-
ISDN: If desired, since ISDN uses G.711。
GSTN: from analogue to G.711。
比特流转换:
-
-
ISDN: H.225.0 to/from unframed。
GSTN:产生 H.225.0。
-
-
-
控制转换 （产生 H.245）。
呼叫控制信令转换。
DTMF tone conversion to/from H.245 userInputIndication message。
9.2基于ISDN（H.320）的可视电话终端
利用基于ISDN（H.320）的H.323-H.320网关实现与可视电话终端的互连。
网关必须考虑到下面的方面。
-
-
-
-
-
-
9.3基于GSTN（H.324）的可视电话终端
可由下列基于GSTN（H.324）的网关提供与可视电话终端的互连。
1）
2）
使用H.323-H.324 网关;
使用H.323-H.320 网关。
视频格式转换-视频编码转换。
数据协议转换。
比特流转换。
控制转换。
呼叫控制信令转换。
SBE Number conversion to/from H.245 userInputIndication message。
网关必须考虑到下面的方面:
•
•
-
-
-
视频格式转换。
数据协议转换。
视频编码转换。
比特流转换。
呼叫控制信令转换。
9.4基于移动通信的可视电话
以后研究。
9.5基于ATM的可视电话
可由下列基于ATM（H.321）的网关提供与可视电话终端的互连。
1） using a H.323-H.321 Gateway;
2） using a H.323-H.320 Gateway, assuming that there exists an I.580 ISDN/ATM Interworking
Unit in the network。
网关必须考虑到下面的方面:
•
•
-
视频格式转换 （If desired, H.261 is mandatory for both terminal types。）
数据协议转换。
视频编码转换（If desired, G.711 is mandatory for both terminal types。）
- 比特流转换。 （H.225.0 to/from H.221）
- 控制转换。（H.245 to/from H.242。）
•
9.6基于有质量保证的LAN（H.322）的可视电话终端
由下述网关提供与基于有质量保证的LAN（H.322）的可视电话终端的互连。
- 使用H.323-H.320网关。
呼叫控制信令转换
网关必须考虑到下面的方面:
•
•
-
视频格式转换 （If desired, H.261 is mandatory for both terminal types。）
数据协议转换。
视频编码转换（If desired, G.711 is mandatory for both terminal types。）
- 比特流转换。 （H.225.0 to/from H.221）
- 控制转换。（H.245 to/from H.242。）
•
9.7基于GSTN（V7。0）的能进行语音和数据同时传输的终端
由下述网关提供与基于GSTN（V7。0）的能进行语音和数据同时传输的终端的互连:
- 使用H.323-V。70 网关。
网关必须考虑到下面的方面:
•
•
•
•
•
9.8 LAN上的T.120终端
具备T.120能力的H.323终端应该被配置为能在标准的T.120 TSAPSH上监听和接收信
息的纯T.120终端。这将允许具备T.120能力的H.323终端参加纯T.120会议。
视频编码转换（G.711 to/from Annex A/G.729。）
数据协议转换。
比特流转换。 （H.225.0 to/from V。76/V。75。）
控制转换。 （Both terminals use H.245。）
呼叫控制信令转换
呼叫控制信令转换
LAN上的纯T.120终端可以参加H.323多点会议中的T.120部分。参见6。2。7。1
节。
10 可选的增加功能
10.1加密技术
以后研究。
11 维护
11.1取维护作用的lOOPBACKS
在H.245中定义了一些loopback 功能来验证终端的一些功能,以确保系统正确运行和提
供令人满意的服务质量。
不能使用SystemLoop和 logicalChannelLoop 请求。 MediaLoop要求是可选的。接收到
maintenanceLoopOffCommand消息的终端关掉当前所有有效的loopback功能。
为了此目地,定义了两种方式:
a）正常运行模式:无loopback。见图34。这时缺省的模式,当收到maintenanceLoopOffCommand
消息时进入这种模式。
b) 媒体环模式:在模拟I/O界面的媒体流的Loopack。接收到H.245协议中定义的mediaLoop
请求时,所选逻辑通道的内容的回退应该激活到指向尽可能近的视频/音频编码器,以形成
解码和再编码媒体环路。见图34的b）图。这种媒体环是可选的。仅在当每个方向上的
单向逻辑通道包含相同的媒体类型时,才可以采用。多通道在返回方向上是开通情况下的
操作没有定义。
a) Normal
Codec
Network
Interface
b) Medialo op
Codec
Figure 34/H.323 – Loop back
Network
Interface
T1521570-96
接收到systemLoop和logicalChannelLoop（H.245消息）请求的网关（连接到H.324和
H.310）,或从SCN终端接收到H.320数字环命令的网关,可以在网关内执行适当的LOOPBACK
功能函数。网关不会将这些请求传递到LAN终端。接收到mediaLoop（H.245消息）的网关
（连接到H.324和H.310）,能将这些请求传递到LAN终端。从SCN终端接收到 H.230 Vid-loop
或Au-loop命令的网关（连接到H.320）,将这些消息转换为适当的H.245 mediaLoop请求并
将其传递到LAN终端。
从LAN终端接收到H.245请求的H.320网关,将mediaLoop消息转换为适当的H.230
Vid-loop或Au-loop命令并且发送到SCN终端。
连接到H.324和H.310的网关,可向SCN终端发送H.245 systemLoop和
logicalChannelLoop消息。连接到H.230的网关,可向SCN终端发出H.230 Vid-loop或Au-loop
命令。若LAN终端与SCN终端建立了呼叫,发送到LAN终端的音频和视频流,可以是
LOOPBACK的音频和视频流,预录的音频和视频流,或没有音频和视频流。
11.2 监视方法
所有终端应支持H.225.0的 IRQ/IRR消息。IRR消息包含所有信道（含T.120,H.245控
制,音频和视频信道）上的当前有效呼叫TSAP标识符。第三方维护设备可利用这些信息来监
视H.323会议,以保证系统正常运行。
附录（不译）
ANNEX A
H.245 messages used by H.323 endpoints
The following rules apply to the use of H.245 messages by H.323 endpoints:
• An endpoint shall not malfunction or otherwise be adversely affected by receiving H.245
messages that it does not recognize。 An endpoint receiving an unrecognized request,
response, or command shall return "function not supported"。 （This is not required for
indications。）
• The following abbreviations are used in Tables A.1 to A.11:
M Mandatory
O Optional
F
•
Forbidden to transmit
A message marked as mandatory for the receiving endpoint indicates that the endpoint
shall accept the message and take the appropriate action。 A message marked as
mandatory for the transmitting endpoint indicates that the endpoint shall generate the
message under the appropriate circumstances。
Table A.1/H.323 - Master-slave determination messages
Message
Endpoint Status
Determination
Determination Acknowledge
Determination Reject
Determination Release
Receiving Endpoint Status Transmitting
M
M
M
M
M
M
M
M
Table A.2/H.323 - Terminal capability messages
Message Receiving Endpoint Status Transmitting
Endpoint Status
Capability Set M M
Capability Set Acknowledge M M
Capability Set Reject M M
Capability Set Release M M
Table A.3/H.323 - Logical channel signalling messages
Message Receiving Endpoint
Transmitting Endpoint Status
Open Logical Channel M M
Open Logical Channel Acknowledge M M
Open Logical Channel Reject M M
Open Logical Channel Confirm M M
Close Logical Channel M M
Close Logical Channel Acknowledge M M
Request Channel Close M O
Request Channel Close Acknowledge O O
Request Channel Close Reject O M
Request Channel Close Release O M
Table A.4/H.323 - Multiplex table signalling messages
Message Status
Multiplex Entry Send F
Multiplex Entry Send Acknowledge F
Multiplex Entry Send Reject F
Multiplex Entry Send Release F
Table A.5/H.323 - Request multiplex table signalling messages
Message Status
Request Multiplex Entry F
Request Multiplex Entry Acknowledge F
Status
Request Multiplex Entry Reject
Request Multiplex Entry Release
F
F
Table A.6/H.323 - Request mode messages
Message Receiving Endpoint
Transmitting Endpoint Status
Request Mode M O
Request Mode Acknowledge M O
Request Mode Reject O M
Request Mode Release O M
Table A.7/H.323 - Round trip delay messages
Message Receiving Endpoint
Transmitting Endpoint Status
Round Trip Delay Request M O
Round Trip Delay Response O M
Table A.8/H.323 - Maintenance loop messages
Message Receiving Endpoint
Transmitting Endpoint Status
Maintenance Loop Request
System Loop F
Media Loop O （Note）
（Note）
Logical Channel Loop
Maintenance Loop Acknowledge O O
Maintenance Loop Reject O M
Maintenance Loop Command Off M O
NOTE - Mandatory in Gateways。
Status
Status
Status
F
O
F F
Table A.9/H.323 - Commands
Message Receiving Endpoint Status
Send Terminal Capability Set
Encryption
Flow Control
End Session
Miscellaneous Commands
Transmitting Endpoint Status
M M
O O
M O
M M
Equalize Delay O O
Zero Delay O O
Multipoint Mode Command M
Cancel Multipoint Mode Command M
Video Freeze Picture M
Video Fast Update Picture M
Video Fast Update GOB M
Video Fast Update MB M
Video Temporal Spatial Trade Off O
Video Send Sync Every GOB O
Video Send Sync Every GOB Cancel
O
MCLocationIndication M
Terminal ID Request O
O
O
O
O
O
O
O
O
O
O
O
Terminal List Request
broadcast Me O
cancel Broadcast Me
Make Terminal Broadcaster
Send This Source
Cancel Send This Source
Drop Terminal O
Make Me Chair O
Cancel Make Me Chair
Drop Conference
Enter H.243 Password
Enter H.243 Terminal Id
Enter H.243 Conference ID
Request Terminal ID
Terminal ID Response
Terminal List Response
Video Command Reject
Make Me Chair Response
O O
O
O O
O O
O O
O O
O
O
O O
O O
O O
O O
O O
O O
O O
O O
O O
O O
Table A.10/H.323 - Conference mode commands
Message
Communication Mode Command
Communication Mode Request
Communication Mode Response
Receiving Endpoint Status
Transmitting Endpoint Status
M
O
O
O
O
O
Message
Function Not Supported
Miscellaneous Indication
Table A.11/H.323 - Indications
Receiving Endpoint Status
Transmitting Endpoint Status
M M
Logical Channel Active O O
Logical Channel Inactive O O
Multipoint Conference M O
Cancel Multipoint Conference M O
Multipoint Zero Comm O O
Cancel Multipoint Zero Comm O O
Multipoint Secondary Status O O
Cancel Multipoint Secondary Status O O
Video Indicate Ready to Activate O O
Video Temporal Spatial Trade Off O O
SBE Number O O
Terminal Number Assign M O
Jitter Indication
H.223 Skew Indication
H2250MaximumSkewIndication
New ATM Virtual Channel Indication
User Input
0-9, *燼nd #）
Non-standard commands, requests, etc。
Terminal Joined Conference O
Terminal Left Conference O
Seen By At Least One Other O
Cancel Seen By At Least One Other O
Seen By All O O
Cancel Seen By All O
Terminal You Are Seeing O
Request For Floor O
O O
F F
O M
F F
M （for 0-9, * and #） M
are allowed。
O
O
O
O
O
O
O
for （
APPENDIX I
Processing of Q.931 messages in Gateways
The Gateway shall terminate the Q.931 Call Signalling Channel between an H.323 endpoint and the
Gateway on one hand and the call signalling channel （if any） between the Gateway and the SCN
endpoint on the other。 The following applies only if the SCN side supports a call signalling
protocol such as Q.931 or Q.2931。
The Gateway shall conform to the call signalling procedures recommended for the SCN side
independent from the LAN side。 The Gateway shall conform to the call signalling procedures of
this Recommendation for the LAN side independent from the SCN side。
In addition, call signalling messages received from one side （LAN/SCN） may require forwarding
to the other side （SCN/LAN）。 Some forwarded messages may contain information elements or
parts of information elements which are unmodified or uninterpreted by the Gateway。 Other
forwarded messages may contain information elements or parts of information elements may be
added or removed by the Gateway, as needed。
In the following, an overview of the actions to be taken by the gateway in response to Q.931
messages and the information elements, is provided。 Messages and information elements that are
forbidden in Recommendation H.225.0 are not considered。
Q.931 messages originating on the H.323 side:
•
•
A SETUP message side shall lead to initiation of call set-up procedure for the SCN side。
A RELEASE COMPLETE shall lead to initiation of the call disconnect as defined for the
SCN side。
• A CALL PROCEEDING message shall be forwarded to the SCN side。 This shall not be
done if a CALL PROCEEDING has been sent before to the SCN in compliance to the
respective SCN specification （Q.931 in the ISDN case）。
• A CONNECT message shall be forwarded to the SCN side upon receipt from an H.323
endpoint。
• A CONNECT ACKNOWLEDGE message shall be forwarded to the SCN side upon
receipt。 This shall not be done if CONNECT ACKNOWLEDGE has been sent before to
the SCN in compliance to the respective SCN specification。 If the Gateway has sent a
CONNECT to an H.323 endpoint and has not received the corresponding CONNECT
ACKNOWLEDGE from the H.323 endpoint within the time frame required for successful
completion of the call, it shall generate the CONNECT ACKNOWLEDGE to the SCN
side as appropriate to comply to the SCN call set-up procedures。
• Messages for supplementary services （FACILITY, HOLD, HOLD ACKNOWLEDGE,
HOLD REJECT, RETRIEVE, RETRIEVE ACKNOWLEDGE, RETRIEVE REJECT and
the INFORMATION messages） that are not processed by the Gateway, shall be
forwarded to the SCN side。
• All messages forbidden to be originated from an H.323 endpoint shall be generated by the
Gateway autonomously as required by the SCN protocol。
The information elements of the respective messages are to be converted as follows:
• The contents of connection specific information elements （such as Call Reference Value）
shall be adapted as required by the SCN protocol。
• Information elements that are not in use on the H.323 side shall be generated by the
Gateway as required by the SCN protocol。
• Translation of other information elements shall be done as required by the SCN protocols
and procedures。 Where interoperability is not an issue, conversion is left to the discretion
of the manufacturer。
• Only the user-data part of the user-user information element shall be forwarded to the
SCN side。 It shall be re-encoded following Figure 4-36/Q.931 and Table 4-26/Q.931。
All Q.931 messages originating on the SCN side are forwarded to the H.323 endpoint without
modification except for the following:
•
•
•
Messages forbidden by Recommendation H.225.0 shall not be passed to the H.323 side。
The call reference value is mapped to the appropriate value for the H.323 side。
The user data field is copied into the corresponding ASN。1 user-user information element
structure。
• The user-user information element structure shall be generated according to the
specification in Recommendation H.225.0。
ITU-T RECOMMENDATIONS SERIES
Series A
Series B
Series C
Series D
Series E
Series F
Series G
Series H
Series I
Series J
Series K
Series L
plant
Series M
Organization of the work of the ITU-T
Means of expression: definitions, symbols, classification
General telecommunication statistics
General tariff principles
Overall network operation, telephone service, service operation and human factors
Non-telephone telecommunication services
Transmission systems and media, digital systems and networks
Audiovisual and multimedia systems
Integrated services digital network
Transmission of television, sound programme and other multimedia signals
Protection against interference
Construction, installation and protection of cables and other elements of outside
Maintenance: international transmission systems, telephone circuits, telegraphy,
facsimile and leased circuits
Series N
Series O
Series P
Series Q
Series R
Series S
Series T
Series U
Series V
Series X
Series Z
Maintenance: international sound programme and television transmission circuits
Specifications of measuring equipment
Telephone transmission quality, telephone installations, local line networks
Switching and signalling
Telegraph transmission
Telegraph services terminal equipment
Terminals for telematic services
Telegraph switching
Data communication over the telephone network
Data networks and open system communication
Programming languages