Bootstrap a WebRTC peer connection without signalling server

[aarongustafson]

WebRTC connections require a lot of infrastructure, such as a signalling server and STUN/TURN. This infrastructure has real costs, both physically, and in complexity to the application. Reducing the need for this infrastructure when possible would significantly expand the types of applications that could utilize peer connections with WebRTC.

The need for a signalling server could be removed in most cases if the initial connection could happen with a one-way data transfer. For example:

1. Peer A would create an offer along with all of its ICE candidates (trickle-ice is disabled in this case).
2. The offer would be encoded/serialized and sent to Peer B out-of-band. A real-world example could be a URL with the offer in the querystring or hash. Something that could be pasted in a chat, text message, encoded in a QR code, etc.
3. Peer B receives this offer out-of-band, sets the appropriate remote description as usual, creates an answer.
4. Peer B then connects directly to Peer A via an ICE candidate that it feels is best, possibly falling back to others as required until it is able to connect.
5. Once Peer B has connected to Peer A, they can continue to negotiate media codecs, protocols, keys, and all the usual stuff as normal.

In other words, the peer connection process only changes in that the back-and-forth part of the communication happens after the peers establish some sort of initial connection.

This enables several scenarios:

• Offline Peer Connections -- I have applications that benefit from communicating with peers over a local network, even if the overall internet access is off. This can be anything from internet failure, power outage, plane ride, off-the-grid visit to the woods, etc.
• Static web pages can use WebRTC -- It is very affordable for basic web pages to be hosted statically. With this enhancement, those pages will be able to use WebRTC in most cases with no additional infrastructure. (Most folks can connect without TURN, which is acceptable for many use cases.)

Other benefits include security enhancements. Not having to maintain a signalling server that can potentially be hijacked is a plus.

There isn't a real workaround for this problem today. We're stuck using excess signalling servers. The cost to everyone is visible given how successful WebRTC hosting business models are.

Let's simplify this by allowing peers to directly connect!