当前位置： >>
H248协议原理 V1[1].1
H248协议原理学习目标通过对本章的学习，您将了解：协议所定义的网络实体 协议中的命令 协议流程的分析222广东邮电职业技术学院内容提要H.248协议的整体概念H.248的组成 呼叫流程分析333广东邮电职业技术学院名词解释协议 Xiéyì [agree on]：共同计议；协商 [agreement； accord；concord]：经过谈判、协商而制定的共 同承认、共同遵守的文件444广东邮电职业技术学院历史背景基于H323体系的第一代IP电话 PSTN/ISDN GK GW媒体变换信令转换??功能扩展性不强：业务的 实现需要对复杂的网关实 体进行改造。 容量扩展性不强：网关功 能实体太过复杂，对大规 模用户的使用支持不好。H323 Terminal呼叫控制555广东邮电职业技术学院网关分解功能模型ControlSoftswitchBICC/SIP-TSIGTRANH.248EdgeRTP/RTCPSG MGISUP/MTPTDM Trunk666广东邮电职业技术学院H248（Megaco）的历史777广东邮电职业技术学院几个问题H248协议发生在谁和谁之间？ H248协议起什么作用？ 同类似的其他协议相比，H248协议有些什么特点？888广东邮电职业技术学院解答第一个问题H248协议发生在谁和谁之间？Service ControlSCP Database AAA Server Application Server Policy ServerSoftswit chSoftswit chCoreCore Packet NetworkH323 GWAccessSS7 Netwo rkSGTGAGNASIP PBX MSAG IAD WAGPSTN/ISD NBroadband AccessWireles s999广东邮电职业技术学院解答第二个问题H248协议起什么作用？ 它主要的作用就是将呼叫逻辑控制从媒体网关分 离出来，使媒体网关只保持媒体格式转换功能101010广东邮电职业技术学院解答第三个问题同其他网关分离协议相比，H248协议有些什么特 点？ASN.1和文本行两种编码方式 完全开放的扩展机制：包扩展机制。与MGCP的包扩 展机制相比，机制更开放，定义的包更多。 对多媒体业务和多方会议支持更好111111广东邮电职业技术学院内容提要H.248协议的整体概念H.248的组成呼叫流程分析121212广东邮电职业技术学院连接模型的引入H248协议的目的是对媒体网关的承载连接行为 进行控制和监视。为此，首要的问题就是对媒体 网关内部对象进行抽象和描述。那么，H248提出了网关的连接模型概念。131313广东邮电职业技术学院终端和关联域 1媒体网关Termination Termination Termination Termination Termination Termination Termination Termination Term. XContext. X终端关联域141414广东邮电职业技术学院终端和关联域 2终端（Termination）：概念：媒体流的源和宿。一个终端可以终结一个 或多 个媒体流。 半永久性终端：物理终端，例如IAD上的一个Z接口 临时性终端：一个信息流，例如一个RTP语音流。 Root终端：代表MG本身。关联域（Context）：概念：代表一组终端之间的相互关系。 Null Context：空关联域，代表尚未和其他终端关联的 终端，例如，空闲的用户线。151515广东邮电职业技术学院连接模型示意（呼叫等待）媒体网关媒体网关关联域 1T2 T1SCN 承载信道关联域 1T2 RTP流RTP流关联域 2T3SCN 承载信道关联域 2T1SCN承载信道T3SCN承载信道161616广东邮电职业技术学院关联域关联特性关联标识（ContextID）： Context 的标识； 拓扑结构（Topology）：媒体的流向 优先权（Priority）：提供关联的优先处理信息； 紧急呼叫的标识符：提供关联的紧急处理信息。171717广东邮电职业技术学院终端终端ID终端可用Termination ID进行标识，Termination ID由 MG分配。终端描述特性性质（Property）：服务状态、媒体信道属性等； 事件（Event）：例如摘机、挂机等； 信号（Signal）：例如拨号音、DTMF信号等； 统计（Statistics）：采集并上报给MGC的统计数据；181818广东邮电职业技术学院描述符描述符（Descriptor）概念：一种语法元素（数据结构），用来描述终端的 特性；H248V1共定义了19个描述语，可以分为7类。 终端状态和配备：TerminationState、Modem； 媒体流相关属性：Media、Stream、Local、Remote、 LocalControl、Multiplex； 事件相关特性：Event、DigitMap、EventBuffer、 ObservedEvents；191919广东邮电职业技术学院封包封包（Package）概念：一种终端特性描述的扩展机制，凡是未在基础 协议的描述语中定义的终端特性可以根据需要增补定 义相应的封包。 常用包举例：al（模拟线管理包）、cg（呼叫进程音发 生包）、dd（Dtmf检测包）、Au（高级放音包）；202020广东邮电职业技术学院H248 常见包名词介绍cg: call progress tone generate (呼叫进程包) al: analog line（模拟用户包） cg/dt----(dial tone)拨号音，cg/bt----(busy tone)忙 音，cg/wt----(warning tone)嗥鸣音 al/of----(offhook)摘机，al/on-----(onhook)挂机， al/fl-----(flashhook)叉簧 Dd/ce表示DTMF收号，mfd/cd表示脉冲收号212121广东邮电职业技术学院八个命令MGC MGAdd?MGC→MG， ?把一个终端加入到一个关联域中, ?如果context ID没有 指定就新建一个关联域222222广东邮电职业技术学院八个命令MGC MGAdd Modify?MGC→MG， ?修改终端属性，事件或者信号属性232323广东邮电职业技术学院八个命令MGC MGAdd Modify subtract?MGC→MG， ?从一个关联域中移出一个终端。 ?如果关联域中没有任 何终端则删除关联域242424广东邮电职业技术学院八个命令MGC MGAdd Modify subtract Move?MGC→MG，将一个终端从一个关联域中移到另一个关联域中252525广东邮电职业技术学院八个命令MGC MGAdd Modify subtract Move AuditValue?MGC→MG， ?获得终端的当前信息，事件，信号信息以及统 计信息262626广东邮电职业技术学院八个命令MGC MGAdd Modify subtract Move AuditValue AuditCapability?MGC→MG， ?获取一个媒体网关的容量性能指标272727广东邮电职业技术学院八个命令MGC MGAdd Modify subtract Move AuditValue AuditCapability Notify282828?MG→MGC， ?媒体网关通过此命令通知媒体网关控制器在 其内部发生的事件（比 如用户提机）。,广东邮电职业技术学院八个命令MGC MGAdd Modify subtract Move AuditValue AuditCapability Notify?MGC?MG?MGC→MG?启动服务 ?退出服务 ?MG→MGC?启动服务?退出服务 ?注册ServiceChange292929广东邮电职业技术学院事务通信机制特点：支持多个命令的并行发送，提高协议的传 送效率。即多个命令组合成事务（Transaction）事务 Action1 Command1 Command2Action2TopologyDescriptor事务标识Action3 Command1 Command3 Command2 Command4同一Action中的所有命令控制范围为同一Context 因此通常每个命令都带有ContextID303030广东邮电职业技术学院事务响应发送方接受方TransactionRequestTransactionReply/ TransactioinPendingTransactionResponseAck313131广东邮电职业技术学院通信方式H.248 TCP/UDP IP Three-way HandshakeSoftswitchH.248MGPort 2944: Text-encodedPort 2945: Binary-encoded323232广东邮电职业技术学院内容提要H.248协议的整体概念 H.248的组成呼叫流程分析333333广东邮电职业技术学院情景呼叫建立 呼叫解除343434广东邮电职业技术学院呼叫建立IAD提机 NTFY_REQ NTFY_REPLYSSIADMEGACO/1 [10.66.100.12]:2944 Transaction = 49414 { Context = { Notify = AG58900 { { ObservedEvents = 3T : al/of } } }MEGACO/1 [10.66.100.1]:2944 P=49414{ C=-{ N=AG58900}}353535广东邮电职业技术学院呼叫建立IAD提机 NTFY_REQ NTFY_REPLY MOD_REQ 放拨号音 MOD_REPLYSSIADMEGACO/1 [10.66.100.12]:2944 Reply = 25218 { Context = { Modify = AG58900 } }MEGACO/1 [10.66.100.1]:2944 T=25218{ C={MF=AG58900{DM=DM99{(## |0X.|11X|13XXXXXXXXX|[28]XXXXXX|9XXXXXXXX)},E= 2002{dd/ce{ DM=DM99},al/on, al/fl},SG{cg/dt}}}}363636广东邮电职业技术学院呼叫建立IAD提机 NTFY_REQ NTFY_REPLY MOD_REQ 放号音 拨号 MEGACO/1 [10.66.100.1]:2944 Rply=49415{ Context={Notify=AG58900}} MOD_REPLY NTFY_REQ NTFY_REPLYSSIADMEGACO/1 [10.66.100.12]:2944 Transaction = 49415 { Context = { Notify = AG58900{ ObservedEvents = 2002 { 31500 : dd/ce { ds = “& , Meth = UM } } } } }373737广东邮电职业技术学院呼叫建立IAD提机 NTFY_REQ NTFY_REPLY MOD_REQ MOD_REPLY NTFY_REQ NTFY_REPLY ADD_REQ ADD_REPLYSSIADMEGACO/1 [10.66.100.12]:2944 Reply = 10003 { Context = 2000 { Add = AG58900, Add=RTP/00000{ Media { Stream = 1 { Local { v=0MEGACO/1 [10.66.100.1]:2944 Transaction = 10003 {Context = $ { Add = AG58900,Add = $ {Media {Stream = 1 {LocalControl {Mode = ReceiveOnly,nt/jit=40 ; in ms}, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 a=ptime:30}}}}}}c=IN IP4 10.66.100.12 m=audio 2222 RTP/AVP 4 a=ptime:30 a=recvonly}}}}}}383838广东邮电职业技术学院呼叫建立IAD提机 NTFY_REQ NTFY_REPLY MEGACO/1 [10.66.100.13]:2944 MOD_REQ MOD_REPLY NTFY_REQ NTFY_REPLY ADD_REQ ADD_REPLY ADD_REQ ADD_REPLY 3939SSIADMEGACO/1 [10.66.100.1]:2944 Transaction = 50003 {Context = $ { Add = AG58901 { Media { Stream = 1 {LocalControl {Mode=SendReceive} }}, Events=1234{al/of}, Signals {al/ri}},Add = $ {Media {Stream =1 {LocalControl {Mode=SendReceive, nt/jit=40 ; in ms}, Local { v=0 c=IN IP4 $ m=audio $ RTP/AVP 4 a=ptime:30}, Remote { v=0 c=IN IP4 10.66.100.12Reply = 50003 { Context = 5000 { Add = AG58901, Add = RTP/00001{ Media { Stream = 1 { Local { v=0 c=IN IP4 10.66.100.13 m=audio 1111 RTP/AVP 4 }} ; }}}}响铃m=audio 2222 RTP/AVP 4 a=ptime:30} ;}}}}}39广东邮电职业技术学院呼叫建立IADMOD_REQ MOD_REPLY MEGACO/1 [10.66.100.1]:2944 Transaction = 10005 { Context = 2000 { Modify = AG58900 { Signals {cg/rt}}, Modify = RTP/00000 { Media { Stream =1 {Remote { v=0 c=IN IP4 10.66.100.13 m=audio 1111 RTP/AVP 4 }} ;}}}} MEGACO/1 [10.66.100.12]:2944 Reply = 10005 { Context = 2000 Modify = AG58900 Modify = RTP/00000 } }SSIAD回铃音404040广东邮电职业技术学院呼叫建立IADMOD_REQ 回铃音 MOD_REPLYSSIADMEGACO/1 [10.66.100.13]:2944 Transaction = 50005 {Context = 5000 { Notify = AG58901 {ObservedEvents =1234 { 20002:al/ of}}}}NTFY_REQ NTFY_REPLY提机 MEGACO/1 [10.66.100.1]:2944 Reply = 50005 { Context = - { Notify = AG58901} }414141广东邮电职业技术学院呼叫建立IADMOD_REQ 回铃音 MOD_REPLYSSIADMEGACO/1 [10.66.100.13]:2944 Reply = 10006 { Context = 5000 {Modify = AG58901, Modify = RTP/00001}}NTFY_REQ NTFY_REPLY MOD_REQ MOD_RERLY提机 MEGACO/1 [10.66.100.1]:2944 Transaction = 10006 { Context = 5000 { Modify = AG58901 { Events = 1235 {al/on}, Signals { } ; to turn off ringing }}424242广东邮电职业技术学院呼叫建立IADMOD_REQ 回铃音 MOD_REPLYSSIADMEGACO/1 [10.66.100.1]:2944 Transaction = 10006 { Context = 2000 { Modify = RTP/00000 { Media { Stream = 1 { LocalControl { Mode=SendReceive}}}}, Modify = AG58900 { Signals { }}}}NTFY_REQ NTFY_REPLY MOD_REQ MOD_RERLY MOD_REQ MOD_REPLY 呼叫建立提机 MEGACO/1 [10.66.100.12]:2944 Reply = 10006 { Context = 2000 {Modify = RTP/00000,Modify = AG58900}}434343广东邮电职业技术学院呼叫解除IAD SSNTFY_REQ MEGACO/1 [10.66.100.13]:2944 NTFY_REPLY MEGACO/1 [10.66.100.1]:2944 Reply = 50008 { Context = {Notify = AG58901} }IAD挂机Transaction = 50008 { Context = 5000 { Notify = AG58901 {ObservedEvents =1235 { 20002:al/ on} } } }444444广东邮电职业技术学院呼叫解除IADMEGACO/1 [10.66.100.13]:2944SSNTFY_REQ NTFY_REPLY SUB_REQ SUB_RERLYIAD挂机Reply = 50009 { Context = 5000 { Subtract = AG58901 { Statistics { nt/os=45123, ; nt/dur=40 ; }}, Subtract = RTP/00001 { Statistics { rtp/ps=1245, nt/os=62345, rtp/pr=780, nt/or=45123, rtp/pl=10, rtp/jit=27, rtp/delay=48 }}}}MEGACO/1 [10.66.100.1]:2944 Transaction = 50009 { Context = 5000 { Subtract = AG58901 {Audit{Statistics}}, Subtract = RTP/00001 {Audit{Statistics}}}}454545广东邮电职业技术学院呼叫解除IAD SSNTFY_REQ NTFY_REPLY MEGACO/1 [10.66.100.1]:2944 Transaction = 50009 { Context = 2000 { Subtract = AG58900 {Audit{Statistics}}, Subtract = RTP/00000 {Audit{Statistics}}}} SUB_REQ SUB_RERLY SUB_REQ SUB_REPLYIAD挂机 MEGACO/1 [10.66.100.12]:2944 Reply = 50009 { Context = 2000 { Subtract = AG58900 { Statistics { nt/os=45123, ; nt/dur=40 ; }}, Subtract = RTP/00000 { Statistics { rtp/ps=1245,Conversation Terminatednt/os=62345, rtp/pr=780, nt/or=45123, rtp/pl=10, rtp/jit=27, rtp/delay=48 }}}}464646广东邮电职业技术学院
更多搜索：
All rights reserved Powered by
文档资料库内容来自网络，如有侵犯请联系客服。H248协议原理（转载）
编者：林国新
审核：柴引达
H.248/Megaco 协议（Media Gataway Control
Protocal），简称H.248协议，是IETF、ITU－T制定的媒体网关控制协议，一个非对等协议，用在媒体网关控制器（MGC）和媒体网关（MG）之间的通信。
主要功能是建立一个良好的业务承载连接模型，将呼叫和承载连接进行分离，通过对各种业务网关：
TG（中继网关），AG（接入网关），RG（注册网关）等的管理，实现分组网络和PSTN网络的业务互通。
协议基本概念
协议的起源
H.248协议是 2000年由 ITU-T第 16工作组提出的媒体网关控制协议，它是在早期的
MGCP协议基础上改进而成。H.248／ MeGaCo协议是用于连接MGC与MG的网关控制协议，应用于媒体网关与软交换之间及软交换与
H．248／ MeGaCo终端之间，是软交换应支持的重要协议。
由于IP网络的快速发展，IP网提供的业务越来越多。同时，原有的电路交换网（如PSTN网）仍然拥有大量的用户，为了能让这些用户使用IP网络提供的服务，需要提供不同网络之间互通的网关设备。随着用户数量及对业务需求的增加，网关在规模上要不断扩大，这种集中型的网关结构在可扩展性、安全性方面及组网的灵活性上都存在很大的限制。由此，提出了将业务、控制和信令分离概念，即将IP电话网关分离成三部分：
信令网关SG、媒体网关MG和媒体网关控制器MGC。SG负责处理信令消息，将其终结、翻译或中继；MG负责
处理媒体流，将媒体流从窄带网打包送到IP网或者从IP网接收后解包后送给窄带网；MGC负责MG的资源的注册和管理，以及呼叫控制。在这种分布式的网关体系结构中，MG和MGC之间采用的是H.248协议，SG和MGC之间采用SIGTRAN协议。网关分解功能模型如图
1‑1所示：
1 网关分解功能模型
1.1.2 &协议连接模型
H248协议的目的是对媒体网关的承载连接行为进行控制和监视。为此，首要的问题就是对媒体网关内部对象进行抽象和描述。那么，H248提出了网关的连接模型概念。连接模型指的是MGC控制的，在MG中的逻辑实体或对象。它是MGC和MG之间消息交互的内容核心，MGC通过命令控制MG上的连接模型，MG上报连接模型的各种信息包括状态、参数、能力等。
H.248协议定义的连接模型包括终端（termination）和上下文（context）两个主要概念。终端是
MG中的逻辑实体，能发送和接收一种或多种媒体，在任何时候，一个终端属于且只能属于一个上下文，可以表示时隙、模拟线和RTP（real
protocol）流等。终端类型主要有半永久性终端（TDM信道或模拟线等）和临时性终端（如RTP流，用于承载语音、数据和视频信号或各种混合信号）。用属性、事件、信号、统计表示终端特性，为了解决屏蔽终端多样性问题，在协议中引入了包（package）概念，将终端的各种特性参数组合成包。一个上下文是一些终端间的联系，它描述终端之间的拓扑关系及媒体混合/交换的参数。最早是在MGCP协议中首次提出
context的概念，使协议具有更好的灵活性和可扩展性，H.248/MeGaCo协议延用了这个概念，它可用
Add命令创建，用Subtract或 Move命令删除。
模型的基本构件包括：终端（termination）和关联域（context）。如下图所示：
图 1-2 H.248连接模型示例
1.2 &协议的主要功能
H.248协议是由MGC控制 MG的协议，也称MeGaCo。
H.248中引入了cnntext概念，增加了许多package的定义，从而将MGCP大大推进一步。可以说H.248建议已取代
MGCP，成为 MGC与 MG之间的协议标准。
将网关分解成MG和 MGC是研制大型电信级IP电话网关的需要。
1．&& MGC的功能是：
（1）& 处理与网守间的H.225 RAS消息；
（2）& 处理 No．7信令（可选）；
（3）& 处理H．323信令（可选）。
2．&& MG的功能是：
（1）& IP网的终结点接口；
（2）& 电路交换网终结点接口；
（3）& 处理 H．323信令（在某类分解中）；
（4）& 处理带有RAS（registeration admission
status）功能的电路交换信令（在某类分解中）；
（5）& 处理媒体流。
1.3 &248协议消息及命令
消息是协议发送的信息单元，一个消息包含一个消息头和版本号，消息头包含发送者的ID。消息中的事务彼此无关，可以独立处理。协议消息的编码格式为文本格式和二进制格式。MGC必须支持这两种格式，MG可以支持其中任一种格式。当MG发起呼叫时，MGC建立一个新的上下文，并使用Add命令将
R7rP流和模拟线这两个终端分别添加到上下文中，当
MG结束呼叫后，MGC使用Subtract命令将终端从上下文中删除，释放资源。用Modify命令可以修改终端的属性和信号参数。H.248还定义了：
Move命令，将一个终端从一个上下文移到另一个上下文；
AuditValue命令，返回终端特性的当前状态；
AuditCapabilities命令，返回终端特性的能力集；
4．&& Notify命令，允许 MG将检测到的事件通知
5．&& serviceChange命令，允许
MG通知MGC一个或多个终端将要脱离或加入业务，也可以用于MG注册到
MGC表示可用性，以及MGC的挂起和MGC的主、备转换通知等。
H．248与MGCP在协议概念和结构上有很多相似之处，但也有不同。H.248/MeGaCo协议简单、功能强大，且扩展性很好，允许在呼叫控制层建立多个分区网关；MGCP是H.248/MeGaCo以前的版本，它的灵活性和扩展性不如H.248/MeGaCo。H．248支持多媒体，MGCP不支持多媒体。应用于多方会议时，H.248比
MGCP容易实现。MGCP基于UDP传输，H.248基于传输控制协议（TCP）、UDP等。H.248的消息编码基于文本和二进制，MGCP的消息编码基于文本。
ZXMSAG下H.248协议常见的符号及简写：
T=Transaction,事务，h248协议结构
C=Context，上下文，Transaction内容
3．&& N=Notify，上报一个事件
4．&& A=Add, 向一个空关联中加入终端时
5．&& S=Subtract,
删除或者移出关联中的最后一个终端
MF=Modify,改变属性或者设置一个事件
7．&& OE=Observed Event
8．&& al/of=hookoff摘机消息
9．&& al/on=hookon挂机消息
终端是能够发送或接收一种或多种媒体流的逻辑实体。终端由许多特性描述，这些特性由组合在命令中的一些列描述符组成。终端有唯一的终端标识（Termination
ID），它是在创建时由媒体网关唯一创建。一个终端在任一时刻属于且只能属于一个关联。
终端是一种逻辑实体，用来发送/接收媒体流和控制流，终端可以分为如下几类：
半永久性终端：代表物理实体的终端，称为物理终端。例如：代表一个TDM信道的终端（如我们稍后配置中常见的MG中的TRUNK资源，MG的AG资源），只要MG中存在这个物理实体，这个终端就存在。
临时性终端：这类终端只有在网关设备使用它的时候才存在，一旦网关设备不使用它，立刻就被释放掉。例如我们稍后配置中常见的MG中的RTP资源，只有当MG使用这些资源的时候，这个终端才存在。临时性终端可以使用add命令来创建和substract命令来删除，当向一个空关联中加入一个终端时，默认的将添加一个关联；若从一个关联中使用substract命令删除最后一个终端时，关联将变为空关联。
根终端（ROOT）：根终端是一种特殊的终端，他代表整个MG。当ROOT作为命令的输入参数时，命令将作用于整个网关，而不是网关中的一个终端。在根终端上可以定义包，也可以有属性、事件和统计特性（信号不适用于根终端），因此，根终端的TerminationID将会出现在一下几个地方：
（1）& Modify命令：改变属性或者设置一个事件
（2）& Notify命令：上报一个事件
（3）& Auditvalue命令：检测属性值和根终端的统计特性
（4）& Auditcapability命令：检测根终端上的属性
（5）& Servicechange命令：声明网关进入服务或者退出服务
除此之外，任何在根终端上的应用都是错误的。
终端上可以有信号，信号是MG产生的媒体流，如：Tone音和通知音，以及一些线路信号如：摘机、挂机等。
MG 可以处理复用媒体流，例如，H.221 建议描述了将多个媒体流复用在几个64kbit/s
数字通道上的帧结构。在处理复用媒体流的连接模型中，用于携带部分复用流的每个数字承载通道都有一个物理或临时的承载终端相对应，所有处于这些数字通道的起始和终结位置的承载终端都被连接到一个称为复用终端（Multiplexing
Termination）的独立终端。复用终端是代表一个面向帧的会话的临时性终端，它使用Mux
描述符来描述所使用的多路复用方式（例如H.320会话中使用的H.221），以及所包含的数字通道以什么顺序组装成帧。复用终端可以是多级的。例如，几个数字通道以H.226
复用之后生成的终端可以再以H.223 加入到其他复用终端中以支持一个H.324 会话。复用终端上不同的Stream
描述符用来描述会话中不同的媒体流。这些媒体流与关联中终结点发出/接收的流相对应，而与生成复用终端的承载终端没有对应关系。每个承载终端只支持一个数据流。这些数据流在复用终端上并不以流的形式出现，对关联的其他部分它们是不可见的。
终端用TerminationID 进行标识，TerminationID
的分配方式由MG自主决定。物理终端的TerminationID 是在MG 中预先规定好的。这些TerminationID
可以具有某种结构。例如，一个TerminationID
可以由一个中继组号及其中的一个中继号组成，例如用TRUNK0010101，其中001指单元号，第一个01指子单元号，第二个01指终端序号。
对于TerminationID
可以使用一种通配机制。该通配机制使用两种通配值（Wildcard）：“ALL”和“CHOOSE”。通配值“ALL”用来表示多个终端，在文本格式的H.248信令跟踪中以“*”表示。“CHOOSE”则用来指示MG
必须自己选择符合条件的终端，在文本格式的H.248信令跟踪中以“$”表示。例如MGC 可以通过这种方式指示MG
选择一个中继群中的一条中继电路。当命令中的TerminationID
是通配值“ALL”时，则对每一个匹配的终端重复该命令，根终端（Root）不包括在内。当命令不要求通配响应时，每一次重复命令将产生一个命令响应。当命令要求通配响应时，则多次重复命令只会产生一个通配响应，该通配响应中包含所有单个响应的集合。
不同类型的网关可以支持不同类型的终端，H248协议通过允许终端具有可选的性质（Property）、事件（Event）、信号（Signals）和统计（Statics）来实现不同类型的终端。那这4类针对于终端的描述特性分别含义如下：
1．&& 性质（Property）
2．&& 事件（Event）
3．&& 信号（Signals）
4．&& 统计（Statics）
H248协议用“描述语”（descriptor）这一数据结构来描述终端的特性，并针对终端的公共特性，分门别类的定义了19个描述语，一般每隔描述语只包含上述某一类终端特性。
H248协议定义了8
个命令用于对协议连接模型中的逻辑实体（关联和终端）进行操作和管理。命令提供了H248协议所支持的最精微层次的控制。例如，通过命令可以向关联增加终端、修改终端、从关联中删除终端以及审计关联或终端的属性。命令提供了对关联和终端的属性的完全控制；包括指定要求终端报告的事件、向终端加载的信号以及指定关联的拓扑结构（谁能听见/看见谁）。
H248协议规定的命令大部分都是用于MGC对MG的控制，通常MGC作为命令的始发者发起，MG作为命令的响应者接收。但是Notify命令和ServiceChange命令除外，Notify命令由MG发送给MGC，而ServiceChange命令既可以由MG发起，也可以由MGC发起。各命令如图1-3图
1-3 H.248命令所示：
H248协议规定的命令参照表1‑1：
1:H.248命令列表
基于事务的消息传递机制
MG 和MGC 之间的一组命令组成了事务（Transaction）。每个Transaction
由一个TransactionID来标识。Transaction 由一个或者多个动作（Action）组成。一个Action
又由一系列命令以及对关联属性进行修改和审计的指令组成，这些命令、修改和审计操作都局限在一个关联之内。因而每个动作通常指定一个关联标识。但是有两种情况动作可以不指定关联标识符，一是当请求对关联之外的终端进行修改或审计操作时，另一种情况是当MGC
要求MG创建一个新关联时。事务、动作和命令之间的关系示意图如下图1-4所示。
-4 事务结构
事务由TransactionRequest（事务请求）发起。对TransactionRequest
的响应放在一个单独的TransactionReply（事务应答）里面。在收到TransactionReply
之前，可能会先出现一些TransactionPending（事务处理中）消息。事务保证对命令的有序处理。即在一个事务中的命令是顺序执行的。各个事务之间则不保证顺序，即各个事务可以按任意顺序执行，也可以同时执行。如果一个事务中有一个命令执行失败，那么这个事务中的所有剩余命令都将停止执行。如果命令中包含通配形式的TerminationID，则对每一个与通配值匹配的TerminationID执行此命令。TransactionReply
包含对应每个与通配值匹配的TerminationID返回的一个响应；即使对其中一个或多个终端产生了错误码。如果与通配值匹配的终端在执行命令时发生了错误，则对此终端之后的所有通配值终端的命令将不再执行。但当命令标记为“Optional（可选）”时，处理的方式将会不同，即：如果一个可选命令执行失败，该事务中的后续命令仍可继续执行。如果中间某个命令执行失败，MG
在继续处理命令前应尽可能恢复该失败命令执行前所处的状态。TransactionReply
包含相应的TransactionRequest
中的所有命令的执行结果，其中包括成功执行的命令返回值，以及所有执行失败的命令的命令名和Error
描述符。TransactionPending
命令是用来周期性地通知接收者一个事务尚未结束，尚处于正在积极处理过程中。具体实现上，对每个事务都应该设置一个应用层定时器等待TransactionReply。当定时器超时后，应该重新发送TransactionRequest。当接收到TransactionReply
后，就应该取消定时器。当接收到TransactionPending
消息后，就应该重新启动定时器。该定时器被称为最大重传定时器。
．&& 事务ID
事务由TransactionID 标识，TransactionID
是由事务发起方分配并在发送方范围内的唯一值。如果TransationRequest 的TransactionID
丢失，TransactionReply 则带回一个Error 描述符指示TransationRequest
中的TransactionID 丢失，其中包含的TransactionID 填0。
注意：H.248的定义
目前IETF 的H.248对事务层只定义了403（Syntax Error in
Transaction）错误码，在没有更合适的错误码之前，暂且使用403 作为TransationRequest
中的TransactionID 丢失的错误码。
．&& 事务接口
事务之间的接口如图1-5所示：
-5事务的接口
（1） TransactionRequest
TransactionRequest
由事务发起方发送，每发起一个请求后就有一个事务与之对应。一个请求包含一个或者多个动作，其中每个动作都指定了它的目标关联以及对目标关联作用的一个或者多个命令。
TransactionRequest（TransactionID {
ContextID {Command … Command},
ContextID {Command … Command }}）
其中，TransactionID 参数必须指定一个值，用于该参数可以将TransactionRequest
与以后接收方发出的TransactionReply 或者 TransactionPending 关联起来。ContextID
必须指定一个值，该值用于随后的所有命令，直到指定下一个ContextID 或TransactionRequest
结束。TransactionReply 由事务的接收方发送，作为对TransactionRequest
的一对一响应。一个TransactionReply
包含一个或者多个动作，其中每个动作都必须指定动作的目标关联，以及对应每个关联的一个或者多个响应。当事务的响应方完成了TransactionRequest
的处理后，就会发送一个TransactionReply。
当出现以下两种情形之一时，就认为接收方已完成TransactionRequest 的处理：
1）&& TransactionRequest
中所有动作已处理完毕；
2）&& TransactionRequest
中的一个非可选命令处理失败。
当命令中的所有描述符都已处理完毕，就认为这个命令处理完毕。对于信号描述符，如果该描述符语法描述正确，接收方支持信号描述符所指定的信号类型，并且指定的信号已经置于等候加载的队列中，就认为信号描述符处理完毕。对于事件描述符，如果该描述符语法描述正确，接收方能够检测事件描述符中所指定的事件，能产生事件描述符中嵌套的信号，能识别事件描述符中嵌套的事件类型，并且MG
已处于检测事件发生的状态，就认为事件描述符处理完毕。&&&&&
TransactionReply （TransactionID {
ContextID{Response … Response},
ContexID {Response … Response}}）
TransactionReply 中的TransactionID 参数必须与相关的TransactionRequest
中的TransactionID 相同。ContextID 参数必须指定一个值，该值适用于动作中所有命令的响应， ContextID
可以指定为确定的值、“ALL”或“NULL”。Response
参数代表一个命令返回值，或者命令执行失败时的Error描述符。失败命令之后的其他命令将不执行，也不产生命令响应。
但有一个例外，当Transactionrequest
中的一个标记为“Optional”（可选）的命令执行失败时，事务中该命令后的命令将继续执行并返回命令响应。如果接收方处理某个ContextID
时发生错误，则返回的动作响应中将包含处理失败的ContextID 和一个Error 描述符，错误码为422（“ Syntax
Error in Action”）。如果接收方遇到一个错误而无法确认某个动作是否合法，则返回的TransactionReply
中包含TransationID 和一个Error 描述符，错误码为422（“Syntax Error in
Action”）。如果接收方无法确认某个动作的结束部分，但是可以解析出其中一个或多个命令，则接收方将执行动作中可以解析的命令，并返回一个包含Error
描述符的响应作为该Transaction 的最后一个动作响应，错误码为422（“Syntax Error in
Action”）。如果接收方遇到一个错误而无法确认接收的Transaction是否合法，则返回包含为0 的 TransationID
和一个Error 描述符的TransactionReply，错误码为403（“Syntax Error in
Transaction”）。如果接收方无法确认某个Transaction
的结束部分，但是可以解析其中一个或多个动作，则接收方将执行Transaction 中可以解析的动作，并返回一个包含Error
描述符的响应作为该Transaction 的最后一个动作响应，错误码为403（“Syntax Error in
Transaction”）。如果接收方一个动作都不能解析，也返回403 错误码。如果接收方无法确认所接收Transaction
中的某个TerminationID，则返回的响应中将包含一个Error 描述符，错误码为442（“Syntax Error in
Command”）。如果接收方无法确认某个命令的结束部分，则返回一个包含Error
描述符的响应作为对最后一个它能解析的动作的响应，错误码为442（“Syntax Error in Command”）。
（2）& TransactionPending
&&&&&&&&&&
TransactionPending 由接收方发送，它表示一个Transaction
正在被处理，但是处理尚未完成。当对一个Transaction
的处理还需要一些时间来完成时，发送这个消息用来防止发送方认为相关的TransactionRequest 已丢失。
TransactionPending （TransactionID {}）
&&&&&&&&&&
TransactionPending 中包含的TransactionID 参数应与相关TransactionRequest
中的TransactionID 相同。根终端的“NormalMGExecutionTime”属性由MGC 设置，用于指示MGC
期待从MG 接收到事务的TransactionReply
时间间隔，另一属性“NormalMGCExecutionTime”属性由MGC 设置，用于指示MG 期待从MGC
接收到事务的TransactionReply 时间间隔。事务发送方可能会接收到一个事务的多个TransactionPending
消息。当处于Pending
状态的接收方接收到一个重复的TransactionRequest，接收方可以立即发送一个重复的TransactionPending
消息，或者等待定时器超时后发送另外一个TransactionPending 消息。
一个消息由多个Transaction 组成，消息的组成如图1-6所示。
1-6消息的组成
每个消息都有一个消息头，其中包含标识消息发送者的标识符。可以将消息发送者的名称（如域地址/域名/设备名）作为消息标识符MID（Message
Identifier）。H248协议建议使用域名作为缺省的消息标识符。在一对MGC
和MG具有控制关系期间，一个H.248实体（MG或MGC）在它作为发起方发送的消息中必须始终如一地使用同一个消息标识符MID。消息包括一个版本字段用于标识消息所遵从的协议版本。版本字段为1位或2位数，目前所采用的协议版本为版本1。
MID如下例所示：
MEGACO/1& [10.66.100.128]:2944
消息中所包含的Transaction是各自独立处理的。消息不规定任何顺序，也无所谓消息的应用程序或对消息的应答。一个消息实质上只是一个传输的机制。例如，消息X包括TransactionRequest
A ，B和C，对它的响应可以是：由消息Y包含对TransactionRequest
A和C的应答，由消息Z包含对TransactionRequestB的应答。同样，消息L 包括TransactionRequestD
，消息M包括TransactionRequest E，可以由消息N同时包含对TransactionRequest D
和E的应答。
H248的传送机制应该支持对在MG 和MGC
之间的所有Transaction的可靠传输。传输应当与协议的中需要传输的特定命令无关，并且可适用于所有的应用程序状态。如果是在IP
上传输H248协议，MG 应当实现TCP 或者UDP/ALF，或者同时支持两者。在IP/TCP/UDP上传输H.248应当为MG
预先提供一个首选MGC 以及0 到多个备选MGC 的名字或地址（如DNS 域名或IP 地址），用于MG 向MGC
发送消息的目的地址。如果传输层协议采用的是TCP 或者UDP，而由于某种原因不知道应将初始的ServiceChange
请求发送到哪个端口，则消息发送方就应当将这个请求发送到缺省的协议端口。无论是TCP
还是UDP，对于文本编码的消息，缺省的协议端口为2944；而对于二进制编码的消息，缺省的协议端口为2945。MGC 接收到来自MG
的包含ServiceChange 请求的消息后，应当能够从中判断出MG 的地址。同时，MG 和MGC
都可以在ServiceChangeAddress 参数中提供一个地址，以便后续的TransactionRequest
都发送到这个地址。但是，所有请求的响应（包括对初始的ServiceChange 请求的响应）必须发送给相应请求的源地址。例如，在IP
网中，这个地址应该是IP 头中的源地址及TCP/UDP/SCTP 头中的源端口号。
H.248协议的传输输机制能够支持在MG和MGC之间的事务处理的可靠传输采用三次握手机制。如图1-7：
H.248的可靠传输
H248协议不要求所采用的底层协议保证Transaction
的顺序到达，这一特性可以增强Action的实时性，但是也具有一些缺陷，如：
Notify 命令可能被延迟；当它到达MGC 时MGC
可能已发送了一个新命令改变了Events描述符。在命令未确认之前发送一个新的命令，不能确保先前的命令在新命令之前被执行。
H248协议规定对于在不同Transaction中传送的命令，MGC应遵循以下规则确保与MG的一致操作。这些规则针对的是在不同Transaction中的命令。同一Transaction中命令的执行是按顺序进行的：
1．&& 当MG
处理多个终端时，与不同终端相关的命令可以同时发送，例如，可采取一种模型，使每一个终端或者一组终端都受控于一个与之相对应的处理进程或线程。
在一个终端上，一般最多只应当有一个未处理完的命令（如Add、Modify
或Move），除非这些未处理完的命令包含在同一个事务中。但是Subtract 命令可以随时发送，因此，有时MG
可能接收到一个Modify 命令作用于一个之前已被删除的终端，此时MG 应忽略这样的命令并返回带错误码的响应。
对于不保证消息按顺序发送的传输协议，如UDP，任何时候在一个终端上一般只应当有一个未处理完的Notify 命令。
4．&& 有时，当Add
命令正在处理时，可能有一个作用于一组采用隐含或显式通配值表示的终端的Subtract 命令，Subtract 命令应先于Add
命令处理。此时，MGC 应专门删除Add 命令中涉及的所有终端。而且，在上述Subtract
命令未被响应之前，不应对包含在通配值（或通配值隐含在MuxDescriptor 中）中的终端发送新的Add 命令。
5．&& AuditValue
和AuditCapabilites 命令可以不按任何顺序发送。
6．&& ServiceChange应当总是MG
发出的第一个命令，过程按照MG 重启动规程的定义。任何其他的命令或响应必须在ServiceChange
命令之后发送。命令的响应方不受以上规则的影响，对于每一个命令，应该及时返回命令响应。
大量的MG同时加电重新启动时，将同时发起大量的ServiceChange 注册流程。此时，由于大量的ServiceChange
命令同时到达很可能会使MGC消息处理流程发生崩溃，从而导致在业务重启期间引起消息丢失和网络拥塞。因此，H248协议建议采用以下规则预防MGC
发生这种重启雪崩，如图1-8所示：
-8预防重启雪崩
当MG加电重启时，应该启动一个重启定时器，并将该定时器值初始化为大于０小于最大等待时延（MWD（Maximum Waiting
Delay））的一个随机值。当多个MG 使用相同的重启定时器值生成算法时，应避免它们之间重启定时器随机值同步生成。
MG应该等待重启定时器超时或者检测到本地用户的一个动作，例如MG检测到用户摘机事件，MG才发起重启流程。重启流程仅要求MG保证MGC从MG收到的第一个消息是通知MGC有关重启的ServiceChange消息。
另外，MWD 是MG 中与MG 类型相关的配置参数。驻地媒体网关（RG）的MWD 可以参照以下因素进行计算。通常MGC
的规模应满足峰值小时话务负荷的需求。在负荷峰值期间，平均有10%的模拟电话线用户处于忙状态，且平均呼叫时长为3 分钟。通常MGC
与MG 之间完成一次呼叫需要5-6 个Transaction。简单估算，平均每三十分钟MGC 需要为每个终端处理5-6
个Transaction，或者平均每5-6 分钟为每个终端处理一个Transaction。因此，建议RG 的MWD 值为10-12
分钟。当MG 未明确定义MWD 值时，MWD 应选取缺省值600 秒（10
分钟）。对于中继媒体网关（TG）或商务媒体网关（Business Gateway）而言，MWD
值应该更小，因为这些网关需要处理的终端数量更多，并且在忙时峰值阶段，终端的利用率也要大于10%，通常为60%。因此，在忙时，MGC
的处理能力将按每分钟为每个终端处理一个Transaction。因此，TG 中每条中继线的MWD 值应比RG 中模拟电话线的MWD
值小6 倍，并且与正在重启动的终端数量成反比。例如，处理T 1 中继线的TG 的MWD 值应被设置为2.5 秒，而处理T3
中继线的MWD 值则应被设置为60 毫秒。
1.7 &协议典型呼叫过程
主叫摘机，MG检测到后通过Notify命令将事件（Off-Hook）报告给MGC；
MGC通过Add命令让MG将主叫端口加入一个Context，并向主叫送拨号音以及下发号码表；
用户拨号，MG将收到的号码通过Notify命令报告给MGC；
MGC分析被叫号码，找出被叫端口，命令MG将被叫端口加入一个Context；
MGC命令MG向主叫送回铃音，向被叫送振铃音；
6．&& 被叫摘机，MGC命令MG连接主被叫；
主/被叫挂机，MGC命令MG释放主被叫连接，将主/被叫端口放空Context。&&&&&&&&&&&&&&&&&
当SS收到主叫用户摘机事件以后，通过MOD_REQ命令指示网关给终端发送拨号音，并把拨号计划DigtalMap发送给H.248网关，要求根据DigtalMap拨号计划收号，并同时检测挂机和拍叉簧事件的发生。网关设备回复相应的响应消息，并按照号码图表的规则上报所拨的号码。
的定义、创建、更新和删除
号码表（DigitMap）指的是MG中的拨号方案，用于检测和报告在终端上接收到的拨号事件。DigitMap
描述符包含DigitMap 名称（DigitMapName）和指定的DigitMap。DigitMap
可以通过管理系统预先装载于MG，并通过在Events 描述符中指定DigtMap 名称进行引用；DigitMap
还可以动态定义,并随后通过所定义的DigitMap 名称进行引用；还可以在Events
描述符中定义当前的DigitMap。在一个命令中的DigitMap 描述符中定义的DigitMap，可以被同一命令中的Events
描述符里的DigitMap Completion
事件所引用，而无需考虑相应描述符的传送顺序。H248协议规定的任何命令都可以使用DigitMap
描述符中定义的DigitMap。DigitMap
一经定义，则可以适用于命令中该TerminationID（可能为通配值）所指定的所有终端。根终端中定义的DigitMap
具有全局性，适用于MG 中的任意终端，只要名称相同的DigitMap
未在特定终端中另作定义。H248协议规定可以按照以下方式在DigitMap 描述符中动态定义DigitMap：
1．&& 创建新的DigitMap
可以通过定义一个未被使用的DigitMap 名称，并应给出取值；
更新DigitMap可以通过给一个已定义的DigitMap 名称赋一个新值。DigitMap 值更新后，当前正使用该DigitMap
的所有终端应该继续使用更新前的DigitMap 定义值；而后面的Events 描述符中的DigitMap
描述符如果包含了该DigitMap 名称，则应使用更新后的DigitMap 定义值。
3．&& 删除DigitMap
可以通过给一个已被定义的DigitMap 名称赋一个空值。DigitMap 删除后，当前正使用DigitMap
的所有终端应继续使用删除前的DigitMap。
2.1.2 &&定时器
H248协议规定了三类定时器用于保护根据DigitMap
所收集的号码，这三类定时器为：起始定时器（T），短定时器（S）和长定时器（L）。
起始定时器T用于任何已拨号码之前。如果起始定时器被设为0（T=0），此定时器就失效了；表示MG将无限期地等待拨号。
2．&& 若MG
确认号码串至少还需要一位号码来匹配DigitMap中的任意拨号方案，则数字间的定时器值应设置为长定时器（L）（例如16 秒）。
若号码串已经匹配了DigitMap中的某一拨号方案，但还有可能接收更多位数的号码而匹配其它不同的拨号方案，则不应立即报告匹配情况，MG
必须使用短定时器（S）等待接收更多位数的号码。
DigitMap中的定时器为可配置参数。这些定时器的缺省值应当在MG中预先设定；但可以被DigitMap中指定的值所修改。
2.1.3 &语法
根据语法，DigitMap可以由字符串和字符串列表来定义。字符串列表中的每个字符串都是一个可选拨号事件序列,可以表示为一个DigitMap字符序列，也可以是DigitMap
字符序列的标准表达形式。
DigitMap字符包括数字和字母，其中数字的范围从“0”到“9”，字母的范围从“A”到由相关信令系统所决定的字母最大值（最大值不超过K）。这些字符应与该DigitMap所适用的终端上的Events
描述符所指定的事件一一对应。DigitMap
字符与拨号事件之间的映射关系在与随路信令系统（如DTMF，MF，R2）相关的包中进行了规定。从“0”到“9”
的数字字符必须映射到信令系统相应的拨号事件。DigitMap字母应当按一定的逻辑结构来分配，以便使用范围表示法（range
notation）表示可选拨号事件。DigitMap
中字母“X”为通配值，可代表与“0”－“9”范围内的符号相关的任何拨号事件。字符串可包含明确的范围，及明确的符号集，以代表任意一个满足该DigitMap
相应位置的拨号事件。符号“.”代表0
次或多次重复在“.”之前的拨号事件（事件、事件范围、可选事件集合或通配符）。根据规定的定时器规则，与符号“.”匹配的事件之间的定时器缺省地采用短定时器S。除了这些事件符号，字符串可以包含“S”和“L”位间定时指示符以及“Z”持续时间修改符。“S”与“L”分别表示MG
对于后续拨号事件应采用短定时器S 或长定时器L，取代先前规定的定时规则。
若明确的定时指示符在一个DigitMap 字符序列中生效，但在任何其他的DigitMap
字符序列中没有规定定时指示符，则必须使用该定时指示符规定的定时器。若所有带有明确定时控制的序列从可选号码序列集合中删除，则定时器会恢复到上述缺省值。如果不同可选号码序列中定时指示符发生冲突，应当采用长定时器（L）。“Z”表示一个长持续时间的拨号事件：“Z”被放在满足给定字符位置的事件符号之前，它表示只有在事件的持续时间超过时间门限时，拨号事件才会满足该位置。该门限值由MG
预先设定。
当引用DigitMap的Events描述符处于激活状态，且DigitMap未结束时，DigitMap
也处于激活状态。H248协议规定当以下情况发生时，DigitMap结束：
1．&& 定时器超时；
已经匹配某一部分拨号事件序列，再收到其他拨号事件已不可能再匹配DigitMap中的其他拨号事件序列，即明确匹配（Unambiguous
检测到一个拨号事件使得以后无论收到什么事件都不可能匹配DigitMap中一个完整的事件序列。DigitMap
结束后，应产生一个带有已经匹配的字符串的 “DigitMap
Completion”事件，此时DigitMap进入去激活状态。以后收到的事件将按当前激活的Events描述符的处理机制进行处理。
在连续的拨号事件没有结束之前，H248协议规定应根据如下规则进行处理：
“当前拨号串”是一个内部变量，起始值为空。候选拨号事件序列集合包括DigitMap中规定的所有候选拨号事件。
在每一步中，设置一个定时器等待下一拨号事件。定时器或者采用缺省的定时原则，或者采用一个或多个拨号事件序列中明确规定的定时器。若定时器超时，且能与候选拨号事件集中的一个拨号事件完全匹配，则报告“定时器超时，完全匹配”（Full
Match，简写为FM）。若定时器超时，且不能与候选拨号事件集完全匹配，或没有候选拨号事件可以匹配，则报告“定时器超时，部分匹配”（Partial
Match，简写为PM）。
如果定时器超时前检测到拨号事件，就将拨号事件映射成号码字符，并将其加到当前拨号字符串的后面。当且仅当事件的持续时间与当前位置相关时（因为至少有一个候选的拨号事件序列在此位置有一个
“Z”指示符），事件的持续时间（不论长短）才会被记录。
当前的拨号字符串与候选的拨号事件序列相比较。当且仅当在该位置上具有长持续时间的拨号事件序列与之相匹配时，即拨号事件具有长持续时间并满足该位置的要求，则任何该位置上未规定长持续时间的候选拨号事件序列都将被丢弃，并且在代表最近拨号事件的符号前插入“Z”以修改当前拨号字符串。如果该位置上可能的长持续时间拨号事件的任意序列不能与正在被检测到的拨号事件相匹配，则该长持续时间拨号事件将会从候选集中丢弃。如果拨号事件序列在给定位置未规定长持续时间拨号事件，并且应用上述规则之后仍然保留在候选拨号集中，则在进行评估匹配时，被观察的拨号事件持续时间将视为无关。
如果恰好只剩下一个候选事件序列且完全匹配，就会产生一个明确匹配（UnambiguousMatch，简写为UM）的“DigitMap
Completion”事件。如果没有候选拨号序列相匹配，则最近的事件将会从当前拨号字符串中删除。如果在检测到最近的拨号事件之前，已有一个候选拨号序列完全满足匹配，则将相应产生一个完全匹配（Full
Match）的“DigitMap Completion”事件，否则将相应产生一个部分匹配（Partial
Match）的“DigitMap
Completion”事件。从当前拨号字符串中删除的拨号事件随后将按照当前激活的事件处理机制进行报告。
6．&& 如果经过前面5 个步骤都没有报告“DigitMap
Completion”事件（即候选拨号集仍然包含多个拨号事件序列），则返回到第2 步进行处理。
当新的Events描述符作用于终端，或者嵌套的Events描述符被激活时，如果Event 描述符包含“DigitMap
Completion”事件，DigitMap 就会被激活。“DigitMap Completion”事件中包含EventDM
参数。每个新激活的DigitMap 将带有空的当前拨号字符串。如果描述的流程第1
步开始执行。激活之前的当前拨号字符串中原来的内容将会丢“DigitMap Completion”事件在Requestedaction
域中未包含EventDM 参数，则该“DigitMap Completion”事件是错误的。如果MG 接收到的Events
描述符中包含这种错误的“DigitMap Completion”事件，MG 应向MGC 报告错误，错误码为457（“Missing
parameter in signalor event”）。
和事件处理的交互
当DigitMap 激活时，含有指定的“DigitMap
Completion”事件的包中所定义的所有事件都可以被检测,正常的事件处理方式对检测到的事件继续适用；例如:如果“DigitMap
Completion”事件的KeepActive 标志没有设置，则停止信号。但有以下例外：
1．&& 含有特定“DigitMap
Completion”事件的包中，除结束事件本身外的事件是不独立通报的；
触发部分匹配结束事件的事件不会被识别，因而直到它随识别到“DigitMap
Completion”事件而被再处理之前，是不会有副作用的。
如果一个包中包含“DigitMap Completion”事件，当Event
描述符中的某个事件包含该包的名称及一个通配的属性名时，就会激活包含的DigitMap；当然，根据3.2.12.6的内容，这个事件应包含EventDM
域。如果该包还包含拨号事件自身，按这种形式指定的事件会引起检测到单个事件时也会向MGC 报告。
当拨号方案如下所示时：
1．&& 11X 紧急呼叫和特服呼叫；
2．&& 6XXXXXXX 本地号码
3．&& 0 长途号码
4．&& 00 国际长途
5．&& *xx 补充业务
如果收集拨号字符时采用“DTMF Detection”（PackageId:dd）包（dd
包的定义参见RFC3015的附录E.6），则该拨号方案的DigitMap 如下所示：
{11x |6 XXXXXXX|0[1—9]XXX. |00XXX. |Exx}
H.248媒体网关MG要开通业务必须首先注册到软交换MGC上去，MG注册成功后，MGC将对空关联中的MG的所有半永久终端的属性进行修改。指示MG
检测用户的摘机事件。此时，此终端可以接收或者发起呼叫。
向MGC注册流程
H.248网关要开通业务，首先是要到ZXSS10
SS1a/SS1b上注册。目前我们支持的协议栈版本为1.0，如果对端的版本大于或者小于该版本，网关响应406“Version Not
Support”,注册失败，其注册流程如图 3‑1所示：
1 网关注册流程
1． 事件1：H.248网关向ZXSS10 SS1a/SS1b发送SVC_CHG_REQ消息进行注册，文本描述如下：
（1）& MEGACO/1&
[10.66.100.12]:2944&&&&&&&&&&&&&&
（2）& T = 3{
（3）& C = －{
（4）& SC = ROOT {
（5）& SV {
（6）& MT = RS, RE = 902 }}}
第一行：MEGACO协议版本号，版本为1。消息由MG发往MGC，MG的IP地址是[10.66.100.12]，端口号是2944。
第二行：事务ID号为3
第三行：此时未创建关联，因为关联为“－“，表示空关联
第四行：ServiceChange命令。终端ID为ROOT，表示命令作用于整个网关
第五行：ServiceChange命令封装的ServiceChange描述符
第六行：ServiceChange描述符封装的参数。表示ServiceChangeMethod为Restart，ServiceChangeReason为热启动
2． 事件2：ZXSS10 SS1a/SS1b收到MG 的注册消息后，回送响应给MG。下面是SVC_CHG_REPLY
响应的文本描述：
MEGACO/1 [10.66.100.2]:2944
P=3{C= - {SC=ROOT{SV{}}}}
第一行：MEGACO 协议，版本为1。MGC-MG，MGC 的IP
地址和端口号为：[10.66.100.2]:2944。
第二行：事务ID 为“3”，关联为空。ServiceChange 命令作用于整个网关。表示MGC 已经收到MG
发过来的注册事务，并且响应注册成功。
H.248媒体网关退出服务，要向MGC或者是ZXSS10 SS1a/SS1b进行注销，其注销流程如图3-2所示：
3.2 网关注销流程
1． 事件1：H.248网关向ZXSS10
SS1a/SS1b发送SVC_CHG_REQ消息进行注销，该命令中ServiceChangeMethod设置为Graceful或者Force，文本描述如下：
（1）& MEGACO/1 10.66.100.12]:2944
（2）& T= 9998
（3）& {C= - {
（4）& SC = ROOT {
（5）& SV {
（6）& MT= FO, RE = 905}}}}
第一行：MEGACO协议版本号，版本为1。消息由MG发往MGC，MG的IP地址是[10.66.100.2]，端口号是2944
第二行：事务ID号为9998
第三行：此时未创建关联，因为关联为“－“，表示空关联
第四行：ServiceChange命令。终端ID为ROOT，表示命令作用于整个网关
第五行：ServiceChange命令封装的ServiceChange描述符
第六行：ServiceChange描述符封装的参数。表示ServiceChangeMethod为force，ServiceChangeReason为终端退出服务
2． 事件2：ZXSS10 SS1a/SS1b 回送证实消息。下面是SVC_CHG_REPLY 响应的文本描述：
MEGACO/1 [10.66.100.2]:2944
P=9998{C= - {SC=ROOT{ER=505}}}
第一行：MEGACO 协议，版本为1。MGC-MG，MGC 的IP 地址和端口号为：
[191.169.150.170]:2944。
第二行：事务ID 为“9998”，关联为空。ServiceChange 命令作用于整个网关。Error
描述符为“505”，表示网关没有注册。
基本呼叫流程的内容主要包括正常呼叫流程和异常呼叫流程。正常呼叫为端到端用户的呼叫接续、通话、挂机（分为主叫挂机和被叫挂机）；异常呼叫流程包括被叫用户忙、被叫用户号码为空号、被叫无应答三种情况。
图 4-1 完整呼叫流程图
注意：在MG中的终端
在MG中包含有物理终端和临时终端，物理终端的TIDNAME是USER0到USER2，依次对应MG的三个普通电话接口。临时终端的TIDNAME是RTP/00000到RTP/00002。
事件1：主叫MG对应的主叫用户摘机，网关通过NTFY_REQ命令把摘机事件通知发送给SS1a/SS1b，SS1a/SS1b收到用户摘机消息后，回应答消息。
（1） NTFY_REQ消息文本描述如下：
MEGACO/1& [10.66.100.12]:2944
2）&& Transaction = 49414
3）&& { Context = -{
4）&& Notify =
USER0&&& {
5）&& ObservedEvents = 2000{
31100：al/of&&&&&
第一行：MEGACO协议版本号，版本为1。消息由MG发往MGC，MG的IP地址是[10.66.100.2]，端口号是2944
第二行：事务ID号为49414
第三行：此时未创建关联，因为关联为“－“，表示空关联
第四行：通知命令Notify，该命令作用对象为USER0，对应的号码为#
第五行：notify命令封装的描述符ObservedEvents，其中事件号为2000，与触发NTFY_REQ命令的请求命令的RequestID保持一致，将两者关联，al/of表示摘机事件，事件发生时间为31100。
（2）SS1a/SS1b回应答消息，NOTY_REPLY消息文本描述如下：
1）&& MEGACO/1
[10.66.100.2]:2944
2）&& P=49414
3）&& C=-{
4）&& N=USER0}}
2．&& 事件2：
SS1a/SS1b收到主叫用户摘机事件以后，通过MOD_REQ命令指示网关给终端发送拨号音，并把拨号计划DigtalMap发送给H.248网关，要求根据DigtalMap拨号计划收号，并同时检测挂机和拍叉簧事件的发生。网关设备回复相应的响应消息。
（1）MEGACO/1 [10.66.100.2]:2944
（2）T=25218{
（3）MF=USER0{
（4）M=DM{（（[2-9]xxxxxx|13xxxxxxxxx|0xxxxxxxxx|9xxxx|1[0124-9]x|E|x.F
|[0-9EF].L） F025xxxxx|FF）},E=2002{dd/ce{ DM=DM
}（收号）,al/on（挂机）,al/fl（拍叉簧
）},SG{cg/dt}（拨号音）}}}
第一行：MEGACO 协议的版本为1。消息发送者标识（MID），此时为MGC的IP
地址和端口号：[10.66.100.2]:2944。
第二行：事务ID 为“25218”，该事务ID 用于将该请求事务和其触发的响应事务相关联。此时，该事务封装的关联为空。
第三行：Modify 命令，用来修改终端USER0的特性、事件和信号。
第四行：DigitMap描述符，SS下发给网关设备。拨号计划dmap1。其中，“[2-9]xxxxxx”表示用户可以拨2～9
中任意一位数字开头的任意7 位号码；“13xxxxxxxxx”表示13 开头的任意11 号码；“0xxxxxxxxx”表示0
开头的任意10 位号码；“9xxxx”表示9 开头的任意5 位号码；“1[0124-9]x”表示1 开头，3
以外的十进制数为第二位的任意3
位号码；“E”表示字母“E”；“x.F”；“[0-9EF].L”表示拨以数字0～9、字母“E”、“F”开头的任意位等长定时器超时之后就会上报。MGC
请求MG 监视终端A0 发生的以下事件：事件一，根据Digit
Map规定的拨号计划（dmap1）收号。事件二，请求网关检测模拟线包（al）中的所有事件。
网关设备的应答信息，文本如下：
&&&&&&&&&&
MEGACO/1& [10.66.100.12]:2944
&&&&&&&&&&
Reply = 25218 { Context = - {
&&&&&&&&&&
Modify = USER0} }
事件3：用户拨号，终端对所拨号码进行收集，并与刚才下发的DigtalMap进行匹配，匹配成功，通过Notify命令发送给SS，SS回复给网关NTFY_REPLY消息。
NTFY_REQ消息文本如下：
（1）& MEGACO/1&
[10.66.100.12]:2944
（2）& Transaction = 49415{Context = -
（3）& { Notify = USER0{ ObservedEvents =
2002（与上面事件号一致） {31500 : dd/ce
{ ds = "F" （所拨电话号码）, （#）& Meth
= UM （明确匹配）} } } } }
第一行：MG-MGC。MG 的IP 地址和端口号为：[10.66.100.12]:2944。
第二行：事务ID
为49415。此时，该事务封装的关联为空。SS1a/1b的实现方式为主叫拨号之后才建立关联，以免主叫摘机不拨号、所拨的号码不存在等原因引起的资源浪费。
第三行：Notify 命令，该命令作用于终端USER0。观测到的事件描述符。RequestID
为“2002”，与上文MOD_REQ 命令的RequestID 相同，表示该通知由此MOD_REQ 命令触发。上报DigitMap
事件 的时间戳。“31500”表示2002年4 月3 日早上8 时13 分15
秒。终端USER0观测到的事件为DTMF 检测包中的DigitMap Completion 事件。该事件的两个参数为：DigitMap
结束方式（Meth）和数字串（ds）。DigitMap 结束方式（Meth）有3 个可能值：
“UM”：明确匹配。如果恰好只剩下一个候选拨号序列且完全匹配，就会产生一个“明确匹配”的DigitMapCompletion
“PM”：部分匹配。在每一步中，等待下一拨号事件的定时器将采用缺省的定时原则，或者参照一个或多个拨号事件序列中明确规定的定时器。若定时器超时，且不能与候选拨号事件集完全匹配或没有候选拨号事件可以匹配，则报告“定时器超时，部分匹配”。
“FM”：完全匹配。若定时器超时，且能与候选拨号事件集中的一个拨号事件完全匹配，则报告“定时器超时，完全匹配”。数字串“ds”，此时表示用户终端所拨的号码为“F”
NTFY_REPLY响应文本如下：
MEGACO/1 [10.66.100.2]:2944
Rply=49415{
Context=-{Notify=USER0}}
事件4：MGC在MG中创建一个新context，并在context中加入TDMtermination 和RTP
termination。MG返回ADD_REPLY响应，分配新的连接描述符，新的RTP终端描述符。
ADD_REQ消息的文本如下所示：
（1）MEGACO/1 [10.66.100.2]:2944
（2）Transaction = 10003 {Context = $ {
（3）Add = USER0,
（4）Add = $ {
（5）Media {Stream = 1 {LocalControl {Mode = ReceiveOnly,nt/jit=40
（6）Local {
&&&&&&&&&&
&&&&&&&&&&
c=IN IP4 $
&&&&&&&&&&
m=audio $ RTP/AVP 4 a=ptime:30}}}}}}
第一行：MGC-MG。MGC的IP地址和端口号为：[10.66.100.2]:2944。
第二行：事务ID为“10003”。“$”表示请求MG创建一个新关联。由于目前关联还不确定，所以使用“$”。
第三行：ADD命令，将终端USER0加入新增的关联。
第四行：ADD 命令，将某个RTP 终端加入新增关联。其中，新的RTP 终端为临时终端，由于RTP
终端的描述符没有确定，所以使用“$”。
第五行：媒体描述符。流号为1，LocalControl为本地描述符，给出了与此媒体流相关的参数，此时终端USER0为只收模式，nt/jit=40，表示Network
Package 中的抖动缓存最大值为40 毫秒。
第六行：Local描述符。MGC 建议新的RTP 终端采用一系列本地描述参数。“v=0” 表示SDP 协议版本为0。“c=IN
IP4 $”表示RTP 终端的关联信息，关联的网络标识为Internet，关联地址类型为IP4，“$”表示目前本地IP
地址未知。“m=audio $ RTP/AVP 4”表示MGC 建议新的RTP 终端的媒体描述，“audio”表示RTP
终端的媒体类型为音频，“$”表示RTP
终端的媒体端口号目前未知，“RTP/AVP”为传送层协议，其值和“c”行中的地址类型有关，对于IP4
来说，大多数媒体业务流都在RTP/UDP 上传送，已定义如下两类协议：RTP/AVP，音频/视频应用文档，在UDP
上传送；Udp，UDP 协议。“4”对于音频和视频来说，就是RTP 音频/视频应用文档中定义的媒体静荷类型。表示MGC 建议RTP
终端媒体编码格式采用G.711A。H.248 协议规定RTP 静荷类型至编码的映射关系为：G.711U = 0；G.726 =
2；G.723，G.7231 = 4；G.711A = 8；G.729，G.729A= 18。
ADD_REPLY消息文本如下所示：
（1）MEGACO/1& [10.66.100.12]:2944
（2）Reply = 10003 {
（3）Context = 2000 {Add = USER0,Add=RTP/00000{
（4）Media {
&&&&&&&&&&
Stream = 1 {
&&&&&&&&&&
&&&&&&&&&&
&&&&&&&&&&
c=IN IP4 10.66.100.12
&&&&&&&&&&
m=audio 2222（rtp媒体端口号） RTP/AVP（媒体协议） 4（媒体编码格式）
&&&&&&&&&&
a=ptime:30
&&&&&&&&&&
a=recvonly}}}}}}
在此回复消息中，已经建立了关联，Context＝2000，其中选择的终端为USER0和RTP/00000。网关设备在利用SS发送的ADD_REQ消息中的SDP描述模板，把自己的媒体信息上报给SS，这些媒体信息包括自己的IP地址：c=IN
IP4 10.66.100.12，RTP流的端口号和网关采用的编解码方式：m=audio 2222 RTP/AVP
4，时延a=ptime:30等信息。
事件5：MGC进行被叫号码分析后，确定被叫端，设置被叫测媒体参数。网关返回ADD_REPLY响应，分配新的连接描述符，新的RTP终端描述符。
ADD_REQ消息文本描述如下
（1）& MEGACO/1&
[10.66.100.2]:2944
（2）& Transaction = 50003 {Context = $ {
&&&&&&&&&&
Add = USER1& {
（3）& Media {Stream = 1 {LocalControl
&&&&&&&&&&
{Mode=SendReceive} }},
（4）& Events={1234{al/of},Signals
{al/ri}（振铃音）},
（5）& Add& = ${
&&&&&&&&&&
Media {Stream =1
&&&&&&&&&&
{LocalControl
&&&&&&&&&&
{Mode=SendReceive,
&&&&&&&&&&
nt/jit=40 ; in ms}, Local {
&&&&&&&&&&
&&&&&&&&&&
c=IN IP4 $
&&&&&&&&&&
m=audio $ RTP/AVP 4
&&&&&&&&&&
a=ptime:30（被叫侧媒体信息模板）},
&&&&&&&&&&
&&&&&&&&&&
&&&&&&&&&&
c=IN IP4 10.66.100.12
&&&&&&&&&&
m=audio 2222 RTP/AVP 4
&&&&&&&&&&
a=ptime:30（主叫侧媒体信息）} ;}}}}}
第一行：MGC-MG。MGC的IP地址和端口号为：[10.66.100.2]:2944。
第二行：事务ID为“50003”。“$”表示请求MG创建一个新关联。由于目前关联还不确定，所以使用“$”。
第三行：媒体描述符。流号为1，LocalControl为本地描述符，给出了与此媒体流相关的参数，此时终端USER0为只收模式。
第四行：事件号为1234，检测有无摘机事件，并且通过Signals {al/ri}给被叫用户放震铃音。
第五行：在被叫侧添加RTP资源，media为媒体描述符，其中定义了媒体资源参数。Mode=SendReceive,表明被叫侧媒体资源为收发模式，设置抖动为40ms（nt/jit=40）。SS下发SDP模板给被叫侧终端，让其上报自己的媒体资源信息，并将主叫用户信息通过Remote描述符传递给被叫用户。
ADD_REPLY响应消息文本描述如下：
MEGACO/1 [10.66.100.13]:2944
Reply = 50003 {
Context = 5000 {
Add = USER1,
Add = RTP/00001{
Stream = 1 {
c=IN IP4 10.66.100.13
m=audio 1111 RTP/AVP 4
ADD_REQ的响应消息。在被叫侧建立关联域和RTP终端，并将本端媒体资源信息封装在SDP描述，通过Media描述符递交给SS。
事件6：MGC发送MOD_REQ命令给主叫侧终端，修改主叫侧终端的属性并请求MG给主叫侧终端放回铃音。MG 返回MOD_REPLY
响应进行确认，同时给主叫侧终端放回铃音。
Mod_REQ消息文本消息如下：
&&&&&&&&&&
MEGACO/1 [10.66.100.2]:2944
&&&&&&&&&&
Transaction = 10005 {
&&&&&&&&&&
Context = 2000 {
&&&&&&&&&&
Modify = USER0 {
&&&&&&&&&&
Signals {cg/rt}（回铃音）},
&&&&&&&&&&
Modify = RTP/00000 {
&&&&&&&&&&
&&&&&&&&&&
Stream =1 {Remote {
&&&&&&&&&&
&&&&&&&&&&
c=IN IP4 10.66.100.13
&&&&&&&&&&
m=audio 1111 RTP/AVP 4（被叫端的媒体信息）}} ;}}}}
MOD_REPLY文本消息如下：
&&&&&&&&&&
MEGACO/1& [10.66.100.12]:2944
&&&&&&&&&&
Reply = 10005
&&&&&&&&&&
{& Context = 2000
&&& Modify =
&&& Modify =
RTP/00000}}
事件7：被叫侧终端用户摘机，被叫侧网关设备把摘机事件通过NTFY_REQ 命令通知MGC。MGC 返回NTFY_REPLY
响应进行确认。
（1）& NTFY_REQ命令的文本描述如下：
&&&&&&&&&&
MEGACO/1 [10.66.100.13]:2944
&&&&&&&&&&
Transaction = 50005 {Context = 5000 {
&&&&&&&&&&
Notify = USER1 {ObservedEvents =1234 {
&&&&&&&&&&
20002:al/of}}}}
（2）& NTFY_REPLY命令的文本描述如下：
&&&&&&&&&&
MEGACO/1& [10.66.100.1]:2944
&&&&&&&&&&
Reply = 50005 {
&&&&&&&&&&
Context = - {
&&&&&&&&&&
Notify = USER1}}
事件8：MGC修改被叫侧终端用户半永久性资源的属性，设置需要检测的事件为挂机事件，并且停止放任何信号音。
（1）& MOD_REQ命令的文本描述如下：
&&&&&&&&&&
MEGACO/1& [10.66.100.2]:2944
&&&&&&&&&&
Transaction = 10006 {
&&&&&&&&&&
Context = 5000 {
&&&&&&&&&&
Modify = USER1 {
&&&&&&&&&&
Events = 1235 {al/on},
&&&&&&&&&&
Signals { } ; to turn off ringing }}
（2）& MOD_REPLY命令的文本描述如下：
&&&&&&&&&&
MEGACO/1 [10.66.100.13]:2944
&&&&&&&&&&
Reply = 10006 {
&&&&&&&&&&
Context = 5000
&&&&&&&&&&
{Modify = USER1,
&&&&&&&&&&
Modify = RTP/00001}}
事件9：Modify命令，修改主叫侧用户的属性，终端用户回复信息给SS。
（1）& MOD_REQ命令的文本消息如下：
&&&&&&&&&&
MEGACO/1 [10.66.100.2]:2944
&&&&&&&&&&
Transaction = 10006 {
&&&&&&&&&&
Context = 2000 {
&&&&&&&&&&
Modify = RTP/00000 {
&&&&&&&&&&
&&&&&&&&&&
Stream = 1 {
&&&&&&&&&&
LocalControl {
&&&&&&&&&&
Mode=SendReceive}}}},
&&&&&&&&&&
Modify = USER0 {
&&&&&&&&&&
Signals { }}}}
（2）& MOD_REPLY命令的文本消息如下：
MEGACO/1& [10.66.100.12]:2944
Reply = 10006 {
Context = 2000
{Modify = RTP/00000,
Modify = USER0}}
至此，主叫终端和被叫终端都知道了本端和对端的连接信息，呼叫建立条件已经具备，可以正常通话了。
事件10：收到被叫用户的挂机事件，MGC 给MG 发送NTFY_REQ
命令修改被叫用户属性，请求网关进一步检测终端发生的事件，如摘机事件等。MG 发送NTFY_REPLY 响应确认已接收MOD_REQ
命令并执行。
（1）& MOD_REQ命令的文本消息如下：
MEGACO/1 [10.66.100.13]:2944
Transaction = 50008 {
Context = 5000 {
Notify = USER1
{ObservedEvents =1235 {
20002:al/on} } } }
（2）& SUB_REPLY命令的文本消息如下：
MEGACO/1& [10.66.100.1]:2944
Reply = 50008 {
Context = -
{Notify = USER1}}
事件11：MGC收到被叫用户的挂机事件后，将向网关设备发送SUB_REQ 命令，把关联的所有的半永久型终端和临时的RTP
终端删除，从而删除关联，拆除呼叫。网关设备返回SUB_REPLY 响应确认已接收SUB_REQ命令
（1）& SUB_REQ命令的文本描述如下：
MEGACO/1& [10.66.100.1]:2944
Transaction = 50009 {
Context = 5000 {
Subtract = USER1
{Audit{Statistics}},
Subtract = RTP/00001
{Audit{Statistics}}}}
（2）& SUB_REPLY命令的文本描述如下：
MEGACO/1 [10.66.100.13]:2944
Reply = 50009 {
Context = 5000 {
Subtract = USER1 {
Statistics {
nt/os=45123, ;
nt/dur=40 ; }},
Subtract = RTP/00001 {
Statistics {
rtp/ps=1245,
nt/os=62345,
rtp/pr=780,&
nt/or=45123,
rtp/pl=10,
rtp/jit=27,
rtp/delay=48 }}}}
事件12：SS将被叫挂机消息转发给主叫用户，主叫用户收到被叫用户的挂机事件后，将向网关设备发送SUB_REQ
命令，把关联的所有的半永久型终端和临时的RTP 终端删除，从而删除关联，拆除呼叫。网关设备返回SUB_REPLY
响应确认已接收SUB_REQ命令。
（1）& SUB_REQ命令的文本描述如下：
&&&&&&&&&&
MEGACO/1& [10.66.100.1]:2944
&&&&&&&&&&
Transaction = 50009 {
&&&&&&&&&&
Context = 2000 {
&&&&&&&&&&
Subtract = USER0
&&&&&&&&&&
{Audit{Statistics}},
&&&&&&&&&&
Subtract = RTP/00000
&&&&&&&&&&
{Audit{Statistics}}}}
（2）& SUB_REPLY命令的文本描述如下：
&&&&&&&&&&
MEGACO/1 [10.66.100.12]:2944
&&&&&&&&&&
Reply = 50009 {
&&&&&&&&&&
Context = 2000 {
&&&&&&&&&&
Subtract = USER0 {
&&&&&&&&&&
Statistics {
&&&&&&&&&&
nt/os=45123, ;
&&&&&&&&&&
nt/dur=40 ; }},
&&&&&&&&&&
Subtract = RTP/00000 {
&&&&&&&&&&
Statistics {
&&&&&&&&&&
rtp/ps=1245,
&&&&&&&&&&
nt/os=62345,
&&&&&&&&&&
rtp/pr=780,&
&&&&&&&&&&
nt/or=45123,
&&&&&&&&&&
rtp/pl=10,
&&&&&&&&&&
rtp/jit=27,
&&&&&&&&&&
rtp/delay=48 }}
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。