2017-05-18 13 views
0

私はTURNサーバーを実装しています。私は質問にTURN rfc5766用語を使用します。TURNサーバーナットトラバーサルICE STUN

私には得られない部分があります。 TURNサーバーに接続されているクライアント(A)と、まだ何も接続されていないピア(B)があるとします。別の仕組みからピア(B)の反射的アドレスを取得し、それをSIPまたは電子メールを使用してクライアント(A)に渡します。多分どんな場合でも。

次は、私たちは、クライアント(A)の割り当て、権限、およびリレーアドレス

それは言うを作成したと仮定することができます、そのクライアント(A)は、サーバが、それを中継するために有効にするには、ピア(B)のためのデータ指示を送信するときピア(B)のサーバ反射的アドレスを指示に添付する。次に、サーバーは、指示とピア(B)の反映アドレスからudpを抽出し、それをピア(B) に送信します。 私は、サーバがNATの背後にあるピア(B)にどのように到達できるのか分かりません。ピア(B)のサーバー反射的なアドレスを知っているだけではそれが正しく処理されません。 ピア(B)がサーバと通信したことがない場合、ピア(B)のNATは、TURNサーバ上のピア(B)からクライアント(A)のリレーアドレスへのマッピングを決して作成しません。

サーバがout ip:portマッピングを使用してピア(B)のサーバ反射的アドレスに到達できる場合、クライアント(A)も可能です(クライアントはピア(B)のサーバ反射アドレスも知っているので)。そして、ターンサーバーは必要ありません。それはちょうどSTUNを使用します。

TURN Serverのポイントは何ですか? 私は何が欠けています。

ピア(B)が同じサーバに事前にSTUNバインディング要求を行い、それがピア(B)サーバリフレクティブアドレスを取得し、その要求がピア(B)上でNATマッピングを作成したとします。の側。これは、エンドポイントに依存しないマッピングとアドレス依存型マッピングを使用するNATでは機能しますが、アドレスとポート依存型マッピングでは機能しません。クライアント(A)の中継アドレスが、STUNバインディング要求が送信されるTurnサーバのアドレスと異なるためです。 例: ターンサーバーアドレス:121.121.121.121:8080 クライアントの中継アドレス:121.121.121.121:8081(同じターンサーバーの別のポートで)。 stunバインディングメッセージは121.121.121.121:8080に送信されるため、121.121.121.121:8081のピア(B)のNATにはマッピングがありません。 基本的に橋が壊れています。

ありがとうございました。

答えて

0

メッセージの開始前にピア(B)がTURNサーバーに接続していないことが説明されています。本当じゃない。

WebRTCクライアントでは、STUNおよびTURNサーバーアドレスを構成する必要があります。クライアントがPeerConnectionsを作成すると、実際のメッセージングが始まる前にTURNサーバーに接続されます。これを行うには、両方のピアがTURNサーバに接続し、NATを通過するトラフィックを許可する「ホールパンチ」を実行する必要があります。

トラフィックをTURNサーバ経由で中継する場合、クライアントは互いに通信するTURNエンドポイントだけをIPアドレスで知りません。

関連する問題