Есть похожий вопрос Сервер 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
У нас заканчиваются идеи, что еще мы могли бы попробовать. Мы даже поменяли сервер, чтобы избежать возможных проблем с оборудованием. Мы запускаем это в контейнере Docker на Alpine. Мы не пробовали использовать Ubuntu 16.04LTS.
Кто-нибудь может увидеть, что не так или есть идеи, что еще мы могли бы попробовать?
Дополнительная информация:
Покопавшись дальше, мы обнаружили, что реле иногда отлично работает, иногда нет. Несмотря на то, что в США все работает нормально, проблемы возникают, когда звонят пользователю из ЕС. Я подозреваю, что провайдеры ЕС скрывают кандидатов prflx, заставляя ретрансляционное соединение, которое тогда терпит неудачу Даже там, где он обычно не работает, он работает в редких случаях, и когда я форсирую ретрансляционное соединение из моего местоположения в США, потоки передаются очень хорошо. Когда это работает, полоса пропускания, используемая на Coturn, почти одинакова для входящего и исходящего трафика, но когда происходит сбой, входящая пропускная способность намного выше исходящей, как видно на этом изображении.
Я не могу добавить полный дамп здесь, но я разместил его в https://fippo.github.io/webrtc-dump-importer/ и извлек соответствующую часть, показывающую установление соединения и пары кандидатов.
