Prosody source installation not recognized by jitsi-meet installer

I was successfully installing jitsi-meet on a Jetson Nano. Later I recognized, that my Prosody version is 0.10. There was no way to install the required 0.11 on Nano’s Ubuntu 18.04 the “apt” way, so I installed it manually from source.

Unfortunately there was another problem now: Since the former jitsi installation did adapt to the previously found 0.10 I was unable to turn it to use 0.11 w/o problem. The webservice call for room registration failed with 502 now.

So I decided to stick with the 0.11 manual installation and purge jitsi in order to re-install it.

But it seems, the jitsi installer is unable to recognize a manually installed 0.11, because it failed like so:

dpkg: error processing package jitsi-meet-prosody (--configure):
 installed jitsi-meet-prosody package post-installation script subprocess returned error exit status 1
Setting up jicofo (1.0-786-1) ...
Updating /etc/jitsi/jicofo/config to use jicofo.conf
Generating an empty jicofo.conf file
useradd: warning: the home directory already exists.
Not copying any file from skel directory into it.
dpkg: dependency problems prevent configuration of jitsi-meet:
 jitsi-meet depends on jitsi-meet-prosody (= 1.0.5211-1); however:
  Package jitsi-meet-prosody is not configured yet.

dpkg: error processing package jitsi-meet (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of jitsi-meet-turnserver:
 jitsi-meet-turnserver depends on jitsi-meet-prosody; however:
  Package jitsi-meet-prosody is not configured yet.

dpkg: error processing package jitsi-meet-turnserver (--configure):
 dependency problems - leaving unconfigured
No apport report written because the error message indicates its a followup error from a previous failure.
                                                                                                          No apport report written because the error message indicates its a followup error from a previous failure.
                                                              Processing triggers for systemd (237-3ubuntu10.51) ...
Errors were encountered while processing:
 jitsi-meet-prosody
 jitsi-meet
 jitsi-meet-turnserver
E: Sub-process /usr/bin/dpkg returned an error code (1)

What can I do now to make this work?

Seems to become a PITA. I will start from a fresh system. No chance to repair that as it seems.

you may consider to use Ubuntu 20.04 - I did not check with a Jetson nano, but on a Raspberry Pi 3 you can have Prosody 11.4 on 20.04 LTS without mucking around with your packages (not counting Jitsi-meet itself of course)

Oh, cool. Thanks for the hint. Ubuntu 20.04 on Jetson Nano is currently not the main stream, but I still have a RPI 3, just hesitated to install 20.04 on it. Will give it a try. Which distro did you use for it?

Disregard, please. Have it

OK, finally…

Having it now on a PI 3A+ Ubuntu 20.04. I had some network problems (not related to jitsi), mostly due to a hanging systemd.resolved.service, which where gone after I assigned a static IP and put the box into the DMZ.

Installation (even non-standard on port 8443) was unproblematic. The box seems a bit sluggish now sometimes, the green LED is on for a long time and SSH is hanging. But in general it seems to work fine.

I would like to ask you a question regarding the ports which will be negotiated via TURN, for instance this one:

2021-08-27T14:20:14.735Z [modules/xmpp/JingleSessionPC.js] <I.sendIceCandidates>: JingleSessionPC[session=P2P,initiator=true,sid=8f60b6739b44] sendIceCandidates [{"candidate":"candidate:1258458217 1 udp 41885439 192.168.190.25 55114 typ relay raddr 80.133.188.133 rport 57972 generation 0 ufrag nPND network-id 1 network-cost 10","sdpMid":"0","sdpMLineIndex":0}]

I mean 57972. Wondering how this will work with my firewall, which is not open for this port. Could you please elaborate?

EDIT: Tested it right now with an LTE based iPhone. And as expected: Even though relay candidates are exchanged, the video is not flowing (which is OK for me).

What do I miss? I mean if the TURN server runs on the same machine as the jitsi-meet then I would expect to have at least an UDP and TCP port range open on the firewall (and forwarded to the box), or what do I miss here?

Since this connection is created by an internal request, the firewall doesn’t care it.

Hmm. No, this was not taken from an internal connection. The connection was between a PC hanging behind a private Wifi network behind a DSL router. The other side was an iPhone running the Jitsi app in an LTE network. There is no way to do P2P w/o the help of TURN. Now - they exchange ports, which are not open, and finally the experiment I made confirmed my idea of that: Connectivity OK, Video NO

EDIT: Connectivity means Signaling

EDIT2: It is not necessarily so, that a device in an LTE network MUST have TURN. If there is no symmetric NATting, there is no need for TURN. But in my case it is.

EDIT3: I’m not sure anymore, from what connection this trace has been shot. It doesn’t matter. The question is: How do you want to ensure, that - once both parties MUST agree to use the relay candidate - the connection can be established, if the TURN device is behind a firewall, which is not open for the advertised port(s)?

EDIT4: I’m just simply missing the advice to open this or that UDP/TCP port range in case the entire installation is behind a firewall… :slight_smile:

Search for “what is STUN

Hey, come on…You are completely missing my point. I told you, that the iPhone is behind symmetric NAT. There is no STUN which could reliably solve this. TURN is needed. And the TURN server is behind a firewall which is closed.

@gpatel-fr I finally landed again on the Jetson Nano, this time with a custom made XUbuntu 20.04. This was by far the smoothest installation, I can only recommend that. My experiences with the various mini PCs here in a couple of lines:

  1. Jetson Nano with original Nvidia Ubuntu 18.04 image: Internal TURN doesn’t work since the latest Prosody version for this platform is 0.10. I was not able to make Jitsi run with a source installation of 0.11. Not a recommended couple

  2. Raspberry PI 3A+, Ubuntu 20.04: Internal TURN was working, but problems with the network, because there is no internal ETH, just a USB device, which made troubles. I abandoned this because the whole device became sluggish, non-responsive and stuck after a while for unknown reason. The low memory (500MB) requires the setup of a swap partition, otherwise not even the installation goes through. IMHO the least capable platform. I suppose the 3B+ is way better, because of the bigger mem.

  3. Custom made Xubuntu 20.04 for Nvidia Jetson Nano. Very, very nice work of a guy in the Nvidia forum Xubuntu 20.04 Focal Fossa L4T R32.3.1 - Custom Image for the Jetson Nano - Jetson Nano - NVIDIA Developer Forums. Very fast, responsive, very nice installation experience, even though I was not using the default installation, but installed it to port 8443 and came with my own certbot managed Lets Encrypt Cert. My favourite.

Now I just need to understand what I wrote above: I did not find instructions what port ranges to open for the TURN functions. AFAIK you are using COTURN, there should be a configurable range.

At least with the default installation behind NAT and the firewall configuration as documented it does not work for the “20% of WebRTC connections, which are not happy with STUN”. Maybe somebody who knows could elaborate.

I have no experience with Jitsi-meet behind a home firewall. I have a nasty habit of disabling P2P on Jitsi-meet to not have to deal with it anyway.
In my worse nightmare I’d not think about setting up a Jitsi-meet behind a home firewall and having to connect phones though internal wifi, PCs though the internal network, PC on the internet, phones on 4G, all this with P2P. Ionos, OVH, Scaleway have their problems but nothing that can justify dealing with that :slight_smile:

FWIW I think that @emrah is right, it’s the firewall job to open the necessary ports and sometimes firewall open too many ports, sometimes not enough. I’d not trust these damn things beyond the most simple uses.

I have no experience with Jitsi-meet behind a home firewall. I have a nasty habit of disabling P2P on Jitsi-meet to not have to deal with it anyway.

In my worse nightmare I’d not think about setting up a Jitsi-meet behind a home firewall and having to connect phones though internal wifi, PCs though the internal network, PC on the internet, phones on 4G, all this with P2P. Ionos, OVH, Scaleway have their problems but nothing that can justify dealing with that :slight_smile:

Naah, that is not an impossible thing. Look, I could expose my entire box to the internet and it would work.

FWIW I think that @emrah is right, it’s the firewall job to open the necessary ports and sometimes firewall open too many ports, sometimes not enough. I’d not trust these damn things beyond the most simple us

No, that is not true. Look. Let’s recap the task of TURN: It jumps in, if both party cannot find connectivity using STUN or are in the same network so that they would be fine with “host” addresses.

Symmetric NAT is a definite show stopper for STUN, since the assignment of the ports is not constant.

Now TURN comes it, that is what TURN is for: Provide an additional hop, which just manages between both parties. It is assumed, that both parties can reach the TURN control ports 3478 and the other TLS port in order to get a “relay” candidate, which consist of a public IP and a PORT.

If the “outer” party is now using this address:port and if the traffic from the outer party, which receives a relay candidate is blocked by the firewall, there is NO WAY to communicate. This is the same as if you would be in a corporate network and would be fine with STUN, but they are blocking all incoming UDP. If the firewall of the instance on which the TURN server is running is not open for a specific range of ports (can be just a hand full, but need to be configured to COTURN), then there is end of lane. The things getting more complicated, if there is an additional firewall and a port forwarding device, because the traffic from outside on the TURN port pool needs to be forwarded to the inside.

COTURN has a setting for this:

# Lower and upper bounds of the UDP relay endpoints:
# (default values are 49152 and 65535)
#
#min-port=49152
#max-port=65535

This is an unnecessarily wide open range, but the default. These ports have to be open on firewalls in front of TURN.

Please refer also to other sources on the net, for instance here:

For example, if a Janus gateway is used too, the TURN server is in the same server as the Janus gateway and both are behind a firewall (not recommended), relay candidates could have the public IP address of the server while peer reflexive candidates could have the internal one. If the firewall drops connections between the public IP address and the public IP address the connection between coTURN and Janus may not be established (but without failing either), which would cause that Firefox establishes a connection with the TURN server, but the TURN server does not send or receive any packet to or from Janus. In Chromium, on the other hand, the connection would work as it would use the internal IP address of the server from the peer reflexive candidate

https://nextcloud-talk.readthedocs.io/en/latest/TURN/

I think your documentation should reflect that. You don’t explicitly forbid installations behind firewalls.

Also have a look here: Setting up firewall for TURN server - #9 by Dorin111 - 💬 Talk (spreed) - Nextcloud community

They are opening the entire UDP range per RFC…

Anyway, I think I will find the COTURN setup, pick 4 ports (don’t need more), open the UFW for it incoming and establish a port forwarding from my router to the box in the DMZ and you will see: I will be able to connect my iPhone via LTE with the inner PC happy with STUN :slight_smile:

Is there a way to disable the internal TURN server by configuration and use the statically configured TURN instead? The one which can be entered in p2p.stunServers?

Found it. Configured my TURN server to /etc/prosody/conf.avail/jitsi-meet.ddns.net.cfg.lua in the “external_services” section and commented all internal stuff.

At least now I’m having a working TURN server in a P2P connection. I have the suspecion, that we understand different things under the term “TURN”.