[РЕШЕНО]Matrix Synapse coturn 2025г установка запуск настройка

[lnx]

Коллеги, сколько-то лет назад, точно, что больше десятка, я на свободных мощностях запускал собственный демон для поддержки федеративности. Оказался не востребован и был позже закрыт. Однако злоба дня вопрос актуализирует, а время прошло и может кто уже имеет боевой опыт или хотябы хорошо начитан по теме развертывания своего сервера и может ткнуть носом в хорошую инструкцию?
на нынешних серверах все такое свистящее и подпрыгивающее, типа https://matrix.org/docs/matrix-concepts ... homeserver, что вот прямо там адекватного чисто технического описания "поставить свой" не находится, и апишут, что есть шлюзы в ТЛГ и ВА, что судя по действиям ОСПОСов внезапно будет нужно. Ну простейший пример - наши родные страны СССР, в одной банят все ru, в другой все ... И нарушение связи видится вполне реальной перспективой.

https://matrix.org/ecosystem/servers/
Tuwunel = Apache-2.0 Rust
Synapse = AGPL-3.0-or-later OR Element Commercial License Python

В репах вижу только Synapse, в Ауре есть и Tuwunel. Кто что скажет конструктивного?

Задача решена. Работает чат, голосовая и видеосвязь как в локальной сети, так и и сотовой. Участники - лэптопы и телефоны.
Инструкцию сделаю и опубликую по запросу заинтересованных лиц - "для галочки" лень готовить простыню и вычищать из нее "личные данные".

[ALiEN]

Кто что скажет конструктивного?

Если верно распарсил ваш поток мысли - самое простейшее прокси решит 99.99% ваших хотелок.

Что такое "шлюзы ТЛГ и ВА" ?

[ALiEN]

DEL

[lnx]

заботящиеся о повышении уровня компьютерной грамотности козлики таки угробили связь между братскими народами в разных "государствах". Вот как по их мнению родители и дети волею судьбы из разных государств теперь должны коммуницировать?
Первым делом пришлось вычислить их адреса навсегда забанить в доступах к моими серверам. И уже после этого поднимать демонов. Synapse. Вцелом ставится легко, nginx прописывается штатно, ключики делаются, однако при старте вываливаются ошибки, явно недоработки создателя пакета, ибо падает из-за неудовлетворенных зависимостей -

/usr/lib/python3.13/site-packages/synapse/config/_base.py:49: UserWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html. The pkg_resources package is slated for removal as early as 2025-11-30. Refrain from using this package or pin to Setuptools<81.
  import pkg_resources

Error in configuration:

vi /usr/lib/python3.13/site-packages/synapse/config/_base.py

import (
  33     Any,
  34     ClassVar,
  35     Dict,
  36     Iterable,
  37     Iterator,
  38     List,
  39     MutableMapping,
  40     Optional,
  41     Tuple,
  42     Type,
  43     TypeVar,
  44     Union,
  45 )
  45 )
  46 
  47 import attr
  48 import jinja2
  49 import pkg_resources
  50 import yaml
  
  
pacman -Ss setuptools
extra/python-calver 2025.03.31-1
    Setuptools extension for CalVer package versions
extra/python-click-plugins 1.1.1-12
    An extension module for click to enable registering CLI commands via setuptools entry-points.
extra/python-cmake-build-extension 0.6.1-2
    Setuptools extension to build and package CMake projects
extra/python-flit-scm 1.7.0-6
    A PEP 518 backend using setuptools_scm to generate a version file, then flit to build
extra/python-setuptools 1:80.9.0-1 (python-build-backend) [installed]
    Easily download, build, install, upgrade, and uninstall Python packages

Что не так? import pkg_resources вроде как требует python-setuptools, который имеется.

[lnx]

Если верно распарсил ваш поток мысли - самое простейшее прокси решит 99.99% ваших хотелок.

вот и попробуйте пожалуйста в современных реалиях потоком своей мысли конструктивно пробулькать свой голос через прокси и настройку прокси телеграмма. С интересом послушаю о результатах.

[ALiEN]

пробулькать свой голос через прокси и настройку прокси телеграмма.

УМВР

[lnx]

картинками и я богат, но также и опытом использования. И за эти дни начитался об аналогичных булькающих результатах.

ТЛГ халтурщики и часть трафика гонят не через прокси, игнорируя его же собственные галки про прокси. И он дропается.

Все простые способы, включая задание всевозможных прокси, поиск альтернативных звонилок, уже списаны в утиль. Обезьяны с гранатами не так опасны, как козлы. https://ntc.party/t/%D0%B1%D0%BB%D0%BE% ... /18333/100

[ALiEN]

https://gost.run/en/

[lnx]

та ошибка преодолена. Как водится, наиболее грамотная инструкция на https://wiki.archlinux.org/title/Matrix + https://element-hq.github.io/synapse/la ... -known-uri. Вот всегда бы она еще была доступная из сетей РФ. Демон без проблем создается и запускается (не чета множеству инструкций по запуску, которые не срабатывали)

[lnx]

Инструкция Вики требует дополнения. Текущее состояние - чаты работают, звонки стартуют и обрываются. Но я еще не занимался TURN. Тема дополняется.

[lnx]

Сегодня весь день бился за голосовые звонки и безуспешно.
Есть демон synapse, он запущен, работает штатно, клиенты к нему нормально подлючаются и все хорошо. В его настройках есть раздел для прописки turn сервера, во всех инструкциях раздел выглядит одинаково -

turn_uris: [ "turn:t.www.ru?transport=udp", "turn:t.www.ru?transport=tcp" ]
turn_shared_secret: "7парольaooYChx2VN"
turn_user_lifetime: 86400000
turn_allow_guests: True

Отлично. Делаем запись ДНС на t.www.ru. По логике matrix при инициализации звонка сообщает клиенту эти данные и клиент стучится на это доменное имя на порт 3478 (покамест по смолчанию). Роутеру предписано этот порт передавать на сервер. 198.168.1.1. Что удивляет - во времена обслуживания мною видеоконференций фронтирующий nginx было фронтом и для того турна. Здесь во всех инструкциях настаивают - без nginx. Хорошо. Настройки демона turnsever простые, из https://element-hq.github.io/synapse/la ... oturn.html, а именно -

use-auth-secret
static-auth-secret=7zj9NpCzпарольoYChx2VN
realm=t.www.ru

listening-port=3478

min-port=50000
max-port=51000

no-tcp-relay

external-ip=внешнийIP
listening-ip=127.0.0.1
allowed-peer-ip=192.168.1.1
allowed-peer-ip=127.0.0.1
allowed-peer-ip=192.168.1.21
#шифрование потока -
no-tls
no-dtls

Служба нормально запускается, работает, о себе пишет штатно -

0: (263688): INFO: pid file created: /var/tmp/turnserver.pid
0: (263688): INFO: IO method: epoll (with changelist)
0: (263688): INFO: RFC5780 disabled! /NAT behavior discovery/
0: (263688): INFO: Wait for relay ports initialization...
0: (263688): INFO:   relay 127.0.0.1 initialization...
0: (263688): INFO:   relay 127.0.0.1 initialization done
0: (263688): INFO: Relay ports initialization done
0: (263690): DEBUG: turn server id=0 created
0: (263688): INFO: Total General servers: 4
0: (263690): INFO: IPv4. TCP listener opened on : 127.0.0.1:3478
0: (263693): DEBUG: turn server id=3 created
0: (263693): INFO: IPv4. TCP listener opened on : 127.0.0.1:3478
0: (263691): DEBUG: turn server id=1 created
0: (263691): INFO: IPv4. TCP listener opened on : 127.0.0.1:3478
0: (263692): DEBUG: turn server id=2 created
0: (263692): INFO: IPv4. TCP listener opened on : 127.0.0.1:3478
0: (263688): INFO: IPv4. UDP listener opened on: 127.0.0.1:3478
0: (263688): INFO: Total auth threads: 3
0: (263688): INFO: turnserver compiled without prometheus support

А при попытке голосового подключения не рабоатет, Element на телефона пишет missing_matrix_RTC_focus, лог turnserver чист, но в логах самого synapse ошибки такие -

2025/08/18 18:19:23 [error] 259310#259310: *5773 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.1, server: x.wwwru, request: "POST /_matrix/client/unstable/org.matrix.simplified_msc3575/sync?pos=5%2Fs138_681_4_198_149_1_79_45_0_1&timeout=30000 HTTP/2.0", upstream: "http://192.168.1.21:8008/_matrix/client/unstable/org.matrix.simplified_msc3575/sync?pos=5%2Fs138_681_4_198_149_1_79_45_0_1&timeout=30000", host: "x.wwwru"
2025/08/18 18:19:50 [error] 259310#259310: *4716 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.1, server: x.wwwru, request: "GET /_matrix/client/v3/sync?set_presence=unavailable&since=s138_702_4_200_149_1_79_45_0_1&timeout=30000 HTTP/2.0", upstream: "http://192.168.1.21:8008/_matrix/client/v3/sync?set_presence=unavailable&since=s138_702_4_200_149_1_79_45_0_1&timeout=30000", host: "x.wwwru"

из чего следует, что сам synapse не соединяется с турном. А может и не с турном - я не понимаю. Но эта же ошибка валится в логах nginx при отправке любого текстового сообщения. Сами сообщения при этом проходят нормально.
Кто может, ткните пожалуйста носом в мои ошибки, в инструкцию по связыванию synapse + coturn

[lnx]

лог turnserver чист, но в логах самого synapse ошибки такие -

Эта ошибка ликвидирована, являлась следствием недоработок инструкций, устранено.
Но голосовой связи нет. Element на телефона пишет missing_matrix_RTC_focus, лог turnserver чист, лог nginx без ошибок, лог synapse тоже без ошибок.

Я в недоумении. Коллеги, какие будут мнения?

[lnx]

Грязно выругался. На разработчиков софта. Телефонный хваленый Element крив. И nheko не без греха - при установке не подтянул зависимости. В консоли при запуске ругается -

 [error] Missing GStreamer elements: webrtcbin qml6glsink 

У меня стоят - gstreamer + gst-plugin-pipewire и даже доставил gst-plugin-webrtchttp, все равно при запуске пишет - Missing GStreamer elements: webrtcbin qml6glsink
Как это дело поправить?

pacman -S gst-plugin-qml6

[lnx]

Это, конечно, прогресс - я увидел изображение и услышал голос. Перкрестно, т.е. не с одного оба, а с одного одно, с другого другое.

десктопный nheko при звонке с телефона на десктоп звонок слышит и при попытке поднятия трубки обрывает -

(nheko:200272): libnice-WARNING **: 00:20:11.213: Agent 0x5595fdb71d30 : We still have alive TURN refreshes. Consider using nice_agent_close_async() to prune them before releasing the agent.
[2025-08-19 00:21:51.496] [ui] [info] WebRTC: setting TURN server: turn://1755637936%3A%40w%3Ax.w.ru:tSwfEtEEoeQUV%2BnQUW0Y9XvhAvk%3D@t.w.spb.ru?transport=udp
[2025-08-19 00:21:51.496] [ui] [info] WebRTC: setting TURN server: turn://1755637936%3A%40w%3Ax.w.ru:tSwfEtEEoeQUV%2BnQUW0Y9XvhAvk%3D@t.w.ru?transport=tcp
[2025-08-19 00:21:51.747] [ui] [error] WebRTC: GstWebRTCICEConnectionState -> Failed

Обратный маршрут аналогично. WebRTC: GstWebRTCICEConnectionState -> Failed

Это через мобильную сеть. А если телефон из той же сетки, то с телефона звонок падате так же, но с nheko звонок телефон принимает изображение от nheko получает, но не получает зук с работающего микрофона. В свою очередь nheko получает хороший звук с микрофона телефона и не получает с его камеры. Впрочем и сам клиент телефона не показывает в окошке работу камеры.
Слишком много версий точек неисправности - телефонный ли клиент, тесктопный ли, сервер ли, или все вместе.

Любые предложения, кроме "убиться об стену", приветствуются.
Телефонный клиент - фарадей, десктопный nheko. Требуется передача аудио и видео. Ищу решения.

[ALiEN]

Требуется передача аудио и видео.

Вместо того, чтобы поднастроить простое прокси на передачу UDP (с банальной передачей 2-3 фейковых пакетов) вы изобретаете какой-то нереальный велосипед. Не говоря уж о том, что домены spb.ru и w.ru вам не принадлежат. Ну а если это попытка поиграть в шпионов - в любом случае это выглядит это очень тупо.

Teams от Microsoft поставьте - вот вам будет передача и аудио и видео.

[lnx]

простое прокси на передачу UDP

потому, что простота бывает хуже воровства. Мне нужно наладить простое решение, которое в серверной части контролировать буду я, а пользователями будут сильно пожилые люди, компетенции которых не идут дальше "скачать из маркета программу и ввести буковки" с последующим нажатием кнопки "позвонить", а плодящиеся в их стране козлы не менее козлиные по сравнению с нашими.

Итак, я продвинулся ощутимо далеко. Главный вопрос сейчас, это логи (разумеется, персонализированную часть доменных имен и тп. я перед публикацией меняю) turnserver, анализ которых позволил "поправить" (преодолеть) неточности хрестоматийных инструкций. Настолько не точные, что даже банальный перечень используемых портов переврали, например слушаемый 5766 ни разу ни где не упоминали, а он постоянно открываемый и в конфигах не прописываемый

Иструкции такие - https://element-hq.github.io/synapse/la ... ation.html + https://element-hq.github.io/synapse/la ... howto.html

Что ломает малину сейчас, так это check_stun_auth: Cannot find credentials of user <1755679515:@домен_matrix>

0: (283971): INFO: OpenSSL compile-time version: OpenSSL 3.5.0 8 Apr 2025 (0x30500000)
0: (283971): INFO: TLS 1.2 supported
0: (283971): INFO: TLS 1.3 supported
0: (283971): INFO: DTLS 1.2 supported
0: (283971): INFO: TURN/STUN ALPN supported
0: (283971): INFO: Third-party authorization (oAuth) supported
0: (283971): INFO: GCM (AEAD) supported
0: (283971): INFO: SQLite supported, default database location is /var/db/turndb
0: (283971): INFO: Redis supported
0: (283971): INFO: PostgreSQL supported
0: (283971): INFO: MySQL supported
0: (283971): INFO: MongoDB is not supported
0: (283971): INFO: Default Net Engine version: 3 (UDP thread per CPU core)
0: (283971): INFO: Domain name: 
0: (283971): INFO: Default realm: домен_турн.ru
0: (283971): INFO: Certificate file found: //turn_server_cert.pem
0: (283971): INFO: Private key file found: //turn_server_pkey.pem
0: (283971): INFO: Relay address to use: 192.168.1.21
0: (283975): INFO: log file opened: /var/log/turnserver/coturn_2025-08-19.log
0: (283975): WARNING: Cannot create pid file: /var/run/turnserver.pid
0: (283975): INFO: pid file created: /var/tmp/turnserver.pid
0: (283975): INFO: IO method: epoll (with changelist)
0: (283975): INFO: RFC5780 disabled! /NAT behavior discovery/
0: (283975): INFO: Wait for relay ports initialization...
0: (283975): INFO:   relay 192.168.1.21 initialization...
0: (283975): INFO:   relay 192.168.1.21 initialization done
0: (283975): INFO: Relay ports initialization done
0: (283977): DEBUG: turn server id=0 created
0: (283977): INFO: IPv4. TCP listener opened on : 192.168.1.21:3478
0: (283979): DEBUG: turn server id=2 created
0: (283975): INFO: Total General servers: 4
0: (283979): INFO: IPv4. TCP listener opened on : 192.168.1.21:3478
0: (283978): DEBUG: turn server id=1 created
0: (283978): INFO: IPv4. TCP listener opened on : 192.168.1.21:3478
0: (283980): DEBUG: turn server id=3 created
0: (283980): INFO: IPv4. TCP listener opened on : 192.168.1.21:3478
0: (283975): INFO: IPv4. UDP listener opened on: 192.168.1.21:3478
0: (283975): INFO: Total auth threads: 3
0: (283984): INFO: IPv4. CLI listener opened on : 127.0.0.1:5766
0: (283975): INFO: turnserver compiled without prometheus support
32: (283979): INFO: IPv4. tcp or tls connected to: 192.168.1.1:55412
32: (283977): INFO: IPv4. tcp or tls connected to: 192.168.1.1:55418
32: (283979): INFO: session 002000000000000001: realm <домен_турн.ru> user <>: incoming packet message processed, error 401: Unauthorized
32: (283979): ERROR: session 002000000000000001: check_stun_auth: Cannot find credentials of user <1755679515:@домен_matrix>
32: (283979): INFO: session 002000000000000001: realm <домен_турн.ru> user <1755679515:@домен_matrix>: incoming packet message processed, error 401: Unauthorized
32: (283977): INFO: session 000000000000000001: realm <домен_турн.ru> user <>: incoming packet message processed, error 401: Unauthorized
32: (283977): ERROR: session 000000000000000001: check_stun_auth: Cannot find credentials of user <1755679515:@домен_matrix>
32: (283977): INFO: session 000000000000000001: realm <домен_турн.ru> user <1755679515:@домен_matrix>: incoming packet message processed, error 401: Unauthorized
32: (283979): INFO: session 002000000000000002: realm <домен_турн.ru> user <>: incoming packet message processed, error 401: Unauthorized
33: (283979): ERROR: session 002000000000000002: check_stun_auth: Cannot find credentials of user <1755679515:@домен_matrix>
33: (283979): INFO: session 002000000000000002: realm <домен_турн.ru> user <1755679515:@домен_matrix>: incoming packet message processed, error 401: Unauthorized
60: (283977): INFO: session 000000000000000001: TCP socket closed remotely 192.168.1.1:55418
60: (283977): INFO: session 000000000000000001: usage: realm=<домен_турн.ru>, username=<1755679515:@домен_matrix>, rp=2, rb=172, sp=2, sb=152
60: (283977): INFO: session 000000000000000001: peer usage: realm=<домен_турн.ru>, username=<1755679515:@домен_matrix>, rp=0, rb=0, sp=0, sb=0
60: (283977): INFO: session 000000000000000001: closed (2nd stage), user <1755679515:@домен_matrix> realm <домен_турн.ru> origin <>, local 192.168.1.21:3478, remote 192.168.1.1:55418, reason: TCP connection closed by client (callback)
60: (283979): INFO: session 002000000000000001: TCP socket closed remotely 192.168.1.1:55412
60: (283979): INFO: session 002000000000000001: usage: realm=<домен_турн.ru>, username=<1755679515:@домен_matrix>, rp=2, rb=172, sp=2, sb=152
60: (283979): INFO: session 002000000000000001: peer usage: realm=<домен_турн.ru>, username=<1755679515:@домен_matrix>, rp=0, rb=0, sp=0, sb=0
60: (283979): INFO: session 002000000000000001: closed (2nd stage), user <1755679515:@домен_matrix> realm <домен_турн.ru> origin <>, local 192.168.1.21:3478, remote 192.168.1.1:55412, reason: TCP connection closed by client (callback)
92: (283979): INFO: session 002000000000000002: usage: realm=<домен_турн.ru>, username=<1755679515:@домен_matrix>, rp=2, rb=172, sp=2, sb=152
92: (283979): INFO: session 002000000000000002: peer usage: realm=<домен_турн.ru>, username=<1755679515:@домен_matrix>, rp=0, rb=0, sp=0, sb=0
92: (283979): INFO: session 002000000000000002: closed (2nd stage), user <1755679515:@домен_matrix> realm <домен_турн.ru> origin <>, local 192.168.1.21:3478, remote 192.168.1.1:57625, reason: allocation watchdog determined stale session state
110: (283979): INFO: IPv4. tcp or tls connected to: 192.168.1.1:54536
110: (283978): INFO: IPv4. tcp or tls connected to: 192.168.1.1:54524
110: (283978): INFO: session 001000000000000001: realm <домен_турн.ru> user <>: incoming packet message processed, error 401: Unauthorized
110: (283978): ERROR: session 001000000000000001: check_stun_auth: Cannot find credentials of user <1755679515:@домен_matrix>
110: (283978): INFO: session 001000000000000001: realm <домен_турн.ru> user <1755679515:@домен_matrix>: incoming packet message processed, error 401: Unauthorized
110: (283979): INFO: session 002000000000000005: realm <домен_турн.ru> user <>: incoming packet message processed, error 401: Unauthorized
110: (283979): ERROR: session 002000000000000005: check_stun_auth: Cannot find credentials of user <1755679515:@домен_matrix>
110: (283979): INFO: session 002000000000000005: realm <домен_турн.ru> user <1755679515:@домен_matrix>: incoming packet message processed, error 401: Unauthorized
110: (283978): INFO: session 001000000000000002: realm <домен_турн.ru> user <>: incoming packet message processed, error 401: Unauthorized
110: (283978): ERROR: session 001000000000000002: check_stun_auth: Cannot find credentials of user <1755679515:@домен_matrix>
110: (283978): INFO: session 001000000000000002: realm <домен_турн.ru> user <1755679515:@домен_matrix>: incoming packet message processed, error 401: Unauthorized
112: (283979): INFO: session 002000000000000003: usage: realm=<домен_турн.ru>, username=<>, rp=1, rb=20, sp=1, sb=32
112: (283979): INFO: session 002000000000000003: peer usage: realm=<домен_турн.ru>, username=<>, rp=0, rb=0, sp=0, sb=0
112: (283979): INFO: session 002000000000000003: closed (2nd stage), user <> realm <домен_турн.ru> origin <>, local 192.168.1.21:3478, remote 188.170.85.243:19852, reason: allocation watchdog determined stale session state
117: (283979): INFO: session 002000000000000005: TCP socket closed remotely 192.168.1.1:54536
117: (283979): INFO: session 002000000000000005: usage: realm=<домен_турн.ru>, username=<1755679515:@домен_matrix>, rp=2, rb=172, sp=2, sb=152
117: (283978): INFO: session 001000000000000001: TCP socket closed remotely 192.168.1.1:54524
117: (283978): INFO: session 001000000000000001: usage: realm=<домен_турн.ru>, username=<1755679515:@домен_matrix>, rp=2, rb=172, sp=2, sb=152
117: (283979): INFO: session 002000000000000005: peer usage: realm=<домен_турн.ru>, username=<1755679515:@домен_matrix>, rp=0, rb=0, sp=0, sb=0
117: (283978): INFO: session 001000000000000001: peer usage: realm=<домен_турн.ru>, username=<1755679515:@домен_matrix>, rp=0, rb=0, sp=0, sb=0
117: (283979): INFO: session 002000000000000005: closed (2nd stage), user <1755679515:@домен_matrix> realm <домен_турн.ru> origin <>, local 192.168.1.21:3478, remote 192.168.1.1:54536, reason: TCP connection closed by client (callback)
117: (283978): INFO: session 001000000000000001: closed (2nd stage), user <1755679515:@домен_matrix> realm <домен_турн.ru> origin <>, local 192.168.1.21:3478, remote 192.168.1.1:54524, reason: TCP connection closed by client (callback)

Обращение к turnsever задается в конфиге synapse, разные комбинации дают одинаковый результат -

turn_uris: [ "turn:доментурн?transport=udp", "turn:доментурн?transport=tcp" ]

#версия 1 -
turn_username: юзер
turn_password: пароль

#версия 2
#turn_shared_secret: "пароль"

Принимающая сторона также в двух врсиях -

use-auth-secret
static-auth-secret=пароль

cli-password=другойпарольдлятелнета
#lt-cred-mech
#user=юзер:пароль

Результат - как у того жирафа. Сдается мне, что следует по-стариковски кохозить со строкой -

turn_uris: "turn:доментурн" 

забахав в нее фиксированный логин-пароль. Но как именно это сделать? Вопрос не праздный и не только у меня, с загадочностью документации в части формата (Господи, ну когда же программисты научатся однозначно выражать свои мысли!) сталкивался не только я, вот пример дискуссии - https://groups.google.com/g/turn-server ... L6zOO096eg
наши люди, кстати.

[lnx]

По логике если мы на стороне турнсервера задаем авторизацию по секрету -

use-auth-secret
static-auth-secret=секрет

а на стороне клиента указываем этот секрет -

turn_shared_secret: "секрет"
и адрес турна -
turn_uris: "turn:турндомен" 

не должно возникать ситуации

INFO: session 000000000000000001: realm <турндомен> user <1755679515:@матриксюзре:матрикдомен>: incoming packet message processed, error 401: Unauthorized

А она возникает. Нагуглить по теме "обращение к turn с указанием логина и пароля в строке" ничего не удается - выдает что угодно, но не нужное.

Пошел смотреть параметры запуска службы https://github.com/coturn/coturn/wiki/turnserver, добавил ключи запуска -
--use-auth-secret
-a
ничего н еменяется, что и понятно - конфиг-то с этими параметрами при старте считывается...

НИгде не говорилось, но вдруг turn_shared_secret: должен содержать не сам пароль, а какой-нибудь от него производный хэш или там соль? Примерно так и есть -https://github.com/coturn/coturn/wiki/t ... n-rest-api

[lnx]

обратил внимание, что в логах писалось check_stun_auth: Cannot find credentials of user.
ОДнако turn и stun разные штуки. И в конфиге явно указывлаось no-stun

Продублировал в конфиге параметры -

turn_uris: "turn:домен_turn"
stun_uris: "stun:домен_turn"

turn_shared_secret: "parol"
stun_shared_secret: "parol"

ничего не изменилось.

[lnx]

Внезапное прозрение-гипотеза. Ну помимо отшелушивания по прочтениям разного + анализ экспериментов и логов turm показал следующее -
1. врут про то, что turnserver должен "работать напрямую" - я же помню, что раньше делал его через nginx и это работает. Правда гадский вебртц потом после старта портами светит и щвыряется как хочет
2. какие бы комбинации звонков я не делал (телефон мобильная сеть или вайфай и кто кому звонит) во всех случаях в логах турна был только @юзер1:матриксдомен, второй участник @юзер2 ни разу в логах турна не появлялся. В логах матрикса (сообщения и пр) - сколько угодно. В каждом сеансе обязательно есть INFO: session 002000000000000001: realm <турндомен> user <>: incoming packet message processed, error 401: Unauthorized.

Поскольку каждый клиент стучится к турну с конфигом от демона матрикса и жалобы только на одного, следует вывод, что косяк на стороне мобильного клиента, коих не много, Element отказывается работать со звонками (у меня же еще и прошивка Цианоген), но работает Faraday. А на лэптопе nheko

Буду признателен за тыки в клиентов. Чтобы звонить.

[lnx]

Мне, конечно, и раньше доводилось быть удивленным разнице между жизнью и инструкциями и документациями по конфигам, но настолько - впервые.
Абсоютно все инструкции предписывают в конфиге sysnapse явно указывать адрес turnserver строкой вида turn_uris: ["turns:чушьсобачьяпроизвольная"]. Т.е. предлагают-то записывать "домен демона".
Задаваясь вопросом ну как так нет авторизации взял и сделал опечатку в домене - а оно работает. Вторую - работает. Закомментил вообще весь раздел в конфиге synapse, включая ключ и пр. - работает, с турном соединяется. Т.е. этот раздел конфига не используется вовсе и он внаглую на ip демона матрикса стучится по стандартному порту!!!!
Но ведь вот инструкция - https://matrix-org.github.io/synapse/la ... howto.html, она требует указания! Теряю дар речи.

И что с этим делать и как с этим жить? зачем тогда вообще отдельное доменное имя для turn?

Скажу больше. Он, coturn, и на собственные настройки чихает - вот указыва ему хрень в доменных именах -
realm=wx.hren.ru
server-name=wx.hren.ru

завожу телефон в мобильную сеть и звоню - в логах вижу соединение с турном! и там же в логах пишет эту хрень!
INFO: session 000000000000000001: new, realm=<wx.hren.ru>, username=<1755721668:@v:доменru>, lifetime=600