Octo requirements

Yes, the Prosody and Jicofo are separated. In order to have a conference, the users must end on the same shard. The conferences are based on MUC rooms in XMPP and the XMPP server Prosody is not federated throughout the setup, each shard has its own prosody and its own jicofo - so even if the room name and the URL is the same, the MUC room will be different if you load different shards.

After that, on the JVB level, you can have OCTO and you have connection between the bridges etc., but on the signalling level you need to “gather” all the participants in a specific conference on the same signalling node.

Once again, it’s easier to do this with HAProxy, it gives you the stick tables, it stores in memory the URLs and you can use the same backend (the same shard) for an already recently accessed URL.

I would do this with HAProxy, but once again it can be done with Nginx, even though the haproxy has a lot more options, in nginx you have for example the following: https://nginx.org/en/docs/http/ngx_http_upstream_module.html#hash

The idea is to achieve url-stickiness and session persistence, so that once an URL is accessed, all other peers go the same path (to the same backend) and all including the first one keep (re)loading the same backend, until some timeout (session) expires.

N.B.: I’ve never done it with Nginx only (yet), so please take the above with a grain of salt. :slight_smile:

As for the video, you are right, it’s getting old, I really have to make updated version(s). The main concepts there are the same, but the details are different - for example today you would connect the JVBs not as components to XMPP, but as clients in a MUC. So if you follow the principles and not the step-by-step instructions and bash command lines, it’s still relevant as a howto. I’ll try to update it, once I find the time…

2 Likes