Firefox, TURN forced ?

[Gilou]

Hi,

I was trying to debug a situation where Firefox is not using IPv6, and
it turns (haha) out, it's a WebRTC TURN issue…

I can reproduce it on demo.bigbluebutton.org (demo3, namely) and
test27.bigbluebutton.org.

Connecting using a machine that is fully UDP capable, with no firewall
restrictions, I immediately get TURN-ed when I try to connect using
WebRTC. I'm using a separate TURN server using coturn. But same happens
on test27 / demo, which probably share the IP for that.

If I try to deactivate turn (using media.peerconnection.turn.disable),
audio connection fails:

WebRTC: ICE failed, your TURN server appears to be broken, see
about:webrtc for more details

But … it shouldn't be using it at all. This browser is firefox 118.0.2
on Ubuntu 22.04.3. And it doesn't matter if I'm using IPv4 and/or IPv6.

If I use Chromium 117, I get connected directly to the server, without
using the TURN server (and I checked by watching the connected sockets).

Do you get the same behavior? Is it a Firefox bug, or a bbb issue?

Connecting to test27.bigbluebutton.org, these are the raw candidates:
local
turn-relay(IP4:192.168.1.13:0/TLS|IP4:143.198.37.212:33727/UDP)
turn-relay(IP4:192.168.1.13:44558/UDP|IP4:143.198.37.212:58344/UDP)
turn-relay(IP4:192.168.122.1:0/TLS|IP4:143.198.37.212:44799/UDP)
turn-relay(IP4:192.168.122.1:39376/UDP|IP4:143.198.37.212:44398/UDP)
remote
candidate:udpcandidate 1 udp 1076558079 143.198.37.212 32126 typ host

Local SDP:
v=0
o=mozilla...THIS_IS_SDPARTA-99.0 9109189983615430833 0 IN IP4 0.0.0.0
s=-
t=0 0
a=fingerprint:sha-256
85:28:A7:A6:28:D0:84:0E:2D:24:E0:C7:BD:8B:8A:49:78:8D:73:A1:DF:4A:0E:F7:3B:DA:A0:75:35:17:79:8C
a=group:BUNDLE 0
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 9 UDP/TLS/RTP/SAVPF 109 9 0 8 101
c=IN IP4 0.0.0.0
a=sendrecv
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:101 0-15
a=ice-pwd:12d578c792250ef45b210b44ac669d15
a=ice-ufrag:4a2dfa86
a=mid:0
a=msid:{a317a640-9195-4d8f-814d-7b5139e3c339}
{c29aefca-b813-40c6-b57a-bc3f0740af3b}
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000/1
a=setup:actpass
a=ssrc:3221034735 cname:{9ee4b170-605e-460a-bc71-e51e943ddc65}

Remote SDP:
v=0
o=mediasoup-client 10000 1 IN IP4 0.0.0.0
s=-
t=0 0
a=ice-lite
a=fingerprint:sha-256
7E:DF:0D:00:01:B0:A6:5A:28:A5:38:8A:D3:0F:4E:DE:E7:7C:68:55:04:50:2E:25:AA:E3:9D:99:47:56:41:71
a=msid-semantic: WMS *
a=group:BUNDLE 0
m=audio 7 UDP/TLS/RTP/SAVPF 109
c=IN IP4 127.0.0.1
a=rtpmap:109 opus/48000/2
a=fmtp:109 useinbandfec=1; maxaveragebitrate=30000;
maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=setup:active
a=mid:0
a=msid:{9ee4b170-605e-460a-bc71-e51e943ddc65}
49de22cf-a5cd-4437-b0ca-b4ec08a65477
a=sendrecv
a=ice-ufrag:9erqqid7q1bwqom5mn0rvne47a0lnxjy
a=ice-pwd:30xss4r1wfxa4mcfkp2hhtw6lkuvdz94
a=candidate:udpcandidate 1 udp 1076558079 143.198.37.212 32126 typ host
a=end-of-candidates
a=ice-options:renomination
a=ssrc:983852080 cname:mqTQAhHKm0ipfxo0
a=ssrc:983852080 msid:mqTQAhHKm0ipfxo0 bcdab267-debf-4612-8822-d3d9b60399cb
a=rtcp-mux
a=rtcp-rsize

[Gilou]

Le 16/10/2023 à 16:29, Gilou a écrit :
> Hi,
>
> I was trying to debug a situation where Firefox is not using IPv6, and
> it turns (haha) out, it's a WebRTC TURN issue…
>
> I can reproduce it on demo.bigbluebutton.org (demo3, namely) and
> test27.bigbluebutton.org.

Note: I tried on a BBB 2.4 set-up with a TURN server, I noticed that we
used to send a STUN stanza in addition to the TURN ones, and… Firefox
happily connects directly using UDP, without using the relay…

Maybe we should send a STUN stanza to make firefox happy? (that's an
actual noob question… I have no idea what the real issue is).

I also note that iceTransportPolicy: all became: iceTransportPolicy: relay…
And in the chromium case:

{ iceServers: [turns:test27.bigbluebutton.org:443?transport=tcp,
turn:test27.bigbluebutton.org:3478], iceTransportPolicy: all,
bundlePolicy: balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0 }

So… are we sending something different to the 2 browsers?

Cheers,
Gilou

[Gilles Pietri]

Le 16/10/2023 à 16:29, Gilou a écrit :

> Hi,
>
> I was trying to debug a situation where Firefox is not using IPv6, and
> it turns (haha) out, it's a WebRTC TURN issue…
>
> I can reproduce it on demo.bigbluebutton.org (demo3, namely) and
> test27.bigbluebutton.org.
>
> Connecting using a machine that is fully UDP capable, with no firewall
> restrictions, I immediately get TURN-ed when I try to connect using
> WebRTC. I'm using a separate TURN server using coturn. But same happens
> on test27 / demo, which probably share the IP for that.

OK…
I found that: https://github.com/bigbluebutton/bigbluebutton/issues/16614

TL;DR
In /etc/bigbluebutton/bbb-html5.yml
public:
media:
forceRelayOnFirefox: false

I have a strong opinion on that subject, and think this is harmful.
Direct connections should be the right default setting, this looks like
a poor work-around for an obscure issue, I'll have to look to
understand, and think if it's an actual wrong behavior with ICE by
Firefox, this ought to be fixed in Firefox.

Also, it works as mentioned in the issue, on Firefox 118 / BBB 2.7,
through direct connection.

And, it seems that this is not only forcing the TURN hoop, but also not
IPv6 friendly (that was main issue, TURN over IPv4 when IPv6 was
available, until I noticed I was using the TURN server without
necessity). I'll need to troubleshoot that specific issue further, but
I'm unhappy about that default setting.

Regards,

Gilles

[Gilou]

Le 16/10/2023 à 17:11, Gilles Pietri a écrit :
>
> I have a strong opinion on that subject, and think this is harmful.
> Direct connections should be the right default setting, this looks like
> a poor work-around for an obscure issue, I'll have to look to
> understand, and think if it's an actual wrong behavior with ICE by
> Firefox, this ought to be fixed in Firefox.

OK, I read more in details the upstream Firefox bug report,
https://bugzilla.mozilla.org/show_bug.cgi?id=1034964

And I understand BBB devs position… now on to understand why IPv6 is not
used primarily… And to follow up on that tricky situation with ICE-lite…

Regards,

Gilou

[Gilou]

Le 16/10/2023 à 17:18, Gilou a écrit :

> And I understand BBB devs position… now on to understand why IPv6 is not
> used primarily…

Hi,

This looks rather simple, it seems that mediasoup makes use of
mediasoup:
webrtc:
listenIps

being an array, thus with order. I feel that it's using that to decide
what to prioritize, but that may be a coincidence (though I doubt it ;))

https://docs.bigbluebutton.org/administration/firewall-configuration#updating-mediasoup

If I'm right, putting the IPv6 stanza before the IPv4 one makes it
define its priority… So something like
mediasoup:
webrtc:
listenIps:
- ip: 2001:db8::
- ip: 0.0.0.0
announcedIp: 192.0.2.0

May lead to IPv6 being (properly?) used by default.

Regards,
Gilou