bigbluebutton
If TURN server is present, STUN is superflous
If a TURN server is available, then there is no need to supply STUN servers to the Browser. As stated on webrtc.org:
TURN (Traversal Using Relay NAT) is the more advanced solution that incorporates the STUN protocols and most commercial WebRTC based services use a TURN server for establishing connections between peers.
It is enough to supply one turn: URL (for UDP) and one turns: (for TCP/TLS).
STUN is used to figure out if TURN is needed or not. You'll want to avoid using TCP over TURN if it is not necessary.
True. However, TURN is an extension to STUN and Browsers will happily use a TURN server to generate all possible ice candidates (including prflx and srflx normally provided by STUN in addition to relay which is provided by TURN). So there is no need to additionally configure STUN if you already supply a TURN server.
If you specify just two TURN URLs as ICE servers, then you cover all cases:
- UDP endpoint:
turn:turn.example.com:3478 - TLS endpoint:
turns:turn.example.com:443?transport=tcp
That is enough. An additional benefit is that Firefox also stops complaining about too many ice servers which might slow down the ice gathering phase.
@basisbit is there a chance that this gets merged at some point? Do you need more information on the subject? Otherwise I'll close this PR.
@znerol I found your argument kinda right. I am hesitate to use it in my production though. I would like to know if you have really test this in production with a diffrent clients/devices?
Thanks,
Btw, you can also check what other applications are doing by pulling up about:webrtc in Firefox and then look for iceServers. E.g., meet.jit.si only specifies one turn URL:
iceServers:
urls: ["turns:meet-jit-si-turnrelay.jitsi.net:443?transport=tcp"]
credential(Provided/Not Provided): Provided
userName(Provided/Not Provided): Provided
Also see their docs on turn. No recommendation to also add stun URLs` if a turn server is available.
Same for matrix-org/synapse
YMMV, it is for sure a good idea to try to find a way to test this before putting it in production.
Just stumbled into this a bit late, but there seems to be a misconception here.
Two different things are being mixed: ICE and STUN/TURN. ICE is a "user" meta protocol of the STUN/TURN protocols. There are two different configurations for that single reason. We need to focus on srflx vs relay candidates rather than whether a TURN instance does STUN as well.
Saying that TURN is STUN capable is just the same as saying that a coturn instance (which is a TURN server) can also be used as a STUN server (which it is).
If you do not set a STUN entry in the stun: dictionaries, the browser won't generate srflx candidates. That's just it. Configuring the turn: entries won't make it generate srflx candidates.
That is to say: setting servers without STUN is indeed a valid use case. I myself do that. But that's due to peer reflexive candidates, not to TURN doing STUN. Even if you set neither you'll get it working under prflx candidates given the right conditions.
The reason I think the docs don't recommend that is: 1) prflx candidates didn't fully work on our side till ~second quarter of 2020 (but they now do fairly well) 2) prflx candidates don't necessarily always work depending on the server NAT and firewall rules, so probably the docs are being zealous.
If you do not set a STUN entry in the stun: dictionaries, the browser won't generate srflx candidates.
I've actually tested this. Both, Chromium and Firefox do generate srflx candidates In my case even though my BBB instances only provide one turn: and one turns: ice server.
Oh, mea culpa for not reading the thread thoroughly. I focused on the jitsi meet example (which is a relay only example anchored on peer reflexive candidates, not server reflexive) rather than reading your PR.
You're actually suggesting to include a turn:3478 UDP (which does generate srflxs and udp relays) endpoint in place of the STUN entry and the turn:443-tcp on the server rather than removing the STUN entry and keeping the current TURN pair. That works.
It would be fine by me if it's guaranteed that Safari isn't borking anymore without two different set of relay-tcp turn entries configured (the turn: and turns:); which was the reason that was suggested a long ago if I remember correctly.
You're actually suggesting to include a turn:3478 UDP (which does generate srflxs and udp relays) endpoint in place of the STUN entry and the turn:443-tcp on the server rather than removing the STUN entry and keeping the current TURN pair. That works.
I guess that is what I suggested. You can check how the section looks like after applying the patch by following this link:
https://github.com/bigbluebutton/bigbluebutton.github.io/blob/eb3c1850cc980ec9827600ec8ffad591affcad67/_posts/2019-02-14-setup-turn-server.md#configure-bigbluebutton-to-use-your-turn-server
It would be fine by me if it's guaranteed that Safari isn't borking anymore without two different set of relay-tcp turn entries configured
Some fraction of my users do use Safari, no complaints so far. Haven't tested it systematically though.
Some fraction of my users do use Safari, no complaints so far. Haven't tested it systematically though.
Cool. I'll look around and see if I can get someone to field trial this and get error rate comparisons.