WebRTC meetup TOKYO#5 勉強会メモ

昨日,WebRTC勉強会に行ってきた.
WebRTC Meetup Tokyo #5

ネットワーク周りの深い話が個人的にはとても楽しかった.
当たり前に繋がることを作る/維持するコストって大変ですよね.


何かネタを出して発表とかもしてみたいなあ.
昨日学んだことはXMS最強伝説.


間違いがありましたらご指摘ください.

ハンズオンSkyWay を使ってビデオチャットを作ります。

 それから、TURNサーバなんかも準備しちゃいます!
 http://www.slideshare.net/yusukenaka52/skyway-handson

・WebRTCのプラットフォームであるSkyWayを使ってハンズオン形式で,
 多人数の会議アプリをHTML+JavaScriptだけで作る.

 開場のWi-FiはLAN内で通信できないので,
 TURNサーバを経由してpeer同士をフルメッシュで繋げる.

・peer.jsも同じAPIKEYを使っているユーザリストを取得できるようになるかも.
 Skywayで先に実装した.
 peer.list...()がそう.

・ハンズオンの流れ
 1.SkywayでAPI KEYを取得
 2.HTMLとJSのテンプレートにAPI KEYと処理を埋め込む
  ・API KEYを記述
  ・peer IDの取得処理(任意のpeer IDを設定可能)
  ・peer参加時の処理
   ・コネクションを管理オブジェクトに追加
   ・接続してきたpeerの画面を追加
   ・画面追加によるリサイズ
 3.STUNサーバで繋がらないことを確認する
 4.TURNサーバを使って繋がることを確認する

・TURNサーバは日本で商用サービスは無い.
 今回はコミュニケーションズのクラウドを使っている.

Q:ハンズオンで使っているサーバは?
 →rfc5766-turn-severをCentOSで動かしている.
  https://code.google.com/p/rfc5766-turn-server/
  
  インストール手順はDialogicの資料が役に立つ.
  http://www.dialogic.com/den/developer_forums/f/71/t/10238.aspx
  
  GoogleのTURNサーバはワンタイムトークンを使っていて,
  一般ユーザは使えないらしい.

Q:TURNで繋がっていることをどう確認すれば良いのか?
 →peerの間にFWを挟んでp2pで繋げない環境を作って確認している.・
  ICE canditatesの中で「relay」の記述が出て来ていたら,
  TURNで接続しようとしていることが分かるので,
  candidatesのみを通すようにすれば良い.
  
  chrome://webrtc-internalsで対向のpeerのIPアドレスが分かるので,
  TURNサーバを使っているかは分かる.

20:45〜21:05 セッションWebRTCの裏側にあるNATの話@iwashi86

 http://www.slideshare.net/iwashi86/webrtcnat-a-talk-on-nat-behind-webrtc

・NATについてはRFC 4787を良く読む必要がある.
 
 ・RFC 3489
  クラシックSTUN:RFC 3489(Obsoleted)
  http://tools.ietf.org/html/rfc3489
 
 →3489で分類が足りなくなったので,4787が新たに作られた.
 ・RFC4787
  Network Address Translation (NAT) Behavioral Requirements for Unicast UDP
  http://tools.ietf.org/html/rfc4787

 基本的な概念はRFC3489に書いてある.

RFC 4787でUDPNAT超えの14個要件が定義されている.

・NAT変換のマッピングは3種類ある.
 1.エンドポイントに依存しない.
 発側が同じなら,宛先が違っても同じIP:ポートのマッピングを使う.
 →IP:ポートの組み合わせでLAN内の端末を外側から指定できる.
 
 2.アドレスに依存しない
 宛先のアドレス別に違うポートを払い出す.
 
 3.アドレスとポートに依存する。
 アドレスとポートの組み合わせに依存して同じマッピングを払い出す.

 STUNにとっては1が望ましい.

p2p接続にとっては企業内のネットワークで,
 IPアドレスプールを使って都度IPアドレスが変わるのは困る.
 ポート多重も困る.

・その他にも利用するポート番号の奇数と偶数はrtpとrtcpでルールがあるので,
 気をつけたほうが良い.

・NATによってはNAT前後のIPレンジが送受で同じになることがある.
 回避するにはNATフォワーディング?が必要.

・フィルタリングもマッピングと同じで,
 エンドポイントに依存しない1が最も望ましい.

 しかしながら,どこからでも特定の端末に接続できることになるので,
 p2p的に最高だがセキュリティの問題がある.
 エンドポイントからいくらでも通し放題になる.
 
 なので2番でも許容する.

・ALG(Application Level Gateway)は勝手にアドレスを書き換えるので,
 P2Pにとっていは問題である.

RFC 5780でNATの組み合わせが網羅されている.
 NAT1-3ならSTUNで大抵つながる.

マッピング,フィルタリングの動作は装置依存なので,要動作確認.
 コナミの資料がある。

 http://homepage3.nifty.com/toremoro/study/voip2008/NATTraversal.pdf
 P2P通信技術とNAT超え

Q:TURNが繋がらないことがあるケースはあるのか?
 →海外サイトを見るとあるらしいが未確認.
 
Q:どの構成なら繋がらないなど、アプリの開発者は気にする必要があるのか?
 →プラットフォームが接続性を担保するように取り組んでいる.
  Skywayはそう.
 →アプリで解決するならWindwos,AndroidでSTUNライブラリがある.

21:05〜21:15 LT1 Stats API(仮)@massie_g

 http://www.slideshare.net/mganeko/webrtc-getstats-meetup5-lt
 
・RTCPeerCOnnection.getStats(callback(rs))でRTCPのスタッツ(RTCStatReport)が取れる.
.names()

・RTCStatReportは2-3階層のリスト構造でRTCPフィードバック観測時点毎のスタッツを持つ.

・iceConnectionStateだとfailedにならない。
 →タイマーを持って監視して接続断を検出しないといけなそう.

21:15〜21:25 LT2OSS MCUで遊んでみた。今度は下り一本化! @tonofo

・前回までは上りだけ1つのストリームにまとめていたが,
 今回は下りも1つにまとめて帯域コストを経済的にする.

OSSベースでMCUを使おうとするとKurentoが有望.
 http://www.kurento.org/

・Kurentoはリポジトリからダウンロードしてすぐに利用できる.

・Kurentoの処理モデルは各クライアントのストリームを,
 パイプライン単位のように機能ブロックに繋げていく.
 
 総合変換できれば,SIP,WEBRTCも繋げられる.

MCUを一本にするには1つのシンク(Composite)で複数のコネクションを貼れば良い.
 Compositeだと各人のデコード→合成ができる.
 トランスコーディングも勝手にしてくれる.(VP8->H.264

 APIも充実している.
  JS(JSONP)
  JAVA(Spring) など

・アプリとの連携は2行で済む.
 RecorderEndpointからの読み込みとAPIを叩くだけ.

・Plumberでストリームをサーバ間で共有する機能はある.
 →ストリーミング版のcdnみたいなもの.

・Kurentoは2016年度まで資金は続くので,プロジェクトの継続性はある.

・しかしながら,会議室モードで誰か一人の接続が切れると,全員が落ちてしまう.

 なんで落ちるのか調べるとNativeのGStreamerの処理周りのようだ.
 →GStreamer最下層のCompositorで止まっている.
  下のレイヤーなのでバッファをいじるなど,
  低レベルの制御が必要でインパクトが大きそう.

21:25〜21:35 LT3Chrome Extensionでスクリーンシェアをやってみる@Tukimikage

 http://www.slideshare.net/yusukenaka52/screenshare-public

Chromeの資料共有はExtensionが必要.
 FIrefoxはそもそも対応していない.

・WebApp->ScreenShare.js->Extension(Bridhge.js)->Extension(Backgroundjs)
 BackgroundjsでストリーマIDを取得してWebAppまで戻して表示している.
 多分スクリーンかウィンドウをストリーム化している.

・getUsermedia()でmandatoryでシェアオプションをつければできる.

21:35〜21:40 クロージング次回告知等@iwashi

次回は2015/1の予定.