RFC 5244：收到事件不等于证明呼叫状态

摘要

运营台看到三份相同事件报告，网络没有丢包，SRTP 校验成功。这样的证据很强，但它只对“这个发送方通过这条安全关联发来了这个事件”负责。它不能证明发送侧听到的就是那个音，也不能证明接收侧向传统接口复原了正确的电气状态。

RFC 5244 的应用场景本身就是一次语义接力。传统电话交换机之间原本在中继上使用多频音、线路条件或 robbed-bit 信令。换成 RTP 中继后，语音编解码可能抹掉那些低位比特，也可能干扰带内音。网关于是先识别信号，再把它编码为 telephone-event 负载。

这一步把脆弱的模拟或帧内现象变成了干净的数字事件，却没有消除前后的不确定性。识别器可能误判，事件表可能版本错配，冗余包可能被重复执行，接收端可能采用不同的本地补位规则，传统状态机还可能因时序或上下文拒绝该信号。

RFC 5244 涵盖 SS No. 5、R1/MF、R2、ABCD 状态、连续性测试音、中继不可用和计次脉冲。它同时明确提醒：文中对这些信令系统的说明并不完整，许多实现所需细节被省略。

这句提醒应当进入架构设计，而不只是实现者的脚注。事件码描述了“送进旧系统的一个输入”，并没有携带旧系统此刻所处的全部状态。相同音调在不同阶段可能意味着不同动作。只有方向、前序状态、时间窗、本地配置和后续确认一起存在，事件才拥有可操作的语义。

标准演进也会改变含义边界。RFC 5244 指出 RFC 2833 中部分定义含糊、有误或重复；除完整 ABCD 信令外，新旧实现并非完全向后兼容。因此，仅保存数值代码会丢掉最重要的来源信息：采用哪一代定义、协商了什么范围、对应哪套传统信令。

ABCD 事件彼此互斥，最近一次转换代表报告的当前状态。为了抗丢包，状态变化时建议以 5 毫秒间隔发送三次，稳定后再周期刷新。这能提高接收概率，却不会让接收日志自动成为线路真相。

当系统只使用 A 位或 A/B 位时，未使用的比特由接收网关根据本地配置补齐。同一个来包，落到不同配置上，可能形成不同的完整输出条件。要证明旧交换机真正看到什么，必须记录重建后的接口值，而不是只保存输入事件。

状态还有有效期。RFC 4733 允许某些状态通过 duration 表达软状态；刷新缺失后，接收方应把它视为未知。把最后一次成功包永久显示为绿色，等于把过期观察伪装成持续事实。

“连续性音已收到”听起来像测试通过，实际不是。四线测试中，发起交换机发送检查音，远端建立环回，发起端只有检测到返回音才可判定通过。两线过程还包括反向验证音。

事件 121 证明某个检查音报告被传送；事件 122 证明某个验证音报告被传送。两者都不能替代最终检测点的判决。缺少回程观察与判定回执时，抓包只能证明控制意图经过了网络，不能证明媒体路径连续。

拥塞处理进一步说明“按包还原”不总等于“按协议还原”。包延迟时突然中断音调可能导致呼叫建立失败；继续播放可避免中断，却会增加建立时延。对 SS No. 5 和 R1/MF 的严格序列，接收端应依据传统规范的时长播放，而不是机械复制报告时长。

计次脉冲与计费相关，因此最容易被业务系统越权解释。RFC 5244 把它定义为离散事件，要求标记和结束位，并建议重传。通话音频可以同时继续。

重传意味着多个包可能代表同一次脉冲。若财务系统按包计数，可靠性机制就会变成重复收费。正确链条需要呼叫关联标识、事件幂等键、去重决定、资费规则、账户归属，以及账本系统接受写入的回执。

同理，“中继不可用”事件并不告诉你原因。规范明确说它可能来自故障，也可能来自管理操作。自动把它归因为硬件损坏，是从状态跳到原因；停止收到它也不证明服务恢复，可能只是刷新丢失或发送端沉默。

RFC 5244 把这些事件与呼叫建立、计费和拆线直接联系起来，并列出窃听、未授权连接、劫持和拒绝服务等威胁。需要时应使用带自动密钥管理的 SRTP 提供机密性、认证和完整性。

但“来自已认证网关”仍不等于“有权产生这笔费用”或“检测一定正确”。密码学保护消息来源和内容；业务授权决定可触发什么；下游回执证明实际发生了什么。三者不能合并成一个绿色状态。

可审计系统至少分别记录：原始信号识别、事件编码及版本、认证传输、解码与去重、信号重建、传统状态机接受、呼叫或业务结果。统一关联 ID 负责连接它们，但不得填补缺失项。

这正是 Lu Heng 所强调的现实优先：标准给出可验证的形式，运行系统必须给出可归因的结果。真正成熟的系统允许“未知”停留在链条中，而不是让一次包投递成功替所有下游签字。