3.5. AVPF RTCP スケジューリングアルゴリズム

S0 をアクティブ送信者 (S 人の送信者のうちの 1 人), N を受信者数, R をそのうちの 1 人とする.

R は, 現在の構成でフィードバック機構を用いることが妥当であることを検証済みであると仮定する (これはアプリケーションに強く依存し, 本ドキュメントでは指定しない).

さらに, Regular RTCP パケット間の最小間隔を強制しない場合は T_rr_interval を 0 とし, アプリケーションが与える意味のある値に設定する場合はそれを用いると仮定する. この値は Regular RTCP パケット間の最小間隔を表す.

このとき, 受信者 R は, 1 つ以上の FB メッセージを最小または完全な複合 RTCP パケットとして送信する際に, 以下の規則を用いなければならない (MUST).

3.5.1. 初期化

初期状態で, R は allow_early = TRUE, t_rr_last = NaN (Not-a-Number, すなわち有効な時刻と区別できる無効値) としなければならない (MUST).

さらに, [1] に従う RTCP 変数の初期化が適用されるが, Tmin の初期値は除く. ポイントツーポイントセッションでは初期 Tmin は 0 とする. マルチパーティセッションでは Tmin を 1.0 秒で初期化する.

3.5.2. Early フィードバックの送信

R が最後の Regular RTCP RR パケットを tp で送信するよう (実際に tp で送るか抑止するかは問わない) スケジュールし, 次の送信を [1] の reconsideration を含め tn = tp + T_rr にスケジュールしたとする. また最後の Regular RTCP 送信が t_rr_last で行われたとする.

Early フィードバックアルゴリズムは次の手順からなる.

1. 時刻 t0 に, R は 1 つ以上の FB メッセージ送信の必要性を検出する (例: メディア「単位」の ACK/NACK が必要など), かつフィードバック情報が送信者にとって有用になりうると判断する.

2. R はまず, 送信予定の複合 RTCP パケット (Early または Regular) に 1 つ以上の FB メッセージが既に含まれているかを確認する.

   2a) 含まれる場合, 新しい FB メッセージはその予定パケットに含めなければならない (MUST). 待機中の複合 RTCP のスケジュールは変更してはならない (MUST). 可能なフィードバック情報は統合し, FB メッセージ数を最小にすることが望ましい (SHOULD). これで直ちに取るべき処理は完了する.

   2b) 予定がない場合, 新しい (最小または完全な) 複合 RTCP を作成し, T_dither_max の最小間隔は次のように選ばなければならない (MUST):

   i) ポイントツーポイントなら T_dither_max = 0.

   ii) マルチパーティなら T_dither_max = l * T_rr, l=0.5.

   T_dither_max は別法 (例: RTT 基準) で計算してもよい (MAY) が, その場合は将来の文書で指定しなければならない (MUST). その指定は, すべての RTP 受信者が同じ T_dither_max 計算機構を用いることを保証しなければならない (MUST).

   上記は最小値である. アプリケーション固有の考慮で T_dither_max を大きくしてもよく, 実装者の判断に委ねられる.

3. 次に R は, t0 で発火した Early RTCP の時間枠内に次の Regular RTCP が入るか, すなわち t0 + T_dither_max > tn かを確認しなければならない (MUST).

   3a) 真なら, Early RTCP をスケジュールしてはならない (MUST NOT). FB は tn の Regular に含めるよう保存する (MUST). 直ちの処理は完了.

   3b) 偽なら以下を実行.

4. R は Early RTCP を送ってよいか, すなわち allow_early == TRUE かを確認しなければならない (MUST).

   4a) FALSE なら, 次の Regular の時刻を確認する (MUST):

   1. tn - t0 < T_max_fb_delay なら, 遅延報告でも有用になりうる. R は tn の Regular に含める FB を作成してもよい (MAY).

   2. そうでなければ FB を破棄しなければならない (MUST).

   直ちの処理は完了.

   4b) TRUE なら, te = t0 + RND * T_dither_max に Early RTCP をスケジュールする (MUST). RND は 0〜1 の一様疑似乱数である.

5. R は, セッション他メンバーから受信した FB と自分が送りたい FB の重なりを検出しなければならない (MUST). そのため RTP セッションの間, R は (最小) 複合 RTCP の到着を常時監視し, 各 FB を少なくとも T_retention 保存しなければならない (MUST). 手順 1〜4 に従って自 FB をスケジュールする際, 区間 [t0 - T_retention ; te] で受信した RTCP 内の保存済みおよび新規 FB それぞれについて次を行う (MUST):

   5a) 受信 FB の意味が分かり, かつ内容が自分が送ろうとしたフィードバックの上位集合なら, 自 FB を破棄し (MUST), 次の Regular を前に計算した tn に再スケジュールする (MUST).

   5b) 意味が分かり, 上位集合でないなら, 予定どおり自 FB を送ることが望ましい (SHOULD). 送る情報と受信情報が重なる場合, 送信量は R の裁量. 変更しないでもよい (MAY), 他メンバーのフィードバックとの冗長を除いてもよい (MAY).

   5c) 意味が分からない場合, Early のままにしてもよい (MAY), または次の Regular を tn に再スケジュールし (MAY), FB をその Regular に付加してもよい (MAY).

   注: 5c) により未知の FB では特定受信者でフィードバック抑制が起きないことがある. よって 1 事象が M 種類の (それぞれ適切だが相互に解釈できない) FB を生じ, 「大きい」受信者群は多くとも M グループに分割されうる. 各グループ内では 5a/5b に従い抑制が起きるがグループ間では起きない. 結果として送信者は O(M) の RTCP FB を受けうる (限定的なフィードバック implosion の可能性). ただし同一アプリケーション・同一コーデック集合の同一 RTP セッションでは, FB 意味の分岐は小さく M も一般に小さいと仮定できる.

   さらに O(M) の FB が T_dither_max 上にランダム分散されると, 追加複合 RTCP は (a) 送信者を圧倒しないと想定され, (b) 補完的な情報を含むため伝達すべきである.

6. 手順 5 により他受信者 FB によって自 FB が抑制されなかった場合, te に達したら R は自 FB を含む (最小) 複合 RTCP を送信しなければならない (MUST). その後 allow_early = FALSE, tn = tp + 2*T_rr を再計算し, tp を直前の tn に設定する (MUST). 新 tn に達したら, 次の Regular を送るか T_rr_interval で抑止するかにかかわらず, allow_early = TRUE に戻さなければならない (MUST).

3.5.3. Regular RTCP の送信

完全な複合 RTCP は定期的に送らなければならない (MUST). 1 つ以上の FB を含んでもよい (MAY). Regular のスケジュールは次のとおり.

T_rr_interval == 0 の場合, 送信は本ドキュメントのセクション 3.2 および 3.4 に従い, セクション 3.5.2 の tn 調整 (Early 送信があれば 1 回の Regular をスキップ) に従わなければならない (MUST). タイマ reconsideration は [1] に従い tn で行う. Regular は reconsideration 後に送信する. Regular を送るか抑止するたびに allow_early を TRUE にし, tp,tn を [1] に従って更新しなければならない (MUST). 最初の Regular 送信後, Tmin を 0 にしなければならない (MUST).

T_rr_interval != 0 の場合, 送信時刻の計算はセクション 3.2, 3.4 および 3.5.2 の tn 調整に従わなければならない (MUST). tn で [1] の reconsideration の後:

1. まだ Regular を送っていない (t_rr_last == NaN) なら Regular をスケジュールする (MUST). 保存済み FB を含んでもよい (MAY). 送信後 t_rr_last = tn, Tmin = 0 とする (MUST).

2. そうでなければ一時値 T_rr_current_interval = RND*T_rr_interval (RND は 0.5〜1.5 一様) を用い:

   2a) t_rr_last + T_rr_current_interval <= tn なら Regular をスケジュール (MUST). 保存 FB を含んでもよい (MAY). 送信後 t_rr_last = tn (MUST).

   2b) t_rr_last + T_rr_current_interval > tn かつ FB が保存待ちなら, tn に RTCP をスケジュール (MUST). 最小または Regular は実装者の裁量 (MAY) だが, 保存 FB を含む複合 MUST とする. t_rr_last は不変 (MUST).

   2c) 同じ不等式で FB 待ちがなければ複合を抑止する (MUST NOT スケジュール). t_rr_last 不変 (MUST).

いずれの場合も (1, 2a, 2b, 2c), allow_early を TRUE にし (Regular 送信後であっても可), tp,tn を [1] に従って更新するが, 5 秒最小の例外は除く (MUST).

3.5.4. その他の考慮

T_rr_interval != 0 の場合, RTP/AVPF 実体のタイムアウト計算 ([1] のセクション 6.3.5) は, Td および M*Td の算出に Tmin の代わりに T_rr_interval を用いるよう変更しなければならない (MUST).

複合 RTCP (最小/完全, Early/Regular) を送受信するたびに avg_rtcp_size を更新し (MUST, [1] 参照), 以降の tn 計算は新しい avg_rtcp_size を用いなければならない (MUST).