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

как развернуть рабочие места сотрудников (софтфон на ПК и SIP-клиент на смартфоне), проверить двустороннюю слышимость, настроить NAT-параметры и межсетевой экран, подключить провайдера (на примере Novofon, ранее Zadarma), организовать входящую и исходящую маршрутизацию, включить запись этапа IVR, а также выполнить небольшую кастомизацию диалплана Asterisk для корректной подстановки DID из SIP-заголовка. Рассматриваются очереди вызовов, переадресации и практики повышения безопасности (Fail2Ban, сложные учётные данные, фильтрация сканеров).

Рабочие места: ПК и смартфон

Софтфон на ПК

• Используется софтфон «Telephone» (или аналог).
• Для регистрации достаточно трёх параметров: адрес SIP-сервера (IP/домен АТС), логин (внутренний номер, например 201) и пароль.
• Поле «Имя/Фамилия» носит описательный характер и не влияет на регистрацию.
• После ввода параметров устройство регистрируется и становится доступным.

SIP-клиент на смартфоне

• Используется Groundwire (Acrobits) или другой SIP-клиент.
• Создаётся стандартный SIP-аккаунт
• При ошибке регистрации в первую очередь проверяются соответствие номера/пароля и актуальность пароля. При множественных неверных попытках возможна блокировка со стороны Fail2Ban (см. раздел «Безопасность»).

Проверка внутренней связи

Выполняются взаимные вызовы между внутренними номерами 201 ↔ 202. Дополнительно выполняется эхо-тест (Echo Test) через встроенное приложение/модуль PBX для проверки двусторонней слышимости.

Сетевые настройки и NAT

Размещение в облаке

При установке АТС в облаке (например, Яндекс Облако) инстанс часто находится за NAT. В конфигурации указывается публичный адрес. Для одно-к-одному NAT (1:1) важно регулярно проверять двустороннюю слышимость RTP.

Режим «АТС за NAT» в офисе

• Опцию «АТС находится за NAT» и явное указание публичного IP следует включать только при наличии внешних подключений по «белому» адресу (удалённые сотрудники/провайдеры).
• Если все пользователи подключаются из локальной сети, лишнее указание публичного IP может вызвать проблемы (в том числе с адресацией RTP).

Локальные/VPN-подсети

• В разделе сетевого экрана добавляются локальные/VPN-подсети (например, 192.168.0.0/24) с пометкой «VPN/локальная подсеть».
  Эта пометка влияет на диалог «АТС ↔ телефон»: при ответе АТС будет отдавать локальный IP вместо публичного для абонентов из этой подсети.
• Для доверенных офисных подсетей может быть включено «не банить эту подсеть» — удобно при миграциях (например, с FreePBX на MikoPBX), когда часть аппаратов временно настроена неверно.

Межсетевой экран и Fail2Ban

Базовые установки

• Межсетевой экран рекомендуется держать включённым по умолчанию (в облаке обычно так и есть).
• При необходимости описываются «белые» адреса/подсети, а также подсети, для которых бан отключён.

Порог блокировки

• Типичная политика — блокировка после трёх неверных попыток аутентификации за короткий интервал (например, до 30 секунд).
• В ряде конфигураций длительность блокировки составляет до 12 часов. При необходимости параметры настраиваются.

Разблокировка

• В веб-интерфейсе доступен список заблокированных адресов с возможностью разбана.
• В крайнем случае — через консоль администрирования сервера:
  fail2ban-client set <jail> unbanip <IP>
  (например, fail2ban-client set asterisk-iptables unbanip 1.2.3.4).
• При полной недоступности интерфейса допустимо временно отключить firewall на консоли, добавить «белые» адреса и включить firewall обратно.

Подключение оператора и маршрутизация

Провайдер

• Подключён оператор Novofon (ранее Zadarma).
• Доступны два внутренних сотрудника (напр., 201 и 202), внутренние вызовы работают.

Входящая маршрутизация

Для входящих звонков задаётся каскад правил по провайдеру:

1. Первое правило — перевод на IVR-меню (предлагается набрать добавочный номер).
2. По истечении тайм-аута (например, 30–600 секунд) — переход к следующему правилу, например в очередь вызовов или на ответственного сотрудника.

Приоритеты: верхние правила имеют более высокий приоритет.

Исходящая маршрутизация

• Для России: номера вида 7XXXXXXXXXX/8XXXXXXXXXX (11 цифр).
  При вызове отсекается первый символ 7/8, добавляется префикс +7.
• Для Беларуси: направление +375… выносится в отдельное правило.
• Рекомендация: создавать атомарные правила по направлениям (РФ, Беларусь, Казахстан и т. д.), чтобы затем гибко назначать права группам сотрудников (межгород/международная связь и пр.).

Практическая проверка

• При исходящем вызове на мобильный определяется реальный номер линии провайдера (в последующем используется для входящей маршрутизации по DID).
• В истории звонков отображаются записи разговоров. В актуальных версиях включена запись и этапа IVR (полезно для анализа действий абонента).

DID из SIP-заголовка и кастомизация диалплана

Проблематика

В истории вызовов может отображаться логин транка вместо реального DID (номера, набранного абонентом). Для корректного отображения DID в отчётах и для входящей маршрутизации требуется извлечь номер из SIP-заголовка, который присылает провайдер.

Решение через кастомизацию

1. В разделе «Кастомизация системных файлов» редактируется extensions.conf.
2. Для входящего контекста провайдера (Novofon) добавляется проверка и прыжок в кастомный контекст (например, incoming-custom) через Gosub.
3. В кастомном контексте из дополнительного SIP-заголовка провайдера читается DID и подставляется в переменную вызываемого номера:
   Для PJSIP: PJSIP_HEADER(read, <Header-Name>).
   Конкретное имя заголовка зависит от провайдера (встречаются варианты вроде X-Called-DID, X-Original-To, Diversion и др.).
4. После подстановки выполняется Return в основной контекст, где вызов обрабатывается уже с правильным DID.
5. Отладка выполняется через verbose-лог вызова: видно заход в кастомный контекст, чтение заголовка и подстановку DID. Отсутствие Return приводит к повторному заходу и преждевременному обрыву — это типичная ошибка, исправляется добавлением Return.

Результат

DID становится «красивым» и пригодным для использования в условиях входящих маршрутов (разные DID — разные IVR/очереди/направления).

Дополнительные входящие маршруты по DID

После появления корректного DID возможно создавание нескольких входящих правил на один и тот же транк, но с разными номерами назначения:

• Отдел продаж — IVR/очередь «Sales».
• Бухгалтерия — своя очередь или прямой маршрут.
• Склад — отдельный маршрут.

Многие операторы позволяют принимать вызовы на несколько DID в рамках одного SIP-транка.

Очереди вызовов (Call Queues)

Общие положения

Очередь объединяет сотрудников-агентов и стратегию дозвона:

• Стандартные стратегии Asterisk: ringall (всем), leastrecent, fewestcalls, random, rrmemory и др.
• Дополнительно доступна линейная стратегия (последовательно сверху вниз), часто удобна для приоритета по списку.

Для удобства операторов в CallerID Name можно добавлять префикс очереди (например, Sales). Рекомендуется использовать латиницу — ряд аппаратов (старые Linksys, некоторые Cisco) некорректно отображают кириллицу. Современные Yealink/Fanvil с кириллицей обычно справляются.

Поведение и оповещения

• Клиент может слышать музыку ожидания или обычные гудки (ringback).
• Озвучивание позиции в очереди и примерного времени ожидания работает, когда все агенты заняты (статус Busy). Это особенность Asterisk.

Дополнительные сценарии маршрутизации

• При отсутствии свободных агентов — перевод на дежурного/ответственного.
• При длительном ожидании (например, >60 секунд) — перевод на «вторую линию» (другая очередь/группа).

DND и вторая линия

• Во избежание «второй линии» в трубке можно отключить получение новых звонков во время разговора.
• Режим DND возможен как средствами телефонов, так и через кастомные сервис-коды (feature-codes) на стороне АТС.

IVR-меню

IVR содержит привязку к аудиофайлу и действия на DTMF-набор (нажатие 1 — очередь A, 2 — очередь B и т. п.).

Опция «Разрешить набор любых добавочных» относится именно к внутренним номерам сотрудников; исключения задаются списком. Допускается номер по умолчанию (Fallback): после N неудачных попыток и/или истечения тайм-аута вызывающий переводится на заданное направление (очередь/сотрудник/голосовая почта).

Карточка сотрудника и переадресации

• В карточке указываются ФИО, внутренний номер, мобильный.
• В расширенных полях задаётся формат набора мобильного (как будет набран номер в диалплане) — удобно для маршрутизации через отдельные исходящие правила (например, префикс 30 на GSM-шлюз).

Переадресация на мобильный может включаться:

• по недоступности (например, через 45 секунд).
• по занятости (по умолчанию занятость = один активный разговор; при необходимости порог изменяется кастомизацией).

Безопасность: учётные данные и защита от сканеров

Помимо сложных паролей рекомендуется использовать нестандартные логины: В PJSIP — auth_username, отличный от внутреннего номера (201, 202 и т. п.). Например, miko-201-<salt>.

Для защиты от SIP-сканеров можно добавлять правила iptables, ограничивающие частоту и характер входящих запросов к портам SIP/RTP — такие запросы будут игнорироваться без ответа, что снижает интерес сканеров.

Интеграции и автоматизация

Возможна интеграция с 1С/CRM через REST API — например, автоматическое подключение/отключение сотрудников к очередям по графику или факту авторизации в 1С.