Как найти причину, если Asterisk не проводит звонок

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

Служба работает, но сокет или CLI недоступен

Сначала проверьте, запущен ли процесс и какую именно ошибку сообщает система. В systemd-системе выполните systemctl status asterisk, затем изучите журнал через journalctl -u asterisk. Эти команды работают только если установщик действительно создал unit с таким именем. При установке из исходников способ запуска зависит от выбранных параметров сборки и установочного сценария: unit может лежать не в /etc/systemd/system, а в другом каталоге systemd или вовсе отсутствовать. Поэтому сообщение Unit asterisk.service not found говорит лишь о том, что systemd не нашёл unit по этому имени; оно само по себе не доказывает, что Asterisk не установлен. Проверьте, как именно его устанавливали и запускают, прежде чем создавать новый сервис поверх существующей схемы. На машине с несколькими экземплярами Asterisk проверяйте сокет именно того процесса, который обслуживает этот вызов. Сверьте PID, командную строку запуска и владельца сокета; одинаковое имя службы не гарантирует, что вы смотрите на нужную инстанцию. Не удаляйте сокет вручную, пока процесс жив: это может затруднить диагностику и не исправит исходную причину.

Если CLI не подключается, отдельно выясните путь к control socket и права на него. /var/run обычно является временной файловой системой, поэтому каталог Asterisk там может создаваться при старте и исчезать после перезагрузки. Владельца и права задают механизм запуска и параметры конкретной установки; не назначайте владельца asterisk вслепую и не исправляйте всё широким chmod. Сверьте пользователя процесса, настройки каталога и сообщение об ошибке в журнале. Если служба активна, но клиентская команда asterisk -r не подключается, это ещё не проблема регистрации SIP: сначала нужен доступ к работающей консоли. В случае студии «Ритм-Плюс» я бы проверял именно этот слой, а не переписывал диалплан без признаков его ошибки. Попросите оператора подтвердить ожидаемый формат имени пользователя и адрес регистрации, если журнал показывает отказ с его стороны. Ответ 401 в SIP может быть обычным запросом аутентификации, а повторный отказ после него уже требует проверки учётных данных и настроек. Оценивайте последовательность обмена целиком, а не одну строку без контекста.

• Проверить фактический способ запуска
• Сверить журнал и состояние процесса
• Проверить сокет и права его каталога

SIP-регистрация: отдельно телефон, отдельно транк

Статус «Подключено» на телефоне обычно описывает связь самого устройства с сетью или регистрацию его учётной записи. Он не подтверждает, что Asterisk зарегистрировал исходящий транк у оператора, и не гарантирует, что входящий вызов сопоставлен с нужным endpoint. Сначала определите, какой сценарий сломан: телефон не регистрируется на АТС, АТС не регистрирует транк или операторский вызов не распознаётся. Эти три случая требуют разных проверок. В CLI включите целевой уровень журналирования PJSIP и посмотрите, какой ответ приходит на запрос: тайм-аут, отказ аутентификации и успешная регистрация — разные улики, а не повод заново вводить все пароли. На входящем вызове отдельно проверьте сопоставление источника SIP-запроса с endpoint: наличие регистрации телефона не обязательно участвует в таком сопоставлении транка. Команда pjsip show endpoints поможет увидеть загруженные endpoint, а pjsip show endpoint <имя> — параметры выбранного объекта. Секреты из конфигурации в переписку не копируйте.

Для исходящих регистраций PJSIP официальная команда просмотра — pjsip show registrations; команда показывает состояние каждой настроенной регистрации. Для деталей используйте pjsip show registration <имя>. В старом драйвере chan_sip команда sip show peers показывает пиры, но не переносите её на PJSIP: это разные драйверы и интерфейсы CLI. Если регистрация не нужна по схеме оператора, отсутствие записи не является ошибкой само по себе. Сверьте адрес сервера, имя пользователя, секрет, транспорт и параметры, которые выдал провайдер, затем сопоставьте ответ оператора с журналом. Не публикуйте пароли и SIP-заголовки с учётными данными в заявках на поддержку. Для проверки используйте один известный номер и ожидаемый контекст, а не набор случайных тестов. Команда dialplan show <контекст> показывает активные правила после загрузки; это полезнее, чем читать только файл, который мог быть не включён в конфигурацию или перекрыт другим источником диалплана. Сначала сравните активное состояние с тем, что вы намеревались настроить.

• Определить сторону регистрации
• Для PJSIP выполнить pjsip show registrations
• Сверить ответ оператора с журналом

Диалплан решает, куда направить вызов

Успешная регистрация не создаёт маршрут автоматически. В обычной конфигурации статический диалплан описан в extensions.conf, чаще всего в каталоге /etc/asterisk, но реальный путь зависит от astetcdir и способа установки. Проверьте контекст, в который попадает входящий вызов, и контекст, назначенный endpoint для исходящего набора. Затем убедитесь, что в нужном контексте есть совпадающий шаблон номера и действие, которое отправляет вызов дальше. Если вызов появляется в журнале, но Asterisk сообщает, что extension или context не найден, это уже конкретный след маршрутизации. Если вызов вообще не виден, вернитесь к SIP-сигнализации: правка extensions.conf не исправит пакет, который до АТС не дошёл. Параллельно смотрите, где виден пакет и какие адреса объявлены сторонам: если RTP выходит с АТС, но не возвращается, ищите потерю по маршруту и фильтрацию; если SDP уже содержит неверный адрес, начинайте с конфигурации Asterisk. Для временной диагностики используйте контролируемый тестовый вызов и ограниченный захват трафика, затем удалите диагностические файлы по внутренним правилам хранения.

После изменения файла не нужно без разбора перезапускать службу. В Asterisk CLI выполните dialplan reload, затем проверьте результат командой dialplan show <контекст>. Это позволяет увидеть, загрузились ли нужные правила. pjsip reload относится к перезагрузке конфигурации PJSIP и не является универсальной заменой обновлению диалплана; core reload тоже не следует советовать как обязательную команду для любой правки. Если dialplan show не отображает ожидаемое правило, проверьте синтаксис, подключение дополнительных файлов через #include и правильность контекста. Перед редактированием сохраните копию конфигурации. Один тестовый исходящий и один входящий вызов дадут больше информации, чем многократное «перезапустить всё». Внешний адрес, локальные подсети и проброс портов должны совпадать с фактической топологией; при двойном NAT, SIP-прокси или раздельных сетях медиаданные могут идти иным путём. Документация Asterisk отдельно предупреждает, что пример NAT подходит не каждой схеме. Поэтому перенесённый из статьи блок конфигурации без адресов и условий часто вреден: измерьте маршрут и адаптируйте настройки к своей сети.

• Найти контекст вызова
• Проверить совпадение номера и маршрута
• Перезагрузить диалплан и показать контекст

Соединение есть, звука нет: проверяем RTP и NAT

Если вызов устанавливается, но звука нет или слышит только одна сторона, сигнализация уже прошла достаточно далеко; теперь проверяйте согласование и прохождение медиапотока RTP. Сверьте адреса в SDP, сетевые маршруты и правила межсетевого экрана на всём пути между АТС и устройствами. В документации Asterisk для типового сценария за NAT приведён RTP-диапазон UDP 10000–20000, но это пример значения по умолчанию, а не приказ открыть его на каждом сервере. Фактические границы задаются в rtp.conf и могут быть изменены. Откройте только настроенный диапазон и только на нужных направлениях, предварительно сверив его с правилами маршрутизатора и firewall. Сохраните вывод версии и список загруженных модулей вместе с точным временем тестового вызова. Это отделит ошибку сборки от проблемы конфигурации и поможет сопоставить сообщения разных журналов. Если пакет обновлялся недавно, сравните состояние с предыдущей версией и проверьте журнал пакетного менеджера; не обновляйте библиотеки вручную поверх управляемой установщиком системы.

Для chan_pjsip параметры NAT не сводятся к одной галочке. Документация описывает local_net, external_media_address и external_signaling_address в транспортном объекте, а также поведение endpoint, например direct_media, в зависимости от топологии. Не копируйте публичный адрес из чужого примера и не добавляйте эти параметры в сеть, где они не нужны: неверный SDP способен закрепить проблему. В старом chan_sip синтаксис и набор опций отличаются, поэтому сначала определите активный драйвер. Сравните SDP с реальными адресами, проверьте захват пакетов на АТС и на границе сети. Кодеки тоже важны, но проверять их стоит по факту неудачного согласования, а не считать причиной любого молчания. «Звук пропал — откроем все порты» не диагностика, а лотерея. Для сборки не смешивайте заголовочные файлы и библиотеки от разных выпусков. Скрипт contrib/scripts/install_prereq доступен для сценариев сборки из исходников, но набор требуемых пакетов определяется платформой. После компиляции проверьте, что запускается установленный бинарный файл, а не оставшийся экземпляр из другого каталога. Такой контроль особенно полезен, когда версия в CLI не совпадает с ожиданием администратора.

• Сверить SDP и реальный RTP
• Уточнить диапазон в rtp.conf
• Настроить NAT для активного SIP-драйвера

Сборка, пакеты и конфигурация установки

Когда служба падает после обновления или часть модулей не загружается, проверьте версию Asterisk, источник пакета и журнал сборки. Не существует универсальной рекомендации установить Asterisk только на Ubuntu, Debian, CentOS или FreeBSD: поддержка зависит от выбранной ветки Asterisk, версии ОС и конкретного способа поставки. Пакет дистрибутива, сторонний репозиторий и установка из исходников могут отличаться версиями, набором модулей, путями конфигурации и способом управления процессом. Зафиксируйте эти сведения до ремонта. Для исходников используйте инструкции именно для выбранного релиза; список библиотек и команд сборки меняется. build-essential — пакет Debian-подобных систем, а не универсальная зависимость для любой ОС. Не делайте вывод о неисправности только по отсутствию сообщения в одном файле: модуль логирования, уровень детализации и каталог журналов зависят от конфигурации. Сначала подтвердите, куда именно пишет этот экземпляр Asterisk, и включите нужную диагностику на короткое время. Так вы получите воспроизводимый след и не утонете в лишних данных.

Если проблему вызвало обновление, найдите первый конкретный отказ в журнале: не загруженный модуль, отсутствующую библиотеку, ошибку конфигурации или несовместимый пакет. Сверьте, откуда установлен бинарный файл и какая версия конфигурации осталась на диске. Не добавляйте packages.asterisk.org автоматически: сначала проверьте официальный способ поставки для своей платформы и выбранной версии, а также то, не управляет ли Asterisk уже установленная PBX-сборка. После исправления проверьте состояние службы, загрузку требуемых модулей и один вызов в каждом нужном направлении. Перезапуск допустим как действие по конкретному плану, но он не заменяет выяснение причины. Если звонок всё ещё не проходит, сохраните временную метку, номер контекста и относящиеся к вызову строки журнала без секретов — этого достаточно, чтобы продолжить разбор предметно. После изменения проверяйте не только успешный запуск команды reload, но и реальный результат вызова: набранный номер, направление маршрута, сигнал ответа и двусторонний звук. Удачная загрузка конфигурации подтверждает синтаксис и применение части настроек, но не доказывает, что оператор принимает вызов или сеть доставляет RTP. Запишите, что именно проверено, чтобы следующая смена не повторяла круг с нуля.

• Зафиксировать версию и источник установки
• Найти первую ошибку в журнале
• Проверить модули и тестовые вызовы

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