De voice-AI-loadtest die de meeste teams vergeten: gespreksafsluiting

De meeste loadtests voor voice-AI beantwoorden één vraag: komen gesprekken bij piekvolume tot stand? Een tweede vraag is net zo belangrijk: wordt een gesprek dat voorbij is ook echt beëindigd?

Een gesprek dat nooit wordt afgesloten, houdt een concurrency-slot op het voice-AI-platform bezet, een kanaal op je SIP-trunk en vaak een poort of seat op je contactcenterplatform. Er praat niemand op. Bij piekbelasting kunnen een paar dozijn van zulke gesprekken je tegen je limieten aan duwen, terwijl het gespreksvolume er normaal uitziet.

Deze gids behandelt de afsluitingskant van loadtesten. Voor latency, nauwkeurigheid en doorvoer onder belasting lees je onze gids over loadtesten van stemagents.

Wat betekent "gespreksafsluiting" bij een voice-AI-gesprek?

Een gesprek is afgesloten wanneer elke leg ervan is vrijgegeven door elk systeem dat het heeft doorlopen: de leg van de beller, eventuele doorverbindingslegs en de sessie van de AI-agent.

Bij een SIP-gesprek is afsluiting een signaleringsgebeurtenis. De ene kant stuurt een BYE-bericht, de andere kant antwoordt met 200 OK en elk systeem geeft het kanaal vrij. Een leg die is overgegaan maar nooit is beantwoord, wordt opgeruimd met een CANCEL.

Bij een voice-AI-implementatie moeten drie dingen kloppen:

• Beide legs hangen op. Als de beller of de andere kant ophangt, wordt de andere leg ook afgebroken in plaats van open te blijven met stilte.
• Doorverbindingen worden afgerond. Een doorverbinding komt tot stand of mislukt netjes, en in beide gevallen valt de AI-leg weg.
• Alle systemen zijn het eens. De carrier, je session border controller (SBC) of contactcenterplatform en het voice-AI-platform tonen het gesprek allemaal als beëindigd.

In Retell heeft een afgerond gesprek de status ended en een reden voor verbreking zoals user_hangup, agent_hangup of call_transfer. Een gesprek dat nog bezig is, heeft de status ongoing, en juist lopende gesprekken tellen mee voor je huidige concurrency.

Waarom blijven gesprekken open na een doorverbinding?

Een doorverbinding maakt van één gesprek twee of meer legs, vaak verspreid over twee platforms, en als er op één leg wordt opgehangen, moet dat signaal de andere legs bereiken. Gaat dat signaal verloren of wordt het genegeerd, dan blijft een leg actief zonder dat er iemand op zit.

Patronen om in je setup te controleren:

• Blinde doorverbinding naar de AI. Veel contactcenters houden de gespreksbesturing op hun bestaande platform en verbinden bellers blind door naar het nummer van de AI-agent. Als de beller ophangt en dat ophangsignaal niet over de doorverbinding heen wordt doorgegeven, blijft de AI-leg actief. Als de AI het gesprek beëindigt en je platform zijn kant niet vrijgeeft, blijft die poort bezet.
• Koude doorverbinding vanuit de AI. De AI-agent valt weg zodra hij het gesprek heeft overgedragen. Retell ondersteunt twee SIP-methoden: SIP INVITE overbrugt de doorverbinding, terwijl SIP REFER de andere kant van het gesprek, meestal je carrier of trunk, vraagt een apart gesprek naar de bestemming op te zetten. REFER werkt alleen als je provider dat toestaat.
• Warme en agentische warme doorverbinding. De agent belt de bestemming terwijl de beller in de wacht staat, dus er zijn tegelijk twee actieve legs. Als de bestemming nooit opneemt, moet de poging een time-out krijgen en beide kanten opruimen.
• Je eigen doorverbindingslogica. Als het voice-AI-platform het nummer niet beheert (bijvoorbeeld bij de dial-to-SIP-methode van Retell), lopen doorverbinden en gesprek beëindigen via je eigen custom functions, en is afsluiting dus de taak van je code.

Voor de belervaring bij elk type lees je hoe gespreksoverdracht werkt tussen AI-stemagents en menselijke teams en onze gids over warme doorverbinding.

Wat kost een open gesprek je bij piekbelasting?

Eén concurrency-slot, zolang het openstaat. Concurrency telt het aantal gelijktijdig actieve gesprekken, en een leeg gesprek telt even zwaar als een echt gesprek.

De rekensom is eenvoudig: extra open gesprekken op elk moment = gesprekken per uur die niet worden afgesloten × aantal uren dat elk ervan openblijft.

De derde rij laat zien hoe teams bij piekbelasting met tientallen spookgesprekken eindigen: één configuratieprobleem, zoals ophangsignalen die niet over een doorverbinding worden doorgegeven, dat bij elk doorverbonden gesprek optreedt.

Die capaciteit is niet gratis. Bij Retell zijn de eerste 20 gelijktijdige gesprekken inbegrepen en kost extra capaciteit $8 per gelijktijdig gesprek per maand (zie prijzen). Wanneer een workspace zijn limiet bereikt, wachten nieuwe inkomende gesprekken ongeveer 40 seconden op een vrij slot. Daarna gaan ze naar het fallbacknummer van het telefoonnummer als dat is ingesteld, of eindigen ze met concurrency_limit_reached. Nieuwe uitgaande gesprekken worden geweigerd, tenzij concurrency burst is ingeschakeld. Bij piekbelasting zorgen vastgelopen gesprekken er dus voor dat echte bellers worden afgewezen.

Dezelfde rekensom geldt voor trunkkanalen en contactcenterlicenties, die het voice-AI-platform niet kan zien.

Hoe test je gespreksafsluiting tijdens een loadtest?

Beëindig elk gesprek bewust, via elk mogelijk eindpad, op je piekniveau, en toon vervolgens aan dat het aantal actieve gesprekken in elk systeem terugkeert naar nul.

Voer een afsluitingsmatrix uit

Transfer-webhooks staan standaard uit. Voeg voor de test transfer_started, transfer_bridged, transfer_cancelled en transfer_ended toe aan de webhook-events van de agent.

Voer een drain-test uit

Stop na de piekopbouw met het plaatsen van nieuwe gesprekken en kijk hoe de tellers dalen. Poll om de paar seconden de Get Concurrency API van Retell, die current_concurrency (het aantal lopende gesprekken) retourneert. Die waarde moet binnen de duur van je langste gescripte gesprek op nul uitkomen. Controleer op dezelfde momenten de tellingen van je SBC, contactcenter en trunk. Elke teller die hoog blijft, wijst op het lek, en het systeem waarin dat gebeurt, vertelt je welke kant niet vrijgeeft.

Vergelijk en inspecteer

• Elke call_started-webhook moet een bijbehorende call_ended hebben. Elke transfer_started moet een transfer_ended of transfer_cancelled hebben.
• Gebruik na de drain de List Calls API met een call_status-filter op ongoing om achterblijvers te vinden.
• Open een achterblijver in Call History en bekijk, waar beschikbaar, het tabblad Packet Capture. Kijk in de SIP-ladder welke partij BYE of CANCEL stuurde en of de andere kant antwoordde.

Wat moet je monitoren na de livegang?

Let op concurrency die hoog blijft wanneer het volume daalt, op meer gesprekken die door time-outs worden afgesloten en op mislukte doorverbindingen.

• Concurrency versus volume. Alertregels in Retell kunnen concurrency_used (piek van gelijktijdige gesprekken in een tijdvenster) naast call_count (gesprekken die in het venster zijn beëindigd) monitoren. Als de concurrency stijgt terwijl het aantal beëindigde gesprekken gelijk blijft, worden gesprekken niet afgesloten.
• Mislukte doorverbindingen. Stel een alert in op transfer_call_failure_count.
• Beëindiging door time-outs. Filter in Call History op reden voor verbreking. Een groeiend aandeel inactivity of max_duration_reached na doorverbindingen betekent dat de vangnetten je gesprekken afsluiten, en niet het ophangen.
• Langlopende gesprekken. Live Monitoring toont elk lopend gesprek met een live meelopende duur. Een gesprek dat veel langer loopt dan je langste echte gesprek, is verdacht. Je kunt het beëindigen vanuit Live Monitoring of met de Stop Call API.
• Tellingen over systemen heen. Het aantal actieve gesprekken op het AI-platform, de trunk en het contactcenter moet gelijk op- en neergaan.

Welke instellingen beperken de schade als een gesprek niet wordt afgesloten?

Time-outs. Ze lossen kapotte signalering niet op, maar ze begrenzen hoe lang een vastgelopen gesprek een slot bezet kan houden.

Stem de stilte- en duurlimieten af op je werkelijke gespreksduur. Met de standaardinstellingen kan een dode leg die stil blijft 10 minuten een slot bezet houden, en een leg die de stiltetimer niet opvangt zelfs tot een uur.

Wat moet je aan je leverancier en telefonieteam vragen?

Vraag vóór de lancering om schriftelijke antwoorden:

1. Welk systeem stuurt de BYE naar de AI-leg wanneer de beller ophangt bij een blind doorverbonden gesprek, en is dat bij piekbelasting getest?
2. Geeft je contactcenterplatform de poort direct vrij wanneer de AI een gesprek beëindigt?
3. Telt het gesprek, nadat een doorverbinding tot stand is gekomen en de AI-agent is weggevallen, nog mee voor de concurrency van het voice-AI-platform totdat beide partijen ophangen?
4. Staat je SIP-trunk SIP REFER toe, en zo niet, welke doorverbindingsmethode moet je dan gebruiken?
5. Kun je packet captures van testgesprekken krijgen van elke hop: carrier, SBC, contactcenter en voice-AI-platform?

Maak afsluiting onderdeel van de release-gate

Behandel "concurrency keert na de test terug naar nul" als criterium voor geslaagd of gezakt. Voer de afsluitingsmatrix en de drain-test uit vóór de lancering en opnieuw na elke wijziging in doorverbindingsinstellingen, nummers of gespreksroutering.

Retell geeft je alle bouwstenen: koude, warme en agentische warme gespreksoverdracht met time-outs voor overgaan en wachten, transfer-webhooks, redenen voor verbreking per gesprek, packet captures, een live concurrency-API en alerts op concurrency en mislukte doorverbindingen. Plan je een uitrol in een contactcenter met een hoge piekconcurrency, dan biedt het Retell Enterprise-abonnement een hoge limiet op gelijktijdige gesprekken en toegewijde support.

Meer lezen: Waarom loadtests het echte gesprekspad moeten volgen, de checklist voor uitgaande telefoonnummers en meer gidsen in de Retell Learn-hub.