摘要

  • RFC 3441 的有序 AAL2 配置交集产生兼容清单，却不会自动把每项业务分配到某个配置行。
  • vsel、dsel 和 fsel 表达业务与配置行之间的偏好映射；它们不能证明发送端此刻用了哪一行、ATM 承载已经建立，或媒体已经抵达呼叫者。

编解码器清单看似只是细节，直到两台网关必须据此共同承载一次语音通话。AAL2 配置包含若干行，每行提供编解码与分组化信息。呼叫控制方可以按优先级提出配置清单；每台网关也有自己的本地支持清单。找出交集只是第一步，交集并没有决定被选配置中的每一行要承载什么业务。

RFC 3441 为 Media Gateway Control Protocol（MGCP）定义 ATM 扩展包，处理这道边界。MGCP 允许外部呼叫代理控制媒体网关端点。扩展包加入了 ATM 承载类型、适配层、业务与流量参数，以及编解码和配置协商等本地连接选项。它是一份 Informational 文档：语法说明符合规范的交换能够表示什么，不说明哪些产品实现了这些选项，也不证明有多少通话用过它们。

关键区别先出现在配置清单上。网关的 L-list 表示本地支持；呼叫代理可以提交按偏好排序的 C-list；另一端的会话描述符则带来 R-list。RFC 3441 要求网关按呼叫方向和本地策略执行有序交集。交集里留下某项配置，证明它在这些清单和策略下兼容；这不是承载电路、业务选择或媒体已经通过的证明。

规范的例子展示了中间结果。网关 1 支持 custom 100, itu 3, itu 1, itu 8，其呼叫代理给出 itu 8, itu 9, atmf 7, itu 3, itu 1, custom 100。起始端策略产生 itu 8, itu 3, itu 1, custom 100，并把它作为远端清单发给网关 2。网关 2 再与本地支持项及呼叫代理清单求交，得到 itu 3, itu 1，最后选中 itu 3。第一台网关偏好的 itu 8 并未约束接收端必须采用它。

配置行中的业务映射是第二个问题。起始呼叫代理把 vsel、dsel 绑定到第一项 itu 8，但它们并不描述后来选中的 itu 3，接收端因此不能原样照搬。网关 2 使用适用于 itu 3 的本地映射，再返回自己的指示：语音对应某些编解码行；语音带数据——例子中也包含传真——对应另一组行。配置交集并未完成业务分配；最终配置决定了哪些映射才有意义。

RFC 3441 将语音、语音带数据和传真选择器称为 vsel、dsel 和 fsel。它们是业务到配置行的偏好，不保证每个分组始终使用指定行。配置一旦绑定到连接，规范允许 AAL2 发送端即时切换配置行。应用可以按业务状态限制切换，以简单性换取灵活度，但这些偏好参数本身并不禁止切换。因此，配置名称不是逐分组编解码器的收据。

扩展包里的其他字段属于不同层。ATM 连接类型、虚电路标识和路径建立选项针对承载；AAL 参数描述适配；流量管理参数描述 ATM 服务类别；编解码选择表达媒体偏好。MGCP 命令被接受、SDP 描述符返回、配置完成协商、承载建立成功、虚电路上传输了信元以及接收方听到清晰声音，是不同的观察结果。RFC 2805 的媒体网关架构与 RFC 3435 的基础控制协议，说明控制器、网关和网络各自承担不同职责。RFC 3108 描述 SDP 中的 ATM 承载特性，但配置达成一致并不等于传输已经发生。

呼叫代理决定自身报价与策略；每台网关掌握本地配置及业务映射；ATM 网络决定能否按给定参数建立虚电路；发送端网关决定某一时刻实际使用哪一行。远端描述符可以记录协商意图，却不能证明信元穿过网络、接收端重组了媒体，或用户体验到预期服务。

本文只讨论 RFC 3441 中配置清单与业务映射的边界。它不宣称 MGCP 目前仍被部署，不推断具体厂商行为、ATM 通话已完成、编解码质量、资源已预留、互通表现或用户实际听感。规范定义的是交换模型和偏好词汇；要证明后续结果，仍需独立证据。

来源：RFC 3441；RFC 3435；RFC 2805；RFC 3108；RFC 3054；RFC 3336；RFC 3337。记录页：RFC Editor；IETF Datatracker。