Today, we're announcing a public beta of the next generation of Talky - &yet's simple video chat and screensharing app for groups.

And, in a few weeks, we'll be announcing a Kickstarter. But more on that later—first I want to tell you about what's new in the Talky beta.

I hesitate to go all Jonny Ive on you, but seriously: the new version of Talky has been reconsidered, reengineered, and redesigned from the ground up. And everything we've been building has been open sourced as part of Otalk, our open WebRTC platform.

Here's the key improvements

Firefox is starting to roll out Firefox Hello to more users. Hello is a videochat, very much like our own Talky.

In the WebRTChacks analysiѕ, I described it a small button to your browser that generates a call URL which you can share.

A question by the palava.tv team got me thinking:

&yet is a highly distributed team, with yetis all over North America and Europe. To keep in touch, we use Talky on a daily basis for impromptu discussions among our teammates. Unfortunately, Talky doesn't quite work for our all-hands meetings because "full-mesh" media sharing only functions well when the number of people in the conference is small. To change that, we are working on an improved version that we've tested up to 20 people, internally known as Talky 2.

Last Friday we had another weekly update meeting and Talky 2 would not work - all the videos remained black. Switching from Chrome to Opera resolved the problem for a while, but at some point every participant in the conference had their browser crash. We had to switch back to Hangouts. Which was embarrassing.

What happened?

Crashing every browser (including Opera) was something I had been expecting. We had seen it before and currently it is being investigated by the WebRTC team. It is quite a serious issue and getting them more data to investigate what is going on helps. Showing black videos, on the other hand, was a behavior I had not seen before, so I went to investigate. I could not reproduce this behavior on my Linux laptop and It seemed to happen only on the Macintosh computer we use in our meeting room.

When launching our Talky videochat service almost two years ago there was one thing missing: the TURN server.

WebRTC creates peer-to-peer connections between browsers to transfer the audio and video data, but sometimes it needs a little help to establish a connection. The TURN server is the thing that helps here: it is deployed on the Internet and relays data for two clients that fail to establish a direct, P2P connection (thus avoiding the dreaded "black video" problem). TURN is generally considered one of the hard topics when people start doing WebRTC and crucial to running a successful service.

When I started at &yet back in March one of the first things I did was to add a TURN server. We choose the open-source restund server because it had proven to be mature and very easy to extend earlier. The rfc-5766-turn-server is another popular choice here, but the design and extensibility of restund was more appealing to us.

In response to adding a TURN server, the number of "black video" problems that users reported went down to almost zero. The exception were Firefox users and this turned out to be a Firefox bug which was fixed.

We believe WebRTC is one of the most important technologies to hit the web in many years. There is a significant opportunity for WebRTC to help deliver on the promise of the open web—but for communication and collaboration.

In several of our colleague Henrik Joreteg's talks the past couple years, he's said, "WebRTC needs more Open Web hackers!" It's very true.

But WebRTC is much more complicated than other browser APIs that web developers deal with.

It seems, from our vantage point, like a large portion of the users of WebRTC have not been Open Web hackers.

Yesterday Fippo talked about applying the principles of the open web to realtime communication with WebRTC. Consider this post the first installment of providing in-depth descriptions of what that means in practice.

Where codecs fit in

A key component of realtime audio and video systems (like Talky) consists of methods for encoding the light waves and sound waves that our eyes and ears can understand into digital information that computers can process. Such a method is called a codec (shorthand for code/decode).

Because there are many different audio codecs and video codecs, if we want interoperability, then it's important for different software implementations to "speak the same language" by having at least one codec in common. In the parlance of industry standards, such a codec is specified as "mandatory to implement" or MTI (often an MTI codec is a lowest common denominator, but software can use better codecs if available - a model that has also worked well for cipher suites in SSL/TLS and other technologies.)

There's a lot of talk about this topic of "the web we want," and a lot of it has focused around WebRTC lately.

I have been working with WebRTC since mid-2012, both in the Chrome and Firefox browsers, as well as the native webrtc.org library. So far I have filed more than sixty issues in the WebRTC project issue tracker and the Chrome bugtracker. I'm especially proud that I've crashed the production version of Chrome eight times.

I am among the top non-Google people to file WebRTC issues. And I managed to get quite a few of them fixed, too. I visited Google's Stockholm office in September and had a conversation with the team there about how I use the issue tracker and how that process works. Full disclosure: I got a t-shirt (even though it turned out to be too large). And I even started reviewing the Chrome WebRTC release notes before they're sent out.

Justin Uberti's description of WebRTC as a "project to bring realtime communication to the open web platform" is still the vision I cling to.

Last week, Google Chrome started to support the next generation video codec VP9 for WebRTC (which is highly experimental in the developer version and you need to enable it, so the ETA for this is probably going to be mid-2015). That is good news because VP9 is going to offer better video quality at the same bandwidth (another way to look at it is that VP9 gives you the same quality at lower bandwidth, although at the expense of computational power, i.e. your mobile device gets warmer).

I immediately wanted to implement and test the feature, if only so I could add Chrome 41 to the long list of versions that I managed to crash. However, this turned out to be harder than it initially seemed.

Let me try to explain the issue with an example of a videochat that has three participants, two of which support VP9: Suppose that those clients use an XMPP MUC for having the conference, supported by an SFU like the Jitsi videobridge (which is what we do in the next version of Talky). The browsers announce their capabilities ("I implement VP8," "I implement VP9," a Firefox browser might even do H.264 and VP8) through Entity Capabilites when joining the MUC.

So the first two browsers know they both implement VP8 and VP9 and use that list of codecs when calling the RtpSenders .send method for the first time. That RtpSender object is another improvement that came from ORTC. If everything goes well, they will enjoy the superior quality of VP9.

Microsoft recently announced they will support Object RTC and now everyone is talking about ORTC and how they will support it.

What is this all about and what is ORTC anyway?

In essence, ORTC is an alternative API for WebRTC. It is object-oriented and protects developers from all that ugly Session Description Protocol (SDP) madness. Some people call it WebRTC 1.1, or maybe WebRTC 2.0.

So... will &yet (and Otalk) (and Talky) support ORTC? Of course!

As you probably know, we run Talky, a free videochat service powered by WebRTC. Since WebRTC is still evolving quickly, we add new features to Talky roughly every two weeks. So far, this has required manual testing in Chrome, Opera, and Firefox each time to verify that the deployed changes are working. Since the goal of any deploy is to avoid breaking the system, each time we make a change we run it through a post-commit set of unit tests, as well as an integration test using a browser test-runner script as outlined in this post.

All that manual testing is pretty old-fashioned, though. Since WebRTC is supposed to be for the web, we decided it was time to apply modern web testing methods to the problem.

The trigger was reading two blog posts published recently by Patrik Höglund of the Google WebRTC team, describing how they do automated interop testing between Chrome and Firefox. This motivated me to spend some time on the post-deploy process of testing we do for Talky. The result is now available on github.

Let's review how Talky works and what we need to test. Basically we need to verify that two browsers can connect to our signaling service and establish a direct connection. The test consists of three simple steps: