coturn | coturn TURN server project | Runtime Evironment library

My suggestion is to gather more information on the reasons of the failure.

I'm assuming you're configuring the Trickle ICE application with a turn:IP:port server URL, which allows for unencrypted exchanges with TURN.

This means you can trace on your machine, e.g. using Wireshark, and verify whether the STUN binding requests and TURN Allocate requests are being sent out to the expected TURN server's public IP and port, and whether there are responses to them being received by the browser.

Additional checks you can do is on the TURN server side. With something like netstat -tunapl you can verify that coturn is not only running but also listening on the expected port (which should be 3478 since you left it unspecified).

If all looks as expected, then run a trace on coturn's host while you trigger a "Gather candidates" from the Trickle ICE application. You could use something like ngrep -d any -lqtW byline port 3478 to see the activity and content exchanged.

If coturn doesn't receive anything, then check again the EC2 instance Security Group and ensure you're allowing traffic to port 3478 UDP (and TCP). Double check the EC2 instance's public IP address is what you're using in the Trickle ICE application.

If instead you have more than one network interface assigned to that EC2 instance, then ensure you have a listening-ip configuration item set to the correct private IP address, and an external-ip directive which includes PUBLIC_IP:PRIVATE_IP, where the public IP is the one you're trying to use and the private IP is the one coturn is listening on.

e.g.:

The cause of the problem is that the IceCandidate of server.js is not sent to caller.js

Modify server.js

network_mode: host doesn't work on MacOS or Windows systems. The Docker Use host networking documentation notes:

The host networking driver only works on Linux hosts, and is not supported on Docker Desktop for Mac, Docker Desktop for Windows, or Docker EE for Windows Server.

It also essentially entirely disables Docker's networking stack, and is almost never necessary.

You need to do three things here:

1. Remove all of the network_mode: host lines from the Compose file. (The container_name: lines are also unnecessary.)
2. For any of the services you need to access from outside Docker (could be all of them and that's fine) add ports: to publish their container ports.
3. When any of these services internally call other services configure their URLs (for example, in the .env files) to use their Compose service names. (See Networking in Compose in the Docker documentation.) (Also note that your frontend application probably actually runs in a browser, even if the code is served from a container, and can't use these host names at all; this specific point needs to still use localhost or the host name where the system will eventually be deployed.)

So, for example, the setup for the frontend and backend containers could look like:

The specification says the property is credential, not credentials. Did you find the wrong spelling in a particular place?

The generally accepted solution for this is time-limited credentials as described in https://datatracker.ietf.org/doc/html/draft-uberti-behave-turn-rest-00 combined with monitoring of your turn servers to assert that the users the credentials were given to are not abusing them (for some definition of that)

There was a simple error in my Android app. When receiving an ice candidate from the signaling server I did the following:

Before setting up a brand new TURN server you can try to understand what's actually happening: if you take a trace on the computer with an application like Wireshark, and filter for stun messages, you should be able to see the browser sending Binding Request and Allocate Request methods towards the TURN server.

A missing response from the server may mean that the server is not available, the port is wrong, or a firewall prevents the browser to reach the TURN server.

If instead the credentials are wrong, the browser will receive a 401 error to the Allocate Request with the message-integrity attribute.

You can also verify the TURN URL and credentials by running the WebRTC sample application that deals with ICE candidate gathering at https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ .

With those changes, I'm able to acheive 3 to 4 stable delay ;)

LINE 79 of

https://github.com/OpenVidu/openvidu/blob/master/openvidu-server/docker/openvidu-recording/scripts/composed.sh

I REPLACED

Even if a TURN extension exists to obtain a TCP allocation, WebRTC does not support TURN TCP relaying, only UDP. However, it supports connecting the TURN server with TCP or TLS.

This reason is that the TURN server is assumed to be on an unrestricted network with working UDP connectivity. Since TCP has bad properties for real-time traffic, it should only be a last resort fallback, and in the extreme situation where both peers lack UDP connectivity, they can connect to TURN servers with TCP, the traffic between the TURN servers will still be UDP.