<b>REST, Webhooks и WebSocket в телефонии: как не сломать обмен событиями</b>

<b>REST, Webhooks и WebSocket в телефонии: как не сломать обмен событиями</b>

Интеграция АТС с CRM, биллингом и омниканальными системами обычно распадается на три канала: REST для команд, Webhooks для асинхронных событий, WebSocket для постоянного потока статусов. Ошибка начинается там, где их смешивают в одну схему и ждут от HTTP «почти real-time».

Для команд держите REST идемпотентным: create-call, hangup, transfer должны принимать request-id и уметь безопасно повторяться. Для событий через Webhooks обязательно закладывайте retry с backoff, подпись payload и дедупликацию по event-id. Если внешний сервис не подтверждает прием, ваш шлюз обязан сохранить событие в очередь, а не терять его в пустоте.

WebSocket полезен там, где нужно держать живую ленту: присутствие операторов, смена статуса очереди, прогресс вызова, DTMF, таймеры. Но это не транспорт для критичных команд: соединение рвется, прокси режут idle-сессии, а клиент может молча уйти за NAT. Поэтому командный контур и событийный контур лучше разделять по разным endpoint’ам и разным SLA.

Практический минимум: таймауты на каждый запрос, schema validation для входящих payload, корреляционный id в логах, отдельная таблица/очередь для неразобранных событий, и обратная совместимость полей JSON. Разбираем дамп трафика в Wireshark, и вот что мы там видим: проблемы почти всегда не в SIP, а в том, как приложение переживает повторы, потери и порядок доставки.

Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе. Если REST, Webhooks и WebSocket разведены по ролям, телефония переживает сетевые сбои без потери бизнес-событий.