Slide 1

Slide 1 text

2016/8月時点
 WebRTCの標準化動向からいくつか
 2016/8/8(Mon) @ WebRTC Meetup Tokyo #11
 @iwashi86

Slide 2

Slide 2 text

■名前
 @iwashi86 ■仕事
 SkyWayの開発・運用


Slide 3

Slide 3 text

WebRTCの標準化団体


Slide 4

Slide 4 text

役割の違い
 ネットワークを流れる プロトコル側を規定 ブラウザのAPI側を規定

Slide 5

Slide 5 text

Changes since May 13, 2016 Changes since February 15, 2016 Changes since November 23, 2015 進化スピードが速い


Slide 6

Slide 6 text

正しい技術記事 無くなる問題! 英語も古い記事が多いので注意

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

圧倒的感謝


Slide 9

Slide 9 text

【本LTの内容】 現在の最新実装ではなく、 将来どうなっていくか、という仕様を紹介 (個人的に開発者へ影響がありそうな仕様をピックアップ) 【本LTのゴール】 WebRTCの未来を知っていること

Slide 10

Slide 10 text

先に注意
 W3C仕様は、ブラウザに実装されてないものが多いので、 `undefined` が出ても泣かないこと!

Slide 11

Slide 11 text

本題

Slide 12

Slide 12 text

まずW3C側から


Slide 13

Slide 13 text

RTCRtpTranceiver
 ・MediaStreamTrackの送受信をコントロール RTCRtpSender RTCRtpReceiver ・Chrome/Firefox共に未実装 = RTCPeerConnection.getTransceivers() は undefined ・Firefoxは、 getSenders() / getReceivers() が存在

Slide 14

Slide 14 text

RTCRtpTranceiver.setDirection
 ・setDirection(“方向属性”)  で、メディアの送受信方向・非活性を設定可能 ・方向属性に設定できるもの  ・sendrecv  ・sendonly  ・recvonly  ・inactive ・今同じことする場合 ⇒

Slide 15

Slide 15 text

RTCRtpTranceiver.setCodecPreference
 ・setCodecPreference(“codec名”)  で、コーデックの優先順序を設定可能 ・今同じことをする場合は、  createOffer/Answerで作成したSDPを修正

Slide 16

Slide 16 text

RTCRtpTranceiver.setCodecPreference
 ・setCodecPreference(“codec名”)  で、コーデックの優先順序を設定可能 ・今同じことをする場合は、  createOffer/Answerで作成したSDPを修正 ・Tips:VP8やめたいとき  ・正しいのは関連するVP8の記述を削除  ・ハックなのは、VP8をhogeなどに置換。 結果として、ネゴシエーションで合意取れず、 他のコーデックが選択される

Slide 17

Slide 17 text

RTCRtpSender.setParameter
 ・setParameter(RTCRtpParameters)  で、コーデックのオプションやRTCPの扱いを設定 ・できることの例  ・maxBitrateを設定  ・解像度を優先するか、フレームレートを優先するか選択   ・maintain-framerate   ・maintain-resolution   ・balanced  ・ちなみに、RIDというsimulcast向けのヘッダ設定もこれ  

Slide 18

Slide 18 text

IETFの話


Slide 19

Slide 19 text

IETF96 (2016/7実施) は省略
 ・IETF96の議論内容はニッチすぎて、  本Meetupでは有用なものが少ないと判断 ・ニッチな例 (rtcweb WGより)  ・max-bundleが指定されたにも関わらず   エンドポイントがbundleしてないメディアを   送ってきたらどう振る舞うべきか?   ⇒結論:最初のm-lineを採用して残りはreject

Slide 20

Slide 20 text

代わりに面白そうな仕様を2つ
 1. Mobility with TURN (TRAM WGより) (draft-ietf-tram-turn-mobility-03) 2. ICE Network Cost (ICE WGへの個人ドラフト) (draft-thatcher-ice-network-cost-00)

Slide 21

Slide 21 text

代わりに面白そうな仕様を2つ
 1. Mobility with TURN (draft-ietf-tram-turn-mobility-03) 2. ICE Network Cost (draft-thatcher-ice-network-cost-00)

Slide 22

Slide 22 text

Mobility with TURN で解決したいこと
 • モバイルで移動中にIPが変わることがある • 例: 会社から外出 Wifi(TURN) -> LTE • このときの現在のWebRTCの動作    ⇒ 一度、切断して再接続 • しかも変更後もTURN経由になった場合※は • Allocation Request • Create Permission • SDP再度交換 (ICE候補の交換) • ICEでホールパンチング   というめんどくさい手順を踏まないといけない ※ 日本は代表キャリアがP2Pを通すので比較的レア

Slide 23

Slide 23 text

Mobility with TURN の解決方法


Slide 24

Slide 24 text

Mobility with TURN の解決方法
 この部分は IPを変更しない (PeerAから見える IPは同じ。TURNが 変更を吸収する。)

Slide 25

Slide 25 text

代わりに面白そうな仕様を2つ
 1. Mobility with TURN (draft-ietf-tram-turn-mobility-03) 2. ICE Network Cost (draft-thatcher-ice-network-cost-00)

Slide 26

Slide 26 text

ICE Network Cost で解決したいこと
 • ICEで候補を集めた結果、以下の経路候補ができた 1. Wifi <-> Wifi 2. Wifi <-> LTE 3. LTE <-> Wifi 4. LTE <-> LTE • このとき、どれを選べばいいのか?

Slide 27

Slide 27 text

ICE Network Cost で解決したいこと
 • ICEで候補を集めた結果、以下の経路候補ができた 1. Wifi <-> Wifi 2. Wifi <-> LTE 3. LTE <-> Wifi 4. LTE <-> LTE • このとき、どれを選べばいいのか? • 日本での通信事情・金銭面を考えると もちろん[1]の Wifi <-> Wifi が望ましい • しかし、仮に重要通信で金銭面を考慮しなくて良い &Wifiが混雑していてLTEのが通信品質が良いなら?

Slide 28

Slide 28 text

ICE Network Cost で解決方法
 • ICEの候補情報にネットワークコストを付与 つまり:   a=candidate …(略)... network-id=1 network-cost=50 • 経路は、ネットワークコストを加味して選定 • ICE Priorityも考慮要素 • ネットワークコストの算出ロジックは実装依存

Slide 29

Slide 29 text

まとめ
 • W3C: • RTCRtpTranceiver/Sender の中から setDirection()、setCodecPreference() を紹介 • IETF: • Mobility with TURN • ICE Network Cost

Slide 30

Slide 30 text

(時間あれば)参考として
 • IETFは、誰でも参加できます • IETF97は11月でソウル • オンラインで良いなら無料 • IETF96の議論模様は Youtube で公開 https://www.youtube.com/channel/UC8dtK9njBLdFnBahHFp0eZQ • 標準化というと堅苦しそうですが、 どのようにしてRFCが制定されていくのか、 一度、様子を覗いてみてはいかがでしょうか? • なおW3Cは、会員(有償)じゃないと参加困難…