Для тех, кто пытается подружить Jami именно с eturnal.
У вас, скорее всего, в логах будет вот такое, и TURN работать не будет:
2026-05-29 11:23:18.265879+10:00 [info] Accepting long-term STUN/TURN authentication [TCP, session 9v720eufflnc, user myuser, client xx.xx.xx.xx:6971] 2026-05-29 11:23:18.265967+10:00 [notice] Rejecting allocation request: unsupported transport [TCP, session 9v720eufflnc, user myuser, client xx.xx.xx.xx:6971] 2026-05-29 11:23:18.266057+10:00 [notice] Relayed 0 KiB (in 0 B / 0 packets, out 0 B / 0 packets), duration: 0 seconds [TCP, session 9v720eufflnc, user myuser, client xx.xx.xx.xx:6971]
После долгих изысканий я нашёл, что:
Jami хочет использовать так называемый TCP Allocation по стандарту RFC 6062 (это расширение TURN, позволяющее TCP соединения, которые Jami использует для Files Sharing. Они об этом писали тут: Peer-to-peer file sharing support in Jami )
Eturnal НЕ поддерживает RFC 6062.
Решение: использовать coturn ( в некоторых ОС называется turnserver). Я проверял у себя, работает 100% с Jami.
Либо Restund (но его я не пробовал).
Да, именно так и происходит. За предложение bootstrap спасибо, но есть желание подружить это всё на своем железе. Если не затруднит, расскажите пожалуйста, или ткните носом в статьи. Я очень слаб в компьютерах, к сожалению. Внешний IPV4 есть, Debian Linux УЖЕ есть (в процессе освоения) и 24\7 работает, проц слабый, 8GB памяти есть.
Если этот хост не может коннектиться к дефолтному bootstrap, то поменять настройку в файле /etc/default/dhtnode (ну т.е. найти предварительно любую доступную ноду из существующих, и вписать ее адрес в этот файл).
Открыть в фаерволе порт 4222 на вход, или другой порт, его можно поменять в том же файле настроек выше.
По умолчанию файл настроек такой:
DHT_ARGS=-b bootstrap.jami.net -p 4222
Да, ваш dhtnode (как и мой и любой другой) не может брать данные для bootstrap из ниоткуда, он должен их взять из любой другой доступной живой ноды. Публичных списков нод, увы, нет (и может это хорошо). Как только ваша нода сконнектится с любой другой, то получит список остальных нод и далее сеть завертится.
Сама dhtnode очень легковесная и занимает в памяти 8-12МБ, трафика гоняет тоже немного.
Спасибо. Собрал. Но теперь проблема: turn не работает,если один из клиентов в той же локальной сети, что и сам turn. В логах user unauthorized. Это как-то решается?
У меня такого не было, поэтому затрудняюсь с советом.
Но я вот помню, что потратил двое суток, бился с проблемой “unauthorized” в turn, все сто раз перепроверил.
Оказалось: по крайней мере мой клиент Jami эмм… любит класть болт на юзер\пароль\realm который ему задаёшь в настройках и упорно использует дефолтный.
Лечилось ручной правкой конфига клиента, файл config.yml, поля:
#Server public IP address(es).
listening-ip=<server_ipv4>
listening-ip=<server_ipv6>
#Relay for World
relay-ip=<server_ipv4>
relay-ip=<server_ipv6>
No TLS in this setup
no-tls
min-port=52000
max-port=60000
lt-cred-mech
user=:
realm=
no-stdout-log
verbose
simple-log
log-file=/var/log/turnserver/turn.log
pidfile=/var/tmp/turnserver.pid
total-quota=1000
bps-capacity=0
stale-nonce
# WebRTC optimisation
no-multicast-peers
У вас, как я понял, coturn сидит в домашней локалке, т.е. он за NAT-ом.
Т.е. есть публичный айпи адрес у роутера и адрес в сети LAN у сервера с coturn.
Тогда, судя по документации, нужно сделать так:
Тут указать пару через слеш: <публичный_айпи>/<локальный_айпи>
external-ip=<public_ip>/<local_ip>
А тут указать только локальный айпи:
listening-ip=<local_ip>
Параметр relay_ip можно убрать, если у вашего сервера с COTURN всего один локальный айпи.
При пробросе портов учесть и порты из диапазона:
min-port=
max-port=
Это всё общие рекомендации конечно, частные случаи могут отличаться.
Проверьте в конфиге COTURN, что у вас ваша локалка не заблочена в