6.3. 再送要求 (Retransmission Requests)

AVPF プロファイルで定義された NACK フィードバックメッセージ形式を, 受信者は SHOULD で再送要求の送信に用いるべきである. 受信者がパケットを要求するかどうかは実装の問題である. 実際の受信者実装は, 許容できるアプリケーション遅延, ネットワーク環境, メディア型などの要因を考慮すべきである.

受信者は一般に, 再送パケットが受信された時点で依然として有用かどうかを評価すべきである. 欠落パケットのタイムスタンプは, オリジナルストリームで欠落パケットが原因のシーケンス番号ギャップの前後のパケットのタイムスタンプから推定できる. ほとんどの場合, タイムスタンプの何らかの線形推定で十分である.

さらに, 受信者は送信者への往復時間 (RTT) の推定値を算出すべきである. 例えば, あるパケットに対して NACK を送った後に再送パケットを受信するまでの再送遅延を測定することで行える. この推定は過去の観測, 利用可能であれば RTCP レポートの往復時間, または他の手段から得てもよい. 受信者が RTT を推定する標準的な仕組みは "RTP Control Protocol Extended Reports (RTCP XR)" [11] で規定されている.

受信者は, 欠落シーケンス番号を検出した直ちに再送要求を送るべきではなく, パケットの再順序化を補うための追加遅延を加えるべきである. この追加遅延は, 例えば経験したパケット再順序化の過去の観測に基づいてよい. パケットの再順序化が稀であるか発生しない環境, 例えば下位データリンク層が順序付き配送を保証する場合などでは, 遅延は極めて低く, ゼロになりうることに注意すべきである. そのような場合, 適切な「再順序遅延」アルゴリズムはタイマベースではなくパケットベースでありうる. 例えば, ギャップ検出後に n 個のパケットを受信したなら, パケットは真に失われたのであって順序外ではないと仮定してよい. これは一部のプラットフォームでは, タイマベースの仕組みに対して非常に短い固定 FIFO パケットバッファとして実装する方がはるかに容易になりうる.

NACK または再送パケットの損失に対する頑健性を高めるため, 受信者は同一パケットに対して新しい NACK を送ってよい. これを複数回再送 (multiple retransmissions) と呼ぶ. 欠落パケットに対して新しい NACK を送る前に, 受信者はタイマに依存し, 前回の再送試行が失敗したと合理的に確信してからにすべきであり, 不要な再送を避ける. タイマ値は観測された往復時間に基づくこと. 静的または適応的な値を MAY で用いてよい. 例えば, 適応的タイマは同一パケットへの各新規要求ごとに値を変えるものでありうる. 本ドキュメントは, この適応値の算出方法についての指針は提供しない. それを調べる実験が行われていないためである.

NACK は MUST でオリジナル RTP ストリームに対してのみ送られなければならない. そうでないと, 受信者が再送ストリームで NACK を送って複数回再送を行おうとしても, 要求するパケットのオリジナルシーケンス番号とタイムスタンプ推定が分からなくなる.

付録 A は, 再送回数の制御方法についてのいくつかの指針を示す.