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

Интеграция АТС с CRM, helpdesk и BI-системами ломается не в SIP, а на стыке API-контракта и событийной модели. Если внешний сервис ждёт синхронный ответ, а вы шлёте ему webhook «когда-нибудь потом», получите дубли, рассинхрон и потерянные статусы.

Рабочая схема обычно такая:
— REST — для команд: создать лид, поднять тикет, запросить карточку звонка.
— Webhooks — для событий: answered, hangup, recording_ready, disposition_changed.
— WebSocket — для live-канала: присутствие операторов, очереди, мгновенные статусы, пуш в интерфейс без polling.

Критичные правила:
— idempotency_key на все входящие команды;
— event_id и version у каждого webhook;
— retry с backoff, но без бесконечных дублей;
— HMAC-подпись или mTLS, иначе любой может подделать событие;
— отдельная очередь для асинхронной доставки, чтобы внешний API не тормозил SIP-логику.

Разбираем дамп трафика в Wireshark, и вот что мы там видим: звонок уже завершён, а CRM всё ещё ждёт webhook. Значит, статус не должен быть «истиной в одном запросе» — храните состояние у себя и синхронизируйте его по событиям, а не по таймаутам.

Правильная интеграция — это не «дернуть API после звонка», а построить устойчивый event-driven контур. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.