VoIP e IA: voice AI agents por meio de SBCs

Voice AI agents saíram dos vídeos de demonstração e chegaram a números telefônicos reais. Recepcionistas de IA atendem chamadas para consultórios odontológicos, discadores outbound da Vapi, Retell e Bland alcançam milhares de consumidores por hora, e centrais de atendimento roteiam o primeiro trecho de cada chamada de cliente por um pipeline de speech-to-text e modelo de linguagem antes que qualquer humano fale. O cluster de voice AI é a parte da pilha que recebe atenção do marketing. O Controlador de Borda de Sessão (SBC) é a parte que determina se algo disso realmente funciona na PSTN.

Este artigo aborda o que muda quando o terminal do outro lado do seu SIP trunk é um modelo de linguagem em vez de um humano, e as escolhas práticas de configuração que afetam latência, atestação, exposição a fraude e planejamento de capacidade. Foi escrito para operadores de infraestrutura de voz que avaliam como colocar AI agents em produção, não para equipes de produto de IA escolhendo um fornecedor de voicebot. Para a arquitetura de referência, como o SBC faz a ponte entre a PSTN e um cluster de voice AI, e como criptografia, negociação de codec, normalização SIP e ocultação de topologia funcionam no nível de componente, consulte SBC como gateway de voz para IA: arquitetura, roteamento e segurança para voice AI na PSTN.

Como voice AI agents mudam o padrão de tráfego

Uma central de atendimento tradicional tem uma curva razoavelmente estável. Chamadas chegam ao longo do dia, agentes fazem login por turnos, contagens de sessões concorrentes se movem dentro de uma faixa previsível. Voice AI agents introduzem vários padrões de tráfego que o planejamento de capacidade de centrais de atendimento não cobre naturalmente, e todos eles chegam ao SBC primeiro.

Discagem outbound em rajadas

Uma campanha de outbound com IA pode disparar várias centenas de chamadas por segundo a partir de uma partida fria, manter um pico de dezenas de milhares de sessões concorrentes por uma hora e então cair a zero. O discador não se auto-regula da forma como uma sala cheia de humanos faz. Dimensionar o SBC pela média diária é o modo de falha aqui; o pico de rajada é o que determina se seus grupos de troncos SIP, capacidade de NAP e limites de CPS aguentam. O limite de CPS por NAP configurado para cada operadora geralmente é a restrição que falha primeiro em produção, e deve ser definido antes do lançamento.

Entrada sempre ativa

Uma recepcionista de IA atende toda chamada a qualquer hora, sem fila fora do expediente e sem transbordo para correio de voz. O heartbeat SIP OPTIONS do SBC, a saúde de registro e a validade de certificado precisam se manter sem janela de manutenção, e a mesma higiene de trust-store que se aplica a uma implantação de Teams Direct Routing se aplica a qualquer terminal TLS ao qual um bot se conecte.

Falas curtas, chamadas longas

AI agents falam em turnos curtos e frequentes. O stream de mídia consiste em muitas rajadas pequenas de RTP separadas por silêncio, com detecção de atividade de voz acionando frequentemente. O comportamento do jitter buffer ajustado para conversação humana interage mal com esse padrão, especialmente quando o SBC também está transcodificando entre codecs. Use o perfil de jitter e codec por NAP do SBC para corresponder ao que a plataforma de IA realmente emite, e verifique com captura de pacotes antes de ir ao ar. Adivinhar nessa camada é a causa mais comum de barge-in cortado.

O orçamento de latência para uma chamada de IA conversacional

IA conversacional soa natural quando o tempo de resposta ponta a ponta fica abaixo de aproximadamente 800 ms. Acima disso, o chamador começa a perguntar “você ainda está aí?” ou a falar por cima do bot. Acima de 1,5 segundo, a chamada soa quebrada. O orçamento de latência é composto por várias etapas, e o SBC é responsável por duas delas.

Para onde vão os milissegundos

Uma ida e volta típica se divide aproximadamente assim: 50 a 150 ms de transporte de rede do chamador ao cluster de IA, 150 a 350 ms de ASR para produzir uma transcrição utilizável, 150 a 800 ms de inferência do modelo de linguagem, 200 a 600 ms de síntese TTS, e 50 a 150 ms de volta ao chamador. O SBC contribui para a primeira e última etapas, mais qualquer transcodificação que realiza em cada perna.

O que o SBC controla nesse orçamento

Três configurações do SBC importam mais. Escolha de codec determina se o SBC decodifica e recodifica cada pacote RTP (transcodificação Opus-para-G.711 em hardware) ou repassa o stream (G.711 em ambas as pernas); transcodificação em hardware adiciona cerca de 20 ms por perna e pass-through adiciona poucos ms. Profundidade do jitter buffer troca latência por tolerância a perda de pacotes, e chamadas de IA querem o buffer mais raso que ainda sobreviva ao jitter real da sua operadora, que geralmente é menor que o padrão. Ancoragem de mídia versus pass-through decide se o SBC pode fazer fork de áudio para gravação (ancorado) ou elimina o salto ao custo de abrir mão da gravação durante a chamada (pass-through).

O que o SBC não pode corrigir é a própria plataforma de IA. Se um bot parece lento e o SBC está configurado corretamente, o problema está upstream. Meça o ASR-to-first-token e TTS-to-first-audio nas métricas da própria plataforma antes de culpar a rede.

Seleção de codec na fronteira IA-PSTN

Incompatibilidade de codec é o problema de produção mais comum em novas implantações de voice AI. A operadora oferece G.711 ou G.729. A plataforma de IA prefere Opus, às vezes aceita L16 wideband, e pode degradar silenciosamente para G.711 se solicitada. O SBC fica no meio e decide o que é negociado em cada lado.

O que o lado PSTN espera

Tráfego PSTN de entrada na América do Norte chega predominantemente como G.711 PCMU ou PCMA; alguns provedores de SIP trunk oferecem G.729 para economizar banda. O ProSBC lida com G.711 nativamente em software. Transcodificação de Opus, G.729 e AMR requer DSP de hardware via a linha de produtos Ttrans hoje; transcodificação em software para codecs adicionais está no roadmap para o final de 2026. Construa o plano de implantação em torno dessa restrição e não em torno do que está em um roadmap futuro. A referência de arquitetura cobre onde a negociação de codec se encaixa no fluxo geral de chamada SBC-para-IA.

O que o lado da IA espera

A maioria das plataformas comerciais de voice AI aceita G.711 diretamente em uma perna SIP e lida internamente com o up-sampling para sua taxa de amostragem preferida. Plataformas baseadas em WebRTC esperam Opus e DTLS-SRTP por padrão, mas a maioria também expõe um endpoint SIP que aceita G.711. O padrão prático é terminar a operadora em G.711 com SDES-SRTP, terminar a IA em G.711 com TLS/SRTP, e deixar o SBC lidar com TLS e SRTP independentemente em cada perna. Transcodificação só é necessária quando uma plataforma de IA específica recusa G.711 ou quando requisitos de qualidade de áudio exigem Opus ponta a ponta.

A questão do DTMF

IVRs de IA que solicitam entrada por teclado dependem de o DTMF sobreviver ao salto de codec. O RFC 4733 (anteriormente RFC 2833) envia DTMF como telephone events out-of-band dentro do stream RTP, em vez de tons de áudio in-band. Se a negociação SDP do SBC descarta o payload type de telephone-event durante o offer/answer de codec, o bot para de ouvir “pressione 1.” Confirme em uma chamada de teste antes do lançamento que o payload de telephone-event é negociado ponta a ponta e que a plataforma de IA está configurada para escutá-lo.

Roteamento programável: perguntando ao orquestrador para onde vai a chamada

Implantações de voice AI raramente usam tabelas de roteamento estáticas. Qual agent atende uma determinada chamada depende do número discado, da campanha, da hora do dia, da detecção de idioma na primeira fala, do histórico do chamador com a marca e, cada vez mais, de um orquestrador de IA que decide em tempo real se roteia a chamada para um bot, escala para um humano ou transfere para outro bot especializado no assunto. O SBC precisa de uma forma de fazer essa pergunta sem reconstruir a tabela de roteamento a cada mudança.

O padrão de consulta HTTP

A integração REST API de roteamento de chamadas do ProSBC trata isso diretamente. Quando um INVITE chega, o script de roteamento emite uma consulta HTTP ao orquestrador com o número chamador, número discado, identificador do NAP e quaisquer outros parâmetros de chamada relevantes. O orquestrador retorna uma resposta JSON especificando o NAP de destino, reescritas de cabeçalho opcionais e prioridade de roteamento. Toda a troca acontece na fase de sinalização antes da negociação de mídia, portanto não adiciona nada à latência de áudio.

O que isso possibilita para voice AI

Um único SBC pode atender uma dúzia de campanhas de AI agent, cada uma com sua própria lógica de roteamento, sem mudanças de configuração estáticas. Novas campanhas se tornam novas entradas no banco de dados do orquestrador, e não novos NAPs no ProSBC. Failover de um bot para um humano acontece no orquestrador sem exigir reload do SBC. A/B testing de dois modelos de voz vira uma regra de roteamento, não uma mudança de implantação. A referência de arquitetura cataloga padrões adicionais de roteamento, incluindo roteamento VIP para um humano, roteamento de chamadas anômalas por um serviço de pontuação de fraude e roteamento por detecção de idioma, com o fluxo de request-response para cada um.

Limites a definir

Mantenha o timeout da consulta ao orquestrador curto (500 a 1.500 ms) e defina um fallback explícito para quando a consulta falhar. O fallback deve cair em algum lugar seguro: um IVR genérico, uma fila humana padrão ou um tratamento de ocupado, dependendo do caso de uso. Deixar chamadas travadas esperando uma resposta lenta do orquestrador é o pior modo de falha aqui. O ProSBC suporta URLs primária e secundária para a consulta HTTP, para que o próprio orquestrador possa ser implantado de forma redundante.

Fraude e confiança na borda de voice AI

Modelos de voz generativa introduzem padrões de ataque nos quais a camada de SBC historicamente não precisou pensar. Alguns são problemas reciclados de fraude em telecomunicações com uma cara nova, outros são genuinamente novos, e o SBC é o ponto de controle correto para a maioria deles.

Deepfake de caller ID e clonagem de voz

Um atacante que clona a voz de um CEO e usa uma chamada assinada com PASSporT sintetizado contra uma equipe financeira tem um pretexto mais convincente do que qualquer campanha de vishing pré-IA. A defesa é a mesma de qualquer spoofing de caller-ID: atestação STIR/SHAKEN na camada do SBC, combinada com parceiros de pontuação de fraude que interceptam chamadas de alto risco antes que toquem. A integração STIR/SHAKEN em produção do ProSBC usa redirect SIP para TransNexus ClearIP ou Neustar, onde o STI-AS atua como servidor de redirect SIP e retorna um 302 com o cabeçalho Identity no caminho de sucesso. O lado de terminação recebe um sinal claro sobre o quanto o originador garante o número chamador, que é a única resposta honesta para um deepfake na camada de operadora.

Outbound originado por IA e atestação

Reguladores se preocupam com como chamadas outbound originadas por IA são atestadas. Uma chamada feita por um discador de IA em nome de um cliente final não verificado não deve receber atestação de nível A; isso é uma declaração falsa que gera risco reputacional e exposição à FCC. O motor de roteamento programável do ProSBC define o nível de atestação por chamada, por campanha ou por NAP, para que um único SBC tratando tráfego de múltiplos tenants de IA possa assinar as chamadas de cada tenant no nível apropriado ao status de verificação daquele tenant. O padrão de roteamento por nível de atestação cobre isso em detalhes.

Prompt injection e abuso específico de IA

Voice AI agents têm uma superfície de ataque única: um chamador pode falar instruções que o modelo de linguagem interpreta como comandos de sistema. O SBC não resolve prompt injection diretamente, mas controla quais chamadas chegam ao bot. Lista de bloqueio dinâmica, proteção contra scanning de registro e limites de CPS por NAP reduzem o tráfego de probing que a camada de IA precisa processar. Os mesmos controles se aplicam a fraude telefônica específica de IA, onde um discador sequestrado pode gerar grandes volumes de chamadas internacionais fraudulentas; filtros de destino por NAP, bloqueios de prefixo de tarifa premium e integração de pontuação de fraude com TransNexus, SecureLogix ou YouMail são as defesas padrão.

Onde voice AI agents se encaixam no SBC

Três formatos de implantação respondem por quase todo o tráfego de voice AI em produção. Cada um tem implicações diferentes para o SBC.

Recepcionista de IA para um cliente SMB ou MSP

O caso mais simples: um número de entrada, um AI agent, um tenant. Um único NAP no lado da operadora, um único NAP no lado da IA, tratamento básico de SIP e codec. Para um MSP entregando voice AI agents por tenant, o multiplicador é o número de clientes, não a complexidade por cliente. Uma única instância do ProSBC com 1.024 NAPs disponíveis pode hospedar centenas de recepcionistas de IA lado a lado, cada uma com seu próprio roteamento, gravação e tratamento STIR/SHAKEN.

Central de atendimento com IA na linha de frente

O bot trata os primeiros 30 segundos de cada chamada, identifica o chamador, faz triagem do pedido e resolve ou transfere para um humano. Este é o padrão de comunicações em nuvem aplicado a AI agents. O papel do SBC é o mesmo de uma central de atendimento tradicional, mais a consulta ao orquestrador no momento do INVITE para decidir fila de bot ou humana com base no número discado, na hora ou no histórico prévio do chamador. Comparado a uma implantação de Teams Direct Routing, o fluxo de IA da central de atendimento se beneficia mais da ancoragem de mídia para gravação e menos do media bypass.

Discador outbound de IA

O formato mais exigente. Um discador orientado a campanha gera os padrões de rajada descritos anteriormente, e cada chamada precisa carregar o nível correto de atestação, caller ID e tratamento de opt-out. O motor de roteamento programável do ProSBC define todos os três por chamada, e o limite de CPS por NAP protege a operadora de ser sobrecarregada. Se a plataforma de IA é hospedada por terceiros, a perna discador-para-SBC frequentemente usa WebRTC ou SIP/TLS pela internet pública, com TLS/SRTP terminando no SBC. O planejamento de capacidade mira o pico de rajada da campanha.

Gravação, conformidade e consentimento de duas partes

Fluxos de chamada assistidos por IA precisam lidar com regras de consentimento nas jurisdições onde operam. Estados com consentimento de duas partes exigem que o chamador seja informado de que a chamada está sendo gravada ou processada por um sistema de IA, e o SBC frequentemente é a camada que prova que a divulgação aconteceu. O padrão prático é ancorar mídia no SBC, fazer fork do áudio (ou apenas da perna de entrada) para um alvo de gravação seguro, e registrar o timestamp do aviso de consentimento e da resposta do chamador. Se uma chamada for questionada depois, a gravação mostra que a divulgação foi feita e o chamador continuou.

Redação de PII e PCI fica na camada da plataforma de IA ou em um serviço de redação separado, mas o SBC controla se o áudio original chega a eles. O modo pass-through economiza carga de mídia do SBC, mas abre mão da trilha de auditoria. Para implantações hospedadas em um SBC em software rodando em AWS, Azure ou KVM, o alvo do fork de gravação pode ser um endpoint de armazenamento em nuvem ou um serviço de gravação dedicado; o SBC não se importa para onde os bytes vão, apenas que o fork está configurado.

Perguntas frequentes

Conclusão

Voice AI agents funcionam em produção quando a camada entre a plataforma de IA e a rede telefônica se comporta como uma peça séria de infraestrutura de telecomunicações, e não como uma demo SIP. O SBC é o que transforma o cluster de IA em algo que uma operadora vai confiar, atestar e rotear. Também é o que protege a camada de IA das realidades mais confusas do tráfego PSTN: variância de codec, desvio de atestação, probing de fraude e rajadas que nenhum cluster de inferência de IA quer absorver diretamente.

O SBC certo para voice AI não é um “SBC de IA.” É um SBC programável e multi-tenant com uma REST API limpa, controle de codec e roteamento por NAP, integração STIR/SHAKEN que se encaixa em padrões reais de produção, e margem de capacidade suficiente para o comportamento de rajada que cargas de trabalho de IA geram. A questão de infraestrutura para uma implantação de voice AI é a mesma questão de qualquer implantação séria de voz, apenas com tolerâncias mais estreitas em latência, atestação e confiança.