Any ideas on debugging Jitsi connection issues on a variety of corporate networks?

I am pushing for Jitsi to be used as a self-hosted solution for several corporate events. However, the option is losing to proprietary solutions because I’m having trouble recreating problems users have connecting across a variety of corporate networks. I can’t be sure if it’s the domain that is getting blocked, the UDP port that is not available, HTTP downgrade or what. Do you see any checks that I could implement on the client side to help debug these problems? Besides just checking that the browser can do a simple GET request to my Jitsi domain.

You can use nc to check whether udp pass through. Thehttps://community.jitsi.org/t/tip-how-to-check-udp-10000-connectivity/73031e

Thank you. Yeah, most of the problem solving that I see involves coordinating with the user that’s having the issue so they can try the thing while I watch for the thing. That’s normally not an option, so I’m looking for ways to identify the issue automatically. But I understand it’s likely impossible to check for something like UDP from the browser, right?

At the very least, I’m trying not to show these users something like a blank iframe with ERR_EMPTY_RESPONSE as if the site is broken. It seems that the only way is to pre-emptively open a hidden room to test the connection, maybe by waiting for the video-conference-joined event from the hidden iframe? Do you have any suggestions on the client front?

test.webrtc.org is another option for checking an environment, its analysis tool. You need some check like that if you want …

test.webrtc.org is another option for checking an environment, its analysis tool. You need some check like that if you want …

By the way, does anyone have something like this self-hosted?