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
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
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
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.