It’s been 10 years since we released our first WebRTC-based UCC solution. But why did we choose this innovative solution? Let’s take a dive into WebRTC and how it came about.
A Brief History of WebRTC: The Lead-Up
Wildix had been using applets to create direct serverless connections in browser since it released its first soft client in 2009. This was a clunky way of doing it, and there were a whole host of issues — a lack of cross-browser support, small browser updates that could break things seemingly at random and the reduced reliance on Java within browsers due to security (and efficiency) issues.
The key problem was no standardization between browsers and a lack of integrated support for the technologies that allowed peer-to-peer video conferencing.
Yet we managed to make it work. Just.
The key technologies were already there, however. Serverless P2P streaming had been freely available since the late ‘90s and early 2000s, notably with the rise of file-sharing torrents. Those who were teenagers and 20-somethings at the time likely knew “a friend” who regularly had popular TV shows and films well before they were widely released.
In addition, telco vendors had already started to see the threat posed by easy access to data streams. Flash 2.0 supported stereo sound back in 1997, and various instant messengers, such as AOL, MSN Messenger and even Yahoo Messenger, provided calling abilities along with SMS-like abilities.
Simultaneously, Mark Spencer developed Asterisk, the first IP-PBX, in 1999 after he couldn’t afford a conventional PBX for his company. This would form the basis of many, many IP-PBXs and would eventually inspire the Wildix Blue Ecosystem.
Skype was released as a beta in 2003, one of the first IP video-calling solutions. All of these offered an insight into what the future would hold, and it’s one that Dimitri and Steve Osler could predict happening. Especially since Dimitri’s thesis was on the development of Asterisk.
So the stage was set for WebRTC
The Development of WebRTC
Global IP Solutions was founded in 1999, and it focused on embedded software that enabled real-time communications (voice and video) for IP networks. Typically, its products were delivered as “engines” that packaged everything the client needed.
The company understood that most VoIP technology had been developed for circuit switched networks — ones with a dedicated channel through which network nodes could communicate. These were highly stable and could be relied on to produce optimal conditions for VoIP.
However, most VoIP calls were over public IP networks, which were subject to packet loss, delay and jitter. A call to an office on the same network was fine; a call to an external client often was unusable.
Global IP Solutions was acquired by Google for $68.2 million in 2010, who started incorporating their patents and ideas into its own open-source standard: WebRTC. It would also work with other companies to develop this idea further.
The initial release of WebRTC was arguably in January 2011 by Ericsson Labs (then a subdivision of Ericsson). It was via a simple blog post: there was very little fanfare. For many, it went wholly unremarked.
In June of the same year, Google released the source code for WebRTC, and the year after it submitted the WebRTC specification to the World Wide Web Consortium and to the Internet Engineering Task Force to help standardize the protocol. This resulted in both Chrome and Firefox implementing WebRTC in 2013.
Wildix quickly found the protocol was highly versatile and secure enough to use. We ditched the NPAPI applets that we’d developed and worked out how to incorporate critical elements into a WebRTC-compatible program.
Or rather, almost ditched those NPAPI applets. The reality was that while Chrome and Firefox supported WebRTC, Microsoft’s beleaguered web browser didn’t at the time. Although this would’ve been fine had we focused on the consumer market, Internet Explorer — later Edge — was still heavily used by businesses.
By summer 2013, we had a working WebRTC communications solution for webpages: WebRTC Kite. This allowed us to connect our PBXs to the webpage to enhance communication in real time. While we’d achieved a similar solution previously with Collaboration running in the browser, this one technology made the process much simpler. But due to the issues above — the “standardised” solution was not yet standard — we found that we had to maintain a lot of code and a large number of updates for other browsers.
But hard clients were becoming redundant.
As more browsers incorporated WebRTC, our initial growing pains were going away. Microsoft would eventually incorporate a form of WebRTC (almost) into its browser in 2017, as it was determined to do something different, as usual.
Even as WebRTC was rapidly becoming a standard, there were still significant issues with the mindset of many UC&C solutions. Most still wanted some sort of hard client downloaded, and many still do in 2023! This can lead to security issues, one of the most recent significant ones being (at time of writing) the 3CX security incident.
Similarly, most so-called WebRTC solutions are still maintained by the applets and plugins of the early 2010s, which result in much more development time, less stability and lower security. After all, why download something when it’s all available in your own browser? To us, it doesn’t make sense.
Further Uses of WebRTC
The uses of WebRTC aren’t limited to real-time communications. As our development of x-bees shows, you can integrate a huge range of products with a WebRTC solution, and the fact that it’s all in-browser makes it highly efficient.
Take the integration with Salesforce,for example. It allows automatic opening for incoming and outbound calls, autodetection of existing contacts within the Salesforce database and a popup for inbound calls.
There’s very little additional headroom required, and there’s no need for a complex integration with a hard client. From a personnel point of view, this simple integration results in huge time savings — there’s no need to copy and paste numbers (or manually enter them). It also allows you to pull up records rapidly from the database just from a number, if they already exist.
Add to that the automatic logging of calls, chats and so on, and you’ve got a heavily sales-oriented solution that keeps your contacts sticky.
But there’s even more WebRTC can do. Videoconferencing is, as mentioned previously, simply data going over a network. So what about remote access via WebRTC? Instead of downloading clunky software, a WebRTC data channel can be used (with the client’s permission) to control a system remotely. This could make checking a computer much easier for MSPs and other IT service providers — especially where ad hoc technical support is required.
Wildix can already do this purely over WebRTC.
And there are other opportunities in the pipeline.
The Effect of WebRTC
What WebRTC has done is standardise the basic building blocks of the browser to enable real-time communications. It doesn’t really matter which browser has it, either — every significant browser now has some form of WebRTC enabled.
Wildix can be used by almost any system, without additional extra plugins or downloads required. As a result, it’s lightweight, easy to use and rapid to deploy.
So the question is this: Why wouldn’t you go with a WebRTC solution?
For more insight on cybersecurity and tech, subscribe to receive our magazine for free!