<b>REST, Webhooks и WebSocket в телефонии: как не сломать интеграцию под нагрузкой</b>

<b>REST, Webhooks и WebSocket в телефонии: как не сломать интеграцию под нагрузкой</b>

Интеграция АТС с CRM, биллингом и оркестратором должна быть событийной, а не опросной. Для исходящих действий используйте REST: создать звонок, получить статус, повесить метку. Для фактов, которые уже произошли в телефонии, отдавайте Webhooks: ответил, сбросил, ушёл в очередь, завершился. Для живого потока состояния — WebSocket, если системе нужен непрерывный канал событий без постоянных HTTP-запросов.

Главная ошибка — смешивать transport и business logic. Webhook должен быть идемпотентным: один и тот же event_id не должен дважды закрывать сделку или начислять оплату. REST-методы защищайте HMAC-подписью, таймаутами и повторными попытками с backoff. Если внешняя система временно недоступна, события складывайте в очередь, а не теряйте их в логах.

Для телефонии критичны порядок и задержка. События call_started, bridge_created и call_ended должны приходить с correlation_id, чтобы склеивать SIP-сессию, запись и карточку клиента. В логах полезно хранить Call-ID, номер, направление, статус доставки webhook и ответ внешнего сервиса. Разбираем дамп трафика в Wireshark, и вот что мы там видим: 200 OK по SIP не гарантирует, что бизнес-событие уже дошло до CRM.

Практический минимум: rate limit на входящие запросы, повторная доставка только для 5xx и таймаутов, отдельный consumer для обработки событий, дедупликация по ключу и dead-letter queue для ошибок схемы. Отказоустойчивость — это не роскошь, а базовое требование к SIP-платформе.

Если интеграция строится вокруг очереди событий и четких контрактов, телефония остаётся предсказуемой даже при сбоях внешних систем.