before deploying a Jitsi-meet instance on a third-party server, I am testing
the web conferencing via https://meet.jit.si:
I am trying a simple web conference between two clients:
1. client with Windows 7 + Chrome (latest 64bit)
2. client on GNU/linux + Firefox (latest - version 50.0.2 64bit)
Both clients are behind NAT and are on the same private network branch.
Once they are visiting the same conf web page, the second client can
see the other client video stream, but the first one can see the second
client stream at maximum for two-three seconds, then the image
grey-out and freeze with a warning that "the user is having connectivity
Then the video stream resume again, but start stuttering again and
again, showing intermittently like if the network connectivity is on a
sloppy link or had bandwidth overload, but the second client video resolution
is 640X480 and there is more than adequate bandwidth to carry on the stream,
so this is not a bandwidth related issue.
Unfortunately until now my research results are poor and I hadn't the time to
look at the source to see what condition(s) trigger(s)
that warning message, but I suspect that the
problem lies somewhere in the GNU/Linux system negotiating a wrong ICE
session setup, and thus packets get dropped or lost somewhere in the
I am linking the only piece of debug info I could collect by looking
at the Firefox web page about:webrtc, it's the full debug log, but I don't
see anything suspecting - at least there are no ERROR messages:
Any suggestions/hints are greatly appreciated.
Also: how can I dig more for debugging the issue? Wireshark? Js web console?
PS= Naturally I am assuming that the https://meet.jit.si instance is working
"good" and its config is "right" and is running the latest stable version,
and so the problem lies somewhere on the client side.