# Arquitetura de Rede

## Estado atual (fase FreeSWITCH inicial)

`freeswitch` roda na rede padrão do Docker Compose (bridge, `b2bcall_default`),
igual a `postgres` e `redis`. Nenhuma porta é publicada no host — nem 8021
(ESL), nem SIP (5060/5080), nem RTP. Isso é intencional: ainda não existe
nenhum tronco SIP real nem ramal externo, então não há motivo pra expor nada.

`apps/api` roda hoje **direto no host** (fora do Docker), então usa
`APP_DATABASE_URL`/`REDIS_URL` apontando pra `localhost` nas portas publicadas
pelo Postgres/Redis. Ela não consegue (nem precisa, ainda) alcançar o
FreeSWITCH.

## Decisão pendente: `network_mode` do FreeSWITCH (agente.md secao 19)

Quando existir um tronco SIP real (fase Trunks), será preciso decidir entre:

- **`network_mode: host`**: mais simples pra SIP/RTP (sem NAT entre o
  container e a rede), mas perde isolamento de rede do Docker.
- **macvlan/ipvlan**: dá ao FreeSWITCH um IP próprio na rede física, sem expor
  outros serviços do host: mais trabalho de configurar, melhor isolamento.

Não decidido ainda — só vira relevante quando houver um carrier/SBC real pra
conectar (secao 17: "FreeSWITCH não deverá depender de IP SIP público" — a
topologia esperada é `Internet → OpenSIPS → rede SIP privada → FreeSWITCH`,
então o FreeSWITCH em si tende a ficar em rede privada mesmo, o que favorece
manter bridge/macvlan em vez de host).

## Quando `apps/api` virar container

Hoje ela roda no host por conveniência de desenvolvimento. Quando virar o
serviço Docker `b2bcall-api` (agente.md secao 14), as connection strings
precisam trocar de `localhost` pros hostnames internos do compose
(`postgres`, `redis`, `freeswitch`) — ver nota em docs/AUTHENTICATION.md sobre
essa pegadinha.