RTC is both exciting and useful. However, it can be hard to understand the underlying technologies, making it difficult to leverage. I will discuss why STUN and TURN are not so scary after all and how it can be simplified by dissecting a server app and using powerful networking tools.
Most developers approach WebRTC with web development experience but have little understanding of the underlying protocol. Often, an impressive client application will be constructed that may work fine on a local network, but falls apart when deployed to a server. Getting a grasp on how the network aspect of WebRTC actually works can be confusing.
At Xirsys, we spend a lot of time answering technical support questions and see the same questions asked again and again. The level of access to this knowledge is currently quite steep, as media servers that enable WebRTC are complex and mysterious.
##Simplifying STUN / TURN
As a solution to this issue, we have created an open source STUN / TURN server [called XTURN]( and have made it as simple as possible. Over the coming months, we will be adding detailed documentation that not only explains how the TURN server works, but also provides examples for extending the TURN server.
My goal is to dissect and disseminate this knowledge with the TURN server as the centre point. I will
* the packets that are sent in WebRTC negotiation for both STUN and TURN and what they do
* the structure of STUN and TURN packets
* how the packets are handled by the STUN / TURN server
* how to debug a WebRTC application using the STUN / TURN server, Wireshark and Chrome Internals
* how to modify the server to create custom features