WebRTCを使ってみよう！ – HTML5Experts.jp

WebRTCで録画する！MediaRecoderを使ってみよう

がねこまさし — Mon, 16 Feb 2015 01:44:06 +0000

連載： WebRTCを使ってみよう！ (7)

こんにちは！がねこまさしです。今回はWebRTCの録画機能を使って、ブラウザ(Firefox)で録画してみましょう。

Media Recorder API

WebRTCでの録画機能はについては、MediaRecorder APIとしてこちらで検討が行われています。

MediaStream Recording

Firefoxではすでに実装が始まっていますので、実際に使ってみることができます。

早速録画してみる

まずはいつものようにgetUserMedia()で localStreamを取得します。それを使って録画するのは、このようになります。簡単ですね!

var localStream; // getUserMedia()で取得したstreamをセットしておく
var recorder =  null;
function startRecording() {
 recorder = new MediaRecorder(localStream);
 recorder.ondataavailable = function(evt) {
  // 録画が終了したタイミングで呼び出される
 }

 // 録画開始
 recorder.start();
}

// 録画停止
function stopRecording() {
 recorder.stop();
}

私が試したところ、60分程度は問題なく録画できました。メモリ使用量が増加することもないので、ディスクのどこかにキャッシュされているのだと思います。（場所は発見できませんでした）

再生するには

録画したものを再生するには、先ほどのrecorder.ondataavaliable()で準備をしておく必要があります。Blobから、URLを生成しておきます。

var blobUrl = null;

 recorder.ondataavailable = function(evt) {
  var videoBlob = new Blob([evt.data], { type: evt.data.type });
  blobUrl = window.URL.createObjectURL(videoBlob);
 }

あとは、videoタグで再生すればOKです。

var playbackVideo =  document.getElementById('playback_video');
function playRecorded() {
 playbackVideo.src = blobUrl;
 playbackVideo.onended = function() {
  playbackVideo.pause();
  playbackVideo.src = "";
 };

 playbackVideo.play();
}

録画を停止しないとondataavaliable()のイベントが発生しないので、再生はできません。残念ながらいわゆる「追いかけ再生」はできないようです。

保存するには

せっかく録画した映像をファイルに保存するにはどうすればよいのでしょうか？　残念ながらJavaScriptでファイルに直接書き込むAPIは今はFirefoxにはなさそうです。タグを使って、ユーザにファイルを指定して保存してもらいます。

var anchor = document.getElementById('downloadlink');

 recorder.ondataavailable = function(e) {
  var videoBlob = new Blob([e.data], { type: e.data.type });
  blobUrl = window.URL.createObjectURL(videoBlob);

  anchor.download = 'recorded.webm';
  anchor.href = blobUrl;
 }

録画されたファイルはwebm形式になります。ビデオコーデックはVP8、オーディオコーデックはVorbis Audioでした。

終わりに

MediaRecorderを使えば、映像を簡単に記録することができます。サーバにポストして保存すれば、映像共有サイトも作れそうです。まだFirefoxでしか利用できませんが、今後の普及が楽しみですね。
※こちらにデモページを用意しました。

全体のソース




 
 recording Firefox


 MediaRecorder Demo for Firefox
 
 
  
 
 
  
 
 Download

WebRTC落穂拾い：初心者がつまずきやすいポイントをフォロー

がねこまさし — Mon, 26 May 2014 00:00:49 +0000

連載： WebRTCを使ってみよう！ (6)

こんにちは、がねこまさしです。以前WebRTCに関する連載を書かせていただきましたが、今回はそのフォロー記事を書きたいと思います。

4月に記事をベースにしたハンズオンを行ったり、別のイベントで参加者の方とお話しさせていただく機会がありました。すると、みなさんいろいろな部分で引っ掛かってしまうケースが多いことが分かりました。私の記事の説明不足も多いので、以下のつまずきやすいポイントについて、この機会に改めて補足させていただきます。

カメラがつながらない
手動シグナリングがうまくいかない
シグナリングサーバーでつながらない
Firefoxでも使いたい

カメラがつながらない

第1回のHTML5でWebRTCを使ってみよう！「カメラを使ってみよう」編ではまずカメラにアクセスします。ところが、カメラにつながらないケースが時々発生しているようです。

ブラウザが違うケース

記事に書いたソースコードは、Chrome用になっていますので、Chromeでお試しください。FirefoxもWebRTCに対応していますが、JavaScriptの書き方がちょっと違います。
※Chrome/Firefox両方に対応させる書き方もあります。この記事の最後でご説明します。

権限の制限に引っ掛かっている

ChromeでWebRTCを使ってカメラにアクセスするには、HTML/JavaScriptをローカルディスクから読み込む(file://～)ではなく、Webサーバーから読み込まなくてはなりません(http://～、https://～)。お手数ですが、ApacheやnginxといったWebサーバー、あるいはpython,ruby,node.js,go等を使ってテスト用サーバーを動かしてください。HTMLファイルは、Webサーバー側に配置してくださいね。

Node.jsを使った簡易Webサーバー

例として簡易WebサーバーをNode.jsで作った場合のサンプルをこちらに掲載します。※HTML5エキスパートの方のソースを一部拝借させていただきました。

var port = 9000;
var html = require('fs').readFileSync(__dirname + '/hand.html'); // 任意のHTMLファイル
var server = require('http').createServer(function(req, res) {
  res.writeHead(200, {'Content-Type': 'text/html', 'Content-Length': html.length});
  res.end(html);
}).listen(port);

こちらを例えば http.js として保存し、htmlファイルも（この例ではhand.html）同じディレクトリに保存してください。
次に、コマンドプロンプト/ターミナルから、

node http.js

のように簡易Webサーバーを起動してください。ブラウザからは http://localhost:9000/ にアクセスしてくださいね。

うっかり「拒否」してしまった

ブラウザがカメラやマイクにアクセスする許可を求めてきた際に、うっかり「拒否」してしまった場合、カメラの映像は取得できません。

そんな場合は、アドレスバーの右端に「カメラに×印」が表示されます。

ここで「カメラに×印」のアイコンをクリックすると、カメラのアクセス許可状態を変更するメニューが現れます。

「カメラやマイクへのアクセスを要求しているか確認する」を選択し、[完了]をクリックすると、リロードを促されます。

[再読み込み]ボタンをクリックして、再度挑戦してみてください。

なぜかカメラを認識しないケース

そもそもブラウザがカメラを認識していないことがあります。確実ではありませんが、次の手順で認識してくれることもあります。

USB接続の場合、カメラを抜き差しする → 再挑戦
ブラウザを終了し、再度起動する → 再挑戦
OSを再起動 → 再挑戦

USBの抜き差しが一番可能性が高く、後ろに行くにしたがって、成功する可能性は下がる印象です。不思議です。

手動シグナリングが上手く行かない

第2回の「WebRTCに触ってみたいエンジニア必見！手動でWebRTC通信をつなげてみよう」では、SDPとICEを手動でコピー＆ペーストしてPeer-to-Peer通信を確立しました。ところが実際にやってみると、うまくいかないケースが多々ありました。実感としては約半数のケースでうまくいかず、ただ黒い画面が表示されるだけでした。

正確な原因はよく分かっていませんが、コピーする範囲（選択した範囲）が1文字でもずれていると、正しく接続できないことは確かです。そのため、対象の文字列を自動で選択するようにちょっとだけ改良しました。記事の最後に「手動シグナリングの改良版ソース(2014年4月21日追加）」として改良したソースを載せていますので、うまくいかなかった人もこちらで再チャレンジしてみてください。

また、この機会に同一LAN上の別のマシン間でも手動シグナリングを試しました。テキストファイル経由でSDP/ICEを交換して、無事通信することができました。

シグナリングサーバーでつながらない

第3回の「WebRTC初心者でも簡単にできる！Node.jsで仲介（シグナリング）を作ってみよう」では、Node.jsを使ってシグナリングサーバーを作りました。こちらもnode.jsをよく触っている方に、勘違いさせてしまったようです。

Node.jsでもexpressなどのフレームワークを使って、Webアプリケーションを作ることが多いです。なので今回もシグナリングサーバーでWebサーバーも兼ねていて、HTMLもそこから取得できると思われた方がいたようです。第3回の記事では、Node.jsでWebSocketを使ったシグナリングサーバーのみ作成しています。お手数ですが、Webサーバーは別途用意してくださいね。
もちろん先ほどと同じく、Node.jsで簡易Webサーバーを作ることも可能ですので、お好みでどうぞ。

Firefoxでも使いたい

FirefoxでもWebRTCが使えますが、私が書いた記事のソースはChromeにしか対応していません。Chrome/Firefox共通で使える様にクロスブラウザ対応にしてみましょう。

クロスブラウザ対応する書き方はいろいろありますが、今回はGoogleで用意しているadapter.jsを使ってみます。題材には、第3回のシグナリングサーバーを使った1対1の通信を用います。

adapter.jsを使うには、まずHTMLの最初でJavaScriptを読み込みます。



  WebRTC 1 to 1 signaling

次に、ブラウザ固有のクラス、メソッドを置き換えます。

navigator.webkitGetUserMedia() —> getUserMedia()
video.src = window.webkitURL.createObjectURL(stream) —> attachMediaStream(video, stream)
webkitRTCPeerConnection –> RTCPeerConnection

具体的には、次の箇所になります。

function startVideo() {
    //navigator.webkitGetUserMedia({video: true, audio: false},
    getUserMedia({video: true, audio: false},

    function (stream) { // success
      localStream = stream;
      //localVideo.src = window.webkitURL.createObjectURL(stream);
      attachMediaStream(localVideo, stream);
      localVideo.play();
      localVideo.volume = 0;
    },

    function (error) { // error
      console.error('An error occurred: [CODE ' + error.code + ']');
      return;
    }
    );
  }

function prepareNewConnection() {
    var pc_config = {"iceServers":[]};
    var peer = null;
    try {
      //peer = new webkitRTCPeerConnection(pc_config);
      peer = new RTCPeerConnection(pc_config);
    } catch (e) {
      console.log("Failed to create peerConnection, exception: " + e.message);
    }

function onRemoteStreamAdded(event) {
      console.log("Added remote stream");
      //remoteVideo.src = window.webkitURL.createObjectURL(event.stream);
      attachMediaStream(remoteVideo, event.stream)
    }

すると、このようにChromeとFirefox間で通信ができるようになります。

おわりに

ありがたいことに実際にWebRTCの記事を試してくださった方々の言葉を聞くチャンスがあり、そこで出てきた疑問に答えるために、今回の記事を書かせていただきました。貴重なフィードバックをいただいた方々にお礼申し上げます。ありがとうございました。

一連の記事についてでも、そうでなくても、WebRTCに関する質問やご意見があれば、どんどんお寄せください。私の分かる範囲でまた補足記事を書かせていただきます。よろしくお願いします。

壁を越えろ！WebRTCでNAT/Firewallを越えて通信しよう

がねこまさし — Tue, 11 Mar 2014 01:00:31 +0000

連載： WebRTCを使ってみよう！ (5)

こんにちは！がねこまさしです。前回は複数人の同時通話まで実現しました。社内で使うには十分なレベルです。
しかし本格的な企業ユースとなると、まだまだ障害があります。会社と家、自社と別の会社さんなど、実際に通信しようとすると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が盛り上がって、企業ユースでも認知されるのを期待しています。
おつきあいいただき、どうもありがとうございました。

シグナリングサーバーを応用！「WebRTCを使って複数人で話してみよう」

がねこまさし — Tue, 04 Mar 2014 01:00:10 +0000

連載： WebRTCを使ってみよう！ (4)

こんにちは！前回はシグナリングサーバーを動かして、WebRTCでPeer-to-Peer通信をつなぐ処理を作りました。最後に書いた通り、前回の実装ではサーバーあたり2人だけしか同時に通知できません。今回はこれをもっと実用的にしていきましょう。 ※今回もNode学園祭2013で発表した内容と共通の部分が多いです。その時の資料も併せてご参照ください。

※こちらの記事は2014年に書かれました。2016年8月のアップデート記事がありますので、そちらもご参照ください。

複数会議室を作ろう

前回作ったのは、いわばカップル1組限定サイトのシングルテナントアプリでした（左）。これを複数組が共存できる、マルチテナント（複数会議室）のアプリに改造します（右）。

複数組が共存できない理由は、シグナリングの通信が同じシグナリングサーバーに接続している全員に飛んでしまうからです。これを混線しないように分離してあげる必要があります。シグナリングサーバーで利用しているsocket.ioでは、これを簡単に実現できるroom機能があります。

roomに入室する… socket.join()
roomから退室する… socket.leave()
room内だけにメッセージを送る… socket.broadcast.to.emit()

まずクライアント側を一部手直しします。

function onOpened(evt) {
    console.log('socket opened.');
    socketReady = true;

    var roomname = getRoomName(); // 会議室名を取得する
    socket.emit('enter', roomname);
}

ソケット接続が確立したら、シグナリングサーバーに対して入室要求(enter)を送っています。ここでgetRoomName()はアプリケーション側で実装する部分で、何らかの方法で会議室名を取得して返します。手抜きなサンプルとしてはこんな感じでしょうか。URLの?以降をそのまま切り出して返しています。

function getRoomName() { // たとえば、 URLに  ?roomname  とする
  var url = document.location.href;
  var args = url.split('?');
  if (args.length > 1) {
    var room = args[1];
    if (room != "") {
      return room;
    }
  }
  return "_defaultroom";
}

ついでにもう少し直しましょう。実は前回までのサンプルではカメラしかアクセスしていません。マイクはアクセスしていないので、声が聞こえません。今回はマイクも取得するように一カ所だけ修正します。※webkitGetUserMedia()の引数を変更

// start local video
  function startVideo() {
    navigator.webkitGetUserMedia({video: true, audio: true},  // <--- audio: true に変更
      function (stream) { // success
        localStream = stream;
        localVideo.src = window.webkitURL.createObjectURL(stream);
        localVideo.play();
        localVideo.volume = 0;
      },
      function (error) { // error
        console.error('An error occurred: [CODE ' + error.code + ']');
        return;
      }
    );
  }

※同一PC上で複数の2つのウィンドウ/タブを開いて通信する場合、ハウリングしやすいので音量を絞るか、ヘッドフォンを利用してください。

今度はシグナリングサーバー側も修正しましょう。クライアントからの入室要求(enter)に対応するのと、会議室内だけに通信する部分です。

// 入室
socket.on('enter', function(roomname) {
    socket.set('roomname', roomname);
    socket.join(roomname);
});

socket.on('message', function(message) {
  emitMessage('message', message);
});

socket.on('disconnect', function() {
  emitMessage('user disconnected');
});

// 会議室名が指定されていたら、室内だけに通知
function emitMessage(type, message) {
  var roomname;
  socket.get('roomname', function(err, _room) {  roomname = _room;  });

  if (roomname) {  socket.broadcast.to(roomname).emit(type, message);   }
  else {   socket.broadcast.emit(type, message);   }
}

シグナリングサーバーを起動しなおして、HTMLをリロードすれば、複数会議室に対応したマルチテナントアプリの完成です。 URLの後ろに ?room1 や ?room2 などのように会議室名を指定すれば、その部屋の人と通信できます。

複数人で通信してみたい

次は2人だけでなく、複数人で同時に話せるようにしてみたいと思います。こんな感じです。

複数のPeer-to-Peer通信を扱うには

複数人と通信するには、クライアント側（ブラウザ側）に相手の数だけPeerConnectionが必要です。それを管理するための便宜上のクラスを作ります。通信状況や、相手のID(socket.ioが割り振る）を保持します。

var MAX_CONNECTION_COUNT = 3;
var connections = {}; // Connection hash
function Connection() { // Connection Class
  var self = this;
  var id = "";  // socket.id of partner
  var peerconnection = null; // RTCPeerConnection instance
  var established = false; // is Already Established
  var iceReady = false;
}

function getConnection(id) {
  var con = null;
  con = connections[id];
  return con;
}

function addConnection(id, connection) {
  connections[id] = connection;
}

ついでに、複数のConnectionを格納する配列と、それを管理する関数群も用意します。ここに挙げた2つ以外に、getConnectionCount(), isConnectPossible(), deleteConnection(id), などなど。（詳細は最後に全ソースを掲載します）

シグナリングを手直し

シグナリングの流れも手直しが必要です。今までのシグナリングでは、最初にOffer SDPを送る際に同じ部屋の全員に送っていました(broadcast)。すると全員からAnswer SDPが返ってきてしまうので、情報が衝突してしまいます。

そこで、まず部屋に誰が居るかを確認し(call-response)、一人ずつ個別にOffer-Answerのやり取りをする必要があります。

では、クライアント側のソースを直していきましょう。

function call() {
  if (! isLocalStreamStarted()) return;
  socket.json.send({type: "call"});
}

function onMessage(evt) {
  var id = evt.from;
  var target = evt.sendto;
  var conn = getConnection(id);

  if (evt.type === 'call') {
    if (! isLocalStreamStarted()) return;
    if (conn) return;  // already connected

    if (isConnectPossible()) {
      socket.json.send({type: "response", sendto: id });
    }
    else {   console.warn('max connections. so ignore call');     }
  }
  else if (evt.type === 'response') {
    sendOffer(id);
    return;
  }
}

call()で全員にbroadcastし、受け取った側はonMessage()の中でcallを受け取ると、responseを相手を特定して送り返します。発信側はreponseを受け取ると、その相手に対してoffer SDPを送っています。 sendOffer()の中身もちょっと変わります。

function sendOffer(id) {
  var conn = getConnection(id); // <--- すでに作成済のコネクションを探す
  if (!conn) {
    conn = prepareNewConnection(id);
  }

  conn.peerconnection.createOffer(function (sessionDescription) { // in case of success
    conn.iceReady = true;
    conn.peerconnection.setLocalDescription(sessionDescription);
    sessionDescription.sendto = conn.id; // <--- 送る相手を指定する
    sendSDP(sessionDescription);
  }, function () { // in case of error
    console.log("Create Offer failed");
  }, mediaConstraints);
  conn.iceReady = true;
}

同様に、sendAnswer()もちょっと変えます。複数のコネクションに対応するのと、送る相手を指定するのが変更点です。

function sendAnswer(evt) {
  console.log('sending Answer. Creating remote session description...' );
  var id = evt.from;
  var conn = getConnection(id); // <--- すでに作成済のコネクションを探す
  if (! conn) {
    console.error('peerConnection not exist!');
    return
  }

  conn.peerconnection.createAnswer(function (sessionDescription) { 
    // in case of success
    conn.iceReady = true;
    conn.peerconnection.setLocalDescription(sessionDescription);
    sessionDescription.sendto = id; // <--- 送る相手を指定する
    sendSDP(sessionDescription);
  }, function () { // in case of error
    console.log("Create Answer failed");
  }, mediaConstraints);
  conn.iceReady = true;
}

さらに、SDPを覚える処理も複数セッションに対応させます。

function setOffer(evt) {
  var id = evt.from;
  var conn = getConnection(id);
  if (! conn) {
    conn = prepareNewConnection(id);
    conn.peerconnection.setRemoteDescription(new RTCSessionDescription(evt));
  }
  else {
    console.error('peerConnection alreay exist!');
  }
}

function setAnswer(evt) {
  var id = evt.from;
  var conn = getConnection(id);
  if (! conn) {
    console.error('peerConnection not exist!');
    return
  }
  conn.peerconnection.setRemoteDescription(new RTCSessionDescription(evt));
}

引き続きConnectionを生成する処理も修正します。今まではPeerConnectionを直接返していましたが、今回はConnectionのインスタンスを生成し、そこにPeerConnectionを保持させます。また、Candidateの送信時にも相手先を指定します。

function prepareNewConnection(id) {
  var pc_config = {"iceServers":[]};
  var peer = null;
  try {
    peer = new webkitRTCPeerConnection(pc_config);
  } catch (e) {
    console.log("Failed to create PeerConnection, exception: " + e.message);
  }
  var conn = new Connection();  // <--- Connectionを作成し、PeerConnectionを保持させる
  conn.id = id;
  conn.peerconnection = peer;
  peer.id = id;
  addConnection(id, conn);

  // send any ice candidates to the other peer
  peer.onicecandidate = function (evt) {
  if (evt.candidate) {
    console.log(evt.candidate);
    sendCandidate({type: "candidate", 
                          sendto: conn.id, // <-- 送信先を指定
                          sdpMLineIndex: evt.candidate.sdpMLineIndex,
                          sdpMid: evt.candidate.sdpMid,
                          candidate: evt.candidate.candidate});
    } else {
      console.log("End of candidates. ------------------- phase=" + evt.eventPhase);
      conn.established = true;
    }
  };

  // ...
}

Candidateの送信部分を変更したので、Candidateを受信した処理も変更しましょう。 onCandidate()も複数コネクションに対応させます。

function onCandidate(evt) {
  var id = evt.from;
  var conn = getConnection(id);
  if (! conn) {
    console.error('peerConnection not exist!');
    return;
  }
    
  // --- check if ice ready ---
  if (! conn.iceReady) {
    console.warn("PeerConn is not ICE ready, so ignore");
    return;
  }
	  
  var candidate = new RTCIceCandidate({sdpMLineIndex:evt.sdpMLineIndex, sdpMid:evt.sdpMid, candidate:evt.candidate});
  console.log("Received Candidate...")
  console.log(candidate);
  conn.peerconnection.addIceCandidate(candidate);
}

さてさて、クライアント側の修正はいったん終わりにして、次はシグナリングサーバー側を修正します。前半では部屋の中だけに送信する機能を加えましたが、次は特定の相手にだけ送信できるようにします。

socket.on('message', function(message) {
    // 送信元のidをメッセージに追加（相手が分かるように）
    message.from = socket.id;

    // 送信先が指定されているか？
    var target = message.sendto;
    if (target) {
      // 送信先が指定されていた場合は、その相手のみに送信
      io.sockets.socket(target).emit('message', message);
      return;
    }

    // 特に指定がなければ、ブロードキャスト
    emitMessage('message', message);
  });

ここまででいったん動かしてみましょう。まだ映像が2人までしか出ませんが、通信はできるはずです。

複数の映像を扱えるようにしよう

ここまでで複数人相手に通信をできるようにしました。でも通信できても映像は見えていません。ちゃんと見えるようにしましょう。まずHTMLに複数のvideoタグを配置します。

その複数のvideoタグを扱えるような関数群を追加します。※本当は動的にタグを作成、削除するのがかっこいいのですが…。

var localVideo = document.getElementById('local-video');
  //var remoteVideo = document.getElementById('remote-video');
  var localStream = null;
  var mediaConstraints = {'mandatory': {'OfferToReceiveAudio':false, 'OfferToReceiveVideo':true }};

  // ---- multi people video & audio ----
  var videoElementsInUse = {};
  var videoElementsStandBy = {};
  pushVideoStandBy(getVideoForRemote(0));
  pushVideoStandBy(getVideoForRemote(1));
  pushVideoStandBy(getVideoForRemote(2));


  function getVideoForRemote(index) {
    var elementID = 'webrtc-remote-video-' + index;
    var element = document.getElementById(elementID);
    return element;
  }

  function getAudioForRemote(index) {
    var elementID = 'webrtc-remote-audio-' + index;
    var element = document.getElementById(elementID);
    return element;
  }

  // ---- video element management ---
  function pushVideoStandBy(element) {
    videoElementsStandBy[element.id] = element;
  }

  function popVideoStandBy() {
    var element = null;
    for (var id in videoElementsStandBy) {
      element = videoElementsStandBy[id];
      delete videoElementsStandBy[id];
      return element;
    }
    return null;
  }

  function pushVideoInUse(id, element) {
    videoElementsInUse[id] = element;
  }

  function popVideoInUse(id) {
    element = videoElementsInUse[id];
    delete videoElementsInUse[id];
    return element;
  }

  function attachVideo(id, stream) {
    console.log('try to attach video. id=' + id);
    var videoElement = popVideoStandBy();
    if (videoElement) {
      videoElement.src = window.URL.createObjectURL(stream);
      console.log("videoElement.src=" + videoElement.src);
      pushVideoInUse(id, videoElement);
      videoElement.style.display = 'block';
    }
    else {
      console.error('--- no video element stand by.');
    }
  }

  function detachVideo(id) {
    console.log('try to detach video. id=' + id);
    var videoElement = popVideoInUse(id);
    if (videoElement) {
      videoElement.pause();
      videoElement.src = "";
      console.log("videoElement.src=" + videoElement.src);
      pushVideoStandBy(videoElement);
    }
    else {
      console.warn('warning --- no video element using with id=' + id);
    }
  }

  // ...

※ソース全体は最後に記載します。

これで準備が整いました。早速接続してみましょう。 [Start video]ボタンを押して、[Connect]を押す、という操作を一人ずつ行ってください。一人、また一人と接続され、最大4人まで通信できます。

補足（2014/03/09追記）

Twitter経由でご指摘をいただきました。User B/Cからresponseではなく、Offerを送れば良いのでは？
アドバイスに従うと、次のように改善されます。

現状：User Aからcall, User B/Cからresponse, User AからOffer, User B/CからAnswer
改善：User Aからcallme, User B/CからOffer, User AからAnswer

確かにその通りです。メッセージのやり取りが片道分少なくなり、すっきりしますね。ご指摘ありがとうございました。

次回は

次回は最終回の予定です。NATやFirewallを越えて通信するための、STUN/TURNについて説明したいと思います。

今回のソースコード

シグナリングサーバー (node.js)

var port = 9001;
var io = require('socket.io').listen(port);
console.log((new Date()) + " Server is listening on port " + port);

io.sockets.on('connection', function(socket) {
  // 入室
  socket.on('enter', function(roomname) {
    socket.set('roomname', roomname);
    socket.join(roomname);
  });
 
  socket.on('message', function(message) {
    // 送信元のidをメッセージに追加（相手が分かるように）
    message.from = socket.id;

    // 送信先が指定されているか？
    var target = message.sendto;
    if (target) {
	　　// 送信先が指定されていた場合は、その相手のみに送信
      io.sockets.socket(target).emit('message', message);
      return;
    }

	// 特に指定がなければ、ブロードキャスト
    emitMessage('message', message);
  });
 
  socket.on('disconnect', function() {
    emitMessage('user disconnected');
  });
 
  // 会議室名が指定されていたら、室内だけに通知
  function emitMessage(type, message) {
    var roomname;
    socket.get('roomname', function(err, _room) {  roomname = _room;  });
 
    if (roomname) {  socket.broadcast.to(roomname).emit(type, message);   }
    else {   socket.broadcast.emit(type, message);   }
  }
});

クライアント側 (HTML, JavaScript)




  WebRTC 4

WebRTC初心者でも簡単にできる！Node.jsで仲介（シグナリング）を作ってみよう

がねこまさし — Fri, 21 Feb 2014 01:00:05 +0000

連載： WebRTCを使ってみよう！ (3)

こんにちは！がねこまさしです。前回はWebRTCの通信を手動でつなぎましたが、今回は仲介役のサーバーを作ってみましょう。

※今回の内容は、Node学園祭2013で発表した内容(の一部)とほぼ同じです。その時の資料もご参照ください。

※こちらの記事は2014年に書かれました。2016年7月のアップデート記事がありますので、そちらもご参照ください。

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

前回は手動でコピー＆ペーストしてシグナリングを実現しました。今回はそれを楽にしましょう。

シグナリングサーバーはどうして必要なの？

シグナリングの過程では、お互いのIPアドレスやポート番号を渡す必要があります。この段階ではお互いIPアドレスを知らないので直接やりとりできません。そこで、仲介役となるシグナリングサーバーが必要となります。このサーバーは、どちらブラウザもIPアドレスを知っていることが前提となります。

つまり、Peer-to-Peer通信の開始前には、普通のサーバー/クライアント型の通信が行わることになります。

Node.jsを準備しよう

今回はシグナリング処理をWebSocketを使って実現してみます。ソケットの処理が実現できればどのような言語でも構わないのですが、メッセージング処理が得意なNode.jsを使うことにします。 Node.jsのインストーラーをこちらのサイトから入手し、手順に従ってインストールしてください。Windows,Mac OS X,Linux用のバイナリが用意されています。今回のサンプルはv0.10.15で動作確認していますが、v0.10.x系ならばそのまま動くはずです。

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

npm install socket.io

socket.ioは、異なる種類のブラウザ間の通信を簡単に行えるようにしてくれるモジュールです。異なる複数の通信方式をサポートしています。

‘websocket’ , ‘flashsocket’ , ‘htmlfile’ , ‘xhr-polling’ , ‘jsonp-polling’

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

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

var port = 9001;
var io = require('socket.io').listen(port);
console.log((new Date()) + " Server is listening on port " + port);

io.sockets.on('connection', function(socket) {
  socket.on('message', function(message) {
    socket.broadcast.emit('message', message);
  });

  socket.on('disconnect', function() {
    socket.broadcast.emit('user disconnected');
  });
});

起動するにはコマンドプロンプト/ターミナルから、次のコマンドを実行してください。

node signaling.js

シグナリングサーバーの動作は単純で、右からきたメッセージをそのまま左に流すだけです。

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

それでは前回のHTMLを、少しずつ変更して行きましょう。まず、socket.ioのクライアント用JavaScriptを読み込みます。localhostの部分は、実際のシグナリングサーバーに変更してください。

次に、socket.ioの接続、通信処理をJavaScriptに追加します。

// ---- socket ------
  // create socket
  var socketReady = false;
  var port = 9001;
  var socket = io.connect('http://localhost:/' + port + '/');
  // socket: channel connected
  socket.on('connect', onOpened)
        .on('message', onMessage);

  function onOpened(evt) {
    console.log('socket opened.');
    socketReady = true;
  }

  // socket: accept connection request
  function onMessage(evt) {
    if (evt.type === 'offer') {
      console.log("Received offer, set offer, sending answer....")
      onOffer(evt);	  
    } else if (evt.type === 'answer' && peerStarted) {
      console.log('Received answer, settinng answer SDP');
      onAnswer(evt);
    } else if (evt.type === 'candidate' && peerStarted) {
      console.log('Received ICE candidate...');
      onCandidate(evt);
    } else if (evt.type === 'user dissconnected' && peerStarted) {
      console.log("disconnected");
      stop();
    }
  }

重要なのはonMessage()の処理で、Offer SDP,Answer SDP,ICE Candidateのそれぞれに対応して、前回用意したOnOffer(), onAnswer(), onCandidate()を呼び出しています。

今度は実際にSDP/ICE Candidateを送る部分を変更します。前回はテキストエリアに表示するだけでしたが、今回はそれをsocket.io経由で送信します。

function sendSDP(sdp) {
    var text = JSON.stringify(sdp);
	console.log("---sending sdp text ---");
	console.log(text);
	textForSendSDP.value = text;
	
	// send via socket
	socket.json.send(sdp); // <--- ここを追加
  }
  
  function sendCandidate(candidate) {
    var text = JSON.stringify(candidate);
	console.log("---sending candidate text ---");
	console.log(text);
	textForSendICE.value = (textForSendICE.value + CR + iceSeparator + CR + text + CR);
	textForSendICE.scrollTop = textForSendICE.scrollHeight;
	
	// send via socket
	socket.json.send(candidate); // <--- ここを追加
  }

最後は、ちょっとしたフラグの処理の追加です。

function onOffer(evt) {
    console.log("Received offer...")
    console.log(evt);
    setOffer(evt);
    sendAnswer(evt);
    peerStarted = true;  // <--- ここを追加
  }

  // start the connection upon user request
  function connect() {
    if (!peerStarted && localStream && socketReady) { // <--- ここを変更
      sendOffer();
      peerStarted = true;
    } else {
      alert("Local stream not running yet - try again.");
    }
  }

  function stop() {
    peerConnection.close();
    peerConnection = null;
    peerStarted = false;  // <--- ここを追加
  }

実際に動かしてみよう

シグナリングサーバーが動いてることを確認したら、Chromeのウィンドウを2つ開いて修正したHTMLを読み込んでください。

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

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

前回の14ステップに比べて、ぐっと減って2ステップになりました。これなら使えそうですね。

シグナリングの流れを追ってみる

シグナリングの流れを追跡してみましょう。前回はコード上を追っかけたので、今回は流れを図で見てみます。

SDPの交換

SDPのOffer, Answerが、シグナリングサーバー経由で交換されます。

ICE Candidateの交換

複数のICE Candidateが飛び交い、すべての交換が終わるとPeer-to-Peer通信が始まります。

次回は

今回はシグナリングサーバーを動かして、Peer-to-Peer通信確立までを自動化しました（それが普通ですけど）。実は今回の仕組みでは、一つのシグナリングサーバーで同時に2人までしか通信できません。まったく実用的ではありません。次回は複数人での通信にチャレンジする予定です。

今回のソース

最後に、今回使ったHTMLを掲載しておきます。

WebRTC 1 to 1 signaling

SDP to send:
SDP to send

SDP to receive:

ICE Candidate to send:
ICE Candidate to send

ICE Candidates to receive:

＜バックナンバー＞

WebRTCに触ってみたいエンジニア必見！手動でWebRTC通信をつなげてみよう

がねこまさし — Thu, 13 Feb 2014 03:30:21 +0000

連載： WebRTCを使ってみよう！ (2)

こんにちは！がねこまさしです。前回はWebRTCでカメラを使いましたが、今回は通信をしてみましょう。

※こちらの記事は2014年に書かれました。2016年6月のアップデート記事がありますので、そちらもご参照ください。

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

WebRTCでは、映像や音声などリアルタイムに取得されたデータ（バイトストリーム）を、ブラウザ間で送受信することができます。それを司るのが　RTCPeerConnection です。 RTCPeerConnectionには2つの特徴があります。

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

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

P2P通信が確立するまで

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

Session Description Protocol (SDP)

各ブラウザの情報を示し、文字列で表現されます。例えば次のような情報を含んでいます。

セッションが含むメディアの種類（音声、映像）、メディアの形式（コーデック）
IPアドレス、ポート番号
P2Pのデータ転送プロトコル → WebRTCでは Secure RTP
通信で使用する帯域
セッションの属性（名前、識別子、アクティブな時間、など） → WebRTCでは使っていなさそう

Interactive Connectivity Establishment (ICE)

可能性のある通信経路に関する情報を示し、文字列で表現されます。次のような複数の経路を候補としてリストアップします。

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

候補が出そろったら、ネットワーク的に近い経路（オーバーヘッドの少ない経路）が選択されます。リストの上から順に優先です。※STUNやTURNについては、別の回で触れたいと思います。

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

このように、P2Pを始めるまでの情報のやり取りを「シグナリング」と言います。実は、WebRTCではシグナリングのプロトコルは規定されていません（自由に選べます）。シグナリングを実現するには複数の方法がありますが、今回は最も原始的な方法を試してみましょう。（理論的にできることは皆知っていますが、実際に試した人は少ないと思います。本邦初公開？）
ちょっと長いですが、こちらのHTMLをお好きなWebサーバーに配置してください。

WebRTC 1 to 1 handshake

SDP to send:
SDP to send

SDP to receive:

ICE Candidate to send:
ICE Candidate to send

ICE Candidates to receive:

Chromeを起動し、2つのウィンドウでWebサーバ上のHTMLにアクセスしてください。同一ウィンドウで複数タブを開くよりも、別のウィンドウで横に並べたほうが作業しやすいです。以降、間違えやすいので慎重に操作してくださいね。

※ 2014/04/03 訂正掲載したソースの45行目に誤りがありました。大変申し訳ありません。

誤 : var mediaConstraints = {'mandatory': {'OfferToReceiveAudio':false, 'OfferToReceiveVideo':true }}; 正 : var mediaConstraints = {'mandatory': {'OfferToReceiveAudio':true, 'OfferToReceiveVideo':true }};

SDPのやり取り

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

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

(3) これを全選択してコピーし、(4)右のウィンドウの[SDP to receive:]のテキストエリアにペーストします。

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

(6) 右のウィンドウの[SDP to send:]のテキストエリアを全選択してコピー、(7)左に戻って[SDP to receive:]のテキストエリアにペーストします。

(8) 左のウィンドウの[Receive SDP]ボタンをクリックします。ここまででSDPのやり取りが終わりました。

ICE Candidateのやり取り

通信経路を示すICE Candidateは、本来は1つずつやり取りされます。手動でやりとりするのは大変なので、今回は複数経路分まとめて渡してしまいましょう。

(9) 左のウィンドウの[ICE Candidate to send:]のテキストエリアを全選択してコピー、(10)右のウィンドウの[ICE Candidates to receive:]のテキストエリアにペーストします。

(11) 右のウィンドウの[Receive ICE Candidate]ボタンをクリックします。

(12) 右のウィンドウの[ICE Candidate to send:]のテキストエリアを全選択してコピー、(13)左に戻って[ICE Candidates to receive:]のテキストエリアにペーストします。

(14) 左のウィンドウの[Receive ICE Candidate]ボタンをクリックします。

これで上手くいけば、P2P通信が始まり両方のウィンドウに2つ目の動画が表示されるはずです。上手くいかない場合は、手順が抜けているか間違っている可能性があります。深呼吸してから両方のブラウザをリロードし、もう一度試してみてください。（私のソースのバグや、説明の間違いの可能性もあります。気がつかれたらご指摘ください）

SDPのやり取りを追ってみる

[Connect]ボタンを押してから、SDPのやり取りをソースで追ってみましょう。 ※ソースは抜粋しています。

function connect() {
  sendOffer();
}

function sendOffer() {
  peerConnection = prepareNewConnection(); // webkitRTCPeerConnection を生成し、コールバックを設定している
  peerConnection.createOffer(
    function (sessionDescription) { // in case of success
      peerConnection.setLocalDescription(sessionDescription);
      sendSDP(sessionDescription);
    },
    function () { // in case of error
      console.log("Create Offer failed");
    },
  mediaConstraints);
}

発信側で[Connect]ボタンを押すと connect() → sendOffer() という順に呼び出されます。中ではRTCPeerConnectionのインスタンスを生成し、そのインスタンスにSDPの作成を依頼します。SDPには通信開始を依頼するOfferと、応答するAnswerの2種類があり、ここではOfferを使います。

SDPはコールバック関数に渡されるので、何らかの手段を使って相手に渡します。今回のsendSDP()ではテキストエリアにSDPを表示するところまでになります。

function onOffer(evt) {
  setOffer(evt);
  sendAnswer(evt);
}
  
function setOffer(evt) {
  peerConnection = prepareNewConnection();  // webkitRTCPeerConnection を生成し、コールバックを設定している
  peerConnection.setRemoteDescription(new RTCSessionDescription(evt));
}
  
function sendAnswer(evt) {
  peerConnection.createAnswer(
    function (sessionDescription) { // in case of success
      peerConnection.setLocalDescription(sessionDescription);
      sendSDP(sessionDescription);
    },
    function () { // in case of error
      console.log("Create Answer failed");
    },
  mediaConstraints);
}

応答側にSDPを貼り付け、[Receive SDP]ボタンをクリックすると、onSDP() → onOffer() → setOffer() と呼び出されます。setOffer()の中ではRTCPeerConnectionのインスタンスを生成し、受け取ったOffer SDPを覚えさせます。

次にsendAnswer()で今度は応答用のAnswer SDPの生成を依頼し、コールバックからsendSDP()で発信側に送り返します。ここでもテキストエリアにSDPを表示するところまでになります。

function onAnswer(evt) {
  setAnswer(evt);
}

function setAnswer(evt) {
  peerConnection.setRemoteDescription(new RTCSessionDescription(evt));
}

発信側にSDPを貼り付け、[Receive SDP]ボタンをクリックすると、onSDP() → onAnswer() → setAnswer() と呼び出されます。setAnswer()の中では生成済のRTCPeerConnectionのインスタンスに受け取ったAnswer SDPを覚えさせます。

ICEのやり取りも追ってみる

同様に、ICE Candidateのやり取りも見てみましょう。まず、prepareNewConnection()の中身から。

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

    // send any ice candidates to the other peer
    peer.onicecandidate = function (evt) {
      if (evt.candidate) {
        console.log(evt.candidate);
        sendCandidate({type: "candidate", 
                          sdpMLineIndex: evt.candidate.sdpMLineIndex,
                          sdpMid: evt.candidate.sdpMid,
                          candidate: evt.candidate.candidate}
		);
      } else {
        console.log("End of candidates. ------------------- phase=" + evt.eventPhase);
      }
    };
    // ... 省略
}

ICE Candidateの生成は、非同期に発生します。そのためRTCPeerConnection.onicecandidateに、コールバック関数を指定します。今回は sendCandidate()を呼び出していますが、その中では例によってテキストエリアに追記する処理を行います。※ICE Candidateは複数個生成され、コールバックもその度に呼び出されます。

function onICE() {
  var text = textToReceiveICE.value;
  var arr = text.split(iceSeparator);
  for (var i = 1, len = arr.length; i < len; i++) {
    var evt = JSON.parse(arr[i]);
	onCandidate(evt);
  }
}
 
function onCandidate(evt) {
  var candidate = new RTCIceCandidate({sdpMLineIndex:evt.sdpMLineIndex, sdpMid:evt.sdpMid, candidate:evt.candidate});
  peerConnection.addIceCandidate(candidate);
}

ICE Candidateをペーストして[Receive ICE Candidates]ボタンをクリックすると、onICE()でテキストエリアの内容を分割し、1つ1つのICE Candidateを取り出します。それをonCandidate()に渡すと、RTCPeerConnectionのインスタンスにセットします。すべての経路の候補(ICE Candidate)の交換が終わると、P2P通信が開始されます。

手動シグナリングの改良版ソース(2014年4月21日追加）

手動シグナリングは操作が面倒なので、ちょっとでも楽になるように必要なテキストを自動で選択するようにしました。あとはコピー＆ペーストでできます。

WebRTC 1 to 1 handshake V2

SDP to send:
SDP to send

SDP to receive:

ICE Candidate to send:
ICE Candidate to send

ICE Candidates to receive:

※手動シグナリングはなぜか動作が不安定で、端末によっては通信が確立しないケースがあります（今のところ成功は4台/7台)。原因がさっぱりわからないのですが、もし心当たりがあったら教えていただけると助かります。情報求む！

次回は

以上、今回は原始的なビデオチャットを動かしてみました。同一PC上ではなく異なるPC間でも(FirewallやNATを挟まない場合は)、SDP/ICEの文字列をチャットなどで渡せば「原理上は」P2P通信は成立するはずです。（私はやってません…）

実際には手動でシグナリングなんかやってられません。次回はシグナリングサーバーを Node.js + socket.io で動かしてみたいと思います。

バックナンバーを読む

HTML5でWebRTCを使ってみよう！「カメラを使ってみよう」編

がねこまさし — Wed, 05 Feb 2014 01:00:04 +0000

連載： WebRTCを使ってみよう！ (1)

こんにちは！がねこまさしです。これから数回に渡って、WebRTCについて書かせていただきます。内容は2013年10月にNode学園祭2013で発表したプレゼンを、再構成したものになる予定です。

※こちらの記事は2014年に書かれました。2016年6月現在のアップデート記事がありますので、そちらもご参照ください。

WebRTCとは？

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

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

WebRTCで何ができるの？

WebRTCには大きく分けて2つの要素があります。

カメラ、マイクといったメディアへのアクセス(UserMedia)
Peer-to-Peer通信を行うための仕組み(RTCPeerConnection)

このほかにもHTML5の様々な要素と組み合わせて活用することができます。

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

ユーザーメディアを使ってみよう

それでは、さっそく使ってみましょう。ユーザーメディアで一番わかりやすいカメラを使います。Webカメラと最新のChromeかFirefoxをご用意ください。
※今回はChrome 32, Firefox 26で動作確認しています。



 
  Self Camera

こちらをお好きなWebサーバーに保存し、ChromeないしFirefoxでアクセスしてみてください。カメラにアクセスしても良いかどうか確認のダイアログが表示されますので、OKすればカメラの映像が表示されるはずです。
FireFoxの場合：

Chromeの場合：

上手く動けば、このように自分の顔が映ると思います。

※上手くいかない場合は、JavaScriptコンソールを表示してエラーを確認してくださいね。
ちなみに、HTMLをWebサーバーに置かずに直接開いた場合(file:// ～ )、Chromeではセキュリティ制限に引っかかりカメラにアクセスするこができません。FireFoxは現状の実装ではアクセスできるようです。

CSS3 と組み合わせてみる

WebRTCは他の要素と組み合わせて使うことができると、最初に書きました。実際にやってみましょう。
※コードを単純にするために、ここからはChrome用のコードを掲載します。Firefoxの場合は適宜プレフィックスを変更してください。

このようにvideoタグを変更すると、左右反転した鏡の状態になります。この方が自分では見慣れた姿に映ります。skypeなど多くのビデオチャットアプリは、左右反転状態がデフォルトになっているものが多いようです。

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

CSS3のアニメーション機能も利用できます。たとえばこんな風に。



 
  Rotate Camera

以上、ユーザメディア（カメラ）を使ってみました。次回は通信関連の要素についてご説明する予定です。

WebRTCを使ってみよう！ – HTML5Experts.jp

WebRTCで録画する！MediaRecoderを使ってみよう

Media Recorder API

早速録画してみる

再生するには

保存するには

終わりに

全体のソース

MediaRecorder Demo for Firefox

WebRTC落穂拾い：初心者がつまずきやすいポイントをフォロー

カメラがつながらない

ブラウザが違うケース

権限の制限に引っ掛かっている

Node.jsを使った簡易Webサーバー

うっかり「拒否」してしまった

なぜかカメラを認識しないケース

手動シグナリングが上手く行かない

シグナリングサーバーでつながらない

Firefoxでも使いたい

おわりに

壁を越えろ！WebRTCでNAT/Firewallを越えて通信しよう

NATを越えよう

NATの役割は

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

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

STUNの仕組みは

STUNサーバーを動かそう

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

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

Firewallを越えよう

TURNの仕組みは

Firewallに穴を空けよう

TURNサーバーを動かそう

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

Firewallはそのままで

TURNサーバを設定し直そう

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

最後に

シグナリングサーバーを応用！ 「WebRTCを使って複数人で話してみよう」

複数会議室を作ろう

複数人で通信してみたい

複数のPeer-to-Peer通信を扱うには

シグナリングを手直し

複数の映像を扱えるようにしよう

補足 （2014/03/09追記）

次回は

今回のソースコード

シグナリングサーバー (node.js)

クライアント側 (HTML, JavaScript)

WebRTC初心者でも簡単にできる！Node.jsで仲介（シグナリング）を作ってみよう

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

シグナリングサーバーはどうして必要なの？

Node.jsを準備しよう

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

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

実際に動かしてみよう

シグナリングの流れを追ってみる

SDPの交換

ICE Candidateの交換

次回は

今回のソース

＜バックナンバー＞

WebRTCに触ってみたいエンジニア必見！手動でWebRTC通信をつなげてみよう

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

P2P通信が確立するまで

Session Description Protocol (SDP)

Interactive Connectivity Establishment (ICE)

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

SDPのやり取り

ICE Candidateのやり取り

SDPのやり取りを追ってみる

ICEのやり取りも追ってみる

手動シグナリングの改良版ソース(2014年4月21日追加）

次回は

バックナンバーを読む

HTML5でWebRTCを使ってみよう！「カメラを使ってみよう」編

WebRTCとは？

WebRTCで何ができるの？

ユーザーメディアを使ってみよう

CSS3 と組み合わせてみる

シグナリングサーバーを応用！「WebRTCを使って複数人で話してみよう」

補足（2014/03/09追記）