摘要

  • RFC 5133 是 2007 年 12 月发布的 Proposed Standard，更新 RFC 4233。
  • RFC 4129 已把管理消息 type 5 分配给 DUA 的 DLC Status Request。
  • RFC 4233 随后又把管理消息 type 5 分配给 IUA 的 TEI Query Request。
  • 当消息类和类型都相同时，仅凭报文头无法区分两个操作。
  • RFC 5133 要求 TEI Query Request 改用 type 8。
  • IANA 当前登记 type 5 为 DLC 状态请求、type 8 为 TEI 查询请求。
  • 注册表给出了唯一的规范含义，却不能证明现场二进制已经升级。
  • SCTP association 成功只证明传输关联，不证明 ASP 活跃或支持 RFC 5133。
  • RFC 4129 推荐 DUA 使用 PPID 10，但允许混合回传时使用 IUA 的 PPID 1。
  • SCTP 本身不解释 PPID，因此 PPID 不是身份、授权或语义强制证明。
  • ASSIGNED 只表示 Q.921 认为 TEI 已分配，不是用户、设备或服务身份。
  • 安全迁移必须分别保存注册、构建、配置、传输、线缆报文、解码、响应、链路状态与业务结果凭证。

歧义不是“可能看错”，而是“没有足够的位可供看对”

RFC 3057 的早期 IUA 没有定义 TEI 查询。RFC 4129 为 DPNSS/DASS 2 引入 DUA，在管理类中定义了 DLC Status Request、Confirm、Indication，类型分别为 5、6、7。后来 RFC 4233 扩展 IUA，又把 TEI Query Request 放在管理类 type 5。

这不是文档标题相似，而是线上的同一坐标承载两种动作。接收端看到 class 0/type 5 时，无法从这两个字段知道发送方究竟要查询 DUA 的数据链路连接，还是 IUA 的终端端点标识符。若实现根据端口、设备角色或运维预期猜测，它增加的是本地假设，不是恢复了报文中不存在的信息。

RFC 5133 的改动因此很小也很彻底：TEI Query 必须使用 type 8，IANA 为它保留该值。当前注册表将 DLC Status Request 留在 5，把 TEI Query Request 放在 8。此后，一份遵守新规则的报文可以被确定性解释。

但标准没有加入能力协商、过渡位、查询关联标识或降级规则。它也没有远程改写已经安装的设备。规范时钟在 2007 年前进了一格，设备时钟可能多年不动。

外层 PPID 不能替内层编号善后

有人会说，SCTP Payload Protocol Identifier 可以区分 IUA 和 DUA。RFC 4129 的确推荐 DUA 使用 PPID 10，IUA 使用 PPID 1。这是有用的分层提示。

同一文档也允许 DUA 使用 IUA 的 PPID，例如 ISDN 与 DPNSS 共用一条 SCTP association 时。它还明确指出，SCTP 不直接使用这个 PPID；某些网络实体可以用它识别 DATA chunk 承载的内容。

因此 PPID 是交给上层的标签，不是传输层实施的语义防火墙。混合部署可以按标准复用 1，配置可能错误，抓包系统可能丢失 ancillary 信息，接收端也可能在验证消息类与类型之前就选错解析器。一个可选的外层提示不能让冲突的内层 namespace 自动安全。

反过来也不能夸大新组合。抓到 PPID 1、class 0、type 8，足以强烈支持“此观察点出现了现代 IUA TEI Query”这一判断。它仍不证明发送组织的身份、查询权限、接收端采用的 build、响应是否齐全或终端业务是否可用。

传输连通与应用一致是两张收据

IUA 通常运行在 Signaling Gateway 与 Application Server Process 之间的 SCTP 上。RFC 4233 把 SCTP association、ASP 状态和应用流量状态分开。SCTP 已建立时，ASP 仍可能处于 INACTIVE；接口标识符与 association/stream 的映射会随 ASP 状态变化，在 failover 期间甚至可能暂时无效。

所以“SCTP up”只能排除一部分传输故障。它不能说明对端理解 type 8、选中了正确的应用配置、激活了目标 Application Server 或把消息关联到正确接口。

迁移验证应保留 association 标识、方向、stream、PPID、公共头的 version/class/type/length、完整字节、两端 build、解析分支与返回消息。Unsupported Message Type 表示不支持该类型，Unexpected Message 表示状态或上下文不期待它，Protocol Error 又是另一类。把它们都归成“网络失败”会丢失最重要的诊断信息。

没有错误也不是成功证明。接收端可能静默丢弃，反向抓包可能缺失，接口查找可能在解析后失败。积极证明需要在明确时间窗内收到预期的 TEI Status Indications，并核对集合是否完整。

TEI 查询里的 DLCI 必须被忽略

RFC 4233 规定，TEI Query 从 ASP 发往 SG，包含公共头与 IUA 头；其中 DLCI 必须由 SG 忽略。这一条揭示了通用结构的风险：字段存在，不代表它在每一种消息中都有意义。

若监控系统把该 DLCI 当作查询目标、按它聚合成功率或拿它关联客户，它就是在制造协议没有给出的关系。正确的观测记录应保留该字段用于原始报文完整性，同时明确标注“本操作不解释此值”。

TEI Status 的 ASSIGNED 表示 Q.921 认为 TEI 已分配；UNASSIGNED 表示认为未分配。它不是设备证书、用户账号、物理在场、合同关系或当前数据链路成功。

这个状态仍然有用。ASP 可以据此准备收发信令，决定是否请求建立数据链路，或调查一个自己此前不知道已分配的 TEI。但“下一步可以做什么”不能被改写成“下一步已经成功”。要声称服务可用，还需观察数据链路建立、信令传输和应用结果。

从 8 退回 5，会把已修复的冲突重新打开

新发送端遇到旧接收端时，type 8 可能收到 Unsupported Message Type。最顺手的兼容逻辑是改用 type 5 重试。然而这不是换路径重发同一个动作，而是把语义判别符改成有冲突的旧值。

在 DUA 场景中，type 5 正是 DLC Status Request。若 DUA 又使用 PPID 1，外层标签也无法可靠救场。一个为了“提高成功率”的 fallback 可能让对端成功执行了另一个查询，而控制台把任意响应当作 TEI 兼容成功。

若遗留兼容无法立即消除，必须把它限定为具名 peer、已证明的 IUA-only 场景；每次调用都留痕；混合或 DUA association 上硬拒绝；设置退出日期；负向测试确保 type 5 绝不进入错误 handler。兼容层越安静，淘汰旧设备的激励越弱。

测试矩阵必须是非对称的：新到新、新到旧、旧到新，IUA-only、DUA-only、混合 backhaul，以及 failover 前后。除了验证正确组合成功，还要验证歧义组合公开失败，而不是“似乎有响应”。

注册表真相、构建真相与运行真相

IANA 注册表回答当前号码的规范归属。软件物料清单回答计划安装什么。代码或构建测试回答一个 artefact 的行为。配置回答节点被要求以什么角色运行。抓包回答某点出现了哪些字节。解析 trace 回答哪个代码分支执行。响应回答 peer 报告了什么。业务探针回答用户得到什么。

把这些层分开，不是贬低标准。恰恰相反，唯一编号让抓包和测试第一次能够提出无歧义的问题。运行代码则证明标准是否真的进入现实。

官方资料没有证明任何具名厂商已修复、任何生产 peer 已升级、任何终端属于谁，也没有证明一次实际服务结果。分析必须在这些边界停止，并把缺失项变成下一张证据请求。

Sources