問題タブ [coturn]

WebRTC を試していますが、接続に関して TURN サーバーがどのように機能するかについて詳しく知りたいです。

同じ電話会社のモバイル デバイスでも、相互に直接接続できないことを試したためです。メッセージを中継するには、TURN サーバーが必要です。

ルームに 4 人のプレイヤー A、B、C、D がいて、全員が互いに直接接続できないと仮定します。では、TURN サーバーの場合、接続はいくつあるでしょうか?

a) 6 b) 12 以上？

他のピアにブロードキャストするピアの場合、TURN サーバーによって受信および中継されるメッセージの数は?

同様の質問があります Coturn サーバー - リレーが機能していませんが、Amazon には NAT の背後にあるサーバーがあるため、適用されません。

オープン インターネットに接続されたベア メタル マシンがあります。WebRTC 接続を強制的に使用するrelayと、候補が交換され、候補が表示されrelay ますが、ストリームはありません。

これが構成です。external-ip設定、TLSのオンとオフの切り替えなど、あらゆる種類のことを試しましたが、役に立ちませんでした。

realmこのサーバーまたは別のサーバーにリダイレクトされる可能性のあるロードバランサーを指していますが、これは問題ではないと思います。

https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/からサーバーを呼び出すと、3 つの候補がすべて表示されます。

https://test.webrtc.orgツールは私にこれを与えます:

srflx上記の候補が表示され、通信経由srflxで実際に機能しているため、結果は間違っていると思います。

これは、chrome://webrtc-internals の両面です。候補ペアが確立されていないようです。

relay候補は次のようになります。

他に何を試すことができるかについてのアイデアが不足しています。潜在的なハードウェアの問題を回避するために、サーバーも交換しました。これを Alpine の Docker コンテナーで実行します。私たちが試していないのは、Ubuntu 16.04LTS の使用です。

誰が何が悪いのかを知ることができますか、または私たちが他に何を試すことができるかについてのアイデアを持っていますか?

追加情報：

さらに掘り下げた後、リレーがうまく機能する場合とそうでない場合があることがわかりました。米国では正常に動作しますが、EU のユーザーが呼び出されると問題が発生するようです。EU プロバイダーが prflx 候補を隠し、リレー接続を強制して失敗させていると思われます。通常は機能しない場所でも、まれに機能し、米国の場所から強制的にリレー接続すると、ストリームは問題なくリレーされます。正常に動作している場合、coturn で使用される帯域幅はインとアウトでほぼ同じですが、失敗すると、この画像に見られるように、インバウンドの帯域幅がアウトバウンドよりもはるかに高くなります。

ここに完全なダンプを追加することはできませんが、https://fippo.github.io/webrtc-dump-importer/に投稿し、接続の確立と候補のペアを示す関連部分を抽出しました。