I just did a new self hosted install on WSL Ubuntu 20.04. The install is behind a Linksys router. I followed the guide for the install. The only things to note was I changed the ports in the nginx configuration from port 80 and 443, and I didn’t use let’s encrypt.
All media connections work with 2 or more people (yes I realize P2P is for < 3 participants) . However, for the connection type, it appears its always going through the JVB on port 10000. P2P always fails. I do not have that problem when starting meetings from https://meet.jit.si/ , when using the same two peer computers.
I started to try to study the console logs on the clients and noticed when I used https://meet.jit.si/ , the STUN servers listed are three Google addresses, whereas the default install for Jitsi Meet included a jitsi.net address. So I changed my config.js to use those three same Google Stun servers instead, but that didn’t change anything.
I noticed when using https://meet.jit.si, that modules/xmpp/JingleSessionPC.js] <w.sendIceCandidates> includes an entry with my public IP address properly included (which you would expect for it to work), whereas my self hosted application does not - I only see my LAN IP address. I assume this is why the P2P can’t be established.
Did you deploy a TURN server? That is needed in order for P2P to work always. Otherwise it may only work in certain network conditions due to NAT. If you used our Debian packages, there is a jitsi-meet-turnserver package (IIRC) which you can use.
I’m just trying to get P2P to work. Is a Turn server really needed? Direct P2P in both directions where (Turn) isn’t used. It seems the jvb handles all my needs for participants > 2.
I tried to get coturn running following every piece of information I could find in the forums and doc. When I added the useStunTurn: true to my config.js, the main page was blank grey and failed to load any content.
It looks like my peers are trying to negotiate P2P mode based on the console log, but the candidates being generated for my install don’t match what I see when I visit meet.jit.si. Isn’t that a issue with Stun? Doesn’t it have to be talking to a stun server to be generating candidates? Why are there stun servers listed in the config.js, but when I look at chrome://webrtc-internals, the stun server is the one that seemingly comes from the prosody xmpp configuration anyway? Even when I don’t set useStunTurn?
Since these forums have seemingly become the larger source of documentation for Jitsi Meet over the formal documentation itself, I am going to report my findings here and still follow with the question I asked above.
P2P mode can work without a Turn server. Once I put a valid stun server in /etc/prosody/conf.avail/MYHOST.cfg.lua , my clients were able to negotiate direct P2P connections.
I was asking above because that is pretty confusing considering the config.js file seems to document the place were you can enter the stun servers, but these don’t seem to be used in any manner. Even when useStunTurn wasn’t set. I didn’t have a valid turn or turns server in MYHOST.cfg.lua file and P2P worked fine when the networks allowed it. If it fails, it falls back to the jvb, which is fine for me.
@Digital1955 I am finding myself in the same situation as you. Would you please share what exactly you added/updated in the /etc/prosody/conf.avail/MYHOST.cfg.lua config and whether or not you had to setup an STUN server and the details of that.
I am far from an expert here, so I am sure you might get other opinions regarding what is most secure / correct.
turncredentials = {
{ type = “stun”, host = “stun.l.google.com”, port = “19302” },
This is a public Google Stun server that seems OK. It’s fine for my usage. So no I don’t run my own Stun server.
The success rate at getting a constant P2P connection is a mysterious thing. Its normally about 85% successful for me. I can always rejoin the session a few times and get it to use P2P. I’d be interested in knowing how many attempts the Jitsi Meet code makes at negotiating P2P. Seems to me like it’s just once because I can frequently rejoin and get P2P to work when it fails.
Make sure P2P works most of the time when you use the meet.jit.si servers. This is about all I can add.
stopped videobridge (I want to only test p2p calls)
no TURN credential is configured in the XMPP server.
Coturn works well. I’ve tested here.
I disabled useStunTurn so that the client doesn’t try to fetch STUN server’s address and credential from the XMPP server and instead use hardcoded credentials in stunServers (Currently security is not a matter). I also stopped videobridge because it’s not needed for p2p calls. With the mentioned configuration, p2p calls don’t work. Although useStunTurn: false, the client still tries to fetch credentials from XMPP server. These are the logs in the client console: