GoS_anonuser1
Carrier built/updated RCS server support is carrier/country/roaming specific, and very spotty and situations change from year to year
If you want to avoid these problems, you can (in some areas) use exclusively Google RCS servers on your end. This does not solve necessarily all the issues at the other end (or RCS receiver)
But whether you use carrier servers or google servers on YOUR end (your device) does not guarantee RCS E2E encryption, as it is a provisional standard and not all carriers have implemented it
So, in short, even if you have gotten "RCS working" on your phone, doesn't mean you are sending/receiving E2E encrypted RCS messages and unless you snoop the traffic, there's no sure way to know this
A couple points here just to clarify (again, since this is in the 18K Messages above multiple times, including as recently as 2 months ago).
Google used to run thier own RCS server and in thier Google Messages app would fall back to using that server if your carrier didn't support it. This was to get traction and adoption. They incidentally also used the same server for thier GoogleFi carrier service.
Carriers slowly adopted over the years, some by paying Google to run servers for them, and others for Google to just set them up inititially. However, the only carrier RCS server implementation that has ever existed is the one from Google.
On 19 Sept 2025 there was a global RCS outage for almost 2 days. From carrier insider reports, this corresponded to the deadline Google gave for carriers to take over full management of RCS servers, which almost certainly means Google restricted access to thier fallback server. It is now only used by GoogleFi users as thier carrier's RCS server and is no longer usable as a fallback. The 2 day outage was carriers scrambling to fix problems with thier carrier servers taking over when any problems were no longer hidden by fallback to the Google RCS server.
The RCS standard defines a lot of open ended parts, like how authentication and authorization work. It's pretty much unspecified in the standard what the specifics are, and it's Ana tea the carriers have clearly been playing with. The authentication is how you get the "RCS Connected" message, while proving authorization via prior authentication, and renewal of authorization are necessary to maintain provisioning (Etouffe status). The basic concepts are pretty standard security practices, but the specifics of restrictions and limitations are completely opaque, unspecified by the RCS standard, and regularly changing carrier by carrier and over time.
E2E is not actually part of the base RCS standard. It's part of the open ended "other features". RCS standard, like many modern communication protocols, supports capability negotiation. From the intersecting set of capabilities that the two client's carriers support, the clients can determine which capabilities the specific client devices both support. These capabilities b can include features that aren't part of theb original RCS spec such as E2EE. It's up to the clients to make use or it though.
All carrier RCS servers are the Google server implementation of the RCS standard, so all of the servers support this additional capability. Among the two existing RCS client applications (at least the two that have knowledge of and a method for the unspecified carrier specific authentication and authorization parts of RCS), Google Messages and Apple iMessage, only the Google Messages client had implemented support for this add-on capability.