Discover the impact of WebRTC and Android on interoperability in communication technology
Interoperability used to be able vendors coming together and making sure their communication equipment talked to each other properly. This is no longer interesting or relevant it seems.
Today, interoperability is mostly about the ability of a service to run from any device and for a service to be reachable by “others”.
How is all that achieved? By relying on two technologies: Android and WebRTC
Table of contents
The good old days of H.323 and SIP interop events
Let’s start with a bedtime story – one that will reveal a lot of my “upbringing” in this field and my love and passion for WebRTC and communications.
Tsahi gets acquainted to communication protocols and signaling
When I started working in the communication space, some 25-30 years ago (who’s counting?), my first role was a developer in the H.323 Gatekeeper Toolkit at RADVISION.
H.323 was/is a long lost signaling protocol that started life at relatively the same time SIP did. It was all the rage, and was THE protocol to use for video conferencing.
Anyways, it took about a week until my computer that was ordered late arrived. What do you do with a new engineer in that period of time? Ask him to print and read standard protocols obviously…
My education in that first week consisted of reading H.323, H.245, H.225, ASN.1 and a few other interesting protocols. All now lost art, like COBOL. Once I finished reading these, I asked to read the source code of the gatekeeper toolkit (a signaling server SDK if we simplify it). I had the opportunity of finding a bug on paper 🤣 #truestory
Here’s the thing though. This first week served me well. Through the next 13 years at RADVISION, I worked in and around communication protocols. It included developing them, marketing and selling them, working in standardization bodies as well as going to and hosting interoperability events.
Up until recently, and maybe even today, when you go into a meeting room and see a room system – there is code I’ve written that runs in that room system.
The idea behind communication protocols
Go back to the early 2,000s. We need to understand and realize what the market assumptions and limitations were at the time:
- Big service providers had millions of users. Unlike today, where we have networks with billions of users in them
- Everything was hardware. You couldn’t really use software based solutions on a PC. There were a few, but that was the exception to the rule
- No browser support. It wasn’t even thought of as a possibility
- The mindset was to copy the telecom system. Global identity system (phone numbers or different), where anyone can reach out anyone else on the network
- On premise. The cloud didn’t exist. There was no AWS EC2 and S3
- Proprietary and closed source. Open source was at its infancy at the time, with most of the industry still mostly ignoring it and a few just figuring out what it is
- Fragmented operating systems world. Most used things like VxWorks, Nucleus, pSOS and similar. Embedded Linux was all the rage – innovative and new. Linux was a big no no. Same for Windows. No Mac or iOS to speak of. The dominant operating systems were all “realtime” ones, which frankly, I have no clue even how to explain it in 2025
With these assumptions in mind, came a set of conclusions:
- Vendors develop and (mainly) manufacture conferencing devices
- Customers don’t want to be vendor locked-in and would like to be able to purchase devices from multiple vendors over a span of a few years or even decades
- Hence devices purchased from multiple vendors should be able to “talk” and communicate to each other 🟰 interoperability
Let’s recap real quickly:
- Standard protocol is defined
- Vendors build products that implement the protocol
- Products communicate with each other
Travel the world in the name of Interoperability
We call the concept products communicating with each other “interoperability”.
Since multiple vendors are reading the standard protocols independently and implementing them independently, the results almost never interoperate immediately. This type of work led to different understanding and implementation of the standard protocols and to varying behaviors that caused devices not to be able to communicate properly.
Companies had large physical labs with products from multiple vendors and a QA team that manually tested against them at all times. It was time consuming and expensive to operate.
To make things easier, there were (and still are) interoperability events. These are prescheduled industry events where companies join in by having their engineers travel to a single physical location (a large hotel, office of a company or a university) with their devices and test them against each other for a period of a few days.
I had my fair share of such events, even hosting two of them in Israel.
They are great. But they are far from flexible, since they occur once or twice a year at specific times and you don’t control who is there and how much time they will have for you.
Our brave new world of “interoperability”
That was 20 or so years ago. Times changed. Quickly.
Today there are still interoperability events. There were even one or two for WebRTC (🫨). But guess what? The interoperability events for WebRTC were scheduled and conducted between browser vendors in the early days. That was it.
In our new world of cloud computing, there is a lot less need and pressure for interoperability events.
The reasons for that are various. I’d mention 3 of them and then go to the anchors of interoperability we have today:
- Cloud computing. Things get deployed in the cloud and at scale. Everything is virtual, and devices themselves have shifted from designed, realtime, proprietary operating systems, to open sources, virtualized software solutions. This simplifies development and reduces costs for everyone – from the entrepreneurs to the end users
- Shorter hardware lifespan. Hardware has a shorter lifespan. We replace our phones on average every 2-3 years (I know you don’t – we’re talking about the average Joe here). Software is the focus today for the most part, and most companies have less of a vendor lock-in from a physical conferencing device point of view
- Open source. This enabled less people to write their own opinionated implementations where most vendors now rely on a few limited open source implementations (that get tested against each other more frequently because they are more accessible)
Android is eating the hardware world
The first new champion of interoperability is the Android operating system.
It started as a smartphone OS, but today it is much more than that.
You can find Android today in most TV set top boxes and streamers. You can also find it in most video conferencing room systems.
At the extreme, Microsoft today relies on AOSP – Android Open-Source Project when letting its partners build Microsoft Teams hardware devices (I’ve covered that on the RTC@Scale 2023 summary). Translated to the language of this article – Microsoft relies on Android to provide the interoperability it needs for its Microsoft Teams ecosystem.
If you want to build interoperable communication devices today, the main approach is to build devices that existing service providers will be able to use. Android offers a great operating system for it.
Moreover, one vendor can enable the installation of an Android app of another vendor on his own device. In this way, you can get WebEx running on a Microsoft Teams room system or vice versa. I am not saying that this is how it is done today – only that it is a valid technical possibility that I am sure some of the vendors are utilizing.
WebRTC is eating the software world
Then there’s WebRTC. The great equalizer of real time communications:
- WebRTC is an open standard
- It is a well maintained open source implementation with a permissive license
- All modern web browsers have WebRTC support built-in
This availability makes it the perfect candidate for offering an interoperability piece of software without offering interoperability at all.
What do I mean by this? Here are 3 ways in which companies are using WebRTC to overcome the need for classic, old-school interoperability:
- Offer guest access using web browsers and WebRTC. Most video conferencing vendors offer this out of the box today. Hell – you can even send an Apple FaceTime video call invite URL for anyone to join from a web browser
- Build third party services into your room systems. The Android devices mentioned earlier? They also have Chrome and WebRTC in them, which can then be used to run the third party apps much the same way as installing full Android apps – just with web technology
- Offer DMA interoperability.The Digital Markets Act is EU regulation that forces large social networks to open up access and offer interoperability. The easiest way to do this for calls is by way of WebRTC (which is what Whatsapp did with its new Business Calling API)
Instead of having interoperability across vendors, what WebRTC enables us to do is to offer interoperability across devices and browsers – all relying on the WebRTC implementation. How do we validate behavior? Against Chrome of course…
Business APIs to the rescue
The third interoperability enabler of our time is the API. Instead of relying and agreeing on a standard, a service can just expose and publish an API layer to access the service. And when it comes to social networks, these are business APIs.
As I’ve mentioned earlier, the DMA interoperability translates at the end of the day into an API layer that social networks expose. And they usually do so via their business API which is geared more towards having businesses communicate with the network’s users than it is about a user of another social network communicating with users on the network (theoretically possible).
The companies making the most of these interfaces today are likely Meta’s Whatsapp and Apple’s iMessage, who both offer business APIs.
Interoperability today is still important
In some industries at least.
It isn’t that the old way of interoperability based on standard protocols isn’t relevant today. It is. Especially in the realm of telephony and cellular networks. For the most part though, in internet communications, it is enough to have standards that are agreed upon and implemented by the browser vendors.
The rest of the industry simply aligns on top of the browsers and these implemented protocols to the best of their ability.
The future of MCP and Generative AI
MCP is something I’ve been thinking about for quite some time. MCP stands for Model Context Protocol. It is a standard proposed by Anthropic for letting generative AI systems (LLMs) interact with third party APIs.
The nice thing about it is that it offers a natural language description of what an API interface does, so that once implemented, an LLM can query the API and figure out on its own what it can do, how to invoke it and what it can expect in return.
The neat part about it? Once every API has its MCP server and description, AI agents can figure out how to interact and interface with them.
This can bring interoperability to a whole new level, in many cases making it a moot point to even needing to think about interoperability at the lower levels of the implementation, leaving it to the MCP layer itself. We see this being discussed for integration purposes in enterprises, but there’s nothing that is barring us from using it for communication services as well.
Where do we go from here
The future is more interesting and integrated than ever before.
Interoperability is here to stay, but its focus and target audience is changing.
For communications, the cloud along with other trends have pushed it from a desired mechanism between device manufacturers to a low level layer across browsers and devices. The interoperability itself is taking place today via Android, WebRTC and APIs. The future, that’s for MCP to figure out.👉 If you are looking some guidance with your roadmap and strategy, leave me a note