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
The libjuice library is designed under the assumption that there is only one UDP socket to make the code simpler. I think integrating TCP candidates would require significant architectural changes.
I'm a bit dubious about ICE-TCP in general, are you talking about active, passive, or simultaneous open? For what use case would you need them?
On a related note someone started implementing TURN TCP a long time ago but bailed out.
I would like active candidates. Currently I am only using libdatachannel as a 'client' only (with OBS).
Some broadcaster want TCP (over UDP). They would rather see backpressure then packet loss. If the stream falls behind real-time that is better then packet loss. You also have the connectivity issues. Users that don't support UDP at all etc..
I prefer ICE-TCP/ICE-TLS over TURN because it reduces the complexity of what I have to deploy. TURN is somewhat expensive to run. You have to maintain another service, and deal with the extra CPU+Network usage. It isn't intractable but I have had more success with ICE-TCP/ICE-TLS personally.
Hey @paullouisageneau
Would ICE-TCP be accepted as a PR, or is that out of scope?
thanks!
The text was updated successfully, but these errors were encountered: