こんにちは！ 2014年に連載した「WebRTCを使ってみよう！」シリーズのアップデート記事も番外編を含めて6回目となりました。2016年の最後として、実際の通信では欠かせないNAT越えと、企業ネットワークで使うために必要なFirewallを通過する方法について見ていきましょう。

NATを越えて

NATの役割

NAT(+IPマスカレード)は企業だけでなく、一般家庭でも使われています。ブロードバンドルーターやWiFiルーターでは、1つのグローバルIPアドレスを、複数のPCやデバイスで共有することができます。このとき、NATには2つの役割があります。

• インターネットにつながったグローバルなIPアドレスと、家庭内/社内のローカルなネットワークでのIPアドレスの変換
• 複数のPC/デバイスが同時に通信できるように、ポートマッピングによるポート変換

WebRTCでNAT越しに通信すること考えてみましょう。

ブラウザが知っている情報

• ローカルネットワークのIPアドレス
• 自分が使う（動的に割り振った)UDPポート

ブラウザでは分からない情報

• グローバルIPアドレス
• NATによってマッピングされた、外部に向けたUDPポート

例えば

次の架空の例を見てみましょう。二つのPCのブラウザでは、それぞれ自分のローカルIPアドレス、UDPは知ることができます。

• 左のPCのブラウザが分かること
  • ローカルIPアドレス 192.168.10.11
  • ローカルUDPポート 4001/UDP
• 右のPCのブラウザが分かること
  • ローカルIPアドレス 10.2.100.51
  • ローカルUDPポート 5001/UDP

しかし、NATの外側から見たグローバルの情報は自分では分かりません。

• 左のPCのブラウザが知らないこと
  • グローバルIPアドレス 178.50.111.222
  • グローバルUDPポート 51111/UDP
• 右のPCのブラウザが知らないこと
  • グローバルIPアドレス 200.100.50.81
  • グローバルUDPポート 52222/UDP

NATを越えてPeer-to-Peer通信を行うには、シグナリング処理でお互いに自分の知らないグローバルの情報を交換する必要があります。

STUNが教えてくれること

自分で知らない情報は、誰かから教えてもらうしかありません。それを可能にするのがSTUN(Session Traversal Utilities for NATs)です。

STUNの仕組みはシンプルです。NATで変換されたIPアドレス/ポートを、外側にいるSTUNサーバーに教えてもらいます。先ほどの例で言えば、このようになります。

自分のグローバル情報が分かったら、それをシグナリングサーバー経由で相手に渡します。

STUNサーバーから得られた情報は、シグナリングの過程でICE Candidateとして取得できます。これをシグナリングサーバーなどを経由して相手に送ることになります。（参考： シグナリングサーバーを動かそう、シグナリングを拡張して、複数人で通信してみよう ）

首尾よくNATとポート変換を潜り抜ければ、Peer-to-Peerで通信を行うことができます。

STUNサーバーを使ってみよう

STUNサーバーを自分で動かすこともできますが、幸い公開されているSTUNサーバーがあります。まず、そちらを使ってみましょう。Googleが公開しているサーバーがよく利用されているようです。

• stun.l.google.com:19302
• stun1.l.google.com:19302
• stun2.l.google.com:19302
• stun3.l.google.com:19302
• stun4.l.google.com:19302

通常はどれか1つ指定すればOKですが、複数指定することもできます。それでは、実際に以前のソースの一部を修正してみましょう。

function prepareNewConnection(id) {
  let pc_config = {"iceServers":[
    {"urls": "stun:stun.l.google.com:19302"},
    {"urls": "stun:stun1.l.google.com:19302"},
    {"urls": "stun:stun2.l.google.com:19302"}
  ]};
  let peer = new RTCPeerConnection(pc_config);
  // ... 省略 ...
}

さあ、これで接続を試してください。上手く行けば、例えば自宅と友人の家で通信が可能になっているはずです。

STUNでNATを越えられないとき

NATにはグローバルIPアドレスを共有するだけでなく、セキュリティ対策としての役割もあります。内部の端末を隠したり、通信できるポートを制限したり、一種の簡易Firewallとして利用されているケースもあります。その場合はFirewallの場合と同じく、次に説明するTURNを利用する必要があります。

またNATの構造によっては、接続先によって（今回の場合、STUNサーバーとPeer-to-Peerの通信相手）別のポートが割り当てられる Symmetric NAT という物があるようです。この場合もSTUNの仕組みでは通信することができません。やはりTURNの出番ということになります。

Firewallを越えたい

一般家庭のようにブロードバンドルーターなどでNATがある環境では、STUNを使えば通信が可能になります。

それに対して一般的な企業では、Firewallにより通信できるポートが制限されるケースが多いようです。STUNを使った場合でもUDPポートは動的に割り振られるままなので、通信をするためにはFirewallにとても大きな穴を空ける必要があります。それではきっとセキュリティ管理者に怒られてしまいます。

こんなケースに対応するのが、TURN(Traversal Using Relays around NAT)の仕組みです。先ほどのSTUNもTURNもどちらもWebRTCのために生まれたのではなく、以前からVoIPやネットワークゲームの世界で使われていたものです。

TURNの仕組み

TURNを使った通信では、TURNサーバが実際のストリームデータを受け渡す間に入ります。すべてのパケットをTURNサーバーがリレーすることになり、もはや厳密にはPeer-to-Peer通信ではなくなります。

ただしこの際、TURNサーバーではパケットをそのままリレーし、内容については一切変更はしません。

• 動画のデコード、エンコードは行わない
• データはそのまま受け渡し、両端のPeerで施された暗号は解除しない

そのため個人的には、アプリケーション的に見た場合にはPeer-to-Peerを維持していると考えていいと思っています。

TURNサーバーでは暗号化処理や動画のデコード/エンコーディングは行わないので、CPU負荷よりもネットワーク負荷が高くなりやすいです。

TURNサーバーを用意するには

それでは、実際にTURNサーバーを動かしてみましょう。2014年の記事ではrfc5766-turn-serverを使いましたが、今回はその後継であるcoturnを使います。coturnが生まれた背景は、こちらの記事に詳しく書かれています。

• [翻訳] coTURN:マルチテナント型のオープンソースのSTUN/TURNサーバ

今回は、OSはUbuntu 16.04 LTSを使って導入してみました。 なるべくOSセットアップ直後の素の状態から自分でビルドしてみましょう。

自分でビルドする手順

まずは、依存ツールやライブラリを導入します。

sudo apt-get update
sudo apt-get upgrade

sudo apt-get install gcc
sudo apt-get install sqlite3
sudo apt-get install libssl-dev
sudo apt-get install libevent-dev
sudo apt-get install make

次にcoturnのソースを、こちらのサイトからダウンロードします。

• https://github.com/coturn/coturn/wiki/Downloads

私が試したときは4.5.0.4が最新でしたが、2016年12月現在は4.5.0.5が最新のようです。 利用したいバージョンのソースをダウンロードして、解凍してください。

wget http://turnserver.open-sys.org/downloads/v4.5.0.4/turnserver-4.5.0.4.tar.gz
tar xvfz turnserver-4.5.0.4.tar.gz

それではビルドしてみましょう。

cd turnserver-4.5.0.4
./configure
make
sudo make install

もし途中で依存ライブラリ不足でエラーが出た場合には、追加でインストールしてからビルドし直してみてください。ビルドに成功すると、Ubuntu16の場合は次の場所に関連ファイルがインストールされます。

• バイナリ → /usr/local/bin/turnserver
• 設定ファイル（ひな形） → /usr/local/etc/turnserver.conf.default

設定ファイルは適宜 turnserver.conf にコピーして、それを編集して利用してください。

※こちらの手順はcoturn 4.5.0.4 をビルドした際のものです。最新のものでは手順が変更されている可能性がありますので、もし何か見つけたらコメントいただけると嬉しいです。

coturn を動かすまで

coturnをTURNサーバーとして動かす際に、通信方法を2種類を使うことがことができます。

• TURN … 特定のUDPポートを利用する
• TURN over TCP … 特定のTCPポートを利用する

企業で使う場合は、後者を利用したいケースが多いと思います。今回は両方使えるように設定しましょう。

tunserver.conf の設定

まず、/usr/local/etc/turnserver.conf.default を /usr/local/etc/turnserver.conf にコピーし、それを編集します。たくさんの設定項目がありますが、TURNをWebRTCで使う際のポイントを見ておきましょう。

ポートの指定

# TURN listener port for UDP and TCP (Default: 3478).
# Note: actually, TLS & DTLS sessions can connect to the
# "plain" TCP & UDP port(s), too - if allowed by configuration.
#
listening-port=80

デフォルトでは3478/UDP を使いますが、それを変更して80/TCPを使うようにします。コメントアウトを外してポート番号80を指定してください。

資格証明方法（クレデンシャル）

# Uncomment to use long-term credential mechanism.
# By default no credentials mechanism is used (any user allowed).
#
lt-cred-mech

# 'Static' user accounts for long term credentials mechanism, only.
# This option cannot be used with TURN REST API.
# 'Static' user accounts are NOT dynamically checked by the turnserver process,
# so that they can NOT be changed while the turnserver is running.
#
#user=username1:key1
#user=username2:key2
# OR:
#user=username1:password1
#user=username2:password2

user=user:password

WebRTCで使うには、lt-cred-mech を有効にする必要があります。デフォルトではコメントアウトされているので、これを有効にしてください。ユーザアカウントは外部のDBを使うのが適切ですが、今回はシンプルに設定ファイルに直接記入しました。ご利用のシステムに合わせて、外部ファイルや外部DBをご利用ください。

同時にrealmも指定します。自分のサーバーのドメインに合わせて、適宜指定してください。

# The default realm to be used for the users when no explicit
# origin/realm relationship was found in the database, or if the TURN
# server is not using any database (just the commands-line settings
# and the userdb file). Must be used with long-term credentials
# mechanism or with TURN REST API.
#
realm=coturn.yourdomain.com

通信プロトコルの指定（変更不要）

# Uncomment if no UDP client listener is desired.
# By default UDP client listener is always started.
#
#no-udp

# Uncomment if no TCP client listener is desired.
# By default TCP client listener is always started.
#
#no-tcp

# Uncomment if no TLS client listener is desired.
# By default TLS client listener is always started.
#
#no-tls

# Uncomment if no DTLS client listener is desired.
# By default DTLS client listener is always started.
#
#no-dtls

プロトコルの指定で no-tcp のコメントアウトを外すとTURN over TCPを利用しなくなります。今回はTCPを使いますので、コメントアウトのままにしておきます。もしUDPを使いたくない場合は no-udp のコメントアウトを外してください。

以前試したときはブラウザでの実装の不十分でtlsやdtlsを利用できなかったのですが、今回試したところデフォルトのまま（有効のまま）で通信できました。もしうまく通信できない場合は、コメントアウトを消してtlsやdtlsを無効にして試してみてください。

coturnを起動しよう

それではcoturnを起動しましょう。今回は80ポートを利用しているため、環境によってはroot権限が必要となりますので、sudoを利用してください。

sudo /usr/local/bin/turnserver -o -v -c /usr/local/etc/turnserver.conf

ここで指定しているコマンドライン引数は次の意味です。

• -o .. デーモンとして起動
• -v .. verboseモード。ログを多く出す
• -c .. 設定ファイルのパスを指定

クライアントのソースを修正しよう

それでは準備したcoturnサーバーを使うように、にクライアント側のソースを修正しましょう。STUNで修正した部分と同じ個所になります。 coturnサーバーが coturn.yourdomain.com で、ポート80で動いていると仮定します。その情報をPeerConnectionに教えてあげましょう。

function prepareNewConnection(id) {
  let pc_config = {"iceServers":[
    {"urls": "stun:coturn.yourdomain.com:80"},
    {"urls":"turn:coturn.yourdomain.com:80?transport=udp", "username":"user", "credential":"password"},
    {"urls":"turn:coturn.yourdomain.com:80?transport=tcp", "username":"user", "credential":"password"}
  ]};
  let peer = new RTCPeerConnection(pc_config);
  // ... 省略 ...
}

また、企業内から外部のシグナリングサーバーを利用するには、そちらも80/TCPや443/TCPを使う必要があるかもしれません。環境に応じてご準備ください。

ここまでできたら、無事Firewallを越えて通信ができるはずです。企業内のブラウザと、外のブラウザ（自宅のPCやアンドロイドのブラウザ）で試してみてください。

最後に

WebRTC入門も2016年中になんとか予定していた記事を書き終えることができました。書いている間にもどんどんブラウザがバージョンアップし、新しいAPIが使えるようになっています。最新情報はブラウザのリリースノートやブログをご覧いただくとよいと思います。

• WebRTC.org Chrome Report Notes
• Mozilla blog Advancing WebRTC

みなさんもWebRTCを活用した素敵なアプリケーションを作ってくださいね。ここまでお付き合いいただき、どうもありがとうございました！

こんにちは！ 2014年に連載した「WebRTCを使ってみよう！」シリーズのアップデートとしてお送りしているこの連載ですが、今回はもとの連載にはなかった内容を番外編としてお届けします。

httpsのハードル

前回は複数人、複数会議室で利用できるようにして、実用的なアプリを作る準備ができました。ところが実際に使おうとすると、Chromeのセキュリティポリシーと向き合わなくてはなりません。

「getUserMedia()やService Workerなどの強力なAPIは、セキュアな環境でなくては利用できない」というポリシーは今のWebの状況に合わせたものだと思います。では、その環境をどうやって用意すればよいのでしょうか？

もちろん証明書を取得して、きちんとサーバーを立てるのがまっとうなやり方です。最近はLet’s Encryptなど無料で証明書を発行するサービスもあります（参考：“Let’s Encrypt – how get to free SSL for WebRTC”）。とはいえ、試験的な利用でそこまで準備するのは大変というのも、正直なところです。そこで今回は、比較的とっつきやすい方法をご紹介します。

Webサーバー

HTMLやJavaScriptなどの静的コンテンツを配置できる手段はいくつかあります。エンジニアの皆さんであれば、次の2つをすでに利用されている方々も多いのではないでしょうか？

• GitHub Pages
• Google App Engine

どちらも http / https の両方でアクセスできますし、独自ドメインで利用することも可能です。（※利用方法についてはWebに多くの情報がありますので、そちらをご参照ください）

また、シグナリングで利用するFirebaseにも静的コンテンツのホスティング機能があります。

シグナリングサーバー

シグナリングにはsocket.ioなど、WebSocketを活用した仕組みが使われる例が多いようです。もちろん他の方法（例えば手動シグナリング）でもいいのですが、サーバーとクライアント（ブラウザ）で双方向に通信するにはWebSocketが適切なのでしょう。

https://～から取得されたHTML/JavaScriptからWebSocketサーバーに接続する場合には、そちらもセキュアでなくてはなりません。(ws://～ではなく、wss://～）。WebSocketを利用したシグナリングサーバーを自分で用意する場合、そちらでも証明書が必要になります。

そこで今回はリアルタイムメッセージングに利用できるBaaSであるFirebaseを使って、シグナリングの仕組みを構築したいと思います。

Firebaseでシグナリングを実現するには

まずはFirebaseにサインアップし、必要なキーやURLを入手しましょう。

• 参考：Firebaseで作る簡単リアルタイムウェブアプリケーション

（※手順については今回は省略させていただきます。あしらかず）

ブラウザでFirebaseの機能を利用するために、必要なライブラリを読み込んでおきます。今回はデータベースを利用するので、必要なjsファイルは次の通りとなります。

<script src="https://www.gstatic.com/firebasejs/3.1.0/firebase-app.js"></script>
 <script src="https://www.gstatic.com/firebasejs/3.1.0/firebase-database.js"></script>

それから取得しておいたキーとURLを用いてFirebaseに接続します。

// Initialize Firebase
  let config = {
    apiKey: "yourAPIKey",  // <-- please set your API key
    databaseURL: "https://yourapp.firebaseio.com/",  // <-- please set your database URL
  };
  firebase.initializeApp(config);
  let database = firebase.database();

シグナリングで送りたいモノ

前回の記事にもあるように、シグナリングでは2つの通信ケースがあります。

• ルーム内の他のメンバー全員（接続している他のクライアントすべて）に送る
• 特定のメンバー（特定のクライアント）だけに送る

また後者のためには、特定のメンバーを識別するための何らかのIDが必要となります。

• クライアント側で、重ならない/重なりにくい ようにIDを決める（UUID、タイムスタンプ、乱数など）
• サーバー側でIDを振り出す

Firebaseを使うとデータベースに格納されるオブジェクトのすべてにIDが振られるので、今回はそれを利用します。

データベースの構造

Firebaseはデータベースによる階層構造をもったデータの永続化と、その追加/変更/削除のイベント通知が行えます。今回は次のようなアプリ/ルーム/メンバーの階層構造としました。

例えばルーム”test”にメンバー”bbb”が参加する場合、次の2カ所のイベントを待ち受けています。

• multi/room_test/_broadcast_ の child_added イベント
• multi/room_test/_direct_/member_bbb の child_added イベント

また、multi/room_test/_join_ はメッセージのやりとり以外の用途で使います。

メンバーのIDの決定

メンバーを特定してメッセージを送るには、メンバーを識別するIDが必要です。先ほどは仮に”bbb”としましたが、実際には衝突を避けるためにFirebase側で振り出されるキーを利用することにしました。

let databaseRoot = 'myapp/multi/';
    let key = database.ref(databaseRoot + room + '/_join_').push({ joined : 'unknown'}).key
    clientId = 'member_' + key;
    database.ref(databaseRoot + room + '/_join_/' + key).update({ joined : clientId});

データベースにパスを指定してpush()すると、子要素が追加されて、そのキーが返っています。その値を使って先ほどの子要素の内容を更新しています。

ここまで終わった時のDatabaseの内容をFirebaseのコンソールで見てみると、次のようになっています。

ルーム内へのブロードキャスト

シグナリングの流れは前回と同じです。

• 新たに通信を開始したい人（member_xxxx）が、通信開始の合図のルーム内にブロードキャスする(“call me”）

“test”ルームにブロードキャストする場合には、 multi/room_test/_broadcast_ の下を使います。

let roomBroadcastRef = database.ref(databaseRoot + room + '/_broadcast_');

  // 通信開始の合図
  function callMe() {
    emitRoom({type: 'call me'});
  }

  function emitRoom(msg) {
    msg.from = clientId; // メッセージに送信元（自分のID)をセット
    roomBroadcastRef.push(msg);
  }

各メンバーはこのブロードキャストのイベントを待ち受けていて、typeに応じて処理を行います。

roomBroadcastRef.on('child_added', function(data) {
      let message = data.val();
      let fromId = message.from;
      if (fromId === clientId) {
        // ignore self message (自分自身からのメッセージは無視する）
        return;
      }
      
      if (message.type === 'call me') {
        // 接続処理
      }
    });

socket.ioでは自分自身からメッセージは飛んで来ませんが、Firebaseでは自分でpush()してもイベントが飛んでくるので、それは無視しています。

特定のメンバーへのメッセージ

通信開始の合図である”call me”以外は、特定のメンバー宛のメッセージのやり取りになります。例えば member_bbb 宛のメッセージは、この下にpush()します。

• multi/room_test/direct/member_bbb

function emitTo(id, msg) {
    msg.from = clientId; // メッセージに送信元（自分のID)をセット
    database.ref(databaseRoot + room + '/_direct_/' + id).push(msg);
  }

Offer/Answerの交換やICE Candidateのやり取りは、すべてこちらのメンバー宛のメッセージになります。

Firebaseのルール設定

Firebaseのデータベースにはアクセスのルール指定があります。デフィルトではread/writeにAuth必要なルールが生成されていますが、今回のサンプルでは特定のパス以下はAuth不要で読み書きできるよう、ルールを追加しました。

{
  "rules": {
    ".read": "auth != null",
    ".write": "auth != null",
    "myapp" : {
      "multi" : {
        ".read": true,
        ".write": true
      }
    }
  }
}

NAT越えの設定 STUNの設定

せっかくFirebaseでメッセージをやり取りできるので、NATを超えてWebRTCで通信できるようにしましょう。

NATを超えて通信を行うには、ローカルネットワークでのIPアドレスではなく、グローバルIPを伝える必要があります。今回は詳しく説明しませんが、そのための仕組みがSTUNです。GoogleがSTUNサーバーを公開しているので、それを使わせてもらいましょう。

function prepareNewConnection(id) {
    let pc_config = {"iceServers":[{"urls": "stun:stun.l.google.com:19302"}]}; // for STUN server
    let peer = new RTCPeerConnection(pc_config);
    // ... 省略 ...
  }

※ 2014年の記事では”url” と指定していましたが、現在の仕様では”urls”と指定する必要があります。

このようにSTUNサーバーを指定することで、通信経路の候補(ICE Candidate)に、STUN経由で取得した情報も含まれるようになります。

動かしてみよう

今回のサンプルをGitHub Pagesで公開しています。Firebaseもしばらく(〜2016年9月末の予定）使える状態にしておきますので、皆さんもお試しください。

• GitHub Pages で試す multi_firebase.html (Chrome/Firefox）
• GitHub でソースを見る multi_firebase.html

※シグナリングの手段以外は、前回のソースと同様の処理になっています。

使い方

• URLの後ろに ?room という形で、好きなルーム名を指定してください
  • https://mganeko.github.io/webrtcexpjp/basic2016/multi_firebase.html?お好きなルーム名
• ルーム名を指定せずに multi_firebase.html を開くと、ランダムにルーム名を決定します
• [Start Video]をクリックし、カメラの映像とマイクの音声を取得します
• 通信相手にも同じルーム名を指定してブラウザ(Chrome/Firebox)でアクセスしてもらいます
  • ?room も含むURLを伝えてください
  • “Mail link of this room” をクリックすると、URLを送るためのメーラーが開きます。宛先を指定して送信してください
• 通信相手にも[Start Video]をクリックし、カメラの映像とマイクの音声を取得してもらいます
• 自分、あるいは相手から[Connect]ボタンを押してください
• Firebase経由で情報が交換され、P2P通信が始まります
• このサンプルでは、同じルームに同時に4人まで(3人の相手と)通信することができます

トラブルシューティング

• 異なるPCで通信できない場合
  • → ルーム名が一致しているか確認していください
  • ルーム名を指定せずにブラウザでアクセスすると、ランダムにルーム名が決定されます
  • 異なるPCでは、それぞれ異なるルーム名がランダムに決定されます
• 一度接続できたが、その後できなくなった場合
  • ルーム内の過去のブロードキャストメッセージが残っている可能性があります
  • ルーム名を変更して、再度接続してみてください
• （例えば）会社と自宅で通信できない場合
  • → NATだけでなく、FirewallでUDP通信やポートが制限されている可能性があります
  • ※Firewallを超えての通信については、次回の記事で取り上げる予定です

Edge同士での通信

webrtc.orgが提供しているadapter.jsを使うと、多くのブラウザの差異を吸収することができます。最新のhttps://webrtc.github.io/adapter/adapter-latest.jsを読み込めば、Microsoft EdgeのサポートしてるORTCを、WebRTCのオブジェクトのインターフェイスを通して利用することができます。

残念ながらサポートしているビデオコーデックの制限で、ChromeやFirefoxとのビデオ通信はできませんが、Edge同士であれば今回のFirebaseを使ったシグナリングでビデオ/オーディオのP2P通信を行うことができます。

• GitHub Pages で試す multi_firebase_adapter.html (Chrome/Firefox）
• GitHub でソースを見る multi_firebase_adapter.html

注意点

• Edgeでは、同一のカメラを複数のウィンドウ/タブで利用することができません。同一PCで通信する場合は、複数のカメラを用意してください
• Edgeでは現在のところSTUNはサポートされていない(TURNのみサポート)ため、今回のサンプルでNATを越えた通信はできません

次回は

今回はFirebaseを使ってシグナリングを実現しました。次回はNAT/Firewallを超えてのWebRTC通信についてお届けする予定です。

こんにちは！ 2014年に連載した「WebRTCを使ってみよう！」シリーズのアップデート記事も4回目となり、佳境に入りました。前回の1対1の通信をベースに、今回はより実用的なビデオチャットを目指して複数人で通信可能なように拡張してみましょう。

複数人、複数会議室を目指して

前回作ったのは、1つのシグナリングサーバーに対して、同時に1ペアだけが利用できる仕組みでした。これを複数人で、複数会議室で利用できるようにしていきましょう。こちらの図の左のBeforeの状態から、右のAfterの状態を実現します。

複数人で通信するためには

WebRTCはPeer-to-Peer (P2P) で通信する仕組みです。なので複数人と通信するためには、複数のRTCPeerConnectionを用意する必要があります。図にするとこんな感じです。

また、P2P通信を開始するためにSDP(Offer/Answer)を交換する必要がありますが、それぞれの相手ごとに生成、交換しなければなりません。

P2Pなので当然かもしれませんが、私は最初に複数の相手と通信しようとして混乱してしまいました。この考え方を踏まえていれば、あとは力技になります。

シグナリングサーバーの対応

シグナリングサーバーは前回の1対1の時と同じく、Node.jsを使って用意しましょう。複数会議室を実現するのに便利なため、今回はwsモジュールではなく、より高機能のsocket.ioを使います。Node.jsのインストールは終わっていると思うので、コマンドプロンプト/ターミナルから、次のコマンドを実行してください。 ※必要に応じて、sudoなどをご利用ください。

npm install socket.io

2014年にはsocket.ioはv0.9でしが、今回はv1.4.xになっています。

シグナリングサーバーのコードは前回の1対1と同様にメッセージを中継するのが役目ですが、接続してきたクライアントがルーム（会議室）に入室要求を送ってきたら、socket.ioのサーバ側でそのルームに join() してあげます。

// ---- multi room ----
    socket.on('enter', function(roomname) {
      socket.join(roomname);
      console.log('id=' + socket.id + ' enter room=' + roomname);
      setRoomname(roomname);
    });

    function setRoomname(room) {
      socket.roomname = room;
    }

クライアントからのメッセージ送信には、次の2つのパターンがあります。

• ルーム内の他のメンバー全員（接続している他のクライアントすべて）に送る
• 特定のメンバー（特定のクライアント）だけに送る

シグナリングサーバーでは、送信先が指定されていればその相手だけに、指定されていなければルーム内の全員（送信者以外）にメッセージを送ります。 ※その際に、送信元を特定できるID（socket.ioが管理しているID)を追加しています。

socket.on('message', function(message) {
        message.from = socket.id; // 送信元のIDをメッセージに追加

        // get send target
        var target = message.sendto;
        if (target) { // 特定の相手に送る場合
          socket.to(target).emit('message', message);　
          return;
        }

        // broadcast in room
        emitMessage('message', message);
    });

    // ルーム内の全員に送る場合
    function emitMessage(type, message) {
      // ----- multi room ----
      var roomname = getRoomname();

      if (roomname) {
        // ルーム内に送る
        socket.broadcast.to(roomname).emit(type, message);
      }
      else {
        // ルーム未入室の場合は、全体に送る
        socket.broadcast.emit(type, message);
      }
    }

サーバーの全体のソースは次の通りです。これを例えば signaling_room.js というファイル名で保存します。

"use strict";

var srv = require('http').Server();
var io = require('socket.io')(srv);
var port = 3002;
srv.listen(port);
console.log('signaling server started on port:' + port);

// This callback function is called every time a socket
// tries to connect to the server
io.on('connection', function(socket) {
    // ---- multi room ----
    socket.on('enter', function(roomname) {
      socket.join(roomname);
      console.log('id=' + socket.id + ' enter room=' + roomname);
      setRoomname(roomname);
    });

    function setRoomname(room) {
      socket.roomname = room;
    }

    function getRoomname() {
      var room = socket.roomname;
      return room;
    }

    function emitMessage(type, message) {
      // ----- multi room ----
      var roomname = getRoomname();

      if (roomname) {
        console.log('===== message broadcast to room -->' + roomname);
        socket.broadcast.to(roomname).emit(type, message);
      }
      else {
        console.log('===== message broadcast all');
        socket.broadcast.emit(type, message);
      }
    }

    // When a user send a SDP message
    // broadcast to all users in the room
    socket.on('message', function(message) {
        var date = new Date();
        message.from = socket.id;
        console.log(date + 'id=' + socket.id + ' Received Message: ' + JSON.stringify(message));

        // get send target
        var target = message.sendto;
        if (target) {
          console.log('===== message emit to -->' + target);
          socket.to(target).emit('message', message);
          return;
        }

        // broadcast in room
        emitMessage('message', message);
    });

    // When the user hangs up
    // broadcast bye signal to all users in the room
    socket.on('disconnect', function() {
        // close user connection
        console.log((new Date()) + ' Peer disconnected. id=' + socket.id);

        // --- emit ----
        emitMessage('user disconnected', {id: socket.id});

        // --- leave room --
        var roomname = getRoomname();
        if (roomname) {
          socket.leave(roomname);
        }
    });

});

コマンドプロンプト/ターミナルから、 次のように起動してください。（ファイル名は適宜置き換えてくださいね）

node signaling_room.js

クライアント側の拡張

次はクライアントとなるブラウザ側の処理を拡張していきます。

socket.io サーバーへの接続

今回はシグナリングサーバーを同じPCの3002番ポートで動かしていると想定します。HTMLファイルの先頭で、socket.ioのクライアント用のjsファイルを読み込みます。

<!doctype html>
<html>
<head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
 <title>multi party</title>
 <script src="http://localhost:3002/socket.io/socket.io.js"></script>
</head>
... 省略 ...
</htm>

クライアントではsocket.ioのサーバー (localhost:3002) に接続します。このとき、ws://～ ではなく、http://～/ となることがWebSocketを直接利用した場合と異なります。

// ----- use socket.io ---
  let port = 3002;
  let socket = io.connect('http://localhost:/' + port + '/');
  socket.on('connect', function(evt) {
    // 接続したときの処理
  });

※実際のシグナリングサーバーの環境に合わせて、URLやポート番号は変更してください。

ルーム（会議室）への入室

クライアンではsocket.ioのサーバーに接続したら、希望のルームに入室を依頼します。ルーム名は今回はURLの後ろに　?部屋名 という形で指定することにしてみました。（お好きな方法で指定してください）

let room = getRoomName();
  socket.on('connect', function(evt) {
    console.log('socket.io connected. enter room=' + room );
    socket.emit('enter', room);
  });

  // -- room名を取得 --
  function getRoomName() { // たとえば、 URLに  ?roomname  とする
    let url = document.location.href;
    let args = url.split('?');
    if (args.length > 1) {
      let room = args[1];
      if (room != '') {
        return room;
      }
    }
    return '_testroom';
  }

複数通信の流れ

1対1の時は相手が1人しかいない前提だったので、ただちにOffer SDP / Answer SDPを送信していました。今回は相手が何人いるか分からない状況からスタートしますし、相手ごとに個々にOffer SDP / Answer SDPを送受信する必要があります。そこで、相手を確認するやりとりを追加しました。図にすると、次のような流れになります。

もう少し細かく見ると、次のような処理を行っています。

• 新たに通信を開始したい人（ブラウザA）が、通信開始の合図のルーム内にブロードキャストする(“call me”）
• 受け取った人（ブラウザB、ブラウザC）は、Offer SDPを生成して、ブラウザAを宛先に指定して送ります
  • RTCPeerConnectionを生成
  • RTCPeerConnection.createOffer()でOffer SDPを生成
  • setLocalDescription()で覚える
  • ブラウザA宛てに送信
• ブラウザAは、Offer SDPを受け取り、Answer SDPを生成してそれぞれの相手に送り返します
  • 相手ごとにRTCPeerConnectionを生成
  • それぞれ受け取ったOffer SDPをRTCPeerConnection.setRemoteDescription()で覚える
  • RTCPeerConnection.createAnswer()でAnswer SDPを生成
  • setLocalDescription()で覚える
  • それぞれの相手にAnswer SDPを返信
• ブラウザB、ブラウザCは、Answer SDPを受け取る
  • 受け取ったAnswer SDPをRTCPeerConnection.setRemoteDescription()で覚える

ソースの修正：複数通信の準備

それでは、ブラウザ側のソースも手を入れていきましょう。まず、複数のRTCPeerConnectionを扱えるように用意します。

// ---- for multi party -----
  let peerConnections = [];
  const MAX_CONNECTION_COUNT = 3;

  // --- RTCPeerConnections ---
  function getConnectionCount() {
    return peerConnections.length;
  }

  function canConnectMore() {
    return (getConnectionCount() < MAX_CONNECTION_COUNT);
  }

  function isConnectedWith(id) {
    if (peerConnections[id])  {
      return true;
    }
    else {
      return false;
    }
  }

  function addConnection(id, peer) {
    peerConnections[id] = peer;
  }

  function getConnection(id) {
    let peer = peerConnections[id];
    return peer;
  }

  function deleteConnection(id) {
    delete peerConnections[id];
  }

相手の映像を表示するvideoタグも、動的に生成して複数管理できるようにします。

let remoteVideos = [];
  let container = document.getElementById('container');

  // --- video elements ---
  function addRemoteVideoElement(id) {
    let video = createVideoElement('remote_video_' + id);
    remoteVideos[id] = video;
    return video;
  }

  function getRemoteVideoElement(id) {
    let video = remoteVideos[id];
    return video;
  }

  function deleteRemoteVideoElement(id) {
    removeVideoElement('remote_video_' + id);
    delete remoteVideos[id];
  }

  function createVideoElement(elementId) {
    let video = document.createElement('video');
    video.width = '160';
    video.height = '120';
    video.id = elementId;

    video.style.border = 'solid black 1px';
    video.style.margin = '2px';

    container.appendChild(video);

    return video;
  }

  function removeVideoElement(elementId) {
    let video = document.getElementById(elementId);
    container.removeChild(video);
    return video;
  }

さらにRTCPeerConnectionの接続や、相手からのメディアストリーム、videoタグを連動して扱う処理も追加しておきましょう。

// --- video elements ---
  function attachVideo(id, stream) {
    let video = addRemoteVideoElement(id);
    playVideo(video, stream);
    video.volume = 1.0;
  }

  function detachVideo(id) {
    let video = getRemoteVideoElement(id);
    pauseVideo(video);
    deleteRemoteVideoElement(id);
  }
  
  function isRemoteVideoAttached(id) {
    if (remoteVideos[id]) {
      return true;
    }
    else {
      return false;
    }
  }

  // --- RTCPeerConnections ---
  function stopConnection(id) {
    detachVideo(id);

    if (isConnectedWith(id)) {
      let peer = getConnection(id);
      peer.close();
      deleteConnection(id);
    }
  }

  function stopAllConnection() {
    for (let id in peerConnections) {
      stopConnection(id);
    }
  }

ソースの修正：シグナリングの変更

WebSocket直接利用から、socket.ioの利用に変わったので、シグナリングも変更します。

// ----- use socket.io ---
  let port = 3002;
  let socket = io.connect('http://localhost:/' + port + '/');
  let room = getRoomName();
  socket.on('connect', function(evt) {
    socket.emit('enter', room);
  });
  socket.on('message', function(message) {
    let fromId = message.from;

    if (message.type === 'offer') {
      // -- got offer ---
      let offer = new RTCSessionDescription(message);
      setOffer(fromId, offer);
    }
    else if (message.type === 'answer') {
      // --- got answer ---
      let answer = new RTCSessionDescription(message);
      setAnswer(fromId, answer);
    }
    else if (message.type === 'candidate') {
      // --- got ICE candidate ---
      let candidate = new RTCIceCandidate(message.ice);
      addIceCandidate(fromId, candidate);
    }
    else if (message.type === 'call me') {
      if (! isReadyToConnect()) {
        console.log('Not ready to connect, so ignore');
        return;
      }
      else if (! canConnectMore()) {
        console.warn('TOO MANY connections, so ignore');
      }

      if (isConnectedWith(fromId)) {
        // already connnected, so skip
        console.log('already connected, so ignore');
      }
      else {
        // connect new party
        makeOffer(fromId);
      }
    }
    else if (message.type === 'bye') {
      if (isConnectedWith(fromId)) {
        stopConnection(fromId);
      }
    }
  });
  socket.on('user disconnected', function(evt) {
    let id = evt.id;
    if (isConnectedWith(id)) {
      stopConnection(id);
    }
  });

  // --- broadcast message to all members in room
  function emitRoom(msg) {
    socket.emit('message', msg);
  }

  function emitTo(id, msg) {
    msg.sendto = id;
    socket.emit('message', msg);
  }

通信開始要求の”call me”や、切断要求の”bye”の処理を追加しています。また接続準備が整っていない場合（カメラやマイクを取得していない場合）や、すでに接続中の相手からの接続要求は無視するようにしています。

SDPやICE candidateのハンドリング

複数の相手とOffer/Answer SDPやICE candidateをやり取りするので、相手を意識した処理に拡張します。といっても違いは対応するRTCPeerConnectionのオブジェクトを生成したり取り出したりするところだけで、他は1対1の場合と同様です。すべてを掲載すると長いので全体はGitHubを参照してくただくとして、ここでは例を取り上げます。

Offer SDPの送信

新たに RTCPeerConnectionを生成し、Offer SDPの作成、送信を行います。

function makeOffer(id) {
    peerConnection = prepareNewConnection(id);
    addConnection(id, peerConnection);

    peerConnection.createOffer()
    .then(function (sessionDescription) {
      console.log('createOffer() succsess in promise');
      return peerConnection.setLocalDescription(sessionDescription);
    }).then(function() {
      console.log('setLocalDescription() succsess in promise');

      // -- Trickle ICEの場合は、初期SDPを相手に送る -- 
      sendSdp(id, peerConnection.localDescription);

      // -- Vanilla ICEの場合には、まだSDPは送らない --
    }).catch(function(err) {
      console.error(err);
    });
  }

  function sendSdp(id, sessionDescription) {
    let message = { type: sessionDescription.type, sdp: sessionDescription.sdp };
    emitTo(id, message);
  }

Answer SDPを受け取った場合の処理

対応するRTCPeerConnectionを取り出し、Answer SDPを覚えさせます。

function setAnswer(id, sessionDescription) {
    let peerConnection = getConnection(id);
    if (! peerConnection) {
      console.error('peerConnection NOT exist!');
      return;
    }

    peerConnection.setRemoteDescription(sessionDescription)
    .then(function() {
      console.log('setRemoteDescription(answer) succsess in promise');
    }).catch(function(err) {
      console.error('setRemoteDescription(answer) ERROR: ', err);
    });
  }

ICE candidateのやりとりなども、同様に対応するRTCPeerConnectionのオブジェクトを取り出して行います。また、手動シグナリングで使っていたSDPをテキストエリアに表示する部分も取り除きました。

カメラ、マイクの取得

前回までは映像だけでしたが、今回はマイクの音声も取得してより実用的にしましょう。ただし1台のPCでやる場合はハウリングしてしまうので、ヘッドフォンを使ってください。

// start local video
  function startVideo() {
    getDeviceStream({video: true, audio: true})
    .then(function (stream) { // success
      localStream = stream;
      playVideo(localVideo, stream);
    }).catch(function (error) { // error
      console.error('getUserMedia error:', error);
      return;
    });
  }

getDeviceStream()は、新旧getUserMedia()をラップするために用意した関数です。これにaudio:trueの指定を渡してマイクも取得しています。

今回マイクの音声も取得するようにしたため、メディアストリームにはビデオとオーディオの2つのトラックが含まれます。このため、相手側のRTCPeerConnectionのontrack()イベントが2回呼び出されますが、2回目は無視するように修正しました。（RTCPeerConnection.ontrack()は現在Firefoxのみがサポートしています）

function prepareNewConnection(id) {
    let pc_config = {"iceServers":[]};
    let peer = new RTCPeerConnection(pc_config);

    // --- on get remote stream ---
    if ('ontrack' in peer) {
      peer.ontrack = function(event) {
        let stream = event.streams[0];
        if (isRemoteVideoAttached(id)) {
          console.log('stream already attached, so ignore'); // <--- 同じ相手からの2回目以降のイベントは無視する
        }
        else {
          //playVideo(remoteVideo, stream);
          attachVideo(id, stream);
        }
      };
    }
    else {
      peer.onaddstream = function(event) {
        let stream = event.stream;
        console.log('-- peer.onaddstream() stream.id=' + stream.id);
        //playVideo(remoteVideo, stream);
        attachVideo(id, stream);
      };
    }

    // ... 省略 ....
  }

全体のソース

主要な部分は以上の通りですが、他にも細かい修正があります。全体のソースはGitHubでご覧ください。

• クライアント用のソース … GitHubで見る
• シグナリングサーバーのソース … GitHubで見る

接続してみよう

今回のサンプルでは4人まで同時に通信できるようにしてみました。それぞれブラウザを立ち上げて[Start Video]→[Connect]の順にボタンをクリックし接続してください。このように複数の相手と接続できるはずです。

※localhost以外に繋ぐときは、Chromeではカメラ/マイクの取得に失敗します。その場合はFirefoxをご利用ください。

次回は

今回のサンプルでは複数人で同時にビデオチャットができるようにしました。が、Chromeではhttp://～で/getUserMedia()が許可されていないため、他のPCと通信するのは厄介です。

Webサーバだけであれば、GitHub Pagesなどでhttps://～を利用することができますが、シグナリングサーバーのWebSocket通信も暗号化する必要がありまり、そちらは自分で証明書を取って対処しなけばなりません。/

そこで次回は番外編として、Firebaseを使った暗号化通信をシグナリングに利用した例をご紹介したいと思います。

こんにちは！ 2014年に連載した「WebRTCを使ってみよう！」シリーズのアップデート記事も3回目となりました。今回は、前回の「手動」で行ったP2P通信の準備を、自動で行えるようにしてみましょう。

シグナリングサーバーを立てよう

前回は手動でコピー＆ペーストを行い、WebRTCのP2P通信を始めるために次の情報を交換しました。

• SDP
• ICE candidate

今回はこれを仲介するサーバー（シグナリングサーバー）を動かしてみましょう。方法として次の2つをご用意しました。

• Node.jsを使ったシグナリングサーバー
• Chromeアプリ

Node.jsを準備しよう

まず、WebSocketを使ってシグナリングを行う方法をご紹介します。WebSocketの扱いやすさから、ここではNode.jsを使います。（もちろん他の言語を使っても同様にシグナリングサーバーを作ることができます）こちらの公式サイトから、プラットフォームに対応したNode.jsを入手してインストールしてください。今回私は 4.4.7 LTSを使いました。

Node.jsのインストールが完了したら、次はWebSocketサーバー用のモジュールをインストールします。コマンドプロンプト/ターミナルから、 次のコマンドを実行してください。 ※必要に応じて、sudoなどをご利用ください。

npm install ws

※以前の連載ではsocket.ioを使いましたが、今回はよりプリミティブなwsを使っています。

シグナリングサーバーを動かそう

次のコードを好きなファイル名で保存してください。（例えば signaling.js)

"use strict";

let WebSocketServer = require('ws').Server;
let port = 3001;
let wsServer = new WebSocketServer({ port: port });
console.log('websocket server start. port=' + port);

wsServer.on('connection', function(ws) {
  console.log('-- websocket connected --');
  ws.on('message', function(message) {
    wsServer.clients.forEach(function each(client) {
      if (isSame(ws, client)) {
        console.log('- skip sender -');
      }
      else {
        client.send(message);
      }
    });
  });
});

function isSame(ws1, ws2) {
  // -- compare object --
  return (ws1 === ws2);     
}

ポート番号は必要に応じて変更してください。起動するにはコマンドプロンプト/ターミナルから、 次のコマンドを実行します。

node signaling.js

シグナリングサーバーの動作はシンプルで、クライアントからメッセージを受け取ったら他のクライアントに送信するだけです。

Chromeアプリを使う場合は

場合によってはNode.jsをインストールして動かすのは、ハードルが高くて難しいケースもあるかもしれません。そんな人のために、Chromeアプリで「simple message server」というものを作ってみました。
Chromeを利用したアプリとしてインストールし、アプリタブから起動して利用します。デスクトップ用のChromeが動く環境（Windows, MaxOS X, Linux, ChromeOS）で動くはずです。

起動すると、 ws://localhost:3001/ でクライアントからの接続を待ち受けます。※実装があまいので時々不安定になります。その場合は[restart]ボタンを押してリセットし、ブラウザもリロードして接続しなおしてください。

シグナリング処理を変更しよう

それでは前回の手動シグナリングのコードを、少しずつ変更していきましょう。まずWebSocketで用意したシグナリングサーバーに接続します。JavaScriptに次の処理を追加してください。（URLは使っているポートに合わせて修正してください）

let wsUrl = 'ws://localhost:3001/';
  let ws = new WebSocket(wsUrl);
  ws.onopen = function(evt) {
    console.log('ws open()');
  };
  ws.onerror = function(err) {
    console.error('ws onerror() ERR:', err);
  };

次に、WebSocketでメッセージを受け取った場合の処理を追加します。

ws.onmessage = function(evt) {
    console.log('ws onmessage() data:', evt.data);
    let message = JSON.parse(evt.data);
    if (message.type === 'offer') {
      // -- got offer ---
      console.log('Received offer ...');
      textToReceiveSdp.value = message.sdp;
      let offer = new RTCSessionDescription(message);
      setOffer(offer);
    }
    else if (message.type === 'answer') {
      // --- got answer ---
      console.log('Received answer ...');
      textToReceiveSdp.value = message.sdp;
      let answer = new RTCSessionDescription(message);
      setAnswer(answer);
    }
  };

JSONテキストからオブジェクトを復元し、typeに応じて前回用意したsetOffer()/setAnswer()を呼び出し、RTCPeerConnectionに渡しています。

SDPの送信

Offer/AnswerのSDPの送信も、WebSocket経由で行います。前回要したsendSdp()を次のように変更します。

function sendSdp(sessionDescription) {
    console.log('---sending sdp ---');

    textForSendSdp.value = sessionDescription.sdp;
    /*--- テキストエリアをハイライトするのを止める
    textForSendSdp.focus();
    textForSendSdp.select();
    ----*/

    // --- シグナリングサーバーに送る ---
    let message = JSON.stringify(sessionDescription);
    console.log('sending SDP=' + message);
    ws.send(message);
  }

SDPをJSONテキストに変換してWebSocketでシグナリングサーバーに送信しています。

実際に動かしてみよう

シグナリングサーバーを起動して、ChromeかFirefoxのウィンドウを2つ開いて修正したHTMLを読み込んでください。ChromeとFirefoxの間で通信することもできます。

Webサーバーを立てるのが難しい場合は、GitHub Pages にもサンプルを公開しているので、そちらで試すこともできます。その場合でもシグナリングサーバーは自分で用意する必要があるのでご注意ください。

• GitHub Pages で試す ws_signaling_1to1_vanilla.html
  • ※http://～/ なのでFirefoxのみ
• GitHub でソースを見る ws_signaling_1to1_vanilla.html

(1) カメラの取得

両方のウィンドウで[Start Video]ボタンをクリックします。カメラのアクセスを許可すると、それぞれリアルタイムの映像が表示されます。

(2) 通信開始

どちらかのウィンドウで[Connect]ボタンを押します。(3)SDP（ICE candidateを含む）が自動で交換され、(4)ビデオ通信が始まります。

手動シグナリングに比べて操作がずっと簡単になりました。これなら実際に利用できそうですね。

Trickle ICE を使ってみよう

コピー＆ペーストを手動で行う必要がなくなったので、ICE candidateを発生するたびに交換するTrickle ICE を使ってみましょう。流れはこのような形になります。

すべてのICE candidateが出そろう前にP2P通信が確立する（ことがある）メリットがあります。（※2014年の記事では「すべてのICE candidateの交換が終わるとP2P通信が始まる」と書いていましたが、これは誤りです）

SDPをすぐに送信する

Offer SDP/Answer SDPを生成したら、すぐに相手に送るように変更します。

function makeOffer() {
    peerConnection = prepareNewConnection();
    peerConnection.createOffer()
    .then(function (sessionDescription) {
      console.log('createOffer() succsess in promise');
      return peerConnection.setLocalDescription(sessionDescription);
    }).then(function() {
      console.log('setLocalDescription() succsess in promise');

      // -- Trickle ICE の場合は、初期SDPを相手に送る -- 
      sendSdp(peerConnection.localDescription);　// <--- ここを加える

      // -- Vanilla ICE の場合には、まだSDPは送らない --
    }).catch(function(err) {
      console.error(err);
    });
  }

  function makeAnswer() {
    console.log('sending Answer. Creating remote session description...' );
    if (! peerConnection) {
      console.error('peerConnection NOT exist!');
      return;
    }
    
    peerConnection.createAnswer()
    .then(function (sessionDescription) {
      console.log('createAnswer() succsess in promise');
      return peerConnection.setLocalDescription(sessionDescription);
    }).then(function() {
      console.log('setLocalDescription() succsess in promise');

      // -- Trickle ICE の場合は、初期SDPを相手に送る -- 
      sendSdp(peerConnection.localDescription);　// <--- ここを加える

      // -- Vanilla ICE の場合には、まだSDPは送らない --
    }).catch(function(err) {
      console.error(err);
    });
  }

ICE candidateも、すぐに交換する

ICE candidateを収集した際も、すぐに送るように変更します。

function prepareNewConnection() {
    // ... 省略 ...

    // --- on get local ICE candidate
    peer.onicecandidate = function (evt) {
      if (evt.candidate) {
        console.log(evt.candidate);

        // Trickle ICE の場合は、ICE candidateを相手に送る
        sendIceCandidate(evt.candidate); // <--- ここを追加する

        // Vanilla ICE の場合には、何もしない
      } else {
        console.log('empty ice event');

        // Trickle ICE の場合は、何もしない
        
        // Vanilla ICE の場合には、ICE candidateを含んだSDPを相手に送る
        //sendSdp(peer.localDescription); // <-- ここをコメントアウトする
      }
    };

    // ... 省略 ....
  }

  function sendIceCandidate(candidate) {
    console.log('---sending ICE candidate ---');
    let obj = { type: 'candidate', ice: candidate };
    let message = JSON.stringify(obj);
    console.log('sending candidate=' + message);
    ws.send(message);
  }

合わせてICE candidateをWebSocket経由で受け取った場合の処理も追加しましょう。相手からICE candidateを受け取ったら、その度にRTCPeerConnection.addIceCandidate()で覚えさせます。

ws.onmessage = function(evt) {
    console.log('ws onmessage() data:', evt.data);
    let message = JSON.parse(evt.data);
    if (message.type === 'offer') {
      // -- got offer ---
      console.log('Received offer ...');
      textToReceiveSdp.value = message.sdp;
      let offer = new RTCSessionDescription(message);
      setOffer(offer);
    }
    else if (message.type === 'answer') {
      // --- got answer ---
      console.log('Received answer ...');
      textToReceiveSdp.value = message.sdp;
      let answer = new RTCSessionDescription(message);
      setAnswer(answer);
    }
    else if (message.type === 'candidate') { // <--- ここから追加
      // --- got ICE candidate ---
      console.log('Received ICE candidate ...');
      let candidate = new RTCIceCandidate(message.ice);
      console.log(candidate);
      addIceCandidate(candidate);
    }
  };

  function addIceCandidate(candidate) {
    if (peerConnection) {
      peerConnection.addIceCandidate(candidate);
    }
    else {
      console.error('PeerConnection not exist!');
      return;
    }
  }

さあ、これで修正は完了です。

Trickle ICEを実行しよう

手順はVanilla ICEの場合と同じです。シグナリングサーバーを起動して、ChromeかFirefoxのウィンドウを2つ開いて修正したHTMLを読み込んでください。あとは同様に[Start Video]→[Connect]です。

見た目も特に変わりはありません。もしかしたら人によっては早く繋がるのを実感できるかもしれません。

GitHub Pages/GitHubも用意しています。

• GitHub Pages で試す ws_signaling_1to1_trickle.html
  • ※http://～/ なのでFirefoxのみ。シグナリングサーバーは別途localhost上で起動しておく必要があります
• GitHub でソースを見る ws_signaling_1to1_trickle.html

2台のPC間の通信

ここまできたら、せっかくなので2台の別々のPCで通信してみたくなります。同じネットワークに属するPC同士ならば通信できるはずです。例として次のような状況を考えてみましょう。

• IPアドレスが 192.168.0.2 と、 192.168.0.3 の2台のPCがある
• 前者(192.168.0.2)のポート:8080でWebサーバー、ポート:3001でNode.jsのシグナリングサーバーが動いている
  
  

Firefoxの場合は、接続するURLを変更すれば問題なく動きます。やっかいなのはChromeの場合です。

• Chromeでは、カメラやマイクにアクセスするためのgetUserMedia()が、原則としてhttp://～では許可されていない/
• http://localhost/～ は例外的な扱いで許可されている
  
  

きちんと対処すると、次のような対策が必要です。ちょっと試すにはハードルが高いですよね。

• 証明書を取得して https://～/ でアクセスするように、Webサーバーに設定
• 合わせて、シグナリングサーバーも wss://～ の暗号化通信を使うように設定

そこで実験的に無理やり動かすには、次のような方法があります。Webサーバーとシグナリングサーバーは同一である必要はなく、また異なるWebサーバーでも構わないことを利用しています。

お勧めはしませんが、どうしてもやりたい場合の参考としてどうぞ。

次回は

今回はNode.jsとWebSocketを使ったシグナリングを実現しました。残念ながら今回の仕組みでは、1対1の通信しか行うことができません。次回はこれを拡張し、複数人で同時に通信できるようにしたいと思います。

オマケ：WebRTCの仕様の差分のおさらい

オマケとして、今回のWebRTC再入門2016シリーズで取り上げているWebRTC関連仕様の変更箇所について、おさらいしおきましょう。(2016年6月現在）

getUserMeida

• navigator.mediaDevices.getUserMedia() が新しく用意された
  • 旧APIの navigator.getUserMedia()は Firefoxでは非推奨
• ベンダープレフィックスが取れた
• コールバックではなくPromiseベースになった
• Firefox, Edge で利用可能。Chromeではフラグ指定が必要

ベンダープレフィックスの除去

• Firefoxでは、主要なオブジェクトのベンダープレフィックスが取れた。mozプレフィックス付は非推奨に
  • 新：RTCPeerConnection, RTCSessionDescription, RTCIceCandidate
  • 旧：mozRTCPeerConnection, mozRTCSessionDescription, mozRTCIceCandidate　（非推奨）
• ただしChromeでは、一部ベンダープレフィックス付のまま
  • プレフィックス有り： webkitRTCPeerConnection
  • プレフィックス無し： RTCSessionDescription, RTCIceCandidate

RTCPeerConnection

• 主要なメソッドがPromiseベースになった
  • createOffer(), createAnswer()
  • setLocalDescription(), setRemoteDescription()
• メディアストリーム処理の新しいイベントハンドラontrack()が追加、onaddstream()は非推奨
  • Firefoxではサポート済、Chromeでは未サポート

仕様は常に更新されていますし、ブラウザの実装状況も異なります。最新の情報もご確認ください。

こんにちは！ がねこまさしです。2014年に連載した「WebRTCを使ってみよう！」シリーズを、2016年6月の最新情報に基づき、内容をアップデートして改めてお届けしています。1回目はカメラにアクセスしてみました。2回目となる今回は、WebRTCの通信の仕組みを実感するために、「手動」でP2P通信をつなげてみましょう。

WebRTCの通信はどうなっているの？

WebRTCでは、映像/音声/アプリケーションデータなどをリアルタイムにブラウザ間で送受信することができます。それをつかさどるのが「RTCPeerConnection」です。 RTCPeerConnectionには3つの特徴があります。

• Peer-to-Peer(P2P)の通信 → ブラウザとブラウザの間で直接通信する
• UDP/IPを使用 → TCP/IPのようにパケットの到着は保障しないが、オーバーヘッドが少ない
• PeerとPeerの間で暗号化通信を行う → P2P通信の前に鍵の交換を行う

多少の情報の欠落があっても許容する替わりに、通信のリアルタイム性を重視しています。UDPのポート番号は動的に割り振られ、49152 ～ 65535の範囲が使われるようです。

P2P通信を確立するまで

ブラウザ間でP2P通信を行うには、相手のIPアドレスを知らなくてはなりませんし、動的に割り振られるUDPのポート番号も知る必要があります。また、その通信でやり取りできる内容についても、お互い合意しておく必要があります。そのためP2P通信が確立するまでに、WebRTCではいくつかの情報をやり取りしています。

Session Description Protocol (SDP)

各ブラウザが通信した内容を示し、テキストで表現されます。例えば次のような情報を含んでいます。

• 通信するメディアの種類（音声、映像）、メディアの形式（コーデック）、アプリケーションデータ
• IPアドレス、ポート番号
• 暗号化の鍵
• セッションの属性（名前、識別子、アクティブな時間など）→ WebRTCでは使っていないようです

ICE Candidate

P2P通信を行う際にどのような通信経路が使えるかは、お互いのネットワーク環境に依存します。通信経路を定めるための仕組みが「Interactive Connectivity Establishment (ICE)」で、その通信経路の候補が「ICE Candidate」になります。WebRTCの通信を始める前に、可能性のある候補がリストアップされます。

• P2Pによる直接通信
• NATを通過するためのSTUNサーバーから取得したポートマッピング → 最終的にはP2Pになる
• Firefallを越えるための、TURNによるリレーサーバーを介した中継通信

候補が見つかったら順次通信を試み、最初につながった経路が採用されます。

手動シグナリングを実験してみよう

このように、P2Pを始めるまでの情報のやり取りを「シグナリング」と言います。実は、WebRTCではシグナリングのプロトコルは規定されていません（自由に選べます）。シグナリングを実現するにはWebSocketを使うなど複数の方法がありますが、今回は最も原始的な方法であるコピー＆ペーストを試してみましょう。

ちょっと長いですが、こちらのHTMLをお好きなWebサーバーに配置してください。

<!doctype html>
<html>
<head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
 <title>Hand Signaling</title>
</head>
<body>
  Hand Signaling 2016<br />
  <button type="button" onclick="startVideo();">Start Video</button>
  <button type="button" onclick="stopVideo();">Stop Video</button>
  &nbsp;
  <button type="button" onclick="connect();">Connect</button>
  <button type="button" onclick="hangUp();">Hang Up</button> 
  <div>
    <video id="local_video" autoplay style="width: 160px; height: 120px; border: 1px solid black;"></video>
    <video id="remote_video" autoplay style="width: 160px; height: 120px; border: 1px solid black;"></video>
  </div>
  <p>SDP to send:<br />
    <textarea id="text_for_send_sdp" rows="5" cols="60" readonly="readonly">SDP to send</textarea>
  </p>
  <p>SDP to receive:&nbsp;
    <button type="button" onclick="onSdpText();">Receive remote SDP</button><br />
    <textarea id="text_for_receive_sdp" rows="5" cols="60"></textarea>
  </p>
</body>
<script type="text/javascript">
  let localVideo = document.getElementById('local_video');
  let remoteVideo = document.getElementById('remote_video');
  let localStream = null;
  let peerConnection = null;
  let textForSendSdp = document.getElementById('text_for_send_sdp');
  let textToReceiveSdp = document.getElementById('text_for_receive_sdp');

  // --- prefix -----
  navigator.getUserMedia  = navigator.getUserMedia    || navigator.webkitGetUserMedia ||
                            navigator.mozGetUserMedia || navigator.msGetUserMedia;
  RTCPeerConnection = window.RTCPeerConnection || window.webkitRTCPeerConnection || window.mozRTCPeerConnection;
  RTCSessionDescription = window.RTCSessionDescription || window.webkitRTCSessionDescription || window.mozRTCSessionDescription;

  // ---------------------- media handling ----------------------- 
  // start local video
  function startVideo() {
    getDeviceStream({video: true, audio: false})
    .then(function (stream) { // success
      localStream = stream;
      playVideo(localVideo, stream);
    }).catch(function (error) { // error
      console.error('getUserMedia error:', error);
      return;
    });
  }

  // stop local video
  function stopVideo() {
    pauseVideo(localVideo);
    stopLocalStream(localStream);
  }

  function stopLocalStream(stream) {
    let tracks = stream.getTracks();
    if (! tracks) {
      console.warn('NO tracks');
      return;
    }
    
    for (let track of tracks) {
      track.stop();
    }
  }
  
  function getDeviceStream(option) {
    if ('getUserMedia' in navigator.mediaDevices) {
      console.log('navigator.mediaDevices.getUserMadia');
      return navigator.mediaDevices.getUserMedia(option);
    }
    else {
      console.log('wrap navigator.getUserMadia with Promise');
      return new Promise(function(resolve, reject){    
        navigator.getUserMedia(option,
          resolve,
          reject
        );
      });      
    }
  }

  function playVideo(element, stream) {
    if ('srcObject' in element) {
      element.srcObject = stream;
    }
    else {
      element.src = window.URL.createObjectURL(stream);
    }
    element.play();
    element.volume = 0;
  }

  function pauseVideo(element) {
    element.pause();
    if ('srcObject' in element) {
      element.srcObject = null;
    }
    else {
      if (element.src && (element.src !== '') ) {
        window.URL.revokeObjectURL(element.src);
      }
      element.src = '';
    }
  }

  // ----- hand signaling ----
  function onSdpText() {
    let text = textToReceiveSdp.value;
    if (peerConnection) {
      console.log('Received answer text...');
      let answer = new RTCSessionDescription({
        type : 'answer',
        sdp : text,
      });
      setAnswer(answer);
    }
    else {
      console.log('Received offer text...');
      let offer = new RTCSessionDescription({
        type : 'offer',
        sdp : text,
      });
      setOffer(offer);
    }
    textToReceiveSdp.value ='';
  }
 
  function sendSdp(sessionDescription) {
    console.log('---sending sdp ---');
    textForSendSdp.value = sessionDescription.sdp;
    textForSendSdp.focus();
    textForSendSdp.select();
  }

  // ---------------------- connection handling -----------------------
  function prepareNewConnection() {
    let pc_config = {"iceServers":[]};
    let peer = new RTCPeerConnection(pc_config);

    // --- on get remote stream ---
    if ('ontrack' in peer) {
      peer.ontrack = function(event) {
        console.log('-- peer.ontrack()');
        let stream = event.streams[0];
        playVideo(remoteVideo, stream);
      };
    }
    else {
      peer.onaddstream = function(event) {
        console.log('-- peer.onaddstream()');
        let stream = event.stream;
        playVideo(remoteVideo, stream);
      };
    }

    // --- on get local ICE candidate
    peer.onicecandidate = function (evt) {
      if (evt.candidate) {
        console.log(evt.candidate);

        // Trickle ICE の場合は、ICE candidateを相手に送る
        // Vanilla ICE の場合には、何もしない
      } else {
        console.log('empty ice event');

        // Trickle ICE の場合は、何もしない
        // Vanilla ICE の場合には、ICE candidateを含んだSDPを相手に送る
        sendSdp(peer.localDescription);
      }
    };

    
    // -- add local stream --
    if (localStream) {
      console.log('Adding local stream...');
      peer.addStream(localStream);
    }
    else {
      console.warn('no local stream, but continue.');
    }

    return peer;
  }

  function makeOffer() {
    peerConnection = prepareNewConnection();
    peerConnection.createOffer()
    .then(function (sessionDescription) {
      console.log('createOffer() succsess in promise');
      return peerConnection.setLocalDescription(sessionDescription);
    }).then(function() {
      console.log('setLocalDescription() succsess in promise');

      // -- Trickle ICE の場合は、初期SDPを相手に送る -- 
      // -- Vanilla ICE の場合には、まだSDPは送らない --
      //sendSdp(peerConnection.localDescription);
    }).catch(function(err) {
      console.error(err);
    });
  }

  function setOffer(sessionDescription) {
    if (peerConnection) {
      console.error('peerConnection alreay exist!');
    }
    peerConnection = prepareNewConnection();
    peerConnection.setRemoteDescription(sessionDescription)
    .then(function() {
      console.log('setRemoteDescription(offer) succsess in promise');
      makeAnswer();
    }).catch(function(err) {
      console.error('setRemoteDescription(offer) ERROR: ', err);
    });
  }
  
  function makeAnswer() {
    console.log('sending Answer. Creating remote session description...' );
    if (! peerConnection) {
      console.error('peerConnection NOT exist!');
      return;
    }
    
    peerConnection.createAnswer()
    .then(function (sessionDescription) {
      console.log('createAnswer() succsess in promise');
      return peerConnection.setLocalDescription(sessionDescription);
    }).then(function() {
      console.log('setLocalDescription() succsess in promise');

      // -- Trickle ICE の場合は、初期SDPを相手に送る -- 
      // -- Vanilla ICE の場合には、まだSDPは送らない --
      //sendSdp(peerConnection.localDescription);
    }).catch(function(err) {
      console.error(err);
    });
  }

  function setAnswer(sessionDescription) {
    if (! peerConnection) {
      console.error('peerConnection NOT exist!');
      return;
    }

    peerConnection.setRemoteDescription(sessionDescription)
    .then(function() {
      console.log('setRemoteDescription(answer) succsess in promise');
    }).catch(function(err) {
      console.error('setRemoteDescription(answer) ERROR: ', err);
    });
  }
  
  // start PeerConnection
  function connect() {
    if (! peerConnection) {
      console.log('make Offer');
      makeOffer();
    }
    else {
      console.warn('peer already exist.');
    }
  }

  // close PeerConnection
  function hangUp() {
    if (peerConnection) {
      console.log('Hang up.');
      peerConnection.close();
      peerConnection = null;
      pauseVideo(remoteVideo);
    }
    else {
      console.warn('peer NOT exist.');
    }
  }

</script>
</html>

GitHub Pagesでも公開していますので、すぐに試すことができます。

• GitHub Pages で試す hand_signaling.html (Chromeもフラグ設定不要）
• GitHub でソースを見る hand_signaling.html
• Safari Technology Preview 対応版を試す hand_signaling_track.html
• Safari Technology Preview 対応版のソース hand_signaling_track.html

次に、PCにWebカメラを接続してからFirefox 47 またはChrome 51でアクセスしてみてください。（※Chromeの場合はカメラ映像取得の制限があるので、https://～か/ http://localhost/～のWebサーバーが必要になります）残念ながら今回はEdgeでは利用できません。

通信するために2つページを開く必要があります。同一ウィンドウで複数タブを開くよりも、別のウィンドウで横に並べたほうが作業しやすいです。

接続手順

接続手順は2014年のものよりも簡略化しました。それでも間違えやすいので慎重に操作してくださいね。

(1) 映像の取得

両方のウィンドウで[Start Video]ボタンをクリックします。カメラのアクセスを許可すると、それぞれリアルタイムの映像が表示されます。

(2) 通信の開始

左のウィンドウで[Connect]ボタンをクリックしてください。すると[SDP to send:]のテキストエリアに、ドバドバっとSDPの文字列が表示されます。

(3)(4) SDPの送信（左→右）

(3)左の[SDP to send:]の内容をコピーし、(4)右の[SDP to receive:]の下のテキストエリアにペーストします。

(5) SDPの受信（右）

右の[Receive remote SDP]ボタンをクリックすると、今度は右のウィンドウの[SDP to send:]のテキストエリアに、ドバドバっとSDPの文字列が表示されます。

(6)(7) SDPの返信（左←右）

さっきと反対に(6)右の[SDP to send:]の内容をコピーし、(7)左の[SDP to receive:]の下のテキストエリアにペーストします。

(8) SDPの受信（左）

左の[Receive remote SDP]ボタンをクリックします。しばらくすると（～数秒）P2P通信が始まり両方のウィンドウに2つ目の動画が表示されるはずです。

上手くいかなかった場合は、コピー範囲が欠けているか、手順が抜けている可能性があります。深呼吸してから両方のブラウザをリロードし、もう一度試してみてください。

それでも通信できない場合は、実はネットワーク環境の問題の可能性があります。この記事の「トラブルシューティング」の章をご覧ください。（あるいはソースのバグや、説明の不備の可能性もあります。何かお気づきの際にはご指摘ください）

トラブルシューティング

これまで何度も手動シグナリングを試して/試していただいて、通信ができないケースがありました。当初は原因が分からなかったのですが、その後に判明したケースを説明します。

外部ネットワークにつながっていない場合

PCが全くネットワークに接続されていない状態では、カメラ映像の取得に成功しても通信ができません。これはネットワークに接続されていない状態では、通信経路の情報であるICE Candidateが収集できないためです。
例え同一PC内で通信を行う場合にも、外部に接続できる状態で利用する必要があります。

ハンズオン等で手動シグナリングを試してもらうことがあるのですが、長いことこの制約に気が付かず通信できないで悩んでいました。

Chrome – Firefox 間での通信

WebRTCではChrome – Chrome間や、Firefox – Firefox 間のように同一種類のブラウザ同士だけでなく、Chrome – Firefox間でも通信することができます。もちろん手動シグナリングでも同様です。
ところが実際に1台のPCで Firefox – Chrome 間で手動シグナリングを行おうとすると、カメラ映像の取得で衝突してしまうケースがあります。この場合は次のどちらかをお試しください

• (a) 2台のカメラをご用意して、ブラウザごとに違うカメラの映像を取得する
• (b) 映像は片方のブラウザのみで取得し、そのブラウザから[Connect]で通信を始める
  • → ※この場合は片方向の映像通信となります

裏側で起こっていること

それでは映像通信に成功したところで、その裏側で起きていることを見てみましょう。

Vanilla ICE と Trickle ICE

WebRTCのP2P通信を確立するためのシグナリングでは、次の2種類の情報を交換する必要があると説明しました。

• SDP
• ICE candidate

ところが今回の手動シグナリングではSDPしか交換していません。いったいぜんたい、ICE candidateの情報はどうなっているのでしょうか？

実はICE Candidateの情報は、今回交換しているSDPの中に含まれています。実際に私のPCで取得したSDPの一部を掲載します。（※IPアドレスは一部マスクしています）

m=video 58461 UDP/TLS/RTP/SAVPF 100 101 116 117 96 97 98
c=IN IP4 192.168.xxx.xxx
a=rtcp:58465 IN IP4 192.168.xxx.xxx
a=candidate:2999745851 1 udp 2122260223 192.168.xxx.xxx 58461 typ host generation 0 network-id 4
a=candidate:2747735740 1 udp 2122194687 192.168.xxx.xxx 58462 typ host generation 0 network-id 3
a=candidate:1606961068 1 udp 2122129151 10.2.xxx.xxx 58463 typ host generation 0 network-id 2
a=candidate:1435463253 1 udp 2122063615 192.168.xxx.xxx 58464 typ host generation 0 network-id 1
a=candidate:2999745851 2 udp 2122260222 192.168.xxx.xxx 58465 typ host generation 0 network-id 4
a=candidate:2747735740 2 udp 2122194686 192.168.xxx.xxx 58466 typ host generation 0 network-id 3
a=candidate:1606961068 2 udp 2122129150 10.2.xxx.xxx 58467 typ host generation 0 network-id 2
a=candidate:1435463253 2 udp 2122063614 192.168.xxx.xxx 58468 typ host generation 0 network-id 1
a=candidate:4233069003 1 tcp 1518280447 192.168.xxx.xxx 9 typ host tcptype active generation 0 network-id 4
a=candidate:3980714572 1 tcp 1518214911 192.168.xxx.xxx 9 typ host tcptype active generation 0 network-id 3
a=candidate:290175836 1 tcp 1518149375 10.2.xxx.xxx 9 typ host tcptype active generation 0 network-id 2
a=candidate:453808805 1 tcp 1518083839 192.168.xxx.xxx 9 typ host tcptype active generation 0 network-id 1
a=candidate:4233069003 2 tcp 1518280446 192.168.xxx.xxx 9 typ host tcptype active generation 0 network-id 4
a=candidate:3980714572 2 tcp 1518214910 192.168.xxx.xxx 9 typ host tcptype active generation 0 network-id 3
a=candidate:290175836 2 tcp 1518149374 10.2.xxx.xxx 9 typ host tcptype active generation 0 network-id 2
a=candidate:453808805 2 tcp 1518083838 192.168.xxx.xxx 9 typ host tcptype active generation 0 network-id 1
a=ice-ufrag:xxxxxxxxxxxxx
a=ice-pwd:xxxxxxxxxxxx

a=candidate: で始まる行がICE candidateになります。（※仮想化ソフトを入れている影響で複数のネットワークが候補になっています）。 SDPを最初に取得したときにはICE candidateの行は含まれず、その後ICE candidateが収集されるにしたがって、SDPの中に追加されます。
今回は全てのICE candidateが出そろった後に、SDPとまとめて交換しています。このような方式を “Vanilla ICE” と呼びます。

これに対して、初期のSDPを交換し、その後ICE Candidateを順次交換する方式を “Trickle ICE” と呼びます。すべてのICE candidateを交換し終わる前にP2P通信が始まることがあるので、Trickle ICEの方が一般的に早く接続が確立します。

Offer と Answer

SDPには通信を始める側(Offer)と、通信を受け入れる側(Answer)があります。必ずOffer → Answerの順番でやりとりする必要があります。

ソースコードを追いかけてみよう

Offer SDPの生成

それでは、SDP(+ ICE candidate)のやり取りをソースコードで見てみましょう。まずは[Connect]ボタンを押してSDPを生成するところまでです。（ソースコードは抜粋しています）

// start PeerConnection
  function connect() {
      makeOffer();
  }

  // Offer SDPを生成する
  function makeOffer() {
    peerConnection = prepareNewConnection(); // RTCPeerConnectionを生成し、必要なメッセージハンドラを設定

    peerConnection.createOffer()
    .then(function (sessionDescription) {
      return peerConnection.setLocalDescription(sessionDescription);
    }).then(function() {
      // -- Trickle ICE の場合は、初期SDPを相手に送る -- 
      // -- Vanilla ICE の場合には、まだSDPは送らない --
      //sendSdp(peerConnection.localDescription);  <-- Vanilla ICEなので、まだ送らない
    }).catch(function(err) {
      console.error(err);
    });
  }

発信側で[Connect]ボタンをクリックすると、次の処理が行われます。

• RTCPeerConnection のオブジェクトを生成
• RTCPeerConnection.createOffer() で Offer SDPを生成
• 生成したOffer SDPを、RTCPeerConnection.setLocalDescription()で覚える
• Trickle ICEの場合はすぐにSDPを送信するが、今回は送信しない

createOffer(), setLocalDescription()は非同期で処理が行われます。従来はコールバックで後続処理を記述していましたが、現在はPromiseを返すので、then()の中に処理を記述します。
※2014年の記事ではsetLocalDescription()が非同期であることを意識しおらず、誤った記述になっていました。

ICE candidateの収集

次は ICE candidateの収集です。ICE candidateの収集も非同期に行われるため、RTCPeerConnectionのイベントハンドラで行います。

function prepareNewConnection() {
    let pc_config = {"iceServers":[]};
    let peer = new RTCPeerConnection(pc_config);

    // --- on get local ICE candidate
    peer.onicecandidate = function (evt) {
      if (evt.candidate) { // ICE candidate が収集された場合
        console.log(evt.candidate);

        // Trickle ICE の場合は、ICE candidateを相手に送る
        // Vanilla ICE の場合には、何もしない
      } else { // ICE candidateの収集が完了した場合
        console.log('empty ice event');

        // Trickle ICE の場合は、何もしない
        // Vanilla ICE の場合には、ICE candidateを含んだSDPを相手に送る
        sendSdp(peer.localDescription);
      }
    };

    // ... 省略 ....

    // 通信対象の映像/音声ストリームを追加する
    if (localStream) {
      console.log('Adding local stream...');
      peer.addStream(localStream);
    }


    return peer;
  }

今回のコードではprepareNewConnection()の中でRTCPeerConnectionオブジェクトを生成し、各種イベントハンドラを設定しています。ICE candidateのためRTCPeerConnection.onicecandidateにイベントハンドラを記述しています。このイベントは複数回発生します。
全てのICE candidateを収集し終わると空のイベントが渡ってきます。このタイミングで最終的なSDPを相手に送信します。今回の手動シグナリングではsendSdp()の中でテキストエリアに表示しています。

Offser SDPの受信

応答側にOffer SDPをペーストして[Receive remote SDP]ボタンをクリックすると、onSdpText() → setOffer() と呼び出されます。

function onSdpText() {
    let text = textToReceiveSdp.value;
    if (peerConnection) { // Answerの場合
      // ... 省略 ...
    }
    else { // Offerの場合
      let offer = new RTCSessionDescription({
        type : 'offer',
        sdp : text,
      });
      setOffer(offer);
    }
    textToReceiveSdp.value ='';
  }

さらに setOffer()の中では次の処理が行われています。

• PeerConnectionのオブジェクトを生成
• 受け取ったOffer SDPを setRemoteDescription()で覚える。Promiseを使った非同期処理を行う
• 成功したら makeAnswer()の中でAnswer SDPを生成

  function setOffer(sessionDescription) {
      peerConnection = prepareNewConnection();
      peerConnection.setRemoteDescription(sessionDescription)
      .then(function() {
        makeAnswer();
      }).catch(function(err) {
        console.error('setRemoteDescription(offer) ERROR: ', err);
      });
    }

Answer SDPの生成→送信

makeAnswer()の中ではOfferの時と同様な処理が行われます。

function makeAnswer() {   
    peerConnection.createAnswer()
    .then(function (sessionDescription) {
      return peerConnection.setLocalDescription(sessionDescription);
    }).then(function() {
      // -- Trickle ICE の場合は、初期SDPを相手に送る -- 
      // -- Vanilla ICE の場合には、まだSDPは送らない --
      //sendSdp(peerConnection.localDescription);
    }).catch(function(err) {
      console.error(err);
    });
  }

• RTCPeerConnection.createAnswer() で Answer SDPを生成
• 生成したAnswer SDPを、RTCPeerConnection.setLocalDescription()で覚える。Promiseを使った非同期処理を行う
• Trickle ICEの場合はすぐにSDPを送信するが、今回は送信しない

この後 RTCPeerConnection.onicecandidate()でICE candidateを収集し、すべて揃ったらsendSdp()でOffer側に送り返します。

Answer SDPの受信

発信側にAnser SDPをペーストして[Receive remote SDP]ボタンをクリックすると、onSdpText() → setAnswer() と呼び出されます。

function onSdpText() {
    let text = textToReceiveSdp.value;
    if (peerConnection) { // Answerの場合
      let answer = new RTCSessionDescription({
        type : 'answer',
        sdp : text,
      });
      setAnswer(answer);
    }
    else { // Offerの場合
      // ... 省略 ...
    }
    textToReceiveSdp.value ='';
  }

  function setAnswer(sessionDescription) {
    peerConnection.setRemoteDescription(sessionDescription)
    .then(function() {
      console.log('setRemoteDescription(answer) succsess in promise');
    }).catch(function(err) {
      console.error('setRemoteDescription(answer) ERROR: ', err);
    });
  }

setAnswer()の中ではRTCPeerConnection.setRemoteDescription()で受け取ったSDPを覚えます。

映像/音声の送受信

PeerConnectionのオブジェクトを生成した際に、送信する映像/音声ストリームをRTCPeerConnection.addStream()で指定しておきます。

function prepareNewConnection() {
    let pc_config = {"iceServers":[]};
    let peer = new RTCPeerConnection(pc_config);

    // ... 省略 ...

    // -- add local stream --
    if (localStream) {
      peer.addStream(localStream);
    }

    return peer;
  }

SDPの交換が終わると、P2P通信に相手の映像/音声が含まれていればイベントが発生します。従来はRTCPeerConnection.onaddstream() にハンドラを記述していましたが、新しいイベントが策定されRTCPeerConnection.ontrack() にハンドラを記述するようになっています。Firefoxはontrack()がすでに使えるようになっていて、onaddstream()は非推奨になっています。（Chromeは未対応です）

function prepareNewConnection() {
    let pc_config = {"iceServers":[]};
    let peer = new RTCPeerConnection(pc_config);

    // --- on get remote stream ---
    if ('ontrack' in peer) {
      peer.ontrack = function(event) {
        let stream = event.streams[0];
        playVideo(remoteVideo, stream);
      };
    }
    else {
      peer.onaddstream = function(event) {
        let stream = event.stream;
        playVideo(remoteVideo, stream);
      };
    }

    // ... 省略 ....
  }

以上で主要な処理の解説は終わりです。

次回は

今回は手動で情報交換を行い、原始的なビデオチャットを動かしてみました。P2P通信が確立するまでの動きを実感していただけたのではないでしょうか？

実際の利用場面では手動シグナリングなんかやってらません。次回はシグナリングサーバーを使って、通信を行ってみたいと思います。

こんにちは！ がねこまさしです。2014年に連載した「WebRTCを使ってみよう！」シリーズですが、内容がすっかり古くなってしまいました。そこで2016年6月の最新情報に基づき、内容をアップデートして改めてお届けしたいと思います。

WebRTCとは？

WebRTCとは”Web Real-Time Communication”の略で、Webブラウザ上でビデオ/オーディオの通信や、データ通信を行うための規格です。HTML5で新しく策定されたもので、複数の技術の連携で成り立っています。 ちなみに策定には複数の団体が絡んでいています。

• API → W3C
• ビデオ/オーディオのコーデック → IETF

APIの策定作業はWebRTC 1.0に向けて大詰めに入っています。またより詳細な低レベルのAPIを定義しているORTCも登場し、将来の統合に向けた動きも始まっています。

コーデックの選定では、ブラウザがサポートしなければならないビデオコーデックに、既にデファクトスタンダードともいえるH.264が加わりました。また、Googleが開発しているオープンソースのビデオコーデック「VP9」をサポートするブラウザも増えています。

WebRTCで何ができるの？

WebRTCは厳密に言うとビデオ/オーディオ/データ通信を行うための仕組みですが、他にも関連が深い技術があります。この連載では3つをまとめてWebRTC（とその仲間たち）ということで扱います。

• カメラ、マイクといったデバイスへのアクセスする … Media Capture and Streams
• ビデオ/オーディオ/データ通信を行う … WebRTC 1.0: Real-time Communication Between Browsers
• ビデオ/オーディオの録画/録音を行う … MediaStream Recording

この3兄弟に、HTML5の様々な要素を組み合わせて活用することができます。

• JavaScript（大前提）
• videoタグ、audioタグ
• CSS3
• Canvas
• WebGL
• Web Audio API
• WebSocket

新しいAPIでカメラを使ってみよう

カメラやマイクと言ったデバイスにアクセスするには、従来はnavigator.getUserMedia()というAPIを使いました。2016年6月現在では、これに代わる新しいAPIが登場しています。

• navigator.mediaDevices.getUserMedia() になった
• ベンダープレフィックスが取れた
• コールバックではなくPromiseベースになった

またデスクトップブラウザの場合は次のブラウザで利用することができます。

• Firefox 47 … 利用可能
• Chrome 51 … 利用する場合にはフラグ設定が必要
  • chrome://flagsというURLを開く
  • 「試験運用版のウェブ プラットフォームの機能 #enable-experimental-web-platform-features」を有効に
  • Chromeを再起動
• Edge 25 … Windows 10 のEdgeでも利用可能

サンプルコード

それではカメラから映像を取得してみましょう。サンプルコードはこちらです。

<!doctype html>
<html>
<head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
 <title>Camera with mediaDevice</title>
</head>
<body>
  <button onclick="startVideo()">Start</button>
  <br />
  <video id="local_video" autoplay style="width: 320px; height: 240px; border: 1px solid black;"></video>
</body>
<script type="text/javascript">
  let localVideo = document.getElementById('local_video');
  let localStream;
  
  // start local video
  function startVideo() {
    navigator.mediaDevices.getUserMedia({video: true, audio: false})
    .then(function (stream) { // success
      localStream = stream;
      localVideo.src = window.URL.createObjectURL(localStream);
    }).catch(function (error) { // error
      console.error('mediaDevice.getUserMedia() error:', error);
      return;
    });
  }
</script>
</html>

このHTMLファイルに、（Webサーバ経由で）ブラウザからアクセスしてみてください。GitHub Pagesでも公開していますので、すぐに試すことができます。

• GitHub Pages で試す camera_new.html（※Chromeの場合は、上記のフラグ設定が必要です）
• GitHub でソースを見る camera_new.html

ブラウザで[Start]ボタンをクリックすると、カメラへのアクセスの許可を求めるダイアログが表示されますので、許可してください。
Firefoxの場合

Chromeの場合

Edgeの場合

ウィンドウの下の部分にこのように表示されます。他のブラウザと違うので、ちょっと気が付きにくいかもしれません。

すると、このようにカメラの映像が表示されるはずです。

HTMLファイルの置き場所

カメラやマイクにアクセスするには、サンプルのHTMLファイルをWebサーバーに配置する必要がありますが、実はブラウザによって条件が異なります。

• Chromeの場合 … 原則 https://～/ のみ。例外として http://localhost/～ でも利用可能
• Firefoxの場合 … https://～/ および http://～/ の両方で利用可能。さらに file://～ でも利用可能
• Edgeの場合 … https://～/ および http://～/ の両方で利用可能。さらに file://～ でも利用可能

FirefoxやEdgeの場合は、ローカルのHTMLファイルを直接読み込んでも、利用可能です。

トラブルシューティング

カメラのアクセスの許可を求められた際に「常に拒否」すると、そのサイトからはカメラの映像を取得することができなくなります。その場合は明示的に再許可してあげる必要があります。

Firefoxの場合で「許可」または「毎回確認する」を選択

Chromeの場合「常に許可する」を選択

Edgeの場合
※いまのところ「常に拒否」することはできないようなので、このケースは発生しません。

新旧 getUserMedia() をラップしてみると

新しいAPIである navigator.mediaDevices.getUserMedia()は、まだChromeではデフォルトの状態では使えません。これは、引数で渡すオプションの指定方法が、まだ新しい書き方に沿っていないことが原因です。

let deviceID = getSelectedIDsomehow(); // デバイスIDを指定する

// Firefoxの場合
let constraints = {
  audio: false,
  video: { 
   deviceId: {exact: deviceID}
  }
};

// Chromeの場合
let constraintsForChrome = {
  audio: false,
  video: {
    optional: [{sourceId: deviceID}]
  }
};

そのため、Chromeではしばらく新しいAPIはデフォルトでは使えない状態が続くと思われます。そこで古いAPIをPromise型にラップする例を用意してみました。（オプション指定の違いは吸収できていません）

// --- prefix -----
  navigator.getUserMedia  = navigator.getUserMedia    || navigator.webkitGetUserMedia ||
                            navigator.mozGetUserMedia || navigator.msGetUserMedia;

  // ---- 新旧APIをPromiseでラップする ----
  function getDeviceStream(option) {
    if ('getUserMedia' in navigator.mediaDevices) {
      console.log('navigator.mediaDevices.getUserMadia');
      return navigator.mediaDevices.getUserMedia(option);
    }
    else {
      console.log('wrap navigator.getUserMadia with Promise');
      return new Promise(function(resolve, reject){    
        navigator.getUserMedia(option,
          resolve,
          reject
        );
      });      
    }
  }

  // 利用例
  function startVideo() {
    getDeviceStream({video: true, audio: false})
    .then(function (stream) { // success
      localStream = stream;
      localVideo.src = window.URL.createObjectURL(localStream);
    }).catch(function (error) { // error
      console.error('getUserMedia error:', error);
      return;
    });
  }

これを使ってカメラ映像を取得する例もご用意しました。Chrome 51でもデフォルトのままで利用できます。

• GitHub Pages で試す camera_old_new.html
• GitHub でソースを見る camera_old_new.html

様々なWebRTC関連のブラウザの違いを吸収する adapter.js が 本家のGitHubで公開されています。より便利に使いたい場合は、そちらをご利用ください。

CSS3と組み合わせてみよう

WebRTCは他の要素と組み合わせて使うことができると書きました。実際にCSS3と組み合わせてみましょう。

<!-- 通常 -->
  <video id="local_video" autoplay style="width: 320px; height: 240px; border: 1px solid black;"></video>

  <!-- 左右反転 -->
  <video id="flip_video" autoplay style="transform: scaleX(-1); width: 320px; height: 240px; border: 1px solid black;"></video>

  <!-- 角丸 -->
  <video id="round_video" autoplay style="border-radius: 80px 80px 80px 80px; width: 320px; height: 240px; border: 1px solid black;"></video>

  <!-- セピア -->
  <video id="filter_video" autoplay style="filter: sepia(100%); -webkit-filter: sepia(100%); width: 320px; height: 240px; border: 1px solid black;"></video>

ほかにも様々なバリエーションが考えられます。ぜひ自分でもいろいろ試してみてください。

また、CSS3アニメーションを使うこともできます。例えばこんな感じです。

<!doctype html>
<html>
<head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
 <title>Camera with mediaDevice</title>
 <style type="text/css">
   #rotate_video
   {
    animation-duration:4s;
    animation-iteration-count:infinite;
    animation-timing-function:linear;
    animation-name:rotate360;     
   }

   #shake_video
   {
    animation-duration:0.5s;
    animation-iteration-count:infinite;
    animation-timing-function:ease-in-out;
    animation-name:shake;     
   }
   
   @keyframes rotate360
   {
    0%{transform:rotate(0deg);}
    100%{transform:rotate(360deg);}
   }

   @keyframes shake
   {
    0%{transform:rotate(-20deg);}
    50%{transform:rotate(20deg);}
    100%{transform:rotate(-20deg);}
   }
  </style> 
</head>
<body>
  Camera with mediaDevice.getUserMedia()<br />
  <button onclick="startVideo()">Start</button>
  <br />
  <!-- 通常 -->
  <video id="local_video" autoplay style="width: 320px; height: 240px; border: 1px solid black;"></video>
  <br />

  <!-- 回転アニメーション -->
  <video id="rotate_video" autoplay style="width: 320px; height: 240px; border: 1px solid black;"></video>

  <!-- 振動アニメーション -->
  <video id="shake_video" autoplay style="width: 320px; height: 240px; border: 1px solid black;"></video>
  
</body>
<script type="text/javascript">
  // --- prefix -----
  navigator.getUserMedia  = navigator.getUserMedia    || navigator.webkitGetUserMedia ||
                            navigator.mozGetUserMedia || navigator.msGetUserMedia;

  let localVideo = document.getElementById('local_video');
  let localStream;
  
  // start local video
  function startVideo() {
    getDeviceStream({video: true, audio: false})
    .then(function (stream) { // success
      localStream = stream;
      localVideo.src = window.URL.createObjectURL(localStream);
	  
      document.getElementById('rotate_video').src = localVideo.src;
      document.getElementById('shake_video').src = localVideo.src;
    }).catch(function (error) { // error
      console.error('mediaDevice.getUserMedia() error:', error);
      return;
    });
  }

  // ---- 新旧APIをPromiseでラップする ----
  function getDeviceStream(option) {
    if ('getUserMedia' in navigator.mediaDevices) {
      console.log('navigator.mediaDevices.getUserMadia');
      return navigator.mediaDevices.getUserMedia(option);
    }
    else {
      console.log('wrap navigator.getUserMadia with Promise');
      return new Promise(function(resolve, reject){    
        navigator.getUserMedia(option,
          resolve,
          reject
        );
      });      
    }
  }
</script>
</html>

CSS3と組み合わせたサンプルも、GitHub Pagesでも公開していますので、試してみてください。（ラップ関数を使っているので、デフォルトのChrome 51でも利用できます）

• GitHub Pages で試す camera_css_wrap.html
• GitHub でソースを見る camera_css_wrap.html

次回は

今回は新しいAPIを使って、カメラの映像を取得してみました。次回はWebRTCによる通信を手動で接続してみます。