Центральная платформа Voxport и hybrid self-hosted

Voxport — hybrid self-hosted платформа: голос и видео идут через Jitsi на VPS владельца, а центральная платформа Voxport координирует аккаунты, комнаты, звонки и клиентские подключения.

Это не «облако вместо self-hosted». Медиапотоки остаются на инфраструктуре владельца сервера. Центральный сервер решает задачи, которые нельзя переложить на Jitsi-инстанс.

Подробнее про Jitsi и self-hosted: Self-hosted сервер связи на open source Jitsi · Создание сервера

Две части системы

Часть	Роль	Где работает
Платформа Voxport	Аккаунты, серверы, комнаты, presence, WebSocket, push, JWT для Jitsi	voxport.net
Сервер связи (Jitsi)	Голос, видео, screen sharing через WebRTC	VPS владельца

Клиент подключается к обеим частям: платформа говорит «кто в какой комнате и с какими правами», Jitsi передаёт аудио и видео.

Зачем нужен центральный сервер

Координация в реальном времени

Self-hosted Jitsi умеет передавать медиа, но не ведёт:

• аккаунты и авторизацию
• список серверов и комнат
• presence (кто онлайн, в какой комнате)
• входящие звонки и их маршрутизацию
• push-уведомления
• выдачу JWT для подключения к Jitsi

Всё это — задачи управляющей платформы. Без неё клиенты не могут найти друг друга и установить звонок, даже если Jitsi работает.

Клиент подключается к платформе по WebSocket (напрямую или через voxman-прокси). Это не VPS владельца и не Jitsi — отдельный управляющий канал.

Что идёт через платформу, а что — через Jitsi

	Платформа Voxport	Jitsi на VPS
Голос и видео	❌	✅
Screen sharing	❌	✅
Логин, аккаунт	✅	❌
Комнаты, роли, инвайты	✅	❌
Presence, WebSocket	✅	❌
Push (входящий звонок)	✅	❌
JWT для Jitsi	✅ (выдаёт)	✅ (проверяет)
Метаданные звонков	✅	❌

Voxport не хранит и не маршрутизирует содержание разговоров. Аудио и видео идут напрямую через Jitsi Videobridge на VPS владельца.

API Gateway через voxman-ноду

Для серверов, развёрнутых через voxman, на VPS поднимается nginx, который проксирует запросы к платформе:

• /api/ → центральный API Voxport
• /ws → WebSocket платформы

Зачем это сделано — доступность

Главная цель API Gateway — повысить доступность платформы для участников сервера.

Пользователь получает набор прокси — это voxman-ноды серверов, в которых он состоит. Клиент не привязан к одному адресу voxport.net:

1. собирает список voxman-серверов, где пользователь — участник
2. проверяет доступность каждого домена
3. выбирает первый рабочий прокси
4. при сбое переключается на следующий или на voxport.net напрямую

На практике прокси часто оказываются ближе к пользователю по сети: админы берут VPS под свою аудиторию (регион, провайдер), а участники состоят именно в этих серверах. Запрос к платформе идёт через знакомый маршрут — через VPS комьюнити, а не только через центральный домен.

Это помогает, когда:

• прямой путь до voxport.net недоступен или нестабилен (блокировки, маршрутизация, DNS)
• один прокси-сервер лежит — клиент переключается на другой
• нужен запасной маршрут к той же платформе

Важно: прокси не заменяют платформу — они только перенаправляют запросы к ней. Прокси решают проблему сетевого маршрута до платформы, а не замену самой платформы.

Важно

• API Gateway работает только для voxman-нод — серверов с managedByVoxman и статусом ready
• Через прокси идут API и WebSocket, не медиа
• Ручной self-hosted без voxman подключается к платформе напрямую

Как клиент зависит от платформы

Ниже — не сценарий, который мы закладываем в продукт, а пояснение архитектуры: что делает центральный бэкенд и почему клиент обращается к нему постоянно. Отказ центрального бэкенда не входит в наши планы — платформа должна работать стабильно.

Для понимания hybrid-модели полезно разделить две части системы:

Центральный бэкенд нужен клиенту для:

• входа в аккаунт
• синхронизации серверов и комнат
• новых звонков, push и WebSocket (presence, события)

Jitsi на VPS — для голоса и видео внутри уже установленного звонка.

Гипотетически, если платформа недоступна, клиент не сможет войти, синхронизировать данные или начать новый звонок. Уже идущий Jitsi-звонок при этом может продолжиться, пока жив VPS с Jitsi — для медиа платформа не нужна.

Это описание структуры работы приложения, а не ожидаемый режим. API Gateway решает другую задачу — доступность маршрута до работающей платформы, когда прямой путь до voxport.net недоступен.

Hybrid vs fully self-hosted

	Voxport (hybrid)	Fully self-hosted (гипотетически)
Медиа	Jitsi на VPS владельца	Свой медиасервер
Аккаунты, комнаты	Центральная платформа	Нужна своя реализация
Клиенты Voxport	Да	Нет (нужен свой клиент)

Voxport — это клиент + платформа + self-hosted Jitsi. Убрать центральный сервер означает переписать всё, что платформа делает сегодня: аккаунты, комнаты, сигнализацию, push.

Ключевые факты

• Hybrid self-hosted: медиа на VPS владельца, координация на платформе Voxport
• Jitsi: open source, Apache 2.0, официальные Docker-образы
• Центральный сервер: аккаунты, комнаты, WebSocket, push, JWT — не медиа
• API Gateway: voxman-нода проксирует /api/ и /ws — повышает доступность маршрута до платформы
• Архитектура: координация — платформа, медиа — Jitsi на VPS владельца