SIP trunking is the protocol-level handoff between your telephony and a voice platform: your PBX or carrier sends calls over SIP, and the platform answers, routes, records, and — increasingly — hands the call to an AI agent. Bring-your-own-carrier (BYO carrier, or BYOC) means you keep your existing carrier contract and phone numbers and point that trunk at the platform instead of porting everything over. For enterprises with a negotiated carrier rate, a fleet of numbers under their own control, or a regulator who wants numbering to stay put, BYO is often the only acceptable way to adopt AI voice agents and programmable voice. This guide covers what SIP trunking and BYO mean in 2026, how Devotel Orbit ingests a customer trunk, what failover and latency look like on that path, and a checklist for when BYO beats bundled telephony.
What SIP trunking and BYO carrier mean in 2026
A SIP trunk is the IP session between your PBX, SBC, or carrier gateway and a voice platform. The call arrives as a SIP INVITE, the platform challenges it for credentials, and once authenticated the call enters the platform's routing, IVR, or agent logic. BYO carrier is the commercial posture around that trunk: you keep your own carrier relationship — your negotiated per-minute rates, your existing numbers, your regulatory registrations — and the platform terminates or originates on your trunk rather than its own.
The tradeoff is real and worth stating plainly:
| Keep-your-carrier (BYO) | Provider-carrier (bundled) |
|---|---|
| Keep negotiated rates and existing numbers | One vendor, one bill, numbers provisioned by the platform |
| Your carrier handles PSTN; platform handles call logic | Platform handles PSTN end to end |
| You own trunk health (registration, credentials, failover) | Platform owns carrier health |
| Works where numbering can't move (regulatory, contract) | Simpler where porting is acceptable |
In 2026 the reason BYO matters more than it did five years ago is AI voice: the value has moved from "terminate the call" to "reason on the call." An enterprise that would never re-platform its carrier will happily re-platform the intelligence layer — as long as the trunk keeps ringing the same numbers. That is the wedge, and it only works if the platform ingests third-party trunks as a first-class path rather than a bolt-on.
How Orbit ingests a customer trunk
Orbit's BYO trunk ingestion has two authentication patterns, and a tenant picks per trunk:
Digest authentication (username + password). Your PBX registers or places calls with a per-trunk digest username and password. The trunk's credentials are stored on your organization settings, encrypted at rest, and when Orbit's voice edge challenges a SIP INVITE or REGISTER, it hands the stored password to the edge for the digest check. Username uniqueness is enforced at trunk-creation time so claims resolve to exactly one trunk.
IP allowlist. Alternatively, a trunk can authenticate by source IP — common when a carrier SBC presents a fixed egress and you don't want credential handling at all. A trunk using IP allowlist is simply excluded from digest lookup.
Both INVITE (the call itself) and REGISTER (the binding that keeps your PBX reachable for inbound) authenticate against the same per-trunk credential on the digest path. A trunk you mark as registration-based re-registers on its keepalive cadence, and Orbit guards the binding: if your PBX requests a pathologically short registration interval, Orbit raises the granted expiry up to a healthy minimum so the trunk does not flap offline between refreshes — a traditional cause of "trunk shows unregistered" mysteries.
Every authentication attempt, successful or not, is recorded against the trunk so the voice dashboard can show a "recent auth failures" panel per trunk — the difference between "carrier says it registered fine" and seeing the failing digest claim with the source IP attached. Persistent unauthenticated probing (toll-fraud scanners cycling usernames against public SIP edges) gets edge-dropped after a bounded threshold instead of burning your log and rate budget.
Credentials live a full lifecycle on the dashboard's SIP trunks screen — create, rotate, suspend — and the softphone side (registering a desk phone or softphone app directly against Orbit, without a PBX at all) has its own credential set, so BYO-PBX trunks and directly registered devices never collide.
No invented capacity claims here: the ingestion path is what the platform ships — digest or IP auth, encrypted-at-rest secrets, registration-expiry floor, per-attempt auth logging, and edge-level probe dropping.
Where it meets AI voice agents and programmable voice
Once your trunk is authenticated, the call is on the same path as every other Orbit call. An inbound INVITE can land on an AI voice agent that answers, reasons mid-call, and warm-transfers to a human with context — or on a programmable voice flow your application controls turn by turn through call-control instructions. The BYO trunk only changes who terminates the call; everything above the media layer behaves identically to Orbit-carrier traffic.
That uniformity is the point buyers should test for: some platforms treat BYO trunks as a second-class path where agents, recording, or transcription silently degrade. On Orbit the agent runs on the same terminated leg whether it came in on your trunk or on Orbit's own numbering, and the same voice dashboard surfaces every call. For the full implementation picture, the programmable voice guide covers the call-control model, and the UCaaS feature page covers the drag-and-drop IVR, queues, and softphone that share the same trunk registry.
A concrete example flow, end to end:
- Enterprise keeps its incumbent carrier; its PBX points a SIP trunk at Orbit with a digest username/password (or IP allowlist).
- Customer calls the enterprise's existing number; the carrier delivers the INVITE to Orbit over that trunk.
- Orbit authenticates the trunk, routes the call to the tenant's AI voice agent, and the agent answers — qualifies, resolves, or warm-transfers to staff.
- Auth attempts, registration health, and call detail stay visible on the tenant's own voice dashboard.
The incumbent carrier never leaves the picture; the AI agent arrives anyway.
Failover, numbers, and latency
Failover. Where a tenant configures more than one trunk, Orbit supports a failover chain: if the primary PBX/SBC trunk is unregistered at dispatch time, delivery walks to the configured secondary instead of silently dropping. The chain is cycle-safe (write-time validation rejects a self-referential or looping chain, and the dispatch walk is hop-capped), so misconfiguration is caught at configuration time, not at 3 a.m. When no usable failover exists, dispatch falls back to the Devotel platform default — which is also what happens for outbound termination generally: the BYO trunk path is for delivery to your equipment, while outbound PSTN egress on Orbit runs over Devotel's own wholesale softswitch.
Number management. BYO means your numbers stay with your carrier, so number management on Orbit covers what you add on top: provisioning, porting, masking pools, lookup, and connectivity for Orbit-carrier numbers, and your BYO trunk and any Orbit numbers can coexist and route into the same agents. The NaaS feature page lays out that numbering and cellular-connectivity layer.
Latency. A SIP trunk adds an edge hop into the agent path, so the honest question is how many milliseconds that hop costs. Orbit publishes its per-stage voice-agent latency budget on the latency benchmark page, and the practical guidance is to keep your PBX's SIP edge close to the platform edge (TLS transport, one registrar) rather than chained through intermediate SBCs. Digest auth and registration add negligible per-call overhead; what hurts is extra proxy hops and far-from-edge media anchoring. For a deeper treatment, see reduce latency for AI voice agents.
Buyer checklist: when BYO beats bundled telephony
BYO is the better answer when most of these are true:
- Carrier contract you can't or shouldn't exit. Multi-year rate, committed-use discount, or a regulatory registration tied to incumbent numbering.
- Numbering can't move. Healthcare, government, or finance deployments where porting numbers triggers re-registration or audit burden.
- PBX estate stays. Genesys/Avaya/Cisco or a custom SBC you operate — you want the agent layer without a forklift.
- Your carrier rate wins. Your wholesale carrier rate beats the platform's bundled rate at your volume.
- Compliance stays tenant-owned. Consent, recording disclosure, DNC, and quiet-hours remain rules your tenant config enforces; the platform gives you the controls, your carrier relationship stays yours.
Bundled (provider-carrier) is the better answer when:
- You're greenfield or happy to port, and want one bill and one vendor for carrier + platform.
- You don't operate any PBX/SBC — softphones register directly, which Orbit supports with its own SIP credentials.
- You'd rather the platform own carrier health end to end.
Either way, the evaluation substance is the same: does the platform ingest your trunk as a first-class path, does everything above media (agents, recording, routing) behave identically, and are failover and auth visibility real features rather than support tickets.
Frequently asked questions
What is SIP trunking with bring-your-own-carrier?
SIP trunking is the IP session between your PBX or carrier and a voice platform. BYO carrier means you keep your existing carrier contract and phone numbers and point that trunk at the platform, instead of porting numbers and buying the platform's bundled telephony. Enterprises use it to adopt AI voice agents without re-platforming their carrier relationship.
How does Orbit authenticate a customer SIP trunk?
Per trunk, either digest authentication (a username and password stored encrypted at rest, verified at the voice edge on each INVITE or REGISTER) or IP allowlist (authentication by source IP). Every auth attempt is logged so the voice dashboard can render a per-trunk recent-auth-failures panel, and persistent unauthenticated probing is edge-dropped after a bounded threshold.
Can an AI voice agent answer calls that arrive on my own trunk?
Yes. Once the trunk is authenticated, the call takes the same path as any other inbound call — an inbound INVITE can route straight to an AI voice agent or a programmable-voice flow. The BYO trunk changes who terminates the call, not which platform features run on it.
What happens if my primary PBX or trunk goes down?
Where you have configured a failover chain, Orbit walks delivery to your configured secondary trunk when the primary is unregistered. The chain is cycle-validated at configuration time. If no usable failover is configured, outbound dispatch falls back to the Devotel platform default.
Does BYO trunking add latency to an AI voice agent?
A trunk adds an edge hop, so keep your SIP edge close to the platform and avoid chained intermediate SBCs. Digest auth and registration add negligible overhead. Orbit publishes its per-stage voice-agent latency budget, which is the right document to evaluate the agent path against.
The takeaway
SIP trunking with BYO carrier is how an enterprise adopts AI voice without abandoning its carrier: the trunk authenticates by digest or IP, the call lands on the same agent and programmable-voice path as platform-carrier traffic, failover chains and auth-attempt visibility are first-class, and your numbers stay where they are. Evaluate any platform on whether BYO is a first-class ingestion path with real failover and observability — on Orbit it is, and the example above (incumbent carrier, pointed trunk, agent answers) is the shipped behavior, not a roadmap promise.
Published 28 August 2026.