15. Backward Compatibility to RFC 3984 (与 RFC 3984 的向后兼容性)

15. Backward Compatibility to RFC 3984 (与 RFC 3984 的向后兼容性)

本文档是对 RFC 3984 的修订并废止后者. 相对 RFC 3984 的技术变更列于第 14 节. 本节讨论向后兼容性问题.

应注意, 在大多数情形下, 按 RFC 3984 实现的既有实现与按本文档实现的新实现之间互通不会存在兼容性问题. 兼容性问题仅当以下两个条件同时成立时才可能出现: 1) 既有实现与新实现正在互通, 且 2) 参数集采用带外传输. 当出现此类兼容性问题时, 可借助以下分析较容易地定位并找出不兼容的原因.

条目 1, 2, 3, 7, 9, 10, 12 与 13 属于缺陷修复类变更, 不会引起任何向后兼容性问题.

条目 4 (新增六个媒体类型参数) 对基于 SDP Offer/Answer 的应用不会引起向后兼容性问题, 因为按 RFC 3984 的接收端会忽略这些参数, 而按 RFC 3984 的发送端不使用这些可选参数也是可以接受的. 然而, 对基于声明式用法 (declarative usage) 的应用存在向后兼容性问题 (仅针对参数 sprop-level-parameter-sets, 因为其余五个参数在声明式用法中不可用). 例如, 使用 RTSP 与 SAP 且采用声明式用法的应用存在向后兼容性问题, 因为按 RFC 3984 的 SDP 接收端无法接受 SDP 中含有无法识别的参数的会话. 因此, RTSP 或 SAP 服务器可能需要准备两套流, 一套给按 RFC 3984 的接收端, 一套给按本文档的接收端.

条目 5, 6 与 11 与参数集的带外传输有关. 存在如下向后兼容性问题.

1. 当按 RFC 3984 的既有发送端将 profile-level-id 所指示的默认级别之外的级别的参数集放入 sprop-parameter-sets 时, 按本文档的接收端会认为 sprop-parameter-sets 的参数值无效; 因此会话可能被拒绝.

2. 在按 RFC 3984 的要约方与按本文档的应答方之间的 SDP Offer/Answer 中, 当应答方在应答中包含的参数集不是要约中所含参数集的超集时, 要约方会认为 sprop-parameter-sets 的参数值无效, 会话可能无法正确建立 (与变更条目 11 相关).

3. 当按本文档的端点 A 将 in-band-parameter-sets 设为 1 时, 另一侧按 RFC 3984 的端点 B 无法理解其必须在带内传输参数集, B 仍可能在其发送的带内流中不包含参数集. 于是端点 A 无法解码其接收到的流.

条目 7 (允许按 [9] 第 6.3 节通过 fmtp 源属性传递 sprop-parameter-sets 与 sprop-level-parameter-sets) 与条目 4 类似. 对基于 SDP Offer/Answer 的应用不会引起向后兼容性问题, 因为按 RFC 3984 的接收端会忽略 fmtp 源属性, 而按 RFC 3984 的发送端不使用可选的 fmtp 源属性也是可以接受的. 然而, 对基于 SDP 声明式用法的应用 (例如使用 RTSP 与 SAP 者) 存在向后兼容性问题, 因为按 RFC 3984 的 SDP 接收端无法接受 SDP 中含有无法识别的参数 (即 fmtp 源属性) 的会话. 因此, RTSP 或 SAP 服务器可能需要准备两套流, 一套给按 RFC 3984 的接收端, 一套给按本文档的接收端.

条目 14 不会引起向后兼容性问题, 因为仍允许带外传输参数集.

条目 15 不会引起向后兼容性问题, 因为新增的第 8.5 节为参考性内容.

条目 16 不会产生向后兼容性问题, 因为若任一端符合 RFC 3984, 对默认级别的处理方式相同; 此外, 符合 RFC 3984 的端点若遇到新的媒体类型参数, 会直接忽略之.