WebRTC, NAT traversing, STUN, TURN

Here is a summary of all stated in the title:

STUN – A protocol where clients sends a request information to STUN server which responds to the client with the ip+port from which the client sent the request. Public internet STUN servers will return the public ip+port.
TURN – A protocol where client sends to a TURN server a request to allocate a relay address together with the target peer to communicate with and the TURN server allocates the address and sends the peer communication request and sends the client the allocated address. The client and peer can now communicate through the allocated relay address. Symmetric NAT may use same port to different targets and the peer to peer port punching using STUN will fail and in such case TURN is required. https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT See info about NAT traversal and explanation when TURN is required (symmetric nats) here: http://stackoverflow.com/questions/13501288/what-is-stun-and-does-it-need-a-port-forwarded-server/13539963#13539963
ICE – Protocol which gathers ip+port candidates of current computer, sorts them and tests which of them are available. Host candidates are local interface candidates. Other candidates are STUN candidates which are public ip+port candidates received from STUN server, and TURN candidates which are TURN server assigned ip+ports for relays.
SIGNALLING SERVER – A server used to exchange the ICE candidates information between the peers to allow them to know how to communicate one with another. Difference between STUN server and SIGNALLING server: http://stackoverflow.com/questions/23715773/is-stun-server-absolutely-necessary-for-webrtc-when-i-have-a-socket-io-based-sig/23716086#23716086
WEBRTC – Uses ICE protocol to get available candidates and then exchanges their information with peer using a signalling server and then starts peer communication either peer to peer or through a relay server depending on the ICE candidate chosen. NOTE: The webrtc protocol javascript implementation leaves it up to the programmer to decide how to perform the signalling of exchanging the initial connection information between the peers, for example signalr\websockets can be used to broadcast information to other connected browsers.
RELAY SERVER – Server which relays data between peers using an intermidiate relay server. WebRTC uses UDP for relaying with TURN relay server.
UDP HOLE PUNCHING\TCP HOLE PUNCHING – Technique to communicate with a client exposed through NAT which uses NAT traversing protocols such as STUN and TURN. TCP hole punching is more complex because a socket can either listen or connect while the techniques require both so many sockets are used and a flag of same address and port must be used to allow multiple sockets on same port. More info here: http://www.brynosaurus.com/pub/net/p2pnat/

WebRTC detailed architecture and protocol explanation:

About specifying STUN\TURN servers and public servers lists:

How chrome decides which STUN\TURN server to use: http://serverfault.com/questions/591837/how-does-chrome-webrtc-select-which-turn-server-to-use-if-multiple-options-are-g/608440#608440

TCP connection to TURN server in chrome WebRTC: https://groups.google.com/forum/#!topic/turn-server-project-rfc5766-turn-server/vR_2OAV9a_w

TCP connection to STUN server (see end of answer for new rfc specification which allows TCP): http://stackoverflow.com/questions/23434753/chrome-webrtc-datachannels-ice-tcp-server-reflexive-candidates-missing-even-wit/23435637#23435637

ICE RFC, a nice read (among others it talks about LITE ICE as compared to full ICE, in LITE ICE only host condidates are used and its good for machines which are directly exposed to the internet): https://tools.ietf.org/html/rfc5245

COMET – General term for web server to client push. Can be executed by various techniques such as polling, long polling, hidden iframe, etc. https://en.wikipedia.org/wiki/Comet_(programming)

Side Note: The following chrome flag allows local files access: –allow-file-access-from-files

Signalling protocols list used to exchange information between peers: https://bloggeek.me/siganling-protocol-webrtc/
Pusher public signalling server: https://pusher.com/tutorials/webrtc_chat

WebRTC stats for an ongoing session can be found at:
chrome://webrtc-internals page in Chrome
opera://webrtc-internals page in Opera
about:webrtc page in Firefox

WebRTC javascript apis in all browsers listed here: https://webrtc.org/web-apis/interop/

WebRTC javascript Shim to insulate apps from spec changes and prefix differences: https://github.com/webrtc/adapter

WebRTC example javascript crossbrowser code:
The ice servers must be specified in the code (if stun\turn candidates are desired in addition to the host candidates).

A more detailed and explained WebRTC example including flow diagrams of the information:
In the bottom there is information of how to get started and also links to various WebRTC frameworks.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s