摘要

  • RFC 3407 让端点声明当前能够且愿意支持的媒体格式，却没有因此把会话绑定到任何一种格式。
  • 能力声明、后续 offer/answer 选择和实际媒体是否工作，是三张不能互相替代的收据。

早期 SDP 的困难不是缺少列表，而是同一个列表承担了两种职责。m= 行既描述本次会话的实际媒体参数，又被拿来展示设备还支持哪些选项。多个 codec 同时出现时，接收方容易把它读成并行承诺；但网关的 DSP 内存与处理能力也许只允许其中一种组合。每项单独可行，不等于所有项可以同时成立。

RFC 3407 添加了一个刻意简化、向后兼容的能力声明。新属性可以被旧实现忽略。声明中的格式只表示端点在当前会话背景下有能力、也愿意与该对端尝试使用。它没有选择格式，更没有定义怎样达成选择。真正启用仍需范围之外的机制，例如 RFC 3264 的 offer/answer。

标准因此写下一个关键禁令：看到某种格式出现在能力集中，不能假定随后只用该格式的协商会成功。对端可能不接受，资源可能变化，参数可能不兼容，组合也可能超出设备能力。声明使一次尝试有依据，却不替尝试签发结果。

能力集还具有完整性和时间边界。一个序号覆盖整个集合；新的完整集合一旦到达，旧集合立即失效。序号从零开始、按模 256 递增，但接收者可能错过中间更新，因此不能仅凭序号跳跃拒绝新集合。它标记声明时代，不是可靠传输日志，也不是单独的防重放证据。

作用域同样限制推论。会话级能力适用于指定媒体类型的所有流；媒体级能力只属于关联的那条 m= 行，即使它声明的媒体类型不同。会话级声明若找不到同类型媒体流，除非整个会话只有一条流，否则作用对象未定义。相同内容放在不同位置，权力边界不同。

格式名也不是完整声明。cpar 可以限定格式参数或带宽条件，cparmin 与 cparmax 表达一个数值区间。忽略这些条件再发起协商，可能得到失败结果，而原来的能力声明仍然完全真实。缺失的不是诚实，而是上下文。

能力编号只是某个序号集合内的句柄，编号缺口也不能单独触发拒绝。外部程序可以引用句柄，但 RFC 3407 不规定引用如何变成协议选择。它主动把“描述”和“决策”分开。

安全风险出现在二者连接处。敏感参数若在没有认证的情况下重新协商，攻击者可能诱导降级，也可能不断触发协商造成拒绝服务。某个弱选项真实存在，并不意味着它可以在任何信任条件下被授权使用。

2010 年的 RFC 5939 后来提供了更完整的模型：能力、候选配置、实际配置以及 offer/answer 程序。它建议新实现采用这套框架，同时允许为旧对端并列携带 RFC 3407 描述。它并未正式废止 RFC 3407，而且明确规定自己的协商程序不会消费旧能力描述。两套语法可以同车运输，却不是同一个决策链。

这段历史适用于今天的功能矩阵、硬件清单和 API 能力发现。它们证明某项操作在某个范围与时刻可能被支持，不证明双方已经选择，不证明资源仍在，也不证明运行结果。把三种观察分别保存，才不会让库存替代事实。

来源