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

全体像 © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 •  2015年初頭のWebRTC •  オブジェクトモデルAPIs •  のり (Transceiver) •  ICEと最適化 •  サイマルキャスト •  その他、WebRTC 1.0に入るトピック

2015年初頭のP2PのWebRTCモデル © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 hJp://www.html5rocks.com/en/tutorials/webrtc/basics/ シグナリング シグナリング メディア 発信側 着信側

シグナリング サーバ PeerConnecNon JavaScriptアプリ (送信側) JavaScriptアプリ (受信側) PeerConnecNon メディア ストリーム データ チャネル CreateOffer SetLocal SetRemote SetLocal SetRemote オファー (SDP) アンサー (SDP) Candidates (SDP) メディア ストリーム データ チャネル OnCandidate AddCandidate CreateAnswer ICE バインディング ＋接続テスト © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 2015年初頭のP2PのWebRTCモデル

シグナリング サーバ PeerConnecNon JavaScriptアプリ (送信側) JavaScriptアプリ (受信側) PeerConnecNon ICE UA DTLS RTP Codec CreateOffer 収集 トランスポート SetLocal SetRemote ICE UA DTLS RTP Codec 収集 トランスポート SetLocal SetRemote Candidates (SDP) OnCandidate AddCandidate CreateAnswer ICE バインディング ＋接続テスト © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 2015年初頭のP2PのWebRTCモデル 万能なPeerConnecNon オファー (SDP) アンサー (SDP) メディア ストリーム データ チャネル メディア ストリーム データ チャネル

© Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 hJp://www.w3.org/TR/webrtc/ 2015年初頭のP2PのWebRTCモデル PeerConnecNonの中身

使われることは 無かった © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 hJp://www.w3.org/TR/webrtc/ 2015年初頭のP2PのWebRTCモデル PeerConnecNonの中身

1つの状態、 4つの異なる ケース… © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 hJp://www.w3.org/TR/webrtc/ 2015年初頭のP2PのWebRTCモデル PeerConnecNonの中身

相互排他的 な経路 © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 hJp://www.w3.org/TR/webrtc/ 2015年初頭のP2PのWebRTCモデル PeerConnecNonの中身

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 2015年初頭のP2PのWebRTCモデル PeerConnecNonの中身 別の観点 発信者 着信者 インターネット © Dr. Alex Gouaillard @ Temasys Comm., 2014. Document provided under CC BY-NC 4.0 © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0

JSから状態が見える © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 hJp://www.w3.org/TR/webrtc/ 2015年初頭のP2PのWebRTCモデル PeerConnecNonの中身 ICE

常に到達するわけではない(実装されてない) © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 hJp://www.w3.org/TR/webrtc/ 2015年初頭のP2PのWebRTCモデル PeerConnecNonの中身 ICE

1つの状態が複数の失敗を含む： -  ICEの失敗 -  DTLSの失敗、 … -  複数トラックの場合、1つのトラックが失敗すると、 状態は”failed”になる。どのトラックが失敗した か確認する方法は無い hJp://www.w3.org/TR/webrtc/ 2015年初頭のP2PのWebRTCモデル PeerConnecNonの中身 ICE

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

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

全体像 © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 •  2015年初頭のWebRTC •  オブジェクトモデルAPIs •  Glue (Transceiver) •  ICEと最適化 •  サイマルキャスト •  その他、WebRTC 1.0に入るトピック

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

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

オブジェクトモデル:例 RtpSender --------------------------------------------------------- -  MediaStreamTrack track -  DTLSTransport transport -  DTLSTransport rtcpTransport --------------------------------------------------------- Promise replaceTrack( track ) RtpCapabiliMes getCapabiliNes() RtpParameters getParameters() Void setParameters( RtpParameters ) © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0

RtpSender --------------------------------------------------------- -  MediaStreamTrack track -  DTLSTransport transport -  DTLSTransport rtcpTransport --------------------------------------------------------- Promise replaceTrack( track ) RtpCapabiliNes getCapabiliNes() RtpParameters getParameters() Void setParameters( RtpParameters ) 追加の再ネゴシエーション無しに トラックを切り替えする 全てのICEの魔法と暗号化がここで起こる。 もしバンドルを利用するなら、transportと rtcpTransportは同じオブジェクトになる。 © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 #9 オブジェクトモデル:例

RtpSender --------------------------------------------------------- -  MediaStreamTrack track -  DTLSTransport transport -  DTLSTransport rtcpTransport --------------------------------------------------------- Promise replaceTrack( track ) RtpCapabiliMes getCapabiliNes() RtpParameters getParameters() Void setParameters( RtpParameters ) RtpCapabiliMes [readonly] --------------------------------------------------------- - Seq codecs - Seq headerExtensions RtpParameters --------------------------------------------------------- - seq encodings - seq headerExtensions - RTCRtcpParameters rtcp - Seq codecs コーデックとストリーミングの 魔法が起こるところ！ JSのAPIを通じてコール中に パラメータ変更できる © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 オブジェクトモデル: 例 能力とパラメータ

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 © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 送信停止 (ミュートして帯域を節約する) ストリームの優先度 帯域を制限 通信環境が悪化したときに、空間or 時間のどちら(両方でも)に影響を 与えるかの選択 #1 RtpCodecParameters --------------------------------------------------------- - unsigned short payloadType - DOMString mimeType - unsigned long clockRate - unsigned short channels = 1 - DOMString sdpFmtpLine #3

DtlsTransportオブジェクト DtlsTransport ----------------------------------------------------------- - readonly IceTransport transport - readonly DtlsTransportState state ----------------------------------------------------------- - EventHandler onstatechange - seq getRemoteCerNficates() © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 Iceオブジェクトは分離されて いる DTLS(暗号化)エラー向けに 新しいステートマシンがある ConnecNng MITM攻撃対策として 内容チェックのために フィンガープリントへアク セスできる #2 #6a

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 getRemoteCerNficates() ------------------------------------------------------------------------ - EventHandler onstatechange - EventHandler ongatheringstatechange - EventHandler onselectedcandidatepairchange © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 同じステートマシンだが、今回はICEの みを対象 #6b Controlling Controlled Rtp Rtcp 選択された候補ペア (動的) #5 訳注：ICE(RFC5245)で 定義される用語です

RtpReceiveオブジェクト RtpReceiver --------------------------------------------------------- -  MediaStreamTrack track -  DTLSTransport transport -  DTLSTransport rtcpTransport --------------------------------------------------------- RtpCapabiliMes getCapabiliNes() Seq getContribuNngSources () © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 Senderと同じ それぞれのメディアソースSSRC とオーディオレベルを提供 Provide SSRC and audio levels of each contribuNng source, across Nme. RtpContribuMngSource --------------------------------------------------------- - DOMHighResTimeStamp Nmestamp - unsigned long source - byte audioLevel

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

全体像 © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 •  2015年初頭のWebRTC •  オブジェクトモデルAPIs •  のり (Transceiver) •  ICEと最適化 •  サイマルキャスト •  その他、WebRTC 1.0に入るトピック

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

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

お絵描き？(訳注：スライド無し) ロールバックが、いかに苦痛か説明する © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 オブジェクトモデルを備えたWebRTC 1.0 と JSEP を足すと…

全体像 © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 •  2015年初頭のWebRTC •  オブジェクトモデルAPIs •  のり (Transceiver) •  ICEと最適化 •  サイマルキャスト •  その他、WebRTC 1.0に入るトピック

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

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/ © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 Trickle:10秒から1秒へ Q:どうやって100ミリ秒へ？

より早いICE -  コールする前に処理を開始！ -  ICEプール -  プレ候補収集 -  ペアリングと接続確認を単純化・高速化 © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0

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

デフォルトICEサーバに対するAPI -  ブラウザはデフォルトSTUN/TURNサーバを アプリケーションに対して提示できる © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0

全体像 © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 •  2015年初頭のWebRTC •  オブジェクトモデルAPIs •  のり (Transceiver) •  ICEと最適化 •  サイマルキャスト •  その他、WebRTC 1.0に入るトピック

復習 マルチキャスト vs サイマルキャスト vs SVC © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 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

復習 マルチキャストシグナリングの状態 © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 WebRTCの開始時より、別々のPeerConnecNonを使っ て複数のメディアストリームを送信可能だったが、 多くのポートを消費し、トラック間の同期が無かった （リップシンクのずれ、…） A B C E E E マルチキャスト •  複数トラック •  別々にデコード可能 •  帯域管理も別々

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

デフォルト 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

RTP/RTCP デフォルト 4 バンドル 2 A V RTP RTCP A V RTP RTCP a=group:BUNDLE 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

RTP/RTCP デフォルト 4 バンドル 2 Rtcp多重 2 A V RTP RTCP A V RTP RTCP A V RTP RTCP a=rtcp-mux a=group:BUNDLE 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

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 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

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

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 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

復習 マルチキャストシグナリングの状態 １つのPeerConnecGonで複数のストリームを扱う！ © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0

© Dr. Alex Gouaillard @ Cosmo ConsulGng., 2015. Document provided under CC BY-NC 4.0 © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 1.  歴史的な理由で, 2年もの間、chromeは標準で規 定されてないシグナリングを利用してきた(Plan B). それがデファクトになった (jitsi, …) 2.  本当の仕様は “Unified Plan”。 Firefoxで実装されていて、 Chromeにはもうすぐやってくる 復習 マルチキャストシグナリングの状態 １つのPeerConnecGonで複数のストリームを扱う！

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} {920e9ffc-728e-0d40-a1b9-ebd0025c860a} a=ssrc:323910839 cname:{72b9ff9f-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 cname:{72b9ff9f-4d8a-5244-b19a-bd9b47251770} a=ssrc:2325911938 msid:{3a2bfe17-c65d-364a-af14-415d90bb9f52} {aa7a4ca4-189b-504a-9748-5c22bc7a6c4f} a=ssrc:2325911938 cname:{72b9ff9f-4d8a-5244-b19a-bd9b47251770} hIps://tools.ieL.org/html/draN-uberG-rtcweb-plan-00 © Dr. Alex Gouaillard @ Cosmo ConsulGng., 2015. Document provided under CC BY-NC 4.0 © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0

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 cname:{72b9ff9f-4d8a-5244-b19a-bd9b47251770} m=video 9 RTP/SAVPF 120 a=mid:sdparta_1 a= msid:{d57d3917-64e9-4f49-ad•-b049d165c312} {35eeb34f-f89c-3946-8e5e-2d5abd38c5a5} a=ssrc:2917595157 cname:{72b9ff9f-4d8a-5244-b19a-bd9b47251770} m=video 9 RTP/SAVPF 120 a=mid:sdparta_2 a= msid:{3a2bfe17-c65d-364a-af14-415d90bb9f52} {aa7a4ca4-189b-504a-9748-5c22bc7a6c4f} a=ssrc:2325911938 cname:{72b9ff9f-4d8a-5244-b19a-bd9b47251770} hIps://tools.ieL.org/html/draN-roach-mmusic-unified-plan-00 © Dr. Alex Gouaillard @ Cosmo ConsulGng., 2015. Document provided under CC BY-NC 4.0 © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0

© Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 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 サイマルキャスト •  複数トラック •  同一のメディアソースから •  別々にデコード可能 •  可能であれば賢く帯域管理

サイマルキャスト: webRTC 1.0でのユースケース -  webrtc 1.0のユースケース: SFU -  ブラウザはマルチキャストで送る、 だけど受信はできない (WebRTC 1.0 では) デスク トップ HD SFU SD QVGA Chrome Book モバイル デスク トップ HD SD QVGA © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0

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

サイマルキャスト: on the wireでの変更 -  On the wireに関するワーク (IETFのAVTEXT): hIps://tools.ieL.org/html/draN-pthatcher-mmusic-rid-02 RTPヘッダ拡張に規定されるRID © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0

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

サイマルキャスト: 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 © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 HD SD QVGA 1 SSRC E E E

全体像 © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0 •  2015年初頭のWebRTC •  オブジェクトモデルAPIs •  のり (Transceiver) •  ICEと最適化 •  サイマルキャスト •  その他、WebRTC 1.0に入るトピック

スクリーンキャプチャAPIの簡易化 -  スクリーン、ウィンドウ、アプリ間での区別無し => これ以上の制約なし、フラットなリスト •  Screen Capture hgp://w3c.github.io/mediacapture-screen-share/ © Dr. Alex Gouaillard @ Cosmo ConsulGng., 2015. Document provided under CC BY-NC 4.0

ストリームを録画(ローカル)、だけど全てじゃない(リモート) hJp://www.w3.org/TR/mediastream-recording/ メディアストリーム録画(クライアント側) © Dr. Alex Gouaillard @ Cosmo ConsulGng., 2015. Document provided under CC BY-NC 4.0

または をソースとして使う！ hJp://w3c.github.io/mediacapture-fromelement/ DOMエレメントのMedia Capture および Image Capture (スナップショット) © Dr. Alex Gouaillard @ Cosmo ConsulGng., 2015. Document provided under CC BY-NC 4.0

異なるストリームを異なるアウトプットへ hJp://w3c.github.io/mediacapture-output/ オーディオ出力デバイス API © Dr. Alex Gouaillard @ Cosmo ConsulGng., 2015. Document provided under CC BY-NC 4.0

hJp://www.w3.org/TR/webrtc-stats/ WebRTCの統計APIに対する識別子 データチャネル、コーデック、FECに対する完全な統計… © Dr. Alex Gouaillard @ Cosmo ConsulGng., 2015. Document provided under CC BY-NC 4.0

譲渡できるデータチャネル つまりワーカ内でデータチャネルを使う © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0

セキュリティ: IPアドレス漏洩 候補収集に関する４つのレベル -  全部 [同意有り] -  制限その1 (ホスト + 1918) [デフォルト] -  制限その2 (ホスト無し) [設定/拡張] -  プロキシ/VPNだけ [設定/拡張] © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0

結論 WebRTC 1.0はハンパじゃない [邪悪な笑いを浮かべつつ] © Dr. Alex Gouaillard @ Citrix Systems, 2015. Document provided under CC BY-NC 4.0