O teste de carga de IA de voz que a maioria das equipes esquece: o encerramento de chamadas

A maioria dos testes de carga de IA de voz responde a uma pergunta: no pico de volume, as chamadas se conectam? Uma segunda pergunta importa tanto quanto: quando uma chamada termina, ela realmente é encerrada?

Uma chamada que nunca é encerrada continua ocupando uma vaga de concorrência na plataforma de IA de voz, um canal no seu SIP trunk e, muitas vezes, uma porta ou licença na sua plataforma de central de atendimento. Ninguém está falando nela. No pico, algumas dezenas dessas chamadas podem levar você aos seus limites enquanto o volume de chamadas parece normal.

Este guia aborda o lado do encerramento nos testes de carga. Para latência, precisão e throughput sob carga, consulte nosso guia sobre teste de carga de agentes de voz.

O que significa "encerramento de chamada" em uma chamada de IA de voz?

Uma chamada está encerrada quando cada perna dela foi liberada por todos os sistemas pelos quais passou: a perna de quem ligou, qualquer perna de transferência e a sessão do agente de IA.

Em uma chamada SIP, o encerramento é um evento de sinalização. Um lado envia uma mensagem BYE, o outro responde 200 OK e cada sistema libera o canal. Uma perna que tocou, mas nunca foi atendida, é finalizada com um CANCEL.

Em uma implantação de IA de voz, três condições precisam ser verdadeiras:

• As duas pernas desligam. Quando quem ligou ou a outra ponta cai, a outra perna também é derrubada, e não fica aberta em silêncio.
• As transferências são concluídas. Uma transferência se conecta ou falha de forma limpa, e a perna da IA sai da chamada nos dois casos.
• Todos os sistemas concordam. A operadora, seu session border controller (SBC) ou plataforma de central de atendimento e a plataforma de IA de voz mostram a chamada como encerrada.

Na Retell, uma chamada finalizada tem o status ended e um motivo de desconexão como user_hangup, agent_hangup ou call_transfer. Uma chamada ainda em andamento tem o status ongoing, e são as chamadas em andamento que contam para a sua concorrência atual.

Por que as transferências deixam chamadas abertas?

Uma transferência transforma uma chamada em duas ou mais pernas, muitas vezes em duas plataformas, e o desligamento em uma perna precisa chegar às outras. Quando esse sinal se perde ou é ignorado, uma perna fica ativa sem ninguém nela.

Padrões para verificar na sua configuração:

• Transferência cega para a IA. Muitas centrais de atendimento mantêm o controle da chamada na plataforma existente e fazem transferência cega de quem liga para o número do agente de IA. Se quem ligou desliga e o desligamento não atravessa a transferência, a perna da IA continua ativa. Se a IA encerra a chamada e sua plataforma não libera o lado dela, essa porta continua ocupada.
• Transferência fria a partir da IA. O agente de IA sai da chamada assim que a repassa. A Retell oferece suporte a dois métodos SIP: o SIP INVITE faz a ponte da transferência, enquanto o SIP REFER pede à outra ponta da chamada, normalmente sua operadora ou trunk, que inicie uma chamada separada para o destino. O REFER só funciona se o seu provedor permitir.
• Transferência assistida e transferência assistida agêntica. O agente liga para o destino enquanto quem ligou aguarda em espera, então existem duas pernas ativas ao mesmo tempo. Se o destino nunca atender, a tentativa precisa atingir o timeout e limpar os dois lados.
• Sua própria lógica de transferência. Quando a plataforma de IA de voz não controla o número (o método dial-to-SIP da Retell, por exemplo), a transferência e o encerramento da chamada passam pelas suas próprias funções personalizadas, então o encerramento é responsabilidade do seu código.

Para a experiência de quem liga em cada tipo, veja como funcionam as transferências de chamadas entre agentes de voz com IA e equipes humanas e nosso guia de transferência assistida.

Quanto custa uma chamada aberta no pico?

Uma vaga de concorrência pelo tempo em que ela permanecer aberta. A concorrência conta as chamadas ativas simultâneas, e uma chamada vazia conta da mesma forma que uma real.

A conta é simples: chamadas abertas extras a qualquer momento = chamadas por hora que não são encerradas × horas que cada uma fica aberta.

A terceira linha mostra como as equipes acabam com dezenas de chamadas fantasmas no pico: um único problema de configuração, como desligamentos que não são repassados através de uma transferência, aplicado a todas as chamadas transferidas.

Essa capacidade não é gratuita. Na Retell, as primeiras 20 chamadas simultâneas estão incluídas e a capacidade adicional custa $8 por chamada simultânea por mês (veja os preços). Quando um workspace atinge seu limite, novas chamadas recebidas aguardam cerca de 40 segundos por uma vaga livre e depois são encaminhadas para o número de fallback do número de telefone, se houver um configurado, ou são encerradas com concurrency_limit_reached. Novas chamadas realizadas são rejeitadas, a menos que o concurrency burst esteja ativado. No pico, chamadas travadas afastam clientes reais.

A mesma conta se aplica aos canais de trunk e às licenças da central de atendimento, que a plataforma de IA de voz não consegue enxergar.

Como testar o encerramento de chamadas durante um teste de carga?

Encerre cada chamada de propósito, por todos os caminhos de encerramento, na sua taxa de pico, e depois comprove que a contagem de chamadas ativas de todos os sistemas volta a zero.

Execute uma matriz de encerramento

Os webhooks de transferência vêm desativados por padrão. Adicione transfer_started, transfer_bridged, transfer_cancelled e transfer_ended aos eventos de webhook do agente para o teste.

Execute um teste de drenagem

Depois da rampa de pico, pare de fazer novas chamadas e observe os contadores caírem. Consulte a API Get Concurrency da Retell, que retorna current_concurrency (o número de chamadas em andamento), a cada poucos segundos. Ela deve chegar a zero dentro da duração da sua chamada roteirizada mais longa. Verifique as contagens do seu SBC, da central de atendimento e do trunk nos mesmos momentos. Qualquer contador que permaneça alto é o vazamento, e o sistema que o mantém indica qual lado não está liberando.

Concilie e inspecione

• Todo webhook call_started deve ter um call_ended correspondente. Todo transfer_started deve ter um transfer_ended ou transfer_cancelled.
• Após a drenagem, use a API List Calls com um filtro call_status igual a ongoing para encontrar chamadas remanescentes.
• Abra uma chamada remanescente em Call History e confira a aba Packet Capture, quando disponível. No diagrama SIP, veja qual parte enviou o BYE ou o CANCEL e se o outro lado respondeu.

O que você deve monitorar após o go-live?

Fique atento à concorrência que permanece alta quando o volume cai, a mais chamadas encerradas por timeouts e a falhas de transferência.

• Concorrência versus volume. As regras de alerta da Retell podem monitorar concurrency_used (pico de chamadas simultâneas em uma janela) junto com call_count (chamadas encerradas na janela). Se a concorrência sobe enquanto as chamadas encerradas ficam estáveis, as chamadas não estão sendo encerradas.
• Falhas de transferência. Crie alertas para transfer_call_failure_count.
• Encerramentos por timeout. Em Call History, filtre pelo motivo de desconexão. Uma participação crescente de inactivity ou max_duration_reached após transferências significa que são os mecanismos de segurança, e não os desligamentos, que estão encerrando suas chamadas.
• Chamadas de longa duração. O Live Monitoring lista todas as chamadas em andamento com a duração atualizada em tempo real. Uma chamada muito mais antiga do que sua conversa real mais longa é suspeita. Você pode encerrá-la pelo Live Monitoring ou com a API Stop Call.
• Contagens entre sistemas. As contagens de chamadas ativas da plataforma de IA, do trunk e da central de atendimento devem se mover juntas.

Quais configurações limitam o prejuízo quando uma chamada não é encerrada?

Os timeouts. Eles não corrigem uma sinalização com falha, mas limitam por quanto tempo uma chamada travada pode ocupar uma vaga.

Defina os limites de silêncio e de duração próximos à duração real das suas chamadas. Com os padrões, uma perna morta que permanece em silêncio pode ocupar uma vaga por 10 minutos, e uma que o timer de silêncio não detecta pode ocupá-la por até uma hora.

O que você deve perguntar ao seu fornecedor e à sua equipe de telefonia?

Obtenha respostas por escrito antes do lançamento:

1. Quando quem ligou desliga em uma chamada com transferência cega, qual sistema envia o BYE para a perna da IA, e isso foi testado no pico?
2. Quando a IA encerra uma chamada, sua plataforma de central de atendimento libera a porta imediatamente?
3. Depois que uma transferência se conecta e o agente de IA sai da chamada, a chamada ainda conta para a concorrência da plataforma de IA de voz até que as duas partes desliguem?
4. Seu SIP trunk permite SIP REFER e, se não permitir, qual método de transferência você deve usar?
5. É possível obter packet captures das chamadas de teste de cada salto: operadora, SBC, central de atendimento e plataforma de IA de voz?

Inclua o encerramento nos critérios de liberação

Trate "a concorrência volta a zero após o teste" como um critério de aprovação ou reprovação. Execute a matriz de encerramento e o teste de drenagem antes do lançamento e novamente após qualquer alteração nas configurações de transferência, nos números ou no roteamento de chamadas.

A Retell oferece todas as peças: transferência de chamadas fria, assistida e assistida agêntica com timeouts de toque e de espera, webhooks de transferência, motivos de desconexão por chamada, packet captures, uma API de concorrência em tempo real e alertas de concorrência e de falhas de transferência. Se você está planejando uma implantação em uma central de atendimento com alta concorrência no pico, o plano Retell Enterprise adiciona um limite alto de chamadas simultâneas e suporte dedicado.

Leituras relacionadas: Por que os testes de carga devem seguir o caminho real da chamada, o checklist de números de telefone para chamadas realizadas e mais guias no hub Retell Learn.