Um trunk é o limite onde a operadora decide quais chamadas o seu equipamento pode enviar e receber. Se você tem um PBX, o sistema telefônico corporativo que roteia suas chamadas, um session border controller, uma plataforma de contact center ou qualquer outro cliente SIP, o trunk é como as chamadas dele chegam ao mundo exterior e como as chamadas externas chegam até ele. Um session border controller é o dispositivo que protege a borda de uma rede de voz.
A primeira pergunta geralmente é se você precisa de um, e a resposta é sim. O que varia é o que você coloca atrás dele.
Eu realmente preciso de um trunk?
Sim. O que muda entre as configurações é o cliente do seu lado, não se existe um trunk.
Toda chamada de ou para a rede telefônica passa por um, porque o trunk é onde a plataforma decide se aceita a chamada. Dois formatos são comuns:
- Você tem um sistema telefônico. Um PBX, softswitch ou plataforma de contact center que já gerencia chamadas e precisa de uma rota para a rede pública. Ele se conecta como par, geralmente a partir de um endereço fixo, e seu próprio plano de discagem, as regras que roteiam suas chamadas, faz o controle da chamada.
- Você tem código de aplicação. Você quer que seu software faça ou receba chamadas sem operar infraestrutura de telefonia. Você ainda precisa de um trunk, e o que se comunica com ele pode ser pequeno: um softphone, um navegador, o CLI ou um runtime de agente de voz. Ele se autentica com uma credencial de sessão de curta duração, um nome de usuário e senha temporários para um cliente SIP, em vez de equipamento em um endereço conhecido.
A distinção é sobre onde o controle de chamada reside, não sobre escala, e nenhum dos dois formatos pula o trunk. O que um cliente leve economiza é a operação de um sistema telefônico, não a conexão em si. As próprias ferramentas Bird reforçam o ponto duas vezes: o telefone do dashboard e a chamada de teste do CLI são ambos clientes SIP fazendo chamadas reais através de um dos seus trunks.
O trunk também não é uma alternativa ao API, porque nenhum endpoint faz uma chamada para um destino que você escolhe. O que é uma API de voz explica como a parte de configuração e a parte de sinalização dividem o trabalho.
O que um trunk realmente faz?
Ele dá ao seu equipamento um endereço para enviar chamadas e decide quais chamadas aceitar.
Bird atribui a cada trunk um domínio SIP fixo, que é o que você insere no seu sistema telefônico para que as chamadas sejam associadas ao trunk. Seu equipamento envia para esse domínio em um de três transportes: UDP ou TCP na porta 5060, ou TLS na porta 5061 quando você quer a sinalização criptografada em trânsito.
Um trunk novo rejeita toda chamada. As duas direções estão desativadas, e nenhum remetente está autorizado. Esse é um padrão deliberado, não uma configuração incompleta. Um trunk que aceitasse chamadas no instante em que fosse criado seria um convite permanente, e fraude de tarifação torna isso caro rapidamente.
Por que saída e entrada são configuradas separadamente?
Porque são problemas diferentes com modos de falha diferentes, e um trunk carrega cada direção de forma independente.
Saída é o seu sistema telefônico fazendo chamadas através de Bird. Até você habilitá-la, o trunk recusa toda tentativa de saída independentemente das credenciais, então uma chamada corretamente autenticada ainda falha se a direção estiver desativada.
Entrada é Bird entregando chamadas ao seu sistema telefônico para os números que apontam para o trunk. Habilitá-la não é suficiente por si só: um trunk com entrada habilitada e sem gateway de entrega recusa toda chamada recebida nos seus números. Apontar um número para o trunk é feito no número, não no trunk, e essa é a outra metade que as pessoas esquecem.
Desativar a entrada faz todos os números apontando para este trunk voltarem a rejeitar, e reativá-la não os restaura. Excluir o trunk faz o mesmo. Então o desfazer não é simétrico: se você desativar a entrada para testar algo, planeje reapontar cada número depois, e verifique os números em vez de presumir que o toggle os restaurou.
Como um trunk decide quem pode enviar chamadas para ele?
Uma lista de IPs permitidos, autenticação por chave API e credenciais de sessão decidem isso. Elas podem ser combinadas, e cada uma se torna ativa assim que tem uma entrada.
Uma lista de IPs permitidos. Adicione os endereços públicos de onde seu equipamento envia para SIP. A filtragem começa no momento em que a lista tem uma entrada, e a partir daí apenas os intervalos listados podem enviar chamadas. Para equipamentos atrás de NAT, esse é o endereço público do roteador, não o endereço privado do sistema telefônico. Chamadas de endereços não listados são recusadas na camada SIP e geralmente nunca aparecem no log de chamadas. Um log vazio é, portanto, um sintoma disso, e não evidência de que nada foi tentado.
Autenticação por chave API. Bird desafia a chamada, e seu sistema responde com um hash da senha em vez da senha em si. O hash é verificado contra uma chave Bird API com acesso de voz em nível de escrita. No seu PBX o nome de usuário é sempre bird e a senha é o segredo da chave. Assim como a lista de IPs, ela se torna exclusiva assim que uma chave é permitida.
Dois detalhes operacionais decorrem disso. Remover a permissão de voz de uma chave interrompe a autenticação imediatamente. A chave permanece na lista de permitidos do trunk, marcada, para que a lista nunca pareça funcional quando não está. Restaurar a permissão a reativa sem nada a alterar. Revogar ou excluir a chave é imediato em todo trunk que a permitia, e é permanente. Faça a rotação adicionando a nova chave ao trunk primeiro, migrando seu equipamento, e revogando a antiga por último.
Credenciais de sessão. Um nome de usuário e senha SIP de curta duração que respondem ao mesmo desafio sem expor um segredo de longa duração. Elas estão desativadas em um trunk novo e pertencem ao espaço de trabalho, não a um trunk específico. A senha é retornada apenas quando é gerada.
Ativar credenciais de sessão não muda como equipamentos na lista de permitidos se conectam. Uma chamada de um endereço listado em um trunk sem chaves API permitidas ainda é admitida sem nenhum desafio de senha. Se você pretendia que a credencial fosse o portão, a lista de IPs silenciosamente ainda é o portão.
Por que meu navegador ou softphone falha ao autenticar?
Quase sempre é o algoritmo de digest. É a única configuração que falha de um jeito que parece um problema de credencial.
Por padrão, Bird oferece SHA-256 primeiro e MD5 segundo, e seu equipamento responde com o primeiro que suporta. Um trunk aceita apenas os algoritmos que oferece, então restringir a oferta restringe o que pode se conectar.
A armadilha são os navegadores: um navegador responde com MD5 e nada mais. Um trunk que oferece apenas SHA-256 rejeita toda chamada de navegador, incluindo o próprio telefone do dashboard. Então mantenha MD5 na oferta em qualquer trunk de onde você pretende ligar por um navegador, e opte por MD5 apenas quando um PBX não lidar bem com um desafio que começa com SHA-256. Chaves API funcionam com qualquer algoritmo e nunca precisam ser reemitidas quando você altera a oferta.
Então, o que eu configuro?
- Um trunk, qualquer que seja seu formato. Toda chamada passa por um, então esta etapa não é opcional.
- Um par, se você opera um sistema telefônico. Conecte o PBX ou a plataforma de contact center a partir de um endereço fixo, e deixe o plano de discagem dele controlar as chamadas.
- Um cliente leve, se você tem código de aplicação. Um softphone, um navegador, o CLI ou um runtime de agente, autenticando com uma credencial de sessão de curta duração em vez de um endereço conhecido.
- Uma regra de remetente, qualquer que tenha sido sua escolha. Uma lista de IPs permitidos, uma chave API permitida ou uma credencial de sessão, lembrando que cada uma se torna exclusiva assim que tem uma entrada.
- MD5 mantido na oferta de digest em qualquer trunk de onde você pretende ligar por um navegador.
Trunks SIP cobre cada configuração e onde encontrá-la. Clientes SIP cobre a conexão de um único cliente em vez de um sistema telefônico, e solução de problemas de voz investiga chamadas que não chegam.
Em resumo
Todo caminho até a rede telefônica passa por um trunk.
O que muda é o cliente do seu lado: um sistema telefônico conectado como par, ou um cliente SIP mais leve, como um navegador ou o CLI com uma credencial de curta duração.
Um trunk novo recusa tudo.
As duas direções estão desativadas, e não há remetente autorizado até você adicionar um. Isso é proposital, não uma etapa de configuração que você pode pular.
Cada direção é habilitada separadamente, e a entrada precisa de um gateway.
Um trunk com entrada habilitada mas sem gateway de entrega recusa toda chamada recebida nos seus números.
Desativar a entrada não desfaz de forma limpa.
Todo número apontando para o trunk volta a rejeitar, e reativar a entrada não os restaura. Reaponte cada número você mesmo.