Posibility of proper ARM packaging for JVB2?

Recently I tried to run it on Ampere ARM and run into a problem with JVB crushing during Colibri requests.
Logs tell oblivious reason:
java.lang.UnsatisfiedLinkError: /tmp/nativeutils2794382925289/libjnisctp.so: /tmp/nativeutils2794382925289/libjnisctp.so: cannot open shared object file: No such file or directory (Possible cause: can’t load AMD 64-bit .so on a AARCH64-bit platform)

so I’m just curious about any plans to have an ARM specific packaging?
How big are changes required, any ideas?

thank you!

You can build the .so using this repository: GitHub - jitsi/libjitsi: Advanced Java media library for secure real-time audio/video communication.

Some patching may be needed. I recently did some work on the libjitsi build system to add ARM64 support but didn’t try to build libjnisctp. You could start with that branch and see if you can build libjnisctp.so. Once it’s built you should be able to just drop it in the lib dir of JVB.

1 Like

Thank you, will have a look!

are you still using sctp ?

nah, I was just curios and tried installing jitsi-videobridge2_2.1-508-gb24f756c-1_all.deb on a Amper A1 in the cloud as an external bridge to existed setup.
It was able to connect to my prosody but was crushing on all colibri calls

I think it tries to load the library regardless.

well, removing the jniwrapper-native…jar file from the /usr/share/jitsi-videobridge/lib/ directory and restarting jitsi-videobridge2 service leads to my test instance to work as before, so I don’t think it is correct on recent Jitsi.

Thanks for testing — in that case, @Dmytro2020, check the value of videobridge.sctp.enabled in jvb.conf (true by default) and set it to false if it’s not already. If you are actually using the SCTP data channels for colibri then you’ll need to switch to websockets.

I tried to add
sctp {

to /etc/jitsi/videobridge/jvb.conf

but it lead to different issue:


SCTP support is not configured

As I said:

Make sure Jicofo is not set to allocate SCTP channels (config) and make sure the client is not configured to try to use them (recent frontend versions won’t try to).

you need also

  websockets {
      enabled = true
      domain = "yur-jitsi-dom.com:443"
      tls = true

and more generally to follow the how-to I linked to.

1 Like

Thank you, I got all of this done.
My test setup needs proper migration to web sockets as described here I assume

I will continue the experiments tomorrow, getting late here in NZ.
I was more curious to just try out-of-the-box JVB2 on ARM, so far the answer is that it is a bit early to do so :slight_smile:
We have a custom client and I need to have a look at what is going on there too

this is not the same websockets migration. xmpp websockets are for prosody connection (instead of bosh).

Sctp → videobridge websockets == migration 1

Bosh → xmpp websockets == migration 2. Bosh has nothing to do with sctp.

migration 1 is more or less mandatory, while migration 2 is an optimization mostly needed for big configs.

1 Like

thank you for an explanation, great.

Let me explain it little bit more details:
Experimental config is:
box1 - jitsi our of the box latest stable+ configured jwtjitsi on AMD Epic
box2 - just a jvb2, connected to box1. Amper A1
default current config, all configs look as in FAQ here FAQ · Jitsi Meet Handbook
So I assume migration 1 is done.

I’m getting that on attempted connection

java.lang.UnsatisfiedLinkError: /tmp/nativeutils2794382925289/libjnisctp.so: /tmp/nativeutils2794382925289/libjnisctp.so: cannot open shared object file: No such file or directory (Possible cause: can’t load AMD 64-bit .so on a AARCH64-bit platform)

than I go to box2(arm) and change /etc/jitsi/videobridge/jvb.conf to disable SCTP

> videobridge {
>     http-servers {
>         public {
>             port = 9090
>         }
>     }
>     websockets {
>         enabled = true
>         domain = "testing-new-jitsi.####.com:443"
>         tls = true
>     }
>     sctp {
>      # Whether SCTP data channels are enabled.
>     enabled=false
>     domain = "testing-new-jitsi.######.com:443"
>         tls = true
>    }
> }

after doing this on attempt to connect I get this in jvb log

SEVERE: [45] [confId=b830833e6c7351d1 gid=17365 conf_name=########.com-####-972324b5-4b99-41e6-89fe-d2548f9b1009@conference.testing-new-jitsi.######.com] ConferenceShim.handleColibriConferenceIQ#483: Error processing sctp connections in IQ: feature-not-implemented SCTP support is not configured

you don’t say if you restarted this jvb…

I definitely restarted that jvb. That is why it so strange

and in config.js you did set openBridgeChannel to websocket ?

the one in /etc/jitsi/meet/?
no, we don’t use any of the meet components, it is a separate client.
Tbh I considering dropping it as it getting too big of a PITA for a quick experiment ( not interested in client code changes ATM ) and we perfectly happy with Epic based setup :slight_smile:

then it must come from this client.

yep, looks like it. So I will let it be there for a moment.
The whole story was about me trying to run jvb on ARM, nothing more.