WebRTC — Web Protocol Lab

#このページで確認できること

SDP オファー/アンサーがシグナリング経由でどう交換されるかを確認する
ICE candidate の種類(host / srflx / prflx / relay)と STUN / TURN の役割を理解する
メディアが DTLS で鍵交換され SRTP で流れるまでの順序をシーケンスで確認する
DevTools のコンソールからSTUNサーバーに観測されたアドレス(srflx candidate)を確認する
観察する項目: chrome://webrtc-internals、Wireshark フィルタ stun / dtls / rtp

実装上の制約: 本サイトにシグナリングサーバー・TURNサーバーは未設置です。掲載しているのはブラウザ単体+公開STUNサーバーで試せる範囲と、既存のWebRTCサービス(ビデオ会議等)を観測する手順です。

#構成要素

要素	役割	仕様
シグナリング	SDP と ICE candidate の交換。方式は仕様外で、通常 WebSocket や HTTPS で実装される	—
SDP	コーデック・トランスポート・暗号パラメータの記述 (offer / answer モデル)	RFC 8866 / 3264
ICE	候補アドレスを列挙し、実際に通る経路を探索する枠組み	RFC 8445
STUN	WebRTCのBinding利用では、NATの外側から見た自分のIP:portを取得する(UDP 3478ほか)。STUNの用途全体はこれに限らない	RFC 8489
TURN	直接経路が成立しない場合などに使う中継サーバー。標準ポートはUDP/TCP 3478、TLS/DTLS 5349。到達性を高める配備ではTLS 443も使われる	RFC 8656
DTLS	メディア鍵の交換とデータチャネルの保護。WebRTCのDTLS要件とDTLS-SRTPプロファイルは、DTLS 1.3そのものとは別の仕様	RFC 8827 / RFC 5764 DTLS 1.3: RFC 9147
SRTP	音声・映像の暗号化転送	RFC 3711
SCTP	データチャネル (DTLS 上で動く)	RFC 8831

#接続確立の流れ

WebRTC 接続確立 — シグナリングからメディアまで

participants: Peer A, Signaling, Peer B
Peer A -> Signaling: SDP offer (WebSocket 等)
Signaling -> Peer B: SDP offer を転送
Peer B -> Signaling: SDP answer
Signaling -> Peer A: SDP answer を転送
note: ICE candidate も同じ経路で随時交換 (trickle ICE)
Peer A <-> Peer B: STUN connectivity checks (候補ペアの疎通確認)
note: 通る候補ペアが決まる — 以降はP2P (またはTURN中継)
Peer A <-> Peer B: DTLS handshake (鍵交換)
Peer A <-> Peer B: SRTP media / SCTP data channel

ICE candidate の4種類: host(ローカル候補)、srflx(STUNで得たNAT外側候補)、prflx(connectivity check中に発見されるpeer-reflexive候補)、relay(TURN経由の中継候補)。候補ペアの優先度と疎通結果に基づいて選択され、直接候補が成立しない場合などにrelayが選ばれる。
シグナリングは観測しやすい: WebSocket 上の JSON として DevTools の WS タブで読めることが多い(サービス実装による)。
キャプチャ単独ではメディアを復号できない: SRTP の鍵は DTLS から導出されるため、通常のパケットキャプチャだけではメディアを復元できない。エンドポイントから鍵情報を得られる特殊な検証環境は別扱い。

#検証 — ブラウザ単体で試す

DevTools Console — 自分の ICE candidate を見る

const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.l.google.com:19302" }]
});
pc.createDataChannel("probe");
pc.onicecandidate = (e) => e.candidate && console.log(e.candidate.candidate);
pc.createOffer().then((o) => pc.setLocalDescription(o));

expected (console 出力の例)

candidate:842163049 1 udp 1677729535 203.0.113.55 54321 typ srflx raddr 0.0.0.0 rport 0 candidate:1234567890 1 udp 2122260223 192.168.1.20 56789 typ host

typ srflx の行に出るIPが「STUNサーバーから見た自分のアドレス」です。VPNやネットワーク環境で値がどう変わるかを比較すると、経路の切り分けに使えます。srflx が出ない場合はUDP(STUN)遮断の可能性がありますが、NATがなくhost候補と冗長になった場合、STUN設定・名前解決・ブラウザポリシーなど別の理由もあり得ます。また、現在のブラウザはプライバシー保護のためhost候補のローカルIPをmDNS名で表示することがあります。STUNパケットとICEエラーを併せて確認してください。

実サービスの観測

# Chrome: 通話中に別タブで開く
chrome://webrtc-internals
# Firefox の場合
about:webrtc

#観測ポイント

DevTools	WS タブでシグナリング(SDP / candidate の JSON)。`chrome://webrtc-internals` で選択された candidate pair、`dtlsState`、ビットレート・パケットロスのグラフ。
Proxy	従来型の明示HTTPプロキシはUDPをトンネルしないが、プロキシ設定だけでブラウザの直接UDP送信が必ず止まるわけではない。ファイアウォールや端末ポリシーでUDPも遮断される環境では、TURN over TCP/TLS(しばしば443)へのフォールバック可否と品質を確認する。選択されたcandidate pairがrelayならTURN中継経由。
tcpdump / Wireshark	フィルタ: `stun`(connectivity check の Binding Request/Response)、`dtls`(鍵交換)。メディアは `udp` の大量の小パケット — Decode As で RTP と解釈させればヘッダー(SSRC等)は読める。
TLS inspection	シグナリング(WebSocket/HTTPS)は復号対象になり得るが、SRTPは通常のTLSインスペクション装置では復号できない。UDP遮断環境ではTURN/TLSの経路がインスペクション設定と競合し、接続が失敗する場合がある。必要に応じてベンダー要件に沿った復号除外を検討する。
ネットワーク設計	主要なWebRTC SaaSは、必要なUDPポート範囲や宛先を公開していることが多い。ファイアウォールで直接UDPを許可するか、TURN/TCP等へフォールバックした場合の品質を受け入れるかの判断材料として観測する。

#関連

鍵交換の仕組みは DTLS、メディア転送の中身は RTP / RTCP / SRTP を参照。シグナリングによく使われる WebSocket も合わせて読むと全体がつながります。