問題タブ [nat-traversal]

私の質問は webrtc ネゴシエーションについてです。

多くのオンライン チュートリアルと MDN で説明されている内容には矛盾があります。

MDNでは、リンクと言っています

各候補生成の最後に、候補プロパティが空の文字列である RTCIceCandidate の形式で候補終了通知が送信されます。この候補は、その通知をリモート ピアに配信するために、通常どおりaddIceCandidate() メソッドを使用して接続に追加する必要があります。

現在のネゴシエーション交換中に予想される候補がまったくない場合、候補プロパティが null である RTCIceCandidate を配信することによって、候補終了通知が送信されます。このメッセージをリモート ピアに送信する必要はありません。これは、icegatheringstatechange イベントを監視することにより、iceGatheringState が完了に変更されるのを監視することによって代わりに検出できる、状態の従来の通知です。

ただし、ここのチュートリアルでは、次のコードを紹介しています

候補が空の文字列の場合、偽と評価され、 経由で送信されませんsendToServer。

さらに興味深いことに、ここの同じ記事でも

彼らは次のサンプルコードを持っています

しかし、このスニペットのすぐ下に、彼らは言います

ICE ネゴシエーション セッションで、特定の RTCIceTransport を提案する候補がなくなると、候補の世代の収集が完了します。これが発生したことは、候補文字列が空 ("") である icecandidate イベントによって示されます。

上記の「新しい候補を共有する」で説明されているように、標準の候補と同様に、これをリモート ピアに配信する必要があります。これにより、リモート ピアにも候補終了通知が確実に送信されます。

実際、私は多くのオンラインチュートリアルを読みましたが、空の文字列候補を処理する場所を見たことがありません。

A と B の 2 つのピアがあり、Symmetric NAT を介して WebRTC ピア接続を確立しようとしているとします。彼らはシグナリングを介してICE候補を交換しました。

A のパブリック アドレス: IP_A : Port_A
B のパブリック アドレス: IP_B : Port_B

まず、A は B IP_A : Port_A ---> IP_B : Port_Bに接続しようとします。

ただし、要求は B の NAT によって拒否されます。B の STUN サーバーだけがそのアドレスで B に接続できます。

次はBさんの番です。
IP_B : Port_B ---> IP_A : Port_A

しかし、ここで、接続を確立する必要がありますか? ピア A の NAT テーブルは、A が最初に B に要求を送信したときにピア B のアドレスを登録している必要があるためです。したがって、B からの応答はすべて受け入れられる必要があります。しかし、もちろん、それはうまくいかないようです。それで、どこが間違っているのですか？