最終回では
最終回となる今回は、実際にJavaScriptクライアントライブラリを使ってみて気が付いた、小ネタについて書いてみます。
ライブラリ/SDKの使い方については、公式ドキュメントやGitHubのサンプルがあるので、そちらをご覧ください。
一般的なビデオチャットの場合
PeerConnectionの使い方
WebRTCの通信を司るPeerConnectionは、映像/音声を双方向にやりとりできます。したがって、1ペアにつき1つのPeerConnectionオブジェクトを使います。
内側を覗いてみると
この時、Chromeのツール chrome://webrtc-internals で見ると、次のようにsend/recv(送信/受信)が2つずつ(映像と音声)表示されます。
opentokのビデオチャットの場合
内側を覗いてみると
opentokを使って1対1の双方向ビデオチャットを行っている状態で chrome://webrtc-internals を開くと、先ほどと違いPeerConnectionのタブが2つ存在することが分かります。
そして1つめのタブを見ると、send(送信)が2つ(映像と音声)があり、recv(受信)がありません。
一方2つ目のタブを見てみると、sendは無くてrecv(受信)が2つです。送信と受信でPeerConnectionを使い分けていることが分かります。
PeerConnectionの使い方
webrtc-internalsの情報から考えると、PeerConnectionはこのようになっているはずです。（コードは読んでません...）
SFUとPeerConnection
どうしてPeerConnectionを使い分けているのか？ それはopentokがSFUを使っているからと推測されます。
SFUの場合、前回の記事のように上り(送信)が1本、下り(受信)が複数になります。そのためPeerConnectionを双方向通信でなく、片方向通信に使っていると推測されます。
opentokは片方向多人数の配信もサポートしていますが、共通の仕組みでシンプルに実装できているはずです。
3人目が加わったら
ここまでの推測が正しいとすると、3人目が会議に加わったら次のようになるはずです。
- sendのみのPeerConnectionが1つ、recvのみのPeerConnectionが2つ
実際にやってみたところ、webrtc-internalsの情報はこの通り。
予想通り、recv専用のPeerConnectionが増えて2つになりました。
おわりに
以上、4回にわたってWebRTCの定番サービス、opentokを調べてきました。
- 基礎編、利用料金編は公開情報のまとめ (2015年4月現在）
- 通信経路編、PeerConnection編は挙動からの推測
有償サービスを長く続けているだけあって、さまざまな工夫がうかがえます。WebRTCをベースにした本格的なサービスを構築する場合には、やっぱり最有力候補ですね。
また今回はiOS/Androidネイティブライブラリは試していません。どなたかがネイティブ編を書いてくれることを、期待しています。