Erlang/OTP Megaco 编解码完全指南：内部形式、六种编码器与版本协商

Erlang/OTP Megaco 编解码完全指南内部形式、六种编码器与版本协商【免费下载链接】otpErlang/OTP项目地址: https://gitcode.com/gh_mirrors/ot/otpMegaco/H.248 是媒体网关控制协议的事实标准而 Erlang/OTP 的 megaco 应用提供了完整的协议栈实现。本文基于 lib/megaco/doc/guides/megaco_encode.md 展开系统讲解 megaco 栈的内部消息表示、文本与二进制两类编码体系、六种可用编解码模块的选型与配置以及多协议版本的处理策略。读完本文你将掌握从构造内部记录、选择编码器、配置 termination id 层级到动态版本检测的完整实战路径。协议标准合规性当前版本的 megaco 栈实现了三种协议版本其定义分别来源于对应的标准文档Megaco/H.248 版本 1基于 RFC3525并按 Implementors Guide 10-13 版更新Megaco/H.248 版本 2基于 draft-ietf-megaco-h248v2-04同样按 Implementors Guide 10-13 版更新Megaco/H.248 版本 3基于 ITU H.248.1 (09/2005)。仓库中保留了相应的标准文档供对照rfc3525.txt、draft-ietf-megaco-h248v2-04.txt 以及 implementors_guide_v10-13.pdf。ASN.1 语法源文件则位于 lib/megaco/src/binary/每个版本对应一份MEDIA-GATEWAY-CONTROL-vN.asn。消息的内部形式Internal Formmegaco 栈对文本与二进制两种编码使用同一套内部表示形式。这套表示深受 ASN.1 编解码器内部格式的影响规则如下ASN.1 构造内部形式表示SEQUENCE OF列表listCHOICE二元组标签tagged tuplesize 2SEQUENCE记录record定义于 megaco_message_v1.hrlOPTIONAL记录中默认值为asn1_NOVALUE的普通字段OCTET STRING无符号整数列表ENUMERATED单个原子atomBIT STRING原子列表BOOLEAN原子true或falseINTEGER整数IA5String整数列表每个整数为对应字符的 ASCII 值NULL原子NULL若要彻底掌握内部形式需要获取一份 Megaco/H.248 协议的 ASN.1 规范再应用上表规则逐项转换关于 ASN.1 到内部形式映射语义的细节可参考 Erlang/OTP 中 ASN.1 编译器的文档。一个关键特例内部形式中并不使用TerminationId记录而是被 megaco_term_id 记录替代该记录定义于 megaco.hrl。从源码注释可以看出二者的对应关系例如文本形式的ROOT对应{megaco_term_id, false, [[$r,$o,$o,$t]]}通配符*对应{megaco_term_id, true, [[$*]]}而R1/101/1对应三级路径[[$r,$1],[$1,$0,$1],[$1]]。分层命名中的通配匹配语义某级通配是否递归匹配所有下级正是通过内部形式中末尾层级是否为空列表来表达的。两种文本编码风格pretty 与 compactMegaco/H.248 标准同时定义了纯文本编码与二进制编码ASN.1 BER。文本编码中实现者可以选择长短关键字混用并可加入空白提升可读性。megaco 栈由此区分两种文本风格compact紧凑使用最短关键字、无任何可选空白pretty美化缩进良好、使用长关键字风格与协议规范中的文本示例一致。下面同一消息的 pretty 版本长关键字、缩进MEGACO/1 [124.124.124.222] Transaction 9998 { Context - { ServiceChange ROOT { Services { Method Restart, ServiceChangeAddress 55555, Profile ResGW/1, Reason 901 Cold Boot } } } }以及 compact 版本短关键字、无缩进!/1 [124.124.124.222] T9998{C-{SCROOT{SV{MTRS,AD55555,PFResGW/1,RE901 Cold Boot}}}}从程序员视角消息的构造方式是先构建一组ActionRequest记录再通过 API 的发送函数送出Prof #ServiceChangeProfile{profileName resgw, version 1}, Parm #ServiceChangeParm{serviceChangeMethod restart, serviceChangeAddress {portNumber, 55555}, serviceChangeReason 901 Cold Boot, serviceChangeProfile Prof}, Req #ServiceChangeRequest{terminationID [?megaco_root_termination_id], serviceChangeParms Parm}, Actions [#ActionRequest{contextId ?megaco_null_context_id, commandRequests {serviceChangeReq, Req}}], megaco:call(ConnHandle, Actions, Config).其中?megaco_root_termination_id与?megaco_null_context_id均在 megaco.hrl 中预定义根终止 ID 与空上下文 ID 0。上述请求对应的完整内部形式打印输出如下{MegacoMessage, asn1_NOVALUE, {Message, 1, {ip4Address,{IP4Address, [124,124,124,222], asn1_NOVALUE}}, {transactions, [ {transactionRequest, {TransactionRequest, 9998, [{ActionRequest, 0, asn1_NOVALUE, asn1_NOVALUE, [ {CommandRequest, {serviceChangeReq, {ServiceChangeRequest, [ {megaco_term_id, false, [root]}], {ServiceChangeParm, restart, {portNumber, 55555}, asn1_NOVALUE, {ServiceChangeProfile, resgw, version 1}, 901 MG Cold Boot, asn1_NOVALUE, asn1_NOVALUE, asn1_NOVALUE } } }, asn1_NOVALUE, asn1_NOVALUE } ] } ] } } ] } } }对照 megaco_message_v1.hrl 中的记录定义MegacoMessage、Message、TransactionRequest、ActionRequest等可以看到SEQUENCE与记录字段一一对应、可选字段缺省为asn1_NOVALUE、megaco_term_id替代了标准 TerminationId 等全部映射规则的实际落地。六种编码/解码模块总览megaco 栈共提供六个编解码模块模块编码格式说明megaco_pretty_text_encoderpretty 文本编码为美化文本解码时 pretty 与 compact 均可megaco_compact_text_encodercompact 文本编码为紧凑文本解码时 pretty 与 compact 均可megaco_binary_encoderASN.1 BERBER 编码器中速度最快官方推荐二进制编解码器megaco_ber_encoderASN.1 BER通用 BER 编解码megaco_per_encoderASN.1 PER注意PER 不在 Megaco 标准之内megaco_erl_dist_encoderErlang 分布式格式冗长但编解码极快同样不属于 Megaco 标准从源码结构看文本类编码器在 lib/megaco/src/text/ 中按版本拆分为megaco_pretty_text_encoder_v1/v2/v3与megaco_compact_text_encoder_v1/v2/v3解析依赖 yecc 生成的megaco_text_parser_vN.yrl与扫描器 megaco_text_scanner.erl二进制类编码器在 lib/megaco/src/binary/ 中其中 megaco_binary_encoder.erl 按协议版本分派到对应的 ASN.1 模块megaco_ber_media_gateway_control_v1/v2/v3与转换器megaco_binary_transformer_v1/v2/v3并借助megaco_binary_name_resolver_vN与 megaco_binary_term_id.erl 完成 termination id 的二进制解析。所有编码器均声明了-behaviour(megaco_encoder)实现统一的回调接口。配置 Erlang 分布格式编码模块megaco_erl_dist_encoder该模块的encoding_config可取以下值[]编码为标准 Erlang 分布格式冗长但编解码极快[megaco_compressed]先做一次内部变换再编码为标准分布格式体积更小但编解码总耗时略增详见 性能章节[{megaco_compressed, Module}]与megaco_compressed等价但由用户提供自己的压缩模块该模块必须实现m:megaco_edist_compress行为参考实现见 megaco_edist_compress.erl分发封装见 megaco_erl_dist_encoder.erl[compressed]编码为标准分布格式的压缩形态体积较小但编解码速度较慢。配置文本编码模块Erlang 扫描器与 Flex 扫描器使用文本编码时实际由两个不同的配置控制底层软件的选择[]空列表表示使用 Erlang 扫描器scanner[{flex, port()}]使用 flex 扫描器解码未针对 SMP 优化见 初始配置[{flex, ports()}]使用 flex 扫描器解码针对 SMP 优化同样见 初始配置。Flex 扫描器是以 C 语言编写的 linked-in driver 形式的 Megaco 扫描器源码见 megaco_flex_scanner_drv.flex.srcErlang 侧接口见 megaco_flex_scanner.erl。有两种方式使其工作方式一让 megaco 栈自行启动 flex 扫描器加载驱动在 megaco 应用的 Erlang 系统配置文件中加入{scanner, flex}或类似指令通过megaco:system_info/1Item text_config取回编码配置将编码配置更新到 receive handle 的encoding_config字段。这种方式的好处是驱动与端口的启动、持有和监督全部由 Megaco 负责。方式二由 megaco 客户端用户自行启动 flex 扫描器启动 flex 扫描器时会创建一个指向 linked-in driver 的端口该端口必须由一个进程持有且该进程绝不能死掉否则端口也会随之终止。因此创建一个常驻进程并确保其被监督一旦死亡能被察觉让该进程调用megaco_flex_scanner:start/0,1启动扫描器取回编码配置并在初始化megaco_receive_handle时设置encoding_config字段将megaco_receive_handle传给传输模块。megaco_receive_handle记录定义在 megaco.hrl包含local_mid、encoding_mod、encoding_config、send_mod以及默认值为dynamic的protocol_version字段——后文版本协商正是围绕这个字段展开的。配置二进制编码模块termination id 层级结构使用二进制编码时必须指明 termination id 的层级结构每个层级占用的比特数[native]跳过变换阶段解码得到的消息不会转换成内部形式[integer()]包含每一级层级的位数bits的列表例如[3,8,5,8]t:integer/0单字节8 位层级的数量目前会被转换为上一种配置例如3等价于[8,8,8]。层级配置之所以必要是因为二进制编码BER中 termination id 按固定位宽逐级编码。这与 megaco.hrl 中megaco_term_id的二进制映射注释相互印证例如一个完全确定的二进制 termination id#TerminationID{wildcard [], id [2#00000001, 2#0011110, 2#00000000]}在内部被表示为三个 8 位层级、每级展开为字符列表而带通配的寻址则通过wildcard位图与内部形式中的?megaco_all$*、?megaco_choose$$字符对应。处理 Megaco 协议版本处理不同编码版本有两种途径动态版本检测仅适用于入站消息或在连接信息中显式设置版本。入站消息动态版本检测将megaco_receive_handle中的协议版本设置为dynamic这也是默认值。该方式仅对支持版本部分解码的编解码器有效目前包括文本编码以及ber_bin即megaco_binary_encoder与megaco_ber_bin_encoder。解码器会从消息本身探测实际版本然后选用对应的解码器。这一点与 megaco_encoder.erl 中decode_message/3回调的约定一致当Version参数为dynamic时解码器应从消息本身推导出版本当Version为整数时则按该预期版本直接解码。显式版本在megaco_receive_handle中显式设置实际协议版本。从版本 1 开始当初始 ServiceChange 完成并协商出版本 2 后通过megaco_tcp:upgrade_receive_handle/2或megaco_udp:upgrade_receive_handle/2将传输进程control_pid的 receive handle 升级到版本 2。需要注意如果使用udp同一个传输进程可能服务于多个连接这可能导致升级无法进行。对于不支持版本部分解码的编解码器目前为megaco_ber_encoder与megaco_per_encoderdynamic设置会回退为版本 1。出站消息更新连接信息中的protocol_version或者在发送消息时向 Options 中添加{protocol_version, integer()}项来临时覆盖版本见megaco:call/3与megaco:cast/3。注意临时覆盖不会影响栈自主发送的消息它们始终使用连接信息中的protocol_version。编码器回调接口所有编码器模块都必须实现megaco_encoder行为定义见 megaco_encoder.erl。该行为要求导出以下核心回调encode_message(EncodingConfig, Version, Message)将#MegacoMessage{}记录编码为二进制decode_message(EncodingConfig, Version, Bin)解码消息Version可为dynamic或整数decode_mini_message/3对消息做最小化解码用于快速预判消息类型与版本encode_transaction/3、encode_action_requests/3、encode_action_request/3、encode_action_reply/3对事务与动作进行局部编码version_of/2判断消息使用的协议版本。行为中还定义了一系列消息相关数据类型例如transaction()为{transactionRequest, ...} | {transactionPending, ...} | {transactionReply, ...} | {transactionResponseAck, ...} | {segmentReply, ...}五元选择。一个值得注意的细节TransactionReply记录在版本 3 中比版本 1/2 多出两个字段因此行为注释中明确说明其类型无法用单一的 Erlang 类型定义表达这也再次印证了不同协议版本对内部记录形态的实际影响。小结megaco 栈通过一套内部形式 多种编解码器的设计让上层应用只需面向 megaco_message_v1.hrl 中定义的记录编程即可在 pretty/compact 文本、BER 二进制、乃至非标准的 PER 与 Erlang 分布格式之间自由切换。选型时建议对等互通优先使用标准文本编码或推荐的megaco_binary_encoder进程内或集群内传输可选用极快的megaco_erl_dist_encoder跨版本互通则善用dynamic版本检测与upgrade_receive_handle/2组合策略。相关的运行与性能细节可进一步阅读 megaco_run.md 与 megaco_performance.md。【免费下载链接】otpErlang/OTP项目地址: https://gitcode.com/gh_mirrors/ot/otp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考