Warum Retell ein eigenes SIP- und WebRTC-Gateway gebaut hat

Bevor Retell ein eigenes Gateway gebaut hat, verband ein führender Anbieter Telefon- und Browser-Anrufe mit den KI-Agenten von Retell. Die Plattform des Anbieters hatte wiederholt Störungen, und der Anbieter brauchte im Schnitt etwa 50 bis 60 Minuten, um jede einzelne zu beheben. Wir hatten keine Möglichkeit, eine Störung schneller zu beheben. Manche eingehenden Anrufe erreichten Retell nie, sodass unsere Systeme keinerlei Aufzeichnung davon hatten. Von den fehlenden Anrufen erfuhren wir über Kundensupport-Tickets.

Wir wollten die Kontrolle über die Qualität und Verfügbarkeit jedes einzelnen Anrufs, also haben wir unser eigenes SIP- und WebRTC-Gateway gebaut. Seit Oktober 2026 läuft 100% der Telefon- und Browser-Anrufe von Retell über das Gateway.

Das Gateway von Retell ist das System, das Telefonnetze und Webbrowser mit den KI-Sprachagenten von Retell verbindet. Es spricht SIP (Session Initiation Protocol), den Standard, mit dem Telefonsysteme Anrufe aufbauen und beenden, sowie WebRTC (Web Real-Time Communication), den Standard, den Browser für Live-Audio nutzen.

Das Gateway baut jeden Anruf auf, überträgt das Audio und mischt es für alle Gesprächsteilnehmer und übernimmt Anrufweiterleitungen, Live-Mithören (ein Supervisor hört den Anruf in Echtzeit mit), Übernahmen (ein Supervisor oder menschlicher Mitarbeiter springt während des Anrufs für den KI-Agenten ein) sowie das Auflegen.

Um diese Änderungen umzusetzen, haben wir den Anbieter in drei Schritten ersetzt.

Die wichtigsten Ergebnisse:

• Die Infrastruktur-Latenz ist um etwa 90% niedriger – von 50 ms auf 0,5 ms.
• Jeder Telefonanruf erreicht zuerst Retell, auch Anrufe, die fehlschlagen.
• Anruffunktionen werden nach dem eigenen Release-Zeitplan von Retell ausgeliefert.

Was zwischen einem Anrufer und einem KI-Agenten liegt

Demos von Sprach-KI zeigen meist nur den letzten Schritt in einem komplexen System: das Modell, das zuhört und antwortet. Ein KI-Telefonagent im Produktivbetrieb braucht jedoch weit mehr. Vor dem Modell liegen in der Regel mehrere Schichten. Sie entscheiden, ob ein Anruf zustande kommt, wie schnell das Audio übertragen wird und was passiert, wenn etwas ausfällt.

Ein Anruf an einen Retell-Agenten durchläuft die folgenden vier Schichten:

1. Das PSTN (Public Switched Telephone Network) ist das globale Telefonnetz. Browser-Anrufe kommen von einer Website oder Web-App.
2. Ein Session Border Controller (SBC) ist der sichere Eingangspunkt für Telefonanrufe. Er nimmt Anrufe von außen entgegen und entscheidet, wohin jeder einzelne geht. Browser-Anrufe umgehen den SBC und verbinden sich direkt mit dem Gateway.
3. Die Media-Schicht. Sie baut jeden Anruf auf, überträgt das Audio in beide Richtungen, mischt es für alle Gesprächsteilnehmer und steuert Anruffunktionen wie Weiterleitungen und Auflegen. Telefonanrufe erreichen sie über SIP, Browser-Anrufe über WebRTC. Bei Retell ist das Gateway die Media-Schicht.
4. Die KI-Infrastruktur von Retell. Sie führt das Gespräch mit dem Anrufer.

Vor dem Gateway übernahm der Anbieter die Schichten 2 und 3. Retell betrieb dazwischen eine Software-Komponente, den sogenannten Audio-Relay. Das Audio lief zwischen dem Anbieter und dem Relay über das öffentliche Internet – ein Hop von etwa 50 ms –, und der Relay leitete es anschließend an die KI-Infrastruktur von Retell weiter.

Warum die Plattform des Anbieters nicht ausreichte

Die Plattform des Anbieters lag im Pfad jedes einzelnen Anrufs, sodass ihre Störungen direkt bei den Kunden von Retell ankamen.

Der Anbieter brauchte im Schnitt etwa 50 bis 60 Minuten, um sich von einer Störung zu erholen. Bei manchen Störungen gelangten eingehende Anrufe nie vom Anbieter zu Retell. Die fehlenden Anrufe hinterließen weder einen Anrufdatensatz noch ein Event in unseren Systemen – wir hatten also keine Möglichkeit, den Ausfall selbst zu erkennen.

Die Abhängigkeit vom Anbieter verursachte weitere Probleme:

• Kundenanforderungen hingen davon ab, was der Anbieter unterstützte – alles, was nicht unterstützt wurde, konnten wir nicht ausliefern.
• Sicherheits- und Compliance-Anforderungen ließen sich über die Plattform des Anbieters nur schwer erfüllen.
• Der Hop über das öffentliche Internet erhöhte die Latenz jedes Anrufs.
• Die Rechnung des Anbieters belief sich auf Millionen Dollar pro Jahr.

Wir haben auch andere Anbieter geprüft. Die Evaluierungen bestätigten, was wir bereits vermutet hatten: Um die Produktqualität zu kontrollieren, mussten wir ein eigenes Gateway bauen.

Wie wir den Anbieter in drei Schritten ersetzt haben

Mit jedem Schritt wurde ein Teil des Anrufpfads auf die Infrastruktur von Retell verlagert.

Session Border Controller von Retell vor den Anbieter schalten

Wir haben eigene SBCs bereitgestellt und die gesamte SIP-Signalisierung auf sie umgeleitet. Kunden schickten ihre Telefonanrufe an die Adresse von Retell statt an die des Anbieters. Außerdem nahmen sie die IP-Adressen von Retell in ihre Allowlists auf – die Listen der Adressen, von denen ihre Telefonsysteme Anrufe annehmen. Anfangs leiteten die SBCs jeden Anruf an den Anbieter weiter.

Mit eigenen SBCs hatten wir die Kontrolle über das Routing. Jeder Telefonanruf erreichte nun zuerst die Infrastruktur von Retell, wo wir ihn sehen konnten – unabhängig davon, ob er zustande kam.

Eine Zeit lang nahmen Anrufe einen längeren Weg. Zwischen den SBCs von Retell und der KI-Infrastruktur von Retell verließ jeder Anruf unser Netzwerk in Richtung Anbieter und kam wieder zurück. Dabei durchquerte er zweimal das öffentliche Internet. Browser-Anrufe gingen weiterhin direkt an den Anbieter.

Telefonanrufe schrittweise auf das Gateway verlagern, von 1% auf 100%

Als Nächstes haben wir das Gateway gebaut und hinter den SBCs innerhalb des Netzwerks von Retell bereitgestellt. Sobald das Gateway live war, konnte jeder Telefonanruf einen von zwei Pfaden nehmen: über den Anbieter oder über das Gateway.

Bei eingehenden Anrufen wählten die SBCs den Pfad, bei ausgehenden Anrufen die KI-Infrastruktur von Retell. Den Anteil der Telefonanrufe über das Gateway haben wir stufenweise erhöht: 1%, 5%, 10%, 20%, 30%, 50%, dann 100%. Auf dem Gateway-Pfad dauert der Hop zwischen den SBCs und dem Gateway etwa 0,5 ms, weil beide im Netzwerk von Retell liegen.

Browser-Anrufe mit dem WebRTC SDK von Retell auf das Gateway verlagern

Browser-Anrufe waren die letzten Anrufe, die noch über den Anbieter liefen. Wir haben unser eigenes WebRTC SDK (Software Development Kit) entwickelt – den Code, mit dem eine Website oder Web-App Browser-Anrufe tätigt – und Browser-Anrufe über das Gateway geleitet.

Nach der Verlagerung der Browser-Anrufe haben wir den Anbieter und den Audio-Relay abgeschaltet. Ein Anruf bleibt nun vom Moment seines Eingangs bis zur KI-Infrastruktur von Retell im Netzwerk von Retell.

Warum die Migration schwierig war

Die Aufgabe bestand darin, die Kontrolle zu übernehmen, ohne ein Verhalten zu ändern, auf das sich Kunden verließen. Die eigentliche Herausforderung: den Anbieter während laufender Anrufe zu ersetzen, ohne dass Kunden etwas davon merkten. Eingehende und ausgehende Anrufe, Weiterleitungen, Browser-Anrufe und Anruffunktionen mussten während der gesamten Migration wie gewohnt funktionieren.

Dafür mussten vier Dinge erhalten bleiben:

• Protokollverhalten (wie das Gateway SIP mit den Systemen am anderen Ende eines Anrufs spricht): Carrier und die Telefonsysteme der Kunden mussten das erwartete Verhalten erhalten.
• Audio-Timing (wann das Audio auf jeder Seite des Anrufs ankommt): Das Audio musste in beide Richtungen ohne neue Lücken oder Verzögerungen übertragen werden.
• Teilnehmerberechtigungen (wer in einem Anruf zuhören, sprechen oder eine Übernahme starten darf): Ein Supervisor, der live mithört, musste dieselben Rechte behalten.
• Semantik des Anruf-Lebenszyklus (wie ein Anruf beginnt, sich verändert und endet): Jeder Anruf musste auf dieselbe Weise beginnen, weitergeleitet werden und enden und dieselben Events an die Systeme von Retell senden.

Dank des schrittweisen Rollouts konnten wir jedes Verhalten an einem kleinen Anteil echter Telefonanrufe testen. Den Anteil haben wir erst erhöht, wenn sich das Verhalten bewährt hatte.

Die wichtigste Erkenntnis für uns: Eine Gateway-Migration wie diese setzt die Kontrolle über das Routing, eine starke Observability und Tests voraus, die den gesamten Anruf-Lebenszyklus abdecken. Observability bedeutet, in Echtzeit sehen zu können, was bei jedem Anruf passiert.

Der Anrufpfad von Retell heute: SBCs, Gateway und WebRTC SDK

Unser neuer Anrufpfad besteht aus drei Teilen.

Die SBCs von Retell bilden die Schnittstelle nach außen. Sie empfangen SIP-Signalisierung von Carriern und den Telefonsystemen der Kunden und routen dann jeden Anruf.

Das Gateway übernimmt die Aufgaben, die früher der Anbieter erledigt hat. Es baut Anrufe auf, überträgt und mischt Audio und steuert Anruffunktionen. Mit der KI-Infrastruktur von Retell kommuniziert es über HTTP und WebSocket, zwei Standardverfahren, mit denen Server Anfragen austauschen und Daten streamen.

Mit dem WebRTC SDK von Retell können Websites und Web-Apps Browser-Anrufe direkt an das Gateway senden.

Sicherheits- und Compliance-Kontrollen sind fester Bestandteil des Designs. Dazu gehören authentifizierter Zugriff, Teilnehmerberechtigungen, der Umgang mit sensiblem Audio und das Schwärzen sensibler Informationen.

Was sich durch das eigene Gateway verändert hat

Wenn wir den Anrufpfad selbst betreiben, sind wir für jeden Aspekt der Anrufqualität verantwortlich.

Wir müssen nicht mehr darauf warten, dass ein Anbieter Anruffunktionen entwickelt. Ein Versicherungskunde benötigte für eine seiner Kampagnen benutzerdefinierte SIP-Header in SIP-BYE-Nachrichten. SIP-Header sind Felder, die zusätzliche Informationen zusammen mit einem Anruf übertragen. Eine BYE-Nachricht ist das Signal, das einen Anruf beendet. Der Anbieter unterstützte damals keine benutzerdefinierten Header in BYE-Nachrichten, also haben wir die Funktion im Gateway gebaut. Da wir den Code und den Release-Prozess kontrollieren, liefern wir nach unserem eigenen Release-Zeitplan aus.

Die Sicherheitsanforderungen eines Kunden (HIPAA, SOC 2 usw.) können wir jetzt selbst erfüllen. Außerdem kann Retell das Gateway in neuen Cloud-Regionen bereitstellen, wenn Kunden das benötigen.

Wann ein Eigenbau die falsche Entscheidung ist

Ein eigenes Gateway ist das falsche Projekt für ein Team, dem die technischen Kapazitäten für den Betrieb von Echtzeit-Kommunikationsinfrastruktur fehlen oder dessen Produktanforderungen den Aufwand nicht rechtfertigen.

Auch nach dem Launch geht unsere Arbeit weiter. Der Betrieb eines Gateways erfordert ein qualifiziertes Team sowie laufende Investitionen in:

• Telefonie-Interoperabilität
• Netzwerktechnik
• Medienverarbeitung
• Sicherheit
• Monitoring
• Rufbereitschaft

Telefonie-Interoperabilität bedeutet, das Gateway mit den vielen Carriern und Telefonsystemen kompatibel zu halten, mit denen es verbunden ist.

Ein eigenes Gateway bedeutet auch, selbst für Incident Response, Kapazitätsplanung, Wartung und sichere Deployments verantwortlich zu sein. Retell hat diese Investition getätigt, weil Anrufqualität, Verfügbarkeit, Anpassbarkeit und schnelle Verbesserungen im Mittelpunkt unseres Produkts stehen.

Tipps für Teams mit demselben Vorhaben

Wenn sich Ihr Team entscheidet, ein eigenes Gateway zu bauen, hat sich bei uns Folgendes bewährt:

1. Übernehmen Sie zuerst die Kontrolle über Ihren SIP-Eingangspunkt, damit Sie das Routing steuern und jeden Telefonanruf sehen können, bevor Sie die Media-Schicht ersetzen.
2. Migrieren Sie Telefonanrufe schrittweise, indem Sie Ihr Gateway hinter Ihren SBCs aufbauen.
3. Behandeln Sie Browser-Anrufe als vollständige Integration, die SDK, Authentifizierung, Verbindungsaufbau und Audio-Transport umfasst.
4. Integrieren Sie Sicherheits- und Compliance-Kontrollen von Anfang an, so wie wir es beim Retell-Gateway getan haben.
5. Messen Sie Latenz, Audioqualität und Ausfallverhalten während der gesamten Migration – einschließlich Anrufen, die fehlschlagen, bevor sie Ihre Anwendung erreichen.

Verbinden Sie Ihr Telefonsystem mit Retell

Wenn Telefonie-Anforderungen den Rollout Ihrer Sprach-KI bisher ausgebremst haben, beginnen Sie mit unserem Leitfaden zur benutzerdefinierten Telefonie. Er zeigt, wie Sie Ihr Telefonsystem über einen SIP-Trunk (eine direkte SIP-Verbindung zwischen zwei Telefonsystemen) mit Retell verbinden und welche Retell-Adressen Sie in Ihre Allowlist aufnehmen müssen. Weitere technische Inhalte finden Sie in unseren Beiträgen zu Real-Time Reliability, Retell Workflows und Retell Memory.

Und wenn Sie hohe Anrufvolumen abwickeln oder strenge Compliance-Anforderungen erfüllen müssen, sprechen Sie mit unserem Team.