こんにちは！がねこまさしです。前回は複数人の同時通話まで実現しました。社内で使うには十分なレベルです。
しかし本格的な企業ユースとなると、まだまだ障害があります。会社と家、自社と別の会社さんなど、実際に通信しようとするとNATやFirewallといった壁が立ちはだかります。

NATを越えよう

NATの役割は

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

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

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

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

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

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

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

Peer-to-Peer通信を行うには、シグナリング処理でお互いに（ローカルネットワーク内の情報ではなく）インターネット側から見た情報を通知する必要があります。

ブラウザーが、インターネット側から見た情報を知るための仕組みが、STUNになります。

STUNの仕組みは

STUNの仕組みは意外とシンプルです。インターネット側にいる誰か（STUNサーバー）に、自分（ブラウザ）がどう見えるか教えてもらうだけです。

STUNは元々WebRTCのために作られた仕組みではなく、より汎用的なUDP通信の補助として生まれました。VoIPやネットワークゲームの世界でも使われているようです。

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

お互いの情報が伝わったら、そこを目掛けて通信を行います。間にNATが挟まりますが、ポートを直接マッピングしているのであくまでもPeer-to-Peerです。

STUNサーバーを動かそう

それでは実際にSTUNサーバーを動かしてみましょう。Linuxで動作するオープンソースのものがあるので、そちらを使います。
rfc5766-turn-server
このサーバはSTUNだけでなく、後程説明するTURNにも対応しています。
DownloadページからOSに合わせたgzファイルをダウンロードし、INSTALL手順に従ってビルド、インストールしてください。参考までに以前私が実施した手順を載せておきます。※ちょっと古いバージョンです。最新のものを取得してインストールしてください。

$ wget https://rfc5766-turn-server.googlecode.com/files/turnserver-3.2.1.4-CentOS6-x86_64.tar.gz
$ tar zxvf turnserver-3.2.1.4-CentOS6-x86_64.tar.gz
$ cd turnserver-3.2.1.4
$ ./install.sh

CentOSの場合、以下の場所に導入されました。

バイナリ →  /usr/bin/turnserver 
設定ファイル →  /etc/turnserver/*.conf

次に設定ファイル( /etc/turnserver/turnserver.conf )を見てみましょう。ポイントとなるのは次の箇所です。

STUN/TURNサーバーの接続待ポート番号。デフォルトは3478です。

コメントアウトを外して数値を指定すれば、任意のポートに変更できます。

#

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=3478

TCPとUDPの両方で待ち受けできますが、STUNはUDPのみが有効なので注意が必要です。※つまりUDPが通らない環境ではSTUNは使えません。

このサーバーはデフォルトでSTUN/TURNの両方をサポートしています。

STUNのみ使いたい場合は、stun-only のコメントアウトを外します。

#

Option to suppress TURN functionality, only STUN requests will be processed.

Run as STUN server only, all TURN requests will be ignored.

By default, this option is NOT set.

#

stun-only

STUNはPeer-to-Peer通信が始まればサーバーのCPU負荷、ネットワーク負荷はかかりません。それに対して後述するTURNでは特にネットワーク負荷がかかります。サーバーを借りていてネットワーク通信量で課金されるようなケースでは、stun-onlyを設定してTURNは無効にしておいた方が良いかもしれません。

設定がすんだらSTUNサーバーを起動してみましょう。画面にエラーが出なければ無事に起動成功です。エラーが出る場合は turnserver.conf を確認してみてください。

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

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

ここまでで準備したSTUNサーバーを使うように、クライアント側のソースを修正しましょう。前回のソースの一部を変更します。
STUNサーバーが stun.yourdomain.com で、デフォルトのポート3478で動いていると仮定します。その情報をPeerConnectionに教えてあげます。

function prepareNewConnection(id) {
  var pc_config = {"iceServers":[ {"url":"stun:stun.yourdomain.com:3478"} ]};
  var peer = null;
  try {
    peer = new webkitRTCPeerConnection(pc_config);
  } catch (e) {
    console.log("Failed to create PeerConnection, exception: " + e.message);
  }

//...省略...
}

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

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

NATにはグローバルIPアドレスを共有するだけでなく、セキュリティ対策としての役割もあります。内部の端末を隠したり、通信できるポートを制限したり、一種の簡易Firewallとして利用されているケースもあります。その場合はFirewallの場合と同じく、次に説明するTURNを利用する必要があります。
また、NATの構造によっては、接続先によって（今回の場合、STUNサーバーとPeer-to-Peerの通信相手）別のポートが割り当てられる Symmetric NAT という物があります。この場合もSTUNの仕組みでは通信することができません。やはりTURNの出番ということになります。

Firewallを越えよう

一般家庭のようにブロードバンドルーターなどでNATがある環境では、STUNを使えば通信が可能になります。次は一般的な企業で使えるようにしましょう。
企業ではFirewallが設置されているケースがほとんどです。その場合、外部と通信できるポートも制限されます。STUNではUDPポートは動的に割り振られるままなので、Firewallにとても大きな穴を空けないと通信ができません。きっとセキュリティ管理者に怒られてしまいます。こんなケースに対応するのが、TURNの仕組みです。TURNもWebRTCのために生まれたのではなく、VoIPやネットワークゲームの世界で使われていたものです。

TURNの仕組みは

TURNを使った通信では、TURNサーバが実際のストリームデータを受け渡す間に入ります。すべてのパケットをTURNサーバーがリレーすることになり、もはやPeer-to-Peer通信ではなくなります。この際TURNサーバーでは動画のエンコーディングは行わないので、CPU負荷よりもネットワーク負荷が高くなりやすいです。

Firewallに穴を空けよう

TURNを使うには、Firewallに1つ穴を空ける必要があります。標準では3478/UDPを使うので、そのポートが通過可能になるように設定して（してもらって）ください。
もう1つ、シグナリングサーバーと通信するための穴も空ける必要があります。例えば9000番を使うのであれば、9000/TCPも同様に通過可能になるように設定して（してもらって）ください。
会社間で通信するのは、両方の会社でFirewallに穴を空ける必要があります。
※これを読んで「結局Firewallをいじるのかよー」とがっかりした人もいますよね？　Firewallをいじらない方法もあるので、最後までお楽しみに。

TURNサーバーを動かそう

TURNサーバーは先ほどSTUNサーバーとしてインストールしたrfc5766-turn-server
がそのまま使えます。/etc/turnserver/turnserver.conf の設定を変更してTURNとして使える様にします。

STUN/TURNサーバーの接続待ポート番号。デフォルトは3478です。

コメントアウトを外して数値を指定すれば、任意のポートに変更できます。

#

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=3478

デフォルトのポートは3478ですが、自由に設定できます。

UDP/IPの他に、rfc5766-turn-serverではTLS/DTLSでの通信も可能です（デフォルトで有効になっています）

残念ながらブラウザー側の実装がまだ不十分なので、この機能は無効にしておく（コメントアウトを外す）ことをお勧めします

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

TLS/DTLSは今回は使わない設定にしておきます。また先ほどのSTUNを動かす際に stun-only を設定した場合は、再びコメントアウトしてTURNも使える様にして下さい。

Option to suppress TURN functionality, only STUN requests will be processed.

Run as STUN server only, all TURN requests will be ignored.

By default, this option is NOT set.

#

stun-only

そして、WebRTCでTURNを使う際のキモはこちらの設定です。

認証の方法を選択します。次の3種類があります。

no-auth

st-cred-mech (short-term credential mechanism)

lt-cred-mech (long-term credential mechanism)

WebRTCでは lt-cred-mechを使用する必要がありますので、その行のコメントアウトを外します。

Uncomment to use long-term credential mechanism.

By default no credentials mechanism is used (any user allowed).

This option can be used with either flat file user database or

PostgreSQL DB or MySQL DB or Redis DB for user keys storage.

#
lt-cred-mech

同時に、realmも設定が必要になります。お忘れなく。

#

Realm for long-term credentials mechanism and for TURN REST API.

#
realm=turn.yourdomain.com

なかなか lt-cred-mech が必須だとは分からず、とても長い間悩んでしまいました。lt-cred-mech で使用するアカウント情報はPostgreSQL, MySQL, Redisなどで管理できますが、今回はシンプルにファイル管理にします。

ユーザーアカウントを定義するファイル名を指定します。

#

'Dynamic' user accounts database file name.

Only users for long-term mechanism can be stored in a flat file,

short-term mechanism will not work with option, the short-term

mechanism required PostgreSQL or MySQL or Redis database.

'Dynamic' long-term user accounts are dynamically checked by the turnserver process,

so that they can be changed while the turnserver is running.

#

Default file name is turnuserdb.conf.

#
userdb=/etc/turnserver/turnuserdb.conf

/etc/turnserver/turnuserdb.conf を使うことにしたので、その内容も変更します。

This file can be used as user accounts storage for long-term credentials mechanism.

#

username1:key1

username2:key2

OR:

username1:password1

username2:password2

yourid:yourpassword

例としてユーザID: yourid 、パスワード: yourpassword　としました。　※実際にはもっと強度の高いパスワードにしてくださいね。

これで turnserverを再起動すれば、TURNでの通信が有効になります。

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

※ちなみに turnserverを安全に停止させる手段が分かりません。仕方がないので kill で殺しています…。

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

ここまでで準備したTURNサーバーを使うように、クライアント側のソースを修正しましょう。STUNで修正した部分と同じ個所になります。 STUN/TURNサーバーが turn.yourdomain.com で、デフォルトのポート3478で動いていると仮定します。その情報をPeerConnectionに教えてあげます。（STUNとTURNの両方を候補にすることができます）

function prepareNewConnection(id) {
  var pc_config = {"iceServers":[
   {"url":"stun:turn.yourdomain.com:3478"},
   {"url":"turn:turn.yourdomain.com:3478", "username":"yourid", "credential":"yourpassword"}
  ]};
  var peer = null;
  try {
    peer = new webkitRTCPeerConnection(pc_config);
  } catch (e) {
    console.log("Failed to create PeerConnection, exception: " + e.message);
  }

//...省略...
}

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

Firewallはそのままで

実際の企業ではセキュリティ上の制約や手続き上の問題で、Firewallに穴を空けるのが大変なことも多々あります。お客様の会社だったらなおさらですよね。そんな時のために、TURN over TCP という規格があり、rfc5766-turn-server と Chrome の両方ともサポートしてます。これを使えば、Firewallはそのままで、通信が可能になります。

TURNサーバを設定し直そう

一つのポート番号で、UDPとTCPの両方を待ち受けすることができます。

HTTPと同じ、80番を設定します。

#

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

設定が終わったら、turnserverを再起動してください。

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

function prepareNewConnection(id) {
  var pc_config = {"iceServers":[
   {"url":"stun:turn.yourdomain.com:80"},
   {"url":"turn:turn.yourdomain.com:80?transport=udp", "username":"yourid", "credential":"yourpassword"},
   {"url":"turn:turn.yourdomain.com:80?transport=tcp", "username":"yourid", "credential":"yourpassword"}
  ]};
  var peer = null;
  try {
    peer = new webkitRTCPeerConnection(pc_config);
  } catch (e) {
    console.log("Failed to create PeerConnection, exception: " + e.message);
  }

//...省略...
}

ここでは省略しますが、シグナリングサーバーも 80/TCP で動かす必要があります。サーバー側のNode.jsのポート番号と、クライアント側のsocket.ioのつなぎ先のポート番号を80番に変更してください。※Webサーバー、シグナリングサーバー、TURNサーバーの3つをすべて80/TCPで動かすので、サーバーを3つ別々に立てる必要があります。頑張ってください。

さあ、これで最後です。ブラウザをリロードしてください。きっと壁を越えて対話ができることと思います。

最後に

これまで全5回、WebRTCの使いかたを説明してきました。開発者向けにコードを一から書いてきましたが、世の中には便利なライブラリやサービスも数多くあります。

• WebRTC開発者向けライブラリ「PeerJS」はこうして作られた
• WebRTCで注目された海外企業のサービス19本一挙公開

こちらを利用するのもありですね。日本でWebRTCが盛り上がって、企業ユースでも認知されるのを期待しています。
おつきあいいただき、どうもありがとうございました。