Why Retell Built Its Own SIP and WebRTC Gateway

Before Retell built its own gateway, a leading vendor connected phone and browser calls to Retell’s AI agents. The vendor’s platform had repeated incidents and took a long time on average to fix each one. Worse still, we had no way to fix an incident faster. This meant that some inbound calls never reached Retell, which meant our systems had no record of them. We learned about these missing calls from customer support tickets.

We wanted control over the quality and availability of every call, so we responded to this challenge by building our own SIP (Session Initiation Protocol) and WebRTC (Web Real-Time Communication) gateway. As of October 2026, the gateway carries 100% of Retell’s phone and browser calls.

Retell’s gateway is the system that connects phone networks and web browsers to Retell's AI voice agents. It speaks SIP, the standard phone systems use to set up and end calls, and WebRTC, the standard browsers use for live audio.

The gateway sets up each call, carries the audio and mixes it for everyone on the call, and handles transfers, live listening (a supervisor hears the call as it happens), take-over (a supervisor or human agent steps in for the AI agent mid-call), and hang-ups.

To make these changes, we replaced the vendor in three steps. But before we discuss replacement, let's talk about the original configuration.

What sits between a caller and an AI agent

Voice AI demos usually show the last step in a complicated system: the model that listens and replies. A production phone agent needs much more than that. Several layers are typically in front of the model. They decide whether a call connects, how fast the audio moves, and what happens when something fails.

A call to a Retell agent passes through the following four layers:

1. The PSTN (public switched telephone network) is the global phone system. Browser calls arrive from a website or web app.
2. A session border controller (SBC) is the secure entry point for phone calls. It receives calls from outside and decides where each one goes. Browser calls skip the SBC and connect to the gateway directly.
3. The media layer. It sets up each call, carries the audio in both directions, mixes it for everyone on the call, and runs call controls such as transfers and hang-ups. Phone calls reach it over SIP. Browser calls reach it over WebRTC. At Retell, the gateway is the media layer.
4. Retell's AI infrastructure. It runs the conversation with the caller.

Before the gateway, the vendor handled layers 2 and 3. Retell ran one piece of software in between, called the audio relay. Audio crossed the public internet between the vendor and the relay, a hop of about 50 ms, and the relay then passed it on to Retell's AI infrastructure.

‍

Why the vendor's platform fell short

The vendor's platform sat in the path of every call, so its incidents reached Retell's customers directly.

The vendor took about 50 to 60 minutes on average to recover from an incident. During some incidents, inbound calls never made it from the vendor to Retell. The missing calls left no call record and no event in our systems, which meant we had no way to detect the failure ourselves.

Renting from the vendor caused other problems:

• Customer requirements depended on what the vendor supported, so we couldn't ship anything that was unsupported.
• Security and compliance requirements were hard to meet through the vendor's platform.
• The public internet hop added latency to every call.
• The vendor bill ran to millions of dollars a year.

We also evaluated other vendors. The evaluations reinforced what we already thought: to control product quality, we had to build our own gateway.

How we replaced the vendor in three steps

Each step moved one part of the call path onto Retell's infrastructure.

Step 1: Put Retell's session border controllers in front of the vendor

We deployed our own SBCs and pointed all SIP signaling at them. Customers sent their phone calls to Retell's address instead of the vendor's. They also added Retell's IP addresses to their allowlists, the lists of addresses their phone systems accept calls from. At first, the SBCs forwarded every call to the vendor.

Step 1 gave us control of routing. Every phone call now reached Retell's infrastructure first, where we could see it regardless of whether it connected.

For a while, calls took a longer path. Between Retell's SBCs and Retell's AI infrastructure, each call left our network for the vendor and came back. It crossed the public internet twice on the way. Browser calls still went straight to the vendor.

‍

Step 2: Move phone calls to the gateway in stages

Next we built the gateway and deployed it behind the SBCs, inside Retell's network. Once the gateway was live, each phone call could take one of two paths: through the vendor or through the gateway.

The SBCs picked the path for inbound calls. Retell's AI infrastructure picked it for outbound calls. We grew the gateway's share of phone calls in stages: 1%, 5%, 10%, 20%, 30%, 50%, then 100%. On the gateway path, the hop between the SBCs and the gateway takes about 0.5 ms, because both are inside Retell's network.

‍

Step 3: Move browser calls to the gateway with Retell's WebRTC SDK

Browser calls were the last calls left on the vendor. We built our own WebRTC SDK (software development kit), the code a website or web app uses to place browser calls, and routed browser calls through the gateway.

With browser calls moved, we retired the vendor and the audio relay. A call now stays on Retell's network from the moment it arrives until it reaches Retell's AI infrastructure.

Why the migration was hard

The hardest part of the project involved replacing the vendor during live calls without friction for customers. Inbound calls, outbound calls, transfers, browser calls and call controls all had to keep working as before, for the whole migration.

That meant preserving four things:

• Protocol behavior (how the gateway speaks SIP to the systems on the other end of a call): Carriers and customers' phone systems had to get the behavior they expected.
• Audio timing (when audio arrives on each side of the call): Audio had to move both ways with no new gaps or delays.
• Participant permissions (who on a call can listen, speak, or start a take-over): A supervisor using live listening had to keep the same rights.
• Call lifecycle semantics (how a call starts, changes and ends): Every call had to start, transfer and end the same way, and send the same events to Retell's systems.

The staged rollout let us test each behavior on a small share of real phone calls. We widened the share only after the behavior held up.

A gateway migration like this requires controlling your routing, having clear visibility into live calls, and testing the entire call flow thoroughly.

Retell’s call path today: SBCs, gateway, and WebRTC SDK

Our new call path has three parts:

• Retell's SBCs face the outside world. They receive SIP signaling from carriers and customers' phone systems, then route each call.
• The gateway does the work the vendor used to do. It sets up calls, carries and mixes audio, and runs call controls. It talks to Retell's AI infrastructure over HTTP and WebSocket, two standard ways for servers to exchange requests and stream data.
• Retell's WebRTC SDK lets websites and web apps send browser calls straight to the gateway.

Security and compliance controls are part of the design. They include authenticated access, participant permissions, handling of sensitive audio, and redaction of sensitive information.

What owning the gateway changed for Retell

Having full control of the call path means we can answer for every part of a call’s quality.

We no longer wait on a vendor to build call features. One insurance customer needed custom SIP headers on SIP BYE messages for one of its campaigns. SIP headers are fields that carry extra information along with a call. A BYE message is the signal that ends a call. The vendor didn't support custom headers on BYE messages at the time, so we built the feature in the gateway. Because we control the code and the release process, we ship on our own release schedule.

We can now meet a customer's security requirements (HIPAA, SOC 2, etc.) ourselves. Retell can also deploy the gateway in new cloud regions when customers need it.

‍

When building your own gateway is the wrong decision

A gateway is the wrong project for a team that lacks the engineering capacity to run real-time communications infrastructure, or the product requirements to justify it.

Our own work has continued after launch. Running a gateway requires a skilled team as well as ongoing investment in:

• Telephony interoperability
• Networking
• Media processing
• Security
• Monitoring
• On-call operations

Telephony interoperability means keeping the gateway compatible with the many carriers and phone systems it connects to.

Owning the gateway also means owning incident response, capacity planning, maintenance and safe deployment. Retell made the investment because call quality, availability, customization, and rapid improvement are central to our product.

Advice for teams doing the same

Should your team choose to build its own gateway, here is what worked for us:

1. Take control of your SIP entry point first, so you can manage routing and see every phone call before you replace the media layer.
2. Migrate phone calls gradually by building your gateway behind your SBCs.
3. Treat browser calls as a full integration that includes the SDK, authentication, connection setup and audio transport.
4. Build in security and compliance controls from the start, as we did with the Retell gateway.
5. Measure latency, audio quality and failure behavior through the whole migration, including calls that fail before they reach your application.

Connect your phone system to Retell

If telephony requirements have held back your voice AI rollout, start with our custom telephony guide. It shows how to connect your phone system to Retell over a SIP trunk (a direct SIP connection between two phone systems) and which Retell addresses to allowlist. For more technical content, check out our entries on Real-Time Reliability, Retell Workflows, and Retell Memory.

And if you’re running high call volumes or dealing with strict compliance requirements, talk to our team.