javascript - WebRTC は使用する TURN サーバーをどのように決定しますか

Question

この質問から分岐WebRTC - 何台の STUN/TURN サーバーを指定する必要がありますか?

複数のTURNサーバーが提供されている場合、WebRTCはどのTURNサーバーを使用するかをどのように決定しますか?

Answer 1

すべてのアイス候補は、集められた時点で優先されます。これはいくつかの要素が混ざり合ったものであり、各プラットフォーム (Chrome、FireFox など) には独自の好みがあると思います。

優先度の生成方法を説明するRFC へのリンクを次に示します。候補 ID は一意である必要があるため (RFC に従っている場合)、各優先度は一意であることが保証されます。したがって、優先順位が同じであってはなりません。優先順位の高いものが最初に試行され、それらとの接続が確立できない場合は、次の行が使用されます。

優先度に関する RFC からの引用:

式を使用する場合、エージェントは候補の各タイプ (サーバー再帰、ピア
再帰、中継、およびホスト) の優先度を決定することによって優先度を計算し、エージェントがマルチホームの場合は、
その IP アドレスの優先度を選択します。次に、これら 2 つのプリファレンス
を組み合わせて、候補の優先順位を計算します。その
優先順位は、次の式を使用して計算されます。

    priority = (2^24)*(type preference) +
               (2^8)*(local preference) +
               (2^0)*(256 - component ID)

タイプ優先度は 0 から 126 までの整数でなければならず、候補のタイプの優先度を表します (
タイプはローカル、サーバー再帰、ピア再帰、中継です)。126 が最高の
優先度で、0 が最低の優先度です。値を 0 に設定すると、このタイプの候補は 最後の手段
としてのみ使用されます。
タイプ設定は、同じタイプのすべての
候補で同一でなければならず、異なるタイプの候補では異なっていなければなりません
。ピア再帰候補のタイプ優先度は
、サーバー再帰候補のタイプ優先度よりも高くなければなりません (MUST)。
セクション 4.1.1 の手順に基づいて収集された候補者は、
ピア再帰候補になることはありません。これらのタイプの候補は
、ICE によって実行される接続チェックから学習されます。

ローカル プリファレンスは、0 から 65535 までの整数でなければなりません。
これは、エージェントがマルチホームである場合に、候補が取得された特定の IP アドレスの優先順位を表します。
65535 は最高の優先順位を表し、0 は最低の優先順位を表します。
IP アドレスが 1 つしかない場合、この値は 65535 に設定する必要があります。より一般的には、特定のメディア ストリームの特定のコンポーネントに同じタイプの候補が複数ある場合、ローカル プリファレンスはそれぞれに一意である必要があります。この
仕様では、これはマルチホーム ホストでのみ発生します。デュアル スタックであるためホストが
マルチホームである場合、ローカル プリファレンスは、RFC 3484 [RFC3484]
で説明されている IP アドレスの優先順位の値と等しく設定する必要があります。

コンポーネント ID は候補のコンポーネント ID であり、1 から 256 までの範囲である必要があります。

サーバーの IP とポートがリレー候補に表示されていることがわかります。以下は、RFC ページ 82およびwebrtc ハックから派生し たものです。

a=candidate:2157334355<ID> 2<Component> udp<NetType> 33562367<Prioirty> 180.6.6.6<NAT pub IP> 54278<NAT pub Port> typ relay<Means it needs to be relayed through Turn> raddr 46.2.2.2<Relay address of turn> rport 38135<relay port of turn> generation 0