Two New Ways for a UC Vendor to Look at WebRTC
Two New Ways for a UC Vendor to Look at WebRTC by Tsahi Levent-Levi
Remember me? That nagging guy who likes to tell UC vendors that they are missing it with WebRTC only to hear that WebRTC doesn't solve so many problems UC vendors face?
Well, I am back. And I want to offer a different prism through which to look at WebRTC. Up until now, the only prism UC vendors used is in the area of accessing their existing architecture and solution. I want to offer two new prisms for you. If you start using them in parallel with your current worldview – you will only benefit.
Prism 1: Reversal
Let's reverse the way you view the world: place WebRTC in the middle, and your current solution as the outliers.
All of the room systems and endpoints you are installing? Make them pure WebRTC capable – have them run an HTML5 browser and let Java Script do the rest. Have your own solution use that type of a deployment. All of your legacy products? Have a gateway for them to access the system.
Gains?
- Each and every piece of software and hardware you now offer can run any type of WebRTC call – even types that don't necessarily come from you as a vendor. It won't assist in displacing you – it will only make your solution a better fit for customers.
- Maintaining and upgrading such a deployment is closer to any other SaaS solution – you deploy once and run everywhere.
Remember that as we shift to a world where most users will access your system from the web on an unmanaged network and device, the alignment around such a technology means a better architectural fit to the needs of the future. It also means enjoying the flexibilities of web development, which is our second prism.
Prism 2: Web
VoIP is hard. It is tough to develop. It requires an experienced and unique workforce. I've done it more than once. It is no fun. Web is different. Anyone can do web. Doing it right isn't easy. It is almost an art. But there are far more artists than there are VoIP developers out there.
I had to switch to web development mindset about two years ago, when I was faced with a 24-year-old snotty developer (I'd hire him in a second if he was unemployed) who tried to explain to me every step of the way that I am doing it wrong – that the way I ask him to develop just doesn't make sense.
There's a lot more trial and error going on when you do web development. There's a faster pace with a lot more of a feedback loop going on during the development. Very short cycles accompanied by immediate feedback.
It is time for UC vendors to look at the web as their platform and not their downloadable apps and hardware equipment as their platform. That switch in mindset means a change in architecture and a change in pace.
Gains?
- A native environment for meshing up services together – something that UC vendors are sorely lacking.
- A change in mindset: in the web everything is stored – not only for the IT manager, but for the actual benefit of the users. From call logs, to call recordings. Easily accessible.
- Faster development cycles mean better fit of the service to the end customers, assuming they are being consulted.
We live in a world where most of the action is in web and apps. In both cases, there's a web mindset attached to it. Join the crowd or be left behind.
WebRTC is happening. All the complaints about what it doesn't solve are things that can, will and are being solved already by vendors. Stating this obvious fact instead of trying to out-innovate competition because of this fact isn't productive.
Build your roadmap to the future – just don't do it with a WebRTC gateway please.