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
P2P ではじめる WebRTC のつまづきどころ
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
tnoho
July 24, 2025
Technology
470
1
Share
P2P ではじめる WebRTC のつまづきどころ
久々に WebRTC で普通に P2P をしてみようと思ったらつまづいてしまった共有です。
VibeCoding で WebRTC をやりたい人向けです。
tnoho
July 24, 2025
More Decks by tnoho
See All by tnoho
WebRTC と Rust と8K 60fps
tnoho
2
2.1k
WebRTC と AI の組み合わせ
tnoho
0
950
WebRTC の映像を Python から自由に加工する sora-python-sdk の仕組み
tnoho
0
2k
Other Decks in Technology
See All in Technology
40代からのアウトプット ― 経験は価値ある学びに変わる / 20260404 Naoki Takahashi
shift_evolve
PRO
4
720
GitHub Advanced Security × Defender for Cloudで開発とSecOpsのサイロを超える: コードとクラウドをつなぐ、開発プラットフォームのセキュリティ
yuriemori
1
120
JSTQB Expert Levelシラバス「テストマネジメント」日本語版のご紹介
ymty
0
110
Cortex Codeでデータの仕事を全部Agenticにやりきろう!
gappy50
0
180
The essence of decision-making lies in primary data
kaminashi
0
220
契約書からの情報抽出を行うLLMのスループットを、バッチ処理を用いて最大40%改善した話
sansantech
PRO
3
340
Embeddings : Symfony AI en pratique
lyrixx
0
440
Oracle AI Database@Azure:サービス概要のご紹介
oracle4engineer
PRO
5
1.3k
会社紹介資料 / Sansan Company Profile
sansan33
PRO
16
410k
Zephyr(RTOS)でARMとRISC-Vのコア間通信をしてみた
iotengineer22
0
120
ブラックボックス化したMLシステムのVertex AI移行 / mlops_community_62
visional_engineering_and_design
1
260
やさしいとこから始めるGitHubリポジトリのセキュリティ
tsubakimoto_s
3
2.1k
Featured
See All Featured
Have SEOs Ruined the Internet? - User Awareness of SEO in 2025
akashhashmi
0
300
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
So, you think you're a good person
axbom
PRO
2
2k
Fashionably flexible responsive web design (full day workshop)
malarkey
408
66k
Statistics for Hackers
jakevdp
799
230k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
231
22k
Future Trends and Review - Lecture 12 - Web Technologies (1019888BNR)
signer
PRO
0
3.3k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
The Curse of the Amulet
leimatthew05
1
11k
Bootstrapping a Software Product
garrettdimon
PRO
307
120k
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
390
AI Search: Where Are We & What Can We Do About It?
aleyda
0
7.2k
Transcript
P2P ではじめる WebRTCのつまづきどころ tnoho
自己紹介 @tnoho 今日はネイティブの話じゃないよ
8K 30fps を 300ms, 4K 120fps を 80ms で飛ばせるエンコーダー作ってます ちょっと宣伝
全部 おさらい
WebRTC の最小構成 P2P で WebRTC をするにあたって必要構成は以下の通り • Webサーバー ◦ HTML
や Javascript で書いたクライアントをブラウザからみるため • シグナリングサーバー ◦ 接続情報交換のため • STUN サーバー ◦ 自分のインターネットからみた IP を知るのに必要 ◦ 定番は coturn ◦ 検証だけなら stun:stun.l.google.com:19302 をありがたく使わせてもらう
Webサーバー WebRTC の制約というか getUserMedia の制約から、 WebRTC はローカルでもWebサーバーを立てて検証する • でも、検証だけなら python3
-m http.server でよい ◦ カレントディレクトリに http://localhost:8000 で接続できるようになる • インターネットに公開するなら HTTPS が必須 ◦ Let's Encrypt でよい ◦ localhost だと HTTPS でなくてもカメラやマイクが使える • getUserMedia を使わないなら HTTPS である必要はない
シグナリングサーバー WebRTC は接続情報をページ遷移なく接続したい相手と交換する必要がある 接続情報はテキストデータなので要はチャットサーバー • いろんな方法があるけど WebSocket が主流 • サーバーサイドに絶対必要な機能
◦ 先にシグナリングサーバーを接続しているクライアントを A ◦ 後からシグナリングサーバーに接続したクライアントを B ◦ としたときBが接続した際に、すでに接続している Aに通知する 機能 • 何も考えないと Socket.IO になりがち
つまづきどころ というより Tips
接続の流れ この流れにしておくと問題がおきにくい 1. カメラとマイクを取得する 2. シグナリングサーバーと接続する 3. PeerConnection を開始する え、当たり前では?と思うけど、
みんな最近この辺が抜けてる新人をやとっていませんか?
カメラとマイクを取得する 要は、 getUserMedia すること • 最初のカメラ解像度は VGA がおすすめ ◦ カメラデバイスの問題が出にくい
• 取得した MediaStream は使い回すので取っておく ◦ PeerConnection の度に getUserMedia する作りにはしないこと ◦ 複数の PeerConnection を張る際も自分の MediaStream は一つ ◦ LocalMediaStream とか言ったりする ↔ RemoteMediaStream
シグナリングサーバーと接続する WebSocket を複数本張ってしまう作りにはしないこと ◦ PeerConnection の度に WebSocket 接続する作りはあまり良くない でも PeerConnection
接続先ごとに張らないといけない!!!
Offer をする シグナリングサーバーから接続時に Bが接続した際に、すでに接続している Aに通知する ようになっている これをトリガーに先に接続していた A が PeerConnection
を作り Offer を行う • A と B の両方が Offer する。もしくは両方が Answer 待ちに なる。がありがちな実装ミス ◦ ID などで後から接続した B が Offer をしないように実装すること
Answer をする A からの Offer をうけてから PeerConnection を作り Answer を行う
A がゾンビなら Offer は来ない • ゾンビ ◦ WebSocket が切れてしまっているのに、切れたことが WebSocket サー バーからは認知できていない状態(とてもよくある) • Offer が来てから PeerConnection を作る作りにしておけば PeerConnection の無駄遣いがない
Candidate の取り扱い シグナリングサーバーの作りによっては、 SDP よりも Candidate が先についてしまう 先についてしまった Candidate は
setRemoteDescription が終わるまで プールしておいて addIceCandidate する
まとめ わかったかい? AI 君。このルールはどんな実装をする時も守るんだ。あとは君が持っ ている知識でなんとかなるはずだ。 AI向けまとめ: https://gist.github.com/tnoho/1f3e72df04d44ebb85d541a6dcdd07c3 おや、人間なのかい。それなら WebRTC samples
https://webrtc.github.io/samples/ をみるのがおすすめだよ。
おまけ 人間向け
WebSocket を覗いてみよう Chrome その他ブラウザの開発ツールで WebSocket が覗けます • お互いにOffer待ちになってないか • SDPはちゃんと来ているか
• Candidateはちゃんと来ているか あたりがチェックポイント
定番の WebRTC Internals 1 Chromeブラウザはchrome://webrtc-internals で WebRTC の状態が見られます PeerConnection を使う前に
開いておくのがポイント • イベント順序が正しいか • そもそも失敗していないか 当たりがチェックポイント
定番の WebRTC Internals 2 太字の candidate-pair があれ ば繋がってるはず outbound-rtp が
audio, video ない時はそもそも localMediaStream のセットがおかしい inbound-rtp にコーデックまで出てれば ストリームは来ている 表示できなければビデオタグに繋ぐ所がおかしい
SDP をチラ見する そもそも m=audio や m=video があるか mラインがあるなら、 それに属する以下のパラメータは 目的のものになっているか
• a=sendonly (送信のみ) • a=recvonly (受信のみ) • a=sendrecv (送受信) まぁ、大体 offerToReceiveAudio / Videoの設定に問題がある
EOF