powered by Jive Software

Openfire Meetings as an alternative to Zoom

If you are a small and medium business and already have Openfire setup and running for chat and groupchat using Spark, Inverse or Pàdé and you want to provide secure video or audio conferencing with authentication for your users from password-protected chat rooms using permissions and configurations already made to Openfire, then you should be looking at Openfire Meetings.

Also consider Openfire Meetings as an alternative to Zoom if the audio and/or video from your meetings needs to be recorded by participants and later played back from their desktops and mobile devices.without downloading any external software or installing any app on their mobile devices.

First, there are few things you need to know. These include:

  1. Openfire meetings does not work properly with Firefox. It works best with Chromium based apps like Chrome, Edge, Electron and Opera. If this is a dealbreaker for you, please move on and download Zoom.

  2. There a two versions available at Ignite. The official version (0.9.5) combines both the offocus and ofmeet plugin into a single package. It is lagging behind the current versions of the jitsi dependencies. Expect an upgrade soon to the new jitsi videobridge2 implementation.

  3. The second version (0.9.8) is a fork of the first at (0.9.4) and customized for Pade. It has latest versions of all jitsi dependency code and the extra feature to record a conference from the browser.

  4. Openfire Meetings will not work out of the box if your Openfire server is configured to use LDAP. You would need to create the Jitsi focus bot user and give it owner/admin permmissions to the MUC service manually.

  5. Openfire Meetings has minimal network requirements and works out of the box internally on a local area network (LAN) or with a hosted Openfire server on the internet. If your Openfire server is placed behind a NAT and firewall and you want to allow external internet access, then you require some network expertise to configure it. You would need to open a few UDP/TCP ports and provide both the public and private IP addresses of your openfire server.

To use Openfire Meetings version 0.9.8, download from here and upload the ofmeet.jar and offocus.jar plugin files in any order from the admin web console of Openfire. Wait for both to appear in the plugins listing and then complete the following three steps to confirm it is working.

  1. Confirm the focus bot user has logged in ok like this. If not, check log files and get help from the igniterealtime community.
    image

  2. If you have an active focus user, then you can do a quick peer-to-peer test with two browser tabs on your desktop. Open both of them to the same htps://your_server:7443/ofmeet/testconf and confirm that it is showing in the conference summary like this

  3. If you get audio and video, then focus bot user is working ok and XMPP messages are passing around ok. If not, it is back to the log files and help from the community.

  4. To confirm the video-bridge is working, you need to run step 3 again with 3 users. If audio and video stops with third participant, then double check on the network configuration, making sure TCP port 7443 and UDP port 10000 are opened for listening from the openfire server. Otherwise, check the log files and ask for help from ignte-realtime community.

Stay safe and best of luck :slight_smile:

For other release announcements and news follow us on Twitter

5 Likes

In step 2., where you have a summary of the meeting conferences, where do you find that??? Definatly not under the meetings tab in 4.3.2 or 4.5.1??
image

The summary is only available in 0.9.8. It is not in 0.9.5

Thank you very much @Dele_Olajide
Finally after 3 days of searching, Openfire meeting working now.

With Java openjdk-11-jdk, not with openjdk-8-jdk
my server is Ubuntu 18

Are there any other guides on how to install and configure this? Im using it on Openfire V 4.5.1 with OFMeet version 0.9.5. I installed the plugin, I created a user with the username “focus” in my activedirectory environment (im using LDAP for authentication which works fine for all users). Whenever i enter https://server:7443/ofmeet/testconf Im just immediately greeted with “You have been disconnected check your network connection” and thats it.

Try using version 0.9.8 and complete the 3 steps above to debug where the issue is.

Thanks I found my issue. Its related to my certificate for SSL as it works fine using http. Of course Chrome doesn’t allow video or audio over http now so I have to find out how to do a self signed cert to see if that works.

A self-signed certificate will only cause you more grief. Use letsencrypt to get a free one.

Dele-
Thank you for the work you’ve put in with the Inverse and OF meetings plugins (you and the rest of the developers are doing some awesome things here). I’ve been working on getting the OF meetings working and was able to follow through on your steps listed above. I’ve tested and gotten to step 4. I can’t seem to figure out the issue with the video-bridge working properly. As soon as a 3rd participant joins the call, audio and video is lost for everyone. As soon as the call drops back down to 2 participants, everything is back to normal. I’ve checked to make sure that port 10000 is open and confirmed by running a netstat. In the all.log, I keep finding this happening. Maybe this is the cause of the bridge not working?

org.ice4j.ice.harvest.HostCandidateHarvester - Retrying a bind because of a failure to bind to address /192.168.11.82 and port 10001 (Address already in use: Cannot bind)
2020.04.20 11:44:10 INFO [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-org.jitsi.videobridge.health.Health]: org.ice4j.ice.harvest.HostCandidateHarvester - Retrying a bind because of a failure to bind to address /192.168.11.82 and port 10002 (Address already in use: Cannot bind)
2020.04.20 11:44:10 INFO [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-org.jitsi.videobridge.health.Health]: org.ice4j.ice.harvest.HostCandidateHarvester - Retrying a bind because of a failure to bind to address /192.168.11.82 and port 10003 (Address already in use: Cannot bind)
2020.04.20 11:44:10 INFO [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-org.jitsi.videobridge.health.Health]: org.ice4j.ice.harvest.HostCandidateHarvester - Retrying a bind because of a failure to bind to address /192.168.11.82 and port 10004 (Address already in use: Cannot bind)
2020.04.20 11:44:10 INFO [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-org.jitsi.videobridge.health.Health]: org.ice4j.ice.harvest.HostCandidateHarvester - Retrying a bind because of a failure to bind to address /192.168.11.82 and port 10002 (Address already in use: Cannot bind)
2020.04.20 11:44:10 INFO [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-org.jitsi.videobridge.health.Health]: org.ice4j.ice.harvest.HostCandidateHarvester - Retrying a bind because of a failure to bind to address /192.168.11.82 and port 10003 (Address already in use: Cannot bind)
2020.04.20 11:44:10 INFO [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-org.jitsi.videobridge.health.Health]: org.ice4j.ice.harvest.HostCandidateHarvester - Retrying a bind because of a failure to bind to address /192.168.11.82 and port 10004 (Address already in use: Cannot bind)
2020.04.20 11:44:10 INFO [org.jitsi.utils.concurrent.RecurringRunnableExecutor.thread-org.jitsi.videobridge.health.Health]: org.ice4j.ice.harvest.HostCandidateHarvester - Retrying a bind because of a failure to bind to address /192.168.11.82 and port 10005 (Address already in use: Cannot bind)

This suggests that the ports are already being used by something else. Could be another user, or another process completely. Or perhaps you’re somehow running two versions of Openfire/OFMeet at the same time by mistake?

Can you use netstat to determine what process has bound these ports (10000+ UDP)?

Thanks for replying, Guus. Strange thing is i don’t see anything in the 10000 range listening. Here’s a listing of the current netstat output. 4560 is the current PID for the openfire process. On a side note, is there supposed to be a second openfire-service.exe running? BTW, this is a server 2016 VM (sorry for leaving that information out):
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:135 chitchat:0 LISTENING 740
TCP 0.0.0.0:445 chitchat:0 LISTENING 4
TCP 0.0.0.0:3389 chitchat:0 LISTENING 888
TCP 0.0.0.0:5222 chitchat:0 LISTENING 4560
TCP 0.0.0.0:5223 chitchat:0 LISTENING 4560
TCP 0.0.0.0:5229 chitchat:0 LISTENING 4560
TCP 0.0.0.0:5262 chitchat:0 LISTENING 4560
TCP 0.0.0.0:5263 chitchat:0 LISTENING 4560
TCP 0.0.0.0:5269 chitchat:0 LISTENING 4560
TCP 0.0.0.0:5270 chitchat:0 LISTENING 4560
TCP 0.0.0.0:5275 chitchat:0 LISTENING 4560
TCP 0.0.0.0:5276 chitchat:0 LISTENING 4560
TCP 0.0.0.0:5985 chitchat:0 LISTENING 4
TCP 0.0.0.0:7070 chitchat:0 LISTENING 4560
TCP 0.0.0.0:7443 chitchat:0 LISTENING 4560
TCP 0.0.0.0:7777 chitchat:0 LISTENING 4560
TCP 0.0.0.0:8888 chitchat:0 LISTENING 4560
TCP 0.0.0.0:9090 chitchat:0 LISTENING 4560
TCP 0.0.0.0:9091 chitchat:0 LISTENING 4560
TCP 0.0.0.0:47001 chitchat:0 LISTENING 4
TCP 0.0.0.0:49664 chitchat:0 LISTENING 456
TCP 0.0.0.0:49665 chitchat:0 LISTENING 940
TCP 0.0.0.0:49667 chitchat:0 LISTENING 604
TCP 0.0.0.0:49671 chitchat:0 LISTENING 1208
TCP 0.0.0.0:49675 chitchat:0 LISTENING 1944
TCP 0.0.0.0:49696 chitchat:0 LISTENING 588
TCP 0.0.0.0:49714 chitchat:0 LISTENING 1760
TCP 0.0.0.0:59051 chitchat:0 LISTENING 604
TCP 127.0.0.1:59125 chitchat:59126 ESTABLISHED 4560
TCP 127.0.0.1:59126 chitchat:59125 ESTABLISHED 4560
TCP 127.0.0.1:59127 chitchat:59128 ESTABLISHED 4560
TCP 127.0.0.1:59128 chitchat:59127 ESTABLISHED 4560
TCP 127.0.0.1:59129 chitchat:59130 ESTABLISHED 4560
TCP 127.0.0.1:59130 chitchat:59129 ESTABLISHED 4560
TCP 127.0.0.1:59131 chitchat:59132 ESTABLISHED 4560
TCP 127.0.0.1:59132 chitchat:59131 ESTABLISHED 4560
TCP 127.0.0.1:59140 chitchat:59141 ESTABLISHED 4560
TCP 127.0.0.1:59141 chitchat:59140 ESTABLISHED 4560
TCP 127.0.0.1:59142 chitchat:59143 ESTABLISHED 4560
TCP 127.0.0.1:59143 chitchat:59142 ESTABLISHED 4560
TCP 127.0.0.1:59144 chitchat:59145 ESTABLISHED 4560
TCP 127.0.0.1:59145 chitchat:59144 ESTABLISHED 4560
TCP 127.0.0.1:59146 chitchat:59147 ESTABLISHED 4560
TCP 127.0.0.1:59147 chitchat:59146 ESTABLISHED 4560
TCP 127.0.0.1:59148 chitchat:59149 ESTABLISHED 4560
TCP 127.0.0.1:59149 chitchat:59148 ESTABLISHED 4560
TCP 127.0.0.1:59150 chitchat:59151 ESTABLISHED 4560
TCP 127.0.0.1:59151 chitchat:59150 ESTABLISHED 4560
TCP 127.0.0.1:59152 chitchat:59153 ESTABLISHED 4560
TCP 127.0.0.1:59153 chitchat:59152 ESTABLISHED 4560
TCP 127.0.0.1:59154 chitchat:59155 ESTABLISHED 4560
TCP 127.0.0.1:59155 chitchat:59154 ESTABLISHED 4560
TCP 127.0.0.1:59156 chitchat:59157 ESTABLISHED 4560
TCP 127.0.0.1:59157 chitchat:59156 ESTABLISHED 4560
TCP 127.0.0.1:59158 chitchat:59159 ESTABLISHED 4560
TCP 127.0.0.1:59159 chitchat:59158 ESTABLISHED 4560
TCP 127.0.0.1:59160 chitchat:59161 ESTABLISHED 4560
TCP 127.0.0.1:59161 chitchat:59160 ESTABLISHED 4560
TCP 127.0.0.1:59162 chitchat:59163 ESTABLISHED 4560
TCP 127.0.0.1:59163 chitchat:59162 ESTABLISHED 4560
TCP 127.0.0.1:59164 chitchat:59165 ESTABLISHED 4560
TCP 127.0.0.1:59165 chitchat:59164 ESTABLISHED 4560
TCP 127.0.0.1:59166 chitchat:59167 ESTABLISHED 4560
TCP 127.0.0.1:59167 chitchat:59166 ESTABLISHED 4560
TCP 127.0.0.1:59168 chitchat:59169 ESTABLISHED 4560
TCP 127.0.0.1:59169 chitchat:59168 ESTABLISHED 4560
TCP 127.0.0.1:59170 chitchat:59171 ESTABLISHED 4560
TCP 127.0.0.1:59171 chitchat:59170 ESTABLISHED 4560
TCP 127.0.0.1:59172 chitchat:59173 ESTABLISHED 4560
TCP 127.0.0.1:59173 chitchat:59172 ESTABLISHED 4560
TCP 127.0.0.1:59174 chitchat:59175 ESTABLISHED 4560
TCP 127.0.0.1:59175 chitchat:59174 ESTABLISHED 4560
TCP 127.0.0.1:59176 chitchat:59177 ESTABLISHED 4560
TCP 127.0.0.1:59177 chitchat:59176 ESTABLISHED 4560
TCP 127.0.0.1:59178 chitchat:59179 ESTABLISHED 4560
TCP 127.0.0.1:59179 chitchat:59178 ESTABLISHED 4560
TCP 127.0.0.1:59180 chitchat:59181 ESTABLISHED 4560
TCP 127.0.0.1:59181 chitchat:59180 ESTABLISHED 4560
TCP 127.0.0.1:59182 chitchat:59183 ESTABLISHED 4560
TCP 127.0.0.1:59183 chitchat:59182 ESTABLISHED 4560
TCP 127.0.0.1:59184 chitchat:59185 ESTABLISHED 4560
TCP 127.0.0.1:59185 chitchat:59184 ESTABLISHED 4560
TCP 127.0.0.1:59186 chitchat:59187 ESTABLISHED 4560
TCP 127.0.0.1:59187 chitchat:59186 ESTABLISHED 4560
TCP 127.0.0.1:59192 chitchat:59193 ESTABLISHED 4560
TCP 127.0.0.1:59193 chitchat:59192 ESTABLISHED 4560
TCP 127.0.0.1:59194 chitchat:59195 ESTABLISHED 4560
TCP 127.0.0.1:59195 chitchat:59194 ESTABLISHED 4560
TCP 127.0.0.1:59196 chitchat:59197 ESTABLISHED 4560
TCP 127.0.0.1:59197 chitchat:59196 ESTABLISHED 4560
TCP 192.168.11.82:139 chitchat:0 LISTENING 4
TCP 192.168.11.82:443 chitchat:0 LISTENING 4560
TCP 192.168.11.82:445 work-pc:64895 ESTABLISHED 4
TCP 192.168.11.82:7443 home-ip-redacted:40682 ESTABLISHED 4560
TCP 192.168.11.82:7443 home-ip-redacted:40960 ESTABLISHED 4560
TCP 192.168.11.82:7443 home-ip-redacted:46324 ESTABLISHED 4560
TCP 192.168.11.82:7443 home-ip-redacted:46486 TIME_WAIT 0
TCP 192.168.11.82:7443 home-ip-redacted:58099 ESTABLISHED 4560
TCP 192.168.11.82:7443 home-ip-redacted:58251 FIN_WAIT_2 4560
TCP 192.168.11.82:49715 52.179.224.121:https ESTABLISHED 1208
TCP 192.168.11.82:59092 fsh:microsoft-ds ESTABLISHED 4
TCP 192.168.11.82:59101 52.179.224.121:https ESTABLISHED 3200
TCP 192.168.11.82:59271 Domainctl:ldap ESTABLISHED 4560
TCP 192.168.11.82:59273 Domainctl:ldap ESTABLISHED 4560
TCP 192.168.11.82:59278 cell-ip-redacted:http TIME_WAIT 0
TCP [::]:135 chitchat:0 LISTENING 740
TCP [::]:445 chitchat:0 LISTENING 4
TCP [::]:3389 chitchat:0 LISTENING 888
TCP [::]:5222 chitchat:0 LISTENING 4560
TCP [::]:5223 chitchat:0 LISTENING 4560
TCP [::]:5229 chitchat:0 LISTENING 4560
TCP [::]:5262 chitchat:0 LISTENING 4560
TCP [::]:5263 chitchat:0 LISTENING 4560
TCP [::]:5269 chitchat:0 LISTENING 4560
TCP [::]:5270 chitchat:0 LISTENING 4560
TCP [::]:5275 chitchat:0 LISTENING 4560
TCP [::]:5276 chitchat:0 LISTENING 4560
TCP [::]:5985 chitchat:0 LISTENING 4
TCP [::]:7070 chitchat:0 LISTENING 4560
TCP [::]:7443 chitchat:0 LISTENING 4560
TCP [::]:7777 chitchat:0 LISTENING 4560
TCP [::]:8888 chitchat:0 LISTENING 4560
TCP [::]:9090 chitchat:0 LISTENING 4560
TCP [::]:9091 chitchat:0 LISTENING 4560
TCP [::]:47001 chitchat:0 LISTENING 4
TCP [::]:49664 chitchat:0 LISTENING 456
TCP [::]:49665 chitchat:0 LISTENING 940
TCP [::]:49667 chitchat:0 LISTENING 604
TCP [::]:49671 chitchat:0 LISTENING 1208
TCP [::]:49675 chitchat:0 LISTENING 1944
TCP [::]:49696 chitchat:0 LISTENING 588
TCP [::]:49714 chitchat:0 LISTENING 1760
TCP [::]:59051 chitchat:0 LISTENING 604
UDP 0.0.0.0:123 : 948
UDP 0.0.0.0:500 : 1208
UDP 0.0.0.0:3389 : 888
UDP 0.0.0.0:4500 : 1208
UDP 0.0.0.0:5050 : 948
UDP 0.0.0.0:5353 : 336
UDP 0.0.0.0:5355 : 336
UDP 0.0.0.0:23021 : 4560
UDP 0.0.0.0:47620 : 4560
UDP 127.0.0.1:1900 : 1380
UDP 127.0.0.1:50029 : 696
UDP 127.0.0.1:52016 : 1208
UDP 127.0.0.1:52606 : 1380
UDP 127.0.0.1:59084 : 604
UDP 127.0.0.1:59227 : 336
UDP 192.168.11.82:137 : 4
UDP 192.168.11.82:138 : 4
UDP 192.168.11.82:1900 : 1380
UDP 192.168.11.82:10000 : 4560
UDP 192.168.11.82:52605 : 1380
UDP [::]:123 : 948
UDP [::]:500 : 1208
UDP [::]:3389 : 888
UDP [::]:4500 : 1208
UDP [::]:5353 : 336
UDP [::]:5355 : 336
UDP [::]:23021 : 4560
UDP [::]:47620 : 4560
UDP [::1]:1900 : 1380
UDP [::1]:52604 : 1380
UDP [fe80::9c7b:e051:8b39:3b96%3]:1900 : 1380
UDP [fe80::9c7b:e051:8b39:3b96%3]:52603 : 1380

I’m running on Linux exclusively, so I can’t be sure - but I do not think so. If you search this site, you’ll find various references at people accidentally running Openfire twice (once as a service, and once invoked directly). My suspicion is that something similar is going on on your end.

Definitely shouldn’t be two openfire-service.exe running. Unless the user means that, which is ok. A service is starting as a child process of executable sitting in the bin folder.
image

1 Like

Thanks Guus and wroot. I used process explorer and verified what wroot said: it looks like the service is starting a child process: Capture .
I can’t see any other instances of openfire running. Is there somewhere else I should be checking for a multiple instances?
Thank you both for taking time to help me with the issue :slight_smile:

I think you are fine and your issues are not related to multiple instances running.

Don’t know if this might ring a bell, but something that I’ve observed. Right now I’m working remotely from home and have temporarily set up a rule on our firewall to allow any traffic from my home IP to hit the NAT’d address of my Openfire server. I tested this with another colleage working remotely and we were able to conduct a point-to-point meeting with no issue (looked awesome). But when I try to connect from an endpoint in the office (different subnet, but same private network as Openfire server) to the same meeting room as i’m connected to from my home computer, i experience the same issue as if 3 parties were trying to connect.

You may need network expertise to make Jitsi video bridge work from an Openfire server behind NAT. At best you just need to specify the public and private IP addresses and it could start working. At worse, you may need to to some configuration on your network routers. Unfortunately, all that network stuff is above my pay grade.

I don’t remember where I found this, but add the following system property:

org.jitsi.videobridge.ofmeet.desktop.sharing.chrome.enabled 	true
org.jitsi.videobridge.ofmeet.min.chrome.ext.ver 	59