要約

  • RFC 3158は、RTPメディアの変換とRTCP証拠の変換を一つの整合性問題として扱った。符号化、パケット化、シーケンス、クロック周波数を変えれば、バイト数、パケット数、タイムスタンプ、損失報告も変える必要がある。
  • 受信報告は出力側のシーケンス空間を観測して逆方向に戻る。入力側へ意味のある逆変換ができない場合、明示的な欠落やトランスレータ自身の合成報告は、別の流れの数字をそのまま転送するより正確だった。
  • 試験方法も自らの限界を示した。選んだ条件での相互運用と典型的な誤りは確認できても、合格だけでRTP全体の適合性、安全性、実運用品質、利用者の体験までは証明できない。

再生成功と報告の正しさは別だった

送信元が二つのパケットを出し、トランスレータが狭い回線向けに再符号化して一つへまとめる。受信側はその一つを復号し、映像を表示する。メディアだけを見れば成功である。

しかし受信側のReceiver Reportは、出力側の履歴について書かれている。観測したのは一パケットであって、元の二パケットではない。これを無加工で上流へ返すと、送信元は構文上正しいまま、自分が送っていない履歴を受け取る。まとめた一パケットの損失は、元の一パケット損失と同義ではない。

データが壊れている必要はない。SSRCは同じでもよく、RTCPは正常に解析でき、暗号学的な完全性も成立し、画面も見える。それでも数値が対象としているパケット集合が違えば、報告は読み手の場所で誤りになる。

RFC 3158が確認したのは、変換後の再生だけではない。payload type、タイムスタンプ、シーケンス番号、padding、markerを変えたとき、制御報告にも対応する変更があるかを確認した。RTCPは付録ではなく、データ履歴の短い表現だった。

試験装置は二つの実装の外側に立った

提案された構成では、二つのRTP実装の間にアプリケーション層の転送装置を置く。両端は装置へ送り、装置が相手へ渡す。通常は損失も余分な遅延も加えず、必要な試験ではパケットを遅らせ、捨て、内容を記録した。

これにより、送信側の記録、受信側の記録、中央で実際に加えた変化を比較できた。約一パーセントをランダムに落とせば、既知の損失とRRの損失率・累積値を照合できる。損失を止めて揺らぎのある遅延を加えれば、報告される到着間隔ジッタの増加を期待できる。

装置は全知ではない。特定の位置と条件しか見ない。RFC 3158は冒頭で、試験が網羅的ではなく、合格しても完全なRTP適合性を必ずしも意味しないと明記した。

したがって結果が証明するのは、識別した実装が実行済みの条件で示した挙動である。未試験の形式、異常入力、別のトポロジ、負荷、セキュリティ設定、人間の品質判断までは含まれない。

RTPとRTCPは同じ履歴を別方向から見た

Sender ReportはSSRC、NTP時刻、RTPタイムスタンプ、送信パケット数、オクテット数を結び付ける。Receiver Reportは対象SSRC、損失、拡張最高シーケンス番号、ジッタ、最後のSRとその後の遅延を伝える。

どの値にも対象範囲がある。クロック周波数のないタイムスタンプ、シーケンス空間のない最高番号、観測区間のない損失率は普遍的な事実ではない。RFC 3158は、報告の存在ではなく、メディアとの整合を試した。

運用では、小さく構造化された報告が完全なキャプチャより扱いやすい。だが報告はイベントの投影であり、イベントそのものではない。途中でデータを変えながら投影だけを残せば、見やすいダッシュボードが最も不正確になる。

SSRCの連続性は測定単位の連続性ではない

トランスレータは複数の送信元を分離したままSSRCを保つ。ミキサは流れを混合し、新しいタイミングと自分のSSRCを作り、必要なら寄与元をCSRCに載せる。

SSRCを保つトランスレータでも、符号化、バイト量、payload type、フレームレート、タイムスタンプ周波数、パケットの結合・分割、シーケンス、padding、暗号化、markerを変えられる。

同じSSRCは送信元を追跡する手掛かりになるが、同じ統計空間を保証しない。送信元の継続と測定尺度の継続は別の主張である。識別子が安定しているほど、その周囲の単位変更は見落とされやすい。

正方向の変換ごとに制御側の責任が生じた

RFC 3158は対応関係を具体化した。符号化を変えればSRのオクテット数を変える。複数パケットを一つにすればパケット数を変える。サンプリング周波数を変えればSRのRTPタイムスタンプを変える。

圧縮後の狭いリンクに入力側のバイト数を残せば、実際には流れていない帯域を計上する。三つを一つにした後も三と数えれば、パケットレートと損失計算の土台が崩れる。

逆方向はさらに難しい。受信側は出力シーケンスだけを観測する。結合や分割で番号が変わったなら、損失と拡張最高番号を入力履歴へ戻すため、入出力の対応表が必要になる。

一つの出力損失が複数入力を含む場合もあれば、分割後の一片だけが失われる場合もある。「一パケット損失」という言葉の分母は、境界の両側で同じではない。

出力を作れても、逆向きの説明を作れるとは限らない

メディアは受信側へ進み、受信報告は送信側へ戻る。トランスレータは出力側の観測を入力側の言葉へ戻さなければならない。しかし多対一の変換は区別を消す。

RFC 3550はこの原則を規範化した。payloadを変換するトランスレータはSR/RRも対応して変更し、単純転送してはならない。その一方で、逆変換が複雑で、意味のある方法が存在しない場合を認めた。

可用な出力を生成する権限と、下流の損失を上流単位へ完全に説明する能力は同じではない。分からない部分を数字で埋めるのではなく、説明可能な境界を記録する必要があった。

正直な空白は誤った精密さより強い

RFC 3158は、合理的に翻訳できない場合、受信報告ブロックを取り除いて空のSR/RRを送る選択を示した。RFC 3550は、報告を渡さない方法と、トランスレータ自身の受信に基づく合成報告を区別した。

報告なしは損失ゼロではない。合成報告は最終受信者の観測でもない。前者は投影不能を示し、後者は特定区間を別の観測者が見た結果である。

すべての欄を埋めることを優先すると、意味を犠牲にして見かけの完全性を得る。空白を保てば、残る証拠の範囲を守れる。実装ごとの裁量は、出所を隠す許可ではなかった。

複製、変換、混合は同じ中継ではない

データを変えずにマルチキャストとユニキャスト間を複製するだけなら、RTCPも無変更で転送できる。責任は中間装置の存在ではなく、実際の変換から生じる。

payloadトランスレータは送信元を維持しつつ報告を合わせる。自分の受信を報告するなら、それはトランスレータの観測点である。ミキサは新しい同期源を作るため、片側の原送信元報告を別側へそのまま流せない。

報告の集約さえ意味を変えうる。RFC 3550は、LSR/DLSRによる伝搬遅延の精度を損なうため、異なる送信元のSR/RRを一般にまとめないよう勧めた。値を変えなくても、時機や包装を変えることで測定は変わる。

暗号学的完全性は意味の変換を検査しない

SRTP/SRTCPは後に機密性、完全性、リプレイ防止を提供した。これらは保護関係の外からの変更を検出するが、トランスレータの逆写像が正しいかまでは判定しない。

真正な報告でもローカル合成かもしれない。完全な報告でも最終受信者ではなく中間点を記述するかもしれない。認証は「誰がどのバイトを述べたか」を守るが、述べられる観測範囲を広げない。

セキュリティ検証と意味検証を一つにすると、署名された局所値が端末間の真実に昇格してしまう。両方の受領記録が必要だった。

試験文書も計算を検証される必要がある

SSRCランダム性の節は、自らを粗い検証と呼んだ。2,500サンプルを25ビンに入れると書きながら、各ビンの期待値を40とした。単純な除算では100である。本研究で保存したRFC Editorのerrata検索にはRFC 3158の該当記録がない。

これは公式erratumではなく、RTP全体への反証でもない。公開済みの試験計画でも、実行者がパラメータを保存し、期待値を独立に計算する必要があるという例である。

RFC 2762は均一なSSRC分布がグループサンプリングに関係する理由を説明する。しかし有限の粗い試験に合格しても、完全な32ビット乱数を証明したことにはならない。

指標が増えても観測座標は残った

RFC 3611はRTCP Extended Reportsを追加し、RFC 7667は多様なトポロジを整理した。RFC 3551はpayload、クロック、markerの意味がprofileに依存することを示し、RFC 3711は通信を保護した。

語彙が増えても観測者は遍在しない。各指標には送信者、期間、パケット集合、シーケンス空間、場所がある。変換後の値は、新しい形式に格納しても変換前の値にはならない。

残すべき履歴は、入力キャプチャ、変換規則と版、入出力対応、出力キャプチャ、SR書き換え、RR逆変換または省略理由、合成報告の観測点、暗号検証、復号・再生、アプリケーション結果を接続する。

RFC 3158の歴史的教訓は、すべての数字を無理に維持することではない。意味を失った数字に、変わっていない外観を与えないことである。パケットが変われば報告も変える。追えないなら、知識が終わる地点を正確に示す。

出典