Goal of this guide

This guide shows how to install, enable, test and fix grommunio Meet on a grommunio 2026.06.1 appliance. The goal is not merely opening the UI. The important part is that multiple users can join the same room and that the connection remains stable afterwards.

  • You install the Meet/Jitsi components on the existing appliance.

  • You enable the Meet plugin for grommunio Web.

  • You validate Prosody, Jicofo, Videobridge, nginx and the Meet routes.

  • You recognise `videobridgeNotAvailable` and an unhealthy JVB.

  • You fix Jicofo configuration, JVB configuration, Colibri WebSocket, UDP 10000 and ICE/NAT mapping.

  • You test two and three participants with real browser sessions.

The grommunio series stays intentionally practical: first install grommunio 2026.06.1, then grommunio-auth with Keycloak, grommunio-antispam with Rspamd and now grommunio Meet. Product context is available on the grommunio product page.

Architecture: what works together in Meet

grommunio Meet is based on Jitsi components. The web UI loads the room, Prosody handles XMPP signalling, Jicofo orchestrates conferences and Jitsi Videobridge forwards audio/video streams as an SFU. That is why HTTP 200 on `/meet/` is not enough for acceptance: if UDP, ICE or the Videobridge are wrong, the room may look fine at first and only fail when the second or third participant joins.

Browser
  -> /meet/ through nginx
  -> /meet/http-bind or /meet/xmpp-websocket
  -> Prosody
  -> Jicofo
  -> Jitsi Videobridge
  -> UDP 10000 for media and Colibri WebSocket for the control channel

Prerequisites

  • A working grommunio 2026.06.1 appliance with a valid FQDN.

  • Working HTTPS access to grommunio Web and grommunio Admin.

  • DNS, firewall and reverse proxy must match the FQDN in use.

  • For production use, clients must be able to reach UDP `10000` on the Videobridge.

  • If the Videobridge is behind NAT or in a private network, you need correct ICE/NAT mapping.

  • You need administrative shell access to the appliance.

Install Meet

On the validated appliance Prosody was already present, but Jicofo, Jitsi Meet and Jitsi Videobridge were installed by the Meet setup. First check whether the packages are already present.

bash
rpm -qa | egrep 'jitsi|prosody|grommunio-web' | sort
systemctl is-enabled prosody jitsi-jicofo jitsi-videobridge 2>/dev/null || true

The grommunio appliance ships a setup part for Meet. Use the real FQDN of your environment. In the validated test environment this was `mail.example.test`.

bash
export FQDN="$(hostname -f)"
/usr/share/grommunio-setup/parts/grommunio-meet.sh

After setup, Prosody, Jicofo and Videobridge must be active. This is where Jicofo initially failed in the test because the systemd unit did not read the expected config path.

bash
systemctl status --no-pager prosody jitsi-jicofo jitsi-videobridge
journalctl -u jitsi-jicofo -n 120 --no-pager
journalctl -u jitsi-videobridge -n 120 --no-pager

Enable Meet in grommunio Web

grommunio Web loads Meet through the existing Meet plugin. Check the configuration and enable the plugin deliberately. Afterwards restart the web/PHP components.

bash
grep -R "meet" -n /etc/grommunio-web /usr/share/grommunio-web/plugins/meet 2>/dev/null | head -80


# /etc/grommunio-web/config-meet.php
# Der Eintrag muss sinngemäß aktiv sein:
# 'enable' => true,


systemctl restart nginx php-fpm

Then validate the public Meet routes. `/meet/`, `/meet/config.js`, `/meet/http-bind`, `/meet/xmpp-websocket` and the Colibri WebSocket paths must be reachable through the same FQDN that users use in the browser.

bash
curl -kI https://mail.example.test/meet/
curl -kI https://mail.example.test/meet/config.js
curl -kI https://mail.example.test/meet/test-room
https://mail.example.test/meet/forgeone-meet-stability

Screenshot: The Meet room loads and shows the join dialog. This alone is not a technical acceptance test.

Jicofo fix: set the config path explicitly

In the test, Jicofo did not start cleanly at first. The message was essentially that Jicofo needs a configuration file and expects `JAVA_SYS_PROPS` with `-Dconfig.file=...`. The robust fix is an explicit `/etc/jitsi/jicofo/config` and a clear HOCON file.

bash
cat >/etc/jitsi/jicofo/config <<'EOF'
JAVA_SYS_PROPS="-Dconfig.file=/etc/jitsi/jicofo/jicofo.conf"
EOF


# /etc/jitsi/jicofo/jicofo.conf
jicofo {
  xmpp {
    client {
      hostname = "localhost"
      port = 5222
      domain = "auth.mail.example.test"
      xmpp-domain = "mail.example.test"
      username = "focus"
      password = "<generated-focus-password>"
      conference-muc-jid = "conference.mail.example.test"
      client-proxy = "focus.mail.example.test"
      disable-certificate-verification = true
    }
    trusted-domains = [ "recorder.mail.example.test" ]
  }
  bridge {
    brewery-jid = "JvbBrewery@internal.auth.mail.example.test"
  }
}


systemctl restart jitsi-jicofo
systemctl is-active jitsi-jicofo

Do not publish passwords or generated XMPP secrets in tickets, screenshots or blog posts. This guide therefore uses a placeholder.

JVB fix: load config, set WebSocket, validate UDP and ICE

The Videobridge must actually load its HOCON configuration. In the validated package layout this required a systemd override. Without it, a clean-looking file may exist while JVB still ignores it.

bash
mkdir -p /etc/systemd/system/jitsi-videobridge.service.d
cat >/etc/systemd/system/jitsi-videobridge.service.d/override.conf <<'EOF'
[Service]
Environment=JAVA_SYS_PROPS=-Dconfig.file=/etc/jitsi/videobridge/jvb.conf
EOF


systemctl daemon-reload

For an internal or NAT topology, separate two things: the local bridge address and the address clients can actually reach. In our validated internal environment the bridge inside the VM was `10.0.2.15`, while the browser reached it through the internal host address. In production, replace these values with your real addresses.

bash
# /etc/jitsi/videobridge/jvb.conf
videobridge {
  http-servers {
    public {
      host = 0.0.0.0
      port = 9090
      send-server-version = false
    }
    private {
      port = 8081
      tls-port = -1
    }
  }
  health {
    # Für rein interne 10.x-Topologien sinnvoll; bei Public Deployments vorher bewusst prüfen.
    require-valid-address = false
  }
  websockets {
    enabled = true
    domains = [ "mail.example.test:443" ]
    tls = true
  }
  apis.xmpp-client.configs {
    shard {
      hostname = "localhost"
      domain = "auth.mail.example.test"
      username = "jvb"
      password = "<generated-jvb-password>"
      muc_jids = "JvbBrewery@internal.auth.mail.example.test"
      muc_nickname = "<unique-bridge-id>"
      disable-certificate-verification = true
    }
  }
}


ice4j {
  harvest {
    use-ipv6 = false
    mapping {
      aws.enabled = false
      stun.enabled = false
      static-mappings = [
        {
          local-address = "10.0.2.15"
          public-address = "10.10.0.12"
        }
      ]
    }
  }
}


systemctl restart jitsi-videobridge jitsi-jicofo

Important: `public-address` is not automatically a public Internet address. It is the address your clients can reach. In an internal-only deployment this can be an internal 10.x address. For external participants it must be the externally reachable address, and firewall/NAT must forward UDP `10000` accordingly.

bash
ss -lntup | egrep '(:10000|:5222|:5280|:5281|:8081|:9090)' || true
journalctl -u jitsi-videobridge -n 120 --no-pager | egrep -i 'static mapping|Authenticated|Joined MUC|Health|No valid IP|SEVERE|ERROR' || true
curl -sS -w 'HTTP_STATUS=%{http_code}\n' http://127.0.0.1:8081/about/health || true

Failure pattern: when the second participant breaks everything

The typical failure is deceptive. The first user can open the room, the second user may join briefly, then participants disappear, the UI shows reconnect and the browser reports `conference.videobridgeNotAvailable` or the BridgeChannel closes.

CONFERENCE FAILED: conference.videobridgeNotAvailable
BridgeChannel closed
triggering ice restart


# Serverseitig war das entscheidende Signal:
Health check failed: No valid IP addresses available for harvesting.

In our test, the cause was not grommunio Web and not the room itself. Jicofo, Prosody and JVB had to work together correctly, and the media path through UDP `10000` had to be reachable by clients.

Test two users

Do not test Meet with a single browser window. Use two separate browser contexts, two profiles or two real devices. Both users must see the same room and the participant count must remain stable.

https://mail.example.test/meet/forgeone-meet-stability

Screenshot: The first user is in the room. The video comes from a test device to keep the flow reproducible.

https://mail.example.test/meet/forgeone-meet-stability

Screenshot: After the fix, two separate browser sessions remain connected in the same room.

Acceptance criteria for two users:
- both click "Join"
- both see the other participant
- participant count remains at 2
- no failed /meet or /colibri-ws requests
- no videobridgeNotAvailable
- no ICE restart
- no BridgeChannel close

Test three users and stability

The second test goes further: three separate browser sessions join the same room. The test does not stop immediately afterwards; it checks the room after 30, 60 and 120 seconds. This reveals a Videobridge that only falls out of the pool after its health interval.

https://mail.example.test/meet/forgeone-meet-stability

Screenshot: The third user joins the running room.

https://mail.example.test/meet/forgeone-meet-stability

Screenshot: After 30 seconds, all three participants are still visible.

https://mail.example.test/meet/forgeone-meet-stability

Screenshot: After 60 seconds, the conference remains stable.

https://mail.example.test/meet/forgeone-meet-stability

Screenshot: After 120 seconds, all three participants are still connected.

Final acceptance from the test:
- Prosody: active
- Jicofo: active
- Jitsi Videobridge: active
- JVB health: HTTP 200
- three participants visible after 30 seconds
- three participants visible after 60 seconds
- three participants visible after 120 seconds
- failedRequests: 0
- videobridgeNotAvailable: 0
- BridgeChannel closed: 0

Production checklist

  1. Validate FQDN, TLS certificate and nginx routes for `/meet/`.

  2. Monitor Prosody, Jicofo and JVB as systemd services.

  3. Open UDP `10000` from the real client networks to the Videobridge.

  4. Test Colibri WebSocket through HTTPS/WebSocket proxying.

  5. For NAT, configure static ICE mapping with local bridge address and reachable client address.

  6. For internal-only 10.x use, align JVB health with that topology deliberately.

  7. Keep IPv6 enabled only when DNS, routing and firewall are correct for it.

  8. Test two and three participants with separate devices or browser profiles.

  9. Check logs for `videobridgeNotAvailable`, `No valid IP addresses available for harvesting`, ICE restarts and BridgeChannel errors.

  10. Repeat the same multi-user test after updates.

Sources and validated basis

  • grommunio 2026.06.1 release notes: grommunio Suite with meetings, identities and the new admin interface.

  • grommunio roadmap: 2026.06.1 as the current stable GA version with openSUSE Leap 16.0 appliance base.

  • Jitsi self-hosting guide: static ICE/NAT mapping in `ice4j.harvest.mapping.static-mappings` for Videobridges behind NAT.

  • Validated appliance: grommunio 2026.06.1, Meet/Jitsi packages from the grommunio repository, synthetic FQDN `mail.example.test`, multi-user test with real browser contexts.

grommunio 2026 step by step

This series is meant as a practical sequence: start with the base installation, then add mail protection, central sign-in, video meetings and chat.

  1. Install grommunio 2026
  2. Set up grommunio-antispam with Rspamd
  3. Set up grommunio-auth with Keycloak
  4. Set up and test grommunio Meet (you are here)
  5. Set up and test grommunio Chat

Licensing and evaluation

If you want to evaluate grommunio or need licences for a production environment, you can contact ForgeOne. As a grommunio Gold Partner, we support architecture, licensing, installation, migration, SSO, antispam, Meet, monitoring, backup and support.

Introduce grommunio Meet in production

ForgeOne plans, licenses and operates grommunio as a sovereign collaboration platform including mail, calendars, contacts, grommunio-auth, grommunio-antispam, grommunio Meet, monitoring, backup and support. If you want to integrate video meetings into your grommunio environment, we can review network path, TLS, TURN/STUN, firewall, user privileges and operations with you.

Discuss grommunio Meet