Інтеграція Бітрікс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.