Try running a meeting with 3 participants in your deployment, the check the connection stats. If websockets are working and configured correctly, you should see all the stats there. If not, some stats will be missing (and resolution will be poor).
an easy way to check for that (beside using browser console) is to look for the dominant speaker indicator. It’s a thin blue line around the last speaker vignette in tile mode. If it moves when someone speaks (when I do tests by myself, i scratch the mic of one of my 2 tests computers), websockets work.
Ah I understand, it’s a dev problem, I just tested and there is no problem in a browser with meet.jit.si, bitrate stats are available a few seconds after meeting is created (3 users). If you use a public instance, you make yourself vulnerable to discrepancies between a possibly older code base and a more recent meet.jit.si - note that the Jitsi-meet devs are made clear that meet.jit.si is not garanteed to match any particular released version, it’s probably between stable and unstable with custom patches but you can never be sure.
If you have never rebased for months, it may be a problem.
IMO using meet.jit.si for dev is good if all you need is the URL API, for everything else setting up a test instance using instable is better - after all you need to develop for the future and you are free to update the test server at any time you want, so it’s stable when you need to debug your code.
I wonder if this stuff could not be softened a bit for the sake of interop - that is, if someone provides a service with a custom client, give the possibility that the client could be used with meet.jit.si (if it’s open source of course), and the Jitsi client could be used with the provider’s service.
Please ping Emil Ivov if you think the question has any interest but you don’t care to reply yourself.