This is a fairly involved topic - a blog from APNIC can provide all sorts of details, but without domain knowledge you might find it difficult to consume: https://blog.apnic.net/2022/05/03/how-n ... ng-cgnats/
Essentially, when the connection was being established both sides provided their internet addresses (local, and WAN) - and when both sides tested their ability to talk to the other side, they failed. Only after this failure is the TURN server used.
Without being able to observe the connection establishment, I can't say for certainty why you're falling back to using the TURN server. But for your investigation, it might be worth trying to do something straightforward like asking both sides for their IP address, and using netcat (nc -l 2555 on one machine, nc ${OTHER_MACHINE_IP} 2555 on the other) to confirm you _can_ talk to the device directly.
If this fails, then Connect has little chance of success without using TURN.
Essentially, when the connection was being established both sides provided their internet addresses (local, and WAN) - and when both sides tested their ability to talk to the other side, they failed. Only after this failure is the TURN server used.
Without being able to observe the connection establishment, I can't say for certainty why you're falling back to using the TURN server. But for your investigation, it might be worth trying to do something straightforward like asking both sides for their IP address, and using netcat (nc -l 2555 on one machine, nc ${OTHER_MACHINE_IP} 2555 on the other) to confirm you _can_ talk to the device directly.
If this fails, then Connect has little chance of success without using TURN.
Statistics: Posted by tdewey — Fri May 10, 2024 3:48 pm
