TCP/443 : 1 public IP address for multiple JVBs


Is there any way to use 1 public address to route TCP/443 candidates to multiple JVBs through reverse proxies ?

For UDP I use port redirection

x.x.x.x:10000 => JVB-0
x.x.x.x:10001 => JVB-1
x.x.x.x:10002 => JVB-2

But for TCP, nginx is already listening on port 443

Thanks :pray:

How you will match which request is for which jvb, I suppose you are talking about media … ?

Yes I am talking about media traffic.

Here’s what happens for UDP :

  • On each JVB I configure the same public IP address :
  • Then I change the listening port on each one
    org.jitsi.videobridge.SINGLE_PORT_HARVESTER_PORT=10000 on JVB-0
    org.jitsi.videobridge.SINGLE_PORT_HARVESTER_PORT=10001 on JVB-1
  • So the client receives the following ICE candidates :

Now, I want to enable ICE-TCP, but all our TCP/443 traffic goes through Apache Reverse Proxies before reaching Jitsi-Meet server (nginx).

I was thinking maybe Apache Reverse Proxies could read TCP/443 traffic and could somehow distribute it to the right JVB (based on some headers or something else)

Nope there is nothing to look at …

Hey Hamza,

We had a project with this aim a few years ago, but it never got to
anything more than a proof of concept. I pushed it here in case you
want to take a look:

The idea is to multiplex based on the ufrag in STUN binding requests,
with backend bridges encoding their address in their ufrag.

However, the current recommendation is to not use ICE/TCP in favor of
TURN/TLS. We’ve been looking for a solution for demultiplexing
TURN/TLS and HTTPS, and while it’s doable we don’t have anything
ready, so you will need one additional IP address for the TURN server.

Hope this helps,

Thank you guys for the prompt reply.

@Boris_Grozev I have a question, isn’t TURN recommended for 2-participant conferences only ? does it also support multiple participants using TCP?

Clients can connect to jitsi-videobridge through a TURN/TLS tunnel:

Client <–TURN/TLS tunnel–> TURN Server <–ICE on UDP/10000–> Jitsi-Videobridge

We recommend this instead of ICE/TCP because some firewalls can recognize ICE/TCP and block it.


Ok, now I see.
Thank you