Почему через LiveKit не работают аудио- или видеозвонки?

Всем привет. Пытаюсь перейти на стек с LiveKit для звонков в Element X — следовал статье <a href="https://habr.com/ru/articles/1028012/" rel="nofollow">https://habr.com/ru/articles/1028012/</a>, но звонки не работают. В логах контейнера livekit-jwt вижу следующее:
  • 25 мая 2026 г. 15:00
Ответы на вопрос 3
Коротко — причин может быть много. Ниже собрал список самых типичных проблем с LiveKit + набор действий для быстрой диагностики. Выполните проверку и пришлите (сюда) логи livekit-server и livekit-jwt + вывод из консоли браузера (WebRTC/Network), тогда помогу точнее.

Что проверить первым делом
1. Совпадают ли apiKey/apiSecret
   - JWT, который генерирует контейнер livekit-jwt, должен быть подписан тем же apiKey/apiSecret, что в конфиге самого livekit-server. Несовпадение даёт "unauthorized" и подключение не проходит.

2. Логи серверов
   - Посмотрите логи livekit-server и livekit-jwt (docker logs ...). В логах livekit-server обычно видно, если токен неправильный, если ICE/DTLS не проходит или проблемы с TURN. Пришлите эти строки.

3. Браузер: разрешения и консоль
   - Откройте DevTools → Console и Network → WebSocket, а также chrome://webrtc-internals (или аналог в Firefox). Какие ошибки по getUserMedia (permission denied), ICE (ICE failed), DTLS, или "connection failed"? Присылайте строчки ошибок.

4. HTTPS / wss / secure context
   - WebRTC getUserMedia и secure origin: если страница не в https (и не localhost), браузер может блокировать доступ к микрофону/камере и/или блокировать wss. Убедитесь, что Element X подключается по wss/https если нужно.

5. ICE / STUN / TURN / NAT
   - Частая причина: сервер отдает кандидаты, которые недоступны извне (NAT), а TURN не настроен — в результате ICE не сходится (ICE failed). Проверьте конфигурацию public/external IP в livekit-server config и наличие доступного TURN (coturn или встроенный relay).
   - Если вы тестируете в закрытой сети/Docker, убедитесь, что UDP-порты для RTP/RTCP открыты/проброшены или настроен TCP/TURN.

6. Проверка токена
   - Декодируйте JWT (jwt.io) — проверьте claims: identity, room, ttl/grants. Убедитесь, что в токене есть права на join/room и что срок действия валиден.

7. Проверка самого живого сервера (health/admin)
   - Попробуйте выполнить health-check / admin запросы к livekit-server (если enabled) — это подтвердит, что сервер работает и доступен.

8. Тест с официальным демо-клиентом
   - Попробуйте подключиться к вашему livekit-server с официального примера/демо-клиента LiveKit (или sample web client). Это помогает изолировать проблему — на стороне Element X или на стороне LiveKit.

Типичные сообщения в логах и что они значат
- "unauthorized" или "invalid token" — ключ/секрет не совпадают или токен malformed.
- "ICE failed" или "no compatible candidates" — проблемы с STUN/TURN/NAT.
- "DTLS handshake failed" — сертификаты/TLS или несовместимые DTLS параметры.
- "no local tracks" — браузер не дал доступ к mic/camera или их не публикуют.

Конкретные команды/действия которые сделают диагностику проще
- docker logs <livekit-server-container> — посмотреть ошибки.
- docker logs <livekit-jwt-container> — посмотреть, как генерируется токен.
- В браузере: открыть DevTools → Console и Network(WebSocket) → сделать скрин/копию ошибок.
- Декодировать JWT (полученный из livekit-jwt) на jwt.io — посмотреть payload.
- Попробовать подключиться demo-client’ом к вашему URL (включая wss/https).

Что пришлите мне для более точной помощи
- Выдержки из логов livekit-server и livekit-jwt (ошибки вокруг времени попытки звонка).
- JWT (можно только payload, без private secret) или строка токена.
- Скрин/копию ошибок из консоли браузера (webrtc-internals, console).
- Конфигурация livekit-server (фрагмент с apiKey/apiSecret, public/external_ip/turn config — если не хотите выкладывать секрет, скрывайте секрет, но покажите ключи и поля).

Если хотите, могу написать короткий тестовый Node/Python-скрипт для генерации токена (чтобы проверить, что токен валиден) или подсказать, как включить/сконфигурировать TURN в docker-compose.
похоже, <code>livekit-jwt</code> из bridge-сети пытается достучаться до <code>matrix.mydomain.com:8448</code> через внешний IP хоста — это hairpin NAT, из контейнера не работает. <br/> <br/> Попробуй добавить в <code>livekit-jwt</code> в docker-compose: <br/> <br/> <pre><code>extra_hosts:
  - "matrix.mydomain.com:host-gateway"</code></pre> <br/> <br/> <code>host-gateway</code> резолвится в IP Docker-хоста изнутри контейнера, и nginx на 8448 станет доступен.
Настройка обратного прокси <br/> Судя по ошибке, livekit-jwt не может достучаться до вашего сервера. Общая сетевая архитектура должна обеспечивать доступ livekit-jwt к тому же API, к которому обращаются ваши клиенты. <br/> Проверка доступности через curl <br/> После настройки прокси выполните несколько тестов с вашего сервера, чтобы убедиться, что все работает изнутри. <br/> <br/> Проверьте файл конфигурации для клиентов: curl <a href="https://matrix.mydomain.com/.well-known/matrix/client" rel="nofollow">https://matrix.mydomain.com/.well-known/matrix/client</a> <br/> Он должен содержать блок org.matrix.msc4143.rtc_foci. Ваш URL сервиса JWT указан в livekit_jwt_sso_url в homeserver.yaml. Убедитесь, что он публично доступен. <br/> <br/> Проверьте файл конфигурации для серверов (федерации): curl <a href="https://matrix.mydomain.com/.well-known/matrix/server" rel="nofollow">https://matrix.mydomain.com/.well-known/matrix/server</a> <br/> Он должен вернуть {"m.server": "matrix.mydomain.com:443"}. <br/> Проверьте федеративное API: curl <a href="https://matrix.mydomain.com/_matrix/key/v2/server" rel="nofollow">https://matrix.mydomain.com/_matrix/key/v2/server</a> <br/> Этот запрос должен вернуть валидный JSON с ключами сервера. <br/> Проверьте конечную точку JWT-сервиса: curl <a href="https://matrix.mydomain.com/livekit/jwt/token" rel="nofollow">https://matrix.mydomain.com/livekit/jwt/token</a> <br/> Этот запрос должен вернуть ошибку {"error":"Not implemented"}, что означает, что сервис работает и готов принимать запросы. <br/> Проверьте и исправьте livekit_jwt_sso_url <br/> В вашем файле homeserver.yaml указан параметр: livekit_jwt_sso_url: " <a href="https://matrix.mydomain.com/livekit/jwt/token" rel="nofollow">https://matrix.mydomain.com/livekit/jwt/token</a> " <br/> Путь /livekit/jwt/token является конечной точкой вашего livekit-jwt. Убедитесь, что ваш обратный прокси (Nginx/Caddy) проксирует все запросы на /livekit/jwt/ на ваш сервис livekit-jwt, а не на Synapse. <br/> Настройка переменных окружения для livekit-jwt (если прокси не помог) <br/> Если после настройки прокси ошибка сохраняется, попробуйте явно указать сервису, как находить ваш хомесервер. В секции environment вашего docker-compose.yml для сервиса livekit-jwt добавьте: <br/> environment: - LIVEKIT_FULL_ACCESS_HOMESERVERS=matrix.mydomain.com <br/> <br/> Убедитесь, что в homeserver.yaml опция allow_federation установлена в true. Федерация должна быть включена, даже если у вас частный сервер. <br/> <br/> allow_federation: true <br/> <br/> Не знаю на сколько поможет но вот
Похожие вопросы