TCP supported for TURN?
Closed this issue · 2 comments
Hello,
I am trying to understand if eturnal allows a WebRTC client to fall back to TCP for TURN relaying, for those cases where the client might be blocked from using UDP?
I think it does, as it says on the eturnal website "Clients can connect using UDP, TCP, or TLS over IPv4 or IPv6."
However -and this is why I am asking- when looking at the list of supported RFCs in the eturnal Github Repo's README, it lists two RFCs, but not RFC 6062: Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations. But maybe this RFC is referring to something different from what I'm referring to?
Apologies for the boring question and thank you kindly for any help clarifying this!
TURN relaying works in an asymmetric manner: The TURN client talks to the server, which talks to the peer. The client might use UDP, TCP, or TLS to talk to the server. The link between server and peer is always UDP:
flowchart LR
Client-- TCP ---Server-- UDP ---Peer
Using TCP for the server―peer link would require the extension you mentioned, which is indeed not supported by eturnal. WebRTC clients typically don't support it either, as far as I'm aware.
So what happens if neither of the WebRTC clients can use UDP? In that case, both will talk TCP to their TURN server, and the TURN servers then talk UDP:
flowchart LR
Client-A-- TCP ---Server-A-- UDP ---Server-B-- TCP ---Client-B
If both clients use the same TURN server, the TURN server talks UDP to itself:
flowchart LR
Client-A-- TCP ---Server-- UDP ---Server-- TCP ---Client-B
I tried to explain these things in a little more detail on the web site.
If anything is still unclear, just ask!
Thank you very, very much for taking the time to answer and for explaining this so well!
Your 3-scenario illustration is the best I have seen anywhere on the web on this topic so far... I somehow mixed peers with clients and missed scenarios 2 and 3 completely...
Thank you again for helping me understand.