Varför lasttester av röst-AI måste följa den verkliga samtalsvägen

Om din kontaktcenterplattform besvarar varje samtal först och sedan överför uppringare till en AI-röstagent säger ett lasttest som ringer AI:n direkt väldigt lite. Det bevisar att AI:n klarar många samtal. Det bevisar inte att din operatör, din plattform för samtalsstyrning, överföringen till agenten och överföringen tillbaka ut alla håller vid toppbelastning. De flesta fel i den här typen av driftsättning uppstår i skarvarna mellan systemen, och skarvarna bär bara trafik när samtalen följer produktionsvägen.

För den generella metoden (stegvis ökad samtidighet, percentiler för latens, regressionssviter), se vår guide till lasttestning av röstagenter. Den här artikeln täcker driftsättningar där en UCaaS- eller CCaaS-plattform har samtalsstyrningen.

Varför bevisar inte ett direkt SIP- eller API-lasttest att driftsättningen fungerar?

Eftersom det hoppar över varje steg som dina uppringare passerar. Ett direkt test skickar samtal rakt till AI-leverantörens SIP-endpoint eller API. Ett produktionssamtal tar en längre väg: det kommer från operatören, landar på din kontaktcenter- eller UCaaS-plattform, går genom din IVR eller routningslogik, blindöverförs till röst-AI:ns ingångspunkt och avslutas sedan antingen där eller överförs tillbaka till en mänsklig kö.

Varje steg har sin egen kapacitetsgräns, sitt eget SIP-beteende och sin egen konfigurationsägare. Ett direkt test prövar inget av dem. Tre exempel från Retell-dokumentationen:

• Kapacitet ställs in på mer än ett ställe. Samtidighetsgränsen i Retell gäller per arbetsyta (arbetsytor med betala per användning börjar på 20 samtidiga samtal). Five9-guiden från Retell påpekar att Five9 tillämpar sina egna kapacitetsgränser för trunkar, och Avaya-guiden säger att du ska bekräfta att det administrerade antalet SIP-trunkar täcker dina förväntade samtidiga samtal. Ett test som kringgår plattformen når aldrig dess gräns.
• Anslutningsmetoden påverkar vad AI:n kan göra. Retell stöder elastisk SIP-trunking (den rekommenderade metoden) och uppringning av en SIP URI. Med SIP URI-metoden är den inbyggda överföringsfunktionen i Retell inte tillgänglig, så överföringar och avslut måste hanteras av din egen logik. Ett direkt test skulle aldrig visa den luckan.
• Överföringar beror på den andra sidan. Kall överföring i Retell använder SIP INVITE som standard, eller SIP REFER om din telefonileverantör stöder det. Om REFER fungerar, och om anpassade headers överlever det, beror på din leverantör, inte på AI:n.

Hur ser den verkliga samtalsvägen ut när en kontaktcenterplattform har samtalsstyrningen?

Det är en kedja av fem steg, och varje testsamtal ska passera alla fem.

Två detaljer i Retell-dokumentationen spelar roll här. Med SIP URI-metoden behöver varje samtal först en Register Phone Call-förfrågan, och samtalet måste nå den URI:n inom 5 minuter, annars avslutas det med registered_call_timeout, så din registreringstjänst måste också hänga med under last. På utgångssidan påpekar Genesys Cloud-guiden från Retell att samtal som Genesys överför vidare väljer en trunk från Sitens nummerplaner och utgående routes: plattformskonfiguration som ett direkt test aldrig når.

Var dyker fel som bara syns i den verkliga vägen upp vid toppbelastning?

Där två system möts, oftast när ett av dem börjar köa samtal. Bevaka dessa under upptrappningen:

1. Den snävaste kapacitetsgränsen avgör. Om plattformens trunk tillåter färre samtidiga samtal än din AI-arbetsyta fastnar uppringarna i plattformen, medan AI-dashboarden ser frisk ut. Dimensionera operatören, plattformens trunk och AI:ns samtidighetsgräns tillsammans.
2. Inkommande köhantering hos AI:n. När inkommande samtal når samtidighetsgränsen i Retell håller Retell nya samtal i cirka 40 sekunder. Om ingen plats frigörs överförs uppringaren till ett konfigurerat fallback_number, eller så avslutas samtalet med concurrency_limit_reached om inget är angivet. Bestäm i förväg vart fallbacken ska gå (ofta tillbaka till plattformens mänskliga kö) och testa att det fungerar under last.
3. Utgående trafik tränger undan inkommande. Alla röstsamtal i en arbetsyta delar en gemensam samtidighetspool. Om samma arbetsyta också kör utgående kampanjer kan reserverad inkommande samtidighet hålla platser åt överförda samtal.
4. Takt för samtalsuppsättning. Retell sätter samtal per sekund per telefoniväg, och dokumentationen påpekar att CPS för Custom Telephony skalar med din samtidighet. En våg av överföringar vid varje heltimme kan nå en hastighetsgräns innan den når en samtidighetsgräns.
5. Nätverks- och medieinställningar. Retell publicerar flera IP-block att allowlista (vissa gäller bara viss amerikansk trafik), sina transporter (TCP rekommenderas, UDP, TLS, mTLS) och sina codecs (PCMU, PCMA, G.722). En allowlist som bara täcker några av blocken kan klara ett litet test och fallera vid volym.
6. SIP-ändringar mitt i samtalet. Plattformar kan skicka re-INVITE för att uppdatera en session, flytta media eller parkera ett samtal. Retell besvarar re-INVITE inom dialogen för sessionsuppdateringar, omförankring av media, codec-byten, SRTP-omnycklingar samt parkering och återupptagning; bekräfta att plattformens re-INVITE beter sig likadant vid volym.

Hur genererar du testtrafik genom den verkliga vägen?

Initiera testsamtal utanför ditt nätverk och ring samma publika nummer som dina uppringare använder. Det är det enda sättet att få last på varje steg.

• Välj en samtalsgenerator som ringer ditt publika nummer. Batchsamtal i Retell ringer utgående samtal från Retell, och simuleringstestning i Retell kör textbaserade konversationer, så ingen av dem återskapar ett inkommande samtal som din plattform överför in. Vissa testpartner ringer riktiga samtal; Hamming beskriver till exempel hur dess röstagenter ringer dina. Fråga varje testleverantör om dess samtal kommer in via det publika telefonnätet eller ansluter direkt till agenten.
• Märk varje testsamtal. Låt plattformen lägga till en anpassad X--SIP-header (till exempel ett testkörnings-ID) vid överföringen. Retell extraherar inkommande X--headers till samtalets fält custom_sip_headers och till dynamiska variabler, så att du kan koppla varje AI-samtal till plattformens post.
• Trappa upp stegvis. Börja under din förväntade topp, öka förbi den, låt sedan trafiken sjunka och bekräfta att systemet återgår till viloläge.
• Boka alla ägare. Operatör, plattformsadministratör och röst-AI-leverantör ska alla delta. Five9-guiden från Retell kör det slutliga integrationstestet som en gemensam session.
• Höj gränserna före testet, inte under det. Kontrollera AI-samtidigheten och CPS-gränserna på sidan Limits (den inbyggda kalkylatorn föreslår värden utifrån trafiken under den mest belastade timmen) och bekräfta att plattformens trunkkapacitet matchar.

Vilka SIP-signaler ska du bevaka under testet?

Bevaka varje samtals signalering från första INVITE till sista BYE, på båda sidor av överföringen. Samtalsdetaljerna i Retell kan innehålla en Packet Capture-flik med samtalets SIP-signalering, och guiden för PCAP-felsökning går igenom hur du läser den i Wireshark. Om du kör en egen trunk rekommenderar Retell-dokumentationen att du fångar trafik på servern eller gatewayen som terminerar SIP, vilket oftast är din SBC.

Leta efter:

• En ren uppsättning på överföringsbenet: INVITE, 100 Trying, 180 Ringing, 200 OK, ACK.
• Felsvar: 403 (allowlist eller behörighet), 404 (fel SIP URI eller routning), 408 eller 477 (endpoint går inte att nå eller transportfel), 486 (upptagen), 503 (tjänsten otillgänglig).
• Överföringen tillbaka ut: en REFER eller en ny INVITE, beroende på överföringsmetod, och om dina X--headers överlevde. Retell-dokumentationen varnar för att anpassade headers kan tas bort när en överföring går till ett PSTN-nummer i stället för en SIP-endpoint.
• Vem som skickade BYE, och när: varje samtal ska avslutas med en BYE från den part du förväntar dig.

Webhook-händelserna i Retell (call_started, call_ended och transfer_*-händelserna) ger dig en tidslinje per samtal att jämföra med paketfångsterna.

Vad ska räknas som godkänt?

Godkänt betyder att siffrorna stämmer överens i alla system, inte bara att AI:n höll sig uppe. Använd den här checklistan:

• Antalet samtal stämmer mellan operatörens poster, plattformens rapporter och AI:ns samtalslogg för testfönstret.
• Varje AI-samtal avslutades med en förväntad orsak till frånkoppling (user_hangup, agent_hangup, call_transfer), och det fanns inga concurrency_limit_reached- eller error_*-orsaker.
• Varje överföring tillbaka till en människa nådde rätt kö, med förväntad nummerpresentation och förväntade headers.
• Inga SIP 4xx- eller 5xx-svar på överföringsbenen, utöver dem du utlöste med flit.
• Ljud flödade i båda riktningarna i stickprovssamtal.
• Toppsamtidigheten låg under varje gräns i kedjan, med marginal.
• När trafiken upphörde återgick samtidigheten till noll på AI-sidan och plattformen visade inga kvardröjande sessioner.

Den sista kontrollen förtjänar en egen testplan, eftersom samtal som aldrig stängs helt efter en överföring kan äta upp samtidighet vid toppbelastning. Vi går igenom samtalsavslut i en separat guide.

Vad ska du fråga din röst-AI-leverantör före testet?

Ställ frågor som får leverantören att visa vägen, inte bara AI:n:

1. Vilken anslutningsmetod rekommenderar ni för vår plattform, och vad ändrar den när det gäller överföringar och avslut?
2. Vilka SIP-överföringsmetoder stöder ni (INVITE, REFER), och vad kräver var och en av vår plattform?
3. Hur skickar och läser vi anpassade SIP-headers i båda riktningarna?
4. Var ställs era gränser för samtidighet och samtal per sekund in, vad händer med samtalet vid gränsen, och kan vi höja dem inför testet?
5. Kan vi se SIP-signalering och orsaker till frånkoppling per samtal, och kommer ert telefoniteam att granska paketfångster tillsammans med oss?

Retell-dokumentationen innehåller installationsguider för Genesys Cloud, Five9, Avaya och Amazon Connect, en allmän guide för anpassad telefoni och en guide för samtidighet som täcker varje gräns. För överföringar från agenten, se samtalsöverföring och hur överlämningar från AI till människa fungerar.

Om din plattform äger samtalsstyrningen och du behöver en AI-röstagent som passar bakom den, se plattformen för konversations-AI för företag från Retell och prata med teamet om att planera ett lasttest på din verkliga samtalsväg.

Relaterad läsning: Lasttestet för samtalsavslut, arbetsflödet från CRM till röst-AI och fler guider i Retell Learn-hubben.