WebRTCとは
WebRTCは、ブラウザやアプリ間で音声・映像・データをリアルタイムに交換する技術群です。一般にWeb Real-Time Communication（ウェブ・リアルタイム・コミュニケーション）を表し、ウェブアールティーシーと読みます。
カメラ・マイクからTrackを得るWeb API、接続条件を合意する提案・応答、NAT越しの経路を選ぶICE、音声・映像を運ぶRTP・RTCPとSRTP保護、任意データを運ぶDataChannelなどを組み合わせます。
WebRTCは一つの通信プロトコルではなく、シグナリング、経路発見、暗号鍵合意、メディア、データを役割別の標準でつなぐ仕組みです。相手を見つけて提案・応答を交換するシグナリング方式はWebRTC自体が指定しません。
接続成立までを、別々の役割に分けて追う
利用者許可を受け、選択したマイク・カメラからMediaStreamTrackを作る
アプリの通信路でSDP提案・応答、ICE候補、参加者情報を渡す
端末、STUNで得るserver-reflexive、TURN中継などの候補を作る
ICE 接続性確認を行い、双方向に到達できる有効ペアを選ぶ
DTLSハンドシェイクの指紋をシグナリング条件へ照らし、SRTP鍵を導く
RTCP、遅延、損失、帯域推定から映像解像度・ビットレート・送信層を変える
シグナリングはWebRTCの外側で、相手と接続条件を交換する
アプリはWebSocket、HTTPS、既存メッセージ基盤などを使い、誰と通話するか、SDP提案・応答、ICE候補を交換します。WebRTCはこの通信路のURL、認証、再送、会議室管理を定めません。
JSEP（JavaScript Session Establishment Protocol／ジャバスクリプト・セッション・エスタブリッシュメント・プロトコル）の提案・応答には、対応コーデック、メディア方向、拡張、DTLS指紋などが入ります。シグナリングサーバーは改ざんされない認証済み経路で結び、別の相手へ差し替えられないようにします。
ICEは複数の候補ペアを検査し、実際に通る経路を選ぶ
ICE（Interactive Connectivity Establishment／インタラクティブ・コネクティビティ・エスタブリッシュメント）は、両端の候補アドレスを組み合わせ、STUN 束縛要求を使う接続性確認で到達性を検証します。優先度を付け、成功した候補ペアから通信に使うものを指名します。
端末インターフェースのホストcandidate、STUNサーバーから見えたNAT外側のserver-reflexive candidate、TURNサーバーが中継する中継candidateなどがあります。候補にアドレスが書かれていることと、その経路が双方向に通信できることは別なので、必ず検査結果で選ぶ仕組みです。
STUNは外から見える対応を知り、TURNは通信を中継する
STUN（Session Traversal Utilities for NAT／セッション・トラバーサル・ユーティリティーズ・フォー・ナット）は、STUNサーバーが受信した送信元IP・ポートを応答し、NATで作られた外側対応を端末へ知らせます。STUNサーバーは通常メディアを中継しません。
TURN（Traversal Using Relays around NAT／トラバーサル・ユージング・リレイズ・アラウンド・ナット）は中継アドレスを割り当て、直接経路が通らないとき通信を転送します。企業ファイアウォールや対称NATなどで必要になり、帯域・遅延・運用費がかかります。TURNを最終候補として確実に利用できる構成が通話成功率を支えます。
メディアはSRTP、鍵合意はDTLS、制御はRTCPを使う
音声・映像はRTPパケットとして送られ、SRTP（Secure Real-time Transport Protocol／セキュア・リアルタイム・トランスポート・プロトコル）で暗号化・完全性保護されます。DTLSハンドシェイクからSRTP鍵を導くDTLS-SRTPを使います。
RTCPは受信パケット数、損失、ジッター、往復時間、映像のキーフレーム要求などを伝えます。送信側は帯域推定と合わせ、ビットレート、フレームレート、解像度、複数simulcast層を調整します。UDPが使えない環境でTURN/TCP・TLSを使うと、順序待ちでリアルタイム性が下がる場合があります。
DataChannelは、メディアとは別の信頼性設定を持てる
WebRTC DataChannelは一般にSCTPをDTLS上へ載せ、文字列またはバイナリーデータをメッセージ境界付きで運びます。順序保証あり・なし、再送回数または生存時間制限などをチャネルごとに選べます。
ファイル、ゲーム状態、字幕、制御信号などへ使えますが、巨大メッセージはほかのチャネルを待たせる場合があります。分割、送信バッファー監視、受領確認をアプリで設計します。WebSocketのように常に中央サーバーとの一本のTCP接続を使う方式とは異なります。
カメラ許可と、相手へTrackを送る操作は別段階である
ブラウザーは安全なコンテキストで、利用者の明示許可を得てカメラ・マイクへアクセスします。許可後も、どのTrackをどのPeerConnectionへ追加し、いつ停止するかはアプリが決めます。画面共有も別の利用者選択を伴います。
デバイスラベル、ローカルIP、候補情報はフィンガープリンティングへ関係します。ブラウザーはmDNS候補などでローカルIP露出を抑える場合があります。権限表示、ミュート状態、送信中表示を画面と実際のTrack状態で一致させます。
P2Pは経路の一候補で、サービスにサーバーが不要という意味ではない
二者通話では端末間の直接候補が選ばれることがありますが、TURN中継、シグナリング、認証、参加者管理、録画、監視にはサーバーを使います。多人数会議では各端末が全員へ送るmeshより、SFUがメディアを選択転送する構成が一般的です。
WebRTCを「必ず直接つながる無料のP2P」と考えず、TURN比率、地域、帯域、障害時フォールバック、暗号終端、録画方針を含めて設計します。SFUがパケットを転送しても、構成によりメディア暗号の終端関係は異なります。
仕様の確認資料：W3C Recommendation「WebRTC 1.0」、RFC 8825「WebRTC Protocol Overview」、RFC 8445「ICE」、RFC 8656「TURN」