よくある質問

STUN、TURN、および ICE とは何ですか。

STUN、TURN、および ICE は、ピアツーピア通信セッションを確立する際に NAT 越えをネゴシエーションするための一連の IETF 標準プロトコルです。WebRTC スタックと他の VoIP スタックには、IP 通信の信頼性を高める ICE のサポートが実装されています。

ホストは、自身が NAT/ファイアウォールの背後にあるときは、STUN (Session Traversal Utilities for NAT)を使用してそのパブリック IP アドレスを検出します。このホストが別の番号から着信接続を受信する必要がある場合、接続を受信可能な場所として、このパブリック IP アドレスを渡します。それでも NAT/ファイアウォールが 2 つのホストの直接接続を許可しない場合、TURN (Traversal Using Relay around NAT)を実装して、サーバーへの接続を確立します。TURN は、2 つの番号間でメディアをリレーします。

IEC (Interactive Connectivity Establishment)は、ホスト間で接続を確立するために STUN と TURN を調整する方法について記述した包括的な標準です。Twilio のネットワークトラバーサルサービスは、WebRTC 標準をサポートするブラウザなど、ICE 互換クライアント向けに STUN と TURN を実装しています。

詳細については、次の RFC を参照してください。

STUN、TURN、および ICE はどのように動作しますか。

Alice と Bob は 2 人とも WebRTC ビデオチャットアプリケーションのユーザーであり、Alice が Bob を呼び出すとします。その後に行われることを次に示します。

Alice のブラウザは、Bob のブラウザに接続するために、SDP (Session Description Protocol)オファーを生成する必要があります。Alice が使用しているアプリケーションが、RTCPeerConnection オブジェクトの createOffer を呼び出すと、SDP 生成プロセスが始まります。

SDP オファーには、Alice のブラウザが確立しようとするセッションに関する一連の情報(使用するコーデック、オーディオセッションかビデオセッションか、など)が設定されます。また、ICE 候補のリストも設定されます。このリストは、Bob のブラウザが Alice に接続するために試すことができる IP とポートのペアです。

ICE 候補のリストを構築するために、Alice のブラウザは、STUN サーバーに一連のリクエストを送信します。サーバーは、そのリクエストの発信元のパブリック IP アドレスとポートのペアを返します。Alice のブラウザは、各ペアを ICE 候補のリストに追加します。このプロセスは、ICE 候補の収集と呼ばれます。Alice のブラウザが ICE 候補の収集を終了すると、SDP を返すことができるようになります。

次に、Alice のブラウザは、ブラウザ間のシグナリングチャンネルを通じて、SDP を Bob のブラウザに渡す必要があります。WebRTC は、このシグナリングの実装を開発者に任せています。シグナリングのインとアウトについては範囲外であり、ここでは説明しません。ここでは、Bob が、何らかのシグナリングチャンネルを通じて、Alice の SDP オファーを受信すると仮定します。

今度は、Bob のブラウザが SDP アンサーを生成する必要があります。Bob のブラウザは、前述の Alice のブラウザが実行したのと同じ手順で ICE 候補の収集などを行い、その後で生成した SDP アンサーを Alice のブラウザに返す必要があります。

Alice と Bob が SDP を交換した後、それぞれが一連の接続性チェックを実行します。各ブラウザの ICE アルゴリズムは、相手の SDP で受信したリストから候補となる IP/ポートのペアを取得し、そこに STUN リクエストを送信します。相手のブラウザから応答が返ってきた場合、発信元のブラウザはチェックが成功したと見なして、その IP/ポートのペアを有効な ICE 候補としてマークします。

すべての IP/ポートのペアについて接続性チェックが終了した後、ブラウザ間でネゴシエーションして、有効なペアの 1 つを使用することを決定します。ペアの選択が終わったら、メディアがブラウザ間を流れ始めます。このプロセス全体にかかる時間は、通常は数ミリ秒です。

ブラウザは、接続性チェックに合格する IP/ポートのペアを見つけられなかった場合、TURN サーバーに STUN リクエストを送信して、メディアリレーアドレスを取得します。リレーアドレスは、リレーアドレスが設定されているブラウザ間で受信したパケットを中継するパブリック IP アドレスとポートです。このリレーアドレスは候補リストに追加され、シグナリングチャンネル経由で交換されます。

WebRTC アプリケーションを構築する場合、上記の処理のほとんどを自動実行する ICE エージェントが WebRTC スタックに組み込まれています。実装する必要があるのは、SDP を交換し、新しい ICE 候補が見つかるたびにそれを送信するシグナリングチャンネルのみです。

アプリケーションで ICE ネゴシエーションをトラブルシューティングする方法を教えてください。

Google Chrome の利用

新しいタブで chrome://webrtc-internals を開きます。別のタブでアプリケーションから WebRTC を呼び出します。webrtc-internals ページには、アクティブな PeerConnection オブジェクトごとに対応するタブが表示されます。このページには、呼び出しを設定しようとしたときに発生した ICE ネゴシエーションイベント(iceGatheringStateChangeonIceCandidate など)のリストが表示されます。ツリーの各ノードを展開すると、イベントの詳細を表示できます。

Firefox の利用

新しいタブで、about:webrtc を開きます。別のタブで、アプリケーションから WebRTC を呼び出します。about:webrtc ページで、「Connection Log」ボタンをクリックします。イベントログが表示されます。このログファイルで文字列「ICE」を指定して、ICE イベントと STUN/TURN イベントを検索します。

ヘルプが必要ですか?

誰しもが一度は考える「コーディングって難しい」。そんな時は、お問い合わせフォームから質問してください。 または、Stack Overflow でTwilioタグのついた情報から欲しいものを探してみましょう。