[本体サーバの最小要件 (BigBluneButton + GreenLight / Docker)]
・OS:Ubuntu 16.04 64-bit(Linux kernel 4.x、root 権限必須)
・CPU:4コア(8コア推薦)
・メモリ:8GB[swap有効](16GBメモリ推薦)
・利用TCPポート:80 & 443 (80は他のアプリケーションで利用されていない事)
・利用UDPポート:16384 - 32768
・最小帯域幅:1Gbps (対称)
追加の推奨環境
・専用ハードウェア(ベアメタル)
・録画用の500GB以上のフリースペース
・250Mbps 以上の転送速度 (対称)
・SSL証明書のセットアップ用のホスト名
・IPV4 と IPV6 アドレス
[参考:Amazon EC2の場合]
- c5.xlarge インスタンス(またはそれ以上のCPUインスタンス)
・モデル:c5.xlarge
・vCPU:4
・メモリ(GB):8
・インスタンスストレージ(GB):EBSのみ
・ネットワーク帯域幅(GB/S):最大10
・EBS帯域幅(MB/S):最大4750
[TURN サーバが必要とされる環境と要件]
サーバにグローバルIPアドレスをアサインできない場合(NAT利用)または、UDP接続を制限するファイアウォールがある場合は、TURNサーバが必要となります。
(TURN:Traversal Using Relays around NAT)プロトコル
TURNサーバの最小要件
・OS:Ubuntu 16.04 64-bit(Linux kernel 4.x、root 権限必須)
・CPU:4コア
・メモリ:8GB
・利用TCPポート:80 & 443 (80は他のアプリケーションで利用されていない事)
・利用UDPポート:16384 - 32768
・最小帯域幅:1Gbps (対称)
[本体サーバ帯域幅の要件の説明]
モデレーターとしてウェブカメラを共有する場合、320x240、640x480、または1280x720が選択可能です。
各解像度で、約 0.25 Mbit/sec、0.40 Mbit/sec、および0.60 Mbit/sec のビデオストリームが必要とされます。
Y = 0.25 Mbit/sec (320x240)
W =ストリーミングしているWebカメラの数
U =視聴しているユーザーの数
計算式:
サーバーの受信帯域幅:W * Y
サーバーの発信帯域幅:W *(U-1)* Y
(ブロードキャスターは自分のストリームにサブスクライブする必要がないため、マイナス1)
たとえば、5人のユーザーが1つの部屋に5台のウェブカメラでストリーミングしている場合、帯域幅の計算は次のようになります。
サーバーの受信帯域幅:1.25 Mbit/sec (5 * 0.25 / 1時間あたり 4.5 Gbit/sec)
サーバーの発信帯域幅:1 Mbit/sec ((5-1)* 0.25 / 1時間あたり 3.6 Gbit/sec)
スライドの共有には、最初のスライドのアップロード/ダウンロード以外の帯域幅はほとんど必要ありません。発表者がクリックして次のスライドを表示すると、視聴者はクライアントで「次のスライドを移動」コマンドを受け取り、ローカルキャッシュから次のスライドをロードします。チャットも帯域幅をほとんど消費しません。
画面共有の場合は、ほとんどの帯域幅を使用します。デスクトップ共有時の実際の帯域幅は、発表者が選択した領域のサイズ(全画面 / 領域)と画面の更新頻度によって異なります。ローエンドでは、発表者の画面がほとんどアイドル状態の場合、画面共有アプリケーションは約0.2 Mbit/sec を送信します。ハイエンドでは、プレゼンターの画面が頻繁に更新される場合、サーバーは 1.0Mbit/sec を送信する可能性があります。 N人のユーザーとのセッションの場合、サーバーはN個のデスクトップ共有ストリームを送信します。(発表者にも画面共有プレビューウィンドウストリームを配信します)
サーバーへのVoIP接続では、ユーザーごとに約0.04 Mbit/sec の受信と0.04 Mbit/sec の送信が必要とされます。VoIPの帯域幅は、ユーザー数に比例して増加します。たとえば、教室に20人の生徒がいる場合、サーバーがVoIPをサポトするための帯域幅の要件は、20 * 0.04 Mbit/sec = 0.8 Mbit/sec となります。ユーザーが聴講のみとして参加すると、オーディオのみを受信します。
ユーザーの帯域幅のニーズの観点からすると、学生がWebカメラとマイクをブロードキャストしている場合、0.3 Mbit/sec (0.25 + 0.04)以上のアップストリーム帯域幅が必要です。生徒が他の4人と一緒にセッションを行っており、全員がウェブカメラもブロードキャストしている場合、生徒は、4 * 0.25 = 1 Mbit/sec のWebカメラ用に受信帯域幅、着信オーディオ用に約0.04 Mbit/sec の受信帯域幅を必要とします。
サーバーは、帯域幅がすべてのストリームを受信するのに不十分である場合、ユーザーの帯域幅を下げます。たとえば、セッションに5人の学生がいて、それぞれがWebカメラを共有している上記のシナリオで、4人の学生がすべてのWebカメラストリームを受信するのに十分な帯域幅を持っている場合、クライアントはほぼ同じ品質のビデオを表示します。生徒の1人が低い帯域幅を使用している場合、ビデオストリームの更新頻度が減り、音声の品質が低下する可能性があります。低帯域幅のユーザーは、他のユーザーへのストリーミングに影響を与えません。
[サーバーでサポートできる同時ユーザーの数]
基本的にサーバーが最小要件を満たしている場合、150人の同時ユーザーをサポート可能です。
(50ユーザーの3つの同時セッション、6 x 25など)
しかしながら1つのセッションで100ユーザーを超えることはお勧めしません。
[ユーザーの最小帯域幅要件]
視聴者(学生)には、(少なくとも)0.5 Mbit/sec (500 Kbit/sec)のアップストリーム帯域幅、および(少なくとも)1 Mbit/sec のダウンロード帯域幅を用意することをお勧めします。アップストリーム帯域幅は、クライアントコンピューターがサーバーにデータを送信するために使用できる帯域幅の量です。
これらは、視聴者のアクティビティに依存するため、厳密な数値ではありません。ビューアがWebカメラをブロードキャストしていない場合、使用されるアップストリーム帯域幅の量は0.5 Mbit/sec 未満になります。
ユーザーが帯域幅を確認する良い方法は、speedtest.net にアクセスすることです。
発表者には、できるだけ多くのアップストリーム帯域幅をお勧めします。たとえば、発表者がデスクトップを共有する場合、共有されているデスクトップの内容を可能な限り迅速にサーバーに公開しようとします。
[クライアント環境の最小要件]
クライアント環境の帯域幅については、1 Mbit/sec のダウンロードと 0.5 Mbit/sec のアップロード速度をお勧めします。ユーザーは、speedtest.net を使用して実際の帯域幅をテストできます。
PCハードウェアについては、2GB以上のメモリを搭載したデュアルコアCPUをお勧めします。Google Chrome と Mozilla FireFox の最新バージョンを実行できるオペレーティングシステムをお勧めします。
ブラウザー(PCやスマートデバイスなど)については FireFox または Chrome を利用することをお勧めします。どちらのブラウザーも、Webリアルタイム通信(WebRTC)に優れたサポートを提供してます。Safari、IE、および Edge も同様に機能しますが、FireFox と Chromeは、低帯域幅の条件でより良いオーディオを提供します。
ユーザーが問題を抱えている場合(音声が定期的に切断されているなど)は、FireFox または Chrome を試すことをお勧めします。問題が解決しない場合は、ネットワークの問題である可能性が高いです。
有線接続はWiFiより優れています。他の人の音声が途切れる、または途切れるように聞こえる場合、無線基地局に近づくか、別の無線ネットワークを試すか、または有線接続に直接接続する事をお勧めします。
公共のWiFi使用は常に最善とは限りません。 Webサーフィンには問題ないかもしれませんが、オーディオやビデオをリアルタイムで送信するには、不十分な場合があります。