要約

  • RFC 5109 では各 ULP レベルが固有のパケットマスクと保護長を持ち、一つのレベルが解けても他のレベルの復元は保証されない。
  • メディア再生は、FEC セッションの受諾、修復利用、完全パケット、デコーダ受理を証明しない。

再生できた理由は一つではない

FEC を別 RTP セッションで送る場合、元のメディアパケットは変更されない。FEC を理解しない端末も保護データを無視してメディアを処理できる。offer/answer では、回答側が FEC セッションを拒否し、メディアセッションだけを受け入れることもできる。

したがって「映像が見えた」は修復の証拠ではない。損失がなかった、損失箇所が不要だった、デコーダが隠蔽した、あるいは FEC が実際に復元した、という異なる状態が同じ外観を持つ。監査には提案、回答、関連付け世代、メディア/FEC 双方の受信、利用された方程式が必要になる。

ULP は均一な傘ではない

Uneven Level Protection はパケット内を重要度の異なるレベルに分ける。先頭部は小さなグループで強く、後方は大きなグループで弱く保護できる。一つの FEC パケットが複数レベルを運べても、各レベルの演算は独立している。

レベルヘッダには 16 ビットの Protection Length と、16 または 48 ビットのマスクがある。基準番号を N とすると、ビット i は N+i のメディアパケットをそのレベルの XOR 方程式へ含める。マスクは対象パケットを、長さは対象バイトを示す。しかし、他の項が受信済みかは示さない。

レベル p で保護されるパケットは p-1 でも保護される必要がある。ただしグループは同一でなくてよく、隣接レベルが別の FEC パケットに入ることもある。「FEC 対象」という一つのフラグでは構造を再現できない。

先頭部だけが解けるとき

欠落パケットがレベル 0 では唯一の未知数なら、受信側は RTP 回復フィールドと保護された先頭部を XOR で戻せる。同じパケットを含む上位レベルで別の欠落もあれば、未知数は二つになり、末尾は解けない。

RFC 5109 はレベル 0 から得た本来の全長と、実際に復元できたペイロード長を比較して部分復元を判定する。ヘッダが整っていても、全長に届かなければ完全パケットではない。

回復処理も二段階である。実装はまず、どのメディア/FEC パケットを組み合わせるか探索する。次に規定手順でバイトを再構成する。解ける組合せがあっても計算予算や再生期限内に見つからない場合がある。レベル 0 の成功は上位レベルの成功を意味しない。

各レベルでは保護長 Ln を読み、正しいオフセットから項を取り、短い項をゼロ埋めし、XOR 結果を所定位置へ置く。複数レベルを連結した後、全長比較で完成を判断する。この過程を一つの回復件数へ圧縮してはならない。

復元値は検証前の入力

パリティは認証ではない。FEC データの改変は結果を変え、異常に長いパケットを作り、計算量を増幅し得る。RFC 5109 は計算前の妥当性確認と、利用前の復元データ検証を勧める。

別セッションなら、関連付け、鍵世代、長さ境界、CPU 制限も必要である。代数的に解けることと、デコーダへ渡して安全であることは別だ。ULP は末尾が連続して欠ける形を作りやすいが、その先頭部を利用できるかは媒体形式と依存関係次第である。

冗長性は混雑から自由ではない

FEC を増やすほど保護は強くなりやすいが、総帯域も増える。損失が混雑由来なら自動増量は原因を悪化させる。RFC 5109 は損失増加時にメディア＋FEC の総量を大幅に増やしてはならないとする。

レベル数やグループを変えた評価では、総レート、メディアレート、キュー遅延、損失、復元バイト、デコード、再生遅延を同じ窓で見る必要がある。

仕様が確定する範囲

RFC 5109 は 2007 年 12 月の Standards Track で、RFC 2733 と RFC 3009 を置き換え、不均等保護を導入した。FEC 形式は旧形式と後方互換ではないが、未変更メディアは消費できる。これは契約上の互換性であり、導入実績ではない。

マスクは最大 48 オフセット、演算は XOR である。特定事業者、製品、コーデック、損失率、回復率、視聴品質は資料から導けない。証明できるのは、どのレベルがどのバイトを保護し、復元が全長へ届いたかである。

出典