WebRTC on a restricted network

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.

First, we discovered that there were still browser bugs lurking here.

In Firefox, TURN support didn't work on Windows at all. This was fixed in less than 24 hours after we reported it, and will be part of the upcoming Firefox 30.

Reporting bugs obviously helps. But seriously, with 300 WebRTC "vendors" out there none of them noticed this? Maybe no one runs Windows anymore? ;-)

In Chrome, if the attempt to establish a TURN/TCP connection failed (yes, there are networks where port 80 is blocked!), the JavaScript layer was never informed of that fact. It took a little longer between our initial report and the fix, but again the responsiveness of the team was pretty awesome. Not for the first time.

With those bugs fixed, we got to thinking: once we know that a peer-to-peer connection does not work, is there a way to determine why and tell the user about it? It turns out that the information we get from the browser is sufficient to determine whether you can make a connection with any of our TURN servers. When the browser tells us that the connection fails, we can compare the information we receive from both you and your peer. This enables us to determine which network is responsible for this failure - which enables you, dear user, to take action.

Admit it, you're bored too, aren't you?

Well, here's the exciting part.

Yes, it's frustrating that sometimes Talky may still fail to establish a connection between you and your peer (currently less than 5% of calls). However, as of today Talky tells you that things have failed, and also tells you which end of the connection is the likely culprit. Plus we've improved the help page to describe some steps you might take to make it work.

Which means today the Internet just might be a slightly happier place than it was yesterday. :-)

You might also enjoy reading: