Jitsi Videobridge Plugin as an XMPP external component

Hi Dele,

I’m wondering how difficult would it be to make Openfire Jitsi Videobridge Plugin acting as an XMPP external component, similar to the original Jitsi Video Bridge approach. The difference would be that your component would speak Rayo instead of Colibri. And I guess web apps cannot be served so easily anymore by a standalone external component and need to be deployed on a dedicated web server.

I looked at the sources and it looks like PluginImpl.java is most likely the class to be changed. It seems to create an internal component currently. So, to make it an external component, one would simply create an ExternalComponent and register it with a ComponentManager. Is it a correct understanding? Or may be this plugin has more places in its code where it is tighly coupled with Openfire? Could you shed some light on this?

What do you think of the overall idea?

Would you welcome the possibility of having your Rayo-based plugin available as both Openfire plugin and external component that is not tighly coupled to Openfire and could be used with other XMPP servers (e.g. ejabberd, etc)?

Would you include the changes into the trunk?

Thanks,

Leo

If you want to use Jitsi Videobridge as an external component, then use it as orginally designed by the Jitsi team. Follow the notes here Free & Open Source Video Conferencing | Jisti Projects.

The Colibri xmpp external component lives inside Jitsi code. It is exposed to Openfire as an internal component. I have made minor changes to Jitsi to get access to the Videobridge object in order to access the media streams for media recording and telephone integration with SIP (which is working) and later on Jingle.

Would you welcome the possibility of having your Rayo-based plugin available as both Openfire plugin and external component that is not tighly coupled to Openfire and could be used with other XMPP servers (e.g. ejabberd, etc)?

Would you include the changes into the trunk?

The Jitsi Videobridge plugin for Openfire is designed to be tighlty coupled to Openfire in order to provide voice and video support to anything and everthing in Openfire, giving an overall better use experience and making the best of the Openfire server APIs. The Jetty web server in Openfire is adequate for the job and enables me to do everything from Openfire without the need for an additional web server. I intend to add support for Openfire clustering later.

I am happy to include any pull changes to the trunk provided they don’t handicap my use of the Openfire APIs and don’t force me to wite or propose new XEPs. I however supspect that it will be increasing difficult to do this by the time I finish all the changes.

My candid advise would be to wait for Jitsi, most of the changes (SIP, third party focus) I am making to the plugin are planned for the core library. It is just a matter of time.

Dele Olajide wrote:

If you want to use Jitsi Videobridge as an external component, then use it as orginally designed by the Jitsi team. Follow the notes here https://jitsi.org/Projects/JitsiVideobridgeWithOpenfire.

Yes. This is an option. But I wanted to use e.g. your Rayo-based third-party focus support.

The Jitsi Videobridge plugin for Openfire is designed to be tighlty coupled to Openfire in order to provide voice and video support to anything and everthing in Openfire, giving an overall better use experience and making the best of the Openfire server APIs. The Jetty web server in Openfire is adequate for the job and enables me to do everything from Openfire without the need for an additional web server. I intend to add support for Openfire clustering later.

I totally understand why you provided your code as a plugin and not as an external component. It absolutely makes sense, because you provide also web apps and a few other features that make use of Openfire.

But in my use-case I do not need to use JitMeet or OfMeet apps provided by your plugin, as I have my own web-apps deployed elsewhere to provide a Web GUI for video conferencing. I also would like an XMPP server with a smaller footprint than OpenFire, as I don’t need most of its features.

In principle, I only need the control plane logic provided by means of Rayo and your plugin for 3rd party focus control. This is the main reason why I asked the original question. I’m still wondering if this logic could be extracted from your plugin in a reasonably easy way and then packaged as e.g. a remote component. But I’m not so sure about it. It looks like you access internal APIs, e.g. VirtualConnection or MUCEventListener, which are most likely not available for external components. Or do you think it is possible?

My candid advise would be to wait for Jitsi, most of the changes (SIP, third party focus) I am making to the plugin are planned for the core library. It is just a matter of time.

This is very interesting! Could you elaborate a bit more? If it is planned for the core library, is it agreed with Jitsi development team already? Will it be based on Rayo or any extensions of Colibri or may be something else? Do you have a rough estimate when it will be introduced in the core library (e.g. this quarter, this year)? I’d be greatful for any information on this topic.

Thanks,

Leo

This is very interesting! Could you elaborate a bit more? If it is planned for the core library, is it agreed with Jitsi development team already? Will it be based on Rayo or any extensions of Colibri or may be something else? Do you have a rough estimate when it will be introduced in the core library (e.g. this quarter, this year)? I’d be greatful for any information on this topic.

You can track the issues for an idea of planned changes. Also, you look at an alternative way for the third party focus control. See Auto-elect a new focus if the original bails · Issue #34 · jitsi/jitsi-meet · GitHub

VirtualConnection was used to implement a virtual user, you could use Smack or any client library instead. MUCEventListener allowed me to get global MUC join/leave room events. You really don’t need that to implement a third party focus especially if you decide to use an alternative room implementation as wevryone does with WebRTC.

For a very small footprint XMPP that is even more up to date than Openfire, take a look at Prosdy.

Dele Olajide wrote:

This is very interesting! Could you elaborate a bit more? If it is planned for the core library, is it agreed with Jitsi development team already? Will it be based on Rayo or any extensions of Colibri or may be something else? Do you have a rough estimate when it will be introduced in the core library (e.g. this quarter, this year)? I’d be greatful for any information on this topic.

https://github.com/jitsi/jitsi-meet/issues/16

Thanks for this link! I was not aware of it. Yes. It seems to go in the right direction.

Also, you look at an alternative way for the third party focus control. See https://github.com/jitsi/jitsi-meet/issues/34

Well, this approach relies too much on the client-side logic. This is why I’m trying to avoid this kind of solutions. I want my clients to be as dumb as possible, so that it is easy to create new Web clients or standalone apps.

VirtualConnection was used to implement a virtual user, you could use Smack or any client library instead.

Ah, OK. That explains a few things.

MUCEventListener allowed me to get global MUC join/leave room events. You really don’t need that to implement a third party focus especially if you decide to use an alternative room implementation as wevryone does with WebRTC.

Exactly. I came to the same conclusion today. Basically, I already have a non-XMPP based way of chat control and I receive corresponding events. I just need to use them instead of what MUCEventListener reports.

For a very small footprint XMPP that is even more up to date than Openfire, take a look at Prosdy.

Yes. I already started looking at it. It is really small. But getting MUCEventListener-like events from it could be problematic, unless you want to implement support for chat rooms as an external component. But Prosody is still nice a light-weight XMPP server that can be used for delivering XMPP messages.

Actually, I went even a bit further in the direction of eliminating a need for an XMPP server. I created an experimantal ExternalSocketComponent using Whack. It is like ExternalComponent and can be started either to receive connections or to establish connections to remote ExternalSocketComponent. Internally, it wraps a usual Component, just like ExternalComponent does. The difference is that now two components may talk to each other directly via sockets. They do not need any XMPP server to exchange XMPP packets between each other. In scenarios, where you are more interested in the XMPP payload, but not so much in how it was delivered, it could be useful. Obviously, it misses many features of a real XMPP server, e.g. presence handling, chat rooms, etc. To test this approach, I took the vanilla Jitsi Video Bridge component and wrapped it into an ExternalSocketComponent. And it seems to work just fine. I can now connect from my client to the VideoBridge directly over a socket, bypassing any XMPP server.

And it seems to work just fine. I can now connect from my client to the VideoBridge directly over a socket, bypassing any XMPP server.

Way cool . Well done. Just a suggestion

Try to implement XMPP federation (if not already available) on your external socket component. That will enable you to remain compatible with XMPP servers in case you need it later.