US Carrier Pivot: The End of CCMI and Google's RCS
Back in October 2019, AT&T, Sprint, T-Mobile, and Verizon made a big joint announcement. They were forming the Cross Carrier Messaging Initiative — CCMI — to bring RCS messaging to every Android user in the US. A unified front. The carriers would handle it together.
It sounded great on paper. Four carriers, one initiative, interoperable RCS for everyone. The pitch was straightforward: replace SMS with something modern, and do it as a consortium so no single carrier has to go it alone.
That was about eighteen months ago. CCMI hasn’t shipped a single product.
I don’t think it ever will.
The CCMI Problem #
The fundamental issue with CCMI was always coordination. Four massive telecom companies — each with their own network infrastructure, billing systems, and strategic priorities — trying to agree on a shared messaging product. Anyone who’s worked on a project with even two stakeholders knows how that goes.
Sprint merged with T-Mobile in April 2020. That reduced the consortium to three effective parties, but it didn’t simplify things. If anything, T-Mobile’s expanded market position gave them less incentive to cooperate on a joint venture where they’d share control.
And then T-Mobile made the move that, in hindsight, killed CCMI’s reason for existing.
T-Mobile Goes Google #
In May 2020, T-Mobile partnered directly with Google to support RCS through Google Messages. This wasn’t a tentative pilot; T-Mobile committed to Google’s Jibe infrastructure as the backbone for their RCS messaging. Their subscribers started getting RCS through Google Messages rather than through any carrier-built solution.
That partnership undercut CCMI’s entire value proposition. The initiative existed because carriers argued they needed to build their own interoperable RCS system. But T-Mobile — one of the four founding members — decided Google had already built it. Why duplicate the effort?
The answer, obviously, is that you don’t.
Google’s Carrier-Independent Play #
Here’s what I find interesting about Google’s approach. They didn’t wait for carrier cooperation. They built the infrastructure (Jibe Cloud), shipped the client (Google Messages), and started rolling out RCS directly to Android users regardless of whether their carrier supported it.
This is a classic platform move. Instead of negotiating with gatekeepers, Google went around them. The GSMA Universal Profile provided the standard; Google’s Jibe Hub provided the interconnect. Carriers could join whenever they wanted, but Google wasn’t going to hold the rollout hostage to carrier timelines.
By early 2021, Google Messages supports RCS for the vast majority of Android users in the US. The app handles the RCS connection server-side through Jibe, so even if your carrier hasn’t officially “enabled” RCS, you can still use it. That’s a fundamentally different model from what CCMI proposed.
CCMI wanted to be the RCS provider. Google made that irrelevant by becoming the RCS provider while the carriers were still drawing up architecture documents.
Why This Matters #
The CCMI story isn’t just about RCS. It’s a case study in how consortium-based innovation loses to platform-based execution.
Carrier consortiums have a terrible track record with messaging products. Remember Softcard (the mobile payments joint venture)? Or Isis Wallet before that? These joint ventures move slowly because every decision requires consensus among competitors. Nobody wants to give up control, nobody wants to fund the other guy’s advantage, and the result is paralysis.
Google’s advantage wasn’t technical sophistication — the Jibe infrastructure isn’t doing anything the carriers couldn’t have built. The advantage was speed and unilateral action. One company, one codebase, one rollout plan. No committee approvals.
What’s Next #
T-Mobile’s Google partnership set the precedent. I’d expect AT&T and Verizon to follow a similar path eventually; the alternative is maintaining their own RCS infrastructure (expensive) for a product that competes with something Google gives away for free.
The end-to-end encryption story is still developing. Google has been testing E2EE for one-on-one RCS chats in Google Messages, which would address one of the biggest gaps between RCS and iMessage. It’s in beta now, but the direction is clear.
For CCMI, the writing’s on the wall. The initiative hasn’t produced anything tangible in eighteen months. T-Mobile already left for a better option. The remaining carriers don’t have the combined leverage to justify building a competing RCS infrastructure when Google’s already won the install base.
Sometimes the best strategy is recognizing when someone else solved the problem faster than you could. The US carriers are learning that lesson with RCS — some more willingly than others.
The Bigger Picture #
I’ve been tracking the RCS ecosystem for a while now, and the pattern repeats across regions. Carriers want control of the messaging layer because it’s strategically valuable. But building and maintaining that layer requires the kind of rapid iteration that telecom companies aren’t built for.
Google’s bet is that RCS becomes the default Android messaging protocol, with Google Messages as the client. If that happens (and it’s happening), the carrier’s role shrinks to providing the data pipe. That’s a significant shift in power dynamics.
CCMI was the carriers’ last real attempt to own the messaging experience on Android. Its failure — which feels inevitable at this point — means Google won the US RCS infrastructure battle without the carriers ever really showing up to fight.