WebRTC Trickle ICE: приёмка 05.10.2026

В той же Chrome-сессии медиана local SDP → connected сократилась с 16,108 с до 1,245 с. Все пять штатных подключений установили DTLS через TURN relay; после подключения росли Opus/RTP-счётчики. Синтетическая речь прошла через Core PCM, streaming ASR/NATS и вернулась в чат как partial, final и ответ. Это измерение подключения в текущей сети, а не скорости модели распознавания.

Исходники, CI и фактические контейнеры

• Реализация: 95595f2, pipeline 4899.
• Совместимость с TCP host-кандидатами Chrome: a925c28, pipeline 4900.
• В обоих pipeline Python, Frontend, Ruby checks и build streaming consumers завершились успешно. build push и deploy остались manual; полный DRS deploy не запускался. Состав стэков, NATS, TURN и ASR mode не менялись.
• Core сначала обновлён на 95595f2, затем Frontend на 95595f2; после проверки Core обновлён на a925c28. Listener выполнил rollout, повторное U не запускалось.

Insight подтвердил running, 1/1, UpdateStatus=completed и OCI revision. Image ID совпал с writing image соответствующего CI build:

Это content hash образа контейнера, не registry manifest digest: Insight inspect не выдаёт RepoDigests, а сохранённый Docker SSH context не имеет доступа. Позднейшая поставка этого отчёта может иметь другую Frontend revision.

Замеры в одной сети и браузере

Контроль до изменения: local SDP → POST занимал 10002 мс; POST → answer — 5224/5291 мс; answer → connected — 868/828 мс. Итог: 16094/16121 мс. Время разрешения микрофона исключено. Во всех новых замерах source — синтетический MediaStream; физический микрофон и его permission latency не измерялись.

Во всех пяти: connected, DTLS connected, remote relay, local srflx. Серверный end ещё не получен в момент connected: медленное gathering Core не задерживает media. Клиентское gathering в этой сети уже успевало завершиться. Тест с зависшим STUN на обеих сторонах выполнен отдельно на точных версиях библиотек: реальные ICE/DTLS/Opus/RTP/decoded PCM работают до его завершения.

Пользовательские и негативные сценарии

• WAV webrtc-control-2plus2-20261002.wav: PCM16 mono 48 kHz, 3,866125 с, SHA-256 513c1066858c3b6052cb1f648cdce18825edd29c47a3a546f149097f9e6fd419. После WAV продолжалась тишина, чтобы не прерывать PCM-поток.
• NATS: пять partial, затем один final «Сколько будет? 2 плюс 2. Ответь коротко.»; затем SHOW_MESSAGE, в UI «2 плюс 2 будет 4!».
• Отдельный текстовый запрос «Сколько будет 3 плюс 4?» получил ответ «3 плюс 4 будет 7!». В /core/history сохранены четыре user/assistant сообщения; после reload они восстановлены в UI. Тесты использовали отдельную сессию.
• Legacy offer без trickle на актуальном Core: DTLS connected, prflx → relay, RTP 0 → 49 packets; local SDP → connected 16092 мс. Для вызова frontend fallback только в тестовой вкладке capability заменялась на 404.
• Дополнительный Trickle NAT-тест: из исходного SDP убраны кандидаты, два отправляемых srflx-кандидата имеют намеренно изменённый публичный порт; все пять UDP host-кандидатов содержат приватные адреса. Core обнаружил рабочий NAT-путь: connected за 1936 мс, DTLS и RTP 0 → 50. Это проверка несовпадения сообщённого и фактического порта; browser stats по-прежнему называют локальный кандидат srflx. Реальный prflx явно виден в отдельном legacy-сценарии выше.
• Без OAuth GET capabilities, DELETE и WebSocket Upgrade возвращают 302 на вход, защищённые данные не выданы. С OAuth handshake работает.
• Неверный connection token: WS закрыт с 1008, ни одного сообщения с данными; действующее соединение владельца остаётся connected.
• После закрытия ICE-канала уже connected peer остаётся connected: DTLS работает, RTP растёт 1950 → 2000 packets; UI предупреждает audio remains connected.
• Явная остановка закрыла все девять созданных тестовых peer. HTTP DELETE после одновременного peer close может получить 404: запись уже удалена; UI cleanup идемпотентен. Изолированные HTTP/WS tests подтверждают token DELETE 204, освобождение registry, auth timeout, лимиты и разрыв до connected.

Все браузерные подмены getUserMedia/RTCPeerConnection/fetch/WebSocket, временный file input и AudioContext удалены после проверки; голос отключён.

Найденная несовместимость и исправление

Первый Trickle rollout отвергал валидные TCP host-кандидаты Chrome и закрывал попытку с Invalid ICE signaling message. UDP-кандидаты уже были пригодны для соединения. handle_ice.py теперь проверяет принадлежность MID/ufrag и общий лимит, затем пропускает TCP-кандидат без отмены UDP/TURN. Регрессионный тест отправляет Chrome TCP active, дубликат, UDP и end через настоящий aiohttp WebSocket. Пять успешных замеров выполнены после этого исправления.

Границы результата

Точная длительность до первого PCM до изменения не наблюдалась в доступной production телеметрии; сравнения этого времени нет. Декодирование подтверждено реальными pinned aiortc tests и production ASR-результатом. WER/DER, физический микрофон, ICE restart и auto-reconnect не проверялись и не добавлялись. Дополнительное полное отключение клиентского STUN не установило соединение; поддерживаемая конфигурация сохраняет STUN/TURN, как в принятом плане. Числа не являются обещанием для других сетей.

Приёмка полного состава chat/voice от 04.10 остаётся отдельным датированным снимком. Сегодня повторно проверен изменённый путь WebRTC → PCM → ASR/NATS → чат/история; файловые voice UI и CPU benchmark не менялись и не объявляются заново проверенными этим отчётом.