Waarom Retell een eigen SIP- en WebRTC-gateway bouwde

Voordat Retell een eigen gateway bouwde, verbond een toonaangevende leverancier telefoon- en browsergesprekken met de AI-agents van Retell. Het platform van de leverancier had herhaaldelijk incidenten, en de leverancier had gemiddeld zo'n 50 tot 60 minuten nodig om elk incident op te lossen. Wij hadden geen enkele manier om een incident sneller op te lossen. Sommige inkomende gesprekken bereikten Retell nooit, waardoor onze systemen er geen registratie van hadden. We hoorden pas van de gemiste gesprekken via supporttickets van klanten.

We wilden controle over de kwaliteit en beschikbaarheid van elk gesprek, dus bouwden we onze eigen SIP- en WebRTC-gateway. Sinds oktober 2026 verwerkt de gateway 100% van de telefoon- en browsergesprekken van Retell.

De gateway van Retell is het systeem dat telefoonnetwerken en webbrowsers verbindt met de AI-stemagents van Retell. De gateway spreekt SIP (Session Initiation Protocol), de standaard die telefoonsystemen gebruiken om gesprekken op te zetten en te beëindigen, en WebRTC (Web Real-Time Communication), de standaard die browsers gebruiken voor live audio.

De gateway zet elk gesprek op, transporteert de audio en mixt die voor iedereen in het gesprek, en verzorgt gespreksoverdrachten, meeluisteren (een supervisor hoort het gesprek terwijl het plaatsvindt), overname (een supervisor of menselijke medewerker neemt het gesprek halverwege over van de AI-agent) en ophangen.

Om deze veranderingen door te voeren, hebben we de leverancier in drie stappen vervangen.

Belangrijkste resultaten:

• De infrastructuurlatency is zo'n 90% lager: van 50 ms naar 0.5 ms.
• Elk telefoongesprek bereikt eerst Retell, ook gesprekken die mislukken.
• Gespreksfuncties worden uitgebracht volgens de eigen releaseplanning van Retell.

Wat er tussen een beller en een AI-agent zit

Demo's van voice-AI laten meestal de laatste stap in een complex systeem zien: het model dat luistert en antwoordt. Een AI-telefoonagent in productie heeft veel meer nodig. Meestal zitten er meerdere lagen vóór het model. Die bepalen of een gesprek tot stand komt, hoe snel de audio zich verplaatst en wat er gebeurt als er iets misgaat.

Een gesprek met een Retell-agent gaat door de volgende vier lagen:

1. Het PSTN (public switched telephone network) is het wereldwijde telefoonsysteem. Browsergesprekken komen binnen vanaf een website of webapp.
2. Een session border controller (SBC) is het beveiligde toegangspunt voor telefoongesprekken. Die ontvangt gesprekken van buitenaf en bepaalt waar elk gesprek naartoe gaat. Browsergesprekken slaan de SBC over en maken rechtstreeks verbinding met de gateway.
3. De medialaag. Die zet elk gesprek op, transporteert de audio in beide richtingen, mixt die voor iedereen in het gesprek en voert gespreksbediening uit, zoals gespreksoverdrachten en ophangen. Telefoongesprekken bereiken de medialaag via SIP. Browsergesprekken via WebRTC. Bij Retell is de gateway de medialaag.
4. De AI-infrastructuur van Retell. Die voert het gesprek met de beller.

Vóór de gateway verzorgde de leverancier laag 2 en 3. Retell draaide daartussen één stuk software, de audiorelay. Audio ging via het openbare internet tussen de leverancier en de relay, een hop van zo'n 50 ms, waarna de relay de audio doorgaf aan de AI-infrastructuur van Retell.

Waarom het platform van de leverancier tekortschoot

Het platform van de leverancier zat in het pad van elk gesprek, dus de incidenten raakten de klanten van Retell direct.

De leverancier had gemiddeld zo'n 50 tot 60 minuten nodig om te herstellen van een incident. Tijdens sommige incidenten kwamen inkomende gesprekken nooit van de leverancier bij Retell aan. De gemiste gesprekken lieten geen gespreksregistratie en geen event achter in onze systemen, waardoor we de storing zelf op geen enkele manier konden detecteren.

Huren bij de leverancier veroorzaakte nog meer problemen:

• Klantwensen waren afhankelijk van wat de leverancier ondersteunde, dus we konden niets uitbrengen wat niet werd ondersteund.
• Beveiligings- en compliance-eisen waren lastig te halen via het platform van de leverancier.
• De hop via het openbare internet voegde latency toe aan elk gesprek.
• De rekening van de leverancier liep op tot miljoenen dollars per jaar.

We hebben ook andere leveranciers geëvalueerd. Die evaluaties bevestigden wat we al dachten: om de productkwaliteit in eigen hand te hebben, moesten we onze eigen gateway bouwen.

Hoe we de leverancier in drie stappen vervingen

Elke stap verplaatste een deel van het gesprekspad naar de infrastructuur van Retell.

Session border controllers van Retell vóór de leverancier plaatsen

We rolden onze eigen SBC's uit en lieten alle SIP-signalering daarnaartoe lopen. Klanten stuurden hun telefoongesprekken naar het adres van Retell in plaats van dat van de leverancier. Ook voegden ze de IP-adressen van Retell toe aan hun allowlists: de lijsten met adressen waarvan hun telefoonsystemen gesprekken accepteren. In het begin stuurden de SBC's elk gesprek door naar de leverancier.

Doordat de SBC's van ons waren, hadden we de routering in handen. Elk telefoongesprek bereikte nu eerst de infrastructuur van Retell, waar we het konden zien, ongeacht of het tot stand kwam.

Een tijdlang namen gesprekken een langere route. Tussen de SBC's van Retell en de AI-infrastructuur van Retell verliet elk gesprek ons netwerk richting de leverancier en kwam het weer terug. Onderweg ging het twee keer over het openbare internet. Browsergesprekken gingen nog steeds rechtstreeks naar de leverancier.

Telefoongesprekken gefaseerd naar de gateway verplaatsen, van 1% naar 100%

Daarna bouwden we de gateway en rolden we die uit achter de SBC's, binnen het netwerk van Retell. Zodra de gateway live was, kon elk telefoongesprek een van twee routes nemen: via de leverancier of via de gateway.

De SBC's kozen de route voor inkomende gesprekken. De AI-infrastructuur van Retell koos die voor uitgaande gesprekken. We vergrootten het aandeel telefoongesprekken via de gateway in fasen: 1%, 5%, 10%, 20%, 30%, 50% en daarna 100%. Op de gatewayroute duurt de hop tussen de SBC's en de gateway zo'n 0.5 ms, omdat beide binnen het netwerk van Retell zitten.

Browsergesprekken naar de gateway verplaatsen met de WebRTC SDK van Retell

Browsergesprekken waren de laatste gesprekken die nog via de leverancier liepen. We bouwden onze eigen WebRTC SDK (software development kit), de code die een website of webapp gebruikt om browsergesprekken te voeren, en routeerden browsergesprekken via de gateway.

Nu de browsergesprekken over waren, hebben we de leverancier en de audiorelay uitgefaseerd. Een gesprek blijft nu op het netwerk van Retell vanaf het moment dat het binnenkomt tot het de AI-infrastructuur van Retell bereikt.

Waarom de migratie lastig was

De opdracht was om het eigenaarschap over te nemen zonder gedrag te veranderen waarop klanten vertrouwden. Het lastige was de leverancier te vervangen tijdens live gesprekken, zonder hinder voor klanten. Inkomende gesprekken, uitgaande gesprekken, gespreksoverdrachten, browsergesprekken en gespreksbediening moesten tijdens de hele migratie blijven werken zoals voorheen.

Dat betekende dat we vier dingen moesten behouden:

• Protocolgedrag (hoe de gateway SIP spreekt met de systemen aan de andere kant van een gesprek): Carriers en de telefoonsystemen van klanten moesten het gedrag krijgen dat ze verwachtten.
• Audiotiming (wanneer audio aan elke kant van het gesprek aankomt): Audio moest in beide richtingen stromen zonder nieuwe gaten of vertragingen.
• Deelnemersrechten (wie in een gesprek kan luisteren, spreken of een overname kan starten): Een supervisor die meeluistert, moest dezelfde rechten houden.
• Semantiek van de gesprekslevenscyclus (hoe een gesprek begint, verandert en eindigt): Elk gesprek moest op dezelfde manier beginnen, worden doorverbonden en eindigen, en dezelfde events naar de systemen van Retell sturen.

Dankzij de gefaseerde uitrol konden we elk gedrag testen op een klein deel van echte telefoongesprekken. We vergrootten dat deel pas als het gedrag standhield.

De belangrijkste les voor ons: een gatewaymigratie als deze staat of valt met eigenaarschap over de routering, sterke observability en tests die de volledige gesprekslevenscyclus afdekken. Observability betekent dat je kunt zien wat elk gesprek doet terwijl het plaatsvindt.

Het gesprekspad van Retell nu: SBC's, gateway en WebRTC SDK

Ons nieuwe gesprekspad bestaat uit drie onderdelen.

De SBC's van Retell staan in contact met de buitenwereld. Ze ontvangen SIP-signalering van carriers en de telefoonsystemen van klanten en routeren vervolgens elk gesprek.

De gateway doet het werk dat de leverancier vroeger deed. Die zet gesprekken op, transporteert en mixt audio en voert gespreksbediening uit. De gateway communiceert met de AI-infrastructuur van Retell via HTTP en WebSocket, twee standaardmanieren waarop servers verzoeken uitwisselen en data streamen.

Met de WebRTC SDK van Retell sturen websites en webapps browsergesprekken rechtstreeks naar de gateway.

Beveiligings- en compliancemaatregelen maken deel uit van het ontwerp. Denk aan geauthenticeerde toegang, deelnemersrechten, de verwerking van gevoelige audio en het afschermen van gevoelige informatie.

Wat eigenaarschap over de gateway veranderde

Nu het gesprekspad van ons is, zijn we verantwoordelijk voor elk onderdeel van de gesprekskwaliteit.

We hoeven niet langer op een leverancier te wachten om gespreksfuncties te bouwen. Een klant in de verzekeringsbranche had voor een van zijn campagnes aangepaste SIP-headers nodig in SIP BYE-berichten. SIP-headers zijn velden die extra informatie met een gesprek meesturen. Een BYE-bericht is het signaal dat een gesprek beëindigt. De leverancier ondersteunde destijds geen aangepaste headers in BYE-berichten, dus bouwden we de functie in de gateway. Omdat wij de code en het releaseproces in handen hebben, brengen we uit volgens onze eigen releaseplanning.

We kunnen nu zelf voldoen aan de beveiligingseisen van een klant (HIPAA, SOC 2, enz.). Retell kan de gateway ook uitrollen in nieuwe cloudregio's wanneer klanten dat nodig hebben.

Wanneer zelf bouwen de verkeerde keuze is

Een gateway is het verkeerde project voor een team dat niet de engineeringcapaciteit heeft om realtime communicatie-infrastructuur te draaien, of niet de productvereisten heeft die het rechtvaardigen.

Ons eigen werk ging na de lancering gewoon door. Een gateway draaien vraagt om een vakkundig team en om doorlopende investeringen in:

• Telefonie-interoperabiliteit
• Netwerken
• Mediaverwerking
• Beveiliging
• Monitoring
• On-call-diensten

Telefonie-interoperabiliteit betekent dat de gateway compatibel blijft met de vele carriers en telefoonsystemen waarmee hij verbinding maakt.

Eigenaarschap over de gateway betekent ook eigenaarschap over incidentrespons, capaciteitsplanning, onderhoud en veilige uitrol. Retell deed die investering omdat gesprekskwaliteit, beschikbaarheid, maatwerk en snelle verbetering centraal staan in ons product.

Advies voor teams die hetzelfde doen

Kiest je team ervoor om een eigen gateway te bouwen? Dit werkte voor ons:

1. Neem eerst de controle over je SIP-toegangspunt, zodat je de routering kunt beheren en elk telefoongesprek kunt zien voordat je de medialaag vervangt.
2. Migreer telefoongesprekken geleidelijk door je gateway achter je SBC's te bouwen.
3. Behandel browsergesprekken als een volledige integratie, inclusief de SDK, authenticatie, het opzetten van de verbinding en audiotransport.
4. Bouw beveiligings- en compliancemaatregelen vanaf het begin in, zoals wij deden met de Retell-gateway.
5. Meet latency, audiokwaliteit en faalgedrag tijdens de hele migratie, inclusief gesprekken die mislukken voordat ze je applicatie bereiken.

Verbind je telefoonsysteem met Retell

Houden telefonievereisten de uitrol van je voice-AI tegen? Begin dan met onze handleiding voor custom telefonie. Daarin lees je hoe je je telefoonsysteem via een SIP-trunk (een directe SIP-verbinding tussen twee telefoonsystemen) met Retell verbindt en welke Retell-adressen je op je allowlist zet. Meer technische content vind je in onze artikelen over Real-Time Reliability, Retell Workflows en Retell Memory.

En verwerk je grote gespreksvolumes of heb je te maken met strikte compliance-eisen? Neem contact op met ons team.