Added Windows support. Migrated on CMake to build native libraries. GitHub Actions + GitHub Packages Registry. #3

mstyura · 2019-09-04T13:27:21Z

I'm currently trying to migrate to JVB 2.0, but my usual dev environment is Windows. I've noticed that jitsi-sctp is no longer support Windows after migration to dedicated Maven artifact. So I've added support of Windows.

The summary of changes:

Native libraries are now build with CMake as it provides cross platform way to compile native libraries.
usrsctp and jniwrapper-native artifacts are now platform specific and distinguished by corresponding maven classifier. E.g. usrsctp-1.0-SNAPSHOT-windows-x86_32.jar, usrsctp-1.0-SNAPSHOT-linux-aarch_64.jar, jniwrapper-native-1.0-SNAPSHOT-x86_64.jar etc.
Pre-built native binaries are no longer stored in git as resources, they stored in maven as artifact with platform classifier.

mstyura · 2019-09-04T13:28:47Z

Hi @bbaldino,
could you please review these changes please?
Thanks a lot in advance,

Yura.

bbaldino · 2019-09-04T16:43:55Z

thanks @mstyura this is obviously a lot to take in and i've just about totally evicted all context of the maven/jni hell that this project involved from my brain so it will take me a while to go through it.

mstyura · 2019-09-04T18:46:01Z

Thanks @bbaldino, I completely understand it's not easy to get into jni build procedure after not touching it for a while, but I hope I made things actually simpler. As a starting point could you please follow an updated README.md from my fork and let me know if you have any issue on your environment? I personally followed original readme and it helped me a lot, thank you very much for documenting build procedure!

bbaldino · 2019-09-11T18:02:05Z

hey @mstyura, haven't forgotten about this just haven't gotten to it yet.

mstyura · 2019-10-30T10:29:57Z

Hello, @bbaldino,
Is there any chance you'll be able to have a look at this PR any time soon? I've also seen Jonathan Lennox had done some work on JNI is SRTP repo, maybe he could review as well?
Thank you very much in advance!

bbaldino · 2019-10-30T17:52:57Z

@mstyura i'm really sorry, i just haven't had the time. i promise you i haven't forgotten (i have a reminder every week in my email for this), but i just haven't gotten to it. jonathan is also pretty busy as we're pushing to get jvb 2.0 fully released and stable. since we don't have any commits going into this repo, really, at least we don't have to worry about 'rot' and this becoming outdated soon.

mstyura · 2019-10-30T18:45:57Z

@bbaldino thank you very much for a quick reply, don't worry that this PR is not been reviewed yet. I didn't want to make a pressure on you. I'm not blocked on it and can continue without it for a few month I think. Have a good day!

MMX777 · 2020-01-09T14:22:44Z

Any news?

mstyura · 2020-03-19T16:47:54Z

@ZeWaren could you please try building jitsi-sctp following README.md from my branch on FreeBSD? In particular I suspect that some of the compiler flags (probably -Wno-address-of-packed-member ) are not supported.

licaon-kter · 2020-04-05T09:02:21Z

Any news on the merge? This makes the bridge work fine on ARM64 ;)

mstyura · 2020-04-05T21:31:30Z

With recent changes I've altered builds scripts to take into account different CPU architectures on various supported OSes

mstyura · 2020-04-06T07:18:12Z

@licaon-kter could you please check if latest changes to this PR still works for you? I've taken into account different CPU architectures per supported OS, but don't have anything with ARM to check myself if it works.

licaon-kter · 2020-04-06T17:39:19Z

@mstyura builds and runs fine for me on RPi3+ arm64 👍

Thanks for the effort.

licaon-kter · 2020-04-09T21:15:30Z

One question, trying to compile this on CentOS 6.10, I have to remove -Werror, -Wno-format-truncation -Wno-address-of-packed-member to be able to compile on GCC 4.4.7. But the resulting usrsctp jar ends up with dirty in its name and in the local maven repo entries which will trigger a fail next when the non-dirty jar is searched instead.

I've edited the local maven files to remove the "dirty" part and then it succeeded.

Is this expected on this old platform or my changes triggered it?

mstyura · 2020-04-10T07:47:23Z

@licaon-kter the durty was added because you've edited pom.xml locally and have not commited it. I'll think of ways to fix it... Thanks for reporting!

licaon-kter · 2020-04-30T13:42:24Z

Ignoring old distros, any blockers for this? I need to replace JARs after each DEB upgrade now.... :(

README.md

bbaldino · 2020-05-01T16:51:50Z

Thanks @mstyura , builds for me now. Another thought I had: I've often regretted that there isn't a good way to know which usrsctp hash is used. Does this maintain that anywhere? I'm wondering if we should include the usrsctp hash somewhere.

mstyura · 2020-05-01T17:02:23Z

Does this maintain that anywhere?

Yes! With submodule you are know exactly which version is used by jitsi-sctp repository.
I've also added git hash for usrsctp into jar name as classifier when it is built, so when you use usrsctp commit 7a8bc9a the resulting artifact will have name usrsctp-1.0-SNAPSHOT-7a8bc9a-linux-x86_64. It will also include git.properties which has more information about commit from which usrsctp is built.

usrsctp hash is also specified in inside pom.xml of jniwrapper , so jniwrapper will look for a specific version and you always will know which version is used.

bbaldino · 2020-05-01T17:12:02Z

Thanks @mstyura , builds for me now. Another thought I had: I've often regretted that there isn't a good way to know which usrsctp hash is used. Does this maintain that anywhere? I'm wondering if we should include the usrsctp hash somewhere.

Ah ha! I just read that it does. Great!

bbaldino

some doc comments--haven't finished yet

bbaldino · 2020-05-01T16:58:43Z

README.md

-### Building the jar files
-* Clone the project
-* Run `mvn package` (and `mvn install` to install locally)
+* The `usrsctp` module handles the compilation of the [`usrsctp`](https://github.com/sctplab/usrsctp).


Nit: lost some words here:

The `usrsctp` module handles the compilation of the [`usrsctp`](https://github.com/sctplab/usrsctp)

should be

The `usrsctp` module handles the compilation of the [`usrsctp`](https://github.com/sctplab/usrsctp) source library.

bbaldino · 2020-05-01T17:03:24Z

README.md

-* Clone the project
-* Run `mvn package` (and `mvn install` to install locally)
+* The `usrsctp` module handles the compilation of the [`usrsctp`](https://github.com/sctplab/usrsctp).
+This maven module produces platform specific artifact having pre-compiled `usrsctp` static library and corresponding `C` API-header.


nit: wording:

This maven module produces a platform-specific artifact containing a platform-specific build of the `usrsctp` static library and corresponding `C` API-header.

bbaldino · 2020-05-01T17:06:12Z

README.md

-* Run `mvn package` (and `mvn install` to install locally)
+* The `usrsctp` module handles the compilation of the [`usrsctp`](https://github.com/sctplab/usrsctp).
+This maven module produces platform specific artifact having pre-compiled `usrsctp` static library and corresponding `C` API-header.
+The module is build only when `build-usrsctp` profile is enabled, e.g. `-Pbuild-usrsctp` switch is passed to Maven. 


The module is built only when the build-usrsctp profile is enabled by passing the -Pbuild-usrsctp switch to mvn.

bbaldino · 2020-05-01T17:31:20Z

README.md

+                `-- SctpJni.class
+    ```
+  * The `jniwrapper-native` module contains the `C` portion of the JNI API that bridges the Java and the [`usrsctp`](https://github.com/sctplab/usrsctp) native lib.
+  The module is build only when `build-jnisctp` profile is enabled, e.g. `-Pbuild-jnisctp` switch is passed to Maven.


build -> built

and I'd phrase the second bit as: "...only when the build-jnisctp profile is enabled by passing the -Pbuild-jnisctp switch to mvn."

bbaldino · 2020-05-01T17:41:50Z

README.md

+  * The `jniwrapper-native` module contains the `C` portion of the JNI API that bridges the Java and the [`usrsctp`](https://github.com/sctplab/usrsctp) native lib.
+  The module is build only when `build-jnisctp` profile is enabled, e.g. `-Pbuild-jnisctp` switch is passed to Maven.
+  It depends on two other modules:
+    * `usrsctp` module, because it needs the pre-built `usrsctp` static library and include headers. The version of `usrsctp` artifact used is specified by property `usrsctp_commit_id` in `jniwrapper/pom.xml` and having short commit hash of pre-built `usrsctp`;


Is usrsctp_commit_id populated dynamically to the checked-out usrsctp hash when building everything at once?

@bbaldino no, right now it is "hard-coded" in the jniwrapper/pom.xml as a property.

bbaldino · 2020-05-01T18:04:01Z

@mstyura haven't made it through the readme in depth entirely yet, and I think after that I'll go through the poms a bit but seems like it's on a good track. I'm wondering, though, if we should include some bash scripts to make the common use cases easier. Something that could take in a usrsctp hash, for example, and just build everything. Thoughts?

mstyura · 2020-05-01T20:18:51Z

I'm wondering, though, if we should include some bash scripts to make the common use cases easier. Something that could take in a usrsctp hash, for example, and just build everything. Thoughts?

I could add simple bash script to build library from scratch for a current platform, which might be convenient for a developers - but it will basically mvn install -Pbuild-usrsctp -Pbuild-jnisctp -f pom.xml . I believe different and ticker script need to be added to run on Jenkins/GitHub Actions, to prepare native libraries for multiple platforms and eventually fat jar.
The usrsctp commit will be chosen by the state of submodule, so no need to provide custom hash to a script. And from my experience usrsctp updates will be rare and commit choice must be done very carefully to pick stable-enough version :)
Unfortunately I was not able to find a way to avoid hard-coding usrsctp hash in jniwrapper/pom.xml, but I hope this obstacle could be forgiven.

licaon-kter · 2020-09-08T11:01:18Z

Any news?

Move to cmake-based usrsctp build. Put static library into predictable directorly. Updated assembly descriptor. Updated assembly descriptor to properly handle cmake's single configuration generators like make as well as multi-configuration generators like VS and XCode. Use target/ directory for CMake compilation. Remove redundant entries from .gitignore. Fixed file path's included in zip. Build jnsctp (jni wrapper) with CMake. Use OS alias as destination directory. Fixed JNI library name. Added support of Windows into Sctp JNI loader. Install pdb along with dll. Specify build plugin versions in root pom. Updated usrsctp submodule. Make some CMake settings platform dependent. Move CMake flags and generator props into root pom Fixed CMake option names. Implemented platform specific artifacts. No longer need to store pre-compiled JNI libraries inside this Git repo. Fixed maven_platform_classifier. Fixed usrsctp assembly definition. Debugging CMake variable definitions on Linux. Fixing CMake's user provided variables. Removed quotes around paths. Install PDB only on Windows. Added missing groupId. Fixed MacOS X jar classifier. Fixed profile id to match other id convention. Minor pom rearrangements. Use pom packaging for native artifacts. Updated README to describe updated build procedure Corrections to README. Use pom packaging for jnilib. Use root pom with project to build specified. Workaround for GCC 9 issue. Fix make dependencies flag. Updated readme. Fixed compilation when usrsctp localed in deep dir. Updated README. Remove warning switch when build on mac. Minor fixed after self-review. Fix in README. Minor comment fix after self-review. Fixed usrsctp CMake binary directory. Include usrsctp commit id into artifact classifier Use javac -h instead of deprecated javah. https://openjdk.java.net/jeps/313 Fixed typos in readme after self review. Updated README.md. Use more stable usrsctp version. Disable unsupported warning on Mac Don't define __FUNCTION__=__func__ on Windows. Added example content of fat jar. Do nothing on install when usrsctp ins not build. Skip install target when nothing usefull is built. Undefine INET6/INET which are not needed and cause crash due to miscompilation Adds FreeBSD support. Define properties for freebsd profile. Updated README.md. Activate profile explicitly via -P switch. Use ${project.groupId} to refer to org.jitsi. maven: updated plugins verions. Added os-maven-plugin to more precise os detection. use maven platform classifier based on os-maven-plugin Renamed usrsctp_install_dir into usrsctp_cmake_install_dir delete pre-built libjnisctp.so for freebsd from git (moved to maven) jniwrapper/native: renamed cmake related properties. put freebsd profile next to linux. only include linux x86_64 and osx x86_64 into "official" fat jar. fixed native library loader to take into account CPU architecture. Updated readme to include cpu arcitecture in maven classifier. bring back freebsd and windows into fat jar to match readme. jnilib: exclude transitive dependencies of jnilib which are embedded into jar. Fix library load on mac Updated readme according to code review feedback. Disable invariants to avoid crashes due asserts. Fixed to readme according to code review.

* Trying github actions. * Fixing projects lists. * Attempt * Enable native build profiles. * Checkout submodule * Submodules. * Attempt to deploy. * Publish 2 * Attemp to fix deploy. * Attempting deploy fix. * Noop * Attemp to fix badrequest * Noop * Verbose maven. * Disable http * Change to username. * Full logs. * Adding settings. * Update version in pom.xml * Remove unnecessary switch. * Print git info. * Git fetch tags. * Git info. * Fetch all history. * Git fetch all tags. * Removed git info step. * Attemp to fix deploy of artifact with classifier. https://github.community/t5/GitHub-API-Development-and/GitHub-package-registry-as-Maven-repo-trouble-uploading-artifact/m-p/56826/highlight/true#M4777 * Deploy only one project. * Attempt to fix double upload. * Attempt to enable wagon. * Attempt to fix double-deploy. * Enable profile * Switch typo. * explicit install step. * Attach. * Attempt to join steps. * Dedicated deploy step. * Remove deploy. * Build jniwrapper-native. * Enable osx build * use api token * Disable deploy step. * Force bash shell. * Bash. * Trying upload step. * Fix upload * Name artifacts. * Download uploaded artifacts. * Fixed syntax. * Fixed sytax. * Attempt to build java. * Install. * Fixed find. * Pass file into install-file * Upload m2. * Workaround for non-expanded path. * Workaround * Attempt to build xplat. * fixed typo * Don't native deploy libraries, they are deployed being embedded into jnilib.jar * Attempt to avoid usage of personal account name. * Fetch entire history to make describe work. * Enable GitHub Actoin only on specific branches. * Deploy only if pushed into master * Fixed copy-paste.

mstyura · 2020-09-22T09:30:54Z

@licaon-kter I thinks this PR is currently blocked on unresolved issue with GitHub packages: there is no way to download artifact without authentication token, which is unfortunate for OSS projects: https://github.community/t/download-from-github-package-registry-without-authentication/14407

mstyura · 2020-09-22T09:40:08Z

It might be possible to workaround authentication by not using GitHub Packages and using some other Maven repos hosting instead to publish pre-built packages. Maybe maven centeral?

licaon-kter · 2020-09-22T09:47:12Z

All the other stuff is in some maven, I don't understand why this needs Github.

I want this and jitsi-srtp to be multi-platform since (at least on arm64) I'm stuck with these versions and I might end up incompatible with JitsiMeet elsewhere if more time passes.

mstyura · 2020-09-22T09:53:42Z

All the other stuff is in some maven, I don't understand why this needs Github.

@licaon-kter I'm completely for putting pre-built library into existing maven https://github.com/jitsi/jitsi-maven-repository from GitHub Actions. Maybe that's even possible, need to consult with someone from Jitsi Team who is aware of publishing of existing repository. Maybe @damencho or @bbaldino know if it's possible (and how ) to publish to existing maven repo from GH Action runner?
UPD: I've tried to shallow (--depth 1) clone https://github.com/jitsi/jitsi-maven-repository and it took 5.65 Gb download and took 33.4 Gb on disk. GitHub Actions runner has only 14 Gb disk, so it's not feasible to do clone, commit, push to existing maven repo, unless there is other way to upload to it.

guusdk · 2020-10-08T11:55:51Z

UPD: I've tried to shallow (--depth 1) clone https://github.com/jitsi/jitsi-maven-repository and it took 5.65 Gb download and took 33.4 Gb on disk. GitHub Actions runner has only 14 Gb disk, so it's not feasible to do clone, commit, push to existing maven repo, unless there is other way to upload to it.

I don't think that this is how that repository is managed in the first place. If I recall correctly, there was a build server that's pushing things into that repository (unless things have changed since I last was involved). At the time, it was a matter of having configured a proper job in that server, which is indeed where you'd need the help of one of the Jitsi dev team.

deleolajide · 2020-11-01T12:07:41Z

I want this and jitsi-srtp to be multi-platform since (at least on arm64) I'm stuck with these versions and I might end up incompatible with JitsiMeet elsewhere if more time passes.

That has now happened. Jitsi Meet mobile has stopped working with JVB1. Openfire Meetings is now stuck with JVB1 and cannot move to JVB2 until this issue is fixed.

bgrozev · 2020-11-02T16:53:57Z

Openfire Meetings is now stuck with JVB1 and cannot move to JVB2 until this issue is fixed.

Hey, can you add more detail on what prevents you from upgrading?

deleolajide · 2020-11-02T19:32:21Z

Hey, can you add more detail on what prevents you from upgrading?

JVB2 does not run in Windows because of the this issue

I'm currently trying to migrate to JVB 2.0, but my usual dev environment is Windows. I've noticed that jitsi-sctp is no longer supported in Windows after migration to dedicated Maven artifact. So I've added support of Windows.

#3 (comment)

I can't start making changes to the Openfire JVB plugin without a working JVB

damencho · 2020-11-02T19:52:08Z

You should migrate to using websockets, as sctp will be gone at some point: https://jitsi.github.io/handbook/docs/devops-guide/faq#how-to-migrate-away-from-multiplexing-and-enable-bridge-websockets

deleolajide · 2020-11-02T21:13:40Z

as sctp will be gone at some point:

I just updated JVB2 to latest code and rebuilt in Windows 10 and this time it worked. The SCTP exception on health checking which caused this PR has gone.

http://127.0.0.1:8080/about/version
{"name":"JVB","version":"2.1.SNAPSHOT","os":"Windows 10"}

Thank you @bgrozev and @damencho for responding 👍 I will get starting on upgrading the JVB Openfire Plugin to JVB2

deleolajide · 2020-11-02T21:21:26Z

For the record, the exception that caused this PR was

2020-11-02 21:18:59.287 SEVERE: [14] RecurringRunnableExecutor.run#230: The invocation of the method >org.jitsi.health.HealthChecker.run() threw an exception.
java.lang.UnsatisfiedLinkError: org.jitsi_modified.sctp4j.SctpJni.usrsctp_init(I)Z
at org.jitsi_modified.sctp4j.SctpJni.usrsctp_init(Native Method)
at org.jitsi_modified.sctp4j.Sctp4j.init(Sctp4j.java:41)
at org.jitsi.videobridge.sctp.SctpManager.(SctpManager.java:61)
at org.jitsi.videobridge.Endpoint.createSctpConnection(Endpoint.java:830)
at org.jitsi.videobridge.health.JvbHealthChecker$Companion.checkConference(JvbHealthChecker.kt:70)
at org.jitsi.videobridge.health.JvbHealthChecker.check(JvbHealthChecker.kt:54)
at org.jitsi.videobridge.health.JvbHealthChecker.access$check(JvbHealthChecker.kt:28)
at org.jitsi.videobridge.health.JvbHealthChecker$healthChecker$1.invoke(JvbHealthChecker.kt:36)
at org.jitsi.videobridge.health.JvbHealthChecker$healthChecker$1.invoke(JvbHealthChecker.kt:28)
at org.jitsi.health.HealthChecker.run(HealthChecker.kt:142)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.run(RecurringRunnableExecutor.java:216)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.runInThread(RecurringRunnableExecutor.java:292)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.access$000(RecurringRunnableExecutor.java:36)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor$1.run(RecurringRunnableExecutor.java:328)

bgrozev · 2020-11-02T22:23:35Z

The SCTP exception on health checking which caused this PR has gone.

Note that unless you configure web-sockets you will probably see a similar exception when a conference is created, and certainly there will be missing functionality (e.g. following the active speaker, or selecting a participant to view in high quality by clicking on them).

deleolajide · 2021-01-13T13:42:56Z

You should migrate to using websockets, as sctp will be gone at some point: https://jitsi.github.io/handbook/docs/devops-guide/faq#how-to-migrate-away-from-multiplexing-and-enable-bridge-websockets

Everything working fine with websockets instead of sctp on Windows until I tried upgrading to JVB latest stable build 2.0.5390
It creates an error loading native library: java.lang.Exception: Unsupported OS: Windows 10 even though Jitsi Meet is configured with

"openBridgeChannel": "websocket"

Is this a regression or am I missing a new parameter somewhere?

2021.01.13 13:13:27 INFO: [23] SctpManager.<clinit>#60: Initializing Sctp4j
2021.01.13 13:13:27 INFO  [Thread-17]: org.jivesoftware.openfire.plugin.ofmeet.JitsiJvbWrapper - onOutputLine Error loading native library: java.lang.Exception: Unsupported OS: Windows 10
2021.01.13 13:13:27 Exception in thread "Smack-Single Threaded Executor 1 (0)" java.lang.UnsatisfiedLinkError: org.jitsi_modified.sctp4j.SctpJni.usrsctp_init(I)Z
2021.01.13 13:13:27    at org.jitsi_modified.sctp4j.SctpJni.usrsctp_init(Native Method)
2021.01.13 13:13:27    at org.jitsi_modified.sctp4j.Sctp4j.init(Sctp4j.java:41)
2021.01.13 13:13:27    at org.jitsi.videobridge.sctp.SctpManager.<clinit>(SctpManager.java:61)
2021.01.13 13:13:27    at org.jitsi.videobridge.Endpoint.createSctpConnection(Endpoint.java:879)
2021.01.13 13:13:27    at org.jitsi.videobridge.shim.ContentShim.createSctpConnection(ContentShim.java:167)
2021.01.13 13:13:27    at org.jitsi.videobridge.shim.ContentShim.getOrCreateSctpConnectionShim(ContentShim.java:359)
2021.01.13 13:13:27    at org.jitsi.videobridge.shim.VideobridgeShim.processSctpConnections(VideobridgeShim.java:211)
2021.01.13 13:13:27    at org.jitsi.videobridge.shim.VideobridgeShim.handleColibriConferenceIQ(VideobridgeShim.java:341)
2021.01.13 13:13:27    at org.jitsi.videobridge.Videobridge.handleColibriConferenceIQ(Videobridge.java:363)
2021.01.13 13:13:27    at org.jitsi.videobridge.Videobridge$XmppConnectionEventHandler.colibriConferenceIqReceived(Videobridge.java:627)
2021.01.13 13:13:27    at org.jitsi.videobridge.xmpp.XmppConnection$handleIqRequest$4.invoke(XmppConnection.kt:179)
2021.01.13 13:13:27    at org.jitsi.videobridge.xmpp.XmppConnection$handleIqRequest$4.invoke(XmppConnection.kt:41)
2021.01.13 13:13:27    at org.jitsi.videobridge.xmpp.XmppConnection.measureDelay(XmppConnection.kt:198)
2021.01.13 13:13:27    at org.jitsi.videobridge.xmpp.XmppConnection.handleIqRequest(XmppConnection.kt:178)
2021.01.13 13:13:27    at org.jitsi.videobridge.xmpp.XmppConnection.handleIq(XmppConnection.kt:163)
2021.01.13 13:13:27    at org.jitsi.xmpp.mucclient.IQListener.handleIq(IQListener.java:50)
2021.01.13 13:13:27    at org.jitsi.xmpp.mucclient.MucClient.handleIq(MucClient.java:501)
2021.01.13 13:13:27    at org.jitsi.xmpp.mucclient.MucClient.access$300(MucClient.java:50)
2021.01.13 13:13:27    at org.jitsi.xmpp.mucclient.MucClient$2.handleIQRequest(MucClient.java:466)
2021.01.13 13:13:27    at org.jivesoftware.smack.AbstractXMPPConnection$4.run(AbstractXMPPConnection.java:1188)
2021.01.13 13:13:27    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
2021.01.13 13:13:27    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
2021.01.13 13:13:27    at java.lang.Thread.run(Thread.java:748)

bgrozev · 2021-01-13T17:08:28Z

You can now disable it in the config of jitsi-videobridge (videobridge.sctp.enabled=false) and/or jicofo (jicofo.sctp.enabled=false).

mstyura force-pushed the master branch from 2fe22a4 to 922ab61 Compare November 1, 2019 12:44

mstyura mentioned this pull request Dec 18, 2019

cross compilation improvements #4

Open

bbaldino mentioned this pull request Mar 17, 2020

Adds FreeBSD support #5

Merged

dubit0 mentioned this pull request Apr 4, 2020

i can't run jitsi mett on armbian 64 (ubuntu 18.04 arm 64) jitsi/docker-jitsi-meet#195

Closed

bbaldino requested changes Apr 30, 2020

View reviewed changes

README.md Show resolved Hide resolved

README.md Outdated Show resolved Hide resolved

bbaldino reviewed May 1, 2020

View reviewed changes

README.md Show resolved Hide resolved

bbaldino reviewed May 1, 2020

View reviewed changes

bbaldino mentioned this pull request May 7, 2020

double free or corruption in sctp_free_assoc #7

Open

deleolajide mentioned this pull request Aug 30, 2020

A few connection issues igniterealtime/openfire-ofmeet-plugin#58

Closed

licaon-kter mentioned this pull request Sep 8, 2020

NoClassDefFoundError JdkDeserializers since 2.1-273-g072dd44b-1 jitsi/jitsi-videobridge#1412

Closed

mstyura force-pushed the master branch 2 times, most recently from 8b3fe39 to ed84714 Compare September 22, 2020 08:55

mstyura changed the title ~~Added Windows support. Migrated on CMake to build native libraries.~~ Added Windows support. Migrated on CMake to build native libraries. GitHub Actions + GitHub Packages Registry. Sep 22, 2020

mstyura added 2 commits September 22, 2020 12:06

mstyura force-pushed the master branch from ed84714 to 1d5e98b Compare September 22, 2020 09:06

deleolajide mentioned this pull request Nov 17, 2020

Can't establish Audio/Video-streams using App Jitsi Meet 20.4. igniterealtime/openfire-pade-plugin#76

Closed

deleolajide mentioned this pull request Nov 26, 2020

Is HttpBind not supported since Version 1.1.X? igniterealtime/openfire-pade-plugin#100

Closed

naive924 mentioned this pull request Dec 7, 2020

Wrong URL path colibiri-ws igniterealtime/openfire-pade-plugin#119

Closed

This comment was marked as spam.

Sign in to view

JonathanLennox mentioned this pull request Feb 14, 2024

Use GitHub actions to build SCTP native binaries. #24

Merged

Added Windows support. Migrated on CMake to build native libraries. GitHub Actions + GitHub Packages Registry. #3

Are you sure you want to change the base?

Added Windows support. Migrated on CMake to build native libraries. GitHub Actions + GitHub Packages Registry. #3

Conversation

mstyura commented Sep 4, 2019 • edited Loading

mstyura commented Sep 4, 2019

bbaldino commented Sep 4, 2019

mstyura commented Sep 4, 2019

bbaldino commented Sep 11, 2019

mstyura commented Oct 30, 2019

bbaldino commented Oct 30, 2019

mstyura commented Oct 30, 2019

MMX777 commented Jan 9, 2020

mstyura commented Mar 19, 2020

licaon-kter commented Apr 5, 2020

mstyura commented Apr 5, 2020

mstyura commented Apr 6, 2020

licaon-kter commented Apr 6, 2020

licaon-kter commented Apr 9, 2020

mstyura commented Apr 10, 2020

licaon-kter commented Apr 30, 2020

bbaldino commented May 1, 2020

mstyura commented May 1, 2020

bbaldino commented May 1, 2020

bbaldino left a comment

Choose a reason for hiding this comment

bbaldino May 1, 2020

Choose a reason for hiding this comment

bbaldino May 1, 2020

Choose a reason for hiding this comment

bbaldino May 1, 2020

Choose a reason for hiding this comment

bbaldino May 1, 2020

Choose a reason for hiding this comment

bbaldino May 1, 2020

Choose a reason for hiding this comment

bbaldino May 1, 2020

Choose a reason for hiding this comment

mstyura May 1, 2020

Choose a reason for hiding this comment

bbaldino commented May 1, 2020

mstyura commented May 1, 2020

licaon-kter commented Sep 8, 2020

mstyura commented Sep 22, 2020

mstyura commented Sep 22, 2020

licaon-kter commented Sep 22, 2020

mstyura commented Sep 22, 2020 • edited Loading

guusdk commented Oct 8, 2020

deleolajide commented Nov 1, 2020

bgrozev commented Nov 2, 2020

deleolajide commented Nov 2, 2020

damencho commented Nov 2, 2020

deleolajide commented Nov 2, 2020

deleolajide commented Nov 2, 2020

bgrozev commented Nov 2, 2020

deleolajide commented Jan 13, 2021 • edited Loading

bgrozev commented Jan 13, 2021

This comment was marked as spam.

mstyura commented Sep 4, 2019 •

edited

Loading

mstyura commented Sep 22, 2020 •

edited

Loading

deleolajide commented Jan 13, 2021 •

edited

Loading