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の予定.