Интеграция телефонии через REST, Webhooks и WebSocket ломается не в API, а в пограничных состояниях

Интеграция телефонии через REST, Webhooks и WebSocket ломается не в API, а в пограничных состояниях

REST удобен для команд управления: создать звонок, перевести, завершить, получить статус. Но синхронный запрос не должен быть единственным источником истины. Если внешний сервис не ответил, у вас должен быть idempotency key, retry с backoff и отдельная таблица сопоставления call_id ↔ external_id. Иначе получите дублирующие действия и «зависшие» карточки в CRM.

Webhooks нужны для событий: answered, hangup, dtmf, recording_ready. Здесь критичны подпись, таймаут обработки и повторная доставка. Принимайте событие быстро, кладите в очередь и обрабатывайте асинхронно. Если обрабатываете прямо в HTTP-обработчике, любое торможение CRM превращается в потерю событий. Разбираем дамп трафика в Wireshark, и вот что мы там видим: чаще всего проблема не в SIP, а в том, что webhook блокируется на уровне приложения.

WebSocket полезен там, где нужен живой канал: экран оператора, мониторинг очереди, уведомления о состоянии вызова. Держите heartbeat, обрабатывайте reconnection, не полагайтесь на порядок доставки без sequence number. Для событийной шины лучше сразу отделить transport layer от business logic: телефония публикует факт, внешняя система решает, что с ним делать.

Минимальный паттерн такой: REST для команд, Webhooks для фактов, WebSocket для realtime-UI. Все входящие события логируйте с correlation_id, а любые повторные запросы делайте безопасными. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.