摘要

  • RFC 5347 规定，只有随当前命令提交的 RemoteConnectionDescriptor 才能参与当前传真过程的选择；旧描述不能充当今天的选择授权。真正发送 T.38 时，则必须依据最近收到的远端描述确认媒体行与传输方式。
  • 省略传真本地连接选项并不等于再次明确要求原有方式。一条在 T.38 Strict 下建立的连接，后来可以接受缺少 T.38 支持的 ModifyConnection；若在同一命令中明确重申 t38，它反而应被拒绝。
  • t38(stop) 只说明网关没有检测到过程错误，不证明页面、完整性、远端接受或人工收件。命令成功、策略授权、媒体许可、过程终止和业务结果必须分别留证。

两只时钟回答两个不同问题

选择时钟绑定当前命令。Call Agent 如果在本次命令中同时给出传真选项和远端连接描述，T.38 Strict 必须得到双方支持。当前描述可以通过媒体行或能力声明提供证据。早先事务中的描述，无论当时多么完整，都不能被拿来决定本次命令可以选择哪一种过程。

发送时钟绑定最近状态。网关在发送 T.38 包之前，最近收到的远端描述必须包含相应的 image/t38 媒体行以及它支持的传输方式。过程可以先启动，包却必须等待授权描述。如果等待超时，过程会停止或失败。

这不是文档前后矛盾，而是两个控制面的分工。选择在回答：本次事务能够建立哪种过程？发送在回答：基于此刻最新的远端状态，哪些字节可以离开接口？

事故平台若只保存一个不断覆盖的 SDP 快照，就无法回放因果链。它需要按命令保存随附描述，又要在每次媒体发送点保存当时最新的描述；还要记录等待区间、解锁事件和超时结果。

“以前支持”不是“现在获准”

把旧描述用于当前选择，会让过期能力穿越事务边界。对端可能换了媒体条件、撤回了传输方式，或者本次命令根本没有携带足够证据。旧状态仍然真实地描述过历史，却不能因此获得对新决定的权力。

相反，一旦过程已经被选择，后续描述又可能改变实时发送许可。选择记录不能代替发包前检查。一个“已协商 T.38”的布尔值无法表达这种变化。

这条边界也解释了为什么不能靠抓包猜媒体。当 RTP 音频与 T.38 在不同时间复用同一地址和端口时，明确的信令状态告诉接收方应期待哪种格式。接收方应按预期格式验证，而不是把包内容当作自动分流依据。

同一个五元组因而可能承载不同阶段的媒体。网络可见性没有消失，但它必须与信令时间线结合，才知道观测到的包是否被当时的授权状态允许。

省略保留了值，却没有保留强制力

RFC 5347 给出的关键案例从一条已在 T.38 Strict 下成功建立的连接开始。随后，Call Agent 发送 ModifyConnection，其中远端描述不再支持 T.38。

如果命令省略传真本地连接选项，修改可以成功。当前选项值被保留，但这次成功并不以满足 T.38 为条件。传真被检测后，T.38 不会再被调用，网关报告 nopfax(start)。

如果 Call Agent 在相同修改中明确重复 t38，命令必须失败。对于无法满足任何明确请求过程的情况，文档建议使用错误 532。红色响应把证据缺口暴露出来，避免控制面假装严格条件仍然成立。

所以“字段没变”不是充分的变更说明。必须记录字段是否出现在当前事务中。省略值与显式值即使文字相同，也承载不同强度的授权要求。

能力广告不等于使用许可

SDP 能力声明可以展示当前能力和潜在能力。设备能够处理 T.38，不代表 Call Agent 在当前命令中允许它切换。能力回答“技术上可能做什么”，显式选项回答“这次被允许做什么”。

反向推断也不可靠。有些对端可能支持 T.38，却不能按预期方式声明能力。Strict 会把缺少声明当作不可满足，因此可能产生假阴性：一个实际上可行的会话被拒绝。

Loose 接受能力声明缺失，可以挽救假阴性，却可能制造假阳性：对一个确实不支持 T.38 的对端发起切换，最终破坏传真。RFC 没有声称两者存在普遍最优解。

真正的治理问题不是维护一个永久的“支持 T.38”标签，而是明确当时有哪些证据、选择容忍哪一类错误、谁授权了使用，以及该选择是否适合特定设备群。

四个选项不是普通优先级

t38 表示由 Call Agent 控制的 T.38 Strict；t38-loose 表示宽松形式；gw 把选择和细节委托给网关；off 表示不采用特殊传真过程，只保留回声消除或编解码器调整等本地动作。

分号分隔的列表通常表示优先顺序，但这里含有特殊终止语义。t38-loose 总能被支持，因此它后面的选项永远不可达。off 也会终止后续选择。

gw 的行为不同。即使网关最终不做任何特殊处理，它在定义上仍然可被支持；但如果这正是选择结果，它可以继续尝试后面的非 off 过程。这是一条针对“委托却无特殊方法”的特殊通路。

因此，只校验 token 合法远远不够。策略检查应报告不可达分支，保留原始顺序，记录每个候选被跳过的原因，并解释是否发生了 gw 的特殊继续。

委托可能把坏消息拖到传真开始

在网关控制模式下，只有两端支持同一种方式且该方式出现在交换的 SDP 中，特殊处理才真正存在。具体方式由厂商决定。如果没有共同方式，网关不会执行特殊传真处理。

Call Agent 在下发命令时未必知道这一点。直到传真真正开始，nopfax(start) 才揭示“没有特殊过程”。之前的绿色命令只是委托被接受，不是某种方式已被选中或执行的凭证。

如果网关控制的方式确实开始，gwfax(start) 才是启动回执。Call Agent 随后应避免发出与该过程冲突的命令，直到收到停止或失败事件。

委托由此产生两项责任：中心必须确认受托执行确实开始，还必须尊重受托方控制过程的时间窗口。配置页只显示 gw，两项责任都看不见。

过程结束不代表文档送达

t38(start) 表示检测到传真并启动了 Call Agent 控制的 T.38 过程。t38(stop) 表示该过程结束，网关没有检测到错误。RFC 明确提醒，这不一定意味着传真成功传输。

网关没有因此证明页数、文件完整性、远端应用接受、收件人正确或人工收到。一个干净结束的网络过程完全可以对应失败或未知的业务结果。

t38(failure) 表示异常结束。gwfax(start|stop|failure) 描述受托过程的生命周期，也不自动越界成为送达回执。nopfax(start) 只有开始事件，因为不采用特殊过程时，不应靠检查媒体去推断传真何时结束。

报表应给过程状态和文档结果不同的字段、不同的证据来源。若系统把 stop 自动写成 delivered，就是让基础设施为它从未观测的事实背书。

检测本身也有误判

实现至少必须从 V.21 前导序列检测传真。T.30 CNG 呼叫音检测是可选项。RFC 记录了调制解调器在非传真呼叫中发出 CNG、导致错误传真触发的报告，并建议提供关闭 CNG 检测的配置。

这意味着授权链即使完全正确，也可能被错误的起始观察触发。过程被合法启动并正常结束，并不能倒推最初真的存在传真文档。

发起 T.38 切换的可以是主叫端、被叫端，也可能两边同时发起。实现必须处理竞态。日志至少应保留检测信号、检测器、发起端、时间点以及同时发起时的收敛结果。

检测置信度与方法授权应保持独立。强烈的传真信号不能越权使用 Call Agent 没有批准的过程；明确批准也不能把错误检测变成正确事实。

兼容性容忍不是策略证明

RFC 建议兼容 UDPTL 和 T.38 属性的大小写差异，也建议容忍某些历史上错误的布尔编码。这些措施帮助旧实现互通，却不能证明双方就策略达成一致。

连接计数器应包含传真包和字节；但在传真进行期间，包括 T.38 阶段，可以暂停到达间隔抖动和平均传输延迟计算。恰逢关键切换，监控图可能出现空白。

复用地址和端口能减少 QoS、NAT 与防火墙问题，却使信令状态更加重要。宽容解析和端口稳定都是部署便利，不应被转化为授权或成功证据。

操作记录需要明确区分：什么语法被宽容接受、什么媒体被批准、什么过程被执行、什么业务结果被其他系统确认。

历史文档的证据边界

RFC 5347 于 2008 年 10 月发布，状态为 Informational，并非 Internet Standard。RFC Editor 的勘误检索显示有六条勘误被保留供文档更新。生产解读应保留这一状态并查阅勘误，而不是默默把原文当作无条件规范。

它不能证明今天的某款产品仍按完全相同方式实现，也不能证明所有传真都必须使用 T.38。历史实现观察不能被写成当前市场事实。

它的持续价值在于展示授权如何随事务和时间变化：当前命令、最近描述、能力广告、显式要求、委托事件和业务结果属于不同证据层。系统只有保留它们之间的边，才能在事后说明一次绿色响应究竟证明了什么。