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

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をサーバサイドで吸収して配信する方法です。実際のプロダクト例としてはJanus、Licode、Mantis等があります。

サーバサイドアプローチである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の選択肢が広がり、ビジネスチャンスが増えてくると考えています。

［セッション］WebRTCかくれんぼ／小松健作氏

続いて小松健作氏による、WebRTCかくれんぼという面白企画（ゲーム）がはじまりました。

ゲーム（WebRTCかくれんぼ）のルールは以下のとおりです。

指定したURLにアクセスするとモザイクアートが表示されます
モザイクアート内部に、自身の映像を1ピースとして埋め込みます（これが隠れるという意味です）
参加者全員が隠れたら、開始の合図とともに他の参加者を探します
最も他の参加者を探せた人が勝者です

上記のゲームが練習と本番で2セット開催され、勝者はRomoを獲得していました。

［デモ］Web Controller for V-Sido Connect

休憩時間にはアスラテック株式会社のWeb Controller for V-Sido Connectのデモが行われました。

以下の写真にあるロボットを、WebRTC経由でコントロールするというデモです。

コントロールは、Webアプリケーション（JavaScript）からWebRTCを利用して実現できます。これまでのWebRTCは主に人と人との通信でしたが、今回のデモのように人とロボットのように、IoTにも利用できます。

続いてLTが4本実施されました。

［LT］MCUとネイティブの四方山話／@tonofo氏

1本目は@tonofo氏によるLTです。

Native Code Packageの追従は大変

WebRTCはブラウザだけではなくNative Code Packageもありますが、追従はかなり大変です。なぜならば、時間が経つと中身が大幅に変わってしまうためです。Native Code packageを利用する方法は、こちらの記事にまとめてあります。

Raspberry Pi 2でWebRTC

世の中にはRaspberry Pi 2を用いて、WebRTC経由でカメラ映像を取得できる例があるとこのでやってみました。まず、カメラからH264のハードウェアエンコーダを通して試したところ、実際に映像を取得できました。

次にH264だけなく、VP8も使いたいと考えました。しかし、VP8のハードウェアエンコーダは無いので、代わりにgstreamerで処理してみます。その結果、Chromeでも映像を確認できるようになりました。ただしソフトウェアエンコーダで処理しているため、ほとんど静止画の状態になります。ハードウェアエンコーダの凄さが実感できました。

［LT］自前WebRTCコードで痛い目にあう／@othersight氏

2本目のLTは@othersight氏のLTです。

会社にてWebRTC試してみようか、と考えてまずPEERJSで使ってみました。使ってみたところ、通信に利用するIDが長くてわかりにくいなと思い、自由にわかりやすいアカウントを設定したい、またWebRTCの中身を理解したい、と思ったことから、自前でWebRTCのシグナリング・プレゼンス機能を作ってみました。結果的に2014年の時点、とりあえず動くものは作れました。

ですが、ブラウザのアップデートにつれて、非推奨のAPIが出てきました。特に、Firefox 33で色々と仕様変更があったため、同じAPIを利用していると、結果的にChromeと相互接続できなくなる事象が発生しました。

結論として、WebRTCのコードを自前で書くと、互換性やAPI仕様変更やら色々と痛い目にあうことがあり、商用で利用するのはかなり大変です。ただしその分、自由度が高いのでメリットはあります。

［LT］getUserMedia／@Tukimikage氏

3本目のLTは、主催者である@Tukimikage氏がgetUserMediaについてのLTです。資料はこちらです。

getUserMediaを呼び出す際にオプションを指定することで、仕様上は様々なパラメタを指定可能です。たとえば、アスペクト比や利用するカメラを選択できます。

実際にgetUserMediaを利用する場合は、ベンダープレフィックスをつける必要がありブラウザごとに挙動が違います。今回はChromeとFirefoxの違いを調べてみました。

まず、WidthとHeightの指定はChromeでしか動きません。Firefoxは指定しても動作しないようです。次に、アスペクト比はChromeとFirefoxのどちらも動作しません。ただし、ChromeではWidthとHeightの指定で代替できます。また、フレームレートの指定はChromeのみで動作しました。

上記と同様の操作をFirefoxで利用したい場合は、about:configからブラウザの設定値を直接変更する方法があります。特にアドオンを配布すれば、Chromeでのオプション指定と似た機能が利用できます。

［LT］SDP for WebRTC／@iwashi86氏

最後のLTは主催者の1人である@iwashi86氏のSDPについてです。資料はこちらです。

WebRTCでは、コーデック等の通信条件のネゴシエーションにオファーアンサー型のプロトコルであるSDP（Session Description Protocol）を利用しています。

SDPはVoIPエンジニアには馴染みのあるものですが、Web開発者にとっては難しいため、その内容について解説します。

SDPには、セッション記述部とメディア記述部があり、WebRTCでは特に「a=」ではじまる拡張属性を利用して、通信に必要な情報を記述します。たとえば、セッション記述部では音声と映像を多重化するための「a=BUNDLE」属性や、TrickleICEを利用するための「a=trickle」を記述します。メディア記述部ではICE候補等を記述します。

その他の詳細は、発表資料をご確認ください。