同様の質問があります Coturn サーバー - リレーが機能していませんが、Amazon には NAT の背後にあるサーバーがあるため、適用されません。
オープン インターネットに接続されたベア メタル マシンがあります。WebRTC 接続を強制的に使用するrelayと、候補が交換され、候補が表示されrelay
ますが、ストリームはありません。
これが構成です。external-ip設定、TLSのオンとオフの切り替えなど、あらゆる種類のことを試しましたが、役に立ちませんでした。
listening-ip=<public-address>
listening-port=443
tls-listening-port=443
cert=/etc/star-attach-live-certificate.pem
pkey=/etc/star-attach-live-certificate.key
min-port=49152
max-port=65535
realm=turn.example.com
server-name=servername.example.com
fingerprint
max-bps=550000
use-auth-secret
static-auth-secret=<secret>
check-origin-consistency
userdb=/usr/local/var/db/turndb
realmこのサーバーまたは別のサーバーにリダイレクトされる可能性のあるロードバランサーを指していますが、これは問題ではないと思います。
https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/からサーバーを呼び出すと、3 つの候補がすべて表示されます。
https://test.webrtc.orgツールは私にこれを与えます:
srflx上記の候補が表示され、通信経由srflxで実際に機能しているため、結果は間違っていると思います。
これは、chrome://webrtc-internals の両面です。候補ペアが確立されていないようです。
relay候補は次のようになります。
sdpMid: 0, sdpMLineIndex: 0, candidate: candidate:3193418391 1 udp 24846335 95.216.16.200 55992 typ relay raddr 0.0.0.0 rport 0 generation 0 ufrag qW0i network-id 1 network-cost 10
他に何を試すことができるかについてのアイデアが不足しています。潜在的なハードウェアの問題を回避するために、サーバーも交換しました。これを Alpine の Docker コンテナーで実行します。私たちが試していないのは、Ubuntu 16.04LTS の使用です。
誰が何が悪いのかを知ることができますか、または私たちが他に何を試すことができるかについてのアイデアを持っていますか?
追加情報：
さらに掘り下げた後、リレーがうまく機能する場合とそうでない場合があることがわかりました。米国では正常に動作しますが、EU のユーザーが呼び出されると問題が発生するようです。EU プロバイダーが prflx 候補を隠し、リレー接続を強制して失敗させていると思われます。通常は機能しない場所でも、まれに機能し、米国の場所から強制的にリレー接続すると、ストリームは問題なくリレーされます。正常に動作している場合、coturn で使用される帯域幅はインとアウトでほぼ同じですが、失敗すると、この画像に見られるように、インバウンドの帯域幅がアウトバウンドよりもはるかに高くなります。
ここに完全なダンプを追加することはできませんが、https://fippo.github.io/webrtc-dump-importer/に投稿し、接続の確立と候補のペアを示す関連部分を抽出しました。
