Por que testes de carga de IA de voz devem seguir o caminho real da chamada

Se a sua plataforma de central de atendimento atende todas as chamadas primeiro e depois transfere os clientes para um agente de voz com IA, um teste de carga que liga diretamente para a IA diz muito pouco. Ele prova que a IA aguenta muitas chamadas. Não prova que a sua operadora, a sua plataforma de controle de chamadas, a transferência para o agente e a transferência de volta aguentam o volume de pico. A maioria das falhas nesse tipo de implantação acontece nas junções entre sistemas, e essas junções só recebem tráfego quando as chamadas seguem a rota de produção.

Para o método geral (aumento gradual de simultaneidade, percentis de latência, suítes de regressão), veja o nosso guia de teste de carga de agentes de voz. Este artigo trata de implantações em que uma plataforma UCaaS ou CCaaS detém o controle das chamadas.

Por que um teste de carga direto via SIP ou API não prova que a implantação funciona?

Porque ele pula todas as etapas pelas quais seus clientes passam. Um teste direto envia chamadas diretamente para o endpoint SIP ou a API do provedor de IA. Uma chamada de produção percorre uma rota mais longa: chega pela operadora, cai na sua central de atendimento ou plataforma UCaaS, passa pela sua URA ou lógica de roteamento, é transferida às cegas para o ponto de entrada da IA de voz e, então, termina ali ou é transferida de volta para uma fila humana.

Cada etapa tem seu próprio limite de capacidade, comportamento SIP e responsável pela configuração. Um teste direto não exercita nenhum deles. Três exemplos da documentação da Retell:

• A capacidade é definida em mais de um lugar. O limite de simultaneidade da Retell se aplica por workspace (workspaces com pagamento conforme o uso começam com 20 chamadas simultâneas). O guia da Retell para Five9 observa que o Five9 aplica seus próprios limites de capacidade de tronco, e o guia para Avaya orienta a confirmar se a quantidade de troncos SIP administrados cobre as chamadas simultâneas esperadas. Um teste que contorna a plataforma nunca atinge esse limite.
• O método de conexão muda o que a IA pode fazer. A Retell oferece suporte a elastic SIP trunking (o método recomendado) e à discagem para um SIP URI. Com o método SIP URI, o recurso nativo de transferência da Retell não fica disponível, então transferências e encerramentos precisam ser tratados pela sua própria lógica. Um teste direto nunca revelaria essa lacuna.
• As transferências dependem do outro lado. A transferência direta (cold transfer) da Retell usa SIP INVITE por padrão, ou SIP REFER se o seu provedor de telefonia oferecer suporte. Se o REFER funciona, e se os cabeçalhos personalizados sobrevivem a ele, depende do seu provedor, não da IA.

Como é o caminho real da chamada quando uma plataforma de central de atendimento detém o controle das chamadas?

É uma cadeia de cinco etapas, e toda chamada de teste deve passar pelas cinco.

Dois detalhes da documentação da Retell importam aqui. Com o método SIP URI, cada chamada precisa primeiro de uma requisição Register Phone Call, e a chamada deve chegar a esse URI em até 5 minutos, ou termina com registered_call_timeout; portanto, o seu serviço de registro também precisa aguentar a carga. Na saída, o guia da Retell para Genesys Cloud observa que as chamadas que o Genesys transfere adiante escolhem um tronco a partir dos planos de numeração e das rotas de saída do Site: configuração da plataforma que um teste direto nunca alcança.

Onde as falhas exclusivas do caminho aparecem no volume de pico?

Onde dois sistemas se encontram, geralmente quando um deles começa a enfileirar. Observe estes pontos durante o aumento gradual:

1. O limite de capacidade mais restrito prevalece. Se o tronco da sua plataforma permite menos chamadas simultâneas do que o seu workspace de IA, os clientes ficam travados na plataforma e o painel da IA parece saudável. Dimensione juntos a operadora, o tronco da plataforma e o limite de simultaneidade da IA.
2. Fila de entrada na IA. Quando as chamadas recebidas atingem o limite de simultaneidade da Retell, a Retell retém novas chamadas por cerca de 40 segundos. Se nenhuma vaga abrir, ela transfere o cliente para um fallback_number configurado ou encerra a chamada com concurrency_limit_reached se nenhum estiver definido. Decida com antecedência para onde esse fallback deve ir (muitas vezes de volta para a fila humana da sua plataforma) e teste se ele funciona sob carga.
3. Tráfego de saída disputando com o de entrada. Todas as chamadas de voz de um workspace compartilham um único pool de simultaneidade. Se o mesmo workspace também executa campanhas de saída, a simultaneidade reservada para entrada pode garantir vagas para as chamadas transferidas.
4. Taxa de estabelecimento de chamadas. A Retell define chamadas por segundo por caminho de telefonia, e sua documentação observa que o CPS da Custom Telephony escala com a sua simultaneidade. Uma rajada de transferências no início da hora pode atingir um limite de taxa antes de atingir um limite de simultaneidade.
5. Configurações de rede e mídia. A Retell publica vários blocos de IP para incluir na allowlist (alguns se aplicam apenas a determinado tráfego dos EUA), seus transportes (TCP recomendado, UDP, TLS, mTLS) e seus codecs (PCMU, PCMA, G.722). Uma allowlist que cobre apenas alguns desses blocos pode passar em um teste pequeno e falhar em volume.
6. Alterações SIP no meio da chamada. As plataformas podem enviar re-INVITEs para renovar uma sessão, mover a mídia ou colocar uma chamada em espera. A Retell responde a re-INVITEs dentro do diálogo para renovação de sessão, reancoragem de mídia, troca de codec, re-keys de SRTP e espera ou retomada; confirme se os re-INVITEs da sua plataforma se comportam da mesma forma em volume.

Como gerar tráfego de teste pelo caminho real?

Origine as chamadas de teste fora da sua rede e ligue para os mesmos números públicos que seus clientes usam. Essa é a única forma de todas as etapas receberem carga.

• Escolha um gerador de chamadas que ligue para o seu número público. As chamadas em lote da Retell fazem ligações de saída a partir da Retell, e os testes de simulação da Retell executam conversas baseadas em texto, então nenhum dos dois reproduz uma chamada recebida que a sua plataforma transfere. Alguns parceiros de teste fazem chamadas reais; a Hamming, por exemplo, descreve seus agentes de voz ligando para os seus. Pergunte a qualquer fornecedor de testes se as chamadas dele entram pela rede telefônica pública ou se conectam diretamente ao agente.
• Identifique cada chamada de teste. Faça a sua plataforma adicionar um cabeçalho SIP personalizado X- (um ID da execução de teste, por exemplo) na transferência. A Retell extrai os cabeçalhos X- recebidos para o campo custom_sip_headers da chamada e para variáveis dinâmicas, para que você possa vincular cada chamada da IA ao registro da plataforma.
• Aumente em etapas. Comece abaixo do pico esperado, suba além dele, depois deixe o tráfego cair e confirme que o sistema volta ao estado ocioso.
• Convoque todos os responsáveis. Operadora, administrador da plataforma e fornecedor de IA de voz devem participar. O guia da Retell para Five9 conduz o teste final de integração como uma sessão conjunta.
• Aumente os limites antes do teste, não durante. Verifique seus limites de simultaneidade e CPS da IA na página Limits (a calculadora integrada sugere valores com base no tráfego do seu horário de pico) e confirme se a capacidade de tronco da plataforma corresponde.

Quais sinais SIP você deve observar durante o teste?

Observe a sinalização de cada chamada, do primeiro INVITE ao BYE final, dos dois lados da transferência. Os detalhes de chamada da Retell podem incluir uma aba Packet Capture com a sinalização SIP da chamada, e o guia de depuração com PCAP mostra como lê-la no Wireshark. Se você opera seu próprio tronco, a documentação da Retell recomenda capturar no servidor ou gateway que termina o SIP, que geralmente é o seu SBC.

Procure por:

• Um estabelecimento limpo na perna da transferência: INVITE, 100 Trying, 180 Ringing, 200 OK, ACK.
• Respostas de erro: 403 (allowlist ou permissão), 404 (SIP URI ou roteamento incorreto), 408 ou 477 (endpoint inacessível ou erro de transporte), 486 (ocupado), 503 (serviço indisponível).
• A transferência de volta: um REFER ou um novo INVITE, dependendo do método de transferência, e se os seus cabeçalhos X- sobreviveram. A documentação da Retell alerta que cabeçalhos personalizados podem ser removidos quando uma transferência vai para um número PSTN em vez de um endpoint SIP.
• Quem enviou o BYE, e quando: toda chamada deve terminar com um BYE da parte que você espera.

Os eventos de webhook da Retell (call_started, call_ended e os eventos transfer_*) fornecem uma linha do tempo por chamada para comparar com as capturas.

O que deve contar como aprovação?

Aprovação significa que os números batem em todos os sistemas, não apenas que a IA se manteve no ar. Use este checklist:

• A contagem de chamadas coincide entre os registros da operadora, os relatórios da plataforma e o log de chamadas da IA na janela de teste.
• Toda chamada da IA terminou com um motivo de desconexão esperado (user_hangup, agent_hangup, call_transfer), e não houve motivos concurrency_limit_reached ou error_*.
• Toda transferência de volta para um humano chegou à fila certa, com o identificador de chamadas e os cabeçalhos esperados.
• Nenhuma resposta SIP 4xx ou 5xx nas pernas de transferência, exceto as que você provocou de propósito.
• O áudio fluiu nos dois sentidos nas chamadas amostradas.
• A simultaneidade de pico ficou abaixo de todos os limites da cadeia, com folga.
• Depois que o tráfego parou, a simultaneidade voltou a zero no lado da IA e a plataforma não mostrou sessões remanescentes.

Essa última verificação merece um plano de teste próprio, já que chamadas que nunca se encerram totalmente após uma transferência podem consumir simultaneidade no pico. Tratamos do encerramento de chamadas em um guia separado.

O que você deve perguntar ao seu fornecedor de IA de voz antes do teste?

Faça perguntas que obriguem o fornecedor a mostrar o caminho, não apenas a IA:

1. Qual método de conexão vocês recomendam para a nossa plataforma, e o que ele muda nas transferências e nos encerramentos?
2. Quais métodos de transferência SIP vocês suportam (INVITE, REFER), e o que cada um exige da nossa plataforma?
3. Como passamos e lemos cabeçalhos SIP personalizados nos dois sentidos?
4. Onde são definidos os limites de simultaneidade e de chamadas por segundo, o que acontece com a chamada no limite, e podemos aumentá-los para o teste?
5. Podemos ver a sinalização SIP e os motivos de desconexão por chamada, e a equipe de telefonia de vocês vai revisar as capturas conosco?

A documentação da Retell inclui guias de configuração para Genesys Cloud, Five9, Avaya e Amazon Connect, um guia geral de telefonia personalizada e um guia de simultaneidade que cobre cada limite. Para transferências a partir do agente, veja transferência de chamadas e como funcionam as passagens da IA para humanos.

Se a sua plataforma detém o controle das chamadas e você precisa de um agente de voz com IA que se encaixe por trás dela, conheça a plataforma de IA conversacional corporativa da Retell e fale com a equipe sobre o planejamento de um teste de carga no seu caminho real de chamadas.

Leituras relacionadas: O teste de carga de encerramento de chamadas, o fluxo de trabalho do CRM para a IA de voz e mais guias no hub Retell Learn.