How JVB 2.0 work in MUC mode?

Hi Jitsi team,

Can you explain how JVB 2.0 work in MUC mode? Before JVB 2.0, Jicofo/Jigasi/Jvb all works as a XMPP component. What are the motivations to move from component mode to MUC mode and what are the advantages?

Thanks in advance,

/Kaiduan

Hi Kaiduan,

Jitsi-videobridge supports both connecting as an XMPP component and an
a user (entering a MUC). Both are supported since v1.0, but the XMPP
component in being deprecated and will be removed at some point in the
future.

The main advantage of using a user connection in general is that it
doesn’t require the XMPP server to be pre-configured with a set of
possible accounts, and the jitsi-videobridge machines configured with
a separate account each. You can just provision a set of machines with
the same user account, and XMPP generates a unique ‘resource’ for
each.

On the implementation level, the main advantage is that with user
accounts a jitsi-videobridge instance can connect to multiple XMPP
servers.

Regards,
Boris

Boris,

Many thanks for detailed explanation. For MUC mode,

  1. How JVB know which MUC to join?

  2. How COLIBRI messages are transmitted between JVB and JICOFO?

  3. I assume switching to MUC mode does not break the COLIBRI REST API support. Please advise.

Thanks,

/Kaiduan

  1. With configuration like this:
    org.jitsi.videobridge.xmpp.user.shard.HOSTNAME=localhost
    org.jitsi.videobridge.xmpp.user.shard.DOMAIN=auth.test.jitsi.net
    org.jitsi.videobridge.xmpp.user.shard.USERNAME=jvb
    org.jitsi.videobridge.xmpp.user.shard.PASSWORD=xxx
    org.jitsi.videobridge.xmpp.user.shard.MUC_JIDS=JvbBrewery@internal.auth.test.jitsi.net
    org.jitsi.videobridge.xmpp.user.shard.MUC=JvbBrewery@internal.auth.test.jitsi.net
    org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME=jvb-123
    org.jitsi.videobridge.xmpp.user.shard.IQ_HANDLER_MODE=sync
    org.jitsi.videobridge.xmpp.user.shard.DISABLE_CERTIFICATE_VERIFICATION=true

To connect to more than one server, add new properties changing “shard” to something else.

Alternatively, for the new bridge you can use the application.conf file with something like this:
apis {
xmpp-client {
configs {
test {
hostname = “test.jitsi.net
domain = “auth.test.jitsi.net
username = “jvb”
password = “xxx”
muc_jids = “JvbBrewery@internal.auth.test.jitsi.net
muc = “JvbBrewery@internal.auth.test.jitsi.net
muc_nickname = “jvb-123”
disable_certificate_verification = true
}
test2 {
hostname = “test2.jitsi.net
domain = “auth.test2.jitsi.net
username = “jvb”
password = “xxx”
muc_jids = “JvbBrewery@internal.auth.test2.jitsi.net
muc = “JvbBrewery@internal.auth.test2.jitsi.net
muc_nickname = “jvb-123”
disable_certificate_verification = true
}
}
}
}

  1. They are transmitted within the MUC (for easier access control).

  2. Correct, all this is orthogonal to the REST API.

Regards,

Boris

Thanks Boris, the MUC JVB joins is a dedicated MUC, it is not same as each XMPP conference participant joins.