Moving a phone operation to the cloud often exposes a hidden dependency: the software platform also wants to become the telecom provider. Bring Your Own Carrier (BYOC) separates those decisions. That separation can preserve numbers, contracts, routing, and regional coverage, but it also leaves your team responsible for more of the voice path. A sound evaluation must cover architecture, operating ownership, and failure testing, especially when the cloud application is a real-time voice AI agent.
What bring your own carrier means
In short: BYOC lets you connect your current or chosen telecom carrier to a cloud communications platform, usually through a Session Initiation Protocol (SIP) trunk. The carrier continues to provide phone numbers and public switched telephone network (PSTN) access. The cloud platform handles call control and application logic.
With Dasha, technical teams can connect a carrier over SIP, link a phone number to an agent for inbound or outbound calling, and keep the carrier edge separate from our managed voice AI backend. We also provide automatic Twilio trunk setup for teams that prefer a shorter path to their first production test.
A cloud phone, contact center, or voice AI platform needs a path to ordinary telephone numbers. The platform can bundle that path with its software, or it can accept calls from a carrier that you select and manage.
BYOC is the second model. It unbundles two layers:
| Layer | Main job | Typical owner in BYOC |
|---|---|---|
| Telecom carrier | Numbers, PSTN origination and termination, route coverage, caller identity, and carrier support | Your organization |
| Cloud communications platform | Call control, routing, agent or contact-center features, application events, and integrations | Platform provider |
| Business application | Conversation logic, data access, workflow rules, and outcome tracking | Your product or operations team |
The carrier and platform normally meet at a SIP trunk. The IETF defines SIP as a signaling protocol used to create, modify, and end sessions. SIP sets up the call and carries the session descriptions used to negotiate media parameters. The audio usually travels on a separate Real-time Transport Protocol (RTP) path.
This distinction matters during troubleshooting. A successful SIP response only proves that call signaling progressed. It does not prove that audio can travel in both directions.
BYOC compared with bundled telephony
| Question | BYOC | Bundled telephony |
|---|---|---|
| Who selects and contracts with the carrier? | You | The platform provider |
| Can existing carrier numbers stay in place? | Usually, when the carrier and trunk remain unchanged | A port or new numbers may be required |
| Who manages the SIP interconnection? | Shared across your team, carrier, and platform | Mostly the platform provider |
| Who investigates cross-provider call failures? | Your team coordinates both providers | The platform provider owns more of the path |
| Can the application layer change without a carrier migration? | Yes, if the replacement accepts the existing SIP design | Often requires a telephony change as well |
| Best fit | Teams with carrier requirements or telecom expertise | Teams optimizing for setup speed and one support owner |
BYOC is an operating model, not a guarantee of lower cost or better quality. Its value comes from choosing each layer on its own merits and retaining a practical migration path.
How BYOC works for inbound and outbound calls
A typical path has five parts:
- A caller or recipient connects through the PSTN.
- Your carrier originates or terminates the public telephone call.
- A SIP trunk carries signaling between the carrier side and the cloud platform. A session border controller (SBC) may sit at the boundary to enforce policy and normalize SIP.
- The platform accepts the call, runs routing or a voice agent, and invokes application tools.
- RTP or Secure Real-time Transport Protocol (SRTP) carries the audio negotiated for the session.
Inbound and outbound calling use the same components in opposite directions, but their policies often differ.
Inbound: The carrier receives a call to one of your numbers and sends a SIP INVITE toward the platform. The platform maps the called number to an application or agent, accepts the session, and exchanges audio.
Outbound: The platform starts the session and sends it to the carrier. The carrier applies its caller-ID policy and checks the route, destination, and account permissions before placing the PSTN call. Outbound calls are often subject to a calls-per-second (CPS) limit in addition to a concurrent-call limit.
In Dasha, manual carrier setup uses the carrier's SIP server, a phone-number record, authentication settings, transport, registration behavior, and the appropriate agent link. Our current configuration supports UDP, TCP, and TLS signaling. The jambonz SIP walkthrough shows the full inbound registration model. Teams comparing carriers can also use our SIP trunk provider guide to narrow the field before an interoperability test.
When BYOC is the right choice
BYOC earns its extra operational work when the carrier relationship has strategic value.
Use BYOC when you need to preserve telecom assets
Existing numbers may appear in advertising, customer records, authentication flows, or regulated filings. Keeping the current carrier can avoid a broad number migration. BYOC can also preserve negotiated rate cards, support arrangements, and contract terms while the application layer changes.
Use BYOC for country-specific coverage and routing
One bundled provider may not offer the right number types, outbound routes, emergency services, or local support in every country. A selected carrier or a small carrier portfolio can provide local access while one application platform runs the workflow.
Use BYOC to reduce platform lock-in
Carrier and runtime are separate architecture decisions. If your numbers and PSTN contracts sit with an independent carrier, you can evaluate another runtime without first porting the entire number inventory. This is useful for phased migrations, parallel testing, and multitenant products in which each customer brings a different carrier.
Use bundled telephony when simplicity matters more
Bundled telephony is often the better choice for a small deployment, a short pilot, or a team without SIP operations experience. One provider handles provisioning and has more end-to-end diagnostic context. You can still design the application so that a later BYOC migration is possible.
Treat cost savings as a hypothesis
BYOC can preserve a favorable carrier contract or lower high-volume route costs. It can also add platform ingress fees, SIP channels, SBC licensing, private connectivity, support, monitoring, and engineering work. Compare a loaded cost per successful outcome, including failed attempts and transfer legs, rather than comparing one advertised per-minute rate.
What BYOC changes for a voice AI product
Real-time agents expose interconnection problems that an ordinary office call may hide. The system must detect speech, produce a response, and play it before the pause feels broken. Four BYOC concerns deserve special attention.
Media routing becomes part of response time
The SIP signaling endpoint and RTP media endpoint can be in different places. Ask where media enters each network and whether you can select a regional point of presence. Measure caller-audible response time, jitter, packet loss, and one-way audio on the actual carrier routes. A low model or runtime latency cannot recover time already lost to a long or unstable media path.
Call starts and active calls are separate limits
Concurrency measures active calls. CPS measures how quickly new calls can begin. An outbound campaign may have spare concurrent capacity and still receive throttling when it starts calls too quickly. Document limits at the carrier, SBC, platform, and application queue, then apply the lowest safe rate.
Transfers can create new call legs
A SIP REFER, bridge, conference, and warm handoff behave differently. They can change which system stays on the call, how caller ID is presented, how many legs are billed, and where recordings or events continue. Test the exact transfer method used in production, including rejection, no answer, timeout, and the recipient hanging up first.
Caller identity still depends on the originating path
BYOC does not create trusted caller ID by itself. In the United States, STIR/SHAKEN allows phone companies to validate caller ID handoffs. Confirm which provider originates the call, which number it will authorize, what attestation it can provide, and how your calling behavior affects analytics and blocking. Treat number reputation as an operating metric, separate from SIP delivery success.
BYOC requirements to settle before configuration
Use an interoperability worksheet before anyone opens a firewall or creates a trunk.
| Area | Decisions to record | Production evidence |
|---|---|---|
| Signaling destination | IP addresses or fully qualified domain names, ports, DNS behavior, and regional endpoints | Calls reach every intended endpoint |
| Authentication | IP allowlist, digest credentials, SIP registration, mutual TLS, or a supported combination | Valid traffic is accepted and invalid traffic is rejected |
| Transport | UDP, TCP, or TLS, plus certificate and cipher requirements | Signaling negotiates on the intended secure path |
| Media | Offered codecs, RTP port ranges, packetization, regional routing, and transcoding | Two-way audio works without unexpected codec changes |
| Encryption | TLS for signaling and SRTP for media, with a shared keying method | A trace shows the intended signaling and media protection |
| DTMF | RTP telephone events, in-band tones, or SIP INFO | Menu digits arrive once and in order |
| Identity | From, P-Asserted-Identity, diversion history, authorized caller IDs, and signing policy | Inbound and outbound identity survives the route correctly |
| Capacity | Concurrent calls, CPS, burst rules, channel limits, and upgrade process | Load test stays below every enforced limit |
| Routing | Primary and backup targets, timeout behavior, health checks, and failback | Controlled failure moves traffic as designed |
| Operations | SIP response visibility, packet captures, call IDs, carrier records, and escalation contacts | One failed call can be traced across all systems |
TLS and SRTP cover different parts of the path. TLS can protect SIP signaling while the audio remains unencrypted RTP. SRTP protects media, so confirm and inspect both, including the agreed key-management method. For keypress-driven menus, agree on the audio/telephone-event format defined in RFC 4733 or another method that both sides support.
A production rollout plan for BYOC
1. Draw the ownership boundary
Name an owner for numbers, origination, termination, caller identity, emergency dialing, recording, transfers, fraud controls, capacity, and incident response. Write down where the carrier's responsibility ends and the platform's begins. A gap between contracts becomes an outage later.
2. Build one narrow route
Start with one phone number, one direction, one region, and one agent or call flow. Keep the existing production route unchanged. Verify SIP authentication, number mapping, and audio before adding destinations or features.
3. Run a functional test matrix
Cover more than a completed conversation:
- inbound and outbound calls;
- answer, busy, rejected, invalid number, voicemail, and no answer;
- caller and called number presentation;
- two-way audio after a long call and after hold;
- DTMF entry;
- cold, warm, and failed transfers where applicable;
- caller hangup, agent hangup, and network timeout; and
- recording, transcript, events, and carrier call-detail records.
4. Test failure isolation
Block one media port range, reject a credential, remove a route, expire a test certificate, and make a backup target unavailable. Confirm that alerts identify the failing layer. Correlate the platform call ID, SIP Call-ID, carrier record, and application event so one incident can be followed from end to end.
5. Load test starts and duration
Ramp CPS and concurrency separately. Include short calls, long calls, transfers, and bursty arrival patterns. Watch SIP response codes, post-dial delay, media loss, CPU or channel use on the SBC, and application queue depth. Set production limits below the first point of instability.
6. Cut over in reversible stages
Move a small share of traffic, compare outcomes with the old route, and retain rollback. Increase volume only after the new path meets thresholds for answer rate, response time, audio quality, call completion, transfers, and trace completeness. Rehearse carrier and platform failover after launch, since an untested backup is only a diagram.
Frequently asked questions
Is BYOC the same as SIP trunking?
No. SIP trunking is a common technical connection used by BYOC. BYOC is the broader commercial and operating model in which you choose and manage the carrier. A provider could support SIP for its own bundled service without allowing you to bring another carrier.
Do you need an SBC for BYOC?
It depends on the carrier, platform, network boundary, and security policy. An SBC can normalize headers and codecs, enforce access rules, hide network topology, anchor media, and manage failover. Some cloud-to-cloud trunks connect directly and do not require a customer-operated SBC. Include an SBC only when it has a defined job, owner, capacity plan, and redundant design.
What is BYOC Cloud versus BYOC Premises?
Terminology varies by provider. In offerings that use these labels, BYOC Cloud usually terminates the carrier connection at the platform's cloud edge. BYOC Premises routes it through an SBC, gateway, or edge component in your environment. Cloud termination reduces equipment ownership. Premises termination gives you more control over local PBXs, gateways, private connectivity, and migration sequencing.
Can BYOC handle both inbound and outbound calls?
Yes, when the carrier and platform support both directions. Configure and test them separately because they use different number mappings, identity checks, routing policies, and capacity limits.
BYOC is most useful when carrier control is an intentional product requirement and the interconnection is treated as production infrastructure. If that matches your voice AI deployment, start building with Dasha and connect the carrier route you already trust.