Asterisk на AlmaLinux: почему 19 и 20 уже не равны

Если выбирать строго между Asterisk 19 и 20, для новой установки не подходит ни одна: ветка 19.x снята с поддержки, а 20.x с 19 октября 2026 года получает только исправления безопасности и завершит поддержку 19 октября 2027-го. Я бы сначала проверил совместимость ОС и приложений, затем выбрал активную LTS-ветку и проверил переход на копии.

Asterisk 19 или 20: короткий ответ по срокам

Если задача — выбрать ветку для новой АТС на AlmaLinux, выбирать между 19 и 20 уже поздно. По таблице проекта Asterisk, 19.x — стандартная ветка, её поддержка закончилась 2 ноября 2023 года. Asterisk 20.x — LTS: полная поддержка завершилась 19 октября 2026 года, после чего остаются исправления безопасности до 19 октября 2027-го. Значит, 20 ещё может быть разумным этапом миграции для уже работающей системы, но ставить её сейчас с расчётом на долгую жизнь — короткий горизонт. Даты здесь важнее слова LTS на коробке.

Для новой установки смотрю на действующие ветки в официальной таблице релизов и на то, что поддерживает ваша платформа и прикладная сборка. В проверенной таблице 22.x обозначена как LTS с полной поддержкой до 16 октября 2028 года и исправлениями безопасности до 16 октября 2029-го. Обратите внимание: жизненный цикл версии и совместимость с конкретной оболочкой, телефоном, платёжным модулем или сторонним приложением — разные проверки. Я не обещаю, что переход на 22 пройдёт без адаптации; сначала сверяю требования и проверяю сборку на том же дистрибутиве.

У Asterisk различаются LTS- и стандартные ветки. LTS получает четыре года полной поддержки и ещё год обслуживания безопасности; стандартная ветка живёт меньше. Точный статус меняется со временем, поэтому перед работами открываю таблицу проекта, а не статью, опубликованную пару лет назад. Ветка может быть ещё не EOL, но уже получать только security fixes. Это не мелкая сноска: такой статус влияет на план обновлений и на то, кто будет исправлять найденную проблему.

Для небольшого офиса я свожу решение к трём вопросам: на какой срок строим телефонию, какие модули и интеграции обязательны, кто отвечает за сборку и обновления. Если систему нельзя регулярно обновлять, это не аргумент в пользу старой версии — это повод уменьшить число зависимостей и заложить окно обслуживания. Можно начать с аудита телефонии и инфраструктуры, если внутри нет администратора, который проверит конфигурацию и откат.

• 19.x — EOL с 2 ноября 2023 года.
• 20.x — security fixes до 19 октября 2027 года.
• 22.x — LTS по таблице проекта; проверьте статус перед внедрением.

Что AlmaLinux меняет в установке и поддержке

AlmaLinux часто выбирают как совместимую с RHEL систему, но из этого нельзя выводить, что проект Asterisk официально тестирует каждую её версию. Документация Asterisk называет поддерживаемыми платформами актуальные CentOS, RHEL, Fedora, Ubuntu и Debian; прочие дистрибутивы обслуживаются по принципу best effort. AlmaLinux не перечислен в этом списке. Это не означает, что Asterisk на нём не запустится. Это означает, что при проблеме нельзя автоматически рассчитывать на поддержку проекта так же, как на явно названной платформе.

Установка из исходников даёт контроль над выбранными модулями и зависимостями, но переносит ответственность на того, кто собирает и обновляет систему. Сценарий установки из пакетов, Asterisk-базированная платформа и собственная сборка — три разных процесса. Нельзя взять инструкцию для Ubuntu, механически заменить пакетный менеджер на dnf и считать результат поддерживаемым. Перед сборкой проверяю требования нужной ветки, компилятор, библиотеки и доступность нужных модулей на целевом AlmaLinux. Команда configure может обнаружить часть отсутствующих зависимостей, а menuselect показывает, какие модули не соберутся из-за них.

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

Не смешивайте тест и продакшен по привычке: тестовый узел должен повторять целевую ОС, архитектуру, способ установки и список модулей. Если production собран из исходников, а проверка сделана на чужом готовом образе, это не проверка миграции. Это проверка другого продукта. В моих проектах именно такой разрыв между стендом и боевым узлом часто делает «успешный тест» бесполезным.

Кодеки и модули: где искать настоящую причину сбоя

Переход на Asterisk 20 сам по себе не означает, что сервер внезапно исключит старые кодеки из конфигурации. Доступные кодеки зависят от собранных модулей, библиотек и настроек конечной точки. В PJSIP разрешённые форматы задаются для endpoint; телефон или шлюз тоже предлагает свой набор. Для конкретного вызова важно пересечение возможностей сторон и выбранная логика согласования. Поэтому фраза «новая версия поменяла кодеки по умолчанию» без проверки конфигурации, сборки и SIP/SDP — не диагноз, а догадка.

Ответ SIP 488 Not Acceptable Here действительно может появиться, когда согласовать параметры предложения невозможно, в том числе при несовпадении кодеков. Но он не доказывает, что проблема именно в версии Asterisk. Я проверяю, какие форматы предложил абонент, что разрешено в его endpoint, загружен ли нужный codec-модуль и как устроена маршрутизация медиа. При необходимости сверяю конфигурацию PJSIP и журнал переговоров. Менять список кодеков наугад опасно: можно исправить один тип вызова и сломать другой, например транскодирование на шлюзе.

Ветку 19 не стоит выбирать ради Opus или G.729: поддержка формата не привязана к маркетинговому ярлыку одной ветки. В Asterisk часть модулей собирается только при наличии нужных библиотек; G.729 может требовать отдельного коммерческого решения. В самой системе состояние форматов и преобразований можно проверить командой core show translation, но она не заменяет тестовый звонок через реальные телефоны, транк и запись разговора. Проверяйте те сценарии, которыми пользуются люди, а не только зелёный статус сервиса.

Сторонние модули требуют отдельной проверки совместимости и версии. Официальная инструкция обновления прямо советует проверять обновления внешних модулей и полноценно тестировать dialplan. Если модуль собран против другой версии Asterisk, одного факта, что его файл лежит на диске, недостаточно. Проверяю загрузку модуля в CLI, его зависимости и реальный вызов, который от него зависит. Для собственных модулей нужны исходники и повторная сборка под целевую ветку. Отдельно можно сверить основы диалплана Asterisk, если при переносе обнаружились приложения и сценарии, завязанные на старую логику вызовов. Чек-лист без этих проверок — просто список пунктов для галочки.

• Сверьте codec-модули в сборке и форматы endpoint.
• Проверьте SIP/SDP для неудачного вызова.
• Обновите сторонние модули и испытайте dialplan.

План миграции: стенд, проверка, окно переключения

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

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

Веду список изменений и результатов: входные условия, что поменяли, какие тесты прошли, что осталось ограничением. Если менялись кодеки, фиксирую согласованный набор на телефонах, endpoint и шлюзе. Если заменён модуль — отмечаю его версию и зависимость. Официальная документация предупреждает, что обновление может затронуть примеры конфигураций; не копируйте новые sample-файлы поверх рабочего каталога без сравнения. Настройки menuselect.makeopts тоже сохраняю: они помогают восстановить выбранный состав сборки, хотя не гарантируют переносимость между разными ветками.

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

Как разбирать проблемы после обновления

В условном сценарии студии «Жасмин-Сервис» я бы начал не с переписывания нескольких сотен строк, а с фактов: какая версия Asterisk работала до изменения, откуда установлена сборка, какие модули загружены, какой endpoint не дозвонился и что видно в SIP/SDP. В исходной истории причина была объявлена как «новые кодеки по умолчанию», но для такого вывода нет технических данных. Поэтому использовать этот эпизод как доказанный клиентский кейс нельзя. Имя здесь задаёт только условный пример; цифры простоя и якобы состоявшиеся работы я не приписываю реальному клиенту.

Если звонок получает 488, сравните предложенные и разрешённые форматы, наличие codec-модуля и настройки транскодирования. Если вызов не доходит до dialplan, ищите раньше: регистрацию, идентификацию endpoint, ACL и маршрутизацию. Если вызов устанавливается, но нет звука, отдельно разбирайте медиапуть, NAT и RTP. Один симптом может появиться на разных этапах, поэтому сначала сопоставьте время звонка с журналом, а затем проверяйте конкретную гипотезу. Статус «Asterisk запущен» говорит только о процессе, но не о работоспособности телефонии.

После исправления повторите исходный тест и соседние сценарии. Например, смена списка разрешённых форматов требует проверки не одного проблемного абонента, а также исходящего направления, транка и записи, если они участвуют в маршруте. Изменение pjsip.conf проверяйте с учётом того, какие настройки применяются динамически, а какие требуют перезапуска; сверяйтесь с документацией вашей ветки. Не пересобирайте всю систему только потому, что это звучит основательно. Если причина в неполном списке модулей или неверной конфигурации endpoint, пересборка добавит риск и не исправит исходную ошибку.

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

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