Closed myOmikron closed 11 months ago
Thanks for pointing this out -- it looks like a quick fix. We'll take a closer look.
bbb-install does not care about IPv6 if I understand that correctly. Adding the listen statement to haproxy should work, however you should investigate the behaviour of freeswitch if you enabled IPv6. If you do not use the fullaudio bridge, freeswitch expects the RTP traffic on the same protocol family as the sipjs websocket connection. So in this case turn servers also should be running a dual stack setup otherwise clients who need a TURN server might not be able to establish a connection if the clients connect using IPv6 and the TURN server only offers IPv4 candidates.
I have stumbled across the same problem.
I modified haproxy.cfg and it's working with a ipv6 turn (on the same system (thanks to haproxy)).
Can somebody modify the install script for all other bbb users? https://github.com/bigbluebutton/bbb-install/blob/master/bbb-install-2.6.sh#L787
We have a lot of dual stack ligth customers. So ipv6 is much more stable.
BTW: test. and demo.bigbluebutton.org are not available via IPv6
Thanks!
@Daniel-at-git, are you able to test @schrd's comment to confirm that a TURN candidate on IPV6 for FreeSWITCH is able to connect when the websocket connection returns an iPV4 address (without using fullaudio setup)?
@ffdixon Let's say it this way. I blocked all ports except 53,80 and 443 on my client and I have audio connection.
It tried to take a look to chrome developer tools. I can see the websocket but it didn't show any IP-Adresse. If I go to chrome://webrtc-internals/ I see an ipv4 address (starting with 78.46.).
I hope this answers you question.
Still not fixed in 2.7... this costs me hours, because I though that I did something wrong, all the time. This should have a high priority I think.
@kepstin as #674 has made a PR with my proposed changes, can we close this issue?
Thanks @myOmikron for the merged pull request. Closing this issue.
The
/etc/haproxy/haproxy.cfg
looks the following after upgrading from bbb 2.5:Haproxy starts as expected on
0.0.0.0:443
, but not on[::]:443
.After changing the bind part to:
and restarting
haproxy.service
, everything works as expected