Installation of jitsi-meet works fine, but no audio/video

Hi,

I installed jitsi-meet .deb packages from https://download.jitsi.org on a Debian 9 (stable, stretch) container.
The installation was very smooth and I like, that the dependencies are used from the Debian base. Nice!

However, only text chat works, while audio and video fail. People see themselves, but not their peers.
The videobridge is running, prosody is running, nginx is running. Ports 80, 443, and 4443 are open to the world, while all other ports are blocked. Nginx still runs with a self-signed cert, btw.

Any idea how to debug this? Any typical errors to check for?

Many thanks in advance!

What about opening udp 10000? Also is your jvb running behind Nat?

I was not aware of UDP 10000 and opened it now. But it does not seem to have any effect. About nat, I’m not sure: Nginx, prosody, jvb etc. all run on the same container. The container has only certain ports open (TCPv4 80, 443, 4443, UDPv4 10000), but cannot open other ports to the outside. The hosting server, however, is not restricted in any way. Using nc I could confirm that the formentioned ports are reachable.

Probably you are using NAT, you need to instruct jvb for addresses: https://github.com/jitsi/jitsi-meet/blob/master/doc/quick-install.md#advanced-configuration

This was very helpful, many thanks! At least after putting 127.0.0.1 as local address and the external adaptors IPv4 as remote address, I was able to have an A/V conference. But it did work only between two participants in the same room, not for a remote person. So there is still something else…

You need to put the ip address which the remote participant can use to reach the jvb. Basically this goes in signalling and jicofo says to the clients, hey send your udp data to this ip address on port 10000.

That’s what I did:

# cat /etc/jitsi/videobridge/sip-communicator.properties
org.jitsi.videobridge.AUTHORIZED_SOURCE_REGEXP=focus@auth.meet.mycompany.com/.*
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=127.0.0.1
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=78.45.89.67

With the latter address being the one of the public interface, and the one that matches the DNS name.

From remote, I can see, that the port is open:

$ nc -vz -u meet.mycompany.com 10000
Connection to meet.mycompany.com 10000 port [udp/*] succeeded!

Still, only text chat possible.

Do you see something in the browser’s js console?

Yes, a lot, but there is something I didn’t catch before (Firefox 60.5.1esr):

ICE failed, add a STUN server and see about:webrtc for more details

And later many of the lines:

[JitsiConference.js] <X.prototype._init/this.e2eping<>: Failed to send a ping request or response.

This happens with two machines behind the same NAT, btw.

What are the other errors?
ICE failed means clients cannot connect to the jvb. In case of Firefox involved there is no p2p connection between clients.

My remote colleague got the following message:

[JitsiMeetJS.js] <getGlobalOnErrorHandler>:  UnhandledError: null Script: null Line: null Column: null StackTrace:  
Error: This client does not support P2P connections
Stack trace:
X.prototype._rejectIncomingCall@https://meet.mycompany.com/libs/lib-jitsi-meet.min.js?v=3216:6:297728
X.prototype._onIncomingCallP2P@https://meet.mycompany.com/libs/lib-jitsi-meet.min.js?v=3216:6:295774
X.prototype.onIncomingCall@https://meet.mycompany.com/libs/lib-jitsi-meet.min.js?v=3216:6:295892
r.prototype.emit@https://meet.mycompany.com/libs/lib-jitsi-meet.min.js?v=3216:6:152484
value@https://meet.mycompany.com/libs/lib-jitsi-meet.min.js?v=3216:25:88568
run@https://meet.mycompany.com/libs/lib-jitsi-meet.min.js?v=3216:6:21513
_dataRecv/<@https://meet.mycompany.com/libs/lib-jitsi-meet.min.js?v=3216:6:29833
forEachChild@https://meet.mycompany.com/libs/lib-jitsi-meet.min.js?v=3216:6:13288
_dataRecv@https://meet.mycompany.com/libs/lib-jitsi-meet.min.js?v=3216:6:29666
_onRequestStateChange@https://meet.mycompany.com/libs/lib-jitsi-meet.min.js?v=3216:6:49165

And then the same as I got:

 ICE failed, add a STUN server and see about:webrtc for more details

All other messages didn’t look like errors, but I can check later again.

Yep means there is a problem with communicating with jvb. You need to check port forwarding and the private/public address in jvb. Have you restarted jvb after setting the private and public address?

Yes, I even restarted the complete container.
I’m pretty sure to have the right remote address, but what about the local address?
Wenn I replace the current 127.0.0.1 with the interface address to the host, which, unfortunately, is not a fixed address, but a dynamic link-local one (169.254.*.*) , the “ICE failed” message does not appear anymore, says my remote colleague. But the long message, the stack trace, still appears.
If nothing helps, I can try installing the packages outside a container later this week, to rule out all errors not related to containerisation.

The error about P2P I suppose is cause on of the participants is using Firefox which currently does not work in p2p.

The local address is needed in case of NAT (not talking at all in the context of containers) and clients are in the local network. Imaging you have jvb running on a machine which has address from the local network and ports are forwarded so it can be used with a public address from Internet, when two participants try to use it from the local network they will probe that internal/private address, it will succeed and both clients will use just the private address to communicate with jvb in the local network.

OK, so the local address is not relevant to me at all, because the container is in a data center with hopefully no local users. Thanks for that explanation! Shall I just remove the line with the local address then?

About the Firefox P2P issue: Because of https://crbug.com/835767 (I guess) we can only test video with Chromium, but not audio. We use mainly Firefox 60.5.1esr for tests. Is this browser not recommended?

The recommended is chrome, it has and simulcast enabled and p2p. The bug you are referring to affect only one case when you are alone in the room and the first participant joins you may not hear the notification sound for a user joining, but after that all is fine.

Ah, then my Chromium bug link is wrong. In my case Chromium refused to use the microphone completely. I now just deleted all my chromium configs and now the error message is gone. Probably I messed it up long ago, when I last time tried Chromium.

Now it seems to work, indeed! I hope, that in the future Firefox will work again, too! But for the time being Chromium only is just fine!

Many thanks again for your extensive and successul help!

Not that Firefox does not work, it works, but it lacks some features right now. We will work on that while moving to plan-b …