Jitsi?


Recommended Posts

One issue I am having is that people can access a non secure version of the jitsi meet. i.e. meet.mydomain.com takes you to a http site. https://meet.mydomain.com is a secure site with the letsencrypt reverse proxy cert and that all works. I have letsencypt generating a top-level cert and a single sub domain cert as well. When I visit mydomain.com it takes you straight away to the https site basic "welcome to our site" page.

 

I have played around with my domain settings and no luck. I have my sub domain (meet) directly resolving to my IP and same with my top level domain. I am beginning to think this may be a jitsi setting that needs to forward people to the secure site.

 

Any help is appreciated.

 

I have set up following Space Invader to a T, I believe. Beyond the above everything is working and I had success with a few meetings. Thank you!

Link to comment

Try forwarding TCP port 5222 on your router to the unraid server internal address. May have to also map it for docker in unraid. For Jitsi you need ports 443 for https, 80 for http, UPD 10000, and TCP 5222. You can of course remap these to none standard points in your router as Unraid already uses 80 and 443. Here's a link to the jitsi documentation also. https://github.com/jitsi/jitsi-meet/blob/master/doc/manual-install.md

Link to comment
1 hour ago, dallus said:

I think I just fixed it. Mine was something with the cloudflare wildcard cert setup I did yesterday. Now I reverted back to google nameservers and I'll use letsencrypt to manage my certs and add subdomains if I add them. I couldn't even connect to my domain outside of the network so that's what led me down the DNS rabbit hole....

 

Now that you mention it, I was having that issue when I tested this morning. My wife's on her work laptop thru a VPN and it wouldn't show video. So she turned off the VPN and reconnected to the meeting and the video was there. I know that's of little to no help to you, but that's what I did to "fix" it. I'll try to replicate the issue and report back if I have any success.

Yeah my temp work around is to have my buddy VPN into my network, and when he does that we get video/audio.  However giving people the ability to VPN into my network....yeah I've got like one person I trust doing that.  So that work around isn't a suitable solution for me.  I reached out to @SpaceInvaderOne to see if maybe he could look at my system to spot whats wrong.  If he has the time and gives me a hand I'll share what he did and hopefully it helps.

 

Link to comment
27 minutes ago, Rooie said:

Yeah my temp work around is to have my buddy VPN into my network, and when he does that we get video/audio.  However giving people the ability to VPN into my network....yeah I've got like one person I trust doing that.  So that work around isn't a suitable solution for me.  I reached out to @SpaceInvaderOne to see if maybe he could look at my system to spot whats wrong.  If he has the time and gives me a hand I'll share what he did and hopefully it helps.

 

Hi @Rooie I just read your pm but thought would reply here first. Please can you check that you have port 10000/udp forwarded from your firewall/router to the ip of your unraid server. Without this port forwarded what you guys have reported happens.

Link to comment

Hi @SpaceInvaderOne,

 

Correct me if I wrong, but does video bridge need port 4443 forwarded to it?

 

image.thumb.png.0233eaed4877f8cee56a7339e2ff037f.png

 

https://github.com/jitsi/jitsi-meet/blob/master/doc/manual-install.md

 

Thank you again for all you do!

 

Edit: things seem to improve dramatically with multi-users and when switching from wifi to cellular once 4443 is forwarded to the server.

 

 

Edited by Michael Woodson
Link to comment
41 minutes ago, Michael Woodson said:

Hi @SpaceInvaderOne,

 

Correct me if I wrong, but does video bridge need port 4443 forwarded to it?

 

 

 

https://github.com/jitsi/jitsi-meet/blob/master/doc/manual-install.md

 

Thank you again for all you do!

 

Edit: things seem to improve dramatically with multi-users and when switching from wifi to cellular once 4443 is forwarded to the server.

 

 

I had both 10000 and 4443 forwarded and your post got me thinking. I tried not forwarding ports and found that if I forwarded 10000 but not 4443, the video worked. When I forwarded 4443 but not 10000, the video did not work. I could connect, but the video wouldn't work.

Link to comment
9 hours ago, Michael Woodson said:

One issue I am having is that people can access a non secure version of the jitsi meet. i.e. meet.mydomain.com takes you to a http site. https://meet.mydomain.com is a secure site with the letsencrypt reverse proxy cert and that all works. I have letsencypt generating a top-level cert and a single sub domain cert as well. When I visit mydomain.com it takes you straight away to the https site basic "welcome to our site" page.

 

I have played around with my domain settings and no luck. I have my sub domain (meet) directly resolving to my IP and same with my top level domain. I am beginning to think this may be a jitsi setting that needs to forward people to the secure site.

 

Any help is appreciated.

 

I have set up following Space Invader to a T, I believe. Beyond the above everything is working and I had success with a few meetings. Thank you!

It looks like I have resolved this issue by commenting out this line of the lets-encrypt jitsimeet.subdomain.conf config file. Now things only direct to https.

image.png.43549ed1ac7e80bd272a176421042462.png

Link to comment

OK - so currently having problems with the functionality of it even within my LAN. I installed it per spaceinvaderones instructions, I can go to the site and create a room.

 

But it never asks for authentication, it never asks for microphone or video use. So something functionally is wrong with my setup.

Link to comment
13 hours ago, Michael Woodson said:

It looks like I have resolved this issue by commenting out this line of the lets-encrypt jitsimeet.subdomain.conf config file. Now things only direct to https.

image.png.43549ed1ac7e80bd272a176421042462.png

Thanks yes i have changed the config file in the download now. Now is as follows

# make sure that your dns has a cname set for jitsi this file assumes the subdomain is meet.yourdomain.com

server {
	listen 443 ssl http2;
        listen [::]:443 ssl http2;
	server_name meet.*;
    include /config/nginx/ssl.conf;

	location / {
        # enable the next two lines for http auth
        # auth_basic "Ask for password from your organisation";
        # auth_basic_user_file /config/nginx/.htpasswd;


		ssi on;
		proxy_pass http://meet.jitsi;
		proxy_set_header X-Forwarded-For $remote_addr;
		proxy_set_header Host $http_host;
	}
	# BOSH
	location /http-bind {
		proxy_pass http://xmpp.meet.jitsi:5280/http-bind;
		proxy_set_header X-Forwarded-For $remote_addr;
		proxy_set_header Host $http_host;
	}

	# xmpp websockets
	location /xmpp-websocket {
		proxy_pass              http://xmpp.meet.jitsi:5280/xmpp-websocket;
		proxy_http_version      1.1;
		proxy_set_header        Upgrade $http_upgrade;
		proxy_set_header        Connection "upgrade";
		proxy_set_header        Host $host;
		tcp_nodelay             on;
	}
}

 

  • Like 1
Link to comment
3 hours ago, tknx said:

OK - so currently having problems with the functionality of it even within my LAN. I installed it per spaceinvaderones instructions, I can go to the site and create a room.

 

But it never asks for authentication, it never asks for microphone or video use. So something functionally is wrong with my setup.

I've had people complain of this as well. In fact, had someone who could not get their video to work even after trying to force the permissions on within the browser (the latest version of chrome). Others in the same meeting had no issues.

Link to comment

Hey so I continue to have problems getting things setup past the letsencrypt part.   I think I have narrowed it down a bit... 

 

I have noticed that in Portainer,  after I add the proxy network to each of the 4 jitsi dockers. . The dockers at times appear to be dropping the IP address.. (IE they randomly appear to be going in and out on the stack page. and also within the docker its self.  I feel this may be leading to the Letsencypt being unable to identify the upstream meet.jitsi as it tried to authenticate...  

 

Any thoughts as to how to trouble shoot this further.  Thanks all:) :)

 

I copy the error I get in Letsencrypt  here :

nginx: [emerg] host not found in upstream "xmpp.meet.jitsi" in /config/nginx/proxy-confs/jitsimeet.subdomain.conf:23
nginx: [warn] could not build optimal proxy_headers_hash, you should increase either proxy_headers_hash_max_size: 512 or proxy_headers_hash_bucket_size: 64; ignoring proxy_headers_hash_bucket_size

Link to comment

So I have lots of weirdness going on. No request for authentification. I can't get the mic to work in the chat since I am set to muted/no video and can't unset it. But when I click on the little arrow, I can see the meter go up and down when I talk and I can see a preview video.

 

...And I get thrown off a bunch. 

 

I suspect it has to to do with my reverse proxy and https issues since WebRTC won't work without it. What sucks is I don't think there is a way to test WebRTC without https just to make sure.

Link to comment
3 hours ago, tknx said:

So I have lots of weirdness going on. No request for authentification. I can't get the mic to work in the chat since I am set to muted/no video and can't unset it. But when I click on the little arrow, I can see the meter go up and down when I talk and I can see a preview video.

 

...And I get thrown off a bunch. 

 

I suspect it has to to do with my reverse proxy and https issues since WebRTC won't work without it. What sucks is I don't think there is a way to test WebRTC without https just to make sure.

 

I had similar issues but it was due to browser permissions. I've since switched to Jitsi apps and haven't had any issues since.

  

On 4/24/2020 at 12:11 AM, Michael Woodson said:

It looks like I have resolved this issue by commenting out this line of the lets-encrypt jitsimeet.subdomain.conf config file. Now things only direct to https.

image.png.43549ed1ac7e80bd272a176421042462.png

 

Did you managed to figure out a way to redirect visitors from the "meet.domain.com" to "https://meet.domain.com/"? Doesn't work automatically for me.

Edited by Katherine
Link to comment
8 hours ago, Katherine said:

 

I had similar issues but it was due to browser permissions. I've since switched to Jitsi apps and haven't had any issues since.

  

 

Did you managed to figure out a way to redirect visitors from the "meet.domain.com" to "https://meet.domain.com/"? Doesn't work automatically for me.

I had a flawless 5 person meeting last night after removing the listen 80 from the above letsencrypt.conf file. Things really start to breakdown if connections are allowed through non-https, so this is critical.

 

I am using Google domains (private domain) and forwarding directly my IP to that meet.* private domain. Now users are only taken to the https site.

 

Additionally, I only have the 3 ports open which spaceinvader recommended. Not port 4443 as I spoke of earlier, 4443 is not a part of the quick install guide. https://github.com/jitsi/jitsi-meet/blob/master/doc/quick-install.md

Link to comment

Anyone know how to make sure the video quality stays good? We use mainly the app for video, 2 people look great. when we add a 3rd person the quaily drops a decent amount. I know 2 person can be peer to peer. 3 people doesn't really tax the server or network at all. It works just fine, but would be nice to keep quality up as good as we can.

 

thanks

Link to comment

Alright, so I have this almost working... It's been a bit of a pain, and recreating everything - fixing my own mistakes, etc... 
Thank you so far with everyone's support on previous posts. I feel that I have only one problem left.... 

I can now reach my jitsi server online through https://meet.mydomain.ca, however when I connect to it and create a meeting, the page turns to an error message which states: Unfortunately, something went wrong. We're trying to fix this. Reconnecting in X sec... " 

This counts down, and attempts to reconnect. 

 

So I do not get a prompt for authentication. And my meeting won't start.... 

 

Has anyone experienced this and knows where to resolve this problem? 

Link to comment
On 4/22/2020 at 8:28 AM, NLDer said:

I use Chrome.... 

I checked those settings and I am unable to change them. The Camera and Mic are both blocked, and grayed out? Odd, I am an admin on that system with full privileges. 

For any others who encounter the issue of camera/mic options greyed out on Chrome when accessing via local IP address (e.g. 192.168.1.XXX:8000) , I found this page that cleared it up for me. Essentially, it's a default behavior of Chrome to disallow camera/mic to any non-https site except specifically 'localhost'. So, I had to whitelist my server's ip address (port included) to get it to behave as we'd expect.

 

https://medium.com/@Carmichaelize/enabling-the-microphone-camera-in-chrome-for-local-unsecure-origins-9c90c3149339

 

Also, just to add my 2 cents to the mix, I got Jitsi working thanks to SpaceInvader's awesome guide (Thank you!) and it seems to be working as advertised.

 

Ports forwarded:

  • 80 to LetsEncrypt (Already had LetsEncrypt setup also based on SpaceInvader's guide.)
  • 443 to LetsEncrypt (Already had LetsEncrypt setup also based on SpaceInvader's guide.)
  • 10000/UDP to Unraid IP

 

Some observations of what I encountered that may/may not help others during their own troubleshooting:

  • Chrome really likes to cache web pages so it's a PITA trying to get it to realize I changed something and that it should really, REALLY reload the page. I ended up using multiple browsers, devices, and a lot of patience to deal with that. 

 

  • Before I had realized I needed to forward 10000/UDP, I was able to connect to Jitsi both locally and via the subdomain using my local PC, but it was even odds if it asked me for auth to create a room or if it just let me do it. During this period, though, I could also connect to Jitsi using the app on my phone (using cellular, not wifi) via the subdomain but was unable to join or create any rooms (network reconnecting error or infinite circle of loading). Fixing the 10000/UDP fixed both issues for me.

 

  • Once it was all set up and working, to test it I connected via my pc, then connected via my phone app over cellular, and it worked great. However, changing nothing except moving the phone to wifi made the phone unable to join the meeting. I suspect some kind of collision with two different instances of jitsi from the same network vying for the same port/resource but wiser folks than me would probably know. Doesn't really impact my use-case though so it's just notable if you're using this type of setup for troubleshooting.

 

  • It seemed to take a few restarts of Jitsi and LetsEncrypt before everything started to play nicely. I suspect there's an appropriate order they should start in so that updates are flowed down the daisy chain and it just took a few cycles for those to populate, but this is just a gut feel.

 

  • Jitsi seems a bit...fragile? Particularly when using its screensharing (couldn't get youtube sharing to work at all but that's a total non-issue). It shares perfectly fine, but when disengaging the share it would more often than not cause some type of graphical issue (e.g. full black screen, window all black but hover still shows buttons exist, tessellated triangles of white all over the screen in a fractal pattern) unless I was a little careful about how I went about it (e.g. no quick successive actions. Just single, deliberate, measured clicks). I could get back on track by closing that window of chrome, going to my history, re-opening the recently closed window, and it put me right back into the meeting good-as-new. So it was annoying but survivable.

 

Edited by KMoney00
Formatting
Link to comment
12 hours ago, NLDer said:

Alright, so I have this almost working... It's been a bit of a pain, and recreating everything - fixing my own mistakes, etc... 
Thank you so far with everyone's support on previous posts. I feel that I have only one problem left.... 

I can now reach my jitsi server online through https://meet.mydomain.ca, however when I connect to it and create a meeting, the page turns to an error message which states: Unfortunately, something went wrong. We're trying to fix this. Reconnecting in X sec... " 

This counts down, and attempts to reconnect. 

 

So I do not get a prompt for authentication. And my meeting won't start.... 

 

Has anyone experienced this and knows where to resolve this problem? 

Well... seems there's more trouble in paradise.... In attempting to make this work, I figured I could play around with some other containers to see if I could get it to work externally with letsencrypts, etc. 

Since I have a wildcard, and validate by DNS, I figure I'd use Radarr and Sonarr to test with. Realizing I missed a step - changing the network to the proxynet - as per spaceninvaderone's labeling - however, as he shows in his video, one is supposed to still be able to access the page on the original local network/port number. This does not work for me, at all. Nor is external access available... 

I have double checked the docker settings and they are configured as per the video. 

 

I know this is straying from Jitsi - and I have looked around, but can't find anything. Hoping  someone may have a rabbit up their sleeve on this one. Maybe it will make other problems clear for my Jitsi issues I am having. As it stands now, nothing is really accessible through the LetsEncrypt configs. (And yes, I have updated the conf files for the subdomains needed for Radarr and Sonarr. 

Link to comment
On 4/24/2020 at 7:23 PM, SpaceInvaderOne said:

Thanks yes i have changed the config file in the download now. Now is as follows


# make sure that your dns has a cname set for jitsi this file assumes the subdomain is meet.yourdomain.com

server {
	listen 443 ssl http2;
        listen [::]:443 ssl http2;
	server_name meet.*;
    include /config/nginx/ssl.conf;

	location / {
        # enable the next two lines for http auth
        # auth_basic "Ask for password from your organisation";
        # auth_basic_user_file /config/nginx/.htpasswd;


		ssi on;
		proxy_pass http://meet.jitsi;
		proxy_set_header X-Forwarded-For $remote_addr;
		proxy_set_header Host $http_host;
	}
	# BOSH
	location /http-bind {
		proxy_pass http://xmpp.meet.jitsi:5280/http-bind;
		proxy_set_header X-Forwarded-For $remote_addr;
		proxy_set_header Host $http_host;
	}

	# xmpp websockets
	location /xmpp-websocket {
		proxy_pass              http://xmpp.meet.jitsi:5280/xmpp-websocket;
		proxy_http_version      1.1;
		proxy_set_header        Upgrade $http_upgrade;
		proxy_set_header        Connection "upgrade";
		proxy_set_header        Host $host;
		tcp_nodelay             on;
	}
}

 

Hi Spaceinvader

 

So to confirm with this new config do you have to port forward both 10000 and 4443 ports?

 

because I just tested with My PC hosting a meeting and then using my mobile to connect as a client...

 

Phone on Wifi can connect with video

Phone on cellular can connect but no video is show for either person in the meeting (Each can see themselves)

Link to comment

ok so just tested forwarding port 4443 and that indeed does need to be forwarded to be able to allow access for external clients.

 

is there a way you would not have to forward this port? it was not in spaceinvaders video unless I missed that part.

 

p.s any guide on how to update the containers?

Edited by enigma27
Link to comment
On 4/24/2020 at 10:24 PM, Aceriz said:

Hey so I continue to have problems getting things setup past the letsencrypt part.   I think I have narrowed it down a bit... 

 

I have noticed that in Portainer,  after I add the proxy network to each of the 4 jitsi dockers. . The dockers at times appear to be dropping the IP address.. (IE they randomly appear to be going in and out on the stack page. and also within the docker its self.  I feel this may be leading to the Letsencypt being unable to identify the upstream meet.jitsi as it tried to authenticate...  

 

Any thoughts as to how to trouble shoot this further.  Thanks all:) :)

 

I copy the error I get in Letsencrypt  here :

nginx: [emerg] host not found in upstream "xmpp.meet.jitsi" in /config/nginx/proxy-confs/jitsimeet.subdomain.conf:23
nginx: [warn] could not build optimal proxy_headers_hash, you should increase either proxy_headers_hash_max_size: 512 or proxy_headers_hash_bucket_size: 64; ignoring proxy_headers_hash_bucket_size

So I continue to have ongoing issue. In troubleshooting this. I have a question for the community. 

 Are there any recommendations against having 2 separate user defined networks with  two different installs of Letsencypt.  One on each of these networks.  ie like a proxynet 1, and proxynet 2.. 

 

I ask as I already have a letsencypt setup working with things like nextcloud, emby, open office etc.  

 

And to troubleshoot the issue with Jitsi thinking of setting it up on it own letsencypt..With essentially nothing else. 

 

Unless others have thoughts on why the IP keep dropping.  If you need logs or things please let me know I am happy to provide:) 

Link to comment

Anyone else seeing the video.meet.jitsi docker using more and more RAM while it is idle?

 

I installed using @SpaceInvaderOne youtube tutorial. Thankyou!

 

Everything appears to be working correctly. I have forwarded the correct ports including UDP 10000. I can access Jitsi from my letsencrypt subdomain and i'm able to host meetings.

 

I restarted Jitsi from Portainer yesterday by this morning video.meet.jitsi was using 3GB of RAM. I restarted it four hours ago and the RAM has already risen to 1.04GB. All of this has happened with no calls or video meets.

 

Log for video.meet.jitsi

Apr 28, 2020 1:50:46 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: Performed a successful health check in 2ms. Sticky failure: false
Apr 28, 2020 1:50:50 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: Running expire()
Apr 28, 2020 1:50:56 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: create_conf, id=da5ba21b2fd0ab2a gid=null logging=false
Apr 28, 2020 1:50:56 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: Performed a successful health check in 2ms. Sticky failure: false
Apr 28, 2020 1:51:06 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: create_conf, id=adf53a44c98d816f gid=null logging=false
Apr 28, 2020 1:51:06 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: Performed a successful health check in 2ms. Sticky failure: false
Apr 28, 2020 1:51:16 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: create_conf, id=eb771cc1e4f11232 gid=null logging=false
Apr 28, 2020 1:51:16 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: Performed a successful health check in 2ms. Sticky failure: false
Apr 28, 2020 1:51:26 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: create_conf, id=be447f7dff3339ad gid=null logging=false
Apr 28, 2020 1:51:26 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: Performed a successful health check in 2ms. Sticky failure: false
Apr 28, 2020 1:51:36 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: create_conf, id=fbcca0c754e72b8f gid=null logging=false
Apr 28, 2020 1:51:36 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: Performed a successful health check in 2ms. Sticky failure: false
Apr 28, 2020 1:51:46 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: create_conf, id=6be89e8d7d38cc22 gid=null logging=false
Apr 28, 2020 1:51:46 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: Performed a successful health check in 2ms. Sticky failure: false
Apr 28, 2020 1:51:50 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: Running expire()
Apr 28, 2020 1:51:56 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: create_conf, id=92e30cc88b43f7b0 gid=null logging=false
Apr 28, 2020 1:51:56 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: Performed a successful health check in 2ms. Sticky failure: false
Apr 28, 2020 1:52:06 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: create_conf, id=b4bdff39698e5c22 gid=null logging=false
Apr 28, 2020 1:52:06 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: Performed a successful health check in 2ms. Sticky failure: false
Apr 28, 2020 1:52:16 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: create_conf, id=61637a55c912c8ea gid=null logging=false
Apr 28, 2020 1:52:16 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: Performed a successful health check in 3ms. Sticky failure: false
Apr 28, 2020 1:52:26 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: create_conf, id=93b77f7dead71923 gid=null logging=false
Apr 28, 2020 1:52:26 PM org.jitsi.utils.logging2.LoggerImpl log
INFO: Performed a successful health check in 2ms. Sticky failure: false

I'm hoping that someone has some ideas for taming the RAM consumption.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.