A text message that reads "Delivered" and a call that connects on the first ring both look instantaneous from an app. Neither one is instantaneous underneath: every SMS and every voice call crosses a signaling layer, at least one carrier interconnect, and a routing decision before either side sees anything, and it is the quality of those layers — not the API that fronts them — that decides whether messages actually land and calls actually connect. This guide breaks down what is actually running underneath a "sent" text or a "connected" call, where that infrastructure commonly fails, and how Orbit's own SMS and voice stack is built.
The layers underneath a "sent" message or a "connected" call
Four layers sit between an API call and a ringing phone or a delivered text, for voice and SMS alike:
- The signaling layer. Voice calls are set up and torn down using the Session Initiation Protocol — SIP, IETF RFC 3261 — while the actual audio travels as RTP, RFC 3550 media streams once the call is connected. SMS uses SMPP (Short Message Peer-to-Peer) binds between a platform and each carrier or aggregator it connects to. This is the layer that fails silently: a SIP trunk can go unregistered, or an SMPP bind can drop, without the sending application noticing until a message or call simply never arrives.
- The carrier interconnect layer. Every message or call ultimately hands off to a mobile network operator. How many hops sit between the platform and that operator — and whether the connection is direct or resold through an aggregator — determines both latency and how much visibility exists when something goes wrong. See our companion guide on carrier ownership vs. reseller CPaaS for how to tell these models apart.
- The routing and failover layer. A platform's route logic decides which carrier or trunk handles a given destination, and — critically — what happens automatically when the first choice is unavailable, congested, or returning errors. This is where the difference between "reliable" and "flaky" infrastructure is actually engineered.
- The delivery-confirmation and observability layer. A Delivery Receipt (DLR) for SMS or a Call Detail Record (CDR) for voice should reflect what the carrier's network reported, not just that the platform's API accepted the request. Conflating "accepted" with "delivered" is the single most common way infrastructure reliability gets overstated.
Where SMS and voice infrastructure actually fails in production
Most reliability problems trace back to one of four gaps, none of which show up on a feature comparison page:
- Single-carrier dependency for a destination. If only one route exists to a given country or mobile network, that route's congestion or an operator-side outage becomes your outage, with no fallback.
- No automatic failover at the signaling layer. A SIP trunk that silently drops registration, or an SMPP bind that isn't automatically re-established, can take a route offline for hours before anyone notices — unless the platform actively monitors trunk and bind health itself.
- Delivery receipts that only confirm API acceptance. A "sent" or "queued" status is not a delivery confirmation. A DLR that reflects the carrier's actual delivery outcome (delivered, undelivered, expired) is what lets you tell a real failure from a slow one.
- Resold hops with no visibility into the extra leg. Traffic routed through a reseller's reseller adds latency and failure points the sending platform often cannot see or diagnose, because it does not operate that leg.
What reliable infrastructure looks like in practice
Evaluating a provider's actual infrastructure, rather than its marketing claim, comes down to four concrete questions:
- Are there multiple carrier routes per destination, with automatic failover between them — not a single path that becomes a single point of failure?
- Is trunk and bind health monitored continuously, so a dropped SIP registration or SMPP bind is caught and re-established automatically rather than discovered from a customer complaint?
- Do delivery receipts and call records reflect the carrier's actual outcome, queryable per message and per call, not just an aggregate uptime number?
- Does the same infrastructure carry every outbound channel — AI voice agents, the cloud phone system, and outbound SMS — so a reliability investment in one channel benefits all of them, instead of each channel sitting on a separate vendor's stack?
How Orbit's SMS and voice infrastructure is built
Outbound (MT) voice and SMS on Orbit terminate over Devotel's own wholesale softswitch, with direct interconnects to 500+ global carriers, rather than a resold aggregator hop — the same infrastructure fact independent readers can verify on the carrier-vs-reseller comparison. That single switch carries every outbound channel on the account: AI voice agents, the built-in cloud phone system, and outbound SMS campaigns all route over it, so route monitoring and failover engineering done for one channel benefits all of them rather than sitting inside one product silo. Delivery receipts and call records are surfaced per message and per call in the dashboard and over webhooks, so a failed send is visible immediately instead of discovered from a support ticket. Current per-minute and per-message rates for this infrastructure are on the pricing page, and the full channel set it carries is on the CPaaS overview and omnichannel messaging pages.
Orbit's angle: one infrastructure stack, not a channel bolted on per vendor
Most teams end up assembling SMS and voice reliability themselves — one vendor's trunk for calls, another aggregator for SMS, a third tool to reconcile delivery receipts across both. Orbit runs both channels over one softswitch and one account, so the redundancy, monitoring, and delivery-receipt visibility built for outbound SMS is the same infrastructure carrying outbound voice, with one dashboard and one bill covering both. See Orbit vs Twilio for how that compares to a channel-specific incumbent, and the best Twilio alternatives guide for the ranked round-up of the providers worth evaluating.
Frequently asked questions
What actually determines whether an SMS or a call is reliable?
Reliability is decided by the signaling layer (SIP for voice, SMPP for SMS), how many carrier hops a message or call crosses, whether failover is automatic when a route fails, and whether delivery receipts reflect the carrier's real outcome rather than just API acceptance. A polished dashboard says nothing about any of these.
What is the difference between a delivery receipt and API acceptance?
API acceptance means the platform received your send request; a delivery receipt (DLR) reflects what actually happened on the carrier's network — delivered, undelivered, or expired. A platform that reports only acceptance status can look reliable while individual messages silently fail.
Why does automatic failover matter more than a headline uptime number?
An aggregate uptime percentage describes the platform as a whole, not the specific route to the destination you're sending to. Automatic failover — re-routing a call or message when the first-choice carrier path fails — determines whether one bad route becomes a dropped call for your customer or an invisible retry.
Does it matter if voice and SMS run on the same underlying infrastructure?
Yes, in two ways: operationally, it means one team's route-monitoring and failover investment benefits both channels instead of being duplicated per vendor, and practically, it means one dashboard and one set of delivery/call records instead of reconciling two separate providers' reporting.
How can I verify a provider's infrastructure claims myself?
Ask for the specifics behind the marketing line: how many direct carrier interconnects exist for the destinations you actually send to, what the automatic-failover behavior is when a route fails, and whether delivery receipts and call records are queryable per message and per call rather than summarized as one uptime figure.
Sources and further reading
- IETF RFC 3261 — SIP: Session Initiation Protocol: the signaling standard that sets up and tears down a voice call.
- IETF RFC 3550 — RTP: A Transport Protocol for Real-Time Applications: the media-transport standard carrying a call's audio once it connects.
- Grand View Research — Communication Platform as a Service Market report: market size and growth-rate forecast through 2030, projecting the CPaaS category to reach $86.26 billion by 2030.
- Which CPaaS providers actually own carrier infrastructure vs. resell it?: a neutral framework for reading a provider's network-ownership claim, with what six vendors publicly state about their own infrastructure.
Published 17 August 2026. Part of the Orbit resources library — foundational guides for teams building on communications infrastructure.