Jitsi JVBs Cascading : security

Hi Every one,

Is jitsi JVB to JVB cascading is secure? if yes what encryption it uses.


Right now traffic moving between bridges is not encrypted, as we never go outside a single datacenter when transmitting data across the Octo link. We do have plans to encrypt this traffic (and e2ee will result in this traffic being encrypted as well).

Thanks @bbaldino
So, when participants are joining from two different regions with cascading, the data from one region to other region is plain?

We don’t currently do inter-region cascading on meet.jit.si, just multiple bridges within one region. But if you deploy your own server, then yes Octo traffic will be unencrypted.

@bbaldino is there anyway that we can enable inter-region cascading if we deploy our own servers?

Yes, you can do them however you want, we just don’t currently deploy them that way.

@bbaldino sorry it was typo in my question. Is there a way to enable encryption in inter-region cascading if we deploy our own servers?

No, that code doesn’t exist today. In case you want to implement this on your own (I’m not sure when we’ll get to it), I recently laid some of the groundwork for it. These lines show the UDP transport class and the Octo transport class. The plan is to insert a crypto layer between those two layers. There are of course details around keys and all that, but you could figure out how you want to do those for your use case.

Hi @bbaldino thanks for your response. May I know if there is a specific reason why meet.jit.si infrastructure itself didn’t have JVB cascading for the meetings which are inter-region, though the solution is available.

Do you think cascading affects the performance for video conference or by introducing encryption will hit the performance.

Just curious whether its a good idea or not to have cascading in place.

Thanks a lot.

Hi @bbaldino

Please let me know.


1 Like


When we scaled up the service to meet increasing demand in March, we added a large number of new shards (jicofo instances) so cross-connecting all shards wasn’t feasible anymore. We disabled cross-region connections temporarily until we can do it in a better way.

Another reason is that getting the selection strategy right turned out to be harder than we thought. Just selecting a bridge in the closest region for each participants has unintended negative effects (increasing RTT on average). Send me a direct message if you’re interested in the details.

Overall, cascading has an overhead in terms of performance. However, it can spread the load between multiple machines, avoiding any one of them getting overloaded. This is how it is currently used on meet.jit.si.