Ir para o conteúdo

Plano Executivo — URA com Asterisk dedicado (manter Panasonic TDE)

Campo Valor
Documento Plano executivo para diretoria
Site / contexto CMRIM — Lorentz URA + Panasonic TDE
Data 2026-08-11 (atualizado 2026-09-17)
Classificação Uso interno — decisão de investimento / implantação
Status Aprovado — nova configuração: Panasonic NS500 (Onda 1) → Issabel/Asterisk VPS (Onda 2); ver 42-planta-tde-asterisk-ura.md
Base técnica Diagnóstico de campo _lab / ura-dtmf-lab — 2026-08-11

1. Resumo executivo

A URA Lorentz funciona quando a chamada vem de ramal SIP interno (teclas reconhecidas). Em chamadas de celular, o áudio do menu toca, mas as teclas não avançam o menu — impacto direto no atendimento automático.

A causa foi isolada por captura de rede e log: no caminho tronco/gateway da central → ramal da URA, o sinal de tecla no padrão esperado (RFC2833 / telephone-event) não chega. O aplicativo URA e a licença não são o problema (prova: MicroSIP → URA OK).

Proposta original (ago/2026): Asterisk on-prem só-URA na frente da TDE (contorno B).

Configuração aprovada (set/2026):

  1. Onda 1: central Panasonic NS500 (DTMF suportado) + código URA atual ativo no Windows — estabilizar menu celular sem rebuild.
  2. Onda 2: subir Issabel + Asterisk em VPS / Docker (lorentz-vps-stack) como plataforma padrão, em cenário híbrido (site ↔ nuvem).

Detalhe técnico e cronograma H1–H5: 42-planta-tde-asterisk-ura.md.

  • NS500 desbloqueia o campo agora; Issabel/Asterisk é o padrão de longo prazo.
  • Asterisk “só URA” on-prem permanece plano B se algum tronco NS500 falhar DTMF.
  • Rollback Onda 1 ↔ Onda 2 documentado na planta 42.

2. Problema e evidências

Origem da chamada Áudio do menu Teclas DTMF Resultado
Softphone interno (MicroSIP) → URA OK Reconhecidas Menu avança
Celular → TDE → URA OK Não reconhecidas Timeout; fluxo não executa

Evidências (2026-08-11):

  • Softphone: negociação SIP inclui telephone-event; log URA com dígito (Event_dtmf).
  • Celular: oferta SIP sem telephone-event; mídia via gateway 192.168.2.196; zero pacotes de evento de tecla no trecho até a URA; log com dígito vazio e timeout.

Conclusão: falha no caminho tronco/gateway PSTN → SIP da URA, não no software LorentzURA.

3. Alternativas avaliadas

Opção Descrição Prós Contras Decisão
A Ajustar DTMF só no tronco/gateway TDE Sem equipamento novo Depende de suporte Panasonic; prazo incerto Preferencial se viável antes; não bloqueia o plano B
B Asterisk intermediário só para URA (este plano) Controle fino de DTMF; TDE intacta para o restante VM + esforço de implantação Recomendada agora
C Alterar URA para tecla “in-band” Independente da TDE Mudança de produto; menos confiável; não é 1º passo Descartada neste ciclo

4. Solução recomendada

Papéis

Componente Papel
Panasonic TDE Continua como central: troncos CO, ramais, destino após o menu
Asterisk (novo, LAN) Somente URA: recebe piloto da TDE, força G.711 + RFC2833 para o LorentzURA
LorentzURA (Windows) Continua em C:\URA; passa a registrar no Asterisk (não mais direto na TDE para os ramais URA)

Fluxo

  1. Celular chega na TDE (como hoje).
  2. TDE envia o piloto/DID da URA por tronco SIP ao Asterisk.
  3. Asterisk toca o LorentzURA com DTMF RFC2833.
  4. Após a escolha no menu, transferência volta à TDE para o ramal do operador.

O que não muda

  • Ramais internos e operação não-URA na TDE.
  • Árvore de voz / conteúdo do menu (salvo apontamento SIP).
  • Issabel/stack cloud: permanece referência de laboratório/documentação; o Asterisk de campo é on-prem na LAN.

5. Escopo e fora de escopo

No escopo

  • VM Linux na LAN (IP fixo), Asterisk mínimo, tronco TDE↔Asterisk.
  • Reapontar contas SIP da URA para o Asterisk.
  • Testes de aceite (celular + log + menu).
  • Documentação e templates no lorentz-vps-stack para suporte/replicação.

Fora de escopo

  • Troca da Panasonic TDE por Issabel/VPS.
  • Rebuild do motor de áudio da URA como solução principal.
  • Hospedar este Asterisk-URA na nuvem sem VPN (descartado por qualidade de áudio/DTMF).

6. Investimento e recursos (ordem de grandeza)

Item Estimativa
Hardware / VM 1 VM ou mini-PC: sugerido 2 vCPU, 4 GB RAM, disco 40 GB, IP fixo na LAN 192.168.2.x
Software Asterisk Livre (Asterisk / Issabel enxuto) — sem licença adicional típica
Esforço equipe Infra + Telecom + URA: ver cronograma (~8–12 dias úteis)
Janela de cutover Preferencialmente fora do pico; rollback < 30 min
Licença LorentzURA Mantém-se a atual (sem novo produto)

Valores monetários de hardware/hora-homem ficam a cargo do orçamento interno da operação.

7. Cronograma (Dia 0 = aprovação da diretoria)

Fase Duração Atividades Resultado esperado
D0 — Aprovação + liberação de IP/VM Autorização formal
F0 — Preparação 1–2 dias úteis VM, NTP, backup TDE e pasta C:\URA, firewall SIP/RTP Ambiente pronto e backup
F1 — Asterisk + URA 2–3 dias Asterisk, peers URA, registro LorentzURA/MicroSIP DTMF OK em teste interno
F2 — Tronco TDE 1–2 dias + janela Tronco SIP, piloto URA, teste celular Menu avança com tecla do celular
F3 — Transferência 1 dia Pós-menu → ramal operador (compatível Panasonic) Atendimento humano após menu
F4 — Cutover 0,5 dia + 2 dias monitor Hunt URA só via tronco; observação Operação estável
Total ~8–12 dias úteis Inclui folga de 1–2 dias Go-live com aceite

Marcos

  • M1: Fim F1 — URA estável no Asterisk (sem celular ainda).
  • M2: Fim F2 — celular com teclas OK (critério crítico de negócio).
  • M3: Fim F4 — go-live e monitoramento encerrado sem rollback.

8. Riscos e mitigação

Risco Impacto Mitigação
Asterisk não regenerar DTMF do tronco Menu celular continua falhando Validar obrigatoriamente na F2 antes do cutover; ajuste de modo DTMF no Asterisk
Falha de transferência (TDE não aceita REFER SIP) Chamada não chega ao operador Usar método já previsto para Panasonic/TDE nos parâmetros da URA
Indisponibilidade na janela URA fora do ar Cutover fora de pico; rollback < 30 min
Capacidade da VM Corte de áudio Dimensionamento mínimo 2 vCPU / 4 GB; monitorar

Rollback

  1. Restaurar Accounts.txt apontando ramais URA de volta à TDE.
  2. Restaurar rota do piloto URA na TDE (hunt anterior).
  3. Validar uma chamada celular de sanidade.

Tempo estimado de rollback: menos de 30 minutos, com backups da F0.

9. Critérios de aceite (obrigatórios)

  1. Chamada de celular chega ao menu da URA.
  2. Tecla do celular é reconhecida (evidência em log da URA e/ou captura de rede).
  3. Menu da árvore avança conforme a tecla.
  4. Transferência para ramal operador na TDE funciona.
  5. Demais ramais e usos da TDE permanecem inalterados.

10. Pedido de decisão — resultado

Código Decisão registrada
APROVAR-NS500-HIBRIDO Aprovado — Onda 1 NS500 + URA atual; Onda 2 Issabel/Asterisk VPS como padrão (Planta H → A)

Registro: ver planta técnica 42-planta-tde-asterisk-ura.md (2026-09).

Opções históricas do PDF original (APROVAR-B / TENTAR-A-PRIMEIRO / ADIAR) ficam superadas por esta decisão.

11. Referências internas

  • Diagnóstico suporte: _lab/lorentz-lab/DIAGNOSTICO-SUPORTE-DTMF-CELULAR-CMRIM-20260811.md (+ PDF)
  • Diagnóstico lab TDE: _lab/lorentz-lab/DIAGNOSTICO-DTMF-TDE.md
  • Playbook campo: _lab/PLAYBOOK-CAMPO-URA.md
  • Stack / URA Windows: lorentz-vps-stack/config/windows-ura/
  • Repositório lab: https://github.com/araguaci/ura-dtmf-lab

Documento gerado para decisão de diretoria. Sem senhas ou dados pessoais de clientes. Detalhe técnico de implantação segue após aprovação.