Can't get jitsi-meet to work with TURN (solved)

Wow, thank you for the incredibly fast reply!

So, I have now tried the following:

Blocked UDP port 10000 (incoming) from my home IP, but allowed for everything else:

root@bender:~# ufw status
Status: active

To                         Action      From
--                         ------      ----
5349                       ALLOW       Anywhere
10000                      REJECT      55.66.77.88
10000                      ALLOW       Anywhere

(Note: shortened to relevant ports, anonymized IP)

And then set up a conference using

  1. A local browser (using the blocked public IP)
  2. Another browser running in virtual machine, connected to a VPN
  3. My cellphone using the jitsi-meet app

From a server point of view, these clients all connect from different IPs.

The result is that:

  1. The browser on the blocked IP doesn’t get or send any audio or video
  2. The browser on the VPN, and the phone work fine (with each other), but they both only use port 10000.
  3. There is no traffic whatsoever on port 5349 (turn)

This was checked using tcpdump on the server: tcpdump -i any -n port 5349.

Any more ideas?

Thanks!

Next step is to verify you see the turns server used in webrtc-internals.

So open the two non-blocked clients, and first open chrome://webrtc-internals on the PC with blocked access to 10000, then open the participant link.
Now in webrtc-internals there are tabs per ever peer connection, and on the top you should see turns in ice servers.

FWIW, I also tried using 3 tabs in the same browser, connected to the same conference (from the “publicly blocked” IP) as you suggested. The result is that the chat is working, but A/V isn’t, each tab only sees their own picture.

Looking at chrome://webrtc-internals/, I find four different tabs, but only one of them has:

iceServers: [stun:example.org:5349]

(note: only stun, no turn)

and the three others have:
iceServers: []

And in coturn.log on the server, I only see stun BINDING stuff, but no TURN stuff…

That is exactly why I’ve been banging my head on the wall for a few days… :slightly_frowning_face:

OK, I did as you suggested.

Made a conference between phone and VPN, works.

Joined using the blocked client:

  • it “knows” the other participants, but no audio or video from them
  • no audio or video from that client on the other clients (but again, they “know” the blocked client exists)
  • chrome://webrtc-internals on the blocked client shows one tab only, with iceServers: []

:frowning:

So it seems turn is not used for the jvb connections. Check whether you see any errors in the prosody log when restarting it, something about turncredentials module.
Check do you see the file /usr/share/jitsi-meet/prosody-plugins/mod_turncredentials.lua.

Yes, that was my suspicion as well, that maybe the turncredentials plugin wasn’t working…

But everything looks fine on the surface:

root@bender:~# ls -la /usr/share/jitsi-meet/prosody-plugins/mod_turncredentials.lua
-rw-r--r-- 1 root root 2965 Jan  9 18:08 /usr/share/jitsi-meet/prosody-plugins/mod_turncredentials.lua
root@bender:~# /etc/init.d/prosody restart
[ ok ] Restarting prosody (via systemctl): prosody.service.
root@bender:~# grep -i turncred /var/log/prosody/prosody.*

Is there any way to “manually” check that the plugin is working? Like, sending a raw XMPP request on the command line or via curl, or telnet, or so?

Otherwise, from looking at the source, maybe I should explicitly remove the turncredentials_secret from the configuration, in the hope that the module should then fail?

What do you think?

Yeah, try so you can see messages, to see it is trying to load.

Hmm…

root@bender:~# /etc/init.d/prosody restart
[ ok ] Restarting prosody (via systemctl): prosody.service.
root@bender:~# grep -i turncred /var/log/prosody/prosody.
prosody.err  prosody.log
root@bender:~# grep -i turncred /var/log/prosody/prosody.*
/var/log/prosody/prosody.err:Apr 09 23:48:27 example.org:turncredentials        error   turncredentials not configured
/var/log/prosody/prosody.log:Apr 09 23:48:27 example.org:turncredentials        error   turncredentials not configured

So it does seem to get loaded.

Any way to manually check if it’s actually working?

Not that I’m aware of … There are xmpp messages sent from lib-jitsi-meet … Maybe check the JavaScript console for errors or something … Search for turn or iceserver

Oh, you’re on to something here. This is what the chrome console shows:

Logger.js:154 2020-04-09T22:15:55.896Z [modules/xmpp/strophe.jingle.js] getting turn credentials failed <iq xmlns=​"jabber:​client" type=​"error" to=​"be8f6129-c4da-40b7-9391-39c3735ee64e@guest.example.org/​eaf0aa63-3a30-4b78-a998-44f8bdbab736" from=​"guest.example.org" id=​"36adfc7e-440d-4437-8300-9fbed14f576d:​sendIQ">​<error type=​"cancel">​<service-unavailable xmlns=​"urn:​ietf:​params:​xml:​ns:​xmpp-stanzas">​</service-unavailable>​</error>​</iq>​
Logger.js:154 2020-04-09T22:15:55.897Z [modules/xmpp/strophe.jingle.js] is mod_turncredentials or similar installed?

The question is, why am I seeing this and how can I fix it?

There is no indication in the server-side logs of anything going wrong, at least as far as I can tell…

BTW, in case I didn’t say so yet – your help and patience is really appreciated, so thank you again!

Thank you.
Which prosody is this?

But wait, you don’t have it enabled under that host. I just saw you have authentication.
Enabled it and for this virtualhost.

2 Likes

Straight from the repositories…

root@bender:~# dpkg -S /etc/prosody/README
prosody: /etc/prosody/README
root@bender:~# apt-cache policy prosody
prosody:
  Installed: 0.10.0-1build1
  Candidate: 0.10.0-1build1
  Version table:
 *** 0.10.0-1build1 500
		500 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
		100 /var/lib/dpkg/status

Yep, I spotted the problem enable the module and you should be fine.

1 Like

Oh, that definitely makes sense.

So, in the /etc/prosody/conf.avail/example.org.cfg.lua

I currently have all of this enabled for VirtualHost "example.org":

		-- we need bosh
		modules_enabled = {
			"bosh";
			"pubsub";
			"ping"; -- Enable mod_ping
			"speakerstats";
			"turncredentials";
			"conference_duration";
		}

… but pretty much nothing for VirtualHost "guest.example.org".

Should I just enable all the modules, just to be on the safe side, or is that not recommended?

Go one by one :slight_smile: If something is not working, now you know :slight_smile:

@damencho,

you are officially the hero of the day. (well, at least for me)

IT WORKS!

Thank you very very much.

(yes, now in hindsight it’s actually a rather trivial configuration thing, but that’s how most problems appear after they’ve been solved :stuck_out_tongue: )

I just copy-pasted the section modules_enabled part from the example.org VirtualHost to the guest.example.org one, to enable all of the “original” modules, but for future readers of this thread, YMMV.

1 Like

Hi,

I have some issues with coturn as well. Since I enabled LDAP auth, i cant see any candidates going through port 443. I did not tested it with original config…

So, when auth is enabled, what is needed to get coturn working? prosody has a guest.host section with now same modules from the main domain - but nothing changed. No errors in prosody regarding coturn.

Current setup:

plugin_paths = { "/usr/share/jitsi-meet/prosody-plugins/" }

-- domain mapper options, must at least have domain base set to use the mapper
muc_mapper_domain_base = "meeting.host.tld";

turncredentials_secret = "secret";

turncredentials = {
  { type = "stun", host = "meeting.host.tld", port = "4446" },
  { type = "turn", host = "meeting.host.tld", port = "4446", transport = "udp" },
  { type = "turns", host = "meeting.host.tld", port = "443", transport = "tcp" }
};

cross_domain_bosh = false;
consider_bosh_secure = true;

VirtualHost "meeting.host.tld"
        -- enabled = false -- Remove this line to enable this host
        authentication = "cyrus"
        -- Properties below are modified by jitsi-meet-tokens package config
        -- and authentication above is switched to "token"
        --app_id="example_app_id"
        --app_secret="example_app_secret"
        -- Assign this host a certificate for TLS, otherwise it would use the one
        -- set in the global section (if any).
        -- Note that old-style SSL on port 5223 only supports one certificate, and will always
        -- use the global one.
        ssl = {
                key = "/etc/prosody/certs/meeting.host.tld.key";
                certificate = "/etc/prosody/certs/meeting.host.tld.crt";
        }
        speakerstats_component = "speakerstats.meeting.host.tld"
        conference_duration_component = "conferenceduration.meeting.host.tld"
        -- we need bosh
        modules_enabled = {
            "bosh";
            "pubsub";
            "ping"; -- Enable mod_ping
            "speakerstats";
            "turncredentials";
            "conference_duration";
			"auth_cyrus";
        }
        c2s_require_encryption = false
		cyrus_application_name = "xmpp"
		allow_unencrypted_plain_auth = true

VirtualHost "guest.meeting.host.tld"
    authentication = "anonymous"
		modules_enabled = {
		"bosh";
		"pubsub";
		"ping"; -- Enable mod_ping
		"speakerstats";
		"turncredentials";
		"conference_duration";
	}
    c2s_require_encryption = false

Component "conference.meeting.host.tld" "muc"
    storage = "none"
    modules_enabled = {
        "muc_meeting_id";
        "muc_domain_mapper";
        -- "token_verification";
    }
    admins = { "focus@auth.meeting.host.tld" }
    muc_room_locking = false
    muc_room_default_public_jids = true

-- internal muc component
Component "internal.auth.meeting.host.tld" "muc"
    storage = "none"
    modules_enabled = {
      "ping";
    }
    admins = { "focus@auth.meeting.host.tld", "jvb@auth.meeting.host.tld" }
    muc_room_locking = false
    muc_room_default_public_jids = true

VirtualHost "auth.meeting.host.tld"
    ssl = {
        key = "/etc/prosody/certs/auth.meeting.host.tld.key";
        certificate = "/etc/prosody/certs/auth.meeting.host.tld.crt";
    }
    authentication = "internal_plain"

Component "focus.meeting.host.tld"
    component_secret = "secret"

Component "speakerstats.meeting.host.tld" "speakerstats_component"
    muc_component = "conference.meeting.host.tld"

Component "conferenceduration.meeting.host.tld" "conference_duration_component"
    muc_component = "conference.meeting.host.tld"

The guest-section had no modules at first!

AH - No. It is working. But only with Chrome. Firefox seem to not able to get these turn-connection or whatever.

With all participants using chrome, the coturn is used (TCP 443). Firefox clients only support UDP/10000.

But why? FF limitation?

EDIT: YES! YOU have to enable those modules in guest configuration as well! At least the turncredentials!

This is missing in the manuals!

If you want turn to work and have auth enabled, the guest component need those module-config als well! (except auth_cyrus, maybe)! Just tested!

1 Like

Same problem here ,all night long struggling .
now SOLVED ! in 5 min !
thanks !! :grinning: