WebRTC can access hardware based encoders and decoders to save on battery life. Check out my own informal experiment, results are...
WebRTC TURN on a restricted networkChris Koehncke
The Internet takes no prisoners, one mistake and you’re done. It’s amazing how people rush services to market, skipping steps, overlooking details and waving off concerns. Make no mistake, simple is really hard. You wanted to read something about WebRTC, well read on.
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. Enter the lowly TURN server, a mind numbing topic of such boredom that I had to take a nap just writing this sentence. TURN’s job is to jump in as the connection of last resource for a WebRTC session.
Many large companies (particularly those with over zealous IT depts) often have port restricted networks. This is almost guaranteed to happen at financial institutes and believe it or not at telecom service providers (who are scared of nearly everything). These networks typically do not support incoming connections and support outgoing connections on TCP Ports 80/443 and maybe (if they’re in a good mood) UDP Port 53 (for DNS). This is not an atypical situation.
This means that only web browsing will work and kills nearly all sorts of communication services. The answer is to tunnel your secret data back thru TCP Ports 80/443. This is a well known process, has some overheads associated and requires some work. But can you make WebRTC work?
A large financial institute posed the question whether WebRTC using a TURN service can work in this network condition. The answers were far from clear. A definite maybe didn’t satisfy me.
I turned to Lee Sylvester, Senior Engineer at Xirsys, who said YES, that their TURN service would work in this situation. Yeah right, I don’t believe you. He offered to show me. I port restricted my home network (which shut down virtually everything) and went to XirSys’s demo page on Herokuapp and damn if a hobbit didn’t appear in my browser window (Lee is from New Zealand land of mystery and TURN services). It worked.
I set about testing a short list of other “commercial” WebRTC services and sadly most of them didn’t work in my port restricted network. Note: appear.in DID work and big surprise, they use Xirsys for TURN services. Why? Because they all decided to skip a step. This is a mis-step in my opinion. I’m not here to pimp Xirsys (though I’m not aware of any other company who is offering an easy to sign up for hosted TURN solution), but it would seem if the solution is easy, why not go the extra few inches to ensure your service works everywhere? Comments welcome.