第 7 章 P2P だけが WebRTC じゃない・・・ SFU と MCU を、の ロロ SFU または MCU この両者は立ち位置こそ同じですが、その挙動はまったくの別物です。 ( = メディアストリームのエンコードと送信 ) が 1 度だけで済むようになるのです。 くなります。そして、 SFU/MCU がメディアストリームを配信してくれるため、 " 上り " 参加者の接続相手は SFU/MCUI 台だけとなり、自分以外の全員と接続する必要がな △図 7.3 SFU と MCU の立ち位置 △図 7.4 SFU と MCU の動作イメー シ SFU 78 かし、一般にエンコードとデコードとでは処理にかかる負荷が高いのはエンコードのほう 信とデコード ) については P2P 接続の場合と同じく参加者一 1 人分必要になるのです。し つまり、上りは 1 本だけで済むようになりますが、 " 下り " ( = メディアストリームの受 SFU から送られてくることになります。 全員に送信します。参加者から見ると、自分以外の全員のメディアストリームがすべて SFU は各参加者から送信されたメディアストリームをそのままコピーし、他の参加者

7.2 SFU と MCU なので、これが 1 度で済むだけで効果は十分にあります。また、インターネット回線も ADSL や CATV など下りに比べて上りのほうが帯域が狭い場合はあってもその逆はまず ないので、上りの帯域が節約できるのは大きなメリットです。 MCU 一方 MCU は、各参加者から送信されたメディアストリームをひとつに合成して参加者 に送信するものです。ポリコムやシスコなどの、従来からあるビデオ会議システムでも使 われているのでご存知の方も多いかもしれません。 映像をどのように合成するかは MCU の実装および設定によって異なります。レース ゲームの複数人対戦のように画面を等分割する場合や、その時々で主に喋っている人の映 像を大きくしたり、あるいはその人の映像だけに切り替えたりする場合があります。 音声についてはエコーやハウリングを防ぐため、参加者それぞれについて、対象者を除 いた全員分を合成して送信します。 MCU を利用した場合、エンコードと送信、受信とデコードともに 1 つだけで済むため、 参加者の負荷はとても小さくなります。一方、 MCU 側は全員分のメディアストリームを いったんデコードし、合成して再び工ンコードしなければならないため、十分なサーバー スペックを用意する必要があります。 SFU と MCU 、どちらを採用すべきか SFU と MCU では役割が異なるため、どちらを採用すべきかはケースパイケースです。 単に通話参加者の負荷を軽減する目的であれば、どちらでも構いません。一般に、 MCU はメディアストリームの合成を行うため、 SFU に比べてサーバースペックを高くする必 要があります。サーバースペックを低く抑えたいのであれば、 SFU のほうが有利です。 また、 MCU では参加者の映像が合成された状態で送信されてきますが、 SFU では個別 に送られてきます。特定の映像だけを拡大して見られるようにしたり、各映像の表示位置 を自由に並び替えたりするような機能をクライアント側に搭載したい場合は SFU のほう が向いています。 一方、 MCU が有利なのは大人数でビデオ会議をするような場合です。 SFU を利用す る場合、下りの本数は参加者一 1 人となるので、マシンのスペックにもよりますが、参加者 が川人を超えたあたりから厳しくなってきます。 MCU であれば参加者が何人であろう と下りが常に 1 つで済むので、参加者がどれだけ増えてもクライアント側の負荷は増えま せん。ただしサーバー側は合成するメディアストリームの数が増えて負荷も高まるので、 そのぶん MCU のサーバースペックもより高くする必要があります。 79

第 7 章 P2P だけが WebRTC じゃない・・・ SFU と MCU 7.3 TURN との違い りに通信を中継するものでした。通信の主体はユーザー同士であり、 TURN サーバーは 第 4 章の復習になりますが、 TURN サーバーは NAT 越えができないユーザーの代わ SFU/MCU には明確な違いがあります。 参加者の通信を中継するサーバーといえば TURN サーバーもありましたが、それと 信するときに改めて暗号化することになります。 できません。参加者から送られてきたデータは SFU でいったん複合し、別の参加者に送 はユーザーごとに異なるため、暗号化済みデータをそのまま別の参加者に転送することは う。一方、 SFU はメディアストリームをコピーして他の参加者に配信するだけですが、鍵 ディアの合成を行うので、データを複合する必要があるということは理解しやすいでしょ な関係です。そのため、当然ながら通信の中身を見ることができます。 MCU の場合はメ 上の役割はともかく、純粋に WebRTC の接続として見れば、ユーザーとサーバーは対等 それに対し、 SFU/MCU はサーバー自体が通信の主体として振る舞います。システム 持っていないため中身を見ることはできません。 りません。また、中継するデータは暗号化されていますが、データの複合に必要な鍵を も、それぞれの間に TURN サーバーが人るだけでフルメッシュであることに変わりはあ それを中継する補助的なものです。仮に参加者全員が TURN サーバーを利用したとして ロロ ロロ TURN 0 SFU または MCU △図 7.5 TURN と SFU/MCU ・通信主体はユーザー同士 ・サーバーはただのトンネル であり、通信の中身を見ない ( 見られない ) ・通信主体はユーザーとサーバー ・サーバーは通信の中身を見る P2P との使い分け 逆に、 SFU / MCU を利用するまでもない ( または、すべきでない ) ケースも存在します。 80 7.4

7.4 P2P との使い分け 少人数の場合 本章の冒頭で説明したケースの裏返しですが、通話の参加者が 3 , 4 人程度までならば、 フルメッシュの P2P 接続でもほとんど支障はありません。それ以上の人数が参加するの であれば、 SFU/MCU の導人を検討しましよう。 音声通話の場合 ン負荷とネットワーク負荷のいずれもそこまで高くならないので、参加者が 10 人程度に トワーク帯域も桁違いに大きくなります。映像が存在しない音声のみの通話ならば、マシ 映像と音声では、映像のほうがエンコードにかかるマシン負荷も、送受信に必要なネッ の人数に視聴してもらえるようになります。 場合、 WebRTC での通話に比べて遅延は大きくなりますが、より低い負荷で多く メディアを録画すれば、通話内容のストリーミング配信も可能になります。この た付加機能を提供したりできます。 通話内容の録画・録音や音声認識によるテキスト化のような、映像・音声を活かし すべての通信がサーバーに集まるため、サーバー側で挙動をコントロールしたり、 SFU/MCU のメリットは、参加者の負荷軽減だけではありません。 負荷軽減以外のメリット SFU/MCU を使い分けましよう。 SFU / MCU の導入にはコストもかかります。アプリの規模や仕様に応じて、 P2P と です。 データを送信したい場合以外は、データチャネルのみの接続を個別に作るほうが効率的 ません。ただし、 SFU / MCU がデータチャネルに対応していても、参加者全員に同時に ポートしていないものもあり、その場合は当然データチャネルは別接続としなければなり タチャネルを同時に利用できます。しかし、 SFU / MCU によってはデータチャネルをサ WebRTC は 1 本の接続でメディアチャネル ( = メディアストリームの送受信 ) とデー データチャネルを利用する場合 で SFU/MCU を使用しなくても大丈夫でしよう。 なっても十分耐えられます。音声通話しかサポートしないのであれば、ほとんどのケース

7.2 SFU と MCU decode encode encode decode encode decode encode decode 4 人 decode encode decode encode decode decode encode encode decode ロロ decode encode encode decode ] ー encode decode ロロ △図 7.2 ビデオ会議の参加者数と送信される映像・音声 ( 参加者が 4 人のとき ) 77 一手に引き受けるハプとなります。 これらのサーバーは図 7.3 のように参加者の間に立ち、メディアストリームの送受信を (Multipoint Control Unit) という 2 種類のサーバーです。 この間題を解決するために登場するのが SFU (Selective Forwarding Unit) と MCU 7.2 SFU と MCU いってしまうのです。 ド・デコードにかかるマシン負荷も、送受信に必要なネットワーク帯域も比例して増えて つまりこのようなフルメッシュの P2P 接続では、会議の参加者が増えるほど、エンコー 変える必要があることなどが理由です。 て利用できるコーデックが異なることや、回線や端末のスペックに合わせて映像の品質を 度だけ行い、全員に同じデータを送信するわけではありません。これはプラウザーによっ 話相手ごとにそれぞれ別にエンコードを行う必要があるということです。工ンコードを 1 こで理解しておく必要があるのは、 WebRTC で送信するメディアストリームは、通 続を張り合うことになります。このようなネットワーク形態をフルメッシュと呼びます。 続相手は 3 人です。つまり、参加者全員がそれぞれ自分以外の全員 ( = 参加者 -1 人 ) と接 こから参加者が 1 人増えて 3 人になると接続相手は 2 人、参加者が 4 人になれば接 面に表示するだけです。 コードして相手に送信し、相手から送信されてきたメディアストリームをデコードして画 会議の参加者が 2 人のときは、特に難しいことはありません。自分の映像・音声をエン

一 8 ) 一 8 一つ 1 つけ -4 4 一りり STUN サーバー 4.2 4.3 NAT を越えてゆけ . 4.4 最終兵器 TURN サーバー 4.5 Microsoft は TURN サーバーがお好き ? STUN/TURN サーバーの構築 第 5 章 coturn のインストール . 5.1 STUN サーバーを構築する 5.2 5.3 TURN サーバーを構築する 映像・音声以外をやり取りする・・・アータチャネル 第 6 章 6.1 データチャネルの開始方法 . 6.2 データの送受信 WebSocket とデータチャネル 6.3 6.4 データチャネルの信頼性 バイナリデータの形式を変える 6.5 6.6 大きなデータを送るには P2P だけが WebRTC じゃない・・・ SFU と MCU 第 7 章 P2P の弱点 SFU と MCU . 7.2 TURN との違い 7.3 P2P との使い分け 第 8 章 開発に便利な Tips & Tricks プラウザーの挙動を変える . プラウザーの内部情報を覗き見する ローカルサーバーに外部から接続できるようにする (HTTPS 対応 ) ビデオチャットのサンプルアプリ 付録 A A. 1 セットアップ方法 A. 2 アプリの起動と実行 WebRTC の理解・活用に役立つ Web ページ集 付録 B B. 1 情報サイト コミュニティ B. 2 ソフトウェア・サービス B. 3 5 - り りり 5 5 一り一 8 一一 0 一つっ 2 つ」一 8 一つけ 6 6 6 8 一ト 9 0 9 9 9 7

第 7 章 P2P だけが WebRTC じゃない・・ SFU と MCU こまで、 WebRTC はユーザー同士が P2P で接続するという前提で解説してきました こからはその前提をひっくり返します。最初からサーバーを経山して通信する前提 で設計したほうが上手くいくパターンもあるのです。 7.1 P2P の弱点 図 7.1 および図 7.2 は、 P2P 接続でビデオ会議を行った場合の、会議の参加者が送受イ するメディアストリームの流れを表したものです。 一三ロ encode encode ロ 2 人 encode decode encode decode decode decode encode decode encode decode ビデオ会議の参加者数と送信される映像・音声 ( 参加者が 2 人・ 3 人のとき ) △図 7.1 76