B2BCall Bootstrap
80e72881b2
Fase 9 (segurança e produção): - GET /api/metrics: endpoint Prometheus com métricas reais (chamadas, agentes, filas, CPS por campanha), protegido por permissão - scripts/backup.sh, restore.sh, healthcheck.sh, install.sh, update.sh — testados contra o ambiente real (backup.sh e healthcheck.sh rodados de verdade; install.sh/update.sh validados por inspeção, ambiente atual já provisionado) - POST /api/agent-console/dispose: aplica disposição de chamada de verdade (lacuna deixada aberta desde a Fase 6), com ações CALLBACK (agenda retorno) e DO_NOT_CALL (suprime automaticamente) - apps/dialer-worker/src/callback-sweep.ts: reativa leads com callback vencido; GET /api/callbacks para consulta - apps/dialer-worker/src/wrap-up-sweep.ts: transição automática WRAP_UP -> AVAILABLE + despausa real na fila do Asterisk. Exigiu corrigir main.ts para conectar ao AMI mesmo em DIALER_SIMULATION=true (DIALER_SIMULATION deve impedir só originação de chamada, não ações administrativas de fila) - nftables revisado (sem alterações necessárias) - Documentação completa: INSTALL, OPERATIONS, BACKUP_RESTORE, SECURITY, DATABASE, API, ASTERISK, OPENSIPS (não implementado, motivo documentado), TROUBLESHOOTING - README.md e CHANGELOG.md reescritos Fase 10 (testes e aceite): - Quality gate completo executado: build/typecheck (7 workspaces), lint, 46 testes unitários, docker compose config/ps, healthcheck — tudo verde - Aceite de segurança (seção 92): 13 itens verificados ao vivo contra o sistema real, não só por inspeção de código - Aceite Asterisk (seção 93): os 5 comandos executados e documentados, comunicação API->AMI->Asterisk validada - docs/RELATORIO_FINAL.md: relatório final no formato da seção 96 Todos os fixtures de teste desta fase foram removidos/desativados ao final. Credenciais de acesso entregues separadamente em CREDENCIAIS.txt (fora do git, nunca versionado).
52 lines
2.2 KiB
Markdown
52 lines
2.2 KiB
Markdown
# B2BCall — OpenSIPS (não implementado nesta fase)
|
|
|
|
A arquitetura alvo do projeto (agente.md seção 5) prevê OpenSIPS na frente
|
|
do Asterisk:
|
|
|
|
```text
|
|
INTERNET → [OpenSIPS] → rede SIP privada → [Asterisk] → [B2BCall]
|
|
```
|
|
|
|
**Este componente não foi implantado neste ciclo.** O Asterisk hoje recebe
|
|
tráfego SIP diretamente (protegido por nftables, sem IP público — ver
|
|
`docs/ARCHITECTURE.md` §3.2). Isso é suficiente para o ambiente de
|
|
laboratório atual (um servidor, troncos configurados diretamente no
|
|
Asterisk), mas não entrega os benefícios que OpenSIPS traria:
|
|
|
|
- Balanceamento entre múltiplas instâncias de Asterisk.
|
|
- Roteamento/normalização de múltiplos troncos antes de chegar ao core de
|
|
telefonia.
|
|
- Uma camada adicional de proteção SIP (rate limiting, topology hiding)
|
|
antes do Asterisk.
|
|
|
|
## Por que não foi feito agora
|
|
|
|
Motivo honesto: com um único servidor e um único Asterisk, OpenSIPS não
|
|
resolve nenhum problema real deste ambiente — adicionaria complexidade
|
|
operacional (mais um serviço com seu próprio config/estado/observabilidade)
|
|
sem benefício imediato. A decisão de projeto (agente.md seções 71/72) é não
|
|
construir infraestrutura para um cenário hipotético que ainda não existe.
|
|
|
|
## Quando reconsiderar
|
|
|
|
Implantar OpenSIPS quando pelo menos uma destas condições existir:
|
|
|
|
1. Mais de uma instância de Asterisk precisar compartilhar o mesmo conjunto
|
|
de troncos/roteamento.
|
|
2. Necessidade de expor SIP a múltiplas operadoras com normalização de
|
|
roteamento antes do Asterisk.
|
|
3. Volume que justifique uma camada de proteção SIP dedicada, separada do
|
|
Asterisk.
|
|
|
|
## Esboço de integração futura
|
|
|
|
- OpenSIPS ficaria na mesma rede privada do Asterisk (nunca IP público
|
|
direto no Asterisk — isso não muda).
|
|
- Trunks/roteamento no domínio da aplicação (`Trunk` no Postgres) já
|
|
modelam host/porta/credenciais de forma genérica — o registro de
|
|
domínios `Trunk.host` como sendo o OpenSIPS em vez do Asterisk-tronco
|
|
direto é, na prática, uma mudança de configuração, não de schema.
|
|
- Regras de firewall (`infrastructure/nftables/`) precisariam abrir a porta
|
|
SIP do OpenSIPS para a origem confiável (operadora/OpenSIPS peer),
|
|
mantendo o Asterisk inacessível de fora da rede interna.
|