Produto

Troncos SIP

Tronco SIP é o link de voz com a operadora. Cadastre uma vez, vincule a Site e Nó de telefonia, configure DDRs/CAP pool, e Campanhas Outbound discam por ele.

Atualizado em 03 de maio de 2026

O que é

Tronco SIP é o link de voz entre o Interaflow e a operadora — o “cano” pelo qual chamadas saem (outbound) e entram (inbound). Cada tronco corresponde a uma conexão SIP configurada com a operadora, tipicamente identificada por:

Host e porta do servidor SIP da operadora.
Credenciais quando a operadora exige autenticação.
Codecs suportados.
Limite de canais simultâneos contratado.

A configuração feita aqui é traduzida automaticamente para os arquivos de configuração do Asterisk (pjsip.conf ou sip.conf) sem você precisar editar arquivo nenhum.

Drivers suportados

O Interaflow suporta dois drivers SIP do Asterisk:

Driver	Quando usar
pjsip (padrão)	Stack moderna, recomendada para novos troncos. Suporta TLS, transporte WebSocket, melhor diagnóstico.
chan_sip (legado)	Mantido para compatibilidade com troncos antigos que não migraram. Não use para configuração nova.

A escolha do driver impacta os campos exibidos no formulário — campos como peer_type, insecure, sendrpid, trustrpid, canreinvite aparecem apenas para chan_sip.

Como o tronco se posiciona

Um tronco está sempre associado a:

Tenant — o tronco pertence a uma conta SaaS específica.
Site — qual infraestrutura processa as chamadas dele (Cloud ou On-Prem). O Site decide a “geografia” da chamada.
Telephony Node (opcional) — qual nó concreto recebe as chamadas (classifier, media). Quando vazio, usa o nó Cloud padrão do Site.
CAP Pool (opcional) — pool de capacidade compartilhada entre vários troncos quando a operadora cobra por limite agregado de link, e não por trunk individual.
DDRs — números de identificação (Caller IDs) usados nas chamadas de saída.

Campos principais

Identificação e conexão

Nome — identificador do endpoint/peer (ex.: “sigavox”). Curto, sem espaço, costuma virar a chave usada no pjsip.conf/sip.conf.
Descrição — contexto humano.
Host — IP ou domínio da operadora.
Porta — 5060 por padrão.
Transporte — udp, tcp ou tls.

Autenticação

Username / Password — credenciais SIP. A senha é criptografada com Fernet no banco; nunca aparece em texto puro na UI.
Auth username — quando a operadora exige usuário diferente do username principal.
Registro — se o tronco precisa fazer REGISTER periódico no servidor SIP da operadora. Marque quando aplicável e ajuste o register_expiry (padrão 300 s).

Alguns peers (operadoras com IP autorizado por whitelist) não exigem autenticação — username/password ficam em branco.

Codecs e DTMF

Codecs — lista priorizada (alaw, ulaw,alaw). alaw é o padrão no Brasil; ulaw aparece em troncos internacionais.
DTMF Mode — como tons DTMF são transmitidos: rfc2833 (chan_sip), rfc4733 (pjsip), inband ou info. Padrão depende do driver.

Capacidade e Caller ID

Max channels — limite de canais simultâneos do tronco (padrão 30). Use o que a operadora contratou; canais acima do limite são rejeitados.
CAP Pool — quando a capacidade real é do link (ex.: VPL1 com 100 canais agregando vários troncos), associe ao pool. O controle passa a ser pela soma agregada, não pelo limite individual.
Caller ID Mode:
- standard — Set(CALLERID(num)=DDR) no dialplan. Funciona com operadoras como Claro.
- pai_header — usa cabeçalho P-Asserted-Identity. Necessário para operadoras como TIM que ignoram o CALLERID padrão. Exige preencher pai_header_ip (IP do servidor SIP).

DDRs (Caller IDs)

DDRs são os números que aparecem como bina nas chamadas outbound. Há duas formas de configurar:

DDRs específicos do tronco — cadastrados na aba do tronco, com possível distribuição por DDD destino.
DDR Pool — quando vários troncos compartilham um pool global de DDRs (operação multi-tronco com mesmo CNPJ).

A escolha entre standard e pai_header costuma ser do dia 1 — operadoras diferentes exigem caminhos diferentes; experimente com a documentação técnica da operadora.

Contexto e identidade

Context entrada — contexto Asterisk usado para chamadas recebidas pelo tronco (from-trunk por padrão). Define o ponto de entrada no dialplan.
From user / From domain — sobrescrevem o From: SIP quando necessário.

Campos `chan_sip` específicos

Quando o driver é chan_sip, alguns campos adicionais aparecem para reproduzir comportamentos do driver legado: insecure (invite,port), sendrpid, trustrpid, qualify (monitora peer com OPTIONS), nat (force_rport,comedia), canreinvite, silencesuppression. Essas opções são herança de configuração de sip.conf e não devem ser usadas em troncos novos — prefira pjsip.

Status

Ativo — tronco gera configuração e fica disponível para Campanhas e roteamento. Padrão para troncos em uso.
Inativo — tronco fica desativado sem precisar excluir.

Para acompanhar status em tempo real (registro válido, canais ocupados agora, latência), use o Monitor de Tráfego e a tela de Status de Troncos (sidebar Telefonia).

Como o tronco é usado

Campanhas Outbound referenciam o tronco diretamente (campanha.tronco_sip_id) ou usam uma Rota de Saída que pode aplicar failover entre troncos.
Chamadas inbound entram pelo context_entrada configurado e são roteadas conforme a regra do dialplan (DID → Canal → rota).

Detalhes em Rotas de Saída e Monitor de Tráfego.

Boas práticas

Comece com PJSIP. A não ser que esteja migrando configuração legada existente, todo tronco novo deve ser PJSIP.
Documente a configuração com a operadora. Cabeçalhos exigidos (PAI), codecs aceitos, limite de canais — capture isso em cada tronco.
Use CAP Pool quando o link é compartilhado. Sem isso, vários troncos podem somar canais acima do que o link suporta.
Combine com DDR Pool quando o mesmo CNPJ atende com vários troncos — uniformiza bina sem duplicar cadastro.
Acompanhe o registro. Tronco sem registro válido aparece com problema no Monitor de Tráfego — investigue antes de discar.
Cuidado com callerid_mode errado. TIM ignorando bina porque está em standard é o sintoma típico — mude para pai_header com IP correto.

Limites conhecidos

Sem geração automática de DDRs. DDRs precisam ser cadastrados manualmente (no tronco ou no pool).
chan_sip é legado. Não há roadmap para evoluir o driver legado; foco é PJSIP.
Senha visível para admins do tenant que abrem o tronco para edição (descriptografada em runtime). Não é renderizada em logs.
Sem teste integrado de tronco (“ligar para um número de validação”) — diagnóstico se faz pelo Monitor de Tráfego ou logs do Asterisk.

Erros comuns

Esquecer de marcar register = true quando a operadora exige. Sem registro, o tronco não recebe inbound.
Codec único quando a operadora não suporta. Especifique ulaw,alaw para fallback se a operadora pode entregar em qualquer um.
callerid_mode = standard em operadora que exige PAI. Bina sai como número genérico; receptor não reconhece a chamada.
Estouro de max_channels_trunk. Campanhas grandes saturam tronco pequeno; cheque no Monitor de Tráfego e suba o limite (com a operadora) ou use CAP Pool agregado.
Excluir tronco com Campanhas apontando. A relação fica órfã; desative em vez de excluir.