42 — Planta híbrida: Panasonic NS500 + URA → Issabel/Asterisk (padrão)¶

Campo	Valor
Status	Aprovado (nova configuração cliente — 2026-09)
Site / contexto	CMRIM (evolução do diagnóstico TDE 2026-08)
Planta	H (híbrida) → convergência para Planta A (Issabel/Asterisk)
Relacionados	PLANO-EXECUTIVO-TDE-ASTERISK-URA.md · 01-visao-geral-arquitetura.md · 06-issabel-pbx.md · `_lab/lorentz-lab/DIAGNOSTICO-SUPORTE-DTMF-CELULAR-CMRIM-20260811.md`

1. Decisão aprovada (resumo)¶

A diretoria / operação aprovou um caminho em duas ondas, mantendo o código LorentzURA atual:

Onda	Plataforma telefonia	URA	Objetivo
1 — Agora (campo)	Panasonic NS500 (DTMF RFC2833 suportado)	LorentzURA atual em Windows (`C:\URA`), ativa	Estabilizar menu celular sem alterar produto URA
2 — Em seguida	Issabel + Asterisk em VPS / Docker (`lorentz-vps-stack`)	URA registra no Asterisk da nuvem (ou híbrido LAN↔VPS)	Padronizar plataforma Lorentz (Planta A)

Padrão de longo prazo: Issabel + Asterisk como plataforma Lorentz (Planta A). A NS500 é a ponte operacional no site.

Paralelo (NS500 em montagem): adiantar Onda 2 na VPS 2.25.92.168 (srv1869007) — ver 43-preparar-issabel-ura-vps-hostinger.md.

O plano original (Asterisk on-prem só-URA na frente da TDE) permanece como contorno B se algum tronco falhar DTMF.

2. Por que mudou (ligação ao diagnóstico)¶

No diagnóstico TDE (2026-08-11), celular → URA falhava porque o tronco/gateway não entregava telephone-event (RFC2833). MicroSIP interno OK.

Com a NS500 (DTMF suportado de ponta a ponta no caminho SIP da URA):

O código LorentzURA atual (evento bit 32 / Event_dtmf) opera sem rebuild nem suporte in-band 1024.
Prioridade imediata: homologar celular → menu → transferência na NS500.
Depois: migrar sinalização/URA para o Issabel da VPS (padrão stack).

3. Arquitetura por onda¶

Onda 1 — NS500 + URA local (híbrido operacional)¶

flowchart LR
  Cel[Celular_PSTN] --> NS500[Panasonic_NS500]
  Soft[Ramais_SIP] --> NS500
  NS500 -->|"SIP RFC2833 G711"| URA[LorentzURA_Windows]
  URA -->|"modelo panasonic/tde"| NS500
  NS500 --> Op[Ramal_operador]

Componente	Papel
Panasonic NS500	PABX site: CO, ramais, piloto URA, DTMF RFC2833
LorentzURA	EXE/DLL atuais; `Accounts.txt` → IP/porta da NS500; modelo `Panasonic` ou `TDE` conforme transferência
Supervisor / CTI	Podem permanecer on-prem ou já na VPS — independente do DTMF da URA nesta onda

Aceite Onda 1 (obrigatório):

SDP celular→URA com telephone-event
Log Event_dtmf;dtmf=<tecla>
Menu avança; transferência para operador OK
Ramais não-URA estáveis

Onda 2 — VPS Issabel/Asterisk (padrão plataforma)¶

flowchart TB
  subgraph site [Site_cliente]
    NS500b[NS500_opcional_tronco]
    URAw[LorentzURA_Windows_ou_lab]
  end
  subgraph vps [VPS_lorentz-vps-stack]
    Issabel[Issabel_Asterisk_hostnet]
    CTI[LorentzCTI]
    SUP[Supervisor]
    SQL[SQL_Server]
  end
  Cel2[Celular] --> NS500b
  NS500b -->|"tronco SIP"| Issabel
  Cel2 -.->|"DID direto SIP"| Issabel
  URAw -->|"REGISTER SIP"| Issabel
  Issabel --> CTI
  CTI --> SQL
  SUP --> SQL
  SUP --> CTI

Componente	Papel
Issabel + Asterisk	PBX padrão stack (`issabel4-docker`, hostnet) — filas, AMI, WSS, gravações
LorentzCTI + Supervisor + SQL	Compose bridge — Planta A
NS500	Pode permanecer como PABX de ramais locais / tronco SIP para o Issabel, ou ser reduzida conforme cutover
URA	Peers no Asterisk da VPS (ou Asterisk dockerizado dedicado URA dentro da mesma estratégia Issabel)

Aceite Onda 2: URA registra no Issabel; DTMF celular OK via caminho Issabel; AMI/CTI verdes; rollback documentado para Onda 1.

4. Relação com plantas da stack¶

Planta	PBX	Uso
A	Issabel / Asterisk AMI	Padrão — VPS / Docker (`lorentz-vps-stack`)
B	Intelbras Impacta CSTA	Isolado — 21-plano-deploy-impacta-csta.md
H	NS500 (agora) → Issabel (alvo)	Este documento — transição CMRIM / sites Panasonic

A Planta H não cria um terceiro produto: é o roteiro de migração até a Planta A.

5. Cronograma sugerido (pós-aprovação)¶

Fase	Duração	Atividade
H1	3–5 d.u.	Cutover URA → NS500; validar aceite Onda 1 (Wireshark + log)
H2	1–2 sem.	Operação estável NS500; monitorar transferência / REFER
H3	5–10 d.u.	Preparar VPS: Issabel + CTI + Supervisor (lab → produção)
H4	3–5 d.u.	Tronco NS500↔Issabel ou DID no Issabel; URA REGISTER no Asterisk cloud
H5	2 d.u. + monitor	Cutover híbrido/cloud; rollback = Accounts + piloto na NS500

Totais orientativos: Onda 1 em cerca de 1 semana; Onda 2 em 2–4 semanas após H1 estável (depende de VPS/DNS/firewall).

6. Configuração URA (Onda 1)¶

Exemplo Accounts.txt (MonitorOPS / config/windows-ura/):

# id;ramal;servidor;usuario;senha;modelo;pasta_wav;arquivo_arv;
0;401;<IP_NS500>;401;<SENHA>;Panasonic;C:\URA\Audio;C:\URA\Fluxo\CMRIM.arv;

Servidor SIP = IP da NS500 (não mais TDE 192.168.2.199 se o PABX mudou).
Modelo: Panasonic / TDE conforme comportamento de transferência na NS500 (validar em H1).
Manter GravarLog=True até aceite celular fechado.

Checklist: _lab/PLAYBOOK-CAMPO-URA.md · lorentz-lab/WIRESHARK-URA-DTMF.md · tools/sip-ramal-test.

7. Onda 2 — o que usar da stack¶

Artefato	Uso
06-issabel-pbx.md	Deploy Issabel hostnet
09-integracao-e-redes.md	Portas SIP/RTP/AMI
38-vps-hostinger-passo-a-passo.md	VPS produção
`config/windows-ura/`	Accounts apontando IP Issabel / Asterisk
Templates futuros `config/asterisk-ura/`	Opcional se URA exigir dialplan mínimo dedicado no mesmo Asterisk

Princípio: um Asterisk Issabel como plataforma; evitar segundo PBX “só URA” na nuvem, salvo necessidade comprovada de isolamento.

8. Riscos e rollback¶

Risco	Mitigação
NS500 ainda falha DTMF em algum tronco	Captura SDP; abrir com suporte Panasonic; Asterisk intermediário volta a ser plano B
Transferência SIP (REFER)	Validar modelo Accounts; método cego Panasonic
Cutover Onda 2 com URA na VPS e NAT	Preferir VPN site-to-site ou URA Windows no site registrando no Issabel com RTP ok
Regressão após H4	Rollback: `Accounts.txt` + piloto → NS500 (Onda 1)

9. Fora de escopo (neste ciclo)¶

Rebuild orbitallura / árvore in-band 1024 como solução principal
Substituir NS500 antes do aceite Onda 1
Planta Impacta (B) misturada neste roteiro

10. Próximos passos imediatos¶

VPS (agora): preparar Issabel URA 401–405 — 43-preparar-issabel-ura-vps-hostinger.md (srv1869007 / 2.25.92.168).
Campo: quando NS500 montar — apontar URA ou tronco; aceite DTMF celular.
Híbrido: tronco NS500↔Issabel ou cutover piloto para VPS.
Manter MonitorOPS / windows-ura alinhados.

Documento vivo da planta híbrida. Issabel + Asterisk permanece o padrão de plataforma Lorentz; NS500 é a ponte operacional aprovada no cliente.