Простое руководство по выбору между отдельными IP-АТС, централизованным управлением вызовами, локальными телефонами и общей связью между офисами.

Развертывание 3CX для распределенной компании (Multi-site) обычно начинается с ключевого решения: где именно будет размещаться центр управления вызовами. Мост (bridge) связывает между собой отдельные АТС, позволяя офисам звонить друг другу. SBC подключает локальные телефоны к АТС, расположенной в другом офисе или в облаке. Оба решения поддерживают распределенную архитектуру, но они решают абсолютно разные задачи связности и администрирования.

Прежде чем открывать консоль администратора, определитесь: нужен ли каждому филиалу собственный сервер АТС, или же все офисы должны использовать единую центральную систему. Филиалу могут требоваться собственные добавочные номера, транки, часы работы, очереди вызовов и локальное администрирование. Другому же офису могут быть нужны только настольные телефоны для подключения к АТС, размещенной в центральном офисе или в облаке.

Это две совершенно разные модели работы. Выбор метода подключения после того, как вы определились с моделью АТС, значительно упростит планирование нумерации, маршрутизации и сетевых настроек.

Разделяйте связность офисов и размещение АТС

Связность офисов отвечает на вопрос: как вызовы и голосовой трафик перемещаются между локациями. Размещение АТС определяет: где именно управляются добавочные номера, транки, очереди, часы работы и правила маршрутизации. Мост объединяет две системы 3CX. SBC подключает телефоны в одном офисе к удаленной системе 3CX.

Это различие принципиально важно, так как мост не превращает отдельные системы в единую АТС, а SBC не создает локальную АТС со своими транками или правилами обработки вызовов. Начинайте с рабочей модели бизнеса, а затем выбирайте соответствующий связующий компонент.

Выбор архитектуры: Мосты (Bridges) против SBC

Несколько АТС как независимые системы (мосты)

new master bridge setup

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

Мост идеально подходит, когда у каждой АТС есть собственные администраторы, транки, часы работы, очереди вызовов или локальные правила маршрутизации. Он сохраняет четкие границы между системами, предоставляя сотрудникам предсказуемый способ связи с коллегами в других филиалах.

Перейдите в консоль администратора > Voice & Chat > +Add Bridge. В конфигурации моста используются роли Master (главный) и Slave (ведомый), общее значение аутентификации, исходящий префикс и безопасный FQDN для удаленной системы. При использовании туннельного соединения трафик SIP и RTP передается через настроемый туннель. Заранее спланируйте нумерацию и исходящие правила, прежде чем пользователи начнут совершать вызовы.

Планирование нумерации, маршрутизации и статусов (Presence)

План на основе префиксов легко объяснить: пользователь набирает префикс филиала, а затем удаленный добавочный номер. План нумерации на основе диапазона номеров офиса выглядит более естественно, когда за каждым офисом закреплен свой уникальный диапазон. Любой из подходов работает только в том случае, если исходящие правила, удаление набранных цифр (digit stripping) и ограничения по кодам стран соответствуют этому плану.

Отображение статусов (Presence) — это отдельное решение. Если пользователям нужно видеть статусы коллег на другой АТС, включите в настройках моста опции публикации и получения информации о присутствии. Не предполагайте, что один лишь межсетевой набор автоматически создает общий справочник или единую систему управления вызовами.

Подключение локальных телефонов к удаленной АТС (SBC)

Выбирайте SBC, когда АТС должна находиться в облаке или в главном офисе, а группе IP-телефонов в филиале требуется надежное локальное подключение. Руководство по 3CX SBC описывает его как локальную службу, которая объединяет сигнализацию SIP и медиа-трафик RTP из одной локации и доставляет их на удаленный экземпляр 3CX.

Часто это самое простое решение для филиала, которому не нужна собственная АТС. Офис сохраняет свои локальные телефоны и локальную сеть (LAN), в то время как управление вызовами, добавочные номера, транки и администрирование остаются централизованными. Для совсем небольших офисов вместо выделенного SBC может быть удобнее использовать поддерживаемый телефон-маршрутизатор (Router Phone) или приложения 3CX.

Хосту SBC требуется статический локальный IP-адрес, и он должен быть доступен всегда, когда локальным телефонам требуется связь. Относитесь к нему как к неотъемлемой части тракта прохождения вызова — наравне с LAN, фаерволом, DNS и электропитанием.

В консоли администратора перейдите в раздел Voice & Chat и выберите +Add SBC. Выполните провижининг SBC, затем назначьте ему локальные телефоны. Помните: SBC решает задачу подключения удаленных телефонов и обхода фаервола. Он не создает вторую АТС и не дублирует конфигурацию основной системы.

Внедрение и чек-лист перед развертыванием

Используйте мост, когда каждому офису требуется собственная идентичность АТС и локальное управление, с плановым межсетевым набором между системами.

Используйте SBC, когда организации нужна единая АТС для управления добавочными номерами, транками, очередями и правилами, в то время как сами телефоны физически находятся в другом месте.

Если филиалам требуются разные часы работы, локальные очереди или отдельные администраторы, раздельные АТС обеспечат более четкие границы. Если же главная цель — единообразное администрирование и единая система добавочных номеров, централизованная АТС с телефонами, подключенными через SBC, обычно гораздо проще в эксплуатации.

Планирование DNS, транков, телефонов и тестирования

Разрешение имен (DNS) – это часть архитектурного проектирования, а не деталь пост-настройки. Руководство 3CX требует использования защищенных FQDN для объединенных мостами систем и рекомендует Split DNS для локальных установок. Используйте одни и те же задокументированные имена при автонастройке телефонов, доступе через приложения, работе с сертификатами, подключениях мостов и администрировании.

Изучите руководство 3CX по настройке фаервола для каждого офиса и запустите проверку фаервола (Firewall Checker) после настройки сети. Отключите SIP ALG, задайте правильные списки доступа (ACL) и зафиксируйте, какие порты и потоки данных необходимы для транков, удаленных телефонов, SBC и администрирования.

Наконец, проведите проверку с точки зрения конечного пользователя. Протестируйте работу настольных телефонов, доступ через веб-клиент, мобильные и десктопные приложения, отправку PUSH-уведомлений, очереди вызовов, переводы звонков, голосовые меню (IVR), сценарии экстренных вызовов, запись разговоров, интеграции и отображение статусов присутствия (Presence) между офисами.

Используйте этот Чек-лист для принятия решений

Перед выбором архитектуры подтвердите следующие пункты:

  • Мост: Отдельным АТС требуется контролируемый межсетевой набор, схема нумерации и, возможно, общий статус присутствия.
  • SBC: Локальным IP-телефонам нужен доступ к удаленной или облачной АТС без развертывания еще одного сервера АТС в данном офисе.
  • Нумерация: За каждым офисом закреплен задокументированный диапазон добавочных номеров, префикс или правило набора, понятное пользователям.
  • Сеть: На каждом объекте настроены необходимые FQDN, поведение DNS, правила фаервола и задокументирован тракт прохождения вызовов.
  • Ответственность: Команда четко знает, кто управляет каждой АТС, мостом, SBC, маршрутизацией транков и изменениями в нумерации.
  • Тестирование: Команда проверила межсетевые вызовы, входящую и исходящую связь, статусы присутствия, доступ к приложениям и ключевые функции телефонии.

Распространенные ошибки в архитектуре

К типичным ошибкам относятся: использование моста, когда офису на самом деле нужна централизованная система добавочных номеров; использование SBC, когда офису требуется собственная АТС и независимые транки; предоставление офисам свободы создавать несовместимые правила нумерации; использование IP-адреса вместо задокументированного FQDN; игнорирование настройки Split DNS; а также ошибочное мнение, что звонки между офисами автоматически создают общий адресный справочник или единый статус присутствия. Главное правило: всегда оценивайте, на какой именно системе лежит ответственность за обработку конкретного вызова.

Архитектура должна быть достаточно прозрачной для обслуживания. Каждые АТС, мост, SBC, запись DNS, маршрут транка и правило нумерации должны иметь ответственного и задокументированный тест. Если никто не может объяснить, как пользователь в одном офисе соединяется с нужным добавочным номером или транком в другом — проект нельзя считать завершенным.

Присоединяйтесь к обсуждению

Присоединяйтесь к обсуждениям 3CX на наших специализированных форумах для партнеров или клиентов. Подписывайтесь на нас в X и LinkedIn, чтобы быть в курсе последних новостей и релизов.