WebRTCプラットフォーム tokboxのopentokを調べてみた(4) PeerConnection編

## 最終回では
最終回となる今回は、実際にJavaScriptクライアントライブラリを使ってみて気が付いた、小ネタについて書いてみます。
ライブラリ/SDKの使い方については、公式ドキュメントやGitHubのサンプルがあるので、そちらをご覧ください。

* <a href="https://tokbox.com/opentok/libraries/client/" target="_blank">OpenTok WebRTC Client Libraries</a>
* <a href="https://tokbox.com/opentok/libraries/server/" target="_blank">OpenTok Server SDKs</a>
* <a href="https://github.com/opentok/" target="_blank">GitHub上のサンプル</a>

## 一般的なビデオチャットの場合
### PeerConnectionの使い方
WebRTCの通信を司るPeerConnectionは、映像/音声を双方向にやりとりできます。したがって、1ペアにつき1つのPeerConnectionオブジェクトを使います。
![peerconnection_usual.png](https://qiita-image-store.s3.amazonaws.com/0/19403/53002e98-84f2-f8e7-8077-8247216080e8.png)

### 内側を覗いてみると
この時、Chromeのツール chrome://webrtc-internals で見ると、次のようにsend/recv(送信/受信)が2つずつ(映像と音声)表示されます。
![webrtc_in_talkin_peer_mix.png](https://qiita-image-store.s3.amazonaws.com/0/19403/877ce2fe-3120-ed07-b141-69107f8e6f12.png)

## opentokのビデオチャットの場合
### 内側を覗いてみると
opentokを使って1対1の双方向ビデオチャットを行っている状態で chrome://webrtc-internals を開くと、先ほどと違いPeerConnectionのタブが2つ存在することが分かります。
そして1つめのタブを見ると、send(送信)が2つ(映像と音声)があり、recv(受信)がありません。
![webrtc_in_toxbox_peerA_mix.png](https://qiita-image-store.s3.amazonaws.com/0/19403/c966635d-95f6-e609-72ad-9676b0a15c14.png)

一方2つ目のタブを見てみると、sendは無くてrecv(受信)が2つです。送信と受信でPeerConnectionを使い分けていることが分かります。
![webrtc_in_toxbox_peerB_mix.png](https://qiita-image-store.s3.amazonaws.com/0/19403/9fbc93a4-09c0-f8b3-1cd6-e5c27b73469c.png)

### PeerConnectionの使い方
webrtc-internalsの情報から考えると、PeerConnectionはこのようになっているはずです。（コードは読んでません...）
![peerconnection_tokbox.png](https://qiita-image-store.s3.amazonaws.com/0/19403/dc3a1d67-3430-d04a-9a44-4dfc6667f16c.png)

### SFUとPeerConnection
どうしてPeerConnectionを使い分けているのか？ それはopentokがSFUを使っているからと推測されます。
SFUの場合、<a href="http://qiita.com/massie_g/items/77f6916b70a3e21a3cb0" target="_blank">前回の記事のように</a>上り(送信)が1本、下り(受信)が複数になります。そのためPeerConnectionを双方向通信でなく、片方向通信に使っていると推測されます。
opentokは片方向多人数の配信もサポートしていますが、共通の仕組みでシンプルに実装できているはずです。

### 3人目が加わったら
ここまでの推測が正しいとすると、3人目が会議に加わったら次のようになるはずです。

* sendのみのPeerConnectionが1つ、recvのみのPeerConnectionが2つ

実際にやってみたところ、webrtc-internalsの情報はこの通り。
![webrtc_in_toxbox_3people.png](https://qiita-image-store.s3.amazonaws.com/0/19403/c21f1898-54af-bfbd-54a7-febe6784360b.png)

![webrtc_in_toxbox_3people_recv.png](https://qiita-image-store.s3.amazonaws.com/0/19403/917d1ddf-df33-5e1d-1234-db8f768ac5f1.png)

予想通り、recv専用のPeerConnectionが増えて2つになりました。

## おわりに
以上、4回にわたってWebRTCの定番サービス、opentokを調べてきました。

* 基礎編、利用料金編は公開情報のまとめ (2015年4月現在）
* 通信経路編、PeerConnection編は挙動からの推測

有償サービスを長く続けているだけあって、さまざまな工夫がうかがえます。WebRTCをベースにした本格的なサービスを構築する場合には、やっぱり最有力候補ですね。

また今回はiOS/Androidネイティブライブラリは試していません。どなたかがネイティブ編を書いてくれることを、期待しています。

## 記事一覧
* <a href="http://qiita.com/massie_g/items/dc6615799ef65ab1a6e4" target="_blank">WebRTCプラットフォーム tokboxのopentokを調べてみた(1) 基礎編</a>
* <a href="http://qiita.com/massie_g/items/7b8eaf87f0a652973399" target="_blank">WebRTCプラットフォーム tokboxのopentokを調べてみた(2) 利用料金編</a>
* <a href="http://qiita.com/massie_g/items/77f6916b70a3e21a3cb0" target="_blank">WebRTCプラットフォーム tokboxのopentokを調べてみた(3) 通信経路編</a>
* <a href="http://qiita.com/massie_g/items/af3ee666969b41293478" target="_blank">WebRTCプラットフォーム tokboxのopentokを調べてみた(4) PeerConnection編</a>