2. 背景

一个 RTP 会话包含数据包和周期性的控制 (RTCP) 数据包. RTCP 数据包假定使用 "与数据包相同的分发机制", 并且 "底层协议必须提供数据包和控制包的复用, 例如在 UDP 中使用不同的端口号" [1]. 复用被下放到底层传输协议, 而不是在 RTP 内部提供, 原因如下:

简单性: 将 RTP 和 RTCP 解复用移到传输层可以简化 RTP 实现, 因为实现无需关心数据包和控制包的分离. 这使实现能够以非常自然的方式组织, 并清晰分离数据平面和控制平面.
效率: 根据集成层处理 (integrated layer processing) 原则 [15], 当解复用发生在单一位置 (例如依据 UDP 端口) 时, 实现会比将解复用拆分到协议栈的多个层次 (例如先依据 UDP 端口, 再依据 packet type) 更高效.
支持第三方监测器: 虽然单播 IP 语音一直被纳入考虑, RTP 也被设计为支持松耦合的组播会议 [16] 和超大规模的组播流媒体应用程序 (例如所谓的三网融合 IP 电视 (IPTV) 服务). 因此, RTP 的设计允许 RTCP 数据包使用不同于数据包的独立 IP 组播组和 UDP 端口进行组播. 这不仅允许会话参与者获得接收质量反馈, 还支持部署第三方监测器, 使其能够在不访问数据包的情况下监听接收质量. 其目的是在不损害隐私的前提下, 为组播会话提供可管理性.

虽然这些设计选择适用于 RTP 的许多用途, 但在某些情况下会带来问题. 许多 RTP 部署并不使用 IP 组播, 并且随着网络地址转换 (NAT) 的使用增加, 在传输层进行复用的简单性已经变成一种负担, 因为它需要复杂的信令来打开多个 NAT 针孔. 在这类环境中, 更理想的做法是提供一种替代方案, 不再使用独立的 UDP 端口对 RTP 和 RTCP 进行解复用, 而是只使用一个 UDP 端口并在应用程序内部解复用.

本备忘录提供的正是这种替代方案: 在单一 UDP 端口上复用 RTP 和 RTCP 数据包, 并通过 RTP payload type 和 RTCP packet type 值进行区分. 这会给 RTP 实现增加一些额外工作, 换来更简单的 NAT 穿越.