Основы PJSIP. Подключение IP-телефонов к Asterisk и к FreePBX (курс молодого бойца)

Asterisk успешно работает на большинстве современных Linux-дистрибутивов, включая Debian/Ubuntu, Astra Linux и Red OS. В корпоративных сборках с ограниченными репозиториями (например, Astra Linux/Red OS) часто приходится вручную доустанавливать зависимости и собирать часть пакетов из исходников. Практично вести собственный список требуемых пакетов (например, в GitHub) и держать его в актуальном состоянии.

Для промышленной эксплуатации предпочтительны LTS-версии Asterisk (long-term support): они дольше получают исправления и обновления безопасности. Линейка Certified Asterisk нередко воспринимается как “лучше”, но фактически это урезанные сборки с выпиленными модулями; иногда отсутствует критичный функционал (например, curl). Для универсальности и предсказуемости сценариев рекомендуется именно LTS.

Образы FreePBX традиционно отстают от актуальной ветки Asterisk на 1–2 релиза. Это ограничение в основном на уровне сборочной логики; при необходимости совместимость можно достичь ручной пересборкой, однако такой подход требует аккуратности.

История изменений и обратная совместимость

Крупные изменения синтаксиса конфигурации были в эпоху 1.2/1.4/1.6. Конфигурации начиная с 1.8 в подавляющем большинстве случаев безболезненно мигрируют на современные версии. При этом в AMI (Asterisk Manager Interface) и событиях встречались эволюционные изменения, но сохранялась разумная обратная совместимость и мягкий путь миграции.

Подготовка системы и сборка из исходников

Зависимости

В исходном дереве Asterisk есть скрипт для установки предварительных зависимостей:

contrib/scripts/install_prereq install

Он подтягивает компилятор, заголовки, dev-пакеты и полезные утилиты для сборки.

PJProject и PJSIP

Современная SIP-реализация в Asterisk — PJSIP (движок — PJProject). При конфигурации:

./configure

система либо найдёт установленный PJProject, либо предложит собрать встроенный (bundled). Без PJSIP сборка SIP-функционала будет ограниченной.

Меню выбора модулей (menuselect)

make menuselect

Здесь выбираются приложения, кодеки, канальные драйверы, звуковые файлы и флаги компиляции.

• Каналы. chan_pjsip — основной; DAHDI нужен только для E1/FXO/FXS.
• PBX-языки. Имеются pbx_config (классический extensions.conf), pbx_ael, pbx_lua, pbx_realtime. Для большинства задач достаточно нативного extensions.conf; альтернативы — по вкусу и задачам.
• Звуки. Для русских подсказок включить пакеты CORE-SOUNDS-RU-WAV (и при необходимости дополнительные форматы).
• Флаги компиляции. Во избежание привязки к конкретному CPU снять флаг BUILD_NATIVE (это повысит переносимость между узлами виртуализации/ЦОД). Флаг DONT_OPTIMIZE использовать только для отладки — он отключает оптимизации и не решает вопрос переносимости.

Сборка и установка

make
make install
make samples            # развернуть пример конфигурации
make install-logrotate  # установить конфиг ротации логов

Минимизация поверхности атаки и загрузка модулей

По умолчанию автозагрузка всех модулей нежелательна: дополнительный открытый порт — это лишний риск. Рекомендуется:

• В modules.conf установить autoload=no.
• Явно перечислить необходимые модули (SIP, RTP, CDR/CEL, нужные приложения/функции).
• Периодически ревизовать список: отключать неиспользуемое.

В комплекте configs/basic-pbx/ есть минимальный набор конфигов; это удобная база, от которой можно «наращивать» только требуемое.

PJSIP вместо chan_sip и миграция конфигурации

Исторический chan_sip признан устаревшим и постепенно исключается из новых веток. chan_pjsip архитектурно современнее, лучше масштабируется на многоядерных системах, корректнее обрабатывает параллельные транзакции и поддерживает мульти-регистрации одного endpoint (например, аппаратный телефон, софтфон на ПК и мобильный — все на одном аккаунте).

Для миграции имеется скрипт:

contrib/scripts/sip_to_pjsip

Он конвертирует объекты из sip.conf в структуры pjsip.conf. Результат автоматически применять не стоит — разумно вручную проверить и допилить нюансы (ACL, трансляции, таймеры, транспорт, аутентификацию и т. д.).

TLS и WebRTC

Скрипты в contrib/scripts/ помогают с генерацией TLS-сертификатов. Для WebRTC предпочтительны публично доверенные сертификаты (например, Let’s Encrypt), чтобы браузеры (Chrome и др.) не ругались на самоподписанные.

Виртуализация и архитектуры

Проблемы тайминга в ранних гипervisors давно решены; Asterisk стабильно работает в VMware, KVM/QEMU, Hyper-V и пр. Возможна установка на ARM (включая Raspberry Pi) — производительность зависит от задач.

Важно учитывать переносимость бинарников между пулами виртуализации: при миграции ВМ между узлами с разными CPU семейства/флагами Asterisk, собранный с -march=native, может не стартовать. Решение — снимать BUILD_NATIVE и, при необходимости, пересобрать.

Кодеки и медиа

• Opus — рекомендуемый кодек для мобильных клиентов и WebRTC: адаптивный битрейт, PLC/FEC, устойчивость к потерям (при корректной настройке может «переваривать» существенные потери пакетов).
• G.711 (µ/А-law) — базовая совместимость, простая транскодирование, но требовательность к качеству канала.
• G.729 — лицензирование и юридические нюансы; готовые бинарные модули доступны не всем, альтернативой остаётся самостоятельная сборка при наличии соответствующих библиотек и соблюдении лицензий.

Транскодирование между кодеками — одна из заметных статей нагрузки CPU; чем меньше транскодировать, тем лучше.

DAHDI и DUNDi (кратко)

• DAHDI — драйверы/интерфейсы для TDM-плат (E1, FXO/FXS). Нужен только при работе с соответствующим оборудованием.
• DUNDi — распределённое обнаружение номеров (DID) для прямых SIP-маршрутов между Asterisk-узлами. Концепт интересный, но в реальной телеком-среде широкого распространения не получил.

Логирование и отладка

В logger.conf задать необходимые каналы: включить файл full и задать желаемые уровни (notice,warning,error,verbose,dtmf и др.);

В CLI для комфортной диагностики повысить подробность: asterisk -rvvvvv   # пять v ≈ уровень 5.

Ротация логов:

• make install-logrotate положит базовый конфиг в /etc/logrotate.d/asterisk;
• целесообразно включить ежедневную ротацию и хранение ~30 файлов; это упрощает поиск проблем по дате и не раздувает единичный лог до десятков гигабайт;
• права в logrotate-конфиге выставлять на пользователя/группу asterisk.

При наличии централизованной системы логирования отправлять туда агрегированные события (CDR/CEL, приложные логи интеграций и т. д.).

Безопасность

• Обязательно ограничивать внешнюю поверхность: отключать ненужные модули, фильтровать доступ к pjsip/http/https/ws/wss/ami/ari.
• Использовать fail2ban в паре с iptables/nftables.
• Отдельно контролировать доступ к AMI/ARI и HTTP-интерфейсу (ACL, пароли, TLS).

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

Запись — одна из самых ресурсоёмких функций (вплоть до диска I/O). Для снижения влияния на звонки:

• в asterisk.conf включить буферизацию в RAM:
• cache_record_files = yes
• record_cache_dir   = /tmp

При завершении вызова записи из RAM переносятся на постоянное хранилище.

• использовать MixMonitor() (универсальнее, чем классический Monitor()); при необходимости сохранять каналы по отдельности и/или пост-обрабатывать их внешним скриптом (склейка, конвертация в mp3).
• проектировать политику хранения и ротации записей заранее.

Реалтайм и интеграции

res_config_* модули позволяют хранить конфигурацию в БД (Realtime), что удобно для динамических сред. Отдельное внимание — интеграциям по AMI/ARI и HTTP (res_curl): чем активнее внешние запросы/ответы, тем выше нагрузка на систему. Планировать ресурсы и очереди обработки соответственно.

Практические заметки по menuselect/CLI

• make menuselect требует достаточно большой терминал; в маленьких окнах интерфейс не стартует.
• При изменении набора модулей: make menuselect → make → make install.
• Списки образцов конфигураций — в configs/samples/; это референс по синтаксису и настройкам всех модулей.

Аппаратные требования (подход)

Астериск сам по себе крайне нетребователен: базовая инсталляция стартует на сотнях мегабайт RAM и одном виртуальном ядре. Нагрузка определяется сценарием:

• запись разговоров, массовые интеграции по AMI/ARI/HTTP, транскодирование кодеков, интенсивный Realtime — основные «пожиратели» ресурсов;
• простая внутренняя телефония без записи и транскодирования работает на скромных конфигурациях;
• заложить резерв под пиковые нагрузки и рост функционала; при виртуализации — мониторить steal-time и I/O.