Как установить Asterisk на AlmaLinux и не гадать со звуком

Установка Asterisk из репозитория сама по себе не ломает звонки: проблема зависит от версии, состава пакета, конфигурации и сети. Я покажу, как сначала отделить сбой SIP от проблемы RTP, а затем выбрать пакет или сборку из исходников для AlmaLinux без обещаний «гарантированной совместимости». В разборе использую условный пример «Хрусталь».

Почему пакет из репозитория не равен сломанной АТС

Фраза «поставили через dnf — звонки умерли» звучит уверенно, но это пока не диагноз. Пакет может быть старым, собранным без нужного модуля или обновляться по правилам конкретного репозитория; может оказаться вполне рабочим. Важно установить источник пакета, его версию, список собранных модулей и срок поддержки ветки. Один только способ установки не объясняет обрыв вызова. Стабильность дистрибутива не означает, что в нём лежит самая новая версия каждого приложения; но и слово «репозиторий» не является синонимом «неисправность».

На дату проверки официальная страница Asterisk указывает 22.11.0 как последнюю LTS-версию. В таблице жизненного цикла ветка 13 уже помечена EOL, а ветки 20 и 22 ещё поддерживаются. Это не готовая рекомендация ставить всем одну цифру: совместимость зависит от интеграций, модулей и ОС. Но строить новый сервер на неподдерживаемой ветке без отдельной причины — плохое начало. Поддержка означает получение исправлений проекта; она не гарантирует, что конкретный RPM собран именно так, как требует ваш сценарий.

Я проверяю RPM командой rpm -qi asterisk и смотрю, откуда пакет установлен средствами DNF. Затем сверяю версию с жизненным циклом Asterisk и проверяю доступные модули в CLI. Пакетная установка удобна обновлениями и согласованием файлов с менеджером пакетов; самостоятельная сборка даёт контроль над конфигурацией сборки, но переносит на администратора обновления, службу, права, резервирование и повторяемость. Если нужна помощь с разбором телефонии и инфраструктуры, я начинаю с ИТ-аутсорсинга: сначала фиксируем симптомы и источник пакета, потом меняем систему. Лучше выяснить это до окна обслуживания.

Что проверить, если регистрация есть, а звука нет

Успешная SIP-регистрация говорит лишь о том, что регистрационный обмен прошёл. Она не доказывает, что состоялся вызов, что стороны согласовали общий кодек или что RTP-пакеты проходят в обе стороны. Поэтому я разделяю проверку на этапы: регистрация транка, установление вызова, согласование медиапараметров и двусторонний звук. Если вызов обрывается через пару секунд, фиксирую точное время, направление вызова и выдержку журнала; слова «RTP timeout» из черновика не считаю универсальным сообщением Asterisk и не советую искать его как готовый диагноз.

Для PJSIP официальное руководство по NAT отдельно выделяет local_net, external_media_address и external_signaling_address в объекте транспорта. Эти параметры решают конкретную задачу: сервер за NAT не должен объявлять внешней стороне недоступный частный адрес в SIP/SDP. При этом набор значений определяется реальной схемой сети и тем, кто выполняет NAT. Диапазон RTP тоже берут из настроек именно этого сервера и открывают согласованно с межсетевым экраном и маршрутизатором; универсальный порт по одной статье назначать нельзя.

Если регистрации нет, проверяю журнал запуска, загружен ли endpoint, его тип, аутентификацию и AoR; если регистрация есть, а аудио одностороннее — смотрю адрес и порт медиа в SDP, маршрут ответных пакетов, NAT и правила firewall. Для PJSIP можно включить pjsip set logger on на время диагностики и после сбора данных выключить. Так мы видим обмен сигнализацией, но этот лог сам по себе не доказывает прохождение RTP. В статье про настройку PJSIP в Asterisk полезно разобрать структуру объектов отдельно. Если одновременно менять кодеки, транспорт и правила фильтрации, найти причину станет заметно труднее.

Когда оправдана сборка Asterisk из исходников

Сборка из исходников полезна, когда нужна версия или функция, которой нет в выбранном пакете, когда требуется управлять набором модулей или когда пакет не подходит к утверждённой схеме обновления. Это решение с ценой сопровождения. Мы сами должны знать источник и контрольную версию кода, хранить параметры сборки, повторять процедуру на тестовом узле и понимать, как обновить или откатить систему. «Собрали один раз и забыли» — не план сопровождения, а способ отложить неприятный разговор.

В официальной документации последовательность устроена так: распаковать исходники, запустить ./configure, устранить обнаруженные недостающие зависимости, повторить проверку, затем вызвать make menuselect и выбрать необходимые модули. configure проверяет доступные библиотеки и готовит сборку под систему; набор библиотек зависит от нужных функций, поэтому короткий список gcc make openssl-devel libedit-devel не является полным рецептом для каждой версии и набора модулей. У Asterisk есть сценарий contrib/scripts/install_prereq, который помогает установить зависимости на поддерживаемых системах, но и его нужно применять с учётом версии и ОС.

Перед компиляцией я фиксирую release series и сверяю её с официальной таблицей поддержки, а не беру расплывчатую «последнюю стабильную» из случайного архива. После make menuselect проверяю, что выбран нужный SIP-драйвер и другие функции проекта. PJSIP — штатный SIP-драйвер Asterisk; однако фраза «выберите PJSIP и RTP» слишком груба: наличие медиатранспорта не гарантирует корректную маршрутизацию или совместимость с оператором. Компиляция не добавляет волшебно отсутствующие кодеки и не исправляет ошибочные адреса в SDP. Модуль должен существовать, быть собран и загрузиться; проверять нужно все три условия.

Установка, служба и проверка после сборки

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

Черновик ошибочно обещал «перезапустить службу Asterisk» после make install, как будто имя и способ регистрации службы универсальны. В документации Asterisk для установки сценария инициализации упоминается make config; поддержка зависит от дистрибутива, а современные системы могут использовать собственное управление systemd. Сначала выясните, каким способом запущен текущий экземпляр, затем применяйте подходящий для вашей ОС сценарий и проверяйте его после перезагрузки в тестовом окне. Не запускайте второй экземпляр вручную поверх уже работающего сервиса: это не метод диагностики.

В CLI проверяю core show version, module show like res_pjsip и pjsip show endpoints. Команда asterisk -rx 'module show' в исходном тексте была неполной как проверка: общий перечень модулей не подтверждает ни регистрацию транка, ни двустороннее аудио. Затем делаю исходящий и входящий тестовый вызов, записываю результат, проверяю слышимость в обе стороны и сопоставляю журнал Asterisk с сетевым наблюдением на границе. Если выбранный кодек не общий для двух сторон, корректировка списка allow должна следовать требованиям оборудования и оператора. Никаких «включить все кодеки на всякий случай».

SELinux, firewall и обновления без мифов

В черновике SELinux был объявлен причиной блокировки сети по умолчанию и предлагалось временно отключить его. Без конкретного сообщения AVC это догадка. Сначала проверьте журнал аудита и контекст файлов, выясните, действительно ли SELinux запретил нужное действие, и применяйте точечную политику, если она необходима. Не копируйте команду из чужого руководства только потому, что в ней есть setsebool: конкретный параметр должен соответствовать версии политики и вашему сценарию. Отключение защиты не объясняет, почему SIP или RTP не проходят, и убирает полезный слой контроля.

На firewall проверяю фактические порты сигнализации и диапазон RTP из конфигурации Asterisk, адреса источника и назначения и правила обратного направления. Не открываю «всё для SIP» и не публикую административный CLI наружу. NAT и firewall — разные звенья цепочки; корректный внешний адрес в PJSIP не создаст разрешающее правило маршрутизатора. Если нужно разобрать основу маршрутизации вызова, посмотрите как устроен dialplan Asterisk. Изменения делаю по одному и проверяю тем же тестовым вызовом.

Обновление сначала проходит на тестовом узле или в согласованное окно с резервной копией конфигурации и понятным откатом. Проверяю changelog и статус ветки у проекта, зависимости и поведение используемых модулей. Сам факт наличия обновления не требует немедленной пересборки в рабочее время; но годами оставлять EOL-ветку тоже нельзя. Если уязвимость относится к конкретному модулю или конфигурации, оцениваю применимость по первичному бюллетеню Asterisk, а не пугаю клиента абстрактными «атаками на RTP». В этой статье нет CVE, потому что для общего сбоя звонков номер уязвимости не нужен.

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

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