Därför byggde Retell en egen SIP- och WebRTC-gateway

Innan Retell byggde en egen gateway kopplade en ledande leverantör telefon- och webbläsarsamtal till AI-agenterna hos Retell. Leverantörens plattform drabbades av upprepade incidenter, och det tog i genomsnitt cirka 50 till 60 minuter för leverantören att åtgärda varje incident. Vi hade inget sätt att lösa en incident snabbare. Vissa inkommande samtal nådde aldrig Retell, så våra system hade ingen registrering av dem. Vi fick veta om de saknade samtalen via ärenden till kundtjänst.

Vi ville ha kontroll över kvaliteten och tillgängligheten för varje samtal, så vi byggde en egen SIP- och WebRTC-gateway. Från och med oktober 2026 hanterar gatewayen 100% av alla telefon- och webbläsarsamtal hos Retell.

Retell-gatewayen är systemet som kopplar telefonnät och webbläsare till AI-röstagenterna hos Retell. Den talar SIP (Session Initiation Protocol), standarden som telefonsystem använder för att upprätta och avsluta samtal, och WebRTC (Web Real-Time Communication), standarden som webbläsare använder för ljud i realtid.

Gatewayen upprättar varje samtal, överför ljudet och mixar det för alla i samtalet samt hanterar överföringar, medlyssning (en arbetsledare hör samtalet medan det pågår), övertagande (en arbetsledare eller mänsklig agent tar över från AI-agenten mitt i samtalet) och avslutade samtal.

För att genomföra förändringarna ersatte vi leverantören i tre steg.

Viktigaste resultaten:

• Infrastrukturlatensen är cirka 90% lägre, från 50 ms till 0.5 ms.
• Varje telefonsamtal når Retell först, även samtal som misslyckas.
• Samtalsfunktioner lanseras enligt vår egen releaseplan.

Vad som finns mellan den som ringer och en AI-agent

Demos av röst-AI visar oftast det sista steget i ett komplicerat system: modellen som lyssnar och svarar. En telefonagent i produktion kräver mycket mer än så. Flera lager ligger vanligtvis framför modellen. De avgör om ett samtal kopplas upp, hur snabbt ljudet rör sig och vad som händer när något går fel.

Ett samtal till en agent från Retell passerar genom följande fyra lager:

1. PSTN (det publika telefonnätet) är det globala telefonsystemet. Webbläsarsamtal kommer från en webbplats eller webbapp.
2. En session border controller (SBC) är den säkra ingångspunkten för telefonsamtal. Den tar emot samtal utifrån och avgör vart varje samtal ska. Webbläsarsamtal hoppar över SBC:n och ansluter direkt till gatewayen.
3. Medielagret. Det upprättar varje samtal, överför ljudet i båda riktningarna, mixar det för alla i samtalet och kör samtalskontroller som överföringar och avslutning av samtal. Telefonsamtal når det via SIP. Webbläsarsamtal når det via WebRTC. Hos Retell är gatewayen medielagret.
4. AI-infrastrukturen hos Retell. Den för samtalet med den som ringer.

Före gatewayen hanterade leverantören lager 2 och 3. Retell körde en mjukvara däremellan, kallad ljudreläet. Ljudet gick över det publika internet mellan leverantören och reläet, ett hopp på cirka 50 ms, och reläet skickade det sedan vidare till AI-infrastrukturen hos Retell.

Därför räckte leverantörens plattform inte till

Leverantörens plattform låg i vägen för varje samtal, så dess incidenter drabbade kunderna hos Retell direkt.

Det tog i genomsnitt cirka 50 till 60 minuter för leverantören att återhämta sig från en incident. Under vissa incidenter kom inkommande samtal aldrig fram från leverantören till Retell. De saknade samtalen lämnade ingen samtalspost och ingen händelse i våra system, vilket innebar att vi inte själva kunde upptäcka felet.

Att hyra av leverantören skapade fler problem:

• Kundkrav berodde på vad leverantören hade stöd för, så vi kunde inte leverera något som saknade stöd.
• Säkerhets- och efterlevnadskrav var svåra att uppfylla via leverantörens plattform.
• Hoppet över det publika internet lade till latens i varje samtal.
• Leverantörsfakturan uppgick till miljontals dollar per år.

Vi utvärderade även andra leverantörer. Utvärderingarna bekräftade det vi redan trodde: för att kontrollera produktkvaliteten var vi tvungna att bygga en egen gateway.

Så ersatte vi leverantören i tre steg

Varje steg flyttade en del av samtalsvägen till infrastrukturen hos Retell.

Placera våra egna session border controllers framför leverantören

Vi driftsatte våra egna SBC:er och riktade all SIP-signalering mot dem. Kunderna skickade sina telefonsamtal till adressen hos Retell i stället för till leverantörens. De lade också till IP-adresserna för Retell i sina tillåtelselistor (allowlists), listorna över adresser som deras telefonsystem tar emot samtal från. Till en början vidarebefordrade SBC:erna varje samtal till leverantören.

Att äga SBC:erna gav oss kontroll över routningen. Varje telefonsamtal nådde nu infrastrukturen hos Retell först, där vi kunde se det oavsett om det kopplades upp eller inte.

Under en period tog samtalen en längre väg. Mellan SBC:erna och AI-infrastrukturen hos Retell lämnade varje samtal vårt nätverk för att gå till leverantören och tillbaka. Det passerade det publika internet två gånger på vägen. Webbläsarsamtal gick fortfarande direkt till leverantören.

Flytta telefonsamtal till gatewayen stegvis, från 1% till 100%

Därefter byggde vi gatewayen och driftsatte den bakom SBC:erna, inne i Retell-nätverket. När gatewayen väl var i drift kunde varje telefonsamtal ta en av två vägar: via leverantören eller via gatewayen.

SBC:erna valde väg för inkommande samtal. AI-infrastrukturen hos Retell valde den för utgående samtal. Vi ökade gatewayens andel av telefonsamtalen stegvis: 1%, 5%, 10%, 20%, 30%, 50% och sedan 100%. På gatewayvägen tar hoppet mellan SBC:erna och gatewayen cirka 0.5 ms, eftersom båda finns inne i Retell-nätverket.

Flytta webbläsarsamtal till gatewayen med vårt eget WebRTC SDK

Webbläsarsamtalen var de sista samtalen som låg kvar hos leverantören. Vi byggde vårt eget WebRTC SDK (software development kit), koden som en webbplats eller webbapp använder för att ringa webbläsarsamtal, och dirigerade webbläsarsamtalen via gatewayen.

När webbläsarsamtalen var flyttade avvecklade vi leverantören och ljudreläet. Ett samtal stannar nu i Retell-nätverket från det ögonblick det kommer in tills det når AI-infrastrukturen hos Retell.

Därför var migreringen svår

Uppgiften var att ta över ägarskapet utan att ändra något beteende som kunderna förlitade sig på. Det svåra var att ersätta leverantören under pågående samtal utan friktion för kunderna. Inkommande samtal, utgående samtal, överföringar, webbläsarsamtal och samtalskontroller behövde fungera precis som tidigare under hela migreringen.

Det innebar att vi behövde bevara fyra saker:

• Protokollbeteende (hur gatewayen talar SIP med systemen i andra änden av ett samtal): Operatörer och kundernas telefonsystem måste få det beteende de förväntade sig.
• Ljudtiming (när ljudet kommer fram på varje sida av samtalet): Ljudet måste röra sig åt båda hållen utan nya avbrott eller fördröjningar.
• Deltagarbehörigheter (vem i ett samtal som kan lyssna, tala eller påbörja ett övertagande): En arbetsledare som använder medlyssning måste behålla samma rättigheter.
• Semantik för samtalets livscykel (hur ett samtal startar, förändras och avslutas): Varje samtal måste starta, överföras och avslutas på samma sätt och skicka samma händelser till systemen hos Retell.

Den stegvisa utrullningen lät oss testa varje beteende på en liten andel riktiga telefonsamtal. Vi ökade andelen först när beteendet höll.

Den viktigaste lärdomen för oss är att en gatewaymigrering som denna bygger på att äga routningen, på stark observerbarhet och på tester som täcker hela samtalets livscykel. Observerbarhet innebär att kunna se vad varje samtal gör medan det pågår.

Samtalsvägen hos Retell i dag: SBC:er, gateway och WebRTC SDK

Vår nya samtalsväg består av tre delar.

SBC:erna hos Retell är vända mot omvärlden. De tar emot SIP-signalering från operatörer och kundernas telefonsystem och dirigerar sedan varje samtal.

Gatewayen gör det arbete som leverantören tidigare gjorde. Den upprättar samtal, överför och mixar ljud och kör samtalskontroller. Den kommunicerar med AI-infrastrukturen hos Retell via HTTP och WebSocket, två standardsätt för servrar att utbyta förfrågningar och strömma data.

WebRTC SDK:t från Retell låter webbplatser och webbappar skicka webbläsarsamtal direkt till gatewayen.

Säkerhets- och efterlevnadskontroller är en del av designen. De omfattar autentiserad åtkomst, deltagarbehörigheter, hantering av känsligt ljud och maskering av känslig information.

Vad det förändrade att äga gatewayen

Att äga samtalsvägen innebär att vi ansvarar för varje del av ett samtals kvalitet.

Vi behöver inte längre vänta på att en leverantör ska bygga samtalsfunktioner. En försäkringskund behövde anpassade SIP-headers i SIP BYE-meddelanden för en av sina kampanjer. SIP-headers är fält som bär extra information tillsammans med ett samtal. Ett BYE-meddelande är signalen som avslutar ett samtal. Leverantören hade då inte stöd för anpassade headers i BYE-meddelanden, så vi byggde funktionen i gatewayen. Eftersom vi kontrollerar koden och releaseprocessen lanserar vi enligt vår egen releaseplan.

Vi kan nu själva uppfylla en kunds säkerhetskrav (HIPAA, SOC 2 m.m.). Retell kan också driftsätta gatewayen i nya molnregioner när kunderna behöver det.

När det är fel beslut att bygga själv

En gateway är fel projekt för ett team som saknar ingenjörskapacitet för att driva kommunikationsinfrastruktur i realtid, eller produktkrav som motiverar det.

Vårt eget arbete har fortsatt efter lanseringen. Att driva en gateway kräver ett kompetent team samt löpande investeringar i:

• Telefoniinteroperabilitet
• Nätverk
• Mediebearbetning
• Säkerhet
• Övervakning
• Jourverksamhet

Telefoniinteroperabilitet innebär att hålla gatewayen kompatibel med de många operatörer och telefonsystem den ansluter till.

Att äga gatewayen innebär också att äga incidenthantering, kapacitetsplanering, underhåll och säker driftsättning. Retell gjorde investeringen eftersom samtalskvalitet, tillgänglighet, anpassning och snabba förbättringar är centrala för vår produkt.

Råd till team som vill göra samma sak

Om ditt team väljer att bygga en egen gateway är det här vad som fungerade för oss:

1. Ta kontroll över din SIP-ingångspunkt först, så att du kan styra routningen och se varje telefonsamtal innan du ersätter medielagret.
2. Migrera telefonsamtal gradvis genom att bygga din gateway bakom dina SBC:er.
3. Behandla webbläsarsamtal som en fullständig integration som omfattar SDK, autentisering, uppkoppling och ljudtransport.
4. Bygg in säkerhets- och efterlevnadskontroller från början, som vi gjorde med Retell-gatewayen.
5. Mät latens, ljudkvalitet och felbeteende under hela migreringen, inklusive samtal som misslyckas innan de når din applikation.

Anslut ditt telefonsystem till Retell

Om telefonikrav har bromsat din utrullning av röst-AI kan du börja med vår guide för anpassad telefoni. Den visar hur du ansluter ditt telefonsystem till Retell via en SIP-trunk (en direkt SIP-anslutning mellan två telefonsystem) och vilka adresser hos Retell du ska lägga till i tillåtelselistan. För mer tekniskt innehåll kan du läsa våra inlägg om Real-Time Reliability, Retell Workflows och Retell Memory.

Och om du hanterar stora samtalsvolymer eller har strikta efterlevnadskrav, kontakta vårt team.