Диагностика ARI: путь вызова от Stasis до CRM

Когда звонок виден в Asterisk, но не появляется в CRM, проверяйте цепочку по этапам: диалплан передал канал в Stasis, ARI отправил событие по WebSocket, приложение обработало его и записало результат. Я покажу, где искать разрыв и почему queue_log отвечает только за вызовы очередей.

Что ARI получает от Asterisk, а что не получает CRM

В классической схеме ARI команды идут через REST, а асинхронные события — через WebSocket. Документация Asterisk также описывает REST поверх WebSocket; проверьте, поддерживает ли этот режим ваша версия. Вызов попадает под управление ARI, когда диалплан передаёт канал в приложение Stasis(); затем Asterisk сообщает подключённому приложению о событиях канала. Сам факт, что SIP-вызов дошёл до сервера, ещё не означает, что он попал в Stasis или что CRM получила запись. Для компаний, которым нужна помощь с телефонной инфраструктурой, мы проводим ИТ-аутсорсинг, но при разборе аварии сначала отделяем состояние звонка в Asterisk от карточки в CRM. Это два разных участка цепочки, и логи у них тоже разные.

Не стройте расследование на мифе о подтверждении каждого события. Событие об изменении состояния и результат команды — разные сообщения по смыслу; в классической схеме приложение получает события по WebSocket и отправляет команды через REST; приложение должно прочитать событие, выполнить нужную логику и само сохранить данные в CRM. Если обработчик завис или потерял соединение, ищите ошибку в приложении и проверяйте повторное подключение. Если канал так и не вошёл в Stasis, проверяйте маршрут диалплана. Если же вызов завершился в Asterisk, а CRM молчит, это ещё не доказывает, что сервер «потерял звонок». Сначала найдите последний подтверждённый этап, потом двигайтесь к следующему.

Как разобрать условный сбой в CRM

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

Дальше строю журнал по контрольным точкам: вызов вошёл в нужную ветку диалплана; канал попал в Stasis; приложение увидело StasisStart; обработчик выполнил свою операцию; CRM вернула или создала запись; канал завершил работу и Asterisk сообщил StasisEnd. На каждой точке сохраняю время, ID канала и результат операции. Если StasisStart отсутствует, смотрю диалплан и состояние ARI. Если событие есть, но в журнале приложения нет обработки, проверяю его подписку, цикл чтения и ошибки процесса. Если приложение подтверждает запись, а оператор её не находит, дальше разбираю поиск, права и фильтры CRM. Такая схема позволяет проверить интеграцию Asterisk с CRM, не объявляя виноватой сеть на глаз.

Сначала подтвердите ARI и маршрут вызова

Перед чтением длинных журналов проверьте, что Asterisk работает и модуль ARI загружен. В установке с systemd команда systemctl status asterisk показывает состояние юнита, если он действительно называется asterisk; в контейнере или пакетной сборке способ управления может отличаться. В CLI Asterisk проверьте модуль командой module show like res_ari.so. Смотрите не только на строку в выводе, но и на состояние модуля: загруженный файл и работающий модуль — не всегда одно и то же. Затем проверьте запуск HTTP-интерфейса в http.conf, пользователя и настройки ARI в ari.conf, а также доступность узла приложения по тому адресу, который задан в вашей конфигурации.

У Asterisk есть два разных пути доступа, и их часто смешивают. ARI использует HTTP для REST-запросов и WebSocket для событий; права на локальный каталог управления Asterisk сами по себе не открывают приложению доступ к ARI. Поэтому проверяйте адрес и порт из конфигурации, TLS при его использовании, учётную запись ARI, сетевой маршрут и записи о подключении. В диалплане подтвердите, что нужный контекст действительно вызывает Stasis() с тем же именем приложения, которое слушает WebSocket. Посмотрите сообщения запуска и конфигурации: Asterisk может успешно принимать SIP, но не загрузить ARI или не передавать в него конкретный канал. Для логов Asterisk проверьте, какие каналы записи включены через logger.conf; называть ari.conf настройкой уровня журналирования неправильно. Отдельно сверьте имя приложения в Stasis() с параметром app в подписке на /ari/events: именно так внешний обработчик связывается с нужной логикой вызова. Опечатка в имени может оставить приложение без событий для этого маршрута, даже когда WebSocket-соединение в целом установлено. Проверьте и учётную запись ARI, которой приложение авторизуется; тестовый успешный HTTP-запрос к другому ресурсу ещё не доказывает подписку на правильное приложение.

• Уточните, как запущен Asterisk и как называется служба
• Проверьте состояние res_ari.so через CLI
• Сверьте HTTP, ARI и имя приложения Stasis
• Сопоставьте время вызова с журналами приложения

Команды отладки SIP и PJSIP

Протокольный журнал полезен, когда нужно понять, дошёл ли SIP-обмен до Asterisk и что сервер ответил. Но команда зависит от драйвера. sip set debug on относится к старому chan_sip; если у вас PJSIP, включайте журнал командой pjsip set logger on. Для первичной диагностики PJSIP документация Asterisk также предлагает поднять подробность и отладку CLI, а после сбора нужного сценария отладку надо выключить. Эти записи показывают SIP-обмен, но не доказывают, что CRM обработала событие ARI: это соседние, а не взаимозаменяемые журналы. Проверить синтаксис и контекст команды для своей конфигурации можно в руководстве по настройке PJSIP.

Включайте только тот протокольный журнал, который нужен для конкретного вызова, и записывайте точное время теста. В CLI это выглядит так:

core set verbose 4
core set debug 4
pjsip set logger on

Для старого chan_sip замените PJSIP-команду на sip set debug on; не запускайте обе наугад. Сразу после воспроизведения отключите протокольный журнал командой, предусмотренной вашим драйвером; для старого chan_sip документация указывает sip set debug off. Верните обычные уровни CLI, если поднимали их для проверки. Отладочный поток может быстро разрастись, а чувствительные заголовки не стоит хранить и пересылать без необходимости. Если в маршруте действительно вызывается AGI(), исследуйте эту отдельную стадию отдельно: AGI и ARI — разные интерфейсы, и отладка AGI не показывает состояние WebSocket ARI.

Что показывают ABANDON и RINGNOANSWER

Файл queue_log полезен только для вызовов, которые прошли через приложение очереди. По умолчанию журнал расположен в /var/log/asterisk/queue_log, но конкретная система может менять способ и место хранения. Строка состоит из полей, разделённых вертикальной чертой: время, идентификатор канала, очередь, участник, тип события и его параметры. ABANDON означает, что абонент покинул очередь до соединения; запись содержит позицию при выходе, исходную позицию и время ожидания. Это не отметка «Asterisk отверг вызов» и не сигнал о потерянном событии ARI. Если звонок вообще не заходил в очередь, искать его в этом журнале бессмысленно.

Событие RINGNOANSWER фиксирует попытку дозвона до доступного участника очереди, которая закончилась без ответа; параметр события — длительность этой попытки в миллисекундах. Сопоставьте его с дальнейшими строками той же очереди и с журналом приложения по времени и ID канала. Несколько ABANDON могут объяснить, почему люди уходили, не дождавшись оператора; RINGNOANSWER — почему конкретная попытка не завершилась ответом. Ни то ни другое само по себе не показывает, записала ли CRM карточку. Для вызова вне очереди нужны журналы соответствующего приложения и Asterisk, а для сверки маршрута полезен разбор базового диалплана Asterisk. queue_log — журнал очередей, не универсальная книга судьбы каждого вызова.

Как применять изменения без лишнего перезапуска

После каждой правки не обязательно перезапускать всю службу Asterisk. Для настроек ari.conf и websocket_client.conf, поддерживающих перезагрузку, документация описывает module reload res_ari.so; для остальных изменений отдельно проверьте, поддерживает ли их модуль. Проверьте руководство именно для своей версии и тип подключения, затем посмотрите вывод CLI и журнал модуля. Перед изменением сохраните копию конфигурации и зафиксируйте исходное состояние. Меняйте один параметр за раз: если одновременно переписать маршрут, пользователя и транспорт, потом придётся гадать, какое именно исправление сработало. Сначала примените конфигурацию, затем проверьте регистрацию приложения и проведите один тестовый вызов до CRM.

Если полный перезапуск всё-таки необходим, согласуйте его с телефонией: принудительный core restart now завершает активные вызовы. core restart gracefully прекращает принимать новые вызовы и ждёт окончания текущих перед перезапуском, поэтому это тоже влияет на доступность и требует подходящего окна. После изменения пройдите всю цепочку заново: канал вошёл в Stasis, приложение получило событие, журнал обработчика содержит результат, CRM сохранила ожидаемую запись. Только потом выключайте диагностику и фиксируйте, что конкретно изменили. Небольшой журнал проверки — дата, параметр, результат вызова — полезнее уверенного «мы вроде перезагрузили». Если интеграцию нужно не только чинить, но и настраивать, посмотрите пример управления вызовом через ARI.

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