WebRTC は『P2P 通信』をブラウザに持ち込む技術
WebRTC はブラウザ間のリアルタイム通信(ビデオ/オーディオ/データ) を実現する標準技術です。本記事では編集部の視点で、実装の要点を公開情報をもとに整理します。SSE 実装ガイド もご参考に。
WebRTC の3要素
(1) MediaStream：カメラ/マイクの取得。(2) RTCPeerConnection：P2P接続管理。(3) RTCDataChannel：任意データのP2P転送。(4) シグナリング：WebSocket等で接続情報交換。(5) STUN/TURN：NAT 越え。P2P と言っても完全 P2P は環境で難しく、サーバー(SFU/MCU)経由が一般的です。
NAT 越えと STUN/TURN
(1) STUN：自分の公開IP/ポートを取得。(2) TURN：リレーサーバ経由(STUNで繋がらない時)。(3) ICE：複数候補を試して接続。(4) TURN コスト：転送量課金で高くつくことも。(5) coturn：OSS の TURN 実装。モバイルや厳しいファイアウォール環境では TURN ヒット率が上がります。
SFU vs MCU vs P2P
(1) P2P：1対1向け、3人以上は破綻。(2) SFU (Selective Forwarding Unit)：サーバが転送、現代の主流。(3) MCU (Multipoint Control Unit)：サーバが合成、CPU 高負荷。(4) Mediasoup / janus / Jitsi：OSS SFU。(5) Twilio / Daily / Agora：マネージドSaaS。マネージド利用が現実的です。
録画と字幕
(1) サーバ側録画：SFU 経由で MP4 等に。(2) クライアント側録画：MediaRecorder API。(3) 音声→テキスト：Whisper / Web Speech API。(4) リアルタイム字幕：ストリーミング ASR。(5) 多言語対応：翻訳 API 連携。
セキュリティ
(1) DTLS 必須：暗号化通信。(2) 認証：シグナリングサーバで JWT。(3) TURN ユーザー認証：濫用防止。(4) 個人情報の取扱い：録画の保管期間。(5) 監査ログ：誰がいつ通信したか。Webセキュリティ実践 もご参考に。
失敗しがちなパターン
(1) P2P で多人数会議：上り帯域が破綻。(2) TURN なしでモバイル対応：接続失敗多発。(3) HD 配信を全員フルで送信：CPU/帯域逼迫。(4) 録画ストレージ無限：コスト爆発。(5) 監視不足：問題が見えない。対策は、(1)SFU、(2)TURN 必須、(3)simulcast/SVC、(4)Lifecycle、(5)接続成功率/レイテンシ計測、です。