3.1　多地点接続の仕組み

　映像コミュニケーションでは電話のように一対一の通信を行うのではなく，複数の参加者が同時に接続して通信する仕組みが必要になります．最も単純な仕組みとして，全ての参加者が互いに接続するいわゆるフルメッシュの接続方式が考えられます（図2(a)）．しかし，この接続方式は全ユーザ間で映像トラヒックの送受信が発生するため，ユーザ端末の負荷が大きくネットワーク帯域の利用量も増加します．この問題を解決するためにサーバを間に置いて通信処理を代行する方式が提案されています（図2(b)，(c)）．図2(b)には，MCU（Multipoint Control Unit）と呼ばれる多地点接続装置を介して参加者が通信を行う仕組みを示しています．MCUは各ユーザ端末から送信される映像と音声の合成処理を行った上で，各ユーザ端末に合成映像を送り返します．このためMCUが設置されるサーバに対しては高い処理能力が要求されますが，ユーザ端末の負荷は削減されネットワークの帯域利用量も削減することが可能です．図2(c)には，SFU（Selective Forwarding Unit）と呼ばれる装置がユーザ端末から送信される映像を複数のユーザ端末へ配信代行する仕組みを示しています．ユーザ端末は全端末からの映像を受信しますが，映像の送信はSFUに対してのみ行われます．このためMCUを用いた方式と比較してサーバの処理負荷を抑えつつ，フルメッシュ通信と比較してユーザ負荷やネットワーク帯域利用量を削減可能な方式となります．

3.2　多地点接続装置（MCU）を用いた場合の構成技術

　次に代表的な方式であるMCUと呼ばれる多地点接続装置を用いた場合を例に，映像コミュニケーションを構成する技術を解説していきます．本方式は非常に多岐にわたる要素技術から構成されますが，大きく分類すると，図3に示すようにサーバシステム，ネットワーク，及び端末で構成されています．

　サーバシステムは図3上部に示すように多地点接続装置，ゲートキーパ，ゲートウェイ，及びカスタマコントロールから構成されます．多地点接続装置は先ほど説明したとおり，ユーザ端末から送信される映像と音声を合成し，ユーザに送り返す映像コミュニケーションの要となる技術です．その隣のゲートキーパは，その名が示すとおり門番的な受付制御機能を提供します．例えば図3に示すユーザ端末AとDのみがゲートキーパによって登録されている場合，その他のユーザ端末は多地点接続装置へアクセスできないため，会議へは参加できず通信のセキュリティを保つことが可能となります．ゲートキーパは一般的にはこの受付制御以外にも，映像コミュニケーション特有のIDとIPアドレスとをひも付けるアドレス解決機能や，ユーザ端末の接続帯域を調整する帯域制御機能も提供します．次にゲートウェイを説明します．ゲートウェイはプロトコル変換機能を提供することで，様々なユーザ端末やアプリケーションの相互接続を実現する技術です．プロトコルとは通信を行うための共通手順のことで，プロトコルが異なるアプリケーションは本来お互いに通信できません．そこでゲートウェイが間に入って共通のプロトコルによる通信に見せかけることで，異なる端末やアプリケーション間での相互接続を可能としています．最後にカスタマコントロールを説明します．カスタマコントロールはカスタマ，すなわちユーザへ会議の制御権を提供する機能です．例えば，会議の開始や終了，画面レイアウトや音声ミュートの制御，会議の予約による自動開催といった機能を，ユーザが親しみやすいWebなどのユーザインタフェースで提供します．

　次にネットワークの説明に移ります．ユーザ端末とサーバシステムは原則IPネットワークで接続されます．IPネットワークそのものの解説は省略しますが，特に映像コミュニケーションにおいてはIPレイヤの上位レイヤで動作するシグナリングプロトコルとメディア転送プロトコルが重要な役割を果たします．シグナリングプロトコルの役割は，通信を行う端末間でセッションと呼ばれる接続関係を確立することです．代表的なプロトコルとしてテレビ会議で利用されるH. 323，IP電話やWeb会議で利用されるSIP（Session Initiation Protocol）⁽⁶⁾が挙げられます．シグナリングプロトコルによって端末間の接続関係が確立された後は，メディア転送プロトコルによって音声や映像がリアルタイムに伝送されます．メディア転送には国際標準となっているRTP（Real-Time Transfer Protocol）やRTCP（Real-Time Transfer Control Protocol）⁽⁷⁾が使われることが主流です．RTPは音声や映像といったデータストリームをリアルタイムに配信するプロトコルであり，処理が単純で遅延が少ない特徴があります．このため，データを配信する際にデータの送達確認やフロー制御を行いたい場合には，RTCPを補助的に併用することが可能です．

　次にユーザ端末側の技術を説明します．ユーザ端末はテレビ会議における専用端末だけでなく，PCやスマートフォン，タブレットといった汎用的なコンピュータを利用可能です．その際，カメラ，モニタ，マイク，スピーカといった映像コミュニケーションのためのハードウェアが備わっていることはもちろんですが，内部的には2．で述べた映像符号化技術が大きな役割を担っています．符号化技術とは，音声や映像を圧縮したり伸張したりする技術です．ネットワークへメディアを転送する際に容量を圧縮する処理をエンコード，逆に圧縮されたメディア情報を人が視聴できるように伸張する処理をデコードと呼びます．特に映像に関しては，品質良く効率的に圧縮する技術は重要な研究テーマとなっています．例えば，映像を送信する際に面的に隣り合った画素が似ている点に着目したフレーム内予測，また，時間的な動きベクトルを予測するフレーム間予測といった技術によって，データを丸ごと送るのではなくその差分のみを送ることで，データ圧縮を実現しています．

　最後にこれまで紹介した技術のおさらいを兼ねて，関連の深いWebRTC^(2),(3)と呼ばれる技術を紹介します．

　WebRTCはWebブラウザ上で映像コミュニケーションを実現する技術で，W3CとIETFによって標準化が進められています．WebRTCという単体の通信技術があるのではなく，複数の技術が合わさってWebRTCによる通信が実現されているイメージを持って頂くとよいかもしれません．このため，WebRTC通信の実現方法は自由度が高いものとなります．例えば標準的なWebRTCアプリケーションの実装では図2(a)のフルメッシュ通信となりますが，もちろん，図2(b)のMCUや図2(c)のSFUを用いた実装も可能です．また，前述したゲートウェイを用いれば，プロトコルが異なるテレビ会議やWeb会議との相互接続も可能となります．WebRTCにおけるシグナリングプロトコルとしてはWebSocketと呼ばれる技術が使われることが多いですが，前述のSIPを使っても問題ありません．メディア転送にはRTPのセキュリティ機能を高めたSRTP（Secure Real-time Transport Protocol）⁽⁸⁾が使われます．WebRTCではメディア転送に関する規定以外に，テキスト等のデータを送信する方法も規定されており，例えば映像コミュニケーションとチャットを組み合わせるといった使い方も実現できます．映像符号化のエンジンはWebブラウザの実装に依存しますが，主にH. 264/AVCやVP8，VP9といったものが使われ，ブラウザが対応しているならばセッション確立時に指定可能です．このように，WebRTCによる通信を例にしても，原則的には図3に示す要素技術で構成されていることが分かると思います．皆さんが普段ブラウザで利用されるWeb会議サービスにおいても，実はこのWebRTCが使われたものが数多く存在しています⁽⁹⁾．