Экс-сотрудник Twitch и разработчик Discord, являющийся заядлым экспертом по WebRTC, жестко раскритиковал решение OpenAI использовать протокол для голосовых AI-агентов. В своем техническом блоге OpenAI признались, что сталкиваются с проблемами, а автор статьи уверил, что дело не в неумении инжиниров, а в самой природе WebRTC. Протокол изначально заточен под видеоконференции, где критически важна низкая задержка и мгновенная реакция. В голосовых AI-ботах такая философия работает против вас. Если сеть ухудшается, WebRTC начинает агрессивно отбрасывать пакеты, чтобы сохранить плавность, но для текстового генератора это означает потерю части промпта. Пользователь слышит искаженный ответ или молчание вместо качественной речи. В отличие от TCP, где можно переслать потерянные данные, в WebRTC пакеты не восстанавливаются. OpenAI вынуждена искусственно добавлять задержки и даже «сон» перед отправкой аудио, чтобы синхронизировать рендеринг, что сводит на нет всю идею мгновенной связи.
Главная техническая проблема кроется в работе load balancing и работе с портами. WebRTC требует использования эфемерных портов для каждой соединения, чтобы обойти NAT, но это создает колоссальную нагрузку на серверы и фаерволы корпоративных сетей, которые часто блокируют такие порты. Сервисы вроде Twitch и Discord вынуждены нарушать спецификации, мультиплексинг соединения на одном порту или используя IPv4-хаки, так как полноценный IPv6 еще не везде внедрен. OpenAI пытается решить эти проблемы самописным балансировщиком, но протокол WebRTC фундаментально зависит от IP-адреса и порта клиента, что делает состояние распределенным и сложным для масштабирования.
Автор предлагает альтернативу: отказаться от WebRTC в пользу QUIC. Протокол QUIC решает проблемы с эфемерными портами благодаря уникальному CONNECTION_ID, который выбирается сервером, а не рандомом. Это позволяет использовать один порт для всех подключений и автоматически переключаться на новый IP при смене сети без разрыва соединения. Более того, QUIC реализует Stateless Load Balancing. Сервер зашифрует свой внутренний ID прямо в CONNECTION_ID первого пакета. Балансировщик не обязан хранить таблицу пересылок в Redis или базе данных, он просто смотрит на первые байты и пересылает пакет нужному бэкенду. Это устраняет необходимость в глобальном состоянии и делает систему отказоустойчивой даже после перезагрузки серверов.
Кроме того, QUIC позволяет использовать комбинированную стратегию адресации: AnyCast для первичной рукопожатия и Unicast для передачи данных после установления сессии. Это убирает необходимость в сложной сетевой архитектуре с балансировщиками. В итоге, хотя голосовой AI через QUIC может столкнуться с потерей пакетов, это решаемая задача, которую не стоит игнорировать ради фиктивных преимуществ WebRTC. Автор считает, что OpenAI должна выбросить WebRTC как ненужный балласт и перейти на QUIC, возможно, внедрив механизмы приоритизации пакетов по мере их появления. QUIC не только масштабируется лучше, но и избавляет от головной боли с NAT и фаерволами. Если вы работаете в большой компании, используйте QUIC вместо WebRTC, это спасет ваш продукт и производительность. Автор оставляет свои контакты для обсуждения темы, полагая, что его аргументы валидны.