[jitsi-dev] The tale of Jicofo and the client connections


#1

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:
https://github.com/igniterealtime/ofmeet-openfire-plugin

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
   users.
   - client connections are used, which introduces a heap of code and
   complexity:
      - 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
server. As
      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
problems.

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.

Regards,

  Guus


#2

Hey Guss,

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:
https://github.com/igniterealtime/ofmeet-openfire-plugin

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
users.
client connections are used, which introduces a heap of code and complexity:

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 server. As 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 problems.

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?

I don't see any problem with that. It will take some time though.

Can jicofo be(come) a full MUC (MIX?) implementation (which would replace
client connections with a XEP-0114-based component connection.

We were thinking about doing something similar for Prosody, but
haven't come up with anything specific yet. The reason we've made
things this way originally was that it uses only XMPP mechanisms
without special plugins, but now we need plugins for other things, so
we may go in that direction with Jicofo too (or at least part of it).

Regards,
Pawel

···

On Mon, Jul 3, 2017 at 12:48 PM, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:


#3

In Jicofo we have few interfaces inherited from Jitsi for the user
connection layer. Maybe it would be possible to use them to fake user
connection. Please take a look at these two and check what and how
they implement:

https://github.com/jitsi/jicofo/blob/master/src/main/java/org/jitsi/impl/protocol/xmpp/ChatRoomImpl.java
https://github.com/jitsi/jicofo/blob/master/src/main/java/org/jitsi/impl/protocol/xmpp/XmppProtocolProvider.java

···

On Mon, Jul 10, 2017 at 8:20 AM, Paweł Domas <pawel.domas@jitsi.org> wrote:

Hey Guss,

On Mon, Jul 3, 2017 at 12:48 PM, Guus der Kinderen > <guus.der.kinderen@gmail.com> wrote:

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:
https://github.com/igniterealtime/ofmeet-openfire-plugin

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
users.
client connections are used, which introduces a heap of code and complexity:

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 server. As 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 problems.

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?

I don't see any problem with that. It will take some time though.

Can jicofo be(come) a full MUC (MIX?) implementation (which would replace
client connections with a XEP-0114-based component connection.

We were thinking about doing something similar for Prosody, but
haven't come up with anything specific yet. The reason we've made
things this way originally was that it uses only XMPP mechanisms
without special plugins, but now we need plugins for other things, so
we may go in that direction with Jicofo too (or at least part of it).

Regards,
Pawel


#4

Hey Pawel,

Would you mind me contacting you over IM? I've got some
implementation-specific questions. You can add me via XMPP at
guus.der.kinderen@igniterealtime.org

Regards,

  Guus

···

On 10 July 2017 at 15:29, Paweł Domas <pawel.domas@jitsi.org> wrote:

In Jicofo we have few interfaces inherited from Jitsi for the user
connection layer. Maybe it would be possible to use them to fake user
connection. Please take a look at these two and check what and how
they implement:

https://github.com/jitsi/jicofo/blob/master/src/main/
java/org/jitsi/impl/protocol/xmpp/ChatRoomImpl.java
https://github.com/jitsi/jicofo/blob/master/src/main/
java/org/jitsi/impl/protocol/xmpp/XmppProtocolProvider.java

On Mon, Jul 10, 2017 at 8:20 AM, Paweł Domas <pawel.domas@jitsi.org> > wrote:
> Hey Guss,
>
> On Mon, Jul 3, 2017 at 12:48 PM, Guus der Kinderen > > <guus.der.kinderen@gmail.com> wrote:
>> 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:
>> https://github.com/igniterealtime/ofmeet-openfire-plugin
>>
>> 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
>> users.
>> client connections are used, which introduces a heap of code and
complexity:
>>
>> 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 server. As 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 problems.
>>
>> 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?
>
> I don't see any problem with that. It will take some time though.
>
>> Can jicofo be(come) a full MUC (MIX?) implementation (which would
replace
>> client connections with a XEP-0114-based component connection.
>
> We were thinking about doing something similar for Prosody, but
> haven't come up with anything specific yet. The reason we've made
> things this way originally was that it uses only XMPP mechanisms
> without special plugins, but now we need plugins for other things, so
> we may go in that direction with Jicofo too (or at least part of it).
>
> Regards,
> Pawel

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

Just as a side note from someone who has had absolutely no prior experience with Jicofo:
While updating to Smack 4.2, I've found it to be quite a mess. Everything makes sense on how it is, given where it all started (Jitsi Desktop). Nowadays though, Guus suggestions on making Jicofo a proper server component without beeing a member in a MUC room sounds really promising. The hacks I had to do while upgrading to Smack 4.2 make this even more apparent.

While Guus made it clear that Whack/Tinder aren't going to be made dependent ob Smack (to prevent breaking dependent projects), it might be worthwhile to investigate creating a new server-component-project that understands org.jxmpp.Jid and the IQs/IQProviders from Smack so that the code parsing and creating Stanzas can be shared between client and server components.

Maybe I'm missing something that Guus can point out, but continuing with the current architecture and dependencies is going to be a real PITA long term - for all of Jitsi Desktop, Meet, and external projects.

Cheers,
Ingo

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

···

On 17 Aug 2017, at 14:38, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

Hey Pawel,

Would you mind me contacting you over IM? I've got some implementation-specific questions. You can add me via XMPP at guus.der.kinderen@igniterealtime.org

Regards,

  Guus

On 10 July 2017 at 15:29, Paweł Domas <pawel.domas@jitsi.org> wrote:
In Jicofo we have few interfaces inherited from Jitsi for the user
connection layer. Maybe it would be possible to use them to fake user
connection. Please take a look at these two and check what and how
they implement:

https://github.com/jitsi/jicofo/blob/master/src/main/java/org/jitsi/impl/protocol/xmpp/ChatRoomImpl.java
https://github.com/jitsi/jicofo/blob/master/src/main/java/org/jitsi/impl/protocol/xmpp/XmppProtocolProvider.java

On Mon, Jul 10, 2017 at 8:20 AM, Paweł Domas <pawel.domas@jitsi.org> wrote:
> Hey Guss,
>
> On Mon, Jul 3, 2017 at 12:48 PM, Guus der Kinderen >> > <guus.der.kinderen@gmail.com> wrote:
>> 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:
>> https://github.com/igniterealtime/ofmeet-openfire-plugin
>>
>> 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
>> users.
>> client connections are used, which introduces a heap of code and complexity:
>>
>> 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 server. As 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 problems.
>>
>> 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?
>
> I don't see any problem with that. It will take some time though.
>
>> Can jicofo be(come) a full MUC (MIX?) implementation (which would replace
>> client connections with a XEP-0114-based component connection.
>
> We were thinking about doing something similar for Prosody, but
> haven't come up with anything specific yet. The reason we've made
> things this way originally was that it uses only XMPP mechanisms
> without special plugins, but now we need plugins for other things, so
> we may go in that direction with Jicofo too (or at least part of it).
>
> Regards,
> Pawel

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev