MikoPBX — расширенные возможности часть 3

На исходном этапе развернута активная телефонная линия, подключены сотрудники, настроена входящая и исходящая маршрутизация. Входящая маршрутизация по DID-номерам распределена на разные отделы. Далее предполагается подключение дополнительного направления: звонки в Республику Беларусь. Требование — предоставить право исходящих звонков в Беларусь только части сотрудников (например, менеджерам), при этом остальным оставить доступ лишь к внутренним и/или российским направлениям.

Маркетплейс MikoPBX и модуль «Управление телефонными группами»

Для разграничения прав на исходящие маршруты используется раздел Marketplace в MikoPBX. Доступны бесплатные и платные модули. В рамках задачи применяется бесплатный модуль «Управление телефонными группами».

Процедура:

1. Регистрация в Marketplace (указание реквизитов организации и контактных данных).
2. Установка модуля из каталога Marketplace.
3. Активация модуля.

Далее настраиваются группы:

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

Сотрудники добавляются в соответствующие группы; одному сотруднику можно назначить несколько групп при необходимости.

Дополнительные возможности модуля групп

• Изоляция группы — полная изоляция внутренних вызовов внутри группы: пользователи группы не могут звонить во внешний мир (и наоборот), за исключением явно разрешённых случаев. Подходит для отделов, требующих строгого разграничения.
• Изоляция функции перехвата (Call Pickup) — ограничение перехвата (по умолчанию — *8) только вызовов своей группы, без возможности перехватывать звонки других отделов.
• Индивидуальный CallerID по группам — при наличии одного SIP-транка с несколькими номерами можно указать номер, который будет подставляться при исходящих вызовах от конкретной группы (например, отдел продаж звонит с одного представляемого номера, бухгалтерия — с другого). Важно убедиться, что провайдер разрешает подстановку CallerID, и соответствующие опции в «Расширенных настройках» провайдера не блокируют его.

Примечание: в MikoPBX CallerID управляется на уровне групп пользователей, что логично при наличии нескольких отделов с разными требованиями. В FreePBX аналогичные параметры могут дублироваться в карточке пользователя и в исходящем маршруте; в MikoPBX рекомендуется централизованная настройка через группы.

Управление доступом к веб-интерфейсу (платный модуль)

Для разграничения доступа к веб-интерфейсу АТС используется модуль «Управление доступом» (платный).

• Создаётся группа доступа, например «Админы», без ограничений.
• Добавляются сотрудники, которые получают отдельные учётные записи для входа в веб-интерфейс (логин может отличаться от внутреннего номера; пароль по умолчанию соответствует SIP-паролю и при необходимости меняется).
• При необходимости создаётся группа с ограниченными правами, например «CDR: История звонков», где разрешён доступ только к разделу истории и, дополнительно, можно отфильтровать видимость записей по конкретным сотрудникам/номерам.

Интеграция с доменом (LDAP/Active Directory)

В модуле «Управление доступом» предусмотрена доменная авторизация: настраиваются параметры подключения к домену (LDAP/AD). Дополнительно существует отдельный модуль синхронизации сотрудников по LDAP:

• Синхронизируются ФИО, фотографии, внутренние и мобильные номера, при необходимости — пароль.
• Поддерживается двусторонняя синхронизация внутренних номеров между MikoPBX и LDAP.
• Модуль полезен при большом количестве сотрудников (практические кейсы — до 2000 рабочих мест).

Сертификаты и шифрование

В Marketplace доступен модуль Let’s Encrypt для выпуска валидного сертификата:

• HTTPS для веб-интерфейса.
• SIP-сигнализация по TLS, медиатрафик — по SRTP (SDES или DTLS-SRTP), если это поддерживается провайдером/клиентским ПО.
• Сертификат Let’s Encrypt может использоваться Asterisk’ом для шифрованных соединений. Шифрование гарантировано до провайдера; на стороне провайдера запись обычно выполняется в открытом виде.

Кастомизация: маскирование номера клиента (Hash/MD5) в Dialplan

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

• в CDR/истории сохраняется реальный номер;
• при исходящем наборе «хэша» система должна дозваниваться до реального клиента.

Реализация без платных модулей — через кастомизацию dialplan в Asterisk.

1. Подключение модуля func_md5 (для вычисления MD5-хэша) через modules.conf.
2. Определение списка внутренних номеров, для которых применяется маскирование (например, конкретные добавочные или шаблон 2XX).
3. Кастомный контекст (например, *_custom), куда попадает канал при установлении диалога с телефоном сотрудника.
4. Обратная подстановка при исходящем наборе: если сотрудник набирает строку вида XXXX*<MD5>, dialplan извлекает реальный номер из AstDB и выполняет исходящий вызов уже на него.

Ключевые моменты:

• Используется только расширение стандартного dialplan с учётом *-custom-вставок; базовый функционал не ломается.
• Встраивание выполняется в предусмотренные «точки расширения»; важно по завершении возвращать управление (условный Return), чтобы не оборвать вызов.
• Для проверки наличия кастомного контекста используется соответствующая проверка существования секции dialplan.

Примеры точек встраивания dialplan

В составе системных файлов (extensions.conf) предусмотрены места для «врезок», например incoming-custom, outgoing-custom, allpeers-custom и т.п. Они позволяют выполнить дополнительную логику до/после стандартных приоритетов, не переписывая штатный сценарий. Это сохраняет корректность истории звонков и совместимость с интерфейсом.

CDR и история звонков

Стандартный CDR Asterisk (в классическом «ванильном» виде) не всегда отвечает бизнес-требованиям (например, при переводах/соединениях). В рассматриваемой системе история звонков реализована на основе событий AMI/AGI и отдельного демона-обработчика, что позволяет:

• точнее вычислять длительность разговоров и фазавость диалогов
• строить наглядные отчёты и статусные панели

Расширенная история звонков (платный модуль)

Модуль создаёт независимую базу данных — реплику «основной» истории — и синхронизирует данные, чтобы тяжёлые запросы (вплоть до выборок за годы) не блокировали работу АТС. Возможности:

• фильтры по направлению (входящие, исходящие, пропущенные), провайдеру, DID и др.;
• отбор по сотрудникам и группам сотрудников (интеграция с модулем «Управление телефонными группами»);
• сохранение настроек отчёта;
• экспорт в Excel/Numbers;
• дополнительные признаки (например, «перезвон клиенту» как связка пропущенного и последующего исходящего).

SIP REFER (Transfer) и особенности CDR

SIP-перевод (REFER/Transfer) во многих системах формирует несколько записей CDR, которые не всегда автоматически связываются между собой, что усложняет аналитику. В описанной реализации клавиши Transfer на совместимых аппаратах (Yealink, Fanvil) обрабатываются так, чтобы в истории строились целостные «диалоги вызовов». На некоторых софтфонах (например, определённые версии Zoiper/фоновых клиентов) возможны частные несовместимости; в таких случаях рекомендуется использовать star-codes (служебные коды) для переводов либо переназначить аппаратную кнопку.

WebRTC и софтфоны

MikoPBX «из коробки» поддерживает WebRTC; для клиентской части можно использовать сторонние веб-софтфоны на базе библиотеки JsSIP или готовые решения (B24, amoCRM и др.). Возможна кастомизация под конкретные сценарии.

Кастомизация pjsip.conf и параметров провайдеров/сотрудников

При создании учётных записей в pjsip.conf формируются секции:

• endpoint (параметры конечной точки регистрации)
• auth (логин/пароль)
• registration (для провайдеров — параметры регистрации на их стороне)

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

• Секция с типом registration может быть целиком скопирована и модифицирована для конкретного провайдера (например, изменить contact_user, интервалы повторной регистрации, URI и т.п.).
• Переопределения из «Дополнительных параметров» имеют приоритет над чекбоксами/полями в карточках провайдера/пользователя (пример: from_user для endpoint).
• При необходимости можно добавить собственные секции напрямую в pjsip.conf через «Кастомизацию системных файлов» и описать любые нестандартные endpoints/аутентификацию, которые не укладываются в GUI.

Синтаксические подсказки: в конфигурации Asterisk используются шаблоны (!) для наследования (templates), а также механизмы добавления/расширения существующих секций; для включения логики важно корректно использовать предусмотренные механизмы «добавить в конец секции» и «переопределить значение», чтобы не ломать штатные части.

Прочие модули Marketplace

• Zabbix-интеграция — мониторинг.
• Let’s Encrypt — выпуск и автопродление сертификатов.
• Телефонная книга — корпоративный справочник.

Платные модули доступны по разным моделям лицензирования (подписка/разовая покупка); предупреждение о пробном периоде (обычно 14–30 дней) отображается при установке.

Организационные замечания

• Для изолированных контуров без доступа в Интернет модули устанавливаются из ZIP-архивов через интерфейс MikoPBX (файлы могут быть переданы на съёмном носителе).
• Названия пунктов меню и отображение модулей в боковом меню настраиваются для удобства пользователей (например, сотрудников с ограниченным доступом через модуль «Управление доступом»).
• Для высокой отказоустойчивости часто рациональнее опираться на средства виртуализации/кластеризации (например, Proxmox с двумя узлами), чем усложнять логику внутри АТС.