Open xdyyll opened 3 years ago
There is no plan to support RFC 6062 as libjuice is a UDP-only ICE agent. RFC 6062 is very niche: a TURN server must have an open access to the Internet, so TURN TCP allocations are only useful if you want a TCP session for file transfer. For instance, TURN TCP allocations are not part of the WebRTC standard.
However, I've been considering implementing TURN TCP transport between client and server, which can be useful for a peer on a network with blocked UDP traffic.
There is no plan to support RFC 6062 as libjuice is a UDP-only ICE agent. RFC 6062 is very niche: a TURN server must have an open access to the Internet, so TURN TCP allocations are only useful if you want a TCP session for file transfer. For instance, TURN TCP allocations are not part of the WebRTC standard.
However, I've been considering implementing TURN TCP transport between client and server, which can be useful for a peer on a network with blocked UDP traffic.
It's great. But I have implemented TURN TCP transport between client and server, RFC 6062 requires this first.
The usage is as follows
// Agent 1: Create agent
juice_config_t config1;
memset(&config1, 0, sizeof(config1));
// TURN server
// Please do not use outside of libjuice tests
juice_turn_server_t turn_server;
memset(&turn_server, 0, sizeof(turn_server));
turn_server.host = "stun.ageneau.net";
turn_server.port = 3478;
turn_server.username = "juice_test";
turn_server.password = "28245150316902";
config1.turn_servers = &turn_server;
config1.turn_servers_count = 1;
config1.cb_state_changed = on_state_changed1;
config1.cb_candidate = on_candidate1;
config1.cb_gathering_done = on_gathering_done1;
config1.cb_recv = on_recv1;
config1.user_ptr = NULL;
// Agent 2: Create agent
juice_config_t config2;
memset(&config2, 0, sizeof(config2));
juice_turn_server_t turn_server2;
memcpy(&turn_server2, &turn_server, sizeof(juice_turn_server_t));
// Use the same TURN server
config2.turn_servers = &turn_server2;
config2.turn_servers_count = 1;
config2.cb_state_changed = on_state_changed2;
config2.cb_candidate = on_candidate2;
config2.cb_gathering_done = on_gathering_done2;
config2.cb_recv = on_recv2;
config2.user_ptr = NULL;
config1.turn_servers[0].transport = JUICE_TRANSPORT_TCP;
//config1.turn_servers[0].allocate_transport = JUICE_TRANSPORT_TCP;
config2.turn_servers[0].transport = JUICE_TRANSPORT_TCP;
//config2.turn_servers[0].allocate_transport = JUICE_TRANSPORT_TCP;
agent1 = juice_create(&config1);
agent2 = juice_create(&config2);
The code may not be robust enough. May I submit a pull request?
It's great. But I have implemented TURN TCP transport between client and server, RFC 6062 requires this first. May I submit a pull request?
That's great! Sure, please do, I'll be happy to review it.
Hey @paullouisageneau
I had a OBS user express interest in this. Networks that have no UDP connectivity or very poor. Are you still open to accepting a patch for rfc6062?
If you are do you have any guidance/suggestions on how to implement it?
@Sean-Der Are you talking about RFC 6062 (TURN Extensions for TCP Allocations) or TCP transport for TURN? WebRTC does not support RFC 6062.
TCP Transport for TURN
just so the creator of the allocation to use TCP. No interest in 6062 sorry for the mix up :(
OK, I opened a separate issue for TURN TCP transport: https://github.com/paullouisageneau/libjuice/issues/257
Some network environments block UDP and only TCP can passed. I am trying to implement RFC 6062, Is it a good idea?