We found clients joining behind corporate networks, cannot successfully use our self hosted service. (This is meetings of more than 2 people thus VideoBridge does kick in.)
From our understanding this could be because the UDP/Stun traffic might be being blocked by a corporate firewall. If fallback options are successfully configured it should fall back to TCP successfully.
To validate if it was a miss configuration at our end we asked the clients to join https://meet.jit.si/ as a test. The outcome was the same result.
@emrah One critical bit of information I missed out:
Once we swapped over to https://meet.jit.si/, the first user to join was one of the corporate users having connection issues. While it was just 2 of us in the call it was working. As soon as a third person joined (I assume) the VB kicked in and at that point we lost the corporate user.
I think this means P2P is working for your environment but multiparty conference isn’t. The participants communicate with each other directly in P2P mode but they communicate through JVB (or TURNS) when there are more than 2 people.
I just tested meet-jit-si and with UDP/10000 and UDP/443 blocked it fell back to TCP/443 (TURN/TLS) as expected. I suggest using meet-jit-si first to pinpoint what’s failing and why. We can help if you include logs from a user that fails to connect.
To make testing easier you can disable p2p with a URL parameter like this: https://meet.jit.si/frequentCardsReadAdequately#config.p2p.enabled=false
It looks like we are planning another test session with some of our clients on “https://meet.jit.si/”. It is taking a while to organise, but we will get there!
Our plan is to gather as much console logs from end users as possible and identify which users can’t see and hear other people on the call.
We will report back to you with our findings. Do you have any advice for us before this test?