Jitsi on-prem видеосвязь для филиалов: сеть, TURN, запись

С чего начинаются проблемы видеосвязи в филиалах

Почти всегда жалобы начинаются не с платформы, а с сети и условий на местах: в одном офисе перегружен Wi-Fi, в другом жесткий NAT, в третьем шумная переговорная. В итоге это звучит просто: «звук пропадает», «все тормозит», «вылетает каждые 10 минут».

С on-prem Jitsi это заметнее, потому что ответственность за то, что в облачных сервисах уже «внутри коробки», лежит на вас: где стоят серверы, как они выходят в интернет, какие порты открыты, кто следит за обновлениями и логами. Отдельная зона риска - периметр: firewall, прокси, NAT и межфилиальные правила безопасности.

Типичные симптомы в распределенной компании:

• обрывы речи и «робот» в голосе из-за потерь пакетов и jitter
• задержка звука и видео при перегрузке канала или Wi-Fi
• «черный экран» при несовместимых правилах NAT/firewall
• нестабильность при подключении гостей из внешних сетей
• резкое ухудшение качества при включении записи

Ожидания, которые стоит согласовать заранее

До пилота договоритесь о базовых сценариях: сколько людей в типичном созвоне (и сколько максимум), нужны ли внешние участники, будет ли запись, есть ли переговорные комнаты с отдельным оборудованием. Совещание на 40 человек с записью и «созвоны на 6-8 участников» требуют разных каналов, серверов и подхода к поддержке.

Критерии успеха

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

Типовая архитектура Jitsi on-prem для организации с филиалами

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

Базовые компоненты и роли

Для пилота роли часто держат на одном сервере, но в филиальной модели их обычно разделяют:

• Jitsi Meet (веб-интерфейс и статика)
• Prosody (XMPP): комнаты, авторизация, события встречи
• Jicofo: управление конференцией
• JVB (Jitsi Videobridge): медиамост, который принимает и раздает аудио и видео

Именно JVB чаще всего становится самым нагруженным узлом, а его размещение сильнее всего влияет на качество связи.

Где размещать и сколько узлов делать

Обычно выбирают один из вариантов: все в ЦОД головного офиса, отдельная площадка (neutral DC) или гибрид, когда часть сервисов централизована, а JVB размещают ближе к филиалам. Один общий кластер проще поддерживать, но если филиалы далеко, растет задержка.

Если, например, головной офис в Алматы, а филиалы в Атырау и Усть-Каменогорске, один центральный узел может дать разный опыт пользователям.

На качество обычно влияют не «километры», а реальная маршрутизация и состояние сети: перегруз WAN в пиковые часы, асимметрия каналов (upload часто слабее download), потери пакетов и джиттер (они особенно бьют по речи).

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

Сеть и пропускная способность: что считать и что мерить

Большинство жалоб в филиалах сводится к двум вещам: не хватает полосы или сеть нестабильна. Для видеосвязи важны не только «Мбит/с по тарифу», но и «насколько ровно» держится канал.

Для прикидки считайте по потокам. Аудио (Opus) обычно занимает десятки кбит/с, а видео - уже мегабиты: 720p часто укладывается примерно в 1.5-2.5 Мбит/с на одного отправителя, 1080p может просить 3-4+ Мбит/с. Демонстрация экрана дает плавающую нагрузку: слайды идут легко, а видео внутри экрана резко поднимает битрейт.

Разница между 1:1 и встречей на 10-30 человек в том, что в группе у каждого растет входящий трафик: вы отправляете один поток, но получаете несколько. В филиалах чаще «ломается» Wi-Fi и канал до пользователя, а на центральной площадке - исходящая полоса узла, который раздает потоки всем.

На WAN меряйте не только скорость, а качество: потери пакетов (даже 1-2% уже слышно), джиттер, задержку (RTT), асимметрию upload/download, просадки по времени суток, а также разницу между проводом и Wi-Fi в той же переговорной.

QoS имеет смысл там, где вы реально управляете очередями: на пограничных маршрутизаторах филиала и центральной площадки, а также в корпоративном Wi-Fi. Он не «ускоряет» интернет, а защищает голос и видео от крупных загрузок вроде резервного копирования и обновлений.

Как понять, что проблема у провайдера, а не в серверной части: один и тот же сервер работает хорошо из одних филиалов и плохо из других, а метрики показывают рост потерь и джиттера именно на проблемном участке. Пример: у филиала с каналом 50/10 Мбит/с десять участников еще говорят нормально, но как только двое начинают шарить экран, слабый upload и скачки задержки дают «робота» в голосе и обрывы фраз.

NAT, firewall и правила доступа: что подготовить заранее

WebRTC чаще ломается не из-за серверов, а из-за сети. Медиа старается идти по UDP между клиентом и медиамостом, а NAT и строгий firewall могут резать UDP, подменять адреса или пропускать только «обычные» веб-порты. В результате люди видят «подключается», слышат обрывы или остаются без звука.

Заранее договоритесь, где будет стоять JVB и как к нему будут ходить филиалы. Идеальный вариант - публичный IP у JVB и понятные правила на периметре. Если сервер в дата-центре, а филиалы за NAT, обычно достаточно разрешить исходящие подключения из филиалов и настроить входящие правила на стороне дата-центра.

По портам обычно нужно следующее: TCP 443 к веб-интерфейсу и сигнальным компонентам, UDP 10000 к JVB (ключевой для качества), TCP 4443 к JVB как запасной вариант, если UDP режут (но задержка и качество обычно хуже). Если планируется обход жестких NAT, отдельно заранее согласуйте порты для TURN.

Если в филиале разрешены только исходящие подключения, проверьте, что хотя бы TCP 443 уходит наружу и есть возможность исходящего UDP. Когда UDP полностью запрещен, связь часто «переезжает» на TCP и становится заметно хуже.

Минимальные проверки с сетевыми администраторами:

• есть ли прямой доступ к серверу по TCP 443 из каждого филиала
• разрешен ли UDP 10000 до публичного адреса JVB
• не ломает ли NAT исходящие UDP-сессии (короткие таймауты, агрессивная инспекция)
• нет ли ограничений по MTU/VPN, из-за которых «сыпется» медиа
• сделан ли тестовый созвон из самого «сложного» филиала в рабочее время

TURN: когда он нужен и как спланировать без сюрпризов

В WebRTC соединение собирает ICE: он пробует разные варианты, как добраться от клиента до клиента или до медиамоста. STUN помогает определить внешний адрес за NAT и часто этого хватает, пока сеть ведет себя предсказуемо.

TURN нужен, когда прямой путь не получается и медиа приходится передавать через ретранслятор. Это не «ускоритель», а запасной маршрут. Если его не спланировать, часть филиалов будет «видеть картинку без звука», «не подключаться с телефона» или подключаться только из дома.

Обычно TURN обязателен при симметричном NAT, строгом firewall (разрешены только ограниченные исходящие порты), в мобильных сетях и гостевых Wi-Fi, а также при подключениях из партнерских сетей, где вы не можете настроить правила у клиента.

Размещайте TURN там, где чаще ломается маршрут. Если филиалы сидят на разных провайдерах и качество между регионами разное, TURN ближе к пользователям обычно дает более ровный результат. Если важнее контроль и проще безопасность, TURN ставят рядом с Jitsi, но закладывают достаточный канал: при ретрансляции весь трафик идет через него.

На практике часто используют coturn: включают long-term credentials (логин и пароль), задают realm, открывают 3478 (UDP и TCP) и при необходимости TLS на 5349. Заранее определите диапазон relay-портов и согласуйте его с firewall.

TURN нельзя оставлять «как есть», иначе его используют как открытый прокси. Минимум: только аутентифицированные пользователи, ограничения по разрешенным IP (если сети фиксированные), лимиты на сессии и полосу, нормальные логи, разделение публичного и админ-доступа.

Качество звука: эхо, шум и обрывы речи

Пользователи почти всегда оценивают встречу по звуку. Видео может «сыпаться», но если речь чистая и без заметной задержки, разговор идет. А вот хороший видеоряд при плохом звуке быстро превращает встречу в угадайку, особенно в филиалах с разными комнатами и сетями.

Эхо и постоянный шум чаще всего рождаются не на сервере, а в комнате. Типичный сценарий: ноутбук стоит в центре стола, динамики включены громко, а встроенный микрофон ловит отражения от стен и стекла. Добавьте кондиционер, проектор и «громкую связь» с телефона - и подавление эха в WebRTC уже не вытягивает.

Перед заменой оборудования проверьте базовое: выбрано ли правильное устройство ввода и вывода, не выводится ли звук на колонки вместо спикерфона или гарнитуры, нет ли слишком высокого усиления микрофона в ОС, отключены ли «улучшатели звука» драйвера, актуален ли браузер и разрешения на микрофон.

По акустике правило простое: чем ближе микрофон к говорящему, тем меньше эха. В переговорной лучше работает отдельный спикерфон или направленный микрофон, чем встроенный микрофон ноутбука. Мягкие поверхности (шторы, ковролин, панели) заметно снижают отражения. Если в комнате много стекла и пустых стен, звук будет «плавать» даже при идеальной сети.

Быстрая диагностика занимает 10 минут. Сделайте короткую тестовую запись и послушайте, когда появляется эхо. Затем по очереди смените устройство (встроенный микрофон -> гарнитура), попробуйте другую комнату и, если возможно, другую сеть (кабель вместо Wi-Fi). Если проблема исчезает при смене сети, дальше смотрите потери, джиттер, Wi-Fi, VPN и маршрутизацию.

Запись встреч: нагрузка, хранение и правила доступа

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

По ресурсам запись почти всегда упирается в CPU и диск. Даже если сама конференция стабильна, запись может начать «заикаться» из-за нехватки вычислений или медленного хранилища. До запуска договоритесь о сценариях (сколько одновременных записей и какой формат) и от этого отталкивайтесь.

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

Дальше решите, где хранить файлы: локально в дата-центре, в файловом хранилище или в системе документов. Заранее опишите роли: кто может смотреть, кто скачивать, кто удалять. Частая ошибка - общий доступ «по ссылке», который случайно уходит наружу.

Отдельно согласуйте политику хранения с безопасностью и юристами: срок (30/90/365 дней), основание для продления и автоматическое удаление. И обязательно предупреждайте участников до начала записи: индикатор, фраза модератора и правило, что запись стартует только после явного подтверждения ведущего.

Переговорные комнаты: оборудование и удобство использования

Даже при идеальной серверной части видеосвязь в переговорных часто «сыпется» из-за мелочей. В филиалах это заметно особенно сильно: оборудование разное, привычки пользователей разные, а поддержка далеко.

Для небольшой комнаты на 4-6 человек обычно достаточно хорошей USB-камеры и спикерфона на столе. Для большой переговорной на 12-20 человек ключевой фактор - звук: одной «таблетки» по центру часто мало, люди по краям звучат тихо, а эхо растет. В таких комнатах заранее планируйте более мощный спикерфон, дополнительные микрофоны или систему с микрофонным массивом, а также камеру с широким углом или PTZ.

Встречу часто ломают неочевидные вещи: отвалившийся USB, плохой HDMI, разряженный пульт, перепутанные входы на ТВ, автосон ПК, внезапное обновление ОС или то, что браузер потерял доступ к микрофону.

Ориентир простой: человек заходит в комнату и понимает, что делать за 10 секунд. Помогают короткая инструкция на 3-4 шага на столе и сценарий «одна кнопка» (например, заранее открыт браузер на странице входа в конференцию или запуск через календарь на выделенном ПК).

Перед первой неделей эксплуатации проверьте базовый набор:

• отдельный ПК/мини-ПК для комнаты, без лишних программ и автосна
• качественные USB/HDMI-кабели и запасной комплект
• камера на уровне глаз и маркировка портов
• тест микрофона с дальнего места в комнате
• роль модератора: кто запускает встречу и впускает внешних гостей

Поддержка работает, когда есть понятный ответ на вопрос «кто поможет прямо сейчас». Обычно это дежурный в IT и один ответственный в каждом филиале. Им стоит дать короткий сценарий восстановления: перезагрузить вкладку, проверить выбранный микрофон, переподключить USB, перезагрузить ПК и только потом эскалировать.

Если переговорные и инфраструктуру делают «под ключ», удобно, когда один подрядчик закрывает и стандарт по оборудованию, и сервис по всей сети. В Казахстане такие проекты часто ведут системные интеграторы уровня GSE.kz.

Пошаговый план внедрения: от пилота до запуска

Чтобы on-prem Jitsi не превратился в вечное «нас не слышно», тестируйте не идеальные условия, а реальные филиалы: разные провайдеры, NAT, VPN, перегруженные каналы и комнаты с эхом.

Сначала соберите точные вводные: сколько одновременных встреч в каждом филиале, сколько людей в типичной встрече, есть ли переговорные, нужна ли запись, какие сети используются (прямой интернет, VPN, мобильные резервные каналы). Это сразу задает требования к полосе и правилам доступа.

Дальше двигайтесь по шагам:

• составьте карту филиалов: подсети, NAT, ограничения firewall, доступные порты и кто может их менять
• запустите пилот на 1-2 филиала и измеряйте качество: задержку, потери пакетов, «заикания» речи, частоту переподключений
• проверьте «худшие» сети и заранее настройте TURN и политику безопасности
• включите запись на пилоте и оцените нагрузку: CPU, диск, сеть, а также хранение и доступы
• подготовьте переговорные: микрофоны, акустика, расположение, короткая инструкция для пользователей

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

Частые ошибки при запуске on-prem Jitsi

Частая ошибка - поставить систему «как есть» в дата-центре или в головном офисе, а потом удивляться жалобам из филиалов. Тест на идеальном канале ничего не доказывает, если у филиалов другой провайдер, другой NAT и другой Wi-Fi.

Проблемы чаще всего появляются из-за того, что не проверили заранее:

• пилот проводят только на хорошем канале, а потом выясняется, что в одном филиале вечером проседает аплинк
• открывают лишние порты «на всякий случай», усложняя безопасность и диагностику
• ставят TURN и оставляют его без ограничений и аутентификации
• недооценивают нагрузку на JVB и особенно на запись (включили запись и внезапно уперлись в CPU и диск)
• собирают переговорную «из того, что было», без проверки эхоподавления и сценариев восстановления

Хорошая практика: один короткий сценарий теста повторить в каждом филиале в рабочее время. Например, 3 участника из филиала, 3 из головного офиса, 10 минут с демонстрацией экрана, 10 минут с записью и 5 минут разговором «как обычно». После этого обычно уже видно узкое место: Wi-Fi, аплинк провайдера, NAT или сервер.

Еще один пункт, который забывают чаще всего, - ответственность. Если заранее не назначить, кто отвечает за сеть (филиалы и firewall), кто за серверы и обновления и кто за поддержку пользователей, любая мелочь превращается в неделю переписок.

Короткий чек-лист перед масштабированием на все филиалы

Перед тем как раскатывать решение на все филиалы, убедитесь, что качество предсказуемо не только в офисе с хорошим интернетом, но и в самых проблемных точках.

Смотрите не на «скорость по тарифу», а на потери и джиттер по реальным маршрутам и в часы пик. Если показатели плавают, даже сильная серверная часть не спасет: WebRTC будет сбрасывать качество, а звук начнет обрываться.

Минимальные проверки перед масштабированием:

• есть замеры потерь и джиттера на ключевых каналах между филиалами (в том числе утром и после обеда)
• NAT и firewall проверены на практике: согласованы правила для UDP и понятен план Б при блокировке UDP
• TURN протестирован из «сложных» сетей: гостевой Wi-Fi, симметричный NAT, мобильные операторы
• сделаны тестовые записи нескольких встреч: оценена нагрузка и понятен расход места на диске
• для переговорных подготовлены короткие инструкции и резервный сценарий (например, «перезапуск комнаты за 2 минуты»)
• назначены контакты поддержки и время реакции: кто принимает инцидент, кто смотрит логи, кто отвечает пользователям

Когда этот список закрыт, масштабирование становится управляемым: добавляете филиалы партиями, сравниваете метрики до и после и быстро ловите отклонения.

Пример для компании с 6 филиалами и что делать дальше

Представим компанию: головной офис и 6 филиалов, у каждого свой провайдер. Где-то прямой интернет, где-то доступ только через корпоративный VPN. В одних офисах белые IP, в других строгий NAT и закрытый firewall. Пользователи хотят простую схему: создал комнату, зашел с ноутбука или из переговорной, и звук не пропадает.

Размещение Jitsi и TURN выбирайте от самого слабого места. Если хотя бы 1-2 филиала часто сидят за жестким NAT или через мобильный интернет, закладывайте TURN сразу, иначе «то работает, то нет» станет нормой. Часто подходит центральный кластер Jitsi (в вашем дата-центре или в головном офисе) и TURN там, где это дает более стабильный маршрут для пользователей.

Нагрузка почти всегда растет неожиданно из-за записи и больших встреч. Практичная схема - разделить роли: узлы под живой трафик и отдельные узлы под запись. Для Jitsi это обычно означает несколько JVB под конференции и отдельные серверы под Jibri, чтобы запись не «съедала» ресурсы в моменты, когда важна стабильность звука.

Чтобы запуск не превратился в переписку «у нас не работает», подготовьте минимум документов: требования к сети по каждому филиалу, правила для firewall/NAT, регламент записи (кто включает, где хранится, кто имеет доступ), инструкция для переговорных, порядок обращения в поддержку и список данных, которые нужно сообщать.

Следующие шаги, которые дают быстрый результат: короткий аудит сети в 2-3 проблемных филиалах, затем пилот на реальной нагрузке (например, еженедельная планерка и одна переговорная) и только потом масштабирование на все точки.

Если нужна ответственность «под ключ» (серверы, интеграция, настройка и дежурная поддержка), имеет смысл подключать системного интегратора с опытом по стране и круглосуточным сервисом. В Казахстане такой формат есть у GSE.kz: компания одновременно производит серверы и выполняет системную интеграцию, что удобно, когда проекту нужны и железо, и поддержка.