socket.ioベースのシグナリングサーバーがある場合、webrtcにはSTUNサーバーが絶対に必要ですか？
クライアントがNAT（ほとんどの場合、すべてではないにしても）の背後にある場合、STUNサーバーはwebrtcクライアントがアドレスとポートを識別するのに役立ちます。また、webrtcクライアントにはシグナリングサーバーが必要であるという記事も読みました。シグナリングサーバーは、Webサーバー、socket.io、またはURLのメール送信などです。私の最初の質問は、STUNサーバーはシグナリングサーバーですか？
実際、私はクライアントのセッションの説明を他のすべてのクライアントにブロードキャストする非常にシンプルなsocket.ioベースのサービスを構築しました。そのため、socket.ioベースのサーバーには、クライアントのアドレスとポート情報に関する十分な知識が必要です。この場合、なぜ別のSTUNサーバーを用意する必要があるのでしょうか。
STUNサーバーは[〜＃〜]ではありません[〜＃〜]シグナリングサーバーです。
シグナリングサーバーの目的は、セッションの開始時にピア間で情報を渡すことです（送信先を知らずにオファーを送信するにはどうすればよいですか？）。この情報には、オファーとアンサーで作成されたSDP、およびいずれかの当事者によって作成された氷の候補も含まれます。
STUNサーバーを用意する理由は、2つのピアがメディアを相互に送信できるようにするためです。メディアストリームはシグナリングサーバーにヒットせず、代わりに直接相手（ピアツーピア接続の定義）に送られます。これに対する例外は、TURNサーバーが使用される場合です。
メディアは魔法のようにNATまたはファイアウォールを通過できません。これは、2つのパーティが互いに直接アクセスできないためです（同じLAN上にある場合のように）。
要するに、2つのパーティが同じネットワーク上になく（ピアツーピアメディアストリーミングの有効な接続候補を取得するため）、シグナリングサーバーが[ 〜＃〜]常に[〜＃〜]が必要です（異なるネットワーク上にあるかどうかに関係なく）。これにより、ネゴシエーションと接続の構築を行うことができます。 接続とストリーミングプロセスの適切な説明
STUNはICEプロトコルの実装に使用され、2つのクライアント間の有効なネットワークパスを見つけようとします。 ICEは、2つのクライアントが（NAT /ファイアウォールの制限により）直接のピアツーピア接続を確立できない場合に、TURNリレーサーバー（RTCPeerConnectionで構成されている場合）も使用します。
STUNサーバーは、インターネット上のコンピューターが使用する外部アドレス（NATの外側のアドレス）を識別し、ピアが使用できるポートマッピングのセットアップを試みるために使用されます（NAT = is "symmetric"）-STUNサーバーにアクセスすると、ICEで使用する外部IPとポートが通知されます。これらは、SDPまたはトリクルICEメッセージに含まれるICE候補です。
ほぼ保証された接続の場合、サーバーにはTURNサーバーが必要です（UDPとTCP TURNをサポートすることが望ましいですが、UDPがはるかに優先されます）。STUNとは異なり、TURNはかなりの帯域幅を使用できるため、ホストに費用がかかります。幸い、ほとんどの接続はTURNサーバーを使用しなくても成功します（つまり、ピアツーピアで実行されます）。
NAT（ネットワークアドレス変換）は、LANでのみ有効な「プライベートIP」をWANで有効な「パブリックIP」に変換するために使用されます。問題は、「パブリックIP」が外部からしか見えないため、STUNが必要ですまたはTURNサーバーから「パブリックIP」を返送します。このプロセスにより、WebRTCピアはパブリックにアクセス可能なアドレスを取得し、シグナリングメカニズムを介して別のピアに渡すことができます。
STUNサーバーは、外部ネットワークアドレスを取得するために使用されます。 TURNサーバーは、直接（ピアツーピア）接続が失敗した場合にトラフィックを中継するために使用されます。詳細については、以下のリンクから参照することもできます： https://www.html5rocks.com/en/tutorials/webrtc/infrastructure/#what-is-signaling