RCS - What Is It?

A comprehensive analysis of „Rich Communication Services” (RCS): technical origins, deployment strategies, regulatory influences, and encryption prospects.

I. RCS Fundamentals: Concept, Purpose, and Development

What is RCS, how did it emerge, and what is its structure?

1.1. Essential Concept and Purpose of RCS

„Rich Communication Services” (RCS) is a messaging standard defined by GSMA for mobile devices. The specifications were first introduced in September 2008. RCS was designed as an IP-based successor to SMS (Short Message Service) and MMS (Multimedia Messaging Service), expanding basic text messaging with modern, device-integrated features: high-definition photos and videos, file sharing, advanced group chats, delivery and read receipts, typing indicators, presence information, location sharing, and video calls. All of this operates over mobile data or Wi-Fi, without the need for a separate third-party application. Strategically, RCS was supported by operators to respond to OTT competition and maintain some control over the messaging ecosystem.

1.2. Historical Dynamics and the Fragmentation Issue

In the early days, different operators implemented varying versions of RCS, resulting in inconsistent functionality. A breakthrough came with the GSMA’s „Universal Profile” (UP): from 2016-2017, it became the de facto implementation path and began addressing interoperability. Subsequent releases further standardized client behavior and service interaction among operators and cloud providers.

1.3. Architectural Assumptions: IP Layer and Protocols Used

Unlike SMS, RCS operates over IP networks (via mobile internet or Wi-Fi) and is assigned to the application layer of the OSI model. Its core consists of several protocols:

SIP (Session Initiation Protocol) – session initiation and management.
MSRP (Message Session Relay Protocol) – content transmission (messages, attachments); sessions are coordinated via SIP and SDP; can be direct or relayed through relay servers.
HTTP(S) – additional interfaces and services (e.g., for uploads).

The early operators’ desire to maintain control created inefficiencies and fragmentation, but over time, interoperability and broad adoption became priorities. The reliance on SIP/MSRP (historically unforeseen in the telecom context for universal, client-independent E2EE) explains why RCS has lagged in achieving full end-to-end encryption compared to more modern OTT solutions.

II. Market Dynamics and Strategic Positioning

Google as a Catalyst, Apple’s Positioning, and EU Regulations

2.1. Google – The Main Driver of RCS Progress

After acquiring Jibe Mobile, Google developed the Jibe cloud infrastructure and the „Guest” model, allowing RCS to be enabled on Android devices through Google Messages even when the operator does not provide local support. This accelerated and standardized the deployment of UP, making RCS features (HD media, groups, receipts, typing indicators) widely available. Additionally, Google Messages provides end-to-end encryption for 1:1 and group chats when all participants use Google Messages and RCS.

2.2. Apple’s Strategy and Regulatory Environment

Apple has long relied on a closed iMessage ecosystem (universal E2EE among Apple devices). Starting with iOS 18, Apple enabled RCS support in the Messages app: communication with non-Apple devices gains high-definition media, read receipts, typing indicators, and more reliable groups. RCS messages on iPhones are displayed in green bubbles, and activation is possible through Settings → Messages → RCS Messaging (support depends on the operator). In the initial implementation, RCS in the iOS environment does not include E2EE, but GSMA has indicated that official cross-platform E2EE is included in new specifications, and the industry is moving towards MLS-based encryption.

In Lithuania, at the beginning of 2025, there were approximately 3.90 million active mobile connections (≈137% of the population), indicating a high prevalence of mobile services and a suitable environment for RCS expansion through operators and cloud channels. ([DataReportal – Global Digital Insights][1])

III. Security and Privacy: Current Status and Comparative Analysis

E2EE Today, MLS Tomorrow, and Comparison with Alternatives

3.1. Security Model and Current E2EE

The security of RCS has so far been fragmented: E2EE depended on the client. In the case of Google Messages, when all participants in a conversation use Google Messages and RCS, E2EE is automatically enabled (indicated by a lock icon). However, in cross-Android–iOS interactions, the initial RCS implementation in iOS 18 did not foresee E2EE – thus, some streams may not utilize end-to-end encryption.

3.2. What UP 3.0 and MLS Promise

GSMA has announced „Universal Profile 3.0”, which provides for E2EE among different RCS providers, with „Messaging Layer Security” (MLS) as the chosen core technology. This is the first step towards standardized, cross-platform E2EE, being implemented by providers (e.g., Google Messages has begun testing MLS), and Apple has confirmed its movement in this direction.

3.3. Comparative Context: SMS/MMS, iMessage, and OTT

RCS vs. SMS/MMS – RCS is clearly superior in functionality (IP, multimedia, receipts, groups), while SMS/MMS is outdated, lacking modern security mechanisms.
RCS vs. iMessage – iMessage provides universal E2EE within the Apple ecosystem; RCS is more open and broadly compatible (especially with Android), with iOS support starting from iOS 18, but cross-platform E2EE is still being implemented under UP 3.0/MLS.
RCS vs. OTT (WhatsApp, Signal) – OTT typically relies on mature E2EE (e.g., Signal protocol); the extent of metadata collection varies (Signal minimizes, WhatsApp collects more). RCS metadata management depends on the operator or platform, while cross-platform E2EE is being implemented through UP 3.0/MLS.

3.4. Summary Table

Indicator	RCS (Universal Profile)	Apple iMessage	Signal / WhatsApp
Type	Open industry standard	Closed Apple ecosystem	Third-party OTT applications
Core Technology	IP (SIP / MSRP, HTTP(S))	IP (Apple ID infrastructure)	IP (phone number or account identity)
E2EE Status (now)	„Google Messages” – available (1:1 and groups); cross-platform E2EE being implemented via UP 3.0/MLS	Universal E2EE for Apple devices	Universal E2EE (Signal protocol)
Compatibility	Widely works on Android; iOS support from iOS 18 (depends on operator)	Only Apple; with non-Apple – RCS/SMS	OS independent (broad)
Metadata	Depends on operator/platform	Limited within Apple ecosystem	Signal – minimal; WhatsApp – larger
Regulatory Influence	Significant (DMA and interoperability requirements)	Significant (DMA encourages opening interfaces)	Low or none

IV. Strategic Insights and Directions

What We Learn from DMA and Where RCS Is Heading

4.1. The Role of Regulation in Standardization

The EU Digital Markets Act (DMA) has practically prompted Apple to enable RCS support and laid the groundwork for interoperability among major platforms. This sets a precedent that critical communication functions must operate across ecosystems, especially when there is a large user base on other platforms.

4.2. Will RCS Become a Universal Standard?

The Universal Profile and Google’s strategy have reduced fragmentation. The biggest unresolved question is unified, cross-platform E2EE. UP 3.0/MLS provides the technical foundation, and implementations (e.g., Google Messages MLS tests) indicate an approaching breakthrough. Once stable cross-platform E2EE is achieved, RCS will become not only functional but also a secure SMS successor across all platforms.

4.3. Recommendations

For Operators: accelerate UP 3.0 implementation, test MLS compatibility, so that some service capabilities return from cloud providers to operator-controlled infrastructure. :contentReference[oaicite:13]{index=13}
For Technology Providers (Google / Apple): consistently implement MLS across both ecosystems and communicate the E2EE status to users (clear indicators, settings).
For Consumer Rights Advocates: advocate for cross-platform E2EE to be a mandatory attribute of RCS and monitor metadata collection practices.

Sources and Further Reading

Where to Learn More

Need help with your device?

If your phone, computer, or tablet is not working properly, bring it to Fiksas. We perform fast diagnostics and often complete repairs within 1–3 hours.

Book a repair