Derfor byggede Retell sin egen SIP- og WebRTC-gateway

Før Retell byggede sin egen gateway, forbandt en førende leverandør telefon- og browseropkald til AI-agenterne hos Retell. Leverandørens platform havde gentagne hændelser, og leverandøren brugte i gennemsnit omkring 50 til 60 minutter på at løse hver enkelt. Vi havde ingen mulighed for at løse en hændelse hurtigere. Nogle indgående opkald nåede aldrig frem til Retell, så vores systemer havde ingen registrering af dem. Vi fik kendskab til de manglende opkald via supporthenvendelser fra kunder.

Vi ville have kontrol over kvaliteten og tilgængeligheden af hvert eneste opkald, så vi byggede vores egen SIP- og WebRTC-gateway. Fra oktober 2026 håndterer gatewayen 100% af alle telefon- og browseropkald hos Retell.

Retell-gatewayen er det system, der forbinder telefonnetværk og webbrowsere med AI-stemmeagenterne hos Retell. Den taler SIP (Session Initiation Protocol), den standard, som telefonsystemer bruger til at oprette og afslutte opkald, og WebRTC (Web Real-Time Communication), den standard, som browsere bruger til livelyd.

Gatewayen opretter hvert opkald, overfører lyden og mixer den for alle deltagere i opkaldet og håndterer viderestillinger, medlytning (en supervisor hører opkaldet, mens det foregår), overtagelse (en supervisor eller en menneskelig agent træder ind i stedet for AI-agenten midt i opkaldet) og afslutning af opkald.

For at gennemføre disse ændringer erstattede vi leverandøren i tre trin.

Vigtigste resultater:

• Infrastrukturlatensen er omkring 90% lavere, fra 50 ms til 0.5 ms.
• Alle telefonopkald når først frem til Retell, også opkald, der fejler.
• Opkaldsfunktioner udgives efter vores egen udgivelsesplan.

Hvad der ligger mellem den, der ringer, og en AI-agent

Demoer af stemme-AI viser som regel kun det sidste trin i et komplekst system: modellen, der lytter og svarer. En AI-telefonagent i produktion kræver langt mere end det. Der ligger typisk flere lag foran modellen. De afgør, om et opkald bliver forbundet, hvor hurtigt lyden bevæger sig, og hvad der sker, når noget fejler.

Et opkald til en Retell-agent passerer gennem følgende fire lag:

1. PSTN (public switched telephone network) er det globale telefonsystem. Browseropkald kommer fra et website eller en webapp.
2. En session border controller (SBC) er det sikre indgangspunkt for telefonopkald. Den modtager opkald udefra og afgør, hvor hvert enkelt skal hen. Browseropkald springer SBC'en over og forbinder direkte til gatewayen.
3. Medielaget. Det opretter hvert opkald, overfører lyden i begge retninger, mixer den for alle deltagere og styrer opkaldsfunktioner som viderestillinger og afslutning af opkald. Telefonopkald når frem til det via SIP. Browseropkald når frem til det via WebRTC. Hos Retell er gatewayen medielaget.
4. AI-infrastrukturen hos Retell. Den fører samtalen med den, der ringer.

Før gatewayen håndterede leverandøren lag 2 og 3. Retell kørte et enkelt stykke software imellem, kaldet lydrelæet (audio relay). Lyden krydsede det offentlige internet mellem leverandøren og relæet, et hop på omkring 50 ms, og relæet sendte den derefter videre til AI-infrastrukturen hos Retell.

Hvorfor leverandørens platform ikke slog til

Leverandørens platform lå i ruten for hvert eneste opkald, så dens hændelser ramte vores kunder direkte.

Leverandøren brugte i gennemsnit omkring 50 til 60 minutter på at komme sig efter en hændelse. Under nogle hændelser nåede indgående opkald aldrig fra leverandøren til Retell. De manglende opkald efterlod hverken en opkaldsregistrering eller en hændelse i vores systemer, hvilket betød, at vi ikke selv kunne opdage fejlen.

At leje hos leverandøren skabte også andre problemer:

• Kundekrav afhang af, hvad leverandøren understøttede, så vi kunne ikke levere noget, der ikke var understøttet.
• Sikkerheds- og compliancekrav var svære at opfylde via leverandørens platform.
• Hoppet over det offentlige internet tilføjede latens til hvert opkald.
• Regningen fra leverandøren løb op i millioner af dollars om året.

Vi evaluerede også andre leverandører. Evalueringerne bekræftede det, vi allerede mente: For at kontrollere produktkvaliteten måtte vi bygge vores egen gateway.

Sådan erstattede vi leverandøren i tre trin

Hvert trin flyttede en del af opkaldsruten over på vores egen infrastruktur.

Sæt vores egne session border controllers foran leverandøren

Vi implementerede vores egne SBC'er og pegede al SIP-signalering mod dem. Kunderne sendte deres telefonopkald til en Retell-adresse i stedet for leverandørens. De tilføjede også IP-adresserne fra Retell til deres allowlists, de lister over adresser, som deres telefonsystemer accepterer opkald fra. Til at begynde med videresendte SBC'erne alle opkald til leverandøren.

Ejerskabet af SBC'erne gav os kontrol over routingen. Alle telefonopkald nåede nu først frem til infrastrukturen hos Retell, hvor vi kunne se dem, uanset om de blev forbundet.

I en periode tog opkaldene en længere rute. Mellem SBC'erne og AI-infrastrukturen hos Retell forlod hvert opkald vores netværk for at gå til leverandøren og kom så tilbage. Undervejs krydsede det det offentlige internet to gange. Browseropkald gik stadig direkte til leverandøren.

Flyt telefonopkald til gatewayen i etaper, fra 1% til 100%

Derefter byggede vi gatewayen og implementerede den bag SBC'erne, inde i Retell-netværket. Da gatewayen var live, kunne hvert telefonopkald tage en af to ruter: gennem leverandøren eller gennem gatewayen.

SBC'erne valgte ruten for indgående opkald. AI-infrastrukturen hos Retell valgte den for udgående opkald. Vi øgede gatewayens andel af telefonopkaldene i etaper: 1%, 5%, 10%, 20%, 30%, 50% og derefter 100%. På gatewayruten tager hoppet mellem SBC'erne og gatewayen omkring 0.5 ms, fordi begge ligger inde i Retell-netværket.

Flyt browseropkald til gatewayen med WebRTC SDK'et fra Retell

Browseropkald var de sidste opkald, der var tilbage hos leverandøren. Vi byggede vores eget WebRTC SDK (software development kit), den kode, et website eller en webapp bruger til at foretage browseropkald, og routede browseropkald gennem gatewayen.

Da browseropkaldene var flyttet, udfasede vi leverandøren og lydrelæet. Et opkald bliver nu på Retell-netværket, fra det ankommer, til det når AI-infrastrukturen hos Retell.

Hvorfor migreringen var svær

Opgaven var at overtage ejerskabet uden at ændre nogen adfærd, som kunderne var afhængige af. Det svære var at erstatte leverandøren under live opkald uden gene for kunderne. Indgående opkald, udgående opkald, viderestillinger, browseropkald og opkaldsfunktioner skulle alle fungere som før under hele migreringen.

Det betød, at fire ting skulle bevares:

• Protokoladfærd (hvordan gatewayen taler SIP med systemerne i den anden ende af et opkald): Teleoperatører og kundernes telefonsystemer skulle opleve den adfærd, de forventede.
• Lydtiming (hvornår lyden ankommer på hver side af opkaldet): Lyden skulle bevæge sig begge veje uden nye huller eller forsinkelser.
• Deltagertilladelser (hvem i et opkald der kan lytte, tale eller starte en overtagelse): En supervisor, der bruger medlytning, skulle beholde de samme rettigheder.
• Semantik for opkaldets livscyklus (hvordan et opkald starter, ændrer sig og slutter): Hvert opkald skulle starte, viderestilles og slutte på samme måde og sende de samme hændelser til systemerne hos Retell.

Den trinvise udrulning gjorde det muligt at teste hver adfærd på en lille andel af rigtige telefonopkald. Vi udvidede først andelen, når adfærden holdt.

Den vigtigste lære for os er, at en gatewaymigrering som denne afhænger af at eje routingen, af stærk observability og af test, der dækker hele opkaldets livscyklus. Observability betyder, at man kan se, hvad hvert opkald gør, mens det sker.

Opkaldsruten hos Retell i dag: SBC'er, gateway og WebRTC SDK

Vores nye opkaldsrute består af tre dele.

SBC'erne hos Retell vender ud mod omverdenen. De modtager SIP-signalering fra teleoperatører og kundernes telefonsystemer og router derefter hvert opkald.

Gatewayen udfører det arbejde, som leverandøren tidligere gjorde. Den opretter opkald, overfører og mixer lyd og styrer opkaldsfunktioner. Den kommunikerer med AI-infrastrukturen hos Retell via HTTP og WebSocket, to standardmetoder, som servere bruger til at udveksle forespørgsler og streame data.

WebRTC SDK'et fra Retell gør det muligt for websites og webapps at sende browseropkald direkte til gatewayen.

Sikkerheds- og compliancekontroller er en del af designet. De omfatter godkendt adgang, deltagertilladelser, håndtering af følsom lyd og maskering af følsomme oplysninger.

Hvad det har ændret at eje gatewayen

At eje opkaldsruten betyder, at vi står til ansvar for alle dele af et opkalds kvalitet.

Vi venter ikke længere på, at en leverandør bygger opkaldsfunktioner. En forsikringskunde havde brug for tilpassede SIP-headers på SIP BYE-beskeder til en af sine kampagner. SIP-headers er felter, der bærer ekstra information med et opkald. En BYE-besked er det signal, der afslutter et opkald. Leverandøren understøttede ikke tilpassede headers på BYE-beskeder på det tidspunkt, så vi byggede funktionen i gatewayen. Fordi vi kontrollerer koden og udgivelsesprocessen, udgiver vi efter vores egen udgivelsesplan.

Vi kan nu selv opfylde en kundes sikkerhedskrav (HIPAA, SOC 2 osv.). Retell kan også implementere gatewayen i nye cloudregioner, når kunderne har brug for det.

Når det er det forkerte valg at bygge selv

En gateway er det forkerte projekt for et team, der mangler den tekniske kapacitet til at drive infrastruktur til realtidskommunikation, eller de produktkrav, der kan retfærdiggøre det.

Vores eget arbejde er fortsat efter lanceringen. At drive en gateway kræver et dygtigt team samt løbende investering i:

• Telefoni-interoperabilitet
• Netværk
• Mediebehandling
• Sikkerhed
• Overvågning
• Vagtberedskab

Telefoni-interoperabilitet betyder, at gatewayen holdes kompatibel med de mange teleoperatører og telefonsystemer, den forbinder til.

At eje gatewayen betyder også at eje hændelseshåndtering, kapacitetsplanlægning, vedligeholdelse og sikker implementering. Retell foretog investeringen, fordi opkaldskvalitet, tilgængelighed, tilpasning og hurtige forbedringer er centrale for vores produkt.

Råd til teams, der vil gøre det samme

Hvis dit team vælger at bygge sin egen gateway, er her det, der virkede for os:

1. Tag kontrol over dit SIP-indgangspunkt først, så du kan styre routingen og se alle telefonopkald, før du erstatter medielaget.
2. Migrér telefonopkald gradvist ved at bygge din gateway bag dine SBC'er.
3. Behandl browseropkald som en fuld integration, der omfatter SDK, godkendelse, opsætning af forbindelse og lydtransport.
4. Byg sikkerheds- og compliancekontroller ind fra starten, som vi gjorde med Retell-gatewayen.
5. Mål latens, lydkvalitet og fejladfærd gennem hele migreringen, også for opkald, der fejler, før de når din applikation.

Forbind dit telefonsystem med Retell

Hvis telefonikrav har holdt din udrulning af stemme-AI tilbage, så start med vores guide til tilpasset telefoni. Den viser, hvordan du forbinder dit telefonsystem med Retell via en SIP trunk (en direkte SIP-forbindelse mellem to telefonsystemer), og hvilke Retell-adresser du skal tilføje til din allowlist. For mere teknisk indhold kan du læse vores indlæg om Real-Time Reliability, Retell Workflows og Retell Memory.

Og hvis du har store opkaldsvolumener eller strenge compliancekrav, så tal med vores team.