The voice decision used to have one axis: which carrier, which SIP trunk, which platform. In 2026 it has a second one. For a growing share of customer relationships, the cheapest and most context-rich path to a live conversation is a call placed inside WhatsApp; for the rest, it is still the public telephone network. This is the decision post for that fork: where WhatsApp Business Calling wins, where programmable PSTN/SIP voice wins, and how a production voice program on Devotel Orbit chains the two instead of choosing one.
Quick answer
- Choose WhatsApp Business Calling for calls to customers who already message you on WhatsApp, and for international legs where the customer's WhatsApp is active but PSTN termination is expensive. The call inherits the message thread, the permission the customer already granted, and the data-path economics of a market Meta has already won.
- Choose programmable PSTN/SIP voice wherever reach must be universal: first-contact dialing, landlines and PBX hunt groups, markets with thin WhatsApp adoption, programs that need carrier-side recording and regulatory control, and flows built on keypad DTMF or trunk-side transfer.
- Choose both, chained, for anything in production: attempt WhatsApp calling first when the customer is opted in, and let programmable voice be the floor that makes a failed WhatsApp leg a retry, never a dead end.
The rest of this post is the evidence behind those three lines.
Reach reality: installed base versus number reachability
WhatsApp's own published count passed 2 billion users in 2020, and 2025 public reports put monthly actives near 3 billion. That number is real, and it is not the number that matters for dialing. A WhatsApp call reaches a WhatsApp identity: an active install, on a number the customer actually uses in the app. The PSTN reaches every assigned telephone number on earth, including the landline, the PBX pilot number, and the handset that never installed anything.
So the reach question is not "how big is WhatsApp?" It is "what share of my dialed list is active on WhatsApp, and what share of those calls may I initiate?" Two further filters sit on top of the installed base:
- Encryption expectations. Consumer WhatsApp calls are end-to-end encrypted. A business call is a different animal: the media terminates at the business endpoint over standard WebRTC (DTLS-SRTP, Opus), which puts the business in the media path exactly as a contact center sits in the path of a PSTN trunk. Meta also documents SIP interworking with G.711 for estates that terminate trunks. Say this plainly to customers who arrive expecting consumer-grade end-to-end encryption on a business call: they get transport encryption to your endpoint, and your recording and consent policy governs from there.
- Business-initiated rules per Meta's published policy. The WhatsApp Business Calling API has been generally available since July 2025, and its developer documentation (published with the GA and current through 2026) sets the rules a dialing program must respect: user-initiated calling works wherever the Cloud API operates, but a business-initiated call requires a per-user permission granted inside the existing conversation; production accounts carry per-user-per-day limits on business-initiated calls; a documented list of country codes is excluded from business-initiated calling; and eligibility rides the account's messaging quality tier, the same rating that governs template messaging.
The operational read: WhatsApp calling is a permissioned, relationship channel. Cold outbound at dialer volume is a PSTN job, and any plan that assumes otherwise dies on the permission gate, not on the media path.
Chaining patterns: WhatsApp first, PSTN as the floor
The pattern that survives contact with production is an ordered chain, and it is the same routing posture Devotel Orbit already ships for messaging: an organization-level fallback chain decides what happens when a channel cannot deliver, and per-send channel selection stays explicit and visible rather than silently inferred. Two posts document that posture in depth, and the voice chain inherits it:
- WhatsApp first, PSTN fallback. When the contact record shows a granted calling permission and an active WhatsApp identity, place the WhatsApp leg. Every failure arm then ends in a PSTN call to the number of record: permission missing or revoked, a destination on Meta's excluded-country list, a network that blocks the media path, or a simple no-answer. The migration runbook for WhatsApp calling makes this the go-live gate: each failure arm is tested deliberately, and each one must end with the PSTN number already on the customer's thread, never with silence.
- PSTN first, WhatsApp continuation. First contact rides the PSTN because it needs no relationship. The follow-up call, the one that grows out of an open case or an open order, is offered in the WhatsApp thread, where the transcript and the consent already live. This is the pattern for support and delivery workflows: universal reach in, context-rich voice after.
- User-initiated inbound, answered anywhere. The customer taps the call icon in the chat; the call lands in the same queues and routing rules as a PSTN call; a human agent answers on the same operator softphone, or a voice AI agent answers first from the same knowledge base and hands off in the same queues with the transcript attached.
On Devotel Orbit the chain is tenant-owned end to end: the WhatsApp calling toggle is per number under Settings → Channels, the permission state is tracked on the shared contact record so any agent sees whether a business-initiated call is allowed before attempting it, and both legs write to one call log and one pay-as-you-go bill, with the PSTN leg carried on Devotel's own carrier-of-record softswitch. The routing decision is a setting the organization owns, which is the property auditors and operators both ask for: routing you can see is routing you can govern.
Operability matrix
The honest matrix, as shipped. The WhatsApp column states the platform's limits without dressing them up; the PSTN column states what the programmable voice stack carries.
| Capability | Programmable PSTN/SIP voice | WhatsApp Business Calling |
|---|---|---|
| Reach | Any assigned number, landlines and PBX included | Active WhatsApp identities only; business-initiated further gated on per-user permission and the excluded-country list |
| Initiation | No relationship required | User-initiated anywhere the Cloud API operates; business-initiated per granted permission, per-day limited |
| Recording | Tenant-owned recording policy, including carrier-side SIPREC recording on the trunk | Session recorded at the business endpoint against the same contact record; bounded by what the WebRTC leg delivers |
| Transcription and QA | Applies to the recorded leg; carrier-side recordings feed the QA lane | Applies where the leg is recorded; treat as additive to, not a replacement for, the carrier-side lane |
| AI agent join | Voice agents join from the same knowledge base | Same: the session bridges to a voice AI agent in real time, with handoff to humans in the same queues |
| DTMF / IVR keypad | RFC 2833 telephone-event over the SIP leg; keypad menus work as designed | The consumer app exposes no dependable keypad contract on business calls; keypad-driven IVR belongs on PSTN |
| Hold and transfer | Trunk-side hold, blind and attended transfer | Limited to what the WebRTC session supports; design flows assuming no attended transfer on the WhatsApp leg |
| Consent, quiet hours, opt-outs | Tenant-owned controls, applied per channel | The same controls on the same contact record: one consent ledger across message and call |
Read the matrix as a contract. Everything tenant-owned on the PSTN leg (recording consent, retention, quiet hours, opt-outs) carries to the WhatsApp leg unchanged, because those controls live on the contact and the organization, not on the channel. Everything trunk-side (keypad DTMF, SIPREC, transfer semantics) is a PSTN property, and flows that depend on it should route there by design rather than discover it by failure.
Cost model, on dated public sources
The two legs price differently, and the difference is structural rather than a single rate:
- The messaging side of the relationship moved to per-template pricing effective 1 July 2025 under Meta's published pricing change; that is the surface a WhatsApp thread already rides, and it is unchanged by adding voice.
- The calling side prices per Meta's published Calling API rate card (developer documentation, published with the July 2025 GA and updated since): business-initiated call minutes are priced by destination market, so pull the current card for the corridors you actually dial rather than averaging one number.
- The Orbit side bills both legs on one pay-as-you-go wallet at the published per-minute rates on the pricing page, with no separate platform line for WhatsApp: Orbit publishes a $0 WhatsApp platform fee across its country pricing pages, so on the messaging side you pay Meta's charges only. The PSTN leg adds its usual number rental.
The modeling move that keeps the comparison honest is to price your own minutes, not a hypothetical average. Pull last quarter's call volume, split it by corridor and by permission state, and price each leg at the current published rates: international corridors with expensive PSTN termination are where the WhatsApp data path wins outright; domestic corridors with cheap termination narrow the gap until context and containment, not the rate, make the decision. Keep the PSTN line item either way. The chain only works if the fallback leg is budgeted as live capacity, because for first contact and for every unpermissioned relationship, it is.
Where to read next
- WhatsApp Business Calling on Devotel Orbit — how the channel is exposed: one inbox, one contact record, calls on a carrier-of-record network.
- WhatsApp Business Calling API Is Now Generally Available — what Meta shipped and why it changed telephony shortlists.
- Migrate a PSTN Voice Flow to WhatsApp Business Calling — the phased runbook, including the PSTN-fallback test gate this post inherits.
- AI Voice Agent Pricing in 2026 — pricing the agent leg that can answer either channel.
- Channel Fallback Capability Matrix and Direct Send: explicit channel routing — the shipped routing posture the voice chain extends.
Frequently asked questions
Is WhatsApp Business Calling a replacement for a SIP trunk?
No. It is a permissioned voice channel that reaches active WhatsApp identities. The PSTN remains the universal-reach leg, the carrier-side recording leg, and the keypad-IVR leg; the two run side by side on one account.
Can I place a WhatsApp call to any customer?
Only where the customer has granted calling permission inside the conversation, within Meta's per-user-per-day limits and outside the documented excluded-country list. User-initiated calls from the customer face none of those gates.
Which channel should carry my IVR flows?
PSTN. Keypad DTMF is a telephone-network contract the WhatsApp consumer app does not reliably honor on business calls, so keypad-driven flows belong on the SIP leg by design.