RTCP 送信者レポート、ジッター、およびパケットロス: ビデオを見ずにストリームの健全性を読み取る

RTCP 送信者レポートと RTP タイミング証拠が、ビデオ再生に依存せずに RTSP カメラ ストリームの健全性を診断するのにどのように役立つか。

RTCP, RTP, RTSP, ジッター, パケットロス

エンジニアが「RTSP ジッター」、「RTP パケット損失」、または「RTCP 送信者レポート」を検索するときは、通常、ストリームが異常なのか、それともプレーヤーが問題を抱えているだけなのかという実際的な質問に答えようとしています。ビデオ再生は後期症状です。 RTP と RTCP の証拠は早期に現れ、サポート訴訟での弁護が容易になります。

RTCP は RTP の制御コンパニオンです。送信者レポート、受信者レポート、パケット数、タイミング情報、品質フィードバックを伝送できます。すべてのカメラが豊富な RTCP 動作を公開しているわけではなく、すべての展開がそれを正しく転送するわけではありませんが、RTCP が存在すると、生の再生では提供されない重要なコンテキストが得られます。

カメラ診断で RTCP が重要な理由

RTP はメディア パケットを伝送します。 RTCP は、メディア セッションの状態を説明するのに役立ちます。 RTSP カメラ ストリームの場合、RTCP の証拠は次の答えに役立ちます。

  • 「PLAY」後、送信者は生きていますか?
  • 送信者は何個の RTP パケットを報告しましたか?
  • RTP タイムスタンプは実時間のタイミングと一致していますか?
  • パケット配信は安定していますか?それともバースト配信ですか?
  • 目に見えるジッターはありますか?
  • ビデオのデコードが失敗しても RTP は続行されましたか?
  • メディアパスにはRTCPが含まれていましたか?

RTSP 制御が成功し、RTP が到着してもビデオがフリーズした場合、RTCP はネットワークのタイミングをコーデックの準備状態から切り離すのに役立ちます。

送信者レポートはタイミングの証拠となる

RTCP 送信者レポートは、RTP タイムスタンプを NTP 形式の絶対時刻値に関連付けることができます。この関係は、受信機がストリームを同期し、クロックの動作を判断するのに役立ちます。診断では、正確な計算は、レポートの存在と一貫性よりも重要である場合があります。

有益な観察:

  • メディアの開始後に送信者レポートが表示される
  • パケット数とオクテット数が増加する
  • RTP タイムスタンプ マッピングの一貫性
  • 報告間隔は妥当である
  • RTP が停止するとレポートも停止します
  • デコーダに障害が発生している間でもレポートは続行されます

RTP と同時に RTCP も停止すると、送信側またはメディアの経路が遮断される可能性があります。 RTCP が継続してもビデオのデコードが失敗する場合は、ペイロードとコーデックの証拠を検査します。

ジッターはパケット損失と同じではありません

ジッターとは、パケットがさまざまなタイミングで到着することを意味します。パケットロスとは、パケットが欠落していることを意味します。どちらも目に見える途切れを引き起こす可能性がありますが、解決方法は異なります。

RTP シーケンス番号は欠落パケットを示します。 RTP タイムスタンプと到着時間はタイミングの変動を示します。 RTCP レポートには、セッション レベルのフィードバックが追加される場合があります。適切なレポートでは、「ネットワークが不良」とだけ書かれるべきではありません。問題が損失、ジッター、バースト配信、ブロックされた RTCP、またはコーデックのデコード境界であるかどうかを示す必要があります。

カメラの場合、ジッターは次の原因で発生する可能性があります。

  • Wi-Fi アップリンクのバリエーション
  • 過負荷のカメラエンコーダ
  • NVR 転送遅延
  • 混雑したスイッチパス
  • VPN または WAN パス
  • クライアント側のバッファリング動作

パケット損失は次の原因で発生する可能性があります。

  • UDP のドロップ
  • ファイアウォール/NAT の動作
  • 過負荷のネットワーク
  • カメラ送信バッファープレッシャー
  • キャプチャポイントの制限

修正内容は異なります。

RTCP が見つからないことも証拠になります

一部の展開では、RTP がフローしている場合でも RTCP がブロックされます。一部のカメラは有用な RTCP を送信しません。クライアントの中には、明確に要求したり受け取ったりしない人もいます。 RTCP が見つからない場合でも、ストリームが壊れていることを自動的に意味するわけではありませんが、記録する必要があります。

RTP over UDP がネゴシエートされている場合は、両方のメディアを検査し、コンパニオン トラフィックを制御します。 RTSP over TCP インターリーブが使用されている場合は、インターリーブされたチャネル メタデータを検査します。 「RTP は表示されますが、RTCP は存在しません」というレポートは、空白のフィールドよりも便利です。

RTSP インスペクターが適している場所

RTSP Inspector は、受動的に表示するのではなく、プロトコルの証拠を目的として構築されています。 RTCP は、RTSP メソッド、SDP、RTP シーケンスの連続性、ペイロード タイプ、コーデック メタデータ、レポート エクスポートと同じ話に属します。

RTCP を多用する検索の場合、RTSP Inspector は次の答えに役立ちます。

  • RTP は「PLAY」後に到着しましたか?
  • RTCP送信者レポートは表示されましたか?
  • パケット数は増えましたか?
  • ジッターまたはシーケンス ギャップは目に見える障害と一致していますか?
  • メディア配信にもかかわらずコーデックの準備が失敗しましたか?
  • トランスポート モードによってヘルス プロファイルが変更されましたか?

これにより、カメラ ベンダー、ネットワーク エンジニア、または VMS 開発者は具体的な開始点を得ることができます。 「ストリームが途切れる」という症状です。 「RTSP 制御が生きている間に、PLAY 後に RTP シーケンスのギャップとジッターが増加した」ことがその証拠です。