3. 再送方式の要件と設計根拠 (Requirements and Design Rationale for a Retransmission Scheme)

RTP における再送をストリーミングメディアの修復手法として用いるのは, 遅延上界が緩く, 完全な信頼性が必須でないシナリオに適している. より具体的には, RTP 再送は信頼性と遅延のトレードオフを可能にする, すなわちエンドポイントは所定のバッファ時間が経過した後は失われたパケットの再送を諦めてよい. したがって TCP とは異なり, RTP 再送によってヘッドオブラインブロッキングは生じない. 実装者は, 完全な信頼性が必要な場合やより高い遅延とジッタが許容できる場合には, TCP または他のトランスポート選択肢を検討すべきであることを認識すべきである.

本ドキュメントで定義する RTP 再送方式は, 次の要件集合を満たすように設計されている.

1. 一般的な RTP および RTCP の仕組みを壊してはならない.

2. ユニキャストおよび小規模マルチキャストグループに適していなければならない.

3. ミキサおよびトランスレータと動作しなければならない.

4. 既知のすべてのペイロード型と動作しなければならない.

5. セッション内で複数のペイロード型の使用を妨げてはならない.

6. 可能な限り広い種類のペイロード形式を支援するため, RTP 受信者は, 受信 RTP シーケンス番号のギャップの結果として, いくつのどの RTP パケットが失われたかを導出できなければならない. 本要件はシーケンス番号保持 (sequence number preservation) と呼ばれる. この要件がなければ, RTP シーケンス番号でパケット損失を検出する会話テキスト [9] やほとんどの音声/動画ストリーミングアプリケーションなどのペイロード形式では再送を用いることができない.

RTP 再送の解を設計する際, オリジナルの RTP パケットと再送された RTP パケットの多重化について, いくつかのアプローチが考えられうる.

一つのアプローチは, 元のシーケンス番号で RTP パケットを再送し, オリジナルと再送を同一 RTP ストリームで送ることである. 再送パケットはオリジナルの RTP パケットと同一, すなわち同一ヘッダ (したがって同一シーケンス番号) および同一ペイロードとなる. しかし, このアプローチは RTCP 統計を破壊するため受け入れられない. その結果, 要件 1 を満たさない. 正しい RTCP 統計では, RTP ストリーム内の各 RTP パケットについてシーケンス番号が 1 ずつ増加しなければならない.

別のアプローチは, 異なるペイロード型の値を用いてオリジナル RTP パケットと再送パケットを同一 RTP ストリームに多重化することである. このアプローチでは, オリジナルパケットと再送パケットは同一のシーケンス番号空間を共有する. その結果, RTP 受信者は, いくつのどのオリジナルパケット (どのシーケンス番号) が失われたかを推論できない.

言い換えれば, このアプローチはシーケンス番号保持要件 (要件 6) を満たさない. これはさらに要件 4 を満たさないことを意味する. ミキサおよびトランスレータが送信者 RTP ストリーム内のこの新しい再送ペイロード型を理解しない場合, 相互運用性もより困難になる. これらの理由から, 同一 RTP ストリーム内でのオリジナルパケットと再送パケットのペイロード型多重化に基づく解は除外される.

最後に, オリジナルと再送パケットは 2 つの別ストリームで送られてよい. これら 2 ストリームは, 2 つの異なるセッションで送るセッション多重化 (session-multiplexing), または異なる SSRC 値を用いて同一セッションで送る SSRC 多重化 (SSRC-multiplexing) のいずれかで多重化できる. オリジナルと再送パケットは同種のメディアを運ぶため, この場合 RTP [3] の 5.2 節の RTP 多重化に対する異論は当てはまらない.

ミキサおよびトランスレータはオリジナルストリームを処理し, 再送ストリームを利用できない場合は単に破棄してよい.

一方, オリジナルと再送パケットを 2 つの別ストリームで送ることだけでは要件 1 および 6 を満たさない. この目的のため, 本ドキュメントは再送パケットにオリジナルのシーケンス番号を含める.

このように, 2 つの別ストリームを用いることで本節に列挙したすべての要件を満たす.