If you already run a SIP trunk with a carrier you trust, the last thing you want is to rip it out just to add an AI voice agent. You negotiated those per-minute rates. Your numbers are printed on invoices, listed in directories, and wired into your CRM. Switching carriers to get AI on the line is a bad trade.
The good news: you do not have to. Bringing your own carrier (BYOC) lets you keep the trunk you already have and layer an AI voice agent on top of it, for both inbound and outbound calls. This post is the practical, step-by-step guide to doing exactly that: what BYOC means, why it beats switching, the full setup, and the gotchas that trip people up.
Already have a trunk? You can connect any standards-compliant SIP trunk and keep your carrier, numbers, and rates. See Bring Your Own SIP Trunk for the product details, then follow the steps below.
Quick verdict (TL;DR)
Connecting your own SIP trunk to an AI voice agent comes down to four moves: add your carrier, define inbound and outbound gateways, authenticate (static IP or SIP registration), and point a number at an agent.
| Step | What you do |
|---|---|
| 1. Add carrier | Enter your SIP host (IP or hostname) and pick an auth mode |
| 2. Add gateways | Define inbound and outbound endpoints, transport (UDP/TCP/TLS), and port |
| 3. Authenticate | Whitelist the Edesy SIP IP (static-IP trunks) or register with credentials |
| 4. Point a DID | Add your E.164 number and assign it to a voice agent |
If your trunk speaks standard SIP, it works. There is no fixed carrier allow-list, no porting, and no new carrier relationship required.
What BYOC actually means
BYOC stands for "bring your own carrier." Instead of buying telephony bundled inside a voice-AI platform, you connect the SIP trunk you already own. The AI voice agent handles the conversation; your carrier handles the calls and the billing.
The connection is deliberately provider-agnostic. It is a generic SIP integration, not a certified, carrier-specific plug-in. That distinction matters: because it speaks standard SIP, a trunk from almost any carrier will work the same way, including your Twilio, Telnyx, Tata, or Airtel trunk. You are not waiting for a special integration to be built. You configure the SIP host, port, transport, and authentication, and any standards-compliant trunk connects.
Calls terminate on Edesy's managed SIP infrastructure, accessed through the Edesy Voice API. Put plainly: you manage the trunk, and Edesy runs the media path and the AI agent. You keep the carrier relationship and the numbers; the platform does the voice orchestration.
Why bring your own trunk
There are three durable reasons teams choose BYOC over switching carriers.
Keep your carrier. If you are already contracted with a SIP provider, there is no reason to port away. No new carrier onboarding, no migration project, no renegotiation. You connect the trunk you have.
Keep your rates. You continue paying your carrier directly at your negotiated per-minute rates. The AI runs on top of your existing telephony rather than reselling minutes back to you at a markup. For high-volume contact centers, keeping a hard-won rate card is often the whole business case.
Keep your numbers. Point the DIDs you already own at an AI agent. No re-provisioning, no updating the number on a thousand marketing assets. Inbound callers dial the same number they always have; it just reaches an AI agent first now.
If none of those apply to you, a provider account might be simpler, and we cover that trade-off in SIP Trunk vs Provider Integration for AI Voice Agents.
Step 1: Add your carrier
Start in the SIP Trunks settings. Create a carrier and give it the two essentials:
- SIP host — an IP address or a hostname such as
sip.yourcarrier.com. This is where signaling goes. - Authentication mode — either static IP (ACL / IP-based auth) or SIP registration with a username, password, and realm.
That is the carrier record. It represents your telephony provider inside the platform. Everything else hangs off it.
Static IP vs registration auth
This is the single most important decision in the whole setup, so get it right up front.
- Static IP (ACL). Common for peered, dedicated trunks. There is no login; instead, your carrier trusts calls coming from a known IP, and Edesy trusts calls from your trunk's IP. You will whitelist the Edesy SIP IP on your carrier side (see Step 3). No credentials are exchanged.
- SIP registration. The trunk authenticates with a username, password, and realm, the same way a SIP phone registers to a PBX. This suits trunks that expect a dynamic client to log in rather than a fixed peer.
You choose per trunk. If your carrier gave you an IP to point at and asked for your IP in return, you are on static IP. If they gave you a username and password, you are on registration.
Step 2: Add inbound and outbound gateways
A carrier can have more than one endpoint, so gateways are where you define the actual SIP endpoints and how calls flow.
For each gateway, set:
- Direction — inbound, outbound, or both. Inbound gateways receive calls destined for your agent; outbound gateways carry the calls your agent dials.
- Transport — UDP, TCP, or TLS, chosen to match what your carrier supports. The default is UDP on port 5060. Pick what your carrier documents; do not assume TLS is on by default.
- Port — default 5060, or whatever your carrier specifies.
- Priority — so you can define failover order if you have multiple gateways.
You can run inbound and outbound on the same trunk. Incoming calls route to the AI agent, and outbound campaigns dial out through the same carrier. Both directions are first-class.
Dial-format controls that save you headaches
While configuring gateways, set the dial-format options your carrier expects:
- Tech prefix — an outbound prefix some carriers require to route or classify calls.
- E.164 with leading-+ control — decide whether numbers carry the leading
+. Some trunks want+919876543210; others want919876543210. Getting this wrong is the most common reason outbound calls fail with a "number not found" error. - DTMF mode — RFC 2833, in-band tones, or SIP INFO, for touch-tone handling mid-call. Match your carrier so IVR digits and menu navigation land correctly.
Step 3: Whitelist the Edesy SIP IP
For static-IP (peered) trunks, your carrier needs to trust signaling from Edesy. Allow the Edesy SIP IP on your carrier side so inbound and outbound signaling is accepted. This is the reciprocal of your carrier handing you an IP to dial.
Registration-based trunks skip this step entirely. They authenticate with your username, password, and realm instead of trusting an IP, so there is nothing to whitelist.
If calls fail right after setup and you are on a static-IP trunk, the whitelist is the first thing to check. An un-whitelisted IP looks exactly like a dropped or rejected call.
Step 4: Point a number at an agent
The final step connects a phone number to a specific voice agent.
- Add your DID in E.164 format (for example,
+919876543210). The number must be one your carrier has leased to you and pointed at us. - Assign it to a voice agent. Inbound calls to that number route to the assigned agent, with its own prompts, voice, and integrations. Outbound calls for that agent dial through your trunk.
You can map different DIDs to different agents, so a sales line and a support line each reach the right AI persona on the same trunk.
Inbound vs outbound: what changes
The trunk is the same; the flow differs.
- Inbound. A caller dials your DID. The call reaches your carrier, which forwards it over the inbound gateway to Edesy's managed SIP infrastructure, where the assigned agent answers. Requirements: an inbound gateway, a DID pointed at us, and (for static-IP trunks) the whitelist in place.
- Outbound. The agent initiates a call. It leaves through your outbound gateway, hits your carrier, and dials the destination on your rates. Requirements: an outbound gateway, correct E.164/tech-prefix formatting, and enough capacity on your trunk.
Because both share the carrier, you provision once and run campaigns and reception on the same telephony.
Requirements and common gotchas
Before you start, make sure you have:
- E.164 numbers. All DIDs and destinations should be in E.164, with the leading-+ behavior matched to your carrier.
- DIDs leased from your carrier and pointed at us. The number stays yours; you just direct its inbound routing to Edesy.
- The Edesy SIP IP whitelisted on your carrier side for static-IP trunks.
- Confirmed transport and port. UDP, TCP, or TLS, on the port your carrier expects. Default is UDP/5060.
The gotchas that cost people the most time:
- Assuming TLS/SRTP is on by default. It is not — the default transport is UDP. Enable TLS only if your carrier supports and expects it.
- Leading-+ mismatches on E.164 numbers, causing outbound failures.
- Forgetting the SIP IP whitelist on static-IP trunks.
- DTMF mode mismatch, so menu digits do not register during a call.
For standard setups this is self-serve in the SIP Trunks settings. For more complex peering, the Edesy team helps you onboard. If you would rather not manage a trunk at all, a provider account is the alternative, and Telephony Providers covers that path.
Frequently asked questions
Which SIP carriers can I connect?
Any standards-compliant SIP trunk. The connection is provider-agnostic, so you configure the SIP host, port, transport, and authentication, and a trunk from any carrier that speaks standard SIP will work. There is no fixed allow-list of carriers, and no waiting for a certified integration to be built for your provider.
Can I use my Twilio, Telnyx, Tata, or Airtel SIP trunk?
Yes, as long as it is a standard SIP trunk. Because the connection is generic SIP, a trunk from any of those carriers connects the same way, using its host or IP, port, transport, and either IP-based or registration authentication. To be clear, this is a generic SIP connection, not a carrier-specific certified integration. The mechanics are identical regardless of who your carrier is.
Does BYOC work for both inbound and outbound calls?
Yes. You define inbound and outbound gateways on your carrier, so incoming calls route to a voice agent and outbound calls dial out through your trunk. Both directions run on the same trunk. Provision the gateways once and you can handle reception and outbound campaigns together.
Static IP or SIP registration — which should I pick?
Whichever your carrier gave you. If they provided an IP to dial and asked for your IP in return, use static IP (ACL) and whitelist the Edesy SIP IP on your side. If they gave you a username, password, and realm, use SIP registration. You choose per trunk, and both are fully supported.
Do I keep my existing phone numbers?
Yes. Point the DIDs you already own at an AI agent in E.164 format. There is no porting and no re-provisioning; the numbers stay with your carrier. Inbound callers dial the same numbers as always, and those calls now reach an AI agent first.
Conclusion
Connecting your own SIP trunk to an AI voice agent is a four-step job: add your carrier, define inbound and outbound gateways with the right transport and port, authenticate by static IP or registration, and point an E.164 DID at an agent. Keep your carrier, keep your rates, keep your numbers, and add AI on top for both inbound and outbound.
Ready to connect? Start with the Bring Your Own SIP Trunk feature page, or sign up and set up your trunk in the SIP Trunks settings. If your peering is complex, the team helps you onboard.
Related resources
- Bring Your Own SIP Trunk — the BYOC feature hub and configuration reference
- Telephony Providers — use a Twilio, Exotel, or Plivo account instead of your own trunk
- BYOK & BYOP — bring your own AI keys and providers
- WebRTC Browser Calls — take calls in the browser, no trunk needed
- SIP Trunk vs Provider Integration for AI Voice Agents — decide between BYOC and a provider account
- AI Voice Agent — the full voice agent platform