Does your Jitsi public service fall back to TCP?

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 as a test. The outcome was the same result.

We want to know if your public service has TCP fall back enabled?


Yes, TURN (for TCP fallback) is enabled on so clients behind a restricted network should be able to connect through TCP. Might be something else/additional going on in your case.

I would agree, however this occurred with 2 separate corporate clients not just one.(Same story with regards to ) @Freddie

Can you gather browser logs and share?

Hi @Freddie,

Sorry its taken me so long to get back to you. We did manage to get logs from our self hosted solution, however we did not get logs from the public service.

I have 2 user console logs, I have had to redact some information.

user_1.log (97.4 KB)
user_2.log (118.1 KB)

There may be a client-side proxy which breaks websocket connection

@emrah One critical bit of information I missed out:

Once we swapped over to, 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.

Exact same behaviour on our self hosted service &

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.

Are these two participants from the same network?

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:


We are willing to ask out client to join us on a call again on “

If we setup a meeting and confirmed the link, time and date and shared that with you, would you be able to analyse the logs from your end? Rather than us providing you with the console logs.

I do not think its going to be possible to get the client to provide us with console logs again.

Not really. The most important information in this case is in the client logs (trying and failing to allocate a TURN candidate, I expect) and we don’t store them.

Hi Jitsi Team,

It looks like we are planning another test session with some of our clients on “”. 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?

Kind Regards,