Как вернуть записи звонков из Asterisk в карточки CRM

Если в CRM нет записи разговора, сначала выясните, существует ли сам аудиофайл и завершилась ли его запись. Затем проверьте, передала ли интеграция ссылку или файл и приняла ли его CRM. Я разбираю эту цепочку по шагам: без гадания по одной строке CDR и без правок наугад.

Сначала найдите, на каком этапе пропала запись

У цепочки есть несколько отдельных звеньев: диалплан запускает запись, Asterisk формирует файл, интеграция получает нужное событие или метаданные, затем CRM принимает файл либо ссылку на него. Пустая карточка сама по себе не говорит, на каком звене сбой. Поэтому я начинаю с конкретного звонка и его идентификатора, а не с массовой перезагрузки службы. Сверьте время, внутренний номер и номер обращения. Для сложного случая можно привлечь ИТ-аутсорсинг; учитывайте, что один разговор после перевода или конференции может соответствовать нескольким каналам и CDR. Если сопоставить не тот канал, диагностика уверенно докажет не то.

Найдите файл в каталоге, который фактически использует ваша конфигурация. Часто встречается /var/spool/asterisk/monitor, но путь зависит от настроек и способа установки; документация указывает, что относительный путь MixMonitor использует каталог мониторинга из asterisk.conf. Проверьте размер и формат файла, а затем прослушайте его на коротком тестовом звонке. Нулевой, отсутствующий или обрезанный файл означает, что сначала надо разбираться с записью. Полный и воспроизводимый файл переводит поиск на этап передачи в CRM. Это простое разделение экономит больше времени, чем поиск универсального «фикса» в интернете.

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

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

Что покажут CDR и события AMI

CDR помогает восстановить ход вызова: в нём есть сведения о каналах, времени, длительности и результате звонка. Но CDR — не универсальный каталог аудиозаписей. В стандартном перечне полей Asterisk нет обязательного recordingfile; отдельный модуль или интеграция могут сохранять путь в пользовательском поле либо собственной таблице. Поэтому запрос к выдуманной колонке recordingfile не является общей диагностической командой. Посмотрите схему именно вашего CDR-бэкенда и способ, которым коннектор связывает звонок с аудио. У переведённых вызовов сопоставляйте связанные идентификаторы и каналы, а не только одну строку.

AMI передаёт события и принимает действия; право read отвечает за получение событий, а write — за выполнение действий соответствующих классов. Для интеграции, которой требуется лишь узнавать о звонках, не выдавайте привилегии «на всякий случай»: сначала выясните, какие события и действия использует коннектор. AMI настраивается в manager.conf; сетевой доступ к нему нужно ограничивать согласно документации и топологии. Не копируйте случайный пример с открытым доступом или широкими разрешениями: такой рецепт превращает диагностику в отдельную проблему безопасности.

Для событий записи ищите MixMonitorStart и MixMonitorStop, если ваша версия Asterisk и сценарий их предоставляют. RecordStart и RecordStop — неверные названия для этой проверки. Наличие MixMonitorStop не подтверждает, что файл дошёл до CRM: событие лишь помогает определить состояние записи на стороне Asterisk. Отсутствие события в журнале может означать фильтр подписки, отсутствие логирования или иной механизм записи. Отдельно проверьте ответ API CRM: код и тело ответа, идентификатор карточки и сведения о принятом файле. Именно ответ, а не факт сетевого соединения, показывает результат приёма.

• Сверьте идентификаторы каналов и вызова в CDR и интеграции.
• Проверьте подписку AMI на нужный класс событий и права `read`.
• Сверьте ответ API и журнал ошибок на стороне CRM.

Проверьте MixMonitor, путь и права

Для записи в диалплане часто используют MixMonitor(filename.extension,[options,[command]]). Приложение пишет звук текущего канала, но само по себе не гарантирует, что CRM получит файл. Если следующая команда диалплана должна работать с готовой записью, документация Asterisk требует корректно остановить запись через StopMixMonitor: это закрывает файловый дескриптор и делает файл доступным для обработки в ходе диалплана. Проверьте порядок приложений, фактическое имя файла и формат. Слепо добавлять StopMixMonitor в любой контекст нельзя: он должен соответствовать логике вызова и моменту завершения записи.

Затем проверьте права на каталог и файл от имени процесса, который читает или отправляет аудио. Asterisk может работать под отдельной системной учётной записью, а интеграция — от другой; это зависит от установки. Недостаточно посмотреть только на владельца верхнего каталога: нужны права прохода по родительским каталогам и чтения файла, а при необходимости — записи в каталог назначения. Команды chmod 755 или chmod 770 без понимания владельца и группы — не ремонт, а лотерея. Не выдавайте права всем пользователям ради одного агента и не запускайте интеграцию от root только потому, что так «заработало».

Сравните путь, который сформировал диалплан, с путём, который ожидает обработчик. Относительный путь MixMonitor разрешается относительно настроенного каталога мониторинга; абсолютное имя использует указанный путь. Проверьте также безопасную обработку имени файла: номер звонящего и другие внешние значения нельзя без фильтрации подставлять в параметры команды. Документация MixMonitor предупреждает о риске инъекции команд при использовании недоверенных строк. Если файл создаётся с корректным содержимым, но отправитель его не читает, чините права и путь. Если файла нет, вернитесь к условиям запуска записи и журналу Asterisk.

• Проверьте приложение MixMonitor и полный путь к результату.
• Убедитесь, что обработка запускается после StopMixMonitor, если файл читается в диалплане.
• Проверьте доступ от имени фактической учётной записи интеграции.

Сделайте передачу в CRM повторяемой

Сначала выясните, что именно ожидает CRM: бинарную загрузку файла, URL или отдельный запрос с метаданными. Это определяется API конкретной CRM и настройкой коннектора; один универсальный Bash-фрагмент тут не поможет. Для тестового вызова проследите всю операцию: какой файл выбрал обработчик, какой запрос сформировал, какой ответ получил и по какому идентификатору обновил карточку. Не считайте HTTP-соединение доказательством загрузки: сервер может вернуть отказ, принять запрос без нужного вложения или создать запись, не прикрепив к ней аудио. Общие принципы телефонной связки разобраны в статье про интеграцию Asterisk с amoCRM.

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

Вызов внешнего скрипта из диалплана может быть вариантом интеграции, но связывать завершение звонка с долгой сетевой загрузкой часто неудачно: задержка внешнего сервиса затронет обработку вызова. Разделите фиксацию события и отправку файла, если архитектура коннектора это позволяет. Учитывайте момент, когда запись ещё открыта: отправитель не должен забирать недописанный файл. Именно здесь StopMixMonitor может быть важен для обработки внутри dialplan, а для внешней очереди потребуется надёжный признак готовности. Я сначала проверяю штатный механизм CRM-коннектора и его журнал, а уже потом предлагаю новый агент: второй велосипед обычно получает собственную очередь поломок.

• Уточните формат запроса и ожидаемый ответ по API CRM.
• Сопоставляйте загрузку с идентификатором вызова и карточки.
• Обработайте временные ошибки, повторы и защиту от дублей.

Как проверить исправление и не пропустить новый сбой

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

Мониторинг делайте по всей цепочке, а не по числу файлов в каталоге. Один счётчик новых файлов не обнаружит отказ API; число CDR не равно числу аудиофайлов, а количество карточек CRM может включать вызовы без записи. Полезнее периодически находить звонки без связанной записи и отслеживать ошибки загрузки по журналу интеграции. Порог и интервал выбирают по обычному потоку звонков и графику работы: тишина ночью не должна выглядеть аварией. Отдельно контролируйте свободное место и срок хранения аудио, иначе система будет создавать файлы до момента, когда закончатся ресурсы.

В условном разборе я не заявляю «за неделю пропаданий не было» без выгрузки, метода сверки и границ наблюдения. После правки сохраняйте дату, проверенные сценарии и число звонков, сопоставленных с файлами и карточками. При расхождении найдите конкретные примеры, а не меняйте порог алерта, чтобы график снова стал зелёным. Если расхождение объясняется вызовами без записи или особенностями CRM, зафиксируйте правило учёта. Если объяснения нет — у вас есть идентификатор для расследования до того, как жалоба менеджера превратится в раскопки по месяцу логов. Для контроля пригодится отдельный разбор мониторинга Asterisk, а если в файле нет звука — материал о пустых записях FreePBX.

• Проверьте звонки с переводом и обычным завершением.
• Сверяйте связку CDR — файл — CRM, а не общие счётчики.
• Зафиксируйте результаты тестов и наблюдения после изменения.

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