要約

  • XR の値を組み合わせる前に、報告元と測定対象、区間型・累積型・標本型、シーケンス境界、測定点が一致するかを確認する必要がある。
  • ブロックがないことはゼロを意味しない。受信後の破棄はネットワーク損失ではなく、推定品質値も人間の体験そのものではない。

データベース到着時刻という錯覚

午前10時00分00秒に二つのレコードが保存された。一つは直前5秒の損失、もう一つはセッション開始からの累積破棄数だった。画面は同じ縦線上に並べる。利用者は同時点のスナップショットだと読む。しかし一致しているのは保存時刻だけで、観測区間は一致していない。

RFC 3611 は2003年11月、RTCP packet type 207 と拡張報告ブロックの枠組みを定めた。最初の七ブロックは損失 RLE、重複 RLE、受信時刻、Receiver Reference Time、DLRR、統計要約、VoIP Metrics である。型と長さによって未知のブロックを読み飛ばせる設計は拡張性を生んだ。同時に、読み飛ばした値をゼロとして扱ってはならないことも意味する。

XR ヘッダーの SSRC は報告を作った主体を示す。各ブロックにある SSRC は測定対象を示す場合がある。誰が、誰について述べたかは別の情報だ。報告グループや中継装置が入ると、この区別を失った数値は帰属不能になる。

IANA の登録表には後発ブロックが並ぶが、登録は実装、ネゴシエーション、送信を証明しない。RFC 3611 自体にも三件の verified errata があり、RTT パラメーター名、SDP 構文、burst density の例が修正されている。解析結果には仕様解釈の版も必要である。

区間を失った指標は再計算できない

Loss RLE と Packet Receipt Times は開始・終了シーケンスを持つ。サイズ制限のため thinning を適用することもできる。thinning された報告は規則に忠実でも、全パケット記録ではない。欠けた位置をグラフ側で補完すれば、観測されなかった連続性を作る。

RFC 6776 は Measurement Information Block を定義し、セッション最初の番号、現在区間の拡張シーケンス境界、直近区間と累積期間の長さを伝えられるようにした。RFC 6792 は interval、cumulative、sampled を区別する。値の型は名称ではなく、時間と集計法で決まる。

RFC 8861 はさらに、対応する SR/RR と XR を異なる compound packet で受けると、測定区間が同期しないため価値が下がると指摘する。特定メディアの XR は、共通報告元に移すのではなく関連 SSRC が送る必要がある。複数ソースを一枚にまとめる場合、同期と帰属の両方を保たなければならない。

Receiver Reference Time と DLRR は協調して往復時間を求める。DLRR は以前受信した参照時刻報告からの経過時間であり、片道遅延ではない。ペアとなる交換を外して単独の「遅延」に変換することはできない。

到着、採用、再生は別の判定

ネットワーク loss は期待したパケットが測定点に来なかったことを示す。discard は到着しても、遅すぎる、早すぎる、またはジッターバッファの規則により使えなかったことを示し得る。RFC 3611 の VoIP Metrics は二つを分離し、後続 RFC は discard count、burst/gap、de-jitter buffer、Discard RLE を個別に定めた。

したがって、loss が安定して discard が増えたとき、最初の調査対象は経路だけではない。遅延変動、バッファ適応、端末負荷、再生期限を見る。逆に loss が増えれば伝送側の証拠を深める。どちらも低い場合でも、コーデック、フレーム再構成、loss concealment、アプリ停止が残る。ユーザー体験は別の受領書である。

burst/gap の境界には Gmin が使われる。RFC 3611 は16を推奨し、セッション中は非ゼロで一定とする。同じパケット列でも閾値が違えば分類は変わる。Gmin を失った burst density は方法を失った結果だ。

R factor や MOS は推定であり、利用者の回答ではない。一部はマルチキャスト会議では定義されず unavailable とすべきである。複数フィールドで127は unavailable を表す。127を悪い点、良い点、ゼロに変換すると、未測定が測定値に化ける。

詳細さは帯域と秘密を消費する

XR も RTCP 帯域計算に含まれる。ブロックが大きくなると平均報告間隔が長くなり得る。実装はサイズ制限、thinning、報告者選択、頻度低下で調整する。全項目を細かく求めることで、短い障害を観測しにくくなる場合がある。

RFC 3611 は詳細報告による confidentiality の増大を明記する。パケット単位情報はマルチキャスト構造の推定に使え、VoIP 指標は個人情報を含み得る。暗号化やフィルタリングは保護になるが、監視情報を失う。プライバシー変更後の空欄は、品質改善ではなく可視性変更として記録する。

目的別の権限と保存期間が必要だ。逐次データを限定された障害対応に使い、広い画面には集約を出すことはできる。ただし withheld、filtered、unsupported をゼロにしてはならない。

同期できる証拠だけを同期する

最小記録には、報告元 SSRC、対象 SSRC、セッション、ブロック型、errata を含む版、測定点、区間種別、シーケンス境界、期間、時計、payload、thinning、単位、パラメーター、sentinel 解釈を残す。未要求、未受信、未知、フィルタ済みを区別する。その後に伝送、端末処理、再生、利用者結果を関連付ける。

これは巨大な中央監視を求める設計ではない。相互運用に必要な最小条件を共有し、詳細は正当なローカル権限に残す。動作中の実装が観測を作り、標準が可搬性を与える。ダッシュボードは、その条件を削除する権限までは得ない。

RFC 3611 の価値は、多数の指標を一つの真実にしたことではない。異なる証言を明示的な型で運べるようにしたことだ。同じ時刻に見せる前に、同じ区間を測っているかを証明しなければならない。

情報源