Warum Lasttests für Sprach-KI dem realen Anrufpfad folgen müssen

Wenn Ihre Contact-Center-Plattform jeden Anruf zuerst annimmt und Anrufende dann an einen KI-Sprachagenten weiterleitet, sagt Ihnen ein Lasttest, der die KI direkt anwählt, sehr wenig. Er beweist, dass die KI viele Anrufe annehmen kann. Er beweist nicht, dass Ihr Carrier, Ihre Plattform für die Anrufsteuerung, die Weiterleitung zum Agenten und die Weiterleitung zurück bei Spitzenlast standhalten. Die meisten Fehler in solchen Bereitstellungen entstehen an den Schnittstellen zwischen Systemen, und diese Schnittstellen führen nur dann Traffic, wenn Anrufe der Produktionsroute folgen.

Die allgemeine Methodik (schrittweise Erhöhung der Concurrency, Latenz-Perzentile, Regressionssuiten) finden Sie in unserem Leitfaden zu Lasttests für Sprachagenten. Dieser Artikel behandelt Bereitstellungen, bei denen eine UCaaS- oder CCaaS-Plattform die Anrufsteuerung innehat.

Warum beweist ein direkter SIP- oder API-Lasttest nicht, dass die Bereitstellung funktioniert?

Weil er jeden Hop überspringt, den Ihre Anrufenden durchlaufen. Ein direkter Test sendet Anrufe direkt an den SIP-Endpoint oder die API des KI-Anbieters. Ein Produktionsanruf nimmt einen längeren Weg: Er kommt vom Carrier, landet auf Ihrer Contact-Center- oder UCaaS-Plattform, durchläuft Ihr IVR oder Ihre Routing-Logik, wird blind an den Einstiegspunkt der Sprach-KI weitergeleitet und endet dann entweder dort oder wird zurück an eine Warteschlange mit menschlichen Mitarbeitenden weitergeleitet.

Jeder Hop hat sein eigenes Kapazitätslimit, sein eigenes SIP-Verhalten und eine eigene Stelle, die für die Konfiguration verantwortlich ist. Ein direkter Test prüft keinen davon. Drei Beispiele aus der Dokumentation von Retell:

• Die Kapazität wird an mehr als einer Stelle festgelegt. Das Concurrency-Limit von Retell gilt pro Workspace (Workspaces mit nutzungsbasierter Abrechnung starten mit 20 gleichzeitigen Anrufen). Der Five9-Leitfaden von Retell weist darauf hin, dass Five9 eigene Trunk-Kapazitätslimits anwendet, und der Avaya-Leitfaden empfiehlt zu prüfen, ob die administrierte Anzahl an SIP-Trunks Ihre erwarteten gleichzeitigen Anrufe abdeckt. Ein Test, der die Plattform umgeht, erreicht deren Limit nie.
• Die Verbindungsmethode verändert, was die KI kann. Retell unterstützt Elastic SIP Trunking (die empfohlene Methode) und das Anwählen einer SIP-URI. Bei der SIP-URI-Methode ist die integrierte Weiterleitungsfunktion von Retell nicht verfügbar, sodass Weiterleitungen und Auflegen über Ihre eigene Logik abgewickelt werden müssen. Ein direkter Test würde diese Lücke nie zeigen.
• Weiterleitungen hängen von der Gegenseite ab. Die unbetreute Weiterleitung (Cold Transfer) von Retell nutzt standardmäßig SIP INVITE oder SIP REFER, sofern Ihr Telefonieanbieter dies unterstützt. Ob REFER funktioniert und ob benutzerdefinierte Header dabei erhalten bleiben, hängt von Ihrem Anbieter ab, nicht von der KI.

Wie sieht der reale Anrufpfad aus, wenn eine Contact-Center-Plattform die Anrufsteuerung innehat?

Es ist eine Kette aus fünf Hops, und jeder Testanruf sollte alle fünf durchlaufen.

Zwei Details aus der Dokumentation von Retell sind hier wichtig. Bei der SIP-URI-Methode benötigt jeder Anruf zuerst eine Register-Phone-Call-Anfrage, und der Anruf muss diese URI innerhalb von 5 Minuten erreichen, sonst endet er mit registered_call_timeout. Ihr Registrierungsdienst muss also ebenfalls unter Last mithalten. Auf der Ausstiegsseite weist der Genesys-Cloud-Leitfaden von Retell darauf hin, dass Anrufe, die Genesys weiterleitet, einen Trunk aus den Number Plans und Outbound Routes der Site wählen: Plattformkonfiguration, die ein direkter Test nie erreicht.

Wo zeigen sich pfadspezifische Fehler bei Spitzenlast?

Dort, wo zwei Systeme aufeinandertreffen, meist sobald eines davon Anrufe in die Warteschlange stellt. Achten Sie während der Laststeigerung auf Folgendes:

1. Das engste Kapazitätslimit gewinnt. Wenn der Trunk Ihrer Plattform weniger gleichzeitige Anrufe zulässt als Ihr KI-Workspace, bleiben Anrufende in der Plattform hängen, während das KI-Dashboard unauffällig aussieht. Dimensionieren Sie Carrier, Plattform-Trunk und Concurrency-Limit der KI gemeinsam.
2. Warteschlange für eingehende Anrufe bei der KI. Wenn eingehende Anrufe das Concurrency-Limit von Retell erreichen, hält Retell neue Anrufe etwa 40 Sekunden lang. Wird kein Slot frei, leitet Retell den Anruf an eine konfigurierte fallback_number weiter oder beendet ihn mit concurrency_limit_reached, falls keine festgelegt ist. Legen Sie im Voraus fest, wohin dieser Fallback führen soll (oft zurück in die Warteschlange mit menschlichen Mitarbeitenden auf Ihrer Plattform), und testen Sie, ob er unter Last funktioniert.
3. Ausgehender Traffic verdrängt eingehenden. Alle Sprachanrufe in einem Workspace teilen sich einen Concurrency-Pool. Wenn derselbe Workspace auch ausgehende Kampagnen ausführt, kann reservierte Concurrency für eingehende Anrufe Slots für hereingeleitete Anrufe freihalten.
4. Rate des Verbindungsaufbaus. Retell legt die Anrufe pro Sekunde (CPS) pro Telefoniepfad fest, und laut Dokumentation skaliert die CPS bei Custom Telephony mit Ihrer Concurrency. Eine Häufung von Weiterleitungen zur vollen Stunde kann ein Ratenlimit erreichen, bevor sie ein Concurrency-Limit erreicht.
5. Netzwerk- und Medieneinstellungen. Retell veröffentlicht mehrere IP-Blöcke für die Allowlist (einige gelten nur für bestimmten US-Traffic), die unterstützten Transportprotokolle (TCP empfohlen, UDP, TLS, mTLS) und Codecs (PCMU, PCMA, G.722). Eine Allowlist, die nur einen Teil dieser Blöcke abdeckt, kann einen kleinen Test bestehen und bei hohem Volumen scheitern.
6. SIP-Änderungen während des Anrufs. Plattformen können re-INVITEs senden, um eine Session zu aktualisieren, Medien zu verlagern oder einen Anruf zu halten. Retell beantwortet In-Dialog-re-INVITEs für Session-Refreshes, Media-Re-Anchoring, Codec-Wechsel, SRTP-Re-Keys sowie Halten und Fortsetzen; prüfen Sie, ob sich die re-INVITEs Ihrer Plattform bei hohem Volumen genauso verhalten.

Wie erzeugen Sie Testtraffic über den realen Pfad?

Starten Sie Testanrufe außerhalb Ihres Netzwerks und wählen Sie dieselben öffentlichen Nummern, die auch Ihre Anrufenden nutzen. Nur so trägt jeder Hop Last.

• Wählen Sie einen Anrufgenerator, der Ihre öffentliche Nummer anwählt. Die Batch-Anrufe von Retell tätigen ausgehende Anrufe aus Retell heraus, und die Simulationstests von Retell führen textbasierte Gespräche, sodass keines von beiden einen eingehenden Anruf nachbildet, den Ihre Plattform weiterleitet. Einige Testpartner tätigen echte Anrufe; Hamming beschreibt beispielsweise, dass seine Sprachagenten Ihre Agenten anrufen. Fragen Sie jeden Testanbieter, ob seine Anrufe über das öffentliche Telefonnetz eingehen oder sich direkt mit dem Agenten verbinden.
• Kennzeichnen Sie jeden Testanruf. Lassen Sie Ihre Plattform bei der Weiterleitung einen benutzerdefinierten X--SIP-Header hinzufügen (zum Beispiel eine Testlauf-ID). Retell extrahiert eingehende X--Header in das Feld custom_sip_headers des Anrufs und in dynamische Variablen, sodass Sie jeden KI-Anruf dem Datensatz der Plattform zuordnen können.
• Steigern Sie die Last schrittweise. Beginnen Sie unterhalb Ihrer erwarteten Spitzenlast, steigern Sie darüber hinaus, lassen Sie den Traffic dann abfallen und prüfen Sie, ob das System in den Ruhezustand zurückkehrt.
• Binden Sie alle Verantwortlichen ein. Carrier, Plattform-Admin und Anbieter der Sprach-KI sollten alle teilnehmen. Der Five9-Leitfaden von Retell sieht den abschließenden Integrationstest als gemeinsame Session vor.
• Erhöhen Sie Limits vor dem Test, nicht währenddessen. Prüfen Sie Ihre Concurrency- und CPS-Limits der KI auf der Limits-Seite (der integrierte Rechner schlägt Werte auf Basis Ihres Traffics zur Hauptverkehrszeit vor) und stellen Sie sicher, dass die Trunk-Kapazität der Plattform dazu passt.

Auf welche SIP-Signale sollten Sie während des Tests achten?

Verfolgen Sie die Signalisierung jedes Anrufs vom ersten INVITE bis zum abschließenden BYE, auf beiden Seiten der Weiterleitung. Die Anrufdetails von Retell können einen Tab „Packet Capture“ mit der SIP-Signalisierung des Anrufs enthalten, und der PCAP-Debugging-Leitfaden erklärt, wie Sie diese in Wireshark auswerten. Wenn Sie Ihren eigenen Trunk betreiben, empfiehlt die Dokumentation von Retell, auf dem Server oder Gateway mitzuschneiden, der SIP terminiert – in der Regel Ihr SBC.

Achten Sie auf:

• Einen sauberen Verbindungsaufbau auf dem Weiterleitungs-Leg: INVITE, 100 Trying, 180 Ringing, 200 OK, ACK.
• Fehlerantworten: 403 (Allowlist oder Berechtigung), 404 (falsche SIP-URI oder falsches Routing), 408 oder 477 (nicht erreichbarer Endpoint oder Transportfehler), 486 (besetzt), 503 (Dienst nicht verfügbar).
• Die Weiterleitung zurück: ein REFER oder ein neues INVITE, je nach Weiterleitungsmethode, und ob Ihre X--Header erhalten geblieben sind. Die Dokumentation von Retell warnt, dass benutzerdefinierte Header entfernt werden können, wenn eine Weiterleitung an eine PSTN-Nummer statt an einen SIP-Endpoint geht.
• Wer das BYE gesendet hat und wann: Jeder Anruf sollte mit einem BYE der erwarteten Partei enden.

Die Webhook-Events von Retell (call_started, call_ended und die transfer_*-Events) liefern Ihnen pro Anruf eine Zeitleiste, die Sie mit den Mitschnitten abgleichen können.

Was sollte als bestanden gelten?

Bestanden heißt, dass die Zahlen über alle Systeme hinweg übereinstimmen – nicht nur, dass die KI verfügbar blieb. Nutzen Sie diese Checkliste:

• Die Anrufzahlen stimmen für das Testfenster zwischen Carrier-Protokollen, Plattformberichten und dem KI-Anrufprotokoll überein.
• Jeder KI-Anruf endete mit einem erwarteten Grund für den Verbindungsabbruch (user_hangup, agent_hangup, call_transfer), und es traten keine Gründe wie concurrency_limit_reached oder error_* auf.
• Jede Weiterleitung zurück an einen Menschen erreichte die richtige Warteschlange, mit der erwarteten Anrufer-ID und den erwarteten Headern.
• Keine SIP-Antworten 4xx oder 5xx auf den Weiterleitungs-Legs, außer solchen, die Sie absichtlich ausgelöst haben.
• Bei Stichprobenanrufen floss Audio in beide Richtungen.
• Die maximale Concurrency blieb unter jedem Limit der Kette, mit ausreichend Spielraum.
• Nachdem der Traffic gestoppt war, fiel die Concurrency auf KI-Seite auf null, und die Plattform zeigte keine verbleibenden Sessions.

Diese letzte Prüfung verdient einen eigenen Testplan, da Anrufe, die nach einer Weiterleitung nie vollständig geschlossen werden, bei Spitzenlast Concurrency verbrauchen können. Das Thema Anrufabschluss behandeln wir in einem separaten Leitfaden.

Was sollten Sie Ihren Anbieter für Sprach-KI vor dem Test fragen?

Stellen Sie Fragen, bei denen der Anbieter den Pfad zeigen muss, nicht nur die KI:

1. Welche Verbindungsmethode empfehlen Sie für unsere Plattform, und was ändert sie an Weiterleitungen und am Auflegen?
2. Welche SIP-Weiterleitungsmethoden unterstützen Sie (INVITE, REFER), und was erfordert jede davon von unserer Plattform?
3. Wie übergeben und lesen wir benutzerdefinierte SIP-Header in beide Richtungen?
4. Wo werden Ihre Concurrency-Limits und Limits für Anrufe pro Sekunde festgelegt, was passiert mit dem Anruf beim Erreichen des Limits, und können wir sie für den Test erhöhen?
5. Können wir die SIP-Signalisierung und die Gründe für Verbindungsabbrüche pro Anruf einsehen, und prüft Ihr Telefonie-Team die Mitschnitte gemeinsam mit uns?

Die Dokumentation von Retell enthält Einrichtungsleitfäden für Genesys Cloud, Five9, Avaya und Amazon Connect, einen allgemeinen Leitfaden zu Custom Telephony und einen Concurrency-Leitfaden, der jedes Limit behandelt. Informationen zu Weiterleitungen aus dem Agenten finden Sie unter Anrufweiterleitung und So funktionieren Übergaben von KI an Menschen.

Wenn Ihre Plattform die Anrufsteuerung innehat und Sie einen KI-Sprachagenten benötigen, der sich dahinter einfügt, sehen Sie sich die Enterprise-Plattform für konversationelle KI von Retell an und sprechen Sie mit dem Team über die Planung eines Lasttests auf Ihrem realen Anrufpfad.

Weiterführende Artikel: Der Lasttest zum Anrufabschluss, der Workflow vom CRM zur Sprach-KI und weitere Leitfäden im Retell Learn Hub.