Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
2016.8時点WebRTCの標準化動向からいくつか / WebRTC Standards ...
Search
iwashi
November 27, 2022
Technology
0
190
2016.8時点 WebRTCの標準化動向からいくつか / WebRTC Standards trends at 2016.8
WebRTC Meetup Tokyo #11 での発表資料です。
動画は↓にあります
https://youtu.be/0RYWw1nPxio?t=1h27m51s
iwashi
November 27, 2022
Tweet
Share
More Decks by iwashi
See All by iwashi
n=1の経験が紡ぐエンジニアリングマネジメントの可能性 / The Possibilities of Engineering Management from n=1 Experiences
iwashi86
22
9.6k
エンジニアリングが好きな私たちのためのエンジニアリングマネジャー入門 / Engineering management for the rest of us
iwashi86
23
5.3k
エレガントパズル 30分 ダイジェスト版/ Elegant Puzzle 30min Digest
iwashi86
5
590
エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか / Elegant Puzzle
iwashi86
18
4.1k
ベロシティを高く保つ仕事のすすめ方 / Maintaining a High Velocity as Productivity Hacks
iwashi86
54
20k
マネージャー&リーダー向け 社内トレーニング / Training of management and leadership for Stockmark
iwashi86
65
32k
30分でわかる「エンジニアのためのドキュメントライティング」- インフラエンジニアBooks / Docs for Developers within 30 minutes
iwashi86
9
2.5k
エンジニアのためのドキュメントライティング / Docs for Developers
iwashi86
34
22k
なぜ変化を起こすのが難しいのか? - 数年以上にわたって難しさに向き合い・考え取り組んできたこと / The reason why changing organization is so hard - What I thought and faced for more than several years
iwashi86
60
88k
Other Decks in Technology
See All in Technology
グループポリシー再確認
murachiakira
0
150
年末調整プロダクトの内部品質改善活動について
kaomi_wombat
0
130
これからクラウドエンジニアになるために本当に必要なスキル 5選
hiyanger
1
450
fukuoka.ts #3 社内でESLintの共通設定を配りたい2025年春版
pirosikick
1
280
Keynote - KCD Brazil - Platform Engineering on K8s (portuguese)
salaboy
0
120
RAGの基礎から実践運用まで:AWS BedrockとLangfuseで実現する構築・監視・評価
sonoda_mj
0
400
17年のQA経験が導いたスクラムマスターへの道 / 17 Years in QA to Scrum Master
toma_sm
0
200
AI・LLM事業部のSREとタスクの自動運転
shinyorke
PRO
0
270
LINEギフトのLINEミニアプリアクセシビリティ改善事例
lycorptech_jp
PRO
0
130
AWS のポリシー言語 Cedar を活用した高速かつスケーラブルな認可技術の探求 #phperkaigi / PHPerKaigi 2025
ytaka23
7
1.4k
チームの性質によって変わる ADR との向き合い方と、生成 AI 時代のこれから / How to deal with ADR depends on the characteristics of the team
mh4gf
4
290
ソフトウェア開発現代史: なぜ日本のソフトウェア開発は「滝」なのか?製造業の成功体験とのギャップ #jassttokyo
takabow
2
1.1k
Featured
See All Featured
Music & Morning Musume
bryan
46
6.4k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Stop Working from a Prison Cell
hatefulcrawdad
268
20k
How GitHub (no longer) Works
holman
314
140k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
30
1.1k
RailsConf 2023
tenderlove
29
1k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
8
690
Agile that works and the tools we love
rasmusluckow
328
21k
Thoughts on Productivity
jonyablonski
69
4.5k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
2.9k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Transcript
2016/8月時点 WebRTCの標準化動向からいくつか 2016/8/8(Mon) @ WebRTC Meetup Tokyo #11 @iwashi86
▪名前 @iwashi86 ▪仕事 SkyWayの開発・運用
WebRTCの標準化団体
役割の違い ネットワークを流れる プロトコル側を規定 ブラウザのAPI側を規定
Changes since May 13, 2016 Changes since February 15, 2016
Changes since November 23, 2015 進化スピードが速い
正しい技術記事 無くなる問題! 英語も古い記事が多いので注意
None
圧倒的感謝
【本LTの内容】 現在の最新実装ではなく、 将来どうなっていくか、という仕様を紹介 (個人的に開発者へ影響がありそうな仕様をピックアップ) 【本LTのゴール】 WebRTCの未来を知っていること
先に注意 W3C仕様は、ブラウザに実装されてないものが多いので、 `undefined` が出ても泣かないこと!
本題
まずW3C側から
RTCRtpTranceiver ・MediaStreamTrackの送受信をコントロール RTCRtpSender RTCRtpReceiver ・Chrome/Firefox共に未実装 = RTCPeerConnection.getTransceivers() は undefined ・Firefoxは、
getSenders() / getReceivers() が存在
RTCRtpTranceiver.setDirection ・setDirection(“方向属性”) で、メディアの送受信方向・非活性を設定可能 ・方向属性に設定できるもの ・sendrecv ・sendonly ・recvonly ・inactive ・今同じことする場合 ⇒
RTCRtpTranceiver.setCodecPreference ・setCodecPreference(“codec名”) で、コーデックの優先順序を設定可能 ・今同じことをする場合は、 createOffer/Answerで作成したSDPを修正
RTCRtpTranceiver.setCodecPreference ・setCodecPreference(“codec名”) で、コーデックの優先順序を設定可能 ・今同じことをする場合は、 createOffer/Answerで作成したSDPを修正 ・Tips:VP8やめたいとき ・正しいのは関連するVP8の記述を削除 ・ハックなのは、VP8をhogeなどに置換。 結果として、ネゴシエーションで合意取れず、 他のコーデックが選択される
RTCRtpSender.setParameter ・setParameter(RTCRtpParameters) で、コーデックのオプションやRTCPの扱いを設定 ・できることの例 ・maxBitrateを設定 ・解像度を優先するか、フレームレートを優先するか選択 ・maintain-framerate ・maintain-resolution ・balanced ・ちなみに、RIDというsimulcast向けのヘッダ設定もこれ
IETFの話
IETF96 (2016/7実施) は省略 ・IETF96の議論内容はニッチすぎて、 本Meetupでは有用なものが少ないと判断 ・ニッチな例 (rtcweb WGより) ・max-bundleが指定されたにも関わらず エンドポイントがbundleしてないメディアを
送ってきたらどう振る舞うべきか? ⇒結論:最初のm-lineを採用して残りはreject
代わりに面白そうな仕様を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)
代わりに面白そうな仕様を2つ 1. Mobility with TURN (draft-ietf-tram-turn-mobility-03) 2. ICE Network Cost
(draft-thatcher-ice-network-cost-00)
Mobility with TURN で解決したいこと • モバイルで移動中にIPが変わることがある • 例: 会社から外出 Wifi(TURN)
-> LTE • このときの現在のWebRTCの動作 ⇒ 一度、切断して再接続 • しかも変更後もTURN経由になった場合※は • Allocation Request • Create Permission • SDP再度交換 (ICE候補の交換) • ICEでホールパンチング というめんどくさい手順を踏まないといけない ※ 日本は代表キャリアがP2Pを通すので比較的レア
Mobility with TURN の解決方法
Mobility with TURN の解決方法 この部分は IPを変更しない (PeerAから見える IPは同じ。TURNが 変更を吸収する。)
代わりに面白そうな仕様を2つ 1. Mobility with TURN (draft-ietf-tram-turn-mobility-03) 2. ICE Network Cost
(draft-thatcher-ice-network-cost-00)
ICE Network Cost で解決したいこと • ICEで候補を集めた結果、以下の経路候補ができた 1. Wifi <-> Wifi
2. Wifi <-> LTE 3. LTE <-> Wifi 4. LTE <-> LTE • このとき、どれを選べばいいのか?
ICE Network Cost で解決したいこと • ICEで候補を集めた結果、以下の経路候補ができた 1. Wifi <-> Wifi
2. Wifi <-> LTE 3. LTE <-> Wifi 4. LTE <-> LTE • このとき、どれを選べばいいのか? • 日本での通信事情・金銭面を考えると もちろん[1]の Wifi <-> Wifi が望ましい • しかし、仮に重要通信で金銭面を考慮しなくて良い &Wifiが混雑していてLTEのが通信品質が良いなら?
ICE Network Cost で解決方法 • ICEの候補情報にネットワークコストを付与 つまり: a=candidate …(略)...
network-id=1 network-cost=50 • 経路は、ネットワークコストを加味して選定 • ICE Priorityも考慮要素 • ネットワークコストの算出ロジックは実装依存
まとめ • W3C: • RTCRtpTranceiver/Sender の中から setDirection()、setCodecPreference() を紹介 • IETF:
• Mobility with TURN • ICE Network Cost
(時間あれば)参考として • IETFは、誰でも参加できます • IETF97は11月でソウル • オンラインで良いなら無料 • IETF96の議論模様は Youtube
で公開 https://www.youtube.com/channel/UC8dtK9njBLdFnBahHFp0eZQ • 標準化というと堅苦しそうですが、 どのようにしてRFCが制定されていくのか、 一度、様子を覗いてみてはいかがでしょうか? • なおW3Cは、会員(有償)じゃないと参加困難…