摘要

  • RFC 5370 规定了 SIP 转码服务的会议桥模型。转码器 T 是 B2BUA，而不是代理；它终止 A–T 一侧的事务，再向唯一目标 B 创建另一个事务。
  • 规范认为该服务不必使用 opt-in 名单，理由是 T 只生成一个 INVITE、目标 URI 本来就是主叫写入的已知地址、下游请求携带主叫身份。这是带条件的结论，不是对任意列表服务的普遍豁免。
  • 即使上下游状态码相同、From 看起来连续，也不能把两条事务当成一条。丢失临时响应后，603 的真正来源需要 History-Info 等路径证据才能说明。

一个地址限制了机器能做什么

A 向 T 发出 INVITE 时，同时提交 SDP 和一个 recipient-list 正文。名单中只有 B 的 URI。T 依据 RFC 5366 的请求内名单机制，向这个 URI 生成新的 INVITE。

RFC 5370 对此作了明确限制：如果名单含有一个以上的 URI，T 应返回 488，并说明只允许一个地址。这个限制不是语法偏好，而是服务权限的外边界。

名单为一项时，一次上游请求最多触发一次下游邀请。T 不能把 A 的意图扩大成多目标行动，也不能把“转码”顺便变成群发。

因此，目标数量应当是审计字段，而不只是解析器的临时变量。若系统只留下“名单处理成功”，后来就无法证明当时是否仍处于单目标模型。

已知目标与目录解析不是同一件事

规范的第二个关键事实，是 A 自己把 B 的 URI 放入初始请求。A 不是交给 T 一个模糊名字，请 T 再决定真正联系谁。

“主叫已知目标”缩小了代理权限。T 执行的是对明示地址的邀请，而不是目标发现、群组展开或身份翻译。

如果未来产品把一个别名解析成多个注册终端，或把企业标识转成后台目录里的陌生地址，操作表面仍可能叫“转码调用”，权限结构却已经改变。

治理记录必须保存目标的来源：由主叫直接写入、由目录解析、由策略替换，还是由服务端扩展。只有第一种能直接继承 RFC 5370 的这项理由。

身份出现并不等于同意

第三个事实是，T 生成的下游 INVITE 中出现主叫身份。B 不会收到一个完全不知来源、又由名单服务突然生成的邀请。

RFC 5370 要求 T 根据入站 From 生成出站 From，但要遵守入站请求的隐私要求，而且不能照搬 tag。身份呈现因此是一项受策略约束的重建动作。

B 看见代表 A 的地址，可以帮助识别邀请来源，却不等于 B 已经同意接受通信，更不等于 B 同意 T 读取和转换媒体。

身份可见是免用 opt-in 名单论证的一项条件，不是完整的同意凭证。认证 A、授权 A 使用 T、向 B 呈现 A，以及 B 接受邀请，仍是四个独立事实。

三个条件共同支撑一个例外

RFC 5363 对 URI 名单服务的放大和非请求通信风险保持警惕，并讨论预先同意名单。RFC 5370 对本模型作出不同判断。

理由不是“辅助技术天然安全”，也不是“只有一个目标就无需授权”。理由是三项结构同时成立：一次输入只产生一次输出；输出目标是输入者自己明示的已知 URI；输出中保留输入者身份。

这三个条件互相补足。单目标阻止数量放大；已知目标阻止语义上的目的地替换；身份呈现让接收方知道谁在发起。

任何一个条件消失，都应重新评估。把一次请求复制给多个终端、用服务器目录替换目标，或因隐私设置完全隐藏来源，都会离开原分析范围。

例外必须写成可计算条件

最危险的实现不是明显违反限制，而是把结论存成永久标签：opt_in_not_required = true。标签保留了结果，丢失了前提。

更可靠的策略会在每次调用时记录并验证：目标数量是否为一，目标是否来自主叫原文，下游是否呈现允许披露的主叫身份。

如果隐私政策要求不呈现身份，系统应明确看到第三项发生变化，而不是继续沿用旧结论。这里并不预先决定新的法律或产品答案，只要求旧答案不能伪装成未受影响。

Minimum Initial Specification 的价值就在此：共享最小条件，而不是把所有未来决定冻结在 2008 年。不同部署可以作本地决策，但必须暴露它依据了哪些事实。

名单完整性保护的是行动对象

入站 INVITE 由多个正文部分组成。SDP 描述 A–T 一侧的媒体能力，recipient-list 指定 T 将向谁创建请求。

这两个对象同在一个消息里，却控制不同资源。篡改 SDP 会改变媒体协商；篡改名单会改变行动目的地。

RFC 5370 强调名单完整性，并引用 S/MIME 或 TLS 等机制。完整性证明要绑定确切字节、保护范围和验证结果，不能只写“连接已加密”。

如果保护只覆盖传输的一段，T 解密后重新生成下游事务，另一侧仍需要自己的保护与验证。A–T 的安全上下文不会自动变成 T–B 的安全上下文。

T 是行动者，不是透明通道

收到名单后，T 按照 RFC 5366 生成面向 B 的 INVITE。RFC 5370 特别说明：T 是 B2BUA，不是代理。

这个分类决定了证据结构。出站 INVITE 属于不同事务，T 还要根据自己提供的转码服务构造 SDP。例如音频编解码转换服务会列出 T 支持的音频能力。

所以 T 不只是运输 A 的指令。它认证、授权、解释名单、应用隐私、构造身份、协商媒体、创建事务，并把结果重新表达给 A。

一个叫“session_id”的内部关联键可以帮助查询，但不能替代上下游各自的事务和对话标识。相关不等于同一。

相同状态码没有跨越事务边界

T 收到 B 的最终响应后，会为 A 的入站 INVITE 生成新的最终响应。规范建议新响应使用下游相同的状态码。

这能把结果类别传回去，却不能把下游响应变成上游事务里的原生事件。603 Decline 可以由 B 在第二条事务中产生，再由 T 在第一条事务中重新产生。

RFC 5370 的失败示例说明了为什么来源重要。如果 A 没收到此前的 183 Session Progress，它仅凭最终 603 无法知道：是 T 拒绝了最初请求，还是 B 拒绝了 T 的请求。

状态码是结论的一部分，不是完整因果链。事故复盘若只按数字聚合，会把目的地策略、转码器授权和网络丢包混进同一个失败桶。

History-Info 补的是归因，不是结果

规范提出在 T 与 A 之间使用 History-Info 解决歧义。History-Info 不把失败改成成功，也不改变 603 的分类；它补充请求如何到达当前结果的路径。

这揭示了临时响应的证据价值。183 到达时，A 至少知道 T 已经进入会话进展阶段。它丢失后，最终响应缺少区分服务端拒绝和下游拒绝的上下文。

RFC 5370 当时引用 RFC 4244；后来 RFC 7044 更新了 History-Info 的规范背景。后续标准并不能反向证明某条历史会话真的携带了所需信息。

系统应保存实际字段、隐私处理和捕获缺口。没有 History-Info 时，应标记来源未知，而不是根据最常见原因补写答案。

被放弃的方案拥有更清楚的观察面

文件还讨论另一种结构：T 可以先用 200 OK 接受 A，再单独邀请 B；A 通过订阅会议状态获知第二次邀请的结果。

这种设计把“T 接受 A”和“B 接受 T”显式分成不同事件，不再需要让一个最终状态同时代表两层结果。

它没有被选中，因为消息更多、实现更复杂、建立时延更长。被选择的设计用更少协调换来了对 History-Info 的依赖。

这是一项可观察性交易。若运营团队后来为了节省日志又丢弃历史，就既接受了不透明设计，又删除了它所需的补偿证据。

302 只把选择交回 A

当 B 无法接受 A 的 SDP 时，也可以用 302 Moved Temporarily 指向 T。Contact 中的 ?body= 参数包含带有 B 地址的 recipient-list。

这条响应不会自动调用 T。A 必须结束原尝试，解析经过转义的正文，再决定是否向 T 发起新 INVITE。

RFC 5370 指出，把正文编码进 URI 很复杂；对被叫发起的场景，3pcc 反而更简单。复杂性意味着解析和验证本身也是权限边界。

审计应分别保存 B 的建议、A 的验证与跟随决定、面向 T 的事务、T 的授权结果和面向 B 的新事务。302 只能证明建议存在。

转码成功仍不是人的成功

RFC 5370 的目标包括为聋人、听力困难者和言语障碍者调用转码服务，例如语音转文字。

两条 SIP 事务成功、两条媒体腿建立，只能证明基础设施状态。它们不能证明语言正确、延迟可用、转换方向适合、文本准确或参与者理解了内容。

如果监控把“桥已建立”直接记成“无障碍需求已满足”，就把网络层事实提升成未经证明的人类结果。

可访问性记录需要用户目的、方向、语言、输出质量和实际结果。没有这些证据时，诚实状态是未知，而不是成功。

身份机制也有历史边界

RFC 5370 允许 T 使用当时的 SIP 身份机制向下游提供原始发送者信息，并引用 RFC 4474。RFC 8224 后来取代了 RFC 4474。

这段历史不能用来推断当前部署采用哪种身份方案，更不能证明 B 验证过某个断言。只能准确描述规范当年的选择，并检查现实系统实际使用的机制。

同样，RFC 5246 等密码学引用属于出版时期背景，不是今日配置建议。保护是否足够必须绑定现实版本、策略和威胁模型。

文档地位、机制注册、产品支持、会话协商和验证成功是五种不同证据。

最小凭证保留条件而不是口号

对这类服务，最小可用凭证包括：认证过的调用者、授权规则、精确名单字节与哈希、目标数量、目标来源、隐私要求、出站身份呈现、上下游事务标识、腿级 SDP、临时与最终响应、History-Info、媒体转换和人类结果。

Reality Layers 提醒我们，名单、身份、事务、状态、媒体与理解属于不同现实层。一个层的成功不会自动填满下一层。

领导者真正需要防止的，是条件漂移。最初只有一个已知目标，后来服务扩展了目录、分叉和匿名功能，却仍引用旧规范中的免 opt-in 结论。

RFC 5370 给出的不是永久豁免，而是一道可以检查的边界。边界由三个事实组成，只有它们仍然成立，原答案才仍然相关。