Experts.jp日本に、もっとエキスパートを。2014年に連載した「WebRTCを使ってみよう!」シリーズのアップデートとしてお送りしているこの連載ですが、今回はもとの連載にはなかった内容を番外編としてお届けします。利用できるようにして、実用的なアプリを作る準備ができました。ところが実際に使おうとすると、Chromeのセキュリティポリシーと向き合わなくてはなりません。Workerなどの強力なAPIは、セキュアな環境でなくては利用できない」というポリシーは今のWebの状況に合わせたものだと思います。その環境をどうやって用意すればよいのでしょうか?もちろん証明書を取得して、きちんとサーバーを立てるのがまっとうなやり方です。いえ、試験的な利用でそこまで準備するのは大変というのも、正直なところです。そこで今回は、比較的とっつきやすい方法をご紹介します。WebサーバーHTMLやJavaScriptなどの静的コンテンツを配置できる手段はいくつかあります。両方でアクセスできますし、独自ドメインで利用することも可能です。(※利用方法についてはWebに多くの情報がありますので、そちらをご参照ください)また、シグナリングで利用するFirebaseにも静的コンテンツのホスティング機能があります。シグナリングサーバーシグナリングにはsocket.ioなど、WebSocketを活用した仕組みが使われる例が多いようです。他の方法(例えば手動シグナリング)でもいいのですが、サーバーとクライアント(ブラウザ)で双方向に通信するにはWebSocketが適切なのでしょう。https://~から取得されたHTML/JavaScriptからWebSocketサーバーに接続する場合には、そちらもセキュアでなくてはなりません。(ws://~ではなく、wss://~)。WebSocketを利用したシグナリングサーバーを自分で用意する場合、そちらでも証明書が必要になります。そこで今回はリアルタイムメッセージングに利用できるBaaSであるFirebaseを使って、シグナリングの仕組みを構築したいと思います。Firebaseでシグナリングを実現するにはまずはFirebaseにサインアップし、必要なキーやURLを入手しましょう。参考:Firebaseで作る簡単リアルタイムウェブアプリケーション(※手順については今回は省略させていただきます。あしらかず)ブラウザでFirebaseの機能を利用するために、必要なライブラリを読み込んでおきます。今回はデータベースを利用するので、必要なjsファイルは次の通りとなります。src="https://www.gstatic.com/firebasejs/3.1.0/firebase-database.js"></script>それから取得しておいたキーとURLを用いてFirebaseに接続します。firebase.database();シグナリングで送りたいモノ前回の記事にもあるように、シグナリングでは2つの通信ケースがあります。ルーム内の他のメンバー全員(接続している他のクライアントすべて)に送る特定のメンバー(特定のクライアント)だけに送るまた後者のためには、特定のメンバーを識別するための何らかのIDが必要となります。ようにIDを決める(UUID、タイムスタンプ、乱数など)サーバー側でIDを振り出すFirebaseを使うとデータベースに格納されるオブジェクトのすべてにIDが振られるので、今回はそれを利用します。データベースの構造Firebaseはデータベースによる階層構造をもったデータの永続化と、その追加/変更/削除のイベント通知が行えます。今回は次のようなアプリ/ルーム/メンバーの階層構造としました。ルーム”test”にメンバー”bbb”が参加する場合、次の2カ所のイベントを待ち受けています。メッセージのやりとり以外の用途で使います。メンバーのIDの決定メンバーを特定してメッセージを送るには、メンバーを識別するIDが必要です。先ほどは仮に”bbb”としましたが、実際には衝突を避けるためにFirebase側で振り出されるキーを利用することにしました。clientId});データベースにパスを指定してpush()すると、子要素が追加されて、そのキーが返っています。その値を使って先ほどの子要素の内容を更新しています。ここまで終わった時のDatabaseの内容をFirebaseのコンソールで見てみると、次のようになっています。ルーム内へのブロードキャストシグナリングの流れは前回と同じです。メッセージに送信元(自分のID)をセットroomBroadcastRef.push(msg);}各メンバーはこのブロードキャストのイベントを待ち受けていて、typeに応じて処理を行います。接続処理}});socket.ioでは自分自身からメッセージは飛んで来ませんが、Firebaseでは自分でpush()してもイベントが飛んでくるので、それは無視しています。me”以外は、特定のメンバー宛のメッセージのやり取りになります。宛のメッセージは、この下にpush()します。Candidateのやり取りは、すべてこちらのメンバー宛のメッセージになります。Firebaseのルール設定Firebaseのデータベースにはアクセスのルール指定があります。デフィルトではread/writeにAuth必要なルールが生成されていますが、今回のサンプルでは特定のパス以下はAuth不要で読み書きできるよう、ルールを追加しました。STUNの設定せっかくFirebaseでメッセージをやり取りできるので、NATを超えてWebRTCで通信できるようにしましょう。NATを超えて通信を行うには、ローカルネットワークでのIPアドレスではなく、グローバルIPを伝える必要があります。今回は詳しく説明しませんが、そのための仕組みがSTUNです。GoogleがSTUNサーバーを公開しているので、それを使わせてもらいましょう。指定していましたが、現在の仕様では”urls”と指定する必要があります。Candidate)に、STUN経由で取得した情報も含まれるようになります。Pagesで公開しています。Firebaseもしばらく(〜2016年9月末の予定)使える状態にしておきますので、皆さんもお試しください。multi_firebase.html※シグナリングの手段以外は、前回のソースと同様の処理になっています。クリックすると、URLを送るためのメーラーが開きます。NATだけでなく、FirewallでUDP通信やポートが制限されている可能性があります※Firewallを超えての通信については、次回の記事で取り上げる予定ですEdge同士での通信webrtc.orgが提供しているadapter.jsを使うと、多くのブラウザの差異を吸収することができます。EdgeのサポートしてるORTCを、WebRTCのオブジェクトのインターフェイスを通して利用することができます。残念ながらサポートしているビデオコーデックの制限で、ChromeやFirefoxとのビデオ通信はできませんが、Edge同士であれば今回のFirebaseを使ったシグナリングでビデオ/オーディオのP2P通信を行うことができます。multi_firebase_adapter.html注意点Edgeでは、同一のカメラを複数のウィンドウ/タブで利用することができません。同一PCで通信する場合は、複数のカメラを用意してくださいEdgeでは現在のところSTUNはサポートされていない(TURNのみサポート)ため、今回のサンプルでNATを越えた通信はできません次回は今回はFirebaseを使ってシグナリングを実現しました。次回はNAT/Firewallを超えてのWebRTC通信についてお届けする予定です。