要約

  • RFC 3545は変化したコンテキスト値をN+1個の連続パケットで反復し、損失バーストがリンクの想定範囲内ならデコンプレッサが再同期できる機会を増やした。
  • 任意のHDRCKSUMはIPv4 UDPチェックサムがゼロのとき再構成ヘッダーの確認に使えるが、IPv4 Identificationは対象外である。N個を超える連続損失では、コンテキストを無効化して状態を要求する方が安全だ。

チェックには見落とされた項目があった。RFC 3545は、IPv4 UDPチェックサムがゼロの場合に16ビットのヘッダーチェックサムへ置き換えることを認め、デコンプレッサが再構成を確かめられるようにした。しかしIPv4 Identificationはその対象フィールドに含まれていない。損失の少ない通常経路では、この欠落は大きな復旧設計の中で目立たないかもしれない。連続損失が多すぎると、「復旧した」と言える範囲そのものを変える。

RFC 2508のCRTPはIP、UDP、RTPヘッダーを圧縮し、両端で共有するコンテキストを使う。まず完全ヘッダーで状態を確立し、その後のパケットは変更や差分値を運べる。更新を含むパケットが失われると、コンプレッサは先へ進み、デコンプレッサは取り残される。そのずれは次の圧縮パケットが届くまで見えない場合がある。遅延の大きいリンクで状態を修復するには少なくとも往復時間がかかり、待つ間にさらにパケットが捨てられ得る。

RFC 3545は反復によってこの問題に対処するが、明確な境界を置く。Nはリンクの損失特性を表し、N個を超える隣接パケットが失われる確率は小さいという想定である。更新をN+1個の連続パケットに含めれば、損失がN個以下のバーストでは少なくとも一つが届く機会がある。デコンプレッサは「twice」アルゴリズムで限られた間隔を再構成し、UDPチェックサム、適用可能な場合はHDRCKSUMで結果を確認できる。これは損失への耐性を高める仕組みであり、どの損失バーストも想定に収まるという保証ではない。

リンクシーケンス番号は4ビットで、16パケットごとに循環する。そのため値の差だけでは、大量の損失と、後続パケットが先に届く並べ替えを常に区別できない。N+1個未満の損失とみなせる解釈があれば、デコンプレッサはその回数分の再構成を試し、検証できる。IPv4で妥当な解釈がNを超える損失となる場合、規則はより明瞭だ。「twice」で推測し続けず、コンテキストを無効化してCONTEXT_STATEを送り、コンプレッサに共有状態の復元を求める。

ここでチェックサムの対象範囲が重要になる。元のIPv4 UDPチェックサムがゼロの場合に限り、HDRCKSUMを挿入して再構成を検査し、デコンプレッサが取り除く。IPv6ではUDPチェックサムをゼロにできないため、この機能は使わない。それでもヘッダーチェックサムはIPv4 Identificationを検証しない。Nを超える損失の後にチェックが通っても、その欠けた証拠は補えない。RFC 3545が求めるのは不確かなIPv4コンテキストの破棄である。IPv4 IDがないIPv6では復旧の規則が異なる。

更新バーストには世代番号による保護もある。N+1個のFULL_HEADERを送っている途中で固定コンテキストフィールドが変化した場合、コンプレッサは新しいバーストを始め、世代番号を変更する。そうしないとデコンプレッサが重なったバーストをより大きな損失許容幅と誤認し、同期ずれを見逃すおそれがある。CONTEXT_STATE応答も反復することが推奨される。これらはプロトコル機構であり、特定装置が機能を有効にした証拠でも、RTPアプリケーションがペイロードを再生した証拠でもない。

歴史上の要点は小さいが、運用では重要だ。チェックサムが証明するのは対象フィールドだけであり、限られた再構成は配送ではなく、コンテキスト修復はメディア受領確認でもない。ローカルチェックが通っても、IPv4 IDは未検証のままになり得る。損失が想定範囲を超えたときに無効化するのは復旧を諦めることではない。曖昧なシーケンスを確実性と取り違えないための判断である。

出典