> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Channel capability coverage matrix: which channels do what, and which slot into your fallback chain > The unifying model for per-channel capabilities — the taxonomy Orbit uses (send, receive, templates, media, DLRs, read receipts), the coverage dimensions that gate a channel (geography, feature set, cost class), fallback eligibility, and a one-row-per-channel index into the channel pages. # Channel capability coverage matrix Every channel page under [Channels](/channels/sms) documents one channel's full surface. That granularity answers "how do I use channel X," but the question a routing decision actually asks is *across* channels: **can RCS carry this payload, is the recipient reachable on it in this market, and if not, which channel next?** This page owns the unifying model — the capability taxonomy, the coverage dimensions that gate a channel per recipient, which rounds of channels are eligible for the org-level fallback chain, and a one-row-per-channel index into the individual channel pages. It deliberately does **not** re-teach each channel's send shapes; it indexes them. ## 1. Capability taxonomy A *capability* in Orbit is a named, machine-checkable message feature — not a vague "this channel is rich." Every channel is assessed against the same taxonomy, so comparing them is apples-to-apples: * **Send** — outbound (MT) delivery: text, or text plus structured payloads. * **Receive** — inbound (MO) delivery into the inbox and webhooks. * **Templates** — a pre-registered, provider-approved structured shape (WhatsApp templates, RCS rich cards/carousels, Messenger generic templates, email block-builder templates). * **Media** — attachments beyond plain text: images, video, audio, documents. * **Delivery receipts (DLRs)** — a terminal delivery verdict from the carrier or provider, distinguishing `delivered` from the three failure classes described in [Message status lifecycle](/concepts/message-status-dag). * **Read receipts** — a recipient-opened signal beyond delivery: RCS and Viber `seen`, WhatsApp/Meta `read`, email open-tracking. These are the columns in the matrix below. A channel's mapping to them is fixed by its upstream provider, not by Orbit — the matrix is a description of provider contracts, not a product toggle. ## 2. Coverage dimensions Having a capability is necessary but not sufficient. Whether a channel can carry a specific recipient is gated by three coverage dimensions, each checked before the send commits: * **Geography.** Channel reach varies by recipient market. SMS reaches effectively every MSISDN worldwide; RCS depends on per-carrier RBM rollout in the recipient's country; Viber availability is market-bounded by Rakuten's allow-list; WhatsApp and Messenger are near-global but live behind Meta's per-market business policies. The recipient's number and country are evaluated the same way the [Number Lookup and reachability model](/concepts/line-type-and-reachability) evaluates them. * **Feature set.** The exact capability needed: media stops the chain at SMS unless MMS carries it; interactive buttons belong to WhatsApp, RCS, and Messenger templates; voicemail-style one-way blasts belong on voice. * **Cost class.** Channels cluster into per-message-charged carriers (SMS, RCS, Viber), Meta conversation-priced channels (WhatsApp, Messenger), and flat/unmetered lanes (email, push). A routing policy like [Least-cost routing](/concepts/least-cost-routing) treats the class, not the sticker price, as the comparable axis. > **Note — pricing lives elsewhere.** Per-channel rate resolution, the pricing ladder, and route preview are owned by [Least-cost routing](/concepts/least-cost-routing) and the [Route preview model](/concepts/route-preview-model). This matrix ranks channels by cost *class* only — it never quotes rates. ## 3. Fallback eligibility The org-level chain ([Cross-channel fallback](/concepts/cross-channel-fallback)) advances a failed send to the next channel — but only across deployments where the next hop can plausibly reach the same recipient. The candidates, in the order a chain normally descends: 1. **Rich messaging carriers** — RCS, WhatsApp, Viber. Each is eligible as a primary and as a fallback hop (the canonical RCS → SMS chain; Viber → WhatsApp → SMS). 2. **SMS (MMS where media applies)** — the floor of every messaging chain: the one channel reachable on virtually every handset. 3. **Email** — eligible as a terminal hop for notification-class traffic where content survivability matters more than real-time delivery; not eligible mid-chain for interactive payloads, since email does not carry them. 4. **Voice / fax** — never in the message fallback chain. Their delivery surface (a call, a document) is not interchangeable with a message, so the router never advances a message send onto them; they are configured and reported separately. Messenger, Instagram, and other Meta DM channels are send-capable but **not** chain candidates beyond their own Meta family: a Messenger hop only works when the recipient has an open Meta conversation, which the generic capability check cannot guarantee. When you encode a chain entry, the router re-validates eligibility per hop — an ineligible entry is rejected at configuration time rather than silently skipped at send time. ## 4. Per-channel capability matrix One row per channel, every capability from the taxonomy as a column. **Yes** = the channel carries it; **No** = it does not, or carries it only in a degenerate form (marked where relevant). Follow the channel link for the send shapes, rate limits, and provider contract. | Channel | Send | Receive | Templates | Media | DLRs | Read receipts | Channel page | | --------- | --------------------------- | ----------------------- | ---------------------------------- | ------------------------------------------------- | ---------------------- | ------------------- | -------------------------------- | | SMS | Yes | Yes | No | No (MMS carries media — see [SMS](/channels/sms)) | Yes | No | [SMS](/channels/sms) | | RCS | Yes | Yes | Yes (rich cards, carousels, chips) | Yes | Yes | Yes | [RCS](/channels/rcs) | | WhatsApp | Yes | Yes | Yes (pre-approved templates) | Yes | Yes | Yes | [WhatsApp](/channels/whatsapp) | | Viber | Yes | Yes (bot accounts only) | Yes | Yes | Yes | Yes (`seen`) | [Viber](/channels/viber) | | Messenger | Yes | Yes | Yes (generic templates) | Yes | Yes | Yes | [Messenger](/channels/messenger) | | Instagram | Yes | Yes | Yes (generic templates only) | Yes | Yes | Yes | [Instagram](/channels/instagram) | | Email | Yes | Yes | Yes (block-builder templates) | Yes (attachments) | Yes | Yes (open tracking) | [Email](/channels/email) | | Voice | Yes (calls, IVR, AI agents) | Yes | N/A | N/A (audio is the payload) | Yes (call disposition) | N/A | [Voice](/channels/voice) | | Fax | Yes (PDF/TIFF documents) | Yes | No | Document payload | Yes | N/A | [Fax](/channels/fax) | The matrix answers two questions at once: **capability** (which channels can carry this payload class at all) and **fallback eligibility** (which of those channels the org-level chain may legitimately descend to). Everything else — the exact request envelope, provider tiers, rate limits, and per-market quirks — belongs to the channel page it links. ## Where the other models plug in * [Cross-channel fallback](/concepts/cross-channel-fallback) — the org-level ordered chain this matrix slots into. * [RCS capability check and SMS fallback](/concepts/rcs-fallback-and-capability) — the capability probe that gates RCS specifically. * [Multi-channel DLR fallback](/concepts/multi-channel-dlr-fallback) — DLR-triggered fallback, distinct from the capability-check chain. * [Least-cost routing](/concepts/least-cost-routing) and [Route preview](/concepts/route-preview-model) — pricing and rate resolution, out of scope here. * [Line type and reachability](/concepts/line-type-and-reachability) — the recipient-side lookup that feeds the geography dimension.