BYOC for Voice AI: Wiring Your Own SIP Trunks into AI Agents (and Why Telephony Margins Matter)

Every AI voice call rides on a phone line, and somebody pays for that line. If you run real call volume — thousands of minutes a day across collections, support, or appointment confirmation — the telephony layer quietly becomes one of your biggest line items.

Most voice AI platforms resell telephony: they buy minutes from a carrier, add a margin, and bill you a bundled rate. That is convenient at small scale. But if your business already has negotiated carrier rates, an inventory of DID numbers your customers recognize, or compliance requirements that dictate exactly which carrier handles and records your traffic, resold telephony works against you.

That is what Bring Your Own Carrier (BYOC) solves. You register your own SIP trunks with the platform, your calls flow over your carrier relationship at your rates, and the AI layer is billed separately from the telephony layer. This post walks through how BYOC actually works on the Zoice SIP platform — the trunk parameters you have to decide, what each tradeoff means in plain language, and a go-live checklist that catches the failures before your customers do.

When BYOC Beats Managed Telephony

Managed (resold) telephony is the right default when you are starting out: one vendor, one bill, zero carrier negotiations. BYOC starts winning in three situations:

• Negotiated carrier rates. If your existing carrier contract prices minutes below the platform's bundled rate, every resold minute is margin you are donating. At high volume the difference compounds fast.
• Existing DID inventory. Your customers already know your numbers. Porting them to a new provider is slow and risky; with BYOC the numbers stay on your trunk and simply get bound to AI agents for inbound routing.
• Compliance and recording requirements. Regulated industries often need calls to traverse a specific licensed carrier, stay within a jurisdiction, or be recorded under an existing arrangement. BYOC keeps the telephony path under your control while the AI handles the conversation.

The billing model reflects this split: on BYOC trunks you pay your carrier directly for minutes, and the platform bills only for the AI side. With resold telephony both are bundled. See the pricing page for how the two models are structured.

The Trunk Parameters You Actually Have to Decide

Registering a trunk is mechanically simple — host, port, save. The engineering judgment lives in five parameter groups, and each one has a real-world failure mode if you guess wrong.

Transport: UDP, TCP, or TLS

UDP is the telephony default — lightweight and universally supported, but signaling travels in cleartext. TCP adds reliable delivery for large SIP messages. TLS encrypts the signaling channel entirely, which matters when call metadata (who called whom, when) is itself sensitive. If you need encrypted media, TLS signaling is also the prerequisite for DTLS-SRTP.

Authentication: Digest Credentials or IP Allowlist

Two models, pick the one your carrier supports. Digest credentials work like a username and password challenge on each request — flexible, works from any IP. An IP-CIDR allowlist instead accepts traffic only from your carrier's published address ranges — no passwords to rotate, but you must keep the list current when the carrier changes infrastructure. One security note worth knowing: once you save a SIP password, the API never returns it again. You can overwrite it, but you cannot read it back — so store it in your own secrets manager too.

Codec Preference Order

The platform negotiates codecs in your stated preference order across PCMU, PCMA, opus, and G722. The practical guidance: PCMU and PCMA (the classic G.711 variants) are the safest interop choice with Indian carriers and PSTN gateways. Opus gives better quality per kilobit and handles jitter gracefully — prefer it when your carrier supports it end-to-end. G722 offers wideband audio on legacy-friendly infrastructure. Putting an exotic codec first costs you nothing when negotiation falls through, but a mismatched list against a strict carrier can mean dead air, so mirror what your carrier actually advertises.

Together with media encryption, DTMF, direction, and capacity limits, these decisions form the core components of every trunk — broken down below.

Tradeoffs at a Glance

Decision	Options	Pick this when
Transport	UDP / TCP / TLS	UDP for plain interop; TLS when signaling privacy or SRTP via DTLS is required
Auth	Digest / IP-CIDR allowlist	Digest for dynamic IPs; allowlist when the carrier publishes stable ranges
Media encryption	None / SRTP (SDES) / SRTP (DTLS over TLS)	SRTP whenever calls carry sensitive content; DTLS-SRTP if you are already on TLS
DTMF	RFC 2833 / SIP INFO / in-band	RFC 2833 by default; SIP INFO or in-band only if the carrier path mangles telephone-events
Direction	Inbound / Outbound / Both	Match the trunk's actual job — a campaign-only trunk should not accept inbound

Why DTMF Deserves Its Own Paragraph

DTMF is the most common silent failure in SIP integrations. RFC 2833 sends digits as dedicated RTP telephone-events — clean, timestamped, codec-independent. SIP INFO sends them in the signaling channel instead, which survives some media paths that strip events. In-band means the literal beep travels inside the audio stream — it works everywhere uncompressed audio works, but compressed codecs can distort the tones beyond recognition. If callers will key in OTPs, account numbers, or menu choices, test DTMF on a real call before launch, not after.

Capacity and Direction Are Guardrails

Per-trunk concurrent-call limits stop a runaway outbound campaign from saturating the channel capacity in your carrier contract — and from triggering carrier-side rejections that look like mysterious call failures. Direction settings (inbound, outbound, or both) are the equivalent guardrail for traffic shape. Set both deliberately; the roadmap below sequences this into a clean rollout.

The Go-Live Checklist

Before pointing production traffic at a new trunk, run through this list. Each item maps to a failure we see in real deployments:

• Probe the trunk. Every trunk has a test button that sends a real SIP OPTIONS probe to your carrier's host and port — not a simulated check. If the probe fails, nothing else matters: fix reachability, firewall rules, or the allowlist first.
• Verify auth both ways. A digest mismatch shows up as 401/407 rejections; an allowlist gap shows up as silently dropped packets. Confirm which model the trunk is using and test an actual call.
• Place bidirectional test calls. An outbound call proves codec negotiation; an inbound call to a bound DID proves number-to-agent routing. Both, not either.
• Test DTMF on a live call. Key digits during a test call and confirm the agent receives them. Switch modes if not.
• Confirm SRTP if required. If your compliance posture demands encrypted media, verify SRTP (SDES, or DTLS-SRTP over TLS) is actually negotiating — and review the broader controls on the security page.
• Set the concurrency cap. Match the per-trunk concurrent-call limit to your carrier contract before the first campaign, not after the first overage.

DIDs: Where Telephony Meets the AI Layer

Once the trunk is healthy, DIDs are the binding layer. Each number is owned by a trunk, and each number is bound to an AI agent — that binding is what decides which agent answers when the number rings. Keeping ownership at the trunk level means your number inventory moves with your carrier relationship, never with the platform.

FAQ

Can I run BYOC and managed telephony side by side?

Yes. Trunks are independent — a common pattern is keeping resold numbers for low-volume experiments while production traffic runs on your own carrier trunks, each with its own direction, codec, and capacity settings.

What happens to my SIP password after I save it?

It is write-only: the API never returns it after saving. You can replace it at any time, but you cannot retrieve it, so keep your own copy in a secrets manager.

Do I need TLS to use SRTP?

For DTLS-SRTP, yes — the key exchange rides on TLS signaling. SDES-based SRTP keys are exchanged in the SDP instead, which is why pairing SDES with unencrypted signaling weakens the guarantee. If you are encrypting media, encrypting signaling too is the consistent choice.

How do inbound calls find the right agent?

Through the DID binding: the number is owned by a trunk and bound to a specific AI agent. Ring the number, reach the agent — no separate routing table to maintain for the simple case.

If you are weighing BYOC against managed telephony for a real deployment, talk to our team and bring your carrier details — a working trunk is usually a same-day exercise.