摘要

  • RFC 3362 把 image/t38 注册为 SDP 中描述实时 T.38 传真流的媒体子类型；编码本身由 ITU-T T.38 建议书定义。
  • 标签消除了一个命名歧义，但不能证明对端接受、传输兼容、媒体加密、网关转换成功、页面完整或收件人实际收到。

设想一台传真网关刚收到 SDP。解析器读到媒体类型，词法判断完全正确：这是 T.38 实时传真流。到此为止，注册表完成了自己的工作。可是右侧终端是否接受、路径走 TCP 还是 UDP、包能否到达、页面是否缺行，仍然没有答案。

2002 年发布的 RFC 3362 连接了两个标准世界。ITU-T 的 T.38 建议书定义第三类传真终端和网关如何在 IP 网络上传递实时传真。IETF 的 SIP 与 SDP 负责会话建立和描述。RFC 3362 没有重写传真编码，而是注册 image/t38，让 SDP 能以共同词汇指出正在提议的媒体。

这种分工是互联网标准化的一种成熟形式。一个机构无需拥有所有层。ITU-T 可以维护传真行为，IETF 可以维护会话协议，IANA 可以保存媒体类型，实施者再决定是否把这些规则写进代码。共同点越准确，越容易验证它到底证明了什么。

注册内容十分克制：必需参数为无，可选参数也为无，编码考虑为二进制，预期用途为常用。没有参数并不等于没有设计。它说明这个标签只承担分类责任，并不暗中携带完整兼容配置。任何有关版本、传输和网关行为的进一步判断，都必须去别的层寻找证据。

RFC 3362 还主动排除了一个容易误读的场景。image/t38 用于 SDP 里的 T.38 媒体流，不用于电子邮件。互通性说明直接指出，邮件应用如何使用它并未定义，因此不能保证与 T.38 流互通。名称以 image 开头，不会自动把实时会话变成普通附件。

这条限制揭示了上下文的作用。同样的字符串放在不同协议里，字符没有变化，运行含义却可能消失。注册表提供的是受约束的语义，不是可以脱离环境复制的万能承诺。

安全说明同样保持边界。该内容代表可能加密、也可能没有加密的传真比特流。image/t38 本身不宣称保密性，也没有说明 SIP 信令是否受保护、媒体段是否加密、或者网关在另一侧是否恢复成明文。安全是具体路径及其配置的属性。

SDP 也不会因为成功描述媒体就负责传输。从 RFC 2327、RFC 4566 到现行 RFC 8866，SDP 都是多媒体会话描述格式，本身不包含传输协议。地址、端口、媒体与格式可以写在描述里；描述存在，不等于数据已经穿过网络。

下一步是提议与回答。RFC 3264 的 offer/answer 模型把一方希望建立的会话写进提议，再由另一方写出自己的回答，两边合在一起才构成完整视图。回答方可以把端口设为零来拒绝某条媒体流。所以抓包里出现合法 image/t38，最多证明一端提出过它。

即使回答接受，互通仍未完成。两端要运行相容的 T.38 行为；选中的 TCP 或 UDP 路径要能穿过网络；丢包、延迟与乱序要处在服务容忍范围；网关还要把分组网络的节奏正确转换成传真终端所期待的过程。会话已建立与页面已完成，是两个不同事实。

因此，运维证据应当逐层记账。IANA 条目证明标识已注册并指向 RFC 3362。软件清单可以证明某实现声称识别它。SDP 提议证明一端提出了该媒体。回答证明接受或拒绝。分组记录证明实际传输。网关事件证明转换尝试。页数和终端结束信号才能证明技术交付。收件流程是否真正接收并处理，还在更后一层。

这些凭证不能互相替代。注册不是部署普查，识别不是接受，接受不是传输，传输不是完整页面，完整页面也不一定等于业务收件。把它们都写成“支持”，会让故障消失在一个模糊词里。

媒体类型注册制度后来的演进也支持这种窄解释。RFC 3362 发布时，RFC 2048 提供注册程序。之后 RFC 4288 和 RFC 6838 更新通用框架。审查、唯一命名与稳定引用可以降低冲突和误解，却不会在任何运营商设备上自动启动功能。

RFC 2119 与 RFC 8174 的规范词汇也只解决文本层问题。大写要求词告诉读者合规实现应当做什么，不会证明某台网关在某个时刻确实做了。规范义务和运行事实之间，始终需要观测凭证。

今天的 IANA 记录仍然很重要。它跨越二十多年保存 image/t38 及其引用，给实施者一个共同查询点。但这份连续性证明的是标识的保管，不是当前使用率、加密比例、传输选择或页面成功率。

本文公开采用 Lu Heng 的两篇文章作为分析镜头。“Minimum Initial Specification”强调，共同层应只保留互通所需且可本地验证的内容，后续采用取决于实际运行代码的参与者。RFC 3362 展示了这种最小连接的价值。“On Reality Layers”要求把记录、声明与运行现实分开；在这里，注册、提议、接受、传输与收件必须分别列账。

RFC 3362 的克制不是缺陷。它把一件小事做得准确：让会话描述可以说“这是一条 T.38 传真流”。一旦有人要说“相容”“安全”“已交付”，就必须拿出下一层证据。

来源