Sponsored By

WebRTC Infrastructure is TrickyWebRTC Infrastructure is Tricky

If I were in the position of Google today, I'd invest someone for the next 12 months in churning out how-to documents on building that infrastructure.

3 Min Read
No Jitter logo in a gray background | No Jitter

If I were in the position of Google today, I'd invest someone for the next 12 months in churning out how-to documents on building that infrastructure.

There's a lot to be said about the ease of use of WebRTC and how it lowers the barrier of entry for anyone thinking to use VoIP. What is usually left out, or more accurately, where I think the biggest hole that Google has left us, is on the infrastructure side.

A while ago I wrote here about the hurdles of streaming, from the point of view of Netflix. From the interviews I did with WebRTC companies, it is easy to say that the hardest thing they have to deal with is the infrastructure.

The one that really strikes home? When Jeremy Thomas of popexpert answers what he would change in WebRTC:

"I'd love to see a more authoritative reference architecture which illustrates how to setup a TURN server, which technologies are good for signaling, etc."

One of the hardest issues for developers with WebRTC? Getting the backend up and running. There doesn't seem to be any good documentation or walkthrough on how to do that well--and in a world of APIs, that's the largest missing part.

If I were in the position of Google today, I'd invest someone for the next 12 months in churning out how-to documents on building that infrastructure.

WebRTC is an API and should be treated as such. If the company behind it wants to get more adoption for it, then they need to take care of all of the developer's needs:

API documentation
There's documentation of the API on the official WebRTC site. I find it somewhat lacking--placing it all in a single HTML page is demeaning in my view. It is also missing some basic code examples and links to related APIs.

Good forum
Every API requires a good place to ask questions and get answers. Unluckily, in this case, the forum is based on Google Groups, which is "ok". A better choice would have been to open up a dedicated Stack Exchange site for it--or something of that caliber when it comes to the types of interactions it enables.

Code samples and how-to guides
There are a few provided by Google, but they are lacking. There needs to be a good place that shows real code samples--things that people actually want to develop--and things that aren't trivial; and we already know that the backend side isn't trivial.

Things that come to mind?
* Setting up TURN server to work with WebRTC
* Implementing basic multipoint video call
* Using SIP signaling
* Using XMPP signaling
* Using basic JS signaling

Focus on WebRTC training by Google should shift from WebRTC APIs to how to stitch WebRTC's infrastructure to build services.

Once that happens, the biggest real gap and hurdle of most developers out there will have been resolved.

About the Author

Tsahi Levent-Levi

Tsahi Levent-Levi is an independent analyst and consultant for WebRTC.

Tsahi has over 15 years of experience in the telecommunications, VoIP,and 3G industry as an engineer, manager, marketer, and CTO. Tsahi is an entrepreneur, independent analyst, and consultant, assisting companies to form a bridge between technologies and business strategy in the domain of telecommunications.

Tsahi has a master's in computer science and an MBA specializing in entrepreneurship and strategy. Tsahi has been granted three patents related to 3G-324M and VoIP. He acted as the chairman of various activity groups within the IMTC, an organization focusing on interoperability of multimedia communications.

What Tsahi can do for you:

  • Show you how to take your company to the forefront of technology

  • Connect you to virtually anyone in the industry

  • Give you relevant, out-of-the-box advice

  • Give you the assurance and validity you are looking for

Tsahi is the author and editor of bloggeek.me,which focuses on the ecosystem and business opportunities around WebRTC.