More Related Content
Similar to TPAC 2015 WebRTC WG 最新レポート (20)
More from NTT Communications Technology Development (13)
TPAC 2015 WebRTC WG 最新レポート
- 1. Copyright © NTT Communications Corporation. All rights reserved.
TPAC WebRTC WG 最新レポート
@ 2015年度 第2回 W3C⽇本会員会議
NTTコミュニケーションズ
技術開発部
岩瀬 義昌
2015/12/21(⽉)
- 2. Copyright © NTT Communications Corporation. All rights reserved.
⾃⼰紹介
■名前
岩瀬 義昌 / @iwashi86
■仕事
NTTコミュニケーションズ 技術開発部
SkyWay(後述)の開発&運⽤
■コミュニティ活動
WebRTC Meetup Japan/Tokyo主催 等
- 3. Copyright © NTT Communications Corporation. All rights reserved.
3
WebRTCの開発者向けプラットフォーム
- 4. Copyright © NTT Communications Corporation. All rights reserved.
(おさらい) WebRTCとは
4
- 5. Copyright © NTT Communications Corporation. All rights reserved.
⾳声、映像、データのリアルタイム通信のオープン標準
• 従来のサービス(LINE、Skype等)は独⾃技術でできていた。
WebRTCはオープン標準、ライセンス使⽤料が不要。
• 中⾝は4つ。IETF(1-3)とW3C(4)で標準化
1. ⾳声と映像の形式(コーデック)
2. ネットワーク機器(NAT等)を越えて直接通信する⼿順
3. 暗号化、到達・順序保証、流量・輻輳制御
を実現するプロトコル
4. JavaScriptから利⽤するAPI
5
- 6. Copyright © NTT Communications Corporation. All rights reserved.
国内でのWebRTC利⽤事例
6
- 7. Copyright © NTT Communications Corporation. All rights reserved.
導⼊が進む⼀⽅で
現在のWebRTC仕様では
未解決の問題がまだまだある
⇒ TPACで議論
- 8. Copyright © NTT Communications Corporation. All rights reserved.
(TPACの議論を理解するために)
WebRTC界隈の全体動向を知る
- 9. Copyright © NTT Communications Corporation. All rights reserved.
WebRTC仕様の限界
・これまでに議論されてきたWebRTCの仕様は
VoIP時代に培われてきた技術である
SDP(RFC3264/4566)に強く依存しているが
WebRTCのユースケースに耐え切れなくなってきた
SDPの例
https://tools.ietf.org/html/rfc4566
- 10. Copyright © NTT Communications Corporation. All rights reserved.
ORTC -> WebRTC NV の登場
・そこにSDPへの依存を排除する
ORTC(Object RTC)が登場。
ORTCの思想は、WebRTC関係者でも認められ
W3C側でもORTC CG発⾜。
(Extensible Webの潮流の1つとも⾔える)
https://www.w3.org/community/ortc/
- 11. Copyright © NTT Communications Corporation. All rights reserved.
ORTC -> WebRTC NV の登場
・⼀⽅で、WebRTC 1.0 の策定は延び延びと
なっている状況であった。
延期された結果
2015年4QがCR期限となった
- 12. Copyright © NTT Communications Corporation. All rights reserved.
ORTC -> WebRTC NV の登場
・⼀⽅で、WebRTC 1.0 の策定は延び延びと
なっている状況であった。
・そこで、WebRTC 1.0(SDP前提) の仕様を凍結させ、
その後に次のWebRTC仕様である
WebRTC NV(Next Version)について議論したい、
というのがWebRTCの全体動向。
本家WebRTC
ORTC
WebRTC NV
WebRTC 1.0
ORTCのアイデアをマージ
- 13. Copyright © NTT Communications Corporation. All rights reserved.
ORTC -> WebRTC NV の登場
・⼀⽅で、WebRTC 1.0 の策定は延び延びと
なっている状況であった。
・そこで、WebRTC 1.0(SDP前提) の仕様を凍結させ、
その後に次のWebRTC仕様である
WebRTC NV(Next Version)について議論したい、
というのがWebRTCの全体動向。
今回のTPAC WebRTC WGの⽬的:
WebRTC 1.0に⼊れる仕様の
最終合意を図ること
- 14. Copyright © NTT Communications Corporation. All rights reserved.
(これを踏まえて)
TPAC2015 WebRTC WGの議論
- 15. Copyright © NTT Communications Corporation. All rights reserved.
1. サイマルキャスト
2. IPリーク
- 16. Copyright © NTT Communications Corporation. All rights reserved.
1. サイマルキャスト
2. IPリーク
- 17. Copyright © NTT Communications Corporation. All rights reserved.
これまでのWebRTC(P2P)
- 18. Copyright © NTT Communications Corporation. All rights reserved.
フルメッシュ型で多⼈数接続(4⼈)
- 19. Copyright © NTT Communications Corporation. All rights reserved.
ノードが増えるとスケールしない
- 20. Copyright © NTT Communications Corporation. All rights reserved.
そこでスタートポロジ(SFU利⽤)
SFU
上りのストリームを、全員が1本送る
SFU: Selective Forwarding Unit
- 21. Copyright © NTT Communications Corporation. All rights reserved.
そこでスタートポロジ(SFU利⽤)
SFU
下りのストリームを、全員が⼈数分受け取る(数は3本)
- 22. Copyright © NTT Communications Corporation. All rights reserved.
もし、モバイルがいたら?
- 23. Copyright © NTT Communications Corporation. All rights reserved.
PC品質のストリームを処理できない
SFU
モバイル回線は⽐較的低速
- 24. Copyright © NTT Communications Corporation. All rights reserved.
そこでサイマルキャスト
- 25. Copyright © NTT Communications Corporation. All rights reserved.
利⽤可能帯域によって送受信品質を変える
・リッチな送信側クライアントは⾼品質と低品質を送る
・貧弱なクライアントは低品質だけ受信する
SFU
⾼品質
低品質
- 26. Copyright © NTT Communications Corporation. All rights reserved.
利⽤可能帯域によって送受信品質を変える
・リッチな送信側クライアントは⾼品質と低品質を送る
・貧弱なクライアントは低品質だけ受信する
SFU
⾼品質
低品質
同時に(Simul)複数ストリームを
配信(cast)するのでサイマルキャスト
- 27. Copyright © NTT Communications Corporation. All rights reserved.
TPACで議論ポイント
・そもそもWebRTC 1.0でSimulcastを含めるのか?
⇒含めることになった
・どうやって⾼品質と低品質をJS APIから指定するか?
- 28. Copyright © NTT Communications Corporation. All rights reserved.
TPACで議論ポイント
・そもそもWebRTC 1.0でSimulcastを含めるのか?
⇒含めることになった
・どうやって⾼品質と低品質をJS APIから指定するか?
rid(ストリーム間の識別⼦)を
誰が決めるのか?ブラウザ or JS?
- 29. Copyright © NTT Communications Corporation. All rights reserved.
TPACで議論ポイント
・そもそもWebRTC 1.0でSimulcastを含めるのか?
⇒含めることになった
・どうやって⾼品質と低品質をJS APIから指定するか?
rid(ストリーム間の識別⼦)を
誰が決めるのか?ブラウザ or JS?
⇒ Javascriptで開発者が指定
- 30. Copyright © NTT Communications Corporation. All rights reserved.
On the wireで流れるのがSDP
- 31. Copyright © NTT Communications Corporation. All rights reserved.
On the wireで流れるのがSDP
SDP
- 32. Copyright © NTT Communications Corporation. All rights reserved.
On the wireで流れるのがSDP
SDP
- 33. Copyright © NTT Communications Corporation. All rights reserved.
SDPはIETFの策定領域
SDP
・SDPの内容はIETF(mmusic WG)の策定領域
⇒歴史的に⾒て、仕様策定に時間がかかる
・W3C側でAPIを先に規定して
IETFを待たずに使えるようにブラウザ側の実装は進⾏中
(仮にSDPの仕様変更が間に合わない場合は、
SDP以外の何らかの⼿段で情報を伝える)
IETF側の仕様
- 34. Copyright © NTT Communications Corporation. All rights reserved.
1. サイマルキャスト
2. IPリーク
- 35. Copyright © NTT Communications Corporation. All rights reserved.
先に前提
・WebRTCは内部でICE(RFC5245)を利⽤
・ICEはP2Pの接続確率を⾼めるため、
⾃⾝が通信可能なIP/Portを全て収集する
STUNNATClient
①私のグローバルIPは?
②グローバルIPは とわかる
これを専⽤のパケットに詰めて返信
③ と知る
ICE動作の⼀部
- 36. Copyright © NTT Communications Corporation. All rights reserved.
36
問題の発端:NYTimesがWebRTCでIP収集
STUNのパケット
(⾒えにくいですが)
- 37. Copyright © NTT Communications Corporation. All rights reserved.
37
STUNのパケット
(⾒えにくいですが)
個⼈特定につながる
(同じNAT配下にいても)
問題の発端:NYTimesがWebRTCでIP収集
https://twitter.com/incloud/status/619624021123010560
- 38. Copyright © NTT Communications Corporation. All rights reserved.
38
TPACで議論された対処⽅法
1. 全ての候補を収集する
(ただし、getUserMediaの同意があるときのみ)
2. 制限付き収集その1[デフォル⼘動作]
(デフォルトNICにBINDされるホスト候補のみ
+ プライベートアドレス(RFC1918)の候補?)
3. 制限付き収集その2
(ホスト候補無し。設定や拡張)
4. プロキシのみ(設定や拡張)
- 39. Copyright © NTT Communications Corporation. All rights reserved.
39
TPACで議論された対処⽅法
1. 全ての候補を収集する
(ただし、getUserMediaの同意があるときのみ)
2. 制限付き収集その1[デフォル⼘動作]
(デフォルトNICにBINDされるホスト候補のみ
プライベートアドレス(RFC1918)の候補?)
3. 制限付き収集その2
(ホスト候補無し。設定や拡張)
4. プロキシのみ(設定や拡張)
- 40. Copyright © NTT Communications Corporation. All rights reserved.
40
TPACで議論された対処⽅法
1. 全ての候補を収集する
(ただし、getUserMediaの同意があるときのみ)
2. 制限付き収集その1[デフォル⼘動作]
(デフォルトNICにBINDされるホスト候補のみ
プライベートアドレス(RFC1918)の候補?)
3. 制限付き収集その2
(ホスト候補無し。設定や拡張)
4. プロキシのみ(設定や拡張)
カメラ、マイクについての同意だが、
IPアドレス収集にも使われる点に注意
- 41. Copyright © NTT Communications Corporation. All rights reserved.
41
TPACで議論された対処⽅法
1. 全ての候補を収集する
(ただし、getUserMediaの同意があるときのみ)
2. 制限付き収集その1[デフォル⼘動作]
(デフォルトNICにBINDされるホスト候補のみ
+ プライベートアドレス(RFC1918)の候補?)
3. 制限付き収集その2
(ホスト候補無し。設定や拡張が必要)
4. プロキシのみ(設定や拡張)
- 42. Copyright © NTT Communications Corporation. All rights reserved.
42
TPACで議論された対処⽅法
1. 全ての候補を収集する
(ただし、getUserMediaの同意があるときのみ)
2. 制限付き収集その1[デフォル⼘動作]
(デフォルトNICにBINDされるホスト候補のみ
+ プライベートアドレス(RFC1918)の候補?)
3. 制限付き収集その2
(ホスト候補無し。設定や拡張が必要)
4. プロキシのみ(設定や拡張)
プライベートIPを収集するかどうかは、
既存のWebRTCアプリがどの程度壊れるかに依存する。
なので、実験して決めることになった。
- 44. Copyright © NTT Communications Corporation. All rights reserved.
44
まとめ
• ORTC/WebRTC NVの後押しがある中、
WebRTC 1.0に向けた仕様をTPACで議論
• TPACで⽩熱した議論のトピックのうち
・サイマルキャスト
・IPリーク
を紹介
• その他トピックについては議事録を参照のこと
- http://www.w3.org/2015/09/09-webrtc-minutes.html
- http://www.w3.org/2015/09/10-webrtc-minutes.html