Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bootstrap a WebRTC peer connection without signalling server #241

Open
aarongustafson opened this issue Dec 7, 2020 · 0 comments
Open
Assignees
Labels
Moonshot want Incoming requests from the community

Comments

@aarongustafson
Copy link
Member


title: Bootstrap a WebRTC peer connection without signalling server
date: 2020-12-07T22:03:56.026Z
submitter: PRIVATE
number: 5fcea6ccbcd238164220e44e
tags: [ ]
discussion: https://github.com/WebWeWant/webwewant.fyi/discussions/
status: [ discussing || in-progress || complete ]
related:

  • title:
    url:
    type: [ article || explainer || draft || spec || note || discussion ]

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!


If posted, this will appear at https://webwewant.fyi/wants/5fcea6ccbcd238164220e44e/

@aarongustafson aarongustafson added the want Incoming requests from the community label Dec 7, 2020
@aarongustafson aarongustafson self-assigned this Dec 7, 2020
@aarongustafson aarongustafson removed their assignment Mar 31, 2021
@WebWeWant WebWeWant deleted a comment from github-actions bot Apr 6, 2021
@WebWeWant WebWeWant deleted a comment from bradisbell Apr 6, 2021
@WebWeWant WebWeWant deleted a comment from bradisbell Apr 6, 2021
@cwilso cwilso self-assigned this Apr 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Moonshot want Incoming requests from the community
Projects
None yet
Development

No branches or pull requests

2 participants