Successfully reported this slideshow.

TPAC 2015 WebRTC WG 最新レポート

4

Share

Loading in …3
×
1 of 44
1 of 44

More Related Content

Slideshows for you

Viewers also liked

Related Books

Free with a 30 day trial from Scribd

See all

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

×