JVB - Could not initialize class org.jitsi.sctp4j.Sctp

Install & Config
#1

Hello everyone,

I’m pretty new around here so feel free to correct me if I’m mistaken. By the way I’m sorry for the links, I had to replace the . by @ since the forum doesn’t allow me to post several links, a very good idea to create a thorough post …

A sed to help you out

echo "dumb link" | sed 's/@/./g'

I’m trying to install jitsi-meet on and Ubuntu 18.04 LTS following the guide.

My stack is:

  • HAProxy on port 80/443 (which redirects other softwares being irrelevant here)
  • NGinx (localhost) on port 8443 for jitsi-meet

I opened up ports UDP 10000 and also TCP 4443 which seems important for Jitsi Video Bridge.

I have java 8

# java -version
openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-8u212-b03-0ubuntu1.18.04.1-b03)
OpenJDK 64-Bit Server VM (build 25.212-b03, mixed mode)

The installation process went fine, I use my own Let’s Encrypt certificate which is loaded in HAProxy, NGinx (I think it’s useless here) and in Jitsi too.

The problem is that when two persons or more connect to a session, an error shows up for each session Unable to access your microphone.

Check the log, I have this:

JVB 2019-07-16 10:14:59.728 GRAVE: [134797] util.UtilActivator.uncaughtException().122 An uncaught exception occurred in thread=Thread[org.jitsi.videobridge.SctpConnection-pool-12-thread-8,5,main] and message was: Could not initialize class org.jitsi.sctp4j.Sctp
java.lang.NoClassDefFoundError: Could not initialize class org.jitsi.sctp4j.Sctp
	at org.jitsi.videobridge.SctpConnection.lambda$maybeStartStream$1(SctpConnection.java:537)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
JVB 2019-07-16 10:15:00.028 PRÉCIS: [129] org.jitsi.videobridge.xmpp.ComponentImpl.processIQ() (serving component 'JitsiVideobridge') Processing IQ (packetId ebWaF-25520): <iq id="ebWaF-25520" type="result" to="xxx.xxx.xxx" from="xxx.xxx.xxx"/>

So I’ve looked around and found a few posts talking about it:

  • community@jitsi@org/t/jitsi-users-java-lang-noclassdeffounderror-could-not-initialize-class-org-jitsi-sctp4j-sctp/9695
  • community@jitsi@org/t/jitsi-users-java-lang-noclassdeffounderror-could-not-initialize-class-org-jitsi-sctp4j-sctp/9691

Most of them are really outdated and don’t seem to help me on the matter.

I also found out related topics on the list but it seems down lists@jitsi@org/pipermail/users/2015-September/010068.html I’m guessing the list has been dropped.

I read the Advanced configuration though I don’t think these parameters matter in my case:

org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=<Local.IP.Address>
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=<Public.IP.Address>

Has anyone an idea on how to fix it ?
Thanks.

#2

Are you accessing it using http or https. Webrtc does not work with http.

#3

Hello @damencho,

It’s all https from the browser to the jvb.

#4

Is your JVB running behind NAT?

#5

@damencho

not really I “forward” only port 80 and 443 to NGinx for jitsi-meet but the JVB runs directly on the public IP of the server:

# netstat -tulpn | grep -E '4443|10000'
tcp6       0      0 xx.xx.xx.xx:4443      :::*                    LISTEN      5942/java           
udp6       0      0 xx.xx.xx.xx:10000     :::*                                5942/java
#6

Can you send me a link to try it out, if you want do it in privately?

#7

@damencho yeah sure, though I don’t seem to be able to send you a private message, could you send me one first so I can answer you ? Thanks.

#8

So I tried with Java 11, I end up with the same error.

I followed this thread and set openSctp:false in /etc/jitsi/meet/[my_URL]-config.js, no luck same error.

I’m out of idea now :confused:

#9

Hello everyone,

I finally found the cause for this error, it was “simply” because while hardening the system we set noexec on /tmp.

1 Like
#10

Thanks!
this fixed it.
but breaks our security ;-(

#11

Very difficult to spot. It would be very convenient to have a script that checks not only jitsi & jvb configuration but also limits, sysctl and mount options.