Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

TPAC 2015 WebRTC WG 最新レポート

1,889 views

Published on

2015年度の第2回 W3C日本会員会議にて講演させていただいた際のスライドです。

Published in: Technology
  • Be the first to comment

TPAC 2015 WebRTC WG 最新レポート

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

×