摘要

  • RFC 3624 把 MGCP 一次只审计一个端点的方式扩展为批量报告，并在回复触及数据报长度上限时允许继续查询。
  • 200 OK 不代表请求的端点范围已经全部覆盖：BA/NE 指向续查位置，BA/EL 则说明压缩后的计数或状态向量究竟对应哪些端点。

2003 年，这不是抽象的协议整理问题。呼叫代理故障切换后，可能要重建自己对一台拥有数百乃至数千个端点的媒体网关的认知。MGCP 基础审计命令一次查看一个端点。RFC 3624 增加 Bulk Audit 包，让代理能够询问一组端点的命名、部分状态和连接信息。它属于 Informational，而非互联网标准；IESG 注记还把 MGCP 与基于标准的 Megaco 方案区分开来，后者见 RFC 3015。这说明它是一种历史上的控制面恢复接口，并不能证明某家运营商实际部署了它。可对照 RFC 2705 的早期 MGCP 与后来的 MGCP 1.0（RFC 3435）。

这个包把容易被通配符混为一谈的问题拆开。BA/Z 请求已配置的端点命名规则；BA/X 请求当前已实例化的非持久虚拟端点。于是 conference/* 这样的命名模式可以存在，但实际创建出来的只是其中不连续的一部分。把命名规则当作清单，会把“可能使用的名字”错写成“此刻存在的对象”。

对已有端点，BA/C 按顺序返回连接数量。十六进制数字表示零到十五；Z 只表示超过十五，而不是精确总数。BA/M 编码连接模式。BA/S 则按请求中的条件评估端点，返回 T、F 或 O（停服）。它对多项条件做逻辑“或”，并非逐条描述端点的所有连接。RFC 明确说明，端点状态指示器不代表其连接状态。这些字段没有一个能证明呼叫已接通、媒体正在传送、应用可以工作，或客户已经获得服务。

接下来才出现数据报大小限制。若完整结果会超过最大数据报尺寸，网关可以只报告部分端点，但必须用 BA/NE 返回下一个本地端点名称。呼叫代理可把它作为后续请求的 BA/SE 起点。成功码确认的是这一次响应；续查游标表明整个审计尚未结束。(RFC 3624，第 2.1.1.1、2.1.1.7 节。)

计数和状态还需要第二条边界：位置映射。BA/EL 必须出现在 BA/C 或 BA/S 列表之前，说明向量中每个位置指向哪些端点。虚拟端点的实例范围可能彼此断开，所以这个映射不是可有可无的装饰。没有映射，格式正确的数字仍可能被归给错误对象。如果同时请求计数与状态，两者还必须覆盖相同的端点集合。(RFC 3624，第 2.1.1.8、2.1.2 节。)

RFC 3624 规定了大清单如何续查，却没有定义跨请求的原子快照。不同分页可以反映不同时间的观察，协议也没有一个共同时间纪元把它们冻结成同一瞬间。故障切换中，代理因此可能获得有用的控制面视图，但不能据此推断它一定完整、同时或等同于服务本身。把“实际运行的系统最终做了什么”与描述它的模型分开，是对 Heng Lu《运行代码优先》的有限借鉴；这只是明确披露的分析视角，不是 MGCP 部署证据。

这套报告语法的克制恰恰有用：它告诉代理网关返回了什么、每个数值属于哪个名称，以及下一条查询从哪里开始。它没有把控制查询伪装成端到端服务测试。连接、媒体、应用和用户结果仍需各自的独立证据。