Closed neon3r closed 3 weeks ago
I'm afraid there's a small misunderstanding here. There are lots of different combinations based on which particular transport protocol TURN clients connect to the server and which protocol the server uses to forward client traffic to the peer.
The typical setup is the TURN client reaching the TURN server over UDP, which forwards client traffic to the peer over UDP. The corresponding sample server is in examples/turn-server/simple
and the client code is in examples/turn-client/udp
. Here is a local test:
go run examples/turn-server/simple/main.go -public-ip 127.0.0.1 -users=user=pass&
go run examples/turn-client/udp/main.go -host=127.0.0.1 -user=user=pass -ping
relayed-address=127.0.0.1:58687
35 bytes from from 127.0.0.1:58687 time=1 ms
35 bytes from from 127.0.0.1:58687 time=1 ms
...
Another popular setup is the TURN client reaching the server over TCP, which again forwards client traffic to the peer over UDP (not TCP!). The corresponding sample server is in examples/turn-server/tcp
and the client code is in examples/turn-client/tcp
(not tcp-alloc
!):
go run examples/turn-server/tcp/main.go -public-ip 127.0.0.1 -users=user=pass&
go run examples/turn-client/tcp/main.go -host=127.0.0.1 -user=user=pass -ping
2024/07/23 17:59:27 relayed-address=127.0.0.1:39994
2024/07/23 17:59:28 35 bytes from from 127.0.0.1:39994 time=0 ms
2024/07/23 17:59:29 34 bytes from from 127.0.0.1:39994 time=0 ms
...
Finally, a somewhat exotic (but fully standardized!) setup is the client connecting the TURN server over TCP, which in turn forwards to the peer over TCP. This is the tcp-alloc
client that you tried. Unfortunately, the server side support for this feature is still pending, see https://github.com/pion/turn/pull/315, so you cannot quite test this setup with pion/turn yet.
Does this answer your question?
Thank you for your answer!
Does this answer your question?
Yes, one of them :) Now I see why the tcp-alloc example didn't work. But I would still like to find out the reason why the server is unreachable on the internet. The other examples you have shown work the same way for me, but when I test the server's availability with Trickle ICE it is always unreachable. I have also tried to implement a server myself with Pion TURN API, but with the same result. The IP address and the listening port I used are available, but the server is not.
I would like to use pion/turn for a WebRTC application and I guess I'm missing something here. Is it possible right now? Thank you!
If the server works on localhost, it should work publicly too. If it doesn't then that's most probably due to a reason outside pion/turn, like a firewall blocking incoming TCP connections to port 3478 or your IP address not being publicly routable. Try the standard debugging tools, like traceroute, ping, netstat, I'm sure you'll find the reason soon.
As per whether pion/turn can provide a production-ready TURN server: it absolutely can. While feature-wise it's not as complete as, say, coturn, it's still running in production in countless deployments. But I'd recommend you not write a TURN server for yourself from scratch or use the example code, because that will not scale neither expose monitoring metrics, etc. Just run a TURN service packaged with your media server (e.g., likevit includes a TURN server out of the box) or use a dedicated TURN server distro like STUNner (disclaimer: I'm one of the lead STUNner devs).
Your environment.
What did you do?
Tried to run the tcp-alloc example with a tcp TURN server from examples. Everything was launched on my local machine. Also tested example TURN servers with Trickle ICE and all of them were unreachable.
What did you expect?
Expected clients to connect and exchange a message successfully. This functionality seems basic, so I assumed that the TURN server from the examples is suitable for this case, or am I wrong? Also expected the server to be reachable on the internet.
What happened?
In the tcp-alloc example clients received each others addresses but failed to dial and didn't exchange messages.
Server:![Screenshot from 2024-07-23 15-47-07](https://github.com/user-attachments/assets/14f47fde-f159-4bab-bbd6-59f487164b48)
Client 1:![Screenshot from 2024-07-23 15-48-58](https://github.com/user-attachments/assets/245e7bb9-af3e-468c-abfd-8db12daf0bb5)
Client 2:![Screenshot from 2024-07-23 15-49-40](https://github.com/user-attachments/assets/9dbb7888-7b31-40d6-be0d-cdf87d78d0ff)