Den belastningstest af stemme-AI, som de fleste teams glemmer: opkaldsafslutning

De fleste belastningstests af stemme-AI besvarer ét spørgsmål: Bliver opkaldene forbundet ved spidsbelastning? Et andet spørgsmål er lige så vigtigt: Når et opkald er slut, afsluttes det så rent faktisk?

Et opkald, der aldrig lukkes, bliver ved med at optage en plads til samtidige opkald på stemme-AI-platformen, en kanal på din SIP-trunk og ofte en port eller licens på din kontaktcenterplatform. Ingen taler i det. Ved spidsbelastning kan nogle få dusin af disse opkald presse dig op mod dine grænser, mens opkaldsvolumen ser normal ud.

Denne guide handler om afslutningsdelen af belastningstest. Læs om latens, nøjagtighed og kapacitet under belastning i vores guide til belastningstest af stemmeagenter.

Hvad betyder "opkaldsafslutning" for et stemme-AI-opkald?

Et opkald er afsluttet, når hvert eneste ben af det er frigivet af alle de systemer, det har passeret: den opkaldendes ben, eventuelle viderestillingsben og AI-agentens session.

I et SIP-opkald er afslutningen en signaleringshændelse. Den ene side sender en BYE-besked, den anden side svarer 200 OK, og hvert system frigiver kanalen. Et ben, der ringede, men aldrig blev besvaret, ryddes med en CANCEL.

For en implementering af stemme-AI skal tre ting være opfyldt:

• Begge ben lægger på. Når den opkaldende eller den anden ende afbryder, bliver det andet ben også nedlagt i stedet for at blive stående åbent med stilhed.
• Viderestillinger gennemføres. En viderestilling bliver enten forbundet eller fejler rent, og AI-benet afbrydes i begge tilfælde.
• Alle systemer er enige. Operatøren, din session border controller (SBC) eller kontaktcenterplatform og stemme-AI-platformen viser alle opkaldet som afsluttet.

I Retell har et afsluttet opkald status ended og en afbrydelsesårsag som user_hangup, agent_hangup eller call_transfer. Et opkald, der stadig er i gang, har status ongoing, og det er de igangværende opkald, der tæller med i dine aktuelle samtidige opkald.

Hvorfor efterlader viderestillinger opkald åbne?

En viderestilling gør ét opkald til to eller flere ben, ofte på tværs af to platforme, og når der lægges på i ét ben, skal det signal nå de andre. Når signalet går tabt eller ignoreres, bliver et ben stående uden nogen i det.

Mønstre, du bør tjekke i dit setup:

• Blind viderestilling til AI'en. Mange kontaktcentre bevarer opkaldskontrollen på deres eksisterende platform og viderestiller de opkaldende blindt til AI-agentens nummer. Hvis den opkaldende lægger på, og signalet ikke føres videre på tværs af viderestillingen, kører AI-benet videre. Hvis AI'en afslutter opkaldet, og din platform ikke frigiver sin side, forbliver porten optaget.
• Uassisteret viderestilling fra AI'en. AI-agenten afbryder, så snart den har overdraget opkaldet. Retell understøtter to SIP-metoder: SIP INVITE kobler viderestillingen sammen, mens SIP REFER beder den anden ende af opkaldet, typisk din operatør eller trunk, om at starte et separat opkald til destinationen. REFER virker kun, hvis din udbyder tillader det.
• Assisteret og agentisk assisteret viderestilling. Agenten ringer op til destinationen, mens den opkaldende venter på hold, så der findes to aktive ben på samme tid. Hvis destinationen aldrig svarer, skal forsøget time out og rydde op på begge sider.
• Din egen viderestillingslogik. Når stemme-AI-platformen ikke styrer nummeret (f.eks. Retells dial-to-SIP-metode), kører viderestilling og afslutning af opkald gennem dine egne tilpassede funktioner, så afslutningen er din kodes ansvar.

Læs om oplevelsen for den opkaldende ved hver type i sådan fungerer viderestilling af opkald mellem AI-stemmeagenter og menneskelige teams og vores guide til assisteret viderestilling.

Hvad koster et åbent opkald dig ved spidsbelastning?

Én plads til samtidige opkald, så længe det står åbent. Samtidighed tæller aktive opkald på samme tid, og et tomt opkald tæller lige så meget som et rigtigt.

Regnestykket er enkelt: ekstra åbne opkald på et givent tidspunkt = opkald i timen, der ikke afsluttes × antal timer, hvert opkald står åbent.

Den tredje række viser, hvordan teams ender med dusinvis af spøgelsesopkald ved spidsbelastning: ét konfigurationsproblem, f.eks. at pålægninger ikke videresendes på tværs af en viderestilling, som rammer alle viderestillede opkald.

Den kapacitet er ikke gratis. Hos Retell er de første 20 samtidige opkald inkluderet, og ekstra kapacitet koster $8 pr. samtidigt opkald pr. måned (se priser). Når et workspace når sin grænse, venter nye indgående opkald ca. 40 sekunder på en ledig plads og går derefter til telefonnummerets fallback-nummer, hvis der er angivet et, eller afsluttes med concurrency_limit_reached. Nye udgående opkald afvises, medmindre concurrency burst er slået til. Ved spidsbelastning betyder hængende opkald, at rigtige opkaldende bliver afvist.

Det samme regnestykke gælder for trunkkanaler og kontaktcenterlicenser, som stemme-AI-platformen ikke kan se.

Hvordan tester du opkaldsafslutning under en belastningstest?

Afslut hvert opkald bevidst, via hver eneste afslutningsvej, ved din spidsbelastningsrate, og bevis derefter, at antallet af aktive opkald i hvert system vender tilbage til nul.

Kør en afslutningsmatrix

Webhooks for viderestilling er slået fra som standard. Tilføj transfer_started, transfer_bridged, transfer_cancelled og transfer_ended til agentens webhook-hændelser i forbindelse med testen.

Kør en tømningstest

Efter optrapningen til spidsbelastning stopper du med at foretage nye opkald og holder øje med, at tællerne falder. Spørg Retells Get Concurrency API, som returnerer current_concurrency (antallet af igangværende opkald), med få sekunders mellemrum. Tallet bør nå nul inden for længden af dit længste scriptede opkald. Tjek tællerne i din SBC, dit kontaktcenter og din trunk på de samme tidspunkter. Enhver tæller, der forbliver høj, er lækagen, og det system, der holder på den, fortæller dig, hvilken side der ikke frigiver.

Afstem og undersøg

• Hver call_started-webhook bør have en tilsvarende call_ended. Hver transfer_started bør have en transfer_ended eller transfer_cancelled.
• Efter tømningen bruger du List Calls API med et call_status-filter på ongoing for at finde efternølere.
• Åbn en efternøler i Call History, og tjek dens Packet Capture-fane, hvor den er tilgængelig. Se i SIP-diagrammet, hvilken part der sendte BYE eller CANCEL, og om den anden side svarede.

Hvad skal du overvåge efter go-live?

Hold øje med samtidighed, der forbliver høj, når volumen falder, flere opkald, der lukkes af timeouts, og fejl i viderestillinger.

• Samtidighed sammenholdt med volumen. Retells alarmregler kan overvåge concurrency_used (højeste antal samtidige opkald i et tidsvindue) sammen med call_count (opkald, der blev afsluttet i tidsvinduet). Hvis samtidigheden stiger, mens antallet af afsluttede opkald er uændret, bliver opkaldene ikke afsluttet.
• Fejl i viderestillinger. Opret en alarm på transfer_call_failure_count.
• Afslutninger via timeout. Filtrer efter afbrydelsesårsag i Call History. En voksende andel af inactivity eller max_duration_reached efter viderestillinger betyder, at det er sikkerhedsnettene og ikke pålægningerne, der lukker dine opkald.
• Langvarige opkald. Live Monitoring viser alle igangværende opkald med en varighed, der tæller i realtid. Et opkald, der er langt ældre end din længste rigtige samtale, er en mulig kandidat. Du kan afslutte det fra Live Monitoring eller med Stop Call API.
• Tællinger på tværs af systemer. Antallet af aktive opkald i AI-platformen, trunken og kontaktcentret bør følges ad.

Hvilke indstillinger begrænser skaden, når et opkald ikke lukkes?

Timeouts. De løser ikke fejlbehæftet signalering, men de sætter et loft over, hvor længe et hængende opkald kan optage en plads.

Sæt grænserne for stilhed og varighed tæt på dine reelle opkaldslængder. Med standardindstillingerne kan et dødt ben, der forbliver tavst, optage en plads i 10 minutter, og et ben, som stilhedstimeren ikke fanger, kan optage den i op til en time.

Hvad skal du spørge din leverandør og dit telefoniteam om?

Få skriftlige svar inden lancering:

1. Når den opkaldende lægger på i et blindt viderestillet opkald, hvilket system sender så BYE til AI-benet, og er det blevet testet ved spidsbelastning?
2. Når AI'en afslutter et opkald, frigiver din kontaktcenterplatform så porten med det samme?
3. Når en viderestilling er forbundet, og AI-agenten har afbrudt, tæller opkaldet så stadig med i stemme-AI-platformens samtidige opkald, indtil begge parter lægger på?
4. Tillader din SIP-trunk SIP REFER, og hvis ikke, hvilken viderestillingsmetode bør du så bruge?
5. Kan du få packet captures af testopkald fra hvert led: operatør, SBC, kontaktcenter og stemme-AI-platform?

Gør afslutning til en del af release-kriterierne

Behandl "samtidigheden vender tilbage til nul efter testen" som et bestået/ikke bestået-kriterium. Kør afslutningsmatrixen og tømningstesten før lancering og igen efter enhver ændring af viderestillingsindstillinger, numre eller opkaldsrouting.

Retell giver dig byggestenene: uassisteret, assisteret og agentisk assisteret viderestilling af opkald med timeouts for ringetid og ventetid, webhooks for viderestilling, afbrydelsesårsager pr. opkald, packet captures, et API til samtidighed i realtid og alarmer for samtidighed og fejl i viderestillinger. Hvis du planlægger en kontaktcenterudrulning med mange samtidige opkald ved spidsbelastning, giver Retell Enterprise-planen et højt loft over samtidige opkald og dedikeret support.

Læs også: Hvorfor belastningstests skal følge den reelle opkaldsvej, tjeklisten til telefonnumre for udgående opkald og flere guides i Retell Learn-hubben.