5 Things Everyone Should Know About WebRTC

When I see a post with the title “WebRTC And V.VoIP: Friends Or Enemies?” there are two things to do:

1. Ignore it as a blatant attempt at getting more page views and clicks
2. Write something of my own that has a catch-eye title, but way more value

Consider this that post.

–

I am going to present in two weeks’ time at Enterprise Connect a long session about the Fundamentals of WebRTC. A lot of the material for that session is new – created specifically for the session. The main reason for it is that I bore myself if I talk too much with the same slides.

I also decided to start and finish that presentation with the following slide:

Many people forget that minor detail…

But it isn’t enough. So here are 5 things that everyone should know about WebRTC – at least if he knows anything about VoIP or HTML5.

Here’s a table I like showing in my presentations about WebRTC:

It shows a comparison between WebRTC and SIP. There are 3 things that can be derived from this table, all important, and all point to the advantages WebRTC has over SIP.

1. SIP has a lot more options to it for virtually everything. I consider this a bad thing as more options mean more headaches in interoperability and more choices for the developers and operations people to screw things up
2. WebRTC has a specific, widely known API, which enables the creation of a developer ecosystem. SIP only has a network interface, along with proprietary APIs, specific to each vendor – which lends itself to interoperability and federation thinking – things that are a bit less important these days
3. WebRTC is targeted at web developers and not at VoIP and communications equipment vendors. This last one is critical. It indicates where disruption will come from, and how current day thinking about VoIP solution and their operability issues (scaling, security, high availability, etc.) just don’t fit anymore

I find it funny when people try to put WebRTC in the same scale of a SIP solution and look at security threats of the two. WebRTC lives in a world of web, where the issues are analyzed and dealt with slightly different. Same thing with scale – WebRTC works well with distributed systems and web scale technologies (think Big Data); places where SIP isn’t as flexible.

When trying to fit WebRTC into an enterprise setting, best to think of the problem statement in web related terms and not enterprise ones.

There are so many voice and video calling vendors, services and projects that use WebRTC that it is getting a bit crowded. It is also very boring. I think I’ve seen this past month every conceivable layout of talking heads imaginable.

But the thing is, WebRTC has a lot more to offer elsewhere. WebRTC is split into 3 main APIs:

1. Get User Media, which essentially provides access to the camera and the microphone of the machine you use
2. Peer Connection, which handles the communication part, including all things VoIP
3. Data Channel, which enables sending any arbitrary data direct between peers/browsers

Ignoring the Peer Connection for a second, there’s a lot that can be done with the rest of the APIs that WebRTC has to offer. There are many uses for the Data Channel already, but there’s also a lot to be achieved with Get User Media alone. Here are two:

1. MailChimp. They just use it to take your photo when you build your profile
2. Tuner-Online.com. An online guitar tuner

None of these even deal with communications, but they were impossible to develop without WebRTC. It would be nice to see more uses of WebRTC beyond yet-another-way-to-make-a-video-call-and-kill-skype-or-webex.

There’s a huge fight about the video MTI codec. That’s the mandatory to implement codec in WebRTC. Is it going to be VP8 or H.264?

The thing is – not everyone cares. If I have a point-to-point video calling service, and that’s all I need from WebRTC:

• I don’t need to record anything
• I don’t need or want to connect to external video systems
• I don’t need to handle multipoint
• I am not trying to broadcast the session

Just a pure video call between two peers.

All I need is for the browsers to decide which one codec they all support. Be it H.264, VP8 or whatever else they decide to use.

If you ask me, this is going to be most of the use cases out there.

As long as there’s an agreement on at least one video codec that all browsers use, many of the vendors just don’t care about the exact selection.

We’ve been talking about WebRTC for two years now, but the truth of the matter is that the standard isn’t closed yet – there’s no specification – no RFC with a number – just a bunch of draft documents.

That said, there are around 350 different vendors and projects that I am now monitoring – all using WebRTC. For a non-standard, that’s quite a lot.

It means several things:

1. Don’t wait for it to stabilize. You’ll be left behind
2. Prepare for surprises. Your solution might break with the next browser version release (every 2-3 months). You will need to make changes in your code. Deal with different API naming and behaviors. Guess what? That’s how web developers have been working for years with new technologies. For them, WebRTC isn’t an exception
3. It will require organizational and procedural changes within your organization

You can treat this as a challenge, or you can look at it as an opportunity to improve. Your choice.

WebRTC isn’t perfect.

It isn’t implemented on IE or Safari.

It behaves differently between Chrome and Firefox.

It has no video codec decision yet.

It has this ugly thing called SDP that everyone loves to hate and use it anyway.

It doesn’t really work on mobile unless you make a real effort.

There’s no good server side solution from Google for all of us to use for free in our services.

All that is true.

But it is also the best solution out there by far if you want to start building things. Use it, and instead of complaining, go find your own solutions and sweat a little.

–

Want to learn more about WebRTC? I have just the report for you: WebRTC for Business People