Quick answer. Technically, RCS sends messages over IP (not the cellular SMS channel) using the GSMA’s RCS Universal Profile to ensure interoperability. When a message is composed, the sending client or platform performs a capability check to confirm the recipient can receive RCS; if so, the message is delivered over the internet through an RCS backend (Google’s Jibe powers most of the world) to the recipient’s messaging app. If not, it falls back to SMS/MMS. For business messaging, the brand sends through a verified RBM agent via a provider’s API into that same backend.
The full A2P path: your application calls a provider’s RCS API → the provider sends the message as your verified RBM agent into the RCS backend (Jibe/carrier) → the backend delivers it to the user’s RCS client → user interactions (taps, replies, read receipts) flow back to your webhook. Anything that can’t be delivered as RCS automatically downgrades to SMS/MMS.
Because it’s IP-based, RCS needs a data connection and supports rich payloads (media, cards, buttons) and real-time signals (typing, read receipts) that the legacy SMS channel can’t carry.
Key facts
- Transport: IP (Wi-Fi/data); interoperability via GSMA Universal Profile; backend largely Google Jibe.
- Capability discovery decides RCS vs SMS/MMS fallback per recipient.
- Business path adds a verified RBM agent and a provider API + webhooks.