tl;dr: with adapter.js you can write WebRTC code that is spec-compliant and works in all supported browsers. That is the web we want.

We have come a long way since WebRTC was first enabled by default in Nightly back in February 2013 after interoperability had been achieved earlier that month. Since then a lot has happened.

One of the bigger updates to the specifications was the addition of a Promise-based version of the API instead of callback-based API in December 2014. Firefox has supported the Promise-based versions of the getUserMedia and the RTCPeerConnection APIs for quite a while now. Yay!

That means you can write code like this:

Back in June, Apple introduced bitcode as a part of their app thinning strategy, which allows them to implement some optimizations in the future without developers having to resubmit their apps. Unfortunately, bitcode must be enabled for the whole app, including third-party libraries. This is a problem if you use WebRTC as it does not currently have a build option to enable bitcode.

Because the Talky iOS app uses WebRTC, I decided to investigate what it would take to enable bitcode when building WebRTC. For this post, I assume that you're building a Release build of WebRTC with the steps outlined at http://www.webrtc.org/native-code/ios.

Step 1: Get the code

If you haven't already downloaded the WebRTC source, open a terminal window and follow the steps for "Getting the code".

We’ve talked before about the revolutionary importance of WebRTC, because it brings the principles of the open web to voice, video, screensharing, and other applications that were traditionally closed off to fast innovation. This revolution has been led not by old-style telcos but by web and mobile companies, especially the developers of the Google Chrome and Mozilla Firefox browsers.

Until recently, both Microsoft and Apple have been standing on the sidelines as this revolution unfolded. Thankfully that’s starting to change, as Microsoft adds these capabilities to its upcoming Edge browser. (Apple, however, is still late to the party.)

There’s a twist to this story, though, because Edge supports an object-oriented flavor of WebRTC called ORTC, which most observers expect will eventually become WebRTC 1.1 or 2.0 or something. :-)

Thus we have a conundrum: in video conferencing apps like our Talky service, cross-browser calls work fine right now because both Chrome and Firefox support WebRTC. But adding Edge to the mix doesn’t automatically result in cross-browser calls to Edge users, since the signaling methods involved have different syntax even though the semantics are the same.

It’s been a while since I last wrote about testing WebRTC applications. And guess what? There has been some progress. We’re now using Travis-CI for integration tests in combination with Selenium for UI testing.

The usage of Travis-CI has been described quite a while ago by our rtc.io friends. It is now being used by adapter.js which has recently become a dependency of our core modules like getUserMedia and RTCPeerConnection since it shims the differences between browsers and is maintained by people from Google and Mozilla.

What Travis does is run a series of tests on every pull request. Thanks to travis-multirunner this is running the testsuite (located here for adapter.js) in different versions of Chrome and Firefox. If the tests pass and jshint and jscs don’t find any style nits, there is a nice green badge:

Thanks to you, our loyal Talky users, today we’re launching an all-new version that’s better, faster, stronger. (We can’t say harder, better, faster, stronger because actually we’ve been making it easier!)

Among other things we’ve added a few of the features you’ve requested most, such as in-session text chat so you can share links and other information during a call.

The big deal, though, is that we’ve upgraded the entire technology behind Talky so that you can meet with 15 or more people, at once. We’ve been using it regularly at &yet and it’s been great for our weekly full-team hangouts.

This version has been in beta for a few months now and it’s finally ready for prime time. We’ve also released an updated version of the Talky iOS app that works with the new backend technology so you can join a Talky room on the go from your iPhone or iPad.

A few weeks ago we talked about the need for private video chat and the challenges involved with making that a reality in a cloud-based environment. That’s why we’ve been working hard to build a version of Talky you can run on your company’s network to keep your voice and video traffic safely away from the public Internet.

We’re proud to announce that Talky On-Premise is now available.

Talky On-Premise takes the same ultra-simple experience you’ve come to love for video chat over the Internet, and moves it in-house. The installation is almost as easy as using Talky in the first place and the price is surprisingly affordable (as we like to say, the only thing astronomical about Talky is the rocket game, Lander).

tl;dr download the Windows 10 preview and test the WebRTC getUserMedia samples in the Microsoft Edge browser!

The WebRTC samples that are made available by Google's WebRTC team on GitHub are a tremendously useful resource for starting with WebRTC. They are so useful that this year my favorite answer on the discuss-webrtc mailing list has been "there is a sample for that".

The samples are grouped into three categories:

• getUserMedia samples which show how to use the getUserMedia API to access the microphone and camera,
• RTCPeerConnection samples which demonstrate the use of the RTCPeerConnection API to establish a peer-to-peer connection (usually within a single page), and
• RTCDataChannel samples which demonstrate the higher-level data channel API to send and receive data and files.

One of the greatest lessons we can learn from watching internet platforms and applications grow in popularity is how crucial users' safety can be in utilizing those services. The safety of our Talky users is extremely important to us.

In keeping with discussing the security and privacy of our service, we also want to share our best practices for safety when using Talky. Below are some tips you can use to help ensure that you have great conversations with the people you choose, and avoid stumbling upon explicit, unwanted content.

Tip #1 - Don’t share Talky rooms publicly

By default all rooms within Talky are public. When two or more people land on the same link they will be connected with video and audio streaming to each other. Sharing a link to a Talky room via Twitter or Facebook is essentially inviting everyone else. To avoid having an Internet party with strangers, only share links via direct messages or other private methods of communication.

This month, &yet’s lead WebRTC engineer Philipp “Fippo” Hancke has been invited to speak at Tokbox’s TechTok on May 21.

As a veteran software developer, messaging and distributed systems have been a passion of Fippo for many years. He is also one of the leading non-Google contributors to the webrtc.org WebRTC library, which is used by Chrome, Opera, Google’s iOS and Android WebRTC SDKs, and others.

This TechTok will focus on Failing gracefully with WebRTC, or everything you need to know about how to handle failures with WebRTC.

Register to attend TechTok here however, if you can’t make it to this event, Tokbox will have a limited number of virtual seats available so tweet at them at @tokbox if you’re interested.

Lead &yet WebRTC engineer Philipp “fippo” Hancke has been very busy recently examining the inner workings of some of your favorite voice and video services. Just a few weeks ago, he wrote up his findings on the popular chat app WhatsApp for webrtcH4cKS. And this week, we have an analysis of Facebooks Messenger service, which recently added videochat.

You can also follow the series of reports at andyet.com/webrtc-reports.

Later this month, he’ll be speaking candidly about more of his discoveries at Twilio’s SIGNAL Conference in San Francisco. In “WebRTC exposed: What we can learn from blackbox exploration of popular voice & video services” fippo explains the findings as well as the lessons that can be learned for WebRTC.

If you’ll be at SIGNAL be sure to ping fippo) or Peter to say hello!

Fippo and I gave a talk this week at Fluent covering:

• The basic fundamentals of WebRTC
• How easy it is to get started building an app with SimpleWebRTC
• What 'signaling' means
• Why IETF controversy over multiparty signaling led to ORTC
• What's different about ORTC and why telephony engineers such as Fippo like it (and why web developers won't care)
• &yet's future plans to support WebRTC and ORTC with SimpleWebRTC

Gar even was able to make a cameo appearance to kick off the talk with an acapella Stevie Wonder and Paul McCartney cover with some twisted lyrics:

WebRTC and ORTC live together in perfect harmony side by side on my laptop keyboard Oh, Lord, hopefully...?

Recently, Chrome’s WebRTC product manager, Serge Lachapelle, asked a critical question about WebRTC “product of the year” awards:

I see all these webrtc product of the year awards... And here I am wondering how come Chrome has not won one yet.

— Serge Lachapelle (@slac) March 25, 2015

We agree!

User experience is very important to us. Almost a year ago, Chrome changed the way screensharing works in WebRTC in a way that increased the usage for Talky by 300%. Still, the onboarding process for your first screen share was not as nice as it could have been.

It used to be, if you tried to share your screen, you were required to install an extension. Once that extension was installed, you would have to reload Talky before you could share your screen. Until today, it was also necessary to click the "Share Screen" button again after the reload.

Now, after you've installed the extension, you're able to screenshare immediately, making the first-time experience faster and easier.

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.