I have been looking into enabling octo on our setup for some time. We have multiple JVB’s that connect fine to jicofo. I have followed the official documentation here, that seems to be a bit outdated to my understanding. I have also followed the community thread here.
I am stuck in a situation where conferences work and I see the correct region (we have single region) reported in jicofo logs, but octo_enabled is always false in the logs like so:
I have added the region info to the jitsi meet config.js as well to the JVB’s configs. I have also added the octo probability with value of 1 to the config.js:
However, the octo_enabled value in the jicofo logs remains false. I am beginning to think that the probability value has no effect at all and might have been removed since I did not find any references to it other than in Readme’s. It’s not present in meet.jit.si config.js either.
I guess my main question is: Does this config value still exist and if yes, is it supposed to affect the jicofo log message above? Many thanks for the help!
Thanks Boris! This is very likely the culprit. However, it seems like we first need to update our setup since config has moved from sip-communicator.properties to jicofo.conf. By the way, does the JVB now have something similar? I mean has the relevant config moved to jvb.conf so we’d need to also add something like:
enabled = true
in jvb.conf. So far we have added the JVB parameters to the jvb sip-communicator.properties as described in the official guide.
Now I have updated our setup to use the latest stable images. I added the enabled = true to jicofo.conf and now I can see three servers instead of one when connecting to a meeting. I have enabled the SplitBridgeSelectionStrategy to test the multi-bridge setup.
However, now it seems that participants on different bridges cannot send or receive media to each other. Everything works if the participants remain on a single bridge (for example when RegionBasedBridgeSelectionStrategy is used).
The bridges seem to connect to jicofo fine and I don’t spot anything obvious from the logs. This could indicate something, but I am unsure what it means:
Unable to find endpoint to send EndpointMessage to: aeb8cd13
@Boris_Grozev Would you have any pointers on what might be causing this? Are the bridges somehow unaware of each other?