Почему сборка Asterisk не запускает звонки

Сборка Asterisk сама по себе не роняет звонки: проблема появляется, когда не собран нужный модуль, сломалась установка или перепутана ошибка DAHDI с ошибкой АТС. Показываю, как различить эти случаи, проверить зависимости и повторить сборку без рискованной очистки системы.

Сборка из исходников нужна не всегда

Сборка из исходников дает контроль над версией и набором модулей. Это полезно, когда конкретная функция не включена в пакет дистрибутива или нужно зафиксировать состав установки. Но команда apt install asterisk сама по себе не означает устаревшую АТС и не доказывает отсутствие PJSIP. Пакеты сопровождают дистрибутивы, их версии и сроки обновления различаются; официального репозитория пакетов Asterisk нет. Сначала я проверяю версию пакета, доступные модули и поддержку нужной системы, а уже потом выбираю способ установки. Сравнение сценариев для Debian есть в материале ставить Asterisk из репозитория или собирать.

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

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

Отдельно проверяю, как новую сборку будут обновлять и запускать. При пакетной установке за обновление отвечает пакетный менеджер; исходная сборка требует своего учета версии, параметров и способа запуска. Если это не записать, следующий администратор не поймет, какой Asterisk обслуживает телефоны и какие файлы можно менять. Поэтому до переноса готовлю короткую карточку: версия, источник установки, выбранные модули, расположение данных и проверенный способ возврата. Это скучная часть работы, зато она дешевле неожиданного простоя.

configure не находит библиотеку

Скрипт configure проверяет систему и готовит исходники к сборке. Когда он останавливается на недостающей библиотеке или заголовке, это еще не поломка звонков: Asterisk пока не установлен или собран не полностью. Сначала читаю первую конкретную ошибку, а не последнюю строку вывода. Имена пакетов зависят от дистрибутива: в Debian-подобных системах часто встречается суффикс -dev, в системах семейства Red Hat — -devel. Поэтому libssl-dev и libsqlite3-dev нельзя выдавать за универсальный обязательный список для каждой версии и каждого набора функций.

В каталоге исходников есть contrib/scripts/install_prereq. Режим test печатает команды установки зависимостей, а install просит скрипт установить пакетные зависимости средствами системы. Я сначала смотрю список, сверяю его с политикой сервера и только затем запускаю установку. Так видно, что именно появится в системе; волшебной кнопки, которая понимает все локальные ограничения, здесь нет.

После установки недостающей зависимости запускаю configure еще раз и проверяю, что прежняя ошибка исчезла. Это прямо важнее, чем сразу переходить к make: иначе система продолжит сборку с теми возможностями, которые смогла обнаружить. Если configure раньше запускали несколько раз и результат выглядит закэшированным, документация Asterisk предлагает очистить данные сборки командой make distclean, а затем снова запустить configure. Делать это следует в каталоге исходников и с пониманием, что удаляются результаты подготовки и сборки.

После успешного configure перехожу к выбору модулей. В Asterisk для этого предусмотрен menuselect: он показывает доступные компоненты и помогает включить то, что действительно нужно конкретной АТС. Здесь полезно проверить не только наличие PJSIP в списке, но и то, что нужные модули отмечены для сборки. Доступность функции зависит от зависимостей и выбранной конфигурации. Установить все подряд — не значит получить более надежную телефонию; это только увеличивает объем того, что придется сопровождать.

Если configure завершился успешно, а make падает уже на исходном коде, вернитесь к первой ошибке компилятора. Поздние сообщения часто лишь повторяют следствие: один заголовок не найден, затем не собирается файл, который от него зависит, а в конце рушится цель целиком. Сохраните вывод, версию исходников и сведения о системе. Не подменяйте эту диагностику повторной установкой случайных библиотек: сначала установите, какого именно файла не хватает и относится ли он к обязательному компоненту или выбранной опции.

Заголовки ядра нужны DAHDI, а не каждой АТС

Отсутствие заголовков ядра — отдельная история. Они нужны, когда собирается внешний модуль ядра, например драйвер DAHDI для традиционного телефонного оборудования. Это не универсальная зависимость самого Asterisk. Если у вас SIP-телефоны и транк работают через PJSIP, установка DAHDI только ради сборки Asterisk не требуется. В документации проекта отдельно сказано, что DAHDI можно не устанавливать, если нет традиционного телефонного оборудования и не используется приложение MeetMe.

Для DAHDI нужен подготовленный набор для конкретного ядра: не просто похожий пакет, а build tree с конфигурацией и файлами, соответствующими версии запущенного ядра. В Debian и Ubuntu пакет обычно называется linux-headers с версией из uname -r; в Fedora и системах семейства RHEL используется соответствующий kernel-devel. Названия и доступность зависят от дистрибутива, поэтому команду из чужого руководства нельзя копировать вслепую.

Если сборка DAHDI жалуется на kernel build tree, я сверяю текущую версию ядра, наличие соответствующего пакета и ссылку на каталог сборки в /lib/modules. Если репозиторий предлагает заголовки для более нового ядра, может потребоваться обновить само ядро и перезагрузить сервер, чтобы версии совпали. Но не нужно задерживать запуск обычной SIP-АТС из-за заголовков, которые ей не требуются. Ошибка драйвера и ошибка Asterisk — разные неисправности, хоть обе и появляются после make.

DAHDI собирается и устанавливается как отдельный компонент. Его модули ядра и пользовательские инструменты решают разные задачи, поэтому успешная компиляция Asterisk не подтверждает, что драйвер оборудования установлен, а ошибка сборки драйвера не доказывает, что не соберется SIP-АТС. Для аппаратных карт сверяйте требования конкретного драйвера с используемым ядром и дистрибутивом. После обновления ядра проверьте, не нужно ли пересобрать внешний модуль: именно на этой границе старый драйвер может перестать загружаться.

make install не лечит старую установку

Команда make компилирует выбранные компоненты, а make install устанавливает собранные программу и модули. Если установка пишет об отказе в доступе к системному каталогу, проверьте права и заданный префикс установки. Для системного пути установку обычно выполняют с правами администратора, например sudo make install, после успешной сборки. При этом ошибка доступа не означает, что бинарник «остался в домашней папке»: это нужно проверять по выводу установки и фактическому пути программы.

Не смешивайте очистку каталога сборки с удалением работающей АТС. make clean удаляет созданные make файлы, а make distclean глубже очищает результаты make и configure. Цель make uninstall-all — совсем другое: она удаляет не только программу, но также конфигурацию Asterisk, каталоги spool и журналы. Это не штатный способ убрать следы неудачной компиляции. Если прежняя установка нужна, сначала сохраните настройки и записи, выясните способ установки и составьте план замены.

Есть еще одна команда, которую я не запускаю автоматически после make install: make samples. Она устанавливает примеры конфигурации и перезаписывает существующие файлы настроек. На новом тестовом стенде это может быть уместно, на действующей АТС — способ внезапно заменить рабочий dialplan демонстрационным. Перед обновлением сверяйте текущую конфигурацию с резервной копией и проверяйте, какие именно файлы изменит выбранный шаг.

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

Различайте и команду make clean, и make distclean, и цели удаления установленной программы. Первые предназначены для артефактов в каталоге исходников; distclean также сбрасывает подготовку configure. uninstall и uninstall-all действуют на установленную систему, причем последняя цель удаляет конфигурацию и данные Asterisk. Перед любой целью удаления сверяйтесь с документацией именно вашей версии и проверьте резервную копию. Название команды — плохая замена пониманию ее последствий.

Условный разбор: ООО «Ирбис»

Возьмем заданный для разбора сценарий ООО «Ирбис»: configure не находит зависимости, сборка DAHDI останавливается на заголовках, затем make install получает отказ в доступе. Без версии дистрибутива, версии Asterisk и полного журнала нельзя честно назвать один пакет или приписать решению точный срок. Я не буду заменять эти данные эффектной цифрой. Сначала отмечаю, на каком этапе возникла первая ошибка, и проверяю, относится ли она к Asterisk или к отдельному драйверу.

Дальше порядок такой: для configure проверяю список зависимостей через install_prereq test, устанавливаю нужные пакеты и повторяю configure. Для DAHDI подтверждаю, что в задаче действительно есть традиционное оборудование или MeetMe, затем сверяю build tree с работающим ядром. Для make install читаю путь и объект отказа, проверяю права и способ предыдущей установки. Только после этого повторяю конкретный шаг — не удаляю весь Asterisk «на всякий случай».

После установки проверяю, что сервис Asterisk запущен, а нужные PJSIP-модули и endpoints доступны в CLI. Команды pjsip show endpoints и pjsip show registrations помогают увидеть загруженные endpoints и состояние регистрации транка; они не заменяют контрольный вызов. Если endpoint отсутствует, ищу сообщение о загрузке конфигурации в журнале. На этом этапе уже можно отделить проблему сборки от неверных параметров SIP и сетевого пути.

Для такого разбора я сохраняю три вещи: первую ошибку configure или компилятора, сведения о версии дистрибутива и ядра, а также способ, которым установлена прежняя АТС. Это позволяет отличить отсутствующий пакет от неподходящих заголовков DAHDI и от простого отказа в доступе на этапе установки. Если этих данных нет, правильный результат диагностики — список проверок, а не уверенный рассказ о том, что «все заработало за пару часов».

Проверяйте звонок, а не только компиляцию

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

Перед вводом в работу проверяю запуск Asterisk, появление нужных PJSIP endpoints, регистрацию транка и реальный входящий и исходящий контрольный звонок. Затем убеждаюсь, что слышны обе стороны и настройки переживают перезапуск. Если нужна инструкция именно по SIP-настройкам, отдельно разбираю настройку PJSIP в Asterisk. Компиляция без этого шага — лишь зеленая строка в терминале.

В рабочей АТС я также заранее фиксирую способ отката: какую версию возвращать, как восстановить конфигурацию и где хранятся записи. Тогда неудачная сборка остается технической задачей, а не ночным расследованием. Шутка короткая: make завершился успешно — телефон от этого еще не зазвонил. Звонок проверяется звонком.

Проверки делаю по уровням. Сначала убеждаюсь, что установленная программа запускается и сервис остается активным после перезапуска. Затем проверяю нужные endpoints и регистрации PJSIP, а после этого провожу контрольный вызов по каждому важному маршруту: внутреннему, входящему и исходящему. Во время разговора слушаю обе стороны и проверяю, что вызов завершился штатно. Один успешный вызов не проверяет все сценарии, но отсутствие такого звонка не дает права называть телефонию готовой.

Когда тесты пройдены, оставляю оператору понятную запись: какой вариант сборки установлен, какие модули нужны, что проверено и как вернуть прежнее состояние. Для следующего обновления этот список становится отправной точкой, а не поводом повторить команды из истории терминала. Если меняется ядро и используется DAHDI, отдельно планируйте проверку совместимости драйвера. Если меняется только модуль Asterisk, повторяйте функциональные проверки телефонии. Так у каждого изменения есть конкретная область проверки.

Если endpoint не появился в списке, Asterisk мог не принять его конфигурацию при запуске. Тогда я проверяю журнал и исправляю указанную ошибку, а не пересобираю программу вслепую. Статус Unavailable у видимого endpoint — это состояние связи с устройством; он не доказывает, что модуль не скомпилировался. Сверяю ожидаемую схему подключения и делаю контрольный вызов. Ошибку сборки, конфигурации и связи нельзя смешивать в один диагноз. Результат каждой проверки фиксирую перед следующим изменением.

Частые вопросы