[jitsi-users] CORS + port harvesting when distributing


#1

Hello,

I have the following setup when using more than one instance of jitsi-meet:
- A redundant App server with jitsi-meet-web served from one subdomain
- X Video instances of BOSH/prosody+jicofo+videobridge located on other
servers each with their own subdomain
- Clients "smartly" distributed across the Video instances by the App
server so that they end up on the right one

In order to support that, I'm having to put nginx in front of the BOSH
setup to add CORS headers, as the jetty as built into jitsi-videobridge
doesn't appear to have options exposed to set up CORS. This results in the
videobridge running on port 4443 or somesuch

Unfortunately, I believe that means I'm losing out on the optimal setup on
port 443 with the port harvesting feature of the video bridge when clients
are on restrictive networks, or likely needing to add an extra public IP to
X instances for the videobridge to bind to in order to use port 443.

Is my thinking correct? Is there a better way to arrange things to
eliminate nginx, the extra IP's on the Video instances, and have the
videobridge + BOSH available on port 443 or is this the optimal way?

Cheers,
Simon


#2

Hi Simon,

···

On 31/05/2018 17:47, Simon Ditner wrote:

Hello,

I have the following setup when using more than one instance of jitsi-meet:
- A redundant App server with jitsi-meet-web served from one subdomain
- X Video instances of BOSH/prosody+jicofo+videobridge located on other servers each with their own subdomain
- Clients "smartly" distributed across the Video instances by the App server so that they end up on the right one

In order to support that, I'm having to put nginx in front of the BOSH setup to add CORS headers, as the jetty as built into jitsi-videobridge doesn't appear to have options exposed to set up CORS. This results in the videobridge running on port 4443 or somesuch

Unfortunately, I believe that means I'm losing out on the optimal setup on port 443 with the port harvesting feature of the video bridge when clients are on restrictive networks, or likely needing to add an extra public IP to X instances for the videobridge to bind to in order to use port 443.

Is my thinking correct? Is there a better way to arrange things to eliminate nginx, the extra IP's on the Video instances, and have the videobridge + BOSH available on port 443 or is this the optimal way?

I think the easiest solution would be to make jitsi-videobridge add the CORS headers that you need. It's not currently supported, but it shouldn't be hard to add.

Regards,
Boris


#3

You were right, it wasn't too hard to add -- even for someone who doesn't
write java :wink: Pull request submitted.

···

--
Simon P. Ditner <spditner@gmail.com>
Office: +1 (416) 848-7573 / Mobile: +1 (647) 899-1293

On Fri, Jun 1, 2018 at 11:51 AM, Boris Grozev <boris@jitsi.org> wrote:

Hi Simon,

On 31/05/2018 17:47, Simon Ditner wrote:

Hello,

I have the following setup when using more than one instance of
jitsi-meet:
- A redundant App server with jitsi-meet-web served from one subdomain
- X Video instances of BOSH/prosody+jicofo+videobridge located on other
servers each with their own subdomain
- Clients "smartly" distributed across the Video instances by the App
server so that they end up on the right one

In order to support that, I'm having to put nginx in front of the BOSH
setup to add CORS headers, as the jetty as built into jitsi-videobridge
doesn't appear to have options exposed to set up CORS. This results in the
videobridge running on port 4443 or somesuch

Unfortunately, I believe that means I'm losing out on the optimal setup
on port 443 with the port harvesting feature of the video bridge when
clients are on restrictive networks, or likely needing to add an extra
public IP to X instances for the videobridge to bind to in order to use
port 443.

Is my thinking correct? Is there a better way to arrange things to
eliminate nginx, the extra IP's on the Video instances, and have the
videobridge + BOSH available on port 443 or is this the optimal way?

I think the easiest solution would be to make jitsi-videobridge add the
CORS headers that you need. It's not currently supported, but it shouldn't
be hard to add.

Regards,
Boris