Hvorfor belastningstest af stemme-AI skal følge den reelle opkaldsvej

Hvis din kontaktcenterplatform besvarer alle opkald først og derefter viderestiller kalderne til en AI-stemmeagent, fortæller en belastningstest, der ringer direkte til AI'en, dig meget lidt. Den beviser, at AI'en kan håndtere mange opkald. Den beviser ikke, at din teleudbyder, din opkaldsstyringsplatform, viderestillingen til agenten og viderestillingen ud igen alle holder ved spidsbelastning. De fleste fejl i denne type implementering opstår i samlingerne mellem systemerne, og samlingerne bærer kun trafik, når opkaldene følger produktionsruten.

For den generelle metode (gradvis optrapning af samtidighed, latens-percentiler, regressionstestsuiter) kan du se vores guide til belastningstest af stemmeagenter. Denne artikel dækker implementeringer, hvor en UCaaS- eller CCaaS-platform har opkaldsstyringen.

Hvorfor beviser en direkte SIP- eller API-belastningstest ikke, at implementeringen virker?

Fordi den springer alle de led over, som dine kaldere passerer igennem. En direkte test sender opkald direkte til AI-udbyderens SIP-endpoint eller API. Et produktionsopkald tager en længere rute: Det kommer ind fra teleudbyderen, lander på din kontaktcenter- eller UCaaS-platform, kører gennem din IVR eller routinglogik, bliver blindt viderestillet til stemme-AI'ens indgangspunkt og ender så enten der eller bliver viderestillet tilbage til en menneskelig kø.

Hvert led har sin egen kapacitetsgrænse, SIP-adfærd og konfigurationsansvarlige. En direkte test afprøver ingen af dem. Tre eksempler fra Retell-dokumentationen:

• Kapacitet indstilles mere end ét sted. Samtidighedsgrænsen hos Retell gælder pr. workspace (workspaces på betal efter forbrug-planen starter med 20 samtidige opkald). Five9-guiden fra Retell bemærker, at Five9 anvender sine egne grænser for trunk-kapacitet, og Avaya-guiden siger, at du skal bekræfte, at det administrerede antal SIP-trunks dækker dine forventede samtidige opkald. En test, der går uden om platformen, rører aldrig dens grænse.
• Forbindelsesmetoden ændrer, hvad AI'en kan. Retell understøtter elastic SIP trunking (den anbefalede metode) og opkald til en SIP URI. Med SIP URI-metoden er den indbyggede funktion til viderestilling af opkald i Retell ikke tilgængelig, så viderestillinger og afbrydelser skal håndteres af din egen logik. En direkte test ville aldrig vise det hul.
• Viderestillinger afhænger af den anden side. Uassisteret viderestilling hos Retell bruger som standard SIP INVITE eller SIP REFER, hvis din telefoniudbyder understøtter det. Om REFER virker, og om brugerdefinerede headers overlever det, afhænger af din udbyder, ikke af AI'en.

Hvordan ser den reelle opkaldsvej ud, når en kontaktcenterplatform har opkaldsstyringen?

Den er en kæde af fem led, og hvert testopkald bør passere gennem alle fem.

To detaljer fra Retell-dokumentationen er vigtige her. Med SIP URI-metoden kræver hvert opkald først en Register Phone Call-anmodning, og opkaldet skal nå den URI inden for 5 minutter, ellers afsluttes det med registered_call_timeout, så din registreringstjeneste skal også kunne følge med under belastning. På udgangssiden bemærker Genesys Cloud-guiden fra Retell, at opkald, som Genesys viderestiller videre, vælger en trunk ud fra Sitets nummerplaner og udgående ruter: platformskonfiguration, som en direkte test aldrig når.

Hvor viser fejl, der kun opstår på opkaldsvejen, sig ved spidsbelastning?

Der, hvor to systemer mødes – som regel når et af dem begynder at sætte opkald i kø. Hold øje med disse under optrapningen:

1. Den strammeste kapacitetsgrænse vinder. Hvis din platforms trunk tillader færre samtidige opkald end dit AI-workspace, går kalderne i stå i platformen, mens AI-dashboardet ser sundt ud. Dimensionér teleudbyderen, platformens trunk og AI-samtidighedsgrænsen samlet.
2. Indgående kø hos AI'en. Når indgående opkald rammer samtidighedsgrænsen hos Retell, holder Retell nye opkald i cirka 40 sekunder. Hvis ingen plads bliver ledig, viderestiller den kalderen til et konfigureret fallback_number eller afslutter opkaldet med concurrency_limit_reached, hvis der ikke er angivet et. Beslut på forhånd, hvor fallback skal gå hen (ofte tilbage til din platforms menneskelige kø), og test, at det virker under belastning.
3. Udgående trafik, der fortrænger indgående. Alle stemmeopkald i et workspace deler én samtidighedspulje. Hvis det samme workspace også kører udgående kampagner, kan reserveret indgående samtidighed holde pladser fri til viderestillede opkald.
4. Hastighed for opkaldsopsætning. Retell fastsætter opkald pr. sekund pr. telefonivej, og dokumentationen bemærker, at CPS for Custom Telephony skalerer med din samtidighed. En bølge af viderestillinger ved hvert hele klokkeslæt kan ramme en hastighedsgrænse, før den rammer en samtidighedsgrænse.
5. Netværks- og medieindstillinger. Retell offentliggør flere IP-blokke, der skal allowlistes (nogle gælder kun for bestemt amerikansk trafik), sine transportprotokoller (TCP anbefales, UDP, TLS, mTLS) og sine codecs (PCMU, PCMA, G.722). En allowlist, der kun dækker nogle af blokkene, kan bestå en lille test og fejle ved høj volumen.
6. SIP-ændringer midt i opkaldet. Platforme kan sende re-INVITEs for at forny en session, flytte medier eller sætte et opkald på hold. Retell besvarer in-dialog re-INVITEs ved sessionsfornyelser, re-anchoring af medier, codec-ændringer, SRTP-genforhandling af nøgler og hold eller genoptagelse; bekræft, at din platforms re-INVITEs opfører sig på samme måde ved høj volumen.

Hvordan genererer du testtrafik gennem den reelle opkaldsvej?

Start testopkald uden for dit netværk, og ring til de samme offentlige numre, som dine kaldere bruger. Det er den eneste måde, hvorpå hvert led bærer belastning.

• Vælg en opkaldsgenerator, der ringer til dit offentlige nummer. Retell-funktionen batchopkald foretager udgående opkald fra Retell, og simuleringstest i Retell kører tekstbaserede samtaler, så ingen af dem genskaber et indgående opkald, som din platform viderestiller ind. Nogle testpartnere foretager rigtige opkald; Hamming beskriver for eksempel, at deres stemmeagenter ringer til dine. Spørg enhver testleverandør, om deres opkald kommer ind via det offentlige telefonnet eller forbinder direkte til agenten.
• Mærk hvert testopkald. Lad din platform tilføje en brugerdefineret X--SIP-header (for eksempel et testkørsels-ID) ved viderestillingen. Retell udtrækker indgående X--headers til opkaldets custom_sip_headers-felt og til dynamiske variabler, så du kan koble hvert AI-opkald til platformens registrering.
• Trap op i trin. Start under din forventede spidsbelastning, gå trinvis op forbi den, lad derefter trafikken falde, og bekræft, at systemet vender tilbage til hviletilstand.
• Book alle ansvarlige. Teleudbyder, platformsadministrator og stemme-AI-leverandør bør alle deltage. Five9-guiden fra Retell gennemfører den endelige integrationstest som en fælles session.
• Hæv grænserne før testen, ikke under den. Tjek dine AI-samtidigheds- og CPS-grænser på siden Limits (den indbyggede beregner foreslår værdier ud fra din trafik i den travleste time), og bekræft, at platformens trunk-kapacitet matcher.

Hvilke SIP-signaler skal du holde øje med under testen?

Følg hvert opkalds signalering fra første INVITE til sidste BYE på begge sider af viderestillingen. Opkaldsdetaljerne i Retell kan indeholde en Packet Capture-fane med opkaldets SIP-signalering, og PCAP-fejlfindingsguiden fra Retell gennemgår, hvordan du læser den i Wireshark. Hvis du kører din egen trunk, anbefaler Retell-dokumentationen at optage på den server eller gateway, der terminerer SIP, hvilket som regel er din SBC.

Kig efter:

• En ren opsætning på viderestillingsbenet: INVITE, 100 Trying, 180 Ringing, 200 OK, ACK.
• Fejlsvar: 403 (allowlist eller tilladelse), 404 (forkert SIP URI eller routing), 408 eller 477 (endpoint kan ikke nås eller transportfejl), 486 (optaget), 503 (tjenesten er utilgængelig).
• Viderestillingen tilbage ud: en REFER eller en ny INVITE afhængigt af viderestillingsmetoden, og om dine X--headers overlevede. Retell-dokumentationen advarer om, at brugerdefinerede headers kan blive fjernet, når en viderestilling går til et PSTN-nummer i stedet for et SIP-endpoint.
• Hvem sendte BYE, og hvornår: Hvert opkald bør slutte med en BYE fra den part, du forventer.

Webhook-hændelserne i Retell (call_started, call_ended og transfer_*-hændelserne) giver dig en tidslinje pr. opkald, som du kan holde op mod optagelserne.

Hvad skal tælle som bestået?

Bestået betyder, at tallene stemmer overens på tværs af alle systemer – ikke kun, at AI'en holdt sig oppe. Brug denne tjekliste:

• Antallet af opkald stemmer overens på tværs af teleudbyderens registreringer, platformens rapporter og AI-opkaldsloggen for testperioden.
• Hvert AI-opkald sluttede med en forventet afbrydelsesårsag (user_hangup, agent_hangup, call_transfer), og der var ingen concurrency_limit_reached- eller error_*-årsager.
• Hver viderestilling tilbage til et menneske nåede den rigtige kø med den forventede nummervisning og de forventede headers.
• Ingen SIP 4xx- eller 5xx-svar på viderestillingsbenene ud over dem, du udløste med vilje.
• Lyden gik begge veje i stikprøveopkaldene.
• Den maksimale samtidighed holdt sig under alle grænser i kæden, med god margin.
• Efter at trafikken stoppede, vendte samtidigheden tilbage til nul på AI-siden, og platformen viste ingen hængende sessioner.

Det sidste tjek fortjener sin egen testplan, da opkald, der aldrig lukkes helt efter en viderestilling, kan æde samtidighed ved spidsbelastning. Vi dækker lukning af opkald i en separat guide.

Hvad skal du spørge din stemme-AI-leverandør om før testen?

Stil spørgsmål, der får leverandøren til at vise opkaldsvejen, ikke kun AI'en:

1. Hvilken forbindelsesmetode anbefaler I til vores platform, og hvad ændrer den ved viderestillinger og afbrydelser?
2. Hvilke SIP-viderestillingsmetoder understøtter I (INVITE, REFER), og hvad kræver hver af dem af vores platform?
3. Hvordan sender og læser vi brugerdefinerede SIP-headers i begge retninger?
4. Hvor er jeres grænser for samtidighed og opkald pr. sekund sat, hvad sker der med opkaldet ved grænsen, og kan vi få dem hævet til testen?
5. Kan vi se SIP-signalering og afbrydelsesårsager pr. opkald, og vil jeres telefoniteam gennemgå optagelser sammen med os?

Retell-dokumentationen indeholder opsætningsguides til Genesys Cloud, Five9, Avaya og Amazon Connect, en generel guide til brugerdefineret telefoni og en guide til samtidighed, der dækker hver grænse. For viderestillinger ud af agenten kan du se viderestilling af opkald og hvordan overdragelser fra AI til menneske fungerer.

Hvis din platform ejer opkaldsstyringen, og du har brug for en AI-stemmeagent, der passer bag den, så se enterprise-platformen til konversationel AI fra Retell, og tal med teamet om at planlægge en belastningstest på din reelle opkaldsvej.

Relateret læsning: Belastningstesten for lukning af opkald, workflowet fra CRM til stemme-AI og flere guides i Retell Learn-hubben.