摘要

  • CAS 有些反应必须在几十毫秒内完成，RFC 3064 因而让媒体网关处理线路侧协议、定时器与超时，Call Agent 保留数字分析、路由和连接管理等较高层决策。
  • rel 与 rlc 证明电话侧资源已经释放、可供下一次呼叫使用，却不会顺带删除网络连接；完整清理还需要独立的 DLCX 动作与回执。

远端控制器赶不上那一下“眨眼”

信道随路信令（CAS）把占线、应答、挂机和释放等状态附着在电话电路上。有些动作的有效窗口只有几十毫秒。如果每一次线路变化都必须先送到远端 Call Agent，再等命令返回，网络时延就会闯进电话状态机，成为协议是否成功的一部分。

2001 年 2 月发布的 RFC 3064 选择了一条更窄也更实际的边界：能在本地完成的 CAS 协议细节、定时和超时由媒体网关承担；需要理解号码、选择呼叫路径或安排分组连接时，再由 Call Agent 决策。快不是网关获得全部权力的理由，只是把一个有明确时限的动作放到能够兑现时限的位置。

文件定义六个 MGCP 包：面向基本 MF CAS 的 MS、面向 DTMF 与脉冲拨号中继的 DT、面向 PBX/FXS 的 BL、面向 FXO 的 DO、面向 Feature Group D EANA/EAIN 的 MD，以及面向话务员业务信令的 MO。IANA 至今列出这六个版本 0 名称。登记能证明命名空间分配，却不能证明某台设备实现了它，更不能证明某条线路今天正在运行。

同一个接口没有消灭不同的线路

对于只接收一串号码的来话，Call Agent 不应因为一条中继使用 wink start、另一条使用 immediate start，就维护两套完整呼叫流程。媒体网关可以吸收这一差异，用共同的“呼叫建立”事件向上报告。

但物理差异仍在。具体中继类型通过 MGCP 之外的方式在网关内配置；Call Agent 仍需知道所用包以及线路是入向、出向还是双向。抽象减少交互次数，并没有把设备、布线和远端交换机变成相同对象。包名是控制接口，不是能力探测结果。

这种分工体现了有限的本地决策权：离硬件最近的一层处理可逆、急迫的动作；拥有跨端点视野的一层决定通话如何继续。两层之间必须交换事实，任何一层都不能凭自己的局部成功宣布整场通话完成。

命令向下走，事件向上来

RFC 3064 对方向的命名很清楚。signal 是 Call Agent 发给网关的命令；event 是网关检测后通知 Call Agent 的事实。命令收到 200 OK，只说明这一协议步骤被接受。随后还可能需要 operation complete，证明本地发号动作结束；再以后才可能出现应答监督与双向媒体。

示例流程有意把这些时刻分开。建立命令先得到确认，号码发完后再有通知，远端摘机后才进入应答状态。因此，成功响应不等于号码已经发完，不等于对方已经接听，也不等于人能听见对话。

部分事件带有 S，表示状态可审计。审计回答的问题同样有限：这条线是否已经启动呼叫？电话侧是否已经空闲，可以接受下一次呼叫？它可以在控制器丢失上下文后校准当前状态，却不能自动重建先前每一步的原因和结果。

一次拆线，两个对象

RFC 3064 最有价值的边界出现在释放阶段。rel 不只是挂机，它表示电话侧资源应当释放，且不能再以 resume 恢复。它既可能是 Call Agent 下发的 signal，也可能是网关因远端挂机或异常状况产生的 event。之后的 rlc 表示中继资源已完全释放，可以供下一次呼叫使用。

可是，文件明确说明：rel 不表示连接也应删除。若要把整场通话连同网络连接一起释放，Call Agent 还必须另外执行 DLCX，可以与 rel 同时，也可以随后进行。

这不是重复操作。电话中继与分组网络连接是两个不同的运行对象。线路侧已经空闲时，连接记录仍可能留在网关；网络连接已经删除时，远端线路也可能尚未完成释放。rlc 与 DLCX 因而是不能互相替代的两张收据。

异常路径更能说明问题。rel 可能来自 glare——双向中继两端同时抢占——或其他使网关无法维持电话侧的故障。这时 rlc 用于完成资源状态转换，未必对应一次字面意义上的远端挂机。它说明资源现在怎样，不负责替人讲述通话为何结束。

Glare 把本地策略暴露出来

双向中继若被两端同时占用，就要决定哪次抢占继续。RFC 3064 允许网关使用已配置的处理方式，包括按 DS0 设置的 glare 选择。决策贴近物理端口，是因为碰撞发生在本地且受时间约束；Call Agent 仍需收到结果与原因，才能处置其余连接。

规范没有把某一种选择宣布为普遍真理。它给不同本地策略提供可互操作的事件语言。运营记录因此必须保留配置、观察到的 hook 状态、原因码，以及后续 rel、rlc 和 DLCX。只看到最终“空闲”，无法知道哪一端获胜，也无法证明网络资源已经回收。

当时已经能看见替代路径

RFC 3064 是 Informational，而不是互联网标准。IESG 注记说该协议当时已在多种产品中部署，同时提醒实现者关注 IETF Megaco 工作组与 ITU-T SG16 正在推进的潜在后继方案。后来的 MGCP 与 Megaco/H.248 文件展示了技术生命周期，却不能反过来改写 RFC 3064，也不能证明今天的采用情况。

这段历史留下的原则并不依赖产品寿命：把有硬期限的动作交给能够按时完成的一层；把跨系统决定交给拥有完整视野的一层；并为每次越界保留独立回执。网关可以掌管毫秒，Call Agent 可以掌管通话，但电话侧释放与网络侧删除永远不能只凭同一盏绿灯宣布完成。

来源