WebRTCはコンタクトセンター業界に地殻変動を起こすか？ [第4回WebRTCの弱点]
今回は「第3回WebRTC関連のサービス」で予告した通り、WebRTCの弱点について考えていきましょう。弱点と書きましたが、実際はWebRTC技術の苦手な所、不向きなことでしょうか。
１．大人数のコミュニケーションには向かない
まずWebRTC技術のウリを考えてみましょう。最初に思いつくことは何と言っても、「間にサーバがいらない、Webブラウザ同士のP2Pコネックション」です。
そしてこのコミュニケーションの形として同時N人での利用が考えられます。しかしながらこのNの値は何人でも良いかというとそんなことはなく、本当にそのままブラウザ同士のみでコミュニケーションをした場合、安定的に運用できる目安は現状ではN=5程度ではないでしょうか。
3名でWeb会議を行った場合と5名で行った場合を図で表してみます。まずは3名の場合です。各ブラウザは他の二人のブラウザと通信しています。
次は5名の場合です。
各ブラウザは他の4名のWebブラウザと同時に通信する必要があり、各PCにかなりの負荷がかかります。そのため、この図のようにWebブラウザを利用した5,6名規模までのビデオ会議は可能ですが、生徒100名が参加する授業のような用途では厳しくなってきます。
これはこの100名規模のセッションに参加する生徒の各Webブラウザが他の99名のWebブラウザへピアコネクションを確立する必要があるためです。その場合PCのマシンパワーが限界に達するか、ブラウザのキャパシティが耐えられなくなり、接続がダウンすることは明白ですよね。
このように、「間にサーバがいらない、Webブラウザ同士のP2Pコネックション」を言葉通りにとった形態を「フルメッシュ方式」と呼びます。その名の通り、各ブラウザがどのブラウザともコネクションを確立するためこのように呼ばれています。
先ほどの100名の生徒が参加する授業の例で考えてみましょう。先生のブラウザは100名の生徒のブラウザに対してコネクションを確立し、それぞれのブラウザに対して常に授業内容の映像と音声を流すことになります。果たして先生のPCのWebブラウザは負荷に耐え、正常に動くでしょうか？
（参考までにラボでの調査によると、ChromeはFirefoxに比べ負荷に強いという結果が出ています。テストに使用するAPIやプラットフォーム、その他環境にもよるとは思いますのであくまでも参考にしてください。）
ではこのような大人数での使用を必要とする場合、どうすれば良いのでしょうか？残念ながら結局、音声や映像といったメディアの伝送について、間にサーバを介在させることになるのです。前述した5名のフルメッシュでの通信を置き換えると以下のようなイメージになります。
後述しますが、複数の会社からこのようなメディア伝送用のサーバが販売されていますし、クラウドサービスとしてこのメディアの伝送を行うサービスも存在します。
２．実際のP2Pコミュニケーション実現にはまだまだNAT越えのハードルがある
この点についてはVoIP業界にいる方はご存知の方も多いのではないでしょうか。ユーザのネットワーク環境は多くの場合NAT(NAPT)されています。また、ファイアウォールも当然あります。ローカルネットワークを超えてWebブラウザ同士がピアコネクションを確立させメディアを伝送できるようになるためには、何らかの方法で正しいアドレスを交換しなければなりません。
このようにNATやファイアウォールを超えてP2Pコネクションのため何とか正しいアドレスを交換しようとすることを「ホールパンチ」と呼んでいます。また、この「ホールパンチ」を実現するための標準プロトコルとしてICE(Interactive Connectivity Establishment)があります。しかしながら、多段NATなどユーザーのネットワーク環境は複雑な場合が多く、これら技術でもP2Pコネクションが確立できない場合は存在します。そういった場合ではやはり間にメディアをリレーする役割を担うサーバを配置することになります。
これまで紹介した、弱点１、２を補うため各ベンダーから提供されている中継サーバやサービスをいくつかご紹介します。
addLive
クラウドでのビデオチャットサービスの提供
日本ブレケケ
WebRTC<->既存のSIPデバイス間の相互接続を一台で行うIP-PBXを提供
WebRTCベースの無料会議サービスを提供
ingate
TURNサーバの提供。メディアコーデックなども行う
vLine
ビデオチャットクラウドサービス(大人数でのビデオチャットが可能)
オンラインでの授業などにも使われているクラウドサービス
３．仕様も実用もまだまだこれから。
ご存じのとおり、WebRTCの標準化はW3C(World Wide Web Consortium)とIETF(Internet Engineering Task Force)において進められている最中です。IEやsafariなどまだまだWebRTCに対応していないブラウザも存在します。
また、日本語向けの情報も少ないのが現状です。開発者はWebRTC関連のミートアップやカンファレンスなどに参加して最新情報を得るかネット等で海外の最新トレンドをチェックする必要があります。
海外サイトの参考例
書籍はリックテレコムより、WebRTC関連の翻訳本が1冊出版されていますが、ビギナー向けの本としては日本語では現状これしかないのではないでしょうか。
英語の方が書籍は充実しています。Amazonなどから購入するのも手ですね。
コールセンターシステムに関わる方へ
WebRTCのウリは「Webブラウザ同士のP2Pコネックション」と書きましたが、コールセンターでビジネスをする上では、お客様がWebブラウザ経由で気軽にアクセスすることは非常にメリットがありますが、P2Pコネクションの部分はどうでも良い気がします。
そのためコールセンターでこれら技術を利用する場合は、上記のWebRTCのマイナス部分も理解して自ビジネスにどう利用するかを考え必要なシステムを社内に構築するか、外部からクラウドサービスとして提供してもらうという選択肢があります。
今回、WebRTCの苦手な点について解説しましたが、やはりコールセンター/コンタクトセンタービジネスにとってはWebブラウザから簡単にアクセスできる技術は魅力的です。WebRTC技術を利用する際はそれを補完する技術やサービスも合わせて選択することが重要となってきます。
