REST, Webhooks и WebSocket в телефонии: как не сломать обработку звонков

REST, Webhooks и WebSocket в телефонии: как не сломать обработку звонков

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

— REST используйте для команд: создать сущность, назначить тег, закрыть тикет.
— Webhook — только для событий, которые можно доставить повторно и проверить по idempotency key.
— WebSocket — для live-обновлений операторского интерфейса: статус агента, очередь, caller ID, таймер разговора.

Критичный момент — подтверждение доставки. Для webhook ответ 2xx должен быть быстрым: принял, записал в очередь, обработал асинхронно. Не делайте бизнес-логику внутри HTTP-обработчика. Если внешняя система недоступна, события складируйте в retry-очередь с backoff, иначе при пике вы потеряете вызовы на уровне интеграции.

Отдельно контролируйте порядок событий: answered, bridged, hangup, record_ready могут приходить не так, как вы их рисуете на схеме. Нужны correlation_id, timestamp источника и состояние, вычисляемое по факту, а не по предположению. Разбираем дамп трафика в Wireshark, и вот что мы там видим: транспорт стабилен, а ломается именно обработка повторов и таймаутов. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.

Стройте интеграцию как event-driven систему: REST для управления, webhooks для фактов, WebSocket для realtime. Тогда телефония остаётся предсказуемой, а внешние системы не диктуют правила вашей маршрутизации.