You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 24, 2023. It is now read-only.
I noticed that currently the WebRTC ICE servers list option is empty. While TURN is superseded by libp2p-circuit, STUN can improve peers connectivity very much!
I see couple of ways to get this going, but not sure what is the right one. That's why this is an issue and not a pull-request ;)
Allow configurable STUN servers, and add in some default public ones
There are many public STUN servers, we could just use them.
Because ideally a libp2p network should be self-sustaining, I'd consider it a bad practice to rely on external services.
Embed a STUN server in capable nodes
Nodes will advertise their service (not sure how tho), and clients will use them dynamically in the WebRTC dialling. STUN is a pretty simple protocol so implementing it should be easy.
Because it's a hustle to maintain another port (and UPNP port mapping if needed) this might not be the best option.
According to the RFC, STUN can be multiplexed on any TCP/UDP port with other services. This means we can reuse existing swarm ports to serve STUN.
In some usages, STUN must be multiplexed with other protocols (e.g.,
[MMUSIC-ICE], [SIP-OUTBOUND]). In these usages, there must be a way
to inspect a packet and determine if it is a STUN packet or not.
STUN provides three fields in the STUN header with fixed values that
can be used for this purpose. If this is not sufficient, then STUN
packets can also contain a FINGERPRINT value, which can further be
used to distinguish the packets.
STUN-like libp2p protocol
STUN really just returns clients the source IP/port of their request, we can get the same info using libp2p communication. Some libp2p code already does similar things like autonat and the identify protocol. The only question here is can we feed the WebRTC API with self-supplied ICE candidates. I need to research the WebRTC API to answer that :)
Thoughts?
The text was updated successfully, but these errors were encountered:
I noticed that currently the WebRTC ICE servers list option is empty. While TURN is superseded by libp2p-circuit, STUN can improve peers connectivity very much!
I see couple of ways to get this going, but not sure what is the right one. That's why this is an issue and not a pull-request ;)
Allow configurable STUN servers, and add in some default public ones
There are many public STUN servers, we could just use them.
Because ideally a libp2p network should be self-sustaining, I'd consider it a bad practice to rely on external services.
Embed a STUN server in capable nodes
Nodes will advertise their service (not sure how tho), and clients will use them dynamically in the WebRTC dialling. STUN is a pretty simple protocol so implementing it should be easy.
Because it's a hustle to maintain another port (and UPNP port mapping if needed) this might not be the best option.
According to the RFC, STUN can be multiplexed on any TCP/UDP port with other services. This means we can reuse existing swarm ports to serve STUN.
(Taken from RFC5389)
STUN really just returns clients the source IP/port of their request, we can get the same info using libp2p communication. Some libp2p code already does similar things like autonat and the identify protocol. The only question here is can we feed the WebRTC API with self-supplied ICE candidates. I need to research the WebRTC API to answer that :)
Thoughts?
The text was updated successfully, but these errors were encountered: