REST, Webhooks и WebSocket в телефонии: где ломается интеграция

REST, Webhooks и WebSocket в телефонии: где ломается интеграция

Интеграция АТС с CRM, BI и ticketing почти всегда упирается не в API как таковой, а в модель событий. Ошибка №1 — синхронно ждать ответ от внешней системы в критическом call-path. Если CRM тормозит, не должен вставать SIP-диалплан или обработка ACK/BYE.

Нормальная схема: REST — для команд и справочников, Webhooks — для событий вызова, WebSocket — для живого состояния операторов, очередей и статусов. Разделяйте write-path и event-path: команда создаёт изменение, событие подтверждает факт. Иначе ловите дубли, гонки и «пропавшие» звонки в отчётах.

Обязательно закладывайте:
• идемпотентность на стороне приёмника по call_id, leg_id, event_id;
• очередь с retry и backoff, а не прямой POST в бизнес-логику;
• подпись webhook-запросов и проверку таймстампа;
• heartbeat для WebSocket и механизм переподключения без потери контекста.

Разбираем дамп трафика в Wireshark, и вот что мы там видим: RTP идёт ровно, а интеграционный слой шлёт события с задержкой в несколько секунд. Пользователь уже положил трубку, а CRM только создала карточку. Это лечится буферизацией событий, строгим порядком delivery и локальным журналом для повторной отправки.

Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе. Держите интеграции асинхронными, фиксируйте корреляцию по всем leg’ам и проверяйте, что внешняя система умеет переживать повторную доставку без побочных эффектов.