Participants can't share screen or video

[smg8fe]

This Issue tracker is only for reporting bugs and tracking code related issues.

Before posting, please make sure you check community.jitsi.org to see if the same or similar bugs have already been discussed. General questions, installation help, and feature requests can also be posted to community.jitsi.org.

Description

---

We set up a new Jitsi on premise. Unfortunately we have some trouble sharing video and screens.

Current behavior

---

We have tried the same three people on meet.jit.si as on our own instance. While video worked on the official server, no such luck on ours. There everybody could see their own screen.

Expected Behavior

---

Participants should see each other's screens and video.

Environment details

---

Most current docker images on Kubernetes.

jitsi-jicofo-574f56fff7-tgckv.log jitsi-jvb-7859cc8c7d-rjs22.log jitsi-prosody-7dfc4bcc98-gjs9q.log jitsi-web-74b587d456-wt5bp.log

[saghul]

Does it work for 2 participants and when a 3rd one joins nobody can see or hear anyone?

[smg8fe]

We just tried and participants only see "black" when the other person starts sharing.

[ChristineBoersen]

This won't solve your problem but will make your debugging more consistent, and able to debug with 2 through n users and have them behave the same way. This is why saghul asked the question he did about how many participants. (Kinda wish they would add this to troubleshooting steps in the official docs)

Set

p2p: { enabled: false}

in the /etc/jitsi/meet/yourserver-config.js (where yourserver is what you entered when setting up jitsi-meet typically).

[smg8fe]

Hi, we are using the docker containers (https://github.com/jitsi/docker-jitsi-meet) and apparently can't set this option. I have no problem getting three ppl together for testing though. Best Regards.

[saghul]

I'm not 100% sure I get the full picture, please answer these:

• does video work for 2 participants?

• does screen-sharing work 2 participants?

• does video work when a 3rd participant enters?

• does screen-sharing work when a 3rd participant joins?

[smg8fe]

No to all four questions.

I have no problem getting three ppl together for testing though.

That statement wasn't implying screensharing works, but plainly that I have some 20 possible guinea pigs I can ask anytime we want to try out something :)

[saghul]

No to all four questions.

😨 Oops. What browsers / devices are you testing?

[smg8fe]

We have tried Macbooks as well as Linux laptops with both Firefox and Chrome. Did you spot anything suspicious in the logs I uploaded above?

[saghul]

Your videobridge doesn't seem to be running. This is the error printed in the JS logs: CONFERENCE FAILED: conference.videobridgeNotAvailable

It's either not running or in a broken state.

[smg8fe]

I have attached the jvb logs from the same time frame and as far as I can tell it's running.

[saghul]

If you are using the brewery mode (as our Docker images do) it's possible the problem is in the prosody side. I see a bunch of errors there, due to missing certificates.

[smg8fe]

Is that an error I can fix or is something missing from the docker files?

[saghul]

Those files are created at boot time by the init script: https://github.com/jitsi/docker-jitsi-meet/blob/master/prosody/rootfs/etc/cont-init.d/10-config so maybe the permissions on your CONFIG volume are not correct?

[smg8fe]

Actually I have no volume mounted there. It definitely did something in /config:

root@jitsi-prosody-7dfc4bcc98-2fb5p:/# find /config  
/config  
/config/prosody.cfg.lua  
/config/conf.d  
/config/conf.d/jitsi-meet.cfg.lua  
/config/data  
/config/data/prosody.pid  
/config/data/auth%2emeet%2ejitsi  
/config/data/auth%2emeet%2ejitsi/accounts  
/config/data/auth%2emeet%2ejitsi/accounts/jvb.dat  
/config/data/auth%2emeet%2ejitsi/accounts/focus.dat  
/config/data/auth%2emeet%2ejitsi/offline  
/config/certs

In the logs the script also executed without output:

[cont-init.d] 10-config: executing...   
[cont-init.d] 10-config: exited 0.

When I execute the certificate generate command manually, I get:

root@jitsi-prosody-7dfc4bcc98-2fb5p:/# echo | prosodyctl --config $PROSODY_CFG cert generate $XMPP_DOMAIN  
The directory /config/data is not owned by the current user, won't be able to write files to it  
root@jitsi-prosody-7dfc4bcc98-2fb5p:/# ls -l /config  
total 20  
drwxr-xr-x 2 root root 4096 May 17 10:40 certs  
drwxr-xr-x 2 root root 4096 May 17 10:40 conf.d  
drwxrwxrwx 3 root root 4096 May 17 10:40 data  
-rw-r--r-- 1 root root 6280 May 17 10:40 prosody.cfg.lua

Strangely enough the folder is set up with 777 as the 10-config script specified as well as both being owned by root :/

[smg8fe]

I see there was a certificate ticket a while ago: https://github.com/jitsi/docker-jitsi-meet/issues/88 From what I gather in that ticket the solution was to use custom-built docker images. While the symptoms only affected Jigasi, some of the error messages match my logs. What's your take on this?

[saghul]

What are the permissions of the directory you are passing as CONFIG ?

[smg8fe]

I copied this from the default file (CONFIG: ~/.jitsi-meet-cfg). The folder doesn't exist anywhere inside the container though:

root@jitsi-prosody-7dfc4bcc98-2fb5p:/# find -name .jitsi-meet-cfg
find: './proc/210/map_files': Permission denied
root@jitsi-prosody-7dfc4bcc98-2fb5p:/# 

I can leave out the variable or replace it with /config, whatever makes more sense :)

[saghul]

I mean on the host system, not inside the container.

[smg8fe]

There is no volume mounted in the container. Hence there are no permissions on the host system as far as I can see.

[saghul]

I'm not sure what you are doing there, so I'm not sure how to help you, sorry. I see you are using Kubernetes, which I have no experience with.

[smg8fe]

Does Prosody need a volume mounted there? I can configure one, if that's the case. Based on the docs I would just assumed it would regenerate the contents of that folder on startup. I also looked at the semi-official helm chart and don't see a volume mounted there: https://github.com/jitsi/docker-jitsi-meet/blob/k8s-helm/k8s/jvb-deployment.yaml

[saghul]

I think I know now. This was fixed some time ago, but hasn't made it onto a release yet: https://github.com/jitsi/docker-jitsi-meet/blob/dev/prosody/rootfs/etc/cont-init.d/10-config#L20

You can build the images from the dev branch and test it out.

[smg8fe]

Before I deploy some unreleased code, can you please answer the following questions:

1. Is the chown the only change relevant for my issue?
2. Can I update Prosody separately from the other images?
3. When is the next release planned?

For now, I have replaced only prosody and still experience the same sympttoms. Prosody's log however appears to be error free now. jitsi-jicofo-574f56fff7-hqcps.log jitsi-jvb-7859cc8c7d-r7g2b.log jitsi-prosody-7fb9fd69d8-vhr8b.log jitsi-web-74b587d456-cr489.log

[saghul]

1. Is the chown the only change relevant for my issue?

Yes.

2\. Can I update Prosody separately from the other images?

Yes.

3\. When is the next release planned?

Soon. I was planning this week, but may not have the time.

For now, I have replaced only prosody and still experience the same sympttoms. Prosody's log however appears to be error free now.

I see errors in Jicofo. There is an error (which is fixed on our latest not-yet-released version) which prevents Jicofo from reconnecting when Prosody is restarted. Same applies to the JVB. If you restart Jicofo and JVB it should start working.

[smg8fe]

I have restarted jvb and jicofo in that order. Do you have a hierarchy in which we should start the containers? We can implement it as a stop-gap measure with sleep commands for now. Anyhow, I still can't get sharing to work. jitsi-jicofo-574f56fff7-w4fvx.log jitsi-jvb-7859cc8c7d-cglwv.log jitsi-prosody-7fb9fd69d8-vhr8b.log

[saghul]

It's still the same problem:

Jicofo 2019-05-22 09:34:14.720 SEVERE: [21] org.jitsi.jicofo.xmpp.BaseBrewery.start().196 Failed to create room: jvbbrewery@internal-muc.meet.jitsi
net.java.sip.communicator.service.protocol.OperationFailedException: Failed to join the room

Try to start the contsiners in this order: prosody, then jicofo, then jvb.

[smg8fe]

That helped! We finally got people to share video :) Unfortunately screen sharing didn't work quite yet. The sharer could see their own screen but the others only got the avatar. jitsi-jvb-7859cc8c7d-6dg9v.log jitsi-prosody-7fb9fd69d8-txr4l.log jitsi-jicofo-574f56fff7-r2c6n.log

[saghul]

Works for me here.

[smg8fe]

I believe it may have been our room foo, that was created while jitsi was malfunctioning. With new rooms everything seems to work. We do have one more question about connectivity: some of our colleagues are using a corporate proxy that only allows HTTP(S) traffic. Is there a way to get make the video bridge usable for them?

[saghul]

I believe it may have been our room foo, that was created while jitsi was malfunctioning. With new rooms everything seems to work.

Glad to hear! I'm, closing this issue then.

We do have one more question about connectivity: some of our colleagues are using a corporate proxy that only allows HTTP(S) traffic. Is there a way to get make the video bridge usable for them?

You could run the bridge with the ssltcp harvester on port 443: https://github.com/jitsi/jitsi-videobridge/blob/master/doc/tcp.md but know that the video quality will be poorer.

[smg8fe]

Actually I have enabled both TCP and UDP at the moment. Will the bridge pick TCP by default then? Also my question was not exactly about TCP, but HTTP. Anything else is filtered by the network :(

[saghul]

In that case I think you are out of luck.

[smg8fe]

What about the TCP/UDP topic? I have configured atm: JVB_PORT: "10000" JVB_TCP_HARVESTER_DISABLED: "false" JVB_TCP_PORT: "4443"

so both ports should be listening. I saw TCP was selected in our calls, which is according to you the worse choice. Is it then recommended to disable TCP?

[saghul]

Not necessarily. Keep it available for trickly clients. If you know beforehand that the entire organization will not be able to use UDP, then I'd suggest trying to persuade IT to allow the it towrds the bridge, otherwise the experience will suffer.