摘要

  • RFC 5098 中的 operational(1) 只表示线路入服所需操作已经完成，且呼叫管理服务器确认了 Restart In Progress；它不是某一通电话成功的回执。
  • 配置行、CMS 地址、音调表与一致性组让管理面更可审计，却不能证明话机真的响铃、媒体到达或用户听到了正确声音。

一块运维看板把端点涂成绿色。pktcSigEndPntStatusError 的值是 operational，呼叫代理名称和 IP 地址也都存在。把这几项读成“电话业务正常”很自然，问题也恰好从这里开始。

RFC 5098 为符合 PacketCable 与 IPCablecom 的多媒体终端适配器定义 NCS 信令 MIB。它记录设备能力、端点配置、音调、节奏、定时器和有限的状态。这里的每一项都可能准确，但准确的管理事实并不会自动升级成业务结果。

标准对 operational 的定义很窄：使线路投入服务所需的操作已经发生，CMS 成功确认了 Restart In Progress 消息。这个状态没有说用户已经拨号，没有说对端应答，也没有说 RTP 媒体建立、解码或从听筒发声。

端点表本身解释了原因。表项保存 MTA 维持与 CMS 的 NCS 通信所需的已配置资料；表项数量代表已配置端点数量。没有相应 CMS 信息的端点被视为尚未配置语音服务。反过来却不能成立：具有 CMS 资料只是控制前提，不是一通电话的完成证明。

pktcSigEndPntConfigStatus 也容易被名称误导。它使用 SNMP 的 RowStatus，而 RFC 明确说，行在激活前不要求其他列满足额外限制或依赖。因此 active(1) 证明的是代理内的一行处于活动状态，不是模拟端口、呼叫控制和媒体系统已经端到端就绪。

呼叫代理名称与端口把责任边界写得更清楚。pktcSigEndPntConfigCallAgentId 包含 CMS 名称和 FQDN，MTA 按当前值通信，并可从 NCS 的 Notified Entity 参数更新它。pktcSigEndPntConfigCallAgentUdpPort 保存 CMS 接收 NCS 的 UDP 端口，参数未给端口时默认为 2727。标准警告正常运行时不要随意经 SNMP 改动它们，因为错误值会破坏信令。

但“目标配置正确”与“消息到达”仍是两件事。pktcSigEndPntStatusCallIpAddress 是从 FQDN 解析后当前选中的 CMS 地址。它能说明 MTA 选择了哪里，却不能说明后续数据报被目标进程接收、授权了呼叫，或建立了媒体路径。

安全关联又是另一条证据链。启用 IPsec 控制时，noSecurityAssociation 表示端点尚无 SA；disconnected 可以表示 SA 已建立，但 NCS 软件仍在通过 RSIP 建立信令链路。禁用 IPsec 时，同一个 disconnected 值描述不含 SA 的链路建立阶段。只看数字、不看配置上下文，会把不同现实压成一个颜色。

音调表让“配置不是输出”变得具体。MIB 可以写下频率、幅度、开关时长、重复次数与是否持续；文档还给出呼叫等待音和拥塞音的编码示例。端点对象定义一次 CMS 请求触发的等待音最多重复几次，以及两次之间延迟多久。

这些是参数和指令，不是模拟线路上的测量。正确表项不能证明 CMS 发出了某次请求；请求不能证明 MTA 驱动了线路；电气输出不能证明话机把它还原成声音；声音存在也不能证明目标用户听见并理解。

能力对象同样受限。可用编解码器、回声消除能力和静音抑制能力回答“设备能否支持”，不回答“本次是否启用”。启用不等于协商使用，协商不等于数据包交付，交付也不等于清晰可懂的语音。

一致性声明只说明实现了哪些 MIB 对象。设备组与端点组对声称符合本 MIB 的 MTA 是强制的；国际化、L 线路与 E 线路组按功能条件适用。它不是运行时每个值的认证，更不是服务质量证书。

尤其值得注意的是，RFC 5098 只为未来扩展预留 pktcSigNotification，没有在本文中定义完整的通知对象链。产品可以另有 trap、日志或遥测，但运营者必须按其真实来源命名，不能把它们倒写成 RFC 5098 已经提供的呼叫事件账本。

端点行还有生命周期限制：MTA 重启后不持久。若不记录启动代次，同一个接口索引在重启前后的读数会被误接成连续历史。标准明确没有承诺这种连续性，审计系统不能自己发明。

可写对象也证明管理面会影响现实。RFC 5098 警告，恶意修改 DSCP、振铃节奏、信号时长、来电显示协议、呼叫代理名称或端口，可能造成错误运行或语音服务中断；地址、错误与编解码器等只读资料也具有敏感性。因此文档建议使用带认证与隐私保护的 SNMPv3，并把 GET、SET 权限限于合法主体。

接受一次 SNMP SET，只证明某个管理操作被代理接受。它不证明下游线路、CMS 与媒体系统已经达到设置者设想的状态。RFC 4682 所定义的相邻 MTA 设备 MIB，以及 RFC 3435 的媒体网关控制模型，都进一步表明：配置、控制和媒体相关，却不是同一个事实源。

一条可复核的呼叫证据链，应分别保存 MTA 身份与启动代次、配置来源、SNMP 主体与操作、OID/值/时间、CMS FQDN 与 DNS 结果、安全关联状态、NCS 事务与 RSIP 确认、每通呼叫的命令和线路事件、承载与媒体路径、编解码/抖动/播放状态，以及最终应用或用户结果。普通日志不应保存密钥与不必要的用户内容。

这不是 RFC 新增的语法，而是运行建议。它贯彻 Heng Lu 对现实层的要求：账本可以对自己记录的那一层负责，不能因为位置靠前，就继承后一层的权力。

Sources