This is a follow-up on a conversation that we had in "the Call" earlier
today. As requested by Saúl, I'm writing this down, to provide you with a
background for further discussion on the subject in a future call.
My apologies for the length of this thing.
The context of much of this is the "Openfire Meetings" (ofmeet) plugin that
we've been working on:
In its core, Openfire Meetings intends to provide a once-click solution
that brings web-based conference functionality to Openfire. It does so by
integrating JVB, Jicofo, and jitsi-meet into the Openfire server. It's
current state is a bit rough around the edges, but it works. If you have a
running Openfire instance, you need to do nothing more than hit 'install'
in our list of available plugins twice, before you have a running web-based
conference solution. This 15 minute video shows you how to do it (most of
the duration is dedicated to setting up a new EC2 instance and installing
Openfire from scratch): https://community.igniterealtime.org/docs/DOC-5343
Jitsi code is the core, heart and backbone of this solution (and, as we
disabled many features in order to do catch up with upsteam Jitsi changes,
it at this stage is pretty much all Jitsi - but we'll start restoring our
own add-on functionality again soon). Although very versatile, we do run
into a limitation with the Jitsi way of orchestrating things, which is what
all of this introduction has lead up to:
Time and time again, we run into issues that somehow relate to having a
focus user. Emphasis on "user."
From a "write once, connect everywhere" perspective, using client
connections makes sense: you have one implementation, and you make that
talk to any XMPP domain that you want.
From a server integration perspective, it's a less optimal solution. There
are a couple of drawbacks. Issues that we have / had:
- there must be a "system user" - which is less trivial than it might
sound. Openfire, for instance, often integrates with existing user bases
(AD / LDAP / Crowd / etc), some of which are considered read-only. Having
to provision a user account often requires manual interaction (and,
depending on company policies, bureaucracy).
- the user must be named 'focus' (which is a minor nuisance and probably
fixable), but the name is common enough to lead to collisions with existing
- client connections are used, which introduces a heap of code and
- You need a client library (Smack) integrated in a server-sided
component, which as a concept is a strange thing to do.
- Client authentication is used, which requires configuration, and
can lead to issues when things like GSSAPI are configured on the
a server-sided component, a different trust model can/should apply.
- User-clients (jitsi-meet, but also auditing tools and loggers) need to
account for an occupant in the MUC that's not really an occupant (visually,
it needs to be hidden).
- The focus user must be able to join the MUC - which again often fails.
Currently, it for instance is impossible to have a pre-existing,
password-protected MUC (something that you'd use for a persistent /
recurring meeting). The focus occupant won't be able to join the MUC when
it's password protected. Currently, password protection "works" by first
creating a non-private room, let focus join, and then set a password.
And the list goes on. Combined with all of the flexibility that we'd like
to provide with the Openfire integration, this makes for a fragile system.
Nine out of ten attempts, a conference fails, and, we'll have to work down
a list of potential issues, even before we get to the "normal" WebRTC
For concise server-sided integration, I'd love to be able to remove the
need for "focus" that connects as a regular XMPP client.
At a very high level, focus is an addressable entity, that orchestrates
XMPP data between end-users and the videobridge. Conceptually, I think that
any addressable entity will be able to fulfill this role. Being based on
MUC, we have addressable entities at our disposal: the MUC room itself is
an addressable entity (and already has a pretty similar purpose:
orchestrating IM data between room participants).
My thought was to add 'focus' functionality to the MUC implementation in
Openfire. From the perspective of a conference participant, nothing really
changes: instead of "doing" COIN / COLIBRI with focus, it exchanges the
same data with the JID of the MUC itself. Another upside of a specific
implementation would be that I'd probably be able to build it in a way that
would easily adapt to the up-and-coming MIX implementation (that will
replace MUC, eventually).
There are major drawbacks though. Much of the business logic of jicofo will
need to be ported (everything minus the client connection implementation)
and kept in sync. This would be a challenge even when the existing
implementation would follow the specification to the letter, and all
functionality would be in that specification - both of which are likely
untrue. Also, this feels partly like re-inventing the wheel, and as such a
waste of time.
This is pretty much what I described in "the Call" earlier today. I would
love your feedback on this, to see if there are practical solutions to the
issues that I described.
If possible, I'd like to avoid much duplication in Openfire code-base (if
that is feasible to begin with), but I'm unsure if there are viable other
solutions. Things that I'm toying with in my head:
- Can the business logic be separated from the client-connection code in
Jicofo, in such a way that it can be re-used as a library?
- Can jicofo be(come) a full MUC (MIX?) implementation (which would
replace client connections with a XEP-0114-based component connection.
I wonder if you see viable solutions. If you made it to here: thanks for
sticking with me.