Perché i test di carico dell'IA vocale devono seguire il percorso reale delle chiamate

Se la tua piattaforma di contact center risponde per prima a ogni chiamata e poi trasferisce i chiamanti a un agente vocale con IA, un test di carico che chiama direttamente l'IA ti dice ben poco. Dimostra che l'IA è in grado di gestire molte chiamate. Non dimostra che il tuo carrier, la tua piattaforma di controllo delle chiamate, il trasferimento verso l'agente e il trasferimento di ritorno reggano tutti ai picchi di volume. La maggior parte dei guasti in questo tipo di implementazione si verifica nei punti di giunzione tra i sistemi, e queste giunzioni trasportano traffico solo quando le chiamate seguono il percorso di produzione.

Per il metodo generale (aumento progressivo della concorrenza, percentili di latenza, suite di regressione), consulta la nostra guida ai test di carico degli agenti vocali. Questo articolo tratta le implementazioni in cui il controllo delle chiamate è affidato a una piattaforma UCaaS o CCaaS.

Perché un test di carico diretto via SIP o API non dimostra che l'implementazione funziona?

Perché salta ogni passaggio attraversato dai tuoi chiamanti. Un test diretto invia le chiamate direttamente all'endpoint SIP o all'API del provider di IA. Una chiamata di produzione segue un percorso più lungo: arriva dal carrier, approda sulla tua piattaforma di contact center o UCaaS, passa attraverso il tuo IVR o la logica di instradamento, viene trasferita alla cieca (blind transfer) al punto di ingresso dell'IA vocale e poi termina lì oppure viene ritrasferita a una coda di operatori umani.

Ogni passaggio ha il proprio limite di capacità, il proprio comportamento SIP e il proprio responsabile della configurazione. Un test diretto non ne mette alla prova nessuno. Tre esempi dalla documentazione di Retell:

• La capacità è impostata in più punti. Il limite di concorrenza di Retell si applica per workspace (i workspace con pagamento a consumo partono da 20 chiamate simultanee). La guida di Retell per Five9 segnala che Five9 applica i propri limiti di capacità del trunk, e la guida per Avaya indica di verificare che il numero di trunk SIP configurati copra le chiamate simultanee previste. Un test che bypassa la piattaforma non ne tocca mai il limite.
• Il metodo di connessione cambia ciò che l'IA può fare. Retell supporta l'elastic SIP trunking (il metodo consigliato) e la chiamata a un SIP URI. Con il metodo SIP URI, la funzione di trasferimento integrata di Retell non è disponibile, quindi trasferimenti e riagganci devono essere gestiti dalla tua logica. Un test diretto non evidenzierebbe mai questa lacuna.
• I trasferimenti dipendono dall'altro capo. Il trasferimento a freddo (cold transfer) di Retell usa SIP INVITE per impostazione predefinita, oppure SIP REFER se il tuo provider di telefonia lo supporta. Il funzionamento di REFER, e la conservazione delle intestazioni personalizzate, dipendono dal tuo provider, non dall'IA.

Che aspetto ha il percorso reale delle chiamate quando il controllo è affidato a una piattaforma di contact center?

È una catena di cinque passaggi, e ogni chiamata di test dovrebbe attraversarli tutti e cinque.

Qui contano due dettagli della documentazione di Retell. Con il metodo SIP URI, ogni chiamata richiede prima una richiesta Register Phone Call, e la chiamata deve raggiungere quell'URI entro 5 minuti, altrimenti termina con registered_call_timeout: anche il tuo servizio di registrazione deve quindi reggere il carico. Sul lato dell'uscita, la guida di Retell per Genesys Cloud segnala che le chiamate che Genesys trasferisce oltre scelgono un trunk in base ai number plan e alle outbound route del Site: una configurazione della piattaforma che un test diretto non raggiunge mai.

Dove emergono, ai picchi di volume, i guasti legati al percorso?

Nei punti di incontro tra due sistemi, di solito quando uno dei due inizia ad accodare. Tieni d'occhio questi aspetti durante l'aumento progressivo:

1. Vince il limite di capacità più stretto. Se il trunk della tua piattaforma consente meno chiamate simultanee del tuo workspace IA, i chiamanti restano bloccati nella piattaforma mentre la dashboard dell'IA sembra in salute. Dimensiona insieme il carrier, il trunk della piattaforma e il limite di concorrenza dell'IA.
2. Accodamento in entrata sull'IA. Quando le chiamate in entrata raggiungono il limite di concorrenza di Retell, Retell mette in attesa le nuove chiamate per circa 40 secondi. Se non si libera alcuno slot, trasferisce il chiamante a un fallback_number configurato, oppure termina la chiamata con concurrency_limit_reached se non ne è impostato nessuno. Decidi in anticipo dove deve andare quel fallback (spesso di nuovo nella coda di operatori umani della tua piattaforma) e verifica che funzioni sotto carico.
3. Il traffico in uscita che sottrae spazio a quello in entrata. Tutte le chiamate vocali di un workspace condividono un unico pool di concorrenza. Se lo stesso workspace esegue anche campagne in uscita, la concorrenza riservata alle chiamate in entrata può tenere slot a disposizione delle chiamate trasferite.
4. Frequenza di instaurazione delle chiamate. Retell imposta le chiamate al secondo per ciascun percorso di telefonia, e la sua documentazione segnala che il CPS di Custom Telephony scala con la tua concorrenza. Un'ondata di trasferimenti allo scoccare dell'ora può raggiungere un limite di frequenza prima di un limite di concorrenza.
5. Impostazioni di rete e media. Retell pubblica diversi blocchi IP da inserire nella allowlist (alcuni valgono solo per determinato traffico statunitense), i propri protocolli di trasporto (TCP consigliato, UDP, TLS, mTLS) e i propri codec (PCMU, PCMA, G.722). Una allowlist che copre solo alcuni di quei blocchi può superare un piccolo test e fallire sotto volume.
6. Modifiche SIP a chiamata in corso. Le piattaforme possono inviare re-INVITE per aggiornare una sessione, spostare i media o mettere in attesa una chiamata. Retell risponde ai re-INVITE in-dialog per aggiornamenti di sessione, re-anchoring dei media, cambi di codec, re-key SRTP e messa in attesa o ripresa; verifica che i re-INVITE della tua piattaforma si comportino allo stesso modo sotto volume.

Come generare traffico di test attraverso il percorso reale?

Origina le chiamate di test al di fuori della tua rete e componi gli stessi numeri pubblici usati dai tuoi chiamanti. È l'unico modo perché ogni passaggio sia sottoposto a carico.

• Scegli un generatore di chiamate che componga il tuo numero pubblico. Le chiamate in batch di Retell effettuano chiamate in uscita da Retell, e i test di simulazione di Retell eseguono conversazioni testuali, quindi nessuno dei due riproduce una chiamata in entrata trasferita dalla tua piattaforma. Alcuni partner di test effettuano chiamate reali; Hamming, ad esempio, descrive i propri agenti vocali che chiamano i tuoi. Chiedi a qualsiasi fornitore di test se le sue chiamate entrano dalla rete telefonica pubblica o si collegano direttamente all'agente.
• Contrassegna ogni chiamata di test. Fai aggiungere alla tua piattaforma un'intestazione SIP X- personalizzata (ad esempio un ID dell'esecuzione di test) durante il trasferimento. Retell estrae le intestazioni X- in entrata nel campo custom_sip_headers della chiamata e nelle variabili dinamiche, così puoi ricollegare ogni chiamata dell'IA al record della piattaforma.
• Aumenta il carico a gradini. Parti al di sotto del picco previsto, superalo gradualmente, poi lascia calare il traffico e verifica che il sistema torni inattivo.
• Coinvolgi tutti i responsabili. Carrier, amministratore della piattaforma e fornitore di IA vocale dovrebbero partecipare tutti. La guida di Retell per Five9 prevede che il test di integrazione finale si svolga in una sessione congiunta.
• Alza i limiti prima del test, non durante. Controlla i limiti di concorrenza e CPS dell'IA nella pagina Limits (il calcolatore integrato suggerisce valori in base al traffico dell'ora di punta) e verifica che la capacità del trunk della piattaforma corrisponda.

Quali segnali SIP monitorare durante il test?

Monitora la segnalazione di ogni chiamata dal primo INVITE al BYE finale, su entrambi i lati del trasferimento. I dettagli delle chiamate di Retell possono includere una scheda Packet Capture con la segnalazione SIP della chiamata, e la sua guida al debug con PCAP spiega come leggerla in Wireshark. Se gestisci un tuo trunk, la documentazione di Retell consiglia di effettuare la cattura sul server o sul gateway che termina il SIP, di solito il tuo SBC.

Cerca:

• Un'instaurazione pulita sulla tratta del trasferimento: INVITE, 100 Trying, 180 Ringing, 200 OK, ACK.
• Risposte di errore: 403 (allowlist o autorizzazioni), 404 (SIP URI o instradamento errati), 408 o 477 (endpoint irraggiungibile o errore di trasporto), 486 (occupato), 503 (servizio non disponibile).
• Il trasferimento di ritorno: un REFER o un nuovo INVITE, a seconda del metodo di trasferimento, e se le tue intestazioni X- sono state conservate. La documentazione di Retell avverte che le intestazioni personalizzate possono essere rimosse quando un trasferimento va verso un numero PSTN anziché verso un endpoint SIP.
• Chi ha inviato il BYE, e quando: ogni chiamata dovrebbe terminare con un BYE inviato dalla parte che ti aspetti.

Gli eventi webhook di Retell (call_started, call_ended e gli eventi transfer_*) ti forniscono una cronologia per chiamata da confrontare con le catture.

Cosa dovrebbe contare come test superato?

Un test è superato quando i numeri coincidono in tutti i sistemi, non solo quando l'IA è rimasta operativa. Usa questa checklist:

• Il numero di chiamate coincide tra registri del carrier, report della piattaforma e log delle chiamate dell'IA per la finestra di test.
• Ogni chiamata dell'IA è terminata con un motivo di disconnessione previsto (user_hangup, agent_hangup, call_transfer), senza motivi concurrency_limit_reached o error_*.
• Ogni trasferimento di ritorno a un operatore umano ha raggiunto la coda corretta, con l'ID chiamante e le intestazioni previsti.
• Nessuna risposta SIP 4xx o 5xx sulle tratte di trasferimento, salvo quelle provocate intenzionalmente.
• L'audio è fluito in entrambe le direzioni nelle chiamate campione.
• La concorrenza di picco è rimasta al di sotto di ogni limite della catena, con margine.
• Dopo l'interruzione del traffico, la concorrenza è tornata a zero lato IA e la piattaforma non mostrava sessioni residue.

Quest'ultimo controllo merita un piano di test dedicato, perché le chiamate che non si chiudono completamente dopo un trasferimento possono consumare concorrenza nei picchi. Trattiamo la chiusura delle chiamate in una guida separata.

Cosa chiedere al tuo fornitore di IA vocale prima del test?

Fai domande che costringano il fornitore a mostrarti il percorso, non solo l'IA:

1. Quale metodo di connessione consigliate per la nostra piattaforma, e cosa cambia per trasferimenti e riagganci?
2. Quali metodi di trasferimento SIP supportate (INVITE, REFER) e cosa richiede ciascuno alla nostra piattaforma?
3. Come passiamo e leggiamo le intestazioni SIP personalizzate in entrambe le direzioni?
4. Dove sono impostati i vostri limiti di concorrenza e di chiamate al secondo, cosa succede alla chiamata quando si raggiunge il limite, e possiamo alzarli per il test?
5. Possiamo vedere la segnalazione SIP e i motivi di disconnessione per ogni chiamata, e il vostro team di telefonia esaminerà le catture con noi?

La documentazione di Retell include guide di configurazione per Genesys Cloud, Five9, Avaya e Amazon Connect, una guida generale alla telefonia personalizzata e una guida alla concorrenza che illustra ciascun limite. Per i trasferimenti in uscita dall'agente, consulta trasferimento di chiamata e come funzionano i passaggi dall'IA agli operatori umani.

Se la tua piattaforma gestisce il controllo delle chiamate e ti serve un agente vocale con IA che si integri a valle, scopri la piattaforma enterprise di IA conversazionale di Retell e parla con il team per pianificare un test di carico sul tuo percorso reale delle chiamate.

Letture correlate: Il test di carico sulla chiusura delle chiamate, il workflow dal CRM all'IA vocale e altre guide nell'hub Retell Learn.