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

3.3. 動作モード

RTCP ベースのフィードバックは, 以下に述べる 3 つのモードのいずれかで動作しうる (図 1). 動作モードは, 受信者が平均してすべての事象をタイムリーに送信者へ報告できるかどうかの目安にすぎず, FB メッセージ送信のスケジューリングに用いるアルゴリズムには影響しない.

受信品質と RTP セッションのローカル監視状態に応じて, 個々の受信者は現在の動作モードについて共通の認識に達しないことがあり, 達する必要もない.

a) Immediate Feedback モード: このモードではグループサイズが FB しきい値未満であり, 各受信側に意図した目的の RTCP フィードバックパケットを送るのに十分な帯域がある. つまり各受信者について, ほぼ「即時」の RTCP フィードバックパケットで各事象を報告するのに十分な帯域がある.

グループサイズのしきい値は, 用いるフィードバックの種類 (例: ACK と NACK), 帯域, パケットレート, パケット損失確率と分布, メディアタイプ, コーデック, 報告する事象の (最悪または観測された) 頻度 (例: フレーム受信, パケット損失) など複数のパラメータの関数である (必ずしもこれに限らない).

粗い推定として, 受信者が間隔 T あたりに報告する平均事象数を N, その受信者の RTCP 帯域割合を B, 平均 RTCP パケットサイズを R とすると, N<=B*T/R の間は受信者は Immediate Feedback モードで動作する.

b) Early RTCP モード: このモードではグループサイズなどのパラメータにより, 各受信者が報告に値する (または報告が必要な) 各事象に反応できなくなる. それでもフィードバックは十分な頻度で与えられ, 送信者がメディアストリーム送信を適応させ全体の再生品質を高められる.

上記の記法では, Early RTCP モードはおおむね N > B*T/R で「下限」として特徴づけられる. 上限の推定は難しい. N=1 とすると, 与えられた R と B に対して報告する事象間の平均間隔として T = R/B が得られる. この情報は RTCP パケットの早期送信が有用かどうか判断するヒントにできる.

c) Regular RTCP モード: あるグループサイズ以上では, 受信者から個々の事象へのフィードバックはもはや有用でない. フィードバックが提供されうる時間尺度のため, および/または大規模グループでは送信者が個々のフィードバックに反応できないためである.

このモードが始まる正確なグループサイズしきい値は指定できないが, 明らかにこの境界は上記 b) の Early RTCP モードの上限と一致する.

本ドキュメントのフィードバックアルゴリズムは滑らかにスケールするため, 参加者間でグループ内の各 FB しきい値の正確な値について合意する必要はない. したがってこれらのモード間の境界はあいまいである.

    ACK
  feedback
    V
    :<- - - -  NACK feedback - - - ->//
    :
    :   Immediate   ||
    : Feedback mode ||Early RTCP mode   Regular RTCP mode
    :<=============>||<=============>//<=================>
    :               ||
   -+---------------||---------------//------------------> group size
    2               ||
     Application-specific FB Threshold
        = f(data rate, packet loss, codec, ...)

                  Figure 1: Modes of operation

前述のとおり, 各 FB しきい値はコーデック, トランスポート, 用いるフィードバックの種類などの技術パラメータだけでなくアプリケーションシナリオにも依存する. セクション 3.6 ではこれらのしきい値を見積もる際の有用なヒント (正確な計算はない) を示す.

に最終更新