WEB board

P1 [ТЕЛЕФОНИЯ]: SIP-звонки на 8000/8010 обрываются — клиент owner не зарегистрирован (endpoints 7015/7016 оба Unavailable)

# SIP 8000 (OpenAI) / 8010 (Gemini) — обрыв звонка (owner 23.08)

⚠️ ЗОНА: телефония = изолированный codex-инженер (внешний, через owner). Контурным воркерам конфиги SIP НЕ трогать (память telephony-zone-isolated-codex). Этот тикет — диагностика read-only + передача.

## Симптом (owner)
Звонки на внутренние номера 8000 (лег OpenAI) и 8010 (лег Gemini) обрываются сразу.

## Read-only диагностика координатора (23.08 01:20 IST, всё с Pi)
- Сервисы живы: ag-sip-native.service (active c 04.05, supervisor+asterisk+gateway+audiosocket), ag-sip-native-opus-experimental, freeswitch.
- **Корень на поверхности: `pjsip show endpoints` → существуют ТОЛЬКО 7015/7016 и оба `Unavailable` (0 контактов)** — SIP-клиент owner не зарегистрирован/не достучался. `core show channels`: 0 active, всего 5 calls processed за всё время.
- Конфиг перегенерирован 04.05 (/tmp/ag-asterisk-native/pjsip-generated.conf): в апрельских логах звонки шли от **7011/7012** — этих endpoint-ов больше НЕТ. Вероятно, клиент owner настроен на старый номер/пароль.
- Гейтвей-лог (/home/pi/ag-voice/infra/sip/.gateway.log) мёртв с 22.04 — свежие попытки до гейтвея НЕ доходят: обрыв на регистрации/дозвоне, ДО легов OpenAI/Gemini.
- Drop-ins юнита: zz-openai-8010.conf, meeting-room-proof*.conf и др. (/etc/systemd/system/ag-sip-native.service.d/).

## Что проверить инженеру (по силе)
1. Регистрация клиента owner: логин/пароль/номер (7015 или 7016?), транспорт (UDP/TCP/TLS, порт), NAT. Апрельская конфигурация клиента была на 7011/7012.
2. Если регистрация оживёт, но леги к OpenAI/Gemini будут рваться — проверить, не режет ли их nft/egress-ограда Pi ПОСЛЕ посадок 30/31 (22-23.08 сторож уже блокирует vendor-вызовы note-clone мимо gateway — см. WEB-316; SIP-гейтвей ходит к OpenAI напрямую).
3. Асофон-конфиг живёт в /tmp (переживает ли ребут Pi?) — /tmp/ag-asterisk-native/*.conf от 04.05.

## Эволюция вопроса
- Паркованная серия Meeting Room/SIP: WEB-45, WEB-46 (roomcall 8010 guards), WEB-15/17 (индикация состояния).
- WEB-307 (review): boot-контракт и телефонийные env.
- Прод-лог блокировок vendor-egress 23.08: см. WEB-316 (общий подозреваемый для легов).
- Память: telephony parked-13 (05.08), codex-engineer-vs-codex-lead (инженер внешний).

## 23.08 01:45 UTC — уточнение корня после owner-репро «het is not valid extension»
- Owner: при звонке на 8000 И на 8010 IVR отвечает «not a valid extension» — звонок ДОХОДИТ до какой-то АТС.
- Но ag-sip asterisk: `pjsip show contacts` → **No objects found** (ноль регистраций), endpoints 7015/7016 Unavailable. До нашей станции звонок не доходит.
- На Pi работают ДВЕ станции: `freeswitch.service` И `ag-sip-native` (asterisk на нестандартном конфиге /tmp/ag-asterisk-native). Гипотеза: телефон owner зарегистрирован во FreeSWITCH (вероятно, стандартный 5060), а «not valid extension» говорит его дайлплан, где 8000/8010 нет.
- Дайлплан ag-sip проверен: 8000 (AGI gateway) и 8010 (Stasis live) объявлены в [internal], endpoints 7015/7016 тоже context=internal — внутри нашей станции маршрут есть; в extensions.conf ДВА раздела [internal] (строки 9 и 223) — мержатся, но инженеру стоит взглянуть.
- Инженеру: выяснить, какая АТС держит регистрацию телефона owner (порты/транспорты обеих), либо перевести клиент на транспорт ag-sip, либо бриджевать 8000/8010 из FreeSWITCH. Пароли эндпоинтов в pjsip-generated.conf (НЕ публиковать).

## 23.08 00:47 UTC — ВАЖНАЯ поправка owner (переворачивает приоритет диагностики)
- Owner: «8000 и 8010 — это звонки кодексу и опусу; codex-live и opus-live сейчас ВЫКЛЮЧЕНЫ (их обрыв штатен). А вот ЗВОНКИ В ТЕТРАДЬ — это и есть 7015/7016, и там IVR отвечает not valid extension».
- Итого чинить надо: маршрут «звонок в тетрадь» через линии 7015/7016.
- Факт из конфига (read-only): в extensions.conf [internal] НЕТ exten для 7015/7016 — это регистрационные endpoints (клиентские линии, pjsip-generated.conf: 7015 «Pi Public Proof», 7016 «Pi Agent Line»), а НЕ набираемые номера. Ассистент-тетрадь в дайлплане = ext 8000 (AGI gateway; апрельские логи: «Call from 7011 to ext 8000 → According to your notes…»). 9090=opus, 9292=codex по конфигу — расхождение с памятью owner о 8000/8010 зафиксировать и НЕ спорить: инженеру выяснить фактическую схему набора owner.
- Открытые вопросы инженеру: (1) куда фактически регистрируется телефон owner и что он набирает при «звонке в тетрадь»; (2) если owner НАБИРАЕТ 7015/7016 как номера — какой PBX отвечает IVR «not valid extension» (у ag-sip таких exten нет; FreeSWITCH тоже кандидат); (3) целевой маршрут: телефон owner (зарегистрированный как 701x/7015/7016?) → ext 8000 (тетрадь).
- Проверка `pjsip show contacts` = пусто остаётся в силе: к ag-sip сейчас не зарегистрирован никто.

[2026-08-27 00:20Z] Диспатчнут web318diag на A1 (sol xhigh): диагноз регистрации owner-клиента + обрывов 8000/8010, фикс-план без прод-мутаций.
[2026-08-27 01:35Z] WEB318DIAG DONE: primary root — sync-dynamic-sip-endpoints.ts:114-153,329-339,388-393 подменяет DB/QR credential owner 7016 статическим proof credential; secondary — TLS предлагается клиенту без TLS transport (pjsip-native.conf:8-18); NAT-риски задокументированы; expiry НЕ корень. Фикс-волна web318fix в очереди A1 (код+конфиг+deploy-план с откатом). -> review (диагноз), фикс отдельно.
[2026-08-27 01:50Z] ДОКУМЕНТЫ (путь эволюции): диагноз A1:/home/ubuntu/waves/WEB318DIAG-REPORT.md (worktree wt-web318); фикс-бриф queue/045-web318fix-brief.md; эволюция: боевые звонки owner 26.08 -> deny 8000 -> диагноз -> web318fix.
[2026-08-27 05:25Z] WEB318FIX DONE: коммит 3284796d (A1 wt-web318) — proof-password override убран, DB digest authoritative, TLS-опция клиенту снята до отдельного TLS-харднинга (cert/PJSIP transport/5061 — будущий тикет), renderer regression + transport policy suites зелёные, секреты в отчёт не утекли, полный откат-план (UFW/DNAT только свои правила). Деплой = с посадкой (renderer в app) либо отдельным целевым патчем после приёмки. Требуется независимая приёмка + после деплоя КОНТРОЛЬ: регистрация owner-клиента живая.
[2026-08-27 06:45Z] acc318 в очереди: независимая приёмка с негативами (proof-контур не регресснул; отсутствующий digest fail-closed; TLS нигде не отдаётся; ротация не залипает). После GO — деплой рендерера + контроль живой регистрацией owner.
[2026-08-27 07:35Z] acc318 NO-GO: buildRecommendedSipLinphoneDescriptor/resolveEffectiveSipLinphoneDescriptor не fail-closed для raw TLS (поле/sips:/URI-параметры) в рантайме. web318fix2 в очереди (все 3 формы TLS + негативы acc318 копиями). Деплой после GO единым rollout runtime-файлов.
[2026-08-27 08:40Z] web318fix2 сдан (3 формы raw TLS + tsconfig-scoped). acc318b в очереди (негативы копиями + свой обходной вектор + deploy-план).
[2026-08-27 09:05Z] acc318b GO (staged): 4/4 негатива копиями + свой вектор (uppercase SIPS: в proxy) + 34/34 renderer/transport + 17/17 UI regression + scoped ts/lint rc=0. Деплой = ЕДИНЫМ application release 18cbe8c5 (вкл. родителя 3284796d) — app-исходники+i18n+Pi-скрипт sync-dynamic-sip-endpoints.ts (drifted, заменить при посадке). РЕШЕНИЕ: ветка web318fix едет в l59-merge (не хот-патч). После посадки: контроль живой регистрацией owner 7016.
[2026-08-27 10:20Z] web318fix ВЛИТ в l59-merge (a8c170aa, чисто). Едет в посадку. После посадки: заменить drifted Pi-скрипт + контроль регистрации 7016.

[28.08 18:35Z M1-ревизор (spark-задача, luna medium)] НЕ ПОЧИНЕНО: 8000 занят uvicorn (не SIP!), 8010 слушает без видимого владельца, регистрация owner-клиента не подтверждена. ВАЖНАЯ находка: `ag-sip-native-opus-experimental.service` в КРАШ-ЛУПЕ (activating auto-restart, status=1/FAILURE) — та самая «холостая» ветка на деле бесконечно падает. По запрету владельца не трогаем, но факт зафиксирован. Отчёт: M1:~/M1-TELREVU-REPORT.md.

---
## 2026-08-29 03:45Z — вымывка: ЗАКРЫТ, работа в проде
Доказано: коммит линии (merge a8c170aa 'web318fix' в l59-merge) — предок текущего прод-релиза l66 (eb577cd1). Значит починка SIP-обрывов 8000/8010 фактически на проде с момента посадки l66 (28.08 21:27Z). Приёмка была пройдена ранее (статус review = принято, ждёт посадки). Перевожу в done.
Если owner при живой проверке звонком увидит обрывы снова — переоткрыть с новыми фактами (это будет уже другой дефект).

26116cff