Octo does not seem to "exist"

Hi all,

I’ve configured octo in my simple setup in a single Jitsi-Meet:

  • jvb1 (region1) - in same vm as Jitsi-Meet
  • jvb2 (region2) - separate vm
  • jvb3 (region1) - separate vm

From jicofo log:
Jicofo 2021-04-09 11:03:17.702 INFO: [30] org.jitsi.jicofo.bridge.BridgeSelector.log() Added new videobridge: Bridge[jid=jvbbrewery@internal.auth.meet1.test.lab/jvb3, relayId=192.168.122.56:4096, region=region1, stress=0.00]
Jicofo 2021-04-09 11:03:17.752 INFO: [30] org.jitsi.jicofo.bridge.BridgeSelector.log() Added new videobridge: Bridge[jid=jvbbrewery@internal.auth.meet1.test.lab/jvb1, relayId=192.168.122.51:4096, region=region1, stress=0.00]
Jicofo 2021-04-09 11:03:17.775 INFO: [30] org.jitsi.jicofo.bridge.BridgeSelector.log() Added new videobridge: Bridge[jid=jvbbrewery@internal.auth.meet1.test.lab/jvb2, relayId=192.168.122.55:4096, region=region2, stress=0.00]

When conferences are created, the octo feature does not seem to exist, although the log did show the region information:

Jicofo 2021-04-09 11:04:03.066 INFO: [30] org.jitsi.jicofo.bridge.BridgeSelectionStrategy.log() Selected initial bridge Bridge[jid=jvbbrewery@internal.auth.meet1.test.lab/jvb1, relayId=192.168.122.51:4096, region=region1, stress=0.00] with reported stress=0.0 for participantRegion=Europe using strategy RegionBasedBridgeSelectionStrategy
Jicofo 2021-04-09 11:04:03.115 INFO: [30] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Region info, conference=8074940: [[region1, Europe]]
Jicofo 2021-04-09 11:04:03.145 INFO: [30] org.jitsi.jicofo.bridge.BridgeSelectionStrategy.log() Selected bridge Bridge[jid=jvbbrewery@internal.auth.meet1.test.lab/jvb1, relayId=192.168.122.51:4096, region=region1, stress=0.01] with stress=0.0 for participantRegion=Europe
Jicofo 2021-04-09 11:04:03.154 INFO: [30] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Region info, conference=8074940: [[region1, Europe, Europe]]

Jicofo 2021-04-09 11:04:29.672 INFO: [30] org.jitsi.jicofo.bridge.BridgeSelectionStrategy.log() Selected initial bridge Bridge[jid=jvbbrewery@internal.auth.meet1.test.lab/jvb2, relayId=192.168.122.55:4096, region=region2, stress=0.00] with reported stress=0.0 for participantRegion=Europe using strategy RegionBasedBridgeSelectionStrategy
Jicofo 2021-04-09 11:04:29.699 INFO: [30] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Region info, conference=8073685: [[region2, Europe]]
Jicofo 2021-04-09 11:04:29.718 INFO: [30] org.jitsi.jicofo.bridge.BridgeSelectionStrategy.log() Selected bridge Bridge[jid=jvbbrewery@internal.auth.meet1.test.lab/jvb2, relayId=192.168.122.55:4096, region=region2, stress=0.01] with stress=0.0 for participantRegion=Europe
Jicofo 2021-04-09 11:04:29.722 INFO: [30] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Region info, conference=8073685: [[region2, Europe, Europe]]

Specifically, I can’t seem to find “octo_enabled= true” or “octo_enabled= false” in the org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Region info, conference=xxxxxx: [[xxxxxx, xxxxxx, xxxx]] line. How do I know if octo exists in my setup or really working?

jvb1’s sip-communicator.properties:
org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME=jvb1
org.jitsi.videobridge.octo.BIND_ADDRESS=localhost
org.jitsi.videobridge.octo.PUBLIC_ADDRESS=192.168.122.51
org.jitsi.videobridge.octo.BIND_PORT=4096
org.jitsi.videobridge.REGION=region1

jvb2’s sip-communicator.properties:
org.jitsi.videobridge.octo.BIND_ADDRESS=localhost
org.jitsi.videobridge.octo.PUBLIC_ADDRESS=192.168.122.55
org.jitsi.videobridge.octo.BIND_PORT=4096
org.jitsi.videobridge.REGION=region2

jvb3’s sip-communicator.properties:
org.jitsi.videobridge.octo.BIND_ADDRESS=localhost
org.jitsi.videobridge.octo.PUBLIC_ADDRESS=192.168.122.56
org.jitsi.videobridge.octo.BIND_PORT=4096
org.jitsi.videobridge.REGION=region1

jicofo’s sip-communicator.properties:
org.jitsi.jicofo.BRIDGE_MUC=JvbBrewery@internal.auth.meet1.test.lab
org.jitsi.jicofo.BridgeSelector.BRIDGE_SELECTION_STRATEGY=RegionBasedBridgeSelectionStrategy
org.jitsi.jicofo.SHORT_ID=123

My jicofo version is 1.0-692-hf-1.

Thanks!
Garry

You want to split your users on different bridges right ?

For the time being, I am trying out splitting the users by region.

I was assuming that participants coming from the URL with:
deploymentInfo: {
shard: “shard1”,
region: “region1”,
userRegion: “Europe”
},

will have their conferences in jvb1 anf jvb3 only. jvb2 (region2) should be “skipped” for participants with (coming from) region1.

jvb2 (region2) would be for those participants coming from region2.
deploymentInfo: {
shard: “shard1”,
region: “region2”,
userRegion: “Apac”
},

Is my assumption about RegionBasedBridgeSelectionStrategy correct?

Thanks,
Garry

I think what is happening here is you have different notations for the regions, stick to one. If jvb is configured to use region1 and region2 use it and for userRegion.

So in deployment info there are two regions cause region to which shard the user connected to … where userRegion is the region the client is connecting from.

I open a conference in Europe and as I’m located in Europe and Europe is region one, I will have:

region: “region1”,
userRegion: “region1”

You connect from US (region2) to the same meeting so you will have:

region: “region1”,
userRegion: “region2”

In other words region1 is returned from the config.js on the shard statically, where userRegion is set from the HAProxy that is closest to you and which you are using (passed as param) and set in config.js using that param.

Hi Damian,

Thanks for the pointer. Managed to get it working. Participants from different regions are now properly placed in their corresponding regional jvbs.

Jicofo 2021-04-12 18:39:31.333 INFO: [30] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Region info, conference=8116163: [[region1, region1]]
Jicofo 2021-04-12 18:39:31.347 INFO: [30] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Region info, conference=8116163: [[region1, region1, region1]]

However, it is still missing the “octo_enabled= true”.

Thanks,
Garry

Hi Damian,

I’ve just checked the codes. “octo_enabled= true” has been removed since Dec 2, 2020. I was looking at May 2020 logs from other postings. Sorry for the confusion.

Best regards,
Garry