Then and now:
In the old days, long time ago, each site had a public IP and each other they exchange IP address and they could do peer to peer communication. But in the world of NAT, this is no longer possible as this introduced the private IPs. This is where STUN is in use.
The Stun works like below
- The client sends a STUN packet request and asks what is my public IP address
- The STUN server sees the IP address the request came from, puts the address into the packet and sends it back.
This usually works but in some cases, it doesn't. For this reason we have the TURN concept.
- TURN provides a cloud fallback when a peer to peer communication fails
- This asks for a public address which anybody can access.
The downside of this is that the data is actually related through the server and there is an operational cost to it.
Now we have two mechanism where one is super cheap but not always reliable, and the other always reliable but has some cost associated to it, To get the best of both the worlds, we have technology called ICE.
ICE framework tries both the paths parallel and figures out which is best and follows it. If it could do STUN it does STUN and if it could not and could do TURN, it does the TURN. as per the statistics, 80% of the time, STUN works, only 20 % we have to Go with the TURN. which means in real world, 1 out of 8 calls could fail if we rely only on STUN.
The overall architecture with TURN, STUN is like below:
Deploying a TURN or STUN server
- Google has a testing STUN server stun.l.google.com:19302
- WebRTC has stun and turn server code as part of the webrtc source code package
- There is also a readily available product rfc5766-turn-server which can be deployed in amazon cloud and can be used. (these are amazone VM images)
References:
http://www.html5rocks.com/en/tutorials/webrtc/basics/
No comments:
Post a Comment