Connectivity question about STUN

[kirintwn]

The project is only using STUN for establish connection for now,
does that means if one is under symmetric NAT would likely failed to connect?

[Antonito]

Yeah, totally. Unfortunately, the connection is very likely to fail if one of the clients is behind a symmetric NAT.

I'm pretty new to WebRTC, but I think a possible solution would be to use a TURN server. But it also means no direct connection: the encrypted data you send will transit through the TURN server.

[kirintwn]

Yeah, adapting tech likes TURN or ICE may be the solution for symmetric NAT problem.

There is a project like what we do here: croc, they used public websocket server to achieve relay connection. Also, they provide self host relay server as an option.

If gfile can support STUN, TURN & ICE fully, I believe we can use some public TURN server or open sourced self host options like pion/turn or coturn.

[kirintwn]

Combined with #4, executing with --turn=turn.example?transport=udp specified seems good.
There is a public STUN / TURN server list I found at github gist, it might be helpful.

[Antonito]

Yeah, that's what I had in mind too.

I like the fact that gfile defaults to a STUN server, just to make sure data doesn't transit on a third-party server by default. But I'd like to add the possibility to use a custom STUN or TURN server. (via command line flags in the short-term, and probably add the possibility to load from a config file in the long-term)

I know there's some work going on ICE improvement on pion/ice and that TURN support is one of the next objective of pion/webrtc.