Tech Sketch Bucket of Technical Chips by TIS Inc.

WebRTC(PeerJS)で遠隔作業支援システムを作る(1)

Pocket

WebRTCという技術をご存知でしょうか。WebRTCとは「ブラウザ上でリアルタイムコミュニケーションを実現するためのAPI仕様」のことで、Flash等のプラグイン無しにカメラ映像や音声の共有、データの双方向通信を可能とする技術です。このWebRTCとスマートグラスを活用し、遠隔作業支援システムを作ってみましょう。


WebRTCとは

WebRTCは "Web Real-Time Communication" から作られた言葉で、ビデオデバイス/オーディオデバイスから得たストリームデータのブラウザ間双方向リアルタイム通信や、テキストデータ・バイナリデータのブラウザ間双方向データ通信などを定めています。WebRTCはHTML5で新しく策定された規格で、WebRTCのAPIレベルでの標準化はW3C、プロトコルレベルでの標準化はIETFで進められています。

WebRTCのコア機能

WebRTCは規格上様々なAPIが定義されていますが、よく利用されるのは以下のJavaScript API群です。

  • ビデオデバイス/オーディオデバイスからストリームデータを取得するAPI(MediaStream API
  • ブラウザ間でPeer-to-Peer接続を確立するためのAPI(RTCSessionDescription APIとRTCIceCandidate API
  • ブラウザ間で効率的なデータストリーミングを行うためのAPI(RTCPeerConnection API
  • ブラウザ間でデータ交換を行うためのAPI(RTCDataChannel API

開発者はHTML5とこれらのJavaScript APIを組み合わせ、WebRTCアプリケーションを組み立てることになります。

WebRTCをサポートしているブラウザ

WebRTCは、まだサポートしているブラウザが限定されています。
現時点(2014年7月14日)で、Windows/MacOS/AndroidのChrome/Firefox/Opera最新版では動作しますが、残念ながらiOSのChromeやOpera、Safariでは動作しません。
(対応ブラウザの詳細は このサイト が参考になります。)

WebRTCの特徴

一度コネクションを確立すればリアルタイムに双方向通信ができる技術という観点からは、WebRTCはWebSocketと似ているかもしれません。しかし決定的に異なっているのは、WebRTCはブラウザどうしが直接データをUDPで送受信するPeer-to-Peerアーキテクチャを取っているという点です
(後述しますが、ネットワークの状況によってはP2P通信ができない場合もあります)。

WebRTC_01.png

WebRTCの良い点と面倒な点

WebRTCの特徴はUDPを用いたP2Pアーキテクチャにありますが、それぞれ良い点もあれば面倒な点もあります。

良い点

P2Pの良い点

WebRTCはブラウザが直接相互接続するため高速な通信が可能です。サーバを経由しないため、サーバが高負荷になり処理が遅延する心配もありません。

UDPの良い点

通信プロトコルとしてUDPを用いるため、オーバーヘッドが少なくリアルタイム性の高いデータ伝送が可能です。そのため映像や音声といった、ある程度のパケットロスを許容してでもリアルタイム性を確保したいデータの交換に最適です。

面倒な点

P2Pの面倒な点

WebRTCはブラウザ間を直接接続しなければならないため、IPアドレスやポート、通信に使うプロトコルや帯域といった情報を交換し、適切なルールに則って接続手続きをしなければなりません。
さらにお互いのブラウザが所属するネットワークが異なり経路間にFWやNATなどが挟まっている場合、ブラウザ自身のIPアドレスやポート等の情報だけでは接続することができません。そのためICE(Interactive Connectivity Establishment)と呼ばれる仕組みを利用し、お互いへ通信可能な経路を探し出して共有しなければなりません。
このようなP2Pの経路を確立しお互いに通信できる状態まで整えることをシグナリングと言いますが、WebRTC自身はこのシグナリングのプロトコルを定義していません。そのため何らかの手段で自力実装する必要があります。

UDPの面倒な点

通信プロトコルがUDPのため、通信回線の状況によってはパケットのロスや順序の逆転などが発生し得ます。映像や音声ではさほど問題になりませんが、大きなファイルを交換する場合などでは致命的な破損を引き起こす可能性が有ります。データ交換に用いるRTCDataChannel APIは規格上通信プロトコルとしてSCTPを用いることになっており、SCTPで信頼性モードを選択すればUDP上でパケットの順序制御や再送制御を行わせることができますが、RTCDataChannel APIの実装状況はブラウザによって差異があり必ず動作するとは限りません。またUDPの制限である64KBを越えるデータを送信したい場合は、データを自力でチャンクに分解する必要もあります。

WebRTCのシグナリング

上述したシグナリングについて、もう少し詳しく説明しましょう。WebRTCのシグナリングは、電話をかける手続きと似ています。ブラウザ間を仲立ちする交換手としてシグナリングサーバが必要ですが、接続元ブラウザ(Caller)から受け取った要求を接続したいブラウザ(Callee)へ受け流すことがシグナリングサーバの仕事となります。

Session Description Protocol(SDP)の交換

SDPとは、P2Pで接続するメディアの種類(音声、映像)やメディアの形式(コーデック)、転送プロトコル 、自身のIPアドレスやUDPポート番号等を記した文字列のことを指します。P2P接続するブラウザは、お互いにこのSDPを交換しなければなりません。これはシグナリングサーバを介して、OfferとAnswerを交換することで実現されます。

  1. Callerが自身のSDPを付けSignaling ServerへOffer送信
  2. Signaling ServerはCalleeにOffer転送
  3. Calleeが自身のSDPを付けてSignaling ServerへAnswer送信
  4. Signaling ServerはCallerにAnswer転送

ICE Candidateの共有

ICE Candidateは、P2Pで接続するブラウザの通信経路の情報を示した文字列です。複数の通信経路が取り得る場合、複数のICE Candidateが交換されます。

  1. CallerからCalleeへ到達できる経路情報(ICE Candidate)を Signaling Serverへ送信
  2. Signaling ServerはCalleeにICE Candidate転送
  3. CalleeからCallerへのIce CandidateをSignaling Serverへ送信
  4. Signaling ServerはCallerにAnswer転送

WebRTC_02.png

SDPとICE Candidateを交換することで、ネットワーク的に最短の通信経路上に、適切なプロトコルでP2P接続が確立されます。

WebRTCの通信経路探索

WebRTCのICEによる通信経路探索をもう少し詳しく見てみましょう。WebRTCは1~3の手段で通信経路を探索し、ネットワーク的に最短の通信経路を選択します。

  1. まずクライアント同士の直接P2P接続を試みる
  2. 直接経路が確立できなかった場合、次に外部のSTUNサーバを用いて外部からみたIPアドレスとポートによるP2P接続を試みる
  3. それでも接続できなかった場合、TURNサーバを経由した接続を試みる

※STUN : Simple Traversal of UDP through NATs
※TURN : Traversal Using Relay NAT

WebRTC_03.png

多段NATの下にいるブラウザと通信する場合など、ネットワークの状況次第ではSTUNサーバを用いても直接接続する通信経路が取れない場合があります。この場合、外部のTURNサーバにパケットを中継させることでブラウザ間を接続することもできますが、TURNサーバに負荷が集中するためWebRTCのメリットが享受できません。TURNサーバを使用しても問題無いのか、あるいはネットワーク構成を見直すほうが良いのか、十分検討すべきでしょう。

PeerJS

ブラウザだけでリアルタイムに映像や音声が共有でき、双方向のデータ通信も可能とするWebRTCはたいへん便利です。しかしシグナリングの処理やデータ通信の細かい制御を自力実装するのはかなり大変です。そこで PeerJS というライブラリを用います。
PeerJSはブラウザごとに異なるWebRTCの実装を隠蔽し、イベントドリブンで使いやすいAPIを提供するOSS(MITライセンス)のWebRTCラッパーです。NTTコミュニケーションズがサービスしているWebRTCプラットフォームの SkyWay も、クライアントライブラリとしてこのPeerJSをベースとした実装が提供されています。
またPeerJSと容易に接続できる シグナリングサーバ も公開されているため、面倒なシグナリング処理は全てPeerJSにお任せすることができます。

ただしSTUNサーバやTURNサーバの機能は提供されません。STUNサーバやTURNサーバのURLをパラメータとしてPeerJSに渡すことができるので、Google等が公開しているSTUNサーバを利用するか、必要であれば このOSS のようなSTUN&TURNサーバ実装を使って独自でサーバを立ち上げても良いでしょう。

実装する遠隔作業支援システム

では最後に、Google Glass等のスマートグラスとWebRTCを活用した遠隔作業支援システムの全体像を示します。
WebRTC_04.png

作業準備

最初に、スマートグラスに内蔵されたブラウザと監視端末のブラウザをWebRTCで接続しペアリングします。

通常作業時

通常作業時は、スマートグラスのカメラから得た作業者の視界を支援者の監視端末上に表示します。

トラブル発生時

トラブル発生時は、支援者は作業者との音声通話を開始し指示を出します。テキストメッセージを作業者のスマートグラスへ転送し、文字で指示を出すこともできます。必要であればスマートグラスから得た作業者の視界をキャプチャし、フリーハンドでキャプチャ画像に指示を書き込み(ココに注意!と赤丸と付ける等)、作業者のスマートグラスへ転送することもできるようにしましょう。

作業終了

作業が終了すると、スマートグラスと監視端末のWebRTC接続を切断し、ペアリングを解除します。

次回は

次回はこの遠隔作業支援システムを作るための準備として、スマートグラス( Vuzix M100 )とサーバサイド( node.js + express + peerjs-server )の環境構築について解説します。

エンジニア採用中!私たちと一緒に働いてみませんか?