2015年第4四半期の WebRTC 標準化アップデート / 2015 update of WebRTC Standards

2015年12月 WebRTC
標準化アップデート
つまり
この一年の標準化はハンパじゃない！
Dr. Alex Gouaillard
(訳者: Yoshimasa Iwase / @iwashi86)
© Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0

View Slide

全体像
•  2015年初頭のWebRTC
•  オブジェクトモデルAPIs
•  のり (Transceiver)
•  ICEと最適化
•  サイマルキャスト
•  その他、WebRTC 1.0に入るトピック

View Slide

2015年初頭のP2PのWebRTCモデル
hJp://www.html5rocks.com/en/tutorials/webrtc/basics/
シグナリングシグナリング
メディア
発信側着信側

View Slide

シグナリング
サーバ
PeerConnecNon
JavaScriptアプリ (送信側) JavaScriptアプリ (受信側)
PeerConnecNon
メディア
ストリーム
データ
チャネル
CreateOﬀer
SetLocal
SetRemote
SetLocal
SetRemote
オファー (SDP) アンサー (SDP)
Candidates
(SDP)
メディア
ストリーム
データ
チャネル
OnCandidate
AddCandidate
CreateAnswer
ICE
バインディング
＋接続テスト

View Slide

シグナリング
サーバ
PeerConnecNon
JavaScriptアプリ (送信側) JavaScriptアプリ (受信側)
PeerConnecNon
ICE UA
DTLS
RTP
Codec
CreateOﬀer
収集
トランスポート
SetLocal
SetRemote
ICE UA DTLS
RTP
Codec
収集
トランスポート
SetLocal
SetRemote
Candidates
(SDP)
OnCandidate
AddCandidate
CreateAnswer
ICE
バインディング
＋接続テスト
万能なPeerConnecNon
オファー (SDP) アンサー (SDP)
メディア
ストリーム
データ
チャネル
メディア
ストリーム
データ
チャネル

View Slide

hJp://www.w3.org/TR/webrtc/
PeerConnecNonの中身

View Slide

使われることは
無かった

View Slide

1つの状態、
4つの異なる
ケース…

View Slide

相互排他的
な経路

View Slide

stable
have-local-offer
stable
オファー
アンサー
Create PC
Create offer
SetLocal(offer) Create PC
SetRemote(offer)
Create answer
SetLocal(answer)
stable
Have-remote-
offer
stable
SetRemote(answer)
addRemoteStream
別の観点
発信者着信者
インターネット
© Dr. Alex Gouaillard @ Temasys Comm., 2014. Document provided under CC BY-NC 4.0

View Slide

JSから状態が見える
ICE

View Slide

常に到達するわけではない(実装されてない)
ICE

View Slide

1つの状態が複数の失敗を含む：
-  ICEの失敗
-  DTLSの失敗、 …
-  複数トラックの場合、1つのトラックが失敗すると、
状態は”failed”になる。どのトラックが失敗した
か確認する方法は無い
ICE

View Slide

DONE FROZEN IN CALL コネクション　　　ハンドシェイク(SDP O/A) .
new
checking
connected
disconnected
failed
Completed
close
new
gathering
complete
発信者シグナリングサーバ　　　　着信者
stable
have-local-offer
stable
Close
OFFER
ANSWER
Create PC
Add local stream(s)
Create offer

SetLocal(offer)
Sending offer Create PC
SetRemote(offer)
addRemoteStream(s)
Add local stream(s)
Create answer

SetLocal(answer)
Send answer
stable
Have-remote-
offer
stable
new
gathering
complete
onIceCandidate
フィルタリング>
Send candidate
addIceCandidate
onIceCandidate
< candidatesの
Send candidate
のフィルタリング>
addIceCandidate
new
checking
connected
disconnected
failed
Completed
close Close
© Temasys CommunicaNons, pvt, ltd, 2014
Document provided under CC BY-NC 4.0
CANDIDATES
Peer
ConnecNon
ICE
ConnecNon
ICE
Gathering
SetRemote(answer)
addRemoteStream
BYE

View Slide

1.  どうやって帯域設定すればいいのか
2.  (マン・イン・ザ・ミドルアタックを防ぐために)
どうやってフィンガープリントを確認するのか
3.  コーデックとそのパラメータをどうやって扱えばいいのか
=> うーん、…SDPを修正して上手くいくことを祈ろう
4.  どのCandidateペアが使われているのか
5.  ICE収集をどうやって制限すればいいのか(自分のIPを晒したくない
から)
6.  どうやってICEの失敗についての詳細な情報を得るのか
7.  ICEハンドシェイクをどうやったら早くできるのか？
8.  JSEP、SDP、オファー/アンサーをどうやったら除去できる？
9.  ネゴシエーションを再度実施せずに、フロント/自身のビューをス
イッチできる？
=> 無理
未解決の問題

View Slide

全体像
•  Glue (Transceiver)

View Slide

2015年第二四半期,
W3C WebRTCの新しいチャーター(憲章)
•  => ORTC と WebRTCの統合
•  オブジェクトモデルAPIの概念(ORTCにインスパイア)
hJp://ortc.org/wp-content/uploads/2014/08/ortc.html

View Slide

オブジェクトモデルって何？
•  各オブジェクトは1つの仕事だけ
•  各オブジェクトは能力を調べられる(JS)
•  パラメタはJSから動的に読み書きできる
#8 (Edge)
hJp://ortc.org/wp-content/uploads/2014/08/ortc.html
訳注：以降の#Xの番号は、
P.15の番号にリンクしています。

View Slide

オブジェクトモデル:例
RtpSender
---------------------------------------------------------
-  MediaStreamTrack track
-  DTLSTransport transport
-  DTLSTransport rtcpTransport
---------------------------------------------------------
Promise replaceTrack( track )
RtpCapabiliMes getCapabiliNes()
RtpParameters getParameters()
Void setParameters( RtpParameters )

View Slide

RtpSender
---------------------------------------------------------
---------------------------------------------------------
RtpCapabiliNes getCapabiliNes()
追加の再ネゴシエーション無しに
トラックを切り替えする
全てのICEの魔法と暗号化がここで起こる。
もしバンドルを利用するなら、transportと
rtcpTransportは同じオブジェクトになる。
#9
オブジェクトモデル:例

View Slide

RtpSender
---------------------------------------------------------
---------------------------------------------------------
RtpCapabiliMes [readonly]
---------------------------------------------------------
- Seq codecs
- Seq headerExtensions
RtpParameters
---------------------------------------------------------
- seq encodings
- seq headerExtensions
- RTCRtcpParameters rtcp
- Seq codecs
コーデックとストリーミングの
魔法が起こるところ！
JSのAPIを通じてコール中に
パラメータ変更できる
オブジェクトモデル: 例
能力とパラメータ

View Slide

RtpSender オブジェクト:
Rtpパラメータの詳細
RtpParameters
---------------------------------------------------------
- seq encodings
- seqheaderExtensions
- RTCRtcpParameters rtcp
- Seq codecs
RtpEncodingParameters
---------------------------------------------------------
- unsigned long ssrc
- RTCRtxParameters rtx
- RTCFecParameters fec
- boolean acNve
- RTCPriorityType priority
- unsigned long maxBitrate
- RTCDegradaMonPreference
degradaNonPreference
送信停止
(ミュートして帯域を節約する)
ストリームの優先度
帯域を制限
通信環境が悪化したときに、空間or
時間のどちら(両方でも)に影響を
与えるかの選択
#1
RtpCodecParameters
---------------------------------------------------------
- unsigned short payloadType
- DOMString mimeType
- unsigned long clockRate
- unsigned short channels = 1
- DOMString sdpFmtpLine
#3

View Slide

DtlsTransportオブジェクト
DtlsTransport
-----------------------------------------------------------
- readonly IceTransport transport
- readonly DtlsTransportState state
-----------------------------------------------------------
- EventHandler onstatechange
- seq getRemoteCerNﬁcates()
Iceオブジェクトは分離されて
いる
DTLS(暗号化)エラー向けに
新しいステートマシンがある
ConnecNng
MITM攻撃対策として
内容チェックのために
フィンガープリントへアク
セスできる #2
#6a

View Slide

IceTransportオブジェクト
IceTransport
------------------------------------------------------------------------
- readonly RTCIceRole role
- readonly RTCIceComponent component
- readonly RTCIceConnecMonState state
- readonly RTCIceGatheringState gatheringState
------------------------------------------------------------------------
- seq getLocalCandidates()
- seq getRemoteCandidates()
- RTCIceCandidatePair getSelectedCandidatePair()
- RTCIceParameters getLocalParameters ()
- RTCIceParameters getRemoteParameters()
- seq getRemoteCerNﬁcates()
------------------------------------------------------------------------
- EventHandler onstatechange
- EventHandler ongatheringstatechange
- EventHandler onselectedcandidatepairchange
同じステートマシンだが、今回はICEの
みを対象
#6b
Controlling
Controlled
Rtp
Rtcp
選択された候補ペア (動的)
#5
訳注：ICE(RFC5245)で
定義される用語です

View Slide

RtpReceiveオブジェクト
RtpReceiver
---------------------------------------------------------
---------------------------------------------------------
Seq
getContribuNngSources ()
Senderと同じ
それぞれのメディアソースSSRC
とオーディオレベルを提供
Provide SSRC and audio levels of
each contribuNng source, across
Nme.
RtpContribuMngSource
---------------------------------------------------------
- DOMHighResTimeStamp Nmestamp
- unsigned long source
- byte audioLevel

View Slide

Early 2015, peer-to-peer webRTC Model
Open QuesNons
最後のAPIを手に入れた
•  どうやって帯域設定すればいいのか
•  (マン・イン・ザ・ミドルアタックを防ぐために)
どうやってフィンガープリントを確認するのか
•  どのCandidateペアが使われているのか
•  どうやってICEの失敗についての詳細な情報を得るのか
•  JSEP、SDP、オファー/アンサーをどうやったら除去できる？
•  ネゴシエーションを再度実施せずに、フロント/自身のビューをス
イッチできる？
　いくつかAPIがある、もっと良いやり方もある
•  コーデックとそのパラメータをどうやって扱えばいいのか
•  ICE収集をどうやって制限すればいいのか(自分のIPを晒したくない)
　まだ解決されてない
•  ICEハンドシェイクをどうやったら早くできるのか？

View Slide

全体像

View Slide

オブジェクトモデルを備えたWebRTC 1.0
と JSEP を足すと…
問題:
1.  SDPのm行は本質的に双方向
2.  SDPのm行はsender/receiverオブジェクトモデル
(mid)に合致する属性が無い。あったとしても、
重複してしまう。
オブジェクトモデルの上に、どのようにしてm行相当
のものを追加すればいいのか？ (将来的にSDPや
JSEPを捨てる場合にどうすればいいのか) ?

View Slide

RtpTransceiver オブジェクト
RtpSenderとRtpReceiverを表していて、共通のmidを持つ
RtpTransceiver
---------------------------------------------------------
- DOMString mid
- RtpSender sender
- RtpReceiver receiver
- boolean stopped
---------------------------------------------------------
- void stop()
- void setCodecPreferences
(seq codecs)
トランシーバレベルでコーデック
を設定するときに便利なメソッド。
API呼び出しの順番に応じて、
SDPのオファーアンサー前後で
コーデックをエレガントに選択
する
#3
RtpTransceiverInit
---------------------------------------------------------
- Boolean send = true
- Boolean receive = true
- seq streams
oﬀerToReceiveの代わり
このトラックを参照しているスト
リームのトラック
ALEXからの注 :
PeerConnecGon.AddTransceiver( RtpTransceiverInit )

View Slide

お絵描き？(訳注：スライド無し)
ロールバックが、いかに苦痛か説明する
オブジェクトモデルを備えたWebRTC 1.0
と JSEP を足すと…

View Slide

全体像

View Slide

ICE isは激アツ!
燃えるぐらいアツい
-  NAT/ファイアウォール向けの
最高の技術
-  完全自動！
-  策定中の仕様が多くある
=> IETFで新しいWGできた
だけど
-  大規模スケールするソリューション
に対する一番の原因 (ciscoの主張、unify…)
-  モバイルでの電話よりまだ遅い
-  モバイルのハンドオーバーに問題がある

View Slide

What’s your flavor?
Full, Trickle, Lite
Feature \ flavor Full Trickle Lite
Make connecNvity checks Yes Yes NO
Answer connecNvity checks Yes Yes Yes
Controlling or controled Both Both Controlled
Candidates send in the Offer/Answer Yes No ?
Flag Ice-opNon:
trickle
a=ice-lite
hJps://tools.ies.org/html/drat-ies-mmusic-trickle-ice-02
hJps://webrtchacks.com/trickle-ice/
Trickle:10秒から1秒へ
Q:どうやって100ミリ秒へ？

View Slide

より早いICE
-  コールする前に処理を開始！
-  ICEプール
-  プレ候補収集
-  ペアリングと接続確認を単純化・高速化

View Slide

ウォームアップ / アーリーメディア
全部非同期にする、待たない
-  ICE, DTLS, メディア中継をシグナリングの前に準
備する (ウォームアップ)
-  Transceiver + トラックの交換
-  SDPアンサー送ると同時にメディア送信開始
(アーリーメディア)
-  Transceiverの凄さ
-  [汎用的な図を描いてそれぞれのケースを指摘]
(訳注：スライド無し)

View Slide

デフォルトICEサーバに対するAPI
-  ブラウザはデフォルトSTUN/TURNサーバを
アプリケーションに対して提示できる

View Slide

全体像

View Slide

復習
マルチキャスト vs サイマルキャスト vs SVC
A
B
C
マルチキャスト
•  複数トラック
•  別々にデコード可能
•  帯域管理も別々
HD
SD
QVGA
サイマルキャスト
•  同一のメディアソースから
•  可能であれば賢く帯域管理
1 SSRC
Δ2
Δ1
QVGA
SVCエンコーディング
•  別々にデコード不可 (ベースレイヤを除く)
•  賢い帯域管理は必須
•  少ない帯域、さらに柔軟に
1 SSRC
E
E
E
E
E
E
SVC Enc.
D
D
D
HD
SD
QVGA

View Slide

復習
マルチキャストシグナリングの状態
WebRTCの開始時より、別々のPeerConnecNonを使っ
て複数のメディアストリームを送信可能だったが、
多くのポートを消費し、トラック間の同期が無かった
（リップシンクのずれ、…）
A
B
C
E
E
E
マルチキャスト
•  帯域管理も別々

View Slide

PeerConnecNonのRTP/RTCP
ユースケース: 2つのメディアトラック(音声と映
像)、何個のポートが必要？少ない方が以下に
とっては良い：
-  モバイル網におけるより良い接続確率
-  TURN/メディアサーバのリソースの最適化
-  クライアントのポート制約

View Slide

デフォルト
4
A
V
RTP RTCP
hIp://tools.ieL.org/html/draN-ieL-mmusic-sdp-bundle-negoGaGon
hIp://datatracker.ieL.org/doc/rfc5761/
© Dr. Alex Gouaillard @ Cosmo ConsulGng., 2015. Document provided under CC BY-NC 4.0
PeerConnecNonのRTP/RTCP

View Slide

RTP/RTCP
デフォルト
4
バンドル
2
A
V
RTP RTCP
A
V
RTP RTCP
a=group:BUNDLE

View Slide

RTP/RTCP
デフォルト
4
バンドル
2
Rtcp多重
2
A
V
RTP RTCP
A
V
RTP RTCP
A
V
RTP RTCP
a=rtcp-mux
a=group:BUNDLE

View Slide

RTP/RTCP
デフォルト
4
バンドル
2
Rtcp多重
2
両方
1
A
V
RTP RTCP
A
V
RTP RTCP
A
V
RTP RTCP
A
V
RTP RTCP
a=rtcp-mux
a=group:BUNDLE

View Slide

RTP/RTCP
-  モバイル網におけるより良い接続確率(10%)
-  TURN/メディアサーバのリソースの最適化(4因子!)
-  クライアントのポート制約(人生ってこんなもの)
-  コンポーネント/ポート/オファーアンサー中のオプ
ション変更に注意
SDP例をもっと多く見たかったら:
hIp://tools.ieL.org/id/draN-nandakumar-rtcweb-sdp-01.html

View Slide

RTP/RTCP – Nトラックに対する推定
デフォルト
2n
バンドル
n
Rtcp-多重
n
両方
1
A
V
RTP RTCP
A
V
RTP RTCP
A
V
RTP RTCP
A
V
RTP RTCP
a=rtcp-mux
a=group:BUNDLE

View Slide

復習
１つのPeerConnecGonで複数のストリームを扱う！

View Slide

1.  歴史的な理由で, 2年もの間、chromeは標準で規
定されてないシグナリングを利用してきた(Plan B).
それがデファクトになった (jitsi, …)
2.  本当の仕様は “Uniﬁed Plan”。
Firefoxで実装されていて、
Chromeにはもうすぐやってくる
復習
１つのPeerConnecGonで複数のストリームを扱う！

View Slide

Plan B: メディア・タイプごとにグループ化
(現行のchrome, hangout, jitsi)
a=group:BUNDLE sdparta_0 sdparta_1
a=msid-semanNc:WMS *
m=audio 9 RTP/SAVPF 109 9 0 8
a=mid:sdparta_0
a=ssrc:323910839
msid:{d57d3917-64e9-4f49-ad•-b049d165c312} {920e9ﬀc-728e-0d40-a1b9-ebd0025c860a}
a=ssrc:323910839
cname:{72b9ﬀ9f-4d8a-5244-b19a-bd9b47251770}
m=video 9 RTP/SAVPF 120
a=mid:sdparta_1
a=ssrc:2917595157
msid:{d57d3917-64e9-4f49-ad•-b049d165c312} {35eeb34f-f89c-3946-8e5e-2d5abd38c5a5}
a=ssrc:2917595157
a=ssrc:2325911938
msid:{3a2bfe17-c65d-364a-af14-415d90bb9f52} {aa7a4ca4-189b-504a-9748-5c22bc7a6c4f}
a=ssrc:2325911938
hIps://tools.ieL.org/html/draN-uberG-rtcweb-plan-00

View Slide

Unified plan: 1 media => 1 m-行 => 1 mid
(現行のFirefox, 次のchrome,本当の標準)
a=group:BUNDLE sdparta_0 sdparta_1 sdparta_2
a=msid-semanNc:WMS *
m=audio 9 RTP/SAVPF 109 9 0 8
a=mid:sdparta_0
a=
msid:{d57d3917-64e9-4f49-ad•-b049d165c312} {920e9ffc-728e-0d40-a1b9-ebd0025c860a}
a=ssrc:323910839
a=mid:sdparta_1
a=
msid:{d57d3917-64e9-4f49-ad•-b049d165c312} {35eeb34f-f89c-3946-8e5e-2d5abd38c5a5}
a=ssrc:2917595157
a=mid:sdparta_2
a=
msid:{3a2bfe17-c65d-364a-af14-415d90bb9f52} {aa7a4ca4-189b-504a-9748-5c22bc7a6c4f}
a=ssrc:2325911938
hIps://tools.ieL.org/html/draN-roach-mmusic-unified-plan-00

View Slide

A
B
C
MulNcast
•  Several tracks
•  Decodable separately
•  Bandwidth management separated
HD
SD
QVGA
1 SSRC
Δ2
Δ1
QVGA
SVC Encoding
•  Several tracks
•  Coming from the same source
•  Not Decodable separately (Except base layer)
•  Smart bandwidth management mandatory
•  Less bandwidth, more resilience.
1 SSRC
E
E
E
E
E
E
SVC Enc.
D
D
D
HD
SD
QVGA
復習
マルチキャスト vs サイマルキャスト vs SVC
サイマルキャスト
•  可能であれば賢く帯域管理

View Slide

サイマルキャスト:
webRTC 1.0でのユースケース
-  webrtc 1.0のユースケース: SFU
-  ブラウザはマルチキャストで送る、
だけど受信はできない
(WebRTC 1.0 では)
デスク
トップ
HD
SFU
SD
QVGA
Chrome
Book
モバイル
デスク
トップ
HD
SD
QVGA

View Slide

サイマルキャスト (SVCは後で):
3 レイヤ, 3つのWG, 2つの標準団体
-  以下の様に分割する
-  “on-the-wire※”の情報(1),
-  JSのAPI (2),
-  シグナリング (3)
シグナリング
サーバ
Web
サーバ
Bob
(ブラウザ)
Alice
(ブラウザ)
Media
(3)
(2)
(1)
※：　(訳注)実際に流れてい
るメディア(RTPなど)だと考え
ると分かりやすいです

View Slide

サイマルキャスト: on the wireでの変更
-  On the wireに関するワーク (IETFのAVTEXT):
hIps://tools.ieL.org/html/draN-pthatcher-mmusic-rid-02
RTPヘッダ拡張に規定されるRID

View Slide

サイマルキャスト: JSのAPI
-  TranceiverInitを通じてTranceiverオブジェクトに加え
られたJSのAPI、ScaleResoluMonDownBy キーワード
を利用:
var sender = pc.addTransceiver(
{sendEncodings: [
{rid: “F”},
{rid: “H”, scaleResoluNonDownBy: 2},
{rid: “Q”, scaleResoluNonDownBy: 4}
]}
).sender;

View Slide

サイマルキャスト: SDPのオファー
•  シグナリング (MMUSICの仕様策定が上手く行けばの話だけど… )
hIps://tools.ieL.org/html/draN-pthatcher-mmusic-rid-02
•  hIps://tools.ieL.org/html/draN-ieL-mmusic-sdp-simulcast-03
// クライアント側のSDP記述
a=rid:F send
a=rid:H send
a=rid:Q send
a=simulcast rid:F,H,Q
// サーバ側のSDP記述
a=rid:F recv
a=rid:H recv
a=simulcast rid:F,H
HD
SD
QVGA
1 SSRC
E
E
E

View Slide

全体像

View Slide

スクリーンキャプチャAPIの簡易化
-  スクリーン、ウィンドウ、アプリ間での区別無し
=> これ以上の制約なし、フラットなリスト
•  Screen Capture
hgp://w3c.github.io/mediacapture-screen-share/

View Slide

ストリームを録画(ローカル)、だけど全てじゃない(リモート)
hJp://www.w3.org/TR/mediastream-recording/
メディアストリーム録画(クライアント側)

View Slide

またはをソースとして使う！
hJp://w3c.github.io/mediacapture-fromelement/
DOMエレメントのMedia Capture
および Image Capture (スナップショット)

View Slide

異なるストリームを異なるアウトプットへ
hJp://w3c.github.io/mediacapture-output/
オーディオ出力デバイス API

View Slide

hJp://www.w3.org/TR/webrtc-stats/
WebRTCの統計APIに対する識別子
データチャネル、コーデック、FECに対する完全な統計…

View Slide

譲渡できるデータチャネル
つまりワーカ内でデータチャネルを使う

View Slide

セキュリティ: IPアドレス漏洩
候補収集に関する４つのレベル
-  全部 [同意有り]
-  制限その1 (ホスト + 1918) [デフォルト]
-  制限その2 (ホスト無し) [設定/拡張]
-  プロキシ/VPNだけ [設定/拡張]

View Slide

結論
WebRTC 1.0はハンパじゃない
[邪悪な笑いを浮かべつつ]

View Slide

2015年第4四半期の WebRTC 標準化アップデート / 2015 update of WebRTC Standards

2015年第4四半期の WebRTC 標準化アップデート / 2015 update of WebRTC Standards

iwashi

More Decks by iwashi

Other Decks in Technology

Featured

Transcript

2015年 第4四半期の WebRTC 標準化 アップデート / 2015 update of WebRTC Standards

2015年 第4四半期の WebRTC 標準化 アップデート / 2015 update of WebRTC Standards

iwashi

More Decks by iwashi

Other Decks in Technology

Featured

Transcript

2015年第4四半期の WebRTC 標準化アップデート / 2015 update of WebRTC Standards

2015年第4四半期の WebRTC 標準化アップデート / 2015 update of WebRTC Standards