Keeping It Realtime

More and more application developers have come to rely on platform-as-a-service providers for building and scaling software.

WebRTC's complexity makes it ripe for this kind of approach, so it's no surprise that so many early WebRTC companies have been platform service providers. Unfortunately for customers, the nascent Rent-Your-WebRTC-Solution market has proven pretty unstable.

News came yesterday that yet another provider of WebRTC hosted services—in this case, Requestec—has been acquired. We've seen this movie before with Snapchat's acquisition of AddLive and we'll probably see it again, maybe multiple times.

At &yet, we've been working steadily at creating open source software and approaches to infrastructure to help our clients avoid the volatile WebRTC rental market.

About a year ago, our friends at TokBox published a blog post entitled WebRTC and Signaling: What Two Years Has Taught Us. It's a great overview of their experience with technologies like SIP and XMPP for stitching together WebRTC endpoints. And we couldn't agree more with their observation that trying to settle on one signaling method for WebRTC would have been even more contentious than the endless video codec debates. However, our experience with XMPP differs enough from theirs that we thought it would be good to set our thoughts down in writing.

First, we're always a bit suspicious when someone says they abandoned XMPP because it didn't scale for them. As a general rule, protocols don't scale - implementations do. We know of several XMPP server implementations that can route, distribute, and deliver tens of thousands of messages per second without breaking a sweat. After all, that's what a messaging server is designed to do. Sure, some server implementations don't scale up that high; the answer is to use a better server. We're partial to Prosody, but Tigase and a few others are well worth researching, too.

Second, pure messaging is the easy part. The hard part is defining the payloads for those messages to build out a wide variety of features and functionality. What we like best about the XMPP community is that over the last 15 years they have defined just about everything you need for a modern collaboration system: presence, contact lists, 1:1 messaging, group messaging, pubsub notifications, service discovery, device capabilities, strong authentication and encryption, audio/video session negotiation, file transfer, you name it. Why put a lot of work into recreating those wheels when they're ready-made for you?

An added benefit of having so many building blocks is that it's straightforward to put them all together in productive ways. For example, XMPP includes extensions for both multi-user chat ("MUC") and multimedia session management (Jingle). If we need multiparty signaling for video conferencing, we can easily combine the two to create what we need. Plus we get a number of advanced solutions for free this way, since MUC includes in-room presence along with a helpful authorization model and Jingle supports helpful features like renegotiation and file transfer. Not to mention that the ability to communicate device capabilities in XMPP enables us to avoid monstrosities like SDP bundling.

We are very excited to announce that the iOS app for Talky is now available for download on the App Store.

(Can I get a woohoo?)

Take a quick look

A few months ago, WebRTC agitator and yeti-friend Chris Koehnke wrote an excellent blog post explaining that browser-based videochat won't work 100% of the time without a little help from something called a "TURN Server". As he put it:

If you're going to launch a WebRTC powered service for financial 
gain, then you need to have done everything within your power to
ensure it works reliably across as many cases as possible.

Chris was satisfied when a few simple tests worked and stopped after that. Well, he skipped the next step. But that's reasonable because he was probably bored already (does anyone get excited about TURN servers?) and he doesn't run a WebRTC powered service himself.

The next step is looking for cases where things did not work and figure out what we can do about it. But hey, we run a WebRTC service called Talky and connection failures are frustrating, so we decided to dig a little deeper.

One of the most talked about presentations at RealtimeConf 2013 was yeti Lance Stout and Philipp Hancke's demonstration of WebRTC signaling over XMPP, resulting in a federated video call within the browser.

This demo caught the attention of The VoIP Users Conference, or VUC a weekly, live discussion about all the telephony things, which began in 2007. Lance and Philipp will be joining the VUC community on December 27 at noon (Eastern Time) to discuss the potential of WebRTC as an interoperable tool to communicate within established protocols.

Philipp and Lance have been working together for some time on projects (strophe.jingle and Stanza.io, respectively) that push forward the ability of developers to utilize XMPP in tandem with the web, specifically WebRTC.

Join their conversation two weeks from today on Friday, December 27, at the VoIPUsersConference.org, or track it on their Google+ community.

Today, yeti Henrik Joreteg, will be discussing WebRTC on the weekly podcast, The Web Ahead. The hour long show allows host Jen Simmons the opportunity to chat one on one with each week's guest on the burgeoning technologies and platforms that are pushing the web forward.

Henrik is author of the popular library, SimpleWebRTC and lead developer for Talky, a tool we built for simple video chat and screen sharing. He's also heading up the effort to push WebRTC forward at IsWebRTCReadyYet.com.

Henrik first spoke on WebRTC at JSConf Brazil and built AT&T's WebRTC focused att.js, which was showcased by AT&T at CES earlier this year. He spoke recently about WebRTC, first on a Realtime Data panel at EdgeConf this past September, and again at RealtimeConf 2013, in Portland a few weeks ago. Henrik will also be speaking at Cascadia.js later this month.

Go to 5by5's website to hear today's podcast with Henrik and Jen.

People have a very special distaste for telecoms.

Between wiretapping, egregious data roaming and text messaging charges, the unreadability of our phone bills, and carrier lock-in, we have plenty of reasons. Add in the fact that we consider ourselves entirely dependent on them and we're all the more resentful and cynical.

But forget the traditional telecoms for a minute.

Google, Microsoft, Apple, and Facebook are truly the new telecoms—each within the last few years has built or bought a communication platform of their own.

Wouldn't it be cool if someone built a federated, interoperable, open source, and super hackable "Skype killer" built on WebRTC and XMPP and released it at RealtimeConf?

I had the privilege to attend EdgeConf 2013 as a panelist and opening speaker for the Realtime Data discussion.

It was an incredible, deeply technical conference with an interesting discussion/debate format.

Here's the video from the panel:

First—some important news: We've changed the dates.

Early this year, we announced dates for RealtimeConf, RedisConf, and a brand new, WebRTC-focused event. A short time later, our friends at LxJS announced their dates—which were unfortunately the same. We immediately reached out, discussed the mix-up, and determined that we were in the best position to change our dates.

After getting back to the states after being part of a wonderful first-time RealtimeConf EU smashingly organized by Julien Genestoux, we've reset dates and, in the meantime, we've made tremendous headway on conference planning.

Last year, we had a full week of Realtime events and we're just ramping that up a notch, by adding a full day focused on the most exciting realtime technology to hit the web: WebRTC.