Connecting AI Voice Platforms via SIP: Vapi, Retell, LiveKit, and ElevenLabs

AI voice platforms such as Vapi, Retell, LiveKit, and ElevenLabs run the conversational agent, but none of them is a phone carrier. To place and receive real phone calls, each platform connects to the public switched telephone network (PSTN) through a SIP trunk supplied by a voice infrastructure provider. The trunk exchanges call signaling and audio with the platform’s SIP edge, and a DID number gives the agent a real, dialable phone identity. All four platforms support this model, usually described as bring your own SIP trunk, custom telephony, or bring your own carrier (BYOC).

This guide explains how the integration works at the protocol level, how each of the four platforms implements it, and what to check before you route production traffic.

Quick facts

Why AI voice platforms need a SIP trunk

An AI voice platform is an application layer. It converts speech to text, runs a language model, generates speech, and manages the conversation in real time. What it cannot do on its own is reach a phone number, because phone numbers exist inside carrier networks, not inside AI platforms.

There are two ways platforms bridge this gap. The first is bundled telephony: the platform resells numbers and minutes from a carrier partner, which is fast to start with but limits your control over coverage, routing, and per-minute economics. The second is a trunk you bring yourself. You buy DID numbers and SIP termination from an infrastructure provider, then configure the platform to send and receive calls through that trunk.

The bring-your-own model matters for three practical reasons:

• Number coverage. Platforms typically bundle numbers from a small set of markets. An infrastructure provider can supply local numbers in many more countries, subject to each country’s documentation rules.
• Portability. Your numbers and carrier relationships stay stable while you swap AI platforms, models, or vendors. Customers keep dialing the same number.
• Control. You choose the carrier path, codec, capacity, and authentication method instead of inheriting whatever the platform’s default reseller uses.

Where the SIP trunk sits in an AI voice stack

A production AI voice deployment has clearly separated layers, and most integration problems come from confusing them. SIP is the signaling protocol that sets up, modifies, and ends the call. RTP is the transport that normally carries the actual audio once the call is established. The trunk handles both between the carrier network and the platform’s SIP edge. Everything above that boundary, including speech recognition, the language model, speech synthesis, and turn-taking logic, belongs to the AI platform.

Caption: A SIP trunk connects the carrier network and DID numbers to the AI platform’s SIP edge. SIP messages set up the call and RTP streams carry the audio; everything above the SIP edge is the AI platform’s responsibility.

Keeping this boundary in mind makes troubleshooting far simpler. If a call never rings, the problem is usually signaling: routing, authentication, or a wrong SIP URI. If the call connects but audio is missing or one-directional, the problem is usually media: RTP paths, NAT, or encryption mismatches. If the call sounds fine but the agent responds slowly, the delay usually comes from the AI processing pipeline rather than from SIP, because SIP itself only sets calls up and does not carry or accelerate audio.

What all four integrations have in common

Despite different dashboards and terminology, Vapi, Retell, LiveKit, and ElevenLabs implement the same underlying pattern. Every integration requires:

1. A DID number purchased from your infrastructure provider, in E.164 format (for example, +31201234567). All four platforms expect E.164 numbers.
2. An inbound path. The provider forwards calls arriving on the DID to a SIP URI or endpoint that the platform publishes for your account.
3. An outbound path. The platform sends SIP INVITEs to your provider’s termination address (a hostname or IP), authenticated with digest credentials or a source IP allowlist.
4. A number-to-agent mapping inside the platform, so an arriving call is answered by the right assistant, agent, or room.
5. Agreed transport and codecs. UDP, TCP, or TLS for signaling, and a codec both sides support for media. G.711 is the near-universal baseline for PSTN interconnection; wideband codecs such as G.722 are available where both the platform and the provider support them.

If you can configure those five items, you can connect essentially any standards-based SIP provider to any of these platforms, which is why the platforms label the option “custom” or “bring your own.”

How inbound and outbound calls flow

Inbound and outbound calls traverse the same components in opposite directions, but the responsibilities differ at each step, which is why the two directions are usually configured separately.

Caption: Inbound calls travel from the caller through the carrier and trunk to the platform, which assigns an agent. Outbound calls start with an API request; the platform authenticates against the trunk, and the carrier terminates the call to the callee.

On the inbound side, the critical configuration lives with the provider: the DID must forward to exactly the SIP URI format the platform expects. On the outbound side, the critical configuration lives with the platform: it must know your provider’s termination address and present valid credentials. A working inbound path proves nothing about the outbound path, and vice versa, so both directions should be tested independently.

Vapi

Vapi treats external telephony as a credential object. Using the Vapi API, you create a SIP trunk credential of type byo-sip-trunk containing your provider’s gateway address and authentication details, either username and password or IP-based. You then create a phone number resource with provider byo-phone-number that links your DID to that credential, and assign an assistant to the number. Vapi documents dedicated flows for a few named carriers alongside the Custom BYO SIP Trunk option, which is the standard path for any provider that implements ordinary SIP.

Inbound calls work by forwarding the DID at your provider to the SIP URI Vapi associates with your account and number. Outbound calls are placed through the trunk credential, so the caller ID shown is your own DID.

One operational detail worth knowing: Vapi is hosted in regions. If your organization is hosted in the EU, the trunk credential and BYO phone number must be created through Vapi’s EU API base URL rather than the default one, and the API region must stay consistent across the credential and the number. Mixing regions is a common cause of numbers that appear configured but never receive calls.

Reference: Vapi SIP trunk documentation.

Retell

Retell documents two ways to connect your own telephony. The recommended method is elastic SIP trunking: you configure origination and termination against Retell’s SIP server at sip.retellai.com, then import the number into Retell and assign it to an agent. With this method, the telephony features Retell supports on its bundled numbers also work on imported numbers, provided your provider supports them. For encrypted signaling, Retell’s documentation specifies the TLS form of the server URI (sip:sip.retellai.com;transport=tls), and SRTP media encryption is supported when TLS transport is used.

Because Retell’s SIP infrastructure is not published as a single fixed IP address, digest credentials are the more dependable authentication method for outbound calls; if you rely on IP allowlisting, you need to track Retell’s published IP information and keep your provider’s allowlist current.

The second method is dialing to a per-call SIP URI: your own telephony system registers the call through Retell’s API and then dials a call-specific URI on Retell’s SIP server. This suits complex existing telephony estates, but it shifts call-control responsibilities to your side; for example, transfer behavior differs from the elastic trunking method, so check the current custom telephony documentation before choosing it.

Reference: Retell custom telephony documentation.

LiveKit

LiveKit is a lower-level building block than the other three: it is a realtime media platform with an agents framework, and its SIP support is part of a broader telephony stack. Instead of importing a number into a dashboard and picking an assistant, you create trunk objects and routing rules.

For inbound calls, you create an inbound trunk, which restricts accepted calls by phone number or source, and a dispatch rule, which decides which room an arriving call joins and therefore which agent answers it. Your provider forwards the DID to your LiveKit SIP endpoint; by default this is a global endpoint that routes each call to the nearest region, and region pinning is available when traffic must stay in a specific region.

For outbound calls, you create an outbound trunk containing the provider’s termination address, your numbers, and the authentication username and password, then place calls by creating a SIP participant in a room where your agent is already running.

LiveKit supports TLS signaling (typically on port 5061) and a media encryption parameter that can allow or require SRTP. Username and password authentication is supported on inbound trunks as well, but only if the provider also supports registering trunks with credentials, so this should be confirmed with your provider.

Reference: LiveKit SIP trunk setup documentation.

ElevenLabs

ElevenLabs Agents connects external telephony through a number import flow: in the Phone Numbers section of the dashboard, you import a phone number from a SIP trunk, supply your provider’s details, and assign an agent to the number. The stated goal of the integration is to let existing phone systems, including PBX platforms, route calls to ElevenLabs agents without replacing the telephony underneath.

Inbound calls must be sent to ElevenLabs’ SIP endpoint using the URI format its documentation specifies, which identifies the imported number; calls sent to the bare endpoint without the proper identifier are a documented failure mode. Outbound calls initiated by ElevenLabs are routed to the hostname you configured for the trunk, and outbound calls can also be triggered through a dedicated API endpoint.

Authentication supports both digest credentials and access control lists based on the signaling source IP. Signaling supports multiple transports including TLS, and the RTP stream can be encrypted according to the media encryption setting you choose. For organizations whose security policy requires IP allowlisting, ElevenLabs offers SIP servers with static IP addresses for enterprise customers, published as an address block spread across several regions.

Reference: ElevenLabs SIP trunking documentation.

Platform comparison

Transport, encryption, and codecs

Three configuration areas account for most quality and connectivity problems after the initial setup works.

Transport. SIP signaling can run over UDP, TCP, or TLS. UDP on port 5060 is the traditional default; TLS on port 5061 encrypts the signaling. When switching to TLS, change the transport, not just the port, because some systems treat port 5061 with UDP or TCP as ordinary unencrypted traffic on a nonstandard port.

Encryption. TLS protects only the signaling. The audio itself is encrypted separately with SRTP, and both sides must agree on it. A frequent misconfiguration is requiring SRTP on one side while the other side has media encryption disabled, which produces calls that connect and then drop, or connect with no audio.

Codecs. G.711 remains the safest interoperability baseline because it is what the PSTN side almost universally speaks. Wideband codecs such as G.722 carry more audio detail, which can help speech recognition accuracy, but only when the platform, the trunk, and the carrier path all support the codec end to end. Forcing an exotic codec that gets transcoded along the way adds processing without adding quality.

Common mistakes

• Testing only one direction. Inbound and outbound are separate configurations with separate failure modes. Test both before going live.
• Wrong number format. Most of these platforms expect strict E.164. A missing plus sign or a nationally formatted number is one of the most common reasons an otherwise correct setup fails.
• Region mismatches. Creating a Vapi credential in one region and the number in another, or ignoring LiveKit region routing when compliance requires regional traffic, produces hard-to-diagnose silent failures.
• IP allowlists that go stale. If the platform’s SIP infrastructure is not a fixed IP, an allowlist that worked at setup can break later. Prefer digest credentials where the platform recommends them.
• Blaming SIP for AI latency. If signaling completes quickly and audio is clean, response lag typically comes from the speech and language pipeline. Measure the legs separately before changing trunk settings.
• Treating the platform as the number owner. In a BYO setup the numbers belong to your relationship with the infrastructure provider. Keep provisioning documents and ownership records with the provider account, not the AI platform account.

Setup checklist

1. Buy the DID numbers you need and complete any required local documentation for the country.
2. Create SIP credentials with your infrastructure provider and note the termination address and supported transports.
3. Configure the trunk in the AI platform: gateway address, credentials, and transport.
4. Link each DID to the trunk in the platform and assign an agent, assistant, or dispatch rule.
5. Configure inbound forwarding at the provider to the exact SIP URI the platform specifies.
6. Place a test call in each direction and verify caller ID, audio in both directions, and clean call teardown.
7. If you need encryption, enable TLS and matching SRTP settings on both sides and retest.
8. Load-test concurrency before campaigns, and confirm channel and calls-per-second limits with your provider.

Where didlogic fits

didlogic provides the voice infrastructure layer in this architecture: DID numbers, SIP trunking, and carrier routing between the AI platform and the public phone network. The AI platform you choose continues to own speech recognition, the language model, speech synthesis, and conversation logic; didlogic carries the call to and from the PSTN.

In practice this means you provision local or toll-free numbers from didlogic’s coverage across 130+ countries, create SIP credentials, and add them to the BYO trunk settings of Vapi, Retell, LiveKit, or ElevenLabs, with digest authentication, UDP or TLS signaling, and SRTP available on request. didlogic publishes setup guides for these platforms, including a step-by-step Vapi configuration guide, and describes the overall model on its AI voice infrastructure page and bring your own carrier page. Because the numbers and trunks live at the infrastructure layer, they stay in place if you later change AI platforms, an approach discussed further in didlogic’s article on why AI voice depends on telecom infrastructure. Developers integrating programmatically can start from the SIP trunking for developers page.

Frequently asked questions

Do I need a separate trunk for each AI platform?
Not necessarily, but it is good practice. Separate SIP credentials per platform make authentication, capacity limits, and call records easier to manage, and let you migrate or run platforms in parallel without touching a working configuration.

Can I keep my phone numbers if I switch from one platform to another?
Yes. In a bring-your-own setup the numbers are held with the infrastructure provider, not the AI platform. Switching platforms means repointing the DID forwarding and creating a new trunk configuration; the numbers your customers dial do not change.

Does the trunk or the platform determine call quality?
Both, in different ways. The trunk and carrier path determine network audio quality and delivery reliability. The platform determines how quickly and naturally the agent processes and responds. Diagnose them separately: signaling and media problems point to the telephony layer, response lag points to the AI pipeline.

Which authentication method should I use?
Use digest credentials unless you have a specific policy requiring IP allowlisting. Some platforms do not operate from a single fixed IP, which makes allowlists fragile; where allowlisting is mandatory, use a platform tier that publishes static addresses.

Do call transfers work over a BYO trunk?
Generally yes when the platform’s transfer mechanism (commonly SIP REFER) is supported end to end by both the platform and the trunk provider. Transfer behavior can differ between integration methods on the same platform, so verify it in your specific configuration before relying on it.

Can one trunk handle both inbound and outbound calls?
Yes. A single SIP account can carry both directions, although the inbound path (DID forwarding to the platform) and the outbound path (platform authenticating to the trunk) are configured and tested separately.

Continue learning

• What is a DID
• What is SIP
• What is SIP trunking
• How AI voice agents connect to the phone network