TPAC 2015 WebRTC WG 最新レポート

Copyright © NTT Communicat ions Corporat ion. All rights reserved.

TPAC WebRTC WG 最新レポート@ 2015年度第2回 W3C⽇本会員会議

NTTコミュニケーションズ技術開発部岩瀬義昌2015/12/21(⽉)


⾃⼰紹介

■名前岩瀬義昌 / @iwashi86

■仕事NTTコミュニケーションズ技術開発部SkyWay(後述)の開発&運⽤

■コミュニティ活動WebRTC Meetup Japan/Tokyo主催等


3

WebRTCの開発者向けプラットフォーム


(おさらい) WebRTCとは

4


⾳声、映像、データのリアルタイム通信のオープン標準

• 従来のサービス(LINE、Skype等)は独⾃技術でできていた。WebRTCはオープン標準、ライセンス使⽤料が不要。

• 中⾝は4つ。IETF(1-3)とW3C(4)で標準化1. ⾳声と映像の形式(コーデック)2. ネットワーク機器(NAT等)を越えて直接通信する⼿順3. 暗号化、到達・順序保証、流量・輻輳制御

を実現するプロトコル4. JavaScriptから利⽤するAPI

5


国内でのWebRTC利⽤事例

6


導⼊が進む⼀⽅で現在のWebRTC仕様では未解決の問題がまだまだある

⇒ TPACで議論


（TPACの議論を理解するために）WebRTC界隈の全体動向を知る


WebRTC仕様の限界・これまでに議論されてきたWebRTCの仕様は

VoIP時代に培われてきた技術であるSDP(RFC3264/4566)に強く依存しているがWebRTCのユースケースに耐え切れなくなってきたSDPの例

https://tools.ietf.org/html/rfc4566


ORTC -> WebRTC NV の登場・そこにSDPへの依存を排除する

ORTC(Object RTC)が登場。ORTCの思想は、WebRTC関係者でも認められW3C側でもORTC CG発⾜。(Extensible Webの潮流の1つとも⾔える)

https://www.w3.org/community/ortc/


ORTC -> WebRTC NV の登場・⼀⽅で、WebRTC 1.0 の策定は延び延びと

なっている状況であった。

延期された結果2015年4QがCR期限となった




・そこで、WebRTC 1.0(SDP前提) の仕様を凍結させ、その後に次のWebRTC仕様であるWebRTC NV(Next Version)について議論したい、というのがWebRTCの全体動向。

本家WebRTC

ORTC

WebRTC NVWebRTC 1.0

ORTCのアイデアをマージ




・そこで、WebRTC 1.0(SDP前提) の仕様を凍結させ、その後に次のWebRTC仕様であるWebRTC NV(Next Version)について議論したい、というのがWebRTCの全体動向。今回のTPAC WebRTC WGの⽬的：

WebRTC 1.0に⼊れる仕様の最終合意を図ること


（これを踏まえて）TPAC2015 WebRTC WGの議論


1. サイマルキャスト2. IPリーク


これまでのWebRTC(P2P)


フルメッシュ型で多⼈数接続(4⼈)


ノードが増えるとスケールしない


そこでスタートポロジ(SFU利⽤)

SFU

上りのストリームを、全員が1本送る

SFU: Selective Forwarding Unit


そこでスタートポロジ(SFU利⽤)

SFU

下りのストリームを、全員が⼈数分受け取る(数は3本)


もし、モバイルがいたら？


PC品質のストリームを処理できない

SFU

モバイル回線は⽐較的低速


そこでサイマルキャスト


利⽤可能帯域によって送受信品質を変える・リッチな送信側クライアントは⾼品質と低品質を送る・貧弱なクライアントは低品質だけ受信する

SFU⾼品質

低品質


利⽤可能帯域によって送受信品質を変える・リッチな送信側クライアントは⾼品質と低品質を送る・貧弱なクライアントは低品質だけ受信する

SFU⾼品質

低品質

同時に(Simul）複数ストリームを配信(cast)するのでサイマルキャスト


TPACで議論ポイント・そもそもWebRTC 1.0でSimulcastを含めるのか？

⇒含めることになった

・どうやって⾼品質と低品質をJS APIから指定するか？





rid(ストリーム間の識別⼦)を誰が決めるのか？ブラウザ or JS？





rid(ストリーム間の識別⼦)を誰が決めるのか？ブラウザ or JS？

⇒ Javascriptで開発者が指定


On the wireで流れるのがSDP


On the wireで流れるのがSDP

SDP


SDPはIETFの策定領域

SDP

・SDPの内容はIETF(mmusic WG)の策定領域⇒歴史的に⾒て、仕様策定に時間がかかる

・W3C側でAPIを先に規定してIETFを待たずに使えるようにブラウザ側の実装は進⾏中(仮にSDPの仕様変更が間に合わない場合は、

SDP以外の何らかの⼿段で情報を伝える)

IETF側の仕様


1. サイマルキャスト2. IPリーク


先に前提・WebRTCは内部でICE(RFC5245)を利⽤・ICEはP2Pの接続確率を⾼めるため、

⾃⾝が通信可能なIP/Portを全て収集する

STUNNATClient

①私のグローバルIPは？

②グローバルIPはとわかるこれを専⽤のパケットに詰めて返信

③ と知る

ICE動作の⼀部


36

問題の発端：NYTimesがWebRTCでIP収集

STUNのパケット（⾒えにくいですが）


37

STUNのパケット（⾒えにくいですが）

個⼈特定につながる(同じNAT配下にいても)

問題の発端：NYTimesがWebRTCでIP収集

https://twitter.com/incloud/status/619624021123010560


38

TPACで議論された対処⽅法1. 全ての候補を収集する(ただし、getUserMediaの同意があるときのみ)

2. 制限付き収集その１[デフォル⼘動作](デフォルトNICにBINDされるホスト候補のみ+ プライベートアドレス(RFC1918)の候補？)

3. 制限付き収集その２(ホスト候補無し。設定や拡張)

4. プロキシのみ(設定や拡張)


39


2. 制限付き収集その１[デフォル⼘動作](デフォルトNICにBINDされるホスト候補のみプライベートアドレス(RFC1918)の候補？)




40


2. 制限付き収集その１[デフォル⼘動作](デフォルトNICにBINDされるホスト候補のみプライベートアドレス(RFC1918)の候補？)



カメラ、マイクについての同意だが、IPアドレス収集にも使われる点に注意


41



3. 制限付き収集その２(ホスト候補無し。設定や拡張が必要)



42



3. 制限付き収集その２(ホスト候補無し。設定や拡張が必要)


プライベートIPを収集するかどうかは、既存のWebRTCアプリがどの程度壊れるかに依存する。

なので、実験して決めることになった。


まとめ


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 最新レポート

Technology

Transcript of TPAC 2015 WebRTC WG 最新レポート