Implement ICE-TCP

[Sean-Der]

This is going to take me a while, but I wanted to check in before I started!

I am going to implement both active + passive. My reasoning is I want to be able to test it E2E.

I don't have any hard ideas/opinions on how it should be implemented. Do you have any advice as I learn the code base?

[Sean-Der]

@paullouisageneau Looking at the different modes conn types (Poll/Thread/Mux) it seems unlikely I would succeed putting the concept of TCP into them.

Should I create something multi-threaded that does TCP as its own thread/struct?

[paullouisageneau]

OK, this is complicated because the whole library is designed with the assumption that candidates can only be UDP. It would be way simpler to implement TURN TCP.

I think you can't realistically implement something on the side running in its own thread. It seems to me the best way to implement this is to add optional TCP sockets for each agent to the thread and poll connectivity backends (I don't think mux mode can have TCP candidates as you would have to create new sockets).

TCP sockets would be polled and read by the backend. A lot of functions assume addresses are UDP only, like conn_get_addrs() and agent_conn_recv(), you will probably need to introduce a socket type in addr_record_t to distinguish between UDP and TCP.

You would then need to modify the logic to match candidates pairs properly. You would probably need to introduce a function to order the backend to actively connect to a remote TCP address.

Again, this is complicated and requires fundamental changes, contrary to TURN TCP (as candidates are still UDP in that case).

[paullouisageneau]

As I understand TCP candidates are not exclusive. An agent may gather both active, passive (and possibly simultaneous open) candidates.

[Sean-Der]

They can be! I believe browsers only do active TCP. They don't accept inbound TCP connections.

[Sean-Der]

It would be way simpler to implement TURN TCP.

Requiring users to run TURN servers would make for a worse ecosystem. It wouldn't be fatal, but I would have regret for pushing the complexity onto everyone.

Many WebRTC implementations don't support adding TURN servers after the setLocalDescription (gathering locally). This means that for WHIP I would have to ask users to support both OPTIONS + POST (for returning TURN servers).

If we do ICE-TCP users don't have to run additional TURN servers with all the extra infrastructure needed to make it work. I hope you think that's a good enough justification to add this to lib juice.