NGN网络测试仪H.248解码模块的设计与实现

程方，王洋

（重庆邮电大学 通信网与测试技术重点试验室 重庆 400065）

0 引言

H.248协议，也叫媒体网关控制协议(Media Gateway Control protocol，Megaco)， 此 协 议 是ITU-T与IETF合作的标准，被国际软交换协会ISC指定为软交换设备与媒体网关之间的标准通信协议。

在NGN网络中，基于呼叫控制与承载分离[1]的思想，传统IP电话网关被物理地分成媒体网关(Media Gateway，MG)和媒体网关控制器(Media Gateway Controller，MGC)两个单独的网络实体，MG负责承载业务，MGC负责呼叫控制。H.248协议就是MG与MGC之间的一种控制协议，它定义了MGC对MG的控制方式和标准的基于IP网络的通信格式。在软交换系统中，软交换设备完成MGC的功能，通过H.248协议实现对MG的控制，最终完成业务的承载[2]。

作为NGN网络的核心协议，其监测解码分析对于网络性能的评定以及网络进一步优化和完善至关重要。因此为了获得H.248连接模型的关键参数，必须对该协议数据实现正确的解码，从而在监测仪表上实现网络中的呼叫重现。文章首先简要介绍H.248协议的连接模型和消息格式，然后根据H.248两种不同的编码方式设计并实现了H.248协议的解码。

1 H.248协议简介

1.1 H.248的协议连接模型

协议的连接模型主要描述媒体网关中的逻辑实体，这些逻辑实体由媒体网关控制器控制。这个连接模型中的主要的抽象概念是终端（Termination）和关联（Context）。在H.248协议[3]定义的连接模型中，包括关联和终端两个实体。一个关联中至少要包含一个终端，否则此关联将被删除。同时一个终端在任一时刻也只能属于一个关联。

终端（Termination）是MG 上的一个逻辑实体，它可能是物理实体（物理信道）或是临时性的RTP流，在逻辑概念上终端就是一次通信的发送端或接收端。关联（Context）是一些终端具相互联系而形成的结合体，它可以描述拓扑结构，及媒体混合和交换的参数。

1.2 H.248的消息结构

H.248协议有文本编码和二进制编码两种编码方式，但不管哪种编码方式H.248消息都有相同的结构，一个H.248消息的结构如图1所示。

图1 H.248消息结构

消息从消息头（Header）开始，一条消息包含若干个事务（Transaction），事务是MGC和MG之间的一组命令组成，有请求和响应两种类型，一对请求和响应由相同的TransactionID来进行标识；一个事务又由一个或者多个动作（Action）组成，每个动作中包含了H.248消息的主要内容——命令。命令实现了对关联和终端属性的控制，包括指定终端报告检测到的事件，通知终端使用什么信号和动作，以及指定关联的拓扑结构等功能。对H.248数据的解码，目的就是取出各字段的关键数据。

2 H.248协议解码设计与实现

2.1 文本编码方式的解码设计思想与实现

采用文本方式编码的H.248协议也叫Megaco协议，它采用ABNF[4]语法规范描述的文本格式进行编码，一条Megaco消息如下所示：

MEGACO/1 [10.35.2.101]:2944

T=452422{C=299{

N=A19{

OE=385879552{al/on}}}}

根据Megaco协议的ABNF语法规范解析上面的消息，结果如下所示：

MegacopToken: MEGACO

// 指示为Megaco协议

Version: 1

// 版本为1

mId: [10.35.2.101]:2944

// MG的IP地址和端口号分别为10.35.2.101:2944

TransToken: T

// 事务请求

TransactionID: 452422

// 事务ID为:452422

CtxToken: C

// 关联指示

ContextID: 299

// 关联ID为299

NotifyToken: N

// 通知命令

TerminationID: A19

// 终结点ID为A19

ObservedEventsToken: OE

// 观测到的事件描述符

RequestID: 385879552

// 请求ID为385879552

pkgdName: al/on

// 指示为模拟线包中的挂机事件

在传统协议解析方法中，主要采用字符串查找匹配方式，需要逐一的取出消息中每个域值，和协议规范进行匹配，判断是否符合规范。在解析长度不定的域时，需要查找该域的结束标志，再取出该域的值。这些操作导致代码实现很复杂，协议解析效率比较低下。因此，我们提出了采用正则表达式解析Megaco协议的方法，该方法相对于传统的字符串查找匹配方式，协议解析速度有较大的提高。

正则表达（regular expression）就是用一个“字符串”来描述一个特征，然后去验证另一个“字符串”是否符合这个特征。在本文中，我们利用正则表达式引擎DEELX的三个关键CRegexpT模板类、MatchResult 类、CContext 类，来分别完成编译正则表达式和进行匹配替换、记录匹配结果、记录所匹配到的字符串及各个捕获组的位置信息。

利用这一引擎，我们就可以根据Megaco的消息结构从外向内进行解码。以协议识别函数为例，首先调用构造函数定义一个CregexpT对象regexp，传入的正则表达式为(?:MEGACO|!)/d{1,2}，其含义表示字符串中含有“MEGACO/”或“!/”，并且后面紧跟最多二位，至少一位的数字，其中(?:MEGACO|!)表示非捕获组，和(MEGACO|!)表示的普通分组相比较；接着调用CRegexpT 类的Match方法，传入协议数据的头指针，查找Megaco消息，并返回匹配结果MatchResult对象result；最后通过MatchResult类的IsMatched方法来判断是否匹配成功，如果返回0，表示匹配失败，该条消息不是Megaco消息，否则表示匹配成功，该条消息是Megaco消息。

采用这样的方法对采集到的Megaco 消息从头部开始根据Megaco协议的格式和消息结构逐一进行查询，就能获取每个关键字的字段名和他们相应的字段值。

2.2 二进制编码方式的解码设计思想与实现

二进制方式编码的H.248协议，采用了ASN.1语法规范的BER[5]（基本编码规则）编码规则，其基本编码结构有如下两种。

图2 不含内容结束八位位组的BER编码结构

图3 含内容结束八位位组的BER编码结构

在BER编码中，数据值的编码主要由标识符八位位组、长度八位位组、内容八位位组、内容结束八位位组等四种成分组成。其中，内容结束八位位组的有无区别了上述的两种基本编码结构。

标识符八位位组用于对数据值类型的ASN.1标签（类和编号）进行编码；长度八位位组标识了内容八位位组的位组数；内容八位位组则由0个、1个或多个八位位组组成，其编码遵循ASN.1中的定义；内容结束八位位组为可选类型，根据内容八位位组的指示出现与否。这几种类型的八位位组构成了BER的TLV三元组形式，这种编码形式的最大特点就是在内容八位位组中可能包含了下一层次的TLV结构，直到最后的一层TLV三元组结束为止。

根据TLV三元组结构的这种特点，我们设计了H.248解码的算法流程如图4所示。

图4 H.248协议解码流程图

在解码过程中，我们首先要对数据的第一个字节即整个TLV数据块的第一个标签八位位组进行解析，通过判断其是否为0x30来识别整个数据块是否是H.248协议数据；协议识别函数同时还必须获取第一个长度八位位组中指示的整个数据块长度，并将指针指向第一个内嵌的TLV三元组的开头；整个解码流程采取逐层解包封的思想达到从外向内获取每个协议关键数据的方法，符合H.248协议的消息结构。

3 软件实测运行结果与分析

通过对某运营商关口局接口现场实测，采集到大量H.248协议数据，下面是其中的一条H.248消息的原始数据：

30 64 a1 62 80 01 01 a1 0c a0 0a 80 04 0a 3b 22 04 81 02 0b 80 a2 4f a1 4d a0 4b 80 04 1e 05 aa 46 a1 43 30 41 80 05 00 ff ff ff fe a3 38 30 36 a0 34 a0 32 a0 0e 30 0c a0 00 81 08 00 00 00 00 40 00 91 54 a1 20 a0 1e a1 1c a0 1a a0 18 80 01 02 81 01 00 82 01 00 a3 0d 30 0b 80 04 00 0d 00 08 a1 03 04 01 00

它的解码结果如图5所示。

在解码结果中可以看出，这是一条包含了一个事务请求的H.248消息，消息中只有一个指定了终端ID的Add命令，并在命令的描述符中规定了本地媒体流的流模式，并指示媒体网关取消回铃控制。它的解码结果如图5所示。

图5 H.248协议解码结果

4 结论

H.248协议由于其编码方式的特殊性，在设计中我们必须能对2种不同的编码方式都提供解析功能。本文通过正则表达匹配法实现了对文本方式编码的Megaco协议的解码，又通过“逐层拆封”的算法思想实现了二进制编码方式下 “TLV结构”的H.248协议数据的解码。为下一步实现呼叫过程合成提供了各种呼叫的关键数据和统计指标，全面有效的实现了对H.248协议数据的监测。通过对解码模块进行的单元测试和软件集成后的现场测试，充分证明了解码方案的可行性和有效性，各项指标均符合协议监测规范[6]。

[1] 高艳玲, 马玉霞. 软交换技术及应用浅析[J]. 计算机与网络. 2006（6）：32-35.

[2] YD/T 1309-2004中华人民共和国通信行业标准, 与承载无关的呼叫承载控制规范[S].IETF RFC3525(2003), Gateway Control Protocol[S].

[3] ITU-T Recommendation H.248.1(2005) Gateway control protocol[S].

[4] IETF RFC 2234 (1997), Augmented BNF for Syntax Specifications: ABNF [S].

[5] ITU-T Recommendation X.690 (2002) ISO/IEC 8825-1:2002 ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules(CER) and Distinguished Encoding Rules (DER)[S].

[6] YD/T1594-2007 YD/T 1594-2007 2GHz TDSCDMA/WCDMA数字蜂窝移动通信网移动软交换服务器与媒体网关间的Mc接口测试方法(第二阶段).

[7] YD/T 1593-2007 2GHz TD-SCDMA/WCDMA数字蜂窝移动通信网设备 移动软交换服务器与媒体网关间的Mc接口技术要求（第二阶段）.

[8] YD/T 1292-2003,中华人民共和国通信行业标准：基于H.248的媒体网关控制协议技术要求 [S].