[jitsi-users] java.lang.NoClassDefFoundError: Could not initialize class org.jitsi.sctp4j.Sctp


#1

Hi.

Since my posting yesterday about not being able to get a new installation of
Jitsi Meet working under Debian, I've completely reinstalled the Virtual
Machine with Debian 7.9 (wheezy), which is the same version as I was using
yesterday, and I've very very carefully followed the instructions at
https://jitsi.org/qi

I now get the same symptoms on the clients as yesterday (local video only, no
remote video or audio, although I can see that there are two conference
members on both machines), although the server is now looking a little bit
better for some reason.

Here's the installed version:

# apt-cache policy jitsi-videobridge
jitsi-videobridge:
  Installed: 518-1
  Candidate: 518-1

Here's what I see in /var/log/prosody/prosody.log when I start the service:

Sep 17 16:51:55 jcp19a36b0 info Incoming Jabber component connection
Sep 17 16:51:55 jitsi-videobridge.192.168.36.80:component info
Component successfully authenticated: jitsi-videobridge.192.168.36.80
Sep 17 16:51:55 jcp19aaf20 info Incoming Jabber component connection
Sep 17 16:51:56 focus.192.168.36.80:component info Component successfully
authenticated: focus.192.168.36.80
Sep 17 16:51:56 c2s19b46c0 info Client connected
Sep 17 16:51:56 sasl warn Client is violating RFC 3920 (section 6.1,
point 7).
Sep 17 16:51:56 c2s19b46c0 info Authenticated as
focus@auth.192.168.36.80

and when the two clients connect:

Sep 18 10:54:44 mod_bosh info New BOSH session, assigned it sid
'70060ff1-652e-4ea2-98e5-321e316f5137'
Sep 18 10:54:45 bosh70060ff1-652e-4ea2-98e5-321e316f5137 info
Authenticated as 5bc35162-f027-412a-bc75-a7a17de66378@192.168.36.80
Sep 18 10:56:51 mod_bosh info New BOSH session, assigned it sid
'91e98608-6668-4382-8e99-08f23f3b17aa'
Sep 18 10:56:52 bosh91e98608-6668-4382-8e99-08f23f3b17aa info
Authenticated as 36e3f35f-cb7d-48dd-8862-52eee7e484e0@192.168.36.80

So, internal XMPP authentication looks okay.

However, when the second client connects, I get the following (amongst about
100 further lines of INFO) in /var/log/jitsi/jvb.log:

2015-08-18 10:56:55.358 SEVERE: [51]
util.UtilActivator.uncaughtException().108 An uncaught exception occurred in
thread=Thread[org.jitsi.videobridge.SctpConnection-pool-5-thread-5,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$1.run(SctpConnection.java:454)
        at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:701)

2015-08-18 10:56:56.081 SEVERE: [54]
util.UtilActivator.uncaughtException().108 An uncaught exception occurred in
thread=Thread[org.jitsi.videobridge.SctpConnection-pool-5-thread-6,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$1.run(SctpConnection.java:454)
        at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:701)

So, there's definitely something still not right, with just a clean install and
following the docs.

Can anyone help me debug, please? I've no idea where to look for guidance on
what that log file output means, and how to fix it.

Thanks,

Antony.

···

--
Never automate fully anything that does not have a manual override capability.
Never design anything that cannot work under degraded conditions in emergency.

                                                   Please reply to the list;
                                                         please *don't* CC me.


#2

org.jitsi.sctp4j.Sctp should be included in /use/share/jitsi-videobridge/lib/libjitsi-*.jar. See if it is there and post the complete videobridge log file (filtering out private stuff, if needed) if you still have the issue.

Regards,
Boris

···

On 18/09/15 05:18, Antony Stone wrote:

Hi.

Since my posting yesterday about not being able to get a new installation of
Jitsi Meet working under Debian, I've completely reinstalled the Virtual
Machine with Debian 7.9 (wheezy), which is the same version as I was using
yesterday, and I've very very carefully followed the instructions at
https://jitsi.org/qi

I now get the same symptoms on the clients as yesterday (local video only, no
remote video or audio, although I can see that there are two conference
members on both machines), although the server is now looking a little bit
better for some reason.

Here's the installed version:

# apt-cache policy jitsi-videobridge
jitsi-videobridge:
   Installed: 518-1
   Candidate: 518-1

Here's what I see in /var/log/prosody/prosody.log when I start the service:

Sep 17 16:51:55 jcp19a36b0 info Incoming Jabber component connection
Sep 17 16:51:55 jitsi-videobridge.192.168.36.80:component info
Component successfully authenticated: jitsi-videobridge.192.168.36.80
Sep 17 16:51:55 jcp19aaf20 info Incoming Jabber component connection
Sep 17 16:51:56 focus.192.168.36.80:component info Component successfully
authenticated: focus.192.168.36.80
Sep 17 16:51:56 c2s19b46c0 info Client connected
Sep 17 16:51:56 sasl warn Client is violating RFC 3920 (section 6.1,
point 7).
Sep 17 16:51:56 c2s19b46c0 info Authenticated as
focus@auth.192.168.36.80

and when the two clients connect:

Sep 18 10:54:44 mod_bosh info New BOSH session, assigned it sid
'70060ff1-652e-4ea2-98e5-321e316f5137'
Sep 18 10:54:45 bosh70060ff1-652e-4ea2-98e5-321e316f5137 info
Authenticated as 5bc35162-f027-412a-bc75-a7a17de66378@192.168.36.80
Sep 18 10:56:51 mod_bosh info New BOSH session, assigned it sid
'91e98608-6668-4382-8e99-08f23f3b17aa'
Sep 18 10:56:52 bosh91e98608-6668-4382-8e99-08f23f3b17aa info
Authenticated as 36e3f35f-cb7d-48dd-8862-52eee7e484e0@192.168.36.80

So, internal XMPP authentication looks okay.

However, when the second client connects, I get the following (amongst about
100 further lines of INFO) in /var/log/jitsi/jvb.log:

2015-08-18 10:56:55.358 SEVERE: [51]
util.UtilActivator.uncaughtException().108 An uncaught exception occurred in
thread=Thread[org.jitsi.videobridge.SctpConnection-pool-5-thread-5,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$1.run(SctpConnection.java:454)
         at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
         at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
         at java.lang.Thread.run(Thread.java:701)

2015-08-18 10:56:56.081 SEVERE: [54]
util.UtilActivator.uncaughtException().108 An uncaught exception occurred in
thread=Thread[org.jitsi.videobridge.SctpConnection-pool-5-thread-6,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$1.run(SctpConnection.java:454)
         at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
         at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
         at java.lang.Thread.run(Thread.java:701)

So, there's definitely something still not right, with just a clean install and
following the docs.

Can anyone help me debug, please? I've no idea where to look for guidance on
what that log file output means, and how to fix it.


#3

Hi Anthony,

I had the exact same problem. Dabbled a bit (I'm far from any java expert)
and then I took the easy way out and switched to Ubuntu 14.04 and
everything worked perfectly after that. Same virtual server, same setup
instructions.

However, I you have the tenacity to stick with Debian and debug all this I
wish you good luck and would really like to know your solution once you
reach it. :slight_smile:

Kindest regards,
Mathias

···

2015-09-18 12:18 GMT+02:00 Antony Stone <Antony.Stone@jitsi.open.source.it>:

Hi.

Since my posting yesterday about not being able to get a new installation
of
Jitsi Meet working under Debian, I've completely reinstalled the Virtual
Machine with Debian 7.9 (wheezy), which is the same version as I was using
yesterday, and I've very very carefully followed the instructions at
https://jitsi.org/qi

I now get the same symptoms on the clients as yesterday (local video only,
no
remote video or audio, although I can see that there are two conference
members on both machines), although the server is now looking a little bit
better for some reason.

Here's the installed version:

# apt-cache policy jitsi-videobridge
jitsi-videobridge:
  Installed: 518-1
  Candidate: 518-1

Here's what I see in /var/log/prosody/prosody.log when I start the service:

Sep 17 16:51:55 jcp19a36b0 info Incoming Jabber component
connection
Sep 17 16:51:55 jitsi-videobridge.192.168.36.80:component info
Component successfully authenticated: jitsi-videobridge.192.168.36.80
Sep 17 16:51:55 jcp19aaf20 info Incoming Jabber component
connection
Sep 17 16:51:56 focus.192.168.36.80:component info Component
successfully
authenticated: focus.192.168.36.80
Sep 17 16:51:56 c2s19b46c0 info Client connected
Sep 17 16:51:56 sasl warn Client is violating RFC 3920 (section 6.1,
point 7).
Sep 17 16:51:56 c2s19b46c0 info Authenticated as
focus@auth.192.168.36.80

and when the two clients connect:

Sep 18 10:54:44 mod_bosh info New BOSH session, assigned it sid
'70060ff1-652e-4ea2-98e5-321e316f5137'
Sep 18 10:54:45 bosh70060ff1-652e-4ea2-98e5-321e316f5137 info
Authenticated as 5bc35162-f027-412a-bc75-a7a17de66378@192.168.36.80
Sep 18 10:56:51 mod_bosh info New BOSH session, assigned it sid
'91e98608-6668-4382-8e99-08f23f3b17aa'
Sep 18 10:56:52 bosh91e98608-6668-4382-8e99-08f23f3b17aa info
Authenticated as 36e3f35f-cb7d-48dd-8862-52eee7e484e0@192.168.36.80

So, internal XMPP authentication looks okay.

However, when the second client connects, I get the following (amongst
about
100 further lines of INFO) in /var/log/jitsi/jvb.log:

2015-08-18 10:56:55.358 SEVERE: [51]
util.UtilActivator.uncaughtException().108 An uncaught exception occurred
in
thread=Thread[org.jitsi.videobridge.SctpConnection-pool-5-thread-5,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$1.run(SctpConnection.java:454)
        at

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
        at

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:701)

2015-08-18 10:56:56.081 SEVERE: [54]
util.UtilActivator.uncaughtException().108 An uncaught exception occurred
in
thread=Thread[org.jitsi.videobridge.SctpConnection-pool-5-thread-6,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$1.run(SctpConnection.java:454)
        at

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
        at

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:701)

So, there's definitely something still not right, with just a clean
install and
following the docs.

Can anyone help me debug, please? I've no idea where to look for guidance
on
what that log file output means, and how to fix it.

Thanks,

Antony.

--
Never automate fully anything that does not have a manual override
capability.
Never design anything that cannot work under degraded conditions in
emergency.

                                                   Please reply to the
list;
                                                         please *don't* CC
me.

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#4

>
> However, when the second client connects, I get the following (amongst
> about 100 further lines of INFO) in /var/log/jitsi/jvb.log:
>
> 2015-08-18 10:56:55.358 SEVERE: [51]
> util.UtilActivator.uncaughtException().108 An uncaught exception occurred
> in
> thread=Thread[org.jitsi.videobridge.SctpConnection-pool-5-thread-5,5,mai
> n] 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$1.run(SctpConnection.java:
> 454) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java
> :1146)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.jav
> a:615)
> at java.lang.Thread.run(Thread.java:701)

> So, there's definitely something still not right, with just a clean
> install and following the docs.
>
> Can anyone help me debug, please? I've no idea where to look for
> guidance on what that log file output means, and how to fix it.

org.jitsi.sctp4j.Sctp should be included in
/use/share/jitsi-videobridge/lib/libjitsi-*.jar. See if it is there

Thanks.

Here's what I find:

root@Jitsi:/usr/share/jitsi-videobridge/lib# grep -r org.jitsi.sctp4j.Sctp .
Binary file ./libjitsi-1.0-SNAPSHOT.jar matches

and post the complete videobridge log file (filtering out private stuff, if
needed) if you still have the issue.

Background info while I think of it - here's the list of packages which got
installed as dependencies when I installed jitsi-meet:

authbind
ca-certificates-java
dbus
default-jre-headless
icedtea-6-jre-cacao
icedtea-6-jre-jamvm
java-common
javascript-common
jicofo
jitsi-meet-prosody
jitsi-videobridge
libavahi-client3
libavahi-common-data
libavahi-common3
libcups2
libdbus-1-3
libgd2-noxpm
libjpeg8
libjs-jquery
libjs-jquery-ui
liblcms2-2
liblua5.1-0
libnspr4
libnss3
libpcsclite1
libpng12-0
libsystemd-login0
libxslt1.1
lua-event
lua-expat
lua-filesystem
lua-sec
lua-socket
lua5.1
nginx
nginx-common
nginx-full
openjdk-6-jre-headless
openjdk-6-jre-lib
prosody
ssl-cert
tzdata-java
wwwconfig-common

Complete log files are at http://al.dehy.de/misc/jitsi/ - they start from the
installation of jitsi-meet and the initial service startup.

Timestamps:

16:29:22 Client 1 connects (sees own video, 1 user in conference)
16:30:19 Client 2 connects (sees own video, 2 users in conference, client 1
also sees that 2 users are in conference, but neither gets other's video or
audio)
16:31:15 Client 1 leaves conference (client 2 becomes conference manager)
16:31:38 Client 2 leaves conference

I hope that helps to track it down - let me know what else I can try, or info
I can provide.

Thanks,

Antony.

···

On Friday 18 September 2015 at 16:39:45, Boris Grozev wrote:

On 18/09/15 05:18, Antony Stone wrote:

--
You can tell that the day just isn't going right when you find yourself using
the telephone before the toilet.

                                                   Please reply to the list;
                                                         please *don't* CC me.


#5

However, when the second client connects, I get the following (amongst
about 100 further lines of INFO) in /var/log/jitsi/jvb.log:

2015-08-18 10:56:55.358 SEVERE: [51]
util.UtilActivator.uncaughtException().108 An uncaught exception occurred
in
thread=Thread[org.jitsi.videobridge.SctpConnection-pool-5-thread-5,5,mai
n] 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$1.run(SctpConnection.java:
          454) at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java
:1146)
          at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.jav
a:615)
          at java.lang.Thread.run(Thread.java:701)

So, there's definitely something still not right, with just a clean
install and following the docs.

Can anyone help me debug, please? I've no idea where to look for
guidance on what that log file output means, and how to fix it.

org.jitsi.sctp4j.Sctp should be included in
/use/share/jitsi-videobridge/lib/libjitsi-*.jar. See if it is there

Thanks.

Here's what I find:

root@Jitsi:/usr/share/jitsi-videobridge/lib# grep -r org.jitsi.sctp4j.Sctp .
Binary file ./libjitsi-1.0-SNAPSHOT.jar matches

and post the complete videobridge log file (filtering out private stuff, if
needed) if you still have the issue.

Background info while I think of it - here's the list of packages which got
installed as dependencies when I installed jitsi-meet:

authbind
ca-certificates-java
dbus
default-jre-headless
icedtea-6-jre-cacao
icedtea-6-jre-jamvm
java-common
javascript-common
jicofo
jitsi-meet-prosody
jitsi-videobridge
libavahi-client3
libavahi-common-data
libavahi-common3
libcups2
libdbus-1-3
libgd2-noxpm
libjpeg8
libjs-jquery
libjs-jquery-ui
liblcms2-2
liblua5.1-0
libnspr4
libnss3
libpcsclite1
libpng12-0
libsystemd-login0
libxslt1.1
lua-event
lua-expat
lua-filesystem
lua-sec
lua-socket
lua5.1
nginx
nginx-common
nginx-full
openjdk-6-jre-headless
openjdk-6-jre-lib
prosody
ssl-cert
tzdata-java
wwwconfig-common

Complete log files are at http://al.dehy.de/misc/jitsi/ - they start from the
installation of jitsi-meet and the initial service startup.

2015-08-18 16:30:26.378 SEVERE: [37] org.jitsi.sctp4j.Sctp.error() Failed to load native library jnsctp: /tmp/jna-105622/jna6754869960835873369.tmp: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /tmp/jna-105622/jna6754869960835873369.tmp)

Ahh, our jnsctp.so is compiled against a version of libc that your debian version doesn't have. You can:
1. Try setting openSctp:false in config.js which might solve the problem, but active speaker switches won't work
2. Compile your own version of libjnsctp.so[0]
3. User a newer version of debian (the current stable works, I believe).

Regards,
Boris

[0]https://github.com/jitsi/libjitsi/tree/master/src/native/sctp

···

On 18/09/15 10:42, Antony Stone wrote:

On Friday 18 September 2015 at 16:39:45, Boris Grozev wrote:

On 18/09/15 05:18, Antony Stone wrote:

Timestamps:

16:29:22 Client 1 connects (sees own video, 1 user in conference)
16:30:19 Client 2 connects (sees own video, 2 users in conference, client 1
also sees that 2 users are in conference, but neither gets other's video or
audio)
16:31:15 Client 1 leaves conference (client 2 becomes conference manager)
16:31:38 Client 2 leaves conference

I hope that helps to track it down - let me know what else I can try, or info
I can provide.

Thanks,

Antony.


#6

Interesting.

So, I've just made myself an Ubuntu 14.04 VM, and installed jitsi-meet (using,
as you did, the exact same instructions).

The list of extra packages it wants to bring in this time is:

authbind ca-certificates-java default-jre-headless fontconfig-config fonts-
dejavu-core java-common javascript-common jicofo jitsi-meet-prosody jitsi-
videobridge libasyncns0 libavahi-client3 libavahi-common-data libavahi-common3
libcups2 libflac8 libfontconfig1 libgd3 libjbig0 libjpeg-turbo8 libjpeg8 libjs-
jquery libjs-jquery-ui liblcms2-2 libnspr4 libnss3 libnss3-nssdb libogg0
libpulse0 libsndfile1 libtiff5 libvorbis0a libvorbisenc2 libvpx1 libxpm4
libxslt1.1 lua-event lua-expat lua-filesystem lua-sec lua-socket lua5.1 nginx
nginx-common nginx-core openjdk-7-jre-headless prosody ssl-cert tzdata-java

The differences between this and the list for Debian are:

Debian only:

  dbus
  icedtea-6-jre-cacao
  icedtea-6-jre-jamvm
  libdbus-1-3
  libgd2-nopxm
  liblua5.1-0
  libpcsclite1
  libpng12-0
  libsystemd-login0
  nginx-full
  openjdk-6-jre-lib
  openjdk-6-jre-headless
  wwwconfig-common

Ubuntu only:

  fontconfig-config
  fonts-dejavu-core
  libasyncns0
  libflac8
  libfontconfig1
  libgd3
  libjbig0
  libjpeg-turbo8
  libnss3-nssdb
  libogg0
  libpulse0
  libsndfile1
  libtiff5
  libvorbis0a
  libvorbisenc2
  libvpx1
  libxpm4
  nginx-core
  openjdk-7-jre-headless

So, amongst that lot, it does look as though Ubuntu is using openjdk-7-jre-
headless whereas Debian is using version 6.

The Ubuntu installation works - each client gets the audio and video from the
other - it's a proper conference.

I tried replacing just openjdk-6-jre-headless from Debian with openjdk-7-jre-
headless (since that's the only JRE package I see which is different between
the two), but it ended up with the same unsatisfactory choices as my previous
posting - uninstall jitsi, or downgrade JRE, neither of which solves the
problem.

Antony.

···

On Friday 18 September 2015 at 14:55:33, Mathias Friman wrote:

I had the exact same problem. Dabbled a bit (I'm far from any java expert)
and then I took the easy way out and switched to Ubuntu 14.04 and
everything worked perfectly after that. Same virtual server, same setup
instructions.

--
I conclude that there are two ways of constructing a software design: One way
is to make it so simple that there are _obviously_ no deficiencies, and the
other way is to make it so complicated that there are no _obvious_
deficiencies.

- C A R Hoare

                                                   Please reply to the list;
                                                         please *don't* CC me.


#7

Well done :slight_smile: You got it :slight_smile:

I didn't want to completely update to Debian 8 Jessie, because I'm avoiding
systemd for the time being, however an update of just one package (libc6) from
the jessie distribution into my wheezy (Debian 7) installation has fixed it.

I now have a working Jitsi installation running under (mostly) Debian 7
Wheezy, and I can now get on with what I was really aiming for, which is the
second part of https://jitsi.org/qi - which is to integrate SIP connections
from standard SIP videophones.

Thanks for the push in the right direction, Boris :slight_smile:

Regards,

Antony.

···

On Friday 18 September 2015 at 20:00:06, Boris Grozev wrote:

On 18/09/15 10:42, Antony Stone wrote:
>
> Complete log files are at http://al.dehy.de/misc/jitsi/ - they start from
> the installation of jitsi-meet and the initial service startup.

2015-08-18 16:30:26.378 SEVERE: [37] org.jitsi.sctp4j.Sctp.error()
Failed to load native library jnsctp:
/tmp/jna-105622/jna6754869960835873369.tmp:
/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found
(required by /tmp/jna-105622/jna6754869960835873369.tmp)

Ahh, our jnsctp.so is compiled against a version of libc that your
debian version doesn't have. You can:
1. Try setting openSctp:false in config.js which might solve the
problem, but active speaker switches won't work
2. Compile your own version of libjnsctp.so[0]
3. User a newer version of debian (the current stable works, I believe).

--
The gravitational attraction exerted by a single doctor at a distance of 6
inches is roughly twice that of Jupiter at its closest point to the Earth.

                                                   Please reply to the list;
                                                         please *don't* CC me.


#8

With thanks to Boris Grozev, for pushing me in the right direction:

1. Add both wheezy and jessie repositories to your /etc/apt/sources.list

2. Set up /etc/apt/preferences with something like:

Package: *
Pin: release a=wheezy
Pin-Priority: 700

Package: *
Pin: release=jessie
Pin-Priority: 650

3. Upgrade libc6:

# aptitude install libc6 -t jessie

or

# apt-get install libc6 -t jessie

depending on whichever tool you prefer.

4. Restart jitsi, and enjoy the now-working system.

Regards,

Antony.

···

On Friday 18 September 2015 at 14:55:33, Mathias Friman wrote:

If you have the tenacity to stick with Debian and debug all this I wish you
good luck and would really like to know your solution once you reach it. :slight_smile:

--
.evah I serutangis sseltniop tsom eht fo eno eb tsum sihT

                                                   Please reply to the list;
                                                         please *don't* CC me.


#9

I now have a working Jitsi installation running under (mostly) Debian 7
Wheezy, and I can now get on with what I was really aiming for, which is
the second part of https://jitsi.org/qi - which is to integrate SIP
connections from standard SIP videophones.

That simply worked with no hiccups at all.

Inbound and outbound SIP participants simply worked - lovely :slight_smile:

Thanks for the push in the right direction, Boris :slight_smile:

Next I want to see whether I can separate the jitsi-meet/videobridge machine
from the jigasi machine, because I'd like to be able to invite SIP
participants to a Jitsi conference where I don't have the ability to install
jigasi on the conferencing server itself.

If anyone has managed to do this already, please let me know :slight_smile:

Regards,

Antony.

···

On Friday 18 September 2015 at 22:52:02, Antony Stone wrote:

--
In the Beginning there was nothing, which exploded.

- Terry Pratchett

                                                   Please reply to the list;
                                                         please *don't* CC me.


#10

I now have a working Jitsi installation running under (mostly) Debian 7
Wheezy, and I can now get on with what I was really aiming for, which is
the second part of https://jitsi.org/qi - which is to integrate SIP
connections from standard SIP videophones.

That simply worked with no hiccups at all.

Inbound and outbound SIP participants simply worked - lovely :slight_smile:

Awesome, I'm glad to hear that!

Thanks for the push in the right direction, Boris :slight_smile:

Next I want to see whether I can separate the jitsi-meet/videobridge machine
from the jigasi machine, because I'd like to be able to invite SIP
participants to a Jitsi conference where I don't have the ability to install
jigasi on the conferencing server itself.

If anyone has managed to do this already, please let me know :slight_smile:

There is absolutely no dependency on these two being on the same machine. You just need to make sure that prosody's component port is accessible from jigasi.

Regards,
Boris

···

On 18/09/15 16:11, Antony Stone wrote:

On Friday 18 September 2015 at 22:52:02, Antony Stone wrote:


#11

Is that true for meet.jit.si?

Antony.

···

On Friday 18 September 2015 at 23:27:48, Boris Grozev wrote:

On 18/09/15 16:11, Antony Stone wrote:
>
> Next I want to see whether I can separate the jitsi-meet/videobridge
> machine from the jigasi machine, because I'd like to be able to invite
> SIP participants to a Jitsi conference where I don't have the ability to
> install jigasi on the conferencing server itself.
>
> If anyone has managed to do this already, please let me know :slight_smile:

There is absolutely no dependency on these two being on the same
machine. You just need to make sure that prosody's component port is
accessible from jigasi.

--
"Black holes are where God divided by zero."

- Steven Wright

                                                   Please reply to the list;
                                                         please *don't* CC me.


#12

Clarification: Although they don't need to be on the same machine, jigasi and videobridge have to be connected to the same XMPP server for everything (both incoming and outgoing calls) to work. Currently you can't connect jigasi and create outgoing calls on meet.jit.si.

It should be possible to have a jigasi instance route incoming SIP calls to a Jitsi-Meet conference hosted somewhere else, as long as the XMPP client port (5222) is accessible (jigasi doesn't support BOSH, which clients normally use). I don't know of anyone having tried that, though. And for meet.jit.si in particular this won't work, because 5222 is filtered.

Regards,
Boris

···

On 18/09/15 16:30, Antony Stone wrote:

On Friday 18 September 2015 at 23:27:48, Boris Grozev wrote:

On 18/09/15 16:11, Antony Stone wrote:

Next I want to see whether I can separate the jitsi-meet/videobridge
machine from the jigasi machine, because I'd like to be able to invite
SIP participants to a Jitsi conference where I don't have the ability to
install jigasi on the conferencing server itself.

If anyone has managed to do this already, please let me know :slight_smile:

There is absolutely no dependency on these two being on the same
machine. You just need to make sure that prosody's component port is
accessible from jigasi.

Is that true for meet.jit.si?


#13

Although they don't need to be on the same machine, jigasi and videobridge
have to be connected to the same XMPP server for everything (both incoming
and outgoing calls) to work. Currently you can't connect jigasi and create
outgoing calls on meet.jit.si.

Is there any (security, for example) reason why not?

It should be possible to have a jigasi instance route incoming SIP calls
to a Jitsi-Meet conference hosted somewhere else, as long as the XMPP
client port (5222) is accessible (jigasi doesn't support BOSH, which
clients normally use). I don't know of anyone having tried that, though.
And for meet.jit.si in particular this won't work, because 5222 is
filtered.

Okay, I'll try that between a couple of VMs on my local net, but as above, I
wonder if there's any reason that an external instance of jigasi shouldn't be
allowed to connect in to meet.jit.si, considering that any random Chrome
client is allowed to?

Thanks for the help so far - it's brought me a long way :slight_smile:

Antony.

···

On Friday 18 September 2015 at 23:48:55, Boris Grozev wrote:

--
"In fact I wanted to be John Cleese and it took me some time to realise that
the job was already taken."

- Douglas Adams

                                                   Please reply to the list;
                                                         please *don't* CC me.


#14

Although they don't need to be on the same machine, jigasi and videobridge
have to be connected to the same XMPP server for everything (both incoming
and outgoing calls) to work. Currently you can't connect jigasi and create
outgoing calls on meet.jit.si.

Is there any (security, for example) reason why not?

Jigasi connects as an XMPP component, so it needs to authenticate. Clients need to know its address, so they can request calls through it.

It should be possible to have a jigasi instance route incoming SIP calls
to a Jitsi-Meet conference hosted somewhere else, as long as the XMPP
client port (5222) is accessible (jigasi doesn't support BOSH, which
clients normally use). I don't know of anyone having tried that, though.
And for meet.jit.si in particular this won't work, because 5222 is
filtered.

Okay, I'll try that between a couple of VMs on my local net, but as above, I
wonder if there's any reason that an external instance of jigasi shouldn't be
allowed to connect in to meet.jit.si, considering that any random Chrome
client is allowed to?

One reason is that the XMPP server is configured without TLS on port 5222. Traffic from web-clients is protected, because they are proxied through the web-server.

Thanks for the help so far - it's brought me a long way :slight_smile:

You are very welcome.

Regards,
Boris

···

On 18/09/15 17:03, Antony Stone wrote:

On Friday 18 September 2015 at 23:48:55, Boris Grozev wrote: