ksir + voicemw

Três camadas independentes, cada uma com uma responsabilidade clara. A chamada flui de baixo (rede SIP) para cima (lógica de negócio) e volta como áudio.

O caminho completo de uma chamada outbound, do disparo via API até a voz do agente, e a volta do áudio do interlocutor.

1. DisparoO dialer chama POST /api/v1/calls no voicemw com destino, external_id, outbound_trunk (opcional) e initial_text.
2. Originate via ARIvoicemw manda o ksir originar a chamada: PJSIP/<destino>@<trunk>, no app voicemw-vmtech.
3. INVITE ao provedorksir envia o INVITE pela Vono (com auth digest 407→retry) e estabelece o RTP em slin16 16 kHz.
4. Evento started → orquestradorAo entrar em Stasis, voicemw chama o webhook principal do tenant (o orquestrador), que lê os parâmetros e decide o agente.
5. Áudio + STTksir devolve o áudio do interlocutor; voicemw transcreve (STT) e detecta fala/silêncio (VAD).
6. Turnos → agenteA cada fala do interlocutor (user_speech), voicemw chama o webhook do agente escolhido. O agente responde com comandos (play_audio, hangup, transfer).

O ksir tem uma config global e um arquivo JSON por cliente (tenant) dentro de clients_dir. Cada cliente lista seus troncos SIP. Não há SIGHUP — para adicionar/editar clientes, reinicie o serviço.

config-ksir.json (global)

{
  "ari_listen": "127.0.0.1:7077",     // API estilo ARI (REST + WebSocket)
  "sip_host":   "31.220.97.96",       // IP público que fala com a Vono
  "sip_port":   5060,
  "rtp_port_start": 30000,
  "rtp_port_end":   30999,
  "clients_dir": "./clients"          // 1 arquivo .json por tenant
}

clients/vmtech.json (o tenant e seus troncos)

Um tenant agrupa todos os troncos SIP de um mesmo cliente. Aqui o vmtech tem dois troncos da Vono — um por atividade. Cada tronco tem auth_user, dids e name únicos globalmente (o ksir valida no boot).

{
  "tenant": "vmtech",
  "stasis_app": "voicemw-vmtech",   // app que recebe as chamadas no voicemw
  "trunks": [
    {
      "name":      "vmtech_vono",     // COBRANÇA
      "auth_user": "ajvy90872",
      "server":    "sip.vono2.me",
      "dids":      ["554428880123"]
    },
    {
      "name":      "ksir_vono",       // APRESENTAÇÃO
      "auth_user": "rgjb82929",
      "server":    "sip.vono2.me",
      "dids":      ["554420181470"]
    }
  ]
}

O voicemw é multi-tenant num único processo. Cada tenant tem seu stasis_app, trunk de saída, token de autenticação, webhook (o orquestrador) e a lista de agentes.

"tenants": [{
  "id": "vmtech",
  "stasis_app": "voicemw-vmtech",

  // tronco default + secundários (allowlist p/ outbound_trunk no POST)
  "outbound_trunk":  "vmtech_vono",      // usado quando o POST não pede trunk
  "outbound_trunks": ["ksir_vono"],      // SIPs secundários escolhíveis por chamada

  "auth_token": "<openssl rand -hex 32>",  // Bearer da API de disparo
  "caller_id":  "Empresa <554428880123>",

  // webhook principal = ORQUESTRADOR (recebe o 'started')
  "webhook": { "url": "https://teste.flexpage.io/orquestrador" },

  // cada agente = um webhook próprio; id casa com o retorno do orquestrador
  "agents": [
    { "id": "cobranca",     "url": "https://teste.flexpage.io/cobrar" },
    { "id": "apresentacao", "url": "https://teste.flexpage.io/apresentar" }
  ]
}]

O webhook principal do tenant é o orquestrador. Ele só atua no started: lê os parâmetros de entrada e responde com o agent_id que deve conduzir a chamada. A partir daí, o voicemw roteia tudo direto para o webhook do agente.

Como o orquestrador decide

Três camadas de prioridade. A primeira que casar vence:

{
  "call_id":  "a96c9de3-…",
  "agent_id": "apresentacao",   // ← voicemw passa a rotear p/ este agente
  "commands": []                // vazio → voicemw toca o initial_text do POST
}

Sequência real de uma chamada de apresentação, validada em log (call a96c9de3).

1. POST de disparoexternal_id: LEAD-…, outbound_trunk: ksir_vono, initial_text com a saudação.
2. Originatevoicemw → ksir: PJSIP/5544991474799@ksir_vono, trunk_override aplicado, caller 554428880123.
3. INVITE + RTPksir → Vono: digest auth (407→retry), mídia slin16 estabelecida.
4. started → orquestradorDECISÃO: agente="apresentacao" (external_id_prefix, LEAD-) → responde agent_id.
5. Delegaçãovoicemw: agente: delegado pelo orquestrador → apresentacao. Toca o initial_text.
6. user_speech → agenteApresentadorbot recebe o turno, faz lazy-reload do contexto do lead, conduz a conversa.
7. Comandos de voltaAgente responde play_audio (vira TTS), e ao fim hangup ou transfer.

Os dois fluxos usam o mesmo endpoint e o mesmo Bearer. Muda o outbound_trunk, o prefixo do external_id e o initial_text.

Cobrança

curl -sk -X POST https://pbx-01.flexpage.io:7090/api/v1/calls \
  -H "Authorization: Bearer $TOKEN_VMTECH" \
  -H "Content-Type: application/json" \
  -d '{
    "destination": "5544991474799",
    "external_id": "FAT-2025-0042",
    "initial_text": "Olá, aqui é uma ligação para Fulano. É com você que estou falando?"
  }'   # sem outbound_trunk → usa o default vmtech_vono

Apresentação

curl -sk -X POST https://pbx-01.flexpage.io:7090/api/v1/calls \
  -H "Authorization: Bearer $TOKEN_VMTECH" \
  -H "Content-Type: application/json" \
  -d '{
    "destination": "5544991474799",
    "external_id": "LEAD-2026-ALERTME-00001",
    "outbound_trunk": "ksir_vono",
    "initial_text": "Oi, tudo bem? Aqui é sobre o Alertme. Posso te falar rapidinho?"
  }'