REST, Webhook или WebSocket: как не сломать интеграцию телефонии на ровном месте

REST, Webhook или WebSocket: как не сломать интеграцию телефонии на ровном месте

Интеграция АТС с CRM, helpdesk и биллингом ломается не на SIP, а на границе протоколов. Типовые ошибки: синхронный REST внутри обработчика звонка, отсутствие идемпотентности, «голые» webhooks без подписи и ретраев.

Для REST держите отдельную очередь и worker: событие звонка фиксируется локально, а внешний запрос уходит асинхронно. В ответе API не ждём бизнес-логику, только 2xx/4xx с понятной ошибкой. Если внешний сервис недоступен — кладём в dead letter и повторяем по backoff, а не блокируем call flow.

Webhooks нужны для событий: ringing, answered, hangup, recording.ready. Обязательно: HMAC-подпись, timestamp в payload, защита от дублей по event_id, логирование request-id. Иначе один и тот же hangup легко создаст два тикета и три сделки.

WebSocket полезен там, где нужен потоковый статус: живая карточка звонка, перевод, удержание, DTMF, presence агента. Но канал должен переживать reconnect без потери состояния: после переподключения клиент запрашивает snapshot, а сервер не полагается на «всё ещё открытое» соединение.

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