Answer in brief: Connecting an AI voice agent to your own SIP trunk is four settings, not a project: origination pointed at the platform SIP host, its signalling IPs allowlisted, a media port range opened (Vapi uses UDP 40000-60000), and one authentication mode chosen. Values differ by platform, and none validates your trunk before the first call.
This page covers the seam between an AI voice platform and a carrier trunk: SIP hosts, transports, codecs, authentication, IP allowlists and SDP offer style. Every figure below was read from the vendor’s own documentation on 10 September 2026 and is attributed in the sources table. Retell, Vapi, LiveKit and Twilio each publish a competent single-vendor setup guide; what none of them publishes is the interop constraint that breaks the call when the two sides disagree, because that constraint belongs to neither vendor.
How do I connect my AI voice agent to my own SIP trunk?
Seven steps, in this order. The order matters because steps 3 and 4 are configured in different consoles and each is invisible to the other.
- Day one, before you open any console: ask your carrier, in writing, whether your trunk gets a termination SIP URI or SIP host unique to your account. That one answer decides your authentication mode and roughly half of everything below.
- Collect the platform side. The SIP host you will point at, its signalling IP addresses, its supported transports and its media port range. These are in the interop matrix below.
- Configure origination on the carrier so calls arriving on your DID are sent to the platform’s SIP host. This is carrier-to-platform and it lives in the carrier’s console.
- Configure termination on the platform using the termination URI your carrier gave you, plus credentials if you are using them. This is platform-to-carrier and it lives in the platform’s API or dashboard.
- Choose one authentication mode and apply the unique-URI rule below. Do not configure IP authentication and credentials as a hedge without checking how the carrier treats the combination; Twilio, for one, states that if you configure both, both are enforced.
- Open media. RTP is a separate flow from signalling and a separate firewall rule. Signalling can complete perfectly with zero audio, which is the single most common shape of a first failed call.
- Place one call in each direction and pull the SIP trace from the carrier, not from the platform.
The finish state: you are done when an inbound call and an outbound call each reach a 200 OK, carry two-way audio for at least 30 seconds without a media timeout, and appear as a matching leg in your carrier’s call detail records. Anything short of all three is a partly configured trunk that will fail in production.
The BYO trunk interop matrix
This is the table the single-vendor guides do not print: the same eight decisions, side by side, for the three AI voice platforms that publish BYO trunk documentation, plus Twilio Elastic SIP Trunking as a representative carrier side. Read from each vendor’s own docs on 10 September 2026.
Part 1: where you point, and what you allowlist.
| Platform | SIP host you point at | Signalling transports | Authentication | IPs to allowlist | Media / RTP |
|---|---|---|---|---|---|
| Retell AI | sip:sip.retellai.com (origination only; Retell states it has no termination URI of its own) |
TCP (recommended), UDP, TLS, mTLS, appended as ;transport=tcp |
Carrier-side; Retell publishes IP blocks to allowlist | Five blocks: 18.98.16.120/30, 3.42.144.0/23, 153.57.128.0/18 (all regions), 143.223.88.0/21, 161.115.160.0/19 (certain US traffic) |
No RTP port range of Retell’s own that we could locate in the full Retell documentation text at docs.retellai.com/llms-full.txt, read 10 September 2026; the port ranges that text does carry belong to your SBC, not to Retell |
| Vapi (US) | sip.vapi.ai; inbound URI form {phoneNumber}@<credential_id>.sip.vapi.ai |
UDP/TCP on 5060, TLS on 5061; gateway outboundProtocol accepts udp, tcp, tls, tls/srtp (default udp) |
Credentials recommended; IP auth discouraged on shared servers | 44.229.228.186/32, 44.238.177.138/32 |
Dynamic media source IPs; UDP 40000-60000, full range required |
| Vapi (EU) | sip.eu.vapi.ai, paired with api.eu.vapi.ai |
As above | As above | 63.182.83.170/32 |
Static media IP 63.182.83.170; UDP 40000-60000 |
| LiveKit Cloud | sip:{subdomain}.sip.livekit.cloud, derived from your project ID with the p_ prefix removed |
SIPTransport enum: auto, UDP, TCP, TLS |
Per inbound trunk: allowed_numbers, or auth_username plus auth_password, or allowed_addresses (which must be enabled for your project by LiveKit support) |
Published, but not in the telephony docs: 143.223.88.0/21, 161.115.160.0/19, 153.57.128.0/18, on the Regions and static IPs page under Manage & Deploy, stated to apply to SIP signalling and media. Canada, EU, India, Japan and US only; LiveKit states all other regions must use wildcard domains |
No SIP media port range we could locate anywhere in the LiveKit documentation on 10 September 2026; the static IP blocks above are stated to cover SIP media as well as signalling |
| Twilio Elastic SIP Trunking (carrier side) | Termination URI {example}.pstn.twilio.com, or a localised form such as {example}.pstn.ashburn.twilio.com |
UDP by default; TCP or TLS via the transport= parameter on the origination URI, TLS on port 5061 by default, TLSv1.2 and above |
IP Access Control Lists and/or Credential Lists. Twilio: You must configure a minimum of either an ACL or credential authentication. | Eight regional signalling gateways on /30 blocks, ports 5060 (UDP/TCP) and 5061 (TLS) |
Global media range 168.86.128.0/18, UDP destination ports 10,000 to 60,000 |
Part 2: what happens once the INVITE lands.
| Platform | Codecs offered | Media encryption | SDP offer style | Cold transfer |
|---|---|---|---|---|
| Retell AI | PCMU, PCMA, G.722 (HD) | SRTP, and Retell states the transport must be set to TLS to use it | Not stated on that page; Retell does document answering in-dialog re-INVITEs, including codec changes and SRTP re-keys | SIP REFER, which you must enable on the provider side along with PSTN transfer |
| Vapi (both regions) | No codec list we could locate on any page in the Vapi documentation index at docs.vapi.ai/llms.txt, every page of which we searched on 10 September 2026 |
TLS signalling on 5061; SRTP via the tls/srtp gateway option |
Not stated on those pages | SIP REFER via a transferCall tool with a sip: destination; may need enabling at the provider |
| LiveKit Cloud | PCMU, PCMA, G722 by default; AMR-WB available but off by default | SIPMediaEncryption: disable, allow, or require |
Early offer only. LiveKit: LiveKit only supports early offers. | SIP REFER |
| Twilio Elastic SIP Trunking | PCMU and PCMA generally available; G.729, Opus and AMR-NB in Limited Availability | Secure Trunking: origination offers AES_CM_128_HMAC_SHA1_80, termination also accepts _32; MKI not supported; with Secure Trunking on, non-encrypted calls are rejected |
Not stated in these terms | Twilio: When Call Transfer is enabled, Twilio will consume an incoming SIP REFER from your communications infrastructure and create an INVITE message to the address in the Refer-To header. |
Read the two tables together and the first real interop trap is visible without a packet capture: Retell and LiveKit both offer G.722, and Twilio Elastic SIP Trunking supports PCMU and PCMA as its generally available codecs. An HD-voice offer meeting a G.711 answer still connects; it just quietly downgrades, and the wideband quality someone specified in a requirements document never arrives.
Origination and termination are configured on opposite sides
Almost every trunk that half-works is a direction problem. Origination is inbound, carrier into platform, and it is configured in the carrier’s console. Termination is outbound, platform out through the carrier, and it is configured in the platform, using a URI the carrier issues. Retell says this about as plainly as it can be said: Retell does not have a termination SIP URI of its own. sip:sip.retellai.com is Retell’s only SIP address, and it’s used as the origination URI on your provider’s side.
The practical consequence: if inbound works and outbound does not, stop looking at the platform, because you have almost certainly given it the wrong termination URI or none. If outbound works and inbound does not, the origination setting on the carrier is wrong, or the platform’s signalling IPs are not on your allowlist. Vapi documents exactly that symptom: Please ensure that you provide all the signaling IP addresses when creating the SIP trunk. Failure to do so will prevent proper whitelisting, which may result in encountering unauthorized 401 errors for inbound calls.
IP authentication or credentials? The unique-URI rule
The unique-URI rule: use IP-based authentication only if your carrier issues a termination URI or SIP host that is unique to your trunk. If the platform you are calling sits behind a SIP host shared with its other customers, use digest credentials instead.
This is not a preference. Vapi publishes the failure mode in its own documentation: We generally don’t recommend IP-based authentication for SIP trunks as it can lead to routing issues. Since our servers are shared by many customers, if your telephony provider has multiple customers using IP-based authentication, calls may be routed incorrectly. IP-based authentication works reliably only when your SIP provider offers a unique termination URI or a dedicated SIP server for each customer, as is the case with Plivo and Twilio integrations. The shared-host problem is structural: the platform can see which IP sent the INVITE, but if two of its customers use the same carrier and that carrier authenticates by IP, the platform cannot tell whose call it is.
Twilio makes the security half of the same argument from the carrier side, advising that user credentials are highly recommended and that IP ACLs alone do not protect against certain types of attacks. So the rule has two exits and no third: a unique URI makes IP authentication safe, and the absence of one makes credentials mandatory rather than optional.
One Vapi-specific corollary worth knowing before you file a support ticket: Vapi documents that inbound gateways accept IPv4 addresses only, and that supplying a hostname with inboundEnabled: true causes the SBC to reject the gateway configuration.
The Five-Seam Preflight, and why you cannot skip it
Here is the fact that shapes this entire page, quoted from Retell’s own FAQ: No, Retell will not be able to know if the setup you provide works or not until a call is made. No platform in the matrix validates a trunk at configuration time. The configuration is accepted, the console goes green, and the first real caller is your test.
So run the Five-Seam Preflight before that caller exists. One seam per line, one check each, and each one fails in a way you would otherwise misread as something else.
| Seam | The check | What it looks like when it is wrong |
|---|---|---|
| 1. Transport | Both sides on the same transport, with the parameter actually appended to the URI (Retell requires ;transport=tcp in the SIP server URL, not just a console setting) |
The INVITE never arrives, or arrives on 5060 when you configured TLS on 5061 |
| 2. Authentication | The unique-URI rule applied, and every one of the platform’s signalling IPs in your allowlist, not just the first | 401 Unauthorized on inbound, or calls landing on someone else’s account |
| 3. Media | The full RTP port range open, bidirectionally, as a rule separate from signalling | The call connects and both parties hear silence; a media timeout ends it |
| 4. Codec | At least one codec in common, checked against both published lists, not assumed | Either no audio, or a silent downgrade from wideband to G.711 |
| 5. Offer | Your carrier sends an early offer if the platform requires one | Setup fails on a trunk that works with every other customer the carrier has |
Seam 5 is the one people have never heard of, and it is binary. LiveKit’s codec documentation states flatly that LiveKit only supports early offers, meaning the SDP must be in the initial INVITE. A carrier configured for delayed offer, where the SDP arrives later in the exchange, will not interoperate at all; there is no tuning that fixes it, only a change of trunk configuration.
Seam 4 has a second-order version worth planning around: LiveKit notes that every codec added to the SDP increases the size of the INVITE packet, and that on UDP transport large packets can fragment and get lost on some networks. Enabling more codecs to be safe is therefore not free, which is exactly why LiveKit ships only_listed_codecs to strip the defaults rather than only ever adding to them.
And a documented failure to keep in view even after all five seams pass. In livekit/agents issue 5847, open since 26 May 2026, a developer running one inbound trunk with several numbers reports that a dispatch rule filtered to a specific number never matches, while the same rule with the number filter removed matches instantly. Their words: I have attempted to format the phone number string in every variation (+E.164, E.164 without +, raw digits, local format), but the dispatch rule still refuses to match when the filter is active.. The trunk was fine. The routing layer above it was not, and no SIP trace would have shown it. If you are sharing one trunk across several numbers, test each number individually rather than testing the trunk once.
Two numbers to work out before you open a firewall ticket
Both of these are arithmetic on published figures, shown end to end so you can substitute your own.
Calculation 1: how large is the allowlist, really? Retell publishes five CIDR blocks. Expanded to individual IPv4 addresses:
| Block | Prefix | Addresses |
|---|---|---|
18.98.16.120/30 |
/30 | 4 |
3.42.144.0/23 |
/23 | 512 |
153.57.128.0/18 |
/18 | 16,384 |
143.223.88.0/21 |
/21 | 2,048 |
161.115.160.0/19 |
/19 | 8,192 |
| Total | 27,140 |
4 + 512 + 16,384 + 2,048 + 8,192 = 27,140 individual IPv4 addresses. That number is the point: if the appliance holding your allowlist takes individual entries rather than CIDR blocks, or caps the number of entries, this trunk is not configurable by hand and you need to know that on day one, not during a change window. The same arithmetic on Twilio’s global media range 168.86.128.0/18 gives another 16,384 addresses on the media path alone. Worth noticing before you write two firewall tickets: three of Retell’s five blocks — 153.57.128.0/18, 143.223.88.0/21 and 161.115.160.0/19, 26,624 of the 27,140 addresses — are character for character the three blocks LiveKit publishes as its static IP ranges, on each vendor’s own page read 10 September 2026.
Calculation 2: bandwidth and ports. Twilio publishes the sizing formula directly: SIP Trunk Peak Bandwidth = Max Simultaneous Calls x 100 kbps, and notes that the 100 kbps figure covers the G711 codec plus overhead. For an agent fleet sized at 40 concurrent calls, that is 40 x 100 = 4,000 kbps, or 4 Mbps in each direction, on a circuit that is probably already carrying your staff. Ports are the other half of the ask: Vapi’s 40000-60000 range is 20,001 UDP ports, and Twilio’s media range of 10,000 to 60,000 is 50,001. Network teams say no to vague requests and yes to specific ones, so bring both numbers.
What a BYO trunk actually costs to run, and when not to bring one
The honest accounting. A BYO trunk adds a permanent second vendor relationship to your voice stack. You now own the seam: when audio is one-way, the platform will point at the carrier and the carrier will point at the platform, and neither is being unreasonable, because the fault genuinely lives between them. You need someone who can read a SIP trace, access to the carrier’s CDRs, and a change window for firewall rules. Number provisioning, regulatory registration and caller-ID reputation stay yours too, which is a real workload rather than a footnote; our note on how long a US AI voice agent launch really takes covers the registration path that runs in parallel with all of this.
| Bring your own trunk when | Use the platform’s numbers when |
|---|---|
| You already own the numbers and porting them is worse than trunking to them | You are validating whether AI calling works for your business at all |
| Your carrier rates at your volume beat the platform’s per-minute pricing by enough to fund the engineering | Nobody on the team reads SIP traces without help |
| A regulator, a procurement policy or a data-residency requirement names your carrier | You need to be live this month |
| You need the trunk to survive a platform change, so the numbers never move again | Your call volume does not yet justify a second vendor relationship |
Two adjacent problems are commonly mistaken for trunk problems and are worth eliminating first. If transfers to humans are failing, that is usually configuration above the trunk rather than the trunk itself, which we worked through in why an AI voice agent transfer to a human stops working. If inbound calls are the concern, the line itself needs preparing before any agent answers it, covered in preparing your phone lines for inbound AI callers.
Sources, and who owns each figure
| Figure or quotation | Owner | Source, read 10 September 2026 |
|---|---|---|
| SIP host, transports, SRTP condition, codecs, five IP blocks, no termination URI, SIP REFER requirement, the until-a-call-is-made FAQ | Retell AI | docs.retellai.com/deploy/custom-telephony |
Regional SIP hosts, IP-authentication warning, BYO trunk and phone-number flow, 401 note, inbound gateway IPv4 constraint, outboundProtocol options |
Vapi | docs.vapi.ai/advanced/sip/sip-trunk and the gateway configuration reference |
| Signalling IPs, ports 5060 and 5061, RTP range 40000-60000, dynamic versus static media | Vapi | docs.vapi.ai/advanced/sip/sip-networking |
Project SIP URI form, inbound trunk authentication options, SIPTransport and SIPMediaEncryption enums |
LiveKit | SIP trunk setup and the SIP API reference |
| Static IP blocks, the regions they cover, and that they apply to SIP signalling and media | LiveKit | Regions and static IPs and Configuring firewalls |
| Early-offer-only limitation, default and extra codecs, INVITE packet-size caveat | LiveKit | docs.livekit.io/reference/telephony/codecs-negotiation |
| Termination URI form, authentication minimum, transports, TLS and SRTP specifications, Call Transfer via SIP REFER, bandwidth formula | Twilio | twilio.com/docs/sip-trunking |
| Eight regional signalling gateways, ports, global media range and port range | Twilio | twilio.com/docs/sip-trunking/ip-addresses |
| Generally available and Limited Availability codec lists | Twilio | twilio.com/docs/sip-trunking/codecs |
| Dispatch rule not matching a filtered number on a shared trunk | Reporter in livekit/agents issue 5847, open since 26 May 2026 | github.com/livekit/agents/issues/5847 |
| Offer/answer model with SDP | IETF | RFC 3264 |
| The interop matrix, the unique-URI rule, the Five-Seam Preflight and both calculations | Zian AI | This page |
Where a cell says a value is not published, that means we searched that vendor’s full documentation index on 10 September 2026 — docs.vapi.ai/llms.txt, docs.retellai.com/llms-full.txt and docs.livekit.io/llms.txt — and did not find it, not that the vendor has no answer. Ask them. One negative claim in an earlier draft of this page was wrong for exactly this reason: LiveKit publishes no firewall page in its telephony docs, but does publish static IP ranges under Manage & Deploy, and they are in the matrix above.
Where to go from here
If you have a network engineer and a carrier relationship you like, the matrix above is enough to finish the job yourself; go and do it, and use the Five-Seam Preflight before the first live caller rather than after. If you would rather the seam be someone else’s problem, that is where Zian AI sits: autonomous sales agents that run the phone, SMS, email and WhatsApp outreach, with the telephony and the CRM and API integrations handled as part of the platform rather than as your integration project. Zian is in partnership-application beta, so there is no free trial and no self-serve signup; you talk to us first. More answers of this kind sit in the Zian AI questions and answers hub. Apply For Partnership and we will tell you plainly whether your numbers should move or stay where they are.
Frequently asked questions
Do I need my own SIP trunk to run an AI voice agent?
No. Every major platform will sell or provision numbers for you, and that is faster to launch. Bring your own trunk when you already own the numbers, when your carrier rates at your volume beat the platform per-minute price by enough to fund the engineering, when a regulator or procurement policy names your carrier, or when you want the numbers to survive a change of platform.
Why does my first inbound call come back as 401 Unauthorized?
Most often because the allowlist is incomplete rather than wrong. Vapi documents this directly, warning that you must provide all of the signalling IP addresses when creating the SIP trunk and that failing to do so prevents proper whitelisting and may result in unauthorized 401 errors for inbound calls. Vapi publishes two signalling addresses for the US region and one for the EU region. Add every address for your region, not the first one that resolves in DNS.
Should I use UDP or TCP for SIP signalling?
Retell lists TCP as recommended, with UDP, TLS and mTLS also supported, and requires the transport to be appended to the SIP server URL rather than set only in a console. There is a media-layer reason to prefer TCP as well: LiveKit notes that each codec added to the SDP increases the size of the INVITE packet, and that on UDP transport large packets can fragment and get lost on some networks. Use TLS on port 5061 if you need encrypted signalling.
Can I get HD voice through my own trunk?
Only if both ends offer a wideband codec. Retell lists PCMU, PCMA and G.722 as supported, and LiveKit enables PCMU, PCMA and G722 by default with AMR-WB available but off by default. Twilio Elastic SIP Trunking supports PCMU and PCMA as generally available codecs, with G.729, Opus and AMR-NB in Limited Availability. A wideband offer meeting a narrowband answer still connects, so the downgrade is silent and you will only notice it in the audio.
What is an early offer and why does it break my trunk?
In the offer and answer model defined by the IETF in RFC 3264, An Offer/Answer Model with the Session Description Protocol (SDP), one side describes the session it wants and the other answers. An early offer puts that description in the initial INVITE. A delayed offer sends the INVITE without it. LiveKit states that it only supports early offers, so a carrier trunk configured for delayed offer will not interoperate with it at all. This is a trunk setting on the carrier side and it is worth confirming before you debug anything else.
Why does my dispatch rule not match the number that was dialled?
It may not be your formatting. In livekit/agents issue 5847, open since 26 May 2026, a developer reports that a dispatch rule scoped to a specific number on a shared inbound trunk never triggers, while the same rule with the number filter cleared matches instantly, after trying every phone number format. If you route several numbers over one trunk, test each number on its own rather than testing the trunk once.
How do I know the trunk is configured correctly before I go live?
You cannot know from the configuration alone. Retell states in its own FAQ that it will not be able to know if the setup you provide works or not until a call is made. Treat the first call as the test it actually is: run the Five-Seam Preflight above, place one call in each direction, and confirm two-way audio for at least 30 seconds plus a matching leg in your carrier call detail records before you point any real traffic at it.