レポート

WebRTCはGoogle独自の技術ではない!「WebRTC Meetup Tokyo #7」イベントレポート

この記事を読むのに必要な時間:およそ 3 分

2015年3月11日(水)にWebRTC Meetup Tokyo #7が開催されました。WebRTC Meetup Tokyoとは,WebRTCに興味がある人向けの特化した勉強会です。プログラミングから新しいサービスアイディアまでなんでもありの勉強会です。これまでの開催模様はこちらから確認できます。

本稿では,およそ1周年を記念して実施されたWebRTC Meetup Tokyo #7の模様を紹介いたします。

[セッション]WebRTCスタックことはじめ/時雨堂@voluntas氏

まず@voluntas氏によるセッションからはじまりました。発表資料はこちらです。

WebRTCはJavaScriptに関する話題が多いですが,今回のセッションではJavaScriptではなく,その内部で動いてるプロトコルの紹介になります。WebRTCで内部で動作しているプロトコルは以下のとおり,多岐に渡ります。

  • SDP
  • STUN
  • TURN
  • ICE
  • DTLS
  • SRTP
  • RTP
  • RTCP
  • SCTP

WebRTCではこれらのプロトコルスタックを利用して,メディアチャネル・データチャネルの通信を実現します。よくあるWebRTCのサンプルではP2Pの簡単なTV会議を実現していますが,ビジネスとして提供する場合にはもう一歩先に進む必要があります。本セッションでは,その必要性について説明します。

P2P確立に必要な技術

まず,P2P確立(NAT越え)に必要な技術として,SDP,STUN,TURN,ICEがあります。これらはメディアチャネル・データチャネル共通で利用されています。メディアチャネルでは,RTPを暗号化したSRTPを利用してメディアを転送しています。データチャネルでは,SCTPを利用してデータを転送しています。SCTPを簡単に説明すると,HTTP/2っぽいプロトコルのことです。

メディアチャネル・データチャネルの暗号化

メディアチャネルとデータチャネルのどちらも暗号化を提供します。WebRTCでは暗号化にDTLSを利用しており,そのバージョンは1.0です。DTLSとは,UDPの上で動くTLSのようなイメージです。

メディアチャネルでは,DTLSのトンネルを作り,そのトンネル内で交換した鍵を利用してSRTPで通信します。DTLSの暗号化をそのまま利用するのではく,SRTP用の鍵交換をして通信しています。

WebRTCはGoogle独自の技術ではない

WebRTCはGoogleが独自に推進している技術・プロトコルのように思われることがありますが,実際には古くから標準化されている技術(RFC)の組み合わせで動作しています。この「古くから使われてきた技術」を,WebRTCに持ってきたことが重要です。なぜならば,古くからあるSIP等のシステムに接続可能になるからです。

サーバサイドWebRTCスタックはなぜ必要なのか?

答えはサーバ上で録画をしたいためです。海外で先行しているWebRTCのシステムは録画可能であり,デファクトの機能でもあります。

WebRTCはこれまで説明してきたプロトコルを利用して通信しますが,原則P2Pの通信であり,その内容は暗号化されています。そのため,サーバ上では暗号を解かない限り録画できません。

そこで,サーバ上で暗号を紐解く必要があります。その場合,ブラウザA~B間でサーバ経由の通信をする場合は,ブラウザA~サーバ,サーバ~ブラウザBのように背中合わせの形で通信を行います。この形式をB2B(Back-to-Back)と呼びます。

ビジネスでWebRTCを提供する場合はサーバ経由での通信が重要です。サーバ経由で通信が出来るようになると,今までのビデオ配信システムは不要になります。つまり,WebRTCをサーバサイドで吸収して配信する方法です。実際のプロダクト例としてはJanusLicodeMantis等があります。

サーバサイドアプローチであるMCUとSFUとは

WebRTCでP2Pのフルメッシュ形式で会議を提供すると,その音声・映像は全員に配信されます。しかし,MCU(Multipoint Control Unit)を利用すると,MCUで音声・映像が1本のストリームに合成されて送信されます。この場合,全ての通信がサーバ経由となっているため,録画機能を提供できます。

SFU(Selective Forwarding Unit)はMCUと異なり,合成しないでストリームを効率良く運ぼうとする仕組みです。たとえば,TokBox(Firefox Helloのバックエンド)はSFUを実現しています。SFUでは10人参加する会議ならば,10本のストリームを配ります。仮に同形式の会議を10個並列に提供する場合は,100本のストリームが必要になります。このような場合,SFUがストリームを100本処理する必要があるため,実装難易度は高くなります。

データチャネルを利用したビジネスチャンス

P2P形式でWebRTCを利用する場合はメディアチャネル単独だとビジネスにつなげるのは難しいですが,データチャネルにはビジネスチャンスがあります。実際に取り組んでいる例としては,たとえばMIST CDNがあります。

まとめ

WebRTCは通信が暗号化されており,解読するためには自前のWebRTCスタックが必要です。WebRTCスタックを実装するとMCUとSFUの選択肢が広がり,ビジネスチャンスが増えてくると考えています。

著者プロフィール

岩瀬義昌(いわせよしまさ)

NTTコミュニケーションズ所属のソフトウェアエンジニア。

Web:http://iwashi.co/

Twitter:@iwashi86

コメント

コメントの記入