H323协议介绍

1. 范围

H.323组件包括终端（Terminal）、网关（Gateway）、网守（Gatekeeper）、多点控制器（Multipoint Controller，MC）、多点处理器（Multipoint Processor，MP）和多点控制单元（Multipoint Control Unit，MCU）。H.323协议主要制订这些组件之间的消息控制和流程。

H.323终端之间在点对点（point-to-point）会议或多点（multipoint）会议中提供音频（必选）、视频和数据（可选）通信服务。如果和其它类型终端（包括其它H协议、GSTN和ISDN语音或数据设备）之间通信的话，需要通过网关进行适配（见图1）。网守则提供接纳控制和地址翻译等服务。MC、MP和MCU则为多点会议提供支持。

Figure 1/H.323 – Interoperability of H.323 terminals

2. 系统介绍

2.1 终端

图4为一个H.323终端示意图。

Figure 4/H.323 – H.323 terminal equipment

2.1.1 H.245控制功能

H.323终端通过H.245协议和其它实体完成会议控制。H.245协议主要完成下列功能：

✓Master/slave determination 

✓Capability Exchange.

✓Logical Channel Signalling.

✓Bidirectional Logical Channel Signalling.

✓Close Logical Channel Signalling.

✓Mode Request.

✓Round Trip Delay Determination.

✓Maintenance Loop Signalling

H.245消息分为四种：

✓Request：该消息需要接收方产生一个动作并立即返回应答；

✓Response：该消息为接收方对Request的应答；

✓Command：该消息需要接收方产生一个动作但不需要应答；

✓Indication：该消息仅为通知，不需要对方产生具体动作和应答。

H.323终端必须能够解析所有的H.245控制消息MultimediaSystemControlMessage，并且能够发送和接收某些消息以完成所需功能。对于所收到的不认识的消息（request, response, command），应该能够回应消息functionNotSupported。

2.1.1.1 能力交换（Capability Exchange）

H.323终端使用能力交换来描述它所具备的接收和发送能力，也可以通过这些方式的组合来描述它同时具备的能力。

发送终端给表capabilityTable中的每一种模式分配一个编号，然后将这些编号放入结构alternativeCapabilitySet中。每一个结构表示终端能够支持的模式。例如{G.711, G.723.1, G.728}表示能够分别支持三种模式中的任一种。

alternativeCapabilitySet再被组织到结构simultaneousCapabilities中，后者表示终端可以同时支持的模式。例如一个simultaneousCapabilities中包含了两个alternativeCapabilitySet结构{H.261, H.263} 和 {G.711, G.723.1, G.728}表示终端可同时支持视频和音频编解码中的任意两两组合。而一个simultaneousCapabilities设置为{ {H.261}, {H.261, H.263}, {G.711, G.723.1, G.728} }则表示该终端可同时支持两路视频信道和一路音频信道：一路为H.261，一路为H.261或H.263，一路为G.711, G.723.1, G.728中任一。

终端所拥有的完整能力通过一组capabilityDescriptor结构来描述，该结构包含一个simultaneousCapabilities 和capabilityDescriptorNumber 结构。例如某终端用两个capabilityDescriptor 来描述其能力，分别是{ {H.261, H.263}, {G.711, G.723.1, G.728} }和{ {H.262}, {G.711}，表示该终端除了拥有前述能力以外还支持H.262编解码，但此时只能同时支持复杂度较低的音频G.711编解码。

非标准的能力和控制消息可以使用nonStandardParameter结构。

2.1.1.2 逻辑信道信令（Logical Channel Signalling） 

终端通过逻辑信道将其发送的音视频数据发送到其它终端。逻辑信道通过消息openLogicalChannel和closeLogicalChannel来打开和关闭，前者向接收方描述了要打开的信道的所有信息。

打开逻辑信道的顺序如下：

发送方首先按照H.245协议规范向接收方发送消息openLogicalChannel，如果使用RTP发送，该消息结构里必须包含参数mediaControlChannel，该参数中指定发送方的回应RTCP传输地址（transport address）。

接收端收到消息后回应OpenLogicalChannelAck消息，如果使用RTP，该结构里必须包含参数mediaControlChannel，参数中给出接收端RTP和RTCP传输地址。

2.1.1.3 主从判定（Master-slave determination）

主从判定用来解决当两个端设备（endpoint）都含有MC时的冲突问题。首先，双方用消息masterSlaveDeterminationl来互相交换随机数来决定主从关系。两个端设备必须在消息中分别设定表1中列出的terminalType和随机数statusDeterminationNumber。

Table 1/H.323 – H.323 terminal types for H.245 master-slave determination

2.1.2 RAS信令功能（RAS signalling function）

RAS信令功能使用H.225.0消息完成端设备（endpoint）和网守之间的注册、呼叫接纳、带宽交换、状态和退出呼叫过程。如果不存在网守的话，RAS信令信道不会被使用。该信道必须先于其它信道之前建立。

2.1.3 呼叫信令功能（Call signalling function）

该功能使用H.225消息在两个H.323端设备之间建立呼叫连接。呼叫信令信道在H.245信道和其它逻辑信道打开之间打开。如果存在网守的话，该信道在端设备和网守之间建立，或者由网守选择在两个端设备之间建立。

2.2 网关

网关用于在不同传输格式（如H.225.0 和H.221）以及通信协议（如H.245 和H.242）之间进行翻译转换，还提供IP网和SCN网之间终端呼叫建立和撤销，以及不同音视频和数据码流格式的转换。

图5给出了H.323网关的功能配置情况。

Figure 5/H.323 – H.323 gateway configurations

2.3 网守

网守是可选设备，作用是向H.323端设备提供呼叫控制服务。网守在逻辑上和其它端设备分开，但是在物理上可以和终端，MCU，网关，MC以及其它非H.323网络设备共存。

网守必须完成的功能有：

✓地址翻译（Address Translation）

完成对终端设备从假名（Alias）到传输地址之间的转换；

✓接纳控制（Admissions Control）

使用H.225.0消息ARQ/ACF/ARJ 对端设备接入请求根据呼叫鉴权以及带宽情况予以批准或拒绝；

✓带宽控制（Bandwidth Control）

✓区域管理（Zone Management）

可选的功能有：

✓呼叫控制信令（Call Control Signalling）

在网守路由方式下对两个端设备之间的呼叫予以控制；

✓呼叫鉴权（Call Authorization）

✓带宽管理（Bandwidth Management）

✓呼叫管理（Call Managemen）

✓目录服务（Directory services）

2.4 MC

多点控制器（MC）在多点会议中为2个以上端设备的会议提供支持。

多点会议建立时，一个端设备通过H.245控制信道和MC连接，连接的方式有：

和MCU直接连接；

和网守内部的MC间接连接；

多点会议中和其它终端和网关内部的MC间接连接；

通过网守和MC间接连接；

和MC连接后通过H.245协议确定会议模式（decentralized or centralized），模式的确定主要决定于和MC连接的终端的能力。

MC可以位于网守，网关，终端或MCU内（见图6）。

如果会议中存在2个以上端设备的话，他们之间需通过主从确定来决定控制会议的MC。

能力交换和主从确定后，MC首先用terminalNumberAssign消息给新的端设备分配一个终端号同时通过消息terminalJoinedConference通知其它端设备会议中有新的端设备加入。新的端设备可以通过消息terminalListRequest获取会议中其它所有端设备的列表。

2.5 MP

多点处理器（MP）在集中式或混合式会议中从各端设备中接收音频、视频和数据流并进行处理后发送到各端设备。MP和MC之间的接口由用户自定义。

在MCU中，MP是不可呼叫的部分。

2.6 MCU

多点控制单元（MCU）必须含有一个MC，0个或多个MP。一个典型的支持集中式会议的MCU由一个MC，一个音视频及数据处理器MP组成。一个典型的支持分散式会议的MCU由一个MC，一个数据处理器MP组成。

3. 呼叫信令（Call Signalling）

呼叫信令消息用于完成呼叫建立，呼叫中带宽改变，查询端设备状态，撤销呼叫。

3.1 地址

每一个H.323端设备对应的地址有网络地址，TSAP标志，假名地址（包括E.1和partyNumber地址）。

如果网络中不存在网守的话，设备之间必须直接用传输地址（Transport Address，由网络地址和TSAP组成）进行呼叫，否则的话还可以用假名地址呼叫，由网守进行地址翻译。

3.2 RAS信道

RAS信道用于完成网守发现（Gatekeeper Discovery）以及端设备注册(Registration)等过程，使用RAS自己的呼叫信令信道传输地址。该信道必须是不可靠连接的信道。

3.2.1 网守发现

端设备使用网守发现过程来确定其注册的网守，分为人工和自动两种。图7描述了自动发现的信令交互。

Figure 7/H.323 – Auto discovery

3.2.2 端设备注册

端设备注册以加入一个域，并且通知网守它的传输地址和假名地址。每次注册都有一个有限的周期，设备需要在注册消息RRQ内的timeToLive参数中指明该周期。在周期中止前，端设备可以发送RRQ消息设置keepAlive位信息来重新设置周期。

同时，端设备通过URQ消息向网守取消注册，网守也可以主动向端设备发送URQ来取消该设备的注册。

图8描述了端设备的注册过程。

Figure 8/H.323 – Registration

3.2.3端设备定位

一个端设备如果只知道另一个端设备的假名，可以通过LRQ消息定位查询其对应的联络信息。该消息可以单播也可以组播，收到该消息的网守如果已有被查询的设备注册的话，可以回LCF消息告诉其所需端设备的地址信息或该网守自身的地址信息。

3.2.4 接纳、带宽改变、状态和disengage

RAS信道还用来完成传送接纳（Admission）、带宽改变（Bandwidth Change）、状态（Status）和Disengage消息。

3.3 呼叫信令信道

该信道用于发送H.225.0消息，必须建立在可靠连接之上。

在没有网守时，两个短设备之间使用呼叫信令传输地址之间进行呼叫。主叫必须预先知道被叫的传输地址。在有网守时，主叫和网守之间先使用RAS信道交换信息，由网守决定主叫是之间呼叫被叫还是由网守路由中转。此后呼叫消息由主叫发往被叫的呼叫信令地址或网守的呼叫信令地址。

 规范中规定了用于呼叫信令的Q.931消息。

3.3.1 呼叫信令信道路由

呼叫信令（call signalling）消息可以有两种方式。第一种是网守路由方式（见图9），此方式下两终端设备的呼叫信令经网守路由中转。第二种方式是直接呼叫方式（见图10），此方式下呼叫信令在两终端设备之间直接发送。具体选用何种方式由网守决定。

Figure 9/H.323 – Gatekeeper routed call signalling

Figure 10/H.323 – Direct endpoint call signalling

3.3.2 控制信令信道路由

在网守路由呼叫信令方式下，有两种方式进行H.245控制信令（Control Signalling）信道的路由。第一种方式下信令通道之间在两终端设备之间建立（见图11）。第二种方式下该信令通道经由网守中转（见图12）。

Figure 11/H.323 – Direct H.245 control channel connection between endpoints

Figure 12/H.323 – Gatekeeper routed H.245 control

3.4 呼叫引用值

所有的呼叫信令和RAS消息都含有一个呼叫引用值（Call Reference Value, CRV），呼叫信令和RAS信令各有一个CRV。所有呼叫信令中的CRV都对应两个实体之间（端设备和网守之间，端设备和端设备之间）的同一此呼叫，第二个CRV和RAS信令相关联。开始新的呼叫时应该使用新的CRV。需注意的是CRV和Call ID以及Conference ID(CID)不同，CRV将两实体间同一次呼叫中的呼叫信令和RAS消息关联起来，Call ID则将一次呼叫中所有实体之间的消息关联起来，而Conference ID则将一次会议中所有实体的所有呼叫消息关联起来。

3.5 呼叫号

呼叫号（Call ID）是一个全局唯一值，由主叫端创建。它标明了消息相关的一次呼叫，它用来关联一次呼叫中所有的呼叫信令和RAS消息。和CRV不同的是，一次呼叫过程中Call ID是不变的。

3.6 会议号和会议目标

会议号（Conference ID）是一个全局唯一值，由主叫端创建，它将一次会议中的所有呼叫消息关联起来。

会议目标（Goal）表示呼叫的目的，主要有：创建（Create）、加入（Join）、邀请（Invite）、能力协商（Capability Negotiation）和呼叫增值服务（Call Independent Supplementary Service）。

4. 呼叫信令过程

一次呼叫的过程如下几个阶段：

A)呼叫建立（Call setup）

B)初始通信和能力交换（Initial communication and capability exchange）

C)音视频通信的建立（Establishment of audiovisual communication）

D)呼叫服务（Call Services）

E)呼叫中止（Call termination）

4.1 阶段A - 呼叫建立

呼叫建立过程使用H.225.0规范中定义的呼叫控制消息进行。

端设备必须能够发振铃（Alerting）消息，表示被叫方正在振铃通知用户。一个端设备成功发出Setup消息后应该在4秒内之上收到 Alerting, Connect, Call Proceeding和 Release Complete中的任意一个消息。

4.1.1 基本呼叫过程

图13描述了一个未进行注册的两个端设备之间的呼叫过程。

Figure 13/H.323 – Basic call setup, no Gatekeepers

4.1.2 两端设备都向同一个网守注册

Figure 14/H.323 – Both endpoints registered, same Gatekeeper – Direct call signalling

Figure 15/H.323 – Both endpoints registered, same Gatekeeper – 

Gatekeeper routed call signalling

4.1.3 主叫方有网守

Figure 16/H.323 – Only calling endpoint registered – Direct call signalling

Figure 17/H.323 – Only calling endpoint registered – Gatekeeper

routed call signalling

4.1.4 只有被叫方有网守

Figure 18/H.323 – Only called endpoint registered – Direct call signalling

Figure 19/H.323 – Only called endpoint registered – Gatekeeper

routed call signalling 

4.1.5 快速连接过程

H.323端设备既可以以规范H.245的方式也可以以快速连接（Fast Connect）的方式建立媒体信道。快速连接过程允许端设备仅用一次消息交互就建立一个基本的点对点呼叫。

快速连接时主叫方在SETUP消息中包含fastStart，该参数由一系列OpenLogicalChannel结构组成。被叫方也可以拒绝支持快速连接，如果拒绝的话在其返回的其后Q.931消息中不含有fastStart。否则的话在，它发送一条Q.931消息（CALL PROCEEDING, PROGRESS, ALERTING, or CONNECT）回给主叫方，从主叫方建议的OpenLogicalChannel里面挑选出一系列放在fastStart里。

主机方在收到含有fastStart的Q.931消息之后就可以开始发送媒体数据了。

4.1.6 和MCU建立连接

集中式多点会议中，所有端设备和MCU交换呼叫信令。端设备和MCU之间的呼叫和端设备之间呼叫的过程一样，MCU既可以作为主叫，也可以作为被叫。

4.1.7 呼叫前转(Call Forwarding)

一个端设备如果希望将呼叫转移的话，可以向主叫发一个Facility消息，该消息中给出了新设备的地址。主叫收到该消息后发一个Release Complete消息后重新向新设备发起呼叫过程。

4.1.8 用会议名发起呼叫

MC中一个会议可以用假名地址来表示。

4.1.8.1 加入一个会议假名，无网守

主叫端设备（Endpoint1）向MC（Endpoint2）的公开的呼叫信令地址发起一个呼叫，Setup消息里包含下列信息：

       conferenceAlias

      MC(U) transport address

       0 (since the CID is unknown)

       join

MC回应的Connect消息里包含：

 h245Address       Transport Address for H.245 signalling

       CID for the conference

4.1.8.3 加入一个会议假名，有网守

主叫方（Endpoint1）首先和网守之间进行消息ARQ (1)/ACF (2)交互（图14），ARQ消息包含：

       conferenceAlias

        some value N

       0 (since the CID is unknown)

网守在应答ACF消息里返回MC（Endpoint2）的呼叫信令信道传输地址。主叫再发Setup(3)消息给MC，包含信息：

       conferenceAlias

      address supplied by ACF

       0

       join

最终，MC返回Connect消息，包含：

        Transport Address for H.245 signalling

       CID for the conference

主叫方（Endpoint1）最后通知网守正确的CID以完成呼叫，发送的消息为IRR，内容有：

 callIdentifier       same value N as used in the first ARQ

       original CID from endpoint 1

      CID from endpoint 2

4.1.8.4 用会议假名进行会议创建或邀请加入

主叫方（Endpoint1）发一个Setup消息给被叫（Endpoint2），消息内容如下：

       conferenceAlias

      MC(U) transport address

       CID of the conference

       create or invite

被叫回应的Connect消息如下：

        Transport Address for H.245 signalling

       CID for the conference

4.2 阶段B - 初始通信和能力交换

一旦双方交换setup消息后，就开始建立H.245控制信道。H.245规范利用H.245控制信道进行能力交换并打开媒体信道。

注：被叫方可以选择在收到Setup消息，主叫方可以选择在收到Alerting或Call Proceding消息后建立H.245控制信道。如果Connect未收到，或一端发出Release Complete，H.245控制信道必须被关闭。

端设备通过H.245消息terminalCapabilitySet交换系统能力信息，该消息必须为第一条H.245消息。

之后是主从判决决定会议的主控MC（Active MC）。主控MC之后可以发送mcLocationIndication消息。

4.3阶段C - 音视频通信的建立

能力交换和主从判决之后，根据H.245规范的要求打开传送信息流所必需的逻辑信道。音视频数据流使用不可靠连接传送，数据通信使用可靠连接传送（见规范H.225.0）。

接收端通过回应openLogicalChannelAck消息给出其分配的逻辑信道对应的传输地址，发送方必须使用该地址发送码流。

音视频逻辑信道打开后，发送方必须为每对音视频发送h2250MaximumSkewIndication消息。

4.3.1 媒体流地址分配

单播方式下，端设备应该向MCU或另一端设备打开逻辑信道，其地址通过消息openLogicalChannel和openLogicalChannelAck传送。

组播方式下，组播地址由MC分配，并通过消息communicationModeCommand通知给各端设备。端设备则必须用分配的组播地址发一个openLogicalChannel消息通知MC，MC再将该消息转发给所有的接收端设备。

当所有端设备码流在一个会话里发送时（比如只有一个组播地址），MC必须负责打开会议中所有接收终端的逻辑信道。

如果一个端设备在最初的communicationModeCommand消息发送后加入会议，必须由MC负责发送一个最新的communicationModeCommand消息并打开其逻辑信道。反之如果一个端设备在communicationModeCommand消息后离开会议，也必须由MC负责关闭该端设备对应的逻辑信道。

4.3.2 通信模式命令过程

H.245命令CommunicationModeCommand由MC发送，用来标明每一种媒体类型：单播或组播。

该命令描述会议中所有会话。对每一个会话描述如下：RTP会话标志RTP （session identifier），相关RTP会话号（如果可能的话），终端标记（terminal label）（如果可能的话），会话描述，会话数据类型，单播或组播地址。

CommunicationModeCommand给出会议的发送模式，并不给出接收模式，接收模式由MC通过OpenLogicalChannel消息给出。

该命令应该在指示multipointConference后给出。端设备收到指示multipointConference后应该等待CommunicationModeCommand收到后再打开逻辑信道。

收到CommunicationModeCommand的端设备使用字段terminalLabel匹配决定是否对自己适用，如果不含有terminalLabel表示对会议中所有端设备都适用。

4.4阶段D – 呼叫服务

4.4.1 带宽改变

会议进行到任意时刻，端设备或网守都可能要求增加或介绍呼叫带宽。如果改变会导致总的码流超过现有呼叫带宽，端设备必须向网守发请求并获得批准。

图25给出发送端发起请求的过程。

Figure 25/H.323 – Bandwidth change request – Transmitter change

图26给出了接收端发起请求的过程。

Figure 26/H.323 – Bandwidth change request – Receiver change

4.1.2 状态

网守可以通过IRQ/IRR消息轮询各端设备状态，轮询间隔必须大于10秒。网守也可以要求端设备以固定间隔发送IRR消息，此时需要在其回给端设备的ACF消息中的irrFrequency字段中指定发送间隔。

网守也可以通过设置RCF或ACF消息中的willRespondToIRR字段的方式通知它能对IRR消息回应，此时网守必须对IRR消息回应IACK或INACK。

呼叫中，端设备或网守可以定时向其它端设备查询呼叫状态，查询方使用状态查询消息。被查询方收到后发送状态消息报告当前状态。

4.1.3 特别会议扩展

一个特别多点会议（Ad Hoc Multipoint Conferencre）是指能从一个包括MC的点对点会议扩展成多点会议的会议。首先，在两个端设备（Endpoint1和Endpoint2）之间创建一个点对点会议。其中至少一个端设备或者网守上包含有一个MC。点对点会议创建后可以有两种方式扩展成多点会议。第一种是会议中任意一个端设备邀请其它端设备（Endpoint3）加入。第二种是另一端设备（Endpoint3）通过呼叫会议中一个端设备加入。

特别会议能够通过直接呼叫信令模型和网关路由信令模型两种方式扩展。直接呼叫模型表示如下：

网守路由呼叫模型表示如下：

扩展时必须有MC存在。

4.1.3.1 直接端设备呼叫信令 – 会议创建

Endpoint 1创建一个会议到Endpoint 2的过程如下：

A1)    Endpoint 1向Endpoint 2发送Setup消息，消息中包含一个全局唯一的CID   N， conferenceGoal = create；

A2)    Endpoint 2有以下选择：

A2a)    如果它同意加入会议，返回一个Connect消息，消息中CID   N。此时Endpoint 2又分两种情况：

    1)    它不在其它任何会议中；或者

    2)    它正在参加另一个会议，同时它可以同时参加多个会议，并且收到的CID   N不同于它正参见的任意一个会议。

A2b)    如果它正在另一会议CID   M中，并且它不能同时参加多个会议：

    1)    发送Release Complete标明in-conference；或者

    2)    向Endpoint 1发送Facility消息表明routeCallToMC，邀请其加入会议CID   M，消息中包含该会议MC的端设备的呼叫信令信道传输地址。

A2c)    如果它拒绝参加会议，它可以发送Release Complete标明destinationBusy。

A2d)    如果Endpoint 2是一个主持多点会议的MCU，并且它希望提供给Endpoint 1一系列会议以供挑选参加，他可以发一条Facility消息标明conferenceListChoice和会议列表以供选择。

A3)    如果Endpoint 2进入会议， Endpoint 1使用收到的Connect消息返回的控制信道传输地址打开Endpoint 2的控制信道。

A4) 之后开始交换H.245消息：

A4a)    端设备直接交换TerminalCapabilitySet消息以确定H.245版本号。

A4b)    使用H.245消息进行主从判定。判定后的主MC发一个MCLocationIndication消息给其它端设备。

A4c) 主MC发terminalNumberAssign消息给其它端设备。

A4d) 能力交换后发送方打开逻辑信道，之后发一条h2250MaximumSkewIndication消息表示音视频对的关系。

4.1.3.2 直接端设备呼叫信令 – 会议邀请

邀请有两种形式。第一，含有主控MC的端设备提出邀请；第二，不含有主MC的端设备提出邀请。

1)    点对点会议建立后，含主控MC的端设备（Endpoint 2)邀请第三方加入会议，过程如下：

    B1)    Endpoint 2发Setup消息给Endpoint 3，消息中含参数CID   N和conferenceGoal   invite。

    B2)    Endpoint 3有以下选择：

    B2a)    如果接受邀请，回一条Connect消息给Endpoint 2，含参数CID   N。.

    B2b)    如果拒绝邀请，回Release Complete消息标明destinationBusy给Endpoint 2。

    B2c)    如果它在另一会议中CID   M，可以向Endpoint 2发送Facility消息表明routeCallToMC，邀请其加入会议CID   M，消息中包含该会议MC的端设备的呼叫信令信道传输地址。

    B2d)    如果收到的CID和它正参加的会议一致，它必须发送Release Complete消息拒绝，并表示它已经在会议中。

    B3)    如果Endpoint 3接受邀请， Endpoint 2用收到的Connect消息内带的控制信道传输地址打开对Endpoint 3的控制信道。

    B4)    之后交换H.245消息：

    C1)    MC和Endpoint 3之间进行TerminalCapabilitySet消息互换。

    C2)    H.245主从判定过程，因为Endpoint 2已经是主控MC，它可以发MCLocationIndication给 Endpoint 3。

    C3)    MC此时必须发multipointConference给所有三个端设备。

    C4)    MC可以发terminalNumberAssign消息给Endpoint 3。

    C5)    一个端设备可以通过发送消息terminalListRequest从MC查询会议中所有其它终端列表，MC回应消息为terminalListResponse。

    C6)    当新端设备Endpoint 4加入会议后，MC向其发送terminalNumberAssign消息，同时发消息terminalJoinedConference通知会议中其它端设备。

    C7)    当一个端设备离开会议时，MC发送terminalLeftConference通知其它端设备。

    C8)    MC必须发communicationModeCommand消息给会议中所有端设备。

    C9)    如果和communicationModeCommand 消息中包括的消息不一致，Endpoint 1和Endpoint 2 需要关闭它们在点对点会议中打开的逻辑信道。

    C10)    此时打开MC和端设备之间的逻辑信道。

Figure 27/H.323 – MC invite signalling

2) 点对点会议建立后，不含主控MC的端设备（Endpoint 1)邀请第三方加入会议，过程如下：

  发送Setup消息给MC (Endpoint 2)，消息中含新的CRV，以及Endpoint 3的传输地址，CID  N, conferenceGoal  invite。表示其打算邀请Endpoint 3。参见图28.

  发送Setup消息给Endpoint 3，消息中CID  N， conferenceGoal  invite。

  呼叫Endpoint 3过程中, Endpoint 2必须将Endpoint 3返回的呼叫信令消息，包括Connect转发给Endpoint 1。

  对于邀请的处理和前面相同。

  和Endpoint 3呼叫释放完成后，Endpoint 2必须发一条Release Complete消息给Endpoint 1。

  如果Endpoint 3接收邀请，Endpoint 2使用Connect消息中附带的控制信道传输地址打开和Endpoint 3之间的控制信道。

  之后按照C1至C10过程交换H.245消息。

Figure 28/H.323 – Non-MC invite signalling

4.1.3.3 直接端设备呼叫信令 – 会议加入

此时存在两种情况。第一种是一个端设备呼叫含有主控MC的端设备申请加入，第二种是呼叫不含主控MC的端设备。

按照A1)至A4)过程建立一个点对点会议后，Endpoint 3呼叫含有主控MC的端设备邀请加入，该过程如下：

B1)    Endpoint 3发送Setup消息给Endpoint 2，消息中CID   N，conferenceGoal   join。参见图29。

B2)    如果CID和该MC中一个会议的CID一致, Endpoint 2 (MC) 有下列选择：

B2a)    如果同意，返回Connect消息，消息中CID   N。

B2b)    如果不同意，返回Release Complete消息，标明destinationBusy。

B3)    如果CID和该MC中所有CID不一致，返回Release Complete，标明CID不存在。

B4)    如果同意，Endpoint 2打开Endpoint 3的控制信道。

B5)    按照过程C1)至C10)交换H.245消息。

Figure 29/H.323 – MC join signalling

点对点会议创建后，Endpoint向一个不含主控MC的端设备Endpoint 1请求加入。此时过程如下：

B1)    Endpoint 3发送Setup消息给Endpoint 1，消息中CID   N，conferenceGoal   join。参见图30。 

B2)    Endpoint 1返回消息Facility标明routeCallToMC，消息含有Endpoint 2(含主控MC)的呼叫信令传输地址和CID   N。

B3)    Endpoint 3发送Setup给Endpoint 2(MC)，消息中CID   N，conferenceGoal   join。过程和前述一致。

Figure 30/H.323 – Non-MC join signalling

4.1.3.4 网守路由呼叫信令 – 会议创建

请参见规范。

4.1.3.4 网守路由呼叫信令 – 会议邀请

请参见规范。

Figure 31/H.323 – Gatekeeper routed invite signalling

4.1.3.4 网守路由呼叫信令 – 会议加入

请参见规范。

Figure 32/H.323 – Gatekeeper routed join signalling

4.1.4 多点层叠

MC层叠时，呼叫必须在两个MC之间建立。呼叫建立并打开H.245控制信道后，主控MC（active MC）可以使另一MC成为主控，此时必须通过H.245消息RemoteMC。下表为收到RemoteMC 消息必须作出的处理：

从MC必须以主控MC创建会议时的CID表示层叠会议。

从MC必须响应主MC的communicationsModeCommand消息，它必须将这些消息转发到其直连端设备。从MC可能从直连端设备收到requestMode消息，且必须转发给主控MC。从MC不能发送communicationsModeCommand消息给主控MC。

每个MC负责打开和它直连的端设备的逻辑信道。

终端编号和控制过程按照规范H.243标准。

收到主MC发送RemoteMC消息标明deActivate时，从MC必须将会议中所有直连端设备移出会议。

4.5阶段E – 呼叫终止

每个端设备可以以下步骤中止一个呼叫。

1) 在发送完一幅完整图像后，停止发送视频，之后关闭视频逻辑信道。

2)    停止发送数据，之后关闭数据信道。

3)    停止发送音频，之后关闭音频信道。

4)    发送H.245控制消息endSessionCommand，通知对端它要关闭呼叫，之后停止H.245消息发送。

5)    等待收到对端endSessionCommand消息后，关闭H.245控制。

6)    如果呼叫信令信道仍然打开，必须发送Release Complete消息关闭。

7)    必须按照下面定义的过程清除呼叫。

终止一个呼叫并不一定终止一个会议。一个会议可以显式使用H.245消息dropConference终止。此时，所有端设备需等待MC按照上述过程终止呼叫。

4.5.1 清除呼叫（无网守）

在没有网守的情况下，上述1)至6)步骤后呼叫就终止了。

4.5.2 清除呼叫（有网守）

在有网守的情况下，1)至6)步骤后还需完成下列步骤（图33）：

Figure 33/H.323 – Endpoint initiated call clearing

4.5.3 网守发起清除呼叫

网守可以发DRQ消息主动清除呼叫（图34）。此时端设备收到后应立即按照步骤1)至6)进行操作，之后回复DCF消息。对端端设备一收到endSessionCommand消息后，必须按照上述过程进行操作。

多点会议中，网守必须发DRQ给会议中所有端设备以终止整个会议。

Figure 34/H.323 – Gatekeeper initiated call clearing