Quality of Serviceサブスクリプションの解説

Quality of Serviceサブスクリプションは、ミーティング、ウェビナー、およびPhoneのQoSデータを顧客のサードパーティエンドポイントに提供するアドオン製品です。

Quality of Service Subscription は、イベントサブスクリプションを通じて Zoom Meetings、Webinars、および Zoom Phone のほぼリアルタイムな QoS テレメトリをストリーム配信するアドオン製品です

Zoom の Quality of Service Subscription（QSS）は、Zoom Meetings、Webinars、および電話通話向けにほぼリアルタイムの Quality of Service（QoS）データを提供するアドオン製品です。QSS は参加者レベルの QoS イベントを分/分単位（設定によりレートや集計は異なる場合があります）で送信することで Zoom の製品機能を拡張します。顧客はこの豊富なデータストリームを使用して、ネットワーク環境が Zoom のサービスに影響を与えているかどうかを特定できます。

QSS は Zoom ダッシュボードおよび API で使用される基礎的な QoS 指標を配信しますが、サンプリングとタイミングが異なります

既存の Zoom ダッシュボード はネットワークのパフォーマンスと使用状況の指標を提供し、顧客がネットワーク環境における Zoom の動作を理解するのに役立ちます。QSS は同じ Zoom の QoS データをより高速なレートで提供します。この高速サンプリングにより、集計された QoS 指標はメインの Zoom ダッシュボードとは異なる値を示します。しかし、これらの指標は顧客が独自のダッシュボードビューに構成して、Zoom データを他のシステムと相関させることを可能にします。

下表は QSS を通じて顧客のエンドポイントに配信される QoS データの説明です。

	QSS を介して配信される QoS データ
品質指標	ビットレート、遅延、ジッター、パケットロス、解像度、フレームレート、CPU 使用率
使用状況指標	デバイス、ネットワーク、シグナリングリージョン、クライアントバージョン、オーディオ（入出力）、ビデオ（入出力）
頻度	おおよそ参加者あたり1分に1件のイベント（アカウント設定に応じて各 QoS 指標ごと、または集計セットごと）。
データ保持	イベント配信ログは Webhook Logs API を通じて7日間保持されます。API エンドポイント経由の過去の QoS データは（ライセンスにより）より長期間保持される場合があります。

Zoom ダッシュボードのデータは QSS を介して顧客のサードパーティーエンドポイントに配信されるデータと比較すべきではありません

QSS と Zoom ダッシュボードは、Zoom の QoS データにアクセスするための別個の仕組みであり、比較するべきではありません。Zoom ダッシュボードと QSS は同じ QoS データプールから取得していますが、取得タイミングやデータ配信頻度の違いにより、それぞれの仕組みでのデータは一致しません。

QSS はミーティング、ウェビナー、電話通話向けのリアルタイムイベントデータをサポートします

QSS はアカウント上のすべてのユーザーに対して Zoom Meetings および Webinars の QoS イベントデータを提供し、Zoom Phone の通話についても QoS イベントデータを提供します。Zoom は通話の最終区間を管理していないため、Zoom Phone 通話についてはアカウントレベルの QoS イベントデータのみを提供し、エンドツーエンドの詳細な参加者データを完全に可視化することはできません。

QSS のデータには外部参加者のデータは含まれません

QSS は外部のミーティング参加者のデータを提供しません。ただし、QSS はどの内部参加者に問題が発生したか、その問題が何であったか、トラブルシューティングに必要な品質および使用状況の指標を特定するのに役立ちます。

QSS は顧客が Zoom ダッシュボードの生の QoS データを既存のワークフローに取り込むことを可能にします

従来、Zoom 顧客は Zoom ダッシュボードや API などのツールを使用して Zoom の QoS データを表示または取得できましたが、QSS を使用するとイベントサブスクリプション（Webhook または WebSocket）を介して Zoom の QoS テレメトリをネットワーク管理および監視プラットフォームにストリーム配信できます。

QSS はほぼリアルタイムの QoS イベントを購読先エンドポイントに配信し、API ポーリングとレート制限の影響を低減します

QSS の顧客はリアルタイムの QoS イベントおよびデータを購読してアプリケーションのエンドポイントにプッシュで受信できます。これにより API 容量の節約やネットワーク利用の最適化に役立ちます。QSS は Zoom の 標準の webhook サービス を補強するもので、ほぼリアルタイムで分あたり4〜6回のレートでエンドポイントに生の QoS データを送信できます。

QSS により顧客は API のレート制限に達することなく Zoom ダッシュボードのほぼリアルタイム QoS データにアクセスできます

API サービスはリクエストベースで、アプリやユーザーが要求したデータを取得する「プル」方式を使用します。API はエンドポイントからデータを繰り返し取得するため、Webhook よりもリソース集約的です。

以下のような顧客は Zoom API を使用して Zoom ダッシュボードから QoS データをプルする際にレート制限に遭遇する可能性があり、これは一定期間内に実行できる API コールの上限に達したことを意味します。QSS は API のレート制限を増やすものではありませんが、顧客がデータを自らプルする代わりに生の QoS データをエンドポイントにプッシュすることで、レート制限の懸念を軽減します。

QSS により顧客は生の Zoom QoS データを取り込み、好みのネットワーク管理システムでトラブルシューティングできます

一部の顧客は複数のアプリケーションで同時にネットワークパフォーマンスを評価する必要がある場合があります。QSS を使用すると、顧客は Zoom の QoS データを自社のアプリケーション群の他のデータと並べてダッシュボードで監視でき、Zoom の QoS データを柔軟かつスケーラブルに取り込み、カスタムダッシュボードにシームレスに統合できます。

Zoom の QoS データは TLS 1.2 経由で送信されます

QSS データは TLS 1.2 以上を使用して送信中に暗号化されます。エンドポイントは有効な認証局（CA）証明書を使用する必要があります。Webhook リクエストには検証用の署名ヘッダーとチャレンジ・レスポンスチェックが含まれます。

追加のセキュリティとして、顧客は Webhook エンドポイントの検証 をチャレンジ・レスポンスチェック（CRC）を使用して求められます。CRC はイベント通知エンドポイント URL の所有権とセキュリティを確認します。

顧客は QSS イベントを受信できるアプリケーションを作成することで QoS データの利用を開始できます

顧客が QSS のアドオンプランを購入した後、アカウント上の少なくとも1人のユーザーが開発者権限を有効にする必要があります。顧客は次の3つの手順を用いて QSS イベントを購読できる Webhook アプリケーションを作成できます。

顧客はまた、 Zoom Developer Pack （QSS フラグ有効）を検討することもでき、これにより QSS が他の開発者ツールとバンドルされます。

1

イベントサブスクリプションアプリを作成する（一般的な OAuth または Server-to-Server OAuth）。イベントサブスクリプションを有効にして QoS イベントを選択する

顧客はまず Zoom App Marketplaceで一般的なアプリまたは Server-to-Server OAuth アプリを作成する必要があります。その後、イベントサブスクリプションを有効にして受信したい QoS イベントを選択します。

次に、顧客はアプリケーションのイベント通知エンドポイント URL を入力して QSS イベント通知の送信先を指定する必要があります

この構成に Webhook のみのアプリは必須ではありません。Zoom は一般的なアプリの作成を推奨します。

2

QSS Webhook イベントを購読する

QSS イベントを購読するには、顧客はイベントを追加し、利用可能な QSS の一覧から選択する必要があります。 イベントタイプ。顧客はプロセスを完了してアプリケーションを有効化する前に、1つ以上の QSS イベントを選択できます。

購読は Marketplace の UI または API コールでも管理できます：

• POST /marketplace/app/event_subscription – 作成

• PATCH /{id} – ユーザー/アカウントを購読

• DELETE /{id} – 購読解除/削除

• GET /marketplace/app/event_subscription – 一覧取得

API を介して認証するには、Client Credentials Grant からのトークンを使用してください。

3

Webhook イベントを検証する

イベントサブスクリプションを構成した後、Webhook URL の所有権とイベントの真正性が適切に検証されていることを確認してください。

• URL 検証

  • イベントサブスクリプションを初めて有効にすると、Zoom はチャレンジ–レスポンスチェック（CRC）を実行して Webhook エンドポイントの所有権を確認します。このプロセスにより、Zoom がアプリが管理する正当な送信先にデータを送信していることが保証されます。（必要であれば、CRC の処理を早い段階のセットアップ手順に含めることもできます。）

• イベント検証

  • 着信する各イベント通知は、アプリケーションによってそれが Zoom 発信であることを確認するために検証されるべきです。アプリは各 Webhook イベントに含まれる署名ヘッダーを使用して着信リクエストを検証できます。デフォルトの署名方法の代替を好む開発者は、Zoom Developer Docs に記載されている他のサポートされている検証オプションのいずれかを使用できます。

  • Get Webhook Logs API を使用して、ステータス、リトライ回数、トレース ID を含む最大7日分の Webhook 配信データを確認してください。

実装の詳細については、以下を参照してください： QSS 実装ガイド 開発者向け。技術的な詳細は、Zoom Developer Docs の Event Subscription API、Webhook Logs API、および Client Credentials Grant 認証ガイドを参照してください。