What Is RCS?

RCS (Rich Communication Services) is a GSMA-standardized messaging protocol designed to replace SMS and MMS with a modern, IP-based messaging experience. Where SMS is constrained to 160-character plaintext payloads routed through the SS7 signaling network, RCS delivers group chat, high-resolution media sharing, read receipts, typing indicators, and rich interactive elements over the mobile data connection. RCS is not an app — it is a carrier-level protocol built into the device's native messaging client, requiring no separate download or account creation on either end.

The GSMA published the first RCS specification in 2008. Adoption was slow for over a decade due to fragmented carrier implementations and competing proprietary standards. The landscape shifted materially when Google adopted RCS as the default protocol in its Messages app for Android, and Apple added RCS support in iOS 18 (September 2024). As of early 2025, RCS is available on the two dominant mobile platforms, though feature parity and encryption status vary significantly between them.

RCS vs SMS: Feature Comparison

Universal Profile

The GSMA Universal Profile is the interoperability specification that defines the baseline feature set for RCS across all compliant carriers and devices. Without Universal Profile, early RCS deployments were balkanized — each carrier implemented its own variant, and cross-carrier RCS messaging often failed or degraded to SMS.

Universal Profile standardizes:

• Chat features. 1:1 and group messaging, file transfer, audio messaging, location sharing, read receipts, and typing indicators.
• Capability discovery. A mechanism for devices to query whether a contact supports RCS and which features are available before sending a message. This prevents attempts to deliver RCS content to SMS-only recipients.
• Enriched calling. Video calling, in-call content sharing, and post-call messaging — though carrier adoption of enriched calling features remains inconsistent.
• Network APIs. Standardized interfaces for provisioning, authentication, and message routing between carrier RCS platforms.

The current production version is Universal Profile 2.6, published by the GSMA in 2023. It includes specifications for end-to-end encryption based on the Messaging Layer Security (MLS) protocol, though carrier implementation of MLS-based encryption is still in progress.

How RCS Works Technically

RCS is built on the IMS (IP Multimedia Subsystem) architecture — the same framework that underlies VoLTE (Voice over LTE) and other IP-based carrier services. The key protocol components are:

SIP (Session Initiation Protocol)

SIP handles session establishment, capability exchange, and presence management for RCS. When a device boots or reconnects to the network, it registers with the carrier's RCS platform via SIP. Before sending a message, the device performs an OPTIONS request or queries the capability server to determine whether the recipient supports RCS, what features are available, and whether to fall back to SMS.

MSRP (Message Session Relay Protocol)

MSRP is the transport protocol for RCS message payloads. Text messages, media files, and rich content are transferred over MSRP sessions established through SIP signaling. MSRP operates over TCP/TLS, providing transport-layer encryption between the device and the carrier's RCS platform.

HTTP for File Transfer

Large media files (photos, videos, documents) are uploaded to a carrier-hosted or Google-hosted content server via HTTP/HTTPS. The recipient receives an MSRP message containing a URL and metadata (file type, size, thumbnail), then downloads the file directly from the content server. This decouples media transfer from the signaling path and allows files far larger than MMS limits.

Google Jibe

Many carriers do not operate their own RCS infrastructure. Instead, they delegate RCS hosting to Google Jibe, a cloud-based RCS platform that Google operates on behalf of participating carriers. Google Jibe handles message routing, capability discovery, file hosting, and protocol compliance. For carriers using Jibe, the RCS backend is effectively Google's infrastructure, with the carrier's branding and number assignment layered on top. Google also operates a direct-to-consumer RCS service through Google Messages that bypasses carrier infrastructure entirely when the carrier has not deployed RCS natively.

Message Flow

Sender Device
   │ (SIP REGISTER + capability query)
   ▼
Carrier RCS Platform / Google Jibe
   │ (SIP OPTIONS → capability check)
   ▼
Recipient's RCS Platform
   │ (MSRP session established via SIP)
   ▼
Recipient Device
   │ (message delivered over MSRP/TLS)
   │ (media downloaded via HTTPS from content server)
   ▼
Read receipt returned via MSRP

If capability discovery determines that the recipient does not support RCS, the sender's client transparently falls back to SMS/MMS through the legacy SMSC path.

RCS Business Messaging (RBM)

RCS Business Messaging is the A2P (application-to-person) counterpart to consumer RCS. It allows businesses to send branded, interactive messages through the recipient's native messaging app — without requiring the user to install a separate application.

Key RBM Features

• Verified sender identity. Business messages display a verified brand name, logo, and description instead of a raw phone number. This is analogous to a verified badge on social platforms.
• Rich cards. Structured content blocks containing an image or video, title, description, and one or more action buttons (open URL, dial number, view location).
• Carousels. Horizontally scrollable sequences of rich cards, enabling product catalogs, option selection, or multi-step flows within a single message.
• Suggested replies and actions. Pre-defined response buttons that the user can tap instead of typing. Suggested actions can trigger phone calls, map navigation, calendar events, or URL opens.
• Delivery and read receipts. Businesses receive confirmation of message delivery and whether the user opened the message.

RBM vs A2P SMS

RBM reach is the primary constraint. Because RCS requires both device and carrier support plus a data connection, any RBM deployment must include an SMS fallback path to ensure message delivery to recipients who cannot receive RCS.

Carrier and Platform Adoption

Android

Google Messages is the default SMS/RCS client on most Android devices shipped since 2019. Google enabled RCS for all Google Messages users globally through its Jibe infrastructure, meaning Android users can send RCS messages even if their carrier has not formally launched RCS. Samsung Messages also supports RCS on Samsung Galaxy devices.

Apple (iOS 18+)

Apple added RCS support in iOS 18, released in September 2024. Prior to iOS 18, iPhones communicated with Android devices exclusively via SMS/MMS — the source of the "green bubble" distinction. With iOS 18, iPhone users can exchange RCS messages with Android users, gaining access to high-resolution media, typing indicators, and read receipts in cross-platform conversations.

However, Apple's RCS implementation follows the GSMA Universal Profile without Google's proprietary extensions. This means:

• Cross-platform (Android to iPhone) RCS chats are not end-to-end encrypted as of early 2025.
• iMessage remains the default for iPhone-to-iPhone communication. RCS is used only when the recipient is on Android.
• Some features available in Google Messages RCS (reactions rendered natively, certain rich card formats) may not render identically on iOS.

Carrier Rollout

RCS deployment is carrier-by-carrier. In the United States, AT&T, T-Mobile, and Verizon all support RCS on Android devices, largely through Google Jibe. Internationally, adoption varies widely — carriers in the UK, Germany, France, India, and Brazil have deployed RCS, while many smaller carriers and MVNOs have not.

Encryption Status

Encryption in RCS is fragmented. The current state as of early 2025:

Google implemented end-to-end encryption for RCS in Google Messages using its own implementation of the Signal Protocol for 1:1 chats and MLS for group chats. These are proprietary extensions — they are not part of the GSMA Universal Profile specification. Apple's RCS implementation does not include these extensions, which is why cross-platform RCS between Android and iPhone is encrypted only at the transport layer (device to server), not end-to-end.

The GSMA has committed to adding E2E encryption to the Universal Profile standard, based on the MLS protocol. When this is ratified and implemented by both Google and Apple, cross-platform RCS encryption will become possible. No confirmed timeline exists as of early 2025.

RCS for Developers

Available APIs

• Google Business Messages / RBM API. The primary programmatic interface for sending RCS Business Messages. Requires agent registration and verification through Google. Provides rich card templates, carousel support, suggested replies, and delivery callbacks.
• Sinch RCS API. Sinch offers an RCS API that abstracts carrier-level differences and provides built-in SMS fallback. Available in markets where Sinch has carrier agreements.
• Vonage (Ericsson). Vonage provides RCS capability through its Messages API as part of a multi-channel offering.

Developer Limitations

RCS API access is more restricted than SMS API access. Key constraints:

• Verification required. Businesses must register and verify an RBM agent before sending messages. This process is more involved than 10DLC registration and includes brand identity verification.
• No universal reach. Unlike SMS, which reaches every mobile phone globally, RCS messages only reach recipients whose device and carrier support RCS. Every RCS implementation must include SMS fallback logic.
• Fragmented feature support. Not all RCS clients render all Universal Profile features identically. Rich cards and carousels may display differently on Google Messages, Samsung Messages, and iOS.
• No shortcode equivalent. RCS does not have a high-throughput shortcode system analogous to SMS shortcodes. Throughput is governed by the RBM platform's rate limits and carrier agreements.

Why SMS Is Not Going Away

Despite RCS offering a dramatically richer experience, SMS remains essential for several structural reasons:

• No data connection required. SMS operates on the signaling channel of the cellular network and works without mobile data or Wi-Fi. RCS requires an active data connection. In areas with poor data coverage, during network congestion, or when a user has exhausted their data plan, SMS still delivers.
• Universal device support. SMS works on every mobile phone manufactured in the last 30 years — including feature phones, IoT devices, and legacy hardware that will never receive RCS support.
• No carrier dependency for basic delivery. While RCS requires carrier provisioning or Google Jibe connectivity, SMS routing through the SMSC and SS7 network is universally deployed.
• Regulatory and compliance infrastructure. The entire A2P messaging ecosystem — 10DLC registration, TCPA compliance frameworks, carrier filtering systems, and CPaaS API integrations — is built around SMS. RBM compliance and registration frameworks are newer and less mature.
• Fallback role. RCS itself depends on SMS as its fallback. When capability discovery fails, when the recipient's device is offline, or when the carrier path is unavailable, the message degrades to SMS. Removing SMS would remove the safety net that makes RCS viable.

SMS is the reliable baseline. RCS is the rich overlay. Both will coexist for the foreseeable future.

Further Reading

• How SMS Works — PSTN, SS7, SMSC routing, and the full network path of an SMS message.
• What Is A2P SMS? — Application-to-person messaging classification, 10DLC registration, and how carriers distinguish A2P from P2P traffic.