Интеграция Битрикс24 с Asterisk
Asterisk стоит у многих компаний как основная корпоративная АТС уже несколько лет. Когда бизнес переходит на Битрикс24, возникает вопрос: выбрасывать ли всё телефонное хозяйство и переходить на облачную телефонию Битрикс24 или сохранить Asterisk и подключить его к CRM? В большинстве случаев — сохранять. Asterisk даёт гибкость настройки, которой нет в облачной АТС, а интеграция с Битрикс24 позволяет получить всё что нужно от CRM: всплывающую карточку, запись звонка, автосоздание лидов.
Два архитектурных подхода
SIP-транк из Asterisk в Битрикс24. Asterisk регистрируется как SIP-транк в облачной АТС Битрикс24. Входящие и исходящие звонки проходят через Asterisk, а медиапоток и сигнализация уходят в Битрикс24. Маршрутизацию звонков и IVR можно оставить в Asterisk или перенести в Битрикс24.
Плюс: вся логика маршрутизации остаётся на Asterisk, Битрикс24 получает только CRM-события. Минус: медиапоток идёт через серверы Битрикс24 — дополнительная латентность.
AGI/AMI-интеграция без передачи медиапотока. Asterisk обрабатывает звонки самостоятельно, а в Битрикс24 передаются только события: звонок начался, звонок завершён, длительность, результат. Используется AMI (Asterisk Manager Interface) или AGI-скрипт.
Это предпочтительный вариант, если Asterisk уже настроен с провайдером и качество звука устраивает. Битрикс24 получает всю CRM-функциональность без изменения телефонной инфраструктуры.
Настройка через AMI: пошаговая схема
AMI — TCP-интерфейс Asterisk для управления и мониторинга. Через AMI можно подписаться на события звонков и отправлять команды.
1. Создать AMI-пользователя в /etc/asterisk/manager.conf:
[bitriks_agi]
secret = your_secret_password
read = call,cdr
write = originate
permit = 127.0.0.1/255.255.255.0
2. Развернуть обработчик — небольшой демон (Node.js, PHP-daemon или Python), который слушает AMI-события:
-
Newchannel— новый входящий звонок -
Hangup— завершение звонка -
Bridge— соединение установлено (оператор ответил)
3. При событии Newchannel вызвать Битрикс24 REST:
POST /rest/telephony.externalcall.register
{
"USER_PHONE_INNER": "101",
"USER_ID": 5,
"PHONE_NUMBER": "+74951234567",
"CALL_START_DATE": "2024-01-15T10:30:00+03:00",
"CRM_CREATE": "Y",
"CRM_SOURCE": "CALL_TRACKER",
"TYPE": 2
}
4. Сохранить CALL_ID из ответа Битрикс24 — он понадобится для завершения звонка и прикрепления записи.
5. При событии Hangup вызвать:
POST /rest/telephony.externalcall.finish
{
"CALL_ID": "сохранённый_CALL_ID",
"USER_ID": 5,
"DURATION": 185,
"STATUS_CODE": "200",
"ADD_TO_CHAT": "Y"
}
Запись звонков и передача в Битрикс24
Asterisk пишет звонки в директорию (обычно /var/spool/asterisk/monitor/). После завершения звонка файл записи нужно передать в Битрикс24.
Через API:
POST /rest/telephony.externalCall.attachRecord
{
"CALL_ID": "CALL_ID",
"FILENAME": "record_2024_01_15_101.mp3",
"FILE_CONTENT": "<base64 содержимое файла>"
}
Для больших записей (разговоры дольше 5-10 минут) base64 неэффективен. Альтернатива: загрузка через disk.file.uploadurl.prepare — получаем ссылку для upload и передаём файл напрямую.
Исходящие звонки из Битрикс24 через Asterisk
Менеджер кликает на номер в CRM — Asterisk должен позвонить. Реализуется через Битрикс24 REST API событие OnExternalCallStart или через telephony.externalcall.originate. Обработчик получает событие и выполняет команду originate в Asterisk через AMI:
Action: Originate
Channel: SIP/101
Exten: +74951234567
Context: outbound
Priority: 1
CallerID: "Иванов Пётр" <+74955551234>
Кейс: колл-центр 12 операторов
Телекоммуникационная компания с собственным Asterisk 18, 12 операторами, очередями и IVR. Переход на Битрикс24 был обусловлен задачей вести историю общения с клиентами — операторы не знали, звонил ли клиент раньше и с каким вопросом.
AMI-интеграция была предпочтительна, потому что вся маршрутизация (очереди, IVR, переадресации) уже настроена в Asterisk и работает без сбоев. Переносить это в Битрикс24 было нецелесообразно.
Нестандартная ситуация: в очереди Asterisk звонок мог переключаться между операторами (первый не ответил — идёт к следующему). Нужно было правильно определить, кому из операторов в Битрикс24 привязывать звонок. Решили через отслеживание события AgentConnect в AMI — именно это событие фиксирует, какой агент принял звонок из очереди.
Срок настройки AMI-интеграции с передачей записей и исходящими звонками: 5-8 рабочих дней.
Частые ошибки
Звонки дублируются в CRM — если Asterisk при переводе звонка создаёт новый канал, AMI-обработчик регистрирует его как новый звонок. Фильтрация по LinkedID в AMI-событиях решает проблему: это ID исходного звонка, он не меняется при переводе.
Запись не прикрепляется — файл записи ещё не готов в момент события Hangup. Asterisk конвертирует .wav в .mp3 асинхронно. Добавить задержку 5-10 секунд или отслеживать появление файла через inotify.