Introductory paragraph
SIP and VoIP
When two devices want to speak to each other, we need a way for them to exchange contact information such as their IP addresses. Web servers use well-known identifiers on the internet — domain names. But for those to work we need DNS servers to help us look up their addresses. For our two random anonymous machines, we can set up mutually known server to help the machines locate each other. In WebRTC this is known as a signalling server.
In our simple case, each peer contacts the signalling server. The server provides the other peer's address, and then the peer can begin exchanging data.
Alas, today's Internet doesn't quite work that way. Most computers online don't have unique IP addresses — they share a public address with all the other devices on their local network. Most local networks also have firewalls that protect machines from unwanted inbound traffic. Swapping IP addresses isn't enough.
The telecommunications industry has been dealing with this problem for a while now*. There are a number of different ways a connection can pass back through a firewall and router to an internal network. ICE is a kitchen sink protocol using a tried-and-true technique: “Try Everything and See What Works™” A server, called a STUN server, uses the ICE protocol and informs a peer of all the possible ways it can be reached from the public Internet. These potential connection methods are called ICE candidates.
Once a machine has a list of candidates, it needs to communicate them to its peer. The signalling server comes to the rescue again- relaying each peer's candidates to the other.
When a device wants to establish a connection, it generates an offer and sends it to a peer using the signalling server. The offer consists of information about the device, such as what protocols it knows how to speak and what communication methods it has. When the peer recieves the offer, it responds with the same sort of information. Then, the two potential peers send each other possible connection methods provided by ICE. If each peer finds a connection method that works, the connection is established!
- A device uses a signalling server to relay a connection offer to a potential peer. In the meantime, it asks an ICE server to find out how it can be reached from the public Internet.
- The potential peer replies with its own connection offer, and also gathers ICE candidates.
- The peers use the signalling server to exchange ICE candidates, attempting to use them to open a connection.
- Once each peer finds a working candidate, the connection is established.
Once a PeerConnection is established, it can be used to carry audio and video MediaStreams as well as a more general DataChannel. There are lots of examples of basic video chat, but I've encountered a surprising lack of DataChannel examples.
* The author of this post is not a telecommunications engineer. He read a lot of Wikipedia and skimmed a few RFCs so you don't have to.