Waarom loadtests voor voice-AI het echte gesprekspad moeten volgen

Als je contactcenterplatform elk gesprek eerst aanneemt en bellers daarna doorverbindt naar een AI-stemagent, zegt een loadtest die de AI rechtstreeks belt je weinig. Die bewijst dat de AI veel gesprekken aankan. Hij bewijst niet dat je carrier, je call-control-platform, de doorverbinding naar de agent en de doorverbinding terug allemaal standhouden bij piekvolume. De meeste storingen in dit soort implementaties ontstaan op de koppelvlakken tussen systemen, en die koppelvlakken krijgen alleen verkeer als gesprekken de productieroute volgen.

Voor de algemene methode (concurrency stapsgewijs opvoeren, latency-percentielen, regressiesuites) zie je onze gids over loadtests voor stemagents. Dit artikel gaat over implementaties waarbij een UCaaS- of CCaaS-platform de call control in handen heeft.

Waarom bewijst een directe SIP- of API-loadtest niet dat de implementatie werkt?

Omdat die elke hop overslaat die je bellers passeren. Een directe test stuurt gesprekken rechtstreeks naar het SIP-endpoint of de API van de AI-provider. Een productiegesprek legt een langere route af: het komt binnen via de carrier, belandt op je contactcenter- of UCaaS-platform, doorloopt je IVR of routeringslogica, wordt blind doorverbonden naar het instappunt van de voice-AI en eindigt daar of wordt teruggezet naar een menselijke wachtrij.

Elke hop heeft een eigen capaciteitslimiet, eigen SIP-gedrag en een eigen configuratie-eigenaar. Een directe test raakt er geen enkele. Drie voorbeelden uit de documentatie van Retell:

• Capaciteit wordt op meer dan één plek ingesteld. De concurrencylimiet van Retell geldt per workspace (Pay-As-You-Go-workspaces beginnen bij 20 gelijktijdige gesprekken). De Five9-gids van Retell vermeldt dat Five9 eigen limieten voor trunkcapaciteit hanteert, en de Avaya-gids zegt dat je moet controleren of het geconfigureerde aantal SIP-trunks je verwachte gelijktijdige gesprekken dekt. Een test die het platform omzeilt, raakt die limiet nooit.
• De verbindingsmethode bepaalt wat de AI kan. Retell ondersteunt elastic SIP trunking (de aanbevolen methode) en het bellen van een SIP URI. Bij de SIP URI-methode is de ingebouwde doorverbindingsfunctie van Retell niet beschikbaar, dus moeten doorverbindingen en ophangen door je eigen logica worden afgehandeld. Een directe test zou dat gat nooit laten zien.
• Doorverbindingen hangen af van de andere kant. De koude doorverbinding van Retell gebruikt standaard SIP INVITE, of SIP REFER als je telefonieprovider dat ondersteunt. Of REFER werkt, en of custom headers het overleven, hangt af van je provider, niet van de AI.

Hoe ziet het echte gesprekspad eruit als een contactcenterplatform de call control heeft?

Het is een keten van vijf hops, en elk testgesprek moet alle vijf doorlopen.

Twee details uit de documentatie van Retell zijn hier belangrijk. Bij de SIP URI-methode heeft elk gesprek eerst een Register Phone Call-request nodig, en moet het gesprek die URI binnen 5 minuten bereiken, anders eindigt het met registered_call_timeout. Je registratieservice moet dus ook onder belasting bijblijven. Aan de uitgangskant vermeldt de Genesys Cloud-gids van Retell dat gesprekken die Genesys verder doorverbindt een trunk kiezen uit de nummerplannen en uitgaande routes van de Site: platformconfiguratie die een directe test nooit bereikt.

Waar duiken storingen die alleen in het pad optreden op bij piekvolume?

Waar twee systemen samenkomen, meestal zodra een van beide gesprekken in de wachtrij begint te zetten. Let hierop tijdens het opvoeren:

1. De krapste capaciteitslimiet wint. Als de trunk van je platform minder gelijktijdige gesprekken toestaat dan je AI-workspace, blijven bellers hangen in het platform, terwijl het AI-dashboard er gezond uitziet. Dimensioneer de carrier, de platformtrunk en de concurrencylimiet van de AI samen.
2. Inkomende wachtrij bij de AI. Wanneer inkomende gesprekken de concurrencylimiet van Retell bereiken, houdt Retell nieuwe gesprekken ongeveer 40 seconden vast. Komt er geen slot vrij, dan verbindt Retell de beller door naar een ingesteld fallback_number, of beëindigt het het gesprek met concurrency_limit_reached als er geen is ingesteld. Bepaal vooraf waar die fallback naartoe moet (vaak terug naar de menselijke wachtrij van je platform) en test of dat onder belasting werkt.
3. Uitgaand verkeer dat inkomend verkeer verdringt. Alle telefoongesprekken in een workspace delen één concurrencypool. Als dezelfde workspace ook uitgaande campagnes draait, kan gereserveerde inkomende concurrency slots vrijhouden voor doorverbonden gesprekken.
4. Snelheid van gespreksopbouw. Retell stelt het aantal gesprekken per seconde per telefoniepad in, en de documentatie vermeldt dat de CPS van Custom Telephony meeschaalt met je concurrency. Een piek aan doorverbindingen op het hele uur kan een snelheidslimiet raken voordat hij een concurrencylimiet raakt.
5. Netwerk- en media-instellingen. Retell publiceert verschillende IP-blokken voor je allowlist (sommige gelden alleen voor bepaald Amerikaans verkeer), de transports (TCP aanbevolen, UDP, TLS, mTLS) en de codecs (PCMU, PCMA, G.722). Een allowlist die maar een deel van die blokken dekt, kan een kleine test doorstaan en bij volume falen.
6. SIP-wijzigingen tijdens het gesprek. Platforms kunnen re-INVITEs sturen om een sessie te verversen, media te verplaatsen of een gesprek in de wacht te zetten. Retell beantwoordt in-dialog re-INVITEs voor sessieverversingen, media re-anchoring, codecwijzigingen, SRTP-re-keys en in de wacht zetten of hervatten; controleer of de re-INVITEs van je platform zich bij volume net zo gedragen.

Hoe genereer je testverkeer via het echte pad?

Start testgesprekken buiten je netwerk en bel dezelfde openbare nummers die je bellers gebruiken. Alleen zo krijgt elke hop belasting.

• Kies een gespreksgenerator die je openbare nummer belt. Met batchgesprekken plaatst Retell uitgaande gesprekken vanuit Retell, en de simulatietests van Retell voeren tekstgebaseerde gesprekken, dus geen van beide bootst een inkomend gesprek na dat je platform doorverbindt. Sommige testpartners voeren echte gesprekken; Hamming beschrijft bijvoorbeeld hoe zijn stemagents de jouwe bellen. Vraag elke testleverancier of de gesprekken binnenkomen via het openbare telefoonnetwerk of rechtstreeks met de agent verbinden.
• Tag elk testgesprek. Laat je platform bij de doorverbinding een custom X--SIP-header toevoegen (bijvoorbeeld een testrun-ID). Retell haalt inkomende X--headers op in het veld custom_sip_headers van het gesprek en in dynamische variabelen, zodat je elk AI-gesprek kunt koppelen aan het record van het platform.
• Voer stapsgewijs op. Begin onder je verwachte piek, ga er stap voor stap overheen, laat het verkeer daarna dalen en controleer of het systeem terugkeert naar inactief.
• Plan elke eigenaar in. Carrier, platformbeheerder en voice-AI-leverancier moeten allemaal aansluiten. De Five9-gids van Retell voert de laatste integratietest uit als gezamenlijke sessie.
• Verhoog limieten vóór de test, niet tijdens. Controleer je AI-concurrency- en CPS-limieten op de Limits-pagina (de ingebouwde calculator stelt waarden voor op basis van je verkeer in het drukste uur) en controleer of de trunkcapaciteit van het platform overeenkomt.

Op welke SIP-signalen let je tijdens de test?

Volg de signalering van elk gesprek van de eerste INVITE tot de laatste BYE, aan beide kanten van de doorverbinding. De gespreksdetails van Retell kunnen een tabblad Packet Capture bevatten met de SIP-signalering van het gesprek, en de PCAP-debuggids legt uit hoe je die in Wireshark leest. Als je een eigen trunk draait, raadt de documentatie van Retell aan om te capturen op de server of gateway die SIP termineert, meestal je SBC.

Let op:

• Een schone opbouw op het doorverbindingsdeel: INVITE, 100 Trying, 180 Ringing, 200 OK, ACK.
• Foutresponses: 403 (allowlist of toestemming), 404 (verkeerde SIP URI of routering), 408 of 477 (onbereikbaar endpoint of transportfout), 486 (bezet), 503 (dienst niet beschikbaar).
• De doorverbinding terug: een REFER of een nieuwe INVITE, afhankelijk van de doorverbindingsmethode, en of je X--headers het hebben overleefd. De documentatie van Retell waarschuwt dat custom headers kunnen worden verwijderd wanneer een doorverbinding naar een PSTN-nummer gaat in plaats van naar een SIP-endpoint.
• Wie de BYE stuurde, en wanneer: elk gesprek moet eindigen met een BYE van de partij die je verwacht.

De webhook-events van Retell (call_started, call_ended en de transfer_*-events) geven je per gesprek een tijdlijn om naast de captures te leggen.

Wat telt als geslaagd?

Geslaagd betekent dat de cijfers in alle systemen met elkaar kloppen, niet alleen dat de AI in de lucht bleef. Gebruik deze checklist:

• Het aantal gesprekken komt overeen tussen carrierrecords, platformrapporten en het AI-gesprekslog voor de testperiode.
• Elk AI-gesprek eindigde met een verwachte reden voor verbreking (user_hangup, agent_hangup, call_transfer), en er waren geen redenen als concurrency_limit_reached of error_*.
• Elke doorverbinding terug naar een mens bereikte de juiste wachtrij, met de verwachte nummerweergave en headers.
• Geen SIP 4xx- of 5xx-responses op de doorverbindingsdelen, behalve die je bewust hebt veroorzaakt.
• Audio liep in beide richtingen bij steekproefgesprekken.
• Piekconcurrency bleef onder elke limiet in de keten, met marge.
• Nadat het verkeer stopte, keerde de concurrency aan AI-zijde terug naar nul en toonde het platform geen achtergebleven sessies.

Die laatste controle verdient een eigen testplan, omdat gesprekken die na een doorverbinding nooit volledig worden afgesloten bij piekbelasting concurrency kunnen opslokken. We behandelen het afsluiten van gesprekken in een aparte gids.

Wat vraag je je voice-AI-leverancier vóór de test?

Stel vragen waarmee de leverancier het pad laat zien, niet alleen de AI:

1. Welke verbindingsmethode raden jullie aan voor ons platform, en wat verandert die aan doorverbindingen en ophangen?
2. Welke SIP-doorverbindingsmethoden ondersteunen jullie (INVITE, REFER), en wat vereist elk daarvan van ons platform?
3. Hoe geven we custom SIP-headers in beide richtingen door en hoe lezen we ze uit?
4. Waar zijn jullie limieten voor concurrency en gesprekken per seconde ingesteld, wat gebeurt er met het gesprek bij de limiet, en kunnen we ze voor de test verhogen?
5. Kunnen we per gesprek de SIP-signalering en redenen voor verbreking zien, en wil jullie telefonieteam de captures met ons doornemen?

De documentatie van Retell bevat installatiegidsen voor Genesys Cloud, Five9, Avaya en Amazon Connect, een algemene gids voor custom telephony en een concurrencygids die elke limiet behandelt. Voor doorverbindingen vanuit de agent, zie gespreksoverdracht en hoe overdrachten van AI naar mens werken.

Als je platform de call control heeft en je een AI-stemagent nodig hebt die daarachter past, bekijk dan het enterprise-platform voor conversationele AI van Retell en bespreek met het team hoe je een loadtest op je echte gesprekspad plant.

Verder lezen: De loadtest voor het afsluiten van gesprekken, de workflow van CRM naar voice-AI en meer gidsen in de Retell Learn-hub.