Как найти причину обрывов звонков в Asterisk

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

1. Что записать до первой команды

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

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

На условной сети «Хрусталь» я бы сначала попросил администратора назвать один внутренний номер и один проблемный внешний вызов, а не присылать скриншот всей панели. Если вопрос требует системно проверить обслуживание IT-инфраструктуры, начинать всё равно стоит с такого короткого описания: оно экономит время и клиенту, и инженеру. Один хорошо зафиксированный обрыв полезнее десятка пересказов «вроде вчера было хуже».

Перед сбором материалов уточните, где хранятся журналы и кто имеет к ним доступ. В типовой установке путь часто находится под /var/log/asterisk, но каталог и состав файлов зависят от сборки, параметров запуска и logger.conf. Нельзя обещать, что всё нужное непременно лежит в full: сперва спросите CLI, какие каналы журналирования настроены, и проверьте временной интервал.

Полезно записать часовой пояс сервера и часовой пояс человека, который сообщает о проблеме. Иначе событие в журнале окажется «раньше» звонка лишь потому, что часы настроены по-разному. Не правьте время во время расследования: сначала сравните системные часы с источником синхронизации и укажите в заявке, в какой зоне дана отметка. Даже небольшое расхождение затрудняет поиск короткого события.

• Время сбоя с часовым поясом и длительность вызова.
• Входящий или исходящий вызов, внутренний номер и транк.
• Симптом отдельно для каждой стороны разговора.

2. Как проверить процесс и CLI Asterisk

Для подключения к уже работающему CLI обычно используют sudo asterisk -rvv. Это подключение к консоли, а не команда запуска или перезапуска службы. Если подключение не состоялось, проверьте состояние службы средствами вашей ОС и права пользователя; не делайте вывод «сервер умер» только по закрытой консоли. На некоторых установках Asterisk запущен в контейнере или управляется панелью, и тогда способ входа будет другим.

В CLI посмотрите core show uptime, core show settings и module show. Эти команды помогают понять, жив ли процесс, как давно он работает и какие модули загружены. Откройте уровень сообщений на время воспроизведения, если он недостаточен: core set verbose 3. После теста верните обычный уровень, согласованный для этой системы. Постоянный подробный debug в рабочей среде — плохая идея: поток сообщений растёт, а полезный сигнал теряется в шуме.

Дальше смотрите не только на общую загрузку, но и на совпадение с конкретным вызовом: CPU, память, дисковое место, ошибки ядра, сетевые потери и сообщения самой службы. top или htop показывают картину в момент проверки, но не доказывают, что именно происходило час назад. Для исторической нагрузки нужны уже имеющиеся метрики ОС или мониторинга. Не существует магического порога CPU, после которого Asterisk обязательно обрывает звонки: важны длительность, пики и корреляция с симптомом.

В «Хрустале» условный план был бы таким: зафиксировать работу процесса, дождаться одного повторяемого вызова и смотреть CLI именно в это время. Если одновременно растёт нагрузка, проверяем, какой процесс её создаёт, а не приписываем вину SIP-регистрациям автоматически. Бесконечные попытки регистрации могут создавать шум и нагрузку, однако утверждение «любой повтор регистрации рвёт разговор» неверно. Сначала ищем совпадающие события и измеряем.

Если служба управляется systemd, состояние можно посмотреть командой systemctl status asterisk; имя службы и способ запуска проверьте на конкретной ОС. Команда не заменяет CLI, зато покажет состояние процесса и недавние сообщения менеджера служб. В Docker, виртуальной АТС или готовом дистрибутиве порядок будет другим. Я не прошу клиента вслепую запускать команды с sudo: сначала выясняем платформу и действуем штатным для неё способом.

• Подключиться к действующему CLI, не перезапуская Asterisk.
• Снять состояние процесса и модулей во время повторения сбоя.
• Сверить текущие ресурсы с историческими метриками, если они есть.

3. Где искать логи и как читать ошибки

Путь /var/log/asterisk/full распространён, но не является обещанием для любой установки. Откройте в CLI logger show channels, затем проверьте logger.conf и каталог журналов в конфигурации конкретного сервера. Asterisk позволяет настраивать имена файлов и уровни сообщений; full будет содержать только то, что направлено в соответствующий канал. Если журнал не включал нужный уровень заранее, задним числом подробностей там не появится.

Фразы вроде registration failed, RTP timeout или all circuits busy — зацепки, а не готовый диагноз. Регистрация может не пройти из-за учётных данных, адреса, ограничений оператора или сетевого пути. Сообщение о занятых линиях само по себе не доказывает ошибку пароля: проверьте ответ транка и контекст вызова. А RTP timeout говорит о событиях медиа, но причину нужно искать с обеих сторон, включая NAT, фаервол и удалённый узел.

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

Если нужных строк нет, выясните, включён ли соответствующий уровень и куда он направляется. Документация Asterisk описывает настройку файловых каналов через logger.conf, просмотр каналов командой logger show channels и включение диагностических уровней в CLI. После краткого воспроизведения верните исходную подробность и отключите временный SIP debug. Диагностика должна оставить следы для разбора, а не гигабайты данных, которые никто не откроет.

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

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

• `logger show channels` — проверить настроенные каналы журналирования.
• Искать вокруг времени сбоя, сопоставляя канал и направление.
• Скрыть пароли, телефоны и внутренние адреса перед передачей.

4. Как отличить SIP-сигнализацию от RTP и NAT

SIP управляет установлением вызова, RTP переносит звук. Поэтому при «вызов проходит, но звука нет» проверяют медиапуть, а при отказе регистрации — обмен SIP и ответ оператора. Граница не абсолютная: некорректные адреса в SDP или политика фаервола могут связать эти симптомы. Важно смотреть на обе стороны соединения и точный сценарий, а не назначать виновником протокол по одному слову в заявке.

Не прописывайте UDP 10000–20000 как универсальный закон. Диапазон RTP задаётся конфигурацией Asterisk и может быть изменён; выясните фактические rtpstart и rtpend в rtp.conf, затем сверяйте их с правилами на хосте, маршрутизаторе и стороне провайдера. Диапазон SIP также зависит от транспорта и конфигурации. Порты 5060/5061 часто встречаются, но это не доказательство, что именно их использует ваша АТС.

Команда nc -zv без уточнения транспорта проверяет TCP-соединение и не подтверждает прохождение UDP-медиа. Успешный ping показывает лишь доступность по ICMP, если тот разрешён; он ничего не говорит о регистрации SIP или фактическом RTP. Для проверки голосового потока нужны журналы/счётчики Asterisk и захват трафика в согласованное время, например tcpdump на нужном интерфейсе с подходящим фильтром. Захват тоже содержит чувствительные метаданные — храните и передавайте его аккуратно.

За NAT проверьте, какие адреса Asterisk объявляет в SIP и SDP. В chan_sip исторически использовали externip и localnet; в PJSIP это другой набор, включая local_net, external_media_address, external_signaling_address, а для удалённых endpoint могут иметь значение rtp_symmetric, force_rport и rewrite_contact. Не копируйте настройки из чужой версии или драйвера. Ошибка объявления частного адреса внешней стороне часто объясняет односторонний звук, но перед правкой подтвердите топологию и фактический SDP.

Проверьте путь целиком: телефон, локальная сеть, NAT, внешний интерфейс, АТС и оператор. Счётчик входящих и исходящих UDP-пакетов на интерфейсе помогает увидеть, где поток исчезает; сравнивать его нужно именно во время тестового разговора. traceroute не покажет весь путь RTP, если промежуточные сети фильтруют ответы, и его молчание не доказывает отказ маршрута. Вывод сетевой команды — улика, но не приговор.

• Сверить фактический RTP-диапазон с `rtp.conf` и сетевыми правилами.
• Проверять SIP и медиапоток раздельно, по одному вызову.
• Для NAT определить драйвер: `chan_sip` или `chan_pjsip`.

5. Что проверить в endpoint, транке и dialplan

Для старого chan_sip команда sip show peers показывает список пиров; для PJSIP используйте pjsip show endpoints. Эти команды не взаимозаменяемы и выводят объекты своего драйвера. Статус конечной точки — только часть картины: отдельно проверьте регистрацию транка, актуальность контакта, адрес назначения и ответы при конкретном вызове. Значение OK не гарантирует, что маршрут звонка, авторизация у оператора и RTP работают без ошибок.

Сравните параметры транка с выданными оператором: имя пользователя, способ аутентификации, адрес сервера, порт и транспорт. Не вставляйте пароль в статью, тикет или командную строку, которая попадёт в историю shell. Если параметры недавно меняли, сначала выясните, перечитал ли нужный модуль конфигурацию; глобальный core restart now для этой проверки не нужен и способен оборвать активные разговоры.

В extensions.conf ищите конкретный маршрут вызываемого номера: контекст, шаблон, переходы Goto/GotoIf, приложение Dial и обработчики ошибок. Проверяйте, куда реально попал вызов: dialplan show <контекст> и запись конкретного вызова дают больше, чем абстрактное предположение о «бесконечной переадресации». Петля в маршруте возможна, но сама команда GotoIf её не создаёт — всё решает логика условий и цель перехода.

После изменения dialplan можно выполнить dialplan reload и убедиться через dialplan show, что новый контекст загружен. Для другой конфигурации способ перечитывания зависит от модуля и версии; не обещайте универсальное «перезапустите всё». Сначала проверьте синтаксис и план отката, затем применяйте точечное действие в согласованное время. Это особенно важно для транка и транспорта: не всякое изменение безопасно перечитывать во время звонков.

В PJSIP состояние endpoint и состояние регистрации транка — отдельные вещи. Для endpoint команда pjsip show endpoint <имя> помогает посмотреть связанные параметры, а состояние регистрации проверяют соответствующей командой регистрации PJSIP в вашей версии и конфигурации. Не переносите синтаксис из старых статей механически. Параметр qualify или похожий механизм доступности тоже не гарантирует качество разговора: он отвечает на отдельный вопрос о доступности узла, а не о прохождении голоса.

• Выбрать CLI-команду согласно загруженному SIP-драйверу.
• Проверить маршрут конкретного вызова командой `dialplan show`.
• Перечитывать только затронутый конфиг поддерживаемым способом.

6. Как собрать заявку вендору без пустых кругов

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

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

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

В «АйТи-Фреш» я сначала отделяю сбой оператора от ошибки на стороне АТС, затем собираю минимально достаточные журналы и проверяю воспроизводимость. На выходе у заказчика остаются описание причины или список проверяемых гипотез, безопасный план исправления и понятный тест после изменений. Если проблема не воспроизводится, это тоже результат: фиксируем условия наблюдения и договариваемся, какие данные собрать при следующем случае. Так поддержка не превращается в соревнование по перезапуску служб.

Для передачи приложите не весь архив телефонии, а небольшой набор с ясными именами файлов: call-time.txt, очищенный фрагмент журнала и заметку с результатами теста. Укажите, кто собрал материалы и когда. Если нужен захват пакетов, заранее согласуйте период и защищённое место передачи. Получатель должен понимать, как воспроизвести симптом и что сравнить; иначе даже большой архив превращается в коробку с проводами без схемы.

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

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