H. 225.0 呼叫信令消息

时间：2021-08-30 10:18 作者：admin 分享到：

H.255.0基本呼叫控制消息取自于Q.931和Q.932消息。由于它不承担连接控制的任务，因此许多消息失去意义，不在H.225.0中出现。对于Q.931消息的精简原则是：

．呼叫信息阶段消息全部是关于呼叫中B信道的暂停和恢复，应于去除。

．呼叫清除的3消息过程缩简为只保留ReleaseComplete一个消息。

．呼叫清除消息中的重启动消息仅与B信道相关，应于去除。

．呼叫建立消息中的ConnectAcknowledge消息可去除。
对于Q.932消息的精简原则是：

．拥塞控制消息是针对B信道而言的，可去除。

．专用消息可去除。

．保留具有通用意义的Facility和UserInformation消息，它们可增强基本呼叫控制的功能。

由此得，H.225.0呼叫信令消息如表5.7所示。

表5.7 H.225.0呼叫信令消息

消息类别	消息名	消息性质
呼叫建立消息	Setup Alerting Connect Setup Acknowledge CallProceeding Progress	M M M 0 0 0
呼叫清除	Release Complete	M
其它消息	Status Status inguiry Information Notify	M o o 0
Q.932 消息	Facility User Information	M 0

注：M一必备消息 O－任选消息

相应地，H.225.0 的信息单元也缩简为16个。其中，从Q.931继承14个，从Q.932继承2个，可参见表5.4和表5.6。

下面对几个信息单元的使用作简要说明。

(1)承载能力(BC)

这是Q.931中最为重要的必备信息单元，它描述了对承载连接的要求。在H.225.0中，虽然它也是Setup消息的必备信息单元，但已不那么重要。对于两个H.323终端之间的呼叫，接收方可以不解释此单元。若用于呼叫无关信令的Setup消息中，其字段有特殊含义，将在补充业务小节中进一步说明。该信息单元在H.225.0中的使用规定是：

．信息传送能力：若主叫为ISDN端点，则网关应将此字段前传，使H.323 被叫终端知道呼叫的性质（话音／数据／视频），有助于确定带宽。若主叫是H.323端点，则可用此字段表示是否要进行可视电话呼叫。如要，则可置为“不受限数字信息”；如仅为话音呼叫，则置为＂话音”或“3.lkHz音频＂。

．多速率系数：如果信息传送速率是多速率，必有此字段。如果主叫是ISDN端点，网关透明传递该字段值。如果主叫是H.323端点，可用来指示该呼叫在SCN侧所需的带宽，网关据此生成SCN侧的BC。

．第1层协议：若为话音呼叫，应为G.711；若为H.323可视电话呼叫，应为H.221/H.242。

．第2层和第3层协议：对于互通无意义。

(2)主叫和被叫号码

如果编号计划标识置为“专用编号计划”，且主叫为H.323终端（由PBN发起），则表示Setup消息中未含E.164地址，呼叫应按用户—用户信息单元中的别名地址来选路。

(3)原因

原因一般是任选信息单元，但在ReleaseComplete消息中则是必备单元。在H.225.0中，释放原因可以由“原因”表示，也可以由“用户—用户“信息单元中的＂释放理由”表示，二者只能取一。但是二者的表达不相同，“因原“信息单元直接取自于Q.931 ,“释放理由”则是针对PBN而言的原因。

对于－GW－电话呼叫，若代首先释放，网关收到的ReleaseComplete消息中的释放原因是由“释放理由”表述的，它必须转换为Q.931的“原因“值，才能送往SCN侧。其映射关系如表5.8所示。

表5.8释放完成理由至原因信息单元的映射

如果是SCN侧用户先释放，网关不必作映射，只需将原因值传给H.323终端即可，因为后者要求具有解码原因信息单元的能力。

(4)用户一用户信息单元

UUIE是H.225.0呼叫信令中最为重要的信息单元。它不只是传送常规的端到端用户数据，更为重要的是由此传送H.323 特定的呼叫控制信息。正是这些特定信息构成了H.323 系统呼叫信令的核心内容，体现了系统的呼叫信令能力。该信息单元是Setup、Alerting、CallProceeding、Connect、ReleaseComplete、Facility、User血ormation等主要消息的必备IE，这些消息中的UUIE定义实际上是H.225.0信令消息设计的主要内容。

UUIE的结构如图5.18所示，和Q.932 定义的不同之处在于：

．“用户一用户信息内容长度”字段由1个字节增加为2个字节，即UUIE的最大长度由原来的131个字节增加为64k字节。

图5.18 UUIE结构

．协议鉴别语改为ASN.1，即用户信息字段的格式由原来的IA5字符（相当于ASCl1字符）改为通用的ASN.l描述。

．用户信息字段由两部分组成。主体部分为h323-UU-pdu,就是各相关消息中的UUIE内容，即H323特定的信令信息；任选部分为真正在终端之间传送的用户数据，仍为IA5字符串，最大长度仍为131字节，相当于原来Q.932定义的用户—用户信息，但封装在新的以ASN.1描述的UUIE数据结构中，作为其数据序列中的一个元素，称为user'-data。

H.225.0定义了每个相关消息UUIE中的h323-UU-pdu的内容。例如，Connect消息的UUIE包含如下内容：

．协议标识：由被叫端点设定为该端点支持的H.225协议版本号。

．H.245地址：被叫端点或网闸的H.245控制信道的运输层地址，主叫侧藉此就可建立至被叫或被叫网闸的H.245控制信道，进而建立所需的媒体信道。这是H.225.0呼叫建立要达到的最主要的目的。该参数也可以由Alerting或CallProceeding消息的UUIE传送。

．目的地信息：指示端点类型，使主叫确定该呼叫是否涉及网关。

．会议标识：即Setup消息中所带的会议标识。

．呼叫标识：由主叫端点设定，回送给主叫。

．H.245安全模式：如果Setup消息中含H.245安全能力，指明主叫可使用的各种H.245信道安全模式，则被叫应回送选定的安全模式。此参数也可在Alerting或CallProceeding消息中回送。

由此可见，UUIE中定义的内容都是H.323系统呼叫信令必需传送的信息，这些信息无法用原来的Q.931/Q.932的信息单元来传送，因此就用UUIE来补充。其设计思想是不再定义许多新的信息单元，只是在原来Q.931/Q.932的基础上增加1个UUIE，且UUIE采用通用的、内容可扩充的ASN.1形式，这样使协议设计简化，和传统的协议有很好的继承性。

仔细分析各个信令过程的信息流，就可理解每个消息中UUIE内容的定义依据，在此不再逐一列举说明。

(5)性能

在H.225.0基本呼叫控制信令中，性能(Facility）消息用来指示呼叫重定向(callredirection)，包括3种情况：呼叫前转；呼叫转向MC；强制将呼叫控制转向网闸。协议规定由Facility消息中的“用户—用户“信息单元(Facility-UUIE)传送这一指示信息，而不是像Q.932那样用“性能“信息单元来传送。此时，“性能“单元长度置零，表示此单元为空。

Facility-UUIE包含如下内容：

．协议标识：为主叫端点设定的所支持的H.225版本号。

．替换地址：指示主叫方应将呼叫转向该运输层地址。如果有此字段，就不再需要“替换别名地址”。

．替换别名地址：可用于呼叫转向的别名地址。有此字段，就不再需要“替换地址”。

．会议标识：唯一标识会议。

．理由：规定了如下几种理由：

—呼叫选路至网闸；

—呼叫前转；

—呼叫选路至MC;

—未定义的理由；

．呼叫标识：呼叫全局标识，由主叫端点设定。

．附加地址：呼叫重定向通过网关时有用的附加别名地址信息。如果要指示呼叫前转，则“性能“信单息元为空，Facility-UUIE的＂替换地址”或“替换别名地址”指示呼叫前转目的地，“理由“置为呼叫前转。

如果主叫端点要加入会议，而被叫端点并无MC功能，则该呼叫需前转到具有MC的另一端点，此时Facility消息的“性能“单元也置空，Facility-UUIE的“会议标识”指示要加入的会议，“理由“置为呼叫选路至MC。

如果要指示主叫端点通过被叫端点的归属网闸和被叫端点建立呼叫信令关系，则“性能“单元也置空，Facility-UUIE的＂替换地址”指示网闸的运输层地址，“理由“置为呼叫选路至网闸。

上述UUIE的意义在下面讨论具体信令过程中将会更加清楚。Facility消息中的“性能“信息单元的使用有待进一步研究。

虽然H.225.0 呼叫信令模型取自于Q.931，但不同之处在于，Q.931用于ISDNUNI，两端分别是用户和网络，一般是不对称应用；而在H.323系统中，呼叫信令是对称应用。对于H.225.0来说，Q.931/Q.932消息和信息单元有必备、任选和禁用三类，除了禁用类不在协议中定义外，规定H.225.0端点对必备消息和信息单元必须能正确处理；对于任选消息，如果不能辨认则予丢弃，应不会影响互操作性，但要回送Status消息指示收到了未知消息；对于消息中的任选信息单元，如果不能辨认也予丢弃，但不需要回送任何响应。

最后说明一下网关对呼叫信令消息的处理原则。此处假设网关和SCN相连，SCN侧的信令协议是Q.931。

对于来自H.323侧的H.225.0呼叫信令，网关处理原则是：

·收到Setup消息应启动SCN侧的呼叫建立过程。

·收到ReleaseComplete消息应启动SCN侧的拆线和呼叫释放过程。

·收到CallProceeding消息应转发至SCN侧。但是如果在此之前，SCN侧已发送过CallProceeding，则此消息不再转发。

·收到Connect消息应转发至SCN侧。

·收到网关不子处理的补充业务相关消息，应转发至SCN 侧。

·如果由于信令互通需要，要向SCN侧发送H.225.0禁用的Q.931消息，由网关负责生成这些消息。
消息中的信息单元的转换原则是：

．和连接相关的信息单元（如CRV)的内容，要根据SCN侧协议要求进行适配转换。

．如果由于信令互通需要，要向SCN侧发送H.323侧不用的信息单元，由网关负责生成这些单元。

．其它信息单元的翻译根据SCN侧协议和信令过程的要求进行，其前提是能保证互操作性。不另行制定映射标准，可由厂商自行确定。

．对于用户一用户信息单元，仅将其中真正的用户数据部分转发至SCN侧，但应按照Q.932标准重新编码。