2人での通話はシンプルです。一方の端末がもう一方の端末に音声やビデオを送り、双方がリアルタイムでメディアを交換します。3人目、4人目、あるいは100人目の参加者が加わると状況は変わります。システムは、メディアのミキシング、ルーティング、エンコード、同期、録音、セキュリティ、制御の方法を決定しなければなりません。これが、多人数通信が単なるユーザー向けの通話機能ではなく、メディアアーキテクチャの問題でもある理由です。

この機能に対する需要は、オフィスの会議室から、クラウド会議、コンタクトセンター、緊急指令、遠隔医療、オンライン教育、配車調整、遠隔保守、エンタープライズコラボレーション、そしてモバイルファーストな働き方へと広がっています。ユーザーは、ワンクリックでの参加、クリアな音声、安定したビデオ、画面共有、ホスト制御、録画、そして電話、ブラウザ、アプリ、SIPデバイス間での互換性を期待します。そのシンプルな体験の裏側で、プラットフォームは参加規模、品質、遅延、デバイスリソース、ネットワーク状況、コストのバランスを取らなければなりません。

シンプルな会議機能からコミュニケーションインフラへ

初期の企業電話システムでは、グループ通話はしばしば会議ブリッジ機能として扱われていました。PBX、ハードウェアブリッジ、またはサービス番号を通じて、数人のユーザーが同じ音声セッションに参加できました。主な焦点は音声ミキシングと通話制御でした。

現代の導入形態はより広範です。会議には、PSTNダイヤルインユーザー、SIP電話、ブラウザクライアント、モバイルアプリ、会議室システム、リモートワーカー、ゲスト、スーパーバイザー、録音サービスが含まれる場合があります。また、ビデオレイアウト、画面共有、ライブキャプション、チャット、本人確認、待機室、ホスト権限、カレンダーやワークフロープラットフォームとの統合も必要になることがあります。

この変化が、参加者の上限がなぜこれほど大きく異なるのかを説明しています。卓上電話は小規模なローカル会議をサポートできるかもしれません。PBXブリッジは数十人をサポートするかもしれません。クラウド会議プラットフォームは、ユーザーがインタラクティブな参加者なのか、聴講のみの出席者なのか、ウェビナー視聴者なのか、ブロードキャスト受信者なのかによって、数百人または数千人をサポートするかもしれません。

実際に参加者数を制限するものは何か？

参加者の上限は、一度に複数の層によって形成されます。第1層はメディア処理です。システムが音声をミックスしたり、ビデオを中央でトランスコードしたりする場合、サーバーは多数のメディアストリームを処理する必要があります。第2層は帯域幅です。各参加者は、音声、ビデオ、または共有コンテンツを送受信する可能性があります。第3層はシグナリングと制御です。参加、退出、ミュート、レイアウト変更、録音、ロール制御はすべてシステムイベントを発生させます。

第4層はエンドポイントの能力です。小型の組み込み端末、卓上電話、ブラウザタブ、モバイルデバイス、会議室アプライアンスでは、CPU、メモリ、マイク、スピーカー、カメラ、コーデックの能力が異なります。第5層はサービスポリシーです。ベンダーや管理者は、ライセンス、会議タイプ、セキュリティレベル、品質プロファイル、またはサブスクリプションプランによって参加者数を制限する場合があります。

この理由から、製品ドキュメントに表示されている数値が、設計に使用すべき数値であるとは限りません。プラットフォームが技術的には200人の参加者を許可できても、特定のネットワーク条件下では、録画と画面共有を伴う高品質なインタラクティブビデオの実用的な上限は低くなる可能性があります。

音声のみのセッション

音声のみのグループ通話は、ビットレートと処理負荷が低いため、一般的にビデオ通話よりも多くの参加者をサポートします。音声ミキシングでは、複数の話者を各リスナー向けの単一ストリームに結合したり、システムがアクティブスピーカーを選択して背景ノイズを抑制したりできます。

しかし、音声セッションにも限界はあります。エコー、ノイズ、会話の重複、パケットの遅延到着、コーデックの不一致、不適切なマイクの使用は、グループが大きくなるにつれてより顕著になります。適切に管理された10人の話者がいる会議は、騒がしい場所にいるミュート解除された50人の参加者がいる会議よりも良好に聞こえる場合があります。

大規模な音声会議では、全員ミュート、挙手、発言キュー、聴講のみモード、および司会進行などのホスト制御が重要です。技術的な限界は、実際の参加者制限の一部にすぎません。人間の会話管理も同様に重要です。

ビデオセッション

ビデオはさらに複雑さを増します。各参加者はカメラ映像を送信し、1つ以上のビデオストリームを受信する可能性があります。システムが各参加者の完全なビデオを他のすべての参加者に送信すると、帯域幅と処理要件が急速に増大します。そのため、最新のシステムでは、選択的転送、アクティブスピーカー切り替え、サイマルキャスト、スケーラブルビデオコーディング、レイアウト最適化、および適応ビットレート制御を使用します。

参加者数は、カメラの解像度、フレームレート、コーデック効率、ネットワーク品質、エンドポイントのCPU、サーバーアーキテクチャ、およびレイアウト要件によって異なります。多数のビデオタイルを表示するギャラリービューは、アクティブスピーカーのみが表示されるセッションよりも要求が厳しくなります。

ビデオ会議では、より強力なユーザーエクスペリエンスデザインも必要です。何百人ものユーザーが参加する場合、ほとんどのユーザーは継続的にカメラ映像を送信すべきではありません。大規模なイベントでは、多くの場合、品質と制御を維持するために、スピーカー、パネリスト、モデレーター、視聴者を分離します。

ブリッジベースの実装

会議ブリッジは、参加者からメディアを受信し、ミックスまたは選択されたメディアを送り返す中央ポイントです。従来の電話では、ブリッジはしばしば音声ストリームをミックスして、各参加者がグループの声を聞けるようにします。エンタープライズPBXシステムでは、これはサーバーに組み込まれているか、専用の会議モジュールによって提供されます。

ブリッジモデルは理解しやすく、音声に適しています。ブリッジは、誰が会議に参加しているか、誰がミュートされているか、誰が話しているか、そして音声がどのように合成されるかを管理します。また、録音、アナウンス、PIN入力、ダイヤルインアクセスもサポートします。

課題はスケーラビリティです。より多くの参加者が参加するにつれて、ブリッジはより多くのメディアを処理する必要があります。ビデオも中央でミックスされる場合、リソースコストは急激に上昇します。大規模な展開では、分散メディアサーバーまたはクラウドスケーリングが必要になる場合があります。

PBXおよびSIPベースの方法

多くのエンタープライズシステムは、SIPシグナリングを使用して通話を確立および管理します。多人数セッションは、エンドポイント上のローカル会議機能、PBXホスト型会議室、アドホック通話マージ、会議用内線番号、またはSIPアプリケーションサーバーを通じて作成できます。

ローカルエンドポイント会議はシンプルですが、電話機またはソフトフォンが複数の通話レッグを処理しなければならないため制限があります。PBXホスト型会議は、サーバーがメディアを管理するため、よりスケーラブルです。会議室番号を使用すると、ユーザーは共有スペースにダイヤルインできます。アドホック会議機能を使用すると、ユーザーはアクティブな通話中に参加者を追加できます。

SIPベースの実装では、シグナリングを正しく処理する必要があります。保留、re-INVITE、REFER、会議フォーカス、メディアネゴシエーション、コーデックサポート、DTMF、アーリーメディア、および録音はすべて、最終的なエクスペリエンスに影響を与える可能性があります。電話機、PBXシステム、ゲートウェイ、およびトランクが異なるベンダーのものである場合、相互運用性テストが重要です。

MCUアーキテクチャ

多地点制御装置（MCU）は、参加者から音声とビデオを受信し、ストリームをデコード、ミキシングまたは合成し、処理されたストリームを各参加者に送り返します。このアプローチは、レイアウトとメディア形式に対する強力な中央制御を提供します。

MCUアーキテクチャは、エンドポイントの能力が限られている場合や、一貫したビデオレイアウトが必要な場合に役立ちます。サーバーは各参加者に対して単一の合成ビデオストリームを作成できるため、エンドポイントの複雑さが軽減されます。

欠点は、サーバーリソースの消費です。多数のユーザー向けにビデオのデコード、ミキシング、再エンコードを行うには、かなりのCPUまたはハードウェアアクセラレーションが必要です。非常に大規模な会議の場合、慎重にスケーリングしない限り、純粋なMCU設計はコストが高くなる可能性があります。

SFUアーキテクチャ

選択的転送ユニット（SFU）は、メディアストリームを受信し、すべてのストリームを完全にミキシングおよび再エンコードすることなく、選択されたストリームを参加者に転送します。これは、完全なビデオミキシングよりも効率的にスケーリングできるため、WebRTCベースの会議プラットフォームで一般的です。

SFUは、アクティブスピーカー、レイアウト、帯域幅、サブスクリプション要求、デバイス能力、またはネットワーク状況に基づいて、送信するストリームを選択できます。サイマルキャストまたはスケーラブルビデオコーディングが使用されている場合、異なる参加者に異なる品質レイヤーを転送できます。

利点は、完全なビデオ合成と比較して、スケーラビリティとサーバー処理の低減です。トレードオフは、エンドポイントが複数のストリームをデコードし、ローカルでレイアウトを処理する必要があるかもしれないことです。表示されるビデオストリームが多すぎると、低電力デバイスにとって負荷が高くなる可能性があります。

クラウド会議プラットフォーム

クラウドプラットフォームは、メディアリソースを動的にスケーリングし、異なるネットワークからのユーザーを接続し、ブラウザまたはアプリベースのアクセスをサポートできるため、主要な方向性となっています。多くの場合、シグナリングサービス、メディアルーティング、録音、ID管理、チャット、カレンダー統合、分析、および管理ポータルを組み合わせています。

クラウドシステムは通常、より広範な会議タイプをサポートします。小規模なチーム会議は完全にインタラクティブにすることができます。トレーニングセッションでは、限られたスピーカーと多数の視聴者を許可できます。ウェビナーでは、ホスト、パネリスト、および出席者の役割を分離できます。ブロードキャストでは、視聴者を同等の会議参加者として扱うのではなく、ストリーミングインフラストラクチャに移動させる場合があります。

この区別は重要です。プラットフォームは何千人もの視聴者をサポートするかもしれませんが、それは何千人もの完全にインタラクティブな音声・ビデオ参加者を意味するわけではありません。インタラクティブ容量とオーディエンス容量は別々に評価する必要があります。

参加者制限のカテゴリ

コーデックとメディア品質

コーデックの選択は、容量と品質に影響します。効率的なコーデックは、許容可能な音声またはビデオ品質を維持しながら帯域幅を削減します。ただし、コーデックのサポートは、エンドポイントとサーバー間で一貫している必要があります。トランスコーディングは互換性の問題を解決できますが、サーバーの負荷と遅延を増加させます。

音声の場合、明瞭度は通常、高忠実度よりも重要です。エコーキャンセレーション、ノイズ抑制、パケット損失隠蔽、およびゲイン制御は、ユーザーエクスペリエンスに強く影響する可能性があります。ビデオの場合、解像度とフレームレートは会議の目的に合わせる必要があります。対面でのディスカッションには、設計レビューや医療相談と同じビデオプロファイルは必要ないかもしれません。

可能な場合、品質設定は適応型であるべきです。ネットワーク状況は、特にリモートユーザー、モバイルユーザー、および輻輳したWi-Fiまたはセルラーネットワークの背後にいる参加者にとって異なります。

帯域幅計画

大規模なセッションには帯域幅計画が不可欠です。各参加者は、メディアを送信するのに十分な上り帯域幅と、メディアを受信するのに十分な下り帯域幅を必要とします。必要量は、音声のみかビデオモードか、解像度、画面共有、可視ストリーム数、コーデック、および適応ビットレート動作によって異なります。

オフィスネットワークでは、集約トラフィックを考慮する必要があります。同じオフィスから10人のユーザーがクラウド会議に参加すると、予想以上のインターネット負荷が発生する可能性があります。会議室システムは、同じ部屋にある多数の個別のラップトップよりも少ない集約帯域幅しか消費しない場合があります。

重要な環境では、ネットワークチームはQoS、トラフィック監視、ファイアウォール容量計画、およびバックアップリンクを使用する必要があります。多人数セッションは、会議プラットフォームが弱いためではなく、ローカルネットワークパスが輻輳しているために失敗する可能性があります。

遅延と会話の流れ

遅延は、会話の自然さに影響します。小規模なインタラクティブ通話では、高い遅延は人々が互いに話し合う原因となります。スピーカーが制御された大規模な会議では、わずかに高い遅延は許容される場合があります。緊急オペレーション、配車調整、または技術トラブルシューティングでは、遅延は指令効率を低下させる可能性があります。

メディアパス設計は遅延に影響します。直接ピアツーピアメディアは小グループでは低遅延かもしれませんが、拡張が難しくなります。中央メディアサーバーはルーティング制御を追加しますが、追加の遅延をもたらす可能性があります。クラウドリージョン、VPNパス、衛星リンク、およびトランスコーディングも遅延を増加させる可能性があります。

設計者は、可能な限りユーザーの近くにメディアリソースを配置し、遠くのネットワークを介した不必要なメディアヘアピニングを避けるべきです。

ロール制御と会議ガバナンス

参加者数が増えるにつれて、ガバナンスはメディアテクノロジーと同じくらい重要になります。ホスト、共同ホスト、モデレーター、プレゼンター、出席者、リスナー、スーパーバイザーのロールが、各参加者が何をできるかを定義します。

全員ミュート、会議のロック、待機室、参加者の承認、参加者の削除、カメラの無効化、画面共有の制御、プレゼンターの割り当て、質問の管理などの機能は、大規模セッションの品質を保護します。これらの制御がない場合、ネットワークとサーバーの容量が十分であっても、大規模な会議は混乱する可能性があります。

エンタープライズおよびパブリックシナリオでは、ロール設計をポリシーの一部にする必要があります。すべての参加者が、いつでも他のユーザーを招待したり、録音したり、画面を共有したり、ミュートを解除したりする権限を持つべきではありません。

セキュリティとプライバシー

グループコミュニケーションは、アクセスが制御されていない場合、機密情報を露出させる可能性があります。会議リンク、ダイヤルインPIN、ゲストアクセス、録音権限、画面共有、チャットログ、参加者の身元はすべて注意が必要です。

セキュリティ対策には、認証された参加、待機室、ホスト承認、暗号化されたメディア、制限されたダイヤルイン、ドメインベースのアクセス、会議パスワード、ロールベースの制御、監査ログ、録音アクセス制限が含まれる場合があります。

プライバシーも重要です。大規模なセッションには、顧客、パートナー、従業員、請負業者、または一般の参加者が含まれる場合があります。プラットフォームは、録音、文字起こし、参加者の可視性に関するルールを明確にする必要があります。

録音とコンプライアンス

録音は、トレーニング、カスタマーサポート、ヘルスケア、公共サービス、法務、金融、緊急調整で一般的です。システムは、音声、ビデオ、画面共有、チャット、参加者リスト、タイムスタンプ、ホストアクションを記録する場合があります。

大規模セッションの録音には、ストレージ計画と保持ポリシーが必要です。また、明確な同意とアクセス制御も必要です。会議の録音には、公に共有したり無期限に保存したりすべきではない機密情報が含まれている可能性があります。

実装の観点からは、録音はローカル、サーバー側、またはクラウドベースで行うことができます。サーバー側の録音は標準化が容易ですが、ローカル録音はユーザーの行動やデバイス設定に依存する可能性があります。

ビジネスシステムとの統合

現代のグループ通話は、多くの場合、カレンダー、顧客関係管理、チケット発行ツール、学習プラットフォーム、配車システム、ヘルスケアシステム、およびワークフローアプリケーションと統合されています。統合により手動ステップが削減され、ユーザーが正しいコンテキストで正しいセッションに参加しやすくなります。

例えば、サポートエスカレーションでは、顧客、サポートエンジニア、スーパーバイザーとの会議を作成できます。遠隔医療の予約では、患者、医師、通訳者をつなぐことができます。現場保守インシデントでは、制御室スタッフ、リモートエキスパート、現場技術者を集めることができます。

統合はセキュリティを維持する必要があります。自動生成された会議リンクは、許可されていないユーザーに公開されるべきではありません。会議記録は、個人情報を漏洩させることなく、ビジネス記録と一致する必要があります。

エンタープライズコラボレーションでの利用

エンタープライズコラボレーションは、最も強力なユースケースの1つです。チームは、日次会議、プロジェクトレビュー、トレーニング、面接、管理職コミュニケーション、支店間調整にグループ通話を使用します。

主な設計要件は利便性です。ユーザーは、迅速な参加、連絡先ディレクトリへのアクセス、カレンダースケジューリング、画面共有、録音、安定した音声を期待します。参加者制限は、まれな最大規模のイベントだけでなく、典型的な会議タイプに合わせるべきです。

組織は会議文化も定義する必要があります。優れたテクノロジーは、不十分なマイクの使用、不明確な議題、不要な出席者、制御されていない画面共有を完全に補うことはできません。

コンタクトセンターとサポートでの利用

サポート環境では、エスカレーション、スーパーバイザー支援、専門家相談、顧客引き継ぎ、技術トラブルシューティングに多人数セッションを使用します。最前線のエージェントは、通話を続けながら専門家を呼び入れて、状況を保持することができます。

このシナリオでの参加者制限は通常控えめですが、制御と録音が重要です。システムは、誰が参加したか、いつ参加したか、顧客が保留にされたかどうか、やり取りが録音されたかどうかを示す必要があります。

高品質なサポートのために、プラットフォームは参加を高速にする必要があります。エージェントが別の担当者を追加しようとしている間、顧客が長時間待たされるべきではありません。

ヘルスケアと遠隔相談での利用

ヘルスケアコミュニケーションには、医師、看護師、専門家、患者、家族、通訳者、管理スタッフが関わる場合があります。グループ通話は、遠隔相談、トリアージ、症例検討、ケア調整、フォローアップをサポートできます。

セキュリティとプライバシーの要件は特に重要です。アクセス制御、録音ポリシー、参加者の身元、同意、データ処理は慎重に設計する必要があります。

ビデオ品質は一部の医療コンテキストでより重要になる場合がありますが、他のコンテキストでは音声の明瞭さと信頼性で十分な場合があります。参加者制限の計画は、一般的な会議容量だけでなく、臨床ワークフローに従うべきです。

教育とトレーニングでの利用

教育とトレーニングのシナリオには、インストラクター、学生、ゲストスピーカー、モデレーター、オブザーバーが関わる場合があります。グループセッションには、講義モード、ディスカッションモード、ブレイクアウトセッション、画面共有、投票、録画されたレッスンが含まれる場合があります。

参加者制限は、指導スタイルによって異なります。小規模なセミナーにはインタラクティブな参加が必要です。大規模な講義には、制御された発言とコンテンツ配信が必要です。公開ウェビナーには、オープンな会話ではなく、出席者管理とQ&Aが必要です。

プラットフォームは、インストラクターが発言権、録音、画面共有、参加者の行動を管理できるように、ロール分離をサポートする必要があります。

緊急時および現場オペレーションでの利用

緊急対応、輸送、公益事業、産業保守、現場オペレーションでは、多くの場合、迅速な多人数調整が必要です。セッションには、制御室スタッフ、現場作業員、監督者、遠隔専門家、外部機関が含まれる場合があります。

設計の優先事項は、信頼性と明瞭さです。参加者は、モバイルネットワーク、無線ゲートウェイ、指令コンソール、衛星リンク、または堅牢なデバイスから参加する可能性があります。システムは、迅速な参加、優先ユーザー、録音、およびフォールバックパスをサポートする必要があります。

これらのシナリオでは、実用的な参加者制限は、現実的なネットワーク条件下でテストする必要があります。オフィスでうまく機能するプラットフォームは、被災地や遠隔地では異なる動作をする可能性があります。

PSTN、SIP、WebRTCハイブリッドアクセス

多くの導入では、混合アクセスが必要です。一部のユーザーはPSTNまたはSIPを介して電話から参加します。他のユーザーはWebRTCを介してブラウザから参加します。モバイルアプリや会議室システムを使用するユーザーもいます。混合アーキテクチャはアクセシビリティを向上させますが、複雑さも増加させます。

音声レベル、コーデック互換性、DTMFサポート、発信者ID、ミュート制御、録音、および転送動作は、アクセス方法によって異なる場合があります。PSTNユーザーは、アプリユーザーと同じインタラクティブコントロールをサポートしない可能性があります。ブラウザユーザーは、マイクとカメラのローカル権限に依存する場合があります。

実装では、各アクセスタイプが何を実行できるかを定義する必要があります。すべての参加者が同じクライアント能力を持っていなくても、会議は使用可能であるべきです。

ローカル、プライベート、クラウド展開

ローカル展開は、データ、ネットワークパス、および内部システムとの統合をより詳細に制御できます。プライベートネットワーク、規制対象環境、制御室、またはインターネットアクセスが制限されているサイトに適している場合があります。ただし、サーバー容量、メンテナンス、冗長性、アップグレード、および熟練した管理が必要です。

クラウド展開は、より簡単なスケーリング、外部アクセス、より迅速な機能更新、およびローカルインフラストラクチャの負担軽減を提供します。分散した組織や公共インターネット参加に適しています。ただし、プロバイダーの可用性、インターネット到達可能性、データポリシー、およびサブスクリプションモデルに依存します。

プライベートクラウドまたはハイブリッド展開は、両方のアプローチを組み合わせることができます。機密性の高い内部トラフィックは制御されたまま、外部ユーザーは管理されたアクセスポイントを通じて参加できます。

実装チェックリスト

まず、会議タイプを定義します。小規模なインタラクティブ通話、サポートエスカレーション、トレーニングセッション、ウェビナー、緊急調整、役員会議にはそれぞれ異なる要件があります。

次に、各タイプの目標参加者数を定義します。すべてのシナリオに単一の最大数を使用することは避けてください。アクティブスピーカー、ビデオ参加者、聴講のみの出席者、ダイヤルインユーザー、視聴者を分けて考えてください。

次に、メディアアーキテクチャを計画します。システムがPBXブリッジ、MCU、SFU、クラウドメディアサービス、ローカルサーバー、またはハイブリッドルーティングのいずれを使用するかを決定します。音声およびビデオコーデック、録音、画面共有、ホスト制御、およびセキュリティモデルを確認します。

最後に、現実的な条件下でテストします。低帯域幅のユーザー、モバイルユーザー、VPNユーザー、外部ゲスト、PSTNダイヤルイン、録音、画面共有、および高い参加者数を含めます。少数のオフィスユーザーだけでテストしても、大規模セッションの準備ができていることを証明することにはなりません。

よくある設計ミス

1つの間違いは、出席者数とインタラクティブ参加者数を混同することです。プラットフォームは多くの視聴者をサポートするかもしれませんが、ビデオ付きのアクティブスピーカーははるかに少ない場合があります。

別の間違いは、ローカルネットワーク容量を無視することです。クラウドサービスが強力でも、ブランチオフィスのインターネットリンクが多数の同時ビデオユーザーをサポートできない場合があります。

3つ目の間違いは、会議を管理されていない状態にしておくことです。ホスト制御がないと、大規模な通話は、開いたマイク、背景ノイズ、偶発的な画面共有、および不正アクセスに悩まされる可能性があります。

4つ目の間違いは、すべてのエンドポイントが同じように動作すると想定することです。電話機、ブラウザ、モバイルアプリ、SIP会議室システム、PSTN参加者は、異なる機能をサポートする場合があります。

5つ目の間違いは、使用前に録音と保持のルールを定義しないことです。適切に管理されていない場合、録音はコンプライアンスとプライバシーのリスクを生み出す可能性があります。

業界トレンドの見通し

業界は、より統合された柔軟なグループコミュニケーションへと向かっています。WebRTCはブラウザベースの参加を容易にします。クラウドメディアプラットフォームはスケーリングをよりアクセスしやすくします。文字起こし、要約、ノイズ抑制、話者識別、翻訳、会議分析のためにAI機能が追加されています。

同時に、組織はセキュリティ、データ主権、相互運用性、ユーザーエクスペリエンスにより注意を払っています。未来は単により大規模な会議だけではありません。よりスマートなセッション制御、より優れたメディア適応、ビジネスワークフローとのより緊密な統合です。

最も実用的な方向性は、シナリオベースの設計です。組織は、単に何人参加できるかだけを問うのではなく、誰が話す必要があるか、誰が聞くだけでよいか、どのような品質が必要か、どのセキュリティポリシーが適用されるか、そしてそのセッションが実際の作業プロセスをどのようにサポートするかを問うべきです。

多人数通話は、単一の宣伝されている最大数ではなく、メディアアーキテクチャ、ネットワーク容量、エンドポイント能力、会議ロール設計、および実際のコミュニケーション目的に従って参加者制限が計画されたときに最も効果的に機能します。

よくある質問 (FAQ)

なぜ通常、音声はビデオよりもスケーラビリティが高いのですか？

音声はビデオよりもはるかに少ない帯域幅と処理能力しか必要としません。ビデオは、特に多くのカメラがアクティブな場合、より多くのエンコード、デコード、レイアウト制御、下り帯域幅を必要とします。

PSTNユーザーはアプリユーザーと同じセッションに参加できますか？

はい、プラットフォームがダイヤルインまたはゲートウェイアクセスをサポートしている場合に可能です。ただし、PSTNユーザーは、アプリやブラウザユーザーと比較して、制御機能が少なく、音声動作が異なる場合があります。

多くの人がカメラをオンにすると品質が低下するのはなぜですか？

より多くのアクティブビデオストリームは、帯域幅、サーバールーティング負荷、およびエンドポイントのデコード作業を増加させます。システムは、解像度を下げたり、フレームレートを下げたり、アクティブスピーカーモードに切り替えたりする場合があります。

ウェビナーはインタラクティブ会議と同じですか？

いいえ。ウェビナーは通常、スピーカーと視聴者を分離します。これにより、ほとんどの出席者が継続的に音声やビデオを送信しないため、より大きな視聴者規模が可能になります。

大規模セッションの前に何をテストすべきですか？

参加方法、ホスト制御、ミュート動作、録音、画面共有、ダイヤルインアクセス、帯域幅使用量、外部ゲストアクセス、および予想される参加者数でのパフォーマンスをテストします。