顧客の観測可能性

OpenTok SDK には、ビデオセッションにおけるリアルタイムのネットワークおよびメディア統計情報（送信側統計情報を含む）にアクセスするためのメソッドが用意されています。

Client observabilityは、パケットロス、受信データ、推定帯域幅などの詳細なストリーム品質メトリクスを提供し、公開または購読されたストリームで使用できます。

統計は主に2つのメカニズムを通じてアクセスできる：

  • 高レベル統計API-ほとんどの場合、好ましいメカニズム。このAPIは、オーディオ、ビデオ、ネットワークのパフォーマンス・メトリクスを提供し、ピア接続の遷移やその他の内部調整を考慮します。SDKはこれらの詳細を集約し、データをパブリッシャーやサブスクライバーの抽象化にきれいにマッピングします。実際のセッション・パフォーマンスをより正確かつ安定的に表現できるため、可能な限りこのAPIを使用してください。
  • 低レベルの WebRTC 統計レポートで、基礎となるピア接続の生の WebRTC RTCStatsReport を公開します。このデータはピア接続の遷移や内部最適化のために調整されておらず、直接の WebRTC 統計情報のみを反映します。高度なデバッグや、生の WebRTC データが明示的に必要な場合に便利です。

このガイドには、以下のセクションが含まれています：

オーディオ、ビデオ、およびメディアリンクの統計情報API

Video 統計 API は、パブリッシャーと購読者の両方に対して、メディア パフォーマンスに関する定期的できめ細かな洞察を提供します。これらの統計情報により、アプリケーションはリアルタイムの音声と動画の品質を監視し、ネットワークの動作を理解し、デバイス側の問題を検出し、帯域幅やパフォーマンスの変化に積極的に対応することができます。API は、すべての Video Client SDK で利用可能で、パブリッシャー側とサブスクライバー側のメトリクスに対して個別のコールバックまたはイベントを提供します。

提供されるデータやイベントの主な種類は以下の通り：

  • オーディオとビデオの統計 - フレームレート、解像度、ビットレート、パケット数など、コールバックやイベントを通じて定期的に配信される。

  • メディアリンク統計 - は、ネットワーク状態のスコアリングや帯域幅の推定など、定期的なオーディオおよびビデオ統計を補完する統一されたトランスポートレベルのメトリクスを提供します。加入者にとっては、これらのメトリクスにより、リモート・パブリッシャーのトランスポート・パフォーマンスとネットワーク劣化の原因を可視化できるため、アプリケーションは接続の問題を正確に診断し、意味のある実用的なフィードバックをユーザーに提供できます。

  • ビデオ画質変更イベント - ビデオストリームの品質が変化するたびにトリガーされ、劣化または改善の理由とともに更新されたメトリクスを提供します。

  • ネットワーク条件変更イベント – パブリッシャーまたはサブスクライバーのネットワーク状態に著しい変化が検出された際に発生します。これらのイベントは、ネットワーク全体の健全性の変化を報告するもので、オーディオおよびビデオの統計情報の完全なスナップショットに加え、ネットワーク状態スコアや状態の原因といったトランスポートレベルの指標が含まれます。サブスクライバーの場合、ネットワーク性能低下の原因も含まれます。詳細は ネットワーク状況 詳細はこちら。

出版社統計

パブリッシャーコールバックは、以下のようなメディアの品質を可視化する。 送信 を各加入者（ルーティング・セッションの場合は Vonage Video Media Router）に送信します。これらのメトリクスは、アップストリーム・ネットワークの状態を把握し、エンコーディングのパフォーマンスを観察し、パケットロスやビットレート低下などの問題を診断するのに役立ちます。

注： ルーティングされたセッションでは、Vonage Video Media Routerがリソースを最適化するために帯域幅を調整することがあるため、パブリッシャー側のメトリクスが実際のメディア値と一致しないことがあります。このような場合、少なくとも1人の加入者が接続されるまでは、パブリッシャー側のメトリクスに依存しないでください。加入者が存在するまでは、パブリッシャの帯域幅に関する品質制限の理由を無視できます。中継セッションの場合、少なくとも1人のサブスクライバーが接続されるまでは、統計情報はレポートされません。

パブリッシャーがリレーセッションの場合、パブリッシャーは各サブスク ライバーに個別のメディアストリームを送ることに注意すること。このため、統計イベントには複数の統計オブジェクトが含まれる。リレーセッションの各統計オブジェクトには、2つの識別フィールドが含まれる：

  • 接続ID:サブスクライバの接続の一意の ID。これは、そのクライアントの接続作成イベントで配信された接続オブジェクトの ID プロパティと一致します。
  • 加入者ID:このパブリッシャーのストリームを受信している サブスクライバーオブジェクトの一意なID。これはサブスクライブしているクライアントの アプリケーションにあるサブスクライバーのIDプロパティと一致する。

これらのフィールドにより、各統計オブジェクトがどのサブスクライバに属するかを判断することができます。

ルーティングされたセッション (Vonage Video Media Router を使用) では、発信メディアストリームは 1 つだけなので、stats 配列には 1 つのオブジェクトが含まれ、接続 ID と加入者 ID はともに未定義です。

オーディオ・メトリクス

  • パケットが失われた： 加入者に到達できなかったオーディオパケットの総数。
  • 送信されたパケット： 加入者またはメディア・ルーターに送信されたオーディオ・パケットの総数。
  • 送信されたバイト数： オーディオペイロード、ヘッダー、パディングを含む、送信されたすべてのオーディオデータの累積サイズ。
  • オーディオレベル： 0から1の間で正規化された、オーディオ信号の現在のラウドネス。
  • タイムスタンプ 各測定がいつ行われたかを示す。

パブリッシャーのトランスポートおよびネットワーク状態のメトリクスは、パブリッシャー・メディア・リンク統計を通じて利用できます。参照 メディアリンク統計 詳細はこちら。

ビデオ・メトリクス

  • パケットが失われた： 宛先に到達しなかったビデオパケットの数。
  • 送信されたパケット： 加入者またはメディアルーターに送信されたビデオパケットの総数。
  • 送信されたバイト数： ビデオペイロード、ヘッダー、パディングを含む、加入者またはメディアルーターに送信された総バイト数。
  • タイムスタンプ 測定開始点と現在の測定点を示す。
  • ビデオレイヤー サイマルキャストまたはスケーラブルビデオ符号化（SVC）用のレイヤごとの情報。サイマルキャスト構成では、各オブジェクトは1つの独立したビデオエンコーディングに対応する（例えば、低、中、高解像度のストリームが並行して送信される）。SVC(スケーラブルビデオコーディング)の場合、パブリッシャは通常、スケーラビリティ(時間的、空間的、またはその両方)が内部的にエンコードされた単一のビデオエンコーディングを送信し、スケーラビリティモードフィールドを介して記述される。これには以下が含まれる：
    • エンコードされたフレーム幅：このレイヤーのエンコードされたビデオフレームの幅。スケーリングやアダプテーションが適用されている場合、カメラのキャプチャ解像度と異なる場合があります。
    • エンコードされたフレームの高さ：このレイヤーのエンコードされたビデオフレームの高さ。幅と同様に、エンコーダーは帯域幅、CPU、またはサイマルキャスト/SVCレイヤーの設定に基づいてフレームをダウンスケールすることがあります。
    • エンコーダー出力フレームレート：ビデオフレームが正常にエンコードされた実際のフレームレート。これは、カメラのキャプチャフレームレート（エンコード前にフレームがドロップされることがある）および実際に送信されるフレームレート（送信前にエンコードされたフレームが破棄されることがある）と異なる場合があります。
    • ビットレート（ビデオペイロードのみ）：エンコードされたビデオペイロードの推定ビットレート。これはRTPオーバーヘッドを除いたものであり、エンコーダのレート制御の決定に基づいて変化する可能性がある。
    • 合計ビットレート（オーバーヘッドを含む）：RTPヘッダー、パディング、その他のトランスポート・オーバーヘッドを含むビットレート。ペイロードのみのビットレートよりも、実際のネットワーク使用量をよりよく反映する。
    • スケーラビリティ・モード：空間的／時間的スケーラビリティ構造を示す（例："L3T3"）。
    • コーデック：このレイヤーのエンコードに使用されるコーデック（例：VP8、VP9、H.264、AV1）。
    • 品質制限の理由：エンコーダーが品質を制限した理由（帯域幅、CPU、その他）を示します。アダプテーションの原因がネットワーク状況にあるのか、デバイス側の制約にあるのかを診断するのに役立ちます。

パブリッシャーのメディアリンク統計

出版社のメディアリンク統計は以下の通り：

  • 交通統計 出版社のローカル輸送とネットワーク統計：
    • アップリンク接続の推定利用可能帯域幅。
    • ネットワーク・コンディション・スコア。参照 ネットワーク状況 詳細はこちら。
    • ネットワーク状態の理由。参照 ネットワーク状況 詳細はこちら。

これらの指標は、以下の方法で提供される：

  • メディアリンク統計イベント： メディアリンク統計を報告するために定期的にトリガーされる専用イベント。
  • ネットワーク状態の変更イベント： ネットワーク状態の重大な変化が検出されたときにトリガーされ、変化の理由とともに現在のメディアリンク統計を配信する。

パブリッシャーのメディアリンク統計は、パブリッシャー自身のアップリンクに関する情報を示しています。 一方、サブスクライバーのメディアリンク統計には、リモート側のパブリッシャーによる伝送状況や、ネットワーク品質低下の原因も報告されます。これら2つの視点の関係や、特定のサブスクライバーの体験を評価する方法については、[パブリッシャーおよびサブスクライバーごとのネットワーク状況](#network_condition_by_publisher and_subscriber)を参照してください。

加入者統計

サブスクライバーコールバックは、以下のメディアに関する情報を提供する。 受け取った アプリケーションは、再生に関する問題を検出し、ダウンストリームのパフォーマンスを評価し、適応的な決定を下すことができます。

オーディオ・メトリクス

  • パケットを受信した： 正常に受信されたオーディオパケット数。
  • パケットが失われた： 正常に受信できなかったオーディオパケットの数。
  • 受信したバイト数： パブリッシャーまたは Video API メディアルーターから受信した音声データの合計。
  • オーディオレベル： リモートの音声の大きさ。
  • タイムスタンプ メトリクスの収集時期
  • 送信側統計: 送信側が報告した帯域幅の推定値。

リモート・パブリッシャー・トランスポート統計およびネットワーク劣化ソース情報を含む、加入者のトランスポートおよびネットワーク状態のメトリクスは、加入者メディアリンク統計を通じて利用できる。参照 メディアリンク統計 詳細はこちら。

ビデオ・メトリクス

  • パケットを受信した： 何個のビデオパケットを正常に受信したか。
  • パケットが失われた： 正常に受信できなかったビデオパケットの数。
  • 受信したバイト数： パブリッシャーまたは Video API メディアルーターから受信した動画データの合計。
  • デコードされた解像度： デコード後のフレームの幅と高さ。
  • デコードされたフレームレート： デコーダーが生成する実際のフレームレート。これは、受信したフレーム数（デコード前にドロップされるフレームもある）やレンダリングされたフレーム数（レンダリング条件によってはデコードされたフレームが表示されない場合もある）とは異なる場合がある。
  • ビットレート： ビデオペイロードのみを考慮した現在の受信メディアスループット。
  • 合計ビットレート： ヘッダーとパディングを含む、現在の受信メディアのスループット。
  • ビデオフリーズのNumbers： WebRTCのStatistics APIで定義されている、ビデオのフリーズ数 フリーズカウント.
  • フリーズの合計時間： フリーズの合計時間。
  • ビデオポーズの数： 意図的な一時停止（パブリッシャーがビデオトラックを無効にした場合など）、およびパブリッシャーまたは加入者の音声フォールバックによりビデオが停止した場合を含む、5秒を超える中断の数。
  • ビデオの一時停止の合計時間： ビデオの一時停止の合計時間。
  • コーデック ビデオストリームで現在使用されているコーデック。
  • 送信側統計: 送信側が報告した帯域幅の推定値。

購読者向けメディアリンクの統計

加入者のメディアリンク統計は以下の通り：

  • 地元の交通機関の統計 加入者のダウンリンク接続のトランスポートおよびネットワーク統計：

    • ダウンリンク接続の推定利用可能帯域幅。
    • ネットワーク・コンディション・スコア。参照 ネットワーク状況 詳細はこちら。
    • ネットワーク状態の理由。参照 ネットワーク状況 詳細はこちら。

  • リモートパブリッシャーのトランスポート統計： ローカルトランスポート統計情報と同じフィールドを持つ、リモートパブリッシャーの アップリンク接続のトランスポート統計情報とネットワーク統計情報。送信側統計が有効でない場合、これらの統計は制限されるかもしれない。

  • ネットワーク劣化の原因 観測された劣化の主な原因が接続のどちらにあるのかを特定する：

    • いない： ネットワークの劣化は検出されなかった。
    • 地元だ： ローカル加入者のネットワークが主な原因である。
    • リモートだ： リモートパブリッシャーのネットワークが主な原因である。
    • 両方かはっきりしない： 劣化の原因を一方に明確に帰することはできない。

加入者メディアリンクの統計は、以下の方法で配信される：

  • メディアリンク統計イベント： メディアリンク統計を報告するために定期的にトリガーされる専用イベント。
  • ネットワーク状態の変更イベント： ネットワーク状態の重大な変化が検出されたときにトリガーされ、変化の理由とともに現在のメディアリンク統計を配信する。

ビデオ画質が変更されたイベント

SDKは、アプリケーションにパブリッシャーまたはサブスクライバーのビデオストリームに関する詳細な洞察を与えるために、ビデオ品質が変更されたイベントを提供します。これらのイベントは、クライアントの観測可能性のために提供される定期的なネットワーク統計を補完し、アプリケーションが継続的なメトリクスと重要な品質変化の両方に反応することを可能にします。

パブリッシャーまたはサブスクライバーにハンドラーをアタッチすることで、品質変更イベントにアクセスできます。このイベントは、劣化または改善の理由とともに、更新されたメトリクスを提供します。このメカニズムにより、メトリクスが内部的にどのように配信されるかに関係なく、アプリケーションで動画のパフォーマンスを監視し、それに応じて UI や動作を適応させることができます。

品質イベントの理由は、定義された優先順位に従ってトリガーされる。たとえば、帯域幅が原因の品質制限は、解像度の変更よりも優先されます。メトリクスのすべての変更を追跡する必要がある場合は、各イベントに含まれる詳細な統計情報を確認してください。詳細については、SDKリファレンス・ドキュメントを参照してください。

出版社にとって、その理由は以下の優先順位で考慮される：

  1. 帯域制限による劣化
  2. CPUの制限による劣化
  3. その他の品質劣化の理由
  4. コーデックの変更
  5. 解像度またはビデオレイヤーの変更

加入者については、以下の優先順位で理由が検討される：

  1. ビデオの中断
  2. コーデックの変更
  3. 決議の変更

通話品質の監視

コア統計APIに加え、OpenTok.js SDKは通話品質の変化をリアルタイムでモニタリングし、対応するための追加機能を提供します。これらの機能は、アプリケーションがデバイスの制約やネットワーク状況に適応してパフォーマンスを最適化するのに役立ちます。

注:CPUパフォーマンス・モニタリングやMOS（Mean Opinion Score）トラッキングを含む通話品質モニタリング機能は、現在Webアプリケーション用のOpenTok.js SDKでのみご利用いただけます。

主な機能

CPUパフォーマンス監視 - デバイスのCPU負荷の変化を検出し、それに応じてアプリケーションを適応させます。アプリケーションは、計算コストの高い機能を無効にしたり、通話の安定性を維持するためにビデオ画質を低下させることで、CPUストレスに対応できます。

平均意見スコア（MOS） - 業界標準のMOSスケール（1～5）を使用して、ユーザーがサービスから感じる体験の質を評価します。MOS アルゴリズムは、パケットロス、ビットレート、ネットワーク遅延、およびメディアの品質に影響を与えるその他の要因を考慮します。

複合最適化 - CPUパフォーマンスとネットワーク品質メトリクスの両方に対応する堅牢なアプリケーションを構築し、ビデオ解像度、フレームレート、その他のパラメータを動的に調整して、さまざまな条件下で可能な限り最高のユーザー体験を提供します。

プレコールテスト - を使用する。 Vonage Video API ネットワークテスト ユーザーがセッションに参加する前に、クライアントが音声および動画の配信に対応しているかどうかを評価し、MOSスコアを推定するためのライブラリ。

ウェブアプリケーションにおける通話品質モニタリングの詳細な実装ガイダンス、コード例、およびベストプラクティスについては、以下を参照してください。 OpenTok.js SDK ドキュメント.

送信側統計

通話中、パブリッシャーはメディアストリームを1つ以上のサブスクライ バーに送信する。メディアは、直接中継されるか、あるいは ビデオ・メディア・ルーター.加入者は、受信するストリームのビットレートを観察することはできるが、通常、ダウンリンクの総容量を把握することはできない。Sender-Side Statistics APIは、加入者がメディアを受信するために利用可能な帯域幅を評価し、ストリーム品質を最適化するのに役立つメトリクスを提供することで、この制限に対処する。

送信者はパブリッシャーまたは ビデオ・メディア・ルーターAPIはSender-side Statisticsと呼ばれる。この API は、送信者が報告されたメトリクスのソースであり、サブスクライバである受信者に配信されるため、送信者側統計と呼ばれます。

APIは、バンドル（オーディオとビデオのペア）ごとに、送信者が推定できる最大ビットレートと現在の推定帯域幅の2つの主要なメトリクスを報告する。最大ビットレートは、プラットフォームの制限により、推定できる上限値である。現在の推定帯域幅は、ストリームのビットレートとは無関係に、メディアに使用可能なWebRTCピア接続チャネル容量の推定ダウンリンク帯域幅である。

例えば、パブリッシャは 1 Mbps 未満の VGA ストリームを送信することができますが、Vonage Video Media Router は送信者側の統計情報を提供するため、現在の帯域幅を 8 Mbps と推定し、チャネル容量に余裕があることを示します。この情報はアプリケーションによって使用され、ビデオレイアウトを調整したり、Vonage Quality on Demand (QoD)などのポリシーベースのアクションをトリガーしたりすることができます。

の場合は解釈が異なることに注意。 シングルピア接続セッション が作成される。1つのピア接続セッションでは、複数のオーディオ+ビデオバンドルが同じ接 続を共有するため、総帯域幅の見積もりは、個々のバンドルの見積もり値を合計す ることによって計算する必要がある。言い換えると、総帯域幅は、単一ピア接続のすべての加入者間で共有される。

送信側統計の有効化

送信者側の統計を有効にするには、クライアント SDK の対応するメソッドを使用して、パブリッシャーで送信者統計トラックを有効にします。有効化すると、以下のメトリクスが通常のサブスクライバーのオーディオとビデオの統計イベントに含まれます：

  • 接続時に推定できる最大ビットレート。
  • 接続の現在の推定帯域幅。

使用例

  • 購読者レイアウトの最適化 Sender APIの推定帯域幅とローカルのエンドポイントのRTC統計を併用し、良好なビデオ画質で多数の加入者を表示する。

  • アダプティブ・メディア・モード： 加入者は、送信者の推定帯域幅が定義されたしきい値(たとえば、500kbps)を超えるかどうかを判断するために、送信者の統計情報を使用して、ビデオ専用モードまたはオーディオ専用モードのどちらで加入するかを決定することができる。

  • 負荷のスケーリング： 低ビットレートの画面共有から高ビットレートのライブビデオへの切り替えなど、加入者が負荷の増加に最適に対応できるかどうかを確認するには、送信側の統計を使用します。

  • しきい値警告： 送信側の統計情報を使用して、送信側接続の推定帯域幅が事前に定義したしきい値を下回った場合、加入者に警告をトリガーする。

  • クオリティ・オン・デマンド（QoD）のトリガー： サブスクライブされたストリームの推定ネットワーク容量が、モバイル・ネットワーク上で所定の閾値を下回った場合にトリガーするために、送信者側の統計情報を使用する。

備考

  • SDKによっては、送信者側の統計は、ネットワーク遅延のため、統計が初めて要求されたときや、サブスクリプション後の最初の統計イベントですぐに利用できない場合があります。
  • もしそうなら 単一のピア接続セッションを作成するピア接続の帯域幅は、すべての加入者で共有される。最大ビットレートは、ピ ア接続が推定できる最高ビットレートを表し、現在のビットレートは、各オーディオビデオバンド ルのビットレートを反映する。単一ピ ア接続のすべての加入者は、この最大ビットレートを共有する。送信者の利用可能な帯域幅を評価するときは、これを考慮してください。たとえば、複数の加入者が同じ単一ピ ア接続を共有している場合、現在のビットレートが 2 Mbps であれば、品質が高いことを示すかもしれない。

既知の問題

セッションがリレーされている場合、または参加者が2人だけの特定のルーティング・セットアップで、パブリッシャーがFirefoxを使用している場合、ブラウザの制限により送信側の統計が利用できないことがあります。

ネットワーク状況

ネットワーク・コンディションAPIは、パブリッシャーとサブスクライバーの両方に対して、ネットワーク接続の健全性をリアルタイムで可視化します。接続の全体的な品質を反映するネットワーク・コンディション・スコアと、そのスコアの主な理由、そして購読者向けに、観測された劣化の原因となっている接続のサイドに関する情報を公開します。

ネットワーク状態の指標はメディアリンク統計に含まれ、2つのチャンネルを通じて配信される：

  • 定期的な統計： ネットワーク状態フィールドは、定期的なメディアリンク統計イベントとともに提供されるメディアリンク統計に含まれています。詳しくは、 メディアリンク統計 詳細はこちら。
  • ネットワーク状態の変更イベント： ネットワーク状態の重大な変化が検出されると、専用のコールバックまたはイベントがトリガーされる。このイベントは、ビデオの有効/無効やオーディオのフォールバック・イベントとは異なり、メディア・トラックの状態の変化ではなく、ネットワークの健全性の変化を報告します。アプリケーションはこのイベントを使用して、UIインジケータの更新、テレメトリのロギング、適応動作のトリガなど、ネットワークの問題に対応することができます。イベントには、現在のメディア・リンクの統計情報と、変更の理由が含まれます。

ネットワーク状態スコア

ネットワーク状態は、指定されたトランスポート（ローカルまたはリモート）のネットワーク接続の全体的な健全性を反映するスコアである。スコアは、パケットロスや推定利用可能帯域幅などのメトリクスから導き出される。値が高いほど、ネットワーク状態が良好であることを示す。

スコア 説明
不明 ネットワークの状態は不明。
素晴らしい 優れたネットワーク条件。ビデオ品質が最適で、推定帯域幅が現在の解像度の最大ビットレートに対応できる。
グッド 良好なネットワーク状態。マイナーまたは一時的な問題が発生する可能性があります。
フェア 中程度のネットワーク状態。ビデオの画質は送信者によって制限される場合があります。
警告 ネットワークの状態が悪い。ビデオの品質に大きな影響があり、オーディオのフォールバックが有効になっている場合、ビデオ無効の警告が発せられる。
クリティカル 深刻なネットワークの問題。音声フォールバックが有効な場合、SDKは通話の安定性を維持するためにビデオを無効にします。

注： ネットワーク品質スコアは、現在のメディア構成と帯域幅需要に対する相対的なものです。ネットワークがアクティブな要件（ビデオ解像度、ビットレート、フレームレートなど）をどの程度サポートしているかを反映します。たとえば、低いカメラ解像度または低いビットレートを使用するようアプリケーショ ンが構成されている場合、帯域幅の需要は最小限であるため、ネットワークは「優」 と評価されます。高解像度または高ビットレートでは、より多くのネットワーク容量が必要となるため、同じネットワーク条件下でも品質スコアが異なる場合があります。

ネットワーク状態の原因

各ネットワークの状態スコアには、評価を左右する主な要因を示す理由が添えられている：

  • いない： 特筆すべき理由はない。
  • 帯域幅： 利用可能な帯域幅によって影響を受けるネットワークの状態。
  • パケットロス： パケットロスの影響を受けたネットワークの状態。

ネットワーク劣化の原因

ネットワーク劣化ソースは、観測されたネットワーク劣化の主な原因が接続のどちらにあるかを特定します。このメトリックは加入者向けに提供され、パフォーマンスの問題が加入者のダウンリンクに起因するのか、リモート・パブリッシャーのアップリンクに起因するのかについて、重要な洞察を提供します。

ネットワーク劣化ソースは、アプリケーションでネットワーク問題の根本原因を突き止めるのに役立ち、的を絞ったトラブルシューティングやユーザーとのコミュニケーションを可能にします。ネットワークの状態が悪いことだけを報告するのではなく、ローカル加入者の接続品質に問題があるのか、リモート・パブリッシャーの接続品質に問題があるのかを示します。

可能な値：

  • いない： ネットワークの劣化は検出されなかった。ローカル接続、リモート接続ともに良好です。
  • 地元だ： ローカル加入者のネットワークが劣化の主な原因です。問題としては、WiFi信号の不良、ダウンリンクでのパケットロスの多さ、加入者の接続で利用可能な帯域幅の制限などが考えられます。
  • リモートだ： リモートパブリッシャーのネットワークが劣化の主な原因である。パブリッシャーのアップリンクのネットワーク状態が悪く、このサブスクライバーが受信するメディアの品質に影響を及ぼしている。
  • 両方かはっきりしない： 劣化が接続の両側で発生している、またはソースが片側に明確に帰属することができない。これは通常、サブスクライバとパブリッシャの両方が同時にネットワークの問題を経験している場合に発生します。

パブリッシャーおよびサブスクライバーごとのネットワーク状況

1つのパブリッシャーは多数のサブスクライバーにサービスを提供できますが、各サブスクライバーは1つのパブリッシャーから1つのストリームを受信します。ネットワーク状態の報告は、次のような形式で行われます。パブリッシャーは自身のアップリンクの状態を報告し、サブスクライバーは自身のダウンリンク、リモートパブリッシャーのアップリンク、および通信品質の低下が生じた場合にその責任がどちら側にあるかを報告します。

出版社が、自社が所有するリンクを報告する。 ルーティングされたセッションでは、パブリッシャーは ビデオ・メディア・ルーター、ストリームを受信するサブスクライバーの数がいくつであっても同様です。メディアルーターはその接続を終了し、自身が管理する個別の接続を介して、各サブスクライバーにメディアを転送します。 したがって、パブリッシャーのトランスポートメトリクスとは、パブリッシャーからメディアルーターに至るメディアパス区間、すなわちパブリッシャーが独自のエンコードやレート制御を通じて直接影響を与えることができる区間を表します。これが、ルーティングされたパブリッシャーの統計配列に、接続IDとサブスクライバーIDが未定義の単一のオブジェクトが含まれる理由でもあります。これについては、 出版社統計. 参加者が2人を超えるセッションでは、これらの指標をすべての受信サブスクライバーに拡張することはスケーラビリティの面で困難であり、診断上の価値も限定的となる。メディアルーターは、不特定多数のサブスクライバーにストリームを転送するため、パブリッシャー側のデータだけではネットワークの問題を特定することも、障害を特定の参加者に帰属させることもできないからである。

ローカルリンクを報告することで、AMRの遷移を透明に保つことができます。 一方で 適応型メディアルーティング（AMR） 具体的には、各パブリッシャーが1人のサブスクライバーを持つ2者間の通話を扱いますが、追加の参加者が参加したり、特定の機能が有効になったりした場合でも、中継されたメディアパスは通話中にメディアルーターへ移行することが可能です。 パブリッシャーのメディアリンク統計は、パブリッシャー自身のネットワークリンク（アップリンク）を表すものであり、そのリンクがサブスクライバーで終端するか、メディアルーターで終端するかに関わらず、そのような遷移の際にもその意味や形式は変わりません。 Applicationsは、現在のトポロジーを追跡したり、通話中にそれに適応したりすることなく、パブリッシャーの統計情報を一貫して利用できます。これは、本ガイドの冒頭で述べた設計目標に沿ったものであり、高レベルの統計 API はパブリッシャーとサブスクライバーの抽象化に明確にマッピングされ、遷移後も安定した状態を維持します。

2者間の通話については、加入者の視点に基づいて判断してください。 各参加者が1つのストリームを配信し、1つのストリームを購読している場合、購読者の統計情報だけで双方向の状況を推論するのに十分です。もしある購読者が、 Remote、遠隔地の参加者のアップリンクには制約があります。また、一般的な原因（Wi-Fi信号の弱さ、アクセスネットワークの混雑、携帯電話の電波状況の悪さなど）は通信リンクの両方向に影響を与えるため、その参加者の加入者側でも通信品質の低下が生じている可能性が高いです。これは確実な事実ではなく、あくまで推測として捉えてください。

こちらも参照 パブリッシャーと購読者のメトリクスを関連付け、根本原因を診断する.

オーディオのフォールバックとの関係

ネットワーク状態の報告は、オーディオのフォールバック・メカニズムと整合しています。オーディオフォールバックイベントが警告またはクリティカルレベルでトリガーされるとき、報告されるネットワークコンディションは同じ重大度を反映します。ネットワークコンディションは、パブリッシャー、サブスクライバー、またはその両方に対応する警告またはクリティカルステートを示し、ネットワークとメディアフォールバックAPI間で一貫したシグナリングを保証します。

オーディオのフォールバックが無効になっている場合、警告またはクリティカル・レベルが報告されても、オーディオのフォールバックはトリガーされません。

ネットワーク状態の有効化

ネットワーク状態のレポートは、複数の機能が連動することで構築されます。より多くの機能を有効にすればするほど、ネットワーク状態データはより豊富で正確なものになります：

  • 送信側統計: サブスクライバーがリモートパブリッシャートランスポートメトリクスと、より正確なネットワーク劣化ソースの帰属を受信できるように、パブリッシャーの送信側統計を有効にします。
  • パブリッシャー・オーディオのフォールバック： パブリッシャー側のネットワーク・コンディション・スコアリングの精度を向上させるため、パブリッシャー側でオーディオのフォールバックを有効にする。
  • 加入者の音声フォールバック： 加入者側のネットワーク状態スコアリングの精度を向上させるために、加入者側で音声フォールバックを有効にする。

これらの機能を有効にしないと、一部のネットワーク状況データが制限されたり、利用できなくなったりすることがあります。

ネットワークコンディションが変化したイベントを受け取るには、パブリッシャー またはサブスクライバー上でネットワークコンディションが変化したコールバック またはリスナーを登録する。イベントには、ネットワーク・コンディションとトランスポート・メトリクスを含む現在のメディア・リンク統計が含まれる。詳細については、各 Client SDK の オーディオとビデオの統計収集が可能 セクションを参照されたい。

クライアントの観測可能性の洞察を利用する

このセクションでは、これらのシグナルを効果的に機能させる方法と、避けるべき一般的な間違いについて、実践的なガイダンスを提供する。

ベストプラクティス

SDKに品質を自動調整させ、その結果に基づいて行動する

SDKはすでに品質適応を自動的に処理している：

  • 出版社側： 帯域幅やCPUに制約がある場合、パブリッシャーは自動的に解像度とフレームレートを下げる。サイマルキャストやSVCのコンフィギュレーションでは、これはエンコーダーがより低い空間レイヤーや時間レイヤーに落ちる可能性があることを意味する。
  • SFU（ルーティングセッション）： Vonage Video Media Routerは、加入者の利用可能なダウンリンク帯域幅に基づいて、各加入者に適切なサイマルキャスト・レイヤーを選択します。弱い接続の加入者は、アプリケーションの介入なしに低解像度のレイヤーを受信します。
  • 中継セッション： パブリッシャーは、各サブスクライバーに個別のストリームを送信するため、 各ピアに対して直接ダウンスケールする。

このロジックをアプリケーションで再現する必要はありませんし、また再現すべきではありません。代わりに、observabilityイベントを使って 反応 UIを更新したり、テレメトリーを記録したり、SDKがすでに報告した内容に基づいて、より高度なポリシー決定をトリガーしたりします。

もし quality_limitation_reason の bandwidth パブリッシャービデオメトリックスでは、エンコーダはすでに出力を絞っています。このシグナルを使用して、冗長な解像度オーバーライドを発行するのではなく、（高解像度のプレビューを非表示にするなど）UX の決定に役立てましょう。同様に、理由が cpuApplicationsは、エンコーダに余裕を持たせるために、アプリケーションの他の場所でCPUリソースを解放することを検討します。例えば、必要のないアニメーションを一時停止したり、バックグラウンド処理を延期したり、UIレンダリングの複雑さを軽減したりします。

リアルタイム・ネットワーク品質インジケーターの表示

メディア リンク統計のネットワーク コンディション スコアを使用して、UI に品質インジケータ（信号強度バーや色の付いたアイコンなど）を表示します。ネットワーク状態 変更 (ネットワーク状態変更イベントを使用)ではなく、定期的な統計ティックごとに行う。これにより、不必要な再レンダリングを回避しながら、インジケータを意味のある品質変化に対応させることができます。

加入者については、ネットワークの劣化ソースが教えてくれる。 どちら の通話に影響があります。例えば、「接続が不安定です」と「リモート参加者にネットワークの問題が発生しています」のように、一般的な品質警告ではなく、ターゲットを絞った実用的なフィードバックを参加者に提供できます。

ポーリングではなく、適応型UXのためにイベントを使う

閾値ロジックのために定期的な統計アレイを検査するよりも、イベントドリブンコールバックを優先してください。ネットワーク状態変更イベントとビデオ品質変更イベントは、意味のある遷移を検出するために構築されています。ティックごとに定期的な統計情報をポーリングして閾値の交差を検出すると、CPU オーバーヘッドが発生します。

定期的な統計データに基づいて行動する必要がある場合は、UXの変更をトリガーする前に、いくつかの連続したサンプルにわたってロジックをデバウンスする。

交通統計をレイアウトや政策決定に活用する

加入者メディアリンク統計は、2つの観点から同時にトランスポートメトリクスを公開する：

  • 地域交通統計 は、送信側（パブリッシャーまたは Vonage Video Media Router）がこの加入者への接続で利用可能であると推定する帯域幅を反映します。WebRTCにおける帯域幅の推定は、RTCPフィードバックに基づいて送信側で実行されるため、この図は、加入者による自己測定ではなく、送信側によるチャネル容量の見方を表しています。
  • リモートパブリッシャートランスポート統計 は、パブリッシャー側から報告されたパブリッシャー自身のアップリンクトランスポートメトリックを反映する。

これら2つのビューを組み合わせることで、発行者と購読者の間の完全なパスを推論することができます。これらのビューを使用して、積極的なレイアウトやポリシーの決定を行いましょう：

  • ビデオタイルの表示数を制限する。 推定容量が少ない場合、グリッドレイアウトで、フリーズしたり劣化したビデオを表示するのではなく、優先順位の低い参加者を非表示にする。
  • クオリティ・オン・デマンド（QoD）ポリシーのトリガー ローカルトランスポート帯域幅の推定値が定義されたしきい値を下回っ た場合、モバイルネットワーク上で、例えば、ハイビジョンストリームから標 準ビジョンストリームに切り替える。
  • 容量警告を表示する ローカルトランスポート帯域幅の見積もりがすでに制約されている場合、セッ ションに新しい高ビットレートストリーム(画面共有など)を追加する前に。

マルチパーティシパントグリッドでは、トランスポート統計とCPU制限シグナルを使用して、パブリッシャー全体に品質バジェットを割り当てることで、このアプローチを拡張できます。SDKは各ストリームを独立して適応させるため、レイアウトにおいてどのパーティシパントが重要であるかについての知識はありません。使用方法 setPreferredResolution そして setPreferredFrameRate パブリッシャーがそれを表現するために、注目のタイルには解像度の上限をすべて与え、バックグラウンドの参加者には低い値を設定します。アクティブなスピーカーが変わったり、状況が変化した場合は、それに応じて天井のバランスを調整します。これは、SDKの自動アダプテーションを補完するもので、アプリケーションが設定した上限値の範囲内で動作し続けます。

パブリッシャーと購読者のメトリクスを関連付け、根本原因を診断する

ネットワークの問題は、通話のどちら側からでも発生する可能性があります。パブリッシャ・メディア・リンクの統計とサブスクライバ・メディア・リンクの統計の組み合わせ、およびネットワークの劣化ソースを使用して、根本原因を推論します：

  • パブリッシャーのアップリンクに警告またはクリティカルなネットワーク状態が発生した場合。 Remote 加入者の劣化ソースは、パブリッシャー側のネットワークの問題を指摘している。
  • 加入者のダウンリンクで利用可能な帯域幅が低下することと、次のことが組み合わされる。 Local 劣化ソースは加入者自身の接続を指す。
  • 双方に劣化が見られる場合、またはソースが Both or unclear問題を共有の問題として扱う。

通話後の分析とデバッグのためのログ統計

定期的な統計とネットワーク状態の変化イベントをバックエンドの分析パイプラインに保存します。キャプチャする価値のある主なメトリクスは以下のとおりです：

  • 出版社および購読者ごとのネットワーク状況スコアとその理由。
  • ビデオ品質制限の理由とアクティブレイヤ（サイマルキャスト/SVC）。
  • メディアリンク統計からの推定利用可能帯域幅。
  • フリーズや一時停止の回数と合計時間。
  • MOS スコア（Web SDK）は、知覚された通話品質の代理として使用されます。

これらのログを通話後に分析することで、特定の時間帯、特定のネットワークタイプ、特定のデバイスモデルで繰り返し発生する劣化などのパターンを明らかにし、インフラやUXの改善を導くことができる。

アンチパターン

SDKの自動品質適応をオーバーライドしないでください。

SDKは、帯域幅やCPUに制約がある場合、すでに解像度とフレームレートを下げています。すべての統計イベントに対応して手動で解像度をオーバーライドすることは、一般的にエンコーダのレート制御と競合し、振動（品質レベル間の急激な切り替え）を引き起こす可能性があります。

特定の品質要件（例えば、最大許容解像度）がある場合は、実行時に統計イベントに反応するのではなく、セッションセットアップ時に宣言的に設定する。

トランスポート統計に基づく音声のみのフォールバックを手動でトリガーしない

SDKの オーディオフォールバック 機能はすでにネットワーク状態を監視しており、接続が警告レベルまたはクリティカルレベルに悪化すると自動的にビデオを無効にします。ローカルのトランスポート帯域幅の推定値に基づいてサブスクライバをオーディオオンリーモードに切り替える独自のロジックを実装すると、この組み込みの動作と重複し、競合する可能性があります。たとえば、SDK独自のしきい値に到達する前にビデオを早期に無効にしたり、SDKとは異なる時点でビデオを再度有効にしたりします。オーディオのフォールバック動作が必要な場合は、トランスポート統計から直接駆動するのではなく、SDKのオーディオのフォールバック機能を使用してください。

定期的な統計イベントごとにUI変更をトリガーしない

定期的な統計は定期的な間隔（通常は数秒ごと）で発生します。イベントごとにUIの更新やビジネス・ロジックを適用すると、特に瞬間的なパケット損失のようなノイズの多いメトリクスで閾値チェックを行うと、インジケータがちらつき、スプリアス・アラートが発生します。ユーザー向けの状態を更新する前に、しきい値を下回る連続した複数のサンプルを要求するか、専用のネットワーク状態変更イベントを使用します。

パブリッシャー側の指標だけに頼らず、購読者の体験を診断する。

パブリッシャーのメトリクスは、アップストリームの伝送品質を反映する。パブリッシャーが優れたネットワーク状況を報告しても、1人または複数の加入者がダウンリンクの品質低下を経験している場合があります。特定の加入者の使用感を評価するには、常にパブリッシャーのメディア・リンク統計と、ネットワーク劣化の原因を含む加入者側のメトリクスを組み合わせてください。

生のバイト数やパケット数を品質信号として使用しない

累積は以下の通り。 bytesReceived または packetsLost は単調に成長し、それ自体に固有の意味はない。常にレート（サンプル間のインターバルの差分）を計算するか、推定ビットレートやネットワーク・コンディション・スコアなど、SDKがすでに生カウンターから導出している上位フィールドを使用する。

エンド・ツー・エンドの品質測定に低レベルのRTC統計を使用しない

RTCの統計報告書は、ある国の状況を反映している。 シングル ある時点における基礎となるピア接続。SDKはセッション中にピア・コネクション間またはトランジション・トポロジ間を移行することがあるため、生のRTC統計はこれらのトランジションをまたいで集約されません。エンド・ツー・エンドの品質測定と長期にわたるセッション・モニタリングには、これらの内部変化を考慮した高レベルのオーディオ、ビデオ、メディア・リンク統計APIを常に使用してください。

ルーティングセッションとリレーセッションの違いを無視しない

ルーティングされたセッションでは、送信者側の統計はVonageビデオ・メディア・ルーターによって提供され、加入者側の帯域幅の見積もりは、メディア・ルーターへの加入者のダウンリンクを反映したものであり、パブリッシャーのアップリンクの直接測定ではありません。中継された（ピアツーピアの）セッションでは、パブリッシャーは個々のストリームを各加入者に送信します。アナリティクスやアダプティブ・ロジックを構築する際は、数値を誤って解釈しないようにセッション・モードを考慮してください。

RTC統計レポート

RTC stats report APIは、公開およびサブスクライブされたメディア・ストリームの低レベルで標準化されたWebRTC統計へのアクセスを提供します。これにより、アプリケーションはWebRTC仕様で定義されたフォーマットで詳細なメトリクスを取得できるようになり、カスタム・クライアントの観測可能メトリクスを超える高度なモニタリングと分析が可能になります。

注： このAPIは、低レベルのピア接続統計情報を提供します。Video SDKは、ピア接続の最適化、異なるトポロジー間の移行、あるいは別のバックエンドサーバーへの移行を行う場合があります。これらの低レベルの統計情報には、現在使用中のピア接続や移行元のピア接続のメトリクスが集計されていません。 したがって、エンドツーエンドの監視には、当社のオーディオおよびVideo APIを利用することをお勧めします。

オーディオとビデオの統計収集が可能

パブリッシャーまたはサブスクライバーでは、対応する統計イベントをリッスンします。詳細については、各 Client SDK の関連する開発者ガイドを参照してください：