WebRTCのICE候補と経路統計で接続失敗を診断する
候補収集、シグナリング、ペア検査、選択経路を分けて観察し、WebRTC接続失敗の仮説を絞ります。
発行・訂正窓口：infostoa · 編集基準
この記事の個別の執筆者・専門査読者の情報は提供されていません。
WebRTCの接続失敗を「ファイアウォールの問題」とだけ説明しても、原因は絞れません。ICEでは候補の収集、アプリのシグナリング経由での相手候補の受け渡し、候補ペアの接続確認、利用経路の選択という段階を観察します。どこで止まったかを分けると、シグナリング側とICE経路側の仮説を整理できます。統計項目はブラウザーやバージョンにより異なり、欠落値をゼロと見なすことはできません。
再現条件を固定し、接続開始前から記録する
ブラウザーとバージョン、OS、ネットワーク種別、発生時刻、再現手順を記録します。Chromeでは通話開始前にchrome://webrtc-internalsを開き、再現中も保持します。WebRTCプロジェクトの不具合報告案内は、接続問題でPeerConnectionの更新情報と統計をダウンロードするよう勧めています。機能やICEの問題ではネイティブログも必要になることがあります。シグナリングの送受信時刻、local/remote descriptionの設定結果、候補イベント、接続状態の変化を同じ時間軸に並べます。
アプリ画面の「接続中」という表示だけでは、候補が集まり相手へ届き検査されたかは分かりません。診断ダンプには候補アドレスなどのネットワーク情報が含まれることがあるため、共有前にアクセスを制限し、必要な情報だけを残します。
候補収集とシグナリングによる受け渡しを分ける
まずiceGatheringStateと候補イベントを確認します。収集が進行中なら追加候補が現れる場合があります。完了後も候補が見えないときはICEサーバー設定、権限やネットワーク環境を調べる手掛かりになりますが、それだけで特定のファイアウォールやNATを原因と断定できません。実装が候補の詳細を制限する場合もあり、アプリから見える一覧がネットワーク全体を表すわけではありません。
次に、アプリが送信した候補と相手から受信した候補を比較します。候補数、セッション識別子、ICE世代、解析結果、時刻を確認します。trickle ICEではdescriptionと候補の到着順が前後するため、アプリが有効な候補を早く破棄していないかも調べます。ローカル候補が生成されたことは、相手への到達や接続検査の成功を意味しません。相手候補が届いていなければ、まずシグナリング経路を調査します。双方に候補があればペア検査へ進みます。
候補ペアの状態を時系列で読む
getStats()のcandidate-pair項目は接続確認を観察する出発点です。W3C統計Editors’ Draft（Recommendation採択前の提案）にはfrozen、waiting、in-progress、succeeded、failedなどの状態があります。連続する標本を比べ、待機中か、検査が始まったか、応答が得られたかを見ます。状態だけで利用者側の通話成功が保証されるわけではありません。requestsSent、responsesReceived、currentRoundTripTimeなどは実装や状況により存在しないことがあるため、欠落をゼロとして扱わないでください。
ペアのIDからローカル・リモート候補統計へたどり、候補種別とプロトコルを確認します。host、server-reflexive、relay候補の違いは次に試す条件を考える材料になりますが、候補種別だけで根本原因は証明できません。成功ペアがない場合も、特定のルーターやネットワークポリシーを特定するには追加証拠が必要です。TURN割当、資格情報、サービス側ログはアプリとTURN運用者が別途確認します。
選択経路とアプリケーションの通信を別々に確かめる
経路選択後は統計レポート内のtransportとcandidate-pairの参照IDをたどり、nomination、送受信バイト数、応答数、時刻の変化を比較します。選択を表す項目は実装差があるため、特定ブラウザーの一つのプロパティを共通仕様として扱わないでください。選択ペアが観察できても、アプリが意図した相手にデータを届けた証明にはなりません。通信量やアプリメッセージが動かない場合、データチャネル状態と相手側の処理を分けて調べます。
断続的な失敗ではICE restartや経路変更の前後を記録します。再起動で候補ペアやIDが変わることがあり、単一の統計スナップショットでは履歴を失います。ブラウザーとネットワーク条件ごとに複数回試し、成功率には標本数を添えます。これは原因候補を絞る方法であり、ログだけで特定のNATや装置の故障を証明するものではありません。
専門家の視点：欠測値とプライバシーを同時に扱う
W3C WebRTC統計Editors’ Draft（Recommendation採択前の提案）は統計をある時点のスナップショットとして説明し、未実装・非該当の項目は省略され得るとします。WebRTCプロジェクトの報告案内は再現手順、ブラウザーとOSの版、接続ログを求めています。見えない値はゼロや失敗に置き換えず「未提供」と記録します。候補アドレスなどが含まれ得る診断ダンプは共有範囲を絞り、調査に必要な項目だけを保存します。