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 May 15, 2013 6 Comments
Tsahi Levent-Levi PNG
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.

 

6 Responses to "Two New Ways for a UC Vendor to Look at WebRTC" - Add Yours

Gravatar
Abdel Kander 5/16/2013 8:26:26 AM

A telecom marketing executive once told me: "you don't call your boss like you call your mother in law!". The point is that while WebRTC is/will be great for many things, vendors still have a lot of value to provide dealing with human factor!
Gravatar
Kevin Kieller 5/16/2013 4:26:57 PM

VoIP is hard. WebRTC is a very good codec library. There are other VoIP libraries but I'm a fan of people using WebRTC.

When you write " let Java Script do the rest" this is naïve. The rest, like VoIP, is also hard. I want my endpoints (even if they are just browsers running WebRTC) to connect multiple parties into a conference. I want authenticated users, presenter control, ability to share my desktop, have presence, do polls, record the session, add calendar invites, mute remote participants, and more.

WebRTC can be a great part of a solution but it is only still a part. I want someone to invite me to a real WebRTC powered multi-party audio/video/web conference. I don't want another hacked together WebRTC demo that someone tells me they created in a week. Take the time and show me a production ready multi-party system.

Kevin
Gravatar
Marvin Mansour 5/17/2013 4:25:52 AM

Tsahi, enjoyed your great article.

I've been using the VoX Mobile VoIP App from VoX Communications on my Samsung Galaxy. They recently added a video plug-in feature. Not all VoIP is created equal, those guys have nailed it down, great quality. They appear to be making inroads into WebRTC, it's worth a look
Gravatar
Tsahi Levent-Levi 5/18/2013 7:06:53 AM

Kevin - I never said the rest isn't hard - but relying on that hardship to be the barrier of entry and the lifeblood of a business model is rather risky.
It took Google about a decade now (I think) to make a dent in Microsoft's office hegemony. How hard should it be to decimate the fragmented VoIP and UC markets through a web based offering?

Marvin - thanks - I'll check them out.
Gravatar
Jeff Hoefgen 5/21/2013 7:08:43 AM

The real point Tsahi is making and he is correct - will you allow your vendor to guide you through their evolution of UC or will you break away from the h/w chains and do the "right(technology, cost, future oriented) thing". To allow your current h/w vendor to guide you is a sure way to the RTC gateway path with you legacy products still at the core. This will increase your vendor dependency, increase your long-term costs and decrease your ability to use the latest and greatest.

Tsahi - is saying, don't fall into that trap- be smarter...I agree.
Gravatar
Kevin Kieller 5/22/2013 7:04:12 PM

Tsahi - while you didn't say the rest was easy you certainly imply it when you wrote "let Java Script do the rest". As a developer maybe this rubs me the wrong way :-) It reminds me of when people over simplify a problem by saying "it is just software".

I'm not clear how WebRTC magically "meshes" services together.

I want to see more production-ready WebRTC examples and less "I coded this in a week" technical demos. Plenty of development tools / libraries let me quickly create a simple demo. Few let me "get the job done" and scale to medium or large business sizes. I know WebRTC can provide consumer-grade peer-to-peer communications. I'm waiting to be shown it can scale up and out.

Kevin

To Leave a Comment, Please Login or Register

UC Summit 2013 UC Alerts
UC Blogs
UC ROI Tool RSS Feeds