Why WebRTC Will Eat Up the UC World
Why WebRTC Will Eat Up the UC World by Tsahi Levent-Levi
For me, UC is as big and as stupid a term as Big Data, IOT and BYOD.
UC stands for Unified Communications, and now, Microsoft (Lync) is trying to re-coin it as Universal Communications. It holds the meaning that a person decides to give it. It has been over hyped and over abused, with no real dictionary term to indicate what is or isn't UC.
And it is the same for Big Data Analytics, Internet of Things, and Bring Your Own Damned Whatever.
Now that we've established the playing ground of UC, it is time to throw at it something that has some real meaning – a technology known as WebRTC – one that is going to take over whatever UC is and change its meaning yet again.
There are three reasons why WebRTC is going to eat up UC's lunch:
1. API vs. Signaling
It starts with the notion of how you connect the various systems that comprises a UC service. UC is predominantly VoIP related, making its focus on signaling and communication protocols. These are usually open for interpretation and wrought with interoperability issues.
WebRTC, on the other hand, is first an API and second a protocol. And today, when APIs are becoming massively popular, there is more room for an API type of thinking than a signaling protocol type of thinking.
2. Developer vs. Vendor Ecosystem
UC is based on signaling protocols, and as such, it is focused on enabling multiple vendors to connect their equipment together via interoperability. This creates a vendor’s ecosystem and a notion of vendor freedom – the ability to select one vendor and in the future replace or enhance said vendor with another one – a noble notion that rarely becomes reality: vendors have other means of locking their customers.
WebRTC, on the other hand, is all about developers. Not VoIP developers, but rather web developers. What WebRTC is achieving is a developer ecosystem – one where a large number of developers know the API and the language. This brings with it the mash-up world where integration across services and products is achieved via an open API (instead of a standardized or proprietary signaling protocol).
3. Federation and Interoperability vs. Service
UC services are all about federation – how I go about connecting my enterprise to yours. For some unknown reason, the decision on that was to take the route of archaic telephony roaming agreements – it is first and foremost a business decision.
They will say that employees shouldn't be able to chat with whomever they wish via UC; that it needs to be "controlled" and the keys be given to IT who ends up deciding who to federate with. I even heard this idea that opening up a UC system to non-employees is a security breach. That being the case, why not limit an employee's phone to specific phone numbers? He shouldn't be able to SMS to people the organization haven't approved in advance.
UC, Federation and Interoperability ends up creating islands of communications which might not be technical but rather bureaucratic ones.
WebRTC? Focus is on the service. How to create a service with the most reach to it. If you want federation, you can add it into the mix, but frankly, there's little evidence that this is what companies are doing with WebRTC.
Why is it important?
When UC is all about merging various means of communications together, WebRTC can do that far better than any other technology from a governance and workflows point of view.
In the same way that we see tension today between contact center vendors and CRM vendors, we will see tension between UC vendors and project management/web collaboration vendors.
For UC to really reach its potential, it needs to think out of its current box. It needs to look at the ideas and concepts that make WebRTC so interesting.