MEGACO协议格式文档

*******************************************************************************说明：本文档是对MEGOCO协议中相关协议格式的集中介绍，其中各个协议字段的具体取值可以在相应的RFC中找到。

本文档可以结合MEGACO协议解码解释库中的源代码一起使用。

参考资料：涉及到的RFC在目录中列出作者：李永亮修改日期：2003-12-1 *******************************************************************************MEGACO协议（RFC3015）======================================================================H.248协议，也叫MEGACO协议，是软交换设备或MGC与MG之间的一种媒体网关控制协议，它是一项作为ITU-T与IETF合作结果的新标准。

早期的媒体网关控制协议主要有两个，一个是由Level3等公司提出的IPDC协议，另一个是由Bellcore等公司提出的SGCP协议。

到1998年11月，Bellcore、CISCO等公司将IPDC和SGCP协议融合为MGCP协议，并将MGCP协议正式提交到IETF和ETSI TIPHON项目组。

与此同时，Lucent、AGCS等公司也提出了一种新的媒体网关控制协议MDCP协议。

经过讨论，IETF成立了MEGACO工作组，将MEGACO和MDCP协议融合为MEGACO协议，并将它确定为MGC和MG之间的标准控制协议。

H.248协议是语音、传真和多媒体信号在公共交换电话网与新兴IP网络之间进行交换成为可能。

H.248协议不涉及IP电话体系结构，只涉及网关分解问题，因而它不仅可以用于H.323 IP电话系统，也可以用于SIP的电话系统。

与MGCP相比，H.248可以支持更多类型的接入技术并支持终端的移动性，除此之外，H.248最显著之处在于比MGCP允许的规模更大，并且H.248通过增加许多Package的定义来对协议功能进行扩展，因而，H.248比MGCP更具灵活性，已逐渐取代MGCP发展成为媒体网关控制协议的标准。

一、连接模型1.终结点（Termination）终结点是MG上的一个逻辑实体，它发送或接收一个或多个数据流。

在一个多媒体会议中，一个终结点可以支持多种媒体，并且发送或者接收多个媒体流。

在终结点中，封装了媒体流参数、MODEM和承载能力参数。

媒体网关在创建终结点的时候，赋予终结点一个唯一的标识TerminationID来标识终结点。

终结点分为半永久终结点和临时性终结点两种。

半永久终结点可以代表物理实体，例如一个TDM信道，此时，只要媒体网关中存在这个信道，这个终结点就存在。

临时性终结点也可以代表临时性的信息流，例如RTP流，此时，只有当媒体网关使用这些信息流时，这个终结点才存在。

临时性终结点可以由Add命令来创建和Subtract命令来删除。

而半永久性终结点则不同，当使用Add命令像一个关联添加物理终结点时，这个物理终结点将转移到空关联中。

终结点可以特性来进行描述，每个特性由一个PropertyID标识，由这些特性可以组成了一系列描述符。

大部分特性由缺省值，当创建一个终结点时，通常这些特性被赋予缺省值，除非媒体网关控制器设定的值不同于缺省值。

如果要改变终结点特性的缺省值，对于物理终结点而言，终结点在空关联中时，可以通过重新设置处于空关联中的终结点特性缺省值。

当终结点返回到空关联中，它的特性值将被设置为这个新的缺省值。

当将一个终结点添加到一个关联之中去时，通过适当的描述符作为Add命令的参数来对一个可读写的特性值进行设置。

在Add命令之中未设置特性值的将保持它们的缺省值。

类似的，通过使用Modify命令，可以改变一个关联之中的终结点的特性值。

Modify命令之中未设置的特性值将保持它们以前的值。

当使用Move命令，将一个终结点从一个关联转移到另一个关联之中的时候，特性值也已能改变。

在这些情况下，描述符将作为命令的输出参数返回。

H.248的描述符共有19个，各描述符的含义如下表所示。

描述符的功能2.关联关联表明了某些终结点之间的连接关系。

有一种特殊类型的关联，即空关联（Null Context），它是不与其它任何终结点相联系的所有终结点的集合。

如果在这个联系中有超过两个终结点，那么关联就对系统的拓扑结构和媒体混合和／或交换参数进行描述。

关联的属性包括以下几个：i．ContextID（关联标识符）。

ii．拓扑（Topology）：用于描述一个关联中终结点之间的媒体流方向。

相比而言，终结点的模式（Send/Receive）描述的是媒体流在ＭＧ的入口和出口处的流向。

iii．关联优先级（Priority）：用于告知ＭＧ在处理关联时的先后次序。

iv．紧急呼叫的标识符（Indicator for Emergency Call）：当使用紧急呼叫标识符时，ＭＧ优先处理此类呼叫。

二、包（Package）不同类型的网关可以支持不同类型的终结点。

H.248协议通过允许终结点具有可选的特性（Property）、事件（Event）、信号（Signal）和统计（Statistic）来实现不同类型的终结点。

为了实现ＭＧ和ＭＧＣ之间的互操作，H.248协议将这些可选项组合成包。

ＭＧＣ可以通过审计终结点来确定ＭＧ实现了哪一种类型的包。

包的定义由特性（Property）、事件（Event）、信号（Signal）和统计（Statistic）组成，这些项分别由标识符(ID)进行标识。

ＭＧ为了实现某种类型的包，则必须支持此包中所有的特性、事件、信号、统计以及信号和事件的所有参数类型。

目前，Ｈ.248定义了以下基本包：１．通用包Generic２．基本根包Base Root Package３．音信号发生包Tone Generator Package４．音信号检测包Tone Detection Package５．基本DTMF生成包Basic DTMF Generator Package６．DTMF探测包DTMF detection Package７．呼叫进展音信号生成包Call Progress Tones Generator Package８．呼叫进程音信号检测包Call Progress Tones Detection Package９．模拟线路管理包Analog Line Supervision Package１０．基本导通包Basic Continuity Package１１．网络包Network Package１２．RTP包RTP Package１３．时分复用电路包TDM Circuit Package三、命令H.248协议使用命令对连接模型中的逻辑实体进行管理，命令提供了对关联和终结点特性进行完全控制的机制。

大部分命令都是由ＭＧＣ作为命令的起始者发起，ＭＧ作为命令响应者接收，从而实现ＭＧＣ对ＭＧ的控制的。

但是Notify和ServiceChange命令例外。

Notify 命令是由ＭＧ发送给ＭＧＣ的，而ServiceChange既可以由ＭＧ发起，也可以由ＭＧＣ发起。

H.248协议中定义了八个命令，它们的功能如下：命令四、描述符命令的参数定义为描述符。

由名称和一些参数组成的参数值。

但不相同的命令可包含相同的描述符。

本部分对这些描述符进行了详细说明。

描述符也可以作为命令的输出项。

描述符的文本格式如下所示：DescriptorName = < someID > { parm = value, parm = value … }描述符功能介绍见第一部分。

五、事务交互ＭＧ和ＭＧＣ之间的一组命令组成了事务交互。

事务交互可以由TransactionID来标识，事务交互由一个或多个动作组成，而一个动作又由在一个关联中使用的一系列命令组成。

因此，可以用ContextID来标识动作。

六、传输H.248协议的传输机制应当能够支持在ＭＧ和ＭＧＣ之间的事务处理的可靠传输。

如果是在ＩＰ上传输本协议，ＭＧＣ应当实现ＴＣＰ和ＵＤＰ／ＡＬＦ，ＭＧ应当实现ＴＣＰ或ＵＤＰ／ＡＬＦ，或者两者同时支持。

ＭＧＣ应当向ＭＧ提供一个主要ＭＧＣ的名字或者地址（如ＤＮＳ名字或者ＩＰ地址），同时还可以提供零个或多个备用的ＭＧＣ的名字或者地址，以便ＭＧ能够向ＭＧＣ发送消息。

当采用TCP或者UDP用作协议的传输层时，如果无法获知将初始的ServiceChange请求发送到哪个端口，那么就应当将这个请求发送到缺省端口上。

无论是TCP还是UDP，文本编码的命令缺省端口的端口号是2944，二进制编码的命令缺省端口的端口号为2945。

MGC 接收到来自MG的包含ServiceChange的请求消息后，应当能够从中判断出MG的地址。

同时，MG和MGC都可以在ServiceChangeAddress参数中提供一个地址，以便后续的事务交互请求都发送到这个地址。

但是，所有的对请求的响应（包括对初始的ServiceChange请求的响应）必须发送给相应的请求的源地址。

七、安全1.保护协议连接为了防止未经授权的实体利用本协议建立非法呼叫，或者干涉合法呼叫，需对H.248协议的传输建立安全机制。

当在IP网络上传输本协议，使用IPSec[RFC2401]到[RFC2422]对H.248协议的传输进行保护。

认证头（AH）对在MG和MGC之间传输的消息提供数据源认证、完整性保护和抗重发保护。

AH的实现应当遵照RFC2402的第5部分有关规定。

封装安全净荷（ESP）则对在MG和MGC之间传输的消息提供机密性保护，ESP的实现应当遵照RFC2406的第5部分的有关规定。

同时，H.248协议推荐使用密钥交换协议（IKE），以为MG和MGC提供协商密钥的机制。

2.过渡性AH方案如果底层协议不支持IPSec，应当在H.248协议头之中定义AH头来实现对协议连接的保护。

此时，这个AH头中的各个域的定义在RFC2402中定义的SPI，SEQUENCE NUMBER 和DA TA域的定义一致。

除了对ICV（Integerity Check V alue，集成校验值）的计算有所不同外，AH头的语法与RFC2402中传输模式中定义的语法完全相同。

在Interim AH方案中，对ICV的计算是基于32比特的源IP地址、32比特的目的IP地址和16比特的UDP或TCP 端口号进行的。

过渡性AH的实现应当遵照RFC2402的第五部分有关规定。

3.保护媒体连接H.248协议支持MGC向MG提供会话密钥，用来对音频消息进行加密。