
В свете сами знаете чего, свой приватный мессенджер и возможность звонков на XMPP стали как никогда актуальны.
Есть быстрый и простой способ: за несколько минут вы поднимаете собственный Jabber-сервер. Дальше — дело техники: рассылаете приглашения маме, бабушке, теще, жене и соседке Даше. После этого можно спокойно звонить и переписываться в защищённом мессенджере, который полностью под вашим контролем.
Звонки идут в зашифрованном режиме, работают p2p. А если у собеседника хитрый NAT, то на помощь автоматически приходит встроенный STUN-сервер.
Клиенты есть под все платформы: Android, iOS, Windows, macOS и Linux.
Что понадобится?
VDS / VPS с белым IP
Домен
Пошаговая настройка
-
Установка docker и Docker Compose версии 2
Если уже установлен, то пропускайте этот шаг. Для Ubuntu / Debian
sudo apt update sudo apt install -y docker.io docker-compose-plugin sudo systemctl enable --now docker
Для RHEL / Rocky Linux / AlmaLinux
sudo dnf -y install dnf-plugins-core sudo dnf config-manager --add-repo https://download.docker.com/linux/fedora/docker-ce.repo sudo dnf -y install docker-ce docker-ce-cli containerd.io docker-compose-plugin sudo systemctl enable --now docker
Можно запустить и на старых дистрибутивах — всё будет работать. Но на этом останавливаться не будем. Скрипты требуют Docker Compose версии 2 и несовместимы с устаревшим docker-compose v1.
-
Прописываем DNS
A chat.your-domain.com → <белый IP VDS/VPS> CNAME groups.chat.your-domain.com → chat.your-domain.com CNAME share.chat.your-domain.com → chat.your-domain.com
Создаем одну A-запись и две CNAME
-
Открываем порты
Ubuntu / Debian
# Веб/ACME sudo ufw allow 80/tcp sudo ufw allow 443/tcp # XMPP sudo ufw allow 5222/tcp # c2s sudo ufw allow 5269/tcp # s2s (федерация, опционально) # STUN/TURN (основные и альтернативные порты) sudo ufw allow 3478/tcp sudo ufw allow 3478/udp sudo ufw allow 3479/tcp sudo ufw allow 3479/udp sudo ufw allow 5349/tcp # TLS sudo ufw allow 5349/udp sudo ufw allow 5350/tcp sudo ufw allow 5350/udp # RTP-реле TURN (медиа) sudo ufw allow 49152:65535/udp # (Опционально) proxy65 для file-transfer sudo ufw allow 5000/tcp
RHEL / Rocky Linux / AlmaLinux
# Веб/ACME sudo firewall-cmd --permanent --add-port=80/tcp sudo firewall-cmd --permanent --add-port=443/tcp # XMPP sudo firewall-cmd --permanent --add-port=5222/tcp sudo firewall-cmd --permanent --add-port=5269/tcp # STUN/TURN sudo firewall-cmd --permanent --add-port=3478/tcp sudo firewall-cmd --permanent --add-port=3478/udp sudo firewall-cmd --permanent --add-port=3479/tcp sudo firewall-cmd --permanent --add-port=3479/udp sudo firewall-cmd --permanent --add-port=5349/tcp sudo firewall-cmd --permanent --add-port=5349/udp sudo firewall-cmd --permanent --add-port=5350/tcp sudo firewall-cmd --permanent --add-port=5350/udp # RTP-реле TURN (медиа) sudo firewall-cmd --permanent --add-port=49152-65535/udp # (Опционально) proxy65 sudo firewall-cmd --permanent --add-port=5000/tcp sudo firewall-cmd --reload
-
Ставим snikket
cd /opt git clone https://github.com/snikket-im/snikket-selfhosted.git snikket cd snikket ./scripts/init.sh
После запуска
./scripts/init.sh
вас спросят имя вашего домена и email, после этого запускаем:./scripts/start.sh
Если все прошло ок, то https://<your domain>/ уже будет форма для ввода логина и пароля.
Теперь осталось сформировать и послать самому себе админский инвайт:
./scripts/new-invite.sh --admin --group default
-
Админка и инвайты для юзеров
После того как вы создали админский инвайт и прошли регистрацию, можно зайти на сайт
https://<ваш-домен>/
— и вы попадёте в админ-зону:Скриншот Из админ-зоны можно сразу отправить первое приглашение. Как только человек его примет и установит приложение — можно звонить и переписываться.
На этом всё!
Технические подробности
Если кому-то интересно, то давайте посмотрим, что мы получили из коробки:
Сервер XMPP (Jabber) — личный мессенджер без рекламы и слежки.
Поддержка федерации — общение с пользователями на других серверах XMPP.
Группы и чаты — приватные и публичные комнаты.
Файлы и мультимедиа — отправка фото, документов
Звонки — встроенный STUN/TURN для аудио- и видеосвязи (WebRTC).
Сквозное шифрование и автономность аккаунта — сквозное шифрование, независимость от телефонного номера
Мультиаккаунты и мультидевайсы — один юзер может быть на нескольких устройствах.
Docker-установка — быстрый запуск на Linux-сервере.
Минимальные требования — достаточно 1 ГБ RAM, поддерживается Raspberry Pi.
Бесплатно — всё бесплатно, звонки работают через встроенный TURN/STUN, ну либо есть ещё Snikket Hosting для тех, кому совсем лень и готов просто заплатить около $6/мес за готовый сервер с поддержкой медиарелеев по всему миру и автоматическим обновлением
Jitter‑буфер для WebRTC — служит буфером, выравнивает задержки и помогает стабильно передавать аудио, особенно при нестабильных сетях и сложных NAT.
Snikket сам получает и продлевает сертификаты Let’s Encrypt. У него внутри есть certbot-контейнер, который автоматически запрашивает и обновляет сертификаты и для веб‑портала, и для служб XMPP, STUN/TURN
Немного о jitter-буфере
Jitter‑буфер — это временное хранилище аудио‑пакетов, которое регулирует их подачу на клиент в равномерном потоке, чтобы избежать искажений и пропаданий звука при переменных задержках сети или нестабильном подключении.
В Snikket такой буфер встроен в WebRTC-движок, поэтому, даже если пользователь за NAT с нестабильной связью, звонок остаётся плавным и без резких «дёрганий» аудио.
Немного о звонках
По умолчанию звонки P2P. Клиенты стараются установить прямое соединение друг с другом через STUN.
Если NAT сложный (симметричный, CGNAT и т.п.), тогда в дело вступает TURN-сервер. В Snikket он встроен, можно оставить свой или подключить внешний. TURN просто пересылает UDP-пакеты между клиентами.
TURN не расшифровывает медиапоток. Всё зашифровано протоколом SRTP (Secure RTP) в рамках WebRTC.
Даже администратор сервера, на котором крутится TURN, не может прослушать или записать звонок, потому что у него нет ключей для расшифровки. Он видит только зашифрованный поток байтов.
То есть схема такая:
Обычный случай: звонок идёт напрямую P2P.
Сложный NAT: трафик «прокачивается» через TURN, но всё равно остаётся end-to-end encrypted, без возможности перехвата.
Маскировка аудиотрафика
Если всё работает стабильно — лучше ничего не менять, так вы сохраните качество звука. Но если провайдер или мобильный оператор начинает «резать» звонки, можно запустить TURN на порту 443 и замаскировать трафик под HTTPS.
Есть два способа:
Использовать дополнительный белый IP и повесить TURN на него, на порт 443.
Запустить nginx-сплиттер и разрулить всё на одном IP.
Оба варианта мы разберём чуть ниже. А пока — поднимем turnserver в Docker: он пригодится в любом случае.
mkdir /opt/turnserver
cd /opt/turnserver
Создаем в этой папке файл docker-compose.yml вот с таким содержанием:
version: "3.8"
services:
coturn:
image: instrumentisto/coturn:latest
container_name: coturn
restart: unless-stopped
network_mode: host
volumes:
- /opt/turnserver/turnserver.conf:/etc/coturn/turnserver.conf:ro
Вариант A: ДВА «белых» IP
Snikket живёт на IP₁ (HTTP/HTTPS/XMPP), а TURN — на IP₂ и слушает 443/TLS
напрямую.
DNS:
chat.your-domain.com → IP₁
turn.your-domain.com → IP₂
Snikket (IP₁) Указываем внешний TURN в файле /opt/snikket/snikket.conf добавляем строки
SNIKKET_TWEAK_TURNSERVER=0
SNIKKET_TWEAK_TURNSERVER_DOMAIN=turn.your-domain.com
SNIKKET_TWEAK_TURNSERVER_SECRET=ME_SECRET
Делаем: docker compose up -d
чтобы конфиг перечитался.
В файл /opt/turnserver/turnserver.conf
кладем следующее:
listening-ip=IP_2
tls-listening-port=443
relay-ip=IP_2
fingerprint
use-auth-secret
static-auth-secret=ME_SECRET
realm=turn.your-domain.com
cert=/etc/letsencrypt/live/turn.example.com/fullchain.pem
pkey=/etc/letsencrypt/live/turn.example.com/privkey.pem
И далее docker compose up -d
для перечитывания
Плюсы: проще, меньше прослоек; отличная устойчивость, звонки реально «как HTTPS» на 443/TLS; меньше джиттера по сравнению с проксированием через stream.
Минусы: нужен второй IP.
Вариант B: ОДИН «белый» IP и nginx как сплиттер
Создаем поддомен turn.your-domain.com и вешаем на тот же самый белый ip.
Настраиваем nginx примерно так:
stream {
map $ssl_preread_server_name $backend {
turn.example.com turn_tls;
default https_upstream;
}
upstream turn_tls { server 127.0.0.1:5349; }
upstream https_upstream { server 127.0.0.1:8443; }
server {
listen 443 reuseport;
proxy_pass $backend;
ssl_preread on;
}
}
Отдаем HTTP на Snikket, чтобы он сам выпускал/продлевал сертификаты:
server {
listen 80; listen [::]:80;
server_name chat.your-domain.com groups.chat.your-domain.com share.chat.your-domain.com;
location / {
proxy_set_header Host $host;
proxy_pass http://127.0.0.1:5080; # SNIKKET_TWEAK_INTERNAL_HTTP_PORT
}
}
Указываем внешний TURN в файле /opt/snikket/snikket.conf добавляем строки
SNIKKET_TWEAK_TURNSERVER=0
SNIKKET_TWEAK_TURNSERVER_DOMAIN=turn.your-domain.com
SNIKKET_TWEAK_TURNSERVER_SECRET=ME_SECRET
Делаем: docker compose up -d
чтобы конфиг перечитался.
В файл /etc/coturn/turnserver.conf
кладем следующее:
listening-ip=127.0.0.1
tls-listening-port=5349
relay-ip=<ПУБЛИЧНЫЙ_IP>
fingerprint
use-auth-secret
static-auth-secret=<ДЛИННЫЙ_СЕКРЕТ>
realm=example.com
cert=/etc/letsencrypt/live/turn.example.com/fullchain.pem
pkey=/etc/letsencrypt/live/turn.example.com/privkey.pem
docker compose up -d
чтобы конфиг перечитался.
Плюсы: один IP, звонки «как HTTPS» на 443/TLS; Snikket продолжает сам управлять LE.
Минусы: чуть сложнее; extra‑хоп (nginx stream) → немного повышается латентность/джиттер.
Комментарии (61)
AlexandreFrolov
20.08.2025 08:14Еще бы экран расшаривать, тогда можно было бы созвоны проводить по работе.
Rilkener Автор
20.08.2025 08:14Я слышал, что для таких задач часто используют Jitsi — он умеет и видео, и демонстрацию экрана. Сам не пробовал.
sp01
20.08.2025 08:14Подтверждаю. Jitsi может. И даже предоставить управление может. Не Radmin конечно, для терпеливых пользователей, но все же.
nevergotoro
20.08.2025 08:14Вчера пробовал jitsi поставить - к звонку подключаешься, вроде все в звонке, но голоса нет, микрофон у всех в муте, на кнопки не реагирует. Пробовал пока только локально, возможно нужно через домен публично выводить и будет лучше
Rilkener Автор
20.08.2025 08:14На сколько я понимаю, ему для работы звонков нужен обязательно публичный домен с валидным HTTPS и корректным сертификатом.
Без этого WebRTC в браузере обычно не пропускает медиа.
GTDOGg
20.08.2025 08:14Я вообще не понимаю зачем пользоваться xmpp в 2025-м. Есть nextcloud, bigbluebutton. Гораздо лучше и гораздо производительнее
Rilkener Автор
20.08.2025 08:14Да, можно. Просто в моём случае нет смысла стрелять из пушки по воробьям. XMPP спокойно работает на виртуалке с 2 ГБ RAM и обслуживает сотни пользователей со звонками. А BigBlueButton — это уже совсем другой класс: для нормальной работы ему нужны многоядерный CPU и не меньше 8–12 ГБ памяти.
baldr
20.08.2025 08:14Так, вроде бы, как раз проблема вотсапа в том, что STUN-трафик детектится и блокируется?
Rilkener Автор
20.08.2025 08:14В Snikket это обходится просто: если обычный STUN не проходит, клиенты автоматически переходят на TURN. А TURN можно поднять на порту 443/TLS и замаскировать трафик под HTTPS — тогда его уже не отличить от обычного веба.
0x00FA7A55
20.08.2025 08:14Зря вы годноту палите. Понимаю конечно, технический ресурс и все дела, но чем популярнее будет решение, тем вероятнее на него нацелятся. Так уже случалось, может случиться и ещё. Между тем, xmpp с stun/turn это не только про локальные конфочки и зконки. Много у кого, например, тупо netbird может сдохнуть. Думаю, пора перестать тут обсуждать методы противодействия, т.к. у большинства посетителей сайта навыков в целом хватает разобраться.
Rilkener Автор
20.08.2025 08:14Это, кстати, интересный и философский вопрос: стоит ли вообще что-то скрывать только из страха, что это могут заблокировать?
pewpew
20.08.2025 08:14Ну чисто технически - это вовсе не метод противодействия, а скорее шаг вбок. Массовым данное решение не назовёшь, а тем кто в состоянии поднять его для себя и своих родных и близких ничего не угрожает, потому что сервер частный для частного обмена информацией. Защиту тайны связи никто ещё не отменял.
baldr
20.08.2025 08:14Защиту тайны связи никто ещё не отменял.
Ух ты, а что это такое? Это вот для вот этого операторы должны 3 месяца хранить весь трафик? Это вот для этого Яровая со своим пакетом ходила?
pewpew
20.08.2025 08:14Это другое. Вы не понимаете.
В нашем государстве принято считать, что силовики имеют право подглядывать и подсматривать, ведь у нас нет причин им не доверять.
При этом конституция на месте. И если ваши протоколы связи не позволяют заглянуть в этот трафик, вы никому ничего не обязаны. Вы не оператор. С вас лично потребовать расшифровать ваш же трафик пока никто не может. Даже топнув ножкой от бессилия не выйдет. Особенно это смешно в контексте использования протокола, где шифрование end-to-end. Даже если интернет провайдер будет хранить весь ваш трафик, это ничего не даст.
EugeneTheWatchman
20.08.2025 08:14Я категорически не согласен
Информация не должна ограничиваться
Я бы никогда в жизни не разобрался. И вообще не знал про то как устроены эти технологии.
Если всю информацию убирать из публичного доступа, то мы скоро в каменный век вернёмся
Groosha
20.08.2025 08:14Подскажите, а групповые звонки поддерживаются? Хочется предложить знакомым альтернативу Discord
Rilkener Автор
20.08.2025 08:14Группы для переписки — есть. А вот групповых звонков, как в Discord, нет. Для этого лучше поднять свой сервер Jitsi — он как раз рассчитан на видеоконференции.
RomanKu
20.08.2025 08:14Лет 20 назад пользовал Jabber и даже вносил посильный вклад в развитие сообщества.
Недавно надо было выбирать менеджер и тоже смотрел в сторону XMPP, но при беглом просмотре показалось, что Jabber скорее мертв, чем жив - все те же проблемы, что и были 20 лет назад с кучей расширений и несовместимыми клиентами. А клиенты за это время не сильно далеко ушли. В итоге решил остановиться на Synapse Matrix
А пользователи в итоге "выбрали" телеграмм
¯\_(ツ)_/¯
Интересно сравнить современный jabber лицом к лицу с конкрутентами, может я и не прав был во 2м пункте
Rilkener Автор
20.08.2025 08:14XMPP жив, и в 2025-м это уже не тот «зоопарк», что был 20 лет назад: Snikket берёт нужные XEP’ы (OMEMO, MUC, звонки), и всё работает «из коробки». Клиенты подтянулись — Conversations, Monal, Siskin, Dino, Gajim справляются со звонками и медиа.
Matrix (Synapse) тоже хорош, особенно для командных чатов.
А XMPP остаётся лёгким и автономным — отличный «запасной аэродром» на случай полного блокирования Telegram, WhatsApp и т. д. Не возвращаться же снова к сотовым звонкам и попадать на деньги при этом ))
muxa_ru
20.08.2025 08:14После этого можно спокойно звонить и переписываться в защищённом мессенджере, который полностью под вашим контролем.
Как решаете проблему с шаловлимыми ручками скучающих сотрудников хостинг-провайдера?
Rilkener Автор
20.08.2025 08:14Даже если хостер получит root-доступ к VPS, он не сможет расшифровать звонки или чаты. WebRTC использует SRTP с end-to-end ключами — они генерируются на клиентах и серверу недоступны. А переписка при OMEMO/OTR также шифруется сквозным образом: сервер видит только зашифрованные пакеты и метаданные.
Шаловливые ручки будут наслаждаться зашифрованными пакетами ))
Rilkener Автор
20.08.2025 08:14Вспоминал ваш вопрос и думал, как ещё «шаловливый» хостер может насолить. Ну, допустим, он получил root-доступ, сбросил пароль у какого-то юзера, залогинился под ним и решил почитать переписку. Я провёл эксперимент: сбросил пароль и на новом устройстве вошёл в аккаунт. Всё, что я увидел — это: «Это сообщение было зашифровано с помощью OMEMO, но не для вашего устройства.»
kamaz1
20.08.2025 08:14Т.е. под одним аккаунтом с нескольких устройств общаться не получится?
Rilkener Автор
20.08.2025 08:14Да, с одним аккаунтом можно сидеть сразу с нескольких устройств — всё работает. У меня Snikket одновременно запущен на Android и Windows, сообщения и звонки синхронизируются. А вот если сбросить пароль и подключить новое устройство «с нуля», то старые переписки не откроются: они зашифрованы под ключи предыдущих устройств.
SlavaHU
20.08.2025 08:14А Вы под это дело с какими-то физическими телефонами не сталкивались - в самом деле для бабушек 80+? С железными и с кнопками?
А то со смартфонами в таком случае бывает проблемка...Rilkener Автор
20.08.2025 08:14Если бы такие XMPP-телефоны с кнопками реально продавались — я бы купил их не только бабушкам
SlavaHU
20.08.2025 08:14А не знаете, обычный SIP блочат? Потому что sip-овских железных телефонов дофига и выше, я сам когда-то grandstream-ами пользвоался
Stanislavvv
20.08.2025 08:14Если в смысле клиентского потока к известному провайдеру телефонии — нет. А к своему астериску — могут. Точнее, делали.
Kotops
20.08.2025 08:14Не знаю было или нет, но вроде как Jami мессенджер работает без впн в России -звонки не блочат. SimpleX тоже неплохо работает но только с ВПН, хотя в наше время без него никуда
Rilkener Автор
20.08.2025 08:14Да, Jami действительно интересный вариант — у него архитектура без центрального сервера, звонки идут напрямую, поэтому его и сложнее «задушить».
SimpleX тоже набирает популярность, но у него своя специфика.Я же выбрал XMPP/Snikket как более проверенное и совместимое решение: клиенты есть под все платформы, плюс звонки можно замаскировать под HTTPS через TURN.
Q000P
20.08.2025 08:14Есть ещё Tomy тоже распределенка но без голоса но в реалиях как и jami работает не всегда моментально. Simplex это первое на что я попытался переехать когда начались проблемы но работает он крайне не стабильно даже сообщения могут не приходить по долго. Пробовал и собственный сервер но он очень быстро попадает под тспу и собственный прокси тоже и 2 дня тспу. И тут либо надо постоянно быть на ВПН и тогда он норм работает а когда то ВПН то без ВПН он неохотно меняет линки и даже отправленное сообщение себе с телефона на PC может зависнуть минут на 5 приходится убивать приложение короче гемор использую для пересылки сообщений и файлов между своими гаджетами
Rilkener Автор
20.08.2025 08:14Да, в этом и разница: полностью P2P-решения (Tox, Jami, SimpleX) хороши концептуально, но в реальности часто нестабильны. XMPP с TURN — золотая середина: децентрализация, но при этом можно замаскировать трафик под HTTPS и обойти блокировки без VPN.
vasisulay
20.08.2025 08:14Simplex-- поднял сервер, но 6 версии приложения не конектятся, 4 вроде работало. В чем дело пока не понял.
lrmpsm53
20.08.2025 08:14Почему не matrix?
Rilkener Автор
20.08.2025 08:14Snikket я поднял реально в две команды — и сразу всё готово: звонки, TURN, jitter-буфер, certbot внутри. На VPS с 1–2 ГБ RAM этого хватает за глаза.
Matrix (Synapse) — тяжелее и по установке, и по ресурсам: нужен PostgreSQL, coturn, nginx. В простое он ест ~1 ГБ+, а под нагрузкой легко уходит в 2–4 ГБ.
И нет такого готового «коробочного» решения, чтобы уложиться ровно в две команды init.sh и start.sh.
falkenberg
20.08.2025 08:14можно еще посмотреть в сторону отечественных (забугорные у меня работали плохо, видимо их фильтруют) SIP-провайдеров, типа sipnet или telphin. Сама регистрация у них бесплатна и звонки внутри сети тоже
Rilkener Автор
20.08.2025 08:14У SIP-провайдеров (Sipnet, Telphin и т. п.) по закону весь трафик пишется и хранится. А в Snikket — даже если захочешь, не запишешь: звонки шифруются end-to-end, серверу остаются только зашифрованные пакеты
falkenberg
20.08.2025 08:14это да, но если консерн в том что не хочется ставить Макс потому что он не только звонки пишет, а много что еще, то может оказаться простым решением. Тем кто за содержание звонков не парится
Rilkener Автор
20.08.2025 08:14Ну да, если исходить из принципа «семь бед — один ответ MAX», то конечно ))
spbcity
20.08.2025 08:14Не подскажете, почему не показывает статус пользователя "онлайн", хотя он сейчас в сети и добавлен в контакты?
И еще интересует вопрос по звонкам - если звонки не работают, полагаю, что заблокировано на уровне провайдера?Rilkener Автор
20.08.2025 08:14Чтобы отображался статус «онлайн», нужно, чтобы контакт подтвердил подписку на presence и находился с вами в одном Круге (Circle) — это стандартные roster-группы XMPP, просто Snikket называет их по-своему. На Android ещё важно выдать приложению работу в фоне и отключить энергосбережение, на iOS — включить push-уведомления.
По звонкам: если не коннектится вовсе, чаще всего виноват блок на уровне провайдера (STUN/UDP). Решение — свой TURN на 443/TLS: трафик выглядит как HTTPS, и звонки начинают работать.
Rilkener Автор
20.08.2025 08:14Ещё проверьте порты: 5222 (клиенты), 5269 (s2s), 3478/3479 (STUN), 5349/5350 (TURN), 443 (TURN/TLS) и медиадиапазон 49152–65535/UDP. Если что-то закрыто — звонки не взлетят.
Fullspb
20.08.2025 08:14Спасибо. Поставил. Конечно не обошлось без запинок. Но результат есть. При разговоре по видео двух человек канал кушает около 6 мегабит. Не совсем удобная схема с аккаунтами, люди путаются. Куда что вводить. В целом жить можно.. но вот нужно ли своё держать, каждый выбирает сам. Я поставил ради спортивного интереса.
eugenrad
20.08.2025 08:14Спасибо за статью. Извините за глупый вопрос - в статье упоминается - "nginx как сплиттер" - его нужно как-то доустановить? (в новый docker контейнер?)
Rilkener Автор
20.08.2025 08:14nginx действительно нужен отдельно — можно поставить на хост (apt/yum install nginx), можно завернуть в отдельный контейнер. Разницы особой нет: он просто слушает 443 и по SNI решает, куда слать трафик — в Snikket или в TURN.
Godless
20.08.2025 08:14Давно (год так 2010 +-) пробовал какой то xmmp сервер, но чёт не срослось. Сценарий - чатики внутри конторки. Судя по всему дофига поменялось. (Или нет?)
Как сие будет воркать если развернуть внутри LAN со своими сертами или центрами сертификации? В целом выглядит весьма работоспособно...
Больше всего интересуют чаты (в т.ч. групповые) с SSO kerberos/ldap (ну или хотя бы учётки из LDAP), шара экрана по возможности, видео/аудио звонки сильно вторичны, но будут хорошим бонусом...
pewpew
Какие клиенты вы посоветуете, поддерживающие голосовой и видео траффик?
Rilkener Автор
Голос через WebRTC, поэтому клиенты нужны с поддержкой XMPP-звонков.
Самое простое — использовать приложение, которое предлагает Snikket прямо в инвайте (скриншот с примером инвайта):
Android / iOS — Snikket App (основан на Conversations/Monal, всё работает «из коробки»).
Windows / macOS / Linux — Gajim (последние версии поддерживают звонки), также можно попробовать Dino под Linux.
Для iOS дополнительно есть Siskin IM.
То есть, если вы рассылаете инвайт, пользователю даже не нужно гадать — ссылки на подходящие клиенты уже там есть.
wipexe
сколько по ресурсам кушает это решение??
если просто на условные 10ть человек
Rilkener Автор
По ресурсам решение очень лёгкое. Для ~10 человек хватает даже 1 vCPU и 1–2 ГБ RAM, CPU почти не грузится, т.к. сервер ничего не транскодирует. Нагрузка заметна только если звонки идут через TURN, а не напрямую P2P.
У меня, например, видеозвонок между двумя странами шёл отлично — картинка супер, и это всё на старом CentOS 7. Так что по железу особых требований нет, главное нормальный канал.