We're calling on all EU-based Mozillians with iOS or iPadOS devices to help us monitor Apple’s new browser choice screens. Join the effort to hold Big Tech to account!

Funkcionalnosć tutoho sydła so přez wothladowanske dźěła wobmjezuje, kotrež maja waše dožiwjenje polěpšić. Jeli nastawk waš problem njerozrisuje a chceće prašenje stajić, wobroćće so na naše zhromodźenstwo pomocy, kotrež na to čaka, wam na @FirefoxSupport na Twitter a /r/firefox na Reddit pomhać.

Avatar for Username

Pomoc přepytać

Hladajće so wobšudstwa pomocy. Njenamołwimy was ženje, telefonowe čisło zawołać, SMS pósłać abo wosobinske informacije přeradźić. Prošu zdźělće podhladnu aktiwitu z pomocu nastajenja „Znjewužiwanje zdźělić“.

Dalše informacije

Tuta nitka je so archiwowała. Prošu stajće nowe prašenje, jeli pomoc trjebaće.

Firefox is not using direct WebRTC connection when disabling TURN protocol but candidates are presented

  • 1 wotmołwa
  • 1 ma tutón problem
  • 1 napohlad
  • Poslednja wotmołwa wot Florian Seifer

Florian Seifer
Florian Seifer
more options

Hello,

we have a BigBlueButton Server setup for our company. Until recently we used a TURN-Server to tunnel the UDP connections thrugh the firewall.

Due to performance issues we wanted to try and let the clients connect directly to the udp ports 16000 - 32000

In Chrome this works as expected.

In Firefox however when we set "media.peerconnection.turn.disable" to "true" FF does not find any WebRTC candidates. We checked the logs and it says there:

"relay only option is set without any TURN server configured" "relay/proxy only option results in ICE TCP being disabled"

But thats NOT true! The option "media.peerconnection.ice.relay_only" is definetly set to "false"

Tested on FF 115.5.0 ESR and 120.0.1

Does anyone have an idea whats happening here? Why doesnt FF even try to make a direct connection?

UPDATE: I just ran a test on our dev system. If we configure BBB so that it does not offer any TURN-servers, FF uses a direct connection. Sadly that is not possible, since we need the TURN server for external connections. When there are TURN-Candidates but TURN is disabled via FF config no connection is established at all. This definetly semms like a bug in FF, since the browser should still be able to simply try and connect directly.


Thank you for you support

Hello, we have a BigBlueButton Server setup for our company. Until recently we used a TURN-Server to tunnel the UDP connections thrugh the firewall. Due to performance issues we wanted to try and let the clients connect directly to the udp ports 16000 - 32000 In Chrome this works as expected. In Firefox however when we set "media.peerconnection.turn.disable" to "true" FF does not find any WebRTC candidates. We checked the logs and it says there: "relay only option is set without any TURN server configured" "relay/proxy only option results in ICE TCP being disabled" But thats NOT true! The option "media.peerconnection.ice.relay_only" is definetly set to "false" Tested on FF 115.5.0 ESR and 120.0.1 Does anyone have an idea whats happening here? Why doesnt FF even try to make a direct connection? UPDATE: I just ran a test on our dev system. If we configure BBB so that it does not offer any TURN-servers, FF uses a direct connection. Sadly that is not possible, since we need the TURN server for external connections. When there are TURN-Candidates but TURN is disabled via FF config no connection is established at all. This definetly semms like a bug in FF, since the browser should still be able to simply try and connect directly. Thank you for you support

Wot Florian Seifer změnjeny

Wubrane rozrisanje

I found the reason for the odd behaviour of Firefox!

Turns out the Bigbluebutton-Server was forcing FF to use TURN-Servers.

Ironically this feature should be deactivated by default. From https://docs.bigbluebutton.org/support/troubleshooting/

"Why isn't forceRelayOnFirefox enabled by default? It's not on by default because bigbluebutton does not come with a TURN server by default, and that's what versioned-in-code setting presumes."

But if you look at the corresponding settings-file you see this: /usr/share/meteor/bundle/programs/server/assets/app/config/settings.yml'

" # Firefox has a buggy ICE implementation. With mediasoup this leads to 

   # connection problems unless all traffic is relayed through a turn server.
   forceRelayOnFirefox: true"

After I deactivated the option, FF is now using a direct connection and for our setup this seems to improve the connection drastically.

Regards

Florian Seifer

Tutu wotmołwu w konteksće čitać 👍 0

Wšě wotmołwy (1)

Florian Seifer
Florian Seifer Prašer
more options

Wubrane rozrisanje

I found the reason for the odd behaviour of Firefox!

Turns out the Bigbluebutton-Server was forcing FF to use TURN-Servers.

Ironically this feature should be deactivated by default. From https://docs.bigbluebutton.org/support/troubleshooting/

"Why isn't forceRelayOnFirefox enabled by default? It's not on by default because bigbluebutton does not come with a TURN server by default, and that's what versioned-in-code setting presumes."

But if you look at the corresponding settings-file you see this: /usr/share/meteor/bundle/programs/server/assets/app/config/settings.yml'

" # Firefox has a buggy ICE implementation. With mediasoup this leads to 

   # connection problems unless all traffic is relayed through a turn server.
   forceRelayOnFirefox: true"

After I deactivated the option, FF is now using a direct connection and for our setup this seems to improve the connection drastically.

Regards

Florian Seifer