TPAC 2015 WebRTC WG 最新レポート

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

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/

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に⼊れる仕様の最終合意を図ること

29. Copyright © NTT Communications Corporation. All rights reserved. TPACで議論ポイント・そもそもWebRTC 1.0でSimulcastを含めるのか？ ⇒含めることになった・どうやって⾼品質と低品質をJS APIから指定するか？ rid(ストリーム間の識別⼦)を誰が決めるのか？ブラウザ or JS？ ⇒ Javascriptで開発者が指定

33. Copyright © NTT Communications Corporation. All rights reserved. SDPはIETFの策定領域 SDP ・SDPの内容はIETF(mmusic WG)の策定領域 ⇒歴史的に⾒て、仕様策定に時間がかかる・W3C側でAPIを先に規定して IETFを待たずに使えるようにブラウザ側の実装は進⾏中 (仮にSDPの仕様変更が間に合わない場合は、 SDP以外の何らかの⼿段で情報を伝える) IETF側の仕様

35. Copyright © NTT Communications Corporation. All rights reserved. 先に前提・WebRTCは内部でICE(RFC5245)を利⽤・ICEはP2Pの接続確率を⾼めるため、⾃⾝が通信可能なIP/Portを全て収集する STUNNATClient ①私のグローバルIPは？ ②グローバルIPはとわかるこれを専⽤のパケットに詰めて返信 ③ と知る ICE動作の⼀部

38. Copyright © NTT Communications Corporation. All rights reserved. 38 TPACで議論された対処⽅法 1. 全ての候補を収集する (ただし、getUserMediaの同意があるときのみ) 2. 制限付き収集その１[デフォル⼘動作] (デフォルトNICにBINDされるホスト候補のみ + プライベートアドレス(RFC1918)の候補？) 3. 制限付き収集その２ (ホスト候補無し。設定や拡張) 4. プロキシのみ(設定や拡張)

39. Copyright © NTT Communications Corporation. All rights reserved. 39 TPACで議論された対処⽅法 1. 全ての候補を収集する (ただし、getUserMediaの同意があるときのみ) 2. 制限付き収集その１[デフォル⼘動作] (デフォルトNICにBINDされるホスト候補のみプライベートアドレス(RFC1918)の候補？) 3. 制限付き収集その２ (ホスト候補無し。設定や拡張) 4. プロキシのみ(設定や拡張)

40. Copyright © NTT Communications Corporation. All rights reserved. 40 TPACで議論された対処⽅法 1. 全ての候補を収集する (ただし、getUserMediaの同意があるときのみ) 2. 制限付き収集その１[デフォル⼘動作] (デフォルトNICにBINDされるホスト候補のみプライベートアドレス(RFC1918)の候補？) 3. 制限付き収集その２ (ホスト候補無し。設定や拡張) 4. プロキシのみ(設定や拡張) カメラ、マイクについての同意だが、 IPアドレス収集にも使われる点に注意

41. Copyright © NTT Communications Corporation. All rights reserved. 41 TPACで議論された対処⽅法 1. 全ての候補を収集する (ただし、getUserMediaの同意があるときのみ) 2. 制限付き収集その１[デフォル⼘動作] (デフォルトNICにBINDされるホスト候補のみ + プライベートアドレス(RFC1918)の候補？) 3. 制限付き収集その２ (ホスト候補無し。設定や拡張が必要) 4. プロキシのみ(設定や拡張)

42. Copyright © NTT Communications Corporation. All rights reserved. 42 TPACで議論された対処⽅法 1. 全ての候補を収集する (ただし、getUserMediaの同意があるときのみ) 2. 制限付き収集その１[デフォル⼘動作] (デフォルトNICにBINDされるホスト候補のみ + プライベートアドレス(RFC1918)の候補？) 3. 制限付き収集その２ (ホスト候補無し。設定や拡張が必要) 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

TPAC 2015 WebRTC WG 最新レポート

NTT Communications Technology Development

TPAC 2015 WebRTC WG 最新レポート

A particular slide catching your eye?