4. RTCP 受信者レポート拡張

本メモは 6 つの新しいフィードバックメッセージを規定する. Full Intra Request (FIR), Temporal-Spatial Trade-off Request (TSTR), Temporal-Spatial Trade-off Notification (TSTN), および Video Back Channel Message (VBCM) は, AVPF [RFC4585] のセクション 6.3 で定義される「ペイロード固有フィードバックメッセージ」である. Temporary Maximum Media Stream Bit Rate Request (TMMBR) および Temporary Maximum Media Stream Bit Rate Notification (TMMBN) は, AVPF のセクション 6.2 で定義される「トランスポート層フィードバックメッセージ」である.

新しいフィードバックメッセージは, 以下のサブセクションで定義され, AVPF 仕様 [RFC4585] のセクション 6.2 および 6.3 と類似した構成に従う.

4.1. 拡張メカニズムの設計原則

RTCP はもともと, プレゼンス, 受信品質統計, 望ましいメディア符号化に関するヒントを伝えるチャネルとして導入された. 限定的なメディア制御機構は, 例えば RFC 2032 [RFC2032] (RFC 4587 [RFC4587] により廃止) のような初期の RTP ペイロード形式のビデオ形式で導入された. しかし本仕様は, 初めて一部のメッセージに双方向ハンドシェイクを提案する. この導入が, RTCP を RTP セッション制御プロトコルとして用いる先例と誤解される危険がある. そのような誤解を防ぐため, 本サブセクションは本メモで規定する拡張の範囲を明確にし, 将来の拡張がここに述べる論拠に従うか, あるいは逸脱する理由を説得力をもって説明することを強く推奨する.

本メモおよび AVPF [RFC4585] に含まれるメッセージは, 次の条件を満たすものに限られる.

a) 比較的厳しいリアルタイム制約を有し, 多くの応用シナリオでは SIP re-invite などの機構の使用を妨げる (リアルタイム制約は必要に応じて各メッセージごとに別途説明する).

b) 各メッセージについて必要に応じて, 矛盾しうるフィードバックメッセージへの反応が規定されており, マルチキャストに安全である.

c) 特定のメディアコーデック, メディアコーデックのクラス (例: ビデオコーデック), または所定の RTP パケットストリームの活動に直接関連する.

本メモでは, 次の条件を満たすメッセージに限り双方向ハンドシェイクを導入する.

a) その性質上, 通知または確認応答が必要である. この要件の有無を判断する分析は, 各メッセージごとに別途行われた.

b) 通知または確認応答は, メディアビットストリームから容易に導出できない.

AVPF [RFC4585] および本メモのすべてのメッセージは, 内容を単純で固定されたバイナリ形式で示す. これにより, メディアパスに上位制御プロトコル機能 (SDP, XML パーサなど) を実装していないメディア受信者にも対応できる.

直前に述べた設計原則に適合しないメッセージは, RTCP または本文書で定義する Codec Control Framework の適切な用法ではない.

4.2. トランスポート層フィードバックメッセージ

RFC 4585 [RFC4585] のセクション 6.1 で規定されるとおり, トランスポート層フィードバックメッセージは RTCP パケット型の値 RTPFB (205) で識別される.

AVPF ではこのカテゴリのメッセージが 1 つ定義されていた. 本メモはさらに 2 つを規定する. これらはフィードバックメッセージ型 (FMT) パラメータにより次のように識別される.

AVPF [RFC4585] で割り当て済み:

• 1: Generic NACK
• 31: 識別子番号空間の将来拡張のため予約

本メモで割り当て:

• 2: 予約 (下記注記参照)

• 3: Temporary Maximum Media Stream Bit Rate Request (TMMBR)

• 4: Temporary Maximum Media Stream Bit Rate Notification (TMMBN)

  注: AVPF [RFC4585] の初期版では FMT=2 が, 後に削除されたコードポイント用に予約されていた. 期限切れ文書に従いフィールドでこの値を用いている実装が存在しうることが指摘されている. 番号空間に十分な余裕があるため, FMT=2 を予約として印付けし, そのような初期実装との相互運用上の問題を避ける.

割り当て可能:

• 0: 未割り当て
• 5-30: 未割り当て

次のサブセクションは, TMMBR および TMMBN メッセージそれぞれの Feedback Control Information (FCI) エントリの形式を定義し, メディア送信者および受信者における関連動作を規定する.

4.2.1. Temporary Maximum Media Stream Bit Rate Request (TMMBR)

Temporary Maximum Media Stream Bit Rate Request は, RTCP パケット型の値 PT=RTPFB および FMT=3 で識別される.

Temporary Maximum Media Stream Bit Rate Request (TMMBR) メッセージの FCI フィールド SHALL, 1 つ以上の FCI エントリを含む.

4.2.1.1. メッセージ形式

Feedback Control Information (FCI) は, 次の構文をもつ 1 つ以上の TMMBR FCI エントリで構成される.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp |  MxTBR Mantissa                 |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2 - Syntax of an FCI Entry in the TMMBR Message

• SSRC (32 ビット): 新しい最大ビットレートに従うよう求められるメディア送信者の SSRC 値.

• MxTBR Exp (6 ビット): 最大合計メディアビットレート値の仮数部に対する指数スケーリング. 値は符号なし整数 [0..63].

• MxTBR Mantissa (17 ビット): 最大合計メディアビットレート値の仮数部を符号なし整数として表す.

• Measured Overhead (9 ビット): 測定された平均パケットオーバーヘッド値 (バイト). 測定 SHALL, セクション 4.2.1.2 の記述に従って行う. 値は符号なし整数 [0..511].

最大合計メディアビットレート (MxTBR) 値 (ビット毎秒) は, MxTBR 指数 (exp) と仮数部から次のように計算される.

MxTBR = mantissa * 2^exp

これにより, 0 から 1310722^63 (約 1.210^24) の範囲で 17 ビットの分解能が得られる.

TMMBR フィードバックメッセージの長さ SHALL, N を TMMBR FCI エントリ数として 2+2*N に設定する.

4.2.1.2. 意味論

メディア受信者 (TMMBR の送信者) の動作

TMMBR は, メディア受信者として動作する報告エンティティにおけるトランスポート関連の制限を示すために用いられる. TMMBR は 2 つの成分を含むタプルの形式をとる. 第 1 の値は, 受信者が選択したプロトコル層で利用可能な, この RTP セッションで受信者が現在サポートするメディアストリームあたりの送信者ごとの最高ビットレートである. 第 2 の値は, セクション 2.2 で定義され, ストリームに対して受信したパケットで選択したプロトコル層で測定されたヘッダオーバーヘッド (バイト) である. オーバーヘッドの測定は, この特定のメディアソース (SSRC) に対して受信する各パケットについて更新される移動平均であり, 次の式を用いる.

avg_OH (new) = 15/16*avg_OH (old) + 1/16*pckt_OH,

ここで avg_OH は移動 (指数平滑) 平均であり, pckt_OH は最新パケットで観測されたオーバーヘッドである.

最大ビットレートがシグナリングで交渉済みの場合, 受信者が TMMBR メッセージで報告する最大合計メディアビットレート MUST NOT, 共通基準 (すなわち同じ参照プロトコル層に揃えるようオーバーヘッドを調整した) に変換した交渉値を超えてはならない.

フィードバックメッセージ用の共通パケットヘッダ ([RFC4585] のセクション 6.1 で定義) では, 「SSRC of packet sender」フィールドが要求の発生源を示し, 「SSRC of media source」は用いられず SHALL 0 に設定する. 特定の TMMBR FCI エントリ内では, FCI フィールドの「SSRC of media source」がタプルが適用されるメディア送信者を示す. これは, 報告エンティティが複数の FCI エントリを用いて 1 つの TMMBR メッセージですべてのメディア送信者に宛てるマルチキャストまたはトランスレータトポロジーで有用である.

メディア受信者 SHALL, 各メディア送信者から受信した最新の TMMBN メッセージの内容を保存する.

メディア受信者 MAY, 次の状況で特定のメディア送信者に TMMBR FCI エントリを送る.

• そのメディア送信者からまだ TMMBN メッセージを受信する前.

• 受信者がそのメディア送信者から受信した最新の TMMBN メッセージ内の境界タプルの発生源として識別されており, そのメディア送信者に関する最大合計メディアビットレートまたはオーバーヘッドの値が変化したとき.

• 受信者がそのメディア送信者から受信した最新の TMMBN メッセージ内の境界タプルの発生源として識別されておらず, 受信者がセクション 3.5.4.2 の増分アルゴリズムまたはそれ以上に厳しい同等の手続を適用した後, そのメディア送信者に関する受信者のタプルが境界集合に属すると判定されたとき.

メディア送信者から次の RTCP パケット送信時点で Temporary Maximum Media Stream Bit Rate Notification (TMMBN) の FCI を受信していない場合, 後続の TMMBR メッセージで TMMBR FCI エントリを繰り返してもよい (MAY). TMMBR FCI エントリのビットレート値は, TMMBR メッセージ間で変更してもよい (MAY). オーバーヘッド測定 SHALL, エントリが送られるたびに avg_OH の現在値に更新する.

TMMBR メッセージで設定する値が恒久的であると期待される場合, TMMBR を設定する側 SHOULD, セッション確立シグナリング (例: SIP re-invite) を用いてセッションパラメータを再交渉し, それを反映すべきである.

メディア送信者 (TMMBR の受信者) の動作

自分に関する FCI エントリを含む TMMBR メッセージを受信したとき, メディア送信者 SHALL, 新しい情報に基づき境界タプル集合を決定するために, 適用可能な初期または増分アルゴリズムを用いる. 用いるアルゴリズム SHALL, セクション 3.5.4.2 で定義される対応するアルゴリズムと少なくとも同等に厳しくなければならない. メディア送信者 MAY, この計算の前に短い間隔 (RTCP 送信間隔に対して相対的) にわたり TMMBR を蓄積してもよい.

境界タプル集合を決定したら, メディア送信者 MAY, これらのタプルが記述する実行可能領域内のパケットレートと正味メディアビットレートの任意の組み合わせを用いて, 合計メディアストリームビットレートを下げることができる. 輻輳状況やその他の制約要因に対処する必要がある場合がある. 詳しくはセクション 5 (輻輳制御) を参照.

メディア送信者が最大合計メディアビットレート値を増やせると判断した場合, 実際に増やす前 SHALL, 受信者が自分のタプルが境界集合に属すると判断した場合に TMMBN で応答できるだけの十分な期間待つ. この遅延期間は次の式で見積もる.

2 * RTT + T_Dither_Max,

ここで RTT はメディア送信者が知る最長往復時間であり, T_Dither_Max は [RFC4585] のセクション 3.4 で定義される. ポイントツーポイントセッションであっても, メディア送信者 MUST 上記の規則に従う. すべてのソースが単一ノードに同居し協調しているかを参加者が正しく判定できる保証はないからである.

メディア送信者 SHALL, 前回の TMMBN 送信以降に受信した TMMBR メッセージに応じて, 可能な限り早い時点で TMMBN メッセージを送る. TMMBN メッセージは, メッセージ送信時点での計算された境界タプル集合とそれらのタプルの所有者を示す.

SSRC は RTP セッション参加者のデフォルト規則に従ってタイムアウトしうる. すなわち, メディア送信者が過去 5 回の通常報告間隔の間に所有者から RTP または RTCP パケットを受信していない. SSRC は明示的にセッションを離脱することもあり, 参加者が RTCP BYE パケットの送信または外部シグナリングチャネルでそれを示す. メディア送信者が境界集合内のタプルの所有者がセッションを離脱したと判断した場合, メディア送信者 SHALL, 以前に決定した境界タプル集合から離脱した所有者のタプルを除いた内容をもつ新しい TMMBN を送信する.

メディア送信者 MAY, 送信経路が現在の制限より厳しいと認識した場合, 自らへの TMMBR メッセージに相当するものを積極的に開始してよい. その結果, タプルの所有者としてメディアソース自身を示す TMMBN が送られ, 他参加者からの不要な TMMBR を避ける. しかし他の参加者と同様, 制限の変化に気づいたときはタプルを変更し, 対応する TMMBN を送る必要がある.

考察

TMMBR および TMMBN のトランスポートの非信頼性のため, 上記規則はこれらの規則に違反しているように見える TMMBR の送信につながりうる. さらにマルチキャストでは, 複数の「非所有」セッション参加者が, 正しくとも誤ってとも, 自分のタプルが境界集合に属すると判断しうる. これは次の理由で致命的ではない.

a) TMMBR メッセージが伝送で失われた場合, メディア送信者は他のメディア受信者への応答として新しい TMMBN を送るか, まったく新しい TMMBN を送らないかのいずれかである. 前者では受信者が増分アルゴリズムを適用し, 自分のタプルが境界集合の一部であるべきと判断すれば別の TMMBR を送る. 後者では無条件に TMMBR の再送を繰り返す. いずれにせよメディア送信者は最終的に必要な情報を得る.

b) 同様に, TMMBN メッセージが失われた場合, 対応する TMMBR を送ったメディア受信者は通知を受け取らず, 要求を再送し別の TMMBN の送信を促すことが期待される.

c) 異なるセッション参加者が競合する複数の TMMBR を送った場合, これらすべてのメッセージを考慮してアルゴリズムを適用でき, 結果の TMMBN が参加者にタプルと境界集合の比較の更新された見方を提供する.

d) 複数の参加者が同時に同じタプル成分値で TMMBR を送った場合, 境界集合に取り込まれるタプルがどれであっても問題ない. 敗れた参加者はアルゴリズム適用後, 自分のタプルが境界集合に入らないと判断し, したがって TMMBR の送信を止める.

偽造 TMMBR に伴うセキュリティリスクを考慮することが重要. セクション 6 のセキュリティ考慮事項を参照.

既に示したとおり, フィードバックメッセージは, 規定されたトポロジーのいずれでもマルチキャストおよびユニキャストセッションの両方で用いうる. しかし参加者数の非常に多いセッションでは, 本機構が要求する最小公倍数による適応が最適でない場合がある. 大規模セッションでは, セッションを異なる品質階層に分割するなど, 参加者の能力にビットレートを合わせる別の方法を検討する必要があるかもしれない.

4.2.1.3. タイミング規則

TMMBR メッセージの最初の送信 MAY, 適時性が望ましい場合に早期または即時フィードバックを用いてよい. 要求メッセージの繰り返し SHOULD, 送信タイミングに通常 RTCP モードを用いる.

4.2.1.4. トランスレータおよびミキサでの取り扱い

メディアトランスレータおよびミキサは, 受信者に特定のメディアストリームを提供するチェーンの一部であるため, TMMBR メッセージを受信し応答する必要がある. ミキサまたはトランスレータは TMMBR にローカルで対処し, そうしたことを示す TMMBN を生成してもよい. あるいはメディアトランスレータの場合は要求を転送し, ミキサの場合は独自の要求を生成して前方に渡す. 後者の場合, ミキサは要求を処理していることを示すため元の要求者へ TMMBN を送る必要がある.

4.2.2. Temporary Maximum Media Stream Bit Rate Notification (TMMBN)

Temporary Maximum Media Stream Bit Rate Notification は, RTCP パケット型の値 PT=RTPFB および FMT=4 で識別される.

TMMBN フィードバックメッセージの FCI フィールドは, ゼロ, 1 つ, または複数の TMMBN FCI エントリを含んでもよい.

4.2.2.1. メッセージ形式

Feedback Control Information (FCI) は, 次の構文をもつゼロ, 1 つ, または複数の TMMBN FCI エントリで構成される.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp |  MxTBR Mantissa                 |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3 - Syntax of an FCI Entry in the TMMBN Message

• SSRC (32 ビット): このタプルの「所有者」の SSRC 値.

• MxTBR Exp (6 ビット): 最大合計メディアビットレート値の仮数部に対する指数スケーリング. 値は符号なし整数 [0..63].

• MxTBR Mantissa (17 ビット): 最大合計メディアビットレート値の仮数部を符号なし整数として表す.

• Measured Overhead (9 ビット): 測定された平均パケットオーバーヘッド値 (バイト) を符号なし整数 [0..511] として表す.

したがって, TMMBN メッセージ内の FCI は境界タプルを示すエントリを含む. 各タプルについて, エントリは SSRC による所有者を与え, 続いて適用可能な最大合計メディアビットレートとオーバーヘッド値を与える.

TMMBN メッセージの長さ SHALL, N を TMMBN FCI エントリ数として 2+2*N に設定する.

4.2.2.2. 意味論

このフィードバックメッセージは, TMMBR メッセージの送信者に, 1 つ以上の TMMBR が受信されたこと, または所有者がセッションを離脱したことを通知するために用いられる. すべての参加者に, 現在の境界タプル集合とそれらのタプルの「所有者」を示す.

フィードバックメッセージ用の共通パケットヘッダ ([RFC4585] のセクション 6.1 で定義) では, 「SSRC of packet sender」フィールドが通知の発生源を示す. 「SSRC of media source」は用いられず SHALL 0 に設定する.

TMMBN メッセージ SHALL, このメディア送信者を識別する FCI エントリをもつ TMMBR メッセージの受信後に送信がスケジュールされる. TMMBN メッセージの送信スケジュールから実際の送信までの間に複数の TMMBR を受信しても, 単一の TMMBN のみ SHALL 送る. TMMBN メッセージは, メッセージ送信時点での境界タプルとその所有者を示す. 含まれる境界タプル SHALL, 前回 TMMBN 送信以降に TMMBR で受信したタプルおよび, あれば以前の境界集合に, セクション 3.5.4.2 の適用可能なアルゴリズムまたは同等のものを適用して得られた集合である.

アルゴリズム適用後に新たに報告された TMMBR タプルが境界集合に受け入れられない場合でも, TMMBR メッセージの受信 SHALL, なお TMMBN メッセージの送信をもたらす. そのような場合, 境界タプルと所有者は変更されない. ただし TMMBR が以前に計算された境界集合内のタプルの所有者からのものでない限りである. この手続により, 最後の TMMBN を見ていなかったセッション参加者も, このメディア送信者の状態の正しい見方を得られる.

セクション 4.2.1.2 で示したとおり, メディア送信者が境界タプルの「所有者」がセッションを離脱したと判断した場合, そのタプルは境界集合から除かれ, メディア送信者 SHALL, 残りの境界タプルを示す TMMBN メッセージを送る. 残る境界タプルがなければ, それを示すために FCI のない TMMBN SHALL 送る. 境界タプルが残らない場合, セッションシグナリングで交渉された最大メディアビットレートおよび最大パケットレート (あれば) が適用される.

注: メディア受信者がセッションに残っている場合, 最後の状況は一時的なものとなる. 空の TMMBN は残る各メディア受信者に, 自分の制限が境界集合に属すると判断させ, 結果として TMMBR を送らせる.

ユニキャストシナリオ (単一送信者が単一受信者と通信する場合) では, 上記の所有権決定アルゴリズムは, メディア受信者が最初の TMMBR メッセージを発行し次第, 唯一の境界タプルの「所有者」になることに帰着する.

4.2.2.3. タイミング規則

TMMBN の確認応答は, セッションに適用されるタイミング規則で許される限り早く送るべきである (SHOULD). これらのメッセージには即時または早期フィードバックモードを用いるべきである (SHOULD).

4.2.2.4. トランスレータおよびミキサによる取り扱い

セクション 4.2.1.4 で論じたとおり, ミキサまたはトランスレータは, 自身が扱う SSRC に対する TMMBR への応答として TMMBN メッセージを発行する必要がある場合がある.

4.3. ペイロード固有フィードバックメッセージ

RFC 4585 [RFC4585] のセクション 6.1 で規定されるとおり, Payload-Specific FB メッセージは RTCP パケット型の値 PSFB (206) で識別される. AVPF [RFC4585] は 3 つのペイロード固有フィードバックメッセージと 1 つのアプリケーション層フィードバックメッセージを定義する. 本メモは 4 つの追加のペイロード固有フィードバックメッセージを規定する. すべて FMT パラメータにより次のように識別される.

[RFC4585] で割り当て済み:

• 1: Picture Loss Indication (PLI)
• 2: Slice Lost Indication (SLI)
• 3: Reference Picture Selection Indication (RPSI)
• 15: アプリケーション層 FB メッセージ
• 31: 番号空間の将来拡張のため予約

本メモで割り当て:

• 4: Full Intra Request (FIR) Command
• 5: Temporal-Spatial Trade-off Request (TSTR)
• 6: Temporal-Spatial Trade-off Notification (TSTN)
• 7: Video Back Channel Message (VBCM)

未割り当て:

• 0: 未割り当て
• 8-14: 未割り当て
• 16-30: 未割り当て

以下のサブセクションは, ペイロード固有フィードバックメッセージの新しい FCI 形式を定義する.

4.3.1. Full Intra Request (FIR)

FIR メッセージは, RTCP パケット型の値 PT=PSFB および FMT=4 で識別される.

FCI フィールド MUST, 1 つ以上の FIR エントリを含む. 各エントリは SSRC で識別される異なるメディア送信者に適用される.

4.3.1.1. メッセージ形式

Full Intra Request の Feedback Control Information (FCI) は, 1 つ以上の FCI エントリで構成され, その内容は Figure 4 に示す. FIR フィードバックメッセージの長さ MUST, N を FCI エントリ数として 2+2*N に設定する.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr.       |    Reserved                                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4 - Syntax of an FCI Entry in the FIR Message

• SSRC (32 ビット): decoder refresh point の送信を求められるメディア送信者の SSRC 値.

• Seq nr. (8 ビット): コマンドシーケンス番号. シーケンス番号空間は, コマンド発生源の SSRC とコマンド対象の SSRC の各ペアごとに一意である. シーケンス番号 SHALL, 新しいコマンドごとに 1 を加え 256 法で増加させる. 繰り返し SHALL NOT シーケンス番号を増やす. 初期値は任意である.

• Reserved (24 ビット): すべてのビット SHALL 送信者により 0 に設定され, 受信時 SHALL 無視される.

このフィードバックメッセージの意味論は RTP ペイロード型に依存しない.

4.3.1.2. 意味論

フィードバックメッセージ用の共通パケットヘッダ ([RFC4585] のセクション 6.1 で定義) では, 「SSRC of packet sender」フィールドが要求の発生源を示し, 「SSRC of media source」は用いられず SHALL 0 に設定する. FIR コマンドが適用されるメディア送信者の SSRC は対応する FCI エントリにある. FIR メッセージ MAY, 対象メディア送信者ごとに 1 つの FCI エントリを用いて, 複数のメディア送信者への要求を含んでもよい.

FIR を受信すると, エンコーダ MUST できるだけ早く decoder refresh point (セクション 2.2 参照) を送る.

送信者 MUST セクション 5 で概説する輻輳制御を考慮し, それは decoder refresh point を迅速に送る能力を制限しうる (MAY).

FIR SHALL NOT 画像損失への反応として送られてはならない -- 代わりに PLI [RFC4585] の使用が RECOMMENDED である. FIR SHOULD, decoder refresh point を送らないとユーザにとってビデオが使用不能になる状況にのみ用いる.

FIR を送るのが適切な典型例は, マルチポイント会議で新しいユーザが参加し, 通常の decoder refresh point 間隔が確立されていない場合である. 別の例はストリームを切り替えるビデオスイッチング MCU である. 通常, MCU は新しい送信者に FIR を発行し, decoder refresh point の送出を強制する. decoder refresh point は通常, Freeze Picture Release (本仕様外で定義) を含み, 受信者の描画処理を再開する. 述べた両手法は MCU ベースのマルチポイント会議で一般的に用いられる.

RFC 2032 [RFC2032] などの他の RTP ペイロード仕様は, 特定のコーデック向けフィードバック機構をすでに定義している. 両方の方式をサポートするアプリケーション MUST, フィードバック送信時に本仕様で定義されるフィードバック機構を用いる. 後方互換のため, そのようなアプリケーション SHOULD, 当該 RTP ペイロード形式が要求する場合, それぞれの RTP ペイロード形式で定義されたフィードバック方式の受信と反応もできなければならない.

4.3.1.3. タイミング規則

タイミングは [RFC4585] のセクション 3 で概説する規則に従う. FIR コマンド MAY 早期または即時フィードバックで用いてよい. FIR フィードバックメッセージ MAY 繰り返してよい. 即時フィードバックモードを用いる場合, 繰り返し SHOULD 送信前に少なくとも 1 RTT 待つ. 早期または通常 RTCP モードでは, 繰り返しは次の通常 RTCP パケットで送る.

4.3.1.4. ミキサおよびトランスレータでの FIR メッセージの取り扱い

セッション参加者が FIR を発行した内容についてメディア符号化を行うメディアトランスレータまたはミキサは, それに対処する責任がある. FIR に対処するミキサ SHOULD NOT メッセージをそのまま転送せず, 代わりに自ら FIR を発行すべきである (SHOULD).

4.3.1.5. 備考

現状, FIR に有用な応用はビデオのみのようである. RTP パケット境界をまたいだメディア予測に大きく依存する RTP ペイロードとして広く展開されているのはビデオのみと思われる. しかし FIR は, 圧縮ビデオと本質的性質を共有する他のメディア型, すなわちクロスフレーム予測 (そのメディア型におけるフレームの意味は任意) にも合理的に想定しうる. 動的な MPEG-4 シーン記述の更新が一例になりうる. そのようなメディア型のペイロード形式は, ペイロード仕様内に類似機構を作るのではなく, 本仕様および AVPF [RFC4585] で定義された FIR および他のメッセージ型を参照することが望ましい. ペイロード仕様は, ペイロード固有の用語が本文のビデオ中心用語にどう対応するか説明する必要があるかもしれない.

ビデオコーデックと組み合わせると, FIR メッセージは通常フルイントラまたは IDR 画像の送信を引き起こす. どちらも予測 (インター) 画像の数倍の大きさである. そのサイズは生成時刻に依存しない. 多くの環境, 特に帯域制限リンクでは, イントラ画像の使用は, 典型的フレーム持続時間の有意な倍数となる許容遅延を意味する. 例: 送信フレームレートが 10 fps でイントラ画像がインター画像の 10 倍と仮定すると, 1 秒の遅延を受け入れねばならない. そのような環境では FIR メッセージ送信の特に短い遅延は不要である. したがって [RFC4585] に従う RTCP タイミング規則で次に許可されるタイムスロットまで待つことは, システム性能に過度に悪影響を与えないはずである.

decoder refresh point 送信完了の最大遅延を義務付けることは応用の観点では望ましいが, 輻輳制御の観点では問題がある. 上記の「できるだけ早く」は合理的な妥協に思える.

送信者がコーデックを制御できない環境 (例: 事前録画・事前符号化コンテンツのストリーミング) では, このコマンドへの反応は規定できない. 適切な反応の一つは, ビデオビットストリーム内で次の decoder refresh point まで早送りすることである. 他のシナリオではコマンドにまったく反応しない方がよい場合もある. 例: 大規模マルチキャストグループへのストリーミング. 他の反応もありうる. 戦略を決める際, 送信者は受信グループの規模, FIR メッセージ送信者の「重要度」 (この応用でどう定義されようとも), コンテンツ内の decoder refresh point の頻度などを考慮しうる. しかし主として事前符号化コンテンツを扱うセッションでは, そもそも FIR を用いないと期待される.

Picture Loss Indication と FIR の関係は次のとおりである. AVPF [RFC4585] のセクション 6.3.1 で論じたとおり, Picture Loss Indication はデコーダに画像の損失としたがってエンコーダとデコーダ間の参照画像のずれの可能性を知らせる. そのようなシナリオは通常進行中の接続での損失に関連する. ポイントツーポイントで高度な誤り耐性ツールがない場合, エンコーダの選択肢の一つは decoder refresh point を送ることである. しかし他の選択肢もある. 例: メディア送信者が PLI を無視する. 埋め込みストリーム冗長性が妥当な時間内に再生画像を修復しうるからである. 対照的に FIR は (リアルタイム) エンコーダに decoder refresh point を送る以外の選択肢を残さない. 上記のような考慮をエンコーダが取り入れる余地はない.

4.3.2. Temporal-Spatial Trade-off Request (TSTR)

TSTR フィードバックメッセージは, RTCP パケット型の値 PT=PSFB および FMT=5 で識別される.

FCI フィールド MUST, 1 つ以上の TSTR FCI エントリを含む.

4.3.2.1. メッセージ形式

Temporal-Spatial Trade-off Request の FCI エントリの内容は Figure 5 に示す. フィードバックメッセージの長さ MUST, 含まれる FCI エントリ数を N として 2+2*N に設定する.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Seq nr.      |  Reserved                           | Index   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5 - Syntax of an FCI Entry in the TSTR Message

• SSRC (32 ビット): Index で与えられたトレードオフ値の適用を求められるメディア送信者の SSRC.

• Seq nr. (8 ビット): 要求シーケンス番号. シーケンス番号空間は, 要求発生源の SSRC と要求対象の SSRC のペアごとに一意である. シーケンス番号 SHALL, 新しいコマンドごとに 1 を加え 256 法で増加させる. 繰り返し SHALL NOT シーケンス番号を増やす. 初期値は任意である.

• Reserved (19 ビット): すべてのビット SHALL 送信者により 0 に設定され, 受信時 SHALL 無視される.

• Index (5 ビット): 要求される相対的トレードオフを示す 0 から 31 までの整数値. インデックス値 0 は可能な限り高い空間品質を示し, 31 は可能な限り高い時間分解能を示す.

4.3.2.2. 意味論

デコーダは TSTR メッセージをエンコーダに送ることで時間空間トレードオフレベルを提案しうる. エンコーダが時間空間トレードオフを調整できる場合, SHOULD 受信した TSTR メッセージを将来の画像符号化に考慮する. 値 0 は高い空間品質を示唆し, 値 31 は高いフレームレートを示唆する. 0 から 31 への値の進行は, 単調に高いフレームレートへの希望を示す. インデックス値は空間品質またはフレームレートの正確な値に対応しない.

異なるメディア受信者からメディア送信者が複数の TSTR メッセージを受信した場合の反応は実装に委ねられる. 選択されたトレードオフ SHALL, TSTN メッセージによりメディア受信者に伝えられる.

フィードバックメッセージ用の共通パケットヘッダ ([RFC4585] のセクション 6.1 で定義) では, 「SSRC of packet sender」フィールドが要求の発生源を示し, 「SSRC of media source」は用いられず SHALL 0 に設定する. TSTR が適用されるメディア送信者の SSRC は対応する FCI エントリにある.

TSTR メッセージ MAY, 対象メディア送信者ごとに 1 つの FCI エントリを用いて, 複数のメディア送信者への要求を含んでもよい.

4.3.2.3. タイミング規則

タイミングは [RFC4585] のセクション 3 で概説する規則に従う. この要求メッセージは時間クリティカルではなく, SHOULD 通常の RTCP タイミングで送る. ユーザインタフェースが迅速なフィードバックを必要とすることが分かっている場合に限り, メッセージ MAY 早期または即時フィードバックタイミングで送ってよい.

4.3.2.4. ミキサおよびトランスレータでのメッセージの取り扱い

TSTR を発行したセッション参加者に送られる内容を符号化するミキサまたはメディアトランスレータ SHALL, 自らの符号化パラメータを変更することで要求を満たせるか判断するために要求を考慮する. 要求を満たせないメディアトランスレータ MAY 要求を変更せずメディア送信者へ転送する. 複数のセッション参加者向けに符号化するミキサは, メディア送信者向けに自ら TSTR を生成する前に, これら参加者の共同のニーズを考慮する必要がある. セクション 3.5.2 の考察も参照.

4.3.2.5. 備考

「空間品質」という語は, 必ずしも再構成ビデオが用いる画素数で測る解像度を指すとは限らない. 実際多くのシナリオではセッション存続期間中ビデオ解像度は一定のままである. しかしすべてのビデオ圧縮標準は, 所定の解像度で空間品質を調整する手段を持ち, 多くの場合 Quantizer Parameter (QP) の影響を受ける. 数値的に低い QP は良好な再構成画像品質をもたらし, 数値的に高い QP は粗い画像をもたらす. この要求に対するエンコーダの典型的反応は, レート制御パラメータを変更して平均して数値的に低い QP でより低いフレームレートを用いるか, またはその逆とすることである. Index 値からフレームレートおよび QP への正確な対応は, 用いる圧縮標準, 空間解像度, コンテンツ, ビットレートなどに依存するため, 意図的にここでは開いたままとする.

4.3.3. Temporal-Spatial Trade-off Notification (TSTN)

TSTN メッセージは, RTCP パケット型の値 PT=PSFB および FMT=6 で識別される.

FCI フィールド SHALL, 1 つ以上の TSTN FCI エントリを含む.

4.3.3.1. メッセージ形式

Temporal-Spatial Trade-off Notification の FCI エントリの内容は Figure 6 に示す. TSTN メッセージの長さ MUST, FCI エントリ数を N として 2+2*N に設定する.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Seq nr.      |  Reserved                           | Index   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6 - Syntax of the TSTN

• SSRC (32 ビット): この Notification の原因となった TSTR の発生源の SSRC.

• Seq nr. (8 ビット): 確認応答の対象となる TSTR のシーケンス番号値.

• Reserved (19 ビット): すべてのビット SHALL 送信者により 0 に設定され, 受信時 SHALL 無視される.

• Index (5 ビット): 以降メディア送信者が用いるトレードオフ値.

参考注: 返されるトレードオフ値 (Index) は要求値と異なりうる. 例: メディアエンコーダがトレードオフを調整できない場合, または事前録画コンテンツを用いる場合.

4.3.3.2. 意味論

このフィードバックメッセージは TSTR の受信を確認するために用いられる. セッション参加者を対象に受信した TSTR ごとに, TSTN フィードバックメッセージに 1 つの TSTN FCI エントリを送らなければならない (SHALL). 1 つの TSTN メッセージは, 複数の FCI エントリを用いて複数の要求を確認してもよい (MAY). 含まれるインデックス値は, TSTN メッセージのすべての FCI エントリで同一でなければならない (SHALL). 各要求者ごとに FCI を含めることで, 各要求エンティティがメディア送信者が要求を受信したと判断できる. Notification は, 受信した TSTR の繰り返しに対しても送らなければならない (SHALL). 要求受信者が単一の要求者から異なるシーケンス番号をもつ TSTR を複数受信した場合, (256 法で) 最も大きいシーケンス番号をもつ要求にのみ応答しなければならない (SHALL). フィールドの折り返しにより, 最大のシーケンス番号がより小さい整数値になりうることに注意. [RFC3550] の付録 A.1 に RTP パケットの最高受信シーケンス番号を追跡するアルゴリズムがあり, この用途に適応しうる.

TSTN は, 要求の結果として用いる Temporal-Spatial Trade-off インデックスを含めなければならない (SHALL). これは必ずしも要求されたインデックスと同じではない. メディア送信者は複数の要求セッション参加者からの要求を集約する必要があるかもしれない. 選択を制限する他の方針や規則を持つ場合もある.

フィードバックメッセージ用の共通パケットヘッダ ([RFC4585] のセクション 6.1 で定義) では, 「SSRC of packet sender」フィールドが Notification の発生源を示し, 「SSRC of media source」は用いられず SHALL 0 に設定する. Notification が適用される要求エンティティの SSRC は対応する FCI エントリにある.

4.3.3.3. タイミング規則

タイミングは [RFC4585] のセクション 3 で概説する規則に従う. この確認応答メッセージは極めて時間クリティカルではなく, 通常の RTCP タイミングで送るべきである (SHOULD).

4.3.3.4. ミキサおよびトランスレータでの TSTN の取り扱い

TSTR に対処するミキサまたはトランスレータ SHALL, 対応する TSTN も送る. 自ら TSTR を転送する必要がある場合, TSTR に応答が返るまで通知メッセージを遅延させる必要があるかもしれない (MAY).

4.3.3.5. 備考

なし.

4.3.4. H.271 Video Back Channel Message (VBCM)

VBCM は, RTCP パケット型の値 PT=PSFB および FMT=7 で識別される.

FCI フィールド MUST, 1 つ以上の VBCM FCI エントリを含む.

4.3.4.1. メッセージ形式

VBCM 表示内の FCI エントリの構文は Figure 7 に示す.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr.       |0| Payload Type| Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    VBCM Octet String....      |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7 - Syntax of an FCI Entry in the VBCM

• SSRC (32 ビット): エンコーダに VBCM に反応するよう指示することが求められるメディア送信者の SSRC 値.

• Seq nr. (8 ビット): コマンドシーケンス番号. シーケンス番号空間は, コマンド発生源の SSRC とコマンド対象の SSRC のペアごとに一意である. シーケンス番号 SHALL, 新しいコマンドごとに 1 を加え 256 法で増加させる. 繰り返し SHALL NOT シーケンス番号を増やす. 初期値は任意である.

• 0: 送信者により 0 に設定されなければならず, メッセージ受信者がこれに基づいて動作すべきではない.

• Payload Type (7 ビット): VBCM ビットストリームを解釈しなければならない RTP ペイロード型.

• Length (16 ビット): パディングオクテットを除く VBCM オクテット列の長さ (オクテット).

• VBCM Octet String (可変長): 特定のフィードバックサブメッセージを運ぶデコーダが生成したオクテット列である.

• Padding (可変長): 32 ビット境界を構成するよう 0 に設定されたビット.

4.3.4.2. 意味論

VBCM 表示の「ペイロード」は, 異なる種類のコーデック固有フィードバック情報を運ぶ. フィードバック情報の型は「ステータスレポート」 (ビットストリームが誤りなく受信されたことの表示, または画像またはブロックの一部または全部の損失など) または「更新要求」 (ビットストリームの完全なリフレッシュなど) に分類しうる.

注: VBCM サブメッセージと FIR などの CCM/AVPF フィードバックメッセージとの間に重複がありうる. さらなる議論はセクション 3.5.3 を参照.

VBCM に運ばれる異なる種類のフィードバックサブメッセージは [H.271] で定義される「payloadType」で示される. 便宜のためこれらのサブメッセージ型を以下に再掲する. ITU-T Rec. H.271 の用語における「payloadType」は H.271 メッセージのサブ型を指し, RTP ペイロード型と混同してはならない.

Table 2: H.271 message types ("payloadTypes")

ペイロード型	メッセージ内容
0	検出されたビットストリーム誤り不一致のない 1 枚以上の画像
1	全体または一部が失われた 1 枚以上の画像
2	全体または一部が失われた 1 枚の画像のブロックの集合
3	1 つのパラメータ集合に対する CRC
4	ある型のすべてのパラメータ集合に対する CRC
5	送信者が先行するビットストリームデータを一切受信していないかのようにビデオビットストリームを完全にリフレッシュすべきであることを示す「リセット」要求
> 5	ITU-T による将来使用のため予約

VBCM のビット列または「ペイロード」は可変長であり自己完結型で, 可変長バイナリ形式で符号化される. メディア送信者は VBCM を利用するにはこの最適化されたバイナリ形式を解析できなければならない.

payloadType で示されるサブメッセージの各型は, 用いるコーデックに応じて異なる意味論を持ちうる.

フィードバックメッセージ用の共通パケットヘッダ ([RFC4585] のセクション 6.1 で定義) では, 「SSRC of packet sender」フィールドが要求の発生源を示し, 「SSRC of media source」は用いられず SHALL 0 に設定する. VBCM が適用されるメディア送信者の SSRC は対応する FCI エントリにある. VBCM の送信者 MAY, 複数のメディア送信者に H.271 メッセージを送り, 同一 VBCM 内で同一メディア送信者に 1 つを超える H.271 メッセージを送ってもよい.

4.3.4.3. タイミング規則

タイミングは [RFC4585] のセクション 3 で概説する規則に従う. サブメッセージ型ごとに用いるべきメッセージタイミングに関する性質が異なりうる. 同一フィードバックパケットに複数の異なる型が含まれる場合, 最も厳しい要件をもつサブメッセージ型の要件に従うべきである.

4.3.4.4. ミキサまたはトランスレータでのメッセージの取り扱い

ミキサまたはトランスレータでの VBCM の取り扱いはサブメッセージ型に依存する.

4.3.4.5. 備考

H.271 メッセージおよび AVPF [RFC4585] および本メモで定義され類似機能をもつメッセージの使用についてはセクション 3.5.3 を参照.

注: このメッセージに RTP ペイロード型フィールドが必要かどうかについて議論があった. 同一セッションに VBCM 対応の RTP ペイロード型が複数ありうる場合, かつ所定の VBCM の意味論がペイロード型間で変わる場合に必要となる. 例えば H.271 型 0 のメッセージにおける画像識別機構は H.263 と H.264 で根本的に異なる (両者は同じ構文を用いるが). したがってここではペイロードフィールドが正当化される. TSTR および FIR にはその必要はないというコメントもあった. TSTR と FIR の意味論は, 現存・想定されるすべてのビデオペイロードに適用できるほど十分に緩いか一般的だからである.