3. 重传方案的需求与设计理由 (Requirements and Design Rationale for a Retransmission Scheme)

在 RTP 中将重传作为流式媒体的修复方法, 适用于时延约束较宽松且不要求完全可靠性的场景. 更具体地说, RTP 重传允许在可靠性与时延之间权衡; 即, 端点可以在经过给定缓冲时间后放弃重传丢失的分组. 与 TCP 不同, RTP 重传因此不会造成队头阻塞. 实现者应了解, 在需要完全可靠性或可容忍更高时延与抖动的情况下, 应考虑 TCP 或其他传输选项.

本文档定义的 RTP 重传方案旨在满足下列需求集合:

1. 不得破坏通用 RTP 与 RTCP 机制.

2. 必须适用于单播与小型多播组.

3. 必须能与混流器 (mixer) 与翻译器 (translator) 协同工作.

4. 必须适用于所有已知载荷类型.

5. 不得妨碍在会话中使用多种载荷类型.

6. 为支持最广泛的载荷格式, RTP 接收端必须能够根据所收 RTP 序列号中的间隙推断丢失了多少个以及哪些 RTP 分组. 该需求称为序列号保持 (sequence number preservation). 若无此需求, 则无法将会话文本 [9] 等载荷格式或大多数音视频流式应用配合重传使用, 这些应用依赖 RTP 序列号检测丢包.

在设计 RTP 重传方案时, 可考虑多种对原始 RTP 分组与重传 RTP 分组进行复用的方法.

一种方法是以原始序列号重传 RTP 分组, 并在同一 RTP 流中发送原始分组与重传分组. 此时重传分组将与原始 RTP 分组完全相同, 即相同首部 (因而相同序列号) 与相同载荷. 然而该方法不可接受, 因为它会破坏 RTCP 统计. 结果是无法满足需求 1. 正确的 RTCP 统计要求 RTP 流中每个 RTP 分组的序列号递增一.

另一种方法是在同一 RTP 流中用不同载荷类型值复用原始分组与重传分组. 采用该方法时, 原始分组与重传分组共享同一序列号空间. 其结果是 RTP 接收端无法推断丢失了多少个以及哪些原始分组 (哪些序列号).

换言之, 该方法不满足序列号保持需求 (需求 6). 这又意味着无法满足需求 4. 若混流器与翻译器不理解发送端 RTP 流中的这一新重传载荷类型, 互操作性也会更加困难. 因此, 排除基于同一 RTP 流中按载荷类型复用原始分组与重传分组的方案.

最后, 原始分组与重传分组可在两个独立流中发送. 这两个流可通过两种不同会话发送, 即会话复用; 或在同一会话中用不同 SSRC 值发送, 即 SSRC 复用. 由于原始分组与重传分组承载相同类型的媒体, RTP [3] 第 5.2 节对 RTP 复用的反对意见在此不适用.

混流器与翻译器可以处理原始流, 若无法利用重传流则直接丢弃.

另一方面, 仅在两个独立流中发送原始分组与重传分组本身并不能满足需求 1 与 6. 为此, 本文档在重传分组中包含原始序列号.

这样, 使用两个独立流即可满足本节列出的全部需求.