WEB-463 · Дефект · — · web
P2 [ТЕЛЕФОНИЯ 8000]: ассистента нельзя перебить (barge-in не срабатывает) — owner 02.09 после переезда SIP на A1
Закрыт
P2
ведёт: —
Суть
<!-- coord-block-start 2026-09-06 -->
## ДЛЯ НУЛЕВОГО АГЕНТА (обновлено 2026-09-06 UTC)
- Телефония 8000: barge-in/VAD.
- Код/линия: voice/SIP runtime, VAD env; 0d7b50ee/44ea7cea в l113f 221e8f39. SIP readiness PASS; host-sync отдельный.
- Открыто: SIP fix NO-GO без реального Asterisk; host-sync v2 требует стенда. Волна/отчёт 2322.
## KNOWN ISSUES / ТРАБЛШУТИНГ
- Barge-in не срабатывает → проверить readiness, VAD env и звонок 8000 → приложение исправлено, host reload не доказан → стендовый e2e перед sync.
- Reload «успешен», endpoints не обновились → проверить текст команды, не rc → Asterisk 20.19: No such command pjsip reload при rc=0 → исправить exit semantics → 2322 NO-GO.
<!-- coord-block-end 2026-09-06 -->
## ДЛЯ НУЛЕВОГО АГЕНТА (обновлено 2026-09-06 UTC)\n- Что это: телефония 8000 — barge-in/VAD, чтобы ассистента можно было перебить.\n- Где код: voice/SIP runtime и VAD env; в прод-составе указаны коммиты , ; хостовый SIP reload — отдельный sync-контур.\n- Посажено/линия: WEB-463 вошёл в l113f ; SIP readiness пост-QA PASS. Хост-синк 508/509/463 выделен в отдельное окно.\n- Открыто: план SIP fix признан NO-GO без реального Asterisk; Asterisk 20.19 отвечает «No such command pjsip reload» с rc 0, что маскирует провал.\n \n## KNOWN ISSUES / ТРАБЛШУТИНГ\n- Barge-in/VAD не срабатывает → проверить SIP readiness, VAD env и реальные события barge-in на звонке 8000 → приложениевая часть l113f содержит , но host reload не доказан → стендовая проверка с реальным Asterisk перед новым окном → SIP host-sync v2.\n- «reload успешен», но endpoints не обновились → проверить stdout/команду Asterisk, а не только rc → Asterisk 20.19 не имеет , helper ошибочно принимал rc=0 → исправить проверку команды/exit semantics в host-sync, отчёт 2322 NO-GO → не трогать SSH/прод из этого тикета.\n
<!-- coord-block-start 2026-09-06 -->
## ДЛЯ НУЛЕВОГО АГЕНТА (обновлено 2026-09-06 UTC)\n- Что это: телефония 8000 — barge-in/VAD, чтобы ассистента можно было перебить.\n- Где код: voice/SIP runtime и VAD env; в прод-составе указаны коммиты , ; хостовый SIP reload — отдельный sync-контур.\n- Посажено/линия: WEB-463 вошёл в l113f ; SIP readiness пост-QA PASS. Хост-синк 508/509/463 выделен в отдельное окно.\n- Открыто: план SIP fix признан NO-GO без реального Asterisk; Asterisk 20.19 отвечает «No such command pjsip reload» с rc 0, что маскирует провал.\n \n## KNOWN ISSUES / ТРАБЛШУТИНГ\n- Barge-in/VAD не срабатывает → проверить SIP readiness, VAD env и реальные события barge-in на звонке 8000 → приложениевая часть l113f содержит , но host reload не доказан → стендовая проверка с реальным Asterisk перед новым окном → SIP host-sync v2.\n- «reload успешен», но endpoints не обновились → проверить stdout/команду Asterisk, а не только rc → Asterisk 20.19 не имеет , helper ошибочно принимал rc=0 → исправить проверку команды/exit semantics в host-sync, отчёт 2322 NO-GO → не трогать SSH/прод из этого тикета.\n
<!-- coord-block-end 2026-09-06 -->
Контрольный звонок owner на 8000 02.09 ~00:30Z (после удаления пробросов 5060/RTP на роутере, SIP уже на A1): связь и приветствие есть, но перебить ассистента голосом не получается — он договаривает до конца. Гипотезы: VAD/настройки interruption в realtime-сессии телефонии (порог/задержка), либо голос не тот (owner: «возможно там голос Гула»). Проверить конфиг перебивания для SIP-плеча (не веб-realtime), эхо-подавление AudioSocket; сквозной тест: речь пользователя во время TTS → TTS останавливается ≤500мс. Эпик WEB-395.
## ЭВОЛЮЦИЯ 04.09.2026 (карта для нулевого агента)
**Якорь прода:** живая линия **l103**, коммит **d91ebefe740ae83484c1de16710f2e6a68610432**, флип **13:51Z 04.09**. Раньше в этот же день: l101 `d825eb0d`, l102 `1b081c5a`. Ветка линии в репозитории-базе `/home/ubuntu/nc` на A1: `l103-line` (проверено `git branch -a --contains d91ebefe...` → `l103-line`).
**Доска:** живая доска — `web-board.sqlite` + HTTP API `http://127.0.0.1:8787/api/web/*` на M1 (`ssh poolpooly@192.168.1.74`). НЕ `board.sqlite` (это iOS/легаси, таблицы `issues`/`ios_issues`, 2225 строк, ключи другие).
### СЕЙЧАС — ФИКС ЖИВОЙ
Barge-in **работает** в запущенном SIP-шлюзе; факт подтверждён контрольной суммой на живом шлюзе. Реальный звонок дал **2 104 аудиокадра без падения** и **два полных хода** диалога.
Гипотеза из тела тикета («голос Гула», порог VAD) не подтвердилась как причина: перебивание не срабатывало из-за состояния живого шлюза, а не из-за настройки голоса.
### ЧТО ОСТАЛОСЬ ИМЕННО ЗДЕСЬ
Обратная сторона включённого barge-in: **приветствие обрезается** — ассистент перебивает сам себя. Нужен guard на первые N мс greeting (или подъём порога VAD на время приветствия).
Критерий: приветствие доигрывает целиком, речь пользователя после него останавливает TTS ≤500 мс.
Второй, отдельный дефект того же плеча — ~5.2 с мёртвого эфира после ответа из-за отсутствующего флага `SIP_EXPERIMENTAL_LIVE_STREAMING_PLAYBACK_ENABLED`; он ведётся в [[WEB-479]].
### 🔴 ЛОВУШКА
Живой шлюз `/home/pi/ag-voice` опережает релизную линию примерно на **2 500 строк**, деплой зеркалит **с удалением** → посадка релиза на `infra/sip/gateway/` уничтожит работающую телефонию. Не сажать туда.
Связи
- связан → WEB-519 — SEC-003 [Hardening; CVSS pending] FastAGI: очистка аудио проверяет подстроку вместо владения вызовом
Лента
2026-09-02T04:30:06.912Z · Fable[02.09 07:05Z Фабл] Волна 1123-bargein сдана (91300bb264): RMS-гейт до очереди, немедленная очистка TTS-очереди + response.cancel вне taskQueue, подавление responseId, отбрасывание устаревших кадров в Stasis transport, live-профиль guard 100 мс / min_frames 12 / floor 1200. КЛЮЧЕВОЕ: 8000 = legacy FastAGI (STREAM FILE целиком, перебивание только DTMF); живое плечо с голосовым barge-in — 8010 (Stasis snoop → realtime bridge). Приёмка 1131 поставлена (+ описать правки диалплана для перевода 8000 на live). Owner-у предложен перевод 8000 после проверки на 8010 (по умолчанию — да).
2026-09-02T04:48:11.263Z · Fable[02.09 08:00Z Фабл] Приёмка 1131-accbargein: FAIL — поздний assistant audio отменённого responseId после interruption_acknowledged/response.done снова попадает в очередь (probe: ожидалось 2 egress-кадра, наблюдалось 5). Доработка 1134-bargein2. В отчёте приёмки описаны правки dialplan для перевода 8000 на live Stasis-плечо (extensions.conf:28-33 → guarded live-блок как 8010 + запуск live-компонентов) — делать после GO фикса и решения owner.
2026-09-02T05:04:41.603Z · Fable[02.09 09:05Z Фабл] 1134-bargein2 сдан (0f08d87a72): отменённый responseId в карантине до конца AudioSocket-сессии; ack/done/cancel_not_active suppression НЕ снимают, снимает только response.created с другим id; bridge пробрасывает nested response.id; тест воспроизводит probe приёмки (ровно 2 egress). Ре-приёмка 1137 (codex, probe 1131 дословно + порядок событий + негативы). Отчёт A1 /home/ubuntu/waves/BARGEIN2-REPORT.md, бандл mirrors/lines/bargein2-1134-*.bundle.
2026-09-02T05:39:51.443Z · Fable[02.09 05:55Z Фабл] Ре-приёмка 1137-accbargein2: PASS/ACCEPT (0f08d87a72) — внешний probe 8/8: повтор кейса 1131 (ровно 2 egress), done до ack, cancel_not_active, новый response.created, первый легитимный ответ, DTMF-cancel + закрытие сессии, provider_session_closed, речь после перебивания. В l88-candidate: d5cd34903 (bargein-1123) + ccd490ac3 (bargein2-1134); зеркало A1 обновлено. Далее: посадка l88 → живая проверка на 8010 → перевод 8000 на live-плечо (dialplan из ACCBARGEIN-REPORT.md).
2026-09-02T09:13:48.060Z · Fable[02.09 09:12Z Фабл] ПОСАЖЕНО на A1: кандидат живого SIP-шлюза 145618713a (1171 GO, честный сухой старт без хуков) — backup /home/pi/ag-voice/infra/sip/backups/gateway-20260902T090941Z.tar.gz, rsync в /home/pi/ag-voice/infra/sip/gateway, node --check + require.resolve всех внешних модулей до рестарта, restart ag-sip-native (health ok, readiness ready, порты 5060/4080/4573), затем ag-sip-native-opus-experimental (5074/4180/4673). 8000 остаётся AGI (по ранбуку §7 перевод на live — отдельный шаг, кандидат dialplan готовит 1164-lane8000). Owner попрошен позвонить на 8000 (ожидание: приветствие «Six by Y»; голосовое перебивание — только после перевода 8000 на live-плечо). В шлюзе теперь: bargein 91300bb2 + bargein2 0f08d87a, greeting fbcff892, 393J f3d7ddfa, web15g 12704970, lease-preflight, vendored импорты, 9090→web2.
2026-09-02T09:55:26.161Z · Fable[02.09 10:45Z Фабл] Посадка шлюза откачена 09:58Z (PIN-гейт на 8000 после нового клиента сессии, см. WEB-395); перебивание/greeting вернутся с повторной посадкой после 1184-sippin.
2026-09-02T11:03:00.138Z · Fable[A1 11:05Z Фабл] ПОСАЖЕН l90 на A1: commit 26da36faba, артефакт me2-standalone-linux-arm64-26da36fa-20260902T105621Z (sha dffb8a17…), run /home/ubuntu/prod/shared/run/l90-26da36fa, /api/ready TRUE (boot-env: 1 warning), paid true, воркер индексации на l90. Env: убраны BLUEBUBBLES_SERVER_PASSWORD и SOCIAL_ENCRYPTION_KEY_PREVIOUS, добавлен SYNC_PAGINATION_ENABLED=1 (P15 SAFE_NOW). Откат: nc-a1.service.bak-l89 + l89 целы.
2026-09-03T06:19:34.218Z · Fable[A1 Фабл] ЖИВОЙ ЗВОНОК owner-а 7016→8000 после посадки круга 10 (3950cf19): callId a9aac956… provider_selected=openai provider_effective=openai; [gateway-barge-in] barge_in detected turnIndex=1 reason=caller_barge_in_during_playback → playback_stopped ok=true → response_cancelled ok=true; call_summary barge_events=1. Перебивание РАБОТАЕТ. Замечено: initial_greeting_blocked (missing_live_bridge, external_channel_not_ready, already_requested) — уточняю у owner-а, звучало ли приветствие (WEB-464).
2026-09-03T06:22:29.746Z · Fable[A1 Фабл] Дубль WEB-479: живой звонок 03.09 — barge-in детектируется, но аудио уже сгенерированного хода продолжает звучать → круг 11 (1504).
2026-09-03T07:05:07.718Z · coordinatorWEB-479/463 — lane 8000 круг 11 (волна 1504) сдан: коммит 6c5f0b1e (база 3950cf19). Причина неудачного перебивания в живом звонке a9aac956: ответ уже полностью сгенерирован и стоял в ARI playback (~1.3 MB), response_cancel_not_active; расхождение turnIndex gateway/bridge. Фикс: синхронный barge-flush очереди, параллельные ARI DELETE всех caller-facing playback (полный/streaming/wait-cue) + повторный DELETE после гонки, отбрасывание поздних событий по responseId/turnIndex, единый turnIndex в обоих bridge, метрики barge_latency_ms/dropped_audio_bytes. Приёмка = волна 1540 (ACCLANE8000V11, A1, после окна установки user wave WEB-472). После GO — посадка на /home/pi/ag-voice и повторный звонок owner-а.
2026-09-04T15:08:17.221Z · coordinator04.09 координатор: в body добавлен блок «ЭВОЛЮЦИЯ 04.09.2026» — состояние, причина с доказательством, что село, что осталось, ловушки.
2026-09-06T10:39:37.253Z · coordinator[06.09 10:39Z координатор] [2026-09-06T10:39Z координатор] WEB-463: приёмка 2261 (A1) = NO-GO 0d7b50ee — функциональный barge-in/full-duplex проходит, но env-валидация VAD clamp-ит вместо «дефолт + предупреждение» (phoneAudioConfig.js:11-17,35-52,60-71; ожидались 300/500, получены 0/3000, warning не вызван) → круг 2 = 2271-web463b (A1). Пост-QA l113d (2239) = NO-GO по ожидаемой причине (прод уже l113e) + SIP readiness на 4080 отвечает 404 на «/» (сервис жив, 5060/5061 слушают) — пост-QA l113e будет с верным пином.
2026-09-06T10:53:43.229Z · coordinator[06.09 10:53Z координатор] [2026-09-06T10:53Z координатор] ИНЦИДЕНТ 10:48–10:51Z: кап Codex (OpenAI) исчерпан — «You've hit your usage limit… try again at Sep 9th, 2026 8:57 PM». Все codex-волны на A2/A1/M4 (в т. ч. 21 ревью Astra блока 18 и приёмки 2270/2272/2273/2275/2276/2277/2263) умерли без отчётов; Astra на M1 тоже ограничен. Владелец уведомлён (докупить кредиты / ждать 9.09). Критичные волны переведены на claude-opus в Anthropic-капе: 2275c приёмка фикса большого PDF, 2278c роли по живым ответам прода, 2272c revive-identity 5, 2270c C5-C круг 6, 2277 приёмка barge-in. Остальное стоит.
2026-09-06T11:07:06.711Z · coordinator[06.09 11:07Z координатор] [2026-09-06T11:07Z координатор] WEB-463: приёмка круга 2 (2277, A1) = GO 44ea7cea (VAD env-валидация: дефолт+предупреждение; barge-in full-duplex, cancel ≤200 мс) → кандидат l113f. На хост телефонии — вместе с WEB-508 в окне.
2026-09-06T12:42:58.486Z · coordinator[06.09 12:42Z координатор] [2026-09-06T12:42Z координатор] ПОСАЖЕНО: ПРОД = l113f 221e8f39 (flip 12:39:47Z, без простоя; оба бэкенда ready, paid enforce_ready, edge 200×8; миграций новых нет (187/192); hetzbk l113f-221e8f39 + env-pack, Pi standby → l113f). Состав (15 коммитов над l113e): роли C5-C детерминированный отказ на прямом отрицании предиката (9fdfd6fe, 86afe601, 3ad54814, 59d4f3ee), WEB-541 SEC-024 retention contract (ebecd7f2, 3fd18f21), WEB-545 SEC-028 lighthouse headers (c4373797), WEB-509 gateway install (9ad8335c, репо-копия), WEB-463 barge-in + VAD env (0d7b50ee, 44ea7cea), WEB-542 rate-limit на client-account-generation (4891645b), WEB-508 SIP reload (8c76aa7d, b93d862f, репо-копия), WEB-506 куки-баннер (fc462e1d), периметр 500/embed (5837dd0f). Откат = l113e 65ff9060 (RUN l113e-65ff9060, REL arm64-l113e-20260906T101257Z). Снято с линии: WEB-560 merge (Prisma при импорте валил сборку → фикс 2309 → l113g). l113g: WEB-550 ed246cae, WEB-531 merge e8c97f1f, WEB-568 faf26ab9, revive5+499 42b61743, WEB-552 ecca7846 + ждущие: big-PDF r3, roles r3, backfill, 560 fix. Хост-синк SIP (508/509/463) — отдельное окно.
2026-09-06T13:20:23.826Z · coordinator[06.09 13:20Z координатор] [2026-09-06T13:20Z координатор] ПРИНЯТО: WEB-560 build-fix — 2317 ACCWEB560BUILDFIX (sol xhigh, PG, импорт-тест phase-production-build) = GO 742066c1 → кандидат l113h (вместе с merge-цепочкой). На проде l113g после посадки: большой PDF cmtkm80jo… revive → pending (checkpoint 9801/9801 сохранён; ждём финализацию воркером); big-test 1782161239510l4gl4zzur revive → pending (revive-identity v5). SIP host-sync план (2315, A1) = GO: sync-plan.sh/rollback.sh, COPY allowlist 12, PATCH allowlist 6 — выполняю окном по плану.
2026-09-06T13:39:43.625Z · coordinator[06.09 13:39Z координатор] [2026-09-06T13:39Z координатор] ОКНО ТЕЛЕФОНИИ 13:31–13:38Z (A1, owner GO): sync-plan.sh --apply 7016 — файлы 508/509/463 скопированы, drop-in 50-web508-reload-persist.conf, reload: PID Asterisk не изменился, контакт 7016 пережил reload, :4080 200; STOP на post-check «AOR 7016 не показывает 90/120/30» (3600/7200 — dynamic AOR из pjsip-generated.conf, dynamic sync на хосте SKIP); rollback.sh STOP «infra-sip archive root is wrong» (ничего не откатил; состояние оставлено — рабочее). Затем restart ag-sip-native для активации barge-in: Asterisk 20.19 поднялся (5060/5061, endpoints=6), :4080 200, но контакт после рестарта не восстановился (0 в +152 с) — persistence регистраций не доказана; владелец перерегистрирует и тестирует звонок/перебивание. Круг 2 плана = 2322-sip-hostsync-fix (A1, sol xhigh). Бэкап: /var/backups/ag-sip-native/20260906T133135Z-3488516-l113f-sync.
2026-09-06T13:45:47.441Z · coordinator[06.09 13:45Z координатор] [2026-09-06T13:44Z координатор] ОТКАТ ОКНА ТЕЛЕФОНИИ 13:47Z: после restart с синком 508 res_pjsip не загрузил ни одного объекта (transports/aors/endpoints=0; REGISTER 7016 → «No matching endpoint found») — и с sorcery.conf «contact = astdb,registrator» (опечатка), и с исправленным «registrar», и с пустым sorcery.conf. rollback.sh упал на своей проверке корня архива → откат вручную: infra-sip.tar + runtime-config.tar из бэкапа, удалены созданные файлы (список created-host-files.list) и drop-in 50-web508; restart → aors=3, endpoints=7, :4080 200 — состояние до окна. Barge-in (463) не активен. Evidence для 2322 в /home/ubuntu/waves/inputs/sip-hostsync-evidence/ (санитизировано). KNOWN ISSUES: (1) на A1 присутствие sorcery.conf ломает загрузку pjsip-конфига — причину искать (порядок #include/pjsip.conf vs sorcery, или res_sorcery_astdb отсутствует в сборке /home/pi/.local/asterisk); (2) rollback.sh v1 непригоден; (3) моки CLI не заменяют реальный Asterisk — приёмка 508 обязана поднимать asterisk на стенде.
2026-09-06T14:56:53.956Z · coordinator[06.09 14:56Z координатор] [2026-09-06T14:56Z координатор] На проде l113h: big-test 1782161239510l4gl4zzur после revive --new-attempt индексируется (status=running, checkpoint 3328/3932, attempts=2) — новый parent бюджета работает. SIP: независимое ревью v2 (2338) = процедура v3 готова (: reload = module reload res_pjsip.so с проверкой endpoints>0; фаза 0 backup/validate+check; фаза 1 reload-only apply; фаза 2 proof без владельца — UDP Digest REGISTER 401→200 и contact через module reload; фаза 3 restart только при необходимости) — выполняю фазу 0 (read-only) сейчас, окно фаз 1–2 следом.
2026-09-06T14:59:41.699Z · coordinator[06.09 14:59Z координатор] [2026-09-06T14:59Z координатор] ОКНО ТЕЛЕФОНИИ v3 (14:57Z, A1): фаза 0 validate/check OK; фаза 1 = APPLY OK — v3 render path, module reload res_pjsip.so, endpoints=7, transports=3, PID Asterisk не изменился, AOR 7016 = 90/120/30 (цель WEB-508), :4080 200; бэкап /var/backups/ag-sip-native/20260906T145730Z-3911089-l113f-sync-v3. Фаза 2 = STOP «proof endpoint reload failed» (синтетический UDP-endpoint не появился после reload; runtime-файл восстановлен) — деплой оставлен (здоров по независимым проверкам), причина proof — в разбор. Фаза 3 (restart для активации barge-in WEB-463) — после подтверждения владельца.
2026-09-06T15:17:52.711Z · coordinator[06.09 15:17Z координатор] [2026-09-06T15:17Z координатор] WEB-547 (Astra 2114 generated config mode): приёмка 2336 = NO-GO cd9cee08 — контракт http.conf/ari.conf верен, регрессия x64 explicit-root (status/stop считают conf root иначе, чем start) → круг 2 = 2356 (M4). SIP proof-диагноз (2347) = NO-GO: внутренняя причина STOP proof-reload.sh:130-132 не восстановима без защищённого reload-add.raw; статические гипотезы отвергнуты (append верный, include-порядок верный); расхождение 6 vs 7 endpoints — мой grep считал заголовок. Круг 2 = 2347b с добавленным evidence. Фаза 3 (restart для barge-in) ждёт «го» владельца с зарегистрированным Linphone. SEC-007 config assurance → 2355 (A1) с receipts-паком.
2026-09-06T18:13:33.757Z · coordinator[06.09 18:13Z координатор] [2026-09-06T18:13Z координатор] SIP host sync v3 — фаза 2/3, состояние на 19:30Z.
- Фаза 1 (sync-plan --apply, reload-only) применена 14:57Z, backup /var/backups/ag-sip-native/20260906T145730Z-3911089-l113f-sync-v3; endpoints 6 (Objects found), AOR 7016 90/120/30.
- SIPPROOFDIAGB (A1, NO-GO для повторного запуска старого proof): непосредственная причина STOP — ненулевой rc от reload-sip-native.sh (proof-reload.sh:130-131); доказанный дефект дизайна v3 — временный proof-блок писался прямо в pjsip-generated.conf, которым владеет application renderer (pjsip-compact-defaults.conf:2-4), без hash-проверки между install и reload; «6 vs 7» endpoints — ошибка grep (заголовок Endpoint: считался объектом), авторитет — строка Objects found.
- SIPPHASE3RUNBOOK (A1, NO-GO = гейт входа): фаза 3 (restart для barge-in) запрещена, пока фаза 2 не даст PROOF OK с exact cleanup; условия: закрыт failed proof v3, повтор фазы 2 PASS, NEW_BACKUP прошёл rollback.sh --validate-only, одно no-call окно с Linphone владельца, на A1 нет второго Asterisk-юнита на :5060. Что реально требует restart: Node-модули gateway (audiosocketTransport/phoneAudioConfig/openaiRealtimeWsBridge — require cache), env 50-web508-reload-persist.conf (SIP_NATIVE_STATE_DIR/REQUIRED_AOR применяет только новый ExecStart), pre-seed в start-sip-native.sh; pjsip-generated.conf/AOR — уже активны после module reload.
- Запущено: 2367 SIPV32PROOF (A1) — proof v3.2: отдельный include-файл вне владения renderer, sha256 до/после reload, baseline через Objects found, raw stdout helper-а в evidence, restart-proof.sh с --i-am-coordinator.
KNOWN ISSUES / ТРАБЛШУТИНГ: симптом «proof endpoint reload failed» после успешной фазы 1 → проверка: есть ли reload-add.raw и hash файла до/после → причина: proof-reload.sh:79-128 пишет в файл renderer-а, конкурентный render/cleanup стирает блок → лечение: v3.2 (отдельный include, hash-гейт). Симптом «endpoints 7 при Objects found 6» → grep считает заголовок → считать только по Objects found (proof-reload.sh:42-49 в v3.1 уже так).
2026-09-06T18:45:45.072Z · coordinator[06.09 18:45Z координатор] SIP host sync — ФАЗА 2 ПРОЙДЕНА (proof v3.2), 18:44Z. `proof-reload.sh --i-am-coordinator` (v3.2): PROOF OK — baseline→baseline+1→baseline по Objects found; dedicated fragment stable across reload; pjsip-generated.conf/pjsip-compact-defaults.conf hashes unchanged. Endpoints после = 6, AOR 7016 = 3 контакта (зарегистрирован). Evidence /var/backups/ag-sip-native/20260906T184441Z-810967-proof-reload-v3.2. Активных звонков 0, реестр не тронут.
Первый прогон v3.2 STOP («add reload failed») — координатор нашёл корневую причину: reload-sip-native.sh детектит бинарь через find_asterisk (platform.sh), проверка №3 = `$HOME/.local/asterisk/sbin/asterisk`; под `sudo ./proof-reload.sh` HOME=/root → бинарь не найден, а ASTERISK_BIN в helper не экспортировался. Фаза 1 (sync-plan) работала, т.к. sync-plan экспортирует ASTERISK_BIN. Лечение (не правка скрипта): запускать фазу 2/3 как `sudo env ASTERISK_BIN=/home/pi/.local/asterisk/sbin/asterisk ASTERISK_PREFIX=/home/pi/.local/asterisk ./proof-reload.sh …`. Это же исправляет исходную причину STOP из SIPPROOFDIAGB (ненулевой rc reload-sip-native.sh).
Фаза 3 (restart для barge-in WEB-463): гейт входа выполнен (фаза 2 GO). Осталось: no-call окно + владелец с зарегистрированным Linphone. Команда: `sudo env ASTERISK_BIN=… ASTERISK_PREFIX=… ./restart-proof.sh --backup /var/backups/ag-sip-native/20260906T145730Z-3911089-l113f-sync-v3 --i-am-coordinator` (RUNBOOK.md §3). Что даёт рестарт: новый gateway-процесс перечитывает Node-модули (audiosocketTransport/openaiRealtimeWsBridge — require cache) и env 50-web508-reload-persist.conf; barge-in активируется только после рестарта.
KNOWN ISSUES / ТРАБЛШУТИНГ: симптом «proof STOP add reload failed» → проверка reload-add.raw = «Asterisk binary not found; refusing reload» → причина find_asterisk №3 использует $HOME, под sudo HOME=/root → лечение `sudo env ASTERISK_BIN=/home/pi/.local/asterisk/sbin/asterisk …`. Симптом «endpoints 6 vs 7» → grep считает заголовок → только Objects found.
2026-09-06T19:01:36.598Z · coordinator[06.09 19:01Z координатор] ФАЗА 3 (barge-in) — рестарт выполнен 19:01Z по «Го» владельца. Хронология: (1) фаза 2 GO (proof v3.2, 18:44Z); (2) restart-proof.sh --i-am-coordinator STOP «cannot query endpoints after restart» → авто-rollback --restart: причина в endpoints-after.raw — «Unable to connect to remote asterisk (asterisk.ctl)»: скрипт опрашивал Asterisk до подъёма control-сокета после restart (гонка, не binary-path); (3) rollback вернул pre-sync-v3 конфиг (sync-v3 --check показал дрейф: [sip-compact-aor] template, sorcery.conf, AOR 7016 timers) — телефония при этом здорова (endpoints 6); (4) я НЕ оставил откат: re-apply sync-v3 --apply (reload-only) вернул синхронизированный конфиг (--check: «v3 files already exact»), endpoints 6; (5) ручной рестарт ag-sip-native с ожиданием asterisk.ctl (до 40 с) + гард endpoints≥6 иначе rollback --restart: endpoints_after=6 (было 6), transports 4, свежий процесс шлюза (index.js/audiosocketTransport.js, uptime ~3 мин) = barge-in код загружен. 7016 после рестарта не зарегистрирован (TCP prune_on_boot; владелец закрыл Linphone) — просьба переоткрыть и позвонить на 8000 для проверки перебивания.
KNOWN ISSUES / ТРАБЛШУТИНГ: (1) restart-proof.sh v3.2 STOP «cannot query endpoints» → причина: опрос Asterisk до подъёма control-сокета после systemctl restart → лечение: v3.3 ждать asterisk.ctl (poll ≤40 с) перед первым query; временно — ручной рестарт с wait-loop. (2) reload/restart вообще: `sudo env ASTERISK_BIN=/home/pi/.local/asterisk/sbin/asterisk ASTERISK_PREFIX=/home/pi/.local/asterisk …` (find_asterisk №3 = $HOME, под sudo HOME=/root). (3) sync --apply STOP «contact set changed across reload» — ложно, если клиент переригистрируется во время reload; проверять --check после (должно быть «already exact»), не откатывать. Бэкап окна: /var/backups/ag-sip-native/20260906T185615Z-878870-l113f-sync-v3.
2026-09-06T20:43:28.329Z · coordinator[06.09 20:43Z координатор] BARGE-IN — КОРЕНЬ НАЙДЕН И ДОКАЗАН НА ПРОДЕ (BARGEINTRACE, A1 + live-проверка координатора 20:50Z). `dialplan show 8000@internal`: строка 6 = `Set(LIVE_UPSTREAM_ENABLED=__LIVE_UPSTREAM_ENABLED__)` — НЕподставленный placeholder (grep `__LIVE_[A-Z0-9_]+__` по /tmp/ag-asterisk-native/extensions.conf:37). Причина: `infra/sip/render-asterisk-dialplan.py` знает только `__LIVE_MEDIA_TRANSPORT__`/`__LIVE_STASIS_SNOOP_SPIKE_ENABLED__`, а `__LIVE_UPSTREAM_ENABLED__` — нет; `start-sip-native.sh` его не вычисляет и не передаёт renderer-у (default `SIP_EXPERIMENTAL_LIVE_UPSTREAM_ENABLED=1` экспортируется ПОСЛЕ render и старта Asterisk — влияет на gateway, не на диалплан). Следствие: GotoIf(... "${LIVE_UPSTREAM_ENABLED}"="1") ложен → 8000 идёт в `legacy_8000_agi`: приветствие играет основной gateway через FastAGI `STREAM FILE "<greeting>" "#"`, Record стартует только после него; caller PCM во время приветствия не поступает ни в OpenAI VAD, ни в speech detector, ни в response.cancel; единственный interrupt — клавиша «#». Фразой перебить невозможно по дизайну этого пути. `SIP_LANE8000_BARGE_IN=1` применяется в Stasis policy и на FastAGI не влияет. Это объясняет оба симптома владельца (приветствие слышно; речь не прерывает) и пустой journal (gateway пишет в /tmp/ag-asterisk-logs/* под PrivateTmp). Вторичный gap: в Stasis-пути OpenAI `caller_speech_started` без fast-cancel — работает local PCM detector с guard/RMS/echo.
ПЛАН: (1) 2441 BARGEINRENDERFIX (A2): placeholder в PLACEHOLDER_NAMES + `--live-upstream-enabled`, start-sip-native.sh вычисляет NATIVE_DIALPLAN_LIVE_UPSTREAM_ENABLED ДО render, generic-гард на любой `__[A-Z0-9_]+__` в rendered файле (fail startup), тест ветки 8000; (2) приёмка; (3) l113j (infra/sip в репо) + sync-plan --apply на хост; (4) рестарт ag-sip-native (фаза 3, v3.3 с ожиданием сокета) в окне с владельцем; (5) `dialplan show 8000@internal` = LIVE_UPSTREAM_ENABLED=1, ветка stasis_8000_enabled; (6) owner-call: barge_in_detected → playback stop → response.cancel в одном callId.
KNOWN ISSUES / ТРАБЛШУТИНГ: симптом «приветствие не перебивается речью» → проверка `dialplan show 8000@internal` строка LIVE_UPSTREAM_ENABLED и grep `__LIVE_` в extensions.conf → причина render без placeholder → лечение 2441 + рестарт. Симптом «journalctl -u ag-sip-native пуст во время звонка» → логи в /tmp/ag-asterisk-logs/{gateway,console,audiosocket}.out (PrivateTmp) — читать от root.
2026-09-06T20:56:58.600Z · coordinator[06.09 20:56Z координатор] CALL-LEVEL PROOF (CALLPROOFLOGS, A1, VERDICT=PRIMARY_ROOT_CAUSE_CONFIRMED_BY_CALL_LEVEL_ASTERISK_LOG): единственный звонок в окне 19:05–19:15Z, Asterisk full-лог 19:08:50.572: `Set LIVE_UPSTREAM_ENABLED=__LIVE_UPSTREAM_ENABLED__` → `GotoIf 0?stasis_8000_enabled:legacy_8000_agi` → `Goto internal,8000,18` → `NoOp Stable FastAGI fallback for 8000` → `AGI agi://127.0.0.1:4573`. Ветка stasis_8000_enabled (barge-in) не исполнялась; событий barge_in_detected/speech_started/response.cancel нет. Диагноз BARGEINTRACE подтверждён на уровне звонка. Фикс: 2441 BARGEINRENDERFIX (A2, идёт) → приёмка → l113j + sync-plan --apply → рестарт ag-sip-native (v3.3, wait-for-socket; SIPV33 GO, kit /home/ubuntu/waves/siphostsync-v3.3/) в окне с владельцем → `dialplan show 8000@internal` = LIVE_UPSTREAM_ENABLED=1.
2026-09-06T21:18:27.954Z · coordinator[06.09 21:18Z координатор] BARGEINRENDERFIX (A2, PASS_READY_FOR_COORDINATOR_APPLY, 28467587 на 18f13093): renderer знает __LIVE_UPSTREAM_ENABLED__ (+ --live-upstream-enabled), start-sip-native.sh вычисляет NATIVE_DIALPLAN_LIVE_UPSTREAM_ENABLED ДО render, новый guard-rendered-asterisk-dialplan.py (любой __[A-Z0-9_]+__ в rendered = fail startup), тест ветки 8000. Порядок применения (из отчёта): 1) sync-plan --apply (файлы infra/sip на хост, включая новый guard); 2) restart ag-sip-native через фазу 3 v3.3 с ожиданием control socket; 3) `dialplan show 8000@internal` = LIVE_UPSTREAM_ENABLED=1, ветка stasis_8000_enabled; 4) owner-call: перебить приветствие. Перед хост-применением — независимая приёмка 2457 ACCBARGEINRENDERFIX (A2, offline на снимке). Рестарт — в окне с владельцем.
2026-09-06T23:01:53.818Z · coordinator[06.09 23:01Z координатор] 🛬 ПОСАЖЕН l113j (46393080dd885f6ff25967f18639075564e12737) на прод 06.09 22:56:47Z (nc-a1) / 22:56:54Z (nc-a1-b) без простоя (контроллер по одному бэкенду, edge ×8 = 200, paid enforce_ready на обоих). Артефакт me2-standalone-linux-arm64-46393080d-20260906T225025Z sha 44b32502…; RUN l113j-46393080; откат = l113i 18f13093. Состав (L113JPREP2 GO, 15 коммитов): BARGEINRENDERFIX 28467587 (WEB-463: рендерер знает LIVE_UPSTREAM_ENABLED → 8000 идёт в live-upstream; на шлюз ещё нужен sync-plan --apply + рестарт в окне), ROLES5BREBASE c010b7de (roles 5b: admission ≤2000 + repair карантина, ACC GO), DOCENGINECOMPLETENESSR2 e3558f48 (ACC GO), INVITE502R2 (ACC GO), controller adopt ed2b3bf2 (writer, dormant до бинаря на хосте; r2 1fc3f8a9 → l113k), единый regen activation manifest. Env по решениям владельца: APP_ALLOWED_HOSTS += 127.0.0.1:3012 (SEC-007 F1), EMAIL_TRANSPORT=resend через nc-fence (allowlist += api.resend.com:443; было: транспорт off с 25.08 — старые ключи SMTP_HOST vs новые EMAIL_*), LEGAL_DOC_MODE=real + реквизиты DMCA-1079963. Миграций новых нет (P19 189). hetzbk publish/env-pack — см. следующий комментарий. Далее: батарея ролей на l113j, dry-run репейра карантина (--in-process-repair, --conditions=react-server), SIP фаза 3.
2026-09-06T23:08:18.925Z · coordinator[06.09 23:08Z координатор] ПОПРАВКА К ЗАПИСИ О ПОСАДКЕ l113j (координатор, проверено по дереву /home/ubuntu/waves/wt-l113j-migrate = 46393080): в l113j ВОШЛИ (18f13093..46393080, 15 коммитов): 8e04c643 fix(sip): materialize live upstream before dialplan startup (= BARGEINRENDERFIX, WEB-463), 474f66fe WEB-528 pnpm/ws floors, 71da9514/21fe91d3/06b2540c SIP config root/x64/atomic publish, 8d6073c2/44c28245 notion diagnostics, 80183b6b l113g activation migration manifest refresh, f7a65d73 WEB-477 idempotency, 1ed5d212/593db10a public landing Vary/static cache, e7697d17/09c4b152 WEB-507 composer, c258d9b7 realtime squash, 46393080 regen activation manifest. НЕ ВОШЛИ (stage 2 L113JPREP2 — «проба на отдельной копии, в bundle/HEAD не входит» из-за prisma/migration-compatibility-manifest.json baseline l113i): ROLES5BREBASE c010b7de (roles 5b + quarantine repair: в дереве нет --in-process-repair/repairQuarantinedSource), DOCENGINECOMPLETENESSR2 e3558f48, controller adopt ed2b3bf2, INVITE502R2. Следствие: прод-репейр карантина на l113j НЕВОЗМОЖЕН; всё это + PODCASTRESOLVE a1248d77 (+миграция) + UPSTREAMCTRLADOPTR2 1fc3f8a9 + VOICERETRYAFTERGATE (после приёмки) собираются в l113k с явным решением манифеста миграций (P19 contract-фаза).
2026-09-06T23:32:39.894Z · coordinator[06.09 23:32Z координатор] SIP ФАЗА 3 — КИТ v4 (волна 2496 SIPHOSTSYNCV4, A1 sol, 23:27Z): OFFLINE GO — release provenance (HEAD 46393080, renderer fix 8e04c643), полный blob-контракт, immutable private-copy --check, однострочный render-diff (Set(LIVE_UPSTREAM_ENABLED=1)), guard-тесты, v3.3 snapshot reload check + restart validate-only, control-socket readiness test — все rc 0. Кит /home/ubuntu/waves/siphostsync-v4/ (sync-plan.sh с self-contained payload, proof-reload.sh, restart-proof.sh v3.3, rollback.sh, RUNBOOK фазы 0–4 с точным backup 20260906T185615Z-878870-l113f-sync-v3). Координатор: фаза 0 + фаза 1 (validate backup под sudo) выполняются сейчас; фазы 2–3 (sync --apply + reload proof, restart + 7016 re-registration) — в окне с владельцем (SIP недоступен ~10–40 с).
2026-09-06T23:52:21.442Z · astra-securityblock22-relay9-adjudication-web-463 — 2026-09-06T23:52:21.441925+00:00 / IST=2026-09-07T05:22:21.441932+05:30
BLOCK22 RELAY-9: вердикты по доставленному пакету. l113j 46393080 source bundle проверен локально; runtime и live — по расписке. Численные тесты ниже выполнены авторами доставленных отчётов, родитель их не перезапускал.
CALLPROOFLOGS-REPORT.md — новый отчёт.
Вердикт: GO for root-cause proof only. Independent call-level evidence confirms the prior WEB-463/BARGEINTRACE diagnosis for the 19:08:50Z 8000 call: Asterisk took legacy_8000_agi because LIVE_UPSTREAM_ENABLED rendered as a literal placeholder. This is not a full live acceptance of the later fix.
Commit/base: No product commit in this report. L113J receipt later maps WEB-463 BARGEINRENDERFIX replay to 8e04c6432 within deployed 46393080dd885f6ff25967f18639075564e12737. / Production log snapshot around 2026-09-06T19:08:50Z; release line context from relay cover is pre-l113j, with l113j later deployed at 46393080dd885f6ff25967f18639075564e12737.
Доказательства: Read-only log analysis only. No tests/build/live calls were run by the report. Meaningful proof is the exact Asterisk branch log, not a harness assertion.
Anchors: /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/a1/CALLPROOFLOGS-REPORT.md:8; /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/a1/CALLPROOFLOGS-REPORT.md:12; /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/a1/CALLPROOFLOGS-REPORT.md:42; /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/a1/CALLPROOFLOGS-REPORT.md:86; /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/L113J-RELEASE-RECEIPT.md:18
KNOWN ISSUES / ТРАБЛШУТИНГ: STREAM FILE, RECORD FILE, exact Answer timestamp, and exhaustive absence of barge_in/speech_started/response.cancel are not independently proved from this snapshot.
Действие: Use this as supporting RCA evidence for WEB-463. Closure still requires accepted/deployed renderer landing plus SIP host-sync proof that dialplan 8000 has LIVE_UPSTREAM_ENABLED=1 and no placeholder.
Report: /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/a1/CALLPROOFLOGS-REPORT.md
SHA256: ef50178f8a2feb3e6d45b4df93e6db35066324817a66c5e3c88de6203b7cf979
SIPV33PREVALIDATE-REPORT.md — новый отчёт.
Вердикт: OFFLINE GO / LIVE NO-GO upheld. The v3.3 SIP restart-proof kit passes offline integrity and validation, but live window admission is blocked by missing exact backup validation, stale RUNBOOK backup path, and missing renderer-aware BARGEINRENDERFIX bundle/sync-plan.
Commit/base: Checked repo line 18f130938b8d2a8f4376811651ad21beb4e28838. Required renderer fix commit 28467587 was unavailable in that local line; l113j later contains replay 8e04c6432 for WEB-463. / /home/ubuntu/waves/wt-l113i-migrate at l113i 18f130938b8d2a8f4376811651ad21beb4e28838; kit directory /home/ubuntu/waves/siphostsync-v3.3.
Доказательства: sha256sum -c SHA256SUMS exit 0; ./proof-reload.sh --check --snapshot exit 0; ./restart-proof.sh --validate-only --snapshot exit 0; ./tests/offline-check.sh exit 0. Exact backup validate-only against /var/backups/... exit 1 due inaccessible root-only path.
Anchors: /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/a1/SIPV33PREVALIDATE-REPORT.md:7; /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/a1/SIPV33PREVALIDATE-REPORT.md:33; /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/a1/SIPV33PREVALIDATE-REPORT.md:130; /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/a1/SIPV33PREVALIDATE-REPORT.md:165; /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/a1/SIPV33PREVALIDATE-REPORT.md:436; /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/L113J-RELEASE-RECEIPT.md:18
KNOWN ISSUES / ТРАБЛШУТИНГ: No live backup VALIDATION OK, no updated RUNBOOK, no renderer-aware sync-plan, no 0 active calls/endpoints=6/7016 Avail/unit enablement proof, and no dialplan show 8000 post-check.
Действие: Proceed only through the existing SIPHOSTSYNCV4 coordinator lane after exact backup validation and renderer-aware bundle admission.
Report: /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/a1/SIPV33PREVALIDATE-REPORT.md
SHA256: a97a0c060fbfb8591d22e912266783caf4e92de95bb0f4f62fb1c83b5663f59c
ACCBARGEINRENDERFIX-REPORT.md — повтор ранее полученных байтов, не новая приёмка.
Вердикт: GO; accepted offline and represented in deployed l113j as replay commit 8e04c643, but runtime SIP host sync/owner-call remained a separate gate
Commit/base: 284675873f61af90e23cfb0532ea7dbb7ecb03f5 (source candidate); l113j replay 8e04c6432db346ab22cef736be784c58f0cb60be / 83683d4818ecc9b91e151be9e27a9ef0d6015294; production comparison 18f130938b8d2a8f4376811651ad21beb4e28838; l113j deployed source 46393080dd885f6ff25967f18639075564e12737
Доказательства: node /home/ubuntu/waves/ACCBARGEINRENDERFIX-VERIFY.mjs exit 0; node --test infra/sip/tests/*.test.js infra/sip/tests/*.test.mjs: 11/11 pass; node --test tests/unit/sip-render-asterisk-dialplan.test.ts tests/unit/sip-audiosocket-prehook-order.test.ts: 2/2 pass; shellcheck --severity=error infra/sip/start-sip-native.sh exit 0; git diff --check 83683d481..284675873 exit 0
Anchors: infra/sip/render-asterisk-dialplan.py; infra/sip/guard-rendered-asterisk-dialplan.py; infra/sip/start-sip-native.sh; infra/sip/asterisk-conf/extensions.conf
KNOWN ISSUES / ТРАБЛШУТИНГ: Offline acceptance only. Runtime dialplan show, Asterisk restart, and owner-call/barge-in proof were not executed here. Apply runtime files atomically.
Действие: Do not open another WEB-463 source brief. Close runtime through existing SIP host-sync/activation path and confirm dialplan marker-free route plus one owner-call.
Report: /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/a2/ACCBARGEINRENDERFIX-REPORT.md
SHA256: 13a449d45dc0b398f7eac1ccc2abf7765bef557661078b7708509656e6cfe3ba
L113JPREP2-REPORT.md — новый отчёт.
Вердикт: GO for l113j stage-1 assembly at 46393080; deployed receipt confirms l113j, but stage 2 was only a probe and did not land.
Commit/base: 46393080dd885f6ff25967f18639075564e12737 / 18f130938b8d2a8f4376811651ad21beb4e28838
Доказательства: check-migration-compatibility rc 0, migrationCount 189; check-api-perimeter rc 0; realtime 61/61; active/passive lease 11/11; landing/proxy/final HTTP 56/56; composer DOM matrix pass; WEB477 23/23 plus negatives; Notion 11/11; SIP/genconfig/barge-in suites pass; activation checks pass; git fsck rc 0; bundle verify rc 0
Anchors: monet-w34-activation-manifest.json; monet-w35-activation-attestation.json; src/lib/billing/generatedActivationManifest.ts; public/_landing.html; src/proxy.ts; infra/sip/*
KNOWN ISSUES / ТРАБЛШУТИНГ: Stage 2 NOT on j: roles5b, docengine R2, controller R2, invite, podcast, beta, citation, overdraft, voice retry. Landing WEB-545 rewrite caused / 500 after deployment and was mitigated by PUBLIC_LANDING_ENABLED=false; fix is wave 2495. Keep WEB-545 landing label separate and do not overwrite SEC545 Lighthouse. Canonical SEC-028/WEB-545 remains Lighthouse; landing label collision is recorded only as provenance.
Действие: Use l113j only for deployed stage-1 contents. Route deferred stage-2 work through l113k/accepted waves; keep landing rewrite under 2495.
Report: /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/a2/L113JPREP2-REPORT.md
SHA256: 8ff5adf24deb0d47091e4e1a5faa38676c582a7337777f6ec18e1babccdce7b3
КАРТА ДОКУМЕНТОВ: /Users/poolpooly/audit/reports/block22-relay9-update.md; /Users/poolpooly/audit/evidence/block22/ledger46.json; /Users/poolpooly/audit/evidence/block22-relay9/adjudications.json. Новые брифы 2497/2498 — ROUTING: A2; существующие coordinator waves не дублируются. Правила обогащения: WEB-449.
2026-09-07T00:50:09.059Z · coordinator[07.09 00:50Z координатор] SIP ФАЗА 2 ВЫПОЛНЕНА (координатор, 00:49Z, кит v4): sync-plan --apply установил 4 reviewed-файла (render-asterisk-dialplan.py b810ef8f, guard-rendered-asterisk-dialplan.py 6869a590, extensions.conf c2741177, start-sip-native.sh 7939a8a1) + runtime materialization Set(LIVE_UPSTREAM_ENABLED=1); proof-reload: DIALPLAN GO (8000 upstream=1, гейт выбирает stasis_8000_enabled, legacy — fallback), PROOF OK ×2, evidence /var/backups/ag-sip-native/20260907T004909Z-2832749-proof-reload-v3.3; `dialplan show 8000@internal`: `6. Set(LIVE_UPSTREAM_ENABLED=1)`, GotoIf → stasis_8000_enabled. Фаза 3 (restart-proof, 7016 re-registration) — сразу следом.
2026-09-07T00:50:35.051Z · coordinator[07.09 00:50Z координатор] SIP ФАЗА 3 (restart-proof v4, 00:49:25Z): STOP ДО рестарта — «no live 7016 contact before restart; auto re-registration is unproven» (телефон владельца офлайн ночью); рестарт не выполнялся, откат не требовался, сервис active. Диалплан уже живой после фазы 2 (reload): 8000 → stasis_8000_enabled с LIVE_UPSTREAM_ENABLED=1 — перебивание проверяемо звонком уже сейчас. Фаза 3 повторить, когда `pjsip show contacts` покажет 7016 (утро): та же команда restart-proof.sh --backup 20260906T185615Z-878870-l113f-sync-v3 --i-am-coordinator.
2026-09-07T01:14:05.278Z · coordinator[07.09 01:14Z координатор] SIP 07.09 00:54Z: два звонка владельца (7016@sip.wool2.online → 8000) дошли до шлюза, Answer, ушли в Stasis(live-8014-snoop-ingress-spike) — приложение не взяло звонок: в это окно (00:41–01:09) падала lease-аттестация (ActivePassiveLeaseAttestationError ×6 в журнале, см. инцидент NC_UPSTREAM_BACKEND_NAME). После 01:09 путь исправен; владельцу предложено перезвонить. Фаза 3 (restart-proof) — когда 7016 зарегистрирован на шлюзе (сейчас Unavailable).
2026-09-07T06:09:40.249Z · coordinator[07.09 06:09Z координатор] СИП / звонок владельца 05:17Z («приветствие, потом кладут трубку»): волна 2528 LIVELANEDISCLOSURE (A1, sol) = FIX_READY_OFFLINE, коммит e12d2e1a «fix(sip): acknowledge live disclosure playback» над d00b8f35. Два дефекта: (1) session-start вычислял fail-closed outcome для ещё НЕ проигранного disclosure и писал hangup_or_route_human/disclosure_not_delivered уже при создании сессии; (2) Stasis ARI playback ждал только websocket-событие PlaybackFinished — потеря события превращала успешный старт в playback_resume_timeout. Теперь начальное состояние wait_for_disclosure, доставка подтверждается фактическим концом ARI playback или AudioSocket turn-end. Причинность именно для 05:17 не доказана (в срезе нет gateway JSONL с call.final) → после посадки обязателен контрольный live-звонок. Дальше: приёмка 2539 (A2) → посадка в l113n + host-sync gateway (координатор, окно) → контрольный звонок владельца.
2026-09-07T06:42:34.972Z · coordinator[07.09 06:42Z координатор] ПРИЁМКА 2539 ACCLIVELANEDISCLOSURE (claude-opus, 06:16–07:00Z) фикса 2528 = GO (4 задокументированных остаточных риска, ни один не блокирует): cherry-pick на l113l чист → 4edc09d1 (9 файлов, +435/−17), строки дефектов в прод-базе подтверждены лично (sessionStart.ts + stasisSnoopIngressSpike.js). Дальше: sessionStart → l113n; gateway-часть — host-sync координатором в окне (⛔ волны); затем контрольный звонок владельца на 8000.
2026-09-07T07:17:44.632Z · coordinator[07.09 07:17Z координатор] КАНДИДАТ l113n (2554 L113NPREP, sol, 07:15Z): VERDICT=GO, commit 44d8af68 над ПРОД l113m 8f4ba1d9 (bundle sha 4d8f6691…): BLOCK19UNLANDEDR2 (Slack signed ingress 88afe3ca, push completion 83de1a1d WEB-549, account-delete 85768ecb WEB-551), BATTERYFAILS3 41aea00b (WEB-99), LIVELANEDISCLOSURE 8c8a7bcf (WEB-463/519 app-часть), regen manifest. Сборка на A2 запущена 07:40Z → посадка ~08:30Z.
2026-09-07T07:37:05.319Z · coordinator[07.09 07:37Z координатор] СИП gateway host-sync v5 (волна 2556, A1, sol xhigh, 07:36Z): VERDICT=GO KIT_READY_OFFLINE — кит /home/ubuntu/waves/gwsync-v5/ (apply.sh с бэкапом, rollback.sh, runtime-proof.sh 60 с, RUNBOOK, patched/ + diffs/, LIVE-DIFF-MANIFEST). Живой gateway — не дерево одного коммита: 18/59 файлов = d00b8f35, 24 с host-only дельтой, 17 только live, 9 только в репо; фикс e12d2e1a reconcile-нут поверх живой копии. Применение — координатором в окне без звонков ПОСЛЕ посадки app-части (l113n, sessionStart.ts) + proof + контрольный звонок владельца на 8000.
2026-09-07T07:48:44.294Z · coordinator[07.09 07:48Z координатор] ПОСАЖЕНО: ПРОД = l113n (44d8af68) с 07:47:36Z 07.09 (флип 07:46:41–07:47:36Z rolling). Над l113m: 88afe3ca Slack signed ingress (SEC-027/WEB-544), 83de1a1d push completion (WEB-549), 85768ecb account-delete completion (WEB-551) — три «принятых, но не посаженных» фикса блока 19 (аудит 2541 → r2 2549, ACC 2545); 41aea00b фиксы батареи ролей (WEB-99: окно T-365 по UTC-полуночи, C4-CROSS; ACC 2544 GO); 8c8a7bcf сип disclosure app-часть (WEB-463/519; ACC 2539 GO). Артефакт 37f136cf…, attestation fable-a2-l113n, активация подписана владельцем, миграций нет (190/190). Verify: ready/paid enforce_ready на обоих бэкендах, edge ×8 = 200, корни ×3 = 200, /login 200, вебхук 401, AttestationError/nginx/LEASE_LOST = 0, Telegram pending 0. hetzbk + env-pack + Pi → l113n-44d8af68. Откат = l113m. Расписка L113N-RELEASE-RECEIPT.md (A1/A2/M4 queue + inputs/release). Далее: gateway host-sync v5 (кит 2556) + контрольный звонок; post-QA 2572; батарея r44.
2026-09-07T07:55:56.760Z · coordinator[07.09 07:55Z координатор] GATEWAY HOST-SYNC v5 ПРИМЕНЁН (координатор, 07:54:12Z, окно без звонков, 0 каналов): патченные stasisSnoopIngressSpike.js + audiosocketTransport.js из кита 2556 положены в живой каталог gateway (sha = PATCHED-SHA256SUMS), ag-sip-native перезапущен: readiness 4080 = 200, audiosocket 4084 = 200 через 24 с, ARI connected, 0 ошибок/LEASE_LOST в свежих логах за 60 с. Бэкап живых файлов: /var/backups/ag-sip-native/20260907T075224Z-gateway-v5 (rollback.sh кита). App-часть (sessionStart wait_for_disclosure) — в l113n с 07:47Z. Ждём контрольный звонок владельца на 8000.
KNOWN ISSUES кита gwsync-v5 (для следующих версий): (1) apply.sh: node --check на staged-файле с суффиксом .$$ падает ERR_UNKNOWN_FILE_EXTENSION → staging-имя должно кончаться на .js; (2) apply.sh проверяет живость gateway PID «на секунде 1» после systemctl restart — супервизор поднимает Asterisk+gateway ~20 с → ложный STOP и авто-rollback (07:52Z стек на 1 мин был без gateway/audiosocket); нужно ждать новый PID-файл/readiness до 90 с; (3) runtime-proof.sh grep-ит ВЕСЬ gateway.out — старые LEASE_LOST от флипов дают ложный STOP; нужен offset от момента рестарта; (4) SHA256SUMS кита включает сами скрипты — любая правка координатора требует пересчёта. Применение сделано вручную по шагам кита после этих находок.
2026-09-07T08:03:16.022Z · coordinator[07.09 08:03Z координатор] КОНТРОЛЬНЫЕ ЗВОНКИ ВЛАДЕЛЬЦА 07:57:23Z и 07:57:57Z на 8000 (после l113n + gateway v5): по-прежнему сброс после приветствия, но ПРИЧИНА СМЕНИЛАСЬ. Consent-часть исправлена и работает: app лог wait_for_disclosure → disclosure playback started → «disclosure delivered» (раньше здесь был hangup_or_route_human). Теперь gateway: `deferred_rejected label=responseDeferred message=Error committing input audio buffer: buffer too small (0.00ms)` → hang-report stasis-snoop-deferred-rejected → `final status=gateway_error` → трубка. Т.е. resume отложенного ответа после disclosure коммитит пустой input-буфер в OpenAI realtime (providerAppendCount=0) и ошибка провайдера считается фатальной. Фикс-волна 2573 SIPGATEWAYEMPTYCOMMIT (A1, sol xhigh) → кит gwsync-v6 → применю → снова звонок. KNOWN ISSUES: симптом «приветствие → гудки» → проверка `grep deferred_rejected /tmp/ag-asterisk-logs/gateway.out` → причина: commit пустого буфера при resume → лечение: v6.
2026-09-07T08:36:05.975Z · coordinator[07.09 08:36Z координатор] GATEWAY v6 ПРИМЕНЁН (координатор, 08:34:35Z, окно без звонков, 0 каналов): фикс 2573 «ignore empty realtime audio commits» (edbb54d2; файлы stasisSnoopIngressSpike.js, audiosocketTransport.js, liveTransport/openaiRealtimeWsBridge.js) поверх живой v5-копии; бэкап /var/backups/ag-sip-native/20260907T083434Z-gateway-v6; после restart readiness 4080 + audiosocket 4084 = 200 за 6 с, ARI connected, 60 с журнала без gateway_error/buffer too small/LEASE_LOST. Ждём контрольный звонок владельца. Причинность обоих звонков 07:57/07:58 доказана в SIPGATEWAYEMPTYCOMMIT-REPORT.md (таблица consent→playback→deferred_rejected 0.00ms→gateway_error).
2026-09-07T08:40:22.676Z · coordinator[07.09 08:40Z координатор] КОНТРОЛЬНЫЕ ЗВОНКИ 08:36Z/08:38Z (после gateway v6): всё ещё сброс после приветствия. Лог: consent delivered ✔, `empty_input_audio_commit_nonfatal … action=recover` ✔ (v6 работает), затем без причины `call_summary frames_above_threshold=63–72 providerAppendCount=0 candidateFrames=0` → `final status=gateway_error`. Третий слой: после recover gateway не переходит в прослушивание (речь абонента есть, в провайдер не аппендится) и молча финализирует звонок. Фикс-волна 2584 SIPGATEWAYRECOVERFINAL (A1) → кит v7. KNOWN ISSUES: симптом тот же → проверка gateway.out: recover есть, но между recover и final нет reason → причина: пустой turn = fatal + ingest заблокирован greeting-состоянием → лечение: v7 (LISTEN после disclosure, reason у каждого finalizeCall).
2026-09-07T09:38:38.904Z · coordinator[07.09 09:38Z координатор] GATEWAY v7 ПРИМЕНЁН (координатор, 09:37:06Z, 0 каналов): фикс 2584 c0e3b233 (третий слой — после recover переход в LISTEN, пустой turn не финализирует, reason у каждого finalizeCall) поверх v6; один файл stasisSnoopIngressSpike.js; бэкап /var/backups/ag-sip-native/20260907T093706Z-gateway-v7; readiness 4080 + audiosocket 4084 = 200 за 6 с, ARI connected, 60 с без fatal-сигнатур. Ждём контрольный звонок владельца. Отчёт A1 SIPGATEWAYRECOVERFINAL-REPORT.md (таблица причинности обоих звонков 08:36/08:38).
2026-09-07T11:40:33.052Z · ЭВОЛЮЦИЯ ЗА 12 Ч (гигиена 2609, 11:25Z 07.09)
ХРОНОЛОГИЯ КРУГОВ
- App-side live disclosure `e12d2e1a` → ACC 2539 GO (`A2 waves/ACCLIVELANEDISCLOSURE-REPORT.md`) → replay `8c8a7bcf` в l113n.
- Host gateway v5 consent, v6 empty-commit and v7 LISTEN-after-disclosure kits прошли offline GO и применены 07:54/08:34/09:37Z (`A1 waves/SIPGATEWAYSYNCV5-REPORT.md`, `A1 waves/SIPGATEWAYEMPTYCOMMIT-REPORT.md`, `A1 waves/SIPGATEWAYRECOVERFINAL-REPORT.md`).
- Два owner calls 08:36/08:38 были до v7; post-v7 результат отсутствует.
- Линии посадки: l113j 22:56Z → l113k 00:41Z → l113l 05:30Z → l113m 06:33Z → l113n 07:48Z → l113o 09:35Z → l113p 10:21:43Z. Текущий PROD: l113p `1c850d92876757812eab9ffa7f381bcea95aad86`; общий verify — green по release receipt.
ДЛЯ НУЛЕВОГО АГЕНТА
- На проде app replay есть; gateway v7 применён host-side. Непосаженного app-кандидата нет, но live call closure не доказан.
- Следующий шаг / владелец: Координатор + owner: один correlated контрольный звонок после v7 и bounded readiness/log proof. До этого review.
KNOWN ISSUES / ТРАБЛШУТИНГ
- Симптом: caller path сбрасывался → проверка sequencing gateway → причина: LISTEN должен стартовать после disclosure → лечение v7; остаток — реальный звонок. `A1 waves/SIPGATEWAYRECOVERFINAL-REPORT.md`.
СВЯЗИ / ИСТОЧНИКИ
- Release: `M4 waves/L113P-RELEASE-RECEIPT.md`; координаторский срез: `M4 waves/OPS-STATUS-HEAD-1120.md`; точные отчёты перечислены в хронологии/KNOWN ISSUES.
- Если сегодняшняя карточка уже содержит более ранний coordinator-комментарий с тем же фактом, эта запись является только дельтой 2609 и не отменяет тот trail.
2026-09-07T12:08:38.384Z · coordinator[07.09 12:08Z координатор] **Контрольный звонок владельца на 8000 (12:05:24Z 07.09, callId 3a9bfc7d…): трубка после приветствия — причина найдена по логу с метками (кит 2613 применён 11:59Z).** Цепочка: initial_greeting → disclosure delivered 12:05:35.812Z → listen_ready → 12:05:40.804Z `empty_input_audio_commit_nonfatal code=input_audio_buffer_commit_too_small action=recover` → `listen_ready reason=empty_commit_recovered` → **12:05:41.131Z `final status=gateway_error reason="Cannot read properties of null (reading 'promise')" stage=listen`** → hangup. Это 4-й сбой одного класса на живом звонке (v5 consent 07:54Z, v6 пустой коммит 08:34Z, v7 LISTEN 09:37Z, теперь null-объект хода после recover) → по правилу «третья находка одного класса = дефект устройства» волна **2627** (A2, sol xhigh) переделывает машину состояний хода (turn-контроллер, ошибки обработчиков не завершают звонок) на снимке живого кода 1210Z + RED/GREEN по трейсу; кит → окно рестарта. Трейс: A2 `waves/inputs/sip-live/call-8000-20260907T1206Z.log`. Также в окне 12:00Z: кит 2613 (метки времени + lease-poll по времени) применён; 2614 (509) откачен — маркер зависимостей не там (круг 2 = 2624); ротация ARI не подействовала (источник учётки не env → волна 2626).
2026-09-10T14:32:41.713Z · coordinatorЗАКРЫВАЮ 10.09 — перебивание работает на боевом звонке владельца, доказано независимо.
История: починено 09.09 волной 3195 на живом шлюзе (providerAppendCount 0 -> 2704),
владелец подтвердил тогда же.
НЕЗАВИСИМОЕ ПОДТВЕРЖДЕНИЕ 10.09. Владелец позвонил на 8000 в 14:06Z
(callId=144a4bfb-1eb2-4ae2-9752-4379a72c5687). В логе шлюза:
barge_in detected turnIndex=0 reason=caller_barge_in_during_playback
barge_in detected turnIndex=1
barge_in detected turnIndex=2
call_summary barge_events=3 barge_latency_ms=3
Три перебивания подряд, задержка 3 мс. То есть ассистента перебить МОЖНО — предмет тикета закрыт.
ВАЖНО, ЧТО ЭТО НЕ ЗАКРЫВАЕТ: сам звонок владельцу пользы не принёс — приветствие заблокировано,
1.8 МБ его речи выброшено. Это ДРУГОЙ дефект, заведён отдельно как WEB-597.
Закрываю именно перебивание и только его.
Воркер
не привязан — привязать:
curl -X POST https://bugs.wool2.online/api/web/assign -H 'content-type: application/json' \
-d '{"issueId":"WEB-463","session":"<имя tmux-сессии>","host":"m4"}'
Обновлён
2026-09-10T14:32:41.715Z