メインコンテンツまでスキップ

1. はじめに (Introduction)

RTP 送信者と受信者の間のパケット損失は, 受信メディアの品質を著しく低下させることがある. 前方誤り訂正 (FEC), 再送, インタリーブなど, パケット損失耐性を高める手法が考えられる. RFC 2354 [8] が各選択肢を論じている.

あるアプリケーション向けに修復手法を選ぶ際には, 許容できる遅延を考慮しなければならない. マルチメディア会議では, 対話性を保つためにエンドツーエンド遅延はせいぜい数百ミリ秒程度に抑える必要があり, 通常は再送は用いられない.

十分な遅延があれば, 修復方式の効率を上げられる. 送信者は受信者のフィードバックを利用し, 受信者側の再生時刻より前に損失に対応できる.

マルチメディアストリーミングでは, ユーザーはセッション確立時の初期遅延を許容でき, 数秒のエンドツーエンド遅延が許容されうる. 本ドキュメントで定義する RTP 再送は, そのようなアプリケーションを対象とする.

さらに, ここで定義する RTP 再送方式はユニキャストおよび (小規模な) マルチキャストグループに適用できる. 本ドキュメントは再送された RTP パケットのペイロード形式を定義し, 再送に関与する送信者と受信者のプロトコル規則を示す.

この再送ペイロード形式は, RTCP ベースフィードバック用拡張 RTP プロファイル AVPF [1] との併用を想定して設計されている. 将来定義される他の RTP プロファイルでも利用しうる.

AVPF プロファイルは, より頻繁なフィードバックと早期フィードバックを許す. 汎用フィードバックメッセージ (NACK) およびコーデック・アプリケーション固有のフィードバックメッセージを定義する. 詳細は [1] を参照.