摘要

  • RFC 5369 是 Informational 框架，不是互联网标准。它讨论如何发现 SIP 会话的转码需要，以及如何用第三方呼叫控制或会议桥模型调用服务。
  • Presence 与 SDP 能提供能力证据，但并行分叉可能让真正应答的终端仍然未知。应在确认实际应答端缺少所需能力后再引入 T，否则两端可能为本来兼容的会话各加一个转码器。
  • 3pcc 可以按媒体流和方向选择 T；会议桥减少调用端信令，却集中更多路径。任何 T 都必须读取并修改媒体，因而普通端到端媒体机密性与完整性不能原样穿过它。

能力必须带着主体

“对方只支持音频”缺少主体。它可能描述某台电话、语音信箱、软客户端，也可能只是过期的 presence 投影。

RFC 5369 列出两类发现方式。Presence 文档可以发布媒体能力；SDP 能在 OPTIONS 的 200 响应、INVITE 的 488 响应或 offer/answer 中暴露能力。

每条证据都有发布者、终端、时间与事务。把设备能力压缩成人员属性，会丢掉路由决策最需要的字段。

记录应保存来源、版本、Contact、新鲜度与适用范围。只有这样，自动化才能说明它为什么把某条流交给 T。

分叉让应答端晚于预测出现

SIP 可以把 INVITE 并行发给多个用户代理。不同分支可能到达电话、客户端或语音信箱，它们的能力集合并不相同。

在缺少足够 presence 的情况下，呼叫方可能无法预知哪一端会应答。RFC 5369 把这类困难联系到 HERFP，并明确不在本文中解决。

不解决并不等于忽略。系统需要区分候选分支、临时响应、最终 Contact、对话与协商结果。

转码判断应绑定最终应答端，而不是绑定某个此前曾经应答过的设备或一个人员级标签。

过早插入可能产生两个 T

RFC 5369 建议 offerer 在确认 answerer 不支持所需能力前，不要调用转码服务。

如果两端都根据预测行动，A 和 B 可以各自加入 T。两个本来共享 GSM 的端点，可能被迫经历 GSM 到 PCM 再回到 GSM 的转换。

多余转换意味着更多延迟、质量损失、成本、故障点与媒体接触方。它不是单纯的资源浪费。

自动策略应要求一份与应答端绑定的不兼容收据。“常见设备不支持”或“上一次失败”都不能替代本次协商。

需要与服务发现是两件事

RFC 5369 不定义媒体服务器发现，而是假定调用端已知服务器 URI。

因此，发现不兼容不会自动选出可信服务。还要验证 T 是否支持具体输入、输出、方向、语言与策略。

服务目录中的名称不能证明容量、时延、管辖区、保留规则或当前健康。URI 只是候选入口。

完整链条包括不兼容、服务选择、T 身份、A–T 协商、T–B 协商、媒体接收、转换输出与终止。

人的需要不是终端故障

两个终端可能没有共同编解码器。终端也可能完全解码音频，但失聪用户无法理解内容。

RFC 5369 对终端级与用户级不兼容使用相同的 SIP 调用机制。这不代表两类证据相同。

编解码器交集可以机械计算；无障碍需要个人偏好、语言、表现形式、方向与时间要求。

转码可以对称，也可以只做一个方向。状态“已开启”不能说明它是否解决了用户真实需要。

3pcc 把会话拆成逐流路径

在 3pcc 模型中，调用端分别与 T 和远端保持信令关系。T 不与远端直接建立信令关系。

高级终端可以只让不兼容的媒体流经过 T。音频已经兼容时，它可以保持 A–B 直连；视频单独经过转换。

同一媒体流的发送与接收方向还可以选择不同 T。信任、成本与失败域因而具有方向性。

RFC 5369 把这种模型的信令隐私描述为较高，因为 T 看不到端到端信令。这个结论不包括它必须处理的媒体。

逐流选择需要逐流收据

拓扑图上画一条直线和一条折线并不证明实现遵守了选择。ICE、SDP、媒体地址与实际包流都可能漂移。

每条流应保存媒体类型、方向、端点、T、协商格式、观察时间与终止原因。会话级布尔值会隐藏多余暴露。

故障转移也必须维持同样的边界。视频 T 失败时，不应为了方便把音频一并迁入另一个服务，除非有新的授权。

质量指标要按流读取。总会话成功率无法显示字幕延迟或单向转换丢失。

会议桥减少了终端的信令

会议桥模型把 T 当作两人会议服务器。T 作为 B2BUA 分别协商 A–T 与 T–B。

调用端一般需要更少信令，对低带宽、高时延接入和简单终端可能重要。

代价是不能为不同流或方向选择不同转码器。桥接服务成为更集中的媒体与信令权威。

所谓“简单”只属于终端侧。运维、隐私、故障定位和审计可能更复杂。

会话中途改变暴露依赖

会话可以先建立共同音频，再增加不兼容视频。转码需要可能在中途才出现。

RFC 5369 认为 3pcc 插入 T 相对直接。会议桥模型在插入或更换 T 时要求远端支持 Replaces 扩展。

文档在 2008 年称当时支持者不多。这是历史描述，不是今天的采用率。

变更前必须验证实际应答端，而不是产品系列。还应保存旧路径、新路径、切换点、回退与媒体连续性。

认证 T 只回答它是谁

T 必须读取媒体才能转换。RFC 5369 建议认证转码器，避免恶意服务获取媒体。

认证不证明 T 只收到必要流，也不证明转换正确、数据未保留或输出未泄露。

如果端到端加密让 T 无法读取，或完整性保护让 T 无法修改，它就无法完成工作。端点仍可分别保护 A–T 与 T–B。

“两段均加密”不是“只有 A 和 B 能看见”。产品必须披露媒体在 T 处终止保护的事实。

不同方向使用不同 T 缩小单点视图

3pcc 可以让 T1 处理发送方向，T2 处理返回方向，从而没有单个 T 看见全部媒体。

这减少一种集中，却增加两套身份、授权、日志、保留与故障处理。共同运营方或时间关联仍可能重建上下文。

隐私声明应限定为“单个转码器不接触双向内容”，而不是“系统无法获得完整会话”。

收据要逐方向列出服务、流、密钥边界、转换、输出与删除。

文档状态不能替代运行证据

RFC 5369 于 2008 年 10 月以 Informational 发布，并明确不是互联网标准。

它引用当时的 TLS 与 S/MIME 文档。RFC 5246 后来被 RFC 8446 取代；RFC 3850 属于较早的 S/MIME 谱系。本文不据此提供当前配置建议。

RFC 3265 后来被 RFC 6665 取代。标准演进不会把旧 presence 自动变成新应答端的事实。

RFC 3351 提供无障碍需求背景，RFC 4117 与 RFC 5370 描述两种调用模型。文档存在不等于实际部署成功。

媒体到达不等于人已理解

能力发布、应答端、不兼容、T 选择、两腿协商、媒体接收、输出产生与人的理解分别需要证据。

正确 RTP 流只能证明一层。转写文本存在也不能证明及时展示、语言正确或用户理解。

Lu Heng 的“最小初始规范”作为明确分析视角：共同合同只定义必要边界，终端与用户保留基于本地信息的判断。“现实层”让 presence、SDP、响应、媒体路径与理解保持不同层。协议事实仍由 RFC 支撑。