You’ve studied up on WebRTC, the sponsor APIs, and worked feverishly to getting your hack together. You’ve been running tests on your local machine and everything is going great, and think to yourself “this WebRTC stuff is easy”. You run some tests between machines on the local network and it works. WebRTC is magic! So now its time to run your tests across the Internet. You make your PeerConnection and wait.. Hmm.. It never took this long to connect before? Wait.. and then it happens – peerConnection failed? What going on? I thought WebRTC was supposed to be easy?
What happened? You remember hearing about something called STUN and TURN that supposed to help in some NAT scenarios? WebRTC includes a mechanism called Interactive Connectivity Establishment (ICE) that helps to traverse firewalls. ICE is brilliant in that once it is initiated it automatically identifies address, port, and protocol combinations that permit peer-to-peer connectivity. By default ICE will select local candidates, which is fine if you are running local. But if you are sitting behind a NAT device your local address will be different from the address presented to the outside world – the one your peer needs to know to connect to you.
Fortunately ICE includes a mechanism to figure out your external address (what is known as your peer reflexive address), known as STUN. STUN is simple – you just ask a STUN server that is sitting outside of your NAT what your external IP address is and it returns that info. This mechanism is super light weight. Google even provides a free STUN server for non-production WebRTC development at stun.l.google.com:19302.
Local candidates and STUN should work in roughly 80-90% of cases. Unfortunately the remaining percentage is stopped by ‘unfriendly’ NAT, firewall, and VPN devices that don’t want you doing VoIP. VoIP and WebRTC typically use UDP. Some firewalls don’t let UDP through at all. Others only allow traffic via web ports.
Shouldn’t WebRTC work everywhere the web works? Of course it should, and that’s why WebRTC includes one last mechanism known as TURN. TURN servers relay WebRTC media when all else fails. A good TURN server, such as the widely used open source coturn project, will support UDP and TCP and can run over standard web ports. TURN is even a good way to speed up the ICE process which can take an insanely long 5-10 seconds in some cases.
TURN sounds great, so what’s the catch? Well, since TURN relays media is consumes a lot of bandwidth, and server bandwidth isn’t free. TURN servers should also be distributed close to your customers to minimize latency and improve call quality.
The moral of the story: don’t forget to add both a STUN and TURN server, especially if you want your hack to work in diverse network environments. Your TADHack API provider may already include one. If not, StreamStack (a TADHack partner) is providing free access to our global TURN server network for all TADHack participants during TADHack. Just email admin@streamstack.io or sign-up at streamstack.io/tadhack.
