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:
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.
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.
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.
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.
Confirm the focus bot user has logged in ok like this. If not, check log files and get help from the igniterealtime community.
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
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.
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.
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.
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.
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)?
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.
Thanks Guus and wroot. I used process explorer and verified what wroot said: it looks like the service is starting a child process: .
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
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 have openfire 4.8.1 server up and running used as IM for chat and group chat with android client
based on XMPP using SMACK 4.4.7, can i use openfire meeting in my case???
.