Talk WebRTC: relay-tcp candidate is preferred over relay-udp

Nextcloud version (eg, 24.0.1): 27.0.0
Talk Server version (eg, 14.0.2): 17.0.1
Custom Signaling server configured: yes, tag 03266eb (currently latest)
Custom TURN server configured: yes, coturn latest
Custom STUN server configured: yes, coturn latest

In case the web version of Nextcloud Talk is involved:
Operating system (eg, Windows/Ubuntu/…): Windows 11
Browser name and version (eg, Chrome v101): Firefox 114

The issue you are facing:
I’m working on a setup with a High Performance Backend and a TURN server listening on 443/udp (TURN) and 443/tcp (TURNS, Let’s Encrypt Certificate). It’s all working, but I have questions about the calculated priorities of the ICE candidates. Currently, i observe the following behavior, depending on my Talk TURN config:

  • “TURN Only”: the udp relay is selected
  • “TURNS Only”: the tcp/tls relay is selected
  • “TURN and TURNS”: the tcp/tls relay is selected.

I would prefer if clients would use the UDP relay if it’s available, as I understand this is more performant. The Mozilla docs state that:

Note: Generally, ICE candidates using TCP are only going to be used when UDP is not available or is restricted in ways that make it not suitable for media streaming. Not all browsers support ICE over TCP, however.

… but this doesn’t seem to be the case here. Can Talk influence this decision somehow? It clearly can completely disregard my TCP/TLS relay with the “TURN only” option.

here’s my ICE status after starting a call.