Версія 2.7.2 розділяє вхідні й вихідні дзвінки у вебхуках на два незалежних ланцюжки, додає керування чергою через REST API та розпізнавання SIP-транків за заголовком для шлюзів, де кілька ліній діляться однією IP-адресою.
Окремий ланцюжок подій для вихідних дзвінків
Раніше вихідні дзвінки з номерів SIP-користувачів взагалі не мали власних подій. Тепер є call.outgoing →
call.outgoing_answered → call.outgoing_ended — незалежно від вхідного ланцюжка call.incoming → call.answered
/ call.missed → call.ended. Розпізнавання вихідного дзвінка прив’язане до конкретного SIP-користувача, а не до
контексту dialplan, — це важливо, бо і користувач, і транк можуть мати однаковий контекст, що збігається з назвою
таблиці маршрутизації.
linkedid, channel і channel_vars у кожній події
Кожен payload тепер містить linkedid — ідентифікатор, спільний для всіх каналів одного логічного дзвінка
(наприклад, обох “ніг” внутрішнього дзвінка), і channel — назву каналу Asterisk. Це дозволяє CRM групувати кілька
вебхук-подій одного дзвінка, не покладаючись на близькість uniqueid чи часових міток. Новий об’єкт channel_vars
передає значення дозволених змінних каналу Asterisk (за замовчуванням — ULINE, слот парковки дзвінка).
Пауза й статус учасників черги через REST API
POST /api/v1/queues/members/pause/ ставить чи знімає учасника черги з паузи через AMI QueuePause, а
GET /api/v1/queues/members/ повертає живий статус учасників (пауза, статус, кількість оброблених дзвінків) —
обидва ендпоінти працюють напряму з Asterisk, незалежно від того, чи запущений dashboard-listener.
SIP-транки для мультипортових GSM-шлюзів
Нове текстове поле custom_identify_settings дозволяє задати власний блок [identify] для транка. Це вирішує
конкретну проблему: коли кілька портів одного GSM-шлюзу реєструються з однієї IP-адреси, Asterisk не може
розрізнити їх за IP — лише за заголовком Contact: у вхідному запрошенні. Раніше [identify] підтримував лише
розпізнавання за IP.
Важлива зміна для наявних вебхуків із таблицями маршрутизації
Якщо у вас налаштований вебхук, що використовує лише таблицю маршрутизації (без контексту чи черги) для
вхідних подій, — після оновлення такі дзвінки почнуть надсилатися як call.outgoing*, а не call.incoming/
call.ended, як раніше. Міграція автоматично переносить існуючі налаштування, але обробник на стороні CRM
потрібно оновити, щоб він очікував нові типи подій. Рекомендований порядок оновлення: спершу migrate та
sync_webhooks, потім перезапуск dashboard-listener.