通話前テストのベストプラクティス
このガイドでは、参加失敗を減らし、ライブセッションの体験を保護したい Video API アプリケーションのための、通話前の体験について説明します。待合室、権限とデバイスのセットアップ、ネットワークテスト、結果の解釈、および参加決定について説明します。
通話前テストでは、ある時点での通話品質を推定します。セッション開始前にセットアップの問題を検出することはできますが、通話中に何が起こるかを予測することはできません。ユーザーが参加した後も クライアントの観測可能性品質イベント、ランタイム適応機能などだ。
コール前の推奨フロー
- ユーザーが通話に参加する前に待合室を使用する。
- カメラとマイクの許可を確認し、ローカルプレビューを表示します。
- ユーザーにデバイスを選択させ、現在選択されているカメラとマイクを表示する。
- で通話前テストを実行する。 別のテスト資格 と別のテスト・セッションを作成します。これにより、コール・セッションとそのインスペ クタ・データが、テスト接続やストリームから分離される。
- 走る
NetworkTest.testConnectivity()まずNetworkTest.testQuality(). - 文書化された出力を使って、控え室のステータスを設定する。簡単なモデルは
Pass,WarnあるいはFail. - アクセス許可、デバイスのセットアップ、通話前のチェックが完了したら、セッションに参加してください。以下の場合
Warn一つの選択肢は、ユーザーに明確な警告を発して続行させることである。
network-testライブラリを使用する場合は、別途 ルート付き テスト・セッションで使用します。通信セッション ID をテスト・セッションに再利用しないでください。テスト実装が明示的な audioSource そして videoSource 値は、待合室で選択したカメラとマイクを使用します。
控室
待合室では、ユーザーが通話に入る前に、カメラやマイクの許可を確認したり、デバイスを選択したりする時間が与えられます。セッション開始前に、推奨されるパブリッシュ設定を適用し、事前通話テストを実行するために使用します。これにより、ライブ・セッションとは別にセットアップを行うことができ、参加者がセッションに参加する際の初期混乱が軽減されます。この ウェブ参照アプリ また、参加前にデバイスのプレビューやセットアップを行うためのウェイティングルームも用意されている。
待合室UI
待合室には以下のようなものがある：
- ローカルカメラのプレビュー、
- マイク動作インジケーター、
- カメラとマイクのセレクター、
- 許可状態と拒否状態のメッセージを消去する、
- 通話前テストのステータスまたは進行状況を示すインジケータ、
- 目に見えるジョイン準備状態、
- 通話前テストの再試行アクション。
以下のいずれかが発生したら、再度テストを実行する：
- ユーザーはカメラやマイクを変更する、
- ユーザーのネットワークが変わる、
- 一旦拒否されたカメラやマイクの許可が再び許可される、
- ユーザーが明示的に再試行を要求した、
- テスト完了から合流までにかなりの時間がかかる。
ホストまたは司会者のパターン
製品にホスト、司会者、発表者の役割がある場合、参加者はホストがライブセッションを開始する準備ができるまで、控え室にとどまることができます。少人数や司会進行のアプリケーションでは、参加者はホストが公開する前にセッションに参加し、ホストの準備ができるまで、接続されたまま公開しないことができます。接続されているが公開されないというアプローチは、一般的な推奨や Video API プラットフォームの要件ではなく、規模のトレードオフを伴うオプションのアプリケーションレベルのパターンとして扱ってください。大規模な視聴者の場合、多くの参加者を事前に接続しておくことで、ホストが公開を開始したときにサブスクリプションが急増します。そのため 待合室サンプルアプリ記事 はその実装例を示している。
ネットワークテストの実行
Vonage Video Networkテストライブラリを使用して、ユーザーがセッションに参加する前に、クライアントがオーディオとビデオの公開をサポートできるかどうかを確認します。
アプリケーションが設定可能なTURNまたはIPプロキシ設定を使用する場合は、対応する iceConfig または proxyServerUrl の値もネットワークテストに加える。
接続性チェック
走る NetworkTest.testConnectivity() 品質テストの前に。
このチェックは、クライアントが Video API セッションに必要なサービスに到達できるかどうかを検証する：
- API リーチャビリティーである、
- メッセージング／シグナリング WebSocket リーチャビリティーである、
- メディア・ルーター リーチャビリティーである、
- ロギングサーバー リーチャビリティーである。
これらの結果は、アプリケーションが使用するセッションモードに基づいて解釈してください：
- もし
apiまたはmessagingチェックに失敗すると、クライアントは必要なセッション接続を確立できません。 - もし
mediaチェックに失敗した場合、ルートされたセッションは成功しない。リレーされたセッションは成功するかもしれないが、TURNが必要な場合には失敗する可能性がある。 - もし
loggingチェックに失敗しても、クライアントは接続できますが、Vonage は、Inspector などのツールで使用される通常のロギング・データを収集しません。
品質チェック
接続の結果があなたのユースケースで許容できるものであれば、以下を実行する。 NetworkTest.testQuality()をテストする：
- オーディオ対応、
- ビデオ対応、
- オーディオとビデオのビットレート、
- オーディオとビデオのパケットロス率、
- 推奨される発行解像度、
- 推奨パブリッシュフレームレート、
qualityLimitationReason値を持つbandwidth,cpuあるいはnull.
注： テストは、デフォルトではオーディオ・ビデオモードで実行され、必要であればオーディオのみのモードで継続することもできる。
タイムアウトテスト
について timeout オプション testQuality() を超える値を受け付ける。 5000 ミリ秒以下 30000 ms。設定しない場合、テストは約 秒間実行される：
- オーディオ・ビデオ・テストでは30秒、
- 音声のみのテストでは10秒。
タイムアウトが短いと結果の精度が落ちる。
ブラウザサポート
testQuality() はFirefoxではサポートされていません。その場合は、許可とデバイスのセットアップのために待合室を使用し、次のものに頼ってください。 testConnectivity() それでも接続性だけの通話前チェックを望むなら。
制限付きネットワーク
制限されたネットワークでは、文書化されたネットワーク要件に従ってください：
- UDPが使用できる環境が望ましい
3478およびTCP443が利用できる。 - 最良のセットアップ時間とメディア品質のために、アウトバウンドUDPも許可してください。
1025-65535メディアICEおよびSRTP用。 - もしTCP
443が利用可能な場合、セッションは接続されるかもしれないが、セットアップが遅くなり、メディア品質が低下する可能性が高くなる。 - プロキシが存在する場合、それは透過的であるか、HTTPS接続用に設定されているべきである。
企業や制限されたネットワークでは、同じように必要なポートとプロトコルをVerifyし、ユーザーが参加する前に接続テストを再実行してください。
より制限の多い環境については、こちらを参照のこと：
通話前の推奨ステータス
| ステータス | こんなときに使う | 次にすべきこと |
|---|---|---|
Pass | アプリケーションが使用するセッションモードで接続が成功し、必要なメディアがサポートされ、パケットロスが3%未満で、ビットレートが最小しきい値（ビデオ150 kbps以上、オーディオ25 kbps以上）を超え、推奨パブリッシュ設定が通話に許容される。 | ユーザーを参加させる。パブリッシャの初期化時に、推奨されるパブリッシュ解像度とフレーム・レートを適用します。 |
Warn | logging 接続チェックに唯一失敗した場合、パケットロスが3～5%ある場合、ビットレートが低いが回復可能な場合、推奨パブリッシュ解像度またはフレームレートが低下している場合。 qualityLimitationReason は bandwidth または cpu. | 控室で理由を表示し、ユーザーに再試行させ、推奨されるパブリッシュ設定を適用する。必要であれば、ユーザーに明確な警告を表示して続行を許可してください。 |
Fail | api または messaging は失敗した、 media アプリケーションに必要なセッションモードに失敗する、必要なオーディオまたはビデオがサポートされていない、許可またはデバイスの取得が不完全である、パケットロスが5%を超える、ビットレートが重要なしきい値を下回る（ビデオ150kbps未満、オーディオ25kbps未満）。 | ユーザーをまだ参加させない。待合室で問題を表示し、解決後に再試行するようユーザーに促します。オーディオはサポートされているがビデオはサポートされていない場合、オーディオのみの参加を提供することができます。 |
ステータスが Warn または Failそして、そのトリガーとなったシグナルを使って、次に何をすべきかを決める：
- もし問題が
bandwidthより強力な、または制限の少ないネットワークで再試行するようユーザーに求めるか、パブリッシュの設定を下げて続行する。 - もし問題が
cpuそのため、ユーザーに要求の多いアプリケーションを終了し、高価なエフェクトを無効にして再試行するよう求める。 - もし問題が
loggingのみを使用する場合、ユーザは接続できますが、通常のインスペクタのデータは減少します。 - ブラウザがFirefoxの場合、許可とデバイスのセットアップのために待合室を使用し、そして
testConnectivity()接続性のみの事前通話チェックが必要な場合。
ネットワーク・テスト結果の解釈
プレコール・ステータスを設定する際は、チェックすること：
- サポート対非サポート、
- コネクティビティの成果、
- パケットロス率（3%未満は許容範囲、3～5%は要注意、5%以上は障害）、
- ビットレートレベル（ビデオ≧150kbps、オーディオ≧25kbpsが最低許容閾値）、
- 推奨公開解像度とフレームレート、
qualityLimitationReason.
ラウンドトリップタイム、フリーズカウント、生のRTC統計などの低レベルの診断が必要な場合は、Client Observabilityまたは生のWebRTC統計レポートを使用してください。
インコール品質シグナル
ユーザーの加入後：
- 用途
qualityScoreChanged通話中整数で加入者の品質を追跡する1-5の規模である、 - 用途
cpuPerformanceChangedウェブクライアントでデバイスの圧力に反応する、 - 基本的な通話前のチェックよりも詳細な情報が必要な場合は、Client Observabilityのパブリッシャーとサブスクライバーの品質イベントを使用してください。
詳細なウェブガイダンスについては、以下を参照のこと。 クライアントの観測可能性：ウェブ.
参加後に続ける
ユーザーが参加したら、次のように続ける：
- クライアントの観測可能性 現在進行中のストリーム・メトリクスのために、
- 購読する品質と適応 加入者の品質監視と再接続処理のため、
- スケーラブルなビデオ マルチパーティストリーム適応のために、
- オーディオ・フォールバック デグレード・ネットワークの挙動について、
- セッション ルーティングされた動作とリレーされた動作とでプレコールロジックを整合させる、
- セッション・インスペクター 呼び出し後の検証とデバッグのために。
サブスクライバー・オーディオ・フォールバックには、ルーティングされたセッションが必要です。パブリッシャー・オーディオ・フォールバックは、ルーティングされたセッションとリレーされたセッションの両方で使用できます。