Содержание
Введение
Пользователь при попытке вызова получает ошибку «При создании звонка произошла ошибка 500, Conference creation failed: Something went wrong».
Р7 Команды развернут на двух серверах (Сервер Управления и Медиа сервер). Медиа сервер имеет белый статический IP адрес и расположен непосредственно в сети интернет. На медиа сервере настроен межсетевой экран — UFW.
Методы первичной диагностики
Чтобы понять, где именно происходит сбой, необходимо проверить логи на обоих серверах.
1. Проверка логов на сервере управления Р7-Команда
Первым делом проверьте логи сервиса callchat на вашем сервере Р7-Команда.
docker logs team-callchat-1
docker logs team-callchat-2
docker logs team-callchat-3
docker logs team-callchat-4
(Примечание: имя контейнера может отличаться в зависимости от вашей установки)
ERROR POST /api/v2/conference 10.62.88.253| {"type":"InternalError","message":"CALL Unable to create conference on media server (status=500 message=Internal Server Error)","stack":"InternalError: CALL Unable to create conference on media server (status=500 message=Internal Server Error)\n at CallService.create (/app/src/service/call/CallService.js:198:15)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async /app/src/WebAPI/v2/Controllers/Conference/ConferenceController.js:36:20","name":"InternalError","errCode":4000313,"meta":{"param":{"userCallerId":"489","targetId":"222"}}}
Если вы видите ошибку `Unable to create conference on media server (status=500)`, это означает, что сервер Р7-Команда успешно отправил запрос на создание конференции, но Медиасервер ответил ему ошибкой 500 (Internal Server Error)
log ERROR POST /api/v2/conference 10.62.88.253| {"type":"InternalError","message":"CALL Unable to create conference on media server (status=500 message=Internal Server Error)","stack":"..."}Эта ошибка говорит, что проблема находится на стороне Медиасервера.
2. Проверка логов на Медиасервере
Проблема локализована, переходим на сервер, где установлен Медиасервер.
Проверка логов nginx:
Контейнер nginx является входной точкой для всех запросов. Проверим его логи:
docker logs media_nginx
Здесь вы, скорее всего, обнаружите ошибку Connection refused (соединение отклонено). Это означает, что nginx получил запрос от Р7-Команды, попытался передать его внутреннему сервису в контейнер media_media, но тот отклонил соединение.
2025/10/06 12:51:57 [error] 7#7: *9 connect() failed (111: Connection refused), client: 109.235.210.188... 2025/10/06 12:51:57 [error] 7#7: *9 [lua] create_conference.lua:58: Can't create conference: connection refused...
Проверка логов media_media:
Теперь посмотрим, почему сервис в контейнере media_media отклоняет соединения.
docker logs media_media
В логах видим причину — сам сервис не может запуститься до конца, потому что не может подключиться к другому внутреннему компоненту, XCoder.
2025-10-06 11:54:32.045 W [------------] XCoder still doesn't respond after restarting, keep trying connecting com.zeroc.Ice.ConnectTimeoutException: null
Итог диагностики:
- Р7-Команда отправляет запрос на Медиасервер.
- nginx на Медиасервере получает запрос, но не может передать его media_media (Connection refused).
- media_media не отвечает, потому что сам не может подключиться к xcoder (ConnectTimeoutException).
- В итоге nginx возвращает ошибку 500 на сервер Р7-Команда.
3. Описание проблемы
Вся проблема сводится к нарушению сетевого взаимодействия между контейнерами на Медиасервере.
Причина проблемы: Конфликт Docker и брандмауэра UFW
В стандартном файле docker-compose.yaml для Медиасервера используется «смешанный» сетевой режим:
- Большинство сервисов (media_media, redis и др.) работают в изолированной виртуальной сети Docker.
- Сервис xcoder настроен с параметром network_mode: host, то есть использует основную сеть сервера напрямую.
- Сервис media пытается связаться с ним через адрес host-gateway, который указывает на IP-адрес сервера изнутри контейнера.
Проблема возникает, когда системный брандмауэр ufw на сервере блокирует пересылку трафика (FORWARD) из виртуальной сети Docker в основную сеть хоста.
4. Рекомендуемое решение
Сначала нужно узнать, какие подсети используют ваши контейнеры. Выполните следующие команды:
docker network inspect media_internal | grep Subnet docker network inspect media_external | grep Subnet
Вывод будет выглядеть примерно так:
"Subnet": "172.19.0.0/16" "Subnet": "172.18.0.0/16"``` Запомните или скопируйте эти значения. В данном примере это `172.19.0.0/16` и `172.18.0.0/16`.
Убедитесь, что служба UFW запущена
Перед добавлением правил брандмауэр должен быть активен. Если вы его отключали для теста, запустите его:
sudo systemctl start ufw
Добавьте разрешающие правила для сетей Docker
sudo ufw allow from 172.19.0.0/16 sudo ufw allow from 172.18.0.0/16
Убедитесь, что все правила на месте и брандмауэр активен:
sudo ufw status verbose В списке должны присутствовать строки вида `ALLOW IN 172.19.0.0/16`. To Action From -- ------ ---- 443/tcp ALLOW Anywhere 10000:10049/tcp ALLOW Anywhere 10000:30000/udp ALLOW Anywhere 22/tcp ALLOW Anywhere 443/tcp (v6) ALLOW Anywhere (v6) 10000:10049/tcp (v6) ALLOW Anywhere (v6) 10000:30000/udp (v6) ALLOW Anywhere (v6) 22/tcp (v6) ALLOW Anywhere (v6) Anywhere ALLOW IN 172.19.0.0/16 # <-- НОВОЕ ПРАВИЛО Anywhere ALLOW IN 172.18.0.0/16 # <-- НОВОЕ ПРАВИЛО