Chris Kranky

Recent Posts


How to simplify WebRTC?

I make some recommendations for the WebRTC Community. We need less, not more.

Chris KoehnckeChris Koehncke

Holidays are a great time of reflection. In 2016, I traversed the world talking up WebRTC at events, groups, and gatherings and meeting with other WebRTC advocates. But in the quiet silence of the end of the year, I realized that “we” the WebRTC Community are failing at our primary directive to make WebRTC accessible.

It hit me when I asked my colleague, Chad Hart (editor of WebRTC Hacks) how long it would take to get a simple Co-TURN server up and running. He said it would take someone who knew what they were doing a few hours of work. A few hours? For a TURN server? Really?

In fact, the GitHub directions for installing co-turn assume you are a rocket scientist. The directions are ambiguous and assume a high level of knowledge. I use this as a mere example.

But why does it have to be so difficult?

I am not a developer. I am not a DevOps person. Yet, I managed to install OpenStack on a test server all by myself. I installed MongoDB. I even got GE’s IOT Predix up and running (now I just need to find a jet engine to ingest data from). LAMP and MEAN installs take just a few minutes from scratch. Yet the minute I touch anything comms related, I look like an idiot. I may not be alone.

But a Co-TURN server takes a “couple of hours.”

Imagine¬†your classic developer. Not in San Francisco, but Des Moines, Iowa. They live in a LAMP world. It’s PHP and a MySQL database and they’re working on the new inventory management system. Their last excitement was rounded CSS boxes. They don’t read TechCrunch but they do coach the local softball league.

So one rainy afternoon, our classic developer has heard about this WebRTC thing and wants to add a video chat to the inventory management system so that the Omaha office can beam in. That would be cool. They’d read an article about how WebRTC has made communications easy. So off they go. This won’t take long, so they think.

But layer by layer, the complexity builds. Remember, this is a LAMP developer, distributed state computing is Cape Canaveral stuff.

You need a signaling server. Where do I get one of those? Who knows. What protocol are you going to use? I have to figure that out? Are you planning on doing any SDP munging? Should I? I hope you’ve given consideration to how you’re gonna deal with your ICE candidates. I thought I already voted. You are going to use VP8, right? Is there a 6-cylinder version? Do you think you will need TURN because that’s gonna take you 2-3 hours and that’s IF you know what you’re doing?

This is just for a simple 1:1 application. You wanna get more complex. Go look at the directions on how to install any of the open source selective forwarding units (SFU). Note: 99.99% of the world has no idea what an SFU is. No matter, it’s faster to put a man on the moon than figure out how to get these platforms up and running.

Is there any surprise only the hardcore make it through this gauntlet?

In the early days of WebRTC, great work was done by Priologic and &yet in offering open source base component solutions. But these were commercial businesses and while they seeded the early work, the broader community needed to take rally around it.

Now before you come after me. I’m simply asking you, the WebRTC community, the true experts – what can we collectively do to make WebRTC easier to implement. That was our original objective, right?

Our position isn’t unique. Many technologies have suffered this before. Usually, there is a small group of well meaning, highly intelligent and equally highly opinionated people who have sparked the initial creation of a piece of technology. The group is eager to be heard, but at some point, it switches from trying to include to trying to exclude newcomers. And like old men at the coffee shop, we sit and argue amongst ourselves in a language only we understand.

We know the technology works and due to the hard work of many, we know that it works pretty well. However, those who have implemented WebRTC applications did so after crawling across broken glass. The word ‘fun’ wasn’t in the equation.

So as 2017 moves in, I’m focusing more and more on the developer in Des Moines Iowa. How can we make WebRTC more approachable to a broader market of developers and applications? Easier is always harder.

Here are my thoughts if we want to include the other 95% of the world.

Documentation is important. Don’t assume people are following your scripted notes. Digital Ocean documentation is a great reference, the idiot’s guide to installing virtually anything. I don’t buy that true experts are annoyed by great documentation. We all need help periodically.

Most developers don’t write distributed state applications. So we need to guide them to the correct choices. It’s not necessarily important for them to understand exactly how something works, just that it works. Usable and supported modules are needed.

Minimize the noise on the edges. A new comer walking into the room with a heated argument underway on whether H.264 or VP9 is better can be a bit scary when that person has no idea what a codec even is.

Return to basics. Don’t assume everyone has been on this journey the whole time. Many of the early samples that were written don’t work as WebRTC and the browsers migrated. It’s OK to re-do and improve. Everyone likes the classics.

With a little help we can continue to evolve and include WebRTC to a broader audience.

Comments 9
  • Philipp Hancke
    Posted on

    Philipp Hancke Philipp Hancke

    Author

    So who is going to pay for
    1/ creating that documentation
    2/ creating and maintaining usable modules


  • Chris Koehncke
    Posted on

    Chris Koehncke Chris Koehncke

    Author

    Fair point as denoted &yet & Priologic both made heroic attempts to jump start this segment. Both jitsi and Kurento took on major open source projects that didn’t have (initially) clear sight to any financial returns (both were luckily acquired). The work on adapter.js is similar as well.

    The Internet has largely been built upon the generosity of time and money from individuals and companies who gave back. WebRTC is clearly a game changer in facilitating a new era of communications & collaboration. We won’t get there (at least quickly) without similar help.


  • Gustavo Garcia
    Posted on

    Gustavo Garcia Gustavo Garcia

    Author

    Run coturn in 15 secs:
    https://github.com/bprodoehl/docker-turnserver

    But I’m not sure the goal of the community should be to make every developer able to deploy a full WebRTC solution in 1h. Even just for signaling (an XMPP server and web client libraries) it usually takes some time to set it up.


  • Aswath Rao
    Posted on

    Aswath Rao Aswath Rao

    Author

    Recognizing the fact that I am not a developer (heck I have not even installed Openstack or anything else), please bear with me. It looks like that github repository installs only STUN. There is no port assignment for TRUN; no assignment of shared secret for the relay server portion. It reinforces Chris’ point that coturn requires specification of lots of configuration parameters.


  • Chris Koehncke
    Posted on

    Chris Koehncke Chris Koehncke

    Author

    “Every” is pretty inclusive! If we looked at a pie chart of “developer” skills, there is clearly some small % that understand WebRTC. I’m mostly thinking of the next segment, smarter developers who perhaps have only dabbled with communications. The key is to increase the share of developers who understand and can deploy a production solution.


  • Chris Koehncke
    Posted on

    Chris Koehncke Chris Koehncke

    Author

    Poor documentation isn’t unique to WebRTC. Lots of splinter technologies have this same issue, lot of half eaten donuts. I had advocated over a year ago that WebRTC needed MEAN setup. A reference platform that included everything you would need to be semi-dangerous with WebRTC. A classic “git install webrtc-all” and be off and running. WebRTC isn’t rocket science to use, unfortunately, the way we often explain makes it seem so.


  • Lawrence Byrd
    Posted on

    Lawrence Byrd Lawrence Byrd

    Author

    Right on. I agree that everyone needs to get out of their coastal “WebRTC is easy” bubbles and move to Des Moines, Iowa. The answer is more CPaaS – regular developers should never have to deploy TURN or any other server – with the right platform everything should just work globally and will be worth the small $$ to make it so.


  • Pieter
    Posted on

    Pieter Pieter

    Author

    @Chris Koehncke Thanks for sharing your thoughts. About “The key is to increase the share of developers who understand and can deploy a production solution.”: deploying (WebRTC based) solutions in the Enterprise is usually the responsibility of Operations. If you want to make that easier you also have to cater to their (Operations) needs:
    – a WebRTC project should offer their code properly packaged either from their own repo or, preferably, it should get included in the Debian and Fedora/CentOS/EPEL repos (deb and rpm are minimally required for greatest initial coverage).
    – configuration files should be well commented and have sane & secure defaults
    – proper documentation (also for ops, focused on e.g. security, firewall ports, SELinux, performance, monitoring)
    – (video)training
    – technical meetups (install 101 of popular use cases and deepdives)


  • Chris Koehncke
    Posted on

    Chris Koehncke Chris Koehncke

    Author

    Wow! Excellent bullet points. Enterprises have often struggled to take advantage of these emerging API capabilities (of all sorts) and as you denote, part of it is the tech side often doesn’t give much thought to the production/implementation elements.